TL;DR: A compact account proof establishes a value only relative to a particular authenticated state root. A light client must also establish why that root belongs to the intended chain, which consensus status it has, and how fresh it is. Bootstrap checkpoints, committee updates, execution-header linkage, proof verification, and application interpretation are separate steps. A valid old proof or a proof for the wrong account can still produce a misleading wallet display.
A fictional mobile wallet, Alder Pocket, receives an account balance and a proof from an RPC provider. The proof verifies mathematically against the supplied state root. The product team wants to label the balance “trustless.” An engineer asks where the state root came from. If the same provider supplied an arbitrary root without independent authentication, the proof has established consistency with the provider's story, not the chain the user intended.
This article builds a proof ladder for Alder Pocket. It focuses on the relationship between consensus evidence and an execution-state query, not on implementing a complete light client from scratch. Ethereum's light-client overview, the consensus light-client specification, and EIP-1186 provide the primary references. Production software must follow the fork-specific specifications it actually supports.
The ladder matters because each rung answers a different question. A signature can authenticate one statement without proving freshness. A Merkle proof can authenticate one storage value without explaining the contract's business meaning. A working application needs the complete chain of reasoning, with failures represented honestly when a rung is missing.
Claim card one: the application is on the intended network
Before verifying a balance, Alder Pocket identifies the chain the user selected. A mainnet account and a test-network account can share the same address representation while referring to different states. A proof for the wrong network should not be accepted merely because the address string looks correct.
The bootstrap configuration therefore includes an explicit network identity and the relevant consensus parameters. The application does not infer them from a provider's branding or a familiar URL. It records which configuration the verifier uses and checks that incoming data belongs to that context.
This is also an interface requirement. If the user changes networks, the displayed balance and verification state must change together. Retaining a verified badge from the previous network while fetching a new value would combine evidence from two different contexts. The rendering state should be tied to the actual verified result, not to a global boolean that once became true.
Alder Pocket's test suite includes a valid proof from another configured network. The expected outcome is rejection or an explicit mismatch, not a successful display with an incorrect label. This test demonstrates that cryptographic validity alone is not enough; the proof must answer the application's intended question.
The product description can now make a narrow claim: this value was checked under a named network configuration. It does not yet claim that the root is current or canonical. Those questions belong to later rungs, and keeping them separate makes the eventual assurance more precise.
Claim card two: the bootstrap has an explicit trust source
A light client needs a starting point from which it can authenticate subsequent updates. For proof-of-stake systems, bootstrapping and long-range history involve assumptions that differ from simply replaying a short chain of hashes. Ethereum's weak-subjectivity explanation discusses the role of a trusted recent checkpoint in establishing the intended history.
Alder Pocket documents how its initial checkpoint is obtained, how its freshness is assessed, and what happens after a long period offline. It does not describe the checkpoint as self-authenticating merely because it is represented by a cryptographic hash. A hash identifies data; the user still needs a justified connection between that data and the intended chain.
Several independently obtained checkpoint observations can reduce reliance on one delivery path, but their independence must be real. Three endpoints operated behind the same upstream service do not necessarily provide three independent trust sources. The application should not turn endpoint count into an unsupported security guarantee.
The bootstrap policy is part of the threat model. A wallet designed for ordinary online use may make different choices from a device returning after years offline. The recovery path for stale state should be specified and tested rather than left to a provider fallback that silently changes the trust assumptions.
The claim card records the checkpoint identity, its source, the applicable policy, and the time or chain context used to assess it. This does not expose sensitive user information; it makes the verifier's foundation inspectable. A later verification result is only as meaningful as the assumptions connecting it to the intended history.
Claim card three: consensus updates must satisfy the protocol
Ethereum light-client updates use specified consensus structures and checks, including sync-committee information and authenticated relationships between data elements. The implementation must verify the relevant signatures, branches, periods, and update conditions according to the supported fork. Receiving a plausible-looking header is not equivalent to processing a valid update.
The Altair light-client synchronization specification provides a foundation for these mechanisms, while later forks can modify the structures or required checks. Alder Pocket pins the versions it implements and treats an unsupported fork as a compatibility condition to resolve, not as permission to skip verification.
The application distinguishes optimistic and finalized information where the protocol and implementation expose that distinction. A recently observed head and a finalized checkpoint have different assurance properties. The user-facing wording should not flatten both into an identical “confirmed” label if the application relies on the difference for spending or reporting decisions.
The verifier's stored state changes only after successful checks. An invalid update should not partially replace committee or header information in a way that corrupts later verification. This is an implementation invariant that deserves tests with malformed and conflicting inputs, not merely successful synchronization examples.
Alder Pocket also records why an update was rejected. A signature failure, stale period, incompatible format, and unavailable data suggest different operational responses. The application can remain clear and concise for the user while retaining enough diagnostic detail for developers to investigate the actual failure.
Claim card four: the execution root must be linked to the accepted consensus evidence
A wallet balance lives in execution state. The consensus evidence must authenticate the relevant execution header and its state root through the fork-appropriate structure. Accepting a consensus header and separately trusting an unrelated execution root from an RPC provider would leave a gap in the proof ladder.
Alder Pocket therefore carries the authenticated relationship through to the exact block state used for the query. It does not mix the latest execution response with an older consensus checkpoint merely because both came from the same service. The block identity and root are part of the result's provenance.
This linkage is especially important when different data sources are used. One provider may supply consensus updates while another supplies state proofs. That separation can be useful, but the application must verify that the second provider's proof corresponds to the root authenticated through the first path. Provider diversity does not replace data binding.
The test suite deliberately supplies a valid account proof for a different block. The proof can be internally correct and still answer the wrong temporal question. The expected outcome is a block-context mismatch, or a clearly labeled historical result if that was explicitly requested.
The claim card is now stronger: the application has an accepted consensus context and an authenticated execution-state root for a specific block. It still has not established the requested account value. That requires checking the next proof rather than treating the root itself as a balance.
Claim card five: prove the requested account and storage key
EIP-1186 describes an RPC method for obtaining account and storage proofs that can be verified against a trusted state root. The method's value lies in making the response checkable; calling a proof endpoint does not itself perform verification. Alder Pocket must validate the returned path and decoded value against the root it already authenticated.
The request identity matters. The application checks the exact account address and, for storage queries, the exact storage key. A provider could return a perfectly valid proof for another account or slot. The verifier should reject it as an answer to the current request even if the underlying proof is mathematically sound.
Nonexistence also needs a valid proof under the data structure's rules. A missing RPC field or an empty response is not proof that an account has a zero balance or that a storage slot is absent. The application must distinguish authenticated absence from an unavailable or malformed response.
The decoding layer is part of the security boundary. Byte ordering, integer interpretation, and expected structure must match the protocol. A correct hash path followed by an incorrect decode can still display the wrong value. Tests should include boundary values and malformed encodings, not only a familiar small balance.
Alder Pocket binds the verified value, block identity, account, query key, and verification status into one result object. This helps prevent a later UI or caching layer from combining a fresh label with an unrelated cached number. The cryptographic result should remain attached to the data it actually supports.
Claim card six: a token balance is a contract interpretation
An account's native-currency balance and a token balance exposed by a contract are different queries. A token interface may compute a result from storage and code rather than place the desired value in one universally known slot. A raw storage proof does not automatically establish the semantic result of an arbitrary contract call.
For a simple known contract layout, a verifier may be able to identify and prove the relevant storage values, but that requires correct knowledge of the code and layout. Proxies, upgrades, rebasing behavior, or other contract logic can change the interpretation. Alder Pocket should not assume that every token follows one storage pattern.
A more general verified call requires the evidence and execution machinery needed to establish the result under the authenticated state. The exact architecture depends on the client. This article does not imply that EIP-1186 alone provides a universal proof of every RPC call or application-level balance.
The wallet's asset metadata also needs separate treatment. A verified integer does not prove the correctness of a token name, symbol, icon, or decimal display chosen by an external catalogue. Those presentation fields can mislead users even when the underlying on-chain quantity is authentic.
Alder Pocket's interface distinguishes what was verified from what was supplied as metadata. It can provide a useful balance view without claiming that a cryptographic proof authenticates every surrounding label. The claim should follow the evidence's actual scope.
The adversarial review tests seven substitutions
The team asks a reviewer to substitute one element at a time while keeping the rest plausible. This is a practical way to test whether the proof ladder has hidden gaps. The substitutions are defensive test cases, not instructions for compromising a live service.
| Substitution | Why a superficial implementation might accept it | Required distinction |
|---|---|---|
| Wrong network | Address format still looks valid | Bind verification to the selected chain |
| Old valid checkpoint | Hash and structure are genuine | Apply the bootstrap freshness policy |
| Invalid committee update | Header fields look familiar | Verify the protocol's update conditions |
| Unrelated execution root | RPC response is well formed | Authenticate the execution linkage |
| Another account's proof | Proof verifies against a real root | Bind proof to the requested address |
| Older block's value | Historical proof is genuine | Preserve the requested temporal context |
| Incorrect token metadata | Integer proof is valid | Separate state evidence from display claims |
The table is not a complete security assessment. It is an original review aid that exposes common category errors between authenticity, relevance, and freshness. A production verifier also needs rigorous implementation review, dependency management, and tests appropriate to its protocol and language.
The reviewer records whether each substitution is rejected, explicitly downgraded, or displayed under a different supported mode. A silent fallback to unverified data is not equivalent to a successful verification. If the product offers such a fallback, it should communicate the changed assurance clearly enough for the user's decision.
The exercise also checks caching. A valid result cached for one block must not be presented as a newly verified result after the network connection fails. The application can show the last verified value with its context, but it should not manufacture freshness from the current wall-clock time.
Availability remains a separate dependency
A provider can refuse to return a proof or stop sending useful updates. Cryptographic verification can help detect invalid data, but it does not force a remote service to provide data. A light client still needs a strategy for obtaining the information required to progress.
Alder Pocket can use multiple sources, retries, and local caching according to its design. Those mechanisms improve availability only to the extent that the sources and failure modes are sufficiently independent. They should be evaluated through actual outage scenarios rather than assumed from a list of URLs.
The user experience distinguishes “unable to refresh” from “balance is zero” and from “proof invalid.” These states have different meanings. Collapsing them into a generic empty balance can cause a user to make a mistaken financial decision even if the verifier itself never accepted a false proof.
The app also limits resource consumption from untrusted inputs. A malicious or broken provider can return oversized or pathological data. Verification should occur within a robust implementation that handles parsing and computational limits without corrupting state or freezing the interface indefinitely.
Availability tests include a provider that serves only old valid data. The response may pass cryptographic checks while failing the application's freshness requirement. The wallet should preserve the last verified state and explain the limitation rather than repeatedly celebrating successful verification of an increasingly stale result.
Privacy does not follow automatically from local verification
A wallet that verifies responses locally may still reveal its queried addresses to the service supplying proofs. Authenticity and query privacy are different properties. A product should not advertise the first as if it automatically supplies the second.
Alder Pocket documents which providers see requests, what identifiers are sent, and whether the application contacts them directly or through another service. The review considers whether repeated queries can be linked through network or application metadata. The appropriate mitigation depends on the product's privacy goals and architecture.
Using several providers can distribute or increase exposure rather than simply improve privacy. A provider-diversity strategy designed for availability needs a separate privacy assessment. The same technical choice can have different consequences across threat models.
Local caches can reduce repeated queries but introduce storage and device-access considerations. A verified balance history may be sensitive even though the underlying chain is public, because the device associates addresses with a particular user. The application should protect that association according to its stated privacy model.
The final product claim stays narrow: local verification reduces the need to trust a provider's unsupported state answer under the documented protocol assumptions. It does not eliminate every network, implementation, bootstrap, or privacy dependency. Precision makes the benefit more credible, not less valuable.
A long-offline device needs a deliberate return path
Alder Pocket is opened after a long period without updates. Its stored state may no longer satisfy the assumptions of the normal incremental update path. The application needs a documented recovery or rebootstrap procedure appropriate to the consensus protocol and client implementation.
The user should not be asked to approve an unexplained replacement checkpoint as though it were a routine refresh. The software can handle ordinary recovery automatically within its established trust policy, but the policy itself must be explicit and reviewed. A hidden emergency shortcut can become the dominant path for infrequently used wallets.
The team tests the return from several offline durations and from interrupted updates. It verifies that stored committee and header state remain consistent and that a failed recovery does not leave a partially trusted root in use. Device backups and application reinstalls are included because they can restore older state unexpectedly.
The test report identifies which supported fork transitions were exercised. A verifier that works on one historical structure is not automatically compatible with every later network upgrade. The maintenance plan needs a way to detect unsupported conditions and update safely without discarding the assurance the product promised.
The wallet can then return to service with an honest state: verified under the current supported path, showing an older verified result, or unable to establish a fresh result. Those outcomes are more useful than a single success indicator that conceals how the device recovered its trust foundation.
Verification results should survive an independent replay
For a representative result, Alder Pocket retains enough nonsecret evidence in its test environment for another implementation or reviewer to repeat the verification. The package identifies the network, accepted checkpoint context, relevant updates, execution header linkage, requested account and storage keys, proof bytes, and decoded result. It also names the verifier version and supported fork rules.
This package is a testing artifact, not a reason to upload every user's address history to a central service. Production diagnostics should minimize personal information and follow the application's privacy policy. The engineering objective is reproducibility of the verification logic, which can often be demonstrated with controlled accounts and public test vectors.
Independent replay can reveal assumptions hidden in one library's convenience API. A helper might accept a provider-supplied block hash without checking the expected linkage, or a cache might substitute a value from another request. A second review follows the evidence from beginning to end instead of assuming that a function named “verify” covers the entire product claim.
The team also checks failure determinism. The same malformed proof should not be accepted after a different sequence of unrelated queries because mutable state leaked between requests. Concurrent requests for different accounts and blocks should remain distinct. These are ordinary software correctness concerns that become part of the trust boundary when the result is presented as cryptographically checked.
The final evidence record separates protocol verification from implementation confidence. Passing known vectors establishes specific behavior; it does not prove the absence of every bug. The product can still offer a meaningful improvement by making its checks, assumptions, and maintenance responsibilities explicit and subject to review.
What the verified badge should mean
Alder Pocket defines its badge as a compact summary of a specific result: the selected account value was checked against an execution root authenticated through the supported light-client process, at a named block context and consensus status, under the documented bootstrap policy. The details can be available on demand without overwhelming the ordinary balance screen.
The badge is removed or changed when any of those conditions no longer describes the displayed value. It does not persist across a network switch, metadata-only update, stale fallback, or failed proof. The UI state is derived from the evidence object rather than maintained as a separate optimistic flag.
The proof ladder gives the engineering team a way to test that claim. Each rung has an input, a verification responsibility, and a failure state. The application can now explain what it knows, what it assumes, and what it could not refresh. That is the practical value of a light client: a smaller but carefully connected body of evidence, not a slogan that every dependency has disappeared.