PUB-004 — DECLARACIÓN DE FINALIDAD DE TRANSACCIONES EN BLOCKCHAIN Blockchain Transaction Finality Disclosure
- Entidad / Entity
- BLIIM GLOBAL LLC — Delaware, United States
- Documento / Document
- Declaración de Finalidad de Transacciones en Blockchain / Blockchain Transaction Finality Disclosure
- ID
- PUB-004
- Versión / Version
- V1.1
- Fecha de vigencia / Effective date
- 6 de octubre de 2026 / 6 October 2026
- Ámbito / Scope
- Web, app y funcionalidades de activos digitales habilitadas / Web, app and enabled digital-asset functionalities
ADVERTENCIA PRINCIPAL / CORE WARNING Una transferencia blockchain puede pasar por estados técnicamente distintos antes de ser irreversible o suficientemente irreversible.
“Enviada” “broadcast” “incluida” “confirmada” , , , , “settled” y “final” no son términos necesariamente equivalentes. El grado y tiempo de finality dependen de la red, mecanismo de consenso, condiciones de red, proveedor y arquitectura; una vez alcanzada la finality aplicable, Bliim o sus partners pueden carecer de capacidad técnica o jurídica para revertir o recuperar activos enviados a una dirección, red o destinatario incorrectos.
A blockchain transfer may pass through technically distinct states before becoming irreversible or sufficiently irreversible.
“Sent, ” “broadcast, ” “included, ” “confirmed, ” “settled” and “final” are not necessarily equivalent. The degree and timing of finality depend on the network, consensus mechanism, network conditions, provider and architecture; once applicable finality is reached, Bliim or its partners may lack the technical or legal ability to reverse or recover assets sent to an incorrect address, network or recipient.
1. Purpose
This Disclosure explains how finality operates for digital-asset transfers conducted through blockchain or distributed ledger technology (DLT) networks, including pre-confirmation states, technical reversal risks before finality, variable execution times and recovery limitations after a transfer.
Its objective is to prevent a “sent,” “submitted,” “processing” or “confirmed” indication from being interpreted as a guarantee of final settlement where the network or provider has not yet reached the applicable level of irreversibility.
2. Scope
It applies to on-chain or DLT transfers of digital assets supported by Bliim, including stablecoins and other assets, where the product permits sending, receiving or transferring to or from a distributed ledger address. It also applies where a partner executes the transfer and Bliim only displays the instruction, status or balance.
Specific application depends on Product × Country × Partner, asset, network, custody model and transfer provider.
3. Relationship with Other Documents
PUB-002 contains the general digital-asset risk disclosure. PUB-004 specifically addresses finality, confirmations, execution, irreversibility and responsibility for address/network selection; PUB-005 addresses network fees; PUB-006 custody; PUB-007 unsupported assets/networks; and USR-004 the contractual terms for the wallet/stablecoin/fiat conversion flow.
The specific document prevails as to its subject matter, always subject to mandatory law and non-waivable user protections.
4. Meaning of Finality
Finality describes the point at which a transaction or state change is considered irreversible or sufficiently irreversible under the rules and circumstances of the relevant DLT. The concept is not identical across networks and may depend on consensus rules, checkpoints, confirmation depth, economic security, validator/miner behavior, settlement layers or other technical mechanisms.
The word “final” must not be used in the UI unless a documented definition exists for the relevant network and status.
5. Deterministic, Crypto-Economic and Probabilistic Finality
Some networks provide an explicit finalization state through their protocol; others use probabilistic finality, where reorganization risk decreases as blocks or confirmations accumulate. Crypto-economic, social or layered finality models may also exist.
PUB-004 does not impose a universal taxonomy. Before enabling a network, Bliim must document the applicable finality criterion and align user-facing status labels with the technical information provided by the relevant network and provider.
6. Transfer Lifecycle
A transfer may move through several stages: instruction created, compliance/operational review, signed, submitted to provider, broadcast to network, pending/mempool, included in block, confirmed, sufficiently irreversible/finalized and credited/settled in the destination system. Exact order and meaning may vary.
The application must define its status labels and avoid presenting an intermediate state as final settlement.
Status Meaning Network State Final?
CREATED Instruction created in Bliim Not transmitted No UNDER REVIEW Pre-transfer validations/controls Not necessarily transmitted No SUBMITTED TO PROVIDER Partner received instruction May not be broadcast No ON-CHAIN PENDING Tx broadcast / awaiting inclusion Mempool / network pending No INCLUDED Included in a block May remain exposed to reorg Not necessarily CONFIRMED Meets intermediate confirmation rule Greater confidence Network-dependent FINALIZED / SUFFICIENTLY
IRREVERSIBLE Meets documented criterion Operational finality threshold Yes for defined criterion CREDITED / SETTLED Destination system credited / flow completed May include additional stages Product-dependent
7. Instruction Received Does Not Equal Broadcast
Receipt of an instruction by Bliim or a partner does not mean it has been transmitted to the network.
Before broadcast, there may be balance, address/network, sanctions/AML, fraud, limit, provider-availability, fee, cut-off or other controls.
The receipt timestamp and broadcast timestamp must be distinguished in evidence where materially different.
8. Broadcast Does Not Equal Block Inclusion
A broadcast transaction may remain pending, be rejected by nodes, replaced, expire in certain systems, remain outside a block or require provider adjustments. A transaction hash may establish that an identifiable transaction exists, but does not by itself guarantee final inclusion or economic success.
The UI must distinguish “broadcast/submitted” from “included/confirmed.”
9. Pending, Mempool and Provider Queues
A pending transaction may remain in the network mempool or an internal provider queue for a variable period. Congestion, low economic priority, nonce conflicts, provider controls, node policies or network changes may affect progression.
Exact timing must not be promised unless an SLA or technical mechanism allows it to be stated accurately.
10. Dropped, Replaced, Superseded and Failed
Depending on network and wallet/provider, a pending transaction may be replaced, superseded, dropped or marked failed. On account-based networks, nonce conflicts or fee replacement may change which transaction becomes canonical; different architectures have different rules.
Bliim must display only statuses supported by provider/network data and preserve linkage between attempts where replacement occurs.
11. Confirmations
A confirmation generally indicates that a transaction has been included in a block recognized by the network; additional confirmations may increase confidence against reorganizations in probabilistic-settlement networks. The appropriate number depends on network, consensus mechanism, value, risk and provider policy.
PUB-004 does not set a universal confirmation number for all networks.
12. Sufficiently Irreversible Threshold
For each supported network there must be a documented definition of when a transfer is considered irreversible or sufficiently irreversible for operational purposes. The definition may use a finalization flag, confirmation count, elapsed time, checkpoint, L1 settlement status or another technically appropriate criterion.
The threshold must have a source, owner, version, rationale, testing and last-verified date.
13. Execution Time Is Not Guaranteed
Block, confirmation and finality times may vary even on networks that publish averages. Network congestion, outages, validator/miner conditions, attacks, maintenance, fee markets, provider queues and compliance reviews may cause delay.
A timing estimate is an estimate and not a guarantee unless product-specific terms legally provide otherwise.
14. Chain Reorganizations / Reorgs
Before finality, a network may reorganize part of its canonical history and replace blocks with an alternative chain under its consensus rules. A transaction that was visible or shallowly confirmed may, depending on the network, be excluded or reordered.
The confirmation policy must reasonably account for reorganization risk on the relevant network.
15. Finality Delay, Chain Halt and Consensus Incident
A network may experience finality delay, chain halt, loss of liveness, validator/miner disruption, attack, client bug or another consensus incident. During such events Bliim or the partner may suspend sends/receives, increase confirmation requirements or wait for network recovery.
A visible balance or hash during an incident must not be assumed to mean the transaction is already irreversible.
16. Forks, Upgrades and Protocol Changes
Hard forks, soft forks, protocol upgrades, governance decisions or emergency interventions may affect validation rules, chain identifiers, assets or states. Bliim and its partners may pause operations and decide which chain/version to support, subject to security, legality and provider capability.
The existence of a fork does not guarantee that Bliim will recognize, credit or support assets on both branches.
17. Settlement Layers, Layer 2 and Rollups
Layer 2, sidechain, rollup or other layered architectures may have different finality states: acceptance on the secondary layer, data publication, proof/challenge completion, base-layer settlement and provider crediting. The UX must identify the criterion Bliim actually uses to treat the transfer as completed.
A Layer 1 confirmation threshold must not be applied to Layer 2 without specific technical analysis.
18. Bridges and Cross-Chain Transfers
A cross-chain operation may involve lock/burn on one network, messages or proofs, bridge operators, mint/release on another network and multiple finality assumptions. An incident at any stage may leave the operation delayed, partially completed or subject to bridge/provider recovery procedures.
PUB-004 does not guarantee simultaneous finality on both networks.
19. Network Fees and Prioritization — PUB-005
On some networks, fees influence priority or likelihood of inclusion without creating an absolute timing guarantee. Depending on the network, a fee may be consumed even where smart-contract execution fails.
Fee calculation, estimation, breakdown and presentation are governed by PUB-005 and must be coordinated with the finality status.
20. Destination Address
Blockchain addresses are technical identifiers, and a syntactically valid address may belong to the wrong person, an incompatible contract, an unsupported exchange-deposit route or an unknown entity. A correctly executed transfer to the wrong address may be irreversible.
Users must verify the complete address and any additional required data before confirming.
21. Network Selection
The same commercially named asset may exist on multiple networks or representations. Selecting the wrong network may cause non-credit, loss or complex recovery even where the address appears compatible.
Bliim must clearly display asset + network before confirmation and link PUB-007 where unsupported-network risk exists.
22. Unsupported Assets, Token Contracts and PUB-007
Sending an unsupported asset, token contract or network may not be credited and may be unrecoverable.
A ticker or commercial name is not sufficient to identify an asset; where material, network, contract address and representation type must be considered.
PUB-007 governs these cases and any discretionary recovery.
23. Native, Wrapped and Bridged Representations
A native asset and a wrapped/bridged representation may share a name or economic reference while having different contract, issuer/custodian, bridge, redemption and finality risks. The interface must not lead users to believe they are legally or technically identical.
The Network/Asset Map must identify the exact enabled representation.
24. Smart Contracts and Execution
A transaction may be included and finalized on a blockchain even where a smart-contract call does not produce the expected economic result. Depending on the network, contract execution may revert while the transaction and fee remain recorded.
“Finalized transaction” must not be confused with “successful business outcome.”
25. Tags, Memos, Destination Identifiers and Deposit Instructions
Some products, exchanges or networks may require a memo, tag, destination identifier, reference or other additional data alongside the address. A correct address with missing or incorrect auxiliary data may cause delay, non-credit or manual recovery.
The UI must request and validate such data where the provider requires it.
26. Internal Ledger vs. On-Chain State
Bliim or a partner may maintain an internal ledger reflecting balances before or after an on-chain movement. An internal credit does not necessarily mean network finality has been reached, and a finalized on-chain transaction may require further processing before the internal balance changes.
Ledger and blockchain statuses must be distinguished where relevant.
27. Custody and Transfer Staging — PUB-006
In a custodial model, the provider may batch, net, delay or execute on-chain after internal processing. The user may not control the exact broadcast time or private key.
PUB-006 must identify who has custody/control, and PUB-004 must describe when the provider treats the transfer as executed and final.
28. Receipt of Assets and Crediting Policy
For inbound transfers, an asset may be visible on the network before Bliim or the partner credits it. The provider may wait for confirmations, screening, asset verification or other controls before crediting.
The inbound-confirmation policy must be documented by asset/network and not presented as a universal rule.
29. Cross-Border Transfers and Additional Rails
Where an operation combines an on-chain leg with a bank, payment rail, FX or cross-border settlement, blockchain finality is only one part of the flow. Full settlement may depend on external systems and different timing.
USR-005 and other specific terms determine when the overall service is considered completed.
30. Rejection, Suspension and Return Before Finality
Before broadcast or at stages controlled by the provider, an instruction may be rejected, suspended or returned under AML, sanctions, fraud, limits, unsupported-network, compliance, technical-failure or other valid grounds. After broadcast, cancellation capability depends on the network and provider and may not exist.
The terms must avoid promising a cancellation right that is technically impossible.
31. Refund, Recall and Recovery
A finalized blockchain transfer generally does not operate like a card chargeback or bank recall. A refund may require a new voluntary transfer by the recipient or a specific custodian/provider recovery mechanism.
Lack of technical reversal capability does not automatically eliminate legal rights against Bliim, a partner or another party where applicable law provides a remedy.
32. Unauthorized or Incorrectly Executed Transfers
An on-chain transfer may be technically irreversible while a legal dispute still exists regarding authorization, execution error, security incident or provider liability. The assessment must distinguish technical finality from legal liability.
Bliim’s Unauthorized Transactions & Error Resolution Policy, together with the applicable terms and law, governs the intake, investigation and resolution of these cases.
33. Fraud, Scams and Social Engineering
Irreversibility makes crypto transfers particularly sensitive to scams, impersonation, fake support, romance/investment fraud, address substitution and social engineering. A deceived user may technically authorize a transfer to a fraudster that cannot later be recovered.
Bliim must use proportionate warnings and fraud controls without promising recovery.
34. AML, Sanctions and Pre-Broadcast Controls
Bliim or its partners may apply KYC/KYB, sanctions screening, blockchain analytics, transaction monitoring, Travel Rule/TOFR controls, fraud review and other controls before executing a transfer. These controls may affect timing or result in reject/suspend/hold where a valid basis exists.
A review does not automatically mean the user committed a violation.
35. Spain / EEA — MiCA Transfer Services
Where the service is within MiCA scope, the architecture must apply Article 82 and the ESMA Guidelines on transfer services for crypto-assets as applicable to the provider and service. The Guidelines require, among other elements, identification of the supported DLT, maximum execution time and a reasonable estimate of time or number of block confirmations needed for the transfer to become irreversible or sufficiently irreversible in probabilistic settlement.
Before execution of an individual transfer, the client must receive a brief standardized warning on whether and when the transfer will be irreversible or sufficiently irreversible, together with applicable fee information.
36. United States — Variable Treatment
In the United States, no single federal block-confirmation standard is presumed for all digital-asset transfers. User-facing information must reflect the asset, network, provider, contractual role and any federal or state obligations applicable to the specific product.
Bliim must not convert a technical practice of Bitcoin, Ethereum or another network into a universal legal guarantee.
37. Colombia, Mexico and Brazil — Local Treatment
For Colombia, Mexico and Brazil, the technical nature of blockchain finality does not replace analysis of regulatory perimeter, contractual responsibilities, consumer protection, foreign-exchange or payment treatment, or the role of the relevant partner. Any additional information, authorization, liability or protection requirements will apply according to the product, responsible entity and relevant jurisdiction.
Technical irreversibility must not be used as a general clause to exclude mandatory liability.
38. Status Labels and UX Design
The UI must use a documented and consistent status taxonomy, for example Processing, Submitted, On-chain Pending, Confirmed, Finalized/Completed, Failed, Rejected or Returned, only where the system can support the meaning. Ambiguous terms such as “Done” should be avoided where the flow may still reverse or requires external settlement.
Each label must map to machine status, source, timestamp and user-facing meaning.
39. Timing Communications and Estimates
Confirmation/finality estimates should be displayed as reasonable ranges or values where the network is variable, and should state that congestion or incidents may extend them. If a confirmation counter is displayed, there must be a reliable source and a definition of when the product treats the threshold as met.
Marketing and CX must not promise “instant” or “immediate” where the flow depends on confirmations or subsequent settlement.
40. Reasonable User Responsibilities
Before confirming, users must verify asset, network, destination address, memo/tag where applicable, amount and any visible warning. Users should understand that a finalized transaction may not be reversible and that third parties may control the destination address.
These responsibilities do not remove mandatory rights or obligations of Bliim or a partner.
41. Bliim-Partner Allocation
For each Product × Country × Partner, the architecture must define who receives the instruction, validates address/network, determines fees, signs, broadcasts, monitors confirmations, declares finality, credits balances, investigates failures and manages recovery/complaints.
Technical reliance on a provider does not replace Bliim’s obligation to accurately communicate the role it actually performs for the user.
42. Presentation, Acknowledgement and Just-in-Time Disclosure
PUB-004 must be available as a general disclosure and, for a material on-chain transfer, a just-in-time warning must be presented before the user’s final confirmation. The warning must clearly identify possible irreversibility, selected asset/network and, where applicable, the relevant estimate or confirmation standard.
Bliim may retain reasonable evidence of the version presented, language, user, jurisdiction, product, asset/network, date and time and, where applicable, the presentation or acknowledgement event.
43. Contact
For legal questions relating to this Disclosure, you may contact [email protected].