Besu BYOC Support

Today we're adding support for Besu (formerly known as Hyperledger Besu) to the Dfns platform through our universal connection layer. This means institutions can now operate wallets on their own private or permissioned Besu networks with the same orchestration, policy, and key management primitives Dfns offers across the 60+ networks we already support.

For banks, financial market infrastructures, and other regulated institutions, this matters because the architecture they actually need is rarely "all public" or "all private." It's both. Besu, plugged into Dfns, gives them a credible way to run private permissioned execution internally while keeping the door open to public Ethereum and the wider EVM ecosystem.

The picture institutions are actually building

The institutional digital asset architecture that is emerging today is hybrid by design. Tokenized deposits, internal settlement networks, and bank-issued stablecoins increasingly live on private permissioned EVM chains, where the institution controls the validator set, the membership, the privacy model, and the data residency. At the same time, those institutions need a path to public liquidity, public stablecoins like USDC and EURC, and public venues for collateral, FX, and settlement.

Besu sits cleanly in that picture. It is an open source, enterprise grade EVM client originally developed by ConsenSys and contributed to the Linux Foundation's Hyperledger Foundation in 2019, making it the only Ethereum client at Hyperledger. Because it is fully EVM compatible, contracts written for public Ethereum run on Besu without modification, and the same tooling (Solidity, Hardhat, Foundry, ethers.js, viem, MetaMask, WalletConnect) works on both sides. That property is what makes Besu the practical bridge between a bank's internal permissioned network and the public chain economy.

Besu is in production today. It is one of the ledgers underpinning the Banco Central do Brasil's Drex pilot, the EEA's enterprise Ethereum work, the Onyx by J.P. Morgan platform's earlier deployments, the Bank of France's wholesale CBDC experiments, and a series of bank consortium and FMI projects in Europe and Asia. When financial institutions ask us about "private EVM," Besu is the first answer on the shortlist.

What "Bring Your Own Chain" means on Dfns

Our Besu connector is the abstraction that lets us treat customer operated EVM networks as first class citizens on our platform without having to maintain a public RPC, an explorer, or a token registry for them. With this release, an institution running a Besu network internally can:

• Provision Dfns wallets that operate directly on their Besu chain
• Use the full Dfns Key Orchestration Service (MPC, HSM or offline signers) for those wallets
• Submit transactions, deploy contracts, and interact with their internal token, tokenized assets, or settlement infrastructure through the same SDKs used across all Dfns supported chains
• Apply the same workflows, attestation, policies, and entitlement controls used for public chains

In other words, the wallet infrastructure layer is unified across the institution's private Besu environment and the public chains they operate on. There is one orchestration plane, one policy model, one audit trail, and one SDK surface for both.

How Besu is supported on Dfns, concretely

We've integrated Besu as a specialty EVM chain in the Dfns network registry, gated by our SpecialtyNetworksWhitelist so it is enabled per client for their specific network deployment. A few engineering specifics worth noting:

• Besu is treated as a legacy (type 0) EVM chain. Transactions use eth_gasPrice based fee resolution rather than EIP 1559, which matches the way most enterprise Besu deployments are configured (free gas or fixed gas price), and avoids fee market assumptions that don't apply on a permissioned network.
• It uses the standard EVM address format.
• Replacement transaction features (speed up, cancel) are intentionally disabled. On a free gas chain there is no fee market to bump against, so these flows would be misleading rather than helpful.
• Besu specific permissioning errors (rejected transactions because the originator is not on the permissioned senders list, or the target contract is not on the permissioned contracts list) are translated into clean DfnsError.forbidden responses, so client applications get a meaningful error code rather than a raw RPC string.
• All of the EVM behavior (signing, broadcasting, nonce management, transaction lifecycle) reuses the existing Dfns EVM stack. Besu inherits the platform, rather than being a parallel integration.

This is a deliberately lean integration. The point is not to reimplement Besu on the Dfns side, it's to make a customer operated Besu network look like any other supported chain from the perspective of the institution's developers and operators.

Limitations to be honest about

Besu is the right tool for a meaningful set of institutional use cases. It is not the right tool for everything. A few things to keep in mind:

• Throughput is bounded by the validator set. Besu's QBFT and IBFT 2.0 consensus modes are well suited to consortium settings but trade off throughput against fault tolerance and decentralization. For very high throughput use cases, institutions typically pair Besu with a more performant settlement layer or with a public L2.
• Privacy is limited. Besu's original private transaction model (Tessera) is being phased out and is no longer recommended for new deployments. Institutions that need transaction privacy beyond network level membership controls usually pair Besu with a privacy layer or evaluate purpose built alternatives such as Canton, Hedera’s Hashsphere or Rayls.
• Operational ownership stays with the client. Bring Your Own Chain means the institution operates the validators, the RPC, the monitoring, and the upgrade cycle. Dfns provides the wallet, key, and orchestration layer on top, but we do not run the chain in this context.
• It's a permissioned chain. Cross chain bridges to public Ethereum, public stablecoins, and public DeFi require explicit design choices. The Dfns platform supports those flows but they are an architectural decision the institution still has to make.

Why this matters

The institutions building the next generation of financial infrastructure want two things at once: full control over their internal execution environment, and a credible bridge to the public chain economy where the liquidity, the stablecoins, and the broader counterparty network actually live. Besu is a practical answer to the first half of that question. Our Besu connector is how you make it work alongside the second half, without running two parallel wallet platforms.

If you are operating or evaluating a Besu network, get in touch and we will help you plug it in. BYOC on Besu is available now to qualifying clients.

Start here: app.dfns.io/get-started
Or contact sales: sales@dfns.co