Built on Robinhood
Wallet identity, browser games, onchain plot ownership and the launch setup.
Local development status
The wallet, Ticket, username, floor and revenue interfaces are implemented. The onchain floor contract and its purchase, takeover, resale, transfer and claim flows have been tested on a local blockchain, including the connection between the website API, contract events and account records.
The actual $CADE and Arcade Floor contract addresses are not configured. Plot purchases stay disabled until the real contracts, network and authorization are connected and checked. This is not a claim that a mainnet contract has been deployed or independently audited. The public waitlist remains active.
A separate local development mode retains simulated balances and transactions for testing. Those balances do not transfer real tokens or fund live claims.
Robinhood Chain
Wallet connections use Robinhood Chain mainnet, chain ID 4663. ETH is the native currency used for network fees.
Paid USDC play packs are currently unavailable on this network. Mainnet token and floor contracts remain unconfigured.
See the official Robinhood Chain documentation for network details. ARCade is an independent project.
Wallet connection and login
RainbowKit connects MetaMask, Rabby and Rainbow browser wallets. A signed login message verifies control of a public address. Connection alone does not create an authenticated player session.
Each account selects a username displayed on leaderboards and plots. Wallet ownership still controls the account. Local test accounts and balances are development tools; they do not authorize production transactions.
Game infrastructure
Games run in the browser using a shared game engine. The server stores runs and calculates their scores, enforces shared play allowances and records completed-game rewards. Game state, Ticket balances and leaderboard calculations stay offchain.
The hosted site uses Vercel and Turso for its account, game and accounting records. Confirmed blockchain events establish plot ownership in the website’s records. The separate local development database and test balances do not fund hosted accounts.
Player data and administration
Account records connect usernames to wallet addresses, plays, Tickets and plot history. Public leaderboards and plot panels display usernames, while ownership remains associated with public wallet addresses. Account actions require the wallet’s signed login session; token transactions additionally require wallet confirmation.
Authorised administrators manage the claim approval queue and verify creator-fee receipts. Approval prepares a payout for an authorised wallet to send; it does not automatically transfer USDC. Local simulation controls are excluded from the hosted transaction flow.
Smart contracts
The implemented Arcade Floor contract records ERC721 ownership for the 80 plots and enforces initial purchases, escalating steals, resales and transfers. Its purchase and steal payments use $CADE; native USDC is used for approved claim payouts. Gameplay, score calculation, Tickets and daily revenue accounting remain on the server.
For an initial purchase or steal, a signed authorization binds the player, plot, price, Tickets, ownership version and expiry. The server reserves the Tickets while the player confirms the wallet transaction. Reused, expired or stale authorizations cannot buy the plot.
Payouts are sent by the treasury or contract owner after administration approves a claim. The contract checks the current owner, ownership version and claim reference before forwarding the payment, preventing an old-owner payout after a transfer. Contract code and integration have been tested locally; deployment and independent review remain separate launch steps.
$CADE token contract address
Placeholder
Arcade Floor contract address
Placeholder
Score validation
The server replays submitted controls against the run’s seed and game-engine version, verifies ownership and calculates its score. Only a completed valid run qualifies for Tickets and daily game activity. A repeated submission must not create a second reward.
Replay validation checks compliance with game rules; it does not prove that a human played or prevent every form of automation.