How rounds, fairness and prizes work

How to play

• Enter the round — you get a lane and a colour.
• When the lights go, your racer runs on its own. Watch the lead change hands.
• Cheer your racer on (it's just for show — cheers never change the race).
• First across the line wins. The replay re-runs the exact race in your browser.

Rules

• Every entrant gets one racer; lanes and colours follow entry slots.
• Racer stats (top speed, acceleration, pace style, finishing kick) and race events (surges, stumbles) are drawn from the round seed.
• Racing within about 4 m behind another racer gives a slipstream boost; racers far off the lead get a small second wind.
• Difficulty sets event intensity: Easy is calm and decided by stats, Hard is chaotic.
• First across the line wins; finish times are measured to 0.01 ms. Exact ties share a place.
• At the time limit, unfinished racers are ranked by distance covered.
• Knockout scoring: at four gates the last racer(s) still running are eliminated; eliminated racers rank below everyone still running, latest out first.

Fairness

The race is a pure function of the round seed and the entrants' slot order — no player input can change it. The seed's hash is published when the round locks and mixed with a public block hash, so nobody (not PlayPad, not the project) can know or pick the result in advance. After the race the seed is revealed and your browser re-runs the identical simulation from {seed, players, config}; it must produce the same finish order and times to the hundredth of a millisecond.

• Commit–reveal seed
• Public block seed
• Re-simulate it yourself
• Hash-chained log

Verify a round yourself

1. Before the start, note the seed commitment shown on the fair-play page.
2. After the race, check that sha256(revealed server seed) equals that commitment, and that the final seed = sha256(server seed ‖ entrants hash ‖ lock block hash).
3. Open the replay: it re-simulates the race in your browser from the revealed seed, the entrant slots and the round config (format race/resim@1) and shows “Re-simulated — matches the server result” only when every finish time is identical.
4. Compare the event-log hash and result hash on the fair-play page with the signed result.

Anti-cheat

• Clients never send positions, speeds or finish times — racers have no gameplay input at all, so there is no client state to tamper with.
• Runner stats and race events come only from the seed (sfc32 seeded from sha256), never from Math.random or wall-clock time.
• Fixed 50 ms simulation steps regardless of server load: late ticks are caught up, never skipped or stretched.
• Cheers are cosmetic: validated, rate-limited (one per 0.4 s per account, 25/s per round) and never reach the simulation.
• Inputs from wallets that are not entrants are ignored.

How to play

• Watch the stage. It stays dark while you WAIT.
• The moment it flashes GO, press — space bar, click or tap.
• Pressing before GO, or impossibly fast, is a false start.
• One press per heat. Lowest time across the heats wins.

Rules

• A round is 3–10 heats (5 by default).
• Each heat: get ready, WAIT through a secret 1.5–5 s delay, then GO.
• Reaction = server receive time − GO send time − min(RTT ÷ 2, 30 ms).
• Pressing before GO, or under 100 ms after it, is a false start.
• The response window is 2.0 s (easy), 1.5 s (normal) or 1.0 s (hard); no press counts as the full window.
• Total time: lowest sum of all heats wins; a false start counts as the window + 1,000 ms.
• Best 3: lowest sum of your three best heats wins; a false start disqualifies that heat.
• Ties break on more clean heats, then the single fastest heat, then fewer false starts.

Fairness

Every GO delay (1.5–5 s) is drawn from the round seed, which is committed before the round locks and revealed only after the result — so nobody, players or creator, can know when GO will fire. Your reaction is measured on the server's clock: from the moment GO is sent to the moment your press arrives, minus half your measured round-trip time (your lowest of the session, never more than 30 ms). Your device's clock is never used, and every press is written to a hash-chained event log.

• Server-clock timing
• Commit–reveal seed
• Public block seed
• Hash-chained log

Verify a round yourself

1. On the Fair Play page, check that sha256(revealed server seed) equals the seed commitment published at lock.
2. Recreate the GO delays: createRng(seed).fork('reaction/delays').int(1500, 5000), once per heat — they must match the delays in the result summary.
3. For every press in the event log: reaction = receivedAt − goSentAt − min(rtt ÷ 2, 30 ms). Anything under 100 ms is a false start.
4. Re-add the heat values with the round's scoring preset (window for no press, window + 1,000 ms for a false start) and compare the standings and event-log hash.

Anti-cheat

• Client timestamps are ignored — only the server's receive time counts.
• The GO moment is never sent early: no timer, countdown or hint appears in any message or snapshot during WAIT.
• A press before GO, or under the 100 ms human limit, is a false start.
• One press per heat. Spamming during WAIT is a false start; extra presses are dropped.
• Latency compensation uses your lowest measured round-trip of the session and is capped at 30 ms, so faking lag can't buy a faster time.
• Inputs are rate-limited (20/s) and presses tagged for another heat are ignored.

How to play

• A question and its answers appear for everyone at once.
• Tap an answer to lock it in — one shot, no changes.
• Speed: faster correct answers score more. Elimination: one miss and you're out.
• When time's up, the correct answer and the room's picks are revealed.

Rules

• Every player gets the same questions in the same order (5–20 per round, 10 by default).
• The answer window is 15 s (easy), 12 s (normal) or 8 s (hard).
• Tap to lock in one answer per question — it can't be changed.
• Answer time = server receive time − reveal time − min(RTT ÷ 2, 30 ms); late answers don't count.
• Speed points: correct = 1,000 × (1 − ½ × time ÷ window); wrong or none = 0. Ties break on more correct answers, then lower total answer time.
• Elimination: a wrong or missing answer knocks you out, unless every remaining player missed. Last standing wins; ties break on most correct, then fastest.
• Questions come from PlayPad's original packs (General Knowledge, Science & Space, Sports, Internet & Gaming) and/or the project's own screened questions.

Fairness

Which questions are asked, their order and where the right answer sits are all derived from the round seed, committed before the round locks. When the match starts, PlayPad publishes a salted hash of the exact question set. Each question reaches everyone at the same moment, and the correct answer is only sent after the answer window closes — it is never in any message or snapshot before that. Answer times are measured on the server clock with latency compensation (your lowest round-trip of the session) capped at 30 ms.

• Commit–reveal seed
• Public block seed
• Hash-chained log
• Server-clock timing

Verify a round yourself

1. On the Fair Play page, check that sha256(revealed server seed) equals the seed commitment from lock.
2. From the result, hash every asked question as sha256(salt + ':' + index + ':' + canonicalJSON({id, category, text, choices, correct})) and compare it with its revealed leaf.
3. Check sha256(leaves joined with ':') equals the question-set hash shown when the match started (the result page does this in your browser).
4. Re-run the selection from the seed — createRng(seed).fork('trivia/select') and fork('trivia/choices/<i>') — to confirm the questions and answer positions weren't hand-picked.
5. Recompute points from the event log: answer time = received − revealed − min(RTT ÷ 2, 30 ms); answers after the window are rejected.

Anti-cheat

• The correct answer is never sent before the answer window closes — not in questions, lock-in updates, acknowledgements or snapshots.
• Questions are revealed to everyone at the same moment; future questions never leave the server early.
• Spectators only see how the room answered after the window closes, so a second device can't crowd-source the answer.
• One locked answer per question; answers that arrive after the window are rejected.
• Client clocks are ignored; latency compensation uses your lowest round-trip of the session and is capped at 30 ms.
• Creator questions are validated (2–4 choices, length limits) and screened by PlayPad moderation before a round can use them.
• Inputs are rate-limited (10/s per player).

How to play

• The prompt appears for everyone at once — you have one timer to draw it.
• Pick a colour and brush, draw with mouse, pen or finger. Undo and clear are there if you need them.
• When time is up, vote for your favourite drawing. You can't vote for your own.
• Most votes wins. Names are revealed with the final tally.

Rules

• All players receive the same prompt at the same moment.
• Drawing time and voting time are fixed per round; the server clock decides when each closes.
• Only freehand vector strokes are accepted: 12 palette colours, 3 brush sizes, undo and clear.
• Drawings are shown anonymously in a seeded shuffled order while voting.
• One vote per signed-in profile. You can't vote for your own drawing. Votes are final.
• Most votes (or points, in Hybrid) wins. Ties go to the drawing that appears first in the seeded gallery order.
• In prize rounds only the players' votes decide the places; spectator votes pick the crowd favourite.
• A blank canvas can't receive votes and ranks below every submitted drawing.

Fairness

The prompt and the anonymous gallery order are drawn from the round seed, which is committed before the round starts and revealed with the result. Drawings are accepted only as vector strokes the server validates point by point; each finished canvas is hashed into the event log. Votes are one per signed-in profile, self-votes are refused, and every vote is published as a salted hash with its target so anyone can recount the tally.

• Commit–reveal seed
• Hash-chained log
• Transparent votes

Verify a round yourself

1. Check that sha256(revealed seed) equals the seed commit published before the round went live.
2. Re-run the seeded prompt pick and gallery shuffle (createRng(seed).fork("prompt") / fork("order")) to confirm the prompt and anonymous order.
3. Re-hash each canvas in the replay (canvasDigestInput) and compare it with the canvas digest recorded in the event log.
4. Count the published vote hashes per drawing — the totals must match the tally exactly.
5. If you voted, find your receipt: sha256(roundId|yourProfileId|drawing|salt) must appear in the list with your drawing.

Anti-cheat

• No image upload or paste path exists — only vector strokes with palette colours and three fixed brush sizes.
• Every stroke message is validated: ≤ 200 points, coordinates inside the canvas, monotonic timing no faster than a real pointer.
• Server-measured rate limits on messages and points (at most 140 points a second — a fast hand), plus caps of 6,000 points and 400 strokes per canvas.
• A stroke's own timing must match when the server received it, so device timestamps can't make a pasted image look hand-drawn.
• Strokes are only accepted while the drawing timer is open on the server clock — late strokes are refused.
• Gallery is anonymous: live canvases and the vote gallery never carry names until the tally.
• One vote per signed-in profile, final once cast; players can't vote for their own drawing; blank canvases can't be voted for.
• Prize rounds: spectator votes (any signed-in wallet) carry weight 0 in the tally — only the players' votes decide who wins the prize; spectators pick the crowd favourite.
• Ties are broken by the seeded gallery order, never by the server operator.

How to play

• Move with WASD / arrow keys, or the on-screen joystick on touch. Space or the DASH button bursts forward (3 s cooldown).
• If you hold the bag, touch someone to pass it before the fuse runs out.
• Just passed it? They can't tag you back for 0.8 s — use it to get away.
• Fuse hits zero → the holder is eliminated and a new bag drops. Last one standing wins.

Rules

• One player starts with the bag (chosen from the seed). Its fuse starts burning after a 2 s scatter.
• Touching another player passes the bag. The previous holder can't receive it back for 0.8 s.
• A fresh holder must keep the bag for 0.3 s before passing it on.
• When a fuse reaches zero the holder is eliminated. A new bag drops on a seeded random survivor after a 1.5 s reveal.
• Fuses are as long as the creator's maximum (default 15 s) but shorten so the round fits its scheduled duration (never under 4 s).
• The arena shrinks gently over time and as players are eliminated.
• Last one standing wins; everyone else places in reverse order of elimination (same-tick eliminations share a place).
• Idle or disconnected players are steered by a seeded autopilot until they come back.

Fairness

The server runs the only physics: clients send a direction and a dash request, never positions. Spawn points, the first bag holder, every new bag holder and the autopilot for idle players all come from the round seed, which is committed before the round and revealed with the result. Every input the simulation used is logged at the exact tick it was applied, so anyone can re-run the open-source simulation and get the same eliminations.

• Commit–reveal seed
• Hash-chained log
• Re-simulate it yourself

Verify a round yourself

1. Check that sha256(revealed seed) equals the seed commit published before the round went live.
2. Download the event log: "in" (direction), "dash" and "auto" (autopilot on/off) events carry the tick they were applied at.
3. Re-run resimulateTag(seed, players, config, events) from the Tag template — the elimination order and winner must match the published standings.
4. Compare the replay tape (10 Hz positions) with your own re-simulation for any moment you care about.

Anti-cheat

• Clients never send positions or speed — the server integrates movement, so speed or teleport hacks can't exist.
• Inputs must be a normalized direction (|x|, |y| ≤ 1, length ≤ 1); anything else is ignored.
• At most 30 input messages per second per player; dash has a 3 s server-side cooldown.
• Tags are detected by the server from its own positions; clients can't claim a tag.
• Fuse timers run on the server clock only.
• Idle (5 s without input) or disconnected players are driven by a seeded autopilot instead of standing still — logged, so it's reproducible.

How to play

• Tap (space, click or touch) when the sliding ledge above you lines up with your climber.
• Perfect timing = quick jump. Slightly off = edge grab (slower). Miss = you fall back a few ledges.
• Checkpoints every 5 ledges catch your falls. Don't mash — fast repeat taps are ignored.
• First to the summit wins; at the horn the highest climber wins.

Rules

• All climbers face the same seeded tower; every ledge slides at its own seeded speed.
• Tap to jump for the ledge above you. Within ±perfect window of the line-up: perfect hop. Within the good window: normal jump. Slightly outside: you grab the edge and pull up (slower). Further off: you fall.
• Falls drop you 1 (Easy), 2 (Normal) or 3 (Hard) ledges, never below your last checkpoint (every 5th ledge).
• Timing windows: Easy ±35/95/150 ms, Normal ±30/75/120 ms, Hard ±25/60/100 ms (perfect/good/edge).
• Tap time is the server's receive time minus half your lowest round-trip of the session, capped at 30 ms.
• First to the summit wins. At the horn, unfinished climbers rank by height, then by who reached it first. Exact ties share a place.

Fairness

Everyone climbs the same tower, generated from the round seed (committed before the round, mixed with a public block hash). Your tap is timed by the server, not your device: the server's receive time minus half your measured round-trip (your lowest of the session, capped at 30 ms). The result is a pure function of the seed and that list of server-timed taps, which is published as the replay (climb/taps@1) — your browser re-runs every tap and must land on the same standings.

• Commit–reveal seed
• Public block seed
• Server-clock timing
• Hash-chained log
• Re-simulate it yourself

Verify a round yourself

1. Before the start, note the seed commitment on the fair-play page.
2. After the round, check sha256(revealed server seed) equals the commitment and that the final seed = sha256(server seed ‖ entrants hash ‖ lock block hash).
3. Open the replay: your browser rebuilds the tower from the seed and re-judges every recorded tap (lane, server time) — it shows “matches the server result” only if every climber ends on the same level, time and place.
4. Each tap is in the hash-chained event log with its server receive time and RTT; compare the event-log hash with the signed result.

Anti-cheat

• Client timestamps are ignored: tap time = server receive time − min(RTT/2, 30 ms).
• Taps less than 120 ms apart are ignored (mashing locks you out); more than 8 taps in any second are ignored.
• Taps while airborne or falling are ignored; taps before the start or after the horn don't count.
• Tap messages must be exactly {k:"tap"}; anything else is dropped. Inputs from non-entrants are ignored. Floods (> 20 messages/s) are dropped before they reach the game.
• Bot-like timing over 12+ jumps — ≥ 75% within ±3 ms of the line-up, or a timing spread under 7 ms — is flagged on the result, and a flagged climber can't win a prize (the place stays on the board; the next eligible climber is paid).