MOLT-1

01Abstract

MOLT-1 describes a fungible SPL token whose Metaplex metadata stays writable for its whole life, with the launchpad as the only update authority. A rewrite of that metadata is called a molt. A molt can be requested by the token's creator, committed in advance as a schedule, or produced automatically by a keeper that follows the market.

Nothing about ownership is touched by a molt. Holders keep the same token in the same account; their wallet simply shows a new name and image the next time it reads the metadata.

02Motivation

On most launchpads a token's identity is frozen the moment it is minted. If the meme fades, the only way forward is a new token, a new pool and a migration that splits the community. MOLT-1 separates the two layers that are usually welded together:

• The asset — mint, supply, balances, liquidity. Permanent.
• The skin — name, ticker, image, description. Replaceable.

A token can follow the culture instead of being left behind by it, and the community that holds it never has to move.

03Terminology

04The molting token

4.1 Mint and supply

A MOLT-1 token is a classic SPL Token mint — not Token-2022 — with 6 decimals and a fixed supply of 1,000,000,000. The mint authority is revoked in the hatch transaction, so supply can never grow.

4.2 Metadata account

Metadata is created through Metaplex Token Metadata with is_mutable = true and the launchpad as update authority. The launchpad never hands that authority to anyone else and never flips mutability off.

If a token's metadata ends up immutable, or its update authority is not the launchpad, the token is marked dormant and the keeper skips it forever.

4.3 Skin limits

4.4 Off-chain document

The URI points to a standard Metaplex JSON document. MOLT-1 adds two attributes so explorers and marketplaces can show that the token molts:

{
  "name": "Nymph",
  "symbol": "NYMPH",
  "image": "ipfs://…",
  "description": "…",
  "attributes": [
    { "trait_type": "Molts", "value": 2 },
    { "trait_type": "Mode",  "value": "scheduled" }
  ]
}

05Molts

5.1 The transaction

A molt is exactly one Solana transaction with two instructions:

1. Metaplex UpdateMetadataAccountV2 (discriminator 15) writing the new name, symbol and URI.
2. A memo of the form molt:shed:<instar>.

The launchpad signs and pays the fee. Holders sign nothing.

5.2 Invariants

A molt never changes:

• the mint address, supply or decimals;
• any balance or token account;
• the bonding curve or graduated pool;
• the update authority or the mutable flag;
• royalties, creators or collection fields.

5.3 Instars

Every molt increments the instar by exactly one. The full history of skins is append-only and public: each one is anchored by its memo on-chain, so anyone can rebuild a token's past from the chain alone.

06Molt modes

The creator picks a mode at hatch. It decides who chooses the next skin and when.

Manual

Only the wallet that hatched the token can request a molt. The request is a signed message, valid for 5 minutes and usable once. Signing is free; the launchpad submits and pays for the transaction, so a token can molt by hand at most once a minute.

Scheduled

The creator commits up to 4 future skins at hatch, each with an offset in hours after launch. Offsets must strictly increase and stay within 720 hours (30 days). Upcoming skins stay hidden until they are applied, and the plan cannot be edited afterwards.

Auto · trending

Each keeper round, the token takes on the name, ticker and image of a Solana memecoin trending at that moment. Trending data comes from Birdeye, with DexScreener as fallback. The token never holds, buys or trades the coin it mirrors — it only borrows the look.

07Creator authorization

Creator actions are authorized with an Ed25519 signature over a human-readable message — not a transaction, so nothing can be moved by signing it. The server:

1. rebuilds the exact message from the request fields;
2. checks that the issued timestamp is within the last 5 minutes;
3. verifies the signature against the wallet that hatched the token, and rejects a signature it has already seen.

# example message — field order and spacing are exact
Molt · request a molt
mint: <mint address>
name: Pupa
symbol: PUPA
image: ipfs://<cid>
description: -
issued: 2026-10-23T14:02:11.000Z

An empty description is written as -. To keep the current picture, image is its ipfs:// address. To change it, the new file travels inside the same request and image is sha256:<hex> of that file — the server checks the hash and pins the file only after the signature, the cooldown and the lease have passed. The metadata URI is not part of the message: the server pins the JSON and only then knows its address.

08The keeper

The keeper is the launchpad service that turns schedules and trends into molts. It runs two loops:

• Schedule loop — every 30 seconds, applies any scheduled skin that has come due.
• Trend loop — every KEEPER_INTERVAL_MIN minutes (30 by default), molts every auto token.

Trend assignments rotate each round, and a token is never handed the coin it is already mirroring.

09Concurrency and safety

Every molt — manual, scheduled or auto — goes through a single code path that first takes a lease on the token: a conditional write that only one worker can win. Leases expire after 3 minutes.

• If the on-chain transaction fails, the lease is released and the token keeps its current skin.
• If the trending sources are down, the keeper skips that round rather than guessing.

10Launch lifecycle

1. Design — pick the first skin, socials and mode.
2. Pin — image and metadata are pinned to IPFS.
3. Hatch — one transaction creates the mint, metadata and bonding-curve pool, with an optional first buy by the creator. A fresh mint key signs it once and is discarded — after the pool exists it controls nothing.
4. Verify — the server simulates the transaction before your wallet is asked to sign, and after it lands checks the pool, the creator and the metadata authority on-chain.
5. Live — the token trades on its curve and molts by its mode.
6. Graduate — liquidity migrates to a DAMM v2 pool.

11Market structure

12Trust model

Holding the update authority gives the launchpad exactly one power: rewriting the skin. Everything that touches value is out of reach.

13Integrating

13.1 Detecting MOLT-1 tokens

A token is MOLT-1 when all three hold:

• its metadata account is mutable;
• its update authority is the Molt launchpad;
• its hatch transaction carries the memo molt:hatch.

13.2 Indexing molts

Watch for memos matching molt:shed:<n>. When you see one, re-read the metadata account and the JSON behind its URI. Cache by mint, never by name or ticker — those change.

13.3 HTTP API

The public API ships together with the launchpad. Planned endpoints:

14FAQ

15Versioning

This is revision 1 of MOLT-1. Later revisions will only add to it. A token always keeps the guarantees of the revision it hatched under.