Open Privacy Suite: privacy for shared financial infrastructure

Banks, FMIs and consortia are no longer asking whether to build on shared ledgers. Tokenized deposits, shared settlement networks and onchain market infrastructure are moving from pilots toward production. The question that now decides whether a network launches is a different one: who will be able to see what?

On a shared ledger, the default answer is everyone. For a regulated institution, that answer ends the project.

Open Privacy Suite changes the default. Each participant on a shared EVM network gets a view defined by policy. Operators and supervisors get a wider view, on agreed terms. Every access decision is recorded. And it runs on the infrastructure institutions already operate, without betting their data on new cryptography.

This article explains the problem Open Privacy Suite was built for, why we chose not to solve it with new cryptography, and how its modules combine with each other, and with an institution's own protection, into layers that cross-protect. It then turns to where it applies and what it changes for the business.

Private by default

Traditional finance is private by default and transparent by permission. A bank's ledger is visible to the bank. A payment system shows each member its own payments. A supervisor sees more, under a legal mandate. An auditor sees what the engagement covers. Nobody designed this as a privacy feature. It is simply how regulated finance works.

Public blockchains inverted that model: transparent by default, private by exception. That suits open networks, and it is the main reason banks, clearing houses and market operators have kept their core activity off them.

Shared institutional networks change the economics, not the obligations. A consortium of banks settling tokenized deposits, or a clearing house running a shared ledger for its members, still owes every client confidentiality. Each member still treats its positions and flows as commercially sensitive. Supervisors still expect access that is mandated, scoped and recorded, not unlimited.

So before tokenization, interoperability or settlement speed, every institutional network has to answer one question: can it reproduce private-by-default on a shared ledger? If it cannot, nothing else gets the chance to matter.

What breaks on a shared ledger

On a standard EVM network, every participant reading from a node reads the same state. That is the point of a public chain. On a network shared by banks, a clearing house and a supervisor, it is the reason the project stops.

The failure shows up in four places, and the first is the one that ends most projects.

Every participant reads every record. Client balances, positions and payment flows become visible to every other member, including direct competitors. That is a breach of client confidentiality on day one, and a gift of market information to everyone else on the network.

Oversight is all or nothing. The operator, the supervisor and the auditor each need a different, defined view. A standard node offers one view: everything. There is no way to grant a supervisor scoped access, let it expire, and prove afterwards what was seen.

The infrastructure keeps a full copy. Hiding data on a screen does not change what the node stores. Whoever runs a participant's node, whether the participant itself or a hosting provider, holds the whole network's data.

Nobody owns the permissions. Who approved a new member's access, and when did it take effect? On most networks the answer lives in a configuration file and an engineer's memory. That does not survive an audit.

The usual workarounds each give something essential away. A private chain per institution removes the point of a shared network. A privacy-native platform means new contracts, new tools and a new security review, and usually a new cryptographic assumption.

A different route

Instead of a separate chain per institution or a new cryptographic platform, it reproduces the control model regulated finance already trusts (identity, least privilege, segregation, approvals and evidence) on the EVM infrastructure institutions already run.

That was a deliberate choice. The industry's usual answer to privacy is cryptographic. Fully homomorphic encryption computes on data that stays encrypted. Zero-knowledge systems prove facts without revealing them. Newer schemes promise privacy enforced by mathematics rather than by anyone's policy. The appeal is real: in principle, nobody has to be trusted.

For institutions, the trade-off looks different. Many of these schemes publish or distribute data in encrypted form, so its protection lasts only as long as the mathematics holds. Financial records stay sensitive, and often must be retained, for many years. Most of these assumptions are young by that standard. Each new scheme also brings new contracts, new tooling and a new security review before anything can go live.

When Igor Mandrigin, Gateway's co-founder and CTPO, started designing Open Privacy Suite about a year ago, he set a constraint that looked conservative at the time: the core privacy mechanism must not depend on new cryptography.

Igor Mandrigin, Co-founder and CTPO of Gateway:

“Novel cryptographic solutions can't be the sole protector of those funds. About a year ago, when we were designing [Open Privacy Suite], we focused on addressing that. We don't include any advanced cryptography. The main privacy mechanisms and schemas must not be cryptography-based.”

Three design choices follow from that constraint:

• Protect by not delivering. Data a participant is not entitled to is never returned to it and, with Inlay, never stored on its infrastructure. What never leaves the source cannot be decrypted later.
• Name the trust boundary. Each edition states plainly what it still trusts, and the next edition moves that boundary further. No layer claims more than it does.
• Compose, don't replace. Open Privacy Suite sits alongside an institution's identity provider, SIEM and network security, and alongside other privacy technologies where they fit.

