Enforcing Solvency Invariants in an On-Chain Prediction Market
A Solana prediction market where a smart-contract solvency invariant, one YES plus one NO backed by one USDC, guarantees redemptions rather than trusting an operator.
settle.fun is a Polymarket-style prediction market built fully on-chain on Solana. Users mint conditional tokens by depositing USDC, trade them through a central limit order book, and redeem winning tokens for collateral once a market resolves. The whole thing hangs on one invariant, and getting that invariant right is the interesting part. You can try it at settle.fun.
The Invariant Is the Product
The rule the smart contract enforces is simple to state and unforgiving to violate: every YES token is backed 1:1 with a NO token and 1 USDC in the vault. As long as that holds, the vault always has exactly enough collateral to honor every possible redemption, no matter how the market resolves. Solvency stops being a thing you monitor and becomes a thing the contract makes impossible to break.
Traditional prediction markets lean on a centralized order book and off-chain settlement, which quietly reintroduces counterparty risk. You are trusting an operator to be solvent and honest at settlement time. Encoding the backing rule as an on-chain invariant removes that trust. The contract is the guarantee.
Escrow at Placement, Not at Fill
The second decision that makes the market trustless is when collateral gets locked. Every limit order locks its collateral immediately at placement, not at the moment it fills. That means when an order does match, the fill is guaranteed to succeed, because the funds were already escrowed. There is no window where a counterparty could place an order they cannot back.
Resolution is handled the same way. Market creators resolve outcomes on-chain, and redemptions then execute algorithmically against the vault. Because the tokens are standard SPL tokens, the conditional positions are composable with the rest of the Solana ecosystem rather than trapped inside one app.
Being Clear About the Stage
The README does not oversell this, and neither will I. The core market program is deployed and functional, and the on-chain order book with escrow is implemented. Frontend integration and indexer synchronization are still in progress. A security audit is pending and devnet testing is ongoing. It is explicitly not production ready: the notes call for a professional audit, devnet stress testing, upgrade authority moved to a multisig, and documented incident response before anyone points it at mainnet.
The takeaway is that in a financial contract, the strongest guarantees are the ones the code cannot break rather than the ones an operator promises to uphold. A 1:1:1 backing invariant and escrow-at-placement are both examples of the same move: turn a policy you would otherwise have to trust into a property the program enforces on every transaction.
Have something that needs building, or stabilizing?
These notes are the work log. The paid work runs through Moonshine Labs, my product and engineering studio. Tell us what you're building, or grab a call.
Work with us →