How to read a casino treasury on-chain
Find the address, read the balance, and understand why a visible treasury is evidence of assets and never evidence of solvency.
A treasury address is the single most useful thing a crypto casino can publish, and the single most over-read. It turns one question — does this operator control funds — from a claim into an observation. It leaves the question people actually care about, can this operator pay everyone, exactly as open as it was before. This page explains how to do the reading, and how to size what you have learned.
Step 1: find the address
There is no standard location, so check in this order: the documentation or developer docs, a “transparency”, “proof of reserves” or “bankroll” page, the footer, the FAQ, the token page if there is a token, and the project’s public repository.
What you find falls into rough categories:
- A bankroll or vault contract — funds the games actually draw on. This is the most informative case, because the contract’s own transactions show it operating.
- A treasury or multisig — operational funds and revenue. Useful, but one step removed from settlement.
- A hot wallet — the address deposits land in and withdrawals leave from. It shows flow rather than depth, and balances there are normally kept low on purpose.
- Nothing — no address anywhere in the public material. That is a legitimate finding to record.
Note which chain each address is on. An operator running across several chains has several balances, and reading one of them tells you about one of them.
Step 2: read it on an explorer
Open the address in a public block explorer for that chain. Three panels matter.
Balance. Native asset plus tokens. Stablecoins and majors are the part that would be available to pay; a balance dominated by the operator’s own token is a different kind of number, because its price depends on the operator’s continued existence.
Transaction history. This is more informative than the balance. Look at the age of the first transaction, whether activity is continuous or bursty, and whether the pattern looks like operations — many small movements — or like a single recent transfer in.
Counterparties. Where do funds come from and go to? Exchange deposit addresses, other contracts controlled by the same project, or a small number of unknown addresses each tell you something different.
Then record what you read: the address, the chain, the block or transaction, and the date. A figure without that context cannot be checked later by anyone, including you.
Step 3: understand what the number is not
Here is where most treasury readings go wrong.
Assets are not solvency
A balance shows assets. Solvency is assets minus liabilities. The liabilities of a custodial casino are the player balances it owes, and those sit in a private database. You can read one side of the balance sheet with certainty and have no access at all to the other. An operator with a substantial visible treasury and larger undisclosed obligations is indistinguishable, on-chain, from a healthy one.
This is not hypothetical. It is the ordinary shape of a custodial failure: the assets were real, and there were not enough of them.
A snapshot is not a track record
A balance is true at a block. Funds can arrive the day before a snapshot and leave the day after. Borrowed liquidity staged for an attestation has appeared repeatedly across crypto, in and beyond gambling. The defence is duration: a balance that has persisted across months, in an address with continuous operational history, is far harder to stage than a single reading.
Control is not custody on your behalf
The operator controls the keys. Nothing about a published address constrains what it can do with the funds, unless the contract itself constrains it — a timelock, a multisig with independent signers, a withdrawal-only path. Read the contract, not just the balance. If a single key can move everything, the address is a window, not a lock.
Proof of reserves without proof of liabilities
The standard form is an attestation that named addresses hold a stated amount at a stated time. It is genuinely better than nothing. On its own it answers the easy half of the question. The rigorous version pairs it with a cryptographic commitment to the liability side, so a player can check their own balance is included in the total; that is rare in gambling as of September 2026, and we have not verified an implementation of it ourselves.
What a good disclosure looks like
Operators whose architecture makes this reading meaningful tend to share a few traits: the bankroll is a contract rather than an address, its transactions are settlement traffic rather than transfers, the contract’s permissions are documented, and the address has been the same for a long time. Among the rows we currently place at the on-chain end of the ladder — Solpump, Overtime, EarnBet — public bankroll or vault contracts are part of what put them there, as of September 2026 and on the strength of documentation we have read rather than a reading we have taken.
At the other end, a custodial operator at tier T2 typically publishes no bankroll contract at all, because there is not one: the bankroll is an internal ledger. That is why our grid caps transparency at 12 of 25 for that architecture regardless of what else is published.
Why our reserve fields are empty
Every verifiedReserve field in our registry is null, and every review says the reserve is unverified. That is not an oversight. Our rule, set out on the methodology page, is that we publish a reserve figure only together with the address, the chain, the block or transaction we read it at, and the date we read it. We have not done that work yet for any operator in the index, so we print nothing rather than repeating a number from somewhere else.
The same rule governs payout hashes: the payouts page stays empty until we hold hashes we have reconciled ourselves. An index that fills unknown fields with plausible numbers is worth less than one with visible gaps.
A short checklist
- Find every published address, and note the chain for each.
- Read the balance, then ignore it until you have read the history.
- Check the age and continuity of the address, not just its size.
- Look for the composition: stablecoins and majors versus the operator’s own token.
- Read the contract permissions. Who can move it, and can that change?
- Record the block and date. A figure without a reading is a rumour.
- Remember you have seen assets only. The liabilities are not on your screen.
You can see how each row scores on transparency, and which caps applied, on the trust score ranking or by putting two operators side by side on the compare page.
18+ only. Gambling involves real financial risk and can be addictive. Nothing here is financial, legal or gambling advice.
Questions
Does a large visible treasury mean an operator can pay me?
It means it holds assets at the block you read. Solvency is assets minus liabilities, and player balances — the liabilities — are almost never on-chain. A visible treasury rules out one failure mode and leaves the others untouched.
What is proof of reserves and why is it incomplete?
A published attestation that named addresses hold a stated amount at a stated time. It proves control of assets at that moment. Without a matching proof of liabilities it cannot show whether those assets exceed what is owed, and balances can move immediately afterwards.
Can an operator borrow funds just for the snapshot?
Yes, and this has happened across crypto generally. A single point-in-time reading is weak evidence. Repeated readings over months, or an address whose history shows continuous operational use, are much harder to stage.
Why does this index not publish reserve figures?
Because we have not read any ourselves yet. Our rule is that a reserve figure is only published with the address, the chain, the block or transaction we read it at, and the date. Until we hold that, the field stays null and the page says unverified.
What if an operator publishes no address at all?
Then the question is unanswerable from outside, and that is the finding. It does not prove anything bad; it means the transparency sub-score has nothing to work with, and the operator is asking to be trusted rather than checked.
How the scores behind these guides are built
Five weighted criteria, three published caps and a tier ladder. Every total is a seed score you can recompute from the public registry.