SWEEP Docs

Overview

SWEEP is a Uniswap v4 hook token built around a reward radar that moves on every trade.

Each holder occupies a receiver sector on a virtual 360° field. The size of that sector depends on the holder's SWEEP balance. More SWEEP means wider receiver coverage.

Each swap moves the radar beam. When the beam lands inside a holder's receiver sector, that holder is credited a share of the fee generated by that event.

100% of protocol fees are routed to holder rewards in ETH.

There is no staking, no reward round, no manual sector placement, and no treasury allocation from trading fees.

Token Parameters

Token

SWEEP

Ticker

$SWEEP

Supply

555,000 SWEEP

Buy fee

2%

Sell fee

3%

Reward asset

ETH

Fee allocation

100% to holders

SWEEP has no fee split for:

• treasury
• team
• marketing
• buybacks
• protocol reserve

All protocol fees are used for holder rewards.

Supply and control

The entire 555,000 supply is minted once, in the token's constructor. There is no mint function anywhere, so the supply can never grow.

Both fee rates are constant in the hook, with no setter of any kind — they cannot be raised after launch. The hook has no owner, no admin, no pause and no rescue; the vault has none either, and the only way ETH leaves it is a holder claiming their own.

The token itself has one owner-only call, setHook, which binds the hook and the pool manager. It reverts on a second call, so the wiring is permanent — and ownership can be renounced afterwards.

Receiver Position

Every SWEEP holder is assigned a deterministic position on the radar. The holder does not choose this position manually.

The position is the wallet's address, hashed:

position = uint256(keccak256(abi.encode(holder))) % PRECISION_360;

The dial is measured in 360,000,000 units rather than 360 whole degrees, so a position resolves to roughly a millionth of a degree. The function is pure: it gives the same answer before the wallet holds a single token and the same answer forever after, and no storage write anywhere in the contract can set a position.

One wallet = one fixed radar position.

This prevents users from manually moving in front of the beam. A holder who wants a different position has only one option: use a different address — and that means moving the tokens, which resets the sector width along with it.

Receiver Width

A holder's SWEEP balance determines the width of their receiver sector. A larger balance creates wider coverage.

The contract stores a half-width — the arc reaches that far on each side of the holder's position, so the sector spans twice it:

halfWidth = K_WIDTH * sqrt(balance / 1e18);
sector    = 2 * halfWidth;

The curve uses diminishing returns. This means:

• more SWEEP always increases coverage
• larger balances continue to benefit
• coverage does not increase linearly forever

Two hard limits sit on top of the curve. A half-width can never exceed 30°, so no sector spans more than 60° — one sixth of the dial — however large the balance. And a balance below one whole SWEEP rounds to zero width and is simply not placed on the dial; the wallet re-enters the moment it crosses one token.

These are the exact values the deployed contract produces, at K_WIDTH = 24,000 over a dial of 360,000,000 units.

Buying SWEEP

When a wallet buys more SWEEP, its receiver sector expands automatically.

No staking transaction is required. No receiver activation is required.

The wallet balance itself controls receiver width.

Selling SWEEP

Selling reduces the wallet balance. Because receiver width depends on balance, the receiver automatically contracts.

Selling therefore reduces both token balance and radar coverage.

Beam Movement

The radar beam moves with trading activity. Each swap advances the beam to a new position.

Conceptually:

1. swap
2. beam moves
3. new beam position
4. active receivers detected
5. fee allocated

The beam moves only when a swap moves it. It does not drift on a timer between trades, and it does not advance by a fixed step: each swap jumps it to a new point derived from that swap. A quiet pool means a stationary beam.

The radar does not operate in rounds. There is no daily reset. There are no epochs.

The beam keeps moving for as long as the pool is traded.

Deterministic Movement

Beam movement is fully deterministic.

• No administrator decides where the beam moves.
• No off-chain operator chooses reward recipients.
• No randomness oracle is called.
• The next beam position is derived only from on-chain swap data.

The movement is a hash of the swap that caused it, folded together with the state it landed in:

movement = keccak256(
    previousBeam, fee, isBuy,
    delta0, delta1, sweepId,
    block.number, block.timestamp, block.prevrandao
) % PRECISION_360;

newBeam = (previousBeam + movement) % PRECISION_360;

Every input is something the chain already knows at the moment of the swap, so the resulting position can be recomputed and verified by anyone from the transaction itself.

Because the movement is a full-range hash rather than a small step, the beam does not creep predictably around the dial — a trader cannot time a buy to land it on their own sector.

Active Receivers

After the beam moves, the protocol checks which receiver sectors contain the new beam position.

The beam is a point on the dial, not an arc. A receiver is active when its own arc covers that point.

BEAM 128.42°

Only active receivers participate in the reward generated by that event.

