HeistJack: player versus player, never the house.

Abstract

HeistJack is a casino in which the operator never takes the other side of a bet, as operator does not exist. Everyone is equal. Every game matches players who put up their own stakes. A program on Solana holds those stakes, decides the result and pays the winner. The only revenue is a flat 1% fee on each settled pot.

That fee does not go to a company. It is spent buying HEIST, the protocol's token, on the open market, and the tokens bought are handed to the people who stake it. HEIST has a fixed maximum supply of 1,000,000, and 60% of it can only ever be earned by playing, on a halving schedule that rewards early players most.

This paper describes how each game works, how money moves, what is trusted and what is not, and how the token is issued and used. It is written to be read start to finish by someone who has never used a blockchain, and the awkward parts are in it too. Known trade-offs is the section to read before you put money in.

The problem

An online casino is a company that takes the other side of your bet. It wins when you lose. Everything else follows from that: the games are built with a fixed mathematical edge, the operator knows every card before you do, and you are trusting a private company with both your money and the outcome.

You cannot check any of it. You cannot see that the deck was shuffled fairly, that the random number generator was not nudged, or that the balance shown on your screen is backed by anything. When a withdrawal is slow, or declined, or an account is closed with a balance in it, there is no mechanism to appeal to, only a support ticket.

"Provably fair" sites improved one part of this. They let you check, after the fact, that a particular hand was dealt from a committed seed. But the house is still the counterparty, still holds the money, and still decides what the seed was.

HeistJack removes the counterparty instead of trying to make it honest. If nobody is playing against you except another player, there is no edge to hide, no incentive to rig anything, and nothing for a house to win.

The whole thing in plain words

Before the detail, here is the entire system in a page.

You connect a wallet, which is a piece of software that holds your money and signs approvals. There is no account, no password, and no deposit to a house balance.

You pick a game and a stake. Your stake moves from your wallet into an escrow: an account on the blockchain that belongs to nobody. It has no password and no owner. The only thing that can move money out of it is the program's own code, following rules that were published before you played.

Someone else matches your stake into the same escrow. You play. When the game finishes, the program reads the result, takes 1%, and sends the rest to the winner's wallet. There is no withdrawal step, because there was never a balance to withdraw from. The money goes straight from escrow to wallet.

Playing also earns you HEIST, the token, whether you won or lost. It is credited by how much you wagered. If you stake HEIST, the casino's 1% is used to buy more HEIST and give it to you.

That is the whole product. The rest of this paper is how each piece is built so that it cannot be cheated, including by us.

Design principles

Four rules decide every design question here. Where a feature would break one of them, the feature loses.

1. The house never has a hand

Every game is between players. The protocol's income is a percentage of settled pots, charged to the winner and the loser alike. It is the same whoever wins, which is what makes it safe to let us run the machinery.

2. Nothing that decides a result may exist before the money is locked

Cards, wheel positions and prices are all produced after the stakes are committed. If a number that decides a game could be known while anybody could still change their bet, that number is worthless.

3. Nobody has to come back

A game that needs both players online at the end is a game that can be held hostage. Every game here can be finished by anyone, so closing your laptop cannot cost you a pot you won.

4. We cannot reach the money

Stakes sit in program-controlled accounts with no withdraw function and no administrator. There is no code path, privileged or otherwise, that sends a stake anywhere except where the rules of the game send it.

Where your money sits

This is the part most worth understanding, because everything else depends on it.

On Solana, a program can own accounts whose addresses are derived mathematically from the program and some inputs, in our case things like the game's own identifier. Nobody holds a key to such an account. There is no private key in existence that controls it. The only way anything leaves is if the program itself authorises the transfer, and the program will only do that by following its published code.

So when you stake 0.1 SOL on a blackjack table, that 0.1 SOL is not "in your HeistJack account". It is in an escrow that exists for that one game, and the possible destinations are already fixed: the winner, both players on a push or a refund, and 1% to the fee account. There is no fourth option, and no human can add one without replacing the program itself. See What you are trusting.

Blackjack

Two players, two separate decks, no dealer. You are not trying to beat a house hand. You are trying to beat the other player's.

