Questions and answers

No. The UI only sends your locked choices to the contract. The contract requests Chainlink VRF and settles from the returned random word.

No. The game options are encoded into the transaction before the VRF request starts. After signing, the choice is fixed on-chain.

Open the Chainlink VRF button on a game page. It shows the request ID, the wager transaction, and the settlement transaction when available.

Win sharing uses a short invite-focused message with light emoji, includes the payout multiplier when payout and wager data are available, and always links friends back to BasePlay. Game pages also include a lightweight invite card outside the win state; when a wallet is connected it shares the wallet referral path without querying referral stats, otherwise it shares the canonical domain.

The on-chain result is final first. Feed, profile, and leaderboard views are updated by the backend indexer after it reads settled Base events. Indexing is mainnet-first by default and batches deployed game addresses into one log query per poll window, while public activity views use cache windows to avoid unnecessary Supabase and RPC load.

Home global stats are served through a shared API cache for up to 10 minutes so every visitor can reuse the same aggregate response. Browser force-cache is disabled for this endpoint, so desktop, mobile, Farcaster, and private windows should converge on the same API value once the shared cache refreshes.

BasePlay uses standard wagmi and viem wallet flows with a global explicit wallet picker for normal web sessions, focused on real injected MetaMask when present, WalletConnect, Coinbase Wallet, and any standalone injected browser wallet. The picker renders at app-provider level, so header, mobile menu, and game-page connect actions all open the same centered modal on web with wallet-specific icons. Normal web sessions also run a silent reconnect check for previously authorized connectors, so desktop web reloads and returns can restore MetaMask, WalletConnect, Coinbase Wallet, or a valid injected wallet without opening the picker again. Farcaster and Base App or Coinbase Wallet in-app browser sessions skip the web modal and connect through their native connector. Explicit MetaMask target connectors and Base Account are kept out of the normal web picker to avoid duplicate or unsupported provider attempts, generic injected wallets are hidden unless a standalone provider exists, WalletConnect is shipped as a direct frontend dependency, and mobile WalletConnect returns are resynced on focus, pageshow, and visibility changes after the player starts a connection. The canonical app URL is https://baseplay.games, Base mainnet is the only active chain, game actions open the wallet picker first on web and then request Base mainnet switching when the wallet is on an unsupported network, wallet transactions include the BasePlay Builder Code attribution suffix, RPC reads keep public Base endpoints ahead of private or Alchemy fallbacks, backend status read failures retry another RPC instead of marking every game unavailable, frontend fallback contract status reads are batched with multicall to reduce RPC load, and the listing copy uses Play. Compete. Win on Base.

BasePlay publishes Farcaster Mini App discovery metadata at /.well-known/farcaster.json, emits feed embed metadata with branded launch imagery, trims the canonical app URL before generating embed URLs, uses a 1200x630 branded social preview for Open Graph and X/Twitter cards, calls the Farcaster ready signal in Mini App clients, and prioritizes the Farcaster Mini App wallet connector only after the player starts a wallet action. Automatic reconnect and background referral signing are disabled in Mini App sessions so reopening the app does not ask for wallet authorization. Core game and Base App flows remain standard wagmi/viem flows.

BasePlay loads Google Analytics through the official gtag script after the app becomes interactive. The production measurement ID is G-EXWSNL6326 and can be overridden with NEXT_PUBLIC_GA_MEASUREMENT_ID if the analytics property changes.

Profile sections are lazy-loaded to reduce Supabase and RPC usage. Counts are shown inside the opened section after the relevant data has loaded, with loading rows displayed while the request is in progress.

Leaderboard data is not used to settle games, so weekly rankings are served through a shared 30 minute cache and all-time rankings use a longer 3 hour cache from aggregate player stats. A player opening it later can reuse the same cached ranking instead of making another database query, and the weekly API falls back to the latest indexed week if the current week has no rows yet.

The wager transaction can confirm before the VRF callback arrives. During that window the round is locked, and the pending/refund panel tracks it.

After the timeout block window fully passes, the same wallet can claim a refund from the game contract. Refund does not trigger a new VRF request.

No. The refund state lives on-chain. Reconnect the same wallet and check the wallet menu or Profile page to see unresolved rounds.

XP is based on the settled wager amount. Wins and losses at the same bet size earn the same XP, so XP represents play volume rather than lucky outcomes.

