Skip to content

Wallet Cap

No wallet can buy more than a set share of the supply while the launch guard lasts: what a creator sets, what counts and what it runs beside.

On this page

While a pool's launch guard lasts, no wallet can buy more than a set share of the token's supply. Wallet Cap is a Hook Block on Hookr's hook. The app offers it in the builder while the chain reads its core as admitted on Hookr's hook.

What you set

SettingWhat it takes
Cap per wallet0.1% to 10% of the token's supply, in 0.1% steps. 2% by default.
GuardAnti-Snipe's launch guard, at least 8 parent blocks. On a pool without a guard, adding Wallet Cap turns one on for 15 parent blocks, about 3 minutes.

The launch turns the share into an amount of tokens from the supply it reads: a new token's whole supply, or an existing token's total supply when the launch is built. The pool keeps that amount for good, and the cap ends when the guard ends.

What counts

  • Each buy during the guard counts the tokens it delivers, after Auto Burn, against the wallet that pays for it: the trader Hookr's router, a gasless swap or the Uniswap router names. A buy through a router that names no trader counts against the wallet that signed the transaction. Tokens a wallet receives from someone else's buy or by transfer do not count, so nobody can use up another wallet's cap.
  • The count is per launch. A launch is the token's pools bound in the same second, as one launch transaction binds them, and every pool of it takes the same cap, since a pool without it would be a way round it. A later launch of the same token counts from zero.
  • Selling frees no room, and neither the creator's dev buy inside the launch nor arb recapture counts. Every pool of a Wallet Cap launch takes arb recapture, or none does: on a pool without it, the arb recapture executor's legs would count against the trader whose swap set them off.
  • The cap limits each paying wallet, not each person. Contracts that each buy through Hookr's router count as wallets of their own, and wallets that buy through one shared relayer or bundler on a router that names no trader share that signer's cap.

What it runs beside

Wallet Cap runs on a core of its own: the whole-pot core with the cap added. Anti-Snipe, dynamic fees, Auto Burn, LP Rewards, the creator royalty, arb recapture and King of the Pool run on it as they do on the whole-pot core. A pool binds one core, so a Wallet Cap pool takes no Buy/Sell Block that refuses same-block round trips. Its core is admitted on Hookr's hook alone, so a launch on a hook of your own does not take it.

A Wallet Cap pool's prizes, rebates and royalties are credited on its core, so they are claimed there.

When a buy is refused

A buy that would take a wallet past its cap is refused with GuardWalletLimit(wallet, actual, limit), in the token's raw units. Before you sign, the trade dock shows what your wallet can still buy and says so when a buy would pass the cap.

For integrations

The pool's core has no view for a wallet's count. Read it from the core's storage with extsload(bytes32 slot), as on Uniswap v4's PoolManager. SLOT is 0x762913e4bc0f59f7b08c82f07586fa48932548ab5fab99e6db0b09765b4ff900, the core's erc7201:hookr.rules storage root.

// The pool's launch: the top 32 bits of the first word of the pool's binding.
uint32 launchedAt = uint32(uint256(core.extsload(keccak256(abi.encode(poolId, SLOT)))) >> 224);
// The wallet's count of the token in that launch.
bytes32 bySubject = keccak256(abi.encode(subject, uint256(SLOT) + 13));
bytes32 byLaunch = keccak256(abi.encode(uint256(launchedAt), bySubject));
uint256 bought = uint256(core.extsload(keccak256(abi.encode(wallet, byLaunch))));

The pool's cap, in the token's raw units, is the potMinBuyQuote field of its RulesConfig, and the cap less bought is what the wallet can still buy. The guard's end is its guardEndBlock, a parent block.