CookLabON-CHAIN CULTURELaunch token
PROTOCOL ONLINEONE PROGRAM1B FIXED SUPPLYTWO-PHASE FEESTELEGRAM NATIVESOLANA SPEED PROTOCOL ONLINEONE PROGRAM1B FIXED SUPPLYTWO-PHASE FEESTELEGRAM NATIVESOLANA SPEED
WhitepaperProtocolProtocol design
08 / 21
Protocol

Protocol design

Canonical CookLab whitepaperProduct & protocol specification · Version 3.0
PROGRAMCURVEFEESVESTPOLICY

CookLab is governed by one canonical Solana program. The implemented state machine launches tokens, executes curve trades, settles creator and protocol fees, releases vested creator allocations, activates native permanent liquidity, and enforces atomic graduation postconditions. Referral payout remains gated work.

InitializeCreates global protocol configuration and safety controls
LaunchAllocates fixed supply, initializes market state, and revokes mint authorities
TradeExecutes deterministic buys and sells against canonical reserve state
SettleRoutes creator and protocol fees atomically
VestReleases only the creator allocation unlocked by time
GraduateAtomic native-pool activation, overflow swap, burn, and vest activation
DEEP DIVE

One program does not mean one undifferentiated instruction. CookLab is a single security boundary containing specialized state transitions whose shared invariants can be evaluated consistently.

01

Core accounts

Global configuration defines protocol-wide authorities and fee destinations. Each market records its mint, creator, reserve, tokens sold, lifecycle status, vesting state, and the parameters needed to reproduce settlement outcomes.

  • Deterministic program-derived addresses
  • Explicit account ownership checks
  • Signer and authority validation
  • Canonical clock for time-based release
02

Protocol invariants

A valid transition preserves total supply, prevents unauthorized minting, bounds arithmetic, respects slippage, routes fees exactly once, and cannot release more tokens than have vested.

  • Checked integer arithmetic
  • No floating-point state transitions
  • Atomic failure on invalid accounts
  • Event emission for indexable outcomes
03

Administrative surface

Administrative powers should be narrow, observable, and incapable of rewriting user balances. Emergency pause exists to stop affected activity, not to confiscate assets or create supply.

  • Single canonical program identity
  • Visible configuration changes
  • Scoped pause behavior
  • Production authority protected by multisignature controls