How ROBACHA works, in detail.

ROBACHA is a memecoin gacha built for Robinhood Chain. You pay for a spin, the contract draws a reward from a funded pool using verifiable randomness, and the reward settles to your wallet as an ordinary ERC-20 transfer.

Three properties hold at all times, and the rest of this page explains how each is enforced in code rather than by policy:

• Odds are published on chain before you pay, and cannot change for a pool that has already sold a spin.
• Rewards come from inventory deposited in advance. A pool cannot open unless every reward it can pay is already funded.
• No operator — including the administrator — can choose your result, supply the randomness, or replace it.

Buying a separate random word for every individual spin would cost more than most spins are worth. Instead, entries collect into a round, and one word settles the whole round.

1. 1

   You enter

   Your payment is escrowed by the gacha contract and your entries are appended to the open round. No reward is chosen here — the outcome does not exist yet, so nothing about your transaction can influence it.

2. 2

   The round closes

   A round closes when it fills or when its time window ends, whichever comes first. After that no entry can be added, so the set of entries a random word will settle is fixed before the word is ever requested.

3. 3

   Randomness is requested

   Anyone can trigger the request — it is not a privileged action, so a round cannot be stranded by an operator failing to act. The request goes to StonkPit's conductor and buys a word folded from the next four certified mining prints: work that has not been done yet at the moment it is bought.

4. 4

   The word returns

   Miners deliver the word once those prints are certified — permissionless, so it does not depend on ROBACHA acting. Only the authorised receiver contract can hand it to the gacha, and only once per round.

5. 5

   Entries settle

   Each entry derives its own result from that word, and the reward is reserved against vault inventory. Settlement is batched so a full round can never exceed the block gas limit.

6. 6

   You claim

   Your reward sits assigned to your address until you claim it. Claiming is a separate transaction that transfers the tokens to you.

Robinhood Chain has no native VRF, and every on-chain value available locally is either predictable by a participant or choosable by a block producer. ROBACHA buys its randomness instead, from StonkPit's conductor, which sells words sealed by real mining work:

RobachaGacha
  → RobachaStonkPitEntropy         (adapter)
  → StonkPit MultiConductor
  → four certified mining prints   (not yet mined)
  → miners deliver the word
  → RobachaStonkPitEntropy         (authenticated callback)
  → settlement

The order is the guarantee. A round closes before its word is bought, so the set of entries is fixed first, and the word folds prints that have not been mined yet — nobody knows it while anyone can still enter, ROBACHA included. Previous versions used a commit-reveal scheme run by ROBACHA; rounds settled under it remain verifiable on their own terms.

One word settles an entire round. Each entry's own result is derived from that word by domain-separated hashing, bound to values that make two entries mathematically unable to share a result:

seed = keccak256(abi.encode(
    randomWord, block.chainid, poolId,
    version, roundId, entryIndex, entrant
))

The tier, the reward slot within that tier, and the amount are each drawn from separately-tagged hashes of that seed, so they cannot be correlated with one another.

None of the following is used anywhere, alone or combined:

• block.timestamp, block.prevrandao, block.difficulty or blockhash
• the L2 block number
• user-supplied entropy
• any value chosen off-chain by ROBACHA or an operator
• browser or JavaScript randomness

The return path is validated before a word is accepted: the conductor must be the caller, the request must be one this adapter opened, and the round must not already be fulfilled. The gacha then checks the request id independently. Any round can be re-derived afterwards from published values — the verifier reads the word back from the conductor's own records and compares it with what the round used, so a substituted number fails the check.

A pool defines tiers, each with a probability in basis points. The registry refuses to configure or activate a pool whose tiers do not total exactly 10,000 bps — there is no rounding slack and no implicit remainder tier.

Each tier holds one or more reward slots. A draw picks a tier by its published probability, then picks a slot uniformly within that tier. So a slot's absolute odds are its tier's probability divided by the number of slots sharing that tier.

