Skip to content
Solva
Solva
Talk to usWaitlist

How it works

How a coverage record is made.

Solva measures what an anchor or custodial app holds against what it owes, asks a contract on Stellar to check the proof, and writes the result where anyone can read it. Five steps for every asset, designed to run every day.

See it workTalk to us
Five steps complete and a record written
RecordStep 5 of 5

Kestrel Anchor · ARSK

ExampleLedger 3,412,088One proof per asset per day

The five steps

From a list of balances to a public record.

The same five steps are designed to run every day for every asset; on Testnet today a cycle runs on request. The home page shows them in motion. This page walks through each one, with the evidence beside it.

  1. Balances

    What is owed enters as a list of balances.

    A custodial app's customers, or an anchor's token holders. The list is the private input to everything that follows. No balance on it is ever published. Today Solva holds the list and passes it to its prover over a private connection.

    row 1row 2row 3row 4row 5row 6row 7row 8every row private · 0 published

    ExampleNo balance published

    For an anchor
    What is owed is a stored list of holder balances. Reading the token supply straight from Stellar at the record's ledger is coming soon.
    For a custodial app
    What is owed is the list of customer balances the app commits that day.
    Published
    Nothing from the list. Today Solva holds the list and passes it to its prover over a private connection; no balance is written anywhere public.

  2. Commit

    The list is folded into one commitment.

    The commitment stands for every balance on the list and for their total. Drop a balance or change one, and the commitment changes with it, so nothing can be left out or edited after the fact.

    commitmentone commitment · total carried with it

    ExampleOne commitmentTotal carried with it

    Commitment
    One value that stands for the whole list and its total. Change a single balance, and the commitment changes with it.
    Published
    The commitment and the total. Never the list.
    Holder check
    A customer can confirm that their own balance sits behind the commitment. No other customer is named; the path shows unnamed subtotals, including one neighbouring balance.

  3. Proof

    A proof shows the total is covered.

    The proof takes the commitment and the reserve balance and shows that what is owed is at most what the reserve accounts hold. No balance is a public input, so none is published. It is small enough for a contract on Stellar to check in one call. The proof system's hiding mode is in development.

    commitment + reserve balance → proofproofonenever publishedevery balance on the listpublic: the totals and the resultsmall enough for a contract to check

    ExampleNo balance publishedTotals public

    What it proves
    Every balance on the list was counted, none is negative, and the total is at most the reserve balance.
    What it publishes
    Only the totals and the commitment. No balance is a public input. The proof system's hiding mode is in development.
    Who checks it
    A contract on Stellar. Solva never checks its own work. The next step shows the contract on Testnet.
    The detail
    How the proof is built is set out in the documentation, alongside the source code.

  4. Verify

    A contract on Stellar checks the proof itself.

    The verifier contract runs the check on the network itself, so no server and no company has to be trusted with the answer. One verification on Testnet cost the fee shown here.

    verifiedledger3,191,042fee0.0122514 XLMchecked bythe contractstellar testnet · checked on the network

    Stellar TestnetLedger 3,191,0420.0122514 XLM

    Verifier contract

    CA3KQYYAGU…CXWXN3

    Stellar Testnet

    Verified transaction

    de9c70fcf6…ed2901

    Ledger 3,191,042

    Ledger

    3,191,042

    where the contract checked the proof

    Fee

    0.0122514

    XLM, 122,514 stroops

    Who is trusted
    Nobody. The contract checks the proof itself, on the network. Anyone can open the transaction where it was verified and rerun the open-source verifier on the same proof.
    Outcome
    A proof that fails to verify writes nothing. Reserves below what is owed produce no proof at all, so a shortfall can never be written as covered. A proof that verifies stores both totals at that ledger.

    Stellar TestnetLinks open stellar.expert

  5. Record

    The result is written once, for anyone to read.

    The verified totals are written once, with the ledger they were checked at. Holders, wallets, lending pools and auditors read them without asking anyone. Each new proof adds the next line, and nothing is edited after the fact. Covered, short and stale labels on each record are coming soon.

    coverage record · 2026-11-02103.61%COVEREDkestrel anchor · ARSKledger 3,412,088written once · read by anyone

    ExampleKestrel Anchor · ARSKLedger 3,412,088

    Three states, nothing in betweenComing soon

    • Covered

      Reserves were at least what was owed at that ledger.

      The record shows the percentage and the surplus. It describes that ledger only; the next day needs its own proof.

    • Short

      Reserves were less than what was owed.

      The record shows the gap in full. The percentage is cut off, never rounded up, so 98.999% reads as 98.99%.

    • Stale

      No recent proof. Treat coverage as unknown.

      Whatever the last result said no longer counts until a new proof is recorded.

    Cadence

    Designed to run daily by default, or on the schedule the institution agrees. Each result names a Stellar ledger, so it carries a time anyone can look up. When a proof does not arrive on schedule, the record will turn stale by itself. Scheduled publishing and freshness checks are coming soon; on Testnet today a cycle runs on request.

    Proof schedule for ARSK

    Daily, 06:00 UTC

    The last seven daily results for ARSK
    DateCoverageState
    2026-11-02103.61%Covered
    2026-11-01104.40%Covered
    2026-10-31104.80%Covered
    2026-10-30105.20%Covered
    2026-10-29105.60%Covered
    2026-10-28106.00%Covered
    2026-10-27102.30%Covered

    In this example the next proof is due at 06:00 UTC, and if it does not arrive the record turns stale. Scheduled publishing and freshness checks are coming soon.

    ExampleKestrel Anchor · ARSKLast 7 days

Boundaries

What Solva never does.

A record is precise about its own limits. These four rules hold on every check, for every asset.

  • Solva never holds your funds

    Your reserves stay in your own reserve accounts, wherever you keep them. Solva works from the reserve balance, signed by your custodian or read from Stellar, and has no way to move money.

  • Solva never publishes a customer's balance

    The record shows totals only. No customer is named and no list of balances is ever published. A customer's own check shows unnamed subtotals, including one neighbouring balance.

  • Solva never rounds coverage up

    The percentage is cut off at two decimals. A reserve that is 99.999% of what is owed reads as 99.99%, and no proof of coverage can be made.

  • Solva never edits a record

    Each result is written at a ledger and stays there. The next proof adds the next result. Showing a missed proof as stale is coming soon.

Further reading

The deeper detail lives in the docs.

For institutions

Put an asset on the record.

Tell us which asset you issue or hold for customers. We plan a pilot with you and publish your first record together.

Talk to us

For readers

Read a record.

See what a holder, a wallet, a lending pool or an auditor sees, and how one record answers the question each of them asks.

The coverage record