Price Oracles
Jupiter Perps aggregates token prices from three independent onchain price oracles:| Oracle | Role |
|---|---|
| Edge by Chaos Labs | Primary oracle |
| Chainlink | Verification and fallback |
| Pyth | Verification and fallback |
Oracle Selection Logic
- If the Edge oracle is not stale and its price is within a defined threshold of both Chainlink and Pyth, the Edge price is used.
- If the Edge oracle is stale or outside the threshold, Chainlink and Pyth prices are compared. If they are within the threshold of each other, the more recent of the two is used.
- If two or more oracles fail, no price update occurs.
Oracle price updates happen both during trade execution and via a dedicated keeper that runs independently. Prices used in Jupiter Perps may differ from prices on other venues. The Jupiter Perps price chart is the source of truth for trade decisions.
Oracle Price Accounts (onchain)
Oracle Price Accounts (onchain)
Migration Note
If you are using the old oracle account referenced in the custody account’sdovesOracle field, migrate to the new accounts by using the dovesAgOracle field instead.
Request Fulfillment Model
Jupiter Perps uses an onchain request fulfillment model for all trade actions. Every trade requires two separate transactions:- Request transaction — The trader (or API client) submits a transaction to Solana containing all required trade parameters (size, collateral, direction, etc.).
- Fulfillment transaction — A keeper detects the request onchain, validates it, and submits a second transaction to execute the trade. The trade is only finalized when this second transaction is confirmed by the Solana network.
Keepers
Keepers are offchain services operated by Jupiter that continuously poll the Solana blockchain for pending trade requests. Jupiter runs two keepers in parallel. Actions processed by keepers:- Opening and closing positions
- Increasing or decreasing position size
- Depositing or withdrawing collateral
- Creating, editing, and triggering TP/SL orders
- Creating, editing, and triggering limit orders
Because execution requires a keeper transaction, there is a short delay between request submission and trade execution. The trade is not live until the keeper’s fulfillment transaction is confirmed.
Custody Accounts (Onchain)
Each asset in the JLP has a corresponding custody account storing all pool and fee parameters for that asset.Custody account addresses
Custody account addresses
Key fields in custody accounts
Key fields in custody accounts
| Field | Description |
|---|---|
pricing.tradeImpactFeeScalar | Scalar constant for linear price impact fee calculation (BPS format, divide by 10,000 for USD) |
priceImpactBuffer.deltaImbalanceThresholdDecimal | OI imbalance threshold for additive price impact fee |
fundingRateState.hourlyFundingBps | Current hourly borrow rate for the asset |
assets.owned | Total tokens owned by the custody |
assets.locked | Tokens currently locked in open positions |
assets.guaranteedUsd | Estimate of total long position size (updated on position changes, not in real time) |
assets.globalShortSizes | USD value of all open short positions |
assets.globalShortAveragePrices | Average entry price across all open shorts |
increasePositionBps | Base fee (BPS) for opening positions |
decreasePositionBps | Base fee (BPS) for closing positions |
Code References
Base fee calculation
Formula and code snippet for the flat 0.06% open/close fee.
Linear price impact fee
Scalar-based fee that scales with trade size.
Additive price impact fee
Reference implementation for the OI-imbalance penalty.
Swap fee calculation
Weightage-based swap fee between JLP-held assets.
JLP mint/burn fee
Same weightage logic applied to minting and redeeming JLP.
PnL calculation
Unrealized and realized PnL formula and pseudocode.