GATEWAY
Open source: Gateway contributes the foundation of Open Privacy Suite to LF Decentralized Trust.

Gateway contributes the foundation of Open Privacy Suite to LF Decentralized Trust

The privacy and access-control layer at the heart of Open Privacy Suite is now an open-source lab at LF Decentralized Trust, Permissioned Privacy Control, licensed under Apache 2.0. It gives banks, market infrastructures and the builders who serve them a shared, inspectable privacy foundation for permissioned EVM networks.

Stavanger, 23 October 2026. Financial institutions are moving activity onto shared ledgers faster than at any point in the past decade. In 2026, Swift opened its shared ledger to banks preparing live tokenized-deposit pilots. Seven central banks and more than 40 regulated institutions tested tokenized reserves and deposits together in Project Agorá. Both networks are permissioned, and both put privacy at the center of their design. As the Agorá report puts it, a shared ledger does not require shared data.

That principle raises a practical question for every institution on a shared network: which software decides who sees what, and can it be trusted?

Today Gateway is answering that question in the open. We have contributed the foundation of Open Privacy Suite, our privacy and access-control layer for EVM networks, to LF Decentralized Trust, the Linux Foundation’s home for open-source decentralized technology. The code now lives in a vendor-neutral organization as the Permissioned Privacy Control lab, licensed under Apache 2.0 and open to contributors from across the industry.

What Open Privacy Suite is

Each participant gets a view defined by policy. On a standard EVM network Bank A, Bank B, a supervisor and an auditor all see everything; with Open Privacy Suite each bank sees its own ledger, the supervisor sees more under a mandate and the auditor sees what the engagement covers.
Private by default, transparent by permission. Illustrative.

Regulated finance has always worked on a simple model: private by default, transparent by permission. A bank sees its own ledger. A payment system shows each member its own payments. A supervisor sees more, under a mandate. An auditor sees what the engagement covers.

Standard blockchains invert that model. On a typical EVM network, every participant reading a node sees the same state, including competitors’ balances and clients’ flows. That suits open networks. For a consortium of banks or a market infrastructure, it is often where the project stops.

Open Privacy Suite restores the original model on the EVM stack institutions already run. It does this without new cryptographic assumptions, chain modifications or proprietary formats. Each participant gets a view defined by policy. Operators, supervisors and auditors get a wider view on agreed terms. And every access decision is recorded.

Open Privacy Suite is built as layers that protect each other, so that a weakness in one does not expose the network:

  • Core decides what each caller can read and call.
  • Trail governs who can change those rules, including the authority given to AI agents.
  • Inlay decides what each participant’s own node is allowed to hold.
  • Shield, privacy from the infrastructure operator, is on the roadmap.
Layers and status: Core is contributed and open source at LF Decentralized Trust; Trail is a Gateway product; Inlay is available for pilots; Shield is on the roadmap.
What is open today, and what comes next.

An institution’s own protections, such as encryption, HSMs or trusted execution, sit alongside. Read more about Open Privacy Suite.

What we have contributed

Every request passes identity and policy first: a participant's JSON-RPC request goes through the Permissioned Privacy Control privacy gateway — identity, policy, runtime trace and audit — before reaching an unchanged EVM node.
The privacy gateway works in front of standard EVM nodes, with no changes to the chain.

The contribution is the first version of Open Privacy Suite: the layer every other capability builds on. It sits in front of standard EVM nodes as a privacy gateway, so every JSON-RPC request passes through identity and policy before any data is returned. Multiple organizations can then transact on one chain without seeing each other’s business. In practice, that means:

Access control at the level institutions think in. Organizations own contracts, groups carry permissions, and users belong to groups. Permissions are layered: which JSON-RPC methods a group may call, which contracts it can see and use, and rules down to individual function parameters. For example, a group may call balanceOf, but only for its own address. Cross-organization isolation is the default, and transactions are traced at runtime, so routing a call through an intermediary contract does not get around it. A risk team can read the policy and recognize its own segregation-of-duties model.

Private by default, with explicit, auditable sharing. Each participant sees its own activity in full, sees what others have explicitly shared with it, and nothing else. Hidden activity appears as placeholders or not at all, and counts and volumes are filtered per viewer. Data crosses a privacy boundary only through explicit mechanisms: an organization can share a contract, or single functions of it, with a specific group. A regulator or auditor can request access through a disclosure request that names a reason and legal basis, requires consent, expires automatically, and is released in full, pseudonymized or redacted form. Every access made under it is logged and can be exported as a compliance report.

