Jupag
Jupag limit orders use USD price triggers in Jupiter Trigger V2
last updatedJupag limit orders automate token swaps on Solana when a selected price condition triggers execution. Jupiter Trigger V2 uses a token's USD price for buy-above, buy-below, sell-above, and sell-below orders. Deposited tokens wait in a shared custodial vault, and the eventual swap uses market pricing. The trigger therefore does not fix the final output amount. Trigger V1 uses a fixed token-pair rate, so its output and deposit rules differ.
Expired Trigger V2 price orders leave unfilled funds in the vault until you complete the cancellation and withdrawal flow.
The trade direction determines the USD trigger
In Trigger V2, a price order connects a buy or sell instruction to the USD value of a selected token, with a condition above or below the target. A buy-below order targets a purchase below that level. Buy-above targets a purchase above it, while sell-above and sell-below apply the corresponding conditions to a sale.
A single price order can use a trailing trigger that follows the market.
V1 and V2 handle deposits and order changes differently
Trigger V1 holds deposits in onchain order accounts, while V2 uses a Privy-managed custodial vault shared across a wallet's orders. V1 targets a fixed pool rate; V2 tests a USD price condition before attempting a market-priced swap.
| Order type | Deposit and order control |
|---|---|
| Trigger V1 limit order | An onchain program-derived address (PDA) order account holds the deposit; edits require cancellation and recreation. |
| Trigger V2 single price order | A custodial vault holds the deposit; trigger price and slippage support in-place edits. |
| Trigger V2 OCO | Two exit orders share one deposit; one side filling cancels the other. |
| Trigger V2 OTOCO | A parent fill activates paired exits on its output tokens. |
| Trigger V2 DCA | The shared vault funds scheduled rounds; changes require cancellation and recreation. |
Trigger V1 receives critical-only updates and has no scheduled deprecation, while development focuses on V2. Older V1 instructions can therefore describe valid behavior for that version, including a fixed output amount, without describing how a V2 order works.
Execution pricing depends on liquidity and slippage
Trigger V2 does not guarantee a fixed output amount. Its USD threshold activates a swap at the market rate available during execution. Liquidity and slippage affect the amount that the swap produces. A reached trigger is therefore different from a completed fill. Price orders have a configurable slippage setting. A tighter setting limits acceptable price movement and can prevent execution when liquidity or prices change, while a wider setting permits a larger price difference. Slippage controls the acceptable execution tolerance; the USD threshold controls when the order triggers. Jupiter routing handles the token conversion when execution begins.
OCO pairs exits, while OTOCO adds a parent entry
An OCO (one-cancels-other) order pairs a take-profit with a stop-loss against the same deposit, so one side filling automatically cancels the other. Any unused funds return to the vault. The pair coordinates alternative exits, and the slippage setting still constrains the swap that executes.
OTOCO (one-triggers-one-cancels-other) adds a parent entry whose fill activates the exit pair on its output tokens. If the parent expires or fails, Jupiter never creates the child orders.
Expiry leaves unfilled price-order funds in the V2 vault
An expired V2 price order leaves its unfilled funds in the vault; expiry alone does not return them to the wallet. The cancel-and-withdraw flow requires initiating cancellation, signing the withdrawal, and confirming it. An unwanted price order uses the same flow to retrieve its funds.
V2 price orders allow in-place changes to trigger price and slippage, preserving the order when those settings change. V1 requires cancellation and recreation for an edit. Neither action reverses a swap that has already executed.
V2 also supports partial fills. A partial fill exchanges only part of the deposit. Fill records distinguish that completed portion from funds that have not yet swapped. The original deposit amount alone does not establish how much of the order has executed.
Dollar-cost averaging (DCA) shares the V2 vault, but its cancellation behavior differs: cancelling returns the unfilled remainder to the wallet. Previously filled rounds stay completed. A DCA change requires cancellation and a new order; the in-place price-order editing rule does not apply.
Private pending orders still use a custodial vault
Trigger V2 stores pending orders offchain, keeping their price, size, and direction private until the condition triggers and execution begins. V1 pending orders expose their details through onchain PDA accounts. Privacy for pending V2 instructions coexists with custodial deposits: Privy manages the vault that holds the tokens. The V2 API combines an API key with challenge-response wallet authentication, using a signed challenge to produce a JSON Web Token (JWT) for authenticated requests. Funding the vault requires a separately signed deposit transaction that transfers tokens from the wallet. The authentication signature alone does not fund an order.
Perps limit orders follow the market's own execution model
Jupiter Perps limit orders on its SOL, ETH, and wBTC markets target leveraged positions against the JLP liquidity pool. A triggered order opens or increases a position on the same market and side, using an oracle price. The order remains active until it triggers or the trader cancels it. Fast price movement can still cause a slippage failure after the target is reached.
On those JLP markets, take-profit and stop-loss instructions attach to an existing position and conditionally close it through the Perps keeper. An order close to the liquidation price may fail to execute before liquidation. Beta Perps markets use a separate trading engine and do not offer these attached TP/SL orders.
Jupag limit orders: quick answers
What is the minimum value for a Trigger V2 limit order?
Trigger V2 specifies a 10 USD-equivalent minimum for price orders. That requirement concerns the order's value, while the USD trigger sets the token price that activates it. DCA has a separate minimum of 10 USD per round, with at least two rounds.
Does an expired JWT stop an open Trigger V2 limit order?
An expired JWT does not stop an existing Trigger V2 order from being monitored or executing. The token authorizes API calls for actions such as creating, editing, and cancelling orders. Re-authentication restores access to those management actions.
How does a market-cap target become a Trigger V2 price condition?
Jupiter's frontend converts a market-cap target into a per-token USD price before submitting the order. The calculation divides the target market capitalization by the token's total supply. Trigger V2 accepts the resulting USD price through triggerPriceUsd, so the API condition concerns token price. It does not monitor a separate market-cap trigger.
Can a Trigger V2 limit order include an integrator fee?
Trigger V2 does not currently support integrator fees within its order flow. The keeper executes the order, so an integrator cannot add an atomic fee transfer to that execution. Collecting such a fee requires a separate transfer outside the order flow. Trigger V2 has no announced timeline for native integrator fee support.
Why does a Trigger V2 stop-loss have a different default slippage setting?
Trigger V2 defaults stop-loss and buy-above price orders to 20% slippage (2,000 basis points) because those directions prioritize execution. Take-profit and buy-below orders instead use automatic slippage through the Real-Time Slippage Estimator (RTSE). A custom setting can override the price-order default. The wider default permits a substantial execution-price difference, so the trigger level alone does not describe the acceptable fill.
Is a buy-below limit order equivalent to price-conditional DCA?
A buy-below price order uses a threshold, while price-conditional DCA applies a price band to scheduled rounds. Each DCA round fills only while the trigger token's USD price falls inside that band. When the price is outside it, the round waits and reschedules to the next interval.