# Musebook fair launch

This work integrates a custom launch prototype into the selected `musebook-private` checkout. The `/fairlaunch/` page configures downloadable launch drafts and demonstrates opening allocations and holder weight. Custom launch and rewards program addresses are local source identifiers, not public deployment receipts. The existing `/launchpad/`, `/meteora/` and CLAWD desk products remain separate executable flows.

For the complete reader-facing explanation, see [A fair opening. A reason to stay.](/research/fairlaunch-agent-economy.md), rendered at `/fairlaunch/article/` and linked from `/docs/#fairlaunch`. Its PDF, Markdown, sanitized developer guides and publication checksums are generated by `web-react/scripts/build-fairlaunch-article.mjs`. The implementation verification baseline stays separate from the article publication artifacts.

The original `$LEGACY_FAIRLAUNCH_ROOT` directory was absent. The user subsequently supplied the actual reference implementation under `parallel/fairlaunch`. Its original source hashes and real AMM fixture hashes are recorded before integration. The hardened programs reuse its actual Rust core, while preserving authenticated administration, immutable supply, escrow accounting and funded reward roots. The running [integration ledger](/research/fairlaunch/integration-ledger.md) tracks source decisions, ABI changes and verification separately from the earlier baseline.

## What REA established

REA 6.4.0 was built directly from `$REA_ROOT` using its lockfile. Its shared CLI/MCP application workflows route to typed providers, with a separate evidence ledger and explicit resource ownership. We used its controlled browser capture, verified script export and static JavaScript analyzer. We did not register an MCP server or run its interactive setup.

The Pump.fun capture observed the public welcome screen, live coin listings and a `/holder-rewards` navigation link. Its script export retains original URL, transaction, digest and capture provenance. Three selected shipped JavaScript files were analyzed; 168 other inventoried files were outside semantic analysis. Some network content was unfinished or unavailable. These results establish visible features and shipped frontend structure, not unpublished on-chain behavior.

REA's native architecture schemas and offline ELF provider do not support Solana SBF. Rust import establishes source identity, not program semantics. Solana compilation and local validator execution provide the separate program verification boundary.

The complete capture and exported third-party scripts stay under ignored `artifacts/fairlaunch-2026-10-11/`. The reproducible requests and compact evidence index are in `audit/fairlaunch-2026-10-11` (`audit/fairlaunch-2026-10-11/`).

## Opening and curve

1. A program-upgrade authority initializes the administration account. Quote approval requires the admin signature. Admin replacement uses proposal and acceptance by the new key. Existing refund and reveal paths remain available during pause.
2. Creation initializes a mint and program-owned token and quote vaults. Supply is minted once, then mint and freeze authorities are revoked. Quote assets must be approved legacy SPL mints without freeze authority; Token-2022 and tokenized-stock quotes are excluded from this version.
3. One order PDA per launch/address escrows real quote tokens during the commit window. The commitment hashes a domain, launch, buyer, deposit, requested allocation and salt. Deposits are public, so commitment privacy does not hide deposited capital.
4. Reveal authenticates the commitment and limits each request to 3% of total supply. The launch creator cannot submit an opening order. After reveal ends, anyone can finalize and settle an order to its owner's fixed token accounts.
5. Every revealed request fills at the same fixed rational price. Oversubscription uses proportional integer allocation; rounding dust remains in reserves. Unspent and unrevealed deposits return to the order owner. Curve trading waits until all opening escrow has been settled; another caller can settle abandoned orders.
6. After every order is settled, a guard starts for at least 75 slots. Opening fills count toward the same cumulative 3% address cap used during that guard. One buy per address per slot and a configured slot-wide buy limit apply; the creator cannot buy during the guard. Delayed settlement cannot consume the guard before trading starts.
7. Constant-product curve trades use the supplied checked core and enforce slippage and reserve backing. The final buy consumes only the quote required to reach the fixed graduation threshold. Fees accrue as separate quote liabilities: 20% protocol, 30% creator, 50% holders, with rounding dust assigned to holders. These are shares of the 1% curve fee; no second fee is charged when splitting actual collected AMM earnings.

Transaction order does not change a revealed order's allocation. This is an address cap, not a person cap: splitting funds across wallets can obtain more allocations. Refundable nonreveals also create an option to withdraw from the opening. Neither mechanism warrants a promise of bundle elimination or Sybil resistance.

## Rewards and authority

```mermaid
flowchart LR
    W[Wallet-approved quote deposit] --> L[Launch escrow and curve]
    L --> H[Funded holder treasury]
    L --> C[Creator epoch and locked collateral]
    I[Auditable balance-event indexer] --> R[Admin-authenticated immutable root]
    H --> R
    R --> V[Proof-bound 180-day vesting]
    V --> O[Holder-owned quote account]
    C --> V
    C -->|creator exit| H
```

