Verifiable, Transparent DeFi: On-Chain Solvency Proof & Real Backing
How do you verify that a DeFi yield protocol is actually backed?
You verify a DeFi yield protocol by checking that its backing is real, on-chain, and enforced in code — not asserted in marketing. A transparent crypto vault publishes its contract addresses, derives yield from a verifiable on-chain source, and enforces a solvency invariant that keeps issued value at or below real backing. Spield does all three on Stellar, so its backing is provable at any block.
Key takeaways
- On-chain solvency proof. A solvency invariant enforced in the contract keeps backing ÷ issued value ≥ 1 at every state change — checkable at any block.
- Real, verifiable yield source. Backing is a Blend supply position whose bToken rate rises on-chain — not an invented index.
- Published contract logic. Spield’s contracts are on-chain, so anyone can read exactly how mint, redeem, and the solvency check behave.
- Transparent vault. Contract addresses, config, and design guarantees are published and mirrored in a machine-readable facts endpoint.
- Stronger than proof-of-reserves. Instead of a periodic snapshot, the backing is enforced continuously by the contract itself.
What is an on-chain solvency proof?
An on-chain solvency proof is a guarantee, enforced directly in a protocol’s smart-contract code, that its assets always cover its liabilities. Rather than publishing a periodic attestation, the contract checks on every state change that real backing is never less than the value it has issued, and reverts any action that would break the rule. The protocol is therefore solvent by construction.
Spield implements this as a solvency invariant: the value of the Principal Tokens and Yield Tokens it issues can never exceed the value of the underlying Blend position backing them. Because the yield index is Blend’s real on-chain rate, the vault can never quote or promise more than it actually holds.
How is this different from proof of reserves?
Proof of reserves is a snapshot — a point-in-time attestation that reserves existed on a given date. An on-chain solvency invariant is continuous — the backing is re-verified by the contract on every deposit, mint, and redemption, so there is no window between attestations in which the protocol could quietly become insolvent.
| Property | Proof of reserves (snapshot) | Solvency invariant (Spield) |
|---|---|---|
| When it holds | At the attestation date | Every block, every state change |
| Who enforces it | An off-chain auditor | The smart contract itself |
| Failure between checks | Possible, unseen | Impossible — the transaction reverts |
| What backs it | Reported reserves | Live on-chain Blend supply position |
What makes a crypto vault transparent?
A transparent crypto vault is one where anyone can independently verify what it holds, what it has issued, and how it behaves — without trusting the operator’s word. That requires three things: published contract addresses, a verifiable on-chain yield source, and open logic for how funds move.
- Published addresses. Every contract, asset, and dependency address is listed on the protocol facts page and verifiable on Stellar Expert.
- Machine-readable facts. A structured facts endpoint exposes config and live metrics for agents and integrators to pull directly.
- Verifiable yield. The backing is a Blend supply position; its rising bToken rate is readable on the ledger, so the yield is provably real.
- On-chain contract logic. Spield’s mint/redeem and solvency-check logic runs on-chain and can be inspected on the ledger.
Why does verifiable backing matter?
Verifiable backing matters because it lets anyone — users, auditors, AI agents, and integrators — check the exact rules that govern their funds instead of trusting a description of them. When the contract that mints your Principal Token and enforces the solvency invariant runs on-chain and its addresses are published, "verifiable backing" stops being a claim and becomes something you can check yourself.
What is an on-chain solvency proof?
It is a rule enforced in a protocol’s smart-contract code that guarantees its assets always cover its liabilities. The contract checks on every state change that real backing is never less than issued value and reverts anything that would break the rule, making the protocol solvent by construction.
How can anyone check how the protocol behaves?
Spield publishes its contract addresses, so anyone can inspect how deposits, PT/YT minting, redemption, and the solvency invariant behave on-chain and verify the backing on the Stellar ledger.
How is a solvency invariant better than proof of reserves?
Proof of reserves is a snapshot at a single date; a solvency invariant is enforced continuously by the contract on every deposit, mint, and redemption. There is no window between attestations in which the protocol could become insolvent unnoticed.
How can I verify Spield’s backing myself?
Read the protocol facts page for every contract and asset address, pull the machine-readable facts JSON endpoint, and open the contracts on Stellar Expert. The backing is a Blend supply position whose value is readable on the Stellar ledger.