I built the frontend for a play-money casino that runs inside Telegram — roulette, plinko, a crash-style game called sky-rush, and a wheel. The single most important architectural decision was made before any game was written:
The client never decides anything. Ever.
Why you can't trust your own frontend
Game code running on a player's device is game code running on an attacker's machine. They can read it, modify it, replay requests, and patch memory. If the client computes where the plinko ball lands — even partially, even "just for smoothness" — someone will make it land where they want.
"It's only play money" doesn't save you. A play-money economy with an exploit stops being an economy. Balances inflate, leaderboards become meaningless, and legitimate players leave because winning feels fake.
The round lifecycle
Every game, no matter how different it looks, runs the same trusted loop:
- The client places a bet. That's the only decision it's allowed to make — how much, on what.
- The server validates — does this user exist, is the bet within limits, does the balance cover it?
- The server rolls the outcome. All randomness lives here. The result and the payout are computed and persisted before the client hears anything.
- The client receives a result — not odds, not a formula, a result — and animates toward it.
- Balances settle server-side. The client's balance display is a cache of the truth, never the truth.
Animation is theater
This is the part that surprises people: the animation is fake, and that's the point. When the plinko ball bounces down the pegboard, the outcome is already decided — the client picks a path that ends in the bucket the server chose. The roulette wheel spins to a number it was told. Sky-rush's curve climbs to a crash point that already exists in a database row.
Players get the drama; the economy gets integrity. Once you accept that the client is a renderer, the animation layer actually gets simpler — it never handles edge cases about outcomes, because it never generates them.
What it does to your API design
Server-authority isn't one endpoint decision; it's a style that spreads through the whole API:
- Endpoints return results, never rules. No odds tables, no payout formulas, no RNG seeds in any response.
- Balances mutate in exactly one place. Every credit and debit is a server-side transaction tied to a round.
- The client's state is disposable. Kill the webview mid-round and reopen: the server knows the round's state; the client just re-renders it.
Telegram makes the auth story clean: Mini Apps hand the frontend a signed initData payload, the backend verifies Telegram's signature, and identity comes from Telegram itself — no separate signup flow to protect.
The takeaway
This is the same trust model real-money gaming and fintech run on, applied to a Telegram toy. The habit transfers: any time a client can profit from a computation, move the computation. The frontend of this project is open — you can check that there's no game math in it, anywhere.