THE 42069 PROTOCOL
ETH REFLECTIONS BY HOOK

00 ABSTRACT

42069 is a fixed-supply ERC-20 token with a paired Uniswap V4 hook contract. The hook intercepts every swap in the ETH/42069 pool, skims a percentage of the ETH leg, and immediately credits all 42069 holders pro rata to their balance. Holders accrue ETH passively and withdraw it via a single claim() call. The accounting is a one-line monotonic index updated in the same transaction as the swap.

01 THE PROBLEM

Reflection tokens have been around since 2021. The pattern works: tax every transfer, redistribute the tax to holders. Most implementations suffer from one or more of the following issues:

• Tax taken in the protocol token, then sold for ETH on the same pool. The protocol's own distributions cause sell pressure visible in the chart.
• Push distributions with hard-coded batch sizes that grief small holders or run out of gas.
• Reflections paid in more of the same token, diluting the holder's USD-denominated position rather than paying out an actually marketable asset.
• Per-transfer accounting that breaks compatibility with vanilla ERC-20 tooling.

42069 solves these by relocating the tax to the swap itself, paying out in ETH, and accruing rewards in a pull model with one monotonic index and one balance lookup per holder.

02 ARCHITECTURE

The protocol is three contracts:

1. Token42069. Vanilla ERC-20, plus reflection accounting, trading gate, and max-tx / max-wallet limits.
2. TetrisHook. Uniswap V4 hook that overrides the LP fee and takes a separate reflection fee in ETH on every swap.
3. HookForge. CREATE2 deployer with built-in salt miner so the hook lands at an address whose low bits match its required permission flags.

A fourth helper, PoolInit, initialises the V4 pool with the right key. Once the pool is open and LP is seeded, the commander calls openTrading() on the token and the system is live.

03 THE TOKEN

Token42069 implements the ERC-20 interface with one extension: every transfer accrues reflections for the sender and recipient before updating balances. A transfer is always a four-step internal operation.

1. Check the trading gate and the per-tx / per-wallet limits.
2. Accrue any pending ETH owed to sender and recipient using their balances before the move.
3. Move tokens.
4. Adjust the exempt-supply counter if either side is reward-exempt (for example, the pool).

Total supply is 420,690 * 10^18 base units. Supply is fixed forever: no burn, no mint, no rebase. The contract is non-upgradeable. handCommand() can renounce ownership by transferring the commander role to the burn address.

04 THE HOOK

TetrisHook declares four V4 permissions: beforeSwap, beforeSwapReturnDelta, afterSwap, and afterSwapReturnDelta. Combined flag bits are 0x00CC, so the hook's deployed address must satisfy addr & 0x3FFF == 0x00CC. HookForge mines a CREATE2 salt that places the address on the correct bits in the same transaction as deployment.

For buys (ETH input -> 42069 output) the hook acts in beforeSwap:

1. Compute fee = ethInput * reflectFeePips / 1_000_000.
2. Return a BeforeSwapDelta that takes fee ETH from the swap's specified currency.
3. poolManager.take(ETH, hook, fee) pulls native ETH to the hook.
4. Forward to the token via distributeRewards{value: fee}(), which bumps the reflection index.

For sells (42069 input -> ETH output) the hook waits for afterSwap, reads the actual ETH output from the BalanceDelta, takes its slice with a positive int128 return, and forwards the same way.

05 ACCOUNTING

The math is the standard reward-per-share pattern used in MasterChef-style staking, adapted to a non-staked supply.

eligibleSupply excludes balances held by addresses flagged isRewardExempt. That primarily means the PoolManager, the hook, the token itself, and any explicit burn addresses. This prevents the protocol from reflecting ETH onto its own contracts, which would lock the ETH irrevocably.

WHY THE INDEX IS MONOTONIC

Each transfer accrues pending rewards for both sender and recipient using their balances before the move. This guarantees that the running total of pending plus claimed equals the total reflected ETH (modulo integer rounding), regardless of transfer pattern.

06 TOKENOMICS

07 LIMITS

Per-transaction and per-wallet limits are enforced on every transfer and transferFrom, regardless of the trading gate state. They protect early holders from whale concentration during price discovery.

The commander can raise limits via setLimits(maxTx, maxWallet) with floors of 0.1% (tx) and 0.5% (wallet). removeLimits() sets both to total supply, effectively disabling the checks. Both calls are one-way from the caller's perspective: nothing prevents the commander from raising again later, but limits can never be set below the floors.

08 TRADING GATE

Before openTrading() is called, only addresses on the isLimitExempt whitelist can move tokens. This includes the deployer, the token contract itself, and any addresses explicitly whitelisted via setLimitExempt. In practice that means the Uniswap V4 PoolManager, PositionManager, Universal Router, Permit2, and the hook contract.

Once trading opens, the gate is permanently lifted. There is no haltTrading(). Limits remain in effect until removed.

09 ADMIN SURFACE