Choosing institutional blockchain infrastructure is not simply a choice between decentralization and control. Architecture determines who can participate, who can validate transactions, what information is visible, who can change system rules, how settlement is established, and how the network connects to existing financial infrastructure.
Those requirements should be defined before a ledger model is selected.
The terminology also needs care. Public/private and permissionless/permissioned are related but not identical labels, and industry usage is not perfectly standardized. Public/private commonly describes aspects of network accessibility, governance, or data visibility, while permissionless/permissioned describes whether participation in activities such as validation, node operation, asset holding, or transfer requires authorization.
BIS research often groups today’s DLT networks into the broad categories of public permissionless and private permissioned designs, but those categories are not exhaustive. MAS has discussed public permissioned foundational infrastructure, while the Bank of England’s 2026 DLT Innovation Challenge examined public permissionless networks with controlled components, permissioned networks, and middleware or chain-agnostic approaches.
The practical question is therefore: Which combination of openness, control, privacy, governance, settlement assurance, interoperability, and operational responsibility does the use case require?
Start With Institutional Requirements, Not the Network
Before comparing blockchain models, define who may hold or transfer the asset, whether validators must be identified, what data may be visible, who controls issuance and upgrades, what settles the cash leg, when settlement is legally final, and which external systems must connect.
The Bank of England DLT Innovation Challenge organized its work around settlement finality and security, scalability, network and asset control, and interoperability. It also concluded that there is no single model for controlling DLT networks and assets.
Architecture selection is therefore an operating-model decision as much as a technology choice.
Governance and Validator Access Determine Where Control Resides
On public permissionless networks, participation generally follows protocol-defined conditions rather than approval by one sponsoring institution. Validation can still require economic or technical prerequisites, such as stake or hardware, but access is not normally based on membership in a closed consortium.
That structure can reduce dependence on a single operator while leaving issuers with limited control over base-layer upgrades, validator behavior, congestion, or broader governance.
Permissioned networks restrict validator or participant access to approved entities. Governance bodies can define change procedures and operator responsibilities, improving accountability while potentially concentrating authority.
The Bank of England found that permissioned models tend to embed control across more layers of the DLT stack, while public-network approaches often rely on application-layer controls such as allowlists, token standards, smart contracts, and off-chain governance. Neither model removes governance risk; it changes where governance authority sits and how it can be exercised.
Kenson’s separate guide to permissioned blockchain infrastructure covers that narrower architecture in greater depth.
Privacy Is About Information Boundaries
Public-ledger activity can be broadly observable, which may conflict with commercial confidentiality or regulated-data requirements. Encryption, selective disclosure, application controls, zero-knowledge techniques, and off-chain storage can restrict what is revealed.
A permissioned ledger is not automatically private either. Participants may still see information another institution considers sensitive unless the architecture deliberately separates data access, execution rights, and audit permissions.
The architecture should therefore answer: Who can see the transaction, who can verify it, who can access the underlying business information, and what must remain confidential?
The Project Agorá 2026 findings show one current institutional approach: privacy safeguards limit data sharing to relevant parties while preserving participation rules and regulatory requirements.
Settlement Requires Technical and Legal Finality
A ledger can technically finalize a state transition without resolving every legal question about settlement.
Technical finality concerns when a network treats a transaction or state transition as final according to its protocol and consensus rules. Legal finality concerns when the applicable legal framework recognizes the transfer or discharge of obligations as final. They can align, but they are not the same concept.
The Bank of England’s 2026 Challenge notes that faster, more deterministic settlement finality was often achieved by reducing decentralization and concentrating control. It also flags probabilistic finality as an issue requiring further work for some public permissionless wholesale-settlement designs. That should not be read as a claim that all public networks have probabilistic finality.
Project Agorá adds the legal dimension. Its May 2026 report found that settlement finality is achievable across the participating jurisdictions, while further technical, operational, and contractual work is needed to align implementation with national legal frameworks.
Kenson’s analysis of programmable settlement finality covers this distinction in more depth.
Permissioning Can Support Compliance Controls, but It Does Not Create Compliance
Permissioned infrastructure can make participant eligibility and transaction restrictions easier to enforce because identified entities control entry and authorization. Public infrastructure can also implement KYC logic, allowlists, blocklists, token rules, and other controls at application or execution layers.
Neither design is automatically compliant. Regulatory obligations depend on the asset, activity, jurisdiction, participant roles, legal structure, recordkeeping, data protection, and other applicable requirements. Architecture can provide control mechanisms; it cannot determine by itself whether the resulting activity satisfies the law.
Public, Permissioned and Hybrid Infrastructure Compared
The following matrix is an illustrative architecture comparison, not a ranking or a standardized taxonomy. Specific networks can depart materially from these patterns.
| Criterion | Public permissionless | Private permissioned | Illustrative hybrid / controlled-public |
|---|---|---|---|
| Governance | Base-layer changes depend on protocol and ecosystem governance. | Identified entities can define formal change and emergency procedures. | Base-layer governance may remain external while asset or application controls sit with identified parties. |
| Validator access | Generally open subject to protocol-defined technical or economic conditions. | Restricted to approved operators. | Depends on the base network and overlay design. |
| Privacy | Ledger activity may be broadly observable unless additional privacy mechanisms are used. | Data access can be restricted by participant, role, or channel. | Open verification can be combined with controlled data or application layers. |
| Settlement | Technical finality follows network-specific consensus; legal finality requires separate analysis. | Validator and consensus design can support more controlled or deterministic finality, subject to legal design. | Requires clear interaction between base-layer finality and controlled asset or settlement rules. |
| Compliance controls | Often implemented at asset, application, intermediary, wallet, or off-chain layers. | Eligibility and transaction controls can be embedded across the network. | Controls can be layered above open or shared infrastructure. |
| Interoperability | Broad ecosystem access, but fragmentation persists across chains and layers. | Tight internal integration is possible, but separate platforms can become walled gardens. | Designed to connect controlled environments with external networks or systems. |
| Resilience | Distributed infrastructure can reduce dependence on one operator but introduces protocol, validator, governance, congestion, and dependency risks. | Greater direct control, but resilience depends on operators, governance, technology, and identity infrastructure. | Can diversify functions while adding integration and dependency risk. |
| Operating cost | Can include network fees, custody, monitoring, compliance tooling, integration, and variable network conditions. | Can include nodes, identity administration, governance, onboarding, maintenance, and consortium coordination. | Can combine cost categories from both models plus interoperability overhead. |
Interoperability Problems Exist on Both Sides
The BIS Annual Economic Report 2026 notes that public permissionless ecosystems are fragmented across base networks and secondary layers that do not communicate seamlessly. Permissioned platforms can fragment through different rules, identities, and data policies.
Connecting those environments can require bridges, messaging systems, middleware, custodial arrangements, or coordinated settlement mechanisms. These links can reduce one form of fragmentation while introducing new trust, governance, security, and operational dependencies.
Kenson’s guides to blockchain interoperability and cross-chain security risk examine those mechanics separately.
For infrastructure selection, the narrower question is: Which external systems must connect, and what new dependencies does each connection create?
Resilience Depends on the Whole Operating Model
A public network is not automatically more resilient because it has many nodes. A permissioned network is not automatically more secure because its operators are known.
Public-network dependencies can include consensus behavior, validator concentration, client software, governance, congestion, application infrastructure, or external services. Permissioned-network dependencies can include validator-set concentration, consortium governance, identity systems, key management, technology providers, contractual arrangements, and operator availability.
The Bank of England emphasizes layered resilience across technical, operational, and organizational controls. The relevant question is not only how distributed the ledger is, but which failure can stop the business process, who is accountable for restoring it, and what fallback process exists.
Operating Cost Means Total Cost of Ownership
A direct comparison between public gas fees and the cost of running private nodes is incomplete. Institutional cost depends on the full service model.
Public-network deployments can create costs around network fees, custody, monitoring, compliance tooling, smart-contract operations, and integration. Permissioned systems can shift more cost into node operation, identity administration, governance, onboarding, maintenance, cybersecurity, and integration.
Hybrid models may inherit cost categories from both environments plus interoperability overhead. These are cost categories rather than empirical claims that one architecture is always cheaper. The relevant measure is total operating cost for the required service level and control environment.
Hybrid Architecture Is a Serious Institutional Design Pattern
The Bank of England’s 2026 Challenge identified three broad approaches among participating solutions: public permissionless networks with centralized components, permissioned networks, and middleware or chain-agnostic architectures. These are design patterns observed in the exercise, not universal industry categories.
A hybrid design might use a public network with asset allowlists, connect controlled issuance to public distribution, keep settlement permissioned while interoperating with RTGS, or use middleware to coordinate several ledgers.
Project Agorá illustrates a layered institutional architecture. The BIS Annual Economic Report 2026 describes a shared platform with a unifying ledger for tokenized commercial bank deposits and separate jurisdiction-specific ledgers for tokenized central bank reserves. Participation rules, domestic control over reserves, and privacy safeguards are preserved within the prototype.
The lesson is not that hybrid infrastructure is superior. It is that institutions can assign different functions to different layers when one ledger does not satisfy every requirement.
Four Institutional Architecture Scenarios
Closed intragroup treasury network
A closed treasury workflow may prioritize known participants, restricted data visibility, predictable governance, controlled integration with internal systems, and clearly assigned operational responsibility. Those requirements can make a permissioned design relevant, although the final architecture still depends on settlement, resilience, and integration requirements.
Broadly distributed tokenized asset
An asset intended for broad secondary distribution may place more weight on ecosystem accessibility, custody support, liquidity, and external integrations. An open base network with controls at the asset or application layer can be one architecture to assess, provided privacy, compliance, governance, and settlement requirements can be satisfied.
Wholesale settlement infrastructure
A wholesale settlement system involving regulated money may prioritize identified participants, legal finality, central-bank-money connectivity, privacy, operational resilience, and explicit governance. Project Agorá shows why that problem can lead to layered infrastructure rather than a simple public-versus-private choice.
Multi-network tokenized-market infrastructure
A market spanning issuance, custody, payments, compliance, and distribution may require interoperability across several ledgers and non-DLT systems. In that case, middleware or another hybrid design can be evaluated as part of the architecture rather than assuming one ledger should become the universal infrastructure layer.
An Institutional Blockchain Architecture Decision Tree
| Decision question | If yes | If no | Architecture implication |
|---|---|---|---|
| Does the use case require broad external participation or ecosystem composability? | Assess whether controls can sit above an open base network. | Restricted participation may be sufficient. | Determines how much openness is required. |
| Must validators or infrastructure operators be identified or contractually accountable? | Permissioned validation or another controlled arrangement may be required. | Protocol-defined open validation may remain viable. | Defines validator-access and accountability requirements. |
| Must sensitive transaction or business data be restricted? | Add privacy, selective-disclosure, partitioning, or controlled-data layers. | Broader ledger visibility may be acceptable. | Defines information-boundary requirements. |
| Is legally recognized settlement finality required for regulated activity? | Map the technical finality event to applicable legal and contractual rules. | Technical finality may still matter operationally. | Prevents protocol finality from being treated as legal finality. |
| Must the system connect to RTGS, custodians, registries, trading venues, or other ledgers? | Design interoperability and governance for each dependency. | The architecture may remain more self-contained. | Identifies external integration and dependency risk. |
| Who must control upgrades, emergency actions, and recovery? | Assign explicit authority and accountability. | Rely more heavily on underlying network governance. | Locates governance and intervention powers. |
| Can the required service level be supported at acceptable total cost? | Compare full operating and control costs. | Reconsider architecture or scope. | Tests viability after governance, compliance, and resilience costs are included. |
The result is not simply “public” or “permissioned.” It is an architecture profile describing the openness, control, privacy, settlement, interoperability, resilience, governance, and cost characteristics the use case requires.
Infrastructure Selection Is a Requirements Exercise
Public permissionless, private permissioned, and hybrid blockchain designs distribute trust, authority, data visibility, and operational responsibility differently. None guarantees privacy, compliance, interoperability, security, resilience, or low cost.
The more useful institutional approach is to begin with participant requirements, governance, data boundaries, settlement assurances, integrations, resilience standards, and operating responsibilities. Only then should the institution determine which architecture can satisfy those requirements with acceptable dependencies and cost.
That turns public vs permissioned blockchains from an abstract technology debate into an infrastructure-selection decision.
Continue the Research
Kenson Investments publishes education, research, and market analysis covering tokenized-market infrastructure, blockchain governance, settlement, interoperability, and digital-asset operational risk. To explore Kenson’s research coverage and educational resources, Contact Us.
