What worked building against the real product, the field notes that cost real hours, and what we'd ask TxLINE to ship or publish next. Everything below came out of our own integration run — nothing here is invented or simulated.
The deployed on-chain verifier is the real thing — we CPI'd validateStatV2 on Solana mainnet against the live daily root and got a byte-exact true for a Merkle proof fetched over the free API minutes earlier. It worked the first time our payload was right.
At the World Cup Final's final whistle: finalisation event to a fetchable V2 stat-validation proof, in under a minute — free tier, no rate limits. We attested the Final on mainnet 4 minutes after the whistle.
Epoch-day seeds are clean and derivable client-side — we computed today's epoch-day root address before it was referenced anywhere in the response, and it matched.
A full 1,385-sequence event stream for the Final, per-stat Merkle proofs, verifiable end to end.
Each of these cost real integration hours. Listed in the order we hit them.
game_finalised arrives with GameState: "scheduled" and empty Data — no StatusId 100 anywhere on the event. Consumers mapping on status alone silently miss the whistle. We only caught this by rehearsing against a completed fixture first."1" home, "2" away) — no named fields, no published registry. We cross-validated against the proof's own statsToProve.seq; the required params were discoverable only by trial. And the on-chain payload timestamp must equal summary.updateStats.minTimestamp exactly — otherwise the verifier throws TimestampMismatch./auth/guest/start and an X-Api-Token header. Nothing states this up front.Seq item is the current state, not a single mutable record.f7e3bcd5db4c6744445f75dfab7eccc879c6d2de to be safe.