Reading Robinhood Chain
Loading verified UPONZI state...
The transparent 3-wide UPONZI
UPONZI separates the money rules from the infrastructure. The referral core is permanently fixed and contains no admin withdrawal. Its immutable owner can only pause or resume new registrations. Only the isolated buyback executor can be upgraded so token and liquidity infrastructure can keep working if the ecosystem changes.
Immutable core
Isolated module
Once the token launches, the developer may bind one buyback proxy to the core exactly once. Its execution logic can then be upgraded only after the replacement has been public on-chain for 48 hours. This allows future router or liquidity support without changing the referral system.
Admin boundaries
These restrictions come from the deployed code, not from a promise by the team. The immutable owner has only the two registration pause functions shown above.
Permanently unavailable
Narrowly permitted
A buyback upgrade can change how future buyback ETH is used. It cannot expand the 7% allocation or gain access to the other 93%. Pausing joins does not grant access to any funds.
Earning model
The calculation uses the fixed 0.033 ETH entry and the immutable rate for each ancestor level. Values are allocated on-chain in integer wei.
Three-wide network
Three direct entries allocate 0.0297 ETH. One level-two entry adds 0.00495 ETH, taking total referral allocations to 0.03465 ETH.
Earlier roots have more available positions beneath them. Within a finite full tree, its 88,572 descendants would need additional later entrants to reproduce the root's ten complete levels.
The 49.26636 ETH figure is reached only when all 88,572 downstream positions are filled. Empty positions do not create referral allocations.
Seven percent of every paid entry enters the daily jackpot pool. Winner probability follows the snapshotted paid-network weight, while the immutable deployment wallet always has zero weight and cannot win.
Contract functions
join(inviteCode)Consumes one valid invitation code, registers one wallet for exactly 0.033 ETH, and allocates every wei.
paymentRouter.pay(paymentId)Completes a signed 0.034 ETH manual request atomically: 0.033 ETH enters UPONZI and 0.001 ETH goes to the fixed treasury.
claimRewardsFor(wallet)Lets anyone trigger a claim; 100% goes to the profile wallet as ETH, or WETH if that wallet rejects native ETH. The caller receives no fee.
processDownlineUpdates(steps)Permissionlessly completes any pending jackpot-weight checkpoints. Current production accounting is bounded to the public ten-level network.
requestJackpot()Uses the latest settled pool and ten-level network-weight checkpoint before requesting verified randomness.
selectAndAwardJackpotWinner()Uses the immutable snapshot and returned random word to credit one winner.
pause() / resume()Lets only the immutable owner stop or reopen new registrations. Existing settlement remains available.
configureUponziToken(token)One-time developer action that permanently locks the launched UPONZI token address.
configureBuybackBurnContract(module)One-time developer action that redirects future 7% allocations from the preparation wallet to a module permanently bound to this core.
releaseBuybackFunds(amount)Releases only tracked 7% token-preparation ETH to the current fixed recipient.
Verified deployment
After mainnet deployment, each published address becomes a direct explorer link. Verify the source, proxy implementation, ownership, events, and balances without trusting this frontend.
Each entry walks the stored inviter chain. The frontend cannot replace ancestors or submit a different payout list.
Unassigned referral amounts are separately counted before being credited to the fixed treasury.
Keepers trigger public actions. Chainlink VRF on Base supplies randomness and CCIP authenticates delivery to Robinhood Chain.
Anyone can execute a claim, but rewards can only reach the wallet recorded as their owner. A wallet that rejects native ETH receives the same amount as WETH. No admin can redirect it.
A plain ETH transfer cannot carry an invitation code. The backend signer creates the participant and code pair, then the contract locks that active request. A replacement cannot change a code while the original remains usable. Always verify the on-chain request before paying.