# Plan Progress (/docs/nodes/utility/plan-progress)

The durable counter behind multi-order plans. Tracks which order a plan is on so overlapping runs never trade the same order at once.



Plan Progress is the bookkeeping behind a multi-order plan such as a DCA. It remembers which order the plan is on, how much of the allocation has been spent, and which run currently owns the order that is about to trade.

You cannot add it yourself. It has no entry in the node palette and the copilot compiles it into the workflows that need it. You will see it on your canvas as **Claim order (1 of 12)** near the start of the graph and **Record filled order** near the end.

```text
[Every 30 minutes] -> [Claim order] -> [Size order] -> [Quote] -> [Swap] -> [Record filled order]
```

The two nodes are one mechanism. The first one asks "is an order due, and is it mine to run?", the second one records that the order actually happened.

What it guarantees [#what-it-guarantees]

**Progress survives everything.** It lives in its own store with no expiry, so pausing the workflow, disabling it, editing an unrelated node, or a week of orders held back by a price limit all resume exactly where the plan left off. A finished plan stays finished.

**Two runs can never hold the same order at once.** Claiming an order leases it for about ten minutes. A second run that starts while the first is mid-order sees the lease, reports that another run holds the order, and skips its tick rather than trading alongside it. The guarantee is no concurrent claim, not no retry: an order whose attempt failed becomes claimable again once its lease lapses, deliberately.

**A dead run does not lose its order.** There is no release step to forget. If a run crashes or an order is rejected between the claim and the fill, the lease simply lapses and a later tick picks the same order back up.

**Only a completed order moves the counter.** The counter advances after the swap step succeeds (while plans run simulation-only, that means a successful dry-run simulation), never after a rejected quote, a failed swap, or a tick that decided to hold. Idle and failed runs never advance the fill count or the spend record, though claiming an order does write its lease bookkeeping.

**The allocation is measured once.** A percentage allocation reads your balance at the first order and stores it. Later orders divide what is left of that stored figure, so selling does not shrink every remaining slice as the balance drops.

When a plan is finished [#when-a-plan-is-finished]

A plan is done when every order has filled, or earlier if the allocation runs out. The second case is real: an allocation too small to give each remaining order at least one raw unit of the token is spent across as many orders as it can fund, and the plan reports complete there rather than idling forever on orders it cannot size.

Once a plan is finished, its ticks do nothing. The workflow keeps running on its schedule and the plan reports that it is complete, which is why the run log shows an idle tick rather than an error.

Editing a plan [#editing-a-plan]

Progress is keyed to the money-shaping settings of the plan: the pair, the direction, the order count, the allocation, and the jitter. Refining any of those starts a **new** plan with fresh progress, because a smaller plan resuming a larger one's spend record would work through the wrong budget. Cadence and reporting are deliberately excluded, so rescheduling a plan or changing where it messages you keeps its progress.

The order count is pinned when the plan starts. If a workflow is edited or imported with a different count, the run is refused rather than trusted, since shrinking a ten-order plan to one would otherwise mark it complete after a single fill and strand the rest of the allocation.

Deleting the workflow deletes its progress.

Simulation only, for now [#simulation-only-for-now]

A workflow containing Plan Progress will not run if any node in it executes live transactions. The check runs once before any node executes, so nothing is broadcast and then refused halfway.

This is deliberate. The lease is a retry mechanism for failures that happen before anything irreversible, which is sound while the trade is simulated. It is not sound for a live trade: if a transaction reached the chain and the run died before the fill was recorded, the lease would expire and the same order would become claimable again. Live multi-order execution needs order-level reconciliation against the chain, and it ships when that does.

Rehearsals and previews never consume an order. They synthesize a first-run state so the sizing logic downstream can be rehearsed without touching the real plan.