The New Pool Address: Mint Is Identity, Pool Is Venue

After migration a token has two addresses that matter: the mint, which is unchanged and identifies the token, and the pool, which is new and identifies the venue. Find the pool by opening the migration transaction and reading the account the routine created. Verify it by confirming the pool holds your exact mint. Never verify by matching a name, because names are metadata and anybody can copy them.

Two addresses, two jobs

The mint is created once, when the token is created. Balances are recorded against it in associated token accounts, as the SPL token reference describes, metadata hangs off it, and every wallet in existence uses it to decide what to display. Migration does not touch it. A holder's balance before and after graduation is the same number recorded against the same mint.

The pool is an account created during migration to hold the two reserves. It is a venue: a place where the mint can be exchanged for the quote asset at a price determined by the ratio of balances inside it. It has no relationship to the mint address, it cannot be derived from it by eye, and it did not exist an hour earlier.

Trouble starts because both are base-58 strings of similar length that look equally official pasted into a chat. Nothing about the format distinguishes them. People who have only ever needed one address suddenly have two, arriving within minutes of each other, at the moment they are least inclined to read carefully.

Why the pool cannot be known in advance

The pool account is created by the migration instruction. Before that instruction executes there is no such account, so there is nothing to look up and nothing an explorer can show you. Any site claiming to display the pool for a token still on its curve is displaying something else, most likely a placeholder or a different token.

Some AMM designs derive pool addresses deterministically from their inputs, which means it can be possible to compute an address before it exists if you know every input and know the exact derivation the program uses. This is a real technique and a poor foundation for anything operational, because it breaks silently when a program changes its derivation, when an input differs from what you assumed, or when the launchpad routes to a different venue than you expected.

The practical consequence is a sequencing rule. Everything that needs the pool address has to be configured after migration, not before. Teams that plan a launch as though the pool were a known constant discover this during the busiest hour they will have, which is a bad time to find out.

Four ways to find the pool

1. From the migration transaction. The authoritative source. Locate the transaction that completed the migration, open it in Solana Explorer, and read the pool account created by the invoked program. Nothing derived from this can be wrong, because you are reading the event that created the thing.
2. From the mint's account history. Walk the mint's recent transactions in an explorer such as Solscan to the point where the curve was marked complete. The migration is normally the transaction immediately at or after that boundary, and the same reading applies once you have it.
3. From an aggregator quote. Request a swap quote for the mint and read the route the aggregator returns. It names the pools it intends to use, which tells you both where the token trades and where trading is actually being routed, which are not always the same answer.
4. From a screener, with care. Third-party sites list pairs and will show a pool address. This is the fastest method and the only one that can hand you the wrong answer, because it depends on that site having indexed the right pool and on you having selected the right row among several with the same ticker. Use it to find a candidate, then verify.

Proving the pool is the right one

Verification is a small number of checks and each one has to be done against full addresses rather than against truncated displays.

• The pool's base-side token account holds your mint, compared character for character rather than by matching the first and last four.
• The pool's quote-side token account holds the quote asset you expect, not a wrapped variant you were not anticipating.
• The pool was created by the migration transaction you identified, rather than by an unrelated account at an unrelated time.
• The program that owns the pool is an AMM program you can name, not an unfamiliar id you have not checked.
• The reserves are consistent with the deposits you read off the migration transaction, allowing for trading since.
• If LP tokens were burned or locked, the LP mint state matches that claim rather than merely being asserted somewhere.

Six checks, a few minutes, and the result is knowledge rather than belief. The alternative is relying on a row in an index maintained by somebody with no obligation to you, at a moment when several rows look almost identical.

The impostor pattern

The confusion around graduation is exploited by a predictable pattern, and it works because every element of it is legitimate on its own.

A mint is created with the same name, symbol and image as a token that is about to graduate or has just graduated. None of that is restricted; metadata is free text and images are URLs. A pool is created for the impostor mint and funded with enough of both sides to make a chart appear and a price exist. Screeners index it like anything else, because from their perspective it is an ordinary new pair.