Identity institutions already use. Participants authenticate with zero-knowledge credentials (Privado ID), with enterprise single sign-on (Microsoft Entra ID), or by linking a wallet. KYC status gates access to protected data, so a network can rely on a verified claim rather than collecting documents itself.

Compliance and evidence built in. Travel Rule checks can be enforced on transfers, sanctions lists can be applied, and contract deployment and upgrades are gated by explicit permissions. Every access decision is written to an append-only, hash-chained audit store, so an operator can prove what was and was not accessed.

Built for the existing stack. It works in front of standard EVM nodes, with no changes to the chain. Teams keep their contracts and tooling. Operators get an admin console, a REST API with a full OpenAPI specification, a command-line tool, and an MCP server that AI coding agents can use to work with the stack. A one-command demo shows two banks and a regulator sharing one chain, with the same query answered differently for each.

Why open source, and why LF Decentralized Trust

Why open source: inspect what you run, no single owner, and a shared foundation.
The privacy layer is the one institutions can’t take on trust.

Of all the software on a financial network, the privacy layer is the one institutions can least afford to take on trust. It sits between every participant and its most sensitive data. That is why we chose an open, vendor-neutral home for it.

  • Institutions can inspect what they run. Security teams, risk committees and regulators can read the full source of the layer that controls their data, under a permissive licence, before anything is deployed.
  • No single company holds the keys to the roadmap, including Gateway. A network built today may run for a decade. With the code governed at LF Decentralized Trust, an institution’s privacy layer does not depend on the commercial future of any one vendor.
  • The industry can converge on a shared foundation. Banks, market infrastructures, consortia and technology providers can build on, and improve, the same privacy layer rather than each solving the problem alone. That makes networks easier to connect and controls easier to compare. Engineers from Consensys, through the Lineth team, are already contributing.

What it enables

  • For banks and financial institutions, a privacy and access-control layer their own teams can audit, which shortens the path from evaluation to approval.
  • For market infrastructures, consortia and central bank programmes, a common way to give each member a private view of a shared ledger, while keeping a defined, logged view for operators and supervisors.
  • For technology providers and integrators, an open base to build services on, without reinventing access control for every network.
  • For regulators, privacy controls they can examine directly rather than infer from a vendor’s description.

How it fits with Gateway

Gateway remains the maintainer of the Permissioned Privacy Control lab, and from today the contributed layer is developed in the LF Decentralized Trust repository, in the open.

Open Privacy Suite continues as Gateway’s product. Further capabilities, including Inlay, are built on this open foundation. Inlay is already available for pilots. The suite is running in pilots with financial market infrastructures and institutional networks in Brazil, Spain and Malaysia.

Open today, with more coming in the open: the contributed foundation is open source under Apache 2.0; the next version of the open layer, with access policies as code, is in development.
Next version scope and timing to be confirmed.

The next version of the open layer is in development. It will make access policies definable as code, so institutions can manage them through infrastructure-as-code and GitOps workflows, and produce the configuration evidence that audits such as SOC 2 Type II, ISO 27001:2022 and PCI-DSS require.

Igor Mandrigin, co-founder and CTPO, Gateway:

“Privacy is the part of a financial network that institutions can least afford to take on trust. Putting the foundation of Open Privacy Suite at LF Decentralized Trust means anyone can read it, run it and improve it, and that it will outlast any single company, including ours. Engineers from Consensys are already contributing. We want many more to join them.”

Pradeep RV Singh, co-founder and CEO, Gateway:

“This is one of the milestones I’m proudest of. Traditional finance has always bought its critical infrastructure as closed, proprietary software. Web3 showed another way: build in the open, and let the people who depend on a system inspect it and improve it. As the two worlds converge, we believe privacy should be built that way too. Much of the privacy technology offered to institutions today is closed. We are opening ours, because a privacy layer the whole industry relies on should be one the whole industry can shape. Contributing it to LF Decentralized Trust is our first step, and we look forward to banks, market infrastructures and builders contributing alongside us.”

Get involved

The Permissioned Privacy Control lab is open to contributors now.

Institutions that want to deploy Open Privacy Suite, or pilot Inlay on their network, can talk to our team.

About Gateway

Gateway is the institutional infrastructure orchestrator for sovereign onchain finance. It combines its platform, specialist partners and an integration team to help banks, market infrastructures and financial institutions bring regulated financial products onchain, under their own rules, brand and jurisdiction. Founded in Norway in 2021, Gateway is a member of LF Decentralized Trust.