How twinpad works

Overview

A twin launch is two coins created together:

• Coin A — an ordinary pump.fun coin, quoted in SOL, 1B supply.
• Coin B — a Meteora Dynamic Bonding Curve (DBC) pool whose quote token is A. 1B supply, immutable mint.

Because B is priced in A, every B purchase is an A purchase first, and B's SOL price is (B/A) × (A/SOL). The two fee streams are wired into each other by an automated loop: A's creator fees buy and burn B, B's fees burn A.

Mechanics

Coin A on pump.fun

A is created with pump.fun's create instruction. Its on-chain creator — the address that earns pump.fun creator fees — is a per-twin keypair generated at launch and held by the loop service. Fees accrue in pump.fun's creator vault for that key; the loop claims them with collect_creator_fee.

Coin B on Meteora DBC

B is a DBC pool created under a partner config where quoteMint = A. Meteora accepts plain SPL mints as quote assets without a token badge (verified on mainnet). The pool's creator is the same per-twin key, and its partner (fee claimer) is the pad wallet.

B's config, fixed at launch and immutable afterwards:

The loop

The loop runs every few minutes for every live twin. Per tick, in this order:

1. B fees → burn A. If B's unclaimed creator fees exceed the threshold, the loop claims them (they arrive as A) and burns every A token in the loop wallet.
2. A fees → buy B → burn B. If A's creator vault exceeds the threshold, the loop collects the SOL, buys A on pump.fun, swaps A for B on DBC (one transaction while both are on-curve), and burns every B token it received.

Step 1 runs before step 2 so any A held at burn time is fee revenue, never A bought on the way to B. Every transaction is written to the twin's ledger with its signature.

Trading A makes B scarcer. Trading B makes A scarcer. Neither side of the pair can be traded without tightening the other.

One-transaction trades

Buying B with SOL is a single wallet signature: pump.fun's buy is "exact tokens out, max SOL in", so the A amount feeding the DBC swap is known before the transaction is built. Selling B to SOL is the mirror: DBC swap B→A, then pump.fun sell of the minimum A out. Both fit a legacy transaction with no compute-budget instruction; if a wallet or route pushes it over 1232 bytes, the trade falls back to two signatures automatically.

After either coin graduates, the respective leg routes through Jupiter and the UI runs the two legs back to back.

Fees

The platform's only revenue is the 20% partner share of B's trading fee. The loop never takes a cut.

B's curve

B uses Meteora's constant-product bonding curve with a configurable migration threshold measured in A tokens. At launch the operator picks how much A must be locked into B's curve before B graduates (10M–100M A, default 25M) and what share of B's supply migrates with it (default 20%). The remaining supply is sold along the curve.

The optional sniper tax sets B's trading fee to 30% at activation, decaying exponentially to 1% over the first five minutes. It is enforced by Meteora's fee scheduler, not by the frontend, so it applies to bots trading the pool directly.

Graduation

• A graduates to PumpSwap like any pump.fun coin. Creator fees continue to accrue on PumpSwap and the loop keeps claiming them.
• B graduates to a Meteora DAMM v2 pool (B/A) when its curve reaches the threshold. 100% of the liquidity is permanently locked; the position belongs to the loop key.

Trust model

Enforced on-chain by pump.fun and Meteora: A's curve; B's curve shape, quote asset, fee mode, fee split, sniper tax, migration threshold and permanently locked liquidity; the immutability of both mints.

Trusted (off-chain): the loop service. It holds each twin's creator key and is responsible for claiming fees, swapping and burning as documented. It never custodies user funds and cannot touch either curve's reserves. Everything it does is visible in the ledger and on-chain under the twin's loop address.

The loop could, in theory, stop running or keep fees instead of burning. It cannot rug the pool, mint tokens, change fees, or move locked liquidity.

Keys & custody

• Per-twin creator key — generated at launch, encrypted at rest with a master key, never exported. It is the on-chain creator of A and the pool creator of B.
• Pad wallet — pays launch and loop transaction fees, receives the 20% partner share of B's fees.
• Your wallet — signs your own trades. The site never asks for approvals beyond the transaction shown.

Risks

Memecoins are highly speculative and can lose all value. B is a leveraged expression of A — if A goes to zero, B's SOL price goes to zero regardless of B's own curve. Read the full risk disclosure.

Launching

Launches are currently operator-signed: the pad wallet pays the creation transactions, so the launch form requires an admin key. What happens on submit:

1. Metadata for both coins is uploaded to IPFS (B reuses A's image).
2. tx1 pump.fun create for A, creator = per-twin key.
3. tx1b optional dev buy of A by the pad.
4. tx2 DBC createConfig with quote = A.
5. tx3 DBC initializeVirtualPool for B.

The twin goes live once tx3 confirms, usually within a minute.

API

All endpoints are JSON and unauthenticated unless noted.

GET  /api/twins                 list twins with live A/B state
GET  /api/twins/:id             twin, A state, B state, ledger, loop totals
POST /api/twins/:id/trade       build unsigned txs for a wallet
     { side: "sol_to_b" | "b_to_sol" | "sol_to_a" | "a_to_b" | "b_to_a" | "a_to_sol",
       wallet: "<pubkey>", amount: number, slippageBps?: number }
     -> { txs: [{ b64, versioned, label }] }   (409 + fallback[] after graduation)
GET  /api/ledger?twin=:id&limit=100
POST /api/twins                 create a twin        (x-admin-key)
POST /api/loop/run              run one loop tick    (x-cron-secret / Bearer)

Stack

Next.js · @pump-fun/pump-sdk v2 · @meteora-ag/dynamic-bonding-curve-sdk · Jupiter (post-graduation routing) · Postgres · wallet-standard wallets. RPC is HTTP-only; everything confirms by polling, nothing subscribes. Source is private for now.