Read an On-Chain Casino's Contract Before You Deposit
- Written by
- the BitcoinCasinoID desk
- Last checked
- Method
- Four checks, no score
An on-chain casino replaces the operator's promise with code, and the promise it keeps is whatever the code says rather than whatever the website says.
19+. Some links on this page are affiliate links: the operator may pay us a commission if you open an account. It costs you nothing and does not change the order of any list. Terms move; the operator's own page is the final word. How we rate
That is a genuine improvement over trusting a custodial operator — but only if somebody reads the code. The useful news is that the questions worth asking can be answered from a block explorer without being able to write a line of Solidity, because they are mostly about who holds what power rather than about the game logic.
On this page4
Start with whether the contract is verified at all
On most explorers, a contract address shows either human-readable source code or a block of bytecode. Verified source means the published code has been compiled and matched against what is deployed on chain, so you are reading what actually runs. Unverified bytecode means you are reading nothing: the site's claims about its own contract cannot be checked, and no further question below is answerable. An unverified gambling contract is a custodial operator with extra steps.
Also confirm that the address the website gives you is the address you are depositing to. A link from the site to the explorer is convenient and not evidence; the address in your wallet's confirmation screen is the one that matters.
The five questions that decide everything
1. Is it upgradeable, and who can upgrade it?
A proxy pattern means the code you read today can be replaced tomorrow by whoever holds the upgrade rights, with no warning and no action from you. Explorers label proxy contracts and show the implementation address. An upgradeable contract controlled by a single address is, in practice, a promise again — a better-documented one, but a promise.
What to look for instead: an immutable contract, or an upgrade path controlled by a timelock that forces a public delay between an announced change and its taking effect, which at least gives you time to withdraw.
2. What can the owner do?
Read the functions that carry an access restriction. The ones that matter have recognisable names: a function that pauses the contract, one that withdraws the treasury, one that changes the house edge or the payout parameters, one that sets fees, one that blacklists addresses, one that transfers ownership. Each is a power held over your funds. A contract where the owner can pause withdrawals and move the treasury has the same failure mode as a custodial casino.
Then check who the owner is. A single externally owned account is one compromised key away from everything. A multi-signature wallet is better, and the number of signers and the threshold are visible on chain.
3. Where does the stake live during a bet?
Three arrangements exist. The stake stays in your wallet and only the settlement moves — the best case and the rarest. The stake moves into the contract for the duration of the bet and settles automatically. Or you deposit a balance into the contract and play against it, which is custody with a smart-contract wrapper: the contract holds your money between sessions, and the owner-powers question becomes the whole question.
4. How is randomness produced, and what is the fallback?
The source matters and so does the failure path. If the randomness provider does not respond, what happens to a pending bet — is there a timeout that refunds you, or can a bet sit unresolved indefinitely? A contract with no refund path on a failed draw has a way to keep your stake without anyone deciding to.
5. Is the bankroll adequate and visible?
The contract's balance is public, and so is the maximum payout it allows. A maximum win larger than the bankroll means a winning bet cannot be paid, and the arithmetic is yours to do: look at the contract's holdings, look at the stated maximum payout, and ask whether the second is covered by the first. Many on-chain casinos cap the maximum bet as a fraction of the bankroll precisely to make this safe — a published cap of that kind is a good sign.
What an audit does and does not tell you
A published audit from a recognised firm is worth having and is routinely overstated. Read the scope section: an audit covers specific contracts at a specific commit, and a later upgrade is outside it. Read the findings rather than the summary, and check whether the issues raised were fixed or acknowledged. And note what no audit covers — the economics. An audited contract can implement a brutal house edge perfectly.
The checks in order, for a deposit you are about to make
- Confirm the address in your own wallet prompt, not on the site.
- Open it on an explorer; confirm the source is verified.
- Check for a proxy and find who can upgrade it.
- List the owner-only functions and read what each can do to funds.
- Check whether the owner is a single key or a multi-signature wallet.
- Find the randomness source and the timeout behaviour on a failed draw.
- Compare contract balance against stated maximum payout.
- Check whether there is any deposited balance at all, or whether play is bet-by-bet from your wallet.
- Read the audit's scope line and its unresolved findings.
Half an hour, once, per contract. The alternative is trusting a site's own description of code that is published precisely so it does not have to be trusted — and on-chain casinos are the one category of gambling site where verification is genuinely available to the player, which makes declining to use it a peculiar choice.
Gambling is for adults and losing is the expected outcome; verifiable code changes who can cheat you, not the house edge written into it. If play has stopped being a choice, the free services on our responsible gambling page are independent of any operator.