Jupiter recurring orders in DCA V2 require a replacement when the schedule changes

A Deposit Spread Across Scheduled Swaps

A DCA V2 allocation moves the token you intend to sell into a vault, and its rounds draw from that funded budget. The interval controls the spacing between attempts. The round count divides the allocation into instalments. The DCA V2 API requires at least two rounds and checks each instalment against its current per-round USD minimum. It rejects a replacement that fails these entry checks. Increasing the count reduces the amount assigned to each round. A recovered balance may therefore support fewer rounds than the original deposit, particularly when the input token’s dollar value has changed.

On Solana, the V2 API uses a per-wallet custodial vault managed by Privy. The order-creation flow prepares a deposit transaction, which the wallet owner signs before the create operation submits it. Sending tokens directly to the vault address does not credit an order. Funds reserved there are also separate from the wallet’s spendable balance. The remaining allocation represents tokens committed to future swaps, while the tokens already exchanged belong to completed trades.

Can You Edit or Pause a Jupiter Recurring Order?

DCA V2 orders cannot be edited or paused; changing the interval, allocation, or price condition requires cancellation and a new order. Restarting after a break also requires a replacement. That order has its own settings and trading history. Its budget should reflect the funds available for the new schedule, with earlier purchases accounted for separately. Through the V2 API, a replacement can specify a future start time within its allowed window. Otherwise, its first round starts immediately.

Open full-size image

Price Bands and Delayed Completion

A price-conditional DCA V2 order fills a round only while its selected trigger token’s USD price satisfies the configured price band. The trigger must be one of the traded tokens and cannot be the stablecoin leg. Price ranges are unavailable for stablecoin-to-stablecoin pairs. Outside the band, the order remains active without increasing its completed-round count. The waiting round is rescheduled, so a change in market price can extend the order’s actual running time.

A time-based order follows its interval without a configured price band. Execution failures can still cause retries and rescheduling in either mode. Insufficient liquidity within the accepted slippage can prevent a round from filling. A scheduled timestamp therefore identifies an intended attempt, rather than confirming a successful exchange. DCA V2 has no order-expiry field. An active schedule runs toward completed fills unless it is cancelled, with the eventual completion time affected by delayed rounds.

What Happens to the Unspent Deposit?

Cancellation returns unfilled input tokens to the owning wallet through a withdrawal, so the recovered allocation can fund a revised trading schedule.

The cancellation request first stops future fills and places the order in withdrawing. Its displayed status can read Pending Withdraw. The deposit remains in the vault at that stage.

The owner then signs the withdrawal transaction, which the cancellation-confirmation process submits. These are separate authorization and settlement stages, even if an interface presents them together. The prepared refund amount identifies the expected return; it does not establish receipt in the wallet.

Cancelling a DCA V2 order does not reverse swaps that have already filled. Filled output and refunded input are different tokens with different roles. The first records what earlier swaps bought; the second funds any replacement schedule. Adding their raw token quantities together would not produce a meaningful available budget.

The V2 API accepts cancellation when a DCA order is active or already withdrawing. The API rejects cancellation while a round is executing. The latest fill and withdrawal records determine what was spent and what remains recoverable.

Why Is My Recurring Order Withdrawal Still Pending?

A pending withdrawal means cancellation has started but its fund-return transaction has not completed, leaving the remaining deposit in the vault. In DCA V2, a failed cancellation confirmation keeps the order in withdrawing. Future fills remain stopped, and the order does not automatically become active again. Reopening the interface changes neither the withdrawal’s settlement status nor the requirement for the owner’s signature.

An interrupted withdrawal can be retried while the order remains withdrawing. If the transaction or its request identifier is no longer usable, initiating cancellation again prepares a fresh withdrawal transaction. This refreshes the withdrawal process without restarting the trading schedule. An authentication error requires a valid session for the owning wallet, which addresses access rather than the separate question of whether a transaction has settled.

DCA V2 does not zero inputAmountRemaining after cancellation. An unchanged figure therefore cannot establish that funds remain locked. Reconcile the order’s status and withdrawal events with the confirmed wallet transfer.

Yield on Capital Between Swaps

Earn While You Wait supplies eligible idle stablecoin capital to Jupiter Lend between time-based rounds, adding lending exposure to the scheduled trading budget. Price-conditional orders do not support this option. Each fill draws its instalment back into the swap. Accrued yield returns on completion or cancellation, although a very small yield balance can enter the final fill. A refund can consequently include yield beyond the unspent input allocation. The rate varies, and the waiting capital carries the lending protocol’s risks alongside the stablecoin’s risks.

Open full-size image

Execution Costs and Automatic Slippage

DCA V2 charges a base fee and any applicable routing fee when each round executes, so the tokens received reflect the fill’s trading costs. Pair category and execution mechanism determine the applicable fees. A new interval changes when those exchanges happen, without fixing their future market prices. Routing draws on available liquidity for each trade. The keeper pays the network and priority fees for scheduled fills; the deposit and withdrawal transactions are separate operations signed by the owner.

Slippage is automatic in the DCA V2 API. The keeper sets the permitted slippage for each round from market conditions, and the order has no user-configurable slippage cap. A USD price band governs whether a round is eligible to execute; it does not fix the number of output tokens received. A replacement order therefore revises the trading plan, while future fills still determine the actual purchased amount.

Individual Swaps and Editable Price Orders

An individually submitted market swap allows a newly chosen amount and timing for every trade. That flexibility can fit plans that need a decision before each purchase. A funded recurring order suits a sequence whose allocation and spacing can remain in place. A standalone Limit V2 order targets a price event and permits updates while open, offering a different approach when a price trigger governs the intended trade.

Cancellation and replacement introduce a withdrawal between the old allocation and the revised schedule. That boundary matters when access to unspent funds takes priority over keeping automation uninterrupted. The already purchased output remains a separate holding unless another trade exchanges it. A replacement budget starts with tokens actually returned to the wallet, such as the 122 input-token units recovered in the hypothetical example.