> ## Documentation Index
> Fetch the complete documentation index at: https://docs.defiloops.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Running it without you

> Schedules, limit orders and chains, the three ways a plan starts when you are not there

A plan you press **Run** on is the simple case. The point of describing a
strategy rather than doing it is that most of it should happen while you are
elsewhere.

Three things start a plan on your behalf:

|                   | fires on                     | example                                              |
| ----------------- | ---------------------------- | ---------------------------------------------------- |
| a **schedule**    | a clock                      | claim the rent on the first of every month           |
| a **limit order** | a price                      | buy if cbBTC comes back to 80,500                    |
| a **chain**       | the plan before it finishing | buy the property, *then* start the monthly rent loop |

## They are all the same shape

**A price is a trigger exactly as a clock is.** A schedule and an order both name
a plan they do not contain, hold no signature, and compile a **fresh** plan every
time they fire.

That last part is the one worth understanding, because it is what makes leaving
something armed for months reasonable. Nothing is signed in advance and nothing
is sitting there pre-authorised. When the clock strikes or the price arrives, the
plan is compiled from scratch, quoted against the market as it is at that moment,
and signed then: with the bounds you set applied to the numbers of that day, not
of the day you set it up.

So a schedule is **not a step**. There is no "every month" you can put inside a
plan, and adding one would be wrong: a step's id goes on chain, and a step that
means "wait thirty days" would be a transaction that never settles.

## Arming is its own decision

A saved plan does nothing. A saved schedule does nothing until it is **armed**,
and arming is deliberately separate from writing: from that moment it fires
unattended and spends real funds every time.

The agent can write all three and cannot arm any of them. Placing an order and
arming a schedule are gated exactly as pressing Run is, for the same reason: a
resting order commits money for as long as it rests.

A schedule is **disarmed**, **armed** or **paused**, and the first two are not
the same as the third. Disarmed is waiting on the plan before it in a chain.
Paused is waiting on a person.

## When a firing cannot run

**One plan runs at a time per account.** So a monthly firing can arrive while an
earlier run is still going, or while one is parked at an approval gate waiting
for you, which waits indefinitely. The firing is refused and recorded as
**blocked** rather than dropped silently, and it asks you which you meant:

* **run it as soon as the account is free**, not "try again now", because the
  reason you were asked is that it is busy
* **skip this one**. This firing only; the schedule keeps its future dates

An unanswered blocked firing is dropped after a week. Whether that is safe
depends entirely on the plan: unclaimed rent stays claimable, so skipping a rent
firing defers money rather than losing it. That is not true of every plan, which
is why it is your decision and not a default.

## A limit order fills in pieces, and that is normal

An order rests as a rate and a size. When the price crosses, the plan is compiled
**sized to what is left**, so a fill of 40% leaves the other 60% resting, and it
re-arms and keeps waiting.

That is worth expecting rather than being surprised by. A large order against a
pool that cannot absorb it in one go is *supposed* to arrive in pieces, and each
piece is a separately compiled, separately signed plan with its own floor
enforced on chain. See [bounded execution](/routing) for how a size is chosen and
[does splitting cost less?](/splitting) for when arriving in pieces is cheaper
than arriving at once.

An order ends by itself when it is fully filled. Until then
"what am I waiting on" is always answerable.

## A chain is plans in order

A chain is how "do this, then keep doing that" is expressed without forcing two
different rhythms into one document. Buying a property runs once. Splitting its
rent between the debt and more collateral runs every month. They are edited,
approved and re-run on completely different schedules, so they are separate
plans with a chain naming the order.

A stage without a schedule runs its plan once and the chain waits for it to
**succeed**. A stage with one **arms** the schedule and carries straight on;
arming is instantaneous, and a recurring stage has no completion to wait for.

**A stage that ends stuck stops the chain and arms nothing after it.** That rule
is doing more work than it looks like. A run that ends stuck is finished as far
as the execution engine is concerned, and claiming rent on a property that was
never bought harvests zero and *succeeds*, so a chain that carried on would arm
a monthly loop that quietly does nothing, for ever, while reporting success every
month.


## Related topics

- [FAQ](/faq.md)
- [DeFiLoops](/index.md)
- [How it works](/platform.md)
- [Adapters](/adapters.md)
- [Every tool](/tools/reference.md)