exchange.IO("dca.*", ...)

Buy or sell in installments with Jupiter's DCA: create, list, cancel and simulate.

    
    
    
exchange.IO(k)

    
    
    
exchange.IO(k, params)

    
    
    
exchange.IO(k, params, wallet)

    
    
    
exchange.IO(k, id)

Examples

• Simulate before creating: buy SOL for 100 USDC a day for 10 days (read-only).

  
      javascript
      
      
  function main() {
      var params = {symbol: "SOL_USDC", side: "buy", total: 1000, numberOfOrders: 10, interval: 86400}
      var sim = exchange.IO("dca.simulate", params)
      if (!sim) {
          Log("Invalid parameters:", GetLastError())
          return
      }
      Log(sim.version, "simulation", sim.ok ? "ok" : "failed", sim.reason || "",
          "per installment", sim.plan.perOrder, "installments", sim.plan.numberOfOrders)
  }
  

• Create a DCA order, check its progress, then cancel it.

  
      javascript
      
      
  function main() {
      var params = {symbol: "SOL_USDC", side: "buy", total: 200, perOrder: 100, interval: 3600,
          maxPrice: 300}
      var r = exchange.IO("dca.create", params)
      if (!r) {
          Log("Create failed:", GetLastError())
          return
      }
      Log("Created", r.version, r.id, "transaction", r.signature)
      Sleep(5 * 60 * 1000)
      var list = exchange.IO("dca.list", {symbol: "SOL_USDC"}) || []
      list.forEach(function(d) {
          Log(d.id, d.state, "filled", d.ordersFilled, "/", d.numberOfOrders,
              "spent", d.spent, "received", d.received, "average", d.avgPrice)
      })
      var c = exchange.IO("dca.cancel", r.id)
      Log("Cancel:", c ? JSON.stringify(c) : GetLastError())
  }
  

Returns

Arguments

See Also

Remarks

v1 and V2

exchange.IO("trigger.api") applies to DCA too: v1 keeps Recurring v1 and v2 forces V2. Jupiter no longer maintains Recurring v1 (it still works). DCA orders do not appear in exchange.GetOrders() and the other order functions; view them with dca.list.

DCA parameters

dca.create

Returns {id, version, signature, symbol, side, total, perOrder, numberOfOrders, interval, minPrice, maxPrice, startAt, priorityFeeLamports}, with version v1 or v2. v1: the total goes into a new DCA order account, signature is the creation transaction, and the call waits for the broadcast only, not for confirmation; the number of installments, the amount per installment (valued in USD with the Jupiter price API) and Token-2022 are checked locally first. V2: the total is deposited into the vault (the connector signs the deposit and Jupiter lands it while creating the order, so it has landed on return), id is the order UUID, plus vault.

dca.list

Lists this wallet's DCA orders (v1 first, then V2 when an API key is set or trigger.api is v2). Parameters {status, symbol}: status is active (default, running) or history (ended), and symbol limits the list to that pair. Each item is {id, version, symbol, side, state, total, perOrder, numberOfOrders, ordersFilled, interval, minPrice, maxPrice, spent, received, filledQty, avgPrice, fee, createdAt, updatedAt, openTx, closeTx, info}:

• state is active, completed or canceled, and for V2 also pending (depositing), canceling (canceled, funds not yet withdrawn) or failed (deposit failed).
• spent is the input token spent so far, received the output token received and fee the fee deducted from it (in the output token; null for V2); filledQty and avgPrice are the filled amount and average price in base-token terms; V2 rows also carry nextFillAt; info is Jupiter's raw row.
• Jupiter indexes a new v1 DCA order with a delay of a few minutes; meanwhile an order this program created (within 10 minutes) whose on-chain account exists is listed under active too, with indexed false and the numbers from the on-chain account (ordersFilled, fee, updatedAt and closeTx null).

dca.cancel

Cancels a running DCA order; v1 and V2 are told apart by the shape of id (V2 needs the API key or trigger.api v2). Rounds already filled are not reversed.

• v1: the remaining input token and any output token not yet withdrawn return to the wallet; the call waits for the broadcast only and returns {id, version, signature, priorityFeeLamports}. A v1 order Jupiter has not indexed yet (in the first minutes) can be canceled too as long as its on-chain account belongs to this wallet: the connector builds the cancel transaction itself from the DCA program's close_dca instruction, simulates it, then signs and broadcasts it, and the result adds indexed: false.
• V2 takes two steps: Jupiter stops the order and builds a withdrawal transaction, which the connector checks, signs and hands back to Jupiter to land; it returns {id, version, signature, refund, refundCurrency, roundsRemaining, info}, signature being the withdrawal and refund the input token returned. If the second step fails the order stays canceling, and canceling it again completes the withdrawal.

dca.simulate

Builds the transaction of dca.create from the same parameters and runs it with the node's simulateTransaction (not signed, nothing broadcast), to check balances, minimums and so on before ordering; with params written {cancel: id} it simulates canceling that DCA order. Returns {ok, err, reason, logs, unitsConsumed, version, wallet, id, plan, priorityFeeLamports}: ok tells whether the simulation succeeded and reason explains a failure (when the paying wallet has no SOL at all the node only returns err AccountNotFound, and reason is AccountNotFound (the paying wallet has no SOL)); id is the address of the DCA account that would be created; plan holds the normalized parameters.

On V2 the deposit into the vault is simulated, only for this wallet, and the result carries vault and no id; the call fails while the wallet has no vault, so register one first with exchange.IO("trigger.vault", "register") (no funds move). Canceling a V2 DCA order cannot be simulated (the cancel call itself stops the order).