Jupiter
Jupiter is the default swap venue for Solana. When your agent quotes, simulates, or executes a token swap on Solana, it routes through Jupiter's aggregated liquidity unless you explicitly choose a different venue.
What it provides
- Token swaps -- Aggregated routing across Solana DEXs. Jupiter finds the best path across available liquidity pools and returns a single transaction.
- Price lookups -- Real-time USD prices for any Solana token mint, used by the agent for balance valuations and trade sizing.
- Token search and metadata -- Name, symbol, decimals, holder count, market cap, liquidity, verification status, and 24h volume stats for any Solana token.
- Limit orders -- Price-triggered orders through Jupiter's Trigger API. The agent deposits funds into a Jupiter vault and the order executes when the trigger condition is met.
Swaps
When the agent calls trade_swap or trade_propose_swap on the Solana chain, the flow is:
- Quote -- The agent requests a quote from Jupiter with the input mint, output mint, amount, and optional slippage. Jupiter returns a route plan showing which pools it will use and the expected output.
- Guardrail checks -- If the agent runs under a Guarded control profile, Cabal checks the quote against your guardrails: max trade size, max price impact, allowed programs, and blocked addresses. The transaction instructions are fetched and inspected before signing.
- Execution -- Cabal signs the transaction with your Privy-managed wallet and submits it to Solana via Helius. After confirmation, Cabal fetches the actual input and output amounts from the on-chain transaction.
- Recording -- The trade is persisted with quote, submission, and confirmation events. If the agent is in Suggest Only mode, it uses
trade_propose_swapinstead, which creates the trade record in anawaiting_approvalstate for you to approve.
Dynamic slippage is enabled by default. Jupiter adjusts slippage based on simulated execution, so you do not need to set it manually unless you have a specific tolerance.
Limit orders
Cabal manages Jupiter Trigger limit orders through its own lifecycle. You can place, list, and cancel them through the agent.
trade_place_limit_order-- Place a price-triggered order. You specify the input token, output token, amount, trigger mint, trigger condition (above or below a USD price), and an expiration timestamp. The agent authenticates with Jupiter's Trigger API, deposits funds into a vault, and opens the order.trade_get_limit_orders-- List your Cabal-managed limit orders. You can filter by status and optionally refresh from Jupiter's order history.trade_cancel_limit_order-- Cancel an open order. Cabal signs the cancellation and confirms the vault withdrawal.
Limit orders have the following statuses as they move through their lifecycle: opening, pending, open, executing, partially_filled, filled, expired, cancel_pending, cancelled, failed.
In Suggest Only mode, the agent uses trade_propose_limit_order instead, which queues the order for your approval before opening it.
Venue selection
Solana swaps default to Jupiter. To use a different venue, the agent or tool call can specify the venue parameter. Currently supported venues are jupiter (default) and meteora (for tracked Meteora launch pairs with referral-aware routing).
Configuration
Jupiter requires no special setup from you. Cabal connects to the Jupiter API automatically using the platform's API key. The relevant environment bindings are:
JUPITER_API_KEY-- Platform-level API key for Jupiter quote and Trigger API access.JUPITER_FEE_ACCOUNTandJUPITER_FEE_BPS-- Optional platform fee configuration. When set, Jupiter applies a platform fee on swaps and routes a share to the configured fee account.
You do not configure these yourself -- they are platform-managed.
Guardrails
Your agent's guardrails apply to Jupiter swaps the same way they apply to any Solana trade:
- Max trade size -- Rejects swaps where the input amount exceeds your configured limit.
- Max price impact -- Rejects swaps where price impact exceeds your configured percentage.
- Allowed programs -- When set, Cabal fetches the swap instructions before signing and checks that every program in the transaction is on your allow list.
- Blocked addresses -- When set, Cabal checks that no writable account in the transaction matches your block list.
- Execution guardrails -- For background runs (routines, watches), additional per-run trade value limits apply when configured.
Swaps that fail a guardrail check are recorded as rejected with the specific check that failed.
See also
- -- set execution limits
- -- configure agent bindings and venues