Motivation
Blockchain promises full data transparency, but regulatory reality is different. Financial regulators and compliance authorities require restricted, scoped access to transaction data - especially in Asia, where I'm based. This is particularly true in enterprise payment infrastructure where multiple institutional parties operate on shared infrastructure.
Contra's approach - private L2 batching with Solana L1 settlement - is a strong answer to this tension. Internal transactions stay off-chain while preserving L1 finality guarantees. However, as Contra scales beyond a single-operator model to multi-party deployments, there is currently no mechanism to scope data visibility between participants.
Current State
- Currently designed around a single-operator model, so the Gateway serves requests without authentication — which makes sense for the current scope
- No concept of tenant identity, ownership, or permission scoping
- In a shared ledger scenario (e.g., banks A, B, C, D on one instance), if a subset (A, B, C) needs to transact privately excluding D, there is no mechanism to enforce that visibility boundary
Proposed Approach
The Gateway is the natural enforcement point — it's already the single entry point for all client traffic. Since Contra is private settlement infrastructure — not a public RPC — requiring authentication on all Gateway access is consistent with its design. By having the Operator issue scoped credentials (API key or mTLS) to each tenant and maintaining a registry that maps each tenant to their owned accounts, the Gateway can filter all responses to return only data the authenticated tenant is authorized to see. Cross-tenant transactions (e.g., A sends to B) would grant both parties visibility, while other tenants see nothing.
The core pipeline (dedup, sigverify, sequencer, executor, settler), read/write nodes, and PostgreSQL schema would remain completely unchanged. L1 escrow verification stays open to all participants as an independent trustless anchor — any party can audit their settlement state directly on Solana mainnet without relying on the Operator.
If this direction makes sense, I'd be happy to submit a PR with an implementation.
Motivation
Blockchain promises full data transparency, but regulatory reality is different. Financial regulators and compliance authorities require restricted, scoped access to transaction data - especially in Asia, where I'm based. This is particularly true in enterprise payment infrastructure where multiple institutional parties operate on shared infrastructure.
Contra's approach - private L2 batching with Solana L1 settlement - is a strong answer to this tension. Internal transactions stay off-chain while preserving L1 finality guarantees. However, as Contra scales beyond a single-operator model to multi-party deployments, there is currently no mechanism to scope data visibility between participants.
Current State
Proposed Approach
The Gateway is the natural enforcement point — it's already the single entry point for all client traffic. Since Contra is private settlement infrastructure — not a public RPC — requiring authentication on all Gateway access is consistent with its design. By having the Operator issue scoped credentials (API key or mTLS) to each tenant and maintaining a registry that maps each tenant to their owned accounts, the Gateway can filter all responses to return only data the authenticated tenant is authorized to see. Cross-tenant transactions (e.g., A sends to B) would grant both parties visibility, while other tenants see nothing.
The core pipeline (dedup, sigverify, sequencer, executor, settler), read/write nodes, and PostgreSQL schema would remain completely unchanged. L1 escrow verification stays open to all participants as an independent trustless anchor — any party can audit their settlement state directly on Solana mainnet without relying on the Operator.
If this direction makes sense, I'd be happy to submit a PR with an implementation.