How a hand is played

1. You lock a stake. 0.02–10 SOL, or 1–1,000 USDT. Before this moment no card exists anywhere.
2. Your browser makes a secret. A random number nobody else sees, of which only a hash goes on the blockchain. A hash is a one-way fingerprint: it proves later that the secret has not changed, without revealing it now.
3. The program asks an outside oracle for a random value. It arrives a moment later, and the program mixes it with the hash of a recent block before storing it.
4. Your deck is built. From that stored value combined with your secret. Your opponent can read the stored value, which is public, but without your secret it tells them nothing.
5. You hit or stand. While you play, the chain records only how many cards you hold, never which ones.
6. Your table appears in the lobby. Another player matches your stake and plays their hand in the open.
7. The program settles it. Your secret is revealed, the program re-derives your hand itself, scores both, and pays.

The rules themselves

Jacks, queens and kings count 10. An ace counts 11 unless that would take you over 21, in which case it counts 1. Closest to 21 wins. Over 21 is a bust. Equal scores, or both players busting, is a push, and both stakes are returned minus the fee. There is no 3:2 blackjack bonus: a two-card 21 is worth exactly what any other 21 is worth.

Why your opponent cannot see your hand, and why you cannot lie about it

The commitment does both jobs at once, and the second is the one people miss.

Your opponent cannot work out your cards because they would need your secret, and it never leaves your browser while the hand is live. But equally, you cannot wriggle out of a bad hand. If your secret never surfaces, you forfeit the pot. If it does, the program re-derives your hand from it and rejects any secret that does not match the fingerprint you published before you saw a single card.

So the hidden hand is not a promise. It is a trap with a penalty on both sides: you cannot choose your cards, and you cannot disown them once you have seen them.

Where each new card comes from

When you hit, the card is taken from the hash of a block roughly four blocks in the future, a block that has not been produced yet at the moment you press the button. Nobody can know it, including us, and there is nothing to grind against. If that block is never produced, the program walks forward to the first one that was.

PvP Leonida Roulette

One shared wheel, up to twenty wallets per round, and no green zero, because there is no house position to pay for.

Your chance of winning is exactly your share of the pot. Stake a fifth of what is on the table and you own a fifth of the wheel. There are no numbers, colours or outside bets; there is one prize and your slice of the wheel is as big as your stake.

How a round runs

1. Players bet. 0.02–10 SOL per wallet. Repeat bets from one wallet merge into a single slice.
2. The countdown starts when the second player sits down. It runs for two minutes, once. Late bets are deliberately allowed: there is nothing to gain from them, because nothing about the result exists yet.
3. Entries close and the wheel is armed. Only now does the program ask for a random value, so no stake is ever placed after the deciding number exists.
4. The draw is mixed from two halves. The oracle's value and the hash of the block the round locked in, so neither the oracle nor a block producer holds both halves.
5. One lamport decides it. The draw picks a single unit out of the pot and pays whoever staked it.

That last step is worth a sentence on its own, because it is why the odds are exactly fair rather than approximately fair. The program does not compute percentages and round them. It picks one indivisible unit of the money on the table and finds whose stake it belongs to. If you put in 3% of the pot, exactly 3% of the units are yours.

If something goes wrong

Alone at the table for an hour: your whole stake comes back, with no fee. The oracle never answers: every stake is refunded in full. Nobody spins: the round voids and refunds. Spinning is permissionless, so any player can do it if our keeper is down.

Trading Duel

The same idea as a card table, played on price instead of cards. Both players receive an identical $1,000 of virtual money and trade real market prices for SOL, BTC and ETH. Whoever grows their bankroll more takes the pot.

Nothing is actually bought or sold. The virtual money is a scoring device. There is no leverage, no spread and no trading fee, so the only thing being compared is whether you called the market better than the other person.

How a duel runs

1. You stake and pick a window. How long each player gets to trade, from five minutes to seventy-two hours. Your opponent matches both.
2. You have 24 hours to place your first trade. That trade starts your own window.
3. The two windows run independently. You never wait on your opponent and you never have to be online at the same time.
4. Trading stops a few seconds before your window closes. The closing price therefore cannot be known while you can still act on it.
5. Both windows closed, the program compares equity. It pays the higher one.

