How Tokenised Settlement Works Across Permissioned and Public Chains

Every settlement is two legs. The asset moves one way, the cash moves the other, and the entire discipline of post-trade exists to stop one leg completing without the other. Tokenisation does not remove that problem — it relocates it, usually to the seam between two different chains. Where you put that seam is the whole design.

What settlement actually requires

Strip away the technology and settlement demands three things.

Simultaneity. The delivery of the asset is conditional on the payment, and vice versa. Central bank literature describes this as delivery-versus-payment, and distinguishes models by whether the legs settle gross trade-by-trade, or whether one side nets. What matters for a system design is that both legs succeed together or neither does.

Finality. A moment after which the transfer cannot be reversed — not by the counterparty, not by the network, not by an administrator, and crucially not by an insolvency practitioner reaching backwards. Technical irreversibility and legal finality are different things and you need both.

Identifiable counterparties. Regulated firms must know who they settled with. A system that delivers atomicity but anonymity has solved the wrong half.

Atomicity is easy on one ledger and hard across two. Almost every real tokenisation architecture is across two.

Why the legs end up on different chains

It is tempting to ask why anyone accepts this. The answer is that each leg is optimised against a different constraint.

The asset leg lives where its compliance lives. A regulated instrument needs enforced eligibility, transfer restrictions, an identifiable holder register and, frequently, confidentiality about who holds what. That pushes it toward a permissioned environment, or toward a permissioned token on a public chain.

The cash leg lives where the money is. Tokenised commercial bank deposits sit on their issuing bank's infrastructure. Wholesale central bank money, where it exists, sits on the central bank's. Stablecoins sit on public chains. None of these will migrate to your asset ledger because you would like them to.

So the design question is never "which chain?" It is "where is the seam, and who carries the risk while a transaction straddles it?"

Four ways to settle across the seam

Single-ledger atomic settlement

Both legs on one chain, one transaction, done. This is the cleanest design and you should take it whenever it is available — typically when the cash leg is a stablecoin or tokenised deposit issued on the same chain as the asset. The constraint is rarely technical. It is that the cash issuer must be willing and permitted to operate there, and that your asset's confidentiality requirements survive a shared ledger.

Hash-locked cross-chain swaps

Both legs are locked against the same cryptographic secret, with expiry timeouts. Revealing the secret to claim one leg necessarily reveals it for the other, so either both complete or both unwind. It is genuinely atomic and needs no trusted intermediary.

It also has a known flaw institutions dislike: the party who moves second holds a free option. They can watch the market until the timeout approaches and simply not proceed, having tied up the first mover's assets for the duration at no cost. For volatile pairs and long timeouts, that option has real value — and it is paid for by your counterparty.

Synchronised commit across ledgers

A coordination layer lets a single transaction span multiple ledgers, committing on all of them or none, without merging them into one shared database and without either side seeing the other's book. The Canton Network is the production example of this model: applications keep their own ledgers and privacy boundaries, while a synchroniser sequences atomic cross-application transactions.

The appeal for regulated settlement is specific. You get atomicity without a bilateral timeout game, and you get sub-transaction privacy — participants see only the parts of a transaction they are party to. The dependency you take on is the availability and governance of the synchronisation layer, which is a real question to diligence rather than a reason to dismiss the model. SUPERBLOCK runs a Canton validator node, which is why this pattern appears in our own settlement designs.

Non-atomic settlement with an agent

An agent holds one or both legs and releases against confirmation. This is not atomic and nobody should pretend it is. It is also how an enormous amount of real business gets done, because the exposure window is short, the agent is regulated and capitalised, and the contract allocates the risk explicitly.

The failure mode to avoid is an architecture that is non-atomic by accident — a diagram that implies simultaneity while the implementation hands an operator a queue of two independent transfers to fire in sequence.

Finality is two questions, not one

Technically: when can this no longer be reversed by the network? A proof-of-stake public chain reaches finality after a couple of epochs — on the order of minutes — and before that, reversal is improbable but possible. A permissioned ledger with a known validator set typically finalises deterministically at the moment of commit.

Legally: at what moment does title transfer, and is that moment protected against an insolvency unwinding it? This is governed by your documentation, your governing law and — in some venues — settlement finality regimes designed for exactly this question. A chain that finalises in twelve seconds does not help if your legal transfer moment is defined as the transfer agent's book entry the next morning.

Teams routinely design against the first and forget the second. Ask counsel where title passes, then make the technical design agree with the answer.

What actually breaks in production

• Bridges. If your design moves value across a bridge rather than settling across a seam, you have added the single most exploited component in the industry to your critical path.
• Timeouts and time zones. Hash-lock expiries denominated in blocks interact badly with weekends, holidays and a counterparty's cut-off.
• Oracle dependencies. Conditioning settlement on an external price or confirmation imports that source's availability into your settlement guarantee.
• Gas on the critical path. A settlement that fails because a relayer ran out of native token is an operational incident with a very embarrassing root cause.
• Reconciliation. Two ledgers means two books. Somebody reconciles them daily, forever, and that person needs a tool rather than a spreadsheet.

Designing a settlement architecture? SUPERBLOCK builds across permissioned and public environments — a Canton validator node, ERC-3643 issuance in SBX Prime, and AURA for the payment leg — so these trade-offs are the ones we make in our own stack. To work through where your seam should sit, see the Settlement Engine — how we join the two legs in practice — or request a demo.