Jupiter Plugin Demo

); } ``` ```tsx Next.js theme={null} "use client"; import { useEffect } from "react"; import Script from "next/script"; export default function SwapPage() { return ( <>

Jupiter Plugin Demo

``` ## Step 3: Run the Project Run the project using `http-server`: ```bash theme={null} http-server ``` There you have it! You've successfully integrated Jupiter Plugin into your HTML application. * Please test the swap functionality and check the transaction. * If you require more customizations, check out the [Plugin Playground](https://plugin.jup.ag) or the [Customization](/docs/tool-kits/plugin/customization) documentation. * If you have any questions or issues, please refer to the [FAQ](/docs/tool-kits/plugin/faq) or contact us on [Discord](https://discord.gg/jup). # Integrate Jupiter Plugin Source: https://dev.jup.ag/docs/tool-kits/plugin/index Seamlessly integrate end-to-end Ultra Swap functionality into any application with just a few lines of code. Jupiter Plugin is an open-source, lightweight, plug-and-play version of Jupiter Ultra Swap, allowing you to bring the exact jup.ag swap experience to any application. Try out the [Plugin Playground](https://plugin.jup.ag/) to experience the entire suite of customizations. To view the open-source code, visit the [GitHub repository](https://github.com/jup-ag/plugin).

**QUICK START** To quick start your integration, check out the [Next.js](/docs/tool-kits/plugin/nextjs-app-example), [React](/docs/tool-kits/plugin/react-app-example) or [HTML](/docs/tool-kits/plugin/html-app-example) app examples. Refer to [Customization](/docs/tool-kits/plugin/customization) and [FAQ](/docs/tool-kits/plugin/faq) for more information. ## Key Features * **Seamless Integration**: Embed Jupiter's swap functionality directly into your application without redirects. * **Multiple Display Options**: Choose between integrated, widget, or modal display modes. * **Customizable Options**: Configure the swap form to match your application's needs. * **RPC-less**: Integrate Plugin without any RPCs, Ultra handles transaction sending, wallet balances and token information. * **Ultra Mode**: Access to all features of Ultra Mode, read more about it in the [Ultra Swap API docs](/docs/ultra/). ## Getting Started When integrating Plugin, there are a few integration methods to think about, and choose the one that best fits your application's architecture and requirements. ### Integration Methods * **Using Window Object** - Simplest way to add and initialize Plugin. * [**Using NPM Package**](https://www.npmjs.com/package/@jup-ag/plugin) - Install via `npm install @jup-ag/plugin` and initialize as a module (will require you to maintain its dependencies). ### Wallet Integration * **Wallet Standard Support**: For applications without existing wallet provider, Plugin will provide a wallet adapter and connection - powered by [Unified Wallet Kit](/docs/tool-kits/wallet-kit/). * **Passthrough Wallet**: For applications with existing wallet provider(s), set `enableWalletPassthrough=true` with context, and Plugin will allow the application to pass through the existing wallet provider's connection to Plugin. ### Adding Fees to plugin * **Referral Account**: You can create a referral account via [scripts](/docs/ultra/add-fees-to-ultra) or [Referral Dashboard](https://referral.jup.ag/). * **Referral Fee**: You can set the referral fee and account in the `formProps` interface when you initialize the Plugin. ### Quick Start Guides In the next sections, we'll walk you through the steps to integrate Jupiter Plugin into different types of web applications from scratch. By integrating Jupiter Plugin into your application, you can seamlessly integrate a fully functional swap interface into your application with minimal effort, while staying at the forefront of Solana DeFi innovation. # Next.js App Example Source: https://dev.jup.ag/docs/tool-kits/plugin/nextjs-app-example Step-by-step guide to integrate Jupiter Plugin into a Next.js application. This guide walks through integrating Jupiter Plugin into a Next.js application from scratch. It covers both App Router and Pages Router setups, TypeScript declarations, and two initialization methods: the window object approach and the `@jup-ag/plugin` npm package. ## Prerequisites Before you begin, make sure you have the following installed on your system. **Node.js and npm**: Download and install from [nodejs.org](https://nodejs.org) ## Step 1: Create a New Next.js Project Head to your preferred directory and create a new Next.js project using `create-next-app` with TypeScript template (you can use other templates or methods to start your project too): ```bash theme={null} npx create-next-app@latest plugin-demo --typescript cd plugin-demo npm run dev ``` ## Step 2: Add TypeScript Support Create a type declaration file `plugin.d.ts` in your project's `/src/types` folder: ```js theme={null} declare global { interface Window { Jupiter: JupiterPlugin; } }; export {}; ``` ```js theme={null} declare global { interface Window { Jupiter: JupiterPlugin; } } export type WidgetPosition = 'bottom-left' | 'bottom-right' | 'top-left' | 'top-right'; export type WidgetSize = 'sm' | 'default'; export type SwapMode = "ExactInOrOut" | "ExactIn" | "ExactOut"; export type DEFAULT_EXPLORER = 'Solana Explorer' | 'Solscan' | 'Solana Beach' | 'SolanaFM'; export interface FormProps { swapMode?: SwapMode; initialAmount?: string; initialInputMint?: string; initialOutputMint?: string; fixedAmount?: boolean; fixedMint?: string; referralAccount?: string; referralFee?: number; } export interface IInit { localStoragePrefix?: string; formProps?: FormProps; defaultExplorer?: DEFAULT_EXPLORER; autoConnect?: boolean; displayMode?: 'modal' | 'integrated' | 'widget'; integratedTargetId?: string; widgetStyle?: { position?: WidgetPosition; size?: WidgetSize; }; containerStyles?: CSSProperties; containerClassName?: string; enableWalletPassthrough?: boolean; passthroughWalletContextState?: WalletContextState; onRequestConnectWallet?: () => void | Promise; onSwapError?: ({ error, quoteResponseMeta, }: { error?: TransactionError; quoteResponseMeta: QuoteResponse | null; }) => void; onSuccess?: ({ txid, swapResult, quoteResponseMeta, }: { txid: string; swapResult: SwapResult; quoteResponseMeta: QuoteResponse | null; }) => void; onFormUpdate?: (form: IForm) => void; onScreenUpdate?: (screen: IScreen) => void; } export interface JupiterPlugin { _instance: JSX.Element | null; init: (props: IInit) => void; resume: () => void; close: () => void; root: Root | null; enableWalletPassthrough: boolean; onRequestConnectWallet: IInit['onRequestConnectWallet']; store: ReturnType; syncProps: (props: { passthroughWalletContextState?: IInit['passthroughWalletContextState'] }) => void; onSwapError: IInit['onSwapError']; onSuccess: IInit['onSuccess']; onFormUpdate: IInit['onFormUpdate']; onScreenUpdate: IInit['onScreenUpdate']; localStoragePrefix: string; } export { }; ``` ## Step 3: Embed the Plugin Script For Next.js applications, you can add the script in two ways: ### Using App Router (Next.js 13+) In your `app/layout.tsx`: ```js theme={null} import Script from "next/script"; export default function RootLayout({ children, }: { children: React.ReactNode; }) { return ( ``` ## Step 4: Initialize Plugin There are two ways to initialize Jupiter Plugin in a React application: ### Method 1: Using Window Object In your `/src/App.tsx`, use the following code to initialize the plugin. ```bash theme={null} import React, { useEffect } from 'react'; import './App.css'; import './types/plugin.d'; export default function App() { useEffect(() => { // Initialize plugin window.Jupiter.init({ displayMode: "widget", integratedTargetId: "jupiter-plugin", }); }, []); return (

Jupiter Plugin Demo

); } ``` ### Method 2: Using @jup-ag/plugin Package **WARNING** Do note that using this method will require you to maintain its dependencies. Install the package: ```bash theme={null} npm install @jup-ag/plugin ``` Initialize the plugin: ```bash theme={null} import React, { useEffect } from "react"; import "@jup-ag/plugin/css"; import "./App.css"; import "./types/plugin.d"; export default function App() { useEffect(() => { import("@jup-ag/plugin").then((mod) => { const { init } = mod; init({ displayMode: "widget", integratedTargetId: "jupiter-plugin", }); }); }, []); return (

Jupiter Plugin Demo

); } ``` There you have it! You've successfully integrated Jupiter Plugin into your Next.js application. * Please test the swap functionality and check the transaction. * If you require more customizations, check out the [Plugin Playground](https://plugin.jup.ag) or the [Customization](/docs/tool-kits/plugin/customization) documentation. * If you have any questions or issues, please refer to the [FAQ](/docs/tool-kits/plugin/faq) or contact us on [Discord](https://discord.gg/jup). # Referral Program Source: https://dev.jup.ag/docs/tool-kits/referral-program Earn on-chain fees from user trades through the open-source Jupiter Referral Program. The Referral Program is an open-source on-chain program that lets developers earn fees through Jupiter API integrations. It supports Swap API, Trigger API, and Plugin. Any Solana program can also integrate the Referral Program to share revenue with its own integrators. **REFERRAL PROGRAM SOURCE CODE** [Open Source Repository](https://github.com/TeamRaccoons/referral): To understand and make use of the referral program better. ## Jupiter API Integrators The Jupiter Programs use the Referral Program to allow developers to earn fees when integrating with Jupiter. Below are some resources to help you quickly get started. There are a different ways to setup such as via the Jupiter Referral Dashboard or using the provided scripts. * [Jupiter Referral Dashboard](https://referral.jup.ag/): To view and manage your referral accounts used with Jupiter APIs. * [Add Fees to Swap API](/docs/swap/order-and-execute#fees): To add fees to your Swap API integration. * [Add Fees to Jupiter Plugin](/docs/tool-kits/plugin#adding-fees-to-plugin): To add fees to your Plugin integration. ## Other Program Integrators ### Project Usage If you have a project/product that runs a program on the Solana blockchain, you can integrate the Referral Program to allow/share revenue with the integrators of your program. Similar to how Jupiter Programs uses the Referral Program to help developers earn fees and/or share the revenue with Jupiter. For example, Jupiter Ultra uses the Jupiter Swap program which relies on the Referral Program. * Create a `Project` by calling `initialize_project` with your chosen `base` key and a project `name` (`base` key refers to a key identifier of your project). * Set a `default_share_bps` to share the fees with your referrers (or integrators). * An example of a `Project` account: [Jupiter Ultra Project](https://solscan.io/account/DkiqsTrw1u1bYFumumC7sCG2S8K25qc2vemJFHyW2wJc) ### Referrer Usage If you are a referrer such as a developer or integrator of a project that runs a program on the Solana blockchain, you can create the necessary accounts via the Referral Program to earn fees. * The program must be integrated with the Referral Program. * Create a `Referral` account by calling `initialize_referral_account` with the correct `Project` account, the `Referral` account, and your own `Partner` account (`Partner` account is the admin of this referral account). * Create the necessary `Referral` token accounts for the `Referral` account to receive fees in. # Integrate Wallet Kit Source: https://dev.jup.ag/docs/tool-kits/wallet-kit/index Integrate Jupiter Wallet Kit into your application to simplify wallet connectivity across all Solana wallets, all in a unified wallet interface The Jupiter Wallet Kit is an open-source, Swiss Army Knife wallet adapter designed to streamline your development on Solana by eliminating redundancies and providing wallet adapter building blocks in a simple, plug-and-play package. This allows developers to focus on what matters most: building innovative features for your users. ## Overview * Creating a wallet notification system. * Managing wallet states (connected, disconnected, etc). * Implementing a mobile-friendly wallet connector. * Support for 20+ wallet adapters via a unified interface. * Support for all wallets built with [Solana's Wallet Standard](https://github.com/anza-xyz/wallet-standard). * Support for [Jupiter Wallet Extension](/docs/tool-kits/wallet-kit/jupiter-wallet-extension). * Support for [Jupiter Mobile Adapter QR code login](/docs/tool-kits/wallet-kit/jupiter-mobile-adapter). To play with different settings,features and styling. To understand and make use of the wallet adapter better. To reference code snippets and examples. ## Technical Features | Feature | Description | | :---------------------------- | :------------------------------------------------------------------------------------------------------------------- | | **Compact Bundle** | Main ESM bundle is a lightweight 94KB (20KB gzipped). | | **Built-in Support** | Comes with Wallet Standard and Mobile Wallet Adapter support. | | **Abstracted Wallet Adapter** | Use the Bring Your Own Wallet (BYOW) approach to select custom and legacy wallets. | | **Mobile Responsive** | Designed to be mobile-first. | | **Smart Notification System** | Integrates seamlessly with your existing notification system or can be used independently. | | **Internationalization** | Supports multiple languages including English, Chinese, Vietnamese, French, Japanese, Bahasa Indonesia, and Russian. | | **Theming Options** | Choose from light, dark, and Jupiter modes, with more customization options coming soon. | | **New User Onboarding** | Simplifies the onboarding process for new users. | # Jupiter Mobile Adapter Source: https://dev.jup.ag/docs/tool-kits/wallet-kit/jupiter-mobile-adapter Integrate Jupiter Mobile QR code login into your app with WalletConnect support. The Jupiter Mobile Adapter lets users connect to your application by scanning a QR code with Jupiter Mobile. It uses the `@jup-ag/jup-mobile-adapter` package and Reown's AppKit for WalletConnect integration. This guide covers installation, Reown project ID setup, and adding the adapter to Wallet Kit. The Jupiter Mobile Adapter allows you to integrate Jupiter Mobile login functionality into your app! By allowing Jupiter Mobile users to simply use the app to scan a QR code to login, they can utilize their wallets on Jupiter Mobile across any platform. ## Overview Install [@jup-ag/jup-mobile-adapter](https://www.npmjs.com/package/@jup-ag/jup-mobile-adapter) Use `useWrappedReownAdapter` (Prerequisite to create an app id on [https://dashboard.reown.com/](https://dashboard.reown.com/)) Add the `jupiterAdapter` to wallets ## Prerequisite Building on top of the example in [Jupiter Wallet Extension example](/docs/tool-kits/wallet-kit/jupiter-wallet-extension), we will pass in the Jupiter Mobile Adapter (which uses Reown's AppKit). ## Step 1: Install dependency You will need to install the following dependency: ```bash theme={null} npm i @jup-ag/jup-mobile-adapter ``` ## Step 2: Get Reown project ID You need to input the project ID on from your [Reown's dashboard](https://dashboard.reown.com/), before you can use the Jupiter Mobile Adapter. This project ID is required for the AppKit integration that powers the mobile wallet connection functionality. To get your project ID: 1. Visit [https://dashboard.reown.com/](https://dashboard.reown.com/) 2. Sign up or log in to your account 3. Create a new project 4. Copy the project ID from your project settings (should be in the navbar) ## Step 3: Add Jupiter Mobile Adapter to wallets In your `/src/app/page.tsx` file, add the Jupiter Mobile Adapter as a wallet. ```js expandable theme={null} "use client"; import { Adapter, UnifiedWalletButton, UnifiedWalletProvider } from "@jup-ag/wallet-adapter"; import { useWrappedReownAdapter } from '@jup-ag/jup-mobile-adapter'; import { WalletNotification } from "../components/WalletNotification"; import { useMemo } from "react"; export default function Home() { // Initialize Jupiter Mobile Adapter with WalletConnect/Reown configuration // This adapter enables mobile wallet connections through WalletConnect protocol const { jupiterAdapter } = useWrappedReownAdapter({ appKitOptions: { metadata: { name: 'Jupiter Wallet Kit Demo', description: `This is a Jupiter Wallet Kit Demo with Jupiter Mobile Adapter`, url: 'https://localhost:3000', icons: ['https://jup.ag/favicon.ico'], }, projectId: '', // Get your project id from https://dashboard.reown.com/ features: { analytics: false, socials: ['google', 'x', 'apple'], email: false, }, // Disable built-in wallet list to use only Jupiter Mobile Adapter enableWallets: false, }, }); // Configure wallet adapters for the UnifiedWalletProvider // This memoized array includes the Jupiter Mobile Adapter and filters out any invalid adapters // The filter ensures each adapter has required properties (name and icon) before being used const wallets: Adapter[] = useMemo(() => { return [ jupiterAdapter, // Jupiter Mobile Adapter with WalletConnect integration ].filter((item) => item && item.name && item.icon) as Adapter[]; }, []); return (

Jupiter Mobile Adapter Demo

Connect your Solana wallet to get started

); }; ``` There you have it! You've successfully integrated Jupiter Wallet Kit into your Next.js application and able to connect the Jupiter Mobile Adapter! * Please test the wallet functionality and build into your own application. * If you require more customizations, check out the [Wallet Kit Playground](https://wallet-kit.jup.ag) or [Github repo](https://github.com/TeamRaccoons/Unified-Wallet-Kit). * If you have any questions or issues, please reach out to us in [Discord](https://discord.gg/jup). # Jupiter Wallet Extension Source: https://dev.jup.ag/docs/tool-kits/wallet-kit/jupiter-wallet-extension Step-by-step guide to integrate Jupiter Wallet Extension into a Next.js application. This guide walks through integrating Jupiter Wallet Extension into a Next.js application using the `@jup-ag/wallet-adapter` package. It covers setting up UnifiedWalletProvider, creating wallet notifications, and detecting the Jupiter Wallet Extension browser addon. ## Prerequisites Before you begin, make sure you have the following installed on your system. This is what we will be using in this example. **Node.js and npm**: Download and install from [nodejs.org](https://nodejs.org) ## Step 1: Create a new project Head to your preferred directory and create a new project using `create-next-app` with TypeScript template (you can use other templates or methods to start your project too): ```bash theme={null} npx create-next-app@latest wallet-kit-demo --typescript cd wallet-kit-demo npm run dev ``` ## Step 2: Install dependency ```bash theme={null} npm i @jup-ag/wallet-adapter ``` ## Step 3: Add notification functionality In `/src/components`, create a new file `WalletNotification.tsx` with the following content: In this example, we will use a simple browser notification system to handle the wallet connection events. ```typescript expandable theme={null} "use client"; interface IWalletNotification { publicKey?: string; shortAddress?: string; walletName?: string; metadata?: { name: string; url: string; icon: string; supportedTransactionVersions?: any; }; } // Simple notification component - you can replace this with your preferred notification library const showNotification = (message: string, type: 'success' | 'error' | 'info' = 'info') => { // For demo purposes, we'll use browser notifications // In a real app, you'd want to use a proper notification library like react-hot-toast console.log(`[${type.toUpperCase()}] ${message}`); // Simple visual feedback if (typeof window !== 'undefined') { const notification = document.createElement('div'); notification.style.cssText = ` position: fixed; top: 20px; right: 20px; background: ${type === 'error' ? '#ef4444' : type === 'success' ? '#10b981' : '#3b82f6'}; color: white; padding: 12px 16px; border-radius: 8px; z-index: 9999; font-family: system-ui, -apple-system, sans-serif; box-shadow: 0 4px 12px rgba(0,0,0,0.15); `; notification.textContent = message; document.body.appendChild(notification); setTimeout(() => { document.body.removeChild(notification); }, 3000); } }; export const WalletNotification = { onConnect: ({ shortAddress, walletName }: IWalletNotification) => { showNotification(`Connected to ${walletName} (${shortAddress})`, 'success'); }, onConnecting: ({ walletName }: IWalletNotification) => { showNotification(`Connecting to ${walletName}...`, 'info'); }, onDisconnect: ({ walletName }: IWalletNotification) => { showNotification(`Disconnected from ${walletName}`, 'info'); }, onError: ({ walletName }: IWalletNotification) => { showNotification(`Failed to connect to ${walletName}`, 'error'); }, onNotInstalled: ({ walletName }: IWalletNotification) => { showNotification(`${walletName} is not installed`, 'error'); }, }; export default WalletNotification; ``` ## Step 4: Wrap your app in the Wallet Kit In `/src/app/page.tsx`, wrap your app with ``. This example code covers the base usage of the wallet kit which allows all wallets in your browser to be detected and used. If you have downloaded the [Jupiter Wallet Extension](https://chromewebstore.google.com/detail/iledlaeogohbilgbfhmbgkgmpplbfboh) , you should be able to see and connect to it. ```typescript expandable theme={null} "use client"; import { Adapter, UnifiedWalletButton, UnifiedWalletProvider } from "@jup-ag/wallet-adapter"; import { WalletNotification } from "../components/WalletNotification"; export default function Home() { // You can add specific wallet adapters here if needed // For now, we'll rely on the Unified Wallet Kit's built-in wallet discovery const wallets: Adapter[] = []; return (

Jupiter Wallet Extension Demo

Connect your Solana wallet to get started

); } ``` There you have it! You've successfully integrated Jupiter Wallet Kit into your Next.js application and able to connect the Jupiter Wallet Extension! * Please test the wallet functionality and build into your own application. * If you require more customizations, check out the [Wallet Kit Playground](https://wallet-kit.jup.ag) or [Github repo](https://github.com/TeamRaccoons/Unified-Wallet-Kit). * If you have any questions or issues, please reach out to us in [Discord](https://discord.gg/jup). # Transaction Submission Source: https://dev.jup.ag/docs/transaction/submit Submit transactions through Jupiter's proprietary infrastructure for fast landing and MEV protection `/submit` sends your signed transactions through Jupiter's proprietary transaction landing infrastructure. This is the same infrastructure that powers Jupiter's own swap products, now open to any integrator. It accepts any valid signed Solana transaction with a SOL tip, costs zero API credits, and works on all plans including keyless access. ## Why /submit is competitive Jupiter's transaction landing stack is purpose-built for high throughput and low latency: * **[SWQoS via high-stake validator](https://solana.com/developers/guides/advanced/stake-weighted-qos).** Jupiter operates [one of the highest-staked validators on Solana](https://solanabeach.io/validators). Solana's Stake-Weighted Quality of Service (SWQoS) reserves \~80% of a leader's TPU capacity for staked validators proportional to their stake. Higher stake means more reserved bandwidth when forwarding transactions to the current leader. * **Beam (custom TPU forwarder).** Jupiter's own TPU client bypasses standard RPC nodes and sends transactions directly to leaders via staked QUIC connections. This removes intermediaries that could be malicious actors and eliminates RPC processing overhead. * **[DoubleZero](https://doublezero.xyz/).** Dedicated fiber network for validator communication, with FPGA-based spam filtering and transaction deduplication at the network edge. Cleaner transaction set, faster propagation between validators. * **Ultra-low-latency fiber.** Private fiber links from Tokyo to Frankfurt reduce physical propagation time between Jupiter's infrastructure and leader validators globally. * **High-performance, scalable infrastructure.** Built to handle the volume of Jupiter's own products, where millions of swaps land daily. ## How it works 1. Build your transaction (using `/build`, or assemble your own) 2. Include a SOL tip transfer instruction (minimum 0.001 SOL) to one of 16 tip receiver accounts 3. Sign the transaction 4. POST the base64-encoded signed transaction to `https://api.jup.ag/tx/v1/submit` For `/build` transactions, use the `tipAmount` parameter to have the tip instruction included automatically. For non-Jupiter transactions, add a standard SOL transfer instruction to one of the [tip receiver accounts](#adding-tip-instruction-manually). ## Requirements | Requirement | Details | | ---------------------------- | ----------------------------------------------------------------------------------------- | | **Valid signed transaction** | Must be a valid Solana transaction with all required signatures | | **SOL tip** | Minimum 1,000,000 lamports (0.001 SOL) transferred to one of the 16 tip receiver accounts | | **Transaction size** | Must not exceed the Solana transaction size limit (1232 bytes) | | **API access** | Works with any API key or keyless access | `/submit` has its own dedicated rate limit bucket (Keyless 20, Free 50, Paid 100 RPS), separate from your general API limit. See [Rate Limits](/docs/portal/rate-limits#dedicated-rate-limit-buckets). ## Code example ### Using /build Use [`/build`](/docs/swap/build) with the `tipAmount` parameter to automatically include a tip instruction in the response. ```typescript @solana/web3.js expandable theme={null} import { AddressLookupTableAccount, ComputeBudgetProgram, Connection, Keypair, PublicKey, TransactionInstruction, TransactionMessage, VersionedTransaction, } from "@solana/web3.js"; import bs58 from "bs58"; // ── Types matching the /build response ─────────────────────────────────────── type ApiAccount = { pubkey: string; isSigner: boolean; isWritable: boolean }; type ApiInstruction = { programId: string; accounts: ApiAccount[]; data: string; // base64 }; type BuildResponse = { computeBudgetInstructions: ApiInstruction[]; setupInstructions: ApiInstruction[]; swapInstruction: ApiInstruction; cleanupInstruction: ApiInstruction | null; otherInstructions: ApiInstruction[]; tipInstruction: ApiInstruction; addressesByLookupTableAddress: Record | null; blockhashWithMetadata: { blockhash: number[]; lastValidBlockHeight: number; }; }; // ── Helpers ────────────────────────────────────────────────────────────────── const CU_LIMIT_MAX = 1_400_000; function toInstruction(ix: ApiInstruction): TransactionInstruction { return new TransactionInstruction({ programId: new PublicKey(ix.programId), keys: ix.accounts.map((acc) => ({ pubkey: new PublicKey(acc.pubkey), isSigner: acc.isSigner, isWritable: acc.isWritable, })), data: Buffer.from(ix.data, "base64"), }); } // ── Main ───────────────────────────────────────────────────────────────────── const API_KEY = process.env.JUPITER_API_KEY!; const connection = new Connection(process.env.RPC_URL!); const signer = Keypair.fromSecretKey( bs58.decode(process.env.BS58_PRIVATE_KEY!), ); // 1. Call /build with your swap parameters const buildRes = await fetch( "https://api.jup.ag/swap/v2/build?" + new URLSearchParams({ inputMint: "So11111111111111111111111111111111111111112", outputMint: "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v", amount: "100000000", taker: signer.publicKey.toString(), tipAmount: "1000000", }), { headers: { "x-api-key": API_KEY } }, ); const build: BuildResponse = await buildRes.json(); // 2. Collect instructions (excluding compute budget — we handle CU limit ourselves) const instructions = [ ...build.setupInstructions.map(toInstruction), toInstruction(build.swapInstruction), ...(build.cleanupInstruction ? [toInstruction(build.cleanupInstruction)] : []), ...build.otherInstructions.map(toInstruction), toInstruction(build.tipInstruction), ]; // 3. Prepare blockhash and address lookup tables const addressLookupTableAccounts: AddressLookupTableAccount[] = []; for (const addr of Object.keys(build.addressesByLookupTableAddress ?? {})) { const result = await connection.getAddressLookupTable(new PublicKey(addr)); if (result.value) addressLookupTableAccounts.push(result.value); } const recentBlockhash = bs58.encode( Buffer.from(build.blockhashWithMetadata.blockhash), ); const { lastValidBlockHeight } = build.blockhashWithMetadata; // 4. Simulate to estimate CU usage, then apply 1.2x buffer const simMessage = new TransactionMessage({ payerKey: signer.publicKey, recentBlockhash, instructions: [ ComputeBudgetProgram.setComputeUnitLimit({ units: CU_LIMIT_MAX }), ...instructions, ], }).compileToV0Message(addressLookupTableAccounts); const sim = await connection.simulateTransaction( new VersionedTransaction(simMessage), { sigVerify: false, replaceRecentBlockhash: true }, ); if (sim.value.err) { console.error("Simulation failed:", sim.value.err); process.exit(1); } const estimatedCUL = sim.value.unitsConsumed ? Math.min(Math.ceil(sim.value.unitsConsumed * 1.2), CU_LIMIT_MAX) : CU_LIMIT_MAX; // 5. Build final transaction with estimated CU limit + CU price from response const messageV0 = new TransactionMessage({ payerKey: signer.publicKey, recentBlockhash, instructions: [ ComputeBudgetProgram.setComputeUnitLimit({ units: estimatedCUL }), ...build.computeBudgetInstructions.map(toInstruction), ...instructions, ], }).compileToV0Message(addressLookupTableAccounts); const transaction = new VersionedTransaction(messageV0); transaction.sign([signer]); // 6. Sign and submit via /submit (or use your own RPC / transaction pipeline) const submitRes = await fetch("https://api.jup.ag/tx/v1/submit", { method: "POST", headers: { "Content-Type": "application/json", "x-api-key": API_KEY, }, body: JSON.stringify({ signedTransaction: Buffer.from(transaction.serialize()).toString("base64"), }), }); const { signature } = await submitRes.json(); console.log("Submitted:", `https://solscan.io/tx/${signature}`); // 7. Confirm the transaction landed const confirmation = await connection.confirmTransaction( { signature, blockhash: recentBlockhash, lastValidBlockHeight }, "confirmed", ); if (confirmation.value.err) { console.error("Transaction failed:", confirmation.value.err); process.exit(1); } console.log("Confirmed:", signature); ``` ```typescript @solana/kit expandable theme={null} import { AccountRole, Address, address, AddressesByLookupTableAddress, appendTransactionMessageInstructions, Base64EncodedBytes, Blockhash, compileTransaction, compressTransactionMessageUsingAddressLookupTables, createKeyPairSignerFromBytes, createSolanaRpc, createTransactionMessage, getBase58Decoder, getBase58Encoder, getBase64Codec, getBase64EncodedWireTransaction, AccountMeta, Instruction, pipe, setTransactionMessageFeePayer, setTransactionMessageLifetimeUsingBlockhash, signTransaction, } from "@solana/kit"; // ── Types matching the /build response ─────────────────────────────────────── type Account = { pubkey: Address; isSigner: boolean; isWritable: boolean }; type ApiInstruction = { programId: Address; accounts: Account[]; data: Base64EncodedBytes; }; type BuildResponse = { computeBudgetInstructions: ApiInstruction[]; setupInstructions: ApiInstruction[]; swapInstruction: ApiInstruction; cleanupInstruction: ApiInstruction | null; otherInstructions: ApiInstruction[]; tipInstruction: ApiInstruction; addressesByLookupTableAddress: Record | null; blockhashWithMetadata: { blockhash: number[]; lastValidBlockHeight: number; }; }; // ── Helpers ────────────────────────────────────────────────────────────────── const COMPUTE_BUDGET_PROGRAM = address( "ComputeBudget111111111111111111111111111111", ); const CU_LIMIT_MAX = 1_400_000; function createInstruction(ix: ApiInstruction): Instruction { return { programAddress: ix.programId, accounts: ix.accounts.map((acc) => ({ address: acc.pubkey, role: acc.isSigner && acc.isWritable ? AccountRole.WRITABLE_SIGNER : acc.isSigner ? AccountRole.READONLY_SIGNER : acc.isWritable ? AccountRole.WRITABLE : AccountRole.READONLY, })), data: Uint8Array.from(getBase64Codec().encode(ix.data)), }; } function makeSetComputeUnitLimitIx(units: number): ApiInstruction { const data = Buffer.alloc(5); data.writeUInt8(0x02, 0); data.writeUInt32LE(units, 1); return { programId: COMPUTE_BUDGET_PROGRAM, accounts: [], data: data.toString("base64") as ApiInstruction["data"], }; } function transformBlockhash(meta: BuildResponse["blockhashWithMetadata"]) { return { blockhash: getBase58Decoder().decode( Uint8Array.from(meta.blockhash), ) as Blockhash, lastValidBlockHeight: BigInt(meta.lastValidBlockHeight), }; } function transformALTs( raw: Record | null, ): AddressesByLookupTableAddress { if (!raw) return {}; return Object.fromEntries( Object.entries(raw).map(([key, addrs]) => [ address(key), addrs.map((a) => address(a)), ]), ); } function buildTransaction( ixs: Instruction[], blockhash: { blockhash: Blockhash; lastValidBlockHeight: bigint }, alts: AddressesByLookupTableAddress, feePayer: Address, ) { return pipe( createTransactionMessage({ version: 0 }), (msg) => appendTransactionMessageInstructions(ixs, msg), (msg) => compressTransactionMessageUsingAddressLookupTables(msg, alts), (msg) => setTransactionMessageFeePayer(feePayer, msg), (msg) => setTransactionMessageLifetimeUsingBlockhash(blockhash, msg), (msg) => compileTransaction(msg), ); } // ── Main ───────────────────────────────────────────────────────────────────── const API_KEY = process.env.JUPITER_API_KEY!; const rpc = createSolanaRpc(process.env.RPC_URL!); const signer = await createKeyPairSignerFromBytes( getBase58Encoder().encode(process.env.BS58_PRIVATE_KEY!), ); // 1. Call /build with your swap parameters const buildRes = await fetch( "https://api.jup.ag/swap/v2/build?" + new URLSearchParams({ inputMint: "So11111111111111111111111111111111111111112", outputMint: "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v", amount: "100000000", taker: signer.address, tipAmount: "1000000", }), { headers: { "x-api-key": API_KEY } }, ); const build: BuildResponse = await buildRes.json(); // 2. Collect instructions (excluding compute budget — we handle CU limit ourselves) const instructions = [ ...build.setupInstructions.map(createInstruction), createInstruction(build.swapInstruction), ...(build.cleanupInstruction ? [createInstruction(build.cleanupInstruction)] : []), ...build.otherInstructions.map(createInstruction), createInstruction(build.tipInstruction), ]; // 3. Prepare blockhash and address lookup tables const blockhash = transformBlockhash(build.blockhashWithMetadata); const alts = transformALTs(build.addressesByLookupTableAddress); // 4. Simulate to estimate CU usage, then apply 1.2x buffer const simTx = buildTransaction( [createInstruction(makeSetComputeUnitLimitIx(CU_LIMIT_MAX)), ...instructions], blockhash, alts, signer.address, ); const sim = await rpc .simulateTransaction(getBase64EncodedWireTransaction(simTx), { encoding: "base64", commitment: "confirmed", replaceRecentBlockhash: true, }) .send(); if (sim.value.err) { console.error("Simulation failed:", sim.value.err); process.exit(1); } const estimatedCUL = sim.value.unitsConsumed ? Math.min( Math.ceil(Number(sim.value.unitsConsumed) * 1.2), CU_LIMIT_MAX, ) : CU_LIMIT_MAX; // 5. Build final transaction with estimated CU limit + CU price from response const compiledTx = buildTransaction( [ createInstruction(makeSetComputeUnitLimitIx(estimatedCUL)), ...build.computeBudgetInstructions.map(createInstruction), ...instructions, ], blockhash, alts, signer.address, ); // 6. Sign and submit via /submit (or use your own RPC / transaction pipeline) const signedTx = await signTransaction([signer.keyPair], compiledTx); const submitRes = await fetch("https://api.jup.ag/tx/v1/submit", { method: "POST", headers: { "Content-Type": "application/json", "x-api-key": API_KEY, }, body: JSON.stringify({ signedTransaction: getBase64EncodedWireTransaction(signedTx), }), }); const { signature } = await submitRes.json(); console.log("Submitted:", `https://solscan.io/tx/${signature}`); // 7. Confirm the transaction landed const confirmation = await rpc .confirmTransaction(signature, { strategy: { type: "blockhash", ...blockhash }, commitment: "confirmed", }) .send(); if (confirmation.value.err) { console.error("Transaction failed:", confirmation.value.err); process.exit(1); } console.log("Confirmed:", signature); ``` ### Adding tip instruction manually For non-Jupiter transactions (another swap protocol, a program call, a transfer), add a standard SOL transfer to one of the 16 tip receiver accounts. Randomise which account you send to on each transaction to reduce write-lock contention. ```typescript @solana/web3.js expandable theme={null} import { SystemProgram, PublicKey } from "@solana/web3.js"; const TIP_ACCOUNTS = [ "GGztQqQ6pCPaJQnNpXBgELr5cs3WwDakRbh1iEMzjgSJ", "2MFoS3MPtvyQ4Wh4M9pdfPjz6UhVoNbFbGJAskCPCj3h", "BQ72nSv9f3PRyRKCBnHLVrerrv37CYTHm5h3s9VSGQDV", "6U91aKa8pmMxkJwBCfPTmUEfZi6dHe7DcFq2ALvB2tbB", "4xDsmeTWPNjgSVSS1VTfzFq3iHZhp77ffPkAmkZkdu71", "CapuXNQoDviLvU1PxFiizLgPNQCxrsag1uMeyk6zLVps", "9nnLbotNTcUhvbrsA6Mdkx45Sm82G35zo28AqUvjExn8", "6LXutJvKUw8Q5ue2gCgKHQdAN4suWW8awzFVC6XCguFx", "HFqp6ErWHY6Uzhj8rFyjYuDya2mXUpYEk8VW75K9PSiY", "DSN3j1ykL3obAVNv7ZX49VsFCPe4LqzxHnmtLiPwY6xg", "69yhtoJR4JYPPABZcSNkzuqbaFbwHsCkja1sP1Q2aVT5", "HU23r7UoZbqTUuh3vA7emAGztFtqwTeVips789vqxxBw", "3LoAYHuSd7Gh8d7RTFnhvYtiTiefdZ5ByamU42vkzd76", "3CgvbiM3op4vjrrjH2zcrQUwsqh5veNVRjFCB9N6sRoD", "GP8StUXNYSZjPikyRsvkTbvRV1GBxMErb59cpeCJnDf1", "7iWnBRRhBCiNXXPhqiGzvvBkKrvFSWqqmxRyu9VyYBxE", ]; const tipIx = SystemProgram.transfer({ fromPubkey: signer.publicKey, toPubkey: new PublicKey( TIP_ACCOUNTS[Math.floor(Math.random() * TIP_ACCOUNTS.length)] ), lamports: 1_000_000, // 0.001 SOL minimum }); // Add tipIx to your transaction, sign, then submit via /submit ``` ```typescript @solana/kit expandable theme={null} import { getTransferSolInstruction } from "@solana-program/system"; const TIP_ACCOUNTS = [ "GGztQqQ6pCPaJQnNpXBgELr5cs3WwDakRbh1iEMzjgSJ", "2MFoS3MPtvyQ4Wh4M9pdfPjz6UhVoNbFbGJAskCPCj3h", "BQ72nSv9f3PRyRKCBnHLVrerrv37CYTHm5h3s9VSGQDV", "6U91aKa8pmMxkJwBCfPTmUEfZi6dHe7DcFq2ALvB2tbB", "4xDsmeTWPNjgSVSS1VTfzFq3iHZhp77ffPkAmkZkdu71", "CapuXNQoDviLvU1PxFiizLgPNQCxrsag1uMeyk6zLVps", "9nnLbotNTcUhvbrsA6Mdkx45Sm82G35zo28AqUvjExn8", "6LXutJvKUw8Q5ue2gCgKHQdAN4suWW8awzFVC6XCguFx", "HFqp6ErWHY6Uzhj8rFyjYuDya2mXUpYEk8VW75K9PSiY", "DSN3j1ykL3obAVNv7ZX49VsFCPe4LqzxHnmtLiPwY6xg", "69yhtoJR4JYPPABZcSNkzuqbaFbwHsCkja1sP1Q2aVT5", "HU23r7UoZbqTUuh3vA7emAGztFtqwTeVips789vqxxBw", "3LoAYHuSd7Gh8d7RTFnhvYtiTiefdZ5ByamU42vkzd76", "3CgvbiM3op4vjrrjH2zcrQUwsqh5veNVRjFCB9N6sRoD", "GP8StUXNYSZjPikyRsvkTbvRV1GBxMErb59cpeCJnDf1", "7iWnBRRhBCiNXXPhqiGzvvBkKrvFSWqqmxRyu9VyYBxE", ]; const tipIx = getTransferSolInstruction({ source: signer, destination: address( TIP_ACCOUNTS[Math.floor(Math.random() * TIP_ACCOUNTS.length)] ), amount: 1_000_000n, // 0.001 SOL minimum }); // Add tipIx to your transaction, sign, then submit via /submit ``` ## Best practices * **Randomise tip accounts:** there are 16 tip receiver accounts. Randomise which one you send to on each transaction to reduce write-lock contention across concurrent submissions. * **Use `tipAmount` with `/build`:** pass `tipAmount` as a query parameter to have the tip instruction included automatically, rather than adding it manually. * **Set `maxRetries: 0` on RPC fallback:** if you run `/submit` in parallel with `sendRawTransaction`, let your application control retry logic rather than the RPC node, so you can refresh the blockhash between attempts. * **Poll for confirmation:** use `confirmTransaction` with the blockhash and `lastValidBlockHeight` from your transaction. If the blockhash expires without confirmation, rebuild with a fresh blockhash and resubmit. * **`/submit` does not simulate:** we send directly to the TPU for fastest possible delivery. If you require simulation, do it before making a request to `/submit`. * **Colocate for lowest latency:** Jupiter's API gateway runs in [six AWS regions](/docs/portal/latency). Deploy your servers in the nearest region to minimise round-trip time. ## How /submit differs from /execute | | `/execute` | `/submit` | | ---------------------- | ------------------------------------------------ | --------------------------------------------------------- | | **Paired with** | `/order` (meta-aggregator flow) | `/build` or any signed transaction | | **Fee model** | Jupiter swap fees (included in the order) | SOL tips (minimum 0.001 SOL) | | **Transaction source** | Must match the exact transaction from `/order` | Any valid signed Solana transaction | | **Credit cost** | 0 credits | 0 credits | | **Use case** | Managed swap execution for `/order` transactions | Any transaction: `/build` swaps, non-Jupiter transactions | ## API reference **Endpoint:** `POST https://api.jup.ag/tx/v1/submit` See the [POST /submit API reference](/docs/api-reference/transaction/submit) for the full specification. ## Related * [Build](/docs/swap/build): build custom transactions with `/build` (use `tipAmount` for automatic tip inclusion) * [Order & Execute](/docs/swap/order-and-execute): the standard swap flow using `/order` + `/execute` * [Reduce Latency](/docs/swap/advanced/reduce-latency): use `mode=fast` on `/build` for faster routing * [Plans and Pricing](/docs/portal/plans): all plans include `/submit` at zero credit cost * [Latency and Server Locations](/docs/portal/latency): API gateway regions and colocation guidance # Authentication Source: https://dev.jup.ag/docs/trigger/authentication Authenticate with the Trigger Order API using a challenge-response JWT flow. The Trigger Order API V2 uses a challenge-response flow to authenticate users. Your wallet signs a challenge, and the server issues a JWT token valid for 24 hours. ## Authentication Flow ``` 1. Request challenge → POST /v2/auth/challenge 2. Sign with wallet → (client-side) 3. Submit signature → POST /v2/auth/verify → JWT token 4. Use JWT → Authorization: Bearer ``` ## Prerequisites Signing challenges and transactions requires `@solana/web3.js` and `bs58`: ```bash theme={null} npm install @solana/web3.js bs58 ``` ## Step 1: Request a Challenge Request a challenge for your wallet. Choose `message` for standard wallets or `transaction` for hardware wallets that only support transaction signing. ```typescript theme={null} const challengeResponse = await fetch('https://api.jup.ag/trigger/v2/auth/challenge', { method: 'POST', headers: { 'Content-Type': 'application/json', 'x-api-key': 'your-api-key', }, body: JSON.stringify({ walletPubkey: walletAddress, type: 'message', // or 'transaction' for hardware wallets }), }); const challenge = await challengeResponse.json(); ``` **Message challenge response:** ```json theme={null} { "type": "message", "challenge": "Sign this message to authenticate with Jupiter Trigger Order API..." } ``` **Transaction challenge response:** ```json theme={null} { "type": "transaction", "transaction": "Base64EncodedTransactionWithMemoInstruction..." } ``` Challenges expire after 5 minutes. Request a new one if your challenge expires. ## Step 2: Sign and Verify Sign the challenge with your wallet, then submit the signature to receive a JWT token. **For message signing:** ```typescript theme={null} import bs58 from 'bs58'; // Sign the challenge message with your wallet const encodedMessage = new TextEncoder().encode(challenge.challenge); const signature = await wallet.signMessage(encodedMessage); const verifyResponse = await fetch('https://api.jup.ag/trigger/v2/auth/verify', { method: 'POST', headers: { 'Content-Type': 'application/json', 'x-api-key': 'your-api-key', }, body: JSON.stringify({ type: 'message', walletPubkey: walletAddress, signature: bs58.encode(signature), }), }); const { token } = await verifyResponse.json(); // Use this token in Authorization: Bearer for all authenticated requests ``` **For transaction signing (hardware wallets):** ```typescript theme={null} import { VersionedTransaction } from '@solana/web3.js'; const signedTx = await wallet.signTransaction( VersionedTransaction.deserialize(Buffer.from(challenge.transaction, 'base64')) ); const verifyResponse = await fetch('https://api.jup.ag/trigger/v2/auth/verify', { method: 'POST', headers: { 'Content-Type': 'application/json', 'x-api-key': 'your-api-key', }, body: JSON.stringify({ type: 'transaction', walletPubkey: walletAddress, signedTransaction: Buffer.from(signedTx.serialize()).toString('base64'), }), }); const { token } = await verifyResponse.json(); ``` ## Using the JWT Include the JWT in all authenticated requests: ```typescript theme={null} const response = await fetch('https://api.jup.ag/trigger/v2/vault', { headers: { 'x-api-key': 'your-api-key', 'Authorization': `Bearer ${token}`, }, }); ``` ## Token Lifecycle | Property | Value | | :---------------- | :-------- | | **Challenge TTL** | 5 minutes | | **JWT TTL** | 24 hours | When a token expires, repeat the challenge-response flow to obtain a new one. There is no refresh endpoint. ## Security Notes **For integrators building user-facing applications:** * Never store JWT tokens in local storage. Use secure, httpOnly cookies or in-memory storage * Always verify the challenge content before signing. Do not blindly sign arbitrary messages * Implement token refresh logic to handle expiration gracefully * The JWT is tied to the wallet public key. Do not reuse tokens across wallets ### What Happens if a JWT is Leaked The JWT grants limited access. An attacker with a leaked token can: * **Cancel orders**: This transitions the order from `open` to `ready_to_cancel`, but does **not** withdraw funds. Withdrawal requires signing a transaction with the wallet private key. * **Edit order parameters**: Updating trigger prices or slippage does not require transaction signing. An attacker **cannot**: * **Withdraw funds**: All withdrawal operations require the wallet owner to sign a transaction. The vault's funds remain secure. * **Create new orders**: Depositing tokens requires signing a deposit transaction with the wallet. All operations involving funds (deposits, withdrawals) require the wallet owner to sign a transaction. A leaked JWT alone cannot result in loss of funds. However, if the wallet private key is also compromised, an attacker could sign transactions and withdraw funds from the vault. # Best Practices Source: https://dev.jup.ag/docs/trigger/best-practices Guidelines for order expiry, slippage, error handling, and integration patterns for the Trigger Order V2 API. The Trigger Order V2 API is in **beta** and under active development. Behaviour, endpoints, and response formats may change as we iterate based on integrator feedback. Pin to specific response schemas and handle unknown fields gracefully. ## Reference Implementation The [jup.ag](https://jup.ag) frontend is the canonical reference for how to interact with the V2 API. When in doubt about edge cases, validation logic, or UX patterns, refer to how jup.ag handles it. This includes: * Order creation flows and parameter validation * Price and slippage presentation * Error handling and retry logic * Order state management and polling ## Order Expiry Every order requires an `expiresAt` timestamp. Unlike V1 where orders could exist indefinitely, V2 enforces expiry on all orders. This allows the system to prune stale orders, improving execution quality for active orders. | Use case | Recommended expiry | | :---------------------- | :----------------------------- | | Short-term trades | 1-7 days | | Swing trades | 7-30 days | | Long-duration positions | 30 days, with periodic renewal | For long-lived orders, set a 30-day expiry and renew by updating the order before it expires via the [update endpoint](/docs/trigger/manage-orders#update-an-order). There is no "no expiry" option by design. ## Slippage | Order type | Default | Recommendation | | :---------------------- | :------------- | :--------------------------------------------------------------------------- | | Take-profit / buy below | Auto (RTSE) | Use the default unless you have specific requirements | | Stop-loss / buy above | 20% (2000 bps) | Keep high for execution certainty -- tighten only if you accept missed fills | | Parent (OTOCO) | Auto (RTSE) | Use the default | Stop-loss orders use a higher default because execution certainty matters more than price precision when cutting losses. If you lower stop-loss slippage, the order may not fill during volatile conditions. ## Error Handling * **Validation errors** (400) include a `details` object with per-field messages. Parse these to surface specific issues to users. * **Authentication errors** (401) mean the JWT has expired. Re-authenticate with a new challenge-response flow rather than retrying the same token. * **Minimum order size** is 10 USD. Enforce this client-side to avoid unnecessary API calls. * Handle unknown fields in responses gracefully. As the API evolves during beta, new fields may be added to response objects. ## Order Summary The API does not validate whether your trigger price makes economic sense. If a user sets a buy order above market price or a sell order below market price, the keeper will execute as instructed and the difference is lost. Display a human-readable summary of what the order will do before the user confirms. On [jup.ag](https://jup.ag), the confirmation shows a plain-language description like: > Buy SOL with 15 USDC when price goes below $76.37 (-10% from market). If triggered, automatically set TP for SOL at $84.01. This helps users catch mistakes before submitting. For OCO and OTOCO orders, include both the trigger conditions and the child order parameters in the summary. ## Token Compatibility * Tokens with transfer tax extensions (Token-2022) are not supported * Input and output mints must be different ## Order Lifecycle Poll the [history endpoint](/docs/trigger/order-history) to track order state. Key states to handle: | State | Meaning | Action | | :---------- | :-------------------------- | :------------------------------------------------- | | `open` | Active, waiting for trigger | No action needed | | `filled` | Fully executed | Show completion to user | | `cancelled` | Cancelled by user | Confirm funds returned to vault | | `expired` | Past `expiresAt` | Prompt user to withdraw funds or recreate | | `failed` | Execution failed | Show error, suggest retry with adjusted parameters | # Create Order Source: https://dev.jup.ag/docs/trigger/create-order Create trigger orders with vault-based deposits. Supports single limit orders, OCO (take-profit/stop-loss), and OTOCO (conditional chains). Creating an order in V2 is a two-step process: craft and sign a deposit transaction, then submit it alongside your order parameters. **Action required:** This change is planned for Thursday, May 14, 2026 at 4:00 AM UTC / 12:00 PM SGT. Price-order deposits crafted with `POST /trigger/v2/deposit/craft` must include `orderType: "price"` and `orderSubType`. Requests missing either field will return a `4xx`. For a working reference of the full order creation flow, see how [jup.ag](https://jup.ag) handles it. The frontend implements the same API with validation, error handling, and UX patterns you can use as a guide. ## Prerequisites Signing deposit transactions requires `@solana/web3.js`: ```bash theme={null} npm install @solana/web3.js ``` ## End-to-End Flow ``` 1. Get vault → GET /v2/vault (or /v2/vault/register on first use) 2. Craft deposit → POST /v2/deposit/craft 3. Sign deposit tx → (client-side) 4. Create order → POST /v2/orders/price (with signed tx) ``` ## Step 1: Get Your Vault Retrieve your vault, or register one if this is your first time. The vault is a Privy-managed custodial account that holds deposits for your orders. ```typescript theme={null} let vaultResponse = await fetch('https://api.jup.ag/trigger/v2/vault', { headers: { 'x-api-key': 'your-api-key', 'Authorization': `Bearer ${token}`, }, }); // First time user — register a new vault if (!vaultResponse.ok) { vaultResponse = await fetch('https://api.jup.ag/trigger/v2/vault/register', { headers: { 'x-api-key': 'your-api-key', 'Authorization': `Bearer ${token}`, }, }); } const vault = await vaultResponse.json(); // { userPubkey: "...", vaultPubkey: "...", privyVaultId: "..." } ``` ## Step 2: Craft a Deposit Transaction The deposit endpoint builds an unsigned transaction that transfers tokens from your wallet to your vault. ```typescript theme={null} const depositResponse = await fetch('https://api.jup.ag/trigger/v2/deposit/craft', { method: 'POST', headers: { 'Content-Type': 'application/json', 'x-api-key': 'your-api-key', 'Authorization': `Bearer ${token}`, }, body: JSON.stringify({ inputMint: 'So11111111111111111111111111111111111111112', // SOL outputMint: 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v', // USDC userAddress: walletAddress, amount: '1000000000', // 1 SOL in lamports orderType: 'price', orderSubType: 'single', }), }); const deposit = await depositResponse.json(); ``` Set `orderSubType` to match the price order you will create: | Order create type | Deposit `orderSubType` | Use it for | | :---------------- | :--------------------- | :----------------------------------------------------------------------------------------- | | `single` | `single` | A standalone price order | | `oco` | `oco` | A one-cancels-other pair sharing one deposit | | `otoco` | `otoco` | A parent trigger that activates an OCO pair. This also provisions an output token account. | **Response:** ```json theme={null} { "transaction": "Base64EncodedUnsignedTransaction...", "requestId": "01234567-89ab-cdef-0123-456789abcdef", "receiverAddress": "VaultPublicKey...", "mint": "So11111111111111111111111111111111111111112", "amount": "1000000000", "tokenDecimals": 9, "inputTokenAccount": "InputTokenAccountPubkey..." } ``` The vault address is automatically resolved from your JWT. You do not specify it in the request. You also do not pass `inputTokenAccount` or `outputTokenAccount` into `POST /trigger/v2/orders/price`; the API stores those accounts against the deposit `requestId`. For `orderSubType: "otoco"`, the response also includes `outputTokenAccount` for the output token account used by the conditional OCO pair. ## Step 3: Sign the Deposit Transaction ```typescript theme={null} import { VersionedTransaction } from '@solana/web3.js'; const transaction = VersionedTransaction.deserialize( Buffer.from(deposit.transaction, 'base64') ); const signedTransaction = await wallet.signTransaction(transaction); const depositSignedTx = Buffer.from(signedTransaction.serialize()).toString('base64'); ``` ## Step 4: Create the Order Submit the signed deposit alongside your order parameters. The order type determines which fields are required. ### Single Order (Limit) A single order triggers when the price of `triggerMint` crosses above or below the target price. ```typescript theme={null} const orderResponse = await fetch('https://api.jup.ag/trigger/v2/orders/price', { method: 'POST', headers: { 'Content-Type': 'application/json', 'x-api-key': 'your-api-key', 'Authorization': `Bearer ${token}`, }, body: JSON.stringify({ orderType: 'single', depositRequestId: deposit.requestId, depositSignedTx: depositSignedTx, userPubkey: walletAddress, inputMint: 'So11111111111111111111111111111111111111112', inputAmount: '1000000000', outputMint: 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v', triggerMint: 'So11111111111111111111111111111111111111112', triggerCondition: 'above', // 'above' or 'below' triggerPriceUsd: 200.00, slippageBps: 100, // 1% expiresAt: Date.now() + 7 * 24 * 60 * 60 * 1000, // 7 days }), }); const order = await orderResponse.json(); // { id: "order-uuid", txSignature: "..." } ``` ### OCO Order (One-Cancels-Other) An OCO order creates a take-profit and stop-loss pair sharing one deposit. When one side fills, the other cancels automatically. ```typescript theme={null} const orderResponse = await fetch('https://api.jup.ag/trigger/v2/orders/price', { method: 'POST', headers: { 'Content-Type': 'application/json', 'x-api-key': 'your-api-key', 'Authorization': `Bearer ${token}`, }, body: JSON.stringify({ orderType: 'oco', depositRequestId: deposit.requestId, depositSignedTx: depositSignedTx, userPubkey: walletAddress, inputMint: 'So11111111111111111111111111111111111111112', inputAmount: '1000000000', outputMint: 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v', triggerMint: 'So11111111111111111111111111111111111111112', tpPriceUsd: 250.00, // Take profit price slPriceUsd: 150.00, // Stop loss price tpSlippageBps: 100, slSlippageBps: 100, expiresAt: Date.now() + 7 * 24 * 60 * 60 * 1000, }), }); ``` The take-profit price must be greater than the stop-loss price. ### OTOCO Order (One-Triggers-One-Cancels-Other) An OTOCO order has a parent trigger that executes first. Once filled, it automatically activates a TP/SL pair (OCO) on the output tokens. ```typescript theme={null} const orderResponse = await fetch('https://api.jup.ag/trigger/v2/orders/price', { method: 'POST', headers: { 'Content-Type': 'application/json', 'x-api-key': 'your-api-key', 'Authorization': `Bearer ${token}`, }, body: JSON.stringify({ orderType: 'otoco', depositRequestId: deposit.requestId, depositSignedTx: depositSignedTx, userPubkey: walletAddress, inputMint: 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v', inputAmount: '200000000', // 200 USDC outputMint: 'So11111111111111111111111111111111111111112', triggerMint: 'So11111111111111111111111111111111111111112', triggerCondition: 'below', triggerPriceUsd: 180.00, // Entry: buy SOL when it drops to \$180 tpPriceUsd: 220.00, // Take profit at \$220 slPriceUsd: 160.00, // Stop loss at \$160 slippageBps: 100, // Parent order slippage tpSlippageBps: 100, slSlippageBps: 100, expiresAt: Date.now() + 30 * 24 * 60 * 60 * 1000, // 30 days }), }); ``` ## Order Parameters Reference ### Common Fields (All Order Types) | Parameter | Type | Required | Description | | :----------------- | :------- | :------- | :---------------------------------------- | | `orderType` | `string` | Yes | `single`, `oco`, or `otoco` | | `depositRequestId` | `string` | Yes | From the deposit craft response | | `depositSignedTx` | `string` | Yes | Base64-encoded signed deposit transaction | | `userPubkey` | `string` | Yes | Your wallet public key | | `inputMint` | `string` | Yes | Mint address of the token to sell | | `inputAmount` | `string` | Yes | Amount in smallest unit (lamports, etc.) | | `outputMint` | `string` | Yes | Mint address of the token to buy | | `triggerMint` | `string` | Yes | Mint address to monitor for price trigger | | `expiresAt` | `number` | Yes | Expiration timestamp in milliseconds | ### Single Order Fields | Parameter | Type | Required | Description | | :----------------- | :------- | :------- | :------------------------------------------- | | `triggerCondition` | `string` | Yes | `above` or `below` | | `triggerPriceUsd` | `number` | Yes | USD price that triggers execution | | `slippageBps` | `number` | No | Slippage tolerance in basis points (0-10000) | ### OCO Order Fields | Parameter | Type | Required | Description | | :-------------- | :------- | :------- | :---------------------------------- | | `tpPriceUsd` | `number` | Yes | Take-profit trigger price (USD) | | `slPriceUsd` | `number` | Yes | Stop-loss trigger price (USD) | | `tpSlippageBps` | `number` | No | Take-profit slippage (basis points) | | `slSlippageBps` | `number` | No | Stop-loss slippage (basis points) | ### OTOCO Order Fields | Parameter | Type | Required | Description | | :----------------- | :------- | :------- | :----------------------------------- | | `triggerCondition` | `string` | Yes | Parent trigger: `above` or `below` | | `triggerPriceUsd` | `number` | Yes | Parent trigger price (USD) | | `tpPriceUsd` | `number` | Yes | Take-profit price after parent fills | | `slPriceUsd` | `number` | Yes | Stop-loss price after parent fills | | `slippageBps` | `number` | No | Parent order slippage | | `tpSlippageBps` | `number` | No | Take-profit slippage | | `slSlippageBps` | `number` | No | Stop-loss slippage | ## Default Slippage If slippage is not specified, defaults vary by order type and trigger condition: | Order side | Default slippage | | :------------------------------------------------- | :---------------------------------------------------- | | **Take-profit / buy below** (buying into strength) | Auto slippage via RTSE (Real-Time Slippage Estimator) | | **Stop-loss / buy above** (selling into weakness) | 20% (2000 bps) | Stop-loss orders use a higher default because execution certainty is more important than price precision when cutting losses. ## Validation Rules * Minimum order size: 10 USD * Input and output mints must be different * Slippage: 0-10000 basis points * `expiresAt` is required and must be a future timestamp (milliseconds) * OCO/OTOCO: take-profit price must be greater than stop-loss price Unlike V1 where orders could exist indefinitely, V2 requires an expiration on every order. Adding a TTL allows the system to prune orders that are unlikely to fill, improving execution quality for active orders. For long-lived orders, use a far-future timestamp (e.g. 30 days). ## Response ```json theme={null} { "id": "order-uuid", "txSignature": "5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d..." } ``` The `txSignature` confirms the deposit transaction landed on-chain. The order is now active and will execute when price conditions are met. # Trigger Order API Overview Source: https://dev.jup.ag/docs/trigger/index Create advanced trigger orders on Solana with vault-based execution, including limit orders, take-profit/stop-loss (OCO), and conditional chains (OTOCO). The Jupiter Trigger Order API enables advanced order types on Solana, allowing users to set price conditions for token swaps that execute automatically when market conditions are met. V1 required traders to think in pool ratios — calculating how many tokens per SOL a pool needed to reach before an order would trigger. V2 replaces this with USD price triggers: set a dollar price and Jupiter handles conversion, routing, and execution. Orders are stored off-chain and private by default, closing the most common MEV attack vector of visible pending orders. ## What's New in V2 | Feature | V1 | V2 | | :------------------ | :----------------------------------------------- | :------------------------------------------------------------------ | | **Trigger type** | Pool rate only (e.g. "1 Fartcoin = 0.00025 SOL") | USD price | | **Order direction** | Buy below, sell above | Buy above, buy below, sell above, sell below | | **TP/SL** | Not supported | Take-profit and stop-loss with OCO bundling | | **Edit orders** | Must cancel and recreate | Edit trigger price and slippage in-place | | **Partial fills** | Not supported | Orders fill partially for optimal execution prices | | **Output amount** | Guaranteed (fixed pool rate) | Not guaranteed (prioritises trigger execution, pool price may vary) | | **Authentication** | API key only | Challenge-response JWT + API key | | **Order privacy** | Pending orders visible on-chain (PDA accounts) | Orders stored off-chain, private until execution | | **Deposits** | Program-derived address (PDA) order accounts | Vault accounts (custodial) by Privy | | **Route prefix** | `/trigger/v1` | `/trigger/v2` | There are no current plans to deprecate V1. However, all development efforts, research, and maintenance are focused entirely on V2. V1 will only receive updates for critical issues. ## Order Types | Type | Description | Use case | | :--------- | :-------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------ | | **Single** | Triggers when USD price crosses above or below a threshold | Standard limit orders, stop-loss | | **OCO** | Two orders sharing one deposit: one take-profit, one stop-loss. When one fills, the other cancels automatically | Risk management with TP/SL brackets (e.g. sell SOL at \$300 TP or \$200 SL while market is \$250) | | **OTOCO** | A parent order triggers first, then activates a TP/SL pair (OCO) on the output | Conditional entry with automatic exit strategy | ## How It Works ``` Your Wallet ──→ Vault (1 per wallet) ──→ Order A ──→ Order B ──→ Order C ``` Each wallet gets a single vault (a Privy-managed custodial account). When you create orders, tokens are deposited from your wallet into your vault. The vault holds funds for all your active orders. 1. [**Authenticate**](/docs/trigger/authentication): Sign a challenge with your wallet to receive a JWT token 2. [**Get your vault**](/docs/trigger/create-order#step-1-get-your-vault): Retrieve your vault, or register one on first use 3. [**Create an order**](/docs/trigger/create-order): Deposit tokens into your vault and submit order parameters 4. **Monitor**: Track order state and history via the [history endpoint](/docs/trigger/order-history) 5. [**Manage**](/docs/trigger/manage-orders): Update order parameters, or cancel with a two-step withdrawal flow ## Base URL ``` https://api.jup.ag/trigger/v2 ``` All endpoints require an API key via the `x-api-key` header. Authenticated endpoints additionally require a JWT token via the `Authorization: Bearer ` header. ## FAQ Funds remain in the vault. To retrieve them, use the same two-step cancel flow: initiate cancellation on the expired order, sign the withdrawal transaction, and confirm. See [Expired Order Withdrawal](/docs/trigger/manage-orders#expired-order-withdrawal). Yes. You can update trigger prices and slippage in-place without cancelling and recreating the order. See [Update an Order](/docs/trigger/manage-orders#update-an-order). V2 uses USD price triggers rather than pool rate triggers. When the price condition is met, the order executes a swap at the current market rate via Jupiter routing. The actual output depends on liquidity and slippage at execution time. 10 USD equivalent. Open orders continue to be monitored and will execute normally. The JWT is only required for API calls (creating, editing, cancelling orders). When your token expires, re-authenticate to manage your orders. A One-Cancels-Other order creates a take-profit and stop-loss pair that share one deposit. When one side fills, the other cancels automatically, returning unused funds to the vault. A One-Triggers-One-Cancels-Other order has a parent trigger that executes first. Once the parent fills, it automatically activates a TP/SL pair (OCO) on the output tokens. If the parent expires or fails, the child orders are never created. Take-profit and buy-below orders use auto slippage via RTSE (Real-Time Slippage Estimator). Stop-loss and buy-above orders default to 20% (2000 bps) because execution certainty is more important when cutting losses. You can always set a custom slippage. The API accepts USD price triggers only (`triggerPriceUsd`). Market cap targeting is a convenience feature on the jup.ag frontend — it converts the market cap to a USD price before submitting to the API. To replicate this, divide the target market cap by the token's total supply to get the per-token USD price. No. V2 orders are stored off-chain and private by default. Order details (price, size, direction) are not revealed until the trigger condition is met and execution begins. In V1, pending orders were stored in on-chain PDA accounts, giving bots a roadmap to front-run profitable trades. Not currently, and there is no timeline for adding them. There is no atomic workaround because the keeper executes the transaction and the order is opaque to integrators. The only option is to run a separate transfer transaction outside the order flow. # Manage Orders Source: https://dev.jup.ag/docs/trigger/manage-orders Update order parameters, cancel orders with two-step withdrawal, and withdraw funds from your vault. ## Prerequisites Signing withdrawal transactions requires `@solana/web3.js`: ```bash theme={null} npm install @solana/web3.js ``` ## Update an Order Modify the trigger price or slippage of an existing order without cancelling and recreating it. ```typescript theme={null} const updateResponse = await fetch(`https://api.jup.ag/trigger/v2/orders/price/${orderId}`, { method: 'PATCH', headers: { 'Content-Type': 'application/json', 'x-api-key': 'your-api-key', 'Authorization': `Bearer ${token}`, }, body: JSON.stringify({ orderType: 'single', triggerPriceUsd: 210.00, slippageBps: 150, }), }); const result = await updateResponse.json(); // { id: "order-uuid" } ``` ### Update Fields by Order Type **Single:** ```json theme={null} { "orderType": "single", "triggerPriceUsd": 210.00, "slippageBps": 150 } ``` **OCO:** ```json theme={null} { "orderType": "oco", "tpPriceUsd": 260.00, "slPriceUsd": 145.00 } ``` **OTOCO:** ```json theme={null} { "orderType": "otoco", "triggerPriceUsd": 185.00, "tpPriceUsd": 230.00, "slPriceUsd": 155.00 } ``` ## Cancel an Order Cancellation is a two-step process. The first step returns a withdrawal transaction that moves funds from the vault back to your wallet. You sign and submit it in the second step. ### Step 1: Initiate Cancellation This immediately moves the order from `open` to `ready_to_cancel`. The order will no longer be filled, even if step 2 has not yet completed. This prevents a race condition where the order could still execute while you are signing the withdrawal transaction. ```typescript theme={null} const cancelResponse = await fetch( `https://api.jup.ag/trigger/v2/orders/price/cancel/${orderId}`, { method: 'POST', headers: { 'x-api-key': 'your-api-key', 'Authorization': `Bearer ${token}`, }, } ); const cancelData = await cancelResponse.json(); ``` **Response:** ```json theme={null} { "id": "order-uuid", "transaction": "Base64EncodedUnsignedWithdrawalTransaction...", "requestId": "cancel-request-uuid" } ``` ### Step 2: Sign and Confirm Sign the withdrawal transaction and submit it to complete the cancellation. ```typescript theme={null} import { VersionedTransaction } from '@solana/web3.js'; const transaction = VersionedTransaction.deserialize( Buffer.from(cancelData.transaction, 'base64') ); const signedTransaction = await wallet.signTransaction(transaction); const confirmResponse = await fetch( `https://api.jup.ag/trigger/v2/orders/price/confirm-cancel/${orderId}`, { method: 'POST', headers: { 'Content-Type': 'application/json', 'x-api-key': 'your-api-key', 'Authorization': `Bearer ${token}`, }, body: JSON.stringify({ signedTransaction: Buffer.from(signedTransaction.serialize()).toString('base64'), cancelRequestId: cancelData.requestId, }), } ); const result = await confirmResponse.json(); // { id: "order-uuid", txSignature: "..." } ``` If step 2 fails (the transaction doesn't land), you can retry by calling the confirm endpoint again with the same `cancelRequestId`. The order remains in `ready_to_cancel` state until the withdrawal confirms. ## Expired Order Withdrawal If an order expires before execution, the funds remain in the vault. To retrieve them, use the same two-step cancel flow: initiate cancellation on the expired order, sign the withdrawal transaction, and confirm. The order transitions through `ready_to_cancel` and then to `cancelled` once the withdrawal confirms on-chain. ## Error Handling | Status | Meaning | | :----- | :---------------------------------------------------------------------- | | `400` | Invalid order ID, order not in a cancellable state, or validation error | | `401` | Invalid API key, or JWT expired/invalid | | `403` | Order belongs to a different wallet | | `404` | Order not found | # Order History Source: https://dev.jup.ag/docs/trigger/order-history Query order history, filter by state, and understand the order lifecycle. ## Get Order History Retrieve your orders with optional filters for state, mint, and pagination. ```typescript theme={null} const historyResponse = await fetch( 'https://api.jup.ag/trigger/v2/orders/history?state=active&limit=20&offset=0', { headers: { 'x-api-key': 'your-api-key', 'Authorization': `Bearer ${token}`, }, } ); const history = await historyResponse.json(); ``` ### Query Parameters | Parameter | Type | Default | Description | | :-------- | :------- | :----------- | :---------------------------------------------------------- | | `state` | `string` | — | `active` (open orders) or `past` (filled/cancelled/expired) | | `mint` | `string` | — | Filter by token mint address (input or output) | | `limit` | `number` | `20` | Results per page (1-100) | | `offset` | `number` | `0` | Number of results to skip | | `sort` | `string` | `updated_at` | Sort field: `updated_at`, `created_at`, `expires_at` | | `dir` | `string` | `desc` | Sort direction: `asc` or `desc` | ### Response ```json theme={null} { "orders": [ { "id": "order-uuid", "orderType": "single", "orderState": "open", "rawState": "open", "userPubkey": "YourWalletPublicKey...", "privyWalletPubkey": "VaultPublicKey...", "inputMint": "So11111111111111111111111111111111111111112", "initialInputAmount": "1000000000", "remainingInputAmount": "1000000000", "outputMint": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v", "triggerMint": "So11111111111111111111111111111111111111112", "triggerCondition": "above", "triggerPriceUsd": 200.00, "slippageBps": 100, "expiresAt": 1704067200000, "createdAt": 1704000000000, "updatedAt": 1704000000000, "events": [ { "type": "deposit", "timestamp": 1704000000000, "txSignature": "5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d...", "mint": "So11111111111111111111111111111111111111112", "amount": "1000000000", "state": "success" } ] } ], "pagination": { "total": 50, "limit": 20, "offset": 0 } } ``` ### Additional Fields for Filled Orders Orders that have been fully or partially filled include extra fields: | Field | Description | | :------------- | :----------------------------------------- | | `triggeredAt` | Timestamp when the price condition was met | | `outputAmount` | Total output tokens received | | `inputUsed` | Total input tokens consumed | | `fillPercent` | Fill ratio (1.0 = fully filled) | ### Execution Attempts Order history includes execution attempts for each order. When an order fails to execute (due to slippage, quote generation failure, or other reasons), the attempt is recorded in the history. The reason for failure is not included in the response. Users can adjust slippage settings via the [update endpoint](/docs/trigger/manage-orders) if execution keeps failing due to slippage. ### Event Types Each order includes an `events` array tracking its lifecycle: | Event Type | Description | | :----------- | :------------------------------- | | `deposit` | Tokens deposited into vault | | `fill` | Order executed (full or partial) | | `withdrawal` | Tokens withdrawn back to wallet | | `cancelled` | Order cancelled by user | | `expired` | Order expired | Each event includes `type`, `timestamp`, and `state`. Events that involve token movement (`deposit`, `fill`, `withdrawal`) also include: | Field | Description | | :------------ | :------------------------------ | | `txSignature` | On-chain transaction signature | | `mint` | Token mint address | | `amount` | Token amount (in smallest unit) | Fill events include additional fields: | Field | Description | | :------------- | :--------------------------------------------------------------------------- | | `outputMint` | Output token mint address | | `outputAmount` | Output amount received | | `orderContext` | Semantic order type: `take_profit`, `stop_loss`, `buy_above`, or `buy_below` | ## Order States Orders follow a state machine from creation to completion. The `orderState` field provides a human-friendly state, while `rawState` shows the exact internal state. ### Display States | State | Description | | :----------------- | :------------------------------------------------- | | `pending` | Deposit is being processed | | `open` | Active and waiting for price trigger | | `executing` | Price condition met, swap in progress | | `filled` | Order completed successfully | | `pending_withdraw` | Cancellation initiated, awaiting signed withdrawal | | `cancelled` | User cancelled the order | | `expired` | Order expired before execution | | `failed` | Execution failed | ### Raw States The `rawState` field exposes the internal processing state. Multiple raw states map to each display state: | `orderState` | `rawState` | Meaning | | :----------------- | :---------------------- | :------------------------------------------------------------------- | | `pending` | `pending_deposit` | Deposit transaction not yet submitted | | `pending` | `depositing` | Deposit transaction submitted, awaiting confirmation | | `open` | `open` | Active and monitoring price | | `executing` | `ready_execute` | Price condition met, preparing swap | | `executing` | `ready_expire` | Order expiry detected, processing | | `executing` | `executing` | Swap transaction in flight | | `executing` | `execute_success` | Swap landed, validating output | | `executing` | `execute_failed` | Swap attempt failed, may retry | | `executing` | `ready_withdraw_output` | Output ready to withdraw to wallet | | `executing` | `withdrawing` | Withdrawal transaction in flight | | `filled` | `fill_success` | Order fully filled and output withdrawn | | `executing` | `partial_fill_success` | Order partially filled, may continue filling | | `pending_withdraw` | `ready_to_cancel` | Cancellation initiated, awaiting signed withdrawal | | `cancelled` | `cancelled` | User cancelled the order | | `cancelled` | `oco_cancelled` | Automatically cancelled because the other side of an OCO pair filled | | `expired` | `expired` | Order expired before execution | | `failed` | `deposit_failed` | Deposit transaction failed on-chain (e.g. insufficient balance) | | `failed` | `withdraw_failed` | Output withdrawal failed after execution | | `failed` | `fill_failed` | Fill validation failed after execution | ### State Flow ``` pending ──→ open ──→ executing ──→ filled │ │ │ │ │ └──→ failed └──→ failed│ (deposit) ├──→ expired │ └──→ pending_withdraw ──→ cancelled ``` For OCO orders, when one side fills, the other transitions to `cancelled` automatically (displayed as `oco_cancelled` in the raw state). For OTOCO orders, the child OCO pair only activates after the parent order reaches `filled`. If the parent expires or fails, the children are never created.

My App

Jupiter Plugin Demo

Jupiter Plugin Demo

Jupiter Plugin Demo

Jupiter Plugin Demo

Jupiter Plugin Demo

Jupiter Mobile Adapter Demo

Jupiter Wallet Extension Demo