Blobule on Robinhood Chain
Uniswap v4 Hook Contract 0x730bc43601c92e49ac2b3575cedb8da34b9fa0cc on Robinhood Chain · Fee sharing · Verified contract
- Volume (24h)
- $0
- Value locked (TVL)
- <$0.01
- All-time volume
- $117
- Pools using this hook
- 1
- Swaps (24h)
- 0 (0 traders)
- Total swaps
- 6
What it does
Every swap in the canonical ETH/token pool pays a fixed toll of tollBps, taken from the ETH side: on ETH-in trades before the swap and on other trades after it, with the proceeds split into four keeper-controlled jars.
How it works step by step
- Charges a toll of tollBps (between 0.75% and 5%, fixed at deployment) on swaps in the single canonical pool that pairs native ETH with this token
- Takes the toll in ETH by minting ERC-6909 claims on the PoolManager via beforeSwap and afterSwap return deltas, so no token transfer is made
- Splits each toll into four accounting jars: 80% to the creator jar (income share), a creditBps portion of that creator share to the community jar, 10% to the shared jar, and the rounding remainder to the platform jar
- Lets only the keeper address of each jar call drain(), which burns the matching ERC-6909 claims and sends the ETH to that keeper
- Rejects any other pool or hook use via hatched and poolId checks, and blocks all liquidity-modification and donate callbacks with Unsupported reverts
- Fixes all keeper addresses and the supply of 1,000,000,000 tokens at construction and renounces ownership in the constructor
- Swap behaviour
- Swaps in the canonical ETH/token pool are taxed by tollBps. For ETH-in exact-input swaps the toll is removed from the input before the pool trades; for ETH-out exact-output swaps the pool outputs a grossed-up amount so the user receives the requested ETH after the toll; for token-in exact-output and token-out exact-input swaps the toll is taken from the ETH leg in afterSwap. Every trade in this pool pays the toll; no trade direction is exempt, and the toll is charged on the ETH side in all cases.
- Liquidity behaviour
- No liquidity callbacks. beforeAddLiquidity, afterAddLiquidity, beforeRemoveLiquidity, afterRemoveLiquidity, beforeDonate and afterDonate all revert with Unsupported, so liquidity can only be managed through the PoolManager by standard means if the hook permits it, which here it does not for this hook's callbacks.
- Fee behaviour
- The pool uses a static fee of 0 (enforced in beforeInitialize). The effective fee is the hook-level toll set by tollBps, taken as a return delta and accrued as ERC-6909 ETH claims. Accrued toll is split 80/20 creator/shared before the creator share is further split by creditBps into community and income portions, with rounding remainder to the platform jar.
- Owner & admin controls
- No owner or admin controls remain: ownership is renounced in the constructor and no function is gated by onlyOwner. Parameters tollBps, creditBps, metadataURI and the four keeper addresses are fixed at construction. The contract is not proxied in the source and has no pause or upgrade path. Each jar's keeper can drain only that jar's accrued balance.
Enabled Uniswap v4 callbacks
beforeInitialize, beforeSwap, afterSwap, beforeSwapReturnDelta, afterSwapReturnDelta
beforeInitialize restricts pool creation to the canonical ETH/token pool with fee 0 and spacing 1 and sets poolId. beforeSwap computes the toll for ETH-in exact-input swaps and returns it as a before-swap delta. afterSwap computes and settles tolls on the ETH leg for the remaining swap directions. beforeSwapReturnDelta and afterSwapReturnDelta allow these deltas to alter the pool's accounting.
Security & trust assessment
Risk level: medium (verified source, high confidence).
Who controls it: No admin key exists after construction. Each of the four keepers can only withdraw ETH from their own jar, and the jar balances are bounded by the toll accounting. A bug in _bank or the toll arithmetic would be permanent because no upgrade path exists.
Risk to user funds: Traders pay the toll on ETH legs and LPs' ETH in the pool is subject to return-delta accounting. The hook holds no token balances beyond ERC-6909 claims it mints for itself, and drain sends ETH only to the keeper addresses fixed at deployment.
Security findings
- [info] Swap-level toll on every canonical trade: Every swap in the canonical pool is taxed by tollBps between 0.75% and 5% of the ETH leg, which the deployer sets once and cannot change afterward.
- [medium] Return deltas let the hook take pool value: beforeSwapReturnDelta and afterSwapReturnDelta are enabled and the hook mints ERC-6909 claims for the toll, so the hook can take value from swap flows; the amount is bounded by _slice and _inflate with checks against int128 overflow.
- [low] Keeper addresses are immutable and drain is limited to each jar: drain() requires msg.sender to equal the stored keeper of the requested jar and the amount to be at most owed, so compromise of one keeper key exposes only that jar's accrued balance.
- [info] Unsupported callbacks revert: Liquidity add, remove and donate calls revert with Unsupported, so the pool's liquidity cannot be provided through the hook; LPs may face a pool that cannot use standard liquidity flows.
- [info] Pool bound to canonical key: beforeInitialize and _mustBeHome restrict hook use to one pool ID, so no other pool can use this hook.
Contract details
- Verified source
- Yes (Blobule)
- Compiler
- solc 0.8.26+commit.8a97fa7a
- Bytecode size
- 7,330 bytes
- Upgradeable proxy
- No
- Detected patterns
- erc20, moves-currency, ownable, return-delta, self-unlock
Pools using Blobule
- ETH / LTRACE (0.00% fee) — 24h volume $0, TVL <$0.01, 0 swaps today