Moving off Tessera private transactions after Besu 25.6

Why moving off Tessera private transactions after Besu 25.6 is a design decision, not an upgrade

If your permissioned network relied on Tessera privacy groups and the EEA and PRIV API groups, Besu no longer gives you a supported path to keep those workflows as they were. Besu 25.6.0 removed the Tessera privacy feature and onchain permissioning, and Besu 25.7.0 removed the EEA and PRIV privacy RPC API groups. The upgrade is therefore not a version bump: every application, script and operator runbook that called those methods or relied on Tessera-managed privacy groups needs an explicit decision about what replaces it.

You have two realistic options. The first is to stay on releases that still contain Tessera and the removed APIs, accepting that you will not receive the feature work, fixes or security changes that later releases carry, and that you must manage the older client's compatibility with JDK and host operating system changes yourself. The second is to re-platform private workflows, for example onto Paladin privacy domains, which means redesigning how transactions are submitted, how private state is stored and how consortium members agree on who sees what. Confirm with your Besu and Tessera contacts how long your current release line will remain usable in your environment before you commit to either path.

The effort depends less on the Besu node itself and more on the private workflows you have built around it. Inventory every privacy group, every application that uses privacy-specific RPC calls, and every onchain permissioning rule that you will need to recreate with local allowlists or a plugin. Ask any implementation partner for a written scope that covers those inventory results, the data migration or re-keying plan, and the test evidence that private transactions remain confidential between members. The Besu release notes on GitHub are the place to check which removals affect your current version.

Which Tessera privacy capabilities map to Paladin and which do not

This table compares the Tessera privacy features Besu used to provide with what Paladin privacy domains offer and what Besu still exposes. Read the rows marked as not mapping cleanly first, because they decide whether application code, stored private state or identifiers need redesign rather than a configuration change.

Capability	Tessera on Besu (before removal)	Paladin privacy domains and remaining Besu behavior
Privacy group identifiers	Tessera privacy group IDs were referenced by clients when sending private transactions and reading private state	Paladin uses its own domain and identifier model, so group IDs will not carry over directly. Confirm the identifier mapping and any translation step with the Paladin project and in a test network.
Private transaction submission	Clients sent private transactions through the EEA and PRIV API groups, which Besu 25.7.0 removed	No EEA or PRIV methods remain in Besu. Application code must be rewritten against Paladin's interfaces. Confirm the exact submission and receipt calls in the current Paladin documentation.
Stored private state	Private state lived in Tessera-managed storage alongside each Besu node	Migration of existing private state is not a documented in-place path. Confirm with the vendor whether any export, replay or re-deployment is needed and whether history is retained.
Client code calling removed methods	Wallets, middleware and scripts calling eea_ or priv_ methods worked on Besu releases before the removal	Calls to removed methods fail on current Besu releases. Inventory every caller and test it against the target release before any upgrade.
Node-level privacy configuration	Nodes ran a Tessera process with its own keys and configuration file	Tessera is no longer part of Besu. Paladin runs its own node components, so key handling and transport settings must be re-planned. Confirm the deployment model in your environment.
Node permissioning and account rules	Local node permissions and account permissions remain documented in Besu, and onchain permissioning was removed in 25.6.0	Local permissioning files still apply to Besu nodes and accounts and do not depend on Tessera. Confirm that consortium-wide rules match what Paladin domains enforce for private data.
JSON-RPC access controls	Besu JSON-RPC authentication supports a credentials file or JWTs validated against a public key	These controls continue to apply to the public Besu RPC surface. Confirm whether Paladin endpoints use the same authentication model and how they are exposed.

Staying on older Besu releases or re-platforming on Paladin

Keeping an older Besu release in service preserves the network as it works today. The chain, the Tessera-backed privacy groups and the EEA and PRIV calls that your applications use remain in place, so no code or data has to move in the short term. The trade-off is that the feature set freezes at the point you stop upgrading, and every dependency beneath it ages with it.

