The Mutable Token Standard

01Abstract#

A token's identity on Solana lives in its Metaplex metadata account: a name, a symbol, and a URI pointing at an image and description. Almost every launch freezes that account the moment it is created. MTS-1 does the opposite. It specifies tokens that are born mutable, the three ways a mutation can be requested, the single transaction that performs it, and the guarantees that hold across every rewrite.

The result is a token that can tell a story over time. It can be one thing at launch and another at graduation, change on a creator's command, or continuously become whatever the market is watching. Holders never move, never migrate, never claim. The token they hold simply becomes something new.

02Motivation#

Memecoins are narratives, and narratives move faster than a fixed ticker. Today a project that wants a new identity has two options: launch a new token and ask everyone to move, or live with the old one. Both lose. Liquidity fragments, holders are left behind, and the history that made the token valuable is gone.

Solana's metadata program already supports rewriting a token's identity. What was missing is a standard: who may do it, when, how it is authorized, what it may never touch, and how anyone watching can follow along. MTS-1 is that standard.

03Terminology#

The key words MUST, MUST NOT, SHOULD and MAY are to be read as described in RFC 2119.

04The mutable token#

Mint and supply#

A mutable token is a classic SPL Token mint with 6 decimals and a fixed supply of 1,000,000,000. The mint authority is revoked at creation; the supply can never change. The mint address is the token's permanent identifier and MUST remain the same for the token's entire life.

Metadata account#

The token's Metaplex metadata account MUST be created with is_mutable = true, and its update authority MUST be the launchpad's key. This is set by the launchpad's Meteora Dynamic Bonding Curve configuration (tokenUpdateAuthority = PartnerUpdateAuthority), so every token created from it inherits the same authority, without exception.

Identity#

Off-chain document#

Each identity points at a JSON document in the format wallets already read. MTS-1 adds two attributes, so the token's mutable nature is visible to any marketplace or explorer that shows traits.

{
  "name": "Shapeshifter",
  "symbol": "Shift",
  "image": "https://ipfs.io/ipfs/bafy…",
  "description": "What it is, and what it might become.",
  "showName": true,
  "createdOn": "https://mutate-spl.com",
  "twitter": "https://x.com/…",
  "website": "https://…",
  "attributes": [
    { "trait_type": "Mutations", "value": 3 },
    { "trait_type": "Mode", "value": "scheduled" }
  ]
}

05Mutations#

The transaction#

A mutation is a single Solana transaction, signed and paid for by the update authority, containing exactly two instructions: the metadata rewrite and a memo that marks it.

UpdateMetadataAccountV2  (Token Metadata, discriminator 15)
  accounts
    [w]  metadata          PDA("metadata", METAPLEX, mint)
    [s]  update_authority  the launchpad
  data
    Some(DataV2 {
      name, symbol, uri            ← the new identity
      seller_fee_basis_points      ← carried over
      creators, collection, uses   ← carried over
    })
    update_authority       None    ← unchanged
    primary_sale_happened  None    ← unchanged
    is_mutable             None    ← unchanged

Memo  "mutate:mutate:<generation>"

Before the transaction is built, the new image (if any) and the new metadata document are pinned to IPFS. Every field the rewrite does not intend to change is read from the current account and written back unchanged.

Invariants#

A mutation MUST NOT change any of the following. They hold across every generation:

Generations#

Each mutation increments the token's generation by exactly one and is recorded with its previous identity, its new identity, what caused it, and the transaction signature. The history is append-only and public on every token page and through the API.

06Mutation modes#

Every token declares a mode at launch. The mode answers one question: who decides when this token becomes something else?

Manual#

The creator rewrites the token from its page. They choose a new name, ticker and optionally an image, and sign a message with the wallet that launched it. Signing is free; the launchpad pays for and submits the transaction. Only the launch wallet can request a manual mutation, and every request expires after five minutes.

Scheduled#

The creator commits the token's future at launch: up to 4 identities, each with a time in hours after launch. Times MUST strictly increase and fall within 720 hours (30 days). An entry without an image inherits the previous one.

