zkRPC for EVM chains: trustless data access made simple

Building on our progress with zkTLS, we’ve been exploring what happens when you wrap standard RPC in a cryptographic security layer powered by ZK and TEE. This led us to zkRPC — a way to execute any RPC call with cryptographic guarantees. zkRPC isn’t reinventing RPC, it’s upgrading it with zkTLS-level integrity and privacy: zkRPC works like regular RPC — whether you're querying balances, posting transactions, or reading contract state — but everything happens inside a zkTLS-secured enclave. You don’t have to trust the node’s honesty anymore. You verify it cryptographically.

If you're new to zkRPC, this post will give you a taste of how it works and why it's worth your attention, especially as we start using it for things like С ollateral abstraction, where trust in off-chain state access is mission-critical.

A few words about the EVM state

At its core, the Ethereum state is stored in a Merkle - Patricia tries (MPTs)—a hierarchical data structure that efficiently organizes and secures blockchain data. This scheme reveals several key components:

Global State Trie: This primary tree maps every Ethereum account (both user and smart contract accounts) to its associated data, such as balances, nonces, contract code, and a pointer to a contract’s dedicated storage trie.
Transaction Trie & Receipt Trie: Every block contains a transaction trie that organizes all the transactions and a receipt trie that stores the corresponding execution receipts.
Contract Storage Tries: Each smart contract maintains its own storage trie, which securely holds its internal data like variables and mappings.

This structure enables the cryptographic verification of specific values (for example, confirming your wallet balance) via Merkle proofs without downloading the entire state. Although these proofs guarantee data integrity, they do reveal the underlying data, and you still rely on nodes to correctly execute state transitions.

zkRPC as RPC wrapped in zkTLS

Suppose you need to retrieve the value of a variable from a smart contract deployed on a different EVM chain.

Check existing support
First, verify whether the contract is already supported by our protocol. If it isn't, contact us to register a dedicated zkRPC service tailored to your use case.
Define execution triggers
You define the conditions under which this service should be triggered. These triggers can be:
- Time-based: e.g., every 24 hours or every 256 blocks
- State-change-based: triggered when a specific part of the contract’s state changes
Triggering the zkRPC engine
Once the specified trigger condition is met (e.g., a state change), the zkRPC engine is activated.
Fetching and proving storage data
The engine uses a zkTLS-secured connection to retrieve the MPT path for the targeted storage slot from one or more public RPC endpoints. It also fetches the root of the contract’s storage trie.
Verification inside TEE + zkVM wrapping
The RPC response is verified within a TEE enclave and wrapped inside a zkVM execution, enabling efficient on-chain verification.
Submitting the result on-chain
The verified data, along with a zk proof, is submitted to our on-chain verification contract. You can claim the result directly from there.

Instead of simply trusting an RPC node’s response, zkRPC leverages zkTLS to secure the call and attach a verifiable zero-knowledge (zk) proof. This proof confirms that the returned data—say, your token balance—was computed directly from Ethereum’s state as recorded in the Merkle-Patricia trie. Think of it as a global spreadsheet where every cell is cryptographically linked, enabling you to verify a specific cell’s value without downloading the entire spreadsheet.

The protocol fetches data from public RPCs. To increase trust guarantees, a threshold-based approach can be used. For example, data can be requested from three RPC endpoints, and a 2-of-3 threshold can be applied to validate consistency. The specific threshold configuration can be customized based on your use case.

Real-world use-cases

Collateral Abstraction for Symbiotic & modular DeFi

Protocols like Symbiotic rely on balances or positions from other chains or systems, but verifying that data requires trust in RPCs or validator sets. zkRPC enables verifiable reads of collateral positions (vaults, staked assets, balances) directly from Ethereum or other EVMs using zkTLS-wrapped RPC.

Powers under-collateralized lending and credit protocols
Trustlessly composes across DeFi layers (vaults, LSTs, AMMs)
Removes the need for validator sets or syncing full nodes

Trustless bridges & cross-rollup messaging

Cross-chain bridges typically rely on validators, multisigs, or synced full nodes to verify state on remote chains. The zkRPC solution allows a contract on Chain A to verify a storage value, event, or account balance on Chain B via a lightweight zk proof — no full node required.

Eliminates validator sets and reduces attack surface
Enables low-latency, high-security bridging
Useful for rollup-to-rollup communication, DA bridges, shared sequencers

There are also potential applications for verifiable dApps & indexer APIs, integration into existing ZK systems - rollups, coprocessors and so on.

Try it out

Tell us what on-chain data your app needs, and we’ll show you how to get it using zkRPC. Whether you're building a wallet, bridge, rollup, or DeFi primitive, zkRPC can make it happen if you need other chains’ contract data.

Take a look at our tech:

Start with our zkTLS open-source repo: GitHub
Explore our trustless Data Feeds oracle: GitBook