How the EVM became institutional infrastructure, and what it means for the next central bank network.

Brazil's central bank runs its digital real pilot on Hyperledger Besu.

Fnality, the wholesale payment utility backed by more than 20 global banks, settles in central bank money through a Bank of England omnibus account on Hyperledger Besu.

In 2023, the Banque de France, the Monetary Authority of Singapore, and the Swiss National Bank issued wholesale CBDCs as ERC-20 tokens and bridged them to an Ethereum testnet using two smart contracts and a relayer.

JPMorgan launched its first public-chain deposit token on Base, an Ethereum L2, in late 2025, after six years on a private chain that shared Base's technical lineage. Deutsche Bank is piloting tokenised asset settlement on ZKsync infrastructure.

None of these institutions would describe what they are doing as "using Ethereum."

The procurement documents say Hyperledger. The press releases say distributed ledger technology. The compliance teams approved a Linux Foundation project.

But the code running underneath all of them compiles against the same virtual machine, conforms to the same standards, and stores state in the same data structures as Ethereum mainnet. They are in the same tent. They just came in through different doors.

That observation, once you see it, changes how you think about the question a European central bank put to me recently. They are designing a multi-sovereign network with other central banks as validators, a commercial bank layer on top, and a path to Ethereum mainnet connectivity when regulation allows.

They wanted a view on the consensus mechanism: Proof of Authority or Proof of Stake?

It is a good question. It also has a straightforward answer, which I will walk through below. But the more interesting thing is that they arrived at essentially the same architecture as every major central bank blockchain project of the last decade, independently, without copying anyone. When I started pulling the thread on why that keeps happening, the consensus question turned out to be the easy part. The harder question, the one they had not fully pressure-tested, is about the client underneath the consensus layer, and it is the decision that determines whether the rest of their plan is possible at all.

I should say something about where I sit before going further. I work at the Ethereum Foundation. Everything I am about to argue leads to an Ethereum client. You should hold that fact in your hand while you read this and decide for yourself whether the argument holds despite the affiliation or because of it. The maximalist position would be that everything should settle on mainnet directly. I do not hold that position, and I think it is counterproductive when talking to institutions whose constraints are real and whose timelines are measured in regulatory cycles. The pragmatic case for Ethereum in institutional infrastructure is not "use mainnet now."

It is "build on a client that keeps mainnet on the table for when you are ready, and do not accidentally close that door by choosing a stack that cannot get there."

Subscribe for free to receive new posts and join the community of 8,000+ business leaders

If you already work in this space, skip to the next section. This is here for readers who want the ground laid before the argument.

Proof of Stake is the mechanism securing Ethereum mainnet. Around 12,000 node operators secure approximately 36 million ether (over $100 billion at current prices) across more than a million validator keys, taking turns proposing and attesting to blocks.

To become a validator you lock up 32 ether in a smart contract. Since the Pectra upgrade in 2025, validators can hold up to 2,048 ether. The protocol selects validators pseudo-randomly to propose blocks. Other validators check the proposed block and attest to its validity. If enough attestations accumulate, the block is added to the chain.

If a validator signs two conflicting blocks or attests to something obviously false, the protocol automatically destroys part of their stake. This is called slashing. There is no human intervention, no court, no regulator. The protocol running on every node sees the contradiction and burns the collateral.

This is a genuinely remarkable piece of engineering, and it is more structured than it first appears. The validator's relationship with the network is governed entirely by smart contract logic: deposit conditions, reward calculations, withdrawal queues, slashing penalties, all encoded in protocol-level contracts that execute deterministically. Permissionless does not mean unregulated. It means the regulation is programmatic rather than institutional. The rules are public, auditable, and enforced by every node on the network simultaneously.

The result is a network that replaces institutional trust with trust in code. Validators do not need to know each other, share a legal framework, or operate under the same regulator. The protocol's rules, running identically on every node, are the common framework. Ethereum is the working example, running in production, securing more value than any other PoS network by an order of magnitude.

The Ethereum ecosystem has also evolved considerably since PoS launched in 2022. Liquid staking, restaking protocols, distributed validator technology, and a growing landscape of L2 rollups have created a rich set of configuration options for institutions entering the space. That richness is a strength for builders who know what they need. For institutional buyers evaluating the ecosystem for the first time, it can also be genuinely overwhelming. There are a lot of doors in the tent, and not all of them are well signposted.

PoS is the right design when the network is open to any participant, when validators are not bound by shared legal frameworks, and when security must be enforced programmatically rather than institutionally. That is Ethereum mainnet, and PoS is the correct mechanism for it.

Proof of Authority is the mechanism that runs when the validator set is known from the genesis block. The rule is not "anyone with 32 ether can validate" but "these specific entities, named here, are the validators." Adding or removing a validator requires an on-chain governance action, usually a supermajority vote of the existing validators.

