Conservation of supply

L29 gave you the verifier framework. Now we open one — the simplest-sounding of the ~30 — and watch how much engineering judgment a one-line invariant actually demands. The invariant is something you could write on a napkin: the sum of everyone's balance equals the total supply. Making that a trustworthy production signal is where the real lesson is.

1 · The shape: a pure-drift verifier

Recall L29's gap / excess / drift taxonomy. This verifier has no gaps or excess by construction: EnumerateOnChain and EnumerateGraph return the same set — the focus tokens — because a token's identity (its address) trivially exists on both sides. So coverage is 100% always, and all the signal lives in VerifyInstance, which forms the ratio. It's a clean reminder that not every verifier uses all three finding kinds — some are pure value-checks.

func VerifyInstance(ctx, ref, _) (pass bool, diffs []Diff, err error) {
    storedQty   := v.sumStoredHolds(ctx, ref.ID)              // Σ HOLDS.quantity_raw from graph
    chainSupply := enrichment.ReadERC20TotalSupply(ctx, ref)  // totalSupply() from chain
    return evaluateConservation(ref, storedQty, chainSupply)
}

Scope is focus tokens only (is_focus_token=true). Running this on LINK — which the indexer tracks at ~19% coverage by design — would just flag intentional sparsity as a violation. The invariant only applies where coverage is meant to be high.

2 · The asymmetric tolerance band — the real idea

L29's drift tolerance was symmetric (abs ∧ rel). This verifier's is deliberately lopsided, and the asymmetry encodes a design decision about the indexer itself. With ratio = Σstored / totalSupply:

3 · Precision placement — big.Int where it counts

An 18-decimal token with a multi-billion supply has raw balances around 2⁹⁰. float64 loses integer precision past 2⁵³, so summing balances as floats would silently corrupt the numerator. The verifier is careful about where it spends precision:

// quantity_raw is stored as a STRING (uint256-safe). Sum with arbitrary precision:
sum := new(big.Int)
for _, s := range rawQuantities {
    b, ok := new(big.Int).SetString(s, 10)   // exact, no overflow
    if ok { sum.Add(sum, b) }
}
// …but the FINAL ratio is float64 — acceptable, because we only test a 1–2% band:
ratio := storedF / chainF        // ~1e-7 worst-case error, vs a 0.02 threshold

4 · Skip, don't lie — observability over false fails

What if totalSupply() can't be read? You can't form a ratio without a denominator. The verifier skips rather than fails, and — crucially — records why on a closed, dashboardable label set:

What you can now do

• State the conservation invariant (Σ HOLDS.quantity_raw ≈ totalSupply) and why overshoot vs undershoot mean different things.
• Explain why it's a pure-drift verifier with 100% coverage by construction, scoped to focus tokens.
• Justify the asymmetric [0.70, 1.02] band as the monitored-set coverage policy expressed as thresholds.
• Explain precision placement — exact big.Int sum, float ratio — and why raw units beat decimals-scaling here.
• Describe skip-don't-lie: chain-read failures skip with a reason label, missing stored balances fail.