In the Rayls official website supplier comparison table, there are nine rows, and I chose the one labeled “Privacy.” The reason is simple: privacy is important, and Besu is open source—its documentation and code are both available for me to look up.
In the comparison table, Rayls checks both rows—“Isolated Privacy” and “Cryptographic Privacy”—while Besu only checks the first row. I planned to verify using the other party’s own documentation, so I looked up Besu’s documentation, then pulled down its code and counted it line by line.
The conclusion isn’t “Besu doesn’t work.” The real difference is this: these two companies place privacy at different layers, and Besu moved it away earlier than many people think.
On the Besu side: from documentation to code
In the Besu official documentation, the privacy-related pages at the top now all have the same banner: privacy functionality based on Tessera has been deprecated starting from version 24.12.0.
The real removal happens in 25.6.0. The release notes for this version list it as a breaking change: removing Tessera privacy functionality, item #8369. In the same batch, on-chain permissions management was also removed.
The portion I verified myself is like this. First, use three version numbers to fetch the same files: in 25.4.0, both PrivateTransaction.java and Enclave.java return 200; in 25.6.0 and 26.2.0 they both return 404. Then look at the interfaces: in 25.4.0, the RpcMethod enum contains 23 methods starting with priv_, eea_, or privx_. In the same file in 26.2.0, there are none. The command line is the same: in 25.4.0 there are 12 startup parameters starting with --privacy; in BesuCommand.java for 26.2.0, you can’t even find the word “privacy”. In terms of scale, in 25.4.0 there are 153 non-test Java files related to privacy and enclave, totaling 17,875 lines.
Why is Besu doing this
This section has to be written, otherwise it turns into nitpicking.
In a September 24, 2024 announcement, the Besu maintainers gave the reasons: the codebase has become a bloated Swiss Army knife. Functionality like Tessera isn’t performant enough for the scenarios it was originally meant to address, and the application layer already has mature and emerging solutions. The announcement also mentioned that an open-source, EVM-oriented programmable privacy project is about to be submitted to the LF Decentralized Trust lab.
That project is Paladin. It has already moved from the lab to become a正式 (official) project of LF Decentralized Trust. With an Apache 2.0 license, it implements privacy for token transfers in two ways: zero-knowledge proofs or issuer pre-verification. It runs on any EVM chain.
So, to be precise: Besu hasn’t abandoned privacy—it moved privacy from the client to the application layer.
Two ways of doing it, each with its price
Rayls’ approach is to put privacy into the protocol: Enygma uses AES-256 to encrypt the transaction content, uses Pedersen commitments to record balances, uses Groth16 to prove that the transaction is correct, and follows the normal transaction path.
You can quantify the cost of this path. In the previous post, I tested proof generation: in a single-core environment, a 6-person anonymity set takes 1.96 seconds per proof. Today I measured something else again: the proof itself is only 164 bytes, and it’s the same size for the 2-person and 6-person sets because Groth16 proofs are fixed-length. But the public data that comes along with the proof isn’t fixed-length: 588 bytes for the 2-person set and 1,612 bytes for the 6-person set.
That number also corrects a common claim. It’s not just “one proof” that leaves the private environment—what leaves includes the encrypted payload, the proof, and the necessary public data. The contents remain hidden, while the system can still verify and settle.
By the way, here’s the other row in the comparison table. Rayls checks “isolated privacy,” and it relies on deployment architecture: each institution’s Sovereign ledger is installed within its own boundaries. According to the wording on the website, private data doesn’t leave that instance; only the minimum payload necessary to complete a transaction is sent to the external network. So for Rayls, these two rows are two layers: institutions are separated by deployment isolation, and cross-institution settlement relies on cryptography. I only looked at the website and documents for this; I haven’t actually deployed it.
You also need to lay out the licensing. Rayls’ open stack is Apache 2.0, but the Enygma and Axyl modules are BUSL 1.1: testing is free, production requires authorization. Each version automatically converts to Apache 2.0 four years after release. Paladin is Apache 2.0.
What does this mean for an institution?
If an institution’s private network runs on Besu and it uses the priv_ or eea_ interfaces, then upgrading to 25.6.0 isn’t really an upgrade—it’s a migration. 23 interfaces and 12 startup parameters disappear at the same time. The privacy logic has to be moved to the application layer and rewritten; if you don’t move it, you can only stay on the 25.4 series, and then all subsequent performance improvements and security fixes are not related to you.
If you choose Rayls, privacy and the ledger are part of the same package—versions, auditing, and support are on the same line, so you don’t have to piece it together yourself. The tradeoff is that every confidential transaction must first compute a proof: the larger the anonymity set, the more public data there is, and the Enygma part must be licensed under BUSL.
How much is that “the more”? I can estimate it. Here’s the calculation I did. For a confidential transfer with a 6-person anonymity set, the proof plus public data totals about 1,776 bytes. If you scale it to the size of 210,483 CHAPS transactions per day in the UK for 2025, that’s about 374 MB per day, or about 136 GB per year. For institutional storage this isn’t much, but it’s a fixed overhead that grows linearly with the number of notes/transactions, and the anonymity set is adjustable: if you drop to a 2-person set, each transfer is only 752 bytes. This assumes each transaction produces only one proof, and I didn’t include circuits for depositing, withdrawing, or DvP.
From this line, the only general question you can extract is three words: which layer. Ask the vendor which layer the privacy functionality lives in, who maintains it, what its lifecycle is, and whether the lifecycle and ledger are tied together. Changes in Besu over the past two years show that the answer will change—and that changes can be destructive.
What I confirmed, and what I inferred
Confirmed parts: whether files exist across different versions, the number of interfaces and startup parameters, what the official announcements and release notes say, the byte counts of proofs and public data, and the proof generation time from the previous post. All of these can be rerun using the commands shown in the screenshots.
Inferred part: the upgrade would interrupt existing privacy business, which I inferred from the fact that the interfaces disappear. I didn’t actually upgrade a private network from 25.4 to 25.6 to test it. Whether Paladin can handle a specific scenario for a given institution— I also haven’t evaluated.
In terms of scope, I only looked at the transfer circuit and privacy. Besu’s users can maintain their own fork or write plugins—that’s allowed by its license. I didn’t touch the other eight rows of the comparison table.
My view
The comparison table is a static picture, while open-source project capabilities move over time. In this line, within two years it changed from “built into the client” to “handled by the application layer,” yet the table can only show a single checkmark.
So I’d rather treat tables like this as a starting point for a checklist: go look at the other party’s repository for the current version for each row. The time I spent on this was under an hour, and the commands are all in the screenshots. When Rayls updates this table next time, what’s worth checking is whether they add version notes to the Besu row.
Reference sources: Rayls official website Sovereign product page and the comparison table with suppliers; the deprecation banner in the Besu official documentation privacy section; the Besu 25.6.0 release notes, item #8369; the LF Decentralized Trust September 24, 2024 announcement (Sunsetting Tessera and Simplifying Besu) and the Paladin project announcement; the three tags (as read on September 24, 2026): hyperledger/besu 25.4.0, 25.6.0, 26.2.0; raylsnetwork/rayls-sovereign-gnark-api commit 67c4c26 (tested locally).