Block production runs through a Byzantine Fault Tolerant (BFT) consensus protocol. The name comes from a classic problem in distributed computing: how do you reach agreement when some participants might be lying or failing? BFT protocols solve this by requiring a supermajority of validators to sign off before any block is committed. PoA is the umbrella category; QBFT and IBFT are the specific BFT protocols that sit underneath it in the Ethereum client ecosystem.

QBFT, the flavour most central bank projects use, works like this. Validators take turns in a pre-agreed order, proposing blocks. Every other validator checks the proposed block and signs a message confirming it is valid. Once two-thirds of the validator set have signed, the block is committed. Finally, irrevocably, in the same sense that a wire transfer is final when the receiving bank credits the account.

The fault tolerance maths is straightforward. With n validators, the network tolerates up to f = floor((n-1)/3) Byzantine faults. For a consortium of ten central banks spanning different geopolitical blocs, the network tolerates three Byzantine faults. No single bloc, and no three aligned nations, can break consensus.

There is no staking token, no slashing, no economic collateral. What stops validators from misbehaving is that they were chosen precisely because they are accountable through other means. A central bank that signs a block it should not have signed has violated a multilateral agreement, breached its operational mandate, and created a diplomatic incident. Those consequences exist entirely outside the protocol and are considerably more severe than losing a staking deposit.

PoA does not manufacture trust from game theory. It encodes existing trust relationships as cryptographic signatures.

PoS and PoA are not competing answers to the same question. PoS was built to secure an open network through programmatic rules and economic incentives, replacing institutional and human trust with trust in code. PoA was built to organise block production among a small set of known, legally accountable institutions, encoding existing trust relationships rather than manufacturing new ones.

Neither mechanism is "better" in any absolute sense. They are answers to different problems. Get the problem right and the consensus choice follows.

A consortium of European central banks is firmly in the known-validator problem for their internal settlement. PoA fits. But settlement does not stop at the edge of the trust circle. When that consortium needs to interact with the central bank of El Salvador, or Iceland, or any jurisdiction where the bilateral institutional trust is thinner, the trust-in-code model that PoS provides becomes the bridge. Ethereum mainnet is the neutral settlement layer that neither party controls and both can verify independently.

The architecture, then, is not PoA instead of PoS. It is PoA within the trust circle; the Ethereum mainnet is between trust circles. Both are running on the same virtual machine. Both speak the same token standards. Both in the same tent, connected by the shared EVM lineage that makes interoperability a configuration decision rather than a replatforming exercise.

That is why the client choice matters more than the consensus choice. The consensus mechanism serves the local problem. The client determines whether the local network can reach the global one.

Before getting there, though, it is worth walking through why PoS does not fit the local problem, because the reasons are more specific than "wrong tool."

The issue is not that PoS is bad. PoS is excellent at what it does and creates a neutral meeting point for many different organisations. The issue is that the slashing mechanism, which is the thing that makes PoS work at all, requires a staking token with real economic value.

When I first looked at the staking question for sovereign validators, I assumed there would be a clean option. There is not.

Option A: Their own CBDC. A central bank stakes some amount of the wholesale CBDC it issues. If it misbehaves, the protocol burns that CBDC. You have now created an on-chain mechanism that can automatically destroy central bank money, directly implicating the monetary base of a sovereign nation. Legal frameworks in every jurisdiction would need to be rewritten. The BIS research on cross-border CBDC is explicit that central bank balance sheets must not be affected by inter-platform transfers, precisely because such effects would be politically and legally intolerable.

Option B: A synthetic governance token. Create a new token with no financial value, issued only for staking. If slashed, the validator loses tokens that have no market, no redemption mechanism, and no balance sheet impact. You have built a mechanism that looks like PoS but provides none of its economic deterrence. The operational complexity of tokenomics with none of the security properties. This is theatre.

Option C: Tokenized reserves. Validators stake a portion of their foreign exchange reserves, tokenized and held in a custody arrangement. Now there is real economic value at risk. You have also introduced tokenized sovereign assets as collateral into a cross-border platform, with custody, accounting, and regulatory capital implications in every participating jurisdiction. The IMF's primer on blockchain consensus for supervisors identifies exactly this as an unresolved governance problem.

Every path through PoS for a sovereign validator network hits the same contradiction. Either you are touching the monetary base, or you are building a deterrence mechanism with no teeth.

The arXiv 2025 survey of 26 deployed CBDC systems says it directly: "Given CBDC's need for efficiency, finality, and energy conservation, PoA, DPoS, and notary-based mechanisms are more suitable than PoW or PoS."

Once the staking token is removed, PoS collapses into permissioned BFT anyway. A known validator set, identity-gated, with no economic bond. At that point you are running BFT consensus with extra steps.

