What HOODBASKET is trying to be
HOODBASKET is a game primitive for eligible tokenized-stock assets on Robinhood Chain. A player chooses an allowlisted token, commits an amount, accepts a versioned rule set, and waits for an outcome. The game engine maps the outcome to a payout multiplier and settlement route. The user-facing wheel is only an animation of contract state.
The current public concept references a 0.9x → 1.5x multiplier range. That is not a promise of profit: a 0.9x result is below the committed amount. Exact buckets, weights, fees and production settlement mechanics remain TBA until published.
Five rules before features
- Rules before randomness. A round stores or references the active game configuration before requesting an outcome.
- Reserve before acceptance. A round is rejected unless the vault can cover the maximum additional payout liability.
- Explicit asset identity. Every supported token is allowlisted by contract address, not by ticker text.
- One-way configuration versions. Admin changes create a new version; they cannot rewrite a committed round.
- Fail closed. Paused assets, stale randomness, insolvent reserves or invalid callbacks must not produce a silent settlement.
Robinhood Chain integration
Robinhood Chain is an EVM-compatible Layer 2. The front end uses the public mainnet configuration below for wallet switching. For production traffic, the app should move to a dedicated RPC provider rather than depend on a public rate-limited endpoint.
| Parameter | Value |
|---|---|
| Network | Robinhood Chain |
| Chain ID | 4663 / 0x1237 |
| Native gas | ETH |
| Public RPC | https://rpc.mainnet.chain.robinhood.com |
| Explorer | https://robinhoodchain.blockscout.com |
Small contracts, explicit jobs
GameEngine
Creates rounds, snapshots config version, pulls approved stake, requests randomness and exposes settlement state.
AssetRegistry
Maps token addresses to enable flags, risk caps, decimals metadata and supported settlement modes.
RandomnessAdapter
Normalizes a chosen provider into request / fulfill callbacks without hard-coding the game to one vendor.
BasketVault
Holds settlement inventory or accounting reserves, enforces capacity and transfers payouts.
RuleRegistry
Stores immutable versions of multiplier buckets, cumulative weights, fees and round timeouts.
Admin / Guardian
Time-locked configuration owner plus emergency pause authority with narrowly scoped permissions.
GameEngine → reserve check → BasketVault
GameEngine → request randomness → RandomnessAdapter
RandomnessAdapter → fulfill → GameEngine → map outcome → BasketVault → User
One round, six states
↓ createRound()
COMMITTED — stake moved; rules frozen
↓ randomness request accepted
PENDING_RANDOMNESS
↓ callback
RESOLVED — outcome stored
↓ settlement transfer succeeds
SETTLED
Timeout / rejected callback → REFUNDABLE
Emergency pause blocks new rounds but does not erase existing claims.
Round data should minimally include player, input token, amount, rule version, randomness request ID, creation block/time, outcome index and terminal state. Production storage layout should be finalized before audit.
Integer math only
Use basis points or another fixed integer scale; never floating point. If multiplierBps represents the total payout multiple:
protocolFee = fee policy defined by the active rule version
netPayout = grossPayout − protocolFee
For example, 0.9x corresponds to 9,000 basis points and 1.5x corresponds to 15,000 basis points. The site deliberately does not invent a fee rate or production probability table.
If the basket settles in multiple assets, each component uses an allocation share whose integer sum must equal the configured denominator. Rounding dust should have a deterministic destination documented in the rule version.
The wheel cannot choose its own winner
The visual animation must never generate the authoritative outcome. Production settlement should rely on a verifiable or externally committed randomness source exposed through RandomnessAdapter. The provider is currently TBA.
Outcome mapping
Store cumulative integer weights in an immutable rule version. Reduce the random word into the total weight domain, then pick the first cumulative boundary above the sampled value. This makes the probability table inspectable before a round.
for each bucket:
if sample < cumulativeWeight[bucket]:
outcome = bucket
break
Accept only what can settle
Before a round is accepted, the vault should reserve enough additional inventory to cover the maximum payout above the committed stake. In the simple same-asset case:
incrementalLiability = max(0, maxGross − stake)
require(freeReserve ≥ incrementalLiability)
Basket settlement adds conversion and inventory risk. A safer initial design is to pre-fund each basket component and enforce per-asset capacity. If conversion is ever introduced, slippage limits and oracle assumptions become separate audited risk surfaces.
Address first, ticker second
A ticker is display text. The actual identity of a supported asset is its chain + contract address. The registry should prevent lookalike symbols from entering the game and give the guardian a way to halt new rounds for a problematic token without touching unrelated assets.
bool enabled;
bool basketEligible;
uint96 maxStake;
uint8 settlementMode;
}
Front-end metadata may show issuer details and links, but contract logic should rely only on verified token addresses and explicit numeric configuration.
Wallet-first, contract-second
The included interface calls eth_requestAccounts, then attempts wallet_switchEthereumChain for chain ID 0x1237. If the wallet reports the network is missing, it falls back to wallet_addEthereumChain using Robinhood Chain's official public RPC and explorer.
Live transaction buttons should stay disabled until a canonical contract address and ABI are committed in the release build. For a production release, contract constants should come from a signed release manifest rather than editable DOM values.
chainId: '0x1237',
chainName: 'Robinhood Chain',
nativeCurrency: { symbol: 'ETH', decimals: 18 },
rpcUrls: ['https://rpc.mainnet.chain.robinhood.com'],
blockExplorerUrls: ['https://robinhoodchain.blockscout.com']
}
Controls that belong in v1
- Checks-effects-interactions and reentrancy protection around token transfers.
- Safe ERC-20 transfer wrappers and explicit rejection of unsupported fee-on-transfer behavior unless deliberately handled.
- Per-asset max stake, global exposure cap and reserve accounting.
- Pause new rounds independently from settlement / refunds.
- Immutable round configuration version after commitment.
- Strict randomness callback authorization and request-ID matching.
- Timeout path that cannot be blocked by the operator.
- Admin ownership moved away from a single hot wallet before production.
- Verified source code, reproducible deployment parameters and public event indexing.
- Independent review before enabling value-bearing play.
Design the unhappy path first
Randomness can stall, RPCs can fail, tokens can pause, and an asset can lose liquidity. A game that only specifies the happy path is incomplete.
| Failure | Expected behavior |
|---|---|
| Randomness timeout | Round becomes refundable after an immutable timeout window. |
| Insufficient reserve | Reject round before taking stake. |
| Asset disabled | Reject new rounds; preserve claim / refund path for existing rounds. |
| Unexpected token transfer behavior | Revert commitment and leave no partial round. |
| Frontend unavailable | Users can call verified contracts directly once deployed. |
| Admin compromise | Timelock / limited guardian scope reduces immediate blast radius. |
What changes TBA into live
- Freeze v1 scope and formalize multiplier / weight table.
- Select and integrate a production randomness provider available on Robinhood Chain.
- Implement contracts with tests covering solvency, timeout, callback spoofing and token edge cases.
- Deploy to Robinhood Chain testnet and publish addresses.
- Run adversarial test rounds and index every state transition.
- Independent security review; resolve critical/high findings.
- Deploy production contracts with reproducible parameters.
- Verify source on Blockscout and publish ABI / deployment transaction.
- Fund settlement reserve and publish the reserve policy.
- Only then enable the live transaction path in the front end.
Network references
Network constants in this site are sourced from Robinhood's current Chain documentation. Use the official pages when validating a deployment: