Architecture categories

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; the documentation explains finality in terms of supermajority links between checkpoints and exposes “safe/finalized” tags in JSON-RPC.
• 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).

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.

Concrete 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.

Measured metrics:

• Hyperledger Fabric 2.5 benchmark (Caliper-based, specific topology and workload): throughput on the order of ~1.5k–2.95k TPS with average latencies reported between ~0.06s and ~1.52s depending on payload and read/write profile (benchmark context matters; these are not universal guarantees).
• Corda (R3 internal testing, older but explicit): 1678 TPS for a single-node issuance scenario and 600 TPS for a two-party payment-like scenario, with the author emphasizing comparability challenges and transaction definition nuance.

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.

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.

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).

Technical requirements and “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.

Comparative table: settlement layer options