GATEWAY
Sign inDiscuss your architecture
K7Open Privacy SuiteApache 2.0

Shared infrastructure.
Controlled visibility.

Operate shared financial systems with defined access, governed permissions, and authorised disclosure.

Built with banks and financial institutions. RBAC, privacy, and compliance controls on the EVM tooling you already run.

Book a demoDiscuss a pilot

Dave’s mask reveals permitted fields in the underlying ledger.

  • balance: Dave, 100 GUSD
  • balance: redacted
  • transfer: To Dave, +40 GUSD
  • transfer: redacted
Dave’s mask reveals his balance and transfer. Snoopy’s records stay redacted.
V4What OPS enables

Share the system.
Define the access.

  1. Separate participant information

    Let institutions share a system while keeping access to records, transactions, and contract functions specific to each participant.

    Participant privacy

  2. Govern changes to access

    Define who can change a permission. Trail adds a review-and-approval workflow before a policy version becomes active.

    Policy governance

  3. Limit distributed data

    With Inlay, give participant RPC nodes their authorised state instead of the full network dataset.

    Selective state delivery

  4. Support authorised review

    Give auditors scoped, expiring disclosure and a verifiable record of access decisions and RBAC changes.

    Disclosure & oversight

  5. Give agents defined authority

    Trail’s agent controls connect an owner and identity to permitted actions, expiry, and decision evidence.

    Governed agent workflows
D5One suite / Four editions

Choose your
privacy boundary.

Start with participant access. Add policy governance, then extend privacy to the state held by participant infrastructure. Your applications keep speaking standard JSON-RPC.

  1. 01Identity / owner
  2. 02Policy evaluation
  3. 03Permitted action or disclosure
  4. 04Decision evidence
Live

Control participant access.

Evaluate the caller, contract, function, and arguments before returning a permitted view. The infrastructure holding source data remains trusted.

Participant boundary
Each participant sees the records its policy permits.
Infrastructure trust
Source-data infrastructure remains trusted.
Explore Core
Your infrastructureShared node
Open Privacy SuiteFilters every response
ReadsParticipant A
ReadsParticipant B
Q2In pilot with institutions

Piloted with financial institutions today.

OPS is running in proofs of concept and pilots with market operators and settlement consortia. Customer identities remain confidential.

Delivery locations: Brazil, Spain, and Malaysia. Developing markets: Saudi Arabia and other European countries.
01Proof of concept

Market infrastructure

Nine requirements: identity, participant separation, existing contracts, and temporary regulator access.

Read the case study 02Pilot

Settlement consortium

Each institution sees its own flows. The operator retains an auditable view across the network.

Read the case study 03Pilot

Post-trade oversight

Private participant views with a defined path for approved supervisory disclosure.

Read the case study 04Working demonstration

Tokenized deposits

Identity, issuance controls, and time-boxed disclosure demonstrated with a simulated bank estate.

Read the case study
R3Applications

Where OPS fits.

Explore the controls behind shared financial infrastructure, confidential workflows, agents, and oversight.

One network. A defined view for each institution.

Separate participant information, govern membership and permissions, and decide what state each participant’s infrastructure receives.

Explore the deployment architecture
OPS administration with two tenants, and Tenant A’s node receiving only its delivered slice of state.
Each participant’s view follows its own access policy.
N613 features / 3 groups

Features

Define who can read, what they can do, and what their node can hold.

Included with OPS

Privacy-aware block explorer

The same chain. A view shaped by your identity.

Dave’s viewSnoopy’s view
Dave sees the transaction details; Snoopy sees Transaction Restricted.
Explore the included explorer
Identity & access / Participant privacy

One network. A different view for each participant.

Organise tenants, users, and groups. Set the contracts and functions each group can access, so participants see the flows that belong to them.

Also in the suite

Wallet linking MCP administration

See it in a demo
E6Identity

Prove the attribute.
Don’t store the file.

Identity stays outside the platform boundary. You bring Microsoft Entra ID or did:iden3.

ISSUERDOCUMENTS STAY HERENODEBOUNDARYOPEN PRIVACY SUITEPROOF OFADDRESSDRIVING LICENCEPASSPORTZK PROOF · CLAIMS✓ KYC passed✓ Not sanctioned✓ Over 18+ any claim you add

The issuer did the KYC. We verify the claim.

