Prize draws
How to verify a raffle
Every Padelbit prize draw is a number generated and cryptographically signed by random.org, drawn against a ticket list that was published before the number existed.
You can independently check the signed number, range and ticket list fingerprint. Match results, eligibility and some safeguards still depend on Padelbit and the people at the event. Here is what each check can — and cannot — establish.
How tickets are earned
Everyone who played that evening gets one ticket, plus one more for each match they won. Win more, more chances — but a player with no wins is never left out.
Two groups hold no tickets: staff running the event, and anyone who has already won a raffle in the last 28 days. Both are listed on screen with the reason, so an exclusion cannot be quietly applied to someone inconvenient.
The full ticket list — every range and who holds it — is public on the game page before the draw, and downloadable afterwards.
What could go wrong, and what stops it
1. "They kept re-rolling until a friend won"
Witness the ticket beforehand; independently verify the same ticket afterward.
Before the evening's first draw — usually hours before, when the games start — we ask random.org to issue a one-use ticket. Its id goes on the game page and the venue screen immediately, long before anyone could know who would win.
If you saw the random.org ticket before the draw and later independently verify that the same ticket was used, the organiser cannot secretly reroll or alter that draw without leaving evidence. Each ticket can be used at most once, and random.org signs the result. Generating several results and choosing a favourite would require other tickets or requests; substituting one would fail the comparison with the announced ticket. Its public page shows when it was used and what it drew, while successor links let you inspect the chain for draws missing from our history.
If random.org cannot issue a ticket, a signed draw can still run, but its history has no ticket link. Such a draw cannot be checked through the ticket chain. The signed serial number is an additional clue about requests under the same API key, not proof that no requests happened elsewhere.
2. "They made the number up"
Checkable on random.org's own site.
Every draw comes back with random.org's cryptographic signature over a record containing the number, the range, the exact time, and our own description of what it was for. The verification page is random.org's, not ours — we only hand you the link, pre-filled.
If we had altered so much as one digit, their checker would reject it.
3. "They chose a range that only their friend could win"
Compare the signed range with the full ticket list.
This is the subtle one, and it is the reason this page exists. A signed number proves the draw was fair for the range that was asked for — it says nothing about whether the range was honest. Asking for "a random number between 31 and 35" when your friend holds tickets 31–35 verifies perfectly and is completely rigged.
Our server is programmed to require the entire ticket pool, from 1 to the last ticket, and reject other ranges. That is a server safeguard, not something the signature independently proves. What you can check yourself is that the signed min is 1 and max matches the last ticket in the full list.
4. "They quietly switched the proofs off"
Then there is no draw at all.
Signing used to be optional: without the key, a draw still ran, just unverifiable. Now a draw with no signature is refused. There is no configuration in which a Padelbit raffle produces a winner you cannot check.
5. "They edited the scores so someone got more tickets"
The list is committed; its prior public display needs a witness.
Tickets come from match results, so changing a score changes the pool. Before each draw, the venue screen shows the SHA-256 fingerprint of the exact ticket list alongside the sealed ticket — while the number still does not exist. That same fingerprint is then sealed inside random.org's signature.
Take a photo or video of the fingerprint before the draw. An independent recording whose timing can be established lets you compare what was shown beforehand with the signed fingerprint and the downloaded list. The random.org signature proves that the fingerprint was included in the draw request; it does not prove that spectators saw it before the number was generated. Without independent evidence of that earlier display, it cannot be established afterwards from the signature alone.
After the draw, the scores are locked: the server refuses any score or round change on a night with a signed draw. And it checks its own work — every time the game page loads, it re-hashes the list from the scores as they stand and compares it with what random.org signed; a mismatch is shown in the draw history as a warning, not left for you to find.
Scores are also entered live, in public, by the players themselves during the evening.
6. "The winner wasn't there, so they just drew again"
Allowed — and always on the record.
If a winner has gone home, staff can redraw the same prize. That is a real need, not a loophole, but it is never invisible: the voided draw stays in the public history on the game page marked "not present — redrawn", the end-of-night recap counts how many draws were redrawn, and each redraw consumes another ticket in random.org's public chain.
A night with more draws than prizes is visible to everyone. The record makes the redraw checkable; it does not prove that the first winner was actually absent. Participants still need to check that real-world claim.
Verify a draw yourself — four steps
Before the draw, note or photograph the announced ticket ID and fingerprint, and record when you saw them. Afterward, open the tournament page and its raffle history. Verify on your own device, checking that the ticket and signature pages are on https://api.random.org. An organiser’s screen or a lookalike page is not independent verification.
- Compare the ticket IDs. Open the ticket on random.org and check that its ID matches the one you saw before the draw. Check its creation and use times and the result. Creation time alone does not prove that the ID was announced beforehand.
- Check the signature. Click the verify link (or scan the QR on the venue screen). random.org's signature checker opens pre-filled. A green result means they generated exactly this number, at this time, for this range.
- Read what it was drawn for. In the verified record,
userDatanames the tournament, the prize number, which draw of the evening it was, and the ticket list fingerprint. A number cannot be quietly reused from another night. - Recompute the ticket list fingerprint. Download the exact list that was hashed and hash it yourself:
The result must equalcurl -s https://padelbit.eu/api/games/<gameId>/raffle/tickets.txt?draw=1 | sha256sumuserData.ticketsin the signed record. Also compare it with an independently captured photo or video from before the draw. Matching the signed hash verifies the list; establishing that it was publicly shown beforehand requires that separate evidence.
What is inside the signed record
| Field | What it tells you |
|---|---|
data | The winning number itself. |
min, max | The signed range. Check that min is 1 and max equals the last ticket in the full list. |
completionTime | random.org's timestamp, not ours. |
serialNumber | The request counter for the API key. Gaps can prompt questions; they do not establish the purpose of other requests. |
ticketData | The one-use ticket, its predecessor and its successor — the evening's chain. |
userData.tournament | Which event this number was drawn for. |
userData.prize, .draw | Which prize, and which draw of the night. |
userData.tickets | SHA-256 of the ticket list — step 4 above. |
What this does not prove
A fairness page that claims too much is worth nothing, so here are the honest limits.
It does not prove the match results or eligibility decisions were correct. Scores, staff exclusions, the 28-day winner exclusion and whether a winner was present depend on Padelbit records and people at the event. Committing the ticket list does not independently validate those inputs.
It does not prove that all Padelbit records are unalterable or that server rules cannot be bypassed. Altered signed records stop verifying, and a changed list will not match its signed hash. Those checks do not authenticate every other record we hold. The ticket chain covers its own linked requests, not all possible activity outside it.
The ticket list is committed before random.org generates the winning number. The signature binds the hash to the number and range; independent evidence is needed to confirm that the hash was publicly shown beforehand.