Every tokenization project makes three architectural bets before a line of code ships: where settlement happens, who holds keys, and what "final" means. We built a payment rail for tokenized assets that is now live in production. This paper maps the trade-off space as we found it — from the build side, not the whitepaper side.
The settlement layer decision
The first fork is public versus permissioned settlement. Neither is universally correct. The honest framing is: what does your regulator need to see, and what does your counterparty need to trust?
Public chains (Ethereum mainnet, L2s) give you composability, deep liquidity, and neutral infrastructure nobody can switch off. The costs: probabilistic exposure to MEV, gas volatility on your settlement cost basis, and a compliance perimeter you do not control. Every address on a public chain is a potential counterparty. Your sanctions-screening surface is the entire chain.
Permissioned DLT inverts this. You trade composability for a closed trust boundary: every participant is identified, onboarded, and legally accountable before their first transaction. For regulated financial institutions this is not a limitation — it is the product. Our Bridge Intelligence rail connects banks, fintechs, and licensed VASPs inside exactly this kind of boundary, with attribution and sanctions hooks on every transfer. Compliance is enforced by construction, not by after-the-fact monitoring.
A hybrid pattern is emerging: permissioned settlement with public-chain anchoring or bridging for liquidity access. It works, but it doubles your attack surface and your audit scope. Do not adopt it because it sounds sophisticated. Adopt it only if your liquidity genuinely lives on the public side.
Custody models
Three viable models, in ascending order of institutional comfort:
- Self-custody with MPC or multisig. Lowest counterparty risk, highest operational burden. Key ceremony discipline, quorum management, and disaster recovery become your problem. Suitable when the asset holder is technically sophisticated.
- Qualified custodian. A regulated third party holds keys under a custody license. This is what most institutional mandates require, and under MiCA it is effectively the default assumption for service providers holding client assets.
- Rail-native custody with segregation. The rail operator holds omnibus or segregated accounts with on-ledger attribution per beneficial owner. Fast settlement, clean audit trail — but the operator becomes a systemic dependency, and regulators will treat it as one.
The trap we see repeatedly: teams choose the custody model that is easiest to build, then discover their target clients' compliance departments cannot sign off on it. Custody is a go-to-market decision disguised as an engineering decision. Decide it in discovery, not in sprint nine.
Finality is a legal question wearing a technical costume
Public proof-of-stake chains give you economic finality in minutes; permissioned BFT consensus gives you deterministic finality in seconds. But the number that matters is when a transfer becomes legally irrevocable in your jurisdiction. Settlement finality regimes were written for central counterparties, not validators. If your rail's technical finality and your contract's legal finality diverge, the gap is your liability.
Write the finality definition into the participant agreement, and make the ledger enforce the same definition. This is one of the strongest arguments for deterministic-finality permissioned consensus in regulated markets: the technical event and the legal event can be made identical.
MiCA and GENIUS: two regimes, one design constraint
The EU's MiCA framework regulates the token and the service provider: asset-referenced tokens and e-money tokens carry issuer obligations and reserve requirements, and anyone touching custody or exchange needs CASP authorization. The US GENIUS Act takes a narrower cut, focused on payment stablecoin issuance with federal and state licensing paths.
For a rail builder, the operative difference: MiCA regulates your participants' entire activity; GENIUS regulates a specific instrument. If you serve both markets — as our US and European clients typically must — design for the stricter perimeter. In practice that means identified participants, per-transfer attribution, reserve transparency hooks, and data handling that survives GDPR scrutiny. Retrofitting compliance onto a permissionless design is a rewrite. Building it in from day one is a schema decision.
Recommendations for regulated markets
- Default to permissioned settlement unless public-chain liquidity is the core of your business case. Most institutional tokenization does not need it yet.
- Make compliance a protocol property. Attribution and sanctions screening on every transfer, not a batch job that runs overnight. Every alert should carry a decision trace an auditor can replay.
- Pin legal finality to technical finality in the participant agreement, and choose consensus that makes them identical.
- Choose custody with your clients' compliance departments, not with your engineers.
- Design the regulator in as a participant. Read access, structured reporting, auditable state transitions. Retrofit is twice the cost.
- Instrument for the audit before the audit. If you cannot reconstruct any transfer's full compliance context on demand, you built a demo, not a rail.
What we would not buy
Two things we routinely advise clients against. First, a public-chain rail for a closed institutional network — you pay the full compliance cost of an open perimeter for composability you will never use. Second, tokenization of assets whose registries already work: if the existing settlement path is cheap, fast, and legally settled, a token adds a layer, not value. The strong cases are cross-border corridors, assets with fragmented registries, and markets where the compliance workflow itself is the bottleneck — which is where our production work sits.
These positions come from shipped systems, not slideware. The architecture is described on our tokenization rails service page, and the production rail behind this paper is documented in the Bridge Intelligence case study.
Building a rail for tokenized assets, or deciding whether you should? Talk to us — we reply within one business day.