Security Architecture

he Server, Anti-Cheat, and Funds.

Security Architecture

Server-Authoritative Logic

The Golden Rule of Game Dev: "Never Trust the Client."

In 21 Duel, the Telegram Mini App (the UI you see) is just a display screen. It does no calculations.

• Movement: When you click "Hit," you are sending a request to the server.

• Validation: The Python backend (bot.py) checks if it is actually your turn, if you have the funds, and if the game is active.

• Execution: Only if all checks pass does the server deal a card.

The "Fog of War" (Anti-Sniffing)

A common cheat in web games is "Packet Sniffing"—intercepting the data coming from the server to see hidden information.

Our Solution: The server does not send the opponent's hidden card data to your device until the round is officially over.

• Network Packet: opponent_hand: ["10H", "??"]

• The Cheat: Even if a hacker intercepts the packet, they literally see "??". The data for the hidden card does not exist on their device.

Fund Safety & Atomic Transactions

• State Management: User balances are stored in a secure SQL database, not in temporary memory.

• Atomic Updates: When a game ends, the credit (Win) and debit (Loss) happen in a single, atomic database transaction. This prevents "Duplication Glitches" where a user might try to claim a win twice due to lag.

• Bot Protection: We utilize Telegram's initData signature validation to ensure every request comes from a legitimate Telegram user, preventing external bots from spamming our API.