Sushiswap DCA divides token trades into scheduled swaps

Regular portions spread the exchange across changing prices

Splitting an allocation reduces the amount exchanged at any single execution time, so different fills may receive different rates as the market moves. The order spends the input token and receives the destination token. For equal portions, the trade size follows the total allocation divided by the scheduled trade count. The chosen interval controls spacing between fills.

A fixed token quantity can change in dollar value when that token changes price. Token-denominated scheduling therefore needs separate valuation if the intended budget is in dollars. Recurring purchases also retain exposure to the destination token: spreading purchases across dates cannot prevent that token from losing value.

The order record separates placement from execution

Before placement, the selected network and pair must support DCA, and the wallet needs the input-token balance and spending permission required for the first portion. The allocation, trade count and interval define the schedule. A price condition, when selected, constrains which executions qualify.

The controls distinguish Every, the estimated interval between trades, from Over, the number of scheduled trades. The order review should reflect the chosen amounts, timing and price condition before confirmation. The underlying contract also gives the order a deadline. That deadline ends its execution window even if some of the allocation remains unspent.

The creation transaction establishes the order. It does not establish that the entire allocation has changed tokens. Successful fill transactions establish the exchanged amounts.

Open full-size image

Network support includes more than a visible token pair

DCA requires an order deployment on the selected network and an executable route for the selected pair. Ordinary swap availability does not establish scheduled-order support. The wallet, input-token contract and order contract must correspond to the same network. A token name may identify assets on several chains, while each deployment has its own address and balance. Cross-chain swaps address movement between networks; DCA spreads trading through its supported order deployment over time. The network associated with an active order remains relevant when viewing its fills or managing it.

Will every DCA trade execute exactly on schedule?

DCA trades can execute late because the interval sets eligibility, while a taker bid and a successful fill transaction determine whether each portion fills. The Orbs integration uses dTWAP, short for decentralized time-weighted average price. Participants called takers propose execution paths for eligible portions. Bidding allows competing proposals before the winning taker submits the fill transaction. The winning taker must wait for the order's bidding delay to elapse before filling the portion.

The interval measures minimum spacing from the previous fill, so delayed execution can shift later eligibility. An unavailable route or an unmet price condition can prevent a fill. The selected trade count describes the intended schedule; it does not establish an exact completion time.

Why can actual DCA output differ from its estimate?

The estimated total uses prices available before future trades occur, whereas the received total comes from the output amounts transferred by successful fills as they settle. Later trades encounter later market conditions. An estimate for the full schedule can therefore differ from the final quantity received. For a partly filled order, the settled output represents only the portions that executed.

Dividing input tokens spent by output tokens received gives the realized exchange ratio, expressed as input units per output unit. This calculation uses settled amounts for the same order and token pair. A dollar-denominated result requires a separate valuation basis. When transfers already reflect deducted fees, subtracting those fees again would understate the received quantity.

Allowances leave future portions exposed to wallet changes

The dTWAP contract draws tokens from the order creator when a fill executes, so unused input tokens remain in the wallet between scheduled trades. An allowance authorizes the specified contract to spend the input token. The balance measures what the wallet actually holds. A dTWAP portion requires sufficient input-token balance and allowance before it can receive a valid execution bid. Spending the token elsewhere or reducing permission can make a later portion ineligible.

Anyone can cancel an active order through a pruning transaction once a portion is due and its required balance or allowance is missing. Adding funds afterward does not reactivate a canceled order.

Fees apply to fills and their execution

Successful portions incur the applicable swap and interface charges, alongside the costs of executing their transactions. A dTWAP taker fee, when charged, comes from the output tokens of the fill. The taker pays for execution and incorporates its requested compensation into the bid. Compare the received output after these deductions with any separately paid transaction costs. More portions create more execution events. However, splitting an unchanged allocation does not multiply a uniform percentage charge by the trade count. Repeated transaction costs can increase the total expense, especially when each portion is small relative to the execution cost.

A replacement order changes future trades

An active DCA order has fixed parameters, so changing its interval, trade count or price condition requires canceling the existing order and creating a replacement with new settings. Cancellation stops subsequent execution once its transaction takes effect. Earlier fills retain their exchanged tokens. The replacement allocation should reflect the unspent quantity after any recent fills, including execution that occurred before cancellation settled. Spending permission is separate from the order record: canceling an order does not itself revoke the token allowance that the wallet granted to the contract.

Longer DCA schedules and shorter TWAP schedules serve different objectives

A longer DCA schedule distributes acquisition or disposal across different market conditions, while a shorter TWAP schedule can divide an exchange intended for a narrower execution window. Both use recurring portions, yet a longer period exposes the remaining allocation to more intervening price movement.

Price impact depends on each trade relative to available liquidity. Gaps between portions can give arbitrage activity time to reduce price discrepancies in liquidity pools. Market drift can still offset that benefit, and thin liquidity can remain problematic for individual portions. Neither a longer interval nor a higher trade count guarantees a better overall exchange rate.

Market schedules and price limits answer different priorities

A market DCA order seeks fills at available prices, while a price-limited DCA order requires each executed portion to satisfy its specified output condition. A restrictive condition can leave the order partly filled when its deadline arrives. Market execution removes that chosen price target, while retaining the need for a usable route and sufficient funds. These alternatives balance willingness to exchange at prevailing prices against willingness to leave tokens unspent. An immediate swap concentrates the exchange in one execution window; a DCA order leaves later portions subject to later market conditions.