The v2 holder replay actually calls the supplied shared Rust accounting over explicitly supplied balance events. Added tokens warm up for 24 hours. Eligible balance earns the exact integral of a loyalty boost, from 1× to 2× over 90 days measured from uninterrupted holding. Reductions remove pending tokens first; reducing eligible balance proportionally forfeits points and resets its loyalty age. Zero-duration buy/sell activity earns zero. The earlier lot-based v1 indexer remains separately labeled. See [shared accounting](/research/fairlaunch/holder-accounting.md) for the precise policies and proof bridge. Generic SPL balances are not intercepted by the rewards program. A publisher must obtain complete finalized transfer history, aggregate token accounts by owner, exclude launch/AMM/creator vaults, and publish reproducible snapshots before claiming this reflects actual wallet holding.

The root publisher is trusted for allocation accuracy. The on-chain program enforces publisher identity, immutable funded epochs, program/epoch/mint/owner/amount-bound Merkle leaves, one receipt per owner, total reservation bounds, 180-day vesting and claimant-owned destinations. Holder epochs are namespaced to the rewards configuration; creator epochs are namespaced to the authentic launch, so a caller cannot occupy another launch's or publisher's announced epoch address. An invalid or incomplete root can misallocate funds or leave them inaccessible; funding bounds do not prove fair allocation. The indexer records the held mint separately from the payout mint and requires owner-aggregated, single-mint balance events; transfers between an owner's own token accounts do not reduce holdings.

Proportional sale/transfer forfeiture affects points before publication. Once a holder allocation is published and funded, later sales do not revoke that immutable tranche or stop its vesting. That stronger ongoing-holder policy would need on-chain transfer tracking or another explicitly trusted eligibility mechanism.

Creator rewards use real locked collateral. Registration and each partial withdrawal require the exact off-curve launch PDA signer. An authenticated monotonic counter measures creator escrow independently of curve reserves in the shared vault. At least 50% of the original creator allocation must remain locked. Withdrawing below that threshold after the minimum 30-day lock permanently stops all creator claims. Anyone can redirect every unpaid creator tranche into the holder treasury, including vested fees not yet claimed; already paid fees cannot be recovered. Future creator fee shares also go to holders. Standalone admin-attested collateral remains a separate external-launch mode. This tracks recorded escrow withdrawal, rather than undisclosed alternate wallets or a project-abandonment oracle.

Six months means exactly six 30-day periods: 180 days. Each funded fee tranche starts its own schedule. This explicit product rule replaces the supplied reference's earlier 182.625-day constant.

## Pool migration

Migration deposits must use real unencumbered reserves. With curve spot price `effective_quote / remaining_base`, the base deposit is `floor(real_quote * remaining_base / effective_quote)`. Virtual quote, opening refunds and fee liabilities cannot fund liquidity. Integer rounding and venue liquidity math must be checked against the actual pool after CPI; a transaction error rolls back staging and state changes.

The adapter crate encodes original calls to pinned public interfaces. It does not copy the AMM implementations. The launch selects a venue and network before migration. Program IDs, mint ordering, funding authority, config address/owner, fee budget, pool/vault/position PDAs, token programs and resulting state are validated.

**Raydium CPMM:** permissionless initialization uses a launch-program-derived pool signer, separate from the attacker-accessible canonical pool. The local test first creates the competing canonical pool, then migrates to the exclusive pool. LP supply must be zero after burning. The price check reads the actual initialized vaults and compares cross products against the final curve; the only allowed difference is the floor of one base token unit in the migration deposit. It does not use a hardcoded price or a percentage tolerance. Burning issued LP forfeits future LP fee rights. Retaining those rights would require a separately verified Burn & Earn/Fee Key integration or authorized creator-fee configuration.

**Meteora DAMM v2:** customizable initialization is permissionless, and permanently locked positions can retain fee claims. Its customizable pool address depends on the mint pair, so a holder can initialize it before late migration. Existing pools must be rejected, not adopted. Gated configs or creating the pool before base tokens circulate are separate approaches to improving migration liveness. A source-supported interface does not itself prove deployed binary parity or successful migration.

After graduation, splits apply to actual collected net venue fees. Meteora's program allocates a protocol portion before position earnings; the proposed 1% curve split cannot be promised as a 1% DAMM gross swap split.

## Current competitive comparison

The supplied comparison is outdated. Checked against primary sources on October 11, 2026:

