How to verify casino payouts on-chain

To verify a casino paid a withdrawal, you need two things: a wallet address you can attribute to that casino, and a transaction identifier that originated from it. Without both, you are trusting screenshots or operator wording. With both, the public block explorer answers the question in about thirty seconds, and the casino does not control the result.

This page walks through the verification process we use on payoutdb and points out where it breaks.

A crypto casino payout is an on-chain transaction from a sender wallet to a recipient address. For USDT on TRON, Ethereum, BSC, or Solana, the transfer also references a token contract or token mint. For Litecoin, the payout is a native LTC transfer, not a USDT token transfer.

What the explorer tells you:

• Which wallet sent the funds
• Which wallet received them
• When it was included or confirmed on-chain
• The exact amount
• The token contract or mint (so you can confirm it is real USDT and not a spoof)

What the explorer cannot tell you on its own:

• Whether the sending wallet really belongs to the casino in question
• Whether the recipient is a player or an internal sweep
• How long the casino took to approve the withdrawal before broadcasting

Wallet attribution is the part that does the real work.

There are three reliable ways to attribute a payout wallet to a specific casino:

• Public block-explorer labels. Etherscan, Tronscan and Solscan add "name tags" to addresses they have verified belong to known entities. When you see "BC.Game: Hot Wallet" on an Etherscan address page, the platform has done the attribution for you. This is the cleanest signal but only covers larger operators.
• On-chain analytics platforms. Arkham Intelligence is the most accessible. Their entity profiles cluster related wallets together and label them with the operator they belong to. A human at Arkham has reviewed the cluster, and a human at our end re-checks it before we activate the wallet for tracking.
• Operator self-disclosure. A small number of operators publish proof-of-reserves pages with wallet addresses they claim to control. This is the weakest source on its own (the operator chose what to show), but it can corroborate a third-party label.

If you cannot find a wallet address with at least one of these three, you cannot verify the payout. The claim is unverifiable, not necessarily false.

The transaction identifier format depends on the network: EVM chains use 0x plus 64 hex characters; TRON uses a 64-character hex transaction ID without 0x; Solana uses a base58 transaction signature; Litecoin uses a 64-character transaction ID.

Two common ways to get it:

• The casino's withdrawal record. When a withdrawal moves from "approved" to "sent", the casino UI usually shows the identifier. Save it.
• The recipient wallet's history. Open your own wallet on the relevant explorer and find the inbound transfer. The "from" address should match the casino's attributed wallet. The transaction view will show the identifier.

If the casino refuses to show the identifier and your wallet has no matching inbound transfer on the claimed network, you do not yet have evidence that the withdrawal was broadcast.

Open the explorer for the network the casino used. For USDT it is:

• TRC20 → tronscan.org
• ERC20 → etherscan.io or eth.blockscout.com
• BEP20 → bscscan.com
• Solana → solscan.io

Paste the transaction identifier. Confirm:

• The From address matches the casino's attributed wallet (or a wallet from the same cluster on Arkham)
• The To address matches the recipient you expected
• For USDT, the token contract or mint matches Tether's official address for that network. Impostor tokens can reuse or imitate the USDT symbol, so the symbol alone is not enough
• The amount is what the casino said it sent
• The status is "Success" or "Confirmed", not "Pending" or "Failed"

If all five match, the payout is on-chain. The attributed wallet sent the transaction shown by the explorer. If any line is off, you have a discrepancy worth investigating.

• The casino broadcast that specific transaction to the recipient on a specific date.
• The recipient address received exactly that amount of USDT.
• The chain confirmed the transaction at a specific block, slot, or timestamp, depending on the network.

That is far stronger than a withdrawal-confirmation screenshot, which is a screenshot.

• How long the casino took to approve the withdrawal before broadcasting. That is operator-internal and not on-chain.
• Whether the recipient is a player or an internal cold-storage sweep. A casino may move funds between its own wallets and that traffic looks similar to player withdrawals.
• Whether the operator pays out the next player. Past on-chain activity is evidence the wallet is active, not a promise about future withdrawals.
• Anything about KYC, bonus terms, or wagering requirements. Those live in the operator's database, not on the chain.

These limits matter. We see them every time we publish observed payout data: the chain tells you what happened, not what is policy.

• "Pending" forever on the operator side, no identifier shown. The withdrawal has not been broadcast yet. The wait is casino-side.
• Identifier shown but Failed on the explorer. The transaction did not execute successfully. The cause may be gas, fees, contract rules, or another network-specific failure.
• From address does not match any known operator wallet. Either the attribution is wrong, or the operator is using a wallet we have not catalogued. Worth asking support which wallet they paid from.
• Token contract is not the canonical USDT contract. Impostor tokens can imitate the USDT symbol. Confirm the contract address against the issuer's published list at tether.to before treating the token as USDT.
• Amount on the chain is much smaller than the casino's stated payout. Either a fee deduction larger than expected, or a different transfer than the one the casino claims to have sent.

Most casino-review sites publish editorial test counts. The number is unverifiable: you trust the editor, the editor trusts their testing process, and no reader can reconstruct what happened. On-chain verification breaks the chain of trust. Once you have the attributed wallet and transaction identifier, the chain provides the evidence directly.

That is the whole reason payoutdb exists. Where we have an attributed wallet, every figure on the site resolves to a transaction you can verify yourself. Where we do not, we say so plainly.

For the working version of this process applied to specific operators, see the verified-payouts evidence ledger and the withdrawal-times leaderboard. Both link every row out to a public block-explorer view of the underlying transaction.