Jupiter Swap API 实战:/v6/quote 与 /v6/swap

quote-api.jup.ag/v6/quote 与 /v6/swap 实战:请求结构、真正影响成交价的字段,以及决定这笔路由交易能不能上链的 RPC 行为。

BoltTx Team··11 min read
solanajupiterswap-apidex 聚合器交易机器人rpc

如果你在 Solana 上做任何 swap——钱包、交易机器人、DeFi UI、有代币流的 dApp——基本最后都会集成 Jupiter swap API。它是 Solana 上事实上的聚合器,工程上做得到位,产生的路由通常自定义逻辑很难打。

但"用 Jupiter"不是全部答案。集成有它的细节,swap 质量取决于你的 RPC 栈和 Jupiter 自身一样多,而且有些常见错误能把一个干净的集成搞慢、搞贵。

这篇我们讲 Jupiter 做(和不做)什么、怎么把 swap API 正确集成进去、影响成交价质量的架构决策。

Jupiter 到底做什么

Jupiter 是个 swap 聚合器。你跟它说"用 X SOL 换尽可能多的 TOKEN",它跨多个 DEX 和路由路径搜索、找最好的、给你回一笔可以签名提交的交易。

它的几个组件:

Jupiter 处理路由、交易构造、滑点容差设置。它处理的是:你的交易提交到网络上的质量。这一块还是要你自己负责。

基础集成模式

const QUOTE_URL = "https://quote-api.jup.ag/v6/quote";
const SWAP_URL = "https://quote-api.jup.ag/v6/swap";

// 步骤 1:拿 quote
const quoteResp = await fetch(`${QUOTE_URL}?` + new URLSearchParams({
  inputMint: SOL_MINT,
  outputMint: TARGET_TOKEN_MINT,
  amount: String(lamports),
  slippageBps: "100",  // 1% 滑点容差
}));
const quote = await quoteResp.json();

// 步骤 2:构建 swap 交易
const swapResp = await fetch(SWAP_URL, {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    quoteResponse: quote,
    userPublicKey: wallet.publicKey.toString(),
    wrapAndUnwrapSol: true,
    dynamicComputeUnitLimit: true,
  }),
});
const { swapTransaction } = await swapResp.json();

// 步骤 3:反序列化、签名、提交
const txBuf = Buffer.from(swapTransaction, "base64");
const tx = VersionedTransaction.deserialize(txBuf);
tx.sign([wallet]);

const signature = await connection.sendTransaction(tx, {
  skipPreflight: true,
  maxRetries: 0,
});

这是最小可用集成。下面讲超出这个之外要想的事。

滑点:最关键的一个决定

滑点容差(slippageBps)是决定你 swap 能不能上链的参数。设太紧、执行期间价格一动交易就失败;设太松、每笔都吃没必要的滑点。

要考虑的:

合理做法:基于路由池子深度和价格冲击估个滑点,再给执行延迟加点 buffer。别跨所有 swap 用一个固定数。

RPC 选择比你以为的重要

Jupiter 构造交易,你提交。你提交走的 RPC 决定:

模式很清楚:Jupiter 做路由,Anti-MEV + 写优化的 RPC 做提交。

常见的集成错误

我们见过开发者犯的、造成生产问题的事:

sendRawTransaction 没设 skipPreflight 默认行为浪费一个 round-trip 去模拟 Jupiter 已经验证过的交易。

忘了开 dynamicComputeUnitLimit: true 不开的话,某些路由可能因为 CU 预算不够而失败。永远设。

提交前不刷新 quote。 30 秒前的 quote 价格已经过时。延迟敏感的场景下,fetch quote、构建、签名、提交要在很紧的时间窗里做完。

重试时用同一个 blockhash。 Jupiter 给你的交易带一个特定 blockhash。重试时要用新的 blockhash 构造新交易。

同一笔交易提交到多个 RPC。 听起来像冗余,实际造成重复和复杂性。挑一个 RPC 发送。

不处理 Jupiter API 限流。 大量 quote 请求会被限流。非时间敏感的缓存 quote;遇到限流就 backoff。