A trade carries no price

This is the subtle part, and it was changed after a player pointed out the flaw in the original design.

If a trade is filled at the price that existed when you signed it, you have a free option: sign the transaction, watch the market for a few seconds, and send it only if the move went your way. Rebuilding it renews the option indefinitely.

So a trade now carries no price at all. It records only that you traded and when. The price it gets is the first quote published after it lands, a price that did not exist when you signed, and therefore cannot be chosen by waiting. And because the earliest valid quote wins, sitting on a quote you prefer is pointless: anyone holding the true first one overrules you.

If somebody never trades

A player who never opens a position loses to one who did. If neither trades, both stakes are returned minus the fee.

The Lottery

One ticket, one price, one winner a week. A ticket costs 1 HEIST, every ticket sold in a week goes into one pot, and when the week ends a single ticket number takes the lot.

Your chance is the plainest arithmetic in this paper: own a hundred of the thousand tickets sold and you win one time in ten. There are no numbers to pick, no lines, no bonus ball and nothing to get right. A ticket is a number the program hands out in order as tickets are bought, and one of those numbers is drawn.

It is also the only game here that is not player-against-player, and the only one whose fee is not 1%. The house puts 200 HEIST into every pot before anybody buys a ticket, and takes 5% of the pot when it is paid out. On any week where fewer than four thousand tickets sell, that trade favours the players: the 200 HEIST going in is worth more than the 5% coming out.

How a draw runs

1. A draw opens by itself. Each one covers a seven-day period, and which draw is open at any moment is arithmetic on the clock rather than a decision anybody makes.
2. You buy tickets. Up to ten thousand in one transaction, as many transactions as you like. Your HEIST goes into the draw's own escrow, and the ticket numbers you were given are recorded against your wallet.
3. The period ends and the draw is armed. Only then does the program ask for a random value, so no ticket is ever sold after the deciding number exists.
4. The draw is mixed from two halves. The oracle's value and the hash of the block the draw locked in — the same construction the wheel uses, so neither the oracle nor a block producer holds both halves.
5. One ticket number is picked and paid. The winner receives the whole pot less the 5%.

The 200 HEIST is minted, and that is the point

The house's contribution is not taken from fees or from a treasury. It is minted out of the same 600,000 HEIST that can only be earned by playing — so every pot is paid for out of the farming allocation, counts against it, and is capped by it exactly as a game's own HEIST rewards are. Nothing is created that was not already promised to players.

The consequence worth stating: the prize comes from the supply that would otherwise have been farmed, so a week of lottery pots is a week of slightly slower farming for everybody. It is a redistribution within the same fixed allocation, never an addition to it.

Nobody picks the number, including us

A draw's winning number is a function of the oracle's value, the block hash of the lock, and how many tickets were sold. Every one of those is on the chain, which means anybody can recompute a finished draw from its own account and check that the ticket that was paid is the ticket the arithmetic names. No part of it is ours to choose and no part of it is ours to withhold — arming a draw and drawing it are both permissionless, so if our keeper is down any player can do either.

If something goes wrong

Nobody bought a ticket: the draw simply voids, the 200 HEIST is never minted and nothing is owed. The oracle never answers: every ticket is refunded in full in HEIST, with no fee. Nobody arms the draw within an hour of the period ending: the same full refund, and until that hour is up any player can arm it instead. The winner's HEIST account has been closed or frozen: the prize stays in the escrow and a permissionless claim pays it the moment that account can receive again — it is never forfeited and it can never be paid to anybody else.

The Horse Race

Twenty lanes, 0.05 SOL a lane, one winner. Buy a lane and you have a horse in the race; buy four and you have four. Every horse is identical, so a lane is simply a share of the pot wearing a name and a set of silks.

It is the wheel's arithmetic with a different picture over it, and deliberately so: your chance of winning is your lanes divided by the lanes sold, exactly, because the program picks one lane out of the field rather than computing a percentage and rounding it.

