How Solva works

A cycle is one full run that turns the reserve balances into a record anyone can read. Following it needs no cryptography. The Build section covers the construction in detail.

The two sides

Every record compares reserves and what is owed.

• Reserves sit in reserve accounts, at a custodian, the firm that holds the money, or in accounts on Stellar.
• For an anchor, what is owed is the token holders' balances, whose total is the token supply that Stellar already publishes. For a custodial app, it is the balances the app holds for its customers. Technical pages call what is owed the liabilities.

Coverage holds when reserves are at least what is owed.

One cycle, step by step

1. The reserve source reports the balances

Solva's orchestrator, the service that runs each cycle, asks the institution's reserve source for the balance of each reserve account. Each institution uses one of two kinds:

• Attested. The custodian signs each balance with its private key, and the orchestrator checks every signature against the custodian's public key. A balance with a bad signature stops the cycle. The signature shows who stated the balance and that nobody changed it on the way. It does not show that the money exists, so that trust sits with the custodian.
• Read on chain. For reserves held in Stellar accounts, the orchestrator reads each account's balance from the Stellar ledger. No custodian reports the figure.

2. The list of what is owed is committed

The orchestrator holds the institution's list of what it owes: one entry per customer, holding a hashed customer reference and a balance. No names go into the list. Today the list is stored when the institution is set up. Balance upload Coming soon lets an institution send a fresh list each cycle.

The prover folds the list into a single value called the commitment root. Every balance, and the total of all of them, is bound into that value. Changing one balance or dropping one customer changes the commitment root, and no balance can be read back out of it.

3. A zero-knowledge proof shows the reserves cover what is owed

The prover takes the reserve figures, the customer list and the commitment root, and builds a proof. The proof shows all of the following at once, without revealing any balance:

• Every balance in the list was counted, and none is negative.
• The list adds up to the total owed, and the commitment root stands for exactly that list.
• The reserve figures add up to the reserves total.
• The reserves total is at least the total owed.
• The reserves did not grow faster than the growth bound allows.

The growth bound. Reserves may grow by at most 10 percent from one record to the next. This limits how far a short-term inflow, moved in shortly before a cycle, can lift the reserves. Reserves may fall by any amount. The first record for a registry must state no growth at all, so there is no starting figure to inflate later.

4. A contract on Stellar checks the proof and keeps the record

The orchestrator sends the proof to the institution's registry. Only the registry's owner can publish to it. See Security.

The registry checks four things before it writes anything:

1. The proof is valid.
2. The reserves total is at least the total owed.
3. The previous reserves figure in the proof matches the reserves in the last record, so the growth bound measures from real history.
4. The publisher is the registry's owner.

If any check fails, nothing is written. If all pass, the registry writes a new record with the reserves total, the total owed, the commitment root and the time.

5. Anyone reads the record

The record is public on Stellar. Anyone reads it without an account and without asking the institution or Solva. A holder can also check that their own balance was counted.

What Solva does not do

• Solva does not hold reserves and cannot move money.
• Solva does not publish any customer balance.
• Solva does not check its own work. The contract on Stellar does.
• Solva does not edit a record. A new cycle adds a new one.

Next