Jupiter

Connects to the Jupiter aggregator on the Solana chain and maps swaps onto the spot trading functions. One exchange object corresponds to one Solana wallet: quotes and swap transactions are produced by the Jupiter Swap API (which splits and routes orders across the many DEXs and market makers on Solana), and the docker signs them with the configured private key and broadcasts them through a Solana node. Without a Jupiter API key the free lite-api.jup.ag is used; with one, api.jup.ag, and by default native limit orders and DCA with a USDC or USDT quote then switch to Jupiter Trigger V2, whose funds are deposited into a vault held in Jupiter's custody (no longer in the wallet's own on-chain order account); to keep the non-custodial v1, call exchange.IO("trigger.api", "v1") at the start of the strategy. See "Limit orders" and "DCA" below.

The same exchange object also provides concentrated liquidity on Meteora DLMM, Raydium CLMM and Orca Whirlpools pools (exchange.IO("lp.*", ...), see "Concentrated liquidity" below): the connector builds and signs the transactions itself and broadcasts them through a Solana node, with commands and result fields aligned with the LP commands of the Uniswap exchange object.

pump.fun launches (exchange.IO("pump.*", ...), see "Pump.fun launches" below): newly created coins are discovered on chain and quoted, bought and sold directly on the pump.fun bonding curve (the connector builds, simulates and signs the transactions itself); once a coin graduates to PumpSwap, trades go through Jupiter swaps automatically. New coins are extremely risky; see the risks in that section.

Names and Configuration

exchange.GetName(): Jupiter (Spot).

The rest of the longer descriptions in the table:

