Learn
First-party withdrawal test vs observed on-chain settlement
What a first-party Tier-A test measures, what a Tier-B observed on-chain settlement measures, why they belong in different evidence tiers, and where the gaps are.
Direct answer
A first-party withdrawal test and an observed on-chain settlement answer different questions about the same operator. A first-party test, run by us, measures the operator's full payout chain end-to-end: the casino's internal approval queue plus the network's broadcast and confirmation. An observed on-chain settlement is a third-party transfer we did not initiate but can see on the public ledger after the operator broadcast it. It tells us the network finished; it cannot tell us how long the operator waited before the broadcast.
This page explains why those two evidence types belong in different tiers, what each one is good for, and where the gaps are.
The two evidence types side by side
| Property | First-party test (Tier A) | Observed on-chain settlement (Tier B) |
|---|---|---|
| Who initiates the withdrawal | Us | A real player, not us |
| Casino approval time visible | Yes — we record the click and the approval timestamp | No — that timestamp lives in the operator's database |
| Broadcast / block timestamp visible | Yes — broadcast time recorded by us; block confirmation visible on-chain | Block confirmation visible on-chain; exact broadcast time may not be available |
| Recipient identity known | Yes — our test wallet | Redacted; the on-chain address only |
| Reproducible by reader | Partially — readers see the explorer link | Yes — readers see the same on-chain transaction |
| What it proves | The operator paid us, under documented conditions | The operator paid someone on this network, under unknown conditions |
| What it does not prove | That the next withdrawal will behave the same | How long the operator's approval took |
| Operator's awareness | The operator can detect the test pattern | The operator did not know we were watching this transfer |
What a first-party test measures end-to-end
A first-party Tier A test runs five steps in order:
- Sign-up. Fresh email, fresh password, no shared identifiers with prior accounts. We complete only the fields the operator requires up front.
- Deposit. A standard amount on the target network. We record the deposit hash and confirmation time.
- Wager-to-clear. Where the operator requires minimum wagering, we play at the lowest-house-edge available game at flat stakes until the requirement clears.
- Withdrawal request. Same network as the deposit, withdrawing the post-wager balance. We timestamp the click.
- Tracking to wallet. We timestamp three more events: when the operator marks the withdrawal approved, when the broadcast appears on-chain, and when the recipient address is credited.
The output is four timestamps and a redacted transaction hash. From the four timestamps we derive three durations:
- Approval time = T2 - T1 (request submitted → operator approved)
- Settlement time = T4 - T3 (broadcast → wallet credited)
- Total payout time = T4 - T1 (request submitted → wallet credited)
Each duration is reported separately. The approval-time leg is what most readers experience as "the wait", and it is the leg only a first-party test can measure.
What an observed on-chain settlement measures
An observed Tier B settlement is a transaction we did not initiate. We see it because the sending wallet is attributed to an operator we track. The chain shows us:
- The block time when the transaction was confirmed, and in some cases the first-seen / broadcast time if captured by an indexer
- The amount, token contract, and recipient address (recipient is redacted on our public surface)
What the chain does not show us:
- When the recipient player first clicked withdraw (T1)
- When the operator marked the withdrawal approved (T2)
- Whether the recipient was a player or an internal cold-storage sweep
- Why this particular withdrawal was approved when it was
Wallet attribution is separate from settlement measurement. We label a wallet as operator-attributed only when there is enough supporting evidence to connect it to the operator; the settlement observation then measures transactions from that wallet, not the operator's private approval workflow.
We can compute T4 minus T3, the on-chain settlement time. That is short and predictable on TRC20 (about one minute) and varies on ERC20 with network gas conditions. What we cannot compute is T2 minus T1, the approval time, because we never observed T1.
Why both tiers matter
A site that publishes only first-party tests has high evidence quality per claim and a small sample. Test-count claims without verifiable per-test evidence should be treated as lower-confidence summaries.
A site that publishes only observed on-chain settlements has a much larger sample but a structural blind spot: it cannot measure the operator-internal portion of the wait.
The combination is stronger than either alone. A first-party test measures one operator approval path under documented conditions. The on-chain settlement sample then shows whether attributed payout wallets continue settling transactions across a broader set of observations.
We currently publish neither at scale. We have no first-party tests in our database and five operators with active attributed payout wallets feeding observed settlements. The honest framing on each operator review page is: Tier B observed settlement data, no Tier A first-party test yet.
How payoutdb uses each tier
On every operator review page, both tiers are displayed if available:
- The page header shows the operator's tier letter (A or B), driven by which evidence we have.
- Tier A pages emit a
ReviewJSON-LD schema with an editorial rating. Tier B pages do not, because a rating without a measured test is structured data we cannot defend. - Tier B pages emit a
FAQPageschema with factual questions about the observed data and explicit limits. - The verified-payouts ledger is the cross-operator surface for Tier B observations across all attributed wallets.
- The methodology page documents the full evidence-grading rubric (A through E) and the corrections policy.
What we do not do: assign a single combined score that mixes Tier A and Tier B evidence into one number. That number would obscure the source of confidence. A reader who wants to know whether payoutdb personally tested an operator should be able to tell from one glance, not from a footnote.
Where each evidence type belongs in your research
If you are researching an operator before depositing, on-chain settlement data tells you whether an attributed operator wallet is currently active. It does not tell you whether your specific account will get fast approval. A first-party test gets closer to that question, with the caveat that one test is one observation under specific conditions.
If you are evaluating an operator's "instant withdrawal" marketing claim, observed on-chain data is the lower-friction check. Look at the operator's attributed wallet on a public block explorer. If the wallet has been processing transfers regularly, the observed network leg can be checked. If not, the public evidence does not support the network-side portion of the claim.
If you are comparing several operators on evidence strength, the best-of evidence page maps operators to use cases. Each row is sourced from the database used by both Tier A and Tier B paths.
Source data and corrections
This page is editorial explanation, not measurement data. The figures cited here are sourced from the live database and may shift as new operators are added or first-party tests are conducted. Per-operator counts are visible on each operator's review page.
If anything on this page contradicts the methodology document, methodology wins. Write to [email protected] with the URL and the specific line.