When Linh — a mobile wallet developer — receives a request from the product team: “I want users to be able to verify balances on Hemi directly on their phones without downloading the whole chain,” she knows she must solve two problems: (1) how the wallet can prove a balance truly exists on Hemi, and (2) how to do that lightly on a mobile device. The answer lies in a concept generally called state proofs — proofs that let anyone, anywhere, verify a slice of Hemi’s state without having to hold the entire dataset.
---
Quick lesson: a proof is a “small piece of evidence” for a much larger thing
Imagine Hemi as a big ledger. Instead of sending the whole ledger to you to prove “Linh has 5 HEM,” Hemi sends a tiny proof — enough to show that the line “Linh → 5 HEM” appears in that ledger. This proof is typically far smaller than all the data and can be checked quickly.
In blockchain engineering, the most basic form of proof is the Merkle inclusion proof: it provides a path from a leaf in a Merkle tree to the root. If you trust the root (for example, because the root is anchored to Bitcoin or verified via a header chain), then that leaf definitely exists in the state.
---
Merkle proofs — the classic navigator
In practical terms:
Hemi produces a state root for each batch/block (a hash that represents the entire state at that moment).
Each account balance, storage slot, or transaction inclusion is a leaf in a Merkle tree (or a Sparse Merkle Tree / Patricia trie depending on the design).
A Merkle proof consists of the sibling hashes along the path from leaf to root; the verifier hashes step by step and compares the result to the root.
In Linh’s scenario: the wallet sends a request getProof(address, key, blockRoot) to a Hemi node or to an hBK API; the node returns the Merkle proof for the balance at blockRoot; the wallet verifies locally by hashing up and comparing to the state root (the root can be taken from an anchored record, a block header, or a trusted checkpoint the wallet trusts).
Advantages: transparent, simple, and light for the verifier. Limitations: the verifier must trust the root — therefore the root needs finality/anchoring (e.g., a root anchored to Bitcoin) or must come from a source the verifier trusts (a trusted checkpoint).
---
Non-inclusion proofs & Sparse Merkle Trees
It’s not only about proving “existence”; sometimes you must prove “non-existence” (e.g., the user does not hold token X). Sparse Merkle Trees (SMTs) allow compact non-inclusion proofs — demonstrating that a key is absent at a particular leaf position. This is useful for light clients checking absence-of-balance or absence-of-state.
---
Succinct / ZK-proofs — when you want extremely small, fast-to-verify proofs
Merkle proofs are “simple and efficient,” but for complex statements (for example: prove that “the balance after the sequence of transactions A..Z is correct”), you may use succinct proofs (zk-SNARKs, zk-STARKs). Instead of proving inclusion piece by piece, Hemi could run a prover that generates a short proof asserting the correctness of a transition or a whole batch.
Advantages of ZK-proofs:
Proofs are very small and quick to verify (on-chain or off-chain).
They can prove the correctness of computation (not just data inclusion).
Disadvantages:
Proof generation (prover compute) can be expensive.
They may require a trusted setup (depending on the ZK scheme) or complex prover infrastructure.
You still need DA to be able to reconstruct raw data for audit when required.
Hemi can use zk-proofs to provide “proof-of-state transition” for important flows, then link that proof to an anchored state root.
---
Practical flow: fetching & verifying proofs on Hemi
Linh implements the wallet flow:
1. Obtain a trusted checkpoint/root. The wallet can take the root from the Hemi explorer, from an anchoring hash on Bitcoin (if Hemi anchored), or from a trusted node.
2. Request a proof. The wallet calls endpoint getStateProof(address, slot, root) on a mirror node or hBK. The node returns a Merkle proof + metadata (block number, timestamp, inclusion path).
3. Verify proof locally. The wallet computes the hashes up to the root and compares them. If they match, the proof is valid.
4. Optionally validate anchoring. If the root is anchored on Bitcoin, the wallet can check the anchor tx hash and confirmation count. That increases trust — not only is the proof valid relative to the root, but the root itself has been recorded on a high-security chain.
The beauty is: this whole process runs lightly on a phone — you don’t download the whole network state.
---
Light clients & UX: blockchain in your pocket
State proofs are the foundation for light clients: apps that only receive headers + proofs instead of storing full block data. With Hemi, this allows mobile wallets to:
Show exact balances;
Check inclusion of a sent transaction;
Verify Merkle receipts for merchants or exchanges.
What makes the UX smooth is: proofs are small and verification is fast — the wallet only does a few local cryptographic operations and can show the user a “verified” badge.
---
Cross-chain relays & oracles: proofs as a common language
State proofs are not only for wallets; relayers and cross-chain bridges use proofs to perform atomic actions between chains. For example:
When a bridge mints a pegged token on Hemi based on a BTC lock, the relayer needs proof that BTC was indeed locked — that could be an inclusion proof of the lock tx in Bitcoin plus a Merkle proof linking that event to Hemi state.
Oracles can use proofs to show that off-chain data has been recorded on Hemi before feeding it into a contract.
Proofs become “evidence” that other systems can rely upon without direct trust.
---
Things to note & developer trade-offs
Trust the root = trust the checkpoint: a proof is only meaningful if you trust the root. Controlling the source of the root is a key security decision (anchoring to Bitcoin boosts trust).
DA still matters: a proof proves inclusion under a root; for detailed audits you need the raw data available at a DA provider. If DA is withheld, you may have a proof but no underlying data to present in a dispute.
Proof size vs compute: Merkle proofs are small and easy to verify; zk-proofs are much smaller but expensive to generate. Choose by flow (micro-payments vs batch settlement).
Freshness & checkpoints: wallets must know the “latest” root to avoid replaying stale proofs; block numbers/timestamps and anchoring messages help.
Caching & offline: store recent proofs for offline verification; implement proof expiry policies.
---
Checklist for Linh (and anyone integrating proofs)
1. Decide the trust level you need (provisional vs anchored final).
2. Obtain the root from a trusted source (anchored checkpoint or trusted node).
3. Use the getStateProof(...) endpoint and verify the proof locally.
4. Check DA availability if you need the raw data.
5. If you use zk-proofs, plan for prover latency & infrastructure.
6. Store proof + metadata with timestamps for later audit.
7. Communicate UX clearly: “verified” vs “anchored”.
---
Conclusion — proof is the bridge between integrity and convenience
State proofs let wallets, relayers, and mobile apps interact with Hemi without running a full node: they receive a compact piece of evidence, perform a few hash operations, and trust the result. That is real power: maintain security, reduce friction, and broaden access. But remember: a proof is only strong when the root is trustworthy and the raw data is available for audit. When Linh implements the proof flow for the wallet, she is not only giving users peace of mind — she is handing them a ticket of evidence they can carry anywhere for verification.