See it work
A real run, end to end: a reserve balance, signed by a custodian or read from Stellar; a commitment to what is owed; a proof; a contract on Stellar Testnet that checks it; and the inclusion path a holder uses to confirm they were counted. Two example institutions use Solva's sandbox as the custodian; a third, Harbor Wallet, holds real Testnet USDC read from Stellar. Everything after the reserve source is the same code a pilot runs.
What one run produces
Real pipelineSandbox and on-chain reserves
Run it
Pick an institution, then run the steps one at a time. Kestrel and Solstice use a stand-in custodian run by Solva, with three scenarios. Harbor Wallet's reserves are real Testnet USDC, read from Stellar on every run. Every published proof lands on Stellar Testnet, where you can open it.
Your registry entry
The institution's own contract on Stellar Testnet.
Connect the reserve source
Open access to the accounts that hold the reserves.
Read the reserve balance
One balance per reserve account, signed by the custodian or read from Stellar.
Prove coverage and publish
Prove that reserves cover the committed total, then publish it on Stellar.
Check the published record
Read the record from the contract on Stellar and check that reserves cover what is owed.
A holder checks they were counted
The contract confirms one holder's balance was counted.
Stellar TestnetReserve source: Solva's sandbox, signed balancesExample customer balances
Step by step
Each institution publishes to its own contract on Stellar. A proof for one never touches another, and the entry is controlled by the institution's own passkey.
Solva holds no credentials for your reserve source. For a custodian, it runs a standard authorisation handshake, then reads balances with a short-lived token; on this page the custodian is Solva's sandbox. For reserves held on Stellar, nothing needs authorising: account balances are public.
A custodian returns each balance with its signature, and the signature is checked before the balance goes anywhere near the proof. Reserves held on Stellar are read straight from the account on the ledger, which anyone can check on an explorer.
What is owed is committed as one value. The proof shows that the total behind it is at most the reserve balance, and the contract on Stellar checks the proof before it stores the result.
This page reads the latest proof straight from the institution's contract with get_latest_proof, as anyone can. The record carries the reserve total, the committed total and the time, and nothing about any single balance.
A holder presents their account reference, this page looks up their inclusion path for the published proof, and the contract checks that path with verify_inclusion. No other customer is named; the path shows unnamed subtotals, including one neighbouring balance.
From the sandbox to a pilot
Reserves held in Stellar accounts are read from the ledger today, as Harbor Wallet's are on this page. Connecting a real custodian that signs your reserve balance is coming soon; on this page the sandbox stands in for one. Everything after the reserve source is the same code.
For an anchor, what is owed will be the token's supply at the ledger of the check, read straight from Stellar. Today what is owed is a stored list of holder balances.
A pilot will run these steps once a day by default, with a missed day written as stale and never filled in afterwards. On Testnet today a cycle runs on request.
Coverage record · Example: what a pilot writes
Northway Custody · USDC
Customer balances, committed as one value. Reserves are the balance of the reserve accounts, signed by the custodian or read from Stellar.
For institutions
Pilots are open to anchors and custodial apps on Stellar. Tell us about your asset and we will plan your first real record with you.
For readers
See what a holder, a wallet, a lending pool or an auditor sees, and how one record answers the question each of them asks.