Immutable core
Cannot be upgraded
- 0.033 ETH entry amount
- 81 / 7 / 7 / 5 allocation
- Three direct members and ten reward levels
- Participant claims and daily jackpot pool
- Fixed treasury and one-time UPONZI token
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
The proxy is fixed in the core, but its execution logic can be upgraded only after the replacement has been public on-chain for 48 hours. This allows future router, liquidity, or ecosystem 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(inviter)Registers one paid 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; payout always goes to the profile wallet as ETH, or WETH if that wallet rejects native ETH.
processDownlineUpdates(steps)Permissionlessly completes all-depth jackpot-weight updates.
requestJackpot()Uses the latest fully settled pool and 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 treasury action that permanently locks the launched UPONZI token.
releaseBuybackFunds(amount)Releases only tracked 7% buyback ETH, and only to the fixed module proxy.
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 sign an inviter. The backend signer creates the participant and inviter pair, then the contract locks that active request. A replacement cannot redirect an inviter that still has room; if all three slots fill before payment, a later request may use another valid inviter. Always verify the on-chain request before paying.