# EpochRebalance

> An index whose whole future is fixed before anybody deposits: the pool's target allocation glides along a schedule written at deployment, and nobody, including the deployer, can change it afterwards.

A production Uniswap v4 hook. Source: https://github.com/nirholas/epoch-rebalance. Part of the HookForge catalogue: https://hookforge.pages.dev

## How it works
A weighted pool is already an index fund. Holding `x^w * y^(1-w)` constant keeps the value split at `w` to `1-w` without anybody trading, because arbitrageurs restore the ratio for free every time the price moves. That result is Balancer's and it is why weighted pools are described as self-rebalancing. What a real index also needs is reconstitution: the target itself changes. Balancer does this with an owner call that starts a gradual weight update, and that is the part worth improving on, for two reasons. The first is trust. A provider deposits into a 60/40 pool and the owner can make it 20/80 next week. Whatever the governance around that key, the provider's exposure is not theirs to control, and the pool's terms are a promise rather than a property. The second is the rebalance itself. A weight change is a trade the pool must do, and if it happens as one step the whole trade is available at one price in one block, which is the most arbitrageable shape a rebalance can have. Every index that reconstitutes on a known date pays for this, and it has a name: index front-running. This hook fixes both by fixing the schedule. Weight checkpoints are set at construction and interpolated linearly between, so the pool's allocation on any future date is computable by anyone from the moment it exists. A provider knows what they are joining for the whole life of the pool. And because the weight moves continuously rather than in a step, the rebalancing flow is spread across the glide instead of concentrated into one block: there is no single moment worth racing to, because at every moment only an instant's worth of the trade is available. The same mechanism is a liquidity bootstrapping pool when the schedule is two points and the first weight is lopsided, so this covers that case without a separate contract.

## Prior art
Weighted pools as self-rebalancing indices are Balancer's, as are gradual weight updates, which are triggered by an owner. Liquidity bootstrapping pools are the two-point case. Making the entire weight schedule immutable and set before the first deposit, so the pool's future allocation is a property a provider can verify rather than a promise a key holder can revise, is the contribution here, along with the observation that a continuous glide removes the single arbitrageable print a stepped reconstitution creates.

## Where it does not help
The schedule cannot respond to anything. An index that needs to react to a delisting, a merger or a depeg cannot be expressed here, and pretending otherwise by picking a schedule that happens to look right is worse than using a pool with a keeper. The glide also does not eliminate rebalancing cost, it spreads it: the pool still trades into the new weight and still pays for that, it simply does not hand the whole trade to one participant in one block.

## Facts
Slug: epoch-rebalance
Contract: EpochRebalanceHook
Callbacks: none
Parameters: none
Dynamic fee required: no

## Caveats
- Unaudited.
- A deployment with status "deterministic" is a mined CREATE2 address with no code at it yet. Never present one as live.