How Reviont is built to be safe

The game runs on our server. Your browser draws a table; it does not decide anything. Every action you take is re-checked against the rules server-side, so a modified client can send an illegal raise and simply be told no.

Just as importantly, the server only sends you what you are entitled to see. Your two cards and the community cards are yours; another player’s hole cards are not sent to your browser at all, so there is nothing in the page for a script to read.

• Decks are shuffled with the operating system's cryptographic random source, not a fast general-purpose generator.
• Before a hand, the server publishes a hash of the shuffled deck. After the hand it publishes the seed, so anyone can confirm the deck was fixed before the first card and never reordered mid-hand.
• Hand histories are retained so a disputed hand can be reconstructed exactly.

• Passwords are hashed with Argon2id at OWASP's recommended cost. We cannot read your password and neither can anyone who steals the database.
• Sessions are opaque random tokens checked against the database on every request. Revoking one takes effect immediately — unlike a signed token, which stays valid until it expires.
• Only a hash of your session cookie is stored, so a database dump does not yield working sessions.
• Sign-in is rate limited per address, and an account locks itself after repeated failures.

• Balances are integers in cents. No float ever touches an amount of money.
• Every movement is written to an append-only ledger before it is applied, and each carries an idempotency key — so a payment notification delivered five times credits you exactly once.
• Debits are a single guarded database operation, so two simultaneous withdrawals cannot both see a sufficient balance.
• Payment callbacks are rejected unless their HMAC signature verifies against our shared secret.

• A content security policy restricts where scripts, styles and connections may come from.
• Session cookies are HttpOnly, SameSite and — in production — Secure, so script cannot read them and other sites cannot send them.
• State-changing requests are checked against the request origin as a second, independent answer to cross-site request forgery.

No one can honestly promise a site cannot be broken into, and a site holding balances is a target worth real effort. What we can say is what the design assumes: that a client may be hostile, that the network may be watched, that a webhook may be forged or replayed, and that the database may one day be read by someone who should not have it.

Not live yet — Independent penetration testing and a published RNG audit are planned before real-money play opens. Until those exist, treat this page as a description of intent backed by code, not as a certification.

If you find a vulnerability, please report it privately to info@reviont.com before disclosing it. We will confirm receipt, keep you updated, and credit you if you would like that.