This is also why the zero-knowledge proofs the suite supports sit at the identity layer. They let a holder prove a claim such as "KYC passed" without handing over the document behind it. They reduce what is stored; they are not what keeps participant data private. And if a proof system were ever broken, a forged claim would still only unlock what the matching role is permitted to see, while Inlay would still keep everything else off that participant's node. That is the Swiss cheese model applied to identity.

Why it matters now

A debate in the Ethereum community this month put that design choice in a new light. On 7 October 2026, Ethereum Foundation researcher Justin Drake wrote on X: "Today I call upon the blockchain industry to calmly begin planning for 'bunker mode'." His concern is that AI-accelerated mathematics could break the signatures protecting most wallets before quantum computers do. Later the same day, Ethereum co-founder Vitalik Buterin wrote on X that the lattice cryptography often proposed as quantum-safe could also take serious hits, and urged the industry to minimise exposure to "not just quantum-vulnerable cryptography, but also potentially AI-vulnerable cryptography".

Quoted from public posts; their inclusion does not imply endorsement of Gateway or Open Privacy Suite.

Neither claims a break has happened. The point is the horizon. Encrypted data can be collected today and decrypted whenever the mathematics gives way, and institutional records stay valuable for years. Igor’s response was:

Igor Mandrigin, Co-founder and CTPO of Gateway:

“While we were designing [Open Privacy Suite], and the design might feel simplistic, those particular risks were top of mind for me even one year ago. It was pretty obvious there is a risk with all new cryptography, and harvesting attacks against any ciphertext, on chain and off chain too. So we tried to solve the problem of privacy in a way that doesn't introduce anything new, and accept the limitations of that.”

Open Privacy Suite was designed a year earlier to avoid that bet. What a participant is not entitled to is not ciphertext waiting to be broken. It is simply never sent.

Layers that cross-protect

Safety engineering learned long ago that no single safeguard is perfect. In aviation and healthcare, serious failures rarely come from one broken control. They happen when the gaps in several controls line up. The response, known as the Swiss cheese model, is to stack independent layers so that each one covers holes the others leave open.

Open Privacy Suite applies that idea through composition. Its modules are designed to be combined with each other, and with protection an institution already has or chooses to add. As Igor puts it:

Igor Mandrigin, Co-founder and CTPO of Gateway:

“In practice, when using the Open Privacy Suite, you can compose the built-in modules (e.g. use both RBAC and Inlay nodes) as well as 3rd party solutions with it, to cross-protect your data.”

Layer	Status	What it protects on its own
Core	🟢 Live	What each caller can read and call. Identity is checked, every call is inspected, every decision is logged.
Trail	🟢 Live	Who can change the rules, including an agent's authority. Changes are proposed, reviewed and approved before they take effect.
Inlay	🟡 Pilot	What each participant's node can hold. Withheld state never arrives.
Shield	⚪ Roadmap	Privacy from the infrastructure operator, added to the stack when it is ready.
Third-party layers	Yours	Whatever the institution adds: encryption, hardware-based protection such as HSMs or trusted execution environments, or other privacy tooling.

The value is in how the layers fail. Access control can fail if a policy is written too broadly, but Inlay still keeps withheld state off the participant's node. A cryptographic layer can fail if its mathematics gives way, but access control and data isolation still keep withheld data from ever being delivered. Because each layer rests on a different assumption, a break in one does not line up with a break in the next.

That is the practical answer to the risk Drake and Vitalik describe. Not a stronger cipher, but a stack that does not depend on any single one.

Each attempt slips through some holes and is stopped by a layer that fails in a different way. Shield, shown dashed, is a future module in the stack. The last attempt gets past every Open Privacy Suite module and is stopped by a third-party layer, which is the cross-protection Igor describes.

The four editions

Each edition can be adopted on its own, and in sequence as a network's trust requirements grow. Throughout, applications keep speaking standard JSON-RPC, and wallets, contracts and developer tools such as MetaMask, Foundry, Hardhat, ethers.js and viem keep working.

Core (live): one network, a defined view for each participant

Core puts identity and policy on the path every request takes to the node. Before a response goes back, Open Privacy Suite checks who is calling, which contract and function they are calling, and with what arguments. It then allows the call, denies it, or returns a redacted view. If anything is missing, it fails closed.

In practice, that means:

• Participant separation. Tenants, groups and users are organised in one place. Each group is granted specific contracts and functions, down to a single function parameter, so a participant sees the flows that belong to it.
• Per-transaction visibility. The same transaction can be fully visible to one participant and shown as restricted to another.
• Identity without storing documents. Institutions bring their own identity: Microsoft Entra ID for single sign-on, or did:iden3 / Privado ID, where a holder presents a zero-knowledge proof of a claim such as "KYC passed" or "not sanctioned". Open Privacy Suite verifies the claim and binds a session and role. The passport or utility bill behind it never reaches the node.
• Scoped, expiring disclosure. Auditors and reviewers receive access to defined records for a defined period. When the period ends, so does the access.
• Accountable access. Every decision is recorded in a tamper-evident log that can be exported to an institution's SIEM.

