cabal/docs
How Cabal uses Jupiter for Solana token swaps, price lookups, and limit orders.

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:

  1. 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.
  2. 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.
  3. 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.
  4. Recording -- The trade is persisted with quote, submission, and confirmation events. If the agent is in Suggest Only mode, it uses trade_propose_swap instead, which creates the trade record in an awaiting_approval state 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_ACCOUNT and JUPITER_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