If you search for “Besu privacy” today, most of what comes up is a Tessera tutorial. Privacy groups, privacy marker transactions, a Tessera sidecar per node, the Q2T port. Some of those guides were updated in 2026.
The problem is that this feature no longer exists in Besu. The maintainers announced its retirement in September 2024 and deprecated it in version 24.12.0. By the end of 2025, it was removed, along with the EEA and PRIV RPC methods apps used to call it.
The timeline below shows how Besu has changed over the last two years.
So the question is worth answering again from scratch. What does privacy on a Besu network look like now? We split it into two parts. First, what Besu does on its own. Second, what you add on top, and how the add-ons differ from each other.
What Does Bank-Grade Privacy Mean on a Besu Network?
Bank-grade privacy means each party sees what its role requires and nothing beyond that, while supervisors can get access when they need it.
Let’s see who this “everyone” is.
Besu handles the first three rows well. The bottom three are where the add-ons come in.
The operator row is an important one. The IMF, in its notes, says, that permissioned systems are often designed so one entity can observe everything, which leaves every other participant trusting that entity not to misuse its position or get compromised (page 7, IMF Note, June 2026). A permissioned network can still have this problem. Most of Part 2 is about fixing it.
Part 1. What Privacy Does Besu Give You by Default?
In one sentence, Besu controls who gets in and what each participant can do. It does not control what an admitted member can read on the ledger.
If an institution uses these configurations very well, it will provide the privacy required at the network level, and that’s a reason Besu is ‘THE’ go-to stack for close to a third of enterprise blockchains.
Network isolation
A private Besu network runs with its own chain ID and uses QBFT or IBFT 2.0 consensus. If you’re not sure how they are different or which live networks today use which consensus, we have a detailed article on it. Give it a read here.
Now let’s get back to our discussion.
So because of this network isolation, nothing is published to a public chain. Each bank decides where its nodes physically sit, which helps settle data residency concerns many countries have for compliance.
Node allowlisting restricts which peers can connect. You can also use –net-restrict to limit peers to approved IP subnets and turn discovery off completely.
Account permissioning
Account permissioning lets the network enforce onboarding and identity requirements, suspend an account, and restrict what an account is allowed to do. There used to be three ways to do this. The Smart-contract-based (onchain) permissioning was removed in the same release as Tessera. Hence, local permissioning and the permissioning plugin are what we have today.
Local account permissioning restricts which accounts can submit transactions. The node checks its allowlist when a transaction is submitted, again when it comes in from a peer, and again when the block-producing node adds it to a block.
The permissioning plugin is the more interesting option for banks. It lets you write rules for connections, transactions, and messages in code. Something like blocking transfers over a threshold from accounts that haven’t finished enhanced due diligence, that kind of rule can live right in the client.
Message control before confirmation
Message permissioning lets a node decide which peers get which messages, and it can be used to stop pending transactions from being forwarded to every peer in the network. Here’s one hypothetical example. Assume a dealer does not want their order flow to be visible early to every network member; this feature can be useful there. But once the transaction is in the block, it will be visible to every node, though.
Here’s a simplified table to digest everything we discussed on permissioning so far.
RPC access
RPC is how people and systems actually read the ledger.
Besu supports JWT authentication with per-user method permissions. It uses JSON Web Tokens. Each user gets a list of methods they’re allowed to call, and that list can be really narrow. For example, there could be just one allowed method like eth_blockNumber. If the list is empty, there is no access. The bank’s own identity provider can issue the tokens through JWT public key authentication.
Then TLS with client authentication on top of that, so only clients with a trusted certificate (or listed by fingerprint in a known-clients file) can connect at all.
One limit we need to mention here, though. Besu’s permissions work per method, not per account or contract. A user allowed to call eth_getBalance can check any address on the network, and eth_getLogs returns events from every contract. Scoping what each institution can see is a job for the application layer, which we cover in Part 2.
Validators and keys
Validators hold a full copy of the ledger, so deciding who becomes one decides who can read everything on it. In QBFT, at least two-thirds of validators must sign each block, and new validators are voted in by existing ones or managed through a smart contract. So, either way, there’s an on-chain record of who approved whom.
Now, when it comes to keys, validator keys can be kept in a hardware security module. The Besu HSM plugin supports PKCS#11 devices and AWS CloudHSM. Hence, the key stays inside the hardware and signing happens there. So this is the same custody standard as the bank’s other signing keys.
What’s missing
Every node that holds the ledger can read every transaction on it. Permissioning decides who joins and who can transact. It says nothing about what a member reads once inside.
Besu used to have private transactions built in, through Tessera. It was removed in 25.6.0. Some people read that as Besu backing away from privacy. We don’t really see it that way. The Besu client still has everything it’s good at, like consensus, execution, and access. Privacy is something that moved out to tools that can change faster and dynamically, as per clients’ needs.
Our part2 focuses on this approach.
Part 2. What Can You Add to Besu for Confidentiality Between Members?
We split the add-ons into two groups. We asked a simple question to create the categories.
Does it sit on the Besu chain you already run, or does it put Besu inside a different system?
Let’s understand them now.
2a. Infrastructure-level (modular) privacy on your existing Besu chain
Here, Besu stays as it is. Privacy is added in layers. In Part 1, what we covered is network-level privacy that Besu offers by default. But as blockchain itself follows a layered architecture, the risk vectors also arise from different layers. Hence, network-level privacy is not enough.
Application layer
Most everyday exposure on a bank network comes from this layer alone. Most stakeholders don’t read raw blocks from blockchain ledgers. They use RPC calls, explorers, and indexers to get the desired data.
Tegaris is an approved LF Decentralized Trust Lab for this layer. The Lab calls it an application-layer privacy and policy control plane for shared EVM networks. It sits at the interfaces where applications meet the network, so Besu underneath doesn’t change at all.
Tegaris treats permission to perform an operation and permission to see what came out of it as two separate things, and applies policy to RPC methods, contract functions, state reads, receipts, and events. Why does it matter in a consortium? For example, an ops analyst at Bank A can push a transfer to Bank B and still not get any view of Bank B’s balances. That’s hard to do with the RPC permissions we discussed in part 1.
Users and workloads get bound to a participant. So every person or system using the network is registered as belonging to one bank. Tegaris always knows “this login is from Bank A,” so it only lets them see Bank A’s data. Delegation is bounded so Bank A can give a vendor or a team limited access, but only within limits it sets. Revocation is there, so Bank A can take that access back at any time.
Policy change is controlled too. When a bank wants to change a rule, Tegaris makes it go through these steps:
- Someone writes the change.
- It’s tested in a simulator first.
- A different person reviews it.
- It gets approved.
- It’s published as a locked, signed version.
Then Tegaris checks that the new rule is actually running on every node. If the rule was approved but one node is still running the old one, Tegaris shows that mismatch.
Every time Tegaris allows or blocks something, it records which rule made that decision. An auditor can later see why someone was allowed or blocked. Signing keys stay with the bank, so Tegaris never holds the keys that approve transactions. The bank or its custodian keeps them.
Asset and ledger layer:
After the application layer is covered, there are still asset and ledger layer privacy issues that need their own solutions.
Why does asset-layer privacy matter? On a plain Besu network, every bank that runs a node holds a full copy of the ledger. That copy shows every wallet address, amount, and balance, along with the full transaction history. A competing bank that studies this for a few months can work out who another bank’s main counterparties are and how it moves its cash.
The solution is using Private Tokens, also called ZK tokens. With a normal token, anyone on the network can read each account’s balance. With a Private Token, the real details are kept off the ledger. The ledger only stores a sealed fingerprint of each one. That fingerprint proves the value exists, but no one can read the amount or the owner from it. But supervisors can still be given access with selective disclosure.
Ledger-layer privacy is different. It limits who sees a contract’s inputs, execution, and final state. It’s not only asset transfers that get recorded on the blockchain. A blockchain doesn’t only record asset transfers. Right? Transfers may be only a small part of a bank’s on-chain activity. The rest is contracts running business workflows, for example, approvals, requests for transferring assets, etc. Privacy is a prerequisite there too. The Zeeve privacy suite offers a few ways to handle this. These include private sub-ledgers, private L1 domains, ZK rollups, bilateral workflows, and privacy-scoped smart-contract execution. The right choice, or mix, depends on the use case.
2b. Besu inside a ZK system
In this group, Besu becomes the execution engine inside a larger stack that produces zero-knowledge proofs.
Start with a correction we make often. A validity proof shows that a batch was executed correctly. It does not encrypt the batch. Where these systems give privacy, it comes from where the data is kept and who can access it.
i) Lineth
Lineth is the ZK rollup stack behind Linea Mainnet, which has been in production since 2023. They open-sourced their stack with LF Decentralized Trust in May 2026. The Lineth execution layer is still Besu with L2-specific plugins, such as the sequencer and tracer that add ZK-rollup functionality.
Linea Besu is required for sequencer nodes and trace generation, while other nodes can run any Ethereum execution client. And for institutions, the private option is a permissioned setup for a closed group in a validium configuration. A validium keeps transaction data off Ethereum. That is different from a rollup, which publishes it.
The benefit is verifiability. Members, auditors or regulators can confirm the ledger is correct without trusting the operator. The trade-off is more infrastructure, proving costs, and a dependency on Ethereum. The proof also hides very little. Because the operator still sees every transaction, so privacy between member banks needs the other layers.
ii) Prividium on Besu
Prividium is ZKsync’s private chain for banks. It doesn’t run on Besu. It’s a replacement for it. But it starts with your current Besu implementation.
Matter Labs offers banks already on Besu a slow way to switch. First, Prividium runs next to the Besu network and adds permission controls. Besu keeps working as before. Then the bank moves its important workloads onto Prividium, where they get ZK proofs on Ethereum. In the end, most or all of the bank’s activity runs on Prividium instead of Besu.
So Prividium on Besu is really a migration path off Besu. The upside is no big-bang switch. The downsides are a new stack, a commercial license, and the same limit as any validium.
So, in Lineth, Besu is the engine. Besu runs every transaction, and Lineth adds proofs around it. In Prividium, Besu is not the engine.
Which Privacy Option Fits Which Bank Use Case?
Zeeve for Bank-Grade Privacy on Your Besu Network
Besu gives banks a strong, governed base. Privacy is built in layers on top of it, and getting each layer right in production is the hard part.
Zeeve is a Certified Solution Provider for Besu, with a growing team of certified Besu engineers. Our engineers contribute to Besu and are working toward maintainer status. That means we can customize the protocol, tune performance, and add engineers to a bank’s own Besu team where needed.
We support on-premises deployment and run production networks with 24/7 support, on SOC 2 Type II and ISO 27001-compliant infrastructure and processes. For banks moving off older chains, we handle chain migration. For banks that need to connect to other networks, we build interoperability using IBC. We also work with LF Decentralized Trust on privacy and interoperability, and the Zeeve privacy suite adds asset- and ledger-layer privacy to the Besu network you already run.
Let’s take a first step today. Schedule a call with our Besu experts to discuss your requirements.