Rarity names — common through legendary — are a presentation label, not pool data. The contract only knows probabilities. The interface ranks tiers by probability and labels the scarcest as legendary, so a pool with fewer than five tiers still reads sensibly.

Reward tokens live in the reward vault, which tracks what it holds against what it owes. The core invariant is enforced on every state change:

reserved[token] <= IERC20(token).balanceOf(vault)

When a spin settles, the reward is reserved against free inventory. The vault refuses to reserve beyond its own balance, so the gacha can never promise a reward the vault cannot pay.

A pool cannot be activated unless every reward slot is funded to at least its own maximum, so any single winning draw is payable at the moment the pool opens.

Non-standard tokens are rejected rather than accommodated:

• Fee-on-transfer tokens cannot be deposited — the vault measures the balance delta and reverts if it differs from the stated amount.
• Rebasing tokens are detected by tracking deposits net of payouts; drift below that figure marks the token unhealthy and blocks activation.
• Withdrawing surplus can never touch inventory reserved against an unclaimed reward.

An assigned reward stays yours until you claim it. Claiming transfers the tokens and marks the reward claimed; a second attempt reverts, and no address other than the owner can claim it.

Claims stay open while spins are paused. Pausing stops new entries — it does not withhold a reward you have already been assigned.

If randomness never arrives, the round becomes refundable after a timeout. Anyone can trigger that transition once the timeout has elapsed; no administrator can trigger it early, and none can substitute a result instead.

Refunds return what the round still holds. The randomness request is paid out of the surcharge, never the base price, so the base price is always fully covered. Any shortfall in the surcharge is divided evenly across participants to the wei, rather than falling entirely on whoever is last in the list.

A spin costs a base price plus a randomness surcharge. They are quoted separately in the interface before you are asked to sign, and they are accounted separately on chain.

The three components must total exactly 10,000 basis points, checked when a change is proposed and again when it is executed. Changes sit behind a 48-hour timelock and emit events at both proposal and execution.

A pool version snapshots the split when it is created, so a fee change can never alter the economics of a pool that is already selling spins. It applies only to future versions.

Privilege is split across distinct roles rather than concentrated in one owner: pool management, pausing, treasury withdrawal, vault management, randomness delivery, and the gacha's own routing role.

What an administrator can do:

• Create and activate a pool version, or close one
• Pause and unpause spins
• Deposit reward inventory, and withdraw genuinely unreserved surplus
• Withdraw accrued protocol revenue to the treasury it accrued for
• Propose a fee change, subject to the caps and the 48-hour timelock

What an administrator cannot do, by construction:

• Supply, replace or influence a random word
• Choose or alter any spin's result
• Change probabilities, amounts or price on a pool that has taken a paid spin
• Withdraw inventory reserved against an unclaimed reward
• Redirect accrued revenue to an address other than the one it accrued for
• Mark a round refundable before its timeout has elapsed

Built and running:

• All contracts deployed and source-verified on Robinhood Chain
• Randomness bought from StonkPit's conductor, with the adapter funded ahead of the rounds it pays for
• Frontend reading pool, odds, inventory and wallet state directly from chain
• Activity and wallet rewards served from confirmed contract logs and reads

Not built yet:

• Database-backed event indexer — activity currently covers a recent block window only, and full history is unavailable
• Administration application — pool operations are performed by direct contract calls
• Automated market-data validation of pool economics before activation
• Age gate, terms acceptance capture, geofencing and self-exclusion controls

Public paid spins are disabled by default and require the operator to enable them deliberately, on top of the contract's own pause and readiness checks.

ROBACHA is a paid, chance-based token-reward product. You pay a known price for a draw whose outcome is not known in advance and is not guaranteed to be worth what you paid.

• Token rewards fluctuate in value and can lose value entirely.
• Published probabilities apply to every entry independently. Past results do not influence future ones.
• Nothing here is financial, investment, tax or legal advice, and no outcome is guaranteed.
• A paid chance-based product may be regulated differently across jurisdictions. Availability may be restricted.