Solana Limit Orders: Why Triggered Doesn't Mean Filled

You set a stop loss, close the app, and figure you're covered. Then the coin dumps straight through your stop and keeps going, and when you check, the order says it triggered but your bag is still sitting there. Nothing sold. That's not a glitch most of the time. It's how Solana limit orders actually work, and the gap between "triggered" and "filled" is the whole story.

This one's for anyone using limit orders, take profits or stop losses on Solana through Jupiter. I'll walk through what happens after you hit place order: where your tokens go, who executes the trade, what it costs, and how an order can trigger and still not fill. Everything here comes from Jupiter's own docs, linked as I go. I haven't run test orders for this piece.

A limit order on a DEX isn't an order book order

On a centralized exchange, a limit order sits on an order book until another trader matches it. Jupiter's limit order docs say plainly that its limit orders differ from a central limit order book. There's no counterparty waiting at your price. Instead, Jupiter watches the market, and when your condition is met, it runs a swap against on-chain liquidity from multiple DEXes.

That one difference explains almost everything else. Your "limit order" is really a conditional market swap. When it fires, it's subject to the same things any swap is: pool depth, price impact and slippage. I broke those down in slippage vs price impact on Solana, and they matter more here because nobody's watching when the order runs.

What happens after you place a Solana limit order

Jupiter's current version is Limit Order V2 (new V1 orders can no longer be created). Here's the flow, per the docs:

1. Your tokens move into a vault. The tokens you're selling leave your wallet and go into a vault, which Jupiter describes as a custodial wallet it creates for your address with its wallet provider, Privy. They sit there while the order is open.
2. Jupiter watches a USD price. V2 triggers on the token's USD price or market cap, not on the exchange rate between your two tokens.
3. A keeper executes. When the trigger hits, a keeper (an automated bot) runs the trade through Jupiter Ultra's routing.
4. Price and slippage checks run. If the price at execution is outside your slippage tolerance, the order doesn't fill.
5. It fills, partly fills, or waits. Partial fills settle right away, and the rest stays open until it fills, you cancel, or it expires.

Expiry is set when you place the order: 1 hour, 1 day, 1 week (the default), 30 days, or a custom date. If the trigger never hits, the order cancels and the tokens go back to your wallet.

The vault is a real tradeoff

While the order is open, your tokens aren't in your wallet. They're in a custodial vault. The older V1 design kept orders in on-chain program accounts (PDAs, which I explained in Solana PDAs explained). Jupiter's Trigger API overview says V2 moved to Privy-managed vault accounts and stores orders off-chain, and it frames the privacy benefit directly: in V1, pending orders sat in on-chain accounts, "giving bots a roadmap to front-run profitable trades." V2 orders stay private until they execute.

So you trade some self-custody for privacy and features. That's reasonable for a lot of people, but know you're making it. The docs flag a few side effects:

• Snapshots may miss you. Anything that reads wallet balances directly, like a third-party airdrop snapshot, may not count tokens sitting in an order.
• The vault isn't a deposit address. Tokens sent straight to it, including holder rewards a project pays to that address, aren't credited to any order and can only be recovered through support, which may or may not work.
• Cancelling takes two steps. Cancel stops the order, then you sign a withdrawal to bring the tokens back. Skip the second signature and the order sits in Pending Withdraw.
• Shared computers are a risk. The vault sign-in is stored in the browser and can cancel or edit orders, so disconnect your wallet on a shared machine.

Why a stop loss can trigger and not fill

Here's the part from the opening. Jupiter's docs put it in a warning box: a stop loss might not execute at all. When the trigger hits, the order goes out with your slippage tolerance applied. If price moves past your stop faster than the order can execute, or there isn't enough liquidity to fill within your slippage, it doesn't fill. The docs add that this is "especially common with low-liquidity tokens such as new memecoins or tokens that have been rugged."

A stop loss is supposed to save you in exactly the moment a thin coin is collapsing. That's also when the pool is draining and every seller is racing for the same exit. A tight slippage setting protects your price but can leave you holding. A loose one gets you out, at a worse price. There's no setting that gives you both. Jupiter's developer docs say stop-loss and buy-above orders default to 20% slippage in the API "because execution certainty matters more when cutting losses," which tells you which side they lean toward.

Two more quirks are worth knowing:

• The output isn't fixed. V2 doesn't lock in the amount you receive. Because the trigger tracks USD price, if you're selling a token for SOL and SOL's own price moves before the trigger, you get a different amount of SOL than the estimate showed.
• Market cap triggers are still price triggers. The developer docs say the API only takes a USD price, and the market cap option on jup.ag converts your target into a per-token price. A big market cap figure can also hide a thin pool, which I covered in market cap vs liquidity on Solana.

Take profit, OCO and trailing stops

V2 groups a few order types under one form. A take profit sells when price rises to your target. An OCO (one cancels other) pairs a take profit and a stop loss on tokens you already hold, and whichever hits first cancels the other. An OTOCO puts a buy in front of that pair: once the entry fully fills, the bought tokens stay in the vault and become the exit orders, so they won't show in your wallet right away.

A trailing stop loss follows price up and holds its level when price falls. You set a distance from 0.5% to 90% (default 10%) instead of a fixed stop price. Jupiter's own example: enter at $80 with a 10% trail, price climbs to $120, and the trigger trails up to $108 instead of sitting at $72. Tighter trails get knocked out by normal volatility; wider ones give back more on the reversal. Same warning applies: triggering isn't executing.

Fees, minimums and token taxes

Per Jupiter's fees page, V2 limit orders charge a 0.03% base fee on stable or pegged pairs and 0.1% on everything else, plus an Ultra routing fee of 0 to 0.5% depending on the pair, all taken at execution. The order needs to be worth about $10 or more, and your wallet needs at least 0.01 SOL. Jupiter notes those minimums can change and the app is the final word.

Watch tokens built on Token-2022 with a transfer fee. Jupiter says the fee is taken every time the token moves: when it goes into the vault, when the order sells, and again if a cancel sends it back. The creator can change that rate, so an order can settle at a different rate than you saw. I covered why that power matters in how to spot suspicious activity in new token launches.

What this doesn't cover

This is Jupiter's documented behavior today, not a test of fill rates, and other Solana apps run limit orders their own way. I'm not rating Jupiter against anyone or telling you which order type to use. Limit orders are a tool for not staring at a chart. They're not insurance.

The takeaway

A Solana limit order on Jupiter is a conditional swap, not a resting order. Your tokens sit in a custodial vault, a keeper fires the trade when a USD price trigger hits, and the fill still has to clear liquidity and your slippage. On a thin memecoin, the stop you're counting on can trigger and not fill right when you need it. Before you rely on one, check the pool depth, decide what slippage you'd actually accept to get out, and remember that the tokens in an open order aren't in your wallet. Have you ever had a stop trigger and not fill, and what did you change after?

Still building. Still here. 🫡