# Practical privacy for institutional EVM networks

By Igor Mandrigin · 2026-09-05 · https://255c.org/practical-privacy/

Confidentiality and auditability have to coexist in institutional onchain systems. Choosing an architecture starts with three decisions: whose access to restrict, what another party must verify, and which information must cross the boundary between institutions.

This is a written companion by [Igor Mandrigin](/about/), published September 5, 2026. It develops the privacy and interoperability thread behind [Practical Privacy at DAppCon, June 16, 2026](https://www.youtube.com/watch?v=5xiuSqab1fY), and the [LF Decentralized Trust workshop, March 18, 2026](https://www.lfdecentralizedtrust.org/learn/webinars/lfdt-webinar-with-gateway.fm-practical-approaches-to-interoperable-blockchain-privacy). The [DAppCon programme](https://vibes.dappcon.io/?view=events) lists the session as “Practical Approaches to Interoperable Blockchain Privacy.”

## Define the property before choosing the technology

Four terms describe different jobs:

- **Confidentiality:** keep specified information from specified observers. “Private from other participants” and “private from the infrastructure operator” are different requirements.
- **Selective disclosure:** release a defined part of that information to a particular recipient under stated conditions.
- **Auditability:** preserve enough evidence for a reviewer to establish what happened and which controls applied.
- **Interoperability:** move value, instructions, or proofs between systems without requiring every participant to use the same environment.

My [doors and roads frame](/notes/private-doors-interoperable-roads/) connects these properties. Doors define access to a room. Roads let the rooms participate in a market. Neither tells us, on its own, who holds the keys or what a traveller reveals when leaving.

## Work through one transfer

Consider a hypothetical transfer between two institutions. The sender needs a record of its instruction. The recipient needs to reconcile the payment. Other participants should not receive the underlying customer information. An appointed reviewer may need access to selected evidence later.

Before comparing products, write down the intended views:

| Participant | Information needed for this example | Boundary to test |
|---|---|---|
| Sender | Its instruction, transfer result, and reconciliation reference | Its credentials do not expose another institution’s records |
| Recipient | The transfer details needed to credit and reconcile it | Receipt of one transfer does not reveal the sender’s unrelated positions |
| Unrelated participant | Whatever shared state the protocol requires it to verify | Shared verification does not silently reveal customer-level records |
| Appointed reviewer | The records and control evidence covered by the review | A disclosure grant has a defined scope and duration |

This is a design example. The institution must decide the actual disclosure rules and evidence requirements for its workflow.

Now add the infrastructure. A sequencer, validator, prover, RPC operator, or key custodian may see data that no application user can request. That produces a second access map: the people and systems that can read the underlying state, memory, keys, or logs. I am developing that map in [Privacy from operators](/notes/privacy-from-operators/).

The reader map describes the desired product. The operator map describes the trust placed in its operation. An architecture needs both.

## Place the control where it can enforce the rule

A policy layer at the JSON-RPC interface can fit an existing application stack. JSON-RPC is the request-and-response interface used to query and interact with an Ethereum-compatible node. Keeping that interface can reduce the integration changes needed for a controlled view.

At Gateway.fm, [Open Privacy Suite](https://gateway.fm/open-privacy-suite/) applies identity, role, and purpose to supported RPC requests. Its configured RPC and explorer surfaces can return a permitted value, a consistent pseudonym, or a redaction. Disclosure grants and access decisions can produce audit evidence. Coverage depends on the client, methods, and deployment configuration.

That boundary has a precise limit: raw-node access, infrastructure administrators, and connected systems need separate controls. Filtering one response does not remove another route to the data. The [product’s enforcement-boundary notes](https://gateway.fm/open-privacy-suite/) make this distinction explicit.

For public Ethereum, data published in plaintext remains available to other readers of the ledger. A private endpoint cannot make that public record confidential. Ethereum’s [privacy overview](https://ethereum.org/privacy/ethereum) explains the exposure from public state and transaction metadata.

## Match the architecture to the observer

These approaches can be combined. They solve different parts of the problem.

| Approach | Where it helps | What still needs an answer |
|---|---|---|
| Permissioned network with controlled application reads | Restrict participation and give authenticated users different views | Which node operators and administrators retain access to the underlying data? |
| Cryptographic private state and proofs | Let a verifier check a defined statement while hiding its private inputs | Who generates the proof, who sees its inputs, and what do public outputs or metadata reveal? |
| A dedicated institutional network connected to other networks | Give the institution control over its operating environment | How do counterparties verify settlement and exchange assets without joining that environment? |

The distinction between a verifier and a prover matters. A zero-knowledge proof can hide private inputs from the verifier; it does not establish that the service generating the proof never received those inputs. Public inputs, emitted events, submission paths, and application logs also need review. Ethereum’s [guide to building privacy applications](https://ethereum.org/latest/privacy-apps-on-ethereum/) describes these surrounding sources of disclosure.

My architectural conclusion is to select the privacy mechanism against the observer it must exclude. A requirement to hide positions from another application user does not automatically require the same machinery as a requirement to hide them from the execution operator.

## Separate a validity proof from an audit record

A proof that a transaction followed a rule answers a particular question. An audit may ask additional questions: which identity authorised the instruction, which policy version applied, who received a disclosure, and whether access was later revoked.

For the transfer example, a useful evidence design would connect the instruction, its authorisation, the settlement result, and any subsequent disclosure. The reviewer’s access to that evidence is itself part of the privacy design.

Keep the claims narrow. A record that a proxy denied a request establishes what happened at that proxy. It cannot establish that an administrator did not read a database through another path. A time-limited grant stops later authorised access; it cannot recall a copy already delivered to its recipient.

Those limits decide where operational controls, cryptography, and evidence must work together.

## Follow the information across the road

Interoperability adds another observer. A bridge, messaging service, counterparty network, or reconciliation system may receive information protected inside the original environment.

Return to the transfer. Write down what leaves the sender’s boundary: an instruction, an asset identifier, an amount, a recipient, a proof, or some smaller statement. Then identify who receives each item, who can verify it, and what happens if the destination cannot complete the operation.

Using the same RPC format on both sides does not answer these settlement and disclosure questions. Interface compatibility helps applications connect. The cross-network protocol still has to define the meaning and validity of the result.

That is the practical test of the [institutional privacy thesis](/institutional-privacy/): preserve the private room while making the road usable. A design review should leave behind a map of readers, a map of data leaving each boundary, the statements counterparties can verify, and the evidence an authorised reviewer can obtain.

The recordings are in the [talks archive](/talks/). The next unresolved boundary is [privacy from operators](/notes/privacy-from-operators/).