The Accounts Involved in a Launchpad Curve Trade

A launchpad curve trade names roughly a dozen accounts in a fixed order: a global configuration account, the fee destinations, the mint, the curve state account, the token account holding the curve's reserves, the buyer's token account, the signer, and the programs invoked along the way. Each slot carries a signer flag and a writable flag, and the program validates all of it before it moves a single lamport.

This is the part of an instruction that people skip, and it is the part that decides whether a transaction succeeds. Argument encoding errors are rare because the fields are simple. Account errors are common because the list is long, positional, and version-specific, and because an account that is correct in principle can still be wrong in the slot it was placed in.

The account model in one paragraph

Solana programs do not fetch state during execution. Every account an instruction will read or write must be declared up front, so the runtime can look at two transactions, see that they touch disjoint sets of accounts, and execute them in parallel. That single design decision explains why account lists are long, why they are explicit, and why they are part of the instruction rather than hidden inside the program. The account model is described in the official Solana documentation and is the stable foundation everything else here rests on.

The corollary is that the account list is a declaration of intent, readable by anyone. Before a transaction executes, its account list already says which state it plans to touch. After it executes, the pre and post balance arrays say what it actually changed. Comparing those two is one of the cleanest audits available on any chain.

The three flags that describe a slot

Each entry in an account list is a public key plus two booleans, and those two booleans carry most of the meaning. A signer flag means the transaction must carry a valid signature from that key. A writable flag means the program is permitted to modify the account, and that the runtime must treat it as contended for scheduling purposes.

• Signer, writable. Almost always the trader's wallet: it authorises the trade and its lamport balance changes.
• Not signer, writable. State the program owns and updates, such as the curve account and the token accounts on both sides of the trade.
• Not signer, not writable. References: the mint, a global configuration account, and the program ids being invoked.
• Signer, not writable. Rare in a trade. It appears where an authority has to approve something without its own balance changing.

Reading the flags first is a useful discipline when you open an unfamiliar transaction. The writable set is the blast radius: nothing outside it changed, no matter what the logs suggest. If an account you expected to move is not flagged writable, it did not move, and your model of the instruction is wrong.

The slots a curve trade names

The table below describes the shape seen in current launchpad traces of this kind. It is a description of a deployed version, not a specification, and the exact set has grown over time as programs added fee destinations and internal accounts.

Slots eleven and twelve surprise people. A program that emits structured events using a cross-program invocation has to name itself and an authority account in the instruction, which is why a trade instruction appears to reference the program it is already calling. It is not redundancy; it is how the event ends up in the inner instruction record rather than only in free-text logs.

Which accounts are derived, and from what

Several of those slots are program derived addresses: computed from seeds plus the program id, with no private key, so the program itself can sign for them. Derivation is deterministic, which has a useful consequence for anyone reading activity rather than producing it. Given a mint, you can compute where its curve state lives, and given a wallet and a mint you can compute where that wallet's tokens live, without a single lookup.

The associated token account derivation is a published standard rather than a launchpad convention, documented alongside the token program in the Solana program library reference. The launchpad-specific seeds are not a standard, and a redeployment can change them, which is the recurring theme of this note.

Why the order is part of the contract

Accounts arrive positionally. The program's account struct maps index zero to its first declared field, index one to its second, and so on, then applies constraints: this account must be owned by this program, this one must be the derived address for that mint, this one must be a signer. If the buyer's token account and the curve's token account are swapped, the constraint on ownership fails and the instruction aborts.

That is the good outcome, and it is worth stating plainly because the alternative sounds worse than it is. A well-constrained program does not quietly do the wrong thing when given a scrambled list; it refuses. The cost is the transaction fee and the slot, not the funds. Programs that lack those constraints are a different and much more serious problem, and they are not the subject here.

Rent, and who pays for what

Every Solana account must hold enough lamports to be rent exempt, proportional to its data size. For a token account this is a small fixed deposit; for a curve state account it is slightly larger. The deposit is not a fee. It stays in the account and is recoverable if the account is closed, which is why some operators close empty token accounts to reclaim it.

Two rent-related facts matter when reading traces. First, a wallet's first purchase of any token is more expensive than its later ones because it includes the deposit. Second, the funder of that deposit is recorded, and it does not have to be the account owner. A single address funding the token accounts of a dozen wallets in the same slot is one of the clearest structural signals available, and it needs no inference to observe. It does need care to interpret, which is covered in the note on how each bot class looks in a trace.

The fee accounts

A launchpad trade usually routes value to more than one destination: the curve itself, a protocol fee account, and in newer deployments a creator-linked account. The addresses for those destinations come from program state rather than from the sender, which is an important detail. The sender does not choose where fees go, and cannot; the program reads the destination from its own configuration and enforces it.

That is why a fee destination appearing in the account list is not evidence of anything about the sender. It is evidence about the deployed program. The only sender-controlled costs in the transaction are the base fee, the priority fee implied by the compute unit price, and any rent deposits the transaction funds. Everything else is protocol behaviour.

What a wrong account list looks like

Account errors surface as failed transactions with recognisable causes, and learning the small set of them turns an opaque failure into a two-minute diagnosis.

• A constraint error naming a seed. A derived address was computed with the wrong seeds, usually because the client was written against a different program version.
• An owner check failure. An account was supplied that exists but belongs to the wrong program, classically a system account where a token account was required.
• A missing signature. A slot that requires the signer flag was passed without it, which means the transaction was assembled with the wrong meta rather than with the wrong key.
• An uninitialised account. The token account was never created, because the creation instruction was omitted or ran after the trade rather than before it.
• An account count mismatch. The program expected more or fewer accounts than it received, which is the classic symptom of a program upgrade that added a slot.

The last one deserves emphasis because it is the failure mode that arrives without warning. A client that worked yesterday starts failing on every transaction, with no change on the sender's side, because the deployed program now expects an additional account. There is nothing to debug in the client; the shape simply moved.

Auditing an account list from a trace

Reading somebody else's account list is a reliable way to understand what their software does, and it needs no cooperation from them. The sequence below works on any confirmed launchpad transaction in a public explorer.

1. List the account keys and mark which are flagged signer and which writable. The writable set bounds everything that changed.
2. Identify the programs by their known ids: system, token, associated token account, compute budget, and the launchpad itself.
3. Find the mint, then derive the expected curve state address from it and confirm the transaction names that exact account.
4. Derive the expected token account for the trading wallet and confirm it appears. If it does not, the wallet was not the recipient.
5. Check whether the fee payer equals the trading wallet. A difference means a funding structure rather than an individual.
6. Read the pre and post balances for every writable account and reconcile them against the trade you think happened.

Do that on a handful of transactions and the class of software behind a wallet becomes fairly obvious. It is also the honest way to evaluate a tool: an operator who routes flow through many wallets with a volume bot on Solana DEXs can point at the resulting signatures and let anyone reconcile them the same way, which is a stronger form of evidence than any dashboard figure.

Account lists drift

The single most important thing to carry away is that account lists are versioned artefacts. They have grown as launchpad programs added fee logic, and they will keep changing, because the programs are upgradeable and their operators use that capability. Any table, including the one above, is a snapshot.

The durable method is derivation rather than memorisation. Learn how derived addresses are computed, learn which programs perform which invocations, learn to read flags, and you can reconstruct an account list from a recent confirmed transaction whenever the shape moves. That takes about as long as looking up a table and does not go stale.

Questions this note keeps getting