Light clients provide the verification boundary for external-chain evidence. They track a trusted or synchronized header state, validate sequential or skip/bisection updates according to the supported trust model, and expose state-proof checks to the consuming module.
Why they matter
A relayer can transport a deposit proof, but it should not be able to invent the source-chain state. The light-client boundary verifies the header chain, trust period, clock drift, and proof relationship before InstaWrap or another consumer changes RP1-side accounting.
Operational implications
- Keep trust roots, chain IDs, and client parameters environment-specific.
- Monitor client freshness and reject proofs from expired or divergent states.
- Treat a proof accepted by a relayer but not yet by the chain as pending.
- Do not report an external deposit as final merely because an indexer saw an event.
The specific proof format and update policy are chain-specific. Use the relevant source-chain integration and testnet runbook rather than copying one chain’s assumptions to another.