Core's boundary is clear and honest: the infrastructure holding the source data is still trusted. Core decides what leaves the node, not what the node holds. For many networks, especially where the operator is a regulated FMI that participants already trust, that is exactly the right boundary.

Trail: every permission change has an owner and an approval

Trail governs how access rules change. In a shared network, the permissions themselves are a control. Changing who can see a contract is as sensitive as the data behind it, so it should go through the same discipline as any other change to a regulated system.

With Trail, a policy change is proposed, reviewed and approved before the new version becomes active. Each step is attributed to a person, and the full history can be followed from proposal to approval. That gives control teams something they rarely get from a blockchain network: a change-management record they can show an auditor.

Trail also brings the same discipline to AI agents. As institutions start to let agents initiate payments or operate workflows, the question is no longer only what a user can do. It is what an agent is allowed to do, on whose behalf, and until when. Trail's agent controls connect each agent to an owner and an identity, to the actions it is permitted to take, to an expiry, and to evidence of each decision it made.

The business value is straightforward:

• Audits get faster, because the question "who approved this access?" has a recorded answer.
• Four-eyes control applies to the network itself, not only to the applications on top of it.
• Agents can be introduced under defined authority, rather than with broad, permanent credentials.

Inlay: withheld data never arrives

Inlay moves the privacy boundary from what a participant can see to what its infrastructure is allowed to hold. Each participant's RPC node receives only the state disclosed to it. Everything else never reaches the machine.

This is the edition that changes the conversation with institutions. Filtering a response protects the screen. Inlay protects the server. If a node never receives a competitor's balance, then the participant running it, the cloud provider hosting it, and anyone with access to its database cannot read that balance either. It is also the clearest answer to "harvest now, decrypt later": withheld state is not stored anywhere on the participant's side, encrypted or otherwise, so there is nothing there to collect.

How it works, in short:

• The bank keeps the sequencer and the full source state.
• Open Privacy Suite applies the disclosure policy and decides which state each recipient receives.
• Each Inlay node receives canonical block headers, its disclosed state, and witness hashes standing in for the parts it may not see.
• The node verifies its slice against the same canonical root as everyone else, without re-executing transactions.
• Existing tools query the node with standard JSON-RPC. A call into state the node does not hold fails closed, with no fallback to a remote node.

The result is one canonical chain with different local state for each participant. An auditor's node can hold only the approved transfers. Gateway's explorer, and unmodified Blockscout, run on these nodes with databases containing only disclosed state.

Inlay is available for pilots today, with Reth, Besu and Lineth for block production and Reth for participant nodes.

Shield: privacy from the operator itself (roadmap)

Shield is the direction Open Privacy Suite is heading next: privacy from the infrastructure operator. It is a future module in the stack. Core decides what participants can see. Trail governs who can change that. Inlay decides what participants' infrastructure holds. Shield addresses the party that still holds a full view: whoever runs the source infrastructure.

That boundary matters most where participants do not want to rely on any single operator's discretion: networks spanning several jurisdictions, consortia where the operator is also a market participant, and infrastructure run by a third-party provider rather than by the institutions themselves.

Shield is not available today, and this article does not describe how it will be built. We will publish its design when it is ready. What matters now is the direction: each Open Privacy Suite edition is a step an institution can take on its own, and each moves the boundary further without asking anyone to rebuild what came before.

Privacy-aware block explorer

Open Privacy Suite offers a privacy-aware block explorer as well. It matters more than it sounds. Explorers are where operations teams, support staff and auditors actually look at a network, and on a standard network they show everything.

With this explorer, two people signed in can open the same transaction: one sees the sender, recipient and amount, the other sees "Transaction Restricted". The explorer keeps no chain data of its own, and every read carries the caller's identity. Auditors get a workspace for their disclosed records and grant expiry, and operators can check exactly what a participant sees in a read-only "view as user" session.

It is also a full block explorer in its own right. Gateway already runs it for customers on networks that need no privacy at all, and it is built for high-load chains: in a recent proof of concept it indexed a chain running close to 3,000 transactions per second, in real time.

Under the hood

Open Privacy Suite sits on the JSON-RPC path between an institution's applications and its EVM node. Nothing about the application or the contracts changes; what changes is that every request is checked before the node answers.

A request takes four steps through Open Privacy Suite:

