> ## Documentation Index
> Fetch the complete documentation index at: https://docs.basestonk.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Dev-buy vesting

> Lock the dev buy in a vault whose schedule is published on-chain in the launch transaction itself.

A V6 launch can route the creator's dev buy into a **vesting vault**
instead of their wallet: a per-launch contract that releases the tokens
linearly over 7, 30, 90 or 365 days, with an optional cliff before
anything unlocks at all.

The point is not the lock - it is the **disclosure**. The launcher emits

```solidity theme={null}
VaultCreated(token, vault, beneficiary, vestCliff, vestDuration)
```

in the launch transaction itself, so the schedule is public from the
block the token exists. An indexer reading launches cannot miss it, and a
buyer reading the token page sees exactly what the creator locked and
until when, before deciding anything.

## The honest trade

<Warning>
  A vested dev buy is **uncapped by design**. The 10% dev-buy cap applies
  only to the unvested path - tokens paid straight to the creator's
  wallet. Choose a lock and the whole buy, whatever its size, routes into
  the vault. The cap protected buyers from an undisclosed large position;
  the vault replaces that protection with a disclosed one: the size and
  the schedule are on-chain in the launch transaction, and the schedule
  can never be shortened.
</Warning>

A vested launch is not automatically safer than a capped one - it is
differently safe. The creator may hold more than 10%, but every token of
it is time-locked on a schedule the chain announced at birth, and the
launcher refuses a vesting request without a dev buy to vest
(`VestRequiresDevBuy`).

## How the vault behaves

One vault per launch, created by the launcher, findable by anyone through
the factory's `vaultOf(token)`. The contract enforces:

* **Linear release.** Nothing before the cliff; after it, tokens vest
  continuously from the schedule's start - launch time, for the dev buy -
  and `release()`, callable by anyone, sends whatever has vested to the
  beneficiary.
* **A 7-day floor.** The shortest schedule the contract accepts is 7
  days; the cliff can never exceed the duration.
* **Extend, never shorten.** The beneficiary can lengthen a schedule's
  cliff or duration; any change that would shorten one reverts.
* **Add, never subtract.** The beneficiary can lock more tokens under new
  schedules (up to 32 per vault). Each addition is its own on-chain
  event.
* **The seat can move.** The beneficiary can transfer the vault to
  another address - a project outliving its founding wallet.

## Dividends while locked

Locked tokens are still held tokens, so a vault on a dividend-paying
launch **accrues holder rewards** like any other holder. The beneficiary
can pull the vault's accrual from the distributor and claim it out,
per asset - the locked principal itself never moves early.

Two ways that stream ends, both one-way:

* **`renounceAccrual`** - the beneficiary gives the locked supply's
  dividend claim to the other holders, forever. It cannot be restored,
  not even by the platform: the distributor refuses to un-renounce a
  renounced claim.
* **Takeover.** If the community
  [takes over the token](/cto), the takeover transaction calls the
  vault's `renounceOnTakeover` - a departed founder's locked supply
  stops earning the moment the seat moves. The tokens themselves remain
  the beneficiary's and keep vesting on their schedule; only the
  dividend stream ends.

## Reading a vault

Everything above is public state: `schedules()` lists every schedule's
total, released amount, start, cliff and duration; `releasable()` is what
`release()` would send right now; `accrualRenounced` says whether the
dividend stream is gone. The factory's `vaultOf(token)` answers whether a
token has a vault at all - `address(0)` means the dev buy was not vested.