How it works.

Liquidity providers deposit USDC and receive vPOOL shares representing their slice of pool equity. The pool is the counterparty to every bet: when a player wins, the pool pays; when a player loses, the stake accrues to the pool. Share price is netAssets / totalSupply, and it drifts up over many bets as the edge accrues — that drift is the LP's yield.

Deposits and withdrawals are priced conservatively against pending bets, so a new depositor can never skim expected value from a bet that is already in flight, and an exiting LP can never dodge one. Withdrawals clear after a short cooldown; the exiting position keeps absorbing P&L until it does.

Every game is quoted at a house edge — 150 bps, 1.50% — that is not a fee the operator collects but the LP's return, expressed as slightly worse-than-fair payout odds. On a fair coin flip the pool pays 2× × (1 − 0.015) on a win; the missing 1.5% is what the LPs earn over the long run.

Crucially, the edge is checked by the contract, not asserted by a frontend. A game only registers if the contract proves, over its entire payout structure, that it respects the edge. The player can read the same inequality and know the exact odds before staking. There is no configurable house-cut that grows behind the scenes.

The engine does not know what a slot, a blackjack hand, or a mines board is. It knows one primitive: a value tree whose nodes are chance draws, player decisions, or payout leaves. Any single-player game of pure chance — coin flip, dice, wheel, plinko, limbo, crash, mines, blackjack — compiles to one of these trees.

You register a tree once. At registration the contract runs backward induction over it and checks two things: every path respects the house edge, and the game can never pay out more than the pool has reserved for it. If either fails, the game will not register. This is why game creation needs no gatekeeper — there is no way to author a tree that drains the pool or cheats the player. The worst you can do is hand yourself the minimum-edge game.

chance

a weighted random branch, resolved by the revealed seed

decision

a player choice (hit/stand, dig/cash-out)

payout

a leaf that credits a multiple of the stake

Randomness comes from a seed the house commits to before you play and reveals only at settlement — a commit-reveal scheme, the same shape as any VRF. Because the commitment is on-chain and fixed in advance, the house cannot grind outcomes, and because the reveal is atomic at close, you cannot cherry-pick a favorable prefix. Neither side can move the result after the fact.

At settlement the contract replays the revealed seed through your tree, recomputes the true net, and settles that — it never trusts a number handed to it. Afterward, anyone can reconstruct the round purely from chain state and confirm it: the seed matches its commitment, the payouts match the tree, the net matches the settle. That is what verifyChannel does, and what every per-channel proof page renders.

commit(seed) fixed on-chain  →  play  →  reveal(seed)  →  contract replays  →  net

Playing opens a channel that escrows a bounded budget. However the rolls fall, the contract settles the net clamped to a [−budget, +liability] window it reserved up front: the player can never lose more than they escrowed, and the pool can never pay more than it set aside. Per-bet payout is additionally capped at a small fraction of pool equity, so a single settle can never move the LPs' position by more than that cap — no matter the game, no matter the seed.

This is the structural guarantee under everything else: solvency does not depend on the operator being honest or the game being well-behaved. It is arithmetic the contract enforces on every close.

The game-tree engine described here is deployed on HyperEVM testnet today; the mainnet deploy lands with the protocol's upgrade. Explore it now at testnet.variancevault.xyz/docs.