• Identity. The caller is authenticated through the institution's identity provider: Microsoft Entra ID, did:iden3 credentials verified as zero-knowledge claims, or the institution's existing identity provider over OIDC. It binds the session to a principal, a tenant and a set of claims. Legacy and developer tools that cannot carry identity use a JWT-injector sidecar.
• Policy. The suite evaluates the caller's roles and grants: which contracts, which functions, and which parameters this principal may use. Rules can live in the suite's own store or in an on-chain contract that an indexer reads, so an institution can manage access rules on chain.
• Inspection. The call itself is traced and checked, down to the function and its arguments, before it reaches the node.
• Response. The suite allows the call, denies it, or returns a redacted view. If anything is missing or unclear, it fails closed.

Every decision is written to a tamper-evident log that can be exported to the institution's SIEM. A read-only "view as user" session lets operators confirm exactly what a participant sees.

Inlay extends this path to the participant's own node, which receives only its disclosed state plus witness hashes and verifies it against the canonical root (see the Inlay section above).

Open Privacy Suite runs in the institution's cloud or on premises, around Hyperledger Besu, CDK-Erigon or Reth, on Ethereum or an enterprise L2.

Who it's for

Open Privacy Suite was built for the organisations that have to make one piece of infrastructure work for many institutions at once.

FMIs, clearing houses and settlement consortia are the clearest case. Each member must see its own flows. The operator needs an auditable view across the network. Supervisors need a defined, approved path to the data rather than a standing back door. That is the pattern in settlement networks where each bank sees only its own payments, in post-trade platforms with pre-agreed supervisory disclosure, and in market infrastructure that grants regulators temporary, logged access. Most start with Core, add Trail to govern membership and permissions, and add Inlay where members run their own nodes.

Infrastructure providers running nodes and networks for regulated clients face a quieter version of the same problem: clients have to trust them with everything those nodes hold. Inlay removes that requirement. A provider can operate a participant's node without ever holding the data that participant is not entitled to, which makes outsourcing acceptable to the client's risk and compliance teams.

Banks and teams building specific financial applications need privacy designed into the workflow rather than added afterwards:

• Tokenized deposits. Issuance controls, identity checks and time-boxed disclosure, with the bank's core remaining the final authority.
• Confidential institutional workflows. Transfers and positions visible only to the parties involved.
• Governed AI agents. Agents that initiate payments or run workflows within an owner, a scope and an expiry, with every decision recorded.
• Disclosure and oversight. Control teams and authorised reviewers with their own workspace, showing what was disclosed, to whom and until when.

Business impact

Privacy is usually discussed as a technical feature. For institutions, it decides whether a shared network can launch at all.

More participants can join. Institutions that would never share a ledger with competitors can join one where their flows stay their own. For a consortium or FMI, the size of the network is the value of the network.

Approval cycles shorten. Legal, compliance and security teams review a known model: identity from the institution's own provider, permissions defined per participant, every access decision recorded. They are not asked to approve a new platform and a new set of tools at the same time.

Existing investment is kept. Contracts, wallets, developer tools and EVM clients stay in place. Teams do not re-learn their stack, and the institution does not take on migration risk to gain privacy.

Oversight becomes a feature, not an exception. Supervisors and auditors get a defined, expiring, logged path to the data they need. Regulatory access stops being a special arrangement negotiated for each request.

Outsourcing becomes possible. With Inlay, an institution can let a provider run participant infrastructure without giving that provider its data. That opens up operating models that confidentiality rules would otherwise block.

Less data is held in fewer places. With zero-knowledge identity claims, the network verifies that a requirement is met without storing the documents behind it. Less sensitive data held means less to protect, and less exposure if something goes wrong.

Already running with institutions

Open Privacy Suite is running today in proofs of concept and pilots with market operators and settlement consortia, with delivery in Brazil, Spain and Malaysia. Customer names stay confidential, but the work is documented, and each case study shows a different side of the same problem:

• Market infrastructure (proof of concept). Nine requirements, from identity and participant separation to keeping existing contracts and granting regulators temporary access. Read the case study
• Settlement consortium (pilot). Each institution sees only its own flows, while the operator keeps an auditable view across the network. Read the case study
• Post-trade oversight (pilot). Participant views stay private, with a defined path for approved supervisory disclosure. Read the case study
• Tokenized deposits (working demonstration). Identity, issuance controls and time-boxed disclosure, shown against a simulated bank estate. Read the case study

Open Privacy Suite is also open source under Apache 2.0, so a security team can read exactly what it would deploy before anything goes live. Every deployment follows the same staged path: proof of concept or DevNet, then testnet, then mainnet.

Define who can see what

A shared network and confidentiality are not a trade-off. The real decision is where your trust boundary sits, and which layers you need to hold it: participant access with Core, governed change with Trail, isolated state with Inlay, operator privacy with Shield as it arrives, and the protection you already run alongside them.

The quickest way to judge Open Privacy Suite is to test that boundary yourself. Run an authorised call and a denied call under two identities. Inspect a permission change and its audit record. Look at what an Inlay node actually stores.