Reference, July 2026
Proof of reserves on Base, and how to read it yourself.
Base has become a home for new dollar tokens, and a lot of them hold their backing on-chain. That makes a stronger kind of proof possible: not an attestation you read and trust, but a reserve you recompute from the chain. This page explains the difference, shows how to check a Base stablecoin's backing in a few calls, and uses Kerne's own signed reserves as the worked example, including where that proof stops.
Two kinds of proof, and why the difference matters.
An attestation is a certification: a firm, or the issuer itself, states that reserves of a certain size existed at a certain time. It is a real and useful control, and for reserves held in bank accounts or with a custodian it is often the only control available. What it asks of you is trust in the attestor and in the freshness of the timestamp.
A recomputation is different. When the backing assets are on-chain, you do not need anyone to certify the figure, because you can read the balances yourself and sum them against the token's own supply. No attestor sits in the trust path, and the check is reproducible at a specific block, so it does not go stale between reports. The full spectrum of these trust models is mapped at attestation vs recomputation.
Base is where this matters in practice, because reserves held on-chain on Base are cheap to read and always current. A dollar token on Base that keeps its reserves on-chain can be recomputed by anyone; one that holds its reserves with a custodian is back to attestation, whatever chain the token itself lives on.
Read a Base stablecoin's reserves yourself.
The pattern is the same for any token whose reserves are on-chain: read the outstanding claim, read the reserve balances, divide. Here it is against kUSD on Base, using its live mint reserve. Any Base RPC works; these use the public endpoint.
# outstanding kUSD (the claim), on Base cast call 0x5C2EfdF0D8D286959b42308966bc2B97f5680AA3 \ "totalSupply()(uint256)" --rpc-url https://mainnet.base.org # USDC held by the live mint module (the 1:1 peg reserve) cast call 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 \ "balanceOf(address)(uint256)" \ 0xaBDE1138aa1Ce88d1dF06422C0c3b05D70569803 \ --rpc-url https://mainnet.base.org # coverage = reserve USDC (6 decimals) / kUSD supply (18 decimals)
Two decimal notes that trip people up: USDC on Base has 6 decimals and kUSD has 18, so line up the scales before dividing. And read the reserve at the same block as the supply, or a mint or redeem landing between the two reads will make the ratio look off. Kerne's reserve endpoint lists the exact set of reads for its full book, so you are not guessing which contracts to sum.
A worked example, with its honest limit.
Kerne publishes a live reserve breakdown at /api/por and an hourly EIP-191 signed statement at /api/por/signed. Both read kUSD's reserves on Base and both include the exact commands to reproduce every number. The signed version binds the figures to a key whose address Kerne publishes, so a reader can recover the signer and confirm it is the one they expect rather than take the signature on faith.
The limit is stated on every one of those surfaces. kUSD's USDC peg reserve and vault collateral are on-chain and recomputable. The Hyperliquid hedge leg is not: it is self-reported and signature bound, the same unverifiable position every delta-neutral dollar carries. So Kerne's reserves are recomputable on the peg and collateral, and attested on the hedge, and the disclosure says so instead of implying the whole book is on-chain. A proof of reserves that hides its own off-chain leg is worth less than one that names it.
What a strong proof of reserves looks like.
- Block-pinned. Every figure is tied to a block, so it reproduces exactly rather than drifting with whatever block a node happened to answer from.
- Reproducible. The exact reads are published, so a reader recomputes the number rather than trusting a dashboard.
- Signed, and the signature checkable. A signature is only worth something if you can recover the signer and match it to the address the protocol claims.
- Honest about off-chain legs. Any reserve or hedge held off-chain is named and labelled as attested, not folded silently into an on-chain total.
- Current. Reserves that update continuously beat a monthly certification that is stale the day after it is signed.
Kerne runs this for other tokens too.
Kerne built this reserve-reading stack for its own kUSD and sells it as fixed-price verification work: a free tool to grade any token's on-chain verifiability at /verify-anything, signed reads and reserve snapshots for issuers, and continuous peg and reserve monitoring. The catalog is at /pricing. The product is the convenience of the read; the reserves themselves stay free to recompute.
Related reading.
Kerne's own reserves: the Proof of Reserves page, /api/por, /api/por/signed, and the machine-readable /facts.json. The trust-model spectrum: attestation vs recomputation. The field ranked on reserve transparency: the scorecard.
Also: the delta-neutral risk checklist, advertised vs realized APY, and the failure ledger.
Contract addresses and reads are for Base mainnet (chain 8453) and were current as of July 2026; verify against the live endpoints above. Nothing here is financial advice.