PoS was invented to solve a trust problem central banks do not have. The mechanism it uses to solve that problem creates new problems central banks cannot absorb. For a validator set of European central banks, under their legal constraints, PoA is the only choice that fits.

Every serious central bank blockchain project of the last decade has landed on permissioned BFT. Not because the architects independently audited consensus mechanisms and concluded PoA was safer, but because every other path required a legal or political concession they could not make. The grouping below is by client, because as I will argue in the next section, the client is the axis that matters.

Hyperledger Besu (EVM, Ethereum-compatible)

Quorum, now community-maintained (EVM, Ethereum-compatible)

Custom EVM

Hyperledger Fabric (no native EVM)

R3 Corda (no EVM)

Mixed stack

Staking token across all twelve projects: none. The implementations vary (QBFT, IBFT, Raft, Dashing, Corda Notary) but they share the same property. A known validator set, identity-based authority, and immediate deterministic finality.

The grouping also surfaces the client split. Seven of twelve projects are on EVM-compatible clients. Five are not, and those five cannot become anything else without being rebuilt.

The convergence is not entirely independent. Many of these projects share BIS Innovation Hub coordination. Several share ConsenSys consultants who wrote the original Quorum code. They share legal templates and vendor shortlists. But the shared constraints were real, and the alternatives were genuinely thin. Every project needed immediate deterministic finality to satisfy payment system regulations, a validator model that did not require touching the monetary base, and an EVM-compatible client that legal teams could evaluate without the word "Ethereum" in the procurement document.

The consensus question is settled. The more consequential decision is what runs underneath it.

The consensus choice turned out to be the least interesting part. Consensus is settled the moment you accept that sovereign validators cannot stake without either touching the monetary base or building theatre. The decision that determines whether the rest of their plan is possible at all is the client.

Their plan, as they described it: a PoA network between European central banks, an L2 on top for commercial bank interaction, and eventual connection to Ethereum mainnet. That plan is viable on exactly one class of client. It is worth being clear about why, and worth being equally clear about where I might be wrong.

Hyperledger Fabric cannot offer meaningful Ethereum connectivity. Fabric has an experimental EVM chaincode (based on Hyperledger Burrow) that can run Solidity inside a chaincode wrapper, but the project is archived, the execution is emulation rather than native, and there is no binary lineage with Ethereum clients, no shared block format, no wire protocol, and no path to becoming an L2 or posting state to mainnet. Fabric networks are technically competent at what they do. If the consortium never wants to interact with the EVM ecosystem, Fabric is a legitimate choice. If it does, Fabric is a rebuild.

R3 Corda cannot offer it either. Kotlin-based contracts, UTXO-like state model, notary-based consensus. Corda networks cannot run an ERC-20 or post a proof to Ethereum L1 without being rebuilt from scratch. Project Jura and Project Jasper Phase 2+ are good working pilots that answered the questions they were designed to answer. They are also architecturally isolated from the EVM ecosystem. Other non-EVM platforms, including Canton Network, face the same constraint: no EVM compatibility means no path to Ethereum L2s, bridges, or mainnet connectivity.

Custom BFT chains can offer it only if they choose to build EVM compatibility in from the start, which mBridge did, because the original BIS-led team had the engineering depth to maintain a bespoke codebase and anticipated the need. Most central banks have neither the depth nor the appetite. Custom BFT is a commitment to maintaining your own client forever.

The cost of choosing wrong is not hypothetical. In 2017, the Australian Securities Exchange engaged Digital Asset to replace its 30-year-old CHESS clearing and settlement system with a system built on DAML, Digital Asset's proprietary smart contract language (the same language that powers Canton Network). The project missed four publicly announced go-live dates. An Accenture review found DAML-specific scalability constraints and architectural latency issues introduced by the distributed ledger design. In November 2022, ASX scrapped the project and wrote off A$250 million. The replacement, rebuilt without Digital Asset on a conventional technology stack, delivered its first release in April 2026 at a total cost of A$445 million and nearly a decade of elapsed time. ASIC subsequently sued ASX for misleading investors about the project's progress. Single-vendor dependency on a proprietary language was identified as a core risk factor.

Hyperledger Besu offers it natively. The same Besu node that runs QBFT consensus for a permissioned network speaks Ethereum from the ground up. Same binary lineage, same EVM, same wire protocol, same Solidity compiler, same token standards, same developer tooling. When a Besu node runs QBFT internally, it is still executing Ethereum opcodes, producing Ethereum-compatible blocks, and storing state in Ethereum-compatible data structures.

This is what I mean when I say these institutions are already using Ethereum without calling it that. A Besu permissioned chain is not an Ethereum-like network. It is an Ethereum network, configured for a closed validator set. The distance between it and mainnet is a governance decision, not a technical migration.