The race you watch afterwards is a replay, not a simulation. The result exists the instant the card is run; the animation reads it back off the chain and draws it, which is why every viewer sees the same horse win and why a finished card can be replayed years later from its own record.

How a race runs

1. Players buy lanes. One horse per 0.05 SOL, up to twenty lanes on a card. Repeat purchases by one wallet are separate horses, because a lane is a runner rather than a slice.
2. The countdown starts when a second wallet joins. Three minutes, once. It also ends early the moment all twenty lanes are gone.
3. The gates close and the card is armed. Only now does the program ask for a random value, so no lane is ever bought after the deciding number exists.
4. The draw is mixed from two halves — the oracle's value and the hash of the block the card locked in.
5. One lane is picked and paid. The winner takes the pot less the 1% fee and less the half-thousandth of a SOL the card paid the oracle.

That last subtraction is small and it is worth naming rather than rounding away: arming a card costs the oracle 0.0005 SOL, and the card pays it out of its own pot rather than charging it to whoever pressed the button. On a full twenty-lane card that is a twentieth of one percent. On the smallest possible card it is more than the house fee.

If something goes wrong

Alone on the card for an hour: your whole stake comes back, with no fee, and anybody can trigger it. The oracle never answers: every lane is refunded in full. Nobody arms the card within an hour of the countdown ending: the same full refund. A card nobody ever finished: swept and refunded after a week. Running a card is permissionless, so a player can do it if our keeper is down.

Where the randomness comes from

Two things decide a card: a value from an outside oracle, and a block hash. Neither party can produce the result alone, and that is the point.

The oracle is a verifiable random function. It produces a number together with a proof that the number is the only one it could have produced for that request. It cannot pick a convenient answer, because any other answer fails its own proof.

But an oracle is still a third party, so the program does not use its value raw. It mixes it with the hash of a block, which is produced by Solana's validators, a completely different set of people with no relationship to the oracle. To influence the outcome you would need to control both at once.

And all of this happens only after the stakes are locked. The request is not even sent until the money is committed, so there is no window in which a result exists and a bet can still be changed.

Where the prices come from

Street Duels need prices, and a price is just as manipulable as a card if it comes from the wrong place.

The anchor is Pyth, an oracle whose prices are published by the exchanges and market makers themselves rather than scraped by intermediaries. Its updates arrive already signed and verified by the time our program reads them, so a duel simply reads an account.

Pyth publishes on a timer, which for some assets means tens of seconds between updates. That is too slow for a screen showing live profit and loss, so we also publish our own faster price tick, signed by us.

A price signed by the house would ordinarily be a serious problem, so it is bounded: the program accepts our tick only if it agrees with Pyth to within a narrow band. Our tick can sharpen Pyth's price by a basis point or two; it cannot invent one. If it ever falls outside the band, the trade simply fills at Pyth instead. Every tick we sign is archived, so one that ever strayed could be checked afterwards against public exchange data.

The house also has no side in a duel, since the 1% is charged whoever wins, so there is nothing a crooked price could earn us.

Settlement, timers and walkaways

A casino where a game can get stuck is a casino that holds your money. Every way a game can stall has a timer, and every timer resolves without anyone's cooperation.

Settling is automatic, and anyone can do it

When a game finishes, our keeper sends the settling transaction within seconds and the program pays the winner out of escrow. Because settling is permissionless, that keeper is a convenience rather than a dependency: any player can send the same transaction if ours is down, and the program behaves identically.

The timers

• Nobody joins your table: reclaim your whole stake, with no fee.
• A player goes idle mid-hand: they are stood automatically on the cards they already hold.
• A hidden hand is never revealed: that player forfeits and the opponent takes the pot.
• A card is drawn but never recorded: scored as a bust, so stalling on a bad card never pays.
• The oracle never answers: every stake refunded in full, no fee.
• A duel side never trades: loses to a side that did; if neither traded, both are refunded.

Every one of these can be triggered by anybody. None of them requires us.

The 1% fee

One number, charged once, on the settled pot. It is the entire house edge on every game but one: the weekly lottery takes 5%, the four extra points paying back the 200 HEIST the house pre-fills each draw with.

