State Proof

Overview

How it works and where it fits

State Proof lets a verifier check a specific claim without downloading the entire Blockchain State. In a Merkle-based structure, the proof contains the neighboring hashes and encoded nodes needed to reconstruct the path from the target value to the state root.

The verifier hashes the supplied elements according to protocol rules and compares the result with the trusted commitment. A matching root can prove inclusion, while some structures also support non-inclusion proofs showing that a key is absent. Correct verification depends on canonical encoding and the exact trie or tree design.

The root must be anchored to an authentic block or finalized checkpoint. A mathematically valid proof against an attacker-created root says nothing about the real network. Light clients therefore combine state proofs with header verification, consensus assumptions, or trusted checkpoints.

State proofs can support wallet balance checks, bridge verification, cross-chain messaging, and independently verifiable application queries. Proof size and verification cost vary, and not every network or RPC provider exposes the required data. Historical proofs may require archive state.

A state proof is different from a transaction receipt or event log. It demonstrates a value in a specific state snapshot, while a receipt describes execution and a log records emitted data. High-value systems may use both receipt evidence and State Verification to confirm that the expected outcome actually exists.

Proof verification should also confirm the expected key derivation and value encoding. A proof can be cryptographically valid while the application queries the wrong storage slot, account, or token contract. Typed schemas and independently tested key construction are as important as the Merkle hash calculation.

Related glossary concepts

Transaction Event; Remote Node; Signature Verification