硬编码 Jupiter URL。 跟 RPC URL 一样,Jupiter 有不同环境。用环境变量。

给交易机器人的具体建议

机器人用 Jupiter 时:

有选择地缓存 quote。 探测多个代币找机会的机器人,可以缓存 quote 几百毫秒。有具体仓位决定的机器人,fetch 新的。

能预构建就预构建。 知道很快要 SOL → TOKEN_X 的 swap,提前 fetch quote 和构建交易,触发时签名提交。

dynamicSlippage: true Jupiter API 支持这个,让系统按路由特征挑滑点容差。通常比你固定数好。

显式设 priority fee。 Jupiter 不替你处理 priority fee,你自己加 ComputeBudgetProgram.setComputeUnitPrice 指令,或者用一个会自动加的封装。

RPC 跟负载匹配。 Jupiter 做路由、Anti-MEV RPC 做发送。读流量贵的话另接一个服务商。

什么情况下不该用 Jupiter

Jupiter 是大多数 swap 用例的对的选择。几个例外:

你对 Jupiter 漏掉的路由有具体理论。 一些 niche 币对用自定义路由有收益。先验证 Jupiter 真的漏了再自己写。

你为了性能直接集成单个 DEX。 一直只在某个特定 Raydium 池上 swap,直接走比 Jupiter 路由层快。

你需要完全控制交易结构。 一些高级模式(带自定义逻辑的原子多 swap、同一笔交易里跟非 DEX 程序集成)需要直接构造。

你做 slot 级高频。 Jupiter API 自己有延迟。亚 100ms 反应度有时候要直接构造。

95% 的用例 Jupiter 都是答案。

这周可以做什么

集成 Jupiter 的话:

  1. 用基础模式把 Jupiter quote + swap 搭起来。 端到端跑通。
  2. 针对真实池子深度测滑点容差。 别用一个静态值跨所有路由。
  3. Jupiter 配 Anti-MEV 写 RPC。 别让 Jupiter 的好路由浪费在被夹的提交路径上。
  4. 加每笔签名级别的遥测。 跟踪哪些 swap 上链了、设了什么滑点、实际成交跟预期差多少。
  5. Profile quote → 提交 → 上链 这一段的延迟。 如果高,瓶颈通常在 RPC。
  6. dynamicComputeUnitLimit: truedynamicSlippage: true 当默认开。

在 Jupiter 集成上试一下 BoltTx

BoltTx 在提交这一侧补 Jupiter:

import { Connection, VersionedTransaction } from "@solana/web3.js";

const connection = new Connection(
  "https://bolttx.io/?api-key=YOUR_API_KEY",
  "processed"
);

// ... 用 Jupiter 构建交易 ...

const signature = await connection.sendTransaction(tx, {
  skipPreflight: true,
  maxRetries: 0,
});

BoltTx 处理提交路径:亚秒级确认、原生 Anti-MEV 路由、专属 SWQoS + 优先级连接。Jupiter 处理路由。这种组合就是大多数跑认真量级的生产 Solana 应用实际在用的。

免费档注册。用真实 Jupiter swap 跑一周,对比有效成交跟当前配置。差额就是 Jupiter 自己关不掉的那部分。

常见问题

Jupiter Swap API 免费吗? 是。API 本身免费。你为实际交易付 swap 费,加上链上 priority fee 和 Jito tip(可选)。

不开 aggregator 账户能用 Jupiter 吗? 能,基础用法不需要账户。一些高级特性和限流提升要 API key。

Jupiter 自动处理滑点保护吗? Jupiter 按你设的滑点容差设最小输出。实际输出低于这个最小值,交易就回滚。

dynamicComputeUnitLimit 干什么用? 告诉 Jupiter 按实际路由设 compute unit 预算。没它,预算可能太低、扛不住复杂路由。

用 Jupiter v4 还是 v6? v6 是当前版,比 v4 有改进。没具体理由就用 v6。

为什么我用 Jupiter 还是被夹? 因为 Jupiter 构造交易、你提交。提交路径对 MEV 机器人可见的话,Jupiter 路由再好你也是三明治目标。修法在 RPC 这一层,不在 Jupiter。

延伸阅读

返回博客列表