feat: add Jupiter Limit Order V2 support (Solana)

[Pepewitch]

Summary

Add trade limit commands for Jupiter Limit Order V2 on Solana — create, list, cancel, and update trigger-based orders.

Commands

• trade limit create — place a limit order (deposit + order in one flow)
• trade limit list — list orders with --state active|past filtering, pagination, mint filter
• trade limit cancel — cancel an order (withdrawal + confirmation)
• trade limit update — update trigger price and/or slippage on an existing order

Design decisions

• Amount convention matches swap: base units by default, --amount-unit token for human-readable (e.g. --amount 1.5 --amount-unit token)
• Slippage convention matches swap: --slippage 0.03 (decimal, 3%) — converted internally to bps for the API
• Shared utilities from trading.js: resolveTokenDecimals(), convertToBaseUnits(), validateBaseUnitAmount(), resolveTokenAddress() — no duplicate infrastructure
• JWT auth: challenge-response with 23h TTL disk cache at ~/.nansen/limit-order-auth.json
• Wallet support: local wallets, Privy, and WalletConnect
• Auto vault registration: first-time users get a vault registered transparently
• 5xx ghost-order recovery: if createOrder returns 5xx, checks recent orders (matching token pair, amount, trigger price, and timestamp) to warn about duplicates before the user retries

Files

File	What
src/limit-order.js	Core module: auth, signing, wallet resolution, all 4 command handlers
src/cli.js	Route trade limit <sub> to limit-order handlers
src/schema.json	Option docs for create, list, cancel, update
src/privy.js	signSolanaMessage() for Privy wallets
src/walletconnect-trading.js	signSolanaMessageViaWalletConnect() for WC wallets
src/__tests__/limit-order.test.js	96 unit tests

Test plan

• npm test — 1378 tests pass (96 new for limit-order)
• npm run lint — clean
• Dogfooded locally:
  • Created orders: SOL to USDC, SOL to TRUMP, SOL to ORCA (all succeeded)
  • Created order: SOL to PUMP (correctly rejected — transfer hook extension)
  • Listed orders with --state active, verified formatting
  • Updated order (trigger price + slippage), verified via list
  • Cancelled all orders, verified withdrawal transactions on Solscan
  • Insufficient balance returns clean error (no misleading ghost-order warning)
• 5xx ghost-order check: only triggers after createOrder call, not on pre-submission errors
• Schema.json updated with correct API state values (active/past)

Generated with Claude Code

[TimNooren]

@Pepewitch Thanks🙌 Some small comments. My main concern is the interface, since it's going to be difficult to change once released. I think the current nansen trade quote/execute interface is not ideal, but I'd say having at least a consistent interface for now is more important, so let's stick with it.

Let's also add a changeset file🙏

[TimNooren]

IIUC the unit here is the human-readable amount. In nansen trade quote/execute we use raw amounts (i.e. not adjusting for decimals). Maybe we should be consistent at least? We can add a --amount-unit, similar to #324.

Also, I saw that this needs to be >$10. Might also be good to document.

[TimNooren]

In nansen trade quote/execute we use slippage and it's a human-readable percentage. Would be good to be consistent.

[TimNooren]

This is currently not correct right?

[TimNooren]

Can we extract this code then instead of duplicating?

[TimNooren]

💭 nansen trade limit?

[TimNooren]

This should probably not be included.

[0xlaveen]

Smoke test results (Privy wallet, Solana mainnet)

Ran 42 end-to-end tests against a Privy server wallet (Hm6a7ZkpPqTHZVqueaPNQRD4t7mg9DKPECpGo1QcFXjR) on mainnet. Full lifecycle verified across SOL→USDC, SOL→JUP, and SOL→WBTC (Wormhole) pairs. All 4 commands work. All 1180 unit tests pass.

Bug fixed during testing: --state query param should be --status — the API rejects state with "Request validation failed". Fix is in a follow-up commit on the branch.

Two issues flagged below in inline comments.

— Ari

[0xlaveen]

create doesn't validate slippageBps range client-side, but update does (line 831). If a user passes --slippage-bps 20000, it passes through to the API which rejects it with: Too big: expected number to be <=10000. The error message is decent, but for consistency with update we should add the same client-side check here:

if (slippageBps != null && (slippageBps < 0 || slippageBps > 10000)) {
  log('Error: --slippage-bps must be between 0 and 10000 basis points.');
  exit(1);
  return;
}

[0xlaveen]

This is the most impactful UX issue I found during testing. When createOrder returns a 500 Gateway Timeout (which happened intermittently from Jupiter), the CLI reports an error — but the order was actually created on the backend. The user thinks it failed, retries, and creates duplicates. During testing I accumulated 7 ghost orders this way.

Suggestion: catch timeout/5xx errors specifically and follow up with a listOrders check:

} catch (err) {
  if (err.status >= 500) {
    log(`Warning: Order submission returned an error, but may have succeeded.`);
    log(`  Checking order status...`);
    try {
      const check = await listOrders(token, pubkey, { limit: 1 });
      const recent = check.orders?.[0];
      if (recent && recent.inputMint === from && recent.outputMint === to) {
        log(`  Found recent order ${recent.id} (status: ${recent.status}). It may be yours.`);
        log(`  Run: nansen trade limit-order list`);
        return;
      }
    } catch { /* list check failed, fall through to error */ }
  }
  log(`Error: ${err.message}`);
  // ...
}

This saved me a lot of confusion during testing — orders were silently created despite the error output.

[TimNooren]

Should trading-api protect against this instead of the user? And we should maybe rely on depositRequestId instead of ecent.inputMint === from && recent.outputMint === to? @Pepewitch