Why do so many institutional tokenization projects use Besu? You will keep coming back to the same question if you dive into each one. It is used in payment networks, digital bond platforms, collateral systems, and central bank experiments. These projects have different goals. Some need to move money between banks. Others need to issue securities or make collateral easier to use.
Yet the underlying technology choice is similar. Project Agorá, Fnality, Clearstream D7 DLT, Citi Token Services, and DTCC’s Collateral AppChain all use Besu, according to the 2026 LFDT Institutional Adoption Report 2026.
For sure, this does not make Besu the best choice for every project. I would be careful with that claim. But there are reasons it keeps getting selected when institutions need control over participation, predictable settlement, and room to adapt the software.
This article looks at why. Because popularity alone tells a bank very little about the reasoning. What a bank needs to know is which capabilities pushed these institutions toward the same client, and whether those capabilities fit its own tokenization plans.
We found seven reasons, and each one below is tied to a deployment that uses it. We are certain they will make more sense once you know what to look for in them.
1. Absolute EVM Equivalence
A bank choosing a blockchain today is also making a decision about what it can connect to later. That is where Besu’s EVM equivalence starts to matter.
Besu is an Ethereum execution client. It runs on Ethereum mainnet, and the same client supports private, permissioned networks. For example, BNP Paribas CIB’s AssetFoundry uses Besu on public Ethereum. Clearstream and DTCC use Besu for permissioned infrastructure, according to the LFDT report cited above. These are different operating models built around the same client.
So a bank can build within a controlled environment while using Ethereum’s execution rules, token standards, and also development tools.
For sure, plenty of platforms describe themselves as EVM-compatible. But Besu has a direct responsibility here. As a mainnet execution client, it has to execute transactions according to Ethereum’s protocol rules. For a bank, this means Solidity contracts, ERC token standards, and familiar tools can form the foundation of its tokenization platform. There is less need to create a separate technical language for institutional assets.
We should be a little careful with what “absolute” means, though. The execution rules can match while the networks have different permissions, external services, and configurations. Contracts still need testing after migration. An audit is helpful, but changes to the surrounding system may need additional review. But whatever it is, the benefit is that the team starts with a common foundation.
One important recent news item I want to link here. On October 19, 2026, J.P. Morgan said Kinexys is bringing their JPM Coin (JPMD) to Ethereum mainnet. For a bank planning tokenized assets, the context is important here. Our reading is that this makes Ethereum alignment more valuable. Public Ethereum is becoming a place where institutional assets and bank-issued deposit liquidity will exist together. A bank issuing assets on a permissioned Besu network has a familiar execution environment when it starts designing connections to that activity.
Source: JP Morgan
Let’s take another example where Besu was directly used.
The Bank of Korea’s Project Hangang is a good example of what institutions can build with Ethereum standards.
According to the LFDT report, around 80,000 people used tokenized bank deposits to pay at merchants during the first phase. Banks settled between themselves using wholesale central bank money on the same Besu ledger. The deposits and wholesale money used ERC-20 tokens. Spending conditions sat in a separate ERC-1155 layer. The next phase adds ERC-3525 so individual grants can have their own identity and still carry a spendable balance.
This separation makes sense to us. An electric vehicle charging subsidy might be restricted to approved suppliers and released as installation milestones are completed. An expense payment might fail at a restricted merchant.
When the policy changes, the bank can update the spending conditions without redesigning the underlying money token. That is a fairly good reason to use established standards.
2. Institutional Privacy Readiness
Privacy is probably where the most important early questions come up. A bank may be comfortable sharing infrastructure with other banks. It is much less likely to be comfortable sharing its customer relationships, balances, and payment patterns with them.
Permissioning only answers part of that problem. It controls participation. The institutions already inside the network may still have access to sensitive information. So privacy has to go further.
Besu’s older Tessera-based private transaction functionality was deprecated following the maintainers’ 2024 announcement. So, new projects need to plan around a supported privacy architecture.
We see this as a choice that needs to be made alongside the asset design. Leaving it until the contracts are finished can create a lot of rework.
Modular privacy through Tegaris
Besu’s permissioning gives institutions control over participation. Application privacy needs more detailed rules. This is where Tegaris Application Privacy, an approved LF Decentralized Trust Lab, can be relevant.
The Lab focuses on participant authority, contract interactions, data visibility, and controlled policy changes on shared EVM networks.
This is useful because sensitive information can be exposed through fairly ordinary application access. An RPC request, an explorer view, or an event subscription may reveal more than a participant needs for its work.
Those access points need controls too. Tegaris already has enterprise sign-in through OIDC, wallet authentication, and role-based access controls. It’s building on this with participant-scoped permissions and delegated authority.
Zero-knowledge readiness
Lineth, originally developed as the Linea Stack, can use Besu-based execution. It includes the wider components needed for a ZK Layer 2, including sequencing, proof generation, and Ethereum contracts for verification and messaging. The stack has powered Linea mainnet since 2023 and now sits under LF Decentralized Trust.
That gives Besu a concrete relationship with a production ZK stack. It does not mean a standard Besu network becomes confidential simply by connecting to Linea. Proofs of correct execution and transaction confidentiality are different requirements. Data availability, participant access, and disclosure still need their own design.
For a bank, the useful point is that Besu-based execution can form part of a broader ZK architecture. It has an established development path beyond a conventional permissioned ledger.
ZKsync Prividium also has specific Besu support. On July 2, 2026, ZKsync announced Prividium support for institutions operating on Besu. It is also a phased path to ZK-proven privacy and Ethereum connectivity while retaining existing infrastructure.
For banks, these options create room to evolve. A project can begin with an issuer-visible privacy model and assess more advanced ZK components as its requirements develop.
But regulators are still careful about zero-knowledge systems. Here’s what the LFDT Institutional Adoption Report says,
“..However, regulators have been cautious. Zero-knowledge proofs (ZKP) are relatively new, the perceived cybersecurity risks are higher, and the specialist skills required to build and audit these systems are scarce…”
So most banks will probably start with other available privacy choices like Tegaris and bring in network-level ZK components as supervisors also get comfortable.
3. QBFT Consensus That’s Built for Finance
Settlement finality is the point after which a transfer can’t be reversed. For financial assets, settlement needs a clear finality because a bank needs to know when a payment has completed. A collateral team also needs to know when an asset is available to pledge again. Waiting for an uncertain outcome complicates everything around the transaction.
Many public permissionless networks only offer probabilistic finality that firms up over time. Because finality is legally defined, that ambiguity creates uncertainty for regulated firms
Besu supports QBFT, which is a proof-of-authority consensus mechanism that uses a known validator set.
QBFT provides immediate technical finality once a block is committed under its consensus assumptions. There are no forks, and every valid block goes into the main chain. Validators can also vote to add or remove members. Besu recommends at least four validators for Byzantine fault tolerance, and requires greater than or equal to two-thirds of validators to be operating to create blocks.
This fits institutions that need identifiable operators and agreed governance.
Fnality is a good example of this capability.
The Sterling Fnality Payment System runs on Besu. It went live in 2023 and is a systemically important payment system regulated by the Bank of England.
Here, the participants move funds into an omnibus account at the central bank and hold matching entitlements on the ledger. Banks use these balances for DvP, margin, repo, and 24/7 cross-border payments.
A UK settlement finality designation granted in late 2024 gives transfers legal finality within the system. So QBFT provides the technical finality, and the legal framework determines its legal effect. We should see those two points together because a consensus mechanism cannot establish the legal meaning of an asset transfer on its own.
Project Agorá could be another example. It also runs on QBFT across permissioned validator nodes, with eight central banks and more than 40 financial institutions involved.
Two points tend to get missed in this consensus discussion.
- Block times grow as validators are added. Correct? So a 30-bank consortium has to think about validator set size and not just membership. This is important sometimes. For example, Citi tuned their consensus mechanism itself to reach global-bank volumes.
- Also, a network doesn’t have to start as a wide consortium always. The Bank of Korea is the sole validator on its ledger. It argues the value lies in programmability and composability rather than decentralization, and a proof-of-authority-style setup gives it both.
4. Permissioning and Control
Let’s take a tokenized money market fund share that a bank wants to accept as collateral. Several questions come to mind straight away.
- Who is on the network?
- Who is allowed to hold the share?
- And if a transfer goes wrong, can the transfer agent fix the register?
The network-level answer for this is Besu permissioning. Node permissioning restricts connections to known participants. Account permissioning lets an operator enforce onboarding checks, suspend accounts, and limit what an account can do. More complex rules can be written as a plugin. For many institutions, this is a mandatory requirement. For example, Clearstream must run a permissioned chain as a CSDR-regulated entity, and D7 does exactly that.
One detail needs to be mentioned here when we describe a network as permissioned. Local permissioning applies to the node under an operator’s control. Its rules are not automatically enforced in blocks produced by other nodes. Consortium-wide controls therefore need coordinated governance and enforcement at the appropriate layer.
The second question is answered in the token contract. Most tokenized money market funds already restrict transfers and redemptions to KYC-checked, whitelisted wallets through smart contract standards. On Besu, a fund issuer does the same thing. The network keeps strangers out, and the token decides which members can hold it.
Now let’s come to the third question, which is important for collateral law. In ISDA’s registered structure, the registrar controls the register at all times and can block or correct an update. Admin functions in the token contract give the transfer agent those powers on-chain. Franklin Templeton’s transfer agent, for instance, can correct errors and unauthorized transactions in its fund shares. Here’s what was said in the ISDA report about it:
“The integrated ledger is the definitive record of legal ownership of the underlying shares. Unlike permissionless tokens, the shares recorded on the integrated ledger are under the unilateral control of the transfer agent. The transfer agent is responsible for maintaining the accuracy of fund share ownership on any blockchain network used by the blockchain-integrated system and has the ability to correct errors and unauthorized transactions in BENJI shares. However, beyond correcting inaccurate or unauthorized entries, the transfer agent cannot unilaterally or arbitrarily amend the ledger without instruction. Franklin Templeton Investor Services, LLC is BENJI’s shareholder servicing agent and acts as the fund’s transfer agent (rather than a third-party intermediary).
On Besu, a bank builds these powers into the token contract as admin functions held by the registrar or transfer agent.
5. Open-Source Code
Citi’s experience gives this point some weight. Citi Token Services runs on CIDAP, Citi’s digital asset platform built on Besu. They process close to $1 billion a day. To reach that volume, Citi fine-tuned the consensus mechanism.
A bank on a closed vendor platform would have to file a feature request and wait. Citi changed the code itself.
Besu also has a plugin system, so a bank can add behaviour without forking the client. Lineth is a good example. Its execution layer is Besu plus Layer 2 plugins, and those plugins add enterprise features without breaking EVM equivalence.
Then there is governance. Besu sits under LF Decentralized Trust, and no single vendor owns its roadmap. Where several networks share a layer, that only works if no one vendor controls it. In the same report, the Bank of Korea also said open source “avoids vendor lock-in and enables a rapid response to security issues”.
The privacy and permissioning changes in Besu are reminders that an open source roadmap still moves. Tessera was retired, and smart contract-based permissioning is being phased out of the core client. Banks that built on those features had to plan upgrades. So a bank on Besu needs people who follow the project closely, either in-house or through a partner who contributes to it, like Zeeve.
6. Hybrid Architecture That’s a Requisite for Tokenization
A hybrid architecture means a bank issues and settles on a controlled permissioned ledger and connects out to public chains, stablecoins, or other networks when it needs them. Tokenized activity today is spread across dozens of smaller networks that are weakly interoperable at most. Scaling depends on better interoperability across networks and common standards. An asset stuck on a closed network has a very small market.
That is why hybrid architecture is valuable. Here, we mean a controlled institutional network with designed connections to public chains, other permissioned networks, and existing financial systems.
Besu’s Ethereum foundations help with these connections.
Different assets need different connection models to reach public liquidity
Banks on Besu have used three different models here, and they suit different assets.
Clearstream uses lock and represent. Because its chain uses Ethereum standards, a partner can lock a Clearstream token on the permissioned network and issue a representation on a public chain. DTCC controls the registry for its tokenized securities. When a holder moves tokens to another chain, DTCC burns them on Besu and mints new ones on the destination chain. KfW wants something else. It issued a €100 million digital bond on Polygon and plans to move it to RL1, the Besu-based network on the SWIAT ledger. KfW’s aim is to change the ledger of record.
Bridges carry their own risk. They widen the attack surface and need their own security standards. DTCC’s Collateral AppChain avoids the issue. A bond tokenized on Clearstream’s D7 stays on D7 and the pledge is marked on the tokens. The AppChain records the encumbrance and passes instructions to the holding ledger. Nothing gets reissued elsewhere.
Here’s a snapshot
Stablecoin ecosystem access
Roughly two-thirds of payments executives interviewed by McKinsey see stablecoins and tokenized deposits as wholesale settlement tools rather than retail currencies.
Source: McKinsey Global Payments Report, September 2026
But Stablecoins are spread across Ethereum, Solana, Polygon and other networks, and they don’t solve interoperability on their own. Several Besu networks are built to connect these instruments. Mastercard’s Multi-Token Network runs on Besu and handles settlement across tokenized deposits, digital assets and regulated stablecoins. The Universal Digital Payment Network uses Besu to connect CBDCs and regulated stablecoins, and Europe’s Commercial Bank Money Tokens initiative uses it for interoperability. Swift has regulated stablecoins on the roadmap for its Besu-based ledger.
Custom interoperability through IBC
Some bank networks want to talk to another permissioned chain without trusting a bridge operator in the middle. IBC, the Inter-Blockchain Communication protocol from the Cosmos ecosystem, lets two chains verify each other’s state directly. There are open source IBC implementations in Solidity that support Besu and other EVM chains.
7. A Dozen of Case Studies That Bring in Production-Grade Trust
Capabilities are easier to assess once we can see what institutions have done with them. The list below covers a dozen deployments that map to the capabilities above.
Zeeve as the Besu Technology Partner for Banks and FMIs
The banks in this article didn’t reach production by installing a Besu client. Citi tuned consensus. Agorá added a privacy layer. Clearstream scaled and hardened a trial network over two years. Most of the work happened around Besu, in customization, privacy, integration, and operations.
That is where Zeeve fits. Zeeve is a Certified Solution Provider for Besu, with a growing team of certified Besu engineers. Those engineers contribute to Besu. That depth supports protocol customization and performance optimization when a bank needs more than the default configuration. Banks that want to build their own capability can bring in Zeeve for Besu team augmentation.
Zeeve also supports on-premise deployments and runs 24/7 production support. Its office infrastructure and processes are SOC 2 Type II and ISO 27001 compliant. If you run an older enterprise chain today, Zeeve’s chain migration engineering can move it to Besu. For hybrid setups, it builds cross-chain interoperability using IBC, and Zeeve’s modular privacy suite offers four layers of privacy for a bank’s blockchain network.
A good next step is to take one asset you plan to tokenize and test it against the seven capabilities we discussed in the article. Zeeve’s Besu engineers can turn those answers into a reference architecture your risk and technology teams can review.
Schedule a call with our Besu experts today.
