Browser games have an old problem: the score is worked out on the player's own device, and anything on a device can be changed. Send a made-up number to the server and, on most sites, it lands on the leaderboard. We built Gamefinity so that a number on its own proves nothing. What counts is the run that produced it, and we play that run again ourselves.
What your browser sends
Every game runs on a fixed clock of 60 steps a second, called ticks. While you play, the game records what you pressed and on which tick: a tap at this spot on tick 412, a key on tick 913. In Mate in One that log is simply your moves, each with the tick you played it on. When the run ends, your browser reports the score, and for any run that can reach a leaderboard it uploads that input log too, with the seed the round was dealt from and the exact version of the game you played.
It also records a fingerprint of the game's whole state once a second, every 60 ticks. Those checkpoints let the server tell not just whether a run ends in the same place, but whether it went the same way all along.
Why a replay gives the same answer
A replay only works if the game is fully predictable: the same seed and the same inputs must give exactly the same run on a cheap phone, a laptop and our servers. That rules out a lot of ordinary programming. A game's rules may not use the browser's random numbers, the clock or anything else outside the game. They use whole numbers or fixed-point numbers instead of floating-point drift, and even trigonometry comes from a lookup table in our own code, because different browsers are allowed to round sine and cosine slightly differently.
On the server those forbidden functions are switched off outright. If a game tried to call the clock or a random number while being replayed, it would fail loudly instead of quietly giving a different answer.

The checks, in order
Each scored run that can change a board goes into a queue, and a worker takes it out and runs these checks. The first failure decides.
- The file is intact. The replay's fingerprint must match the one the game reported with its result, and it must read as a valid replay.
- The details agree. The game, its rules version, the seed, the run, the mode, the number of ticks, the score and the final state's fingerprint in the replay must all match what the run reported.
- The right code. The server loads the exact version of the game you played, identified by a fingerprint of its code, not just its name.
- The replay. The game is played again with your inputs and nothing else. Its end, every checkpoint along the way, and every input must line up exactly, with no input left over.
- The tie-break time. In games where the faster player wins a tie, the time you were credited must equal the time the replay measures.
- The live record. For runs that send progress while you play, that progress must form an unbroken chain and never get ahead of real time.
That last check matters most in The Daily. While you play it, your browser sends a short fingerprint of your inputs so far every 600 ticks, about every ten seconds, and the server notes when each one arrives. A run that was rewritten afterwards would break the chain, and a run played faster than real time would be caught too: no progress fingerprint may arrive more than half a second earlier than the game's own clock allows.
What happens after the verdict
A run that passes is marked verified on every board it reached. Until then it shows as unverified. A run that fails comes off those boards, the player's entry falls back to their best verified run if they have one, and the run is flagged for us to look at.
Two players can never post the very same run. When a verified run with a real score and at least 600 ticks of real play has exactly the same checkpoints as another player's verified run, the copy fails as a duplicate.
Some failures are not the player's fault: a server can time out, or a game version can turn out to behave differently on some device. Those runs are retried up to two more times. If honest runs of one version start failing for many different accounts, that version is taken off the leaderboards for new runs until we fix it, and runs that fail on it from then on are not held against their players.
Guests are checked exactly like accounts. A guest's score sits on the same boards and goes through the same replay.
What a replay cannot prove
A replay proves that a score came from those inputs. It cannot prove who or what made them. A program that plays perfectly would pass, which is why bots and scripts are against our terms of use. On our flagship games the top 10 of each board also goes to a review queue, where a person can hide a run, and in question games such as Daily IQ and Uncommet the clock keeps running while a question is open, so it cannot be stopped to look an answer up.
Our footer says it in one line: every top score is verified by replaying it on our servers. This is what that line means. If a score on a board looks wrong to you, tell us and we will look at the run.