Jupiter Limit Orders and DCA: The Rent Trail Most Traders Ignore

Jupiter is the default aggregator on Solana, and for many users it's the default DEX interface as well. Beyond the swap UI, Jupiter offers two automated products — limit orders and dollar-cost-averaging (DCA) schedules — that behave more like standalone smart contracts than a swap. Every order and every schedule creates its own on-chain account with its own rent deposit.

How limit orders work under the hood

When you place a Jupiter limit order, the interface builds a small account that holds the order parameters (input mint, output mint, target price, expiry) plus the input tokens themselves. A keeper monitors the price and, when the order becomes fillable, executes the swap and delivers the output tokens to your wallet. The account is what makes the order composable and cancellable.

The account has a rent deposit of roughly 0.002 SOL. When the order fills or is cancelled, the intent is for the account to close and the rent to refund. In practice, the close doesn't always run — especially for orders that fill in edge cases, or for orders cancelled during high-load periods where the close instruction gets dropped. The account survives, the rent stays locked, and you don't notice because Jupiter's UI stops listing the order once it's no longer active.

DCA schedules

DCA on Jupiter creates a schedule account that runs a swap at a fixed interval — say, buying $100 of SOL every day for 30 days. The schedule holds the input balance, the parameters, and a small execution buffer. Rent runs around 0.002 to 0.003 SOL.

Completed schedules — where the full input balance has been swapped through — should close automatically at the end of the last execution. Cancelled schedules should close at cancel time. Both paths sometimes fail to close the underlying account, especially cancellations issued after long dormancy. If you've run DCA on Jupiter and stopped, it's worth checking whether the schedule accounts actually closed.

Finding them

Jupiter's limit order and DCA programs are both public. Query them with a filter on the maker or owner pubkey and you get every account they created for your wallet. Cross-reference against active orders in the Jupiter UI — anything that isn't currently active is a candidate for close.

Closing

Each program exposes a close instruction. For limit orders that filled, the close is straightforward. For orders that were partially filled and cancelled, you may need to withdraw remaining input tokens first — the account can't close while it still holds funds. DCA schedules follow the same pattern: withdraw any residual input, then close.

The recovery per account is small — around 0.002 SOL — but the count adds up for anyone who's used these products actively. A wallet with 20 old limit orders and half a dozen completed DCA schedules is looking at roughly 0.05 SOL of recoverable rent, plus whatever residual input tokens might still be sitting in the accounts.

Part of a full recovery

Jupiter accounts are one of the smaller categories in a full wallet recovery, but they're also one of the least-visible — most users have no idea these accounts persist. Any scan that only covers empty token accounts will miss them entirely. A complete recovery flow checks Jupiter limit orders, DCA schedules, wSOL residuals, OpenBook orders, and everything else in a single pass.