• Jupiter Api Key: Without it the free lite-api.jup.ag is used; with it api.jup.ag is used, the request rate can be raised according to your plan (see exchange.IO("rps", ...)), and native limit orders and DCA with a USDC or USDT quote switch by default to Jupiter Trigger V2 (funds deposited into a vault in Jupiter's custody, see "Limit orders" and "DCA"; to keep the non-custodial v1, call exchange.IO("trigger.api", "v1")). Get the key on the Jupiter developer platform; a key restricted by endpoint permissions must include Trigger.
• Liquidity Sources: Swap only through these liquidity sources, for example pump (the pump.fun bonding curve and PumpSwap), meteora, raydium, orca, or Jupiter source names; empty means all sources. It can be changed at run time with exchange.IO("dexes", ...).

Trading Pairs and Contract Codes

Pair examples: SOL_USDC, JUP_USDC, BONK_SOL

SOL is the native coin and is wrapped and unwrapped automatically during swaps. Built-in tokens: SOL, USDC, USDT, JUP, BONK, WIF, JTO, PYTH, RAY, JitoSOL, mSOL, JupSOL, TRUMP, PENGU, POPCAT. Other tokens can be written in three ways: by token name, resolved to the verified token with exactly that name in the Jupiter token list (an error is raised when several verified tokens share the name); by mint address; or after registering them with exchange.IO("token", ...). Pairs are not upper-cased (mint addresses and token names such as mSOL are case-sensitive), so write them as they are, for example DB5QKorV9KHY54y73h5xWQqYyuD8P3jC1p5Ea8DBpump_SOL.

Exchange-specific IO Commands

The rest of the longer descriptions in the table:

• lp.track: Positions of all three protocols are found by owner, so registering is normally unnecessary; the command is kept for parity with Uniswap, and positions created by lp.add in this process are remembered automatically. Looking up another wallet's Orca position uses the node's getTokenLargestAccounts to find the NFT holder (public nodes rate-limit it tightly).

For the common command currency see exchange.IO.

The common command api is not supported (the call fails with an error and returns null).

Function Support

Not supported (the call fails with an error and returns null): exchange.GetTickers, exchange.GetTrades, exchange.CreateConditionOrder, exchange.ModifyConditionOrder, exchange.CancelConditionOrder, exchange.GetConditionOrder, exchange.GetConditionOrders, exchange.GetHistoryConditionOrders.

Served through a fallback:

• exchange.GetRecords: Native periods are 1m, 5m, 15m, 1h, 4h, 12h, 1d (GeckoTerminal's timeframes); other periods of a minute or longer are synthesized by the docker, while second-level periods are unavailable (there is no trade feed to build them from).

Notes

• Request rate: Jupiter limits requests per second and returns 429 above the limit. The connector queues requests at the rate set with exchange.IO("rps", ...) (1 per second by default), and the exchange objects in one docker process that use the same Jupiter API address share this pace. With the default setting exchange.GetTicker() takes about 2 seconds and a 5-level exchange.GetDepth() about 10 seconds; for more speed, get a Jupiter API key and raise rps according to your plan.
• Fees: the Solana base fee and priority fee of each transaction (capped by exchange.IO("priorityFee", ...)) are deducted from the SOL balance, and the order's Info contains fee. The first time a token is bought, the wallet has to create an account for it, which takes a deposit of about 0.002 SOL; the deposit still belongs to the wallet and is not counted in the fill.

Pump.fun launches

exchange.IO("pump.*", ...) trades coins on the pump.fun bonding curve (program 6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P) directly, without Jupiter. Accounts, instructions and quote formulas follow pump.fun's official public documentation (the IDLs and docs of pump-fun/pump-public-docs on GitHub).

• New coins: pump.new discovers new coins on chain, and a strategy polls it in a loop (see the example below). Public nodes rate-limit per second and are slow (about 4 seconds for 20 transactions); for sniping, configure your own paid node in "Rpc Address".
• Only SOL-quoted coins are traded: pump.fun also has coins quoted in USDC or in another pump coin (quote of pump.new), for which pump.buy and pump.sell fail; cashback coins (no longer created) fail too and can be traded through Jupiter with exchange.Buy and exchange.Sell.
• Price protection: a buy is exact input (spending solAmount, fees included) with a minimum output of the local quote × (1 − slippage); a sell's minimum SOL output is the local quote × (1 − slippage). The default slippage is 5%, enforced on chain; when it cannot be met the whole transaction fails and only the network fee is charged.
• Fees: the protocol and creator fees follow the Pump Fees program's fee table, tiered by market cap (0.95% + 0.30% in October 2026; pump.info and pump.quote return the actual rates, and coins without a creator charge no creator fee), plus the Solana network and priority fees. The first buy of a coin creates its token account (a deposit of about 0.002 SOL, returned by default when pump.sell sells all and closes the account); a wallet's first pump.fun trade also creates its volume account (about 0.0018 SOL, not returned).
• Buying past the curve: when a buy's budget exceeds what the curve has left to sell (except on mayhem coins), the rest fills at the price of the PumpSwap pool the migration will create (pump.fun's "synthetic migration"), and crossesCurve of pump.quote is true; after that the curve cannot be traded until the migration happens. On mayhem coins a buy beyond what is left fails.
• Graduation: for coins whose curve is complete (complete), pump.buy and pump.sell swap through this exchange object's Jupiter at market instead (pair MINT_SOL, price protection by the call's slippage, which Jupiter requires to be below 0.5) and return venue jupiter; the priorityFee and computeUnitLimit options do not apply then (they fail), the priority fee cap is exchange.IO("priorityFee", ...), and dryRun is not available (quote with pump.quote, which goes to Jupiter for graduated coins as well). In the short time after a curve completes and before it migrates, both routes can fail.
• Every transaction is simulated by the node before sending and is not sent when the simulation fails, with the reason in the error (pump.fun error codes with their names, such as BuySlippageBelowMinTokensOut); broadcasting and deciding whether a transaction went out work as for swap orders, and waiting for confirmation works as for concentrated liquidity (an undecided outcome is reported as outcome is unknown with the signature, never as nothing happened).
• When sniping, pay enough priority fee (options.priorityFee), or under congestion the transaction may expire without being included.

Sniping loop example (JavaScript):

            javascript
            
            
