1 August 2026. Rewritten in plain English. Supersedes every earlier version.
The problem. Before a player deposits at an online casino, the one thing they want to know is: will these people pay me. Nothing on the market answers it. Every site rates bonuses, games and support, and grades payouts on how people felt. Complaints only arrive after the harm, only from angry people, and cannot be checked.
The product. A public record of how long each casino actually takes to pay, split by payment method and by whether the player was up or down, built from players logging their own withdrawals with screenshot evidence, alongside what they wrote about the experience. Free to read, no login.
Who it is for. US players first, on cards and bank transfers, where the unpaid-withdrawal problem is densest. Older and less technical than the crypto crowd. Most arrive mid-crisis, on a phone, five to nine days into a withdrawal that has not turned up.
What success looks like at launch. A player in that moment lands on a casino page and gets a real answer in five seconds: how long people here wait, how many are still unpaid, and what it was like. The first gate is whether they then log their own case and come back to confirm it arrived.
What this is not. Not a complaints service, not a mediator, not a scorer. We never decide who was right, never publish a composite rating, and never let an operator pay to change a number. The full list is in chapter 15.
The one number that matters. Time to resolution: how long every withdrawal took, however it ended. It is the only figure a casino cannot improve except by paying people sooner.
How to read this document. Chapters are numbered, and every rule inside them has an address like 3.4 so it can be cited in a ticket or an argument without quoting a paragraph. Three markers appear against decisions:
Anything unmarked is a rule that follows from the ones around it.
This is a record of how long online casinos take to pay people and what playing there was like.
Payout time is the core measure. Nobody else tracks it, and anyone can check it. It answers the main question before a player deposits: Will these people pay me?
Each payout record also includes the player's story.
A number can show that a casino took 26 days to pay. The player can explain that the casino asked for the same document four times. They can also report that live chat went quiet each evening, or payment arrived after a Twitter post.
The evidenced record is the premium tier, and everything is ranked against it.
A payout record without a story is one data point. A story without a payout record is weaker. It appears lower, is clearly marked, and never changes a number.
Testimony without a withdrawal still has a place.
A confiscated win never becomes a late withdrawal. Players must be able to report this, but the site never treats it as a measurement.
Easy cashing out is the single best sign of a healthy casino.
Nobody measures it. Existing sites measure complaints, which only appear after harm. They come only from angry people and cannot be checked.
The site has three parts, and the lookup matters most.
It is a free public page with no login. It shows what a casino's payouts are doing now. It also shows what people say getting money out is like.
Players create the data by recording their withdrawals. Almost nobody will do this, and that is fine. The lookup must still be worth visiting without them.
Players write about what happened to them. Not only the payout. The bonus terms, whether support was any use, the games, the whole experience. Some of it sits on a withdrawal record. Some of it stands on its own.
The lookup answers: "Is it just me, or is the site broken?"
Nothing today answers this question. The two answers require opposite actions. If it is just you, fix your paperwork and chase support. If it affects everyone, get your money out.
You log your first cashout before anything is asked of you.
No account, no ID, no second screenshot. We take an email address at the end, only so the clock has somewhere to report.
An account is created after that first record, not before it.
Identity verification is optional even then. It is never needed to log a cashout, read anything, or take part.
Identity verification uses an ID and selfie.
A provider checks them. We keep only a token, never the documents. Verification raises your tester level and the credibility shown on every record you file.
Each casino account is linked once.
We ask for a screenshot of your casino account page after your first record, never before it. You never repeat this for that operator.
Nothing is asked for before your first upload.
A person may arrive with only ten minutes of motivation. That time should go toward the record, not setup.
An unlinked record is a lower tier, not a rejection.
If your identity is verified, we match the name and raise the link tier. No-KYC casinos only provide a username, so the link stays at the lower tier.
Every cashout follows these steps.
Request it through the casino.
Do not crop it. The casino branding and layout around the transaction make it useful as evidence.
On desktop, take a normal screenshot. You can also scan a QR code and use your phone.
Use the website or the app's share sheet.
The casino is read from the screenshot, and you confirm it. If the layout carries a username we read that too. The account link is asked for later, see 2.3, so the first record never depends on a link that does not exist yet.
You type anything we cannot read. You confirm every detail before saving.
The clock starts without telling the casino. LOCKED
We alert you when the cashout passes 1.5x its benchmark, the same point it is marked overdue.
The benchmark is the lowest of three values: local wait times, the market wait for that method, and the casino's published window. A casino promise can only make the cashout overdue sooner.
See chapter 4 for every state, scenario, and number. The alert names the value that applied.
Most casinos publish no payout window.
In that case, our measured median is the benchmark. It does not use a casino promise.
We show both measured and published times when both exist.
"They say 3 to 5 days, people are seeing 11" is stronger than either number alone.
Confirm with one tap from a push notification or email.
An arrival screenshot is optional.
You can attach a bank or wallet screenshot showing the incoming amount and date. This proves arrival and raises the record's tier, but it is never required.
A crypto address can close the clock automatically.
For crypto, you may paste the receiving address at step 3. We watch it and close the clock, so you never need to return.
A pending cashout can be logged and backdated.
You can log it today and use the date shown in the screenshot. Most people arrive around day five to nine, when the money has not appeared.
Every casino page shows the official complaint route.
The page names the route for the operator's licence. It also names the required alternative dispute resolution body, its link, and its cost.
Complaint information is static for each regulator.
It needs no staff and follows chapter 15. After the numbers, it is the most useful information for a player on day nineteen.
We never contact the operator about a withdrawal.
We do not judge who was right. We also place no commercial link on a casino page, record, or feed.
Phase two has one narrow, player-started exception.
See chapter 4. It does not exist at launch.
Affiliate links appear on one separate page only.
See chapter 11.
Every number on the site starts with one screenshot.
If that upload is awkward, there is no data to publish.
The capture flow is specified as fully as the statistics.
A desktop screenshot needs one keystroke and no second device.
Photographing the monitor is only a fallback. A person who does not know the shortcut can scan a QR code.
Nothing is asked for before the first upload.
We use the withdrawal screenshot to link the casino account when its layout allows. Otherwise, we ask for the link afterwards.
A desktop screenshot often shows the username in its header.
When it does, we use it for the link and ask for nothing else.
A mobile screenshot usually does not show the username.
The header often shrinks to a menu and balance. Most players use mobile.
Getting the link from the first screenshot is a bonus, not the plan.
The normal plan is to ask for it afterwards.
The first upload must use the player's short window of motivation.
A person may arrive on day nine, angry about a stuck withdrawal and using a phone. Their motivation may last about ten minutes.
Setup and a second capture can lose the record.
Many casinos do not label account screens as we describe them. A second capture also sends the player back into the casino app while they are upset.
The pending row may disappear before the second capture.
The flow uses this order:
Nothing comes before it. There is no account setup, ID check, or second image.
This includes the casino, amount, method, date, and any visible username or account ID. The player types anything unreadable.
The clock needs somewhere to send updates.
The account now contains a record worth keeping. The first reminder is the natural time to ask, because the player is already engaged.
An unlinked record is a tier, not a rejection.
It is published at once, below linked records and with a clear mark.
An unlinked record does not affect a median or count.
It starts counting only after the casino link identifies a distinct member. This follows the same distinct-member rule used elsewhere.
Waiting for the link loses no data.
Asking for it first can lose the whole record.
Every image is checked for every useful detail it contains.
One screenshot can link the casino account, prove a deposit, show the casino interface, and date the request.
Every avoided question helps keep a record.
Later evidence can raise a record's tier.
A link taken from the record's screenshot gets the tier that evidence supports. A later profile screenshot or verified identity can raise it.
The tier system lowers weak records instead of blocking them.
See chapter 3.
A completed upload matters more than a cleaner dataset.
When they conflict, the upload wins and the record gets a lower tier.
Most phone users take and share a normal screenshot.
They send it through the share sheet or upload it. This is the main route and takes two taps.
Desktop users take a normal screenshot and drag in the file.
Both main desktop operating systems use one shortcut. We show the shortcut when it is needed, not on a help page.
Desktop users can move capture to their phone with a QR code.
The upload page opens the capture flow on the phone. The file then appears in the desktop session.
Photographing a monitor is only for people who do not know the desktop shortcut.
This is a large part of the audience. It is the only reason to photograph a monitor.
We show one marked real example before capture.
It shows what we read, why the surrounding page matters, and what we will hide.
One clear example prevents most capture failures.
Players send the whole screen without hiding anything first.
Asking them to cover their balance creates another point where they may quit.
We detect and mask fields we do not need.
We show the masked version for approval before publication. The player can remove a mask or add another one.
Moving work from the player to us keeps more records.
It also creates better evidence. Manual redaction often removes the casino interface that makes the image useful.
Casino screen problems never block a record.
If the pending row and header are on different screens, we accept multiple images and join them into one record.
Some casinos show nothing until processing starts. We accept the confirmation email or balance change instead, at a lower tier.
The record is marked as player-stated instead of image-read.
It goes into the buried tier and is never blocked. See chapter 3 for how it appears.
A failed capture is never a lost record.
The player can file later and backdate it to the request date. Most people already arrive after waiting several days.
No step can require the player to leave the casino page, install anything, or understand anything.
The player is mid-withdrawal, often anxious, and usually on a phone. Every extra instruction costs records.
A completed upload matters more than a cleaner dataset.
When they conflict, the upload wins and the record gets a lower tier.
Before the rules, here is what a reader sees on a casino page:
The rest of this chapter is how each of those is computed. LOCKED markers are settled.
We publish individual records and only the aggregates named here. LOCKED
We do not publish a composite trust score, a weighted formula, or anything made by a model. We publish medians and counts with their sample size and coverage.
Small samples stay visible as individual records.
A median from five cases looks more exact than it is. Five records with evidence are honest about their limits. This also leaves no formula to attack or defend.
Each record shows the casino, amount band, method, request time, arrival time, and evidence tier.
Amounts are banded on the casino page, ticker, and shared links.
An exact amount at a named casino on a named date can identify a player. An operator's payment team could match it in under a minute.
Members may show exact amounts on their own records.
The default is an amount band.
Written accounts carry the same risk, but banding cannot fix it.
A dated list of events can map directly to a support ticket. Members get a plain warning while writing and may publish without dates.
Unverified records are buried, never hidden and never blurred. LOCKED
Hiding or blurring them costs us Google traffic, our whole acquisition channel. They appear below verified records, look less important, and carry a clear label.
Every count shows its coverage.
Two records from three linked members mean something different from two records among two hundred linked members. We never suggest we know more about an operator than our coverage supports.
Time is measured in minutes and displayed by size.
Times under one hour show minutes. Times under one day show hours. Longer times show days.
Days alone would hide useful differences. Four minutes and six hours would both become "under a day", even though players care about that gap.
Fast payouts use exact useful timing.
"Paid in 47 minutes" is worth sharing. "Paid same day" says very little.
The two main numbers stay inside one payment method.
They are never combined across methods:
Bank transfer Taking back money they deposited: median 4 hours (14 records) Taking out winnings: median 26 days (9 paid), 3 still waiting
The same casino, method, and page show the contrast.
A payout median always appears beside withdrawals that did not end in payment.
A payout median only covers withdrawals that ended in payment. Other endings do not enter it.
A casino can lower its median by refusing its slowest cases.
Refusing everyone raises the refusal rate. Refusing only the slowest cases can lower the median while barely changing that rate.
The not-paid line sits directly beside the median.
We show the two lines together instead of creating another formula:
Bank transfer Taking out winnings: median 26 days (9 records) Did not end in payment: 3 still waiting, 4 refused after a median 19 days, 1 reported locked out
The unpaid line has the same size as the median line.
It cannot be collapsed or placed where readers can scroll past it.
Nine payouts beside eight withdrawals without payment cannot look like a good result.
The two lines show this more clearly than a new formula would.
The payout median only describes withdrawals that ended in payment.
Any action that gives a slow case another ending improves that median. Refusing slow cases or stalling until players reverse removes those waits from it.
We publish time to resolution beside the payout median.
It has no escape through another ending:
Time to resolution: median 9 days over all 17 withdrawals, however they ended.
Every ending counts at the time it took to reach it.
Paid on day 3 counts as three days. Refused on day 19 counts as nineteen days. Cancelled on day 9 counts as nine days. Account closed on day 22 counts as twenty-two days.
Open cases count at their current elapsed time.
An open case makes the number worse every day it stays open.
Time to resolution improves only when visible cases end sooner.
Refusing a slow case keeps its nineteen days. Stalling a player until they reverse keeps the stall. Going quiet makes the number rise. Paying is usually the fastest way to finish.
This protection only covers the people we can see.
We publish the casino, amount, method, request date, and arrival date. The operator has all five fields in its payout queue.
An operator can often match a published record to an account.
A fuzzy match takes one engineer about a week and works for many records. Written accounts reveal more through dates, amounts, and agent names.
An operator can pay tracked players faster instead of paying everyone faster.
Operators already run exception queues for VIPs. They can use the same system for tracked players and call it proactive identification.
The resulting records are real.
Nothing is fabricated, so the abuse controls in chapter 9 do not detect it.
Targeted treatment can produce the same number at about one percent of the cost.
Every metric based on self-reported records has this weakness. We state it clearly.
We only see records that the operator can also see.
Without a second sample, we cannot detect different treatment.
Some records stay unpublished until they end.
Any member can opt in. The tester programme is the natural source because we schedule those withdrawals.
Tester records have two separate jobs.
Chapter 7 uses them as the visible launch set so pages are not empty. This chapter uses them as the sample operators cannot see.
One record cannot be both visible and hidden.
A minority of each tester batch is held back. The majority publishes at once and seeds the site.
The held share and record selection are not published.
Assignments are random, not chosen.
Every assignment is logged.
See chapter 12. Nobody can quietly move a record between the visible and held sets.
The held share and selection method are set in the control-sample row of chapter 14.
A held record stays hidden for its full run.
It publishes only after it ends.
A consistent tracked versus untracked speed gap is a finding.
The comparison must use the same operator, method, and period. The gap is measurable and publishable.
A speed gap is evidence of a two-tier payout process.
That is worse than a slow median. No other part of this design detects the attack as cheaply.
The held sample must stay large and hard to predict.
Maintaining it is an ongoing cost, not just a launch task.
The tester programme must continue after launch.
Its main long-term job is to provide a sample the operator cannot see, not just seed pages.
The two main numbers answer different questions.
The payout median answers, "If they pay me, how long?" Time to resolution answers, "How long until I know?"
Similar numbers suggest direct handling.
A wide gap means many endings are not payments. The gap itself is a finding.
The headline uses the casino's most-used method.
We count distinct members, not records. The method is named in the heading, and other methods are one tap away.
Record volume does not choose the headline method.
Otherwise, one person could repeat minimum withdrawals through a flattering method. They could control the headline for only the transaction fees.
A casino used mostly for card payouts leads with card.
Methods cannot be blended into one number, see chapter 3. Averaging a wire and stablecoin transfer would break that rule in the page's main figure.
A player's net position changes how operators treat a withdrawal.
A player withdrawing $5,000 after depositing $6,000 is taking back their own money. A player withdrawing $5,000 after depositing $50 is taking the casino's money.
Operators often return deposits quickly and question real winnings.
That change is worth measuring, and nobody else publishes it.
We ask about net position instead of guessing it.
A recent transaction screenshot can mislead us. A player may have deposited twenty times over six months.
We ask one plain question at confirmation.
It requires no arithmetic:
"After this payment, will you have taken more out of this casino in total than you have put in?" Yes / No / Not sure
Net position has three separate states.
Verified means we saw lifetime deposit and withdrawal totals in a screenshot.
Player-stated means the player answered the question.
Unknown means the record still counts for payout time but not the winnings split.
We always have the amount.
It appears on the screenshot.
We often do not have the net position.
The player must answer, and many will choose "Not sure." Using it as the main split would leave too many records unclassified.
Amount and net position measure different things.
Both matter.
Amount triggers the casino's payment controls.
These include approval limits, source-of-funds checks, and game provider reviews. A casino may pay $2,000 in four hours but go quiet at $10,000.
Net position shows whether the casino is losing money on the player.
Casinos often stall most when the amount is large and the player is ahead.
Amount and net position often match.
A five-figure withdrawal is usually winnings. A $200 withdrawal usually is not.
A player's real question includes both amount and net position.
For example: I won eight grand, how long will this take? The ideal answer is one cell in a grid, but low volume cannot fill that grid.
We capture both values on every record.
Amount bands form the main structure because they are always available.
The winnings split appears inside a band when enough records exist.
The full grid appears as volume grows.
The winnings versus deposits contrast stays in the casino-page headline.
It gets attention, but always shows the count behind it.
We never blend methods into one number. LOCKED
A bank transfer and a USDC transfer use different systems. Wires and ACH use banking rails that can take one to three business days. Stablecoin transfers can settle in minutes.
Blending methods punishes casinos for the rails they offer.
It also gives players a useless number because players choose a method.
Each method gets its own figure.
A casino page reads:
Bank transfer, winnings: median 9 days (11 records) USDC, winnings: median 3 hours (6 records)
This is fairer and more useful.
Differences between methods stay visible.
A casino paying crypto in minutes but holding bank transfers for three weeks reveals where its money may be available.
We separate approval time from rail time only when the evidence allows it.
The casino controls the time between the request and release. Fedwire, ACH, SWIFT, or a blockchain controls what happens after release.
Crypto gives us the release time.
The on-chain send has a timestamp.
Fiat usually gives us only request-to-arrival time.
We label it that way and compare only within the same method.
Minute precision requires real times at both ends.
Crypto provides both. Fiat provides both when the player attaches a bank line showing the credit.
Unevidenced fiat arrivals use day precision.
"It turned up" is accurate only to the day. It displays in days and never enters a minute-level median.
We never claim more precision than the evidence supports.
An operator would attack unsupported precision first.
Withdrawal caps stay visible as findings.
Some casinos cap withdrawals at a few thousand dollars per week. A $16,000 win may then take a month to arrive in instalments.
We do not adjust capped withdrawals out of the results.
The cap is part of the casino's terms. We already store and date those terms.
The page shows the cap beside the numbers.
A record paid in instalments is marked that way and names the cap.
VIP and standard payouts are kept separate.
VIP accounts can get much faster payments through a dedicated host. Combining them gives standard players a misleading number.
Each record stores the player's VIP status at that time.
VIP is a display split, not an unused field.
Hosted payouts are often same-day. Mixing them into the standard figure would create the misleading result the site exists to stop.
VIP and standard appear separately when both groups have enough records.
The headline uses the standard figure.
Standard players are the main audience.
Payout speed partly reflects the player relationship.
A hosted player may get fast payments because they deposit heavily. Without this split, the number measures the customer as well as the operator.
VIP status is player-stated.
Operators use inconsistent systems. Some have visible tiers, while others offer only a private phone number. We label the player's answer instead of presenting it as confirmed fact.
Multiplier bands come later.
A 2x and 50x cashout can get very different treatment. Multiplier bands are more useful than a yes-or-no split, but need more records.
We capture the raw multiplier data now.
We will decide how to show it later. The multiplier is arithmetic over data we already store.
Every record and written account publishes within seconds of submission, unless automated screening flags it.
This includes the first record for a casino with no earlier coverage. There is no holding queue or minimum publication count.
Only aggregate arithmetic waits.
A median needs enough records to avoid being controlled by one loud person. The thresholds below apply only to aggregates.
A page with one record shows that record and no median.
It clearly says there is one record.
Immediate publication keeps contributors returning.
A contributor whose submission disappears into a queue may not come back. The product needs repeat contributors.
A page with one record still helps search traffic.
See chapter 12.
We do not use a daily manual review queue.
That would break the staffing limit.
Automated screening can hold one flagged item.
It holds only that item and nothing else.
Captured fields do not all appear on day one.
Four splits across nine casino records would create cells with one record each. That looks like analysis but is only noise.
The display opens automatically as records arrive.
The page lists individual records. Each shows its amount, method, and whether it was winnings. Readers can judge the small sample directly, see chapter 3.
The count always appears beside it. Winnings versus own money will usually be the first split to open because it matters most.
The order is method, amount band, then net position.
No cell appears below its threshold.
An empty cell says "not enough records yet" and links to the records behind it. It never borrows from a nearby cell or falls back to a blended method average.
The starting threshold is roughly eight to ten records.
This is a value to tune after we see the real distribution. It is not a derived number.
The threshold counts distinct people, not just records.
The threshold is also the cost of attacking the statistic. One person filing eight withdrawals cannot be allowed to open a median.
A slice needs enough records from enough separate verified members.
One member's contribution to a single slice is capped.
An attacker must fund several verified identities and real withdrawals.
Those identities need real accounts at a casino the attacker does not control. That costs far more than opening a few accounts.
Every aggregate gives weight to distinct verified players, never record volume.
See chapter 3. This rule applies everywhere a number is computed.
Mixed precision resolves downward within each slice.
Crypto arrivals and evidenced fiat arrivals are accurate to the minute. Player-stated fiat arrivals are accurate to the day.
A slice uses the precision of its least precise record.
One player-stated arrival moves the whole slice to day precision. This rule is fixed and never claims too much precision.
Evidence keeps a slice precise.
Attaching a bank line can preserve minute precision. A slice says when every record is minute-accurate.
A changed payment method belongs to neither method median.
A bank request paid by card would carry bank delay into the card figure. That would break the within-method comparison.
A changed payment method becomes a Method changed record.
It is excluded from both method medians. It still appears on the casino page with both methods named.
Method changed records live only in the Method changed counter. They are not in any method median and not in Paid.
Frequent rerouting remains visible instead of being spread across two medians.
Counts use the same gates as medians.
Publication stays immediate for every record. Only the headline count waits.
A headline count needs enough distinct members.
For example, "6 unpaid" uses the same distinct-member gate as a median. One fake pending record cannot change a published count on day one.
Visibility and aggregate counting are separate.
Below the gate, the page shows the records but no aggregate.
Every counter uses the gate without exception.
This includes the most serious counters.
Account closed uses the same gate.
A failed-login screenshot is the easiest evidence in this document to fake, see chapter 4. Publishing a count of one could create an accusation from one verified identity.
One member can never reach the gate alone.
Filing more records does not help.
The most damaging counters need the gate most.
Serious claims should not become aggregates faster.
Every rate uses the same denominator.
This includes the refusal rate, cancellation rate, and deposit-again range:
Every rate is computed over records in that slice which have reached an ending, within a stated time window, counted once per member.
The denominator includes every completed ending: Paid, Part paid once complete, Refused, Cancelled, Account closed, Closed short, Method changed, Abandoned unpaid and Unconfirmed.
Paid is included.
Part paid is included once complete.
Refused is included.
Cancelled is included.
Account closed is included.
Abandoned unpaid is included.
Unconfirmed is included.
An unanswered ending is still an ending. Excluding it would reward operators for driving players away.
Draft is excluded.
It was never submitted.
Removed is excluded.
Chapter 11 removes it from every figure.
Live records are excluded.
They have not ended. They appear separately in the still-waiting count.
Method changed is included in the denominator.
It reached an ending, even though it appears in no method median.
Every rate shows its time window.
"40% refused" over three years is different from "40% refused" over ninety days.
Tester records stay in their own bucket.
They never enter an organic rate, see chapter 7.
Each member contributes their own median first.
We then take the median across members.
One record and thirty records each produce one member value.
Thirty records from one member show long-term evidence about an operator. They do not become thirty separate witnesses.
Record volume gives no extra weight.
The aggregation is one algorithm: take each member's own median for the slice first, then take the median across members. The cap of 2 in 14.2 applies to the records that feed a member's own median, so no single member can build their personal median from more than two records in one slice. No decay curve or weighting table is used.
Every published median uses this method.
This includes payout median, time to resolution, time to decision, and wait before cancelling.
Lifetime medians can describe an old owner or system.
Casinos often change owners, platforms, and payment processors. Chapter 4 already moves records with the operator after a rebrand.
Every published figure uses a named rolling window.
The window appears beside the figure.
All-time figures are one tap away.
They are clearly labelled as all-time.
A rolling window is not a decay formula.
Chapter 3 bans decay formulas. A named period is clear and can be checked.
Every number shows its slice and the count behind it.
We never publish a bare median.
These are the only record states.
Anything else is a bug, not a new case.
| State | What it means | Counts as unpaid | In the payout median | Visible |
|---|---|---|---|---|
| Draft | Uploaded, but the player has not confirmed the details | No | No | Only to them |
| Waiting | Live and inside the normal range for this casino | Yes | No | Yes |
| Waiting, overdue | A live record past 1.5x the benchmark. Overdue is a property of a live record, not a separate state | Yes | No | Yes |
| Paid | Money arrived and the player confirmed it | No | Yes | Yes |
| Part paid | Some money arrived, some is still outstanding | Yes, for the outstanding part | No, only once the balance reaches zero | Yes |
| Closed short | Part paid, then the casino refused the remainder | Yes, for the refused part | No | Yes, with the refusal reason |
| Refused | The casino declined and said so | No, counted separately | No | Yes |
| Cancelled | The player reversed it and kept playing | No | No | Yes, with the wait before cancelling |
| Unconfirmed | The player went quiet with no signal either way | No | No | Yes, marked as unconfirmed |
| Abandoned unpaid | The player went quiet after the case became overdue or they last said they were still waiting | Yes | No | Yes, with the date last confirmed unpaid |
| Method changed | Paid, but by a different method than requested | No | In no method median, counted in the payout counters | Yes, both methods named |
| Account closed | The player was locked out while the withdrawal was still outstanding | Yes, counted separately | No | Yes, as its own outcome |
A casino page publishes exactly these counters.
Every record belongs to exactly one counter.
Each completed record counts as one whole record.
Each record counts as one whole record and is never split across two counters. It enters a payout median only when complete.
Still waiting contains Waiting and Overdue records.
Gave up waiting contains Abandoned unpaid records.
Refused contains Refused records.
It also shows the median time to decision.
Account closed contains Account closed records.
Cancelled contains Cancelled records.
It also shows the median wait before cancelling.
These records are shown but never described as good or bad.
The paid part is shown, and the refused remainder is counted with its reason and time to decision.
It is in no method median, because the method it was paid by was not the one requested. It lives only in the Method changed counter, never also in Paid.
Every published record sits in exactly one counter. Draft is not published and has no counter.
A Part paid record is not split between Paid and an outstanding counter. Putting one record in two counters would make every total wrong.
"Unpaid" and "the not-paid line" are two different things, on purpose.
"Unpaid" is the strict set: Still waiting, Gave up waiting, Account closed, the outstanding part of Part paid, and the refused part of Closed short. Refused is not unpaid.
The not-paid line is a display grouping shown beside the median. It adds Refused to the unpaid set, so a reader sees every withdrawal that did not end in payment. Refused keeps its own separate count as well.
Cancelled is excluded because the player took the money back. A casino cannot be blamed for that, see chapter 4.
Cancelled appears beside the not-paid line.
It has its own rate and wait figure. This stops a reversal from becoming a hiding place.
"Unpaid" means Still waiting, Gave up waiting, and Account closed together.
It also includes the outstanding part of a Part paid record and the refused part of a Closed short record. Draft is never published.
Disputed and Removed are flags, not states.
A record always has one state from the table. It may also have either flag.
The system uses one state field and two separate flags.
It does not use a thirteen-value enum.
| Flag | What it means | Effect on the state | Effect on the numbers |
|---|---|---|---|
| Disputed | The casino says the record is factually wrong | None, the record keeps its state | None, the flag is shown and nothing moves |
| Removed | Taken down under chapter 11 | None, the state is kept underneath | Drops out of every count and median |
Any flag can sit on any state.
Both flags can apply at once.
Clearing a Disputed flag changes nothing else.
We never decide who is right, and a dispute never moves a number.
Clearing a Removed flag restores the record to its old state.
Removal never overwrites the state.
Silence keeps the last known state.
It never resets a record to neutral.
Silence without an unpaid signal becomes Unconfirmed.
This applies when the record never became overdue and the player never said it was outstanding. It avoids treating paid players who moved on as unpaid.
Silence after an unpaid signal becomes Abandoned unpaid.
This applies when the record was overdue or the player had said "still waiting" at least once. Bad treatment can make players angry and less likely to reply, so silence must not erase their last report.
A silent player may have been paid and moved on.
Unconfirmed stops that case from becoming a false accusation.
A silent player may have waited six weeks or lost a win.
Abandoned unpaid stops anger and disengagement from making a bad outcome disappear.
The last known facts decide the silent state.
We cannot ask the player, so we use the latest signal we have.
It is neutral, published, counted separately, and never treated as an accusation.
It stays in the unpaid count and shows the date last confirmed outstanding. The record says only what the player already told us.
It remains separate and never turns into Paid by itself. It leaves Refused only when there is evidence that the casino later paid, see chapter 4.
Both silent outcomes are published as separate numbers.
They are never folded into another number. "4 records went unanswered while still overdue" is true, useful, and visible.
A voided win leaves a visible record.
It may never become a late withdrawal, so the clock alone cannot find it. The written account covers this gap, see chapter 5.
| Scenario | What happens |
|---|---|
| Paid, player confirms | The record becomes Paid. It feeds the median. |
| Player goes silent, record never went overdue and they never said it was outstanding | The record becomes Unconfirmed after reminders. It is never unpaid. This may be the paid-and-happy case, but we use only what we can observe. |
| Player goes silent after the record went overdue, or after they said once it had not arrived | The record becomes Abandoned unpaid. It stays in the unpaid count with the date last confirmed outstanding. |
| Player cancels and keeps playing | The record becomes Cancelled. It stays out of every payout figure. It still answers the deposit-again question and enters the cancellation rate and wait-before-cancel figure. |
| Casino refuses, gives a reason | The record becomes Refused. The casino's reason and email are shown. It is counted separately from unpaid. |
| Casino refuses, gives no reason | The record becomes Refused with "none given" as the reason. The missing reason is part of the finding. |
| Casino closes the account with the balance in it | The record becomes Account closed. It has its own published count and is never folded into Refused or the payout median. |
| Paid in instalments under a weekly cap | The record stays Part paid until settled. The median runs from the first request to the final payment. The instalment pattern is shown because paying a big win over forty weeks matters. |
| Paid to a different method than requested | The record is marked Method changed. Both methods are shown. It is excluded from both method medians, see chapter 3, but remains in the payout counters. |
| Payment bounces or is clawed back after being marked paid | The record reopens to Waiting. The original close remains visible. |
| Same withdrawal logged twice | The second record is merged. Records match on casino, member, amount within 1 percent, and request date within one day, per 14.11. The duplicate is not published. Two different casino accounts held by one member can still each produce a record, because the key is the member and the amount, not the account. |
| Player made a mistake in the details | Details are editable before confirmation and amendable afterwards. Later changes are logged and visible. |
| Casino says the record is factually wrong | The record gets a Disputed flag. The record and the casino's objection both appear. We never decide who is right or quietly remove the record. |
| A casino rebrands mid-case | The record follows the operator. Both brand names appear on the page. |
| Casino goes dark entirely | Live records become Overdue and then Abandoned unpaid as players give up. A casino that stops answering everyone creates a clear visible finding. |
| Casino refuses, player escalates, casino relents and pays | The record becomes Paid. The refusal is cleared. The full time from the original request enters the payout median. The refusal and reversal remain visible in the record history with their dates. |
| Part paid, then the casino refuses the remainder | The record becomes Closed short. It never enters a median because Part paid enters only when complete. The refusal is counted with its reason and time to decision. A casino cannot pay $500 of a $16,000 win in two hours, refuse the rest, and post a fast payout. |
| Part paid, then the player goes silent | The silence rule applies to the whole record. It becomes Abandoned unpaid if overdue or previously reported outstanding. Otherwise it becomes Unconfirmed. No part of it enters a payout median, because the balance never reached zero. |
| Part paid, remainder simply never arrives | The outstanding balance ages like any other live record. It is flagged overdue, and on continued silence becomes Abandoned unpaid. An outstanding balance never quietly stops counting. |
| A record's value was already published, then it is removed or reopened | Every affected median is recomputed. The page says that it changed. Published figures are corrected and corrections are never silent. |
| Player deletes their account | The records stay and become anonymous. The measurement is about the casino, not the player. |
| Player asks for their record to be removed | The record is removed but still renders as a removal. The date and reason are shown. Nothing is quietly deleted. |
The system measures completed payouts.
It does not measure fairness and must never claim to.
Confiscated wins are a known blind spot.
The worst operators may confiscate instead of stall. A casino that takes big wins but quickly pays everything else can look good here.
The methodology page states this blind spot.
A voided win never becomes a late withdrawal, so payout timing alone cannot detect it.
An unconfirmed record is never treated as unpaid.
The player may have been paid, felt happy, and never returned. Treating that as unpaid would create false claims through normal loss of contact.
A live record is Waiting or Overdue.
The difference is published.
Waiting means the record is inside the normal range for that casino.
Overdue means the record is past what other people there actually wait.
Overdue uses the lowest available benchmark.
This is not an ordered ladder. All three candidates are calculated for the record's payment method, and the smallest one wins.
The record names the benchmark used.
"Overdue" is never an unexplained verdict.
A record stays Waiting when no benchmark exists.
It shows only the elapsed time. No record becomes Overdue against a benchmark we cannot name.
Using the lowest benchmark stops casinos from raising their own bar.
A slow casino cannot use its own slow history to keep records out of Overdue.
A long published window cannot buy extra time.
A casino cannot promise sixty days and gain sixty days in which records never become Overdue.
The fastest available standard applies.
The casino is measured against its own record, the wider field, and its own promise. Being slow or promising to be slow never buys time.
Every benchmark stays within one payment method.
Bank transfers are compared with bank transfers. They are never compared with stablecoin transfers, see chapter 3.
The site-wide method figure applies when a casino has no records for that method.
The payment rails are the same for everyone.
It is shown and counted separately. It is never folded into "still unpaid."
It stays in the unpaid count, see chapter 4.
The reminder schedule collects an early signal.
Before a record could reasonably be abandoned, the player gets a one-tap question: "Has it arrived yet, yes or not yet?"
One "not yet" can separate a stalled case from a forgotten paid case.
A "not yet" on day four costs the player one tap and remains useful if they later go quiet.
Unpaid has one fixed meaning.
A record is unpaid while it is Waiting (including overdue), Abandoned unpaid, or Account closed. The outstanding part of a Part paid record and the refused part of a Closed short record are also unpaid.
Waiting and Overdue come from the clock.
They do not need a statement from anyone.
Silence does not automatically remove a record from unpaid.
A record becomes Unconfirmed only if it was never overdue and the player never said it was outstanding.
Silence after an unpaid signal becomes Abandoned unpaid.
The silence rule in chapter 4 controls.
Silence never creates an accusation.
But time passing on a live record is not silence. It is the measurement itself.
Open cases do not need repeated player reports to keep counting.
Requiring active reports would make open cases quietly disappear and make every casino look better.
The confirmation prompt offers every possible ending.
A state needs an answer that lets the player reach it.
Paid means the money arrived.
Still waiting means the player says the money has not arrived.
This keeps the record in the unpaid set. It also makes the record Abandoned unpaid instead of Unconfirmed if the player later goes quiet.
I cancelled it means the player reversed the cashout.
Many casinos let players return pending cashouts to playable funds. This is common and is used as a retention tool.
A cancelled cashout is not a payout.
It never enters the payout median.
A casino is not blamed for money the player took back.
The cancellation remains outside payout figures.
A cancelled record is still published.
Otherwise a casino could make waiting unbearable and benefit when the player gives up.
Cancellation keeps the long wait visible.
It also keeps the record on the page and preserves the player's answer to the deposit-again question.
Two cancellation figures are published.
Neither claims that the casino owes the money.
A high rate is not automatically bad because some casinos make cancellation easy. It is still a fact that belongs beside payout time.
A reversal after twenty minutes may mean the player changed their mind. A reversal on day nine may mean they gave up. The median wait-before-cancel shows the difference without judging either case.
Cancellation figures sit beside the payout median.
They never sit inside it.
A cancelled record still answers the deposit-again question.
Cancellation is an ending. The metric must include bad endings to stay useful.
They refused means the casino said it would not pay.
Refusal is different from stalling and is never mixed with it.
Voided and confiscated wins are recorded as Refused.
From the site's view, each is a refusal with a stated reason. There is no separate Confiscated state.
Some of it arrived means the record becomes Part paid.
This covers instalments caused by withdrawal caps or partial releases. It enters a payout median only after the whole amount arrives.
I cannot get into my account means Account closed.
The player is locked out while the withdrawal remains outstanding. This answer creates the entry event for the state, see chapter 4.
Refusals require careful handling.
Many refusals are valid. The page must never suggest otherwise.
Common refusal reasons include duplicate accounts, bonus max-bet breaches, incomplete verification, and reopening after self-exclusion.
The player must provide the casino's stated reason.
We also ask for the casino's email that gives the reason.
The casino's own words provide its side without direct contact.
This is how the design stays fair when the casino had a good reason.
A refusal record shows the refusal and the casino's reason.
We never say who was right.
A refusal count is not a scandal.
It is published separately and never folded into unpaid.
Refusal patterns are published without judgement.
If nineteen of twenty refusals name the same clause, we can state that fact.
The refusal rate and reasons appear together.
A casino refusing forty percent of withdrawals may face heavy fraud or may use its terms as a weapon. We publish both facts and choose neither explanation.
A refusal replaces the running payout state.
A withdrawal may wait eleven days before the casino voids the win for a bonus max-bet breach. That is a refusal, not a slow payout.
A refusal never enters the payout median.
The median measures how long the casino takes to pay people. A refusal is a different event.
The record moves from Waiting or Overdue to Refused.
The move happens on the day the refusal is recorded. Refused is counted separately everywhere.
The time before refusal becomes time to decision.
Eleven days to say no is different from two hours to say no. This figure appears beside the refusal count, never inside the payout median.
Long waits before refusal remain visible.
A pattern of long silence followed by refusals can be seen without us describing it as good or bad.
A state change needs evidence.
A player's feelings do not set the state.
Refused requires a refusal artifact.
This can be the casino's email, a message in its interface, or a screenshot of the voided transaction.
The player's written account can describe the refusal at any length.
We publish that account unedited. The account holds the player's view, while the state follows the evidence.
A disputed record keeps its state.
If the player will not record the refusal and the casino disputes the record, the Disputed flag applies, see chapter 4.
A dispute shows both positions.
The record stays visible and carries the flag. We do not decide who was right.
The refusal rate blocks mass refusal as a way to game the median.
A casino that refuses people instead of paying moves the problem to a number beside the payout time. A forty percent refusal rate is more visible than a slow median.
A record cannot stay Waiting forever.
A record far beyond the casino's normal time becomes Overdue.
A silent Overdue record becomes Abandoned unpaid.
It stays visible, stays in the unpaid count, and shows the date last confirmed outstanding.
There is no separate long-unresolved state.
It would describe the same condition and create a place to park records quietly.
One Part paid state cannot store every payment event.
Instalments may come from a weekly cap or partial release. Each arrival needs its own amount and date.
A record stores payment legs.
Each leg has an amount, method, arrival timestamp, reversal status, and the outstanding balance after it.
The record state is calculated from its legs, then stored for fast lookup. The legs are the source of truth. The stored state is a cache and is recomputed if a leg changes.
It is not stored separately beside them.
Paid means the outstanding balance reached zero.
Part paid means at least one leg arrived and the balance is still positive. It is a live state, not a terminal one.
The payout median uses the final leg's timestamp.
The question is when the player had all the money, not when the first part arrived.
A record whose balance never reaches zero keeps adding time.
It never edits an earlier leg. A clawback stays visible instead of rewriting history.
A quiet concealed refusal is the hardest case.
The player may omit a refusal without arguing about it.
A concealed refusal can look like a stalled withdrawal.
The casino may void a win for a bonus breach and email the player. If the player reports only that the money never came, the casino may look at fault despite acting correctly.
The system has no second source for a concealed refusal.
We never contact the operator. Nothing inside this loop can reveal an email the player hides.
This limit is stated openly.
The protections below reduce its frequency and effect. None can detect every concealed refusal.
One record cannot move a published figure by itself.
The thresholds in chapter 3 require enough separate verified members before a median appears. One member's effect on any slice is also capped.
Individual records make outliers visible.
One concealed refusal beside twelve six-hour payouts looks like an outlier. Inside a composite score, it would move the result without showing why.
The reminder asks about more than payment.
It asks whether the casino said anything, whether the account remains open, and whether anything was cancelled or voided.
A false reminder answer becomes part of the record.
Omitting an email is one act. Clicking "they have told me nothing" while holding that email is a recorded false statement and can cost the player standing.
A "still waiting" answer asks for a cheap artifact.
A screenshot may show that the pending row vanished, the balance changed, or the account was restricted. It costs one tap and may reveal the answer.
Standing makes false reports costly.
A player with verified identity, levels, and a reliable record history has something to lose.
New dramatic accounts carry less weight.
The standing tiers tell readers to treat them differently. The system does not need to catch every lie to make lying costly.
A casino can dispute a record without us contacting it.
An operator that finds its page can mark a record factually wrong. The Disputed flag appears on the record, see chapter 4.
A dispute does not make the casino right.
We do not decide or take the casino's word over the player's. The reader sees both positions.
The evidence layer is partial but stronger than common alternatives.
Trustpilot, AskGamblers, and forums have no comparable defence. They may not even prove that the writer has an account.
The target is better evidence, not perfect evidence.
A written limit is more useful than a limit nobody has noticed.
A claim that the casino did not pay should carry evidence.
Evidence sets the tier, not whether the record can be filed.
Every evidence level still files.
Lower evidence produces a lower placement. The player is asked for the best evidence they actually have.
This includes an email, live chat transcript, or interface message. It can be pasted or screenshotted, read by OCR, and published as the casino's statement.
It may show the withdrawal as cancelled, reversed, voided, or missing from a list where it once appeared. The player uses the same screen and capture habit as before.
The amount must be dated. A balance alone is weaker because it does not show who changed it or why.
It enters the lowest tier and is buried, see chapter 3. It is labelled honestly as one person's account with no supporting artifact.
The original withdrawal evidence already proves half the case.
We keep the pending withdrawal screenshot from the request date. The player only needs to support the ending.
A locked-out player cannot open their transaction history.
The evidence ladder mostly breaks when the account cannot be opened.
An account closed during a pending withdrawal is the most serious pattern on the site.
The case is raised as its own outcome instead of being lowered as weak evidence.
Accusatory counters are published as reports, never as our verdict. LOCKED
The counter reads "3 verified members reported losing account access with a withdrawal outstanding", not "account closed: 3". The first is a true statement about what members reported. The second is an assertion about the casino that we cannot stand behind. Same number, and only one of them is safe.
A fast automatic gate stands in front of every accusatory counter. In seconds the machine checks three things: an evidence artifact is attached, the member's identity is verified, and the account link predates the withdrawal. Pass all three and it publishes at once. Fail any and it holds for a person. There is no slow queue and no artificial delay, only a floor.
No accusatory counter ships at launch without counsel sign-off. Until then the site shows the timing figures only. This is a hard launch blocker.
Account closed with a withdrawal outstanding is a separate outcome.
It has its own count on the casino page. It is never folded into slow payouts or refusals.
Three account closures at one operator need no added description.
The count is the fact.
A locked-out player can still provide evidence.
Several sources may remain available.
It shows an absence, but it is still evidence.
Many operators send one.
The support email thread survives outside the account.
Existing records can prove the earlier account link and pending withdrawal.
The full sequence combines several proven facts.
It can show a verified member, a proven casino account, a proven withdrawal request, and a later inability to log in.
No single item proves confiscation.
We never claim that it does. We publish the dated sequence and let the reader decide.
Account closed is also the easiest serious claim to fake.
A failed-login screenshot is easy to make.
Account closed has the strictest standing requirement.
It counts as its own outcome only when the member's identity is verified and their casino account link predates the withdrawal.
Other account-closure reports enter the buried tier.
They are treated like other unsupported accounts.
We do not communicate with casinos about players by default.
We do not verify records, chase cases, or check stories with them.
"We tell the casino nothing" remains the main rule.
Everything below is a narrow exception, not a second operating mode.
The exception exists for contested refusals.
Sometimes only the operator can say, "We voided this, here is the clause." This contact channel is a different thing from the public reply in 11.1b. The reply is a launch feature and an annotation that moves no number. This channel is the operator contacting us about one contested withdrawal, and it belongs in phase two, never phase one, under the three guards below.
Rare access uses fixed rules.
Case-by-case access could look like favouritism. The same published trigger applies to every operator.
The operator channel opens only when all three conditions are met.
We never start it for a good story, a large amount, or a record that looks wrong.
Consent applies only to that specific case.
The operator must have disputed it, or the player must be challenging a stated refusal. A slow payout or uncontested record never qualifies.
Records outside these conditions follow the normal process.
We publish the player's evidence and any operator dispute flag. We do not decide who is right.
Player consent makes the contact lawful.
A casino's data protection officer will not normally discuss a named customer's transaction with a third party.
Unasked pressure can slow the player's payment.
Risk teams may treat outside pressure during payout as a mild fraud signal.
Written consent changes the role of the channel.
The player is using a right over their own data, with us carrying the request. We are not questioning the operator about someone without permission.
The operator channel stays simple.
It contains a record link and a box for the operator's reason and clause. It has no integration, account management, or relationship.
Three fixed rules control the operator channel.
The first protects the site's independence.
Every operator gets access on identical terms.
Access is never a relationship perk.
Friendly operators get no special channel.
Any operator can use the same published door. Prior contact with us makes no difference.
Operator participation creates no metric or badge.
It cannot earn a mark, tier, placement, or number.
Fast replies do not prove good payouts.
A clerk who answers within an hour could beat a casino that pays but replies slowly. The channel adds facts to records, not scores to operators.
Operator replies annotate records but do not decide them.
The operator's statement appears beside the player's statement, like a Disputed flag.
An operator reply does not change the state or median.
It cannot remove the record.
We never say who was right.
A casino explaining itself does not make the explanation correct.
The channel should not be built if these three rules cannot hold.
Its value would be lower than the independence it costs.
"Pending" does not mean "processing."
It may mean the casino has not started. We measure from request to arrival, not between status changes.
Crypto payouts may be batched to save fees.
An "instant" payout can still wait for hours before broadcast.
Every record can include a short written account of what happened.
The account is optional and uses the player's own words. We ask for it at confirmation, after the story has an ending.
A written account sits on top of a timestamped withdrawal with evidence.
A Trustpilot review is only a story. This account has proof underneath it, so the same words carry more weight.
Attached accounts sit on withdrawal records.
Each one has a timestamped event with evidence underneath it. This is the premium tier, and casino pages show these first.
Standalone accounts cover everything that is not a cashout.
Good and bad. A bonus that could not be cleared, or one that was genuinely fair. Support that never answered, or an agent who sorted it in five minutes. A frozen game. An account closed with no explanation. The wagering terms, the game selection, whether the app works.
A player can write "I really liked the customer support" and that is a valid account.
Nothing here is limited to complaints. A site that only carries bad experiences is not a record of what a casino is like, it is a complaints board, and the numbers stop meaning anything. The player experience is more than its last five minutes.
A standalone account requires proof of a deposit.
A linked account only proves that someone registered. Registration is free, so a competitor could open fifty accounts and write fifty reviews at no cost.
Money makes fake accounts expensive.
The player must provide a transaction history screenshot that shows at least one completed deposit. This is the same page used for the withdrawal screenshot, so it requires no extra work.
There are three standing tiers at each casino.
Each tier matches the effort and cost needed to reach it.
| Tier | Proof | What it permits |
|---|---|---|
| Registered | Account page screenshot | Read, take part, and write, but only into the buried bucket below everything else |
| Deposited | Transaction history showing a deposit | Standalone accounts, published in the main section |
| Withdrew | A full evidenced withdrawal record | Attached accounts, and feeds the numbers |
Nothing is blocked, but everything is tiered.
Someone may fail to deposit or have their account closed first. They can still write, but their account appears in the buried bucket with unverified records.
Unverified accounts appear below everything else and are clearly marked.
See chapter 3. Hiding them would hurt our Google presence and silence a real type of complaint.
Deposit proof covers confiscated wins that the withdrawal clock cannot see.
A confiscated win never becomes a late withdrawal. The player has deposits but no withdrawal, and the deposit proof makes their account credible.
Standalone accounts have their own section below evidenced records.
They are clearly marked.
Standalone accounts never affect any number on the page.
They do not affect a median, ranking, or count. They are testimony, not measurement.
There are no star ratings.
A star average is another type of combined score. Chapter 3 rules these out.
There is exactly one structured sentiment question.
"Knowing how that went, would you deposit here again?" Yes / No
Every record that reaches an ending gets this question.
This includes bad endings.
A record ends in one of these eight terminal states: Paid, Refused, Cancelled, Account closed, Abandoned unpaid, Closed short, Method changed, Unconfirmed. Part paid and Draft are live, not terminal.
Every terminal state answers it, or would if the player were still reachable: Paid, Refused, Cancelled, Account closed, Closed short, Method changed, Abandoned unpaid, Unconfirmed. Refused is where a confiscation is recorded. Live records do not answer.
Every terminal state in chapter 4 is included.
Only live records are excluded. A person may be unreachable after the record ends.
Bad endings must stay in the percentage.
If only paid records could answer, refusing a withdrawal would remove a near-certain No. This would raise the casino's published percentage.
A metric must not improve when a casino treats a player worse.
Including the worst outcomes stops the metric from rewarding refusals.
Open records do not count either way.
They have no ending yet. The displayed count makes this clear.
The metric has an unavoidable response bias.
The player must still be engaged to answer. The people treated worst may be the least likely to reply.
An Abandoned unpaid record may hide a missing No.
This state means the player stopped replying. Some players may leave because they never want to think about the experience again.
A respondents-only percentage can reward a casino for driving players away.
When a player stops replying, their near-certain No leaves the total.
The result is published as a range, not one number.
Between 44% and 68% would deposit here again. 31 of 47 endings answered.
The top of the range uses respondents only.
The bottom of the range counts every non-response as a No.
Neither end is presented as the truth. The real figure is somewhere between them.
Silencing players makes the range wider and pulls its bottom toward zero.
It does not raise the published result.
A tight range means most endings received an answer.
This is evidence that players were not driven away.
A wide range means many endings went unanswered.
That fact is useful on its own.
The percentage comes from one question tied to a real account and withdrawal attempt.
It is not a combined formula.
Standalone accounts never include this question.
People cannot influence the percentage by posting text alone.
A cancelled withdrawal can be repeated at no cost.
The money returns to the account. A player could deposit, request, cancel, answer No, and repeat.
Each member gets one answer per casino.
Only the most recent answer counts. Twenty endings from one person still equal one voice.
The percentage uses the same distinct-member rule as medians and counts.
It is not published until at least 5 separate people have answered. That is the distinct-member gate. Unlike a median it has no 8-record floor, because an answer is not a timed record.
Cancelled endings appear as their own share of the answers.
Readers can see whether most No answers came from reversals instead of completed payouts. We can see it too.
The cancellation rate uses the same distinct-member gate.
Without it, one person could create a casino's reversal figure by cycling deposits.
Written accounts cover problems the numbers cannot measure.
Examples include:
A voided win never becomes a late withdrawal, so the clock misses it. The player can still describe it.
This includes three rounds of "your document is too blurry".
This includes an agent copying and pasting the same line five times.
This includes a request on withdrawal number eleven after ten withdrawals were paid without one.
The written account is free text, never a dropdown of accusations.
Dropdown choices would turn the player's claims into our words.
Every ending also gets one structured document question.
This covers one of the most common complaints, which nobody measures.
"Did they ask you for documents during this withdrawal?" No / Once / More than once
A sudden repeat document check can be an early warning.
This matters when a casino has already paid the same player many times.
We ask after the story ends.
We do not ask while the withdrawal is still running.
We ask at every ending.
When the money arrives, when a refusal or confiscation is recorded, when the player cancels, when a record is closed short, when an account is closed, and when a player returns after an unconfirmed or abandoned record. We do not ask while a record is still live.
We do not ask for a review during a stuck withdrawal.
Asking on day three produces anger, not useful information.
Nobody starts with an empty text box.
A blank field saying "tell us about your experience" stops many people from writing.
The prompt asks about moments people remember.
Every question is optional.
How long did it take before anything moved? Did anyone actually answer you, and were they any use? Did anything change that you were not told about? What would you tell someone about to deposit here?
The response is free text, never a dropdown of accusations.
Dropdown choices would turn the player's claims into our words.
The prompts are neutral questions.
They are not answer choices, and they do not suggest an answer.
We ask for a short account.
A few sentences are more useful than a wall of text.
Long accounts are shortened for display.
The full text is always one click away.
Our summary is clearly marked as ours.
It never replaces the original, which stays unchanged on the page.
We never rewrite, soften, or correct the player's grammar.
A six-week withdrawal is not one event.
The player may need to record several important moments.
The account is append-only for its author.
The player can add updates as events happen. Each addition gets a timestamp.
The author cannot rewrite or delete published text.
The published account shows the whole thread in order.
Append-only rules apply to the author, not moderation.
Moderation is a separate action performed by us.
Moderation is never silent.
Removed content leaves a visible marker. See chapter 11.
Players cannot quietly change history, and we cannot quietly erase it.
The two rules apply to different people.
Timed updates show details that an ending summary may miss.
"Day 9: they asked for a utility bill. Day 14: asked for the same bill again. Day 22: paid without explanation" is more useful than one line written at the end.
Nothing is quietly deleted.
A removal leaves a visible marker saying what was removed and why. See chapter 11.
We remove named staff, other players' personal details, identity risks, and threats.
We do not remove anger, accusations, or claims that an operator says are untrue.
The account records what the player says happened. We do not decide who was right in the dispute.
Screening happens automatically before publication.
Chapter 12 rules out work that needs daily manual checks for every item.
Publishing first and removing later needs permanent manual review.
Screening first sends only the small flagged group to a person.
The removal rules are designed for automatic checks.
Personal names, contact details, account numbers, and threats can be detected as patterns.
We never try to decide automatically whether an accusation is fair.
Fairness is not a pattern problem. Avoiding that judgment keeps the review queue small enough for two developers.
A flagged item is held while other submissions continue.
Its author is told that it was held.
The system must handle coordinated waves of complaints.
A casino with a real grievance can attract one.
Standing tiers and per-member rate limits control large complaint waves.
The answer is not asking a person to read faster.
The model finds repeated themes across accounts.
For example: "eleven people mentioned repeated document requests at this casino".
The model never creates a number or rating.
The model never writes an account.
Accounts give player communities a lasting memory.
The same question may appear in a Facebook group every nine days, receive the same twenty replies, and then disappear.
Accounts attached to casino pages build up instead of disappearing.
The product records payout times and quiet changes to casino terms.
We keep dated copies of each casino's terms and publish what changed. This lets people check claims that a rule was always there.
We track only terms that can decide whether a player gets paid.
This includes withdrawal limits and caps, dormancy, verification triggers, maximum wins, and bonus forfeiture.
Version one does not build the weekly terms archive. LOCKED
Instead the passport carries one dated field per casino: the published payout window, the withdrawal cap, the source URL, and the date we read it. That single field is all the rest of this document actually uses, the Overdue benchmark and the instalment display, so nothing else breaks.
The full weekly-snapshot archive is a later product. Scraping, diffing and a confirmation queue against a two-developer budget is a third product, not a launch feature. It comes back once the core loop is proven.
Every casino has a useful profile before it has any records.
Payout data cannot provide this information.
Every casino page shows a factual profile built from public sources.
The profile includes:
The passport covers confiscated wins that payout records cannot see.
See chapter 4. A confiscated win never becomes a late withdrawal. An operator could pay every small withdrawal in six minutes, void every five-figure win, and still look excellent.
Maximum-win caps and bonus-forfeiture clauses are visible before anyone loses money.
The payout clock measures behaviour after it happens. The passport shows the terms an operator can use.
The passport cannot be attacked by choosing which records exist.
See chapter 9. A licence number stays the same whether the operator likes it or not. No group can change that fact by choosing which records to submit.
The passport makes an empty casino page useful.
A casino with no records has no payout numbers. Its page can still show who owns it, its licence, and its payment terms.
A page with no records must clearly say so.
The page remains useful, honest, and available to search engines from day one.
Sibling brands show links between casinos owned by the same operator.
An operator may launch the same business under new names. A shared owner with three other brands can be a stronger warning than a median.
Sibling-brand information does not need a contributor.
Ownership can be found in public sources.
The passport is cheap to build and maintain.
Licence registers and terms pages are public. Ownership is usually listed in the site footer or licence record. The work is scraping and maintenance, not a new product.
The passport has no score, grade, or combined rating.
It states facts and links to sources. It never rates a licence as good or a jurisdiction as safe. See chapter 3.
Every field shows its source and the date we read it.
A licence status that was correct in March may not be current today. Showing old information as current can cost more than the feature is worth.
Records publish within seconds.
The first record for an uncovered brand can create a casino page from a name or URL typed by a stranger.
A submitted name or URL is a hint, not a fact.
Players often misspell domains. A small mistake can create a second page, split one operator's records, and corrupt both pages' counts.
It uses fuzzy matching against known brands, known domains, and the mirror-domain list. A confident match joins the existing casino. Any other submission creates a provisional casino.
noindex and has no stable URL.Its record is visible to anyone with the direct link, but the provisional page is never indexed and never appears on a public casino page until a person confirms the brand. The page does not enter the index until a person confirms the brand exists and matches its claims. Indexing junk brands would damage the product's only acquisition channel.
link.verify.See chapter 12. The review checks whether the operator is real, whether it mirrors an existing casino, whether its licence claim is plausible, and whether the domain matches the licence record.
If a provisional casino is an existing brand, all its records move to that brand. The provisional URL returns 410 Gone, not 404, so search engines remove it cleanly.
Mirror domains are different addresses for the same operator.
The list comes from past review decisions. It is not bought.
Every mirror-domain entry has a named owner and review date.
An old list can be worse than no list.
Only a verified casino can mark a record Disputed.
See chapter 4. An operator has no member account; it verifies through a separate domain-control route, scoped to reply, dispute and its paid profile only, per 11.1b. Without that verification anyone could use the Disputed flag as an unlimited public attack on a rival.
Verification uses domain control and nothing else.
We send a magic link to an email address on the brand's primary domain. We reject generic email providers.
Verification does not use documents, phone calls, or relationships.
Domain control is cheap to check and hard to fake without controlling the domain.
Verification controls access to the Disputed flag and the phase two channel.
See chapter 4.
The dispute channel must be built mainly for operators.
Across roughly two and a half years of one competitor's data, 91 percent of all reports came from casino representatives. Operators will be the main users of this system.
A dispute without a stated reason is not a dispute.
This stops anyone from covering a rival's page with disputes.
An operator whose disputes rarely lead to a correction can file fewer. We never decide who was right about a withdrawal. A dispute leads to a correction only when the operator shows the record is factually wrong, a wrong amount, a wrong date, the wrong casino. That is a fact check, not a judgement.
Two attempts are allowed, ever.
A visible "under review" marker would let competitors create stigma. The flag shows that another position exists without suggesting the record is doubtful.
Evidence covers what we can check.
We can verify that an account exists, a request happened, and money arrived. Crypto is checked on chain. Fiat is checked with an attached bank or wallet screenshot.
Level covers what we cannot check.
This includes an arrival that the player claims without attaching proof. The level tells readers how much weight to give these claims.
Members have a visible level from 1 to 99.
Levels rise as members contribute. People can see, work toward, and display their level.
Levels are the product's only motivation mechanic.
The system uses game-like progress because it makes contributing worth the effort.
Levels affect how records are handled.
Higher-level members corroborate contested or flagged records. A record reaches a higher tier when several senior members back it independently.
Senior standing must be slow and costly to fake.
A ring cannot quickly or cheaply create senior accounts. Fraud depends on being fast and cheap.
The first group is paid per test.
This pays for records and teaches a group what a good test looks like. It also creates the senior members who set the standard.
Payment drops as status takes over.
Standing, perks, and access replace payment over time.
Members must earn access to a closed Discord.
The Discord is not open to everyone. Members must level up and prove themselves first.
The Discord gives serious players useful early information.
Its members may know which casino is becoming unstable before that information is public.
Identity verification unlocks rewards instead of blocking entry.
People are unlikely to upload a passport for eight dollars. They may do it to unlock status and a closed room.
The level curve. LOCKED
Points accumulate. Tiers are point thresholds plus a few gates. Levels interpolate evenly inside a tier.
| Tier | Levels | To reach | Unlocks |
|---|---|---|---|
| Registered | 1 to 9 | 0 to 99 points | Records publish, buried but visible |
| Verified | 10 to 29 | 100 points and KYC | Verified badge, records rank normally |
| Established | 30 to 59 | 400 points, 3 distinct casinos, 60 days | Records count toward ranking, flag a record, early sight of the weekly numbers |
| Senior | 60 to 89 | 1,200 points, 5 distinct casinos, 180 days, no proven false statement | The Discord, corroborate contested records, alerts on casinos you have no account at |
| Top | 90 to 99 | 3,000 points, manual invite | Paid tests first, a say in which casinos get tested, direct line to the team |
What earns points:
| Action | Points |
|---|---|
| KYC verification | 50 |
| A completed evidenced withdrawal record | 25 |
| Arrival proof attached (bank line or on chain) | 10 |
| A casino account link | 15, once per casino |
| A verified deposit at a distinct casino | 20, capped at 8 casinos. Off until the link-graph protection ships, see 7.1 sequencing. |
| A written account on an evidenced record | 5 |
| Answering a reminder on time | 2 each, capped at 10 a month |
| Corroborating a contested record that holds up | 15, Senior only |
| A completed paid test | 20 |
The anti-farming cap. No more than 150 lifetime points from any one casino. A ring farming a single operator stalls in Verified and never reaches the tiers that matter.
Losing standing is public. A proven false statement, a concealed refusal caught or a fabricated artifact, costs 100 points and one full tier, logged where anyone can see it. Standing is the only real restraint, so its loss has to be visible.
No decay on the number, but senior privileges sleep. The level never drops on its own. Senior and Top privileges (Discord, corroboration, paid-test priority) pause after 180 days with no evidenced record or corroboration, and resume on the next one. This keeps seniority slow to fake without punishing the recreational player.
This curve suits both a first-timer and a professional. A blindsided first-timer with one fully evidenced record plus KYC lands around 105 to 120 points, clearing Verified on their single real case, which is the tier where their record ranks normally. Above Established the ladder stays weighted toward players with many distinct casinos, because that pattern is the fraud defence. The methodology page says this plainly: entry standing is built for the first-timer, senior standing is built for fraud resistance.
Every perk helps members judge which casinos to trust.
The perks are not generic loyalty rewards.
Senior levels include real responsibility.
This makes the level valuable and slow to fake.
Discord information must already be planned for publication.
Information may also appear there under a short embargo.
The Discord must not become a private information advantage.
That would make access worth buying and give operators a strong reason to infiltrate it. One employee could level up for two months and then see everything early.
The product has no streaks or daily check-ins.
It also gives no points for gambling volume and has no public member leaderboard.
The product does not reward frequent gambling.
That would target the wrong behaviour at the wrong audience. Experienced players may also see it as a farming scheme for a future token.
The casinos are the contestants.
Members have standing, not scores.
Levels come mainly from actions that cost real money or require a real identity.
These actions are harder to fake.
Identity verification is a ceiling, not a gate.
Members can join, add records, and climb without it. At a set level, they cannot progress further until they verify.
Unverified members cannot access the Discord, corroborate records, or receive paid tests.
Verification is never required upfront. It is never required just to take part.
Verification becomes useful after members have built standing.
People may verify once they want the room and status. By then, they also have their own records to protect.
Verified deposits at distinct, unrelated casinos can raise a member's level.
A casino link counts only when transaction history shows that money went in. Registration alone is free and does not count.
This signal stays off until the link-graph storage in chapter 15 is built.
The signal would create a cross-operator file about each member. That file must be protected before members are asked to create it.
This order cannot change.
Building personal dossiers before their protection exists is the largest risk this design creates for contributors.
Real players usually link to more unrelated casinos than seeding accounts.
A seeding operation cares only about its own casino, so each account links to one operator. A real player may have five or eight.
Records gain value when they hold up.
A record can be corroborated independently. It can also match later records from other members about the same operator.
Volume and tenure affect levels only weakly.
Both are cheap to farm.
A badge can make one record credible.
It does not make a casino page credible.
Sample size and recent activity make a casino page credible.
"212 cashouts, last one 40 minutes ago" is stronger than a badge. Dubious sites can put badges on themselves.
The site launches with a founding corpus of roughly 2,000 measured withdrawals, not an empty scoreboard.
These cover the target casinos and are logged before launch.
The founding contributors are veteran real players, not a recruited farm.
They are experienced casino players, for example long-standing reviewers from the public paid-review contests, who log withdrawals at casinos where they already have real accounts and playing history. This is their normal activity, not manufactured sessions.
They use the exact same flow, and the same approval, as any player.
They log a cashout and write an account through the ordinary product flow. Every contribution passes the same quality approval, applied to the work regardless of whether the outcome is positive or negative for the casino.
They are paid through the public loyalty engine, the same feature every player uses.
There is no closed batch, no pay-per-verdict, and no special payment arrangement. The loyalty engine is a public product feature that rewards every contribution on the site, so the founding group is paid exactly the way a future player is.
Evidence earns a small bonus, for the verification work, never for the verdict.
Any approved contribution backed by evidence, account history or transaction files, earns a small loyalty bonus, on the order of $2. It pays for the cost of verifying, and it deliberately builds the evidence corpus the whole product stands on. It applies to everyone, founding group included, and there is no bonus for a positive result. A negative submission is never rejected for being negative.
This is incentivized-and-disclosed, not fabricated.
These are genuine users reviewing casinos they actually play at, the legal and disclosable category of incentivized contribution, not reviews from people who never used the business. Disclosure is intrinsic because the loyalty engine is a public feature applied to every contribution, and founding-member activity during closed beta is stated openly.
Every founding contributor verifies identity.
Verification is required because we pay for this data.
Founding records stay in their own separate bucket and never fill an organic gate.
Their calculations are separate. Organic medians require organic members; founding records cannot supply those members, or the separation would be cosmetic. Both numbers appear on the page, labelled and never merged into one figure, and every page shows founding records as visually distinct from organic player records.
Compensation and method are public on each record.
Each founding record shows that it was incentivized, never disclosed only in a footer, and the method, who contributed, the instructions, and the loyalty terms, is public.
The founding corpus solves the cold-start problem.
The page is useful on day one, before any organic player contributes, and the framing describes a method, not a scandal.
A tester withdrawing their deposit is not withdrawing winnings.
The product focuses on winnings withdrawals.
Rankings use winnings withdrawals only.
See chapter 8.
The headline compares winnings with the player's own money.
See chapter 3.
Most tester sessions produce own-money withdrawals.
A tester may deposit, play a little, and cash out. Most sessions lose, so the withdrawal mainly returns the tester's own money.
Four thousand tests could leave every league table empty.
They could also leave half of every headline blank.
Testers cannot be told to win.
Instructions cannot solve this limit.
The tester brief gives priority to winnings withdrawals when they happen.
Testers play in their own way and sometimes finish ahead. Those sessions are the most valuable.
A winnings withdrawal must include proof of the tester's net position.
The tester cannot simply state that they finished ahead.
Launch claims cover only what the tester corpus supports.
Own-money payout times, coverage, terms, and the method are available on day one.
Winnings medians and rankings stay limited until organic records arrive.
The page says when data is thin. It does not show a confident number based on four records.
Our own data follows the warning in chapter 8.
The own-money bucket is cheap to flood by cycling accounts. A large paid corpus in that bucket has the same shape as data we would criticise elsewhere.
Paid tester data stays visibly separate for this reason.
The separation protects the numbers as well as disclosing how the data was produced.
A withdrawal still has value when it never enters a headline.
It proves the account existed, measures the deposit-return path, and adds data to the page and index.
The launch plan cannot assume tester records seed the most important numbers.
We need a league table.
People need to compare casinos.
The league table is not a trust score.
It only ranks payout speed.
There is no single league table for all casinos.
Chapter 3 does not allow the blended number this would need. Mixing wire transfers with stablecoin transfers measures payment methods, not casino behavior.
A crypto-only casino would automatically rank above a good card casino. This would make the table easy to attack.
Casinos rank within each payment method.
The reader chooses how they would get paid. They then see casinos ranked for that method.
Examples include fastest by bank transfer, fastest by card, and fastest by USDC. Each compares casinos using the same type of payment system.
Each method ranks measured payout time for winnings withdrawals only.
The own-money-back group is cheap to flood by cycling accounts.
A casino appears only after meeting the threshold for that method.
See chapter 3. A casino cannot borrow a number from another method. An overall rank cannot replace a missing method rank.
Rankings use distinct verified players, not record count.
One person can file many records for one casino. Fifty records from one person show behavior over time, not fifty independent witnesses.
Sample size appears beside the rank, never inside it.
There is a minimum sample size to appear. The player count is shown at every rank.
No model produces the ranking number.
A model can read reports and find repeated themes. For example, "eleven people mentioned repeated document requests."
The ranking number comes from measurements. A casino that disputes the ranking must dispute the measured time, not our opinion.
The trend is the most valuable single result.
For example, "Median went from 5 minutes to 4 hours over the last 10 days." This gives players an early warning that nobody else offers.
Serious players would pay for this. It also answers, "is it me or is the site broken."
The combined data is shared, not the personal case.
One person's record is an anecdote and can be dismissed. The casino page is worth sharing because it can settle arguments.
Sharing uses two formats.
The two audiences behave differently:
These sites show link previews. The preview image must include the casino name, number, sample size, and recency because most people never click.
Links rank last in these groups. Many members will not click a stranger's link, so the screenshot is the proof.
Shared links stay live instead of becoming snapshots.
A case shared while five days pending must change to "paid after 9 days" when it ends. Old links must not keep showing stale information and make us look unreliable.
Shared content never includes identity.
Use a case reference, never a username. Amounts are grouped into bands or hidden, based on the member's choice.
We are not fraud-proof and will not claim to be. UNSOURCED
Trustpilot removes fake reviews on a very large scale every year and publishes the number. It has also publicly flagged casino review sites for removed fake reviews. We need to be better than that, not perfect. [Exact figures to be sourced before any of this reaches public-facing copy.]
Self-seeding is the cheapest attack on this site.
A casino can use accounts at its own casino. It controls the accounts, payouts and timestamps. The money returns to the casino, so this costs it nothing.
Five verified people could pass the distinct-member gate, per 14.1.
They could make real withdrawals using money that keeps moving between accounts. The casino could pay every withdrawal at once.
Verified identities are the scarce input.
Each identity must belong to a real person with real documents. Each person can only count once.
The pattern is visible even when every record is real.
A group may appear together, use only one casino and receive unusually fast payouts. That pattern appears in the data even when no record is false. See chapter 7.
Self-seeding cannot make another casino look bad.
It can only create a flattering median for the casino doing it. Real player records can undo that median when they show different results.
Self-seeding remains a real weakness.
It is not fully stopped. This supports the distinct-casino weighting in chapter 7. One group of members must never establish a casino's number by itself.
The strongest defence is activity across unrelated casinos.
A seeding operation only cares about its own casino. A real player often has accounts at several casinos. Verifying eight unrelated operators means funding competitors to make the seeded accounts look real.
A competitor can cheaply make a rival look bad.
It can file a pending record with a fake screenshot and never confirm payment. This needs no deposit, real account or money at risk. It harms the main number shown on the page.
One fake record changes no published count.
The record appears at once, like every record. But headline counters use the same distinct-member gate as medians. See chapter 3. One fake pending withdrawal appears as one person's claim and changes no figure.
Unverified records stay buried and do not affect the ranking.
The cheapest attack reaches the least visible part of the page.
Clusters reveal coordinated attacks.
A burst of pending records may target one operator. The accounts may be created during the same period, and none of the records may ever close. We can state this pattern without accusing anyone.
The linked-account requirement sets a tier, not a gate.
We ask for the account link after the first record, not before it. A fake first record only costs the attacker an email address.
An unlinked record affects no median or counter.
The record is published in the buried tier. It does not feed any published number.
The cost applies to being counted, not being published.
Anyone can publish a first record cheaply. Getting that record counted requires more proof.
Spread across related brands does not count as real spread.
An operator with several brands could seed records across its own group. Shared platforms, payment processors and nearly identical terms can show that the brands are related.
The operator graph connects related brands.
See chapter 6. It uses shared licences, legal entities, platform fingerprints, payment processors, terms language and mirror domains. The passport already collects most of this from public sources.
Every mirror-domain list needs a named owner and review date.
An old list is worse than no list. It turns "we did not know" into "we knew and carried on."
Time is a defence because attackers cannot buy it.
An attacker cannot create months of records across unrelated casinos in one week. That matters when a casino suddenly wants to repair its reputation.
We publish these limits on the public methodology page.
A critic should find the flaw because we already explained it.
Every defence in chapter 9 checks whether a record is true.
Three independent adversaries reviewed this document separately. All three concluded that a serious attacker would not file a false record. Cheaper attacks need no lie and avoid every gate, tier, artifact ladder and threshold in this document.
Attackers control which records exist.
A player may hide a refusal they deserved and file the two refusals they dispute. Both filed records may include the maximum evidence. Nothing is false, and the missing record cannot be detected.
Missing records can make a correct operator look dishonest.
The operator may have enforced its terms correctly. But its refusals appear to have no valid reason because the player did not file the other record.
Attackers control when records arrive.
Every figure depends on arrival time. The contributor controls that time.
Thirty real members can change the not-paid line and trend in one afternoon.
They can file thirty real pending withdrawals at the same chosen time. Nothing in those records needs to be false.
Withheld records can hide an early warning.
A player leaving an unstable operator may wait until their money arrives before filing. This hides the warning when it matters most. The delay leaves no trace.
Attackers control who gets asked to contribute.
An operator knows the time taken for every payout it completes. It can invite only players paid within thirty minutes. It can ignore the player held for eleven days.
Selective invitations create genuine but distorted records.
The records can come from distinct real people at real evidence tiers. The distinct-member gate does nothing because every person and record is real.
Selective invitations are free and break no rule.
An operator's marketing team can use this method without being asked.
An operator can identify contributors and pay them faster.
This breaks the strongest claim in chapter 3. That chapter also covers the control group, which is the only way to detect it.
No threshold fixes selection attacks.
Higher gates increase the cost of large attacks. These attacks do not need large numbers.
Standing is the only mechanism that can restrain these attacks.
Standing must have value, and losing it must be public. This is why the level curve in 7.1 makes losing standing public.
Anything that weakens standing removes the only working restraint.
The system must protect the value of standing.
Turning omissions into statements helps.
Chapter 4 asks whether the casino said anything, whether the account is open and whether anything was voided. This turns a free omission into a clear statement that can be proved false.
These statements only help with records that someone files.
They cannot reveal a record that was never created.
Every casino page publishes its contributor mix.
The page shows the share of records from members with very many linked operators. It also shows the share from members filing their first record.
Contributor mix needs no judgment or manual case decisions.
We already hold the data. Publishing it gives readers the context needed to understand a distorted page.
A narrow contributor group produces a different page from a broad group.
Only we can see which kind of group supplied the records. We must show that difference to readers.
The trust ladder is not neutral and must be chosen on purpose.
Chapter 7 treats deposits at distinct unrelated casinos as the strongest signal. The reason is that a seeding operation usually links only its own operator.
The strongest fraud signal also selects professional bonus players.
Almost no other group has that account pattern. A recreational player may use three operators and withdraw only a few times each year.
The ladder promotes the most hostile population and lowers the population the site serves.
Professional bonus players rise because they have many records. Recreational players fall because they have fewer.
There are only two choices.
We can lower the weight of that profile and lose the best-supported, highest-volume contributors. Or we can accept the profile and state that choice on the methodology page. The document currently chooses the second option by accident.
Evidence quality tracks expected harm, not actual harm.
Players with a clean artifact chain were already collecting proof. People usually collect proof because they already distrust the operator.
The top evidence tiers fill with wary professionals.
The bottom tier fills with first-time players who did not expect trouble. Those first-time players are the people the site exists to serve.
The website comes first.
It works for everyone on day one. It needs no install or store review. It tests whether anyone will log a cashout.
The native app comes second.
We build it only after people show they will log cashouts. It adds the share sheet and push notifications.
The share sheet lets people add screenshots without leaving the casino app. Push notifications help paid users close their cashout clocks.
A web app meets the main requirement.
Screenshot uploads work on every phone. This is the core flow.
Web push also works. On iOS, users must first add the site to their home screen. Most people never do this.
Only the share sheet requires a native iOS app.
Safari has never supported the Web Share Target API. The share sheet is useful, but it is not required.
Ship the web app first. Build the native app only if traffic shows that the share sheet and reliable push matter.
The app has no casino links of any kind.
It is a personal tracker. This keeps it clear of Google Play's rule against links that call users to wager. Apple has no such rule.
Desktop players use a normal screenshot or a phone QR handoff.
See chapter 2. There is no browser extension or desktop app. Casinos cannot detect or ban someone for using them.
The two audiences need different things.
Trying to serve both from one surface makes people leave.
The web has no login, is fully indexed, and is free to read.
It is the lookup tool and the way new people find us. A person worried about a withdrawal should not need to install anything.
The app is the logging tool for the few hundred community members doing the work.
They find it through the community, not an app store. Discovery is not its job.
The app handles three things that browsers cannot do reliably.
Push notifications are the main reason the app exists.
Confirmation is the weakest part of the product. A record with no confirmed arrival produces no median. It is only a draft with extra steps.
Email that requires a login recovers only a small share of these records.
A one-tap push on the payment day recovers roughly half.
That can mean the difference between pages with medians and pages full of pending records. Everything else depends on that tap.
The share sheet logs screenshots without breaking the user's flow.
Members can log from inside the casino app when they take the screenshot. They do not need to switch to a browser and find the site again.
The app keeps a persistent, ordered list of each member's open cases.
Community members may run several accounts. They need this list, and a web session forgets it.
Reminder emails contain tappable answers that work without a login.
The answers are Paid, not yet, I cancelled it, and they refused. Tapping an answer acts at once.
Removing the login is the cheapest fix in this document.
The measured gap was not email versus push. It was login versus no login.
An email that requires a sign-in and record search recovers far fewer answers. Direct taps close most of the gap for people without the app.
Each email link performs one action on one record and then expires.
It never gives access to an account. Emails can be forwarded, quoted, or leaked. A link that also opens a profile could let someone steal the account.
Nobody must install anything to log or confirm a record.
A person with a stuck withdrawal may not install an app just to upload a screenshot. Every step before the first upload costs records.
The web and email buttons must always work from start to finish without an install.
The community tier requires push and at least a home-screen web install.
This applies to levels, the Discord, early access to numbers, and paid tests.
A native app is built only if the evidence test in this chapter is met. The home-screen web install is the minimum either way.
The data model does not depend on which option sends the notification.
The install is a ceiling, not a gate.
See chapter 7. A person who wants community standing installs it. A person who only wants to log a case is never blocked or asked twice.
Confirmation has three reliability tiers, and none is zero.
Community members answer a push. Everyone else taps an email button.
People who ignore both age into Unconfirmed or Abandoned unpaid under the silence rule. See chapter 4.
The app does not block access to anything.
Anyone can still file a web record without an account. See chapter 2.
The app makes community work faster. It never becomes the cost of contributing.
Web push remains the fallback.
Safari has supported push for home-screen-installed pages since iOS 16.4.
Most ordinary visitors never install a site to their home screen. Community members will do it when their community asks them to.
A store rejection weakens the plan but does not end it.
The home-screen web app still provides push.
The app has no operator links, bonuses, promotions, or paths to casinos.
Apps that name and rank gambling operators may conflict with Apple's real-money gaming rules. They may also conflict with Google Play's rule against calls to wager.
The app only records members' withdrawals and shows the data.
The current store rules must be checked before development starts.
An industry reviewer claimed that stores often remove apps that name and rank operators, even without links. The reviewer also claimed that appeals fail.
This claim is unverified. The answer decides whether the native app or web app is the main surface.
Home-screen web push is the minimum in every case.
The community is told to install it on day one. The data model does not depend on whether web or native push sends the notification.
A live case never ticks for the person who owns it.
A rising counter can become compulsive for someone waiting on a five-figure withdrawal. Show "registered 6 days ago" and send a notification.
Everywhere else uses full detail. Exact numbers make the data credible and easy to share.
Users do not see a running total of their own losses unless they ask.
Casual players may want this feature. It may also make them delete their account.
The product must not look like a crypto product.
Do not use dark mode, monospace, "ledger", "on-chain", or decorative "verified" labels. Many fiat users read these as signs of a scam or a product that is not for them.
Half of them still call buying coins "buying credits."
No "Play Now" button appears near a casino name.
Every player asked said this would destroy the page's credibility.
The homepage starts with a live feed from every covered casino.
$2,400 · Casino X · paid in 6 minutes · just now $12,000 · Casino Y · day 19 · still waiting $840 · Casino Z · logged 4 minutes ago
The feed makes the site feel active instead of static. It always gives visitors something new to read without needing new written content.
The ticker can show other people's open cases.
The no-ticking rule applies only to the viewer's own open case. Watching your own waiting time rise can increase anxiety.
Watching other people's cases resolve can reduce uncertainty. A person can see others in the same queue and learn that two were paid on day nine.
The ticker rewards fast operators.
A stream of six-minute payouts gives free attention to casinos that deserve it. This creates the right incentive.
The ticker never shows identities.
It shows only the casino, amount band, elapsed time, and state. Nothing connects a record to a person.
Three ticker rules are not optional.
A feed can fail in three specific ways.
The ticker never shows viewers their own cases.
A global feed must not bring back the same rising counter that the no-ticking rule removes. Removing the person's name is not enough.
A member will recognise their own $12,000 withdrawal on day 19. Their records are removed from their feed on both the client and server.
Ticker amounts use bands, and the member's display choice wins.
An exact amount at a named casino on a known day can identify a player to casino staff. This risk is highest for the people the site most needs to protect.
Chapter 8 lets members band or hide their amount. The ticker follows that setting.
The ticker cannot be flooded.
Without limits, it is the cheapest part of the site to attack. An operator could post many favourable six-minute payouts. A competitor could post many hostile day-19 records.
The feed uses only records from evidenced tiers. It has rate limits for each casino and member. When volume is high, it samples records instead of showing everything.
The ticker is a window into the data. Nobody can push items directly into it.
The ticker only runs as live when it has enough activity.
Three events from yesterday make the site look less active than having no ticker.
The ticker must use real volume from covered casinos. This supports launching deeply with twenty casinos instead of thinly with two hundred.
If there is not enough volume, label it as recent activity. Do not call it live.
The tester programme supplies activity from day one. This is another reason the pre-launch corpus matters.
Clearance has never been run on this name. OPEN
Buying a domain is not clearance. The earlier CasinoPilot work found a German casino comparison site already using the matching domain, and made trademark checks a day-zero gate. That check was never repeated for Unrigged. A word this common is exactly where somebody got there first, and the cheapest time to find out is before any page is indexed.
The name is not locked and can change.
We keep it for clear reasons, not because we bought the domain.
The name fits the wide product better than the narrow product.
A payout clock alone needs a name about speed or payment. Unrigged would fit that product poorly.
The wider product covers whether an operator treats players fairly. It includes both payment time and what players face during the process.
The name is short, direct, and familiar to players.
It is one word, has a real .com domain, and challenges the industry. Players already use this language.
When players say a site is rigged, they often mean they won but cannot get paid.
Unrigged describes our work, not our verdict on a casino.
The name is a strong claim, but the product does not make unsupported claims.
No casino page, record, ranking, or feed item calls an operator rigged or unrigged.
We publish what happened, how long it took, and what the player wrote. The name describes the project, never the casino.
The tagline explains both parts of the product.
Unrigged: what really happens when you cash out.
Affiliate revenue share is the model.
Casinos are never charged for responses, corrections, placement or removal of anything measured. This protects trust with sceptical players.
Every commercial link appears in one separate section.
Commercial links never appear on casino pages, records, the feed or the app. The section is reachable from navigation and nowhere else.
The rule controls placement, not affiliate revenue itself.
Affiliate revenue is allowed. Commercial links outside the separate section are not.
The commercial section can be turned off by jurisdiction.
We turn it off where revenue share affiliate pay is restricted.
DECIDED, 1 August: affiliate revenue share is the model.
The alternatives below show why we made the choice. The decision is not open. We reviewed and confirmed it after considering the case for dropping it.
Operators can pay for presentation and a voice, never for data treatment. LOCKED
The old rule was "nothing an operator can buy". That is now narrowed: nothing an operator pays for is readable by any calculation, and nothing a calculation produces is changeable by any payment. This is safe for one structural reason. Everything measured lives on the Casino entity. Everything paid lives on the Operator entity. The scoring, ranking, counter, trend and benchmark code reads only Casino-side data and has no path into the Operator store. Payment cannot move a number because the number's inputs sit where payment cannot reach.
Free for every domain-verified operator (verification is domain control only, per 6.6, and payment never substitutes for it):
Paid, on a published price list identical for every operator, with the paid status disclosed on the profile:
What a paying operator can never do:
Enforced in code, not policy. A build test fails if any scoring or ranking query joins the Operator store. This turns the wall from a promise into a constraint a developer cannot cross by accident.
The commercial page could attract the operators with the worst numbers.
Fast, well-run brands may ignore a small site's listing request. Operators with bad numbers may sign quickly to buy an association with the word unrigged. That contrast alone creates the appearance of corruption.
An operator is eligible only while its measured numbers pass a published bar.
An operator that falls below the bar comes off automatically and visibly. An operator we have never measured is not eligible.
We only take money from casinos that pass our measurement.
When their results fall below the bar, they come off the commercial page. This keeps the commercial page close to the fast-payer list.
Eligibility can read the published numbers, but the numbers cannot read eligibility.
Commercial status never affects any calculation. It remains absent from every scoring and ranking calculation.
Commercial relationships never affect the data.
We measure operators that refuse a deal. We do not favour operators that accept one. Records are calculated in exactly the same way.
Commercial status is not stored in the scoring or ranking data model.
There is no commercial field that anyone can pressure us to soften.
The key test is whether the payer cares what the numbers say.
This matters more than revenue. Revenue can be replaced, but credibility cannot.
Direct payment from an operator is fatal to trust.
Payment from an affiliate is one step removed and can be survived. Payment providers, platforms, regulators and readers do not need any casino to look good. They are the cleanest payers.
The ten options below are kept so the choice is visible and can be revisited if affiliate revenue underperforms. They do not reopen the decision in 11.1. This is a record of the alternatives, not a live debate.
Figures marked panel are informed estimates, not verified market data.
They come from the review panel. One affiliate operator quoted his own business, and one small-brand founder quoted what he would pay. Every figure must be checked before it appears in a deck.
1. Affiliate revenue share uses links on one separate page.
This is the current specification.
Estimated revenue is $0.02 to $0.10 per visitor, compared with $0.65 for a normal affiliate site (panel).
Most visitors arrive during a crisis and cannot convert. Affiliate revenue only pays when someone opens and funds a new account.
The visitors most likely to convert are highly focused on withdrawals.
Operators screen for this group and reduce its value.
The separate page may fill with operators our data rates worst.
Good operators may ignore our emails. That result could create a damaging screenshot and story about us.
2. Affiliate revenue share beside editorial is the industry norm.
It could earn about ten to fifty times as much as option 1. Casino Guru and Trustpilot place commercial links beside critical editorial and remain the most trusted names in their categories.
This option would remove the main thing that separates us from existing sites.
The market accepts this placement, but it costs our strongest point of difference.
A token page that nobody visits gives us the worst parts of both options.
It creates the reputation cost of making money without producing useful revenue. We must choose one end, not the middle.
3. Data licensing gives affiliates a payout number they cannot produce themselves.
Estimated revenue is $3,000 to $8,000 a month, with perhaps thirty potential buyers (panel).
This option can earn money from the first hundred records.
It does not depend on traffic. It also turns a strong competitor into a customer.
Affiliate money remains linked to operators.
Affiliates are paid by operators. Their money is two steps from the measured party, rather than three.
4. Counterparty risk data helps payment providers and acquirers judge gambling merchants.
They have no independent view of payout behaviour. Payout behaviour directly signals when a merchant may be in trouble.
Payment providers and acquirers need the number to be true.
They carry the loss when it is wrong. This makes them the cleanest large buyer available. This option has received the least study.
5. Platform and provider benchmarking measures the systems behind most results.
A few dozen platforms decide most of what we measure.
Estimated revenue is $5,000 to $15,000 a month from each buyer (panel).
The data supports their sales claims and their defence. These buyers also have real purchasing budgets.
Measuring platforms and processors directly is harder to game than measuring brands.
This option fits that measurement model.
6. Operator self-benchmarking sells private tools, not publicity.
An operator buys its own numbers, comparisons with peers and alerts when performance falls.
Estimated revenue is $400 to $800 a month from a small brand (panel).
Most operators cannot see their own payout performance, so they genuinely want this tool.
This option fails the test above.
The payer is also the measured party.
Any operator self-benchmarking product needs strict controls.
It needs a published price list. The purchase must appear on the operator's public page. Commercial status must remain outside the data model.
Those controls do not fix the headline risk.
"Casinos pay us for reports" remains damaging even with added detail.
7. Consumer subscriptions let readers watch a casino.
Readers receive an alert when its numbers move. This follows from the trend being the most valuable output.
Consumer subscriptions offer the smallest revenue and the cleanest position.
The reader is the customer.
8. Regulators and licensing bodies need independent payout data.
Payout data is a stated policy concern for them.
This option has a very slow sales cycle and very high credibility.
One regulator or licensing body as a reference customer would change how others view the site.
9. The founders can fund the site as a public good.
Their other businesses would support it, and the site would earn no revenue.
Public-good funding removes every revenue conflict.
It creates the strongest independence claim in the industry. We must disclose the funding openly.
Combining public-good funding with option 1 creates the worst available outcome.
The site would be funded by gambling money and still carry affiliate links.
10. Acquisition can be the actual business model.
Likely buyers include large affiliate groups and existing complaint sites.
Independent sites in this category often get acquired.
Building for acquisition changes what we should prioritise, so the option must be named.
The measured data is the asset, and the consumer site may be its marketing.
Options 3 through 5 and 8 can earn money from the first hundred records. They do not need the traffic that options 1 and 2 may take eighteen months to build.
Options 1 and 6 take money from a party that cares about the numbers.
This creates the clearest conflict risk.
Affiliate revenue share is the decision for now, but our own numbers show it is weak.
We chose it because it can start without finding a buyer. We did not choose it because it beat the alternatives.
Options 3 to 5 and 8 remain open and are the most likely replacements.
The build gate forces us to review this choice instead of letting it drift.
Pending-withdrawal screenshots can contain sensitive data.
They may show balances, account identifiers and names. We will hold thousands of them.
This document had no retention rule.
That was a gap.
We extract its fields, ask the member to confirm them and publish the record. We then keep the original for a limited dispute window before destroying it.
Data hidden from display is also hidden in storage. We do not keep the unmasked original after its retention window.
The record keeps its evidence tier and is marked as evidence since destroyed. The tier records what we saw at the time.
Deleted images leave backups within the backup rotation window. This makes the deletion claim real.
Published records leave a visible removal marker. The underlying images were never published and follow these separate rules.
The retention windows are set in the contract chapter.
The link layer must be built into link resolution from day one.
Adding it later would require changes to every template. The target market makes this control necessary.
UNSOURCED The facts below come from the 31 July specification and have not been independently checked here.
Counsel must review them before launch. The figures must be checked rather than trusted.
California AB 831 was recorded as in force from 1 January 2026.
It extends criminal liability to entities that knowingly and willfully support or promote an online sweepstakes game in California. It explicitly names media affiliates, payment processors and geolocation providers.
The recorded penalty is a misdemeanour, $25,000 and up to one year.
California was estimated to hold 17 to 20 percent of the US sweepstakes market.
Thirteen states were listed as banning or effectively prohibiting dual-currency sweepstakes.
Oklahoma was listed as following on 1 November 2026.
Chapter 13 names US sweepstakes as the wedge market.
Chapter 11 previously answered the legal issue only by calling the commercial section geo-switchable. A criminal law needs a full link control, not only a revenue setting.
| State | What renders | When |
|---|---|---|
| Monetised | Tracked affiliate link, with the relationship disclosed above the fold | Legal there, deal in place, disclosure compliant |
| Plain | Untracked direct link, disclosed as having no commercial relationship | Legal, but no deal exists or the compensation model is not allowed there |
| Record only | No outbound link. Everything else renders unchanged. | Promotion is restricted or prohibited in that jurisdiction |
Coverage never changes, only the link changes.
Records, medians, written accounts and terms history stay identical in all three states. A reader in California sees the same record as everyone else.
The measurement part of the product does not depend on outbound links.
Removing a link keeps the publisher's record while stopping the promotional action.
Every link decision is stored in an immutable log.
The log includes the inputs that produced the decision. It provides evidence against a "knowingly and willfully" allegation.
The immutable log must exist from day one.
It is cheap to create at launch and impossible to rebuild accurately later.
A stale jurisdiction table is worse than no table.
It can turn "we did not know" into "we knew and carried on."
Every jurisdiction row needs an effective date, source and review date.
A named person must maintain the table. It cannot be a one-time task.
Open: counsel must decide whether an unmonetised sweepstakes link counts as promotion.
A record without a link is consumer information. A visit button without an affiliate tag may still count as promotion.
California sweepstakes uses the Record only state until counsel answers.
This is the default.
The schema stores funding event and payout request.
Sweepstakes operators change their legal structures across states. Terms tied to one legal wrapper would require a data migration.
The interface may still display casino and withdrawal.
The stored terms remain neutral while the sweepstakes wrapper changes.
Every removal stays visible with its reason and date.
A removed record leaves a visible hole in its original place.
Visible removals make deletion claims easy to check.
Anyone can see whether we removed a record. This matters more because the site now has a commercial page.
The removal log is append-only and public.
Records may be removed because of fraud, a legal demand or the member's request. Each reason renders differently and is stated clearly.
The founders have interests in other gambling businesses.
A hidden link to casino operators would cause severe damage. We disclose those interests openly.
The disclosure appears on the site.
They receive no special handling.
This exclusion is permanent.
The businesses remain separate.
Disclosed history can build trust in this industry.
Discovered history destroys it. Disclosure must be live from launch.
Two developers build the product.
Anything that needs daily staff work for each record is out of scope. This includes mediation, arbitration, inbox sorting and manual verification queues.
The existing Cyprus entity operates the product at first.
The domain and brand assets stay there for now. Brand IP protection is planned but delayed, and it does not block launch.
Members give consent at signup.
The signup screen explains what we publish, what we keep and what appears under a name or anonymously. This is a product screen, not just a legal exercise.
SEO shapes the product from the start.
The tester records arrive before launch, so Google never indexes an empty site. Casino page titles include the casino name because the new brand has no search value yet.
Unverified records are buried, not hidden.
Hiding them would remove them from the search index.
The architecture includes an entity model, roles, permissions, an audit log, a ledger, an API and access controls.
It also supports evidence images, a clock and a sample that is kept out of public results.
An entity gets its own store when it supports a useful question without joining another entity.
Members, Casinos, Operators, Records and Ledger have their own stores.
Evidence, linked accounts, endings, flags, disputes and appends are child entities.
They do not pass the entity test.
Casinos and Operators have separate stores.
A dated claim connects them. The measurement belongs to the casino brand and must never touch a commercial account.
Most brands are unclaimed. The same operator may also relaunch brands many times.
The casino passport depends on the operator graph.
See chapter 6.
Permissions are separate units that can be granted.
The permissions are record.review, flag.adjudicate, link.verify, evidence.unmask, anomaly.review, control.assign, terms.confirm, commercial.manage, config.thresholds and staff.manage.
Roles are bundles of permissions.
One person holds all eleven permissions at launch (the ten named plus payout.approve).
New staff can receive specific permissions without changing the system.
A person managing an operator relationship cannot review that operator's records or flags.
That person cannot hold record.review or flag.adjudicate for the operator. This puts the firewall from chapter 11 into code.
control.assign is granted to a different person as soon as a second person exists. At launch one person holds everything, so the separation is a rule waiting for the second hire rather than an enforced wall. Until then the audit log is what keeps that person honest, which is why it exists from day one.
The person choosing records for the withheld sample cannot see the published set. Otherwise, the control group stops being a control.
Every state change creates an immutable audit entry.
Each entry stores {actor, permission_used, entity_type, entity_id, from_state, to_state, reason, timestamp}.
The audit log is the main integrity control at launch.
One person performs every duty, so duties cannot yet be split between staff. The log is cheap to add now and impossible to rebuild later.
Every control sample assignment enters the audit log.
Nobody can quietly remove a record from the withheld set.
Every threshold change enters the audit log.
A changed median can always be traced to a decision, a person and a date.
The system has one canonical store.
A moderation inbox is a saved query with a permission and a target time. It is not a second table that can drift from the record.
Every path uses the same transition guards.
An action from a queue card must behave like the same action on the record page.
Anomaly review is a staff queue.
It covers the outlier clustering from chapter 9. It is the only defence against attacks that automated checks do not detect.
Flagged content is a staff queue.
Account links with name mismatches are a staff queue.
Disputed records are a staff queue.
Terms changes that need confirmation are a staff queue.
These queues become active when a person is available to work them.
Publishing, removing, disputing and correcting a record update every related result.
Counters, medians, tiers and the not-paid line all recompute.
Either every related change succeeds or none of them succeed.
Removing a record directly must have the same effects as removing it after an upheld flag. Different results would create bugs and raise questions about fairness.
Evidence access depends on the viewer.
This matters because the product stores bank screenshots.
Every image starts in the masked state.
Masked data is changed in storage, not only hidden when the image is shown.
Only evidence.unmask can access an unmasked original.
Every access enters the audit log. The original is destroyed on the schedule in chapter 11.
Operators can never access an image.
This applies at every tier and under every commercial arrangement.
The system stores timestamps, not elapsed durations.
It stores the request timestamp, arrival timestamp, state and applied benchmark.
Every elapsed time is calculated when it is read.
A stored duration could make a benchmark change silently rewrite history. The product must be able to recalculate and defend every time a year later.
Members use email or social sign-in.
Staff with operational permissions use a separate sign-in route.
They must use a hardware-backed second factor. Staff and members have different screens, sessions and access paths.
Operators have no accounts.
There is nothing for an operator to sign into.
Casino pages, records, medians and counts come from a public read API.
The API supports server-side filtering, sorting, cursor pagination and true totals. It calculates aggregates across the full result set, not only the current page.
The API is built as a product surface from the start.
Chapter 11 lists data licensing as a revenue option. The API is the product that would be licensed.
Every API response includes its slice, count and calculation date.
A number can never appear without its denominator. This enforces the rule from chapter 3 at the API boundary.
The plan keeps three useful parts from the earlier strategy: gates, missing numbers and the main risk.
A 36-month milestone table and four governance committees are too much for a company this size.
Every gate has a response written before the result arrives.
This prevents investment in an expected answer from changing the response.
| Gate | The test | If it fails |
|---|---|---|
| Funnel | Measure how many people file a record and return to confirm arrival after landing on a casino page during a crisis. | Under roughly 40 percent confirmation, the median product cannot exist. Rebuild the product around anomaly detection and one-tap reports instead of evidenced records. |
| Winnings supply | Check whether any operator produces organic winnings withdrawals within ninety days. | Limit every published claim to deposit returns and say so on the page. Do not publish a ranking. |
| Buyer | Get one signed pilot or letter of intent for the data before launch. | The consumer site has no business behind it. Stop and decide whether it will be a public good or nothing. |
| Legal | Get counsel's approval for publishing the account-closed counter and refusal rate for named operators. | Publish timing figures only. Hold back the accusatory counters. |
| Standing | Check whether the level ladder recruits blindsided first-time players or only professionals. | Reweight the sample or state that it is professional-weighted on the methodology page. |
The document has no budget, runway or launch date.
It includes individual figures, such as $8 per test, roughly $32,000 for the tester records and revenue-per-visitor ranges. It does not show the total cost or shipping date.
One page must show the main business numbers before anyone makes a decision.
It must include the cost of reaching the first hundred organic records, cost per verified contributor, monthly burn and launch date. It must also state what revenue is expected and by when.
The tester records have an incomplete cost estimate.
Roughly $32,000 covers time payments. It does not include the real deposits required at forty operators or the house edge lost on those deposits.
The tester records do not affect the ranking.
See chapter 7.
The tester records must be fully funded or reduced to twenty casinos.
Full funding must allow winnings sessions to happen. The other option is to halve the set, test twenty casinos in depth and spend the difference elsewhere.
Defamation and regulatory exposure can end the product.
The plan currently gives this risk no protection and no budget.
The product publishes serious claims about named licensed companies.
These include counts of refusals, account closures and non-payment. They come from self-reported screenshots that may be fake.
The product currently offers no adjudication.
An operator can flag a record, but the flag does not move it. The companies involved have legal budgets and a history of using them.
Claims need evidence thresholds before publication.
Operators need a standing right of reply.
The product needs a published methodology.
The product needs a public correction log.
The company needs named counsel and insurance.
The company must decide where it will show accusatory counters.
Different places create different legal risks.
The cross-operator link graph can never be sold.
See chapter 15. This is the right rule, but the company must understand its cost.
The cross-operator link graph may be the company's most valuable asset.
A buyer may price it even though the company promised not to sell it. The community contributes data based on that promise.
The product does not adjudicate.
This is one of the four rules that separates it from a normal review site.
Operators cannot buy anything.
Commercial pressure cannot change the product's records or results.
Records publish immediately.
Publication does not wait for operator approval.
Removing a record leaves a visible hole.
The public record must show that something was removed.
Revenue pressure will test all four rules in the first thin month.
These rules are why the product can be worth more in three years than a conventional review site. If one goes, the asset loses what makes it different.
These industry facts set the limits of this product.
They were expensive to learn and are easy to forget.
The cashout is the last end-to-end test of the casino experience.
Most players never reach it. This makes the data rare and valuable.
A casino's back office does not show everything we measure.
It usually does not show the request time, arrival time, and destination crypto address together. Fiat records are worse. Players struggle to rebuild their history, and operators struggle to challenge our timestamps.
Casino emails vary too much to trust.
Many casinos send no withdrawal email. Many leave out the amount for security. White-label brands often send nothing.
Nothing in this system may depend on parsing casino emails.
CRM teams change email templates without warning. We learn what each casino sends from the emails that arrive. We never hard-code this map or use it to block registration.
"Your withdrawal has been processed" does not mean the money arrived.
It marks an event inside the casino. Money can bounce, be recalled after a name mismatch, or be sent again days later by another route.
Pending does not mean processing.
It often means the casino has not started.
Most casinos use shared payment processors.
CoinsPaid alone serves hundreds of operators. A payout wallet cannot be linked to one casino.
We do not watch operator wallets.
The money often moves through shared processors. Anyone asking "why don't you just watch the chain" has the wrong picture of how it moves.
Card refunds can stay at the acquiring bank for days.
This can happen after the casino releases the money. A slow card payout does not always mean a slow casino.
Every record captures and shows the payment rail.
The rail helps explain where a delay happened.
VIP and standard payouts must be measured separately.
VIP accounts get much faster payouts through a dedicated host. A figure that combines VIP and standard accounts is misleading.
Crypto payouts are often grouped to save network fees.
An "instant" payout can wait for hours before it is broadcast.
UNSOURCED US sweepstakes casinos appear to have the highest concentration of unpaid-withdrawal complaints today.
This must be supported with evidence before we say it publicly. These casinos use almost only cards and bank transfers.
Fiat coverage is required.
The concentration of complaints at US sweepstakes casinos is the clearest reason.
The audience is older and less technical than the crypto casino audience.
The interface must not use a dark-mode-and-monospace style. It must not use terms like "ledger" or "on-chain." It must not look like a crypto product to someone who calls buying coins "buying credits."
Every number here is a launch default, not a guess to be argued about later. LOCKED
Each is tunable once real data exists. Until then these are the values a developer builds. Where this chapter and the prose disagree, this chapter wins.
A slice is one casino, one payment method, one net-position bucket, one amount band, and one VIP flag. LOCKED
Every threshold below is measured per slice. A median, a count, the per-member cap, the precision rule and the trend all apply to a slice, not to a casino as a whole.
Slices open in order as volume allows. The first split is net position (winnings versus own money). Method is always separate and never blended. Amount band and VIP open when a slice has enough records to fill them. A figure is only shown once its own slice clears the gate, never borrowed from a neighbour.
The benchmark for Overdue is the exception: it is computed per casino and method only, not down to net position or VIP, so a live record can be judged before its finest slice has filled.
| Parameter | Launch default | Notes |
|---|---|---|
| Records before a slice shows a median | 8 | Below this the page lists records and computes nothing |
| Distinct members required for that slice | 5 | One member's records are capped at 2 in any one slice |
| Distinct members before a headline counter shows | 5 | Applies to unpaid, refused, account closed, cancelled |
| Rolling window on every published figure | 180 days | All-time is one tap away and labelled |
| Records a member may file at one casino per week | 5 | Anti-flood, not anti-contribution |
Under $250, $250 to $1k, $1k to $2.5k, $2.5k to $5k, $5k to $10k, $10k to $25k, $25k and over.
Bands are shown, not exact amounts, on every public surface. A member may opt to show the exact figure on their own records.
| Event | Launch default |
|---|---|
| First "has it arrived" prompt | Day 2 after request |
| Then | Days 4, 7, 14, then weekly |
| Silence to Unconfirmed | 21 days after the last contact, if the record never went overdue and the player never said it was outstanding |
| Silence to Abandoned unpaid | 21 days after the last contact, if it did go overdue or they did say it was outstanding |
| Draft expiry | 14 days, then deleted with one warning |
| Dispute response target | 72 hours |
"Last contact" means the last time the player replied to us, not the last reminder we sent. Otherwise weekly reminders would reset the clock forever and the timer would never fire.
| Rule | Launch default |
|---|---|
| A live record goes Overdue at | 1.5x the benchmark for that casino and method |
| The benchmark is | The lowest of: this casino's median for that method, the site-wide median for that method, the casino's published window |
| If none of the three exists | The record stays Waiting and shows elapsed time only, never Overdue |
| Rule | Launch default |
|---|---|
| Share of each tester batch withheld | 20 percent |
| Selection | Random within the batch, assigned at logging, before the outcome is known |
| Who can see the held set | Only the holder of control.assign |
| When it publishes | Once the record resolves, marked as a released control record |
| Rule | Launch default |
|---|---|
| Trend window | The last 10 records, compared against the 10 before them |
| Minimum to show a trend | 20 records total in the slice |
| Suppressed when | Fewer than 3 distinct members are behind the movement |
| Relation to the 180-day window | The trend is the one figure exempt from it, because its whole job is to show recent change |
The launch method list, and everything is compared only within one of these: bank transfer, card, ACH, wire, PayPal, Skrill, other e-wallet, USDT, USDC, BTC, ETH, other crypto. A record's method is read from the screenshot and confirmed. Crypto records also carry the chain.
Amounts are stored in their original currency and converted to USD for banding, at the rate on the request date. The original figure is always kept. Bands in 14.2 are USD.
| Rule | Launch default |
|---|---|
| Maximum file size | 12 MB |
| Accepted formats | JPEG, PNG, HEIC, PDF |
| Malware scan | On upload, before storage, blocking |
| EXIF | Stripped on ingest, including location |
| OCR confidence to auto-fill a field | 0.85, below that the player types it |
| Redaction failure | The record files as typed-only, the image is not stored |
| Unmasked original retained | 90 days from record close, then destroyed |
| Masked version retained | While the record is published |
Two records are the same record when they share casino, member, an amount within 1 percent, and a request date within one day. The second is merged, not published.
Open disputes per casino at one time: 5. Re-disputing the same record: 2 attempts, ever. An operator whose disputes lead to a correction under 30 percent of the time, after at least 5 disputes, is throttled. Correction means a factual error was fixed, never a ruling on who was right.
These are decisions, not defaults, and each has a consequence.
Four external claims are load-bearing and unverified, and each is marked UNSOURCED where it appears: the Trustpilot fake-review figures, the claim that US sweepstakes carry the densest concentration of unpaid-withdrawal complaints, the legal table in chapter 11, and the assertion that app stores reject apps of this kind. The last one decides whether the app is the primary surface or the fallback.
We never build complaint mediation.
We do not step into complaints between players and casinos.
We never build case management.
We do not manage complaint cases.
We never decide who was right.
We do not judge disputes.
We never build a combined trust score or weighted formula.
We do not reduce trust to one score.
A reply never becomes a record state. An operator reply is an annotation with its own moderation state, see 11.1b, exactly like the player's written account. It never changes the record's own state, never moves a median, never a counter. That is what no operator response states means: the reply is visible, but the measurement does not know it exists.
We never use standing mail-forward rules or inbox access.
We never build a browser extension.
We never create fake reviews.
We never place commercial links on a casino page, a record or the feed.
The cross-operator link graph is never sold, shared, licensed or included in any partnership.
This protection must be part of the system, not just a promise.
The cross-operator link graph is unique and highly valuable.
It links one verified identity to accounts at many operators. It includes deposits, withdrawals, net position and refusals across all of them.
No operator, processor or regulator has this full file. It could be worth more to casino risk teams or shared blacklist providers than every other asset here combined. Members would have built it for us by choice.
The system must block future attempts to sell the graph.
Such an attempt may be called a fraud-prevention partnership. It may appear in year three, when revenue is below plan, with careful wording and a price.
The graph must remain protected if the entity is sold, subpoenaed or breached.
Intent and policy are not enough.
The data must not allow a per-person cross-operator view to be rebuilt or exported.
The link set must be stored in a form that prevents this.
The identity token must be separate from the account links.
Keeping only a token and never the identity documents does not protect the graph. It protects the passport data but leaves the account links exposed.
Selling the graph would permanently destroy the community.
The members who produced the data would leave and not return.
Community comments and up and down voting are a phase one feature (moved in from phase two, 2026-08-02).
They are the discussion layer that makes this a place players come back to, so the homepage and each casino page lead with them. They are kept strictly separate from the measured record: discussion is opinion and can be voted on, but every payout time is computed from verified withdrawal records only, and no comment or vote ever moves a number. Posting requires a verified-player account (one confirmed withdrawal with a screenshot), which is what keeps sock-puppet accounts from gaming the discussion the way a raw search or click count could.
A formal complaints process is still deferred to phase two, not banned. It comes later. The system must leave room for it instead of making it impossible.
Kept because the reasoning is expensive and somebody will otherwise re-propose the thing that was already tried. These are corrections to earlier versions of this document, not open questions.