Future identities are hidden. The API reveals only when each lands, never what it will be, until it is applied. A scheduled token cannot be mutated manually and its plan cannot be edited: what was committed at launch is what happens.

Auto · trending#

The token follows the market. On every keeper run it becomes a memecoin trending on Solana at that moment, taking that coin's name, ticker and image. Trending data comes from Birdeye's trending list, falling back to DexScreener's most-boosted Solana tokens when Birdeye is unavailable. The image is copied to IPFS so the token never depends on another project's servers.

07Creator authorization#

Creator actions are authorized by an Ed25519 signature over a plain-text message, not by a transaction. The wallet proves it holds the launch key; the launchpad's update authority performs the write. The message is human-readable in the wallet prompt and names the exact change.

Mutate: mutate my token
token: 7xKpQm…3FqA
name: Shapeshifter
symbol: Shift
image: https://ipfs.io/ipfs/bafy…
issued: 1792540800000

Mutate: change mutation mode
token: 7xKpQm…3FqA
mode: auto
issued: 1792540800000

1. 1
   Rebuild

   The server rebuilds the message from the request body. Any difference in token, values or time invalidates it.
2. 2
   Freshness

   The issued timestamp MUST be within five minutes of the server clock, so a signature can't be saved and replayed later.
3. 3
   Signer

   The signature MUST verify against the token's creator: the wallet that paid for its launch.
4. 4
   Execute

   Only then is the mutation leased, pinned, signed by the update authority and broadcast.

08The keeper#

The keeper is the process that mutates tokens without anyone asking. It runs two loops: every 30 seconds it applies any scheduled identity that has come due, and on a fixed interval (KEEPER_INTERVAL_MIN, 30 minutes by default, one setting for the whole platform) it rewrites every auto-mode token.

Auto tokens are dealt different coins so the platform never turns into twenty copies of the same thing, and the deal rotates each round. A token is never handed the coin it already mirrors.

round = floor(now / interval)
for token[i] in auto tokens (oldest first):
  pick = trending[(i + round) mod n]
  while pick.mint == token.mirror_mint or pick.symbol == token.symbol:
    pick = next in trending
  mutate(token, pick)

09Concurrency and safety#

Creators, schedules and the keeper all mutate through one code path. Before any work begins it takes a lease: a conditional write that succeeds only if the token is still at the expected generation and no other mutation holds it. Leases expire after three minutes, so a crashed process can never wedge a token.

10Launch lifecycle#

1. 1
   Design

   The creator chooses the launch identity, socials and a mode. Scheduled tokens also commit their plan.
2. 2
   Pin

   The image and generation-zero metadata document are pinned to IPFS.
3. 3
   Create

   One transaction creates the mint, metadata and bonding-curve pool from the launchpad's DBC config, with an optional first buy and a mutate:launch memo. The browser generates the mint keypair; it never leaves the creator's device.
4. 4
   Verify

   Before broadcasting, the server checks the signed transaction is the one it built and simulates it.
5. 5
   Live

   The token trades on its curve immediately, and its mode takes effect.
6. 6
   Graduate

   When the curve fills, liquidity migrates to a Meteora DAMM v2 pool. Mutations continue after graduation.

11Market structure#

12Trust model#

MTS-1 is explicit about where trust sits. The launchpad holds the update authority for every mutable token. That is what makes mutations possible without asking holders to sign anything, and it means holders rely on the launchpad to follow this standard.

13Integrating#

Detecting MTS-1 tokens#

A token is MTS-1 if its metadata account is mutable, its update authority is the launchpad's key, and its creation transaction carries the mutate:launch memo. Its metadata document lists Mutations and Modeattributes.

Indexing mutations#

Wallets and explorers SHOULD re-read a token's metadata account when they see a transaction from its update authority carrying a mutate:mutate:<n> memo, and SHOULD NOT cache an MTS-1 token's identity indefinitely. The memo's generation lets an indexer detect and order rewrites without diffing accounts.

HTTP API#

Everything the site shows is available as JSON from mutate-spl.com.

14FAQ#

15Versioning#

Future revisions will be additive. A token launched under one revision keeps that revision's guarantees for life.