Differentiated visibility for a market operator
A privacy network for one of the world’s largest financial market infrastructure groups. Nine functional requirements, from hierarchical identity to time-boxed regulator access, all covered by Open Privacy Suite at the JSON-RPC boundary with no change to the core architecture.
One of the world’s largest financial market infrastructure groups set nine functional requirements for a privacy network proof of concept: institutions and their functional profiles as a hierarchy, participants joining and leaving without a restart, permissions checked on both observation and execution, a block explorer that shows each institution only its own activity, state confidentiality between institutions, transactions across them, the group’s existing contracts running unmodified, an audit trail of every permission change, and temporary, scoped access for a regulator. Gateway answered with Open Privacy Suite at the JSON-RPC boundary. All nine are supported, and none required a change to the core architecture.
Nine requirements, what each asked, what the record shows
Two requirements carry explicit success criteria in the customer’s document: the denied cross-institution state read and the audit record for three administrative operations. Both are met.
How the boundary does the work
Policy at the JSON-RPC boundary
- Each group carries an allowed method list. A profile that may observe cannot execute; a profile that may deploy cannot administer.
- Data scope is enforced per institution across transactions, balances, events and contract state.
- Function selectors and parameters can be constrained per grant for contract-level control.
One explorer, filtered per viewer
- The block explorer runs in privacy mode and reads through the proxy, so every view is filtered for the person looking.
- Addresses are labelled by the viewer’s relationship to them: mine, my organisation, public, disclosed, private.
- What the explorer shows and what direct RPC returns cannot disagree, because they share one policy.
A regulator with a window, not a key
- The regulator is onboarded into an observer profile scoped to the institutions and contracts in question.
- The membership carries an access window, set in the admin panel or by API. Expiry revokes access with no operator action.
- The grant is in the permission audit trail, the activity is in the request logs, and the window can be ended early.
Selective disclosure for the targeted case
- For a documented disclosure about specific activity to a named recipient, a per-target grant with a hard expiry.
- Standing levels of full, pseudonymous or redacted; withdrawal with a reason; the request, access and expiry cycle audited.
- Broad, time-boxed observation uses the observer profile. Targeted, individually audited disclosure uses this.
An audit trail an administrator can query
- Every permission change records executor, timestamp, action and the institution or profile affected.
- Records are organisation-scoped and queryable through the administrative API, with a timeline view in the dashboard.
- Audit events can be forwarded to the institution’s own security monitoring.
Identity the institution already trusts
- Login is zero-knowledge identity by default, with the institution’s enterprise single sign-on as an option.
- A user belongs to one or more groups and receives the union of their permissions. There is no hidden inheritance.
- Organisation administrators manage their own groups. The operator bootstraps the cluster and steps back.
Six parts of the privacy network
Privacy proxy
- The sole path to the nodes
- Allowed JSON-RPC methods and data scope per group
- Refuses cross-institution state reads
Identity and groups
- Organisations contain groups; users hold the union of their groups’ permissions
- Zero-knowledge identity login, enterprise single sign-on optional
- Deploy, upgrade and admin claims for contract control
Private block explorer
- Reads through the proxy, filtered per viewer
- Relationship labels on every address
- Contract verification and network branding for the institution
Selective disclosure
- Full, pseudonymous or redacted standing levels
- Per-target grants with hard expiry and withdrawal with reason
- Disclosure view in the dashboard
Audit trail
- Immutable record per permission change: executor, timestamp, action, scope
- Administrative API and dashboard timeline
- Forwarding to security monitoring
The chain and the contracts
- Standard EVM execution, unchanged
- The group’s own contracts deployed as they are
- Cross-institution transactions confirm on-chain
The steps agreed for the proof of concept
- Deploy the group’s actual contracts and exercise mint, transfer and burn to confirm bytecode-level parity
- Demonstrate a cross-institution eth_getStorageAt denial through the gateway
- Onboard a read-only observer with an access window and show access ending when it expires, on RPC and in the explorer
- Run a selective disclosure grant through request, access and expiry with its audit trail
- Perform three administrative operations and query the resulting audit records by API
What this record does and does not claim
The customer is a Latin American financial market infrastructure group and is not named. This is a pilot record: a response to the customer’s nine functional requirements and the validation steps agreed for the proof of concept, not a production deployment.
State confidentiality is enforced at the gateway, which is the only access path for participants. It is not cryptographic encryption of ledger state, and the record says so.
At the time of the record, automatic expiry of the observer window was scheduled for the next release. The deployed build reached the same outcome by removing the observer at the end of the engagement, which takes effect immediately. Automatic expiry of selective disclosure grants was already available.