What would have to be true before this held real money.

What runs today

• The unlock curve is a pure function in lib/vesting.ts. Tests cover the start, the cliff, the end, and the time on either side of each boundary.
• Supply buckets are integer basis points and must sum to 10,000. The interface asks for whole percents so that sum can be exact.
• Example projects and their sample events are fixtures. Event percents are computed from the same function, not typed in by hand.
• Launch drafts are stored in local storage after secret-looking values are stripped. There is no account, no wallet adapter, and no remote database.

The reference formula

Time is an integer millisecond timestamp. A month is 30 days. Let elapsed be the time since start, cliff the cliff length, and duration the full length. The unlocked share of the creator allocation, in basis points, is:

0                                      if elapsed < 0
0                                      if 0 ≤ elapsed < cliff
10_000                                 if elapsed ≥ duration
floor(elapsed × 10_000 / duration)     otherwise

At the cliff instant the linear amount accrued since the start unlocks at once. If the cliff equals the duration, the check for the end comes first, so the allocation stays locked until that instant and then unlocks in full. The unlocked share of supply is the creator allocation times that fraction, again rounded down. The locked remainder is whatever is left, so the two parts still add up to the creator allocation.

A Solana shape, not a program

A later version could put the creator allocation in escrow at launch instead of paying it to a hot wallet. A reviewed program would record the start, cliff, duration, beneficiary, and the set of disclosed wallets. The beneficiary could withdraw only the difference between unlocked(now) and the amount already released, using this same integer formula. Disclosed wallets would be a registry the team opts into, not a discovery of every holder.

Sale warnings would come from a separate indexer subscribed to those accounts. The indexer can notice an outbound movement. It cannot see a wallet that was never registered, a deal that never touches a disclosed account, or the intent behind a transfer. The program and the indexer are different jobs. Neither exists in this repository.

Before any real money

• An independent audit of the program, including the integer formula against the implementation.
• A written threat model for the indexer: missed events, reorgs, wrong mints, and disclosed-wallet impersonation.
• A clear statement, in the product, that undisclosed wallets are undetectable and that a schedule is not an audit.
• No safety score, no rug-proof claim, and no promise that a published vow will be kept by anything except the audited code.

On-chain enforcement and sale monitoring both require that audited program and that indexer. Until they exist, a page like this one can explain a schedule. It cannot hold funds.