Choosing the token pair and the venue
Two fields at the top of the form decide what you are actually trading and where every swap is sent. Get either one wrong and the rest of the settings are irrelevant, because the run will be perfectly executed against the wrong thing.
In one line
The token field wants a mint address copied from an explorer, and the venue field decides which pool or curve every swap in the run is routed through.
The short answer
The token field wants a mint address: the long base58 string that uniquely identifies a token on Solana. The venue field decides which program every swap is routed to, which in practice means a launchpad bonding curve if the token has not migrated yet, or an automated market maker pool if it has. Paste the mint from a block explorer, then pick the venue where the token is actually trading right now.
Both fields look trivial and both are where whole runs get wasted. A ticker that matched the wrong token, or a venue that holds almost no liquidity, produces a run that works exactly as designed and achieves nothing you wanted.
The field wants a mint, not a ticker
Ticker symbols on Solana are not unique and are not registered. Anyone can create a token called anything, and popular symbols are duplicated within minutes of becoming popular. The mint address is the only identifier that means one specific token, which is why the field asks for it and why pasting anything else is guesswork.
The safe way to get one is boring and takes fifteen seconds. Open the token on a block explorer, find the field labelled mint or token address, and copy it from there. Then paste it into the panel and compare the first four and last four characters against the explorer tab. Address poisoning attacks work precisely because addresses with matching ends look identical at a glance, so compare characters rather than shapes.
Where mints come from, in order of safety
Best: copied from the token page of a block explorer you navigated to yourself. Acceptable: copied from the launchpad page for that token, reached through your own bookmark. Not acceptable: pasted from a chat message, a reply under a post, or a screenshot. The last category is where lookalike mints circulate, and a mistyped run is unrecoverable once the swaps have landed.
What the panel shows once it resolves
Pasting a valid mint changes the screen. A panel that does nothing after you paste is either still fetching or cannot see a market for that token, and both of those are information worth pausing on.
Empty field
The venue selector is usually greyed out, size fields are disabled, and any estimate area shows placeholders. Nothing downstream can be calculated because nothing upstream has been decided.
Resolved mint
A name, a symbol and usually a decimal count appear. The venue list populates with the markets the panel can see, one of them preselected. Size fields unlock and any depth or impact estimate starts showing real numbers.
Read the resolved values rather than glancing at them. The name and symbol confirm you have the token you meant. The decimals matter more than they look: a token with six decimals and one with nine behave differently in every amount field on the form, and a panel that shows you the figure is telling you it read the mint properly.
If the panel resolves the mint but lists no venue, the token has no market the panel can route to. That is not a bug to work around. It means there is nothing to trade against, and no setting further down the form changes that.
What the venue field is really choosing
A swap on Solana does not meet a buyer. It meets a program holding a reserve of two tokens, which prices the trade by a formula and adjusts its own balances afterwards. The venue field chooses which program that is, and different programs price the same trade differently.
Newly launched tokens usually start on a bonding curve, a single account that sells tokens at a price defined by how many have already been sold. There is no second party depositing liquidity: the curve itself is the counterparty. When enough of the supply has been bought, the launchpad migrates the token into an ordinary pool, an event usually called graduation. After migration the curve is finished and the pool is where trading happens.
This matters for a run because the two behave differently under repeated small trades. On a curve, buys push the price up along a fixed formula and sells bring it back down along the same one, so a balanced schedule returns close to where it started minus fees. In a pool, the same is broadly true but depth is contributed by liquidity providers and can change underneath you while the run is going, because somebody else can add or remove liquidity at any moment.
The venue types side by side
Panels name venues after protocols, so the selector reads like a list of brands. Underneath, there are only a few structural types and they are what actually change the run.
| Venue type | Where liquidity comes from | What it means for a run |
|---|---|---|
| launchpad curve | The curve formula itself, no providers | Predictable pricing, but every trade moves along the curve and the venue disappears at migration |
| constant product pool | Providers depositing both sides | The classic case: impact falls as reserves grow, and depth can change mid-run |
| concentrated liquidity | Providers choosing a price range | Very deep inside the active range and thin outside it, so impact is uneven across sizes |
| dynamic or bin-based pool | Providers with programmatic parameters | Fees and depth can vary with volatility, so a cost estimate from one hour may not hold in the next |
| aggregated route | Several of the above at once | Better pricing per trade, but the run is spread across venues and harder to reconcile afterwards |
If your panel offers an automatic option, it is usually routing through an aggregator, which splits a trade across whichever venues price it best. That is good for execution and awkward for measurement, because the resulting transactions do not all belong to the pool you were thinking about. Routing behaviour is documented in the Jupiter developer documentation if you want to see how a router decides.
For tokens still on a launchpad curve the choice is narrower and the tooling is usually specialised, which is why a Pump.fun volume bot is sold as its own product rather than as a mode inside a general one. Curve trading has its own fee structure and its own migration cliff, and a tool that treats it as just another pool will eventually route into a curve that no longer exists.
When several pools exist for one token
A single mint can have many markets. Someone creates a pool at launch, someone else creates a second one on a different protocol, a third appears after migration, and two of them hold almost nothing. Your panel will list some or all of them, often with near-identical labels.
Sort them by depth and ignore the rest. A pool holding a small reserve will show enormous price impact on ordinary trade sizes, which means the budget goes into slippage rather than into turnover. Depth is usually shown as total value locked or as reserve amounts; either is fine for comparison as long as you use the same measure across candidates.
Then check that the pool you picked is the one everyone else is trading in. If the pool with the deepest reserves is not the pool with recent transactions, something unusual is happening and it is worth understanding before routing a run through either. An explorer will show you the recent activity on a pool account directly, which is a more reliable answer than any label on a selector.
The migration trap
For a period around graduation, interfaces disagree. Some still show the curve, some already show the new pool, and a cached panel may offer a venue that has finished trading. Routing into a dead curve produces a run of failures that costs fees and achieves nothing. If a token has migrated in the last hour, refresh the panel and re-resolve the mint before starting.
The other half of the pair
Every venue trades your token against something else, and that something is usually SOL, occasionally USDC, and sometimes a wrapped variant. The panel may show this as a pair label rather than as a field you can change, but it affects two practical things.
The first is what your budget is denominated in. A run against a SOL pair spends SOL and its notional moves with the SOL price; a run against a stablecoin pair does not. If you set a cap in SOL and the pair is quoted in USDC, the two numbers drift apart during the run, and the drift is not a bug.
The second is wrapping. Trading against SOL frequently involves wrapped SOL, a token account that holds SOL in token form so it can be swapped like any other token. Panels usually handle this invisibly, but it explains why a run creates token accounts you did not expect and why a small amount of SOL can be sitting in one when the run ends. It is recoverable when the account is closed, which some tools do automatically and some do not.
Depth, worked with numbers
Venue choice is really a depth choice, and depth is easiest to understand as arithmetic. A constant product pool keeps the product of its two reserves fixed across a trade, which is enough to work out impact by hand.
Take a pool holding 400 SOL and 40,000,000 tokens. The product is 16,000,000,000. Send in 2 SOL and the SOL reserve becomes 402, so the token reserve must become 16,000,000,000 divided by 402, which is about 39,800,995. The difference, roughly 199,005 tokens, is what the trade receives. The starting rate implied 200,000 tokens for 2 SOL, so the trade got about 0.5 per cent less than the quoted rate. That difference is price impact, before any fee.
Now run the same 2 SOL trade against a pool holding 40 SOL and 4,000,000 tokens. The product is 160,000,000. After the trade the SOL reserve is 42 and the token reserve is about 3,809,524, so the trade receives roughly 190,476 tokens against a quoted 200,000. That is about 4.8 per cent of impact on the same trade, in a pool a tenth of the size.
| Pool reserves | Tokens at quoted rate | Tokens received | Impact |
|---|---|---|---|
| 400 SOL | 200,000 | 199,005 | 0.5 per cent |
| 40 SOL | 200,000 | 190,476 | 4.8 per cent |
The lesson is not the exact figures, which depend on a formula that not every venue uses. It is the relationship: impact scales with trade size relative to reserves, and a venue ten times thinner turns a trivial cost into a dominant one. This is why the venue field and the swap size field have to be decided together rather than one after the other.
Six checks before you save
Run these in order. They take about a minute in total and they catch every mistake described above.
- The mint matches the explorer, character for character. Compare the ends and at least one run of characters in the middle.
- The resolved name and symbol are the ones you expected. If the panel shows a different name, believe the panel and re-check the address.
- The venue in the selector is where recent trades actually are. A venue with no recent activity is not a venue.
- The pool depth is large relative to your intended swap size. If your trade is a visible fraction of reserves, reduce the size or choose another venue.
- The pair is quoted in the unit your budget is in. Otherwise your cap and your spend will drift apart during the run.
- Migration status is current. Re-resolve the mint if the token graduated recently, and start from a refreshed panel rather than a cached one.
A panel that routes across several venues at once cannot pass check three and four in the same way, and that is fine as long as you know it. In that case the check becomes: does the panel tell you afterwards which venues it used? If it does not, reconciling the run against a block explorer will be considerably harder.
Where this leads
The venue you chose sets the depth, and depth is the constraint that the next two fields have to respect. A swap size that is invisible in a deep pool is a market event in a thin one, and a wallet count that is affordable on one venue can be dominated by account overhead on another.
Panels that support several protocols usually present all of this as one selector, which is why a general-purpose volume bot on Solana DEXs has to show you which market it resolved rather than just the token you typed. If a tool will not tell you which pool it is trading in, you cannot check its work, and checking its work is the only real protection available.
Next, the two numbers that decide what a run costs before a single swap lands: how many wallets send the trades, and how large each trade is. Those two fields are where most of the money in a small run actually goes.
Written by The Setup Desk. Field names and screen layouts differ between tools, so this page describes what a setting is for rather than where a particular build puts it; any figure in an example is arithmetic chosen to show the shape of the calculation and describes no real account. The way these pages are put together is set out in how this desk works, and anything that reads wrong can be sent back as a correction.