Preserved behavior: Privacy group flows, onchain permissioning rules and EEA and PRIV API calls keep working on releases that still include them. Tessera and onchain permissioning were removed in 25.6.0, and the EEA and PRIV groups were removed in 25.7.0, so confirm the exact boundary in the release notes before you choose a version.
Unpatched exposure: Maintainers do not carry fixes for removed features forward in the current codebase. Ask who will track security advisories for the pinned release and whether any fix would have to be backported by your team.
Dependency drift: Older releases were built against older JDK versions, and Tessera is no longer part of the Besu codebase. Your team owns the operation of those components for as long as the network runs.
Support boundary: Get written confirmation from your support provider of what they will support on a frozen release, and for how long.

Before choosing this path, check which release each node runs, which privacy and permissioning features the network depends on, and who owns security patching for every component on that release.

Documented export and import paths for private transaction data

Besu's documentation and release notes cover reading chain data from nodes and extending the client through plugins, while Paladin documents its own privacy domains. Together these define what is supported today, and no documented one-step converter moves Tessera private state into Paladin.

No documented one-step converter

No documented one-step converter moves Tessera private state into Paladin. Tessera payloads, privacy group membership and the private state they produced are not carried over by any Besu release or Paladin tool that the supplied sources describe. Treat any migration as a designed data project, and confirm with each vendor whether they offer an export or import option before you plan around one.

Reading chain data from nodes

Public chain state and the transactions that were executed remain readable through standard Besu node interfaces, so the public ledger history can be read and recorded independently of Tessera. Private payloads that Tessera stored outside the chain are a separate matter. Check which data your old nodes still hold locally and whether your retention plan covers it before any upgrade removes the old privacy features.

Besu plugin framework

Besu has a modular plugin framework, and the maintainers suggest plugins or community forks for teams that still need removed features. A plugin can be a route to keep an extraction or reporting function running, but it is custom code that your team owns. Ask whether the plugin will be maintained against each new calendar release and who signs off on it.

Community forks for removed features

A community fork that keeps Tessera or the EEA and PRIV API groups is an option only if it is actively maintained and builds on the JDK version your release requires. Forks diverge from upstream security fixes, so each fork adds a patch and review cost on every upgrade. Confirm the fork's maintenance status, license and support terms in writing before you put production data behind it.

Paladin privacy domains

Paladin documents privacy domains as its model for keeping transactions private between consortium members. Moving a workflow means redesigning it around domain membership, data ownership and the contracts involved, rather than replaying old private transactions. Read the Paladin documentation for its privacy domain model and confirm that it supports your production requirements and export needs.

Export questions to confirm

Before you commit to a path, ask each vendor and your integrator the same questions: which private state can be exported, in what format, whether it can be imported into a new privacy model, and who verifies completeness. Record the answers in the written scope so the migration plan does not rely on undocumented behavior.

What the data and integration work covers

The first piece of work is an inventory, and it has to cover more than the chain. Start with the private transaction payloads that Tessera held off-chain, because once Besu no longer runs Tessera those payloads are not reachable through the node. For each privacy group, record its membership, the participants who hold the group's payloads, and which of them still need to read historical data. Then list every client application that calls the EEA or PRIV method groups, since Besu 25.7.0 removed those APIs and each caller will fail after the upgrade. Include wallets, back-office services, reporting jobs and any internal scripts that were written against them. Confirm with each participant where their Tessera storage lives and whether it is backed up, because that storage, not the chain, holds the data you may need to keep.

The authentication work sits at the JSON-RPC boundary, and it is where most integration teams will need to change code and infrastructure. Besu supports either a username and password credentials file or JWTs validated against a public key, using RS256, RS384, RS512, ES256, ES384 or ES512. Decide which model each calling application will use, then plan how credentials or key material are issued, rotated and revoked. Besu does not terminate HTTPS natively, so the TLS design is yours: choose a reverse proxy or gateway, define certificate issuance and renewal, and decide whether the proxy or Besu validates the JWT. Document which RPC methods are exposed through the proxy and which stay on a private interface, since the proxy becomes the control point for access to the node.

