Authentication & permissions

Three separate permissions#

Arcade grants and inputs#

The EIP-712 arcade grant is bound to the player, game key, chain, registry, game contract, expiry and revocation state. Both owner and game-key signatures prove the delegation and possession. The maximum session duration is two hours.

Match joins bind the opponent, room, commitment, session, nonce, expiry, tournament, mode, ranking choice and rules version. The existing Input signature binds its match, player, direction, sequential nonce and block-validity window. A revoked or expired key fails validation; replaying a nonce does not create another valid command.

Only the limited arcade material and recovery data are stored in sessionStorage. The remembered passkey hint in localStorage is not the wallet key. Owner-derived keys are opened for their operation and closed afterward.

Independent family and compact controls#

Human rules 14 and 18 register a limited two-hour family authorization on Monad. Admission binds its player and game key to the exact approved arena, epoch and logical match. Later controls carry compact arguments and a game-key transaction signature, without repeating a full owner grant on every movement. Root signatures remain necessary for spending, profile writes, encrypted-data writes and revocation.

Family revocation prevents future admissions. Revocation of a binding already admitted to an engine is a separate operation. The interface reports a pending network revocation instead of claiming that a local logout invalidated every remote copy. The journal preserves uncertain signed bytes across F5 and reconciles their exact hash before another nonce is used.

Historical single-application controls#

The previous rooms deployment verifies the complete owner-signed SDK grant once through registerControls. It records the player, limited game key, expiry and engine epoch. Later movements use direct zero-value transactions from that game key, so the full grant is no longer repeated in every command. Historical match links retain these authorization rules.

Reloading the same tab checks the recorded binding and reuses it. Changing the engine epoch requires a new binding. Disconnect attempts revokeControls before removing the local key; a refused or offline attempt is shown as pending, and expiry still applies. Revocation leaves a tombstone, so the same grant cannot register that key again. Older deployments retain their existing authorization paths.

The tab journals signed game bytes before sending. After a lost response, it reconciles the original hash before signing another command. An absent receipt is not proof of failure.

Application authentication#

The server issues a single-use nonce and message bound to player, chain and game. A valid owner or active arcade signer exchanges the signed message for an HttpOnly, SameSite Strict cookie, Secure on production HTTPS. The current cookie lifetime is two hours; a session signed by an arcade key also depends on that key remaining valid.

Private app routes check the cookie and the matching x-pongit-player header. State-changing app requests check the allowed Origin. This prevents a changed account in another tab from silently editing the previous account's profile.

Private notebook#

A separate PRF namespace, pongit.xyz/notebook/v1, feeds HKDF and a nonextractable AES-GCM key. Each save uses a fresh 96-bit IV, account-bound authenticated data and revision-based concurrency control. Keys and plaintext stay in memory; stored ciphertext is not a guarantee against a compromised live browser.

Receiving money#

Fixed-recipient payouts are permissionless to trigger or retry. No beneficiary signature is required because the caller cannot choose another recipient or change the debt. Spending permissions are unchanged. API reference.