Verifiable RPC.
Ask for Ethereum state and get the proof with it. Willow returns balances, storage, and call results your client verifies against the block's state root — so a wrong answer can't sneak past.
Your RPC provider can return anything. This one can't lie.
Every wallet, dapp, and bot acts on whatever its RPC endpoint returns. A buggy node, a compromised provider, or anyone in the middle can hand back a wrong balance or stale state — and your application will act on it without blinking, because there's nothing to check it against.
Willow's verifiable RPC carries the evidence with the response. State reads return Merkle-Patricia proofs for every account and storage slot touched; contract calls come with the state they were executed against. The SDK re-walks each proof against the block's state root on your machine — strict verification is the default, not an option you have to find.
The same proof-carrying pattern also serves Willow's indexed data: key-value reads on any subgrove, answered straight from the indexer with the proof attached. Low-latency reads, verification included.
Ethereum state and calls are covered today, with helpers for the reads you actually make — token balances, allowances, NFT ownership, pool reserves — through the SDKs for TypeScript, Rust, Python, Go, and Swift.
Proofs by default
Strict mode re-verifies every account and storage proof against the state root before your code sees the data. Dial it down per call when you just want passthrough.
State and calls
Balances, nonces, storage slots, and contract reads — plus ergonomic helpers for ERC-20, ERC-721, and pool state, each returning verifiable results.
Indexed reads too
Key-value reads on any Willow subgrove are served the same way — direct from the indexer, proof attached, no consensus round-trip.
From setup to verified reads.
- 01
Point
Point the SDK at Willow's verifiable RPC endpoints — no contract changes, no special node.
- 02
Request
Fetch account state, a storage slot, or a contract call result — or use the typed helpers for common token and pool reads.
- 03
Receive
The response carries the block context and a Merkle-Patricia proof for every account and slot it touched.
- 04
Verify
The SDK re-walks the proofs against the state root locally. Wrong or tampered data fails before your code ever sees it.
import { WillowClient } from '@willow/sdk';
const client = new WillowClient({
apiUrl: 'https://api.willow.tech',
});
// ERC-20 balance, with account and storage proofs
const balance = await client.eth.erc20Balance({
token: '0xa0b8...',
holder: '0x7c3a...',
});
// Strict mode (default): every proof re-walked
// against the block state root before returning
console.log(balance.value);Common questions.
How is this different from Infura or Alchemy?
A standard RPC provider returns JSON you take on faith — there's no way to tell a correct answer from a wrong one. Willow returns the same data plus the proofs, and the SDK checks them against the block's state root on your side. A provider bug, a compromise, or a man-in-the-middle produces a verification failure, not a silent wrong answer.
Which chains does it cover?
Ethereum state and calls today. Proof-carrying reads on indexed subgrove data work for every chain Willow indexes, and verified state reads extend to more chains as their tooling allows.
What does verification cost me?
Proofs verify locally in milliseconds. Verification is per-call configurable: strict by default, with lighter modes when a read genuinely doesn’t need the full check.
Stop trusting your RPC.
Point the SDK at Willow’s verifiable endpoints and every read comes back with its proof.