Cross-chain settlement is the point at which a transfer between two blockchains is final on both sides. The asset is debited on the source chain, credited on the destination, and neither leg can be reversed independently of the other.
This page explains what has to be true for a cross-chain transfer to be settled, how the settlement models differ, and what happens when settlement stalls. To scope settlement for a regulated asset, reach out to our team.
What is cross-chain settlement?
Cross-chain settlement is the completion of a transfer whose two legs execute on different ledgers. One chain records the debit, another records the credit, and there is no shared clock or shared ledger between them.
That gap is the whole problem. A single-chain transfer settles atomically because one ledger records both sides in one transaction, while a cross-chain transfer is a sequence that has to be constructed so the two legs cannot diverge.
What has to be true for a transfer to be settled
Three conditions, in order.
- The source leg is final. The debit must be deep enough in the source chain's history that a reorganization will not undo it.
- The event is verified. A party outside both chains must attest that the source event occurred, and that attestation must be committed on the destination chain.
- The credit has executed. The destination transaction must have run successfully and reached destination finality.
Skipping the first condition is the common error. Verifying an event before the source chain has settled it means a reorganization can erase the debit while the credit stands, which is why block confirmations are a per-pathway security setting rather than a default to inherit.
The second condition separates two things that are easy to conflate. DVNs attest to the message, a commit stage aggregates the required attestations onto the destination chain, and an Executor then calls the receiving contract. A message that DVNs have verified is not yet settled, because the commit and execution stages still have to complete.
Settlement models compared
What the recipient ends up holding differs sharply by model, which makes this a settlement question rather than a routing question. The last column is an assessment of fit, not a regulatory classification.
| Model | What the recipient holds | What settlement depends on | Fit for regulated assets |
|---|---|---|---|
| Custodial transfer | A claim on the custodian | The custodian remaining solvent and available | Weak: the holder takes custodian credit risk |
| Liquidity pool | An equivalent token from a pool | Pool inventory on the destination side | Limited: can fail on depth, not on truth |
| Lock-and-mint (wrapped) | A third-party wrapped copy | The wrapper contract and its operator | Weak: the holder does not hold the issuer's asset |
| Burn-and-mint (canonical) | The issuer's own token | Verification of the source burn | Strong: the destination token is the issuer's asset |
| Atomic delivery-vs-payment | Both legs, or neither | Each leg being conditioned on the other | Strong where both legs are onchain |
The distinction that matters for an issuer is whether settlement can fail for reasons unrelated to the truth of the transfer. A pool-backed model can stall because the destination lacks inventory even though the source debit is valid, while a canonical model settles on verification alone.
Canonical settlement also fixes the accounting. Under the OFT standard, a send debits the source chain by burning or locking, and the paired contract credits the destination by minting or unlocking the same amount, so total supply is unchanged by the transfer. Where an existing token is escrowed rather than burned, one escrow should back the whole mesh, which keeps redemptions from competing across several independent pools of collateral.
What happens when settlement stalls
A stalled transfer sits at an identifiable stage, and the stage determines the remedy. Message status distinguishes a transfer waiting on source confirmations or verification from one that reached the destination and reverted, and from one blocked by pathway configuration such as a mismatched verifier set or an unset peer.
Where normal delivery cannot continue, settlement state is adjustable at the Endpoint. A receiver can skip a nonce that has not been delivered, clear one already verified, nilify a nonce by payload hash so it can be re-executed later, or burn a nonce so it cannot. These change messaging channel state rather than retrying a failed execution, and they matter most where ordered delivery is enforced and one stuck nonce would block the messages behind it.
FAQ
Is a cross-chain transfer atomic?
Not in the single-ledger sense. Canonical designs make the credit contingent on a verified source debit, so the legs cannot diverge, but they do not execute simultaneously.
What is the difference between message finality and asset finality?
Message finality means the instruction has been verified and delivered. Asset finality means the destination credit has itself reached finality, so a delivered message whose destination transaction is still confirming is not yet settled.
How long does cross-chain settlement take?
Most of the elapsed time is the source finality wait. The verification, commit, and execution stages are quick by comparison, so settlement time tracks the corridor's finality requirement more than the protocol.
Can a settled cross-chain transfer be reversed?
Not at the protocol layer. Once the destination credit is final, moving the asset back requires a new transfer. Issuers of regulated assets do retain token-level powers that act after settlement, including blocklisting an address and admin-level fund recovery, which are properties of the token rather than of the transfer.
Can settlement fail after the source chain has debited?
Execution on the destination can revert, which leaves the transfer recoverable rather than lost. The message can be retried once the cause is fixed, or the nonce resolved through Endpoint-level recovery.
Does settlement work between chains with different access models?
Yes. The requirement is an endpoint on both chains and a DVN set that can observe both, which holds whether a chain is open or access-controlled. LayerZero has announced an integration with the Canton Network, a chain purpose-built for institutional finance with configurable privacy.
Scope settlement for your asset
Settlement behaviour is largely configuration: how much source finality each pathway waits for, which verifiers must attest, and which accounting model the asset uses. Those choices set both the speed and the failure modes.
To work through settlement for a specific asset and corridor, reach out to our team, or start at Developers.