No. Referral rewards are only XP and badge progression. They do not create claimable ETH, rebates, or vault liabilities.

Lucky Draw is a promotional reward loop, not a wagered game round. After 10 qualifying settled rounds at or above 0.000115 ETH, the connected wallet opens the dedicated Lucky Draw page and submits those round request IDs to the LuckyDraw contract. The backend filters candidates through the live game contracts first, and the LuckyDraw contract verifies every proof against the approved game contracts, blocks reused rounds, snapshots the prize table, requests Chainlink VRF, and makes the resolved ETH prize claimable on-chain. The backend/UI also applies a soft daily earning cap of 10 draw rights per wallet per UTC day, resetting at 03:00 TSI; unused available draws and partial progress carry forward only when backed by unconsumed contract-valid proofs. Available draws and next-draw progress are shown separately, so progress restarts at 0/10 after an available draw is earned and then continues 1/10, 2/10, and onward toward the next draw. Backend maintenance can reconcile stored Supabase counters to the same proof-backed source if old indexer data drifted. The Lucky Draw page keeps the request transaction and VRF request ID visible while the draw is pending, and it can surface the resolved prize from wallet history if VRF resolves after the first wait window. Claimable wallet rewards are highlighted in green, use a dedicated claim button, and disappear from the claimable list once the claim transaction is mined. The page includes a collapsible How it works panel that summarizes qualifying, unlocking, daily cap, and claiming. If daily status is still loading, the page falls back to the configured cap instead of hiding available draw data. Pending, failed, refunded, duplicate, wrong-wallet, already consumed, or below-minimum rounds do not create valid UI draw proofs.

The admin Lucky Draw page focuses on reward config, the 0.000115 ETH minimum eligible bet, the 10 draw daily cap, ETH/USD reference pricing, historical rows, and the LuckyDraw reward treasury with ETH and USD estimates. VRF subscription health and funding now live under the separate admin VRF page because the same subscription affects both game settlement and Lucky Draw randomness. Admin operation reads and writes require the frontend backend URL, the Railway backend service to pass /health, a configured multi-wallet admin allowlist on frontend and backend, and a matching owner/admin wallet signature. Vercel deploys inline only defined public env values, pins the frontend output directory, and uses stable Next.js 16.2.6 so optional missing frontend variables and Next adapter canary defaults do not block builds. The daily cap control defaults safely to 10/day if an older admin response is missing that field; internal Supabase progression plus Lucky Draw functions are not exposed for public client execution.

Yes. Admin controls can pause the feature, change the required round count, set the minimum eligible bet, update the daily cap, update the ETH/USD reference used by the UI, and edit on-chain prize amounts and weights. A draw uses the prize table snapshot from request time, so admin changes after a player opens a draw cannot alter that pending result.

No. Referral relationship and reward rows are kept behind the backend referral API, which uses service-role Supabase access and request rate limits.

Daily and weekly quests update after a settled on-chain round is indexed. They can track rounds, wins, distinct games, and streaks. Pending, failed, or refunded rounds do not count.

Not in the first version. Badges are profile achievements now, with mint-ready metadata fields prepared for a future contract if it is added.

XP rewards activity and quest progress. Volume ranks how much was wagered in the selected leaderboard scope, so active players can be compared without turning leaderboard order into a lucky profit race.

Game pages show the gross multiplier from the game rule. The vault applies the configured house edge before sending the final net payout.

Direct calls use the same game contract validation as the UI. Invalid params revert, active rounds are limited, and the vault reserves max payout before randomness is requested. For Lucky Draw, the 0.000115 ETH minimum eligible bet is contract-enforced, while the daily 10 earned-draw cap is a backend/UI soft cap until a future LuckyDraw v2 moves that limit on-chain.

Bots can submit transactions like any wallet, but they cannot know the VRF result before the contract receives it. Rate limits and max bet controls reduce spam and vault risk.

Scratch Card has no player-side choice. One bet creates one VRF-backed prize tier, so the UI presents it as a single reveal ticket.

Some games can land below 1x gross, such as low Plinko slots. That is a payout segment, but it can still be less than the wager and therefore a net loss.

Check the connected wallet, selected Base network, bet amount, and the game options. BasePlay also checks network and wallet balance before sending the wager.

BasePlay only opens Play when the selected game is ready and the bankroll can safely cover the round. If it is disabled, try another game or check again later.