How VoltCade leaderboards are protected, and where the protection stops
A plain account of the checks every score passes before it appears on a board: what they catch, what they cannot, and what happens when something gets through.
A leaderboard on the public web is a target. Anyone who has run one knows the moment a 999,999 appears on a game where a strong run scores a tenth of that. Once it does, every honest score next to it is worth less.
No scheme stops a determined attacker, and we would rather describe ours accurately than oversell it. The aim is modest: make faking a score more work than earning one. These are the checks a score goes through.
A session issued by the server
When a game starts, the page asks the server for a session. The server records it and returns a token signed with a secret key that never leaves the server. A score must arrive with a valid token for that session and that game. A session can be used once: the moment a score is accepted against it, it is spent, and a second submission with the same session is refused. Sessions also expire after a day.
This stops the simplest attack, which is posting a number straight to the score endpoint without ever having opened the game.
A ceiling and a clock for every game
Each game declares two numbers: the highest score that is actually possible, and the shortest time a real run can take. Both are held on the server, not in the game, so editing the game in your browser does not move them. A score above the ceiling is rejected. So is a score that arrives sooner after its session began than a run could possibly take.
Limits on how often
Scores from one network address are limited per game per hour. A person playing normally never gets near the limit. A script hammering the endpoint does. Initials are checked too: exactly three capital letters.
Verified players
Accounts are optional, and guests can post scores. But a score posted by a signed-in player carries a verified check and is tied to that account. It does not make a score more honest, but it does make it accountable: you can see that a set of scores belongs to one player.
What this does not catch
These checks do not watch how a run was played. Someone who automates the real game in a real browser, waits a believable length of time and submits a believable score will pass every one of them. We do not record or replay inputs, and we do not fingerprint devices. We would rather be straightforward about that limit than imply a system we do not have.
When something gets through
Scores can be removed by hand. If you see one that cannot be real, the contact page is the way to tell us: say which game and which score. A removed score is gone from the board and from the rankings built on it.
That is the whole system. It is deliberately simple, it does not require anyone to hand over personal details in order to play, and it keeps the cost of cheating above the cost of getting good.