DLT Network Architecture: Permissioned vs Public
The design of the distributed ledger protocol layer — validator governance, consensus mechanism, access controls, and finality model — that determines settlement certainty, privacy, and liquidity access for any DLT rail a regulated firm operates on.
Definition
The critical architecture decision for a regulated institution deploying DLT is not blockchain versus no blockchain. It is which trust model governs settlement finality, access control, and legal accountability. Every design choice that follows — consensus mechanism, validator governance, privacy architecture, upgrade governance — is a consequence of that primary decision. Network selection that is made by default, or delegated entirely to a technology vendor, is a risk management failure. The architecture determines who can validate transactions, who can observe them, how long finality takes, what happens during a network partition, and who is legally accountable when something goes wrong.
DLT network architecture — permissioned vs public vs hybrid
| Attribute | Permissioned | Public | Hybrid / Consortium |
|---|---|---|---|
| Validator governance | Known · whitelisted | Open · protocol-incentivized | Controlled set · public layer |
| Finality model | BFT · deterministic | PoS economic / PoW probabilistic | Deterministic local · public anchor |
| Privacy | Native · configurable | Transparent by default | Configurable · ZK / off-chain |
| Liquidity access | Consortium only | Global · open market | Bridge to public rails |
| Regulatory comfort | Highest (controlled) | Evolving (ESMA Pilot, GENIUS Act) | High (governed + interoperable) |
| Examples | Canton · Corda · Besu | Ethereum · Solana | AggLayer · Avalanche Subnets |
Three architectural families exist in institutional DLT deployment as of 2026. Permissioned networks restrict access and governance to authorized participants, achieving deterministic finality through BFT consensus but accepting a liquidity constraint. Public networks provide open access and global liquidity at the cost of transparent order flow, probabilistic or time-locked finality, and MEV exposure. Hybrid and consortium networks — the dominant institutional direction as of 2026 — combine a controlled validator layer for operational governance with a connection to public consensus for liquidity access and interoperability, implementing what the industry now calls Network Sovereignty: control over your local environment without isolation from the global settlement ecosystem.
Permissioned DLT — Controlled Access and Deterministic Finality
Permissioned DLT networks restrict both validator participation and transaction access. Only authorized nodes can participate in consensus; only approved counterparties can submit or observe transactions. The validator set is known, contractually accountable, and governance is defined by consortium or operator rules rather than an open protocol. BFT consensus — the standard for permissioned networks including Canton Network, R3 Corda, and private Hyperledger Besu deployments — achieves deterministic finality: once a supermajority of validators signs a block, the transaction is irrevocable. There is no probabilistic reversal window. For regulated institutions, the deterministic finality guarantee directly satisfies PFMI Principle 8 requirements: the settlement infrastructure provides clear and certain final settlement, backed by contractual accountability of the known validator set.
The operational tradeoff is liquidity confinement. A permissioned network is a closed system — assets and liquidity exist only within the consortium perimeter. Repo, collateral, and settlement flows available within the consortium cannot freely access external liquidity without a bridge to a separate network. This is the liquidity silo problem: the operational certainty of a permissioned environment is bounded by how many institutions are connected to it.
Public DLT — Open Consensus and Global Liquidity
Public blockchain networks have no access restrictions on validator participation or transaction submission. The validator set is anonymous or pseudonymous, economically incentivized through protocol token rewards and transaction fees rather than contractually accountable. Ethereum's proof-of-stake network achieves near-deterministic economic finality through Casper FFG after approximately 12-15 minutes — reversal would require destroying at least one-third of all staked ETH, a threshold established in BFT theory as the maximum Byzantine fault tolerance, making reversal economically irrational at scale. Layer 2 networks — Optimistic rollups with 7-day challenge periods, ZK-rollups with near-immediate Layer 1 finality — add additional finality models that operations teams must explicitly model. For a detailed treatment of each finality mechanism, see Settlement Finality (DLT/Blockchain).
The operational advantage of public networks is liquidity concentration: USDC, EURC, and other MiCA-compliant stablecoins are predominantly liquid on public rails. A settlement workflow that needs a cash leg available at 2:00 am on a Saturday can use public network stablecoin liquidity in ways that a permissioned chain without a stablecoin bridge cannot replicate. The tradeoff is order flow exposure through the public mempool, MEV risk from validator transaction reordering, and governance volatility — protocol upgrades on public networks require community consensus processes that institutional operators cannot unilaterally control.
Hybrid Networks and Network Sovereignty
The dominant institutional DLT architecture of 2026 is neither fully permissioned nor fully public. It is a hybrid: a permissioned or consortium layer for operational control, privacy, and deterministic finality, connected to a public consensus layer for liquidity access and settlement anchoring. Polygon AggLayer and Avalanche Subnets are structural implementations of this model — institutions deploy application-specific chains (AppChains) with their own validator set, access rules, and transaction privacy, while using the public network's consensus as the ultimate settlement anchor. The industry term for this pattern is Network Sovereignty: institutional governance over the local node environment and validator set, without isolation from the global liquidity and composability of public networks.
The 2026 convergence trend runs in both directions. Public networks are becoming more institutionalized — Ethereum's Proposer-Builder Separation (PBS), private mempools, and institutional validator operators reduce MEV exposure and governance unpredictability. Permissioned networks are becoming more interoperable — Canton Network's participation in BIS interoperability pilots, and Corda's evolving bridge architecture, enable asset and data flow across consortium boundaries. The binary "permissioned or public" framing is increasingly obsolete. The operational question is: which trust layer handles which function?
The Finality-to-Capital Link
Settlement finality architecture is not only an operational question — it is a capital question. The Basel Committee on Banking Supervision's standard on cryptoasset prudential treatment (BCBS, December 2022, effective January 2025) distinguishes tokenized traditional assets on DLT rails that meet strict settlement finality requirements from those that do not. Positions settled on deterministic BFT permissioned networks are more likely to receive standard capital treatment comparable to their underlying instruments. Positions on public probabilistic chains may attract additional operational risk capital buffers where supervisors determine that finality uncertainty constitutes a quantifiable settlement risk exposure. This is the finality-to-capital link: the network architecture decision affects not only how settlement works but how much regulatory capital the firm must hold against its digital asset positions. Bank treasuries and risk functions should be in the room for DLT architecture decisions, not just technology teams.
Questions an Architecture Committee Must Answer
Before selecting a network architecture for any institutional DLT deployment, eight questions must have documented answers:
- Who can run validator nodes — and what is their contractual accountability if consensus fails?
- Who can reverse a confirmed transaction, under what conditions, and through what process?
- What constitutes finality for this network, and does it satisfy the firm's settlement policy?
- What happens during a protocol upgrade — who controls the upgrade decision and how long can the network be unavailable?
- Can regulators observe settlement activity when required for examination or enforcement?
- Can counterparties be screened at the infrastructure level before transaction submission?
- How does the network connect to legacy rails — SWIFT, ISO 20022, CSD, CCP — and what is the latency and failure mode of those connectors?
- Who bears legal liability for a network outage that causes settlement failure?
An institution that cannot answer all eight questions has not completed its architecture evaluation. Regulatory scrutiny of DLT settlement infrastructure will use these questions as the basis for operational risk assessment.
DLT architecture — privacy vs. open liquidity
Devancore Glossary · devancore.com
How it works
Each architectural family has distinct operational mechanics. Understanding how finality, privacy, and liquidity work in each model is the prerequisite for the use-case decision matrix that follows.
Permissioned DLT — Operational Mechanics
Permissioned networks use BFT consensus among a known validator set to achieve deterministic finality. In Canton Network, smart contracts written in the Daml language execute on the Canton runtime, with transactions visible only to the parties directly involved — not to the full network. Transaction finality is achieved when the designated set of validators signs the transaction, which occurs within the block time of the network. In R3 Corda, transactions are not broadcast to the full network: they are shared only between the transacting parties and a designated notary node that checks for double-spend and confirms finality. There is no global ledger in the traditional sense — Corda's shared ledger is a constellation of bilateral shared facts, each visible only to the parties with a legitimate stake. Hyperledger Besu deployed in a private configuration uses the Clique or IBFT 2.0 consensus protocol for permissioned BFT finality, and can be run on infrastructure controlled entirely by a single financial institution or consortium. In all permissioned configurations, the validator governance structure is a legal agreement, not a protocol mechanism — contractual accountability supplements technical controls.
Public DLT — Operational Mechanics
On Ethereum, settlement instructions are broadcast to the public mempool as pending transactions. Block validators (proposers) select which pending transactions to include in each block, ordered by priority fee. Once included in a block, a transaction receives one confirmation; economic finality through Casper FFG occurs after approximately 12-15 minutes. Layer 2 networks add a second finality model: transactions achieve immediate Layer 2 finality but depend on the Layer 1 for ultimate settlement anchoring — ZK-rollups provide near-immediate Layer 1 finality by posting cryptographic validity proofs with each batch; Optimistic rollups post transaction data with a 7-day challenge period before Layer 1 finality is achieved. For post-trade operations teams, each Layer 2 carries its own finality model that must be explicitly configured as a firm settlement policy before positions can be marked as settled and reported under Rule 17a-3.
MEV is the public network operational risk with no equivalent in permissioned DLT. Block validators on public networks can extract value by reordering pending transactions in ways that front-run large settlement instructions, sandwich institutional order flow, or censor specific addresses. The effective institutional controls are: (1) private mempools — submitting transactions directly to specific block builders rather than the public mempool, removing front-running visibility; (2) PBS (Proposer-Builder Separation) — the Ethereum architecture that separates transaction selection from block proposal, reducing the surface area for validator-level extraction; and (3) limit orders and commit-reveal schemes for price-sensitive settlement instructions. Institutions running tokenized settlement on public networks should have a documented MEV risk framework as part of their operational risk management procedures.
Hybrid Networks — Network Sovereignty in Practice
Avalanche Subnets allow an institution to deploy a custom subnet blockchain with its own validator set, transaction rules, and privacy configuration, while remaining connected to the Avalanche primary network for cross-chain asset transfers and liquidity access. Polygon AggLayer provides a similar model for Polygon CDK chains: permissioned AppChains settle to Ethereum via a shared aggregation layer that maintains cryptographic proof of cross-chain state. The operational implication is that a consortium running repo operations on a permissioned AppChain can maintain counterparty-controlled settlement finality for interbank transactions while accessing USDC liquidity on the public Ethereum base layer for the cash leg — without routing cash through the consortium chain. This is the architectural answer to the liquidity silo: use the permissioned layer for what it is good at (deterministic finality, access control, privacy) and bridge to the public layer for what it is good at (open liquidity, composability, 24/7 cash rails).
Privacy Architecture
Privacy on DLT infrastructure is not binary. Four technical approaches exist along a spectrum. First, permissioned access by design: on Canton and Corda, transaction data is shared only with parties who have a stake in the transaction — privacy is structural, not add-on. Second, private subnets: on public networks, a private subnet or Layer 2 with restricted access can provide transaction privacy while settling to the public Layer 1 for finality anchoring. Third, zero-knowledge proofs: ZK proofs allow a party to prove that a transaction satisfies certain conditions — valid settlement, authorized counterparty, correct amount — without revealing the underlying data. ZK-based privacy is increasingly relevant for institutional DLT: a bank can prove to a regulator that a settlement was valid without exposing trade details to other network participants. Fourth, off-chain confidential data layers: transaction metadata — trade details, counterparty identities, position information — is stored off-chain in encrypted form, with only a hash committed on-chain. The on-chain record is verifiable; the data content is not publicly visible. For Rule 17a-3 books and records compliance, any off-chain data layer must be accessible to regulators on examination and must satisfy the same retention requirements as on-chain records.
The Interoperability Problem
No single network serves all institutional needs. Most institutions will operate across multiple DLT networks simultaneously — a permissioned network for bilateral collateral, a public network for stablecoin settlement, a consortium network for tokenized bond issuance — alongside traditional SWIFT, ISO 20022, and CSD infrastructure. This creates an interoperability requirement that is not solved by network selection alone. SWIFT's blockchain interoperability experiments and ISO 20022 adapters for on-chain settlement provide one integration path; Oracle's Financial Services middleware and custom API gateways provide another. Cross-chain bridges — smart contract protocols that lock assets on one chain and mint equivalent representations on another — introduce their own operational risk: bridge exploits have been the largest single category of DLT security failure by value. Institutional bridge designs favor custodian-controlled lock-and-mint mechanisms with maker-checker authorization rather than automated bridge contracts with unrestricted execution. The interoperability problem is not resolved in the network architecture selection — it must be addressed as a distinct integration design exercise.
Use Case Decision Matrix
Most use cases have an architecture preference, not a mandate. The preference derives from the dominant operational requirement:
— Bilateral repo and collateral management: counterparty privacy, deterministic finality, and controlled access favor permissioned or consortium networks. HQLAx on R3 Corda is the live production example. See Tokenized Collateral Repo Settlement.
— Stablecoin settlement and 24/7 cash legs: global liquidity access and continuous availability favor public or hybrid networks where USDC and EURC concentration is highest. See Stablecoin Settlement.
— Tokenized bond issuance and secondary market trading: regulatory perimeter dominates; EU instruments require ESMA DLT Pilot Regime framework — see ESMA DLT Pilot Regime — with network choice constrained by the authorized DLT market infrastructure's architecture.
— Internal netting and intragroup settlement: permissioned or proprietary DLT, where the consortium overhead is not justified and a single-operator network suffices.
— Cross-border interbank settlement: hybrid architectures connecting permissioned banking layers to public liquidity rails, with atomic DvP where the cash leg is a public-network stablecoin. The wholesale CBDC model — where the cash leg is a central bank liability rather than an EMT — addresses the same use case with higher finality certainty at the cost of operating window constraints.
DLT network selection — use case decision
Devancore Glossary · devancore.com
In Devancore™
Devancore — network-agnostic settlement adapter
Devancore Glossary · devancore.com
Devancore's settlement architecture is network-agnostic by design. The core principle is that the settlement rail — permissioned BFT, public proof-of-stake, or hybrid — is a configuration parameter, not a structural assumption. Operations teams using Devancore see one settlement workflow, one position view, and one audit trail regardless of which network carries the underlying transaction.
Multi-Protocol Settlement Connectivity
Devancore connects to both permissioned and public DLT rails through a protocol adapter layer that translates each network's native interface — whether Canton Network's Daml-based transaction model, Hyperledger Besu's EVM JSON-RPC interface, or Ethereum's standard RPC — into a normalized settlement instruction format. When a trade is enriched and a settlement instruction is generated, the rail designation — PERMISSIONED, PUBLIC, or HYBRID — determines which adapter handles the on-chain submission. The operations team configures the network and contract address per instrument type; the adapter handles the protocol translation. No manual intervention is required for rail switching, and no parallel workflow exists for DLT settlements versus traditional DTCC/DTC settlements — they flow through the same enrichment and instruction generation process.
Finality Normalization — ABOR Update on Firm Threshold
Each settlement rail is configured with a finality policy: the confirmation depth or checkpoint state at which Devancore considers a transaction final for position update purposes. For permissioned BFT networks with deterministic finality, the policy is immediate — one validator threshold confirmation triggers the ABOR update. For public proof-of-stake networks, the policy is configured per chain: a specific number of block confirmations, or Casper FFG checkpoint finality, triggers the update. For Layer 2 networks, the policy distinguishes between Layer 2 confirmation (fast, lower certainty) and Layer 1 anchoring (slower, higher certainty). The ABOR position is updated only when the configured finality threshold is reached — not on broadcast, not on pending state, not on Layer 2 confirmation if the firm's policy requires Layer 1 anchoring. This prevents premature position updates from inflating the IBOR/ABOR reconciliation before settlement is actually complete. The on-chain transaction hash, block number, confirmation count, and finality timestamp are captured in the Rule 17a-3 audit record for every on-chain settlement, regardless of network.
Privacy-Preserving Middle Office on Public Rails
When settlement executes on a public network, trade detail — counterparty identity, position size, instrument — is operationally sensitive information that the firm's Rule 17a-3 blotter must capture without exposing to the public mempool. Devancore separates the on-chain settlement event (the token transfer, which is publicly visible) from the off-chain trade record (which is not). The on-chain transaction hash is linked to the internal trade record, counterparty, and account in Devancore's books and records layer, but the trade record itself is maintained off-chain in encrypted form. Regulators can access the full trade record under examination through the internal system; external observers see only the on-chain token transfer. This separation satisfies Rule 17a-3's contemporaneous recordkeeping requirement while preserving the operational privacy of the firm's settlement book. For permissioned network settlements, where the ledger is not publicly visible by design, the same link structure applies — the on-chain transaction hash is captured and linked, with the additional assurance that the settlement itself is private to consortium participants.