Choosing network architecture for tokenization

On-chain on public networks

Public on-chain settlement uses a permissionless blockchain where transaction ordering/finality is achieved by the network’s consensus protocol, and tokens are controlled by cryptographic keys. This yields 24/7 availability and strong composability, but raises privacy, governance, and compliance constraints for regulated activity.

Measured / reference metrics

Ethereum:

• Block time is organized into ~12-second slots and uses a “finalized” concept via checkpoints under proof-of-stake;
• Finality timing: multiple sources explain finalization typically occurs over ~two epochs (with epochs defined as 32 slots), i.e., on the order of minutes rather than seconds; third-party protocol analysis and infrastructure providers commonly reference ~12.8 minutes for two-epoch finality, with average “wait-to-finalized” closer to ~2.5 epochs for a typical transaction placement within an epoch.

Solana:

• The developer docs describe slots configured at ~400ms (with variation) and define commitment levels, including “finalized” as the highest commitment associated with maximum lockout.
• Throughput snapshot: the public explorer displays live TPS; at time of retrieval it showed ~2,996 TPS (this value is inherently time-variable and should be treated as an observation, not a guaranteed SLA).

What you get

• 24/7 trading
• global access
• easy integration with DeFi and apps

Trade-offs

• low privacy (everything is visible)
• hard to enforce regulation (KYC, restrictions)
• governance is decentralized (no single control point)

Good for: open markets, experiments, Hard for: regulated assets

Permissioned ledgers / enterprise DLT

Permissioned DLT systems restrict validator/participant sets and can support higher privacy and tailored governance, often at the cost of open composability and retail reach. They commonly rely on membership rulebooks, identity systems, and operator controls that more closely resemble traditional FMIs.

Examples:

• Hyperledger Fabric: modular architecture with ordering service and transaction validation/commit to peers.
• Corda: transaction finality relies on a notary service for uniqueness and a finality flow for distribution/recording among relevant participants.

What you get

• controlled access (only approved participants)
• better privacy
• clear governance

Trade-offs

• less interoperability
• harder to connect to public liquidity

Good for: banks, internal systems, regulated workflows

Off-chain settlement rails and traditional FMI-connected settlement

Many tokenization designs keep “final settlement” on existing rails even when token transfer is recorded elsewhere.

Key rails:

• RTGS: an effecting final settlement of interbank funds transfers continuously and transaction-by-transaction during the processing day.
• ACH: NACHA documents show a windowed processing/settlement model; Same Day ACH includes multiple submission deadlines with corresponding settlement times.
• SWIFT: SWIFT is primarily messaging/communications; Focuses on payment message processing speed rather than being a settlement ledger itself.

This category is often used in “token transfer on ledger, cash settlement off-ledger” designs, or in systems where tokenization is limited to recordkeeping/transfer instruction while legal settlement remains on a CSD/RTGS combination.

What you get

• strong legal certainty
• trusted systems

Trade-offs

• slow
• not programmable
• limited innovation

Common pattern: Token moves on-chain → money settles off-chain

CBDC pilots and multi-CBDC platforms

CBDC-based settlement layers attempt to bring central bank money onto (or tightly integrated with) programmable platforms.

A well-documented example with metrics is Project mBridge (multi-CBDC platform): during a 2022 pilot involving real-value transactions among 20 commercial banks across four jurisdictions, over $12 million was issued on-platform and the pilot facilitated 160+ payment and FX PvP transactions totaling over $22 million.

mBridge reached an MVP stage and emphasized governance/legal framework creation (rulebook) for a decentralized platform and EVM compatibility as a testbed feature.

What you get

• settlement in central bank money
• potential atomic settlement (DvP / PvP)

Trade-offs

• still early stage
• limited access

Hybrid designs

Hybrid designs deliberately split responsibilities across multiple systems to reconcile programmability with legal and operational realities. Standard-setters observe that many arrangements still rely on traditional infrastructure for parts of the lifecycle, and legal certainty around which record is authoritative remains central.

Common hybrid patterns include:

• DLT issuance + conventional CSD holding/settlement link (interoperability bridge between tokenized and conventional infrastructure).
• On-chain transfer layer + off-chain authoritative register (typical for some tokenized funds).
• Permissioned DLT “parallel book” with authoritative record remaining in legacy system (risk-managed migration).

Takeaway: This is what most real-world systems use today

Metrics that matter

Below is a technically oriented checklist, reflecting both DLT constraints and FMI-grade expectations:

• Finality: protocol finality (economic/probabilistic vs deterministic) plus legal finality under system rules and insolvency law.
• Throughput: sustained TPS under realistic payloads, including worst-case bursts and block-building constraints; “headline TPS” is not sufficient.
• Latency: time from submission to irreversible settlement state; for public chains, distinguish pre-confirmation vs finalized; for permissioned, measure end-to-end commit.
• Privacy & confidentiality: identity/position confidentiality, selective disclosure, and data residency constraints; often pushes institutions toward permissioned or hybrid designs.
• Cryptographic guarantees: integrity (hash-linked ledgers), signature schemes, key custody requirements; also proof systems for attestations and audit.
• Atomicity (DvP/PvP): ability to settle asset + cash legs as one unit; reduces settlement risk but may require prefunding and changes to liquidity management.
• Interoperability: cross-chain and cross-FMI connectivity; standard-setters flag fragmentation and non-interoperable chains as a scalability constraint.
• Resilience: operational resilience, cyber defense, incident response; public chain dependencies and bridge/oracle risks enlarge attack surface.