There is no dealer advantage, because there is no dealer. No rake on top. No spread on duel trades. No withdrawal fee, because there are no withdrawals. A push is charged the same 1% as a win, which is the one place the fee is charged on a game nobody won.

For comparison, the edge a conventional casino holds on blackjack comes from rules such as the dealer acting last, ties on 22 and 6:5 payouts, and is usually larger than 1% before any rake. Here the arithmetic of the game is symmetrical between the two players and the 1% is the whole of it.

The fee is paid into an account owned by the buyback program, not by us, and the only thing it can be spent on is buying HEIST. See The buyback.

Rent: the deposit you get back

This confuses almost everybody the first time, so it gets its own section.

Solana charges a deposit to keep an account stored on the network. It is called rent, which is misleading, because it is refundable rather than spent. Creating a game locks a small amount of SOL for as long as that game exists, and the program returns it when the finished game is closed.

Your very first game also creates two small permanent accounts of your own, which track your statistics and the HEIST you have earned. That is a one-time cost, and they are reused by every game you ever play afterwards.

So a wallet needs slightly more than the stake: the stake, the refundable rent, and a fraction of a cent in network fees.

The HEIST token

HEIST is the token that owns the casino's revenue.

Two of those rows matter more than the rest.

There is no freeze authority. On Solana a token can be created with an authority that lets somebody freeze any holder's balance. HEIST was created without one, and that is permanent. It cannot be added later by anyone, including us. Nobody can freeze your tokens.

Nobody can print more. The authority to mint belongs to the program, not to a person, and the program will only mint what a player has already earned by wagering. The 600,000 farming allocation is a ceiling in the code, not a policy.

Earning HEIST by playing

Every settled game credits HEIST to both players, by the dollar value they wagered. Winning is not required. The loser of a hand earns exactly what the winner earns on the same stake.

This is deliberate. Rewarding volume rather than results means the token goes to the people who used the casino, not to the people who happened to run well.

The halving schedule

Earning starts generous and gets harder. Each epoch pays out half as much per dollar wagered as the one before it, and an epoch ends when a fixed amount of cumulative volume has passed through the casino. Early players earn the most, and the final tokens are the hardest to mine, the same shape as Bitcoin's issuance, applied to wagering instead of hashing.

Earned HEIST accumulates to your wallet's own record and is claimed when you choose. It is not minted until you claim it.

Staking

Staking HEIST is how you receive the casino's revenue.

You deposit HEIST and receive xHEIST, a second token representing your share of the staking pool. There is no claim button and no reward schedule. When the buyback deposits HEIST into the pool, the pool gets bigger while the number of xHEIST stays the same, so each xHEIST is simply worth more HEIST than it was.

The exchange rate is never stored anywhere. It is computed, every time, as the HEIST in the vault divided by the xHEIST in existence. That means there is no number for anyone to set, and anything that adds HEIST to the vault, whether the buyback or a plain donation from a stranger, raises the value of everybody's stake automatically.

Unstaking takes seven days

When you unstake, your xHEIST is burned immediately and the amount of HEIST you are owed is fixed at that moment. The HEIST itself becomes available a week later.

The week is deliberate. Without it, somebody could stake just before a large buyback, capture a share of it, and leave, taking value from people who carried the position all month. The cooldown makes that strategy cost a week of exposure, which is longer than the advantage is worth. If you want out immediately, you can sell xHEIST on the open market instead; the cooldown restricts redemption, not trading.

The buyback

The fee reaches stakers through a program that can do exactly one thing: convert the fees into HEIST and deposit them into the staking vault.

Fees arrive in SOL and USDT. HEIST trades against cbBTC. So the route runs in legs: USDT to SOL, SOL to cbBTC, cbBTC to HEIST. The HEIST is then transferred into the staking vault. Each leg is a separate transaction, so a failure leaves the treasury holding an intermediate asset rather than half-routed, and the next attempt simply picks up where it stopped.

What stops a permissionless buyback being robbed

Anyone may turn the crank; nothing about it is privileged, and there is no reward for doing so. That openness needs guarding, and it is guarded in several ways at once.

