Why Solva settles on Stellar

People assume the interesting part of a system like ours is the cryptography. The proof gets the attention. But a proof that only the prover can check is not worth much. What decides whether any of this can be relied on is the verification, and verification happens on a chain. Choosing that chain was one of the more consequential calls we made, and it came down to three requirements that are not glamorous at all.

What a verifier has to do

A verifier has one job: take a proof and a handful of public values, run the check, and return true or false. Two things follow from that.

The chain has to run that check at a price that makes sense, and it has to let anyone, not only us, run it. If verification is expensive, nobody proves often. If verification is closed, you are back to trusting a status page. Either failure defeats the point of moving the check on-chain.

So the question was never which chain is popular. It was which chain lets a public contract verify one of our proofs cheaply, with final results, in the open.

The cost of re-checking

Frequent proving only works if re-checking costs almost nothing. We want institutions publishing fresh proofs on a steady schedule, and never rationing them because each verification costs real money. A chain where one verification burns a meaningful fee pushes everyone towards proving less, which is the opposite of what a coverage record needs.

On Stellar, one verification costs about 0.012 XLM, and the fee is predictable. That predictability matters as much as the number. An institution that publishes a proof every day needs to know what a month costs without modelling a fee market. Daily scheduled publishing for live institutions is coming soon; on Testnet today a cycle runs on request. The heavy arithmetic our verifier needs runs as a native operation inside the contract, instead of being emulated instruction by instruction. That is the difference between a verification that fits in a contract call and one that is too expensive to run on a schedule.

Finality you can quote

A coverage state is only useful if it is settled. "Probably verified, pending confirmation" is not a state you want a counterparty reading before they move funds.

Stellar gives deterministic finality. A proof we publish is settled within seconds, and after that it stays settled. There is no reorganisation to wait out before a result means anything. That lets us treat a published result as a fact with a ledger number, rather than a transaction we are still nervous about. When a wallet reads the latest result, it reads something the network has already agreed on. A one-call is_covered check for other contracts, such as a lending pool, is coming soon.

A verifier anyone can call

The part that matters most is the last one. The verifier is a public Soroban contract. Its code is open and it lives on the chain. It checks every proof before storing it, so a proof that fails never becomes a record. Anyone can read the stored result and check their own balance against it, with no Solva server involved. We could not fake a result if we wanted to, because the result is whatever the contract computes.

That is what lets us name exactly what you trust. The reserve figure comes from outside the proof: either a custodian-signed balance, whose signature Solva checks, or the balance of Stellar accounts read straight from the ledger. The proof checks the arithmetic and the commitment, not that the money exists. Real custodian connections are coming soon. For the arithmetic, you trust a contract you can read yourself.

let record = registry.get_latest_proof();
let counted = registry.verify_inclusion(id, id_hash, balance, path);

The first call returns the totals and the commitment, which the contract verified when the proof was published. The second lets a customer check their own balance against that commitment. Reading a record needs no permission. An auditor can do it. A counterparty can do it. A curious person with a script can do it. They all get the same answer, from a contract none of them has to take our word about. A standalone call to re-run the proof check is coming soon.

The plain conclusion

None of these three things is exciting on its own: cheap, final, public. Together they are the reason an on-chain coverage proof beats a signed PDF, and getting any one of them wrong would undermine the cryptography on top.

We picked Stellar because it lets all three hold at once. The proof is the clever part. The chain is what makes the proof mean something to someone who was not in the room when it was made.