Verification Caching

Verification caching is the practice of storing the result of an expensive cryptographic check — a signature validation, a range proof, a Merkle proof — so that repeat encounters with the same object skip the work. It is a standard and usually necessary optimisation in node software, where the same transaction may be validated on receipt, on block inclusion, and on reorg.

The soundness condition

A verification cache is sound only if its key captures everything the verification result depends on. If two distinct objects can produce the same cache key, the cache will return a result computed for one of them when asked about the other.

This makes the cache part of the verifier's trusted computing base. A perfectly correct verification routine behind an incorrectly keyed cache is, from an attacker's perspective, no verification at all — and it fails silently, reporting success rather than error.

Failure shape

The attack pattern is consistent:

1. Submit a legitimate object that verifies successfully, populating the cache.
2. Construct a malicious object that collides with the same cache key.
3. Submit it. The node returns a cache hit and never evaluates the proof.

The September 2026 Liquid Network exploit followed exactly this shape — a cache-key collision in Elements' range proof verification, which allowed unbacked issuance without any federation key being compromised.

In audit scope

Enumerate every memoisation, short-circuit, "already validated" flag and early return on the path to a security-critical check. For each, ask what the key is derived from, and whether an attacker can construct two objects that share it while differing in a way the verification would have caught. A cache key that is a lossy digest of the verified object is a verification bypass.