The dial has no seam: a wallet sitting at 359.9° and a beam at 0.1° are 0.2° apart, not 359.8°. The contract always measures the shorter way round.

Finding them without a holder loop

The dial is divided into 64 buckets of 5.625° each, and every receiver is filed into the buckets its arc touches. Because an arc can never reach further than 30°, a swap only has to open the 13 buckets within that range of the beam — everything further away is mathematically incapable of covering it.

Each bucket holds at most 16 wallets, so one reward event examines at most 208 slots no matter how many holders exist. There is no loop over every holder anywhere in the swap path, and no input that can make the work unbounded.

When a bucket is full, a slot is priced by width: a wider arc displaces the narrowest one currently holding a slot. A displaced wallet keeps its balance and its position, and takes a slot again on its next balance change.

Overlapping Receivers

Receiver sectors can overlap. This is intentional.

If one receiver covers the beam, that receiver takes 100% of the reward for that event. If several overlap it, the reward is divided equally between them:

share = reward / activeReceivers;

The split is equal, not proportional to balance.

A wallet holding ten times more SWEEP than its neighbour does not take ten times the share of a crossing they both sit under — they take the same. Balance buys a wider arc, which means the beam finds you more often; it does not buy a larger cut of any single event.

Integer division leaves a remainder of at most one wei per receiver. It is not dropped: it rolls into a carry and is paid out with the next event, so the ledger stays exactly whole.

Holder Rewards

100% of protocol fees belong to the holder reward system.

Fee flow:

1. BUY / SELL
2. PROTOCOL FEE
3. ACTIVE RECEIVERS
4. REWARD ACCOUNTING
5. CLAIMABLE ETH

The reward asset is ETH, taken as ETH — nothing is swapped or sold to produce it. There is no treasury allocation from fees.

The hook forwards 100% of every fee to the vault in the same transaction and keeps nothing: it holds no ETH between transactions, cannot state a reward amount without paying the matching ETH, and cannot withdraw a single wei of what it credited. The vault address is fixed in the hook's constructor and immutable, so rewards cannot be redirected.

When the beam lands on empty dial

Sometimes the beam crosses a stretch of the circle nobody occupies. That fee is not refunded to the trader and not forwarded anywhere else — it waits in a carry and is added to the next event that does find a receiver.

Every wei of every fee ends up with holders.

Claiming Rewards

Rewards accumulate internally and are claimed later. No ETH is pushed to anyone during a swap:

pendingRewards[holder] += share;

The holder can then call, at any time:

claimRewards();

This keeps the swap path cheap and bounded, and it means a wallet that cannot receive ETH can never stall a distribution for everyone else.

The claim function takes no recipient parameter. It pays msg.sender and nobody else, so there is no function anywhere in the protocol that can direct one wallet's reward to another.

There is no vesting, no lockup, no minimum balance and no deadline. A reward credited to you stays yours even if your SWEEP balance later goes to zero.

Transfers

Receiver width is based on the current wallet balance. When SWEEP moves between wallets:

• Sender balance decreases → sender receiver contracts
• Receiver balance increases → receiver sector expands

Coverage is always tied to the wallet's current SWEEP balance. There is no transferable boost or separate staking position.

This happens inside the token's own transfer path, on every mint, burn and transfer — both sides are re-pointed automatically and nobody has to call anything. A sector can never be out of step with the balance behind it.

Rewards already credited are unaffected: sending your SWEEP away shrinks your arc, but the ETH you have already been allocated stays claimable.

No Staking

SWEEP does not require staking. Holding the token is enough to participate.

1. BUY SWEEP
2. HOLD SWEEP
3. RECEIVER EXISTS

There is no staking transaction, no activation, no lockup and no registration. The receiver follows the balance, and the balance is the only thing that decides it.

One threshold applies: a balance below a single whole SWEEP rounds to zero width and is not placed on the dial. The wallet is back on it the moment it crosses one token.

This keeps the utility directly connected to the token itself.

No Reward Rounds

SWEEP does not use round cycles — no ROUND #1, ROUND #2, ROUND #3.

There is no cycle reset. There is no fixed reward epoch. Each swap is simply another beam movement.

The radar continues indefinitely.

Why Hold More SWEEP

The token itself is the receiver.

More SWEEP means:

1. larger balance
2. wider receiver
3. greater radar coverage
4. more opportunities for beam contact

The utility is therefore directly tied to balance.

Holding more SWEEP does not guarantee a fixed reward amount, and it does not enlarge your cut of any single crossing — that is split equally among whoever is under the beam. What it buys is a wider arc, and therefore more crossings over time.

Balance buys frequency, not a bigger slice.

Diminishing returns and the 30° half-width ceiling mean coverage cannot be bought outright: even a wallet holding the entire 555,000 supply would occupy well under a sixth of the dial.

Full Protocol Flow