A light client verifies block headers, consensus or finality, and requested state or transaction claims with signatures and Merkle proofs; it does not replay every block or store the full chain.
1. Establish the chain you are following
A light client first needs a trustworthy starting point: chain specifications, genesis information, and a trusted block root, normally from a finalized checkpoint within the weak-subjectivity window. It then requests compact updates from a full node or peer. The provider supplies data; the light client decides whether that data matches the commitment it already trusts.
On Ethereum Mainnet, the bootstrap includes a beacon block header, its sync committee, and a Merkle branch proving that the committee belongs to the header's state. When that verification is part of a cross-chain route, the wider Manta Bridge context is a separate matter from the proof mechanics described here.
2. Verify consensus, not a downloaded opinion
The client next checks that the advertised header was authorized by the chain's consensus participants. Ethereum's light-client design uses a randomly selected sync committee of 512 validators. A signed aggregate from at least two-thirds of that committee is the threshold: the client checks the BLS signature, signer bitfield, committee keys, signing domain, and header root. The committee changes about every 27 hours, so an update also carries a Merkle proof of the next committee.
A finalized update is stronger than an optimistic update. The latter says that a sync committee signed a recent header; the former also includes a finality proof tying a finalized header to the attested state. An application may tolerate the optimistic head, while a bridge or settlement action normally waits for finality.
Polkadot Network takes a different route. A smoldot light client warp-syncs headers and verifies GRANDPA finality justifications, where more than two-thirds of the active authority set must support a common finalized prefix. BABE produces blocks; GRANDPA finalizes them. The authority set is therefore part of the state the client must track, rather than a fixed 512-member committee.
The comparison is practical: Ethereum packages a 512-key sample with a two-thirds signature threshold and roughly a 27-hour committee period; Polkadot uses a changing authority set, a two-thirds GRANDPA threshold, and explicit finality justifications. Those numbers describe different security objects, not interchangeable guarantees.
3. Verify only the claim requested
A valid header commits to roots for the chain's state and transaction data. To check an account balance, the client asks for the account proof and hashes each branch back to the trusted state root; for a contract value, it also verifies the relevant storage proof. To check a transaction, it verifies inclusion against the transaction or receipt commitment. The full node can choose the answer and lie about it, but it cannot make an invalid branch hash to the accepted root.
That is the key limit: a proof authenticates a committed claim, not every fact a remote node could report. Data can be withheld, a stale header can be served, and an optimistic header can later be reorganized. The client needs freshness rules, a local clock, the right chain specification, and a policy for finalized versus optimistic data. It cannot prove a claim for which the protocol exposes no usable commitment or proof.
4. Keep the trust boundary visible
A light client removes the need to trust one RPC response, not every assumption. Its security still rests on the initial checkpoint, consensus threshold, correct validator-set transitions, and proof availability. This distinction matters in cross-chain systems: Symbiosis Finance documents a BridgeV2 flow in which off-chain relayers submit MPC-authorized transactions, a different trust boundary from independently verifying source-chain finality and a Merkle proof.
The practical sequence is short: anchor the client, advance its consensus state, reject updates that fail signatures or finality, request the exact state or transaction proof, and accept the result only when its root, freshness, and finality policy pass. “Without the full chain” means less data and computation, not less verification.