How the migration runs from inventory to decommission

The sequence moves privacy workflows from Tessera to Paladin in controlled stages, so each stage produces evidence that the next one can rely on before any old component is removed. Each step has a named output that gates the move to the following step.

Inventory privacy groups and dependent applications
List every Tessera privacy group, its members, the private contracts and transactions it carries, and each application or service that calls the EEA or PRIV RPC API groups. Record which node versions and Besu releases each network runs, and which applications read private state. Assign an owner for each dependency. The step is done when the team can show a complete table of privacy groups, callers and owners, reviewed by every consortium member who holds a node.
Take a verified backup before any upgrade
Before changing any Besu version, back up each node's data directory and keys, and store the copies outside the node's host. The 26.10.0 release notes state that the Bonsai database upgrades automatically on first start and that older Besu versions cannot open an upgraded database, so this backup is the only documented rollback path. Restore a backup on a separate host to confirm it opens with the intended release. The step is done when each node has a tested restore record and the team has signed off on the rollback plan.
Stand up a pilot Paladin privacy domain
Deploy a Paladin privacy domain on a small, non-production subset of the consortium, using one representative business flow copied from the inventory. Define the members, the contracts and the key handling for that domain in writing. Confirm that the pilot can transact privately between the intended parties and that non-members cannot read the data. The step is done when the pilot runs the chosen flow end to end and the results are documented for the consortium's security and compliance reviewers.
Run both paths in parallel
Send the same business flows through the existing Tessera privacy groups and the Paladin pilot for an agreed observation period. Compare outcomes at each step, including final state, error handling, access control and the records kept for audit. Investigate every mismatch before continuing, and keep Tessera operating so the old path stays available. The step is done when the team has a reconciliation report showing agreed outputs for the full set of flows and no open discrepancies.
Cut over applications to Paladin
Switch each dependent application from the EEA or PRIV calls to Paladin interfaces, one application at a time, with a rollback step defined for each switch. Freeze new activity on the Tessera groups for the cutover window, move in-flight business records as agreed, and confirm the consortium members have the new access settings. The step is done when every application in the inventory reads and writes through Paladin and the cutover log is signed by the application and business owners.
Decommission Tessera and the removed API groups
Stop the Tessera services, remove the privacy configuration from Besu node settings, and confirm that no client still calls the EEA or PRIV API groups, which Besu 25.7.0 removed. Retain the archived Tessera data and the backups under the retention rules your organization has agreed. Update the runbooks, monitoring and access reviews to remove references to Tessera. The step is done when logs show no calls to the removed groups over an agreed period and the decommission record is filed with the network documentation.

What makes the Tessera exit cost more or less

This table lists the factors that raise or lower the effort of leaving Tessera privacy groups, and separates one-time project work from recurring operating work. Read each row against your own network to see which drivers apply, then use the quote questions to compare written scopes. No figures are given here, because effort depends on your environment.

Driver or cost	What increases it	What reduces it or how it recurs
Number of privacy groups	Many groups with long histories, overlapping membership or payloads that must be reconciled before cutover	Few active groups, with inactive groups archived and documented before design starts
Client applications calling removed APIs	Custom applications or middleware that call the EEA or PRIV privacy RPC groups in several code paths	A single integration layer that already isolates privacy calls, so one change point replaces many
Volume and retention of private payloads	Large private payload stores, long legal retention periods and payloads that must be readable after migration	Clear retention rules agreed early, so only data that must move is migrated and the rest is archived under policy
Consortium members who must agree	Many organizations with separate legal reviews, differing privacy models and separate change windows	A single agreed privacy model and governance charter signed before design, with named decision owners
HSM and key handling	Node keys or transaction signing keys held in several places, or HSM-backed keys that need re-enrollment for a new stack	Documented key inventory and a plan that reuses existing key custody without new key ceremonies
Number of release steps	Staying on older releases for a long period, forcing several intermediate upgrades on a database that cannot roll back	Planning a single target release path with a backup taken before each database upgrade
One-time work	Privacy design, application rework, test environments, data migration and cutover rehearsal	Reusing existing test harnesses and limiting migration to the data the business still needs
Recurring work	Tracking Besu releases, running two stacks during parallel run and keeping patches on unsupported older releases	Ending the parallel run on a fixed date and retiring the old stack once acceptance tests pass