Besu is not the only EVM client. GoQuorum has the same ConsenSys lineage and was the workhorse of the 2018-2022 institutional era. JPMorgan's JPM Coin, later Onyx, now Kinexys, ran on GoQuorum from 2019 through the 2025 public-chain move. Then ConsenSys handed GoQuorum back to the community, and Besu became the client where active development, EEA standards work, and institutional attention now sit. Building on GoQuorum today is choosing the slower-moving fork of the same family tree. Nethermind is an excellent Ethereum client, but it was designed for mainnet validators. The QBFT tooling, the smart-contract validator management, the institutional packaging: none of it is where Besu's is. Nethermind is what you run if you are staking on mainnet. It is not what you run if you are building a multi-sovereign permissioned network.

Step back from the specific client recommendation and look at what has actually happened over the last five years.

The EVM started as the execution environment for one public blockchain. It is now the common technical standard across public chains, private permissioned networks, L2 rollups, institutional pilots, and central bank infrastructure. A solo Ethereum validator, a Coinbase L2 sequencer, a JPMorgan deposit token, a Bank of England-backed wholesale settlement system, and a Brazilian central bank digital real pilot are all running on the same virtual machine. Their code compiles against the same specification. Their tokens conform to the same interfaces. Their developers use the same tooling.

These entities have nothing in common culturally, regulatory, or commercially. A Fnality engineer and an Ethereum mainnet solo staker would not recognise each other's working lives. But their infrastructure is interoperable at the protocol level because they made the same client choice, or one that shares its lineage.

This is what happened with TCP/IP in the 1990s. Private corporate networks ran proprietary protocols for years. Eventually the ecosystem gravity of the common standard pulled them in. Not because anyone mandated it. Because the cost of maintaining a separate stack, and the opportunity cost of being unable to interoperate, compounded until migration became inevitable. Nobody "chose TCP/IP" by the late 2000s. It was just what networks ran.

I think the EVM is on the same trajectory for institutional financial infrastructure. That is an ambitious claim and I hold it with appropriate uncertainty. What I can say with more confidence is that a central bank consortium choosing Besu today is keeping a door open at minimal cost. Reopening it later is a replatforming exercise, not a configuration change.

JPMorgan is the proof that the door is real. When JPMorgan launched JPMD on Base in November 2025, its first public-chain deposit token, the shared EVM lineage with its private Kinexys chain meant institutional logic, developer tooling, and smart contract patterns could carry over. A bank that had built on Fabric or Corda in 2019 would have had to rebuild the stack to launch an equivalent public-chain product.

The strongest argument against this entire thought is the time horizon.

Ethereum mainnet connectivity is a ten-year bet. Most central bank projects have much shorter project budget cycles. A consortium that chooses Besu for EVM optionality and then never exercises that option has paid for architectural flexibility it did not use and is arguably just as well served by other non-EVM options.

There is also a version of this story where the regulatory environment moves decisively against public chain interaction for sovereign institutions. Not impossible. European regulators have shown willingness to create compliance frameworks (MiCA, the pilot regime for DLT market infrastructure), but those frameworks could tighten rather than loosen. If they do, the "call option on mainnet" is worth nothing, and the consortium has chosen a more complex client for no benefit.

I think the directional bet is right. The trajectory of institutional finance is toward the EVM ecosystem, not away from it, and the cost of maintaining optionality through Besu is low enough relative to the cost of replatforming later that it is the correct choice even under significant uncertainty.

A central bank independently arrived at the same architecture every major BIS project has converged on: Proof of Authority at the base layer, an L2 for commercial bank interaction, a path to Ethereum mainnet. That keeps happening because the constraints are the same everywhere and the alternatives are genuinely thin. Sovereign validators cannot stake without touching the monetary base or building theatre, which settles the consensus question. The client choice is what determines whether the rest of the plan is possible.

Besu gives you permissioned BFT consensus that satisfies every legal and operational constraint, and it keeps Ethereum mainnet on the table. Central banks that built on Corda and Fabric got working pilots. Central banks that built on Besu got working pilots and a path to the settlement infrastructure the rest of institutional finance is converging on.

The consensus mechanism is downstream. The client choice is the strategy.

Enjoyed this deep dive? Share on socials and with someone you know. Most of our subscribers come from referrals.

Thanks for reading, until next week.

James Smith

Sources: BIS Project mBridge brochure (October 2023) | BIS Project Mariana report | BIS Project Dunbar report | BIS Project Jura report | Hyperledger Besu QBFT documentation | EEA QBFT specification (January 2023) | IMF, Blockchain Consensus Mechanisms: A Primer for Supervisors (2022) | arXiv, CBDC Survey 2025 | Fnality, Consensus mechanism | JPMorgan Kinexys | Linux Foundation Hyperledger CBDC Ebook