Proxy RPC API

Understand how the Prividium™ Proxy RPC enforces access control.

The Proxy RPC sits between end users and the chain's standard RPC API. It enforces transaction-level access control by filtering all blockchain interactions before they reach the sequencer.

Prividium™ is a licensed product. Non-production use requires accepting the license terms; production deployments require a commercial agreement.

How It Works

The Proxy RPC validates every request against the Permissions API:

  1. User submits a transaction or query through the Proxy RPC
  2. Proxy validates the user's JWT and wallet address
  3. Proxy checks permissions for the requested contract function
  4. Authorized requests proceed to the standard RPC; unauthorized requests return 401 Unauthorized
Keep the standard RPC endpoint private. Implement a firewall to restrict access. Only expose the Proxy RPC publicly.

Limitations

Multicall Contracts

Multicall contract methods bypass individual function permission checks. The Proxy blocks multicall patterns to prevent policy circumvention.

L1-L2 Transactions

Forced transactions originating from Ethereum (L1) can bypass the Proxy entirely. These transactions provide censorship resistance on public chains but create security risks for permissioned networks:

  • Deploy arbitrary contracts
  • Execute unauthorized writes
  • Leak data through blind attacks

Mitigation:

L1-L2 transactions are not automatically disabled. Chain operators can implement transaction filtering to control forced transaction behavior.

The PrividiumTransactionFilterer contract provides an allowlist-based filter:

  • Allowlisted addresses execute unrestricted forced transactions
  • Other addresses can only transfer ETH or ERC-20 tokens
Enabling transaction filtering grants the chain operator censorship capability. Document your filtering policy for users.

Made with ❤️ by the ZKsync Community