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 seals its house edge into the payout odds at registration — never a separate fee — and the contract validates it inside a hard band when the tree is sealed, so no game can be quietly detuned in either direction. Games of pure chance run at ~1.5%: a fair coin flip would pay 2×; the pool pays 2 × (1 − 0.015) = 1.97×, and that missing 1.5% is the LP's return. Rule-transparent games (blackjack, classic baccarat) seal at their own natural edge — some under 1.1% at optimal play — because a sharp player can compute the edge from the visible rules, so the rules themselves are the honest quote. Each game page shows its exact sealed return, read from the tree on-chain.

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. 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.

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

Concretely: each roll is keccak256(serverSeed ‖ clientSeed ‖ channelId ‖ step) mod 10000 — the revealed seed, YOUR seed, the channel id, and the step number, nothing else. The roll walks the sealed tree: each chance node's children partition those 10,000 outcomes by their exact probabilities, and where the roll lands is what happened. At settlement the contract replays all of it and settles the recomputed net — it never trusts a number handed to it.

Every settled channel gets a proof page that re-runs the full verification in your browser — seed preimage, your signature over the exact stream, the hash-chain, every roll re-derived byte by byte, every payout walked from the on-chain tree, the caps, and the settled totals — against this site's RPC or any RPC you paste. Open any game on the games explorer and click through any recent round to its channel. The algorithm is verifyChannel in the published SDK — run it from a terminal for zero trust in this site.

What you still take on trust, stated plainly: the randomness beacon must not bias a seed it committed before seeing your play (it is one named, swappable party — the honest register lives in the entropy notes), and the house must settle the highest stream you signed — it provably cannot forge or reorder one. Peer-vs-peer arena matches carry a different, smaller story: no house entropy at all — both players commit hashes of their moves before either reveals, and their match page re-derives every commitment, the standings, both signatures, and exact pot conservation the same browser-side way.

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.

vault (game-tree)

0x88CddADA26386d39BDf79B67Fd02d9C0274ED5F9

USDC

0x2B3370eE501B4a559b57D449569354196457D8Ab

chain id

998 (HyperEVM testnet)

explorer

https://app.hyperliquid-testnet.xyz/explorer

Ready to build on it? The SDK quickstart takes you from an empty directory to a verified round.