​

State proofs

​

The difference

​

Store backends

• Classic IAVL stores
• store/v2 memiavl commitment stores
• Any other proof-capable (queryable) store reached through cache, tracekv, Giga cache, or prefix store wrappers

​

What this affects

• Light clients that verify state without trusting an RPC node
• Cross-chain bridges that prove the inclusion of state on Sei
• Applications that verify contract storage values trustlessly

​

Calling eth_getProof

​

Storage key requirements

• Keys must be hex-encoded. Each storage key must be a valid hex-encoded value (for example, 0x0000000000000000000000000000000000000000000000000000000000000001). Sei decodes each key and left-pads it to 32 bytes. Sei rejects a malformed, non-hex key with an invalid storage key error. Raw byte strings do not work, although earlier versions accepted them.
• At most 1024 keys per request. A single proof request may include a maximum of 1024 storage keys. A request for more keys returns a too many storage keys error. Split larger sets across multiple requests.

import { createPublicClient, http } from 'viem';
import { sei } from 'viem/chains';

const client = createPublicClient({ chain: sei, transport: http() });

const proof = await client.getProof({
  address: '0xContractAddress',
  storageKeys: ['0xStorageSlot'],
});

// proof.accountProof and proof.storageProof contain IAVL proof data,
// not Ethereum MPT proofs — do not pass to an MPT verifier

import { ethers } from 'ethers';

const provider = new ethers.JsonRpcProvider('https://evm-rpc.sei-apis.com');

const proof = await provider.send('eth_getProof', [
  '0xContractAddress',
  ['0xStorageSlot'],
  'latest',
]);

// Same caveat — proof data is IAVL format

​

Verifying proofs