var seen = {}
var start = Date.now()
while (true) {
    var coins = exchange.IO("pump.new", {limit: 20, since: start})
    for (var i = 0; coins && i < coins.length; i++) {
        var c = coins[i]
        if (seen[c.mint] || c.quote != "SOL" || c.mayhem) continue
        seen[c.mint] = true
        if (c.devBuy && c.devBuy.quoteAmount > 1) continue   // creator bought too much, skip
        var r = exchange.IO("pump.buy", c.mint, 0.01, {slippage: 0.2, priorityFee: 0.0005})
        if (r) Log("bought", r.tokenAmount, c.symbol, "for", r.solAmount, "SOL", r.txHash)
    }
    Sleep(1000)
}

Risks:

• Most new coins go to zero quickly; the creator or wallets bundled with it often buy in the creation transaction or the next few blocks and can dump at any moment (rug pull).
• Sniping bots and MEV compete hard: the order within a block depends on priority fees and tips, and a wide slippage invites sandwich attacks that fill at the worst price.
• The name, symbol and metadata link are whatever the creator chose and can impersonate well-known projects; go by the mint address.
• Protocol, creator, network and priority fees are paid on every buy and sell, so frequent in-and-out trading is costly.

Limit orders (tif gtc)

exchange.CreateOrder(symbol, side, price, amount, {tif: "gtc"}) (or exchange.Buy and exchange.Sell with the same order option) does not swap immediately but places a native Jupiter limit order, which Jupiter's keepers fill asynchronously once the price is reached. Without tif, or with another tif, orders behave as before (immediate swaps). There are two APIs:

With an API key the default is the custodial V2: the funds of an order leave the wallet for a vault in Jupiter's custody. To keep the non-custodial v1, call exchange.IO("trigger.api", "v1"); conversely exchange.IO("trigger.api", "v2") forces V2 even without an API key (Jupiter currently accepts V2 calls without a key, but its documentation requires one).

Jupiter has marked v1 as no longer developed (critical fixes only, no shutdown announced); new features go to V2. Existing v1 orders are not affected by the configuration and can still be queried and canceled (the shape of the order ID selects the API, regardless of trigger.api; V2 orders need the API key or trigger.api set to v2 to be queried, canceled or modified).

Common rules:

• Amounts: amount is in the base token; a buy gives amount × price of the quote token (rounded down to the smallest unit, never paying more), a sell gives amount of the base token (v1 also asks for amount × price of the quote token in return, rounded up, never receiving less). Market orders are not possible (a price of -1 or type market fails).
• Order extra parameters: expiry is the expiry timestamp in milliseconds; slippage is an allowed slippage ratio (such as 0.003). v1 defaults to 0 (exact fills at the limit price), and a slippage raises the fill rate at the cost of filling below the limit; V2 lets Jupiter set it automatically from market conditions by default, and a given slippage is used as a fixed value.
• States: open is pending, open with fills is partially filled, fully filled is filled, and canceled is canceled. Info is Jupiter's raw order row.
• Expiry: Jupiter does not close expired orders for you, and the funds stay locked until exchange.CancelOrder() withdraws them (v1 returns the principal and the order account's rent; V2 withdraws from the vault). An expired order that has not been canceled is therefore still pending (or partially filled), with Info.expired true and Info.note saying it must be canceled to get the funds back. Expired v1 orders are still listed by exchange.GetOrders() (Jupiter keeps them open); Jupiter files expired V2 orders under history, so they are not in exchange.GetOrders() but are found by exchange.GetOrder() and exchange.GetHistoryOrders(). After the cancel withdraws the funds the order is canceled.
• Canceling: for an order already filled or canceled exchange.CancelOrder() returns false with the reason in GetLastError().
• Every exchange.GetOrders() call requests Jupiter's v1 limit order list once (and the V2 list once more when an API key is set), paced by exchange.IO("rps", ...).
• Token-2022 tokens with the transfer fee or transfer hook extension cannot be used in limit orders (Jupiter does not support them).
• Use exchange.IO("trigger.simulate", ...) to simulate an order before placing it.

Trigger v1:

• Placing and canceling are on-chain transactions signed by the connector and broadcast through a Solana node; when the node's preflight simulation fails nothing is sent and the call fails. Each pays a Solana transaction fee and priority fee, and the first order in a token may create token accounts, whose deposits remain the wallet's. Canceling waits for the broadcast only; confirm the result with exchange.GetOrder().
• Fees: Jupiter deducts its fee from the token received (0.03% for stable pairs and 0.1% otherwise per its documentation; each fill record is authoritative). The order's AvgPrice is before fees, and the amounts actually received are in trades of Info.
• exchange.GetOrder() looks in the open orders and then in the history; an order this program has just placed that Jupiter has not indexed yet is reported from its on-chain state (an existing order account means open).

Trigger V2:

• Authentication: the connector signs Jupiter's login challenge with the wallet's private key (only a message that starts with Jupiter's fixed login text and names this wallet) for a 15-minute access token, refreshed automatically and kept in memory only. A leaked token cannot move funds (withdrawals need a transaction signed by the wallet) but can cancel orders and change their prices.
• Placing: the connector looks up the wallet's vault and registers one if there is none (this creates a custodial account for the wallet at Jupiter; exchange.IO("trigger.vault", "register") does it ahead of time); it then has Jupiter build the deposit transaction and checks it instruction by instruction (the wallet pays the fee, only the System, Token, Associated Token Account, Compute Budget and Memo programs are called, the tokens leaving the wallet go only to the vault side and add up to exactly the order amount, and the only accounts created with the wallet's rent are the order's input account handed to the vault (Jupiter creates it with CreateAccountWithSeed based on the vault, and closes it after a cancel or fill with the rent returned to the wallet) and associated token accounts of the wallet and the vault), signs it, simulates it with the node first (nothing is sent and the call fails when the simulation fails), and hands it to Jupiter with the order parameters; Jupiter lands the deposit during that call and returns the order UUID. If that call fails the deposit may already have landed: the error names the deposit transaction signature; check it with exchange.IO("receipt", ...) and exchange.IO("trigger.vault") before retrying.
• Trigger: a buy buys when the base token's USD price falls to price or below, a sell sells when it rises to price or above. The quote token is taken as 1 USD (if USDC or USDT depegs, the trigger drifts accordingly). Jupiter does not check whether the price makes sense: a buy above or a sell below the market fills at once at the market rate.
• Amounts and fills: the order's Amount is the base token deposited for a sell and the quote token deposited ÷ price for a buy; DealAmount and AvgPrice come from the amounts actually used and received (the fee is already taken from the amount received and not listed separately on V2).
• Modifying: exchange.ModifyOrder() changes only the price (and slippage), only for an open single order that has not started filling, and not the trigger price of a trailing order; the amount is fixed by the deposit and cannot change (an amount passed in must equal the original). A buy keeps the quote amount it spends when its price changes, so its Amount becomes amount ÷ new price.
• Canceling takes two steps: Jupiter stops the order (no more fills from then on) and builds a withdrawal transaction, which the connector checks (the wallet only pays the fee) and signs; Jupiter adds the vault's signature and lands it, and the unfilled tokens return to the wallet. If the second step fails the order waits for withdrawal (still listed by exchange.GetOrders()), and canceling it again completes the withdrawal. Expired orders are withdrawn with exchange.CancelOrder() too.
• Custody risk: while an order is open its funds are in Jupiter's Privy-held vault, not in the wallet; they are not counted by exchange.GetAssets() (see exchange.IO("trigger.vault")). Withdrawals depend on Jupiter building the withdrawal transaction and co-signing it, so they cannot be done alone while Jupiter's service is down. Jupiter still labels the V2 API beta, and its behavior may change.
• Fees: the wallet pays the network fees of the deposit and withdrawal transactions; fills are executed by Jupiter's keepers, who pay their network fees, and Jupiter's swap fee is already taken from the amount received. There is no integrator fee.
• Requests: queries and orders authenticate first (the token is cached in the process), using one or two extra requests of the rate limit; an API key restricted by endpoint permissions must include Trigger, otherwise those calls fail with 403.
• The order functions list all V2 limit orders of the wallet, including those placed elsewhere such as on jup.ag (each take-profit, stop-loss or OCO leg is listed as one order priced at its USD trigger, with the direction in triggerCondition of Info). An order that triggers on a USD price but is not quoted in USDC or USDT, or that does not trigger on the base token's price, cannot be expressed as a price of its pair, and queries that meet it fail (a query for a given pair only looks at that pair's orders).

DCA

exchange.IO("dca.create", ...), dca.list, dca.cancel and dca.simulate: with an API key and a USDC or USDT quote new DCA orders use Jupiter Trigger V2 DCA by default (custodial vault; exchange.IO("trigger.api", ...) applies as well: v1 keeps Recurring v1, v2 forces V2), otherwise the Recurring API v1 (time-based DCA, program DCA265Vj8a9CEuX1eb1LWRnDT7uK6q1xMipnNyatn23M). Jupiter no longer maintains Recurring v1 (it still works); DCA has moved into Trigger V2. dca.list lists both (V2 needs the API key), and dca.cancel tells v1 (an address) from V2 (a UUID) by the shape of the DCA ID. DCA orders do not appear in exchange.GetOrders() and the other order functions.

• v1: the total is deposited into a DCA order account at once, Jupiter's keepers swap one installment every interval seconds, and the bought tokens are sent back to the wallet. At least 2 installments, each worth at least 50 USD; Token-2022 tokens are not supported; Jupiter takes a 0.1% fee from the tokens received. Creating and canceling are on-chain transactions with transaction and priority fees; canceling returns the remaining tokens to the wallet. Jupiter takes a few minutes to index a new DCA order; meanwhile dca.list lists the orders this program just created from their on-chain accounts (indexed: false), and dca.cancel cancels them all the same.
• V2: authentication, the vault, the deposit and the custody risk are as for V2 limit orders above. The total is deposited into the vault and the keepers swap one installment per round, sending the tokens received straight to the wallet and paying the network fees; slippage is set automatically by Jupiter from market conditions and cannot be specified; the fee is already taken from the amount received. At least 2 installments, each worth at least 10 USD, an interval of 60 seconds to 1 year, a start at most 30 days ahead, and at most 10 running DCA orders per wallet. With minPrice or maxPrice a round swaps only while the base token's USD price is in the range, and a round outside it moves to the next interval. DCA orders cannot be modified; canceling takes two steps (as for V2 limit orders), and rounds already filled are not reversed.

Concentrated liquidity (LP)

The exchange.IO("lp.*", ...) commands provide concentrated liquidity on Meteora DLMM pools (program LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo), Raydium CLMM pools (program CAMMCzo5YL8w4VFF8KVHrK22GGUsp5VTaW7grrKgrWqK) and Orca Whirlpools pools (program whirLbMiicVdio4qvUfM5KAg6Ct8VwpYzGff3uctyCc; how these two differ from DLMM is below): pool selection, planning and simulation, adding, increasing and decreasing, collecting fees and farm rewards, withdrawal and position queries. Command names, parameters and result fields follow the lp.* commands of the Uniswap exchange object, with these differences:

• Prices are discretized into bins rather than ticks: bin i has price (1 + binStep/10000)^i (scaled by the two tokens' decimals), ranges are given as lowerBinId and upperBinId (both inclusive), and the bin holding the current price is activeId; range may be written {bins: [lo, hi]}. The active bin holds both tokens, bins above it only X and bins below only Y, so the shape of a position is how much goes into each bin (spot, curve, bidask).
• A position is an account, not an NFT: its id is meteora:position address (the bare address is accepted too); a position holds at most 70 bins, and wider spot ranges are split into several positions.
• Rent: each position account locks its rent-exempt minimum (from the node's getMinimumBalanceForRentExemption, about 0.042 SOL in October 2026), returned when lp.remove withdraws everything and closes it; bin array accounts (70 bins each) missing in the range are created first, and their rent (about 0.052 SOL each in October 2026) is not returned. rentSol, rentRefundableSol and binArraysToCreate of the plan give these amounts. Holding a token for the first time also creates a token account (about 0.0015 SOL, still the wallet's).
• SOL is wrapped and unwrapped automatically: when one side of the pool is SOL, the transaction wraps the SOL to deposit into wSOL and closes the wallet's wSOL account at the end (wSOL already in the wallet turns back into SOL as well).
• Swaps go through this exchange object's Jupiter swaps (market orders, slippage per exchange.IO("slippage", ...)).
• Every write transaction is simulated by the node before sending and is not sent when the simulation fails, with the reason in the error (DLMM, Raydium CLMM and Orca Whirlpool error codes with their names). The compute-unit limit is the simulated usage plus headroom, and the priority fee is the 75th percentile of recent fees paid by transactions writing the same accounts, capped by exchange.IO("priorityFee", ...). Broadcasting and the "may it have been sent" judgment are those of swap orders; commands return after confirmation, with actual amounts from the balances before and after the transaction. While waiting, every node is asked for the transaction status, and a transaction is reported expired (expired without being included … nothing happened, it really did not run) only when some nodes block height is past its last valid block height and a node past that point does not know it; a lagging or failing node never makes it look expired. When it is neither confirmed nor provably expired within 120 seconds the error says outcome is unknown and carries the signature: it may have landed, so check it with exchange.IO("receipt", signature) before retrying. When a nodes preflight reports BlockhashNotFound (it has not seen the blockhash yet; nothing was sent) the transaction is signed again with a fresh blockhash and resent, up to 2 times.
• Withdrawals have no minimum-output protection: DLMM withdraws the position's share of each bin, so the amounts depend on the bins' composition at that moment.
• Token-2022 tokens with a transfer hook are not supported, nor are positions whose fees go to another wallet (feeOwner); there is no lp.history, lp.stake, lp.unstake or lp.claim (farm rewards are claimed by lp.collect, lp.decrease and lp.remove).
• lp.positions finds positions by owner with the node's getProgramAccounts; the official public node serves it, some nodes do not or rate-limit it, and then the call fails. Public nodes rate-limit per second and the connector backs off and retries; for frequent queries configure your own node.

How Raydium CLMM and Orca Whirlpools differ from DLMM above (they use the same tick model as Uniswap V3):

• Prices are discretized into ticks: tick i has price 1.0001^i (scaled by the two tokens' decimals), a position covers [tickLower, tickUpper), and both ends are multiples of the pool's tick spacing (tickSpacing); a position in range holds both tokens, one out of range holds one. Shapes and layers are those of the Uniswap exchange object: curve and bidask consist of several positions.
• A position is an NFT: its id is raydium:NFT mint or orca:NFT mint (the bare mint or the position account address is accepted too); whoever holds the NFT owns the position. lp.positions finds positions from the NFTs with amount 1 in the wallet and needs no getProgramAccounts. Token-2022 tokens with a transfer hook are not supported.
• Raydium: new positions are Token-2022 NFTs, and opening creates no metadata to keep the deposits minimal: rent for the position account, the NFT mint and the NFT account (about 0.0053 SOL together in October 2026), all returned when lp.remove closes the position. The TickArrays (60 tick spacings each) at the two ends of the range are created by the opening transaction when missing, and their rent (about 0.072 SOL each in October 2026) is not returned; tickArraysToCreate of the plan lists them. Adding and increasing fix the amount of one token (the SOL side first, otherwise the more valuable side) and cap the other at the planned amount × (1 + slippage); when a price move pushes the other token beyond the cap the program fails with PriceSlippageCheck and nothing is sent. Withdrawals require at least the amounts at the current price × 0.99. Every initialized reward of the pool (even an ended one) is settled with each withdrawal or collection, and the reward tokens' ATAs are created first. Ticks beyond the pool's built-in range need the pool's TickArray bitmap extension account, and its absence is an error. Looking up a single position that is not in this wallet (lp.track) finds the NFT's holder by mint with the node's getProgramAccounts (the official public node serves it).
• Orca: new positions use a Token-2022 NFT (with the metadata extension, as the official Orca SDK does); older SPL Token NFT positions and positions in a Position Bundle can be queried, increased, decreased, collected and closed as well. Each position locks the rent-exempt minimums of the position account, the NFT mint and the NFT token account plus the rent of two ticks (about 0.0084 SOL in all in October 2026), all returned when lp.remove closes it; a tick array (covering 88 tick spacings) missing at either end of the range is first created as a dynamic tick array, and its rent (about 0.0019 SOL each) is not returned. Adding liquidity passes the two token amounts on chain as maxima (increase_liquidity_by_token_amounts_v2), and the program adds the most liquidity they allow at the execution price, failing when the price is outside the bounds implied by slippage; withdrawals are protected by minimum amounts (those estimated at the current price less 1%). Decreasing or closing a locked position (lock_position) fails in simulation; only the main program deployment is supported (not Orca's immutable deployment). Pool statistics come from Orca's public API (api.orca.so); looking up a position that is not in this wallet finds the NFT holder with the node's getTokenLargestAccounts (public nodes rate-limit it tightly).

Monitoring and exits are left to the strategy: lp.positions reports whether each position is in range, its current value and uncollected fees, and the strategy decides when to rebalance or stop out.

Risks:

• Impermanent loss: the further the price moves from the entry, the lower the position is worth compared with simply holding; as the price rises the position sells X bin by bin, and as it falls it buys X.
• Once the price leaves the range the position holds a single token and earns no fees until the price returns.
• Rent locked when opening: the position account's rent (and the NFT's on Raydium and Orca) comes back on withdrawal, new bin arrays' and TickArrays' rent does not; a plan split into several positions locks rent for each.
• Every add, adjustment, collection and withdrawal is an on-chain transaction with fees and priority fees; frequent rebalancing can cost more than it earns.
• The estimated daily fees in a plan come from the past 24h volume and the plan's current share of the active bin; they do not predict future income.

Cross-chain bridge

exchange.IO("bridge.*", ...) bridges tokens from this exchange object's chain to another chain through the bridges LI.FI aggregates (Across, Stargate, CCTP, deBridge, Mayan, Relay, NEAR Intents and more), between EVM chains and between EVM and Solana (from Solana). LI.FI supplies the quote and transaction, as a serialized transaction that the docker signs, simulates with simulateTransaction and broadcasts. Requests carry the integrator tag integrator=fmz and add no fee; fees in a quote such as LIFI Fixed Fee are LI.FI's and the bridges' own and are already deducted from toAmount.

Typical flow: bridge.quote for a quote → bridge.simulate to simulate → bridge.send to send → bridge.status every 10 to 30 seconds until DONE or FAILED.

• Bridging is asynchronous: when bridge.send returns, only the source-chain transaction has been broadcast; delivery takes seconds to tens of minutes (see executionDuration in the quote) and must be confirmed by polling bridge.status; PARTIAL means a different token arrived on the destination chain and REFUNDED that the funds went back to the source chain.
• Cross-VM transfers (EVM↔Solana) require toAddress, checked against the destination chain's address format; funds sent to a wrong address cannot be recovered.
• Risks: the security of bridge contracts and cross-chain messaging rests with each bridge; quotes move, and bridge.send re-quotes before sending; the destination wallet needs gas to use what arrives. Test with a small amount first.
• Rate limits: without an API key LI.FI limits by outgoing IP, /quote to 75 requests per 2 hours (bridge.quote, bridge.simulate and bridge.send use one each) and other endpoints to 100 per minute; strategies on the same docker share the quota. With a key set through exchange.IO("bridge.apiKey", key) the limit is 100 per minute. A rate-limited call fails with rate limited (HTTP 429 …).

Strategy examples

Complete runnable strategies: Jupiter Limit-Order Grid (native limit orders), DEX Dollar-Cost Averaging (native DCA), pump.fun Sniping Strategy and DEX-CEX Arbitrage; see DEX Strategy Examples.

In this sectionRead the whole section