• The destination accounts are pinned. The output of every swap goes to the protocol's own account, named in the code. A caller cannot redirect it.
• The pools are pinned, and a change to them ripens for an hour before it can take effect.
• The minimum output is computed by the program from the Pyth oracle, not supplied by the caller, so nobody can quote themselves a price.
• Balances are measured before and after, because a swap that does not revert has not necessarily done what was asked.
• The HEIST leg is bounded by size, not by price. One purchase may spend a capped amount, and the next cannot follow immediately.

That last one deserves its reasoning. A price bound protects a treasury by refusing to trade when the pool looks wrong, which means the buyback visibly stops exactly when people are watching it, and a desk that does nothing for hours while fees pile up reads as broken. So there is no price ceiling at all. What bounds a manipulator instead is that the prize is small and slow: shoving the pool wins at most one capped purchase, against the fees they pay on their own much larger shove and the arbitrage that answers it.

There is no withdraw instruction anywhere in the program. The fees cannot be sent to a person. They can only go through the route and into the vault.

Governance

Depositing xHEIST gives voting weight. A proposal requires a meaningful stake to open, the cost of opening further concurrent proposals rises, and there is a cap on how many one holder may have open at once, so the queue cannot be flooded by one person with a single qualifying deposit.

A deposit is locked while it has a live vote or an unfinished proposal attached to it, which stops the same tokens voting twice by moving between wallets. Withdrawing a vote during the voting period removes it from the tally; doing so afterwards only unlocks the deposit.

Governance decides parameters and direction. It does not have a key to the money, because no such key exists.

Leaderboard

Every settled game is recorded against both players in US dollars, fixed at the value at the moment it settled, so a board is not rewritten by later price moves.

Nobody is filtered out. Not bots, not market makers, not our own wallets. Anyone can and will run bots; a leaderboard that quietly removed the accounts somebody disapproved of would be a leaderboard somebody is curating. All play is visible, and that is the point of publishing it.

What you are trusting

Most of this paper describes things you do not have to trust. This section is the remainder, stated plainly.

You are not trusting us with your money

Stakes are in escrows no key controls. There is no withdraw function. The program cannot send your stake anywhere except where the rules of the game send it, and it will finish a game whether or not we are running.

You are trusting us not to replace the program

The program is upgradeable, and we hold that authority. It is how new games ship and how bugs get fixed, and it is the single largest thing you are trusting us with. A replaced program could do anything a program can do. The intention is to give the authority up once the games stop changing; until then it is a real risk and it is better known than discovered.

Known trade-offs

Decisions that cost something, and what they bought.

A block producer who plays has a small edge on hits

A hit's card comes from a future block's hash. Whoever produces that block influences its contents and therefore the hash. A player who also produces blocks could, at considerable expense, grind their own card. Closing it entirely would need a separate oracle request for every hit, which would cost more than most hands are worth. The deal, which decides far more than any single hit, does use the oracle.

Virtual bankrolls, not real trades

A duel is scored on simulated fills, so it has no market impact and no liquidity constraints. That is what makes a $1,000 bankroll meaningful on a 0.02 SOL stake, and it means duel performance is not the same as trading performance.

A push still pays the fee

Two players tie and the protocol still takes 1%. Charging nothing would make a push the cheapest way to generate free volume, and the 1% fee is taken because the game was finished anyway.

How this is tested

The program is covered by an automated test suite that runs on every change, and by batteries of adversarial tests that fire deliberately malicious transactions at the deployed program and check each one is refused for the expected reason: stealing another player's payout, settling a game you are not in, redirecting the fee, farming tokens without authority, substituting a token of your own, and so on.

Beyond that, the codebase is swept periodically by reviews organised by technique rather than by feature. One pass over arithmetic and rounding everywhere, one over account validation everywhere, one over timing and clocks, because defects cluster by kind, not by file. Findings are given to independent reviewers instructed to refute them by default, and only what survives is acted on.

Verify it yourself

Nothing in this paper has to be taken on trust. Every game that has settled can be re-derived from public data by anybody, and this section is how.

The shape is the same in every game: the numbers that decided the result were published after the money was committed and before anyone could act on them, and the rule for combining them was fixed in advance. Fetch the inputs, apply the rule, compare with what was paid.