| Feature | Current Pump interface | Musebook prototype |
| --- | --- | --- |
| Holder rewards | Holder-reward mode diverts creator fees to holders | Separate holder and creator allocations with funded vesting |
| Curve fees | Published SOL/USDC schedule: 1.25%, including 0.30% creator/holder | Proposed 1%, including 0.50% holder and 0.30% creator |
| Quote assets | Custom pairs, tokenized-stock pairs and eligible Pump coin quotes exist | Exact approved compatible SPL quotes; restricted to no freeze authority |
| Opening | Published continuous buy/sell interface | Uniform fixed-price commit/reveal with proportional fills and address caps |
| Creator incentives | Published fee collection/sharing interfaces | Minimum collateral lock; all unpaid creator fees forfeited on threshold breach |
| Post-graduation | PumpSwap fees depend on pair and market-cap tier | Raydium or Meteora, with venue-specific fee-rights requirements |

Primary references: [Pump holder rewards](https://github.com/pump-fun/pump-public-docs/blob/2293f9a66c654e9fe82dc5e8f4618538f24bb35f/docs/HOLDER_REWARDS_README.md), [Pump fees](https://pump.fun/docs/fees), [custom pairs](https://pump.fun/docs/custom-pairs), [Pump-coin quote interface](https://github.com/pump-fun/pump-public-docs/blob/2293f9a66c654e9fe82dc5e8f4618538f24bb35f/docs/instructions/CREATE_WITH_PUMP_COIN_QUOTE.md), [Raydium initialization](https://github.com/raydium-io/raydium-cp-swap/blob/b3187ae53a1b95a201f855a59024a12ca8f5b51a/programs/cp-swap/src/instructions/initialize.rs), [Raydium Burn & Earn](https://github.com/raydium-io/raydium-docs-v1/blob/main/user-flows/burn-and-earn.mdx), [Meteora customizable initialization](https://github.com/MeteoraAg/damm-v2/blob/a85c926607433f23f0ea60f4ca7b1ae92f4156cb/programs/cp-amm/src/instructions/initialize_pool/ix_initialize_customizable_pool.rs), [Meteora fee constants](https://github.com/MeteoraAg/damm-v2/blob/a85c926607433f23f0ea60f4ca7b1ae92f4156cb/programs/cp-amm/src/constants.rs).

## Running and verification

From `web-react`, run `npm run fairlaunch:check` for the combined local verification, or `npm run fairlaunch:quick` for host/client checks without the chain or browser suites. Full verification builds the canonical and supplied reference SBF outputs, regenerates source-derived instruction interfaces, executes the supplied Raydium LiteSVM lifecycle and hardened actual-sale creator test, runs the isolated real-venue validator, builds the app and runs frontend regression/browser checks. Logs, current source hashes and binary hashes are saved under `artifacts/fairlaunch-2026-10-11/integration/`.

This Mac's default Rust 1.96.1 is sufficient for the pinned Anchor programs, but the supplied locked LiteSVM 0.18/Agave 4.3 graph needs Rust 1.97.1 or newer. The runner uses the already installed `cargo +nightly` for that host test only, without installing or changing the default toolchain. Solana SBF compilation uses its own installed platform toolchain.

The browser verifier checks the built route on desktop/mobile, validates launch and agent draft boundaries, tests visible provider failures and verifies zero financial broadcasts. The agent panel links registered Core assets to the existing Genesis bonding-curve workflow and separately prepares undeployed custom associations. See [agent integration](/research/fairlaunch/agents.md) and the [shared holder replay](/research/fairlaunch/holder-accounting.md). The read-only `/api/fairlaunch/risk?mint=...` endpoint uses configured server-side providers, at most 40 physical requests including failover, and explicit partial/unknown coverage. No missing history produces a clean risk score.

Each program has an independent pinned Cargo manifest. Run `cargo test --locked --manifest-path programs/musebook-fairlaunch/Cargo.toml`, the matching holder-rewards and pool-adapters commands, and `cargo-build-sbf` for the two programs. Local validator verification requires their SBF outputs and explicitly owned disposable keys. No user wallet, mainnet broadcast or paid service is used.

See the verification report in the audit directory for checks actually completed and gaps still open. Public release requires source/bytecode provenance, complete finalized holder indexing, venue-specific fee-rights verification, adversarial program tests and an independent security review. No external pool-access request or production deployment is implied by this local integration.

## Licenses

REA is MIT. Raydium CPMM source is Apache-2.0; the existing Raydium JS SDK is GPL-3.0. Meteora's AMM source and its separately distributed MIT SDKs carry different licenses. This work uses original interface encoders and preserves those component boundaries; it does not reproduce the noncommercial AMM implementation. License names alone do not settle distribution obligations or CPI access rights.