# VestedBuy

> Vests what a buyer receives, at the pool, so a launch can sell without handing every buyer a same-block exit.

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

## How it works
A token that wants its early buyers to hold has two options today and both are bad. Vesting in the token contract binds everyone forever, including the market makers and the exchanges the project needs, and it is the reason so many tokens ship with transfer restrictions nobody can later remove. Or the project vests nothing and watches the first hour decide the price, because a buyer who can sell immediately is not a holder, they are a position with a very short horizon. The thing that actually wants vesting is not the token, it is the purchase. Buying through this pool during its vesting period delivers a share of the tokens now and the rest on a schedule, and the token itself is untouched: no transfer hooks, no allowlist, no permanent restriction, and every other venue trades it normally. A project can point its launch at this pool, get holders rather than flippers out of it, and still have a plain ERC-20. The buyer keeps `immediateBps` of the fill and the hook holds the rest as ERC-6909 claims, releasing them linearly from `cliff` to `cliff + duration`. Claims are paid as real tokens. Attribution needs no signature. `hookData` may name who the vested tokens belong to, and naming somebody else gives them your tokens, which is the only thing a forged attribution achieves. A buy that names nobody vests to the router it came through, which lets a launchpad run the vesting for its users. Exact-output buys are refused while vesting is live, and that is a security property rather than a limitation. Uniswap v4 lets a hook adjust only the swap's unspecified currency, which on an exact-output buy is the input, not the output. A hook that quietly declined to vest those would be a hook whose vesting is bypassed by changing one field, so it says no instead.

## Prior art
Vesting is normally a property of the token (transfer restrictions, locked allocations) or of a distribution contract that holds an allocation and releases it. Vesting the purchase at the venue, so the token stays a plain ERC-20 and only buys through this pool are vested, is the contribution here.

## Where it does not help
It binds one pool. The same token bought anywhere else is not vested, so this shapes a launch rather than enforcing a lockup, and a project that needs the second should vest in the token. The schedule also cannot be cancelled or clawed back by anybody, including the project, which is deliberate but means a buyer who loses their key loses the unvested remainder.

## Facts
Slug: vested-buy
Contract: VestedBuyHook
Callbacks: afterSwapReturnsDelta, afterSwap, afterInitialize
Parameters: buyIsZeroForOne (bool), immediateBps (uint16), cliff (uint32), duration (uint32), endsAt (uint64)
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.