The mutable launchpad

01Why#

Narratives move fast. A new name trends, a story changes direction, and within minutes there are several coins for the same idea, each betting on a different name. Normally every new narrative means a new coin.

Holders pay for that. They split across competing tickers, each group pushes its own, and whoever picked the wrong one gets vamped by the next coin. The idea stays the same; the holders end up spread over several coins.

On Metapad, one coin can follow the narrative instead. When the story moves, the coin updates its name, ticker and image, and its holders stay where they are.

02Mutable metadata#

On Metapad, a coin's identity is not locked at launch. Its name, ticker and image can be updated on-chain later, on the same mint. Nobody migrates, nobody claims, nobody sells one coin to buy another.

same coin · mint 7xKp…3FqAmetadata update

Before

AudaCity

$DacityCoin

name

AudaCity

ticker

$DacityCoin

image

audacity.png

↓one tx

After

Dacity Coin

$Dacity

name

Dacity Coin

ticker

$Dacity

image

dacity.png

mint · supply · balances · pool: unchanged

The name debate happens inside one coin. Holders propose names and vote, and the winner is written on-chain. If opinion changes later, a later vote can change it again. One coin follows the narrative instead of several competing for it.

03Holders choose or creator#

Who can update a coin's metadata is chosen at launch. There are two options.

04How holder votes work#

Most coins on Metapad let holders choose. Voting runs in rounds, 60 minutes each by default. In each round, holders propose a name, ticker and image, and vote for one proposal. Votes are weighted by token balance at the moment the round closes, so moving tokens to a second wallet does not add weight. The winning proposal becomes the coin's new metadata.

If two names compete for the same idea, both can be proposals on the same coin. Holders pick one; if they later prefer the other, a later round switches it, and nobody has to sell or move.

1. 1
   Propose

   During a round, any holder submits a name, ticker and image. Up to 20 proposals per round.
2. 2
   Vote

   Each wallet votes once. Its weight is its token balance when the round closes.
3. 3
   Close

   At the end of the round the keeper tallies the votes. The proposal with the most weight wins.
4. 4
   Write

   The winner is written on-chain in one transaction and appears on the Updates page. The next round opens.

05What changes, what never does#

One field is locked: the website in every coin's metadata always points to its page, metapad.tech/coin/<mint>, so wallets and explorers link back to the current identity and its history.

06Launch in 4 steps#

1. 1
   Pick the identity

   Name, ticker, image, and your X link. The website is set to the coin's page for you.
2. 2
   Choose who updates it

   Holders choose (default) or creator only. This is fixed at launch.
3. 3
   Add a first buy

   Optional. Enter an amount in SOL; it buys on the curve in the same transaction, with no swap.
4. 4
   Approve once

   One wallet approval creates the mint, the metadata and the curve. The coin is live and tradable right away.

07Fees and curve#

08On-chain details#

For developers, wallets and explorers.

Partner update authority#

Every coin launches from a Meteora DBC config with tokenUpdateAuthority = PartnerUpdateAuthority. The launchpad's partner key stays the Metaplex metadata update authority, and the metadata account stays mutable. The mint authority is revoked at creation, so the supply can never change.

The update transaction#

An update is a single transaction: a Metaplex UpdateMetadataAccountV2 with the new name, symbol and a new metadata URI pinned on IPFS, plus a memo. Fields that aren't meant to change are read from the current account and written back as they are.

one transaction, signed by the partner key
  1. Token Metadata · UpdateMetadataAccountV2
       metadata          PDA("metadata", METAPLEX, mint)
       update_authority  partner key (signer)
       data  DataV2 {
         name, symbol, uri        ← the new identity
         royalties, creators      ← carried over unchanged
       }
  2. Memo  · tags the update and its sequence number

unchanged: mint · supply · decimals · balances · pool

Signed messages#

Proposals, votes and creator updates are authorized by a plain-text wallet signature, not a transaction. The server rebuilds the message from the request, checks the signer, and rejects anything older than a few minutes so a signature can't be replayed.

Metapad: propose the next identity
token: 7xKp…3FqA
name: Dacity Coin
symbol: Dacity
image: https://…/ipfs/bafy…
round: 29817342
issued: 1794480000000

Metapad: vote on the next identity
token: 7xKp…3FqA
proposal: 1842
round: 29817342
issued: 1794480000000

Metapad: update my token's metadata
token: 7xKp…3FqA
name: AudaCity
symbol: DacityCoin
image: https://…/ipfs/bafy…
issued: 1794480000000

The keeper#

The keeper is the launchpad process that closes finished rounds. About every 30 seconds it checks for rounds that have ended, tallies the balance-weighted votes, and writes the winner on-chain with the partner key. Only one update per coin can run at a time; if a transaction fails, nothing is recorded and the coin keeps its identity.

Metadata JSON#

The URI points to a standard token metadata document on IPFS, in the format wallets already read. Each update pins a new one.

{
  "name": "Dacity Coin",
  "symbol": "Dacity",
  "image": "https://…/ipfs/bafy…",
  "description": "…",
  "twitter": "https://x.com/…",
  "website": "https://metapad.tech/coin/<mint>",
  "createdOn": "https://metapad.tech"
}

Indexers should re-read a coin's metadata account when they see a transaction from the partner key on its metadata, and not cache a Metapad coin's name forever.

09FAQ#