Pick rules, set numbers, launch. One on-chain engine enforces the stack on every transfer — buy, sell, wallet-to-wallet — until the curve graduates and the token trades free.
Pick a name and a ticker.
One tap picks its rules — who can buy, when holders can sell, how much anyone can hold.
About 0.07 SOL total, paid from your wallet one step at a time, below.
One small form. Everything else — the knobs, the fine print, the raw spec — is tucked below for when you want it. Only rules the engine actually implements are offered — the launcher refuses anything else rather than dropping it quietly.
Agent branch — the AgentOnly defaults are preselected: an agent gate (Agent-Only, rule 3 — or the Ecosystem Gate, rule 17, whose family picker defaults to Muse), Max Wallet at 5% (500 bps), and holder fees on. Every default is overridable below.
Members-only warning: on the launch curve itself, buys of a gated token are refused in this version — gated tokens are handed out through surfaces that check the gate first, like the agent skill's send.
When the phase ends, the rules switch off and the token moves to a regular pool and trades freely. Any exact number works — use the field at the top of this section.
Graduating moves the token to a regular pool where anything can trade it — and the rules switch off for good. Keeping the rules forever means the token never leaves this curve: the rules keep enforcing on every transfer, and only hook-aware doors can ever trade it. The third way graduates the token onto our own house venue at its own threshold: the rules stay on, the curve stays as the legacy door, and trading doors default to the house pool.
Agent-held and holder-vote authority live in Advanced.
Every rule the engine implements, every number exposed. The presets and the sentence box write into this same form — one spec, one source of truth — and node launch.mjs spec.json --dry-run consumes exactly what it emits.
Transfers out are vetoed while price ≥ the holder's on-chain entry basis. The first dip below basis latches the holder unlocked forever — sell later at any price, even a profit. Basis blends on buys, ratchets down on rebuys.
Use it when… you want a token holders can't dump into strength — exits unlock only after a dip under the holder's own entry, so the first exit is always at a loss.
Example: basis 0.0020 SOL → price 0.0026: sell vetoed; dip to 0.0018 latches you — from then on you can sell at any price, even 0.0030.
GRADUATED mode (the LATCH token's form, and the pairing Escrow Split is proven with) earns a sellable fraction by time held, accelerated by dips, with the latch paying 100% at the crossing. Its sub-parameters (EMA half-life, crank band, base fraction, vesting ramp, dip multiplier) stay spec-JSON fields — selecting the mode here applies the engine defaults for them.
The HARVEST split: part of every buy escrows at the entry and resolves on exit — a dip below entry refunds 96/2/2 (seller / pool depth / treasury), no dip forfeits the resolved share to pool depth. Venue-side on Solana: the split lives in the house venue's swap, not in the engine, so this rule requires graduation "house" (selecting it forces that below) and Basis Latch — escrow resolution IS the latch's dip logic.
House venue only: the split applies to house-venue trades after activation; curve trades are unsplit, and escrow resolves only on house-venue sells. The split share is the knob below (splitBps in the spec; launch.mjs validates it by name).
Only wallets with an active Registry record may receive the token — buys and sends alike. Registration is one signed transaction; agents self-register through the skill.
Use it when… the token is members-only — the guest list is the Registry, and registration is one signed transaction.
Example: an unregistered wallet's AGTR buy reverted NotRegistered and it received 0; after registering (≈0.0012 SOL) and syncing, the same buy landed.
Constrain where the token may move: only wallet-to-wallet, or only on the venue.
Use it when… you want to force all movement through the market (no-p2p — no side deals, every transfer is a trade), or the mirror image: a pure hand-to-hand social token that never trades on its curve (p2p-only).
Example: no-p2p: sending 1,000 tokens to a friend's wallet is vetoed; selling the same 1,000 on the curve passes.
Receiving requires holding at least a set amount of a named gate token, checked at transfer time.
Use it when… receiving should require skin in another game — only holders of your first token can receive the sequel.
Example: gate minimum 1,000: a wallet holding 999 cannot receive; at 1,000 it can. In v1, curve buys fail closed — distribution runs through surfaces that sync first, like the skill's send.
No wallet may receive past a cap share of total supply. Pool and distributor accounts are exempt by launch config.
Use it when… you want anti-whale fairness — no single wallet can corner more than a set slice of supply at receive time.
Example: cap 500 bps on a 1B supply → no wallet may receive past 50,000,000 tokens; a buy that would cross the cap is vetoed outright, not partially filled.
Buys (receives from a venue) are allowed only when the calling venue is one named app or venue in the config — the FOMO-only pattern. Wallet-to-wallet sends are governed by the P2P Toggle (rule 7).
New in engine v4: implemented in the engine and selectable here. Name one or two app program ids below — at least one is required, and the zero key is refused. Each named app must also sit in the token's venue allowlist, or caller validation rejects its trades before this rule is even consulted; the launcher writes the DBC program as the venue, so list it as an app if plain curve trades should pass the gate.
Explicit lists decide who may receive: an allowlist of pre-approved token accounts, or a sealed blocklist of wallets that can never receive.
New in engine v4: implemented in the engine and selectable here. The knob below sets which lists run (mode in the spec). The lists themselves are not launch parameters — they live in their own per-token accounts and are written by the config authority after launch.
Anti-dump memory: selling a large share of a bag within the window marks the wallet — for a configured duration its venue buys are banned outright, or capped to a trickle. Repeat offenses escalate. Selling is never blocked; the grudge prices the return.
New in engine v4: implemented in the engine and selectable here. Every number the encoder accepts is a knob below. A 0 in a duration field selects the engine default (24h window, 24h base penalty, escalation cap 4); cap mode requires a buy-cap amount.
Transfers are allowed only inside configured clock windows — venue trades and wallet-to-wallet sends alike.
New in engine v4: implemented in the engine and selectable here. Set the fixed UTC offset, the days, and the daily window below. The offset is a fixed number of seconds — it cannot follow daylight saving. The window is [start, end) in local time and cannot cross midnight; the defaults are the reference fixture (Mon–Fri, 09:00–17:00 at UTC−5).
Received tokens unlock on a per-wallet schedule (linear or cliff): transfers out are vetoed for the locked fraction; the unlocked fraction moves freely.
New in engine v4: implemented in the engine and selectable here. Set the mode and at least one leg below — a per-holder hold period counted from each position's anchor, and/or one global release time. A vesting clock with neither leg never unlocks, so the launcher refuses it at spec time (here and in launch.mjs).
The largest holder is named King and receives the config's tithe share while reigning; losing the top spot moves the stream automatically.
New in engine v4: implemented in the engine and selectable here. The knob below is the tithe share (titheBps in the spec) paid to the reigning king at each settlement; 0 keeps the rule tracking-only. The king leg pays only when the token has settlements — holder fees on.
The token's fee beneficiary is read at settlement from a Crown PDA. Anyone can challenge for the seat with a bonded SOL stake-vote (72h window, 24h timelock, 7-day minimum reign, 20% slash on the losing side); win, and the fee stream pays the new beneficiary from the next settlement. Token, pool and rules never change — only who gets paid.
New in the Phase B settlement build: implemented and selectable here. The knob below is the crown share (crownBps in the spec; launch.mjs validates it by name). The crown pays only when the token has settlements — holder fees on — and after the token's one-time Crown Init; until then the leg skips and its share folds to holders.
A fixed share of the fee stream pays whoever holds a designated seat NFT at settlement time. The seat trades freely; the stream follows the NFT, never a hardcoded wallet.
New in the Phase B settlement build: implemented and selectable here. Name the seat NFT's mint and set the tithe share below (seatMint and titheBps in the spec; launch.mjs validates both by name). The tithe pays only when the token has settlements — holder fees on.
The mint-wide transfer-fee rate starts high and decays linearly to a floor over a set period, driven by a permissionless crank that can never raise it. It rides the Transfer Fee extension, so it keeps working after graduation, when the hook is gone. Stated honestly: the fee rate is mint-wide on Solana, so the decay follows the token's age — a per-holder decay is not possible here.
Status — program live, not launchable through this composer yet: the FeeSchedule program is deployed on mainnet and its InitSchedule fails closed on any mint without a Transfer Fee extension — and DBC-launched mints cannot carry one, so a token launched here could never initialize its schedule. A direct fee-extension mint path is pending; this rule stays disabled until it ships. (launch.mjs rejects rule 14 at spec time too — a hand-written spec carrying it fails validation before anything is sent.)
A permissionless crank watches the SOL curve fees accruing at the token's fee claimer; past a threshold it claims them, keeps a small caller cut, buys the token on its own curve with the rest, and burns what it bought — total supply drops by the bought amount. It can be combined with holder-fee routing: no check in the launcher, the engine, or the Distributor forbids the combination. The two are separate paths over the same accrued fees — holder fees are claimed at the fee claimer, converted, and settled to holders through the Distributor, while the buyback crank claims at the fee claimer and spends what it claimed on the buy-and-burn — so which path claims a given accrual is an operational choice, not a code restriction.
New in the Phase B settlement build: implemented and selectable here. The threshold and caller cut are the knobs below (thresholdSol and callerCutBps in the spec; launch.mjs validates them by name). One operational fact: only the fee claimer of record can sign the fee claim, so a rule-16 token is crank-operated in practice when it was launched with its fee claimer set to the crank wallet.
Only wallets whose Registry registration carries an attested tag for the chosen ecosystem may receive. The gate proves a wallet was created through that platform's flow and attested by that platform's attester key — it does not prove what software operates the wallet day-to-day.
Use it when… the token belongs to one ecosystem's wallets — Muse, FOMO, Claude, or Grok — and receiving should require that ecosystem's attestation.
Today only Muse is attestable — its attester is the one configured. The other ecosystem presets (2–16) are unset, so no other ecosystem can attest a wallet yet.
One catalog rule cannot live in the engine: Escrow Split (rule 2) — on Solana the split belongs to the swap venue, not the transfer hook. It is built, venue-side in the house venue's swap program, and selectable above with its house-venue-only label — and the house venue is LIVE on mainnet (HouseSwap deployed 2026-10-20), so rule 2 and the "house" graduation are open. Every other catalog rule is implemented in the engine and selectable above.
The creator fee is the launch curve's trading fee — 100 bps = 1% of every trade (allowed range 25–9900 bps, the venue's own bounds). It accrues to the fee claimer and goes where the destination above points it: kept by the creator, or routed to holders through the Distributor. Set once at launch, inside the curve config; the transfer hook never skims anything.
{}
The same sequence and the same instructions as node launch.mjs spec.json — built in this page by the vendored launcher bundle (the real Meteora DBC SDK + Solana web3.js + the SPL token library, bundled into one self-hosted file, launch.bundle.js — no CDN, no third-party scripts) and signed by your wallet, one transaction per step. Your wallet pays, becomes the fee claimer, and holds the rule authority unless the spec is Locked. Two extra keys are generated in your browser for the launch itself — the DBC config account and the mint; each signs only its own creation step and is powerless afterwards. The in-progress session is kept in this browser's local storage so an interrupted launch can resume where it stopped; discard it when you're done.
Paste a launch record (written by launch.mjs at launch) to see the token's rules and addresses. Live balances come from node hook.mjs status; a record's snapshot block, when present, renders here directly.