Roadmap and open questions
Status today
| Piece | State |
|---|---|
| Marketing site, docs | Built |
| Launch builder and launch page | Built. Token, locked pool, and optional vault registration, signed from the creator's wallet. Never run against the real network. |
| Vault: fee split, recipient, treasury, admin handover | Built, tested locally, not deployed. Rust and Anchor 1.2.1 in vault/. |
| Vault: renames that wait in public | Built, tested locally. Needs the vault deployed. |
| Vault: fee escrow for an X account, and permit-checked claims | Built, tested locally. |
X claim service and /claim page |
Built. 28 unit tests and 41 end-to-end checks with a stand-in login. Never run against the real X API: it needs X credentials. |
Fees page (/fees) |
Built. Collects fees in wallet mode and vault mode, and points X-account launches to the claim page. 79 checks. |
Manage page (/manage) |
Built. Queue, apply or cancel a rename, lower your share, change the payout wallet, rename instantly where allowed. Not tried with a real browser wallet. |
Token page (/token) and trading panel |
Built. Reads the chain and lists red flags first. Buys and sells from the pool. Scenarios passed on a local validator. |
| Creator first buy and early-buyer flag | Built, not yet run on a validator. An optional buy of up to 10 percent from the creator wallet inside the pool transaction (about 1,120 bytes), and a token page check for early buyers the creator funded. Checks for the first buy are in vault/tests-int/src/app-launch.ts. |
Crank bot (scripts/crank-bot.mts) |
Built. Cranks fees and applies due renames. Dry run unless given a key and --send. |
| Indexer | Not built. The pages read the chain directly. |
| Stock-token pair pool | Not built, on purpose (see Stock pairs). |
| Independent audit | Not done |
What the launch builder does without the vault
The first version skips the vault. The creator's wallet owns the pool position, which is permanently locked at creation (isLockLiquidity), so liquidity still cannot be removed. The creator claims all trading fees directly with claimPositionFee. That leaves out the protocol fee split, handle escrow and the 48 hour metadata delay, which all need the vault.
What was checked and what was not
Checked offline: the token transaction is about 600 bytes, the pool transaction about 1,050 and the vault hand-over 500 to 720 depending on the options, all under the 1,232 byte limit. The SDK's math agrees with the worked example (an older setting: 5 SOL start, 10,000x ceiling, buying out the whole supply takes exactly 500 SOL). At the site's default (20 SOL start, 1,000x) it takes about 632 SOL.
Checked on a local validator running the real Meteora and Metaplex programs (counts printed by each suite on 2026-10-16: Rust unit tests 16, vault suite 125, website-builder suite 31, fees page 79, claim service 49 unit tests and 41 end-to-end checks, token page 132 checks across nine scenarios; rerun commands are in vault/tests-int/README.md):
- A single-sided pool with a zero quote amount is accepted, with the production fee schedule.
- The fees a crank pays out match the SDK's own estimate exactly. The creator gets exactly the floor of the share, and the protocol takes the rounding remainder.
- Lowering the creator share changes the next split. Raising it fails. Only the creator can change their launch, and only the admin can change the treasury.
- Registering a position the vault does not hold, a position from a different pool, or the same launch twice all fail.
- A crank costs roughly 60k to 170k compute units, depending on how many token accounts it has to create.
Checked with the website's own code: vault/tests-int/run-app.sh runs src/lib/launch.ts, the same file the launch page uses, against the validator with the vault, Meteora and Metaplex metadata programs loaded. All three steps land (about 52k, 120k and 29k compute units). The supply is 1,000,000,000 with the mint authority revoked, the metadata is written, the position is permanently locked, the vault records an 80 percent creator share, and after a trade a crank pays the creator exactly 80 percent of the fees. 14 of 14 checks pass. The vault suite also checks each fix from the security review, including who can initialize the config, what registration accepts and refuses, and the admin handover.
Not checked: anything on mainnet. Wallet signing in a real browser wallet has never run, the vault is not deployed, and no independent review has happened. The first real launch is the test, so make it a small one.
What is left, in order
Everything that can be built and tested on a local network is built. What is left needs the outside world:
- A first small launch on the live network, with a real browser wallet. Every suite passes locally, but nothing has run against mainnet and no page has been used with a real wallet. Launch a tiny token, then try the fees, manage and token pages with that wallet. Devnet was skipped by choice.
- Independent audit and a multisig upgrade authority. The vault's upgrade key controls every launch's fee rights, and the claim signer's key controls every X-account share, so the key policy matters as much as the code. See
vault/DEPLOY.md. - Deploy the vault, initialize its config, and set
NEXT_PUBLIC_VAULT_PROGRAM_IDso the launch page offers the vault options. Run the crank bot on a schedule. - Switch on X claims, if the trust it needs is acceptable: create the X app, generate the claim signer key, and have the admin call
set_claim_signer. Setup steps are in X claims. - An indexer, if reading the chain directly from the browser proves too slow or gets blocked by public RPC limits.
- Staged public opening. Small caps and an allowlist first.
Open questions
| Question | Why it matters | How we answer it |
|---|---|---|
| Does mainnet behave like the local copy of Meteora's program? | The tests load a binary dumped from mainnet, but programs can be upgraded. | The first small mainnet launch. |
| Who holds DAMM v2's upgrade authority, and is it a multisig? | It decides whether the permanent lock could ever be removed. | solana program show cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG. |
| Does a quote-only fee mode work with a single-sided pool? | It would let creators earn SOL only. | A local test of that mode. |
| Which xStocks exist today, with what liquidity? | A stock pair feature needs a real list. | Query the xStocks listing and Jupiter quotes when building it. |
| Metaplex versus Token-2022 metadata | Wallet and DEX support differs. | Test both in common wallets. |
| Is Meteora's protocol fee on a customizable pool really 20 percent on mainnet? | The site tells creators Meteora keeps 20 percent of every trading fee, taken from its current source code. | Read pool_fees.protocol_fee_percent from the first live pool. |
| What do the three launch transactions really cost? | The launch page says "roughly 0.04 SOL", which is an estimate. | Measure on the first live launch and replace the estimate. |
Answered locally: a single-sided pool with a zero quote amount is accepted; a program-owned address can hold the position and claim after the lock; all three launch transactions fit the size limit.
Sources
- Meteora DAMM v2 documentation and program repository (instructions, fee scheduler, price range, permanent lock, program id).
- Solana Foundation case study on xStocks (launch date, issuer, non-US availability).
- Ignition's public site (the feature list this design responds to). Its own contracts and fee terms were not published there, so no claim is made about how it works internally.