Reconciling agent USDC spend against an on-chain balance: our method and its gaps

The reconciliation we run

For a wallet we track, we can pull its live USDC balance directly from the chain and independently sum every inbound and outbound transfer we've recorded. Starting balance plus inbound minus outbound should equal current balance; when it does, our ledger is a faithful record of that wallet's history for the period we've been watching.

Where it doesn't close

A mismatch almost always means one of two things: our ingest cursor missed a range of blocks (rare, but a stalled cron or an RPC gap can cause it — we've hit this before and fixed it with a per-wallet cursor and chunked catch-up), or the wallet moved USDC on a network or token contract we're not polling. We only watch the USDC contracts on Base and Solana that we've configured; a wallet that also holds USDC on another chain, or holds it as a wrapped or bridged variant, will show a balance we can't explain from our ledger alone.

We don't currently surface a reconciliation mismatch as a user-facing alert — it's something we've checked manually when debugging, not an automated check running against every tracked wallet. That's a real gap if you're relying on us as the source of truth rather than a monitoring layer on top of the chain itself.

What this means for your fleet

Treat our ledger as a monitoring layer, not an accounting system of record — for anything audit-grade, reconcile against the chain directly, the same way we do internally, rather than trusting our totals as final.