The short way: paste the address

Everything in this section can be done by hand, and it can also be done for you. heistjack.fun/#verify takes a blackjack game's address, fetches the account, rebuilds both decks from the published random value and the revealed secret, and prints every check it ran, passed or failed, with the cards it derived beside the cards the chain recorded. It shows its working rather than a verdict, so a disagreement is visible rather than hidden behind a tick.

The window the rent closes

There is one real limit here and it is better known in advance than discovered. A finished game's account is closed about half a minute after it settles so that its rent deposit goes back to the player who paid it, and a closed account is gone: its bytes are no longer on the chain for anybody, us included. To check a game against the blockchain itself, and nothing else, you have to do it inside that window.

Because a minute is not long enough to be useful, the keeper writes the settled account's own bytes, and the revealed secret with them, into our database before it allows the game to close, and keeps them for a year. The verify page reads that copy when the account has gone and says on screen that it has. Be clear about what the copy is worth: it is our copy, so re-deriving an old hand from it means trusting that we stored it faithfully. That is a trust assumption and we are not going to dress it up as anything else.

What does not depend on us either way is the money. The settling transaction stays in Solana's history permanently and shows the stakes going into escrow, the winner's transfer coming out and the 1% fee, all independently readable years later. So the payment is always verifiable without us; after the account is closed, it is only the cards that rest on our copy.

Blackjack

Four things decided the hand, and all four are public once the game has settled: the oracle's random value, the hash of the block it was mixed with, the hashes of the blocks each hit drew from, and Player 1's revealed secret.

1. Check the commitment. Hash the revealed secret and compare it with the hash published in the transaction that created the game. They must match, and because that hash was on chain before the oracle had answered, the secret cannot have been chosen to suit the cards.
2. Rebuild the deck. Combine the stored random value with the secret and shuffle. That is Player 1's deck.
3. Replay the hits. Each card drawn after the deal came from the hash of a specific later block, recorded against the game. Fetch those blocks and apply the same derivation.
4. Score both hands and compare with the payout. The winner's transfer and the 1% fee are explicit transfers in the settling transaction.

Player 2's hand needs no secret, because it was public from the start, so it checks the same way with the first step skipped.

PvP Leonida Roulette

Simpler, because there is only one number to check.

1. Confirm the value came after betting closed. The request is made in the transaction that closes entries, and the program records the block it happened in. No stake can appear after that.
2. Rebuild the draw. Combine the oracle's value with the hash of that block.
3. Find the winning unit. Take the draw modulo the pot, then walk the stakes in order adding them up. The player whose running total first passes that number won.
4. Check the payout. The winner receives the escrow's balance less 1% of the staked pot. That balance also carries the oracle's fixed fee for the draw, and anything anyone sent to the escrow address, which goes to the winner rather than to us.

Each player's chance is their stake divided by the pot, with no rounding at all, because the draw selects one indivisible unit rather than computing a percentage.

Street Duels

1. Check each fill came after its trade. A trade records only that it happened and when; the price is written in by a separate transaction anybody can send. The price must be the later of the two.
2. Check the price against Pyth. Every fill is bounded by the oracle's own published value. One that disagrees with Pyth, is stale, or is signed by the wrong key is refused by the program outright.
3. Replay the book. Apply each trade in order to the $1,000 starting bankroll, mark any open position at the recorded closing price, and compare the equity with the one the program settled on.

What you are actually checking

That the numbers which decided your game existed after your money was committed and before anybody could act on them, and that the arithmetic applied to them was published in advance. If both hold, there was no room for anyone, whether a player, the oracle, a validator or us, to choose the result.

A hand still in progress cannot be verified this way, by design: card values are not written on chain until settlement. That is the same property that keeps them hidden from your opponent.

Addresses

The permanent on-chain identities. Everything else in the system is derived from these, so they are the only ones worth writing down, and the only ones you should ever trust. Verify any address you are given against this list or against the website.

No figures for price, supply in circulation or volume appear anywhere in this paper. They change, and a document cannot. The website publishes them live.

Glossary

Plain definitions for the words this paper could not avoid.