The money that normally leaves comes back down.

The accounting is exact

When rent is charged it is divided immediately into three balances the hook keeps. Integer division leaves a remainder, and that remainder is not rounded away or left to accumulate somewhere — it is folded into the liquidity share, so the three balances always add up to precisely what was charged. Not approximately. Precisely.

Redemption is separate from charging, and deliberately so. Charging happens on the swap path and must stay cheap; paying out happens in its own transaction that anybody may send. Three permissionless calls do it: one donates the liquidity share, one pushes the staker share, one burns the burn share.

What can move, and how far

The three shares are the subject of a token vote and nothing else can change them. The vote cannot invent a fourth destination, cannot route anything to an address, and cannot escape two hard limits written into the hook: the liquidity share can never be set below 50 %, and the burn share can never be set above 20 %.

Whatever passes, the three shares always sum to the whole. There is no slice that is unaccounted for. How the vote works →

The largest share is the one most protocols get wrong, because paying liquidity providers usually means building a second contract they have to trust, discover, and claim from.

This does not do that. The share is donated to the pool through Uniswap v4's own donate path, which credits it to in-range liquidity exactly as if it had been a fee on a trade. If you are providing liquidity in range, it lands in your position. You do not have to know this page exists.

Two consequences worth being straight about. The donation is in $RENT, so it arrives on one side of the pair rather than as a balanced payout. And because a donation must land on liquidity that is currently in range, if there is none at that instant the share simply waits in the hook until there is — it is never lost, and the attempt never disturbs the pool.

Stake $RENT, receive a pro-rata share of the staker bucket as it arrives. Stake and reward are the same asset, so there is no second token, no wrapper, no receipt to look after and no exchange rate to reason about.

There is no lock-up. Unstake whenever you like; unstaking pays out whatever you have accrued in the same transaction. Rewards accrue only for the time you were actually staked — someone who stakes after a distribution does not receive any part of it.

The vault has no owner, no pause, no upgrade path and no withdrawal function for anybody else's balance. The only privileged caller is the hook, wired once at deployment, and the only thing it is able to do is add rewards.

The smallest share is the plainest. The hook burns $RENT out of its own balance. It cannot burn anyone else's — the token accepts a burn instruction from the hook and applies it only to what the hook already holds.

Supply therefore moves in one direction only. It is fixed at one billion at deployment, there is no mint function after that, and every burn is permanent.

An honest note on scale

How much rent gets charged depends entirely on what the fee-setting right turns out to be worth to the people bidding for it. That could be a lot or close to nothing, and no page can tell you which in advance. What the contract fixes is where it goes if it exists — not how much of it there will be.