Skip to main content
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
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

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.
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, 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.