“A zero-knowledge proof can tell a counterparty ‘Yes, this person meets your requirement’ without that counterparty knowing your name, income, or address.”

Hester M. Peirce, SEC Commissioner, remarks at SIFMA’s Digital Assets Conference, 23 September 2026. Her views are her own; no endorsement implied.

Microsoft Entra ID

Single sign-on for banks that already run on Azure.

did:iden3 / Privado ID

The holder presents a zero-knowledge proof of a claim: age, residency, KYC passed, not sanctioned. Open Privacy Suite verifies the proof and binds a session and role. The passport, licence or utility bill behind it never reaches the node.

Extendable by claim

Accredited investor, jurisdiction, account ownership: add a claim type and the same flow verifies it. You extend what can be proven, never what is stored.

L3How it works

The life of
an RPC request.

Identity, policy, and disclosure sit around your existing EVM infrastructure. Your applications keep speaking standard JSON-RPC.

01 / Your applicationsExisting interfaces
Wallets & dApps
Business systems
Admin console
Block explorer
↓ JSON-RPC + identityFiltered view ↑
02 / Policy enforcement

Open Privacy Suite

Fail closed
  1. 01IdentityPrincipal, tenant & claims
  2. 02PolicyRoles, contracts & grants
  3. 03InspectionTrace & call checks
  4. 04ResponseAllow, deny or redact
Tenant · group · userEvery decision recorded
↓ Validated JSON-RPCNode response ↑
03 / Native executionYour EVM clientExisting contracts & runtime
Chain stateHeld by the execution node
One governed request path

Legacy and developer tools can use the JWT-injector sidecar to supply identity on standard JSON-RPC calls.

F9Included with Open Privacy Suite

Privacy-aware block explorer

Explore the same chain through each participant’s permissions.

DDaveAuthorised participantVisible
SSnoopySigned in · outside this disclosureRestricted

Same transaction, different views. Dave sees 750 GUSD and its details. Snoopy sees Transaction Restricted.

Actual product capture
Privacy mode

Every read carries the caller’s identity.
The explorer keeps no chain data of its own.

ViewerOPSPermitted view
01

Visibility you can read

Address labels explain why a record is visible. Per-caller reads keep one viewer’s data out of another viewer’s page.

02

A workspace for auditors

Review disclosed addresses, grant expiry, and access activity. Pseudonymous grants keep the underlying address out of the browser.

Explore disclosure & expiry
03

Review as a participant

Operators can inspect a user’s view in a read-only session with a persistent banner. A hardened build removes write surfaces entirely.

Explore view as user

Also available as a standard block explorer

Use the full explorer toolset when a privacy-filtered deployment isn’t required.

  • Etherscan-compatible contract verification
  • Contract read & write
  • Live updates & analytics
  • Gas tracker & charts
  • Public API
  • White-label & multiple networks
J4Privacy from RPC operators Pilot available

Inlay

Give each participant a node that holds only the state disclosed to it.

Bank-controlled source
Sequencer + OPS policy

Full state stays with the bank.

Inlay RPCParticipant AIts disclosed slice
Inlay RPCParticipant BIts disclosed slice
Inlay RPCAuditorApproved disclosures
See it on the node

Withheld state
never arrives.

The recipient’s own operator cannot read plaintext that its node never receives. Each node verifies its slice against the canonical root.

Inlay pilot / walkthrough00:45
Tenant A and Tenant B follow the same chain, while each node retains a different state slice.
01 / Verify

The same canonical root

Witness hashes stand in for hidden subtrees. Nodes verify imported state without re-executing transactions.

02 / Query

Standard JSON-RPC

Existing tools query the tenant node directly. Calls into missing state fail closed, with no remote fallback.

03 / Explore

Keep your explorer

Gateway’s explorer and unmodified Blockscout run on tenant nodes whose databases contain only disclosed state.

Across EVM clients
Reth · Besu · Lineth Block productionReth Tenant nodes
S8Deployment architecture

Where the
state lives.

The bank keeps the sequencer and the source state. Each participant’s Inlay RPC node receives only the state it is allowed to hold.

Inlay / Privacy from RPC operatorsOne canonical chain. Different local state.
Bank-controlled infrastructureFull source state stays here

Bank sequencer

Executes transactions. Holds the source.

100 GUSD50 GUSD40 GUSD15 GUSD
Open Privacy Suite

