A private EVM is an Ethereum-compatible chain that is not the public Ethereum network: same bytecode, same Solidity contracts, same developer tooling, but run by an institution or a small group of them with the public excluded from reading it by default. Banks want this specifically so they can reuse a decade of audited smart-contract patterns and ordinary developer hiring without broadcasting every trade to competitors. That part is simple.
What sent me looking is a specific fact: the software Rayls' own Private Network Hub runs on, Hyperledger Besu, already ships a built-in way to do exactly this. Rayls builds something else instead. I wanted to know why.
Besu already has a privacy feature
Besu calls it private transactions, and the mechanism is specific. A sender's node passes the transaction to a paired Tessera node which encrypts it and distributes it point-to-point to the Tessera nodes of everyone else in the deal. Only a privacy marker transaction, a hash pointing at that off-chain exchange goes onto the actual cha$in. Besu's own documentation describes the result as two parallel systems: "the private transaction distributed to involved participants, and the privacy marker transaction (PMT) included on the public blockchain."
This is privacy by segregation: the content simply never reaches anyone outside the deal. It is the same category Rayls' own marketing materials, in earlier reporting on this platform, use to describe competing products.
Here is where it gets specific and dated.
The feature is being retired
Besu's own current documentation states it in nearly identical language across five separate pages: "Tessera-based privacy is deprecated in Besu version 24.12.0 and later." A standing warning, not a roadmap note repeated on the privacy overview, the private-transactions page, the processing page, the privacy-groups page, and the plugin page.
That deprecation traces to a specific, named announcement. The Besu Maintainers published it on 24 September 2024, titled "Sunsetting Tessera and Simplifying Besu," and gave a direct reason: Tessera is "not performant enough for their intended use cases." The same post pointed to the replacement path, app-layer privacy solutions built outside Besu's base client, as robust and performant enough that Besu no longer needed to maintain its own version.
Besu's own release notes record the feature's actual removal in version 25.6.0, released 4 June 2025, under the changelog line "Remove Tessera Privacy feature." Checked against independent release trackers, that is roughly eight months from announcement to removal, and almost exactly eight years and eight months after Quorum, Tessera's conceptual ancestor, first shipped. Current Besu releases have removed Tessera-based privacy entirely, past the point of mere discouragement.
There is a second older constraint worth knowing, because it bears directly on Rayls' own history. Besu's documentation has long warned against running private transactions in production on a consensus mechanism where forks occur, naming proof-of-work and Clique specifically, and labeled the combination an early-access feature as far back as Besu v1.4. Rayls' own Sovereign ledger ran on exactly that consensus, Clique, before its migration to Axyl in 2026. Had Rayls wanted Besu's native privacy on its old stack, Besu's own documentation would have told it not to run that combination in production.
Even setting the deprecation and the Clique warning aside, the architecture itself does not fit a growing institutional network well. Besu's privacy groups are fixed at creation. Its documentation is blunt about it: "Once created, you cannot change the members of a privacy group." Adding one commercial bank to an existing group means forming an entirely new group, and migrating whatever state the old one held.
Why banks wanted this category of product at all
The need predates Rayls by nearly a decade. J.P. Morgan unveiled Quorum in October 2016, a modified Go Ethereum client built to sit between fully private and fully public for derivatives and payments, according to Fortune's contemporary reporting. The design swapped private data for cryptographic hashes on a shared chain with one JPMorgan engineer describing the result at the time as "a clear separation between private and public." That is the same two-word problem a private EVM has always existed to solve: shared infrastructure, excluded public.
ConsenSys acquired Quorum from J.P. Morgan in August 2020, folding its development into what became ConsenSys Quorum, offered through two clients: GoQuorum and, increasingly, Besu itself. Tessera-based privacy is the direct descendant of that original 2016 design, the industry's first widely adopted answer to how a bank gets privacy on an EVM chain.
What Rayls built instead
Rayls' Enygma framework does not move private data off-chain at all. It keeps the data on the Hub, encrypted and wrapped in zero-knowledge proofs, verifiable by anyone who can read the chain without being readable by them. A Private Network Operator recovers institutions' view keys, encrypted to it during registration, and can read every transfer; participants hold separate spend keys that can authorise value movement but were never built to decrypt anyone else's. Adding a new institution means registering a new view key, not rebuilding a group.
I checked Rayls' own Hub, key-management, and Enygma documentation, specifically the pages describing the Besu-based Private Network Hub, for any mention of Tessera, privacy groups, or a privacy marker transaction, the vocabulary of the software that Hub actually runs. None of the pages reviewed use any of those terms. That absence sits across documentation that would be a natural place to mention it if Rayls were layering its privacy on top of Besu's native feature rather than replacing it, suggestive of building something separate, though an absence like this stops short of conclusive proof.
Rayls' public hackathon-starter repository also loaded directly, giving one more place to check. It documents the separate Reth-based Privacy Node layer rather than the Besu-based Hub, so it neither confirms nor rules out Tessera use at the Hub specifically. It's evidence about a different part of the stack.
There is also a measured cost to the feature Rayls appears to have skipped. An independent academic test of a live Besu-and-Tessera deployment, published on arXiv in 2025, recorded private contract deployment latency averaging above 5 seconds, with individual private function calls ranging from roughly 1 to over 6 seconds, attributed specifically to the encryption, off-chain payload distribution, and consensus coordination Tessera adds on top of ordinary Besu processing. That's measured, independent evidence that segregation-based privacy carries its own overhead, separate from and in addition to whatever overhead a cryptographic approach adds.
The question, and what the evidence actually supports
If Besu already has a built-in way to make transactions private, why would anyone running on Besu need a second, separate privacy layer?
Three separate facts, taken together, point the same direction. Besu's own maintainers announced the feature's retirement in September 2024 and finished removing it by June 2025, citing performance in their own words. Besu's own documentation discouraged the one consensus mechanism, Clique, that Rayls' own ledger ran on for most of its history. And the feature's static, re-creatable-only privacy groups were a structural mismatch for a network that Rayls' own documentation describes being built up one newly admitted institution at a time. Each of those three is a specific, dated mismatch between what Besu's native tool offered and what Rayls' own documented growth pattern needs.
Why this distinction matters in practice
An institution evaluating "do we need Rayls, or can we just run Besu with Tessera" is really asking two different questions that happen to share a vendor, and the second one has an answer with an expiration date on it. Besu's segregation model trusted node operators to keep data off the public record entirely and asked nothing more exotic of a developer than ordinary Ethereum tooling, exactly what Quorum promised banks in 2016, but that specific implementation no longer ships in a current Besu release.
Rayls' cryptographic model trusts math rather than operator discipline, lets a network grow by registering individual keys instead of rebuilding fixed groups, and runs on software whose maintainers completed the removal traced above eight months after announcing it.
This is a specific, dated answer to a specific question. Besu's own documentation is what actually explains why a chain running Besu would need something Besu does not fully offer anymore.