Where re-platforming private workflows usually goes wrong

Moving private transactions off Tessera touches data, keys, people and release management at once. The risks below are the ones that most often turn a planned cutover into an incident, and each one has a prevention step you can assign before work starts.

Privacy leakage during parallel run

While old Tessera-based flows and new Paladin domains run side by side, the same business data can be sent through both paths. Map every private payload to exactly one channel and confirm which participants can see each one. Test with synthetic transactions first, and review node logs and metrics for unintended payload exposure before any live data moves.

Members out of step on cutover

A consortium rarely changes all its nodes at once. If one member still expects EEA or PRIV calls while another has moved on, transactions fail or are silently routed wrong. Agree a cutover date, a rollback owner and a shared runbook in writing with every participant, and record which release each node runs before the switch.

Losing access to historical private data

Private transaction history held under Tessera does not automatically become readable through a new privacy model. Before decommissioning anything, export and verify the records you must keep, and confirm with your auditors and legal team how long they must remain retrievable. Keep the old infrastructure read-only until that is settled.

Unpatched older releases kept in production

Staying on a release that predates the removals is a deliberate choice with a growing maintenance cost, since Besu ships roughly monthly and later releases carry fixes. Document which release each node runs, who owns security patches for it, and the date you will stop running it. Confirm the current release line with the project before setting that date.

Keys and node identities mishandled

Re-platforming often means new node identities, new account keys or new permissioning entries. Besu documents that the local node private key file is not encrypted, so copying key files between hosts during a migration widens exposure. Generate new keys inside your key management process, store them in an HSM or approved vault where possible, and retire old identities explicitly so they cannot be reused.

Removed API calls left in client code

Applications, scripts and monitoring jobs may still call the EEA and PRIV RPC groups that Besu removed in 25.7.0. These calls fail only when the code path runs, which can be days after a release. Search every client repository and integration for EEA and PRIV method names before upgrading, and add a test that exercises each private transaction path against a staging node.

Questions buyers ask before moving off Tessera

How much effort does moving off Tessera private transactions take?

Effort depends mainly on how many private workflows rely on Tessera privacy groups and how many applications call the EEA or PRIV RPC groups that Besu removed in 25.7.0. The main drivers are the number of privacy groups, the number of applications and middleware that submit private transactions, how much business logic assumes Tessera behavior, and how many environments need to be rebuilt and tested. Cost has two parts: your internal engineering time, which is one-time for the migration but recurs as ongoing operation, and any external work you contract. Ask any partner for a written inventory of workflows and integrations before accepting a quote, because the inventory sets the scope.

How long does a Tessera to Paladin migration take?

The supplied sources do not give a duration for this move, so treat any timeline as unverified until it is written into a scope. Timing usually follows the number of privacy workflows, the number of applications to change, the amount of testing needed for each workflow, and the cutover approach you choose. Plan around Besu's release cadence as well. The GitHub releases page lists 26.7.0 (July 13, 2026), 26.8.0 (August 19, 2026), 26.9.0 (September 25, 2026) and 26.10.0 (October 16, 2026), so the move may cross one or more upgrades. Ask for milestones tied to workflows and environments, not a single end date.

What does the migration need from our internal team?

The work needs named people who can decide on business behavior and people who can change and operate the infrastructure. Expect to provide:

A business owner for each private workflow who can confirm which parties must see which data and how long records must be kept.
Application owners who can change how their systems submit and read private transactions.
Node and network operators who can schedule restarts, manage validator changes and approve cutover windows.
Security owners for key handling, access control and any hardware-backed key storage.
Test environments that match production closely enough to prove the new flow before go-live.

Can our own engineers move private workflows without a partner?

Your team can do this in-house if it already operates Besu nodes, understands JSON-RPC changes, can build and run the Besu release required by your upgrade plan (26.6.0 requires JDK 25), and has someone who can own the privacy design. The deciding factors are skills and capacity, not only tooling. Check whether engineers have run a privacy migration before, whether they can test every privacy workflow end to end, and whether they can keep up with monthly Besu releases while the migration is in progress. A fixed-scope partner engagement can cover parts of the work, such as the inventory, design, build, testing or documentation, and it can be paired with your own operations team.

Is staying on an older Besu release safe after 25.6?

Staying on an older release can keep existing privacy workflows running for a period, but it moves the risk to your team. The maintainers have announced the sunsetting of Tessera privacy and onchain permissioning, so you should expect no roadmap for those features. You will be responsible for patches, dependency changes and compatibility with your infrastructure, including the JDK version newer releases require. Plan the exit before a forced upgrade. Keep in mind that Besu 26.10.0 auto-upgrades the Bonsai database on first start, and older versions cannot open an upgraded database, so take a verified backup before any upgrade. Confirm the support status of your version on the Besu releases page.

Which applications break first when Tessera privacy is removed?

The first breakages usually appear in applications and middleware that call the removed EEA or PRIV RPC groups, that depend on Tessera-specific privacy group identifiers, or that read private state through paths that no longer exist. Check every client library, wallet service, backend and monitoring job that talks to the node. Also review scripts, runbooks and batch jobs, because they often fail silently. Build a list of RPC methods used by each application from logs or code, and test each one against the release you plan to run. Ask your team or any partner to produce this list before scheduling cutover.

What happens to historical private transactions during the move?

Historical private data is the hardest part of the move, and the decision belongs to your data owners, legal and compliance teams, not only to engineers. Decide first which records must be kept, for how long, and who may read them. Options include keeping a read-only archive of the old Tessera-held payloads, rebuilding current state in the new privacy model, or documenting a defined cutoff. Before you decommission Tessera, confirm where payloads are stored, whether they can be exported in a usable form and how to verify the export. Record every decision so auditors can trace how private data was handled.

How DeployOpen scopes and delivers a Besu private workflow migration

DeployOpen approaches a move off Tessera private transactions as a fixed-scope engagement that starts with an inventory of what your network actually depends on. We plan, build, test and document the replacement inside infrastructure you control, then hand it over with runbooks your team can operate. Ongoing support is available as a retainer once the work is live.

How we scope

Inventory every privacy group, private transaction flow and EEA or PRIV API call your applications use today.
Map each workflow to a target design, with the Besu releases and any Paladin privacy components agreed in writing.
Agree deliverables, acceptance tests and timelines in a written scope before any build work starts.

How we build

Stand up a non-production replica of the current network and reproduce the private workflows on it first.
Rebuild permissioning, key handling and node configuration using the local permissioning and key management options your network supports.
Test data-isolation rules, failure cases and upgrade steps, and confirm the results with your security and compliance owners.

How we hand over

Document the target architecture, configuration files, data-migration steps and the rollback path, including a backup taken before any database upgrade.
Run operator training sessions and walk your team through monitoring dashboards, alerts and day-two procedures.
Provide a cutover checklist and a closeout review listing open risks and the items your team must confirm with vendors.

How we support

Offer ongoing support, upgrade planning and continuous testing as a retainer after go-live.
Track each Besu calendar release against your deployment and prepare upgrade plans before your nodes fall behind.
Review the private workflow design whenever your consortium adds members, changes rules or changes the data it shares.