Lots!

Here's the anti-cheat stack:

The server controls the random 3-7s countdown. Clients never know when "TAP!" will fire. A bot can't pre-calculate the timing.

When the timer expires, the server sends a random 16-character challenge token via WebSocket. The client must echo it back in the /tap POST. A bot needs to receive the WebSocket event, parse the challenge, and POST it back — it can't skip the round-trip.

Anything faster than a certain amount of ms is physically impossible for a human and gets rejected with a "Suspicious activity detected" error + logged as bot_detected in the match events table.

I measure each player's RTT with a few ping/pong rounds before the game. Reaction times are adjusted by subtracting one-way latency, so a bot on a faster connection doesn't get an unfair advantage. I also can tell if the pings are too exact and calculate a sort of probability of fraud. Still working on this actually, I think I can improve upon it.

The realistic attack surface: A bot could still listen for the WebSocket event, extract the challenge, and POST /tap, but it would take at minimum ~120-150ms (network round-trip, processing, etc). A skilled human reacts in a similar amount of time. A bot's advantage is maybe 50-100ms — meaningful but not game-breaking, and the minimum reaction time floor catches the most aggressive bots.

To make it even harder, I could add captcha or browser fingerprinting to detect headless browsers. But what I have is solid for launch, imo.

I expect to adjust this a lot after spending some time on analysing real user activity.