Disclosure policy

The bank decides which state each recipient receives.

↓Canonical headers + disclosed state + witness hashes
Inlay RPC node01
Participant ADave’s disclosed state
Retained state
  • Dave · balance100 GUSD
  • Witness hash only
  • Transfer to Dave40 GUSD
  • Witness hash only
Same canonical root, verified
Standard JSON-RPC No remote fallback
Inlay RPC node02
Participant BSnoopy’s disclosed state
Retained state
  • Witness hash only
  • Snoopy · balance50 GUSD
  • Witness hash only
  • Transfer to Snoopy15 GUSD
Same canonical root, verified
Standard JSON-RPC No remote fallback
Inlay RPC node03
AuditorApproved transfers only
Retained state
  • Witness hash only
  • Witness hash only
  • Transfer to Dave40 GUSD
  • Transfer to Snoopy15 GUSD
Same canonical root, verified
Standard JSON-RPC No remote fallback
Disclosed state is retainedWithheld plaintext never reaches the nodeIllustrative GUSD ledger
Operators can’t read state their nodes never receive.

Inlay verifies imported state against the canonical root using witness hashes for hidden subtrees, without re-executing transactions.

Standard JSON-RPCYour cloud or on-premisesNeed privacy from node operators? Explore Inlay
W7Built to fit your stack

Modular deployment

Connect your policies, identities, and tools around one governed request path.

01 / Rules on-chain

Develop your rules on-chain.

Store access rules in an on-chain contract instead of Postgres. An indexer reads the contract so the Core RBAC module can enforce your rules.

  1. On-chain contractAccess rules
  2. IndexerReads contract rules
  3. Core RBACEnforces access
Flexible rule storage, with enforcement in Core.
02 / Bring-your-own identity

Start with identities you already know.

Use did:iden3 or Microsoft Entra ID out of the box, or connect your existing identity provider. OPS carries the authenticated identity into each governed request.

  1. Identity providerdid:iden3 · Entra ID
  2. OPSIdentity-bound session
  3. CallerAuthenticated access
Your identity provider remains the source of identity.
03 / Existing tooling

Fit privacy into your existing stack.

Wallets, applications, and contracts keep their interfaces. OPS enforces access on the JSON-RPC request path.

  • MetaMask
  • Foundry
  • Hardhat
  • ethers.js
  • viem
  1. Your toolsWallets & developer tools
  2. OPSStandard JSON-RPC
  3. EVM nodeExisting contracts
Familiar tools, with a governed path to your node.
C3Infrastructure

Deployment

Choose your EVM environment.
OPS fits around the client you run.

Execution layer

EVM clients

  • Hyperledger Besu
  • CDK-Erigon
  • Reth

Enforce access around the node’s JSON-RPC interface.

Network layer

Your network

  • Ethereum
  • Enterprise L2

Use the same identity and policy model across EVM environments.

P8Deployment & integration

Fit your
operating environment.

On your infrastructure or as part of a Gateway deployment.

Your environment

Cloud, on-premises, or hybrid.

Your systems

did:iden3, Microsoft Entra ID, and standard JSON-RPC.

Your operating model

Monitoring, support, and recovery agreed up front.

A staged path to production.

  1. 01

    PoC / DevNet

  2. 02

    Testnet

  3. 03

    Mainnet

H6Show the evidence

Test the boundary.
Inspect the result.

Build an evaluation around your participants, supported methods, and deployment. Start with the demonstrations already on this page.

01

Participant separation

Run an authorised call and a denied call under distinct identities. Compare the same transaction in two explorer views.

Identity A → allowedIdentity B → denied
Watch access enforcement
02

Permissions & governed change

Inspect a permission change and its audit record. For Trail, scope the proposal, approval, and policy activation workflow.

Change → access recordTrail → approval flow
Inspect the audit evidence
03

Infrastructure boundary

Inspect the state retained by each Inlay node. Verify witness hashes, local reads, and the components that retain full source data.

Disclosed state → retainedWithheld state → witness hash
Watch the Inlay pilot

Bring a workflow and the access rules it needs. We’ll define what to demonstrate and how to assess it.

Plan an evaluation
Z5Discuss your architecture

Define who can see what.

Bring your participants, workflows, and infrastructure requirements. We’ll identify the OPS edition, integrations, and configuration for your deployment.

Discuss OPSRequest a custom solution