Then the address is circulated, usually into channels where people are already looking for a post-migration address and already primed to copy the first plausible one they see. The victim's swap succeeds. They receive tokens. The tokens are real tokens of a real mint that simply is not the mint they wanted, and the pool they bought from is controlled by whoever made it.

Read the middle and right columns and the point becomes obvious. Everything that is easy to check is identical. The only reliable difference is the mint address, and the second most reliable is whether the pool traces back to a migration at all.

Illustrative arithmetic on a wrong-pool trade

Addresses people routinely confuse

Beyond mint and pool there are several other addresses in the neighbourhood, and knowing what each one is prevents a whole class of confused questions.

• The curve account. The venue during the curve phase. After migration it is a historical record and not a place to trade.
• The pool's token accounts. Two accounts owned by the pool, one per side. They hold the reserves and are not the pool address itself.
• The LP mint. The mint for the pool's liquidity provider token. Its supply and destination tell you whether the seeded position was burned, locked or left spendable.
• The creator or deployer wallet. The address that created the token. Interesting for provenance, useless as a trading identifier.
• Your own associated token account. Where your balance of the mint actually lives. People occasionally paste this when asked for the token address.

Recording it before anybody needs it

The window in which the pool address matters most is the window in which nobody has time to derive it. The fix is procedural and takes a minute: as soon as migration lands, write down the migration signature, the pool address, the program that owns the pool, and what happened to the LP position, in a place your team can copy from.

Keep the mint separate and prominent, because that is the address for a general audience. Keep the pool with the operational notes, because that is the address for whoever is configuring tools. Mixing the two in one announcement is how the wrong one ends up in a swap box.

Keying tools by mint or by pool

Every tool in a launch stack is keyed to one of these two, and the choice determines whether it survives migration. Mint-keyed tools survive: holder trackers, supply monitors, transfer alerts, anything reasoning about ownership. Pool-keyed tools break: price feeds, depth monitors, chart embeds, anything reasoning about a market.

Breaking is not the problem. Breaking silently is. A price feed pointed at a dead curve does not raise an error; it returns the last thing it knew, or nothing, and a dashboard built on it looks calm. Anything venue-keyed should have a staleness check that fires when it stops receiving updates, and that check should exist before the migration rather than after somebody notices.

This is also the question worth asking of anything that trades rather than observes. Teams comparing tooling usually ask a Solana DEX volume bot which venues it supports; the more revealing question is whether it takes a mint and resolves the venue itself, or takes a pool address and keeps using it long after the token has moved on.

Second pools for the same mint

Nothing stops anybody creating another pool for a mint that already has one. Pool creation is permissionless and only requires depositing both sides, so a token that attracts attention frequently ends up with pools on more than one venue, created by people with no relationship to the project.

These are not impostors. They hold the correct mint and they are a legitimate second market in the same asset. Arbitrage keeps their prices roughly aligned with the original, at whatever cost the arbitrage takes. What they create is an identification problem rather than a safety problem: there is now more than one correct answer to the question of where the token trades, and different tools will give different ones.

The practical consequences are worth stating plainly. Depth readings differ by pool, so a dashboard pointed at the thinner pool will report a market that barely exists. Turnover splits across venues, so a single-pool figure understates activity. And routing decides which pool a given swap actually uses, which means the pool a team watches can be the one least of their community trades in.

The resolution is to distinguish the migration pool, which is the one created by the graduation and the one whose provenance you can prove, from any other pool that exists. Record the first explicitly. Discover the others deliberately rather than being surprised by them, and when a number disagrees with expectation, check which pool produced it before checking anything else.

Habits that make the hour survivable

None of this is difficult, and all of it fails under time pressure unless it is habitual. Compare full addresses, never truncated ones, because truncation is exactly what the impostor pattern is designed to exploit. Get addresses from a transaction you opened yourself, not from a message somebody forwarded.

Treat the first plausible answer as a candidate rather than a conclusion, and spend the two minutes verifying. Keep the mint as the public identifier and the pool as an operational detail. And when something looks wrong, check which account you are looking at before checking anything else, because that is the explanation more often than any of the interesting hypotheses.

Questions the desk is sent