> ## 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.

# Going live: approval, limits and stopping

> What you sign when you approve a card, the caps and budget it carries, what a firing is, and every way a card stops.

**In short:** you approve a card on one page, where you read what the checker says it can and can never do, the backtest and the limits, and sign them. You then start it on paper or live. A live card spends from the budget you set aside, inside the limits you signed, without asking each time. You stop it from its card page or the kill switch. Stopping moves no money and reverses nothing.

## What you approve

The approval page shows four things.

1. **What the card can and can never do.** One paragraph written by the checker from the card itself, never by the agent that helped you write it, so the agent cannot talk it into saying something false. You are never asked to approve the description written while the card was drafted.
2. **The backtest.** The card against holding, over the same days with the same costs, and the number of variants tried. A card with no backtest shows the reason, and lists every order, swap and collect it will run.
3. **The limits you sign.** Or a line that says the card has none and your defaults apply.
4. **What this version allows that the last approved one did not.** For a first version it says there is nothing to compare. A version that allows more than the one before it lists exactly what widened, and you sign those widenings too. If the comparison could not be made, the page says so. It is never read as "no wider".

You sign with your passkey session or with your wallet. A signature from a wallet that is not your account's owner is refused.

**What your signature covers:** you, the version, a fingerprint of the exact program that will run, the line from item 1, the report you saw, the limits as written, and the widening. Because the fingerprint is in it, a card edited after its backtest is a different card, and your signature does not cover it.

**Approving freezes the version.** Its card, measures and runtime can never change from then on. A change of any kind, even one limit, is a new version that is backtested and approved again.

A card that runs once is approved by a lighter step in chat. You confirm with "Yes, run it once". The confirmation covers the checker's line and the exact amounts it states.

## Starting it

Start an approved version on paper or live from the approval page or the kill switch page. The start goes through the same check as every other start: your signed approval, the runtime the version was approved on, and the kill switch.

A live card needs a `BUDGET` line. A start without one is refused, before anything is set aside. The one exception is a clock card that only collects your Uniswap fees and spends what it collected.

A live start also checks that your wallet holds the budget and has allowed it to your account, and names what to add if not. Paper and backtests assume the money is there.

## The budget

`BUDGET` is the part of your account one card may use, as a quantity of each token, never a share.

* Inside a card, "my USDC" means what this card holds, starting from its budget. A card cannot sell what another card bought.
* A budget can come from your wallet, from your account's own balance, or from your Aave v3 supply.
* The budgets of all your cards in one token cannot add up to more than your wallet holds. If your wallet later holds less than the cards add up to, the shortfall is reported and new entries in that token are blocked until it is whole again. Nothing scales a card down, sells anything or moves money between cards.
* A firing the budget cannot cover is skipped, never traded in part. Fees and gas count against the budget.

## The limits

`LIMITS` is a line of caps. The host re-reads every cap from what you signed when a firing is claimed, and refuses a firing that goes past one, even if the card's own engine produced it.

| you write | it means |
| - | - |
| `at most once a day`, `at most 3 times a week` | at most that many firings in the period |
| `never more than $5,000 per run` | one run moves at most that many dollars |
| `never more than $20,000 per week` | at most that many dollars in the period |
| `stop after 52 runs` | after that many runs the card does nothing more |
| `at most 1% below market per swap` | the widest price slippage a swap may accept |
| `at most 10 actions per run` | a run writes at most that many steps |

A card that says nothing about a kind of cap gets these defaults, which are yours: a run may move up to \$1,000,000, and there is no default limit on the steps of a run, the dollars of a week or the firings of a day. What you write only tightens them.

> [!WARNING]
>
> **A card with no frequency limit can fire on every bar it is true.** A rule that could do so is refused unless it has a guard, such as `this strategy holds no cbBTC` or a frequency limit. Write the caps you want into the card. Do not rely on a default.

A swap also faces checks outside the card. When you save the card, the router's price for each pair it swaps is compared with an independent reference, and a gap of more than 2% refuses the card. At save, at approval, at every start and when an order is placed, a slippage or band wider than 1.5% is refused, and so is a token outside our list for that network. When a swap is signed, the enclave checks its floor once more against its own price source. [The hardware enclave](https://docs.defiloops.com/security/enclave.md) says what that last check covers on its own.

## Firings

A firing is one decision. A rule found its conditions true on a closed bar and wrote its steps.

* One firing is one record, written once. It is keyed by the card version, the rule and the time of the bar. If the service restarts and replays the bar, the record exists and the card does not fire again.
* Each firing says why. The explanation names every condition and the value it saw, in the card's own words and units.
* A firing keeps what the card chose to remember, such as what it paid, so a restart carries on from the last firing.

The card page shows each firing with its swap and fill. A refused firing says why and spends nothing. If the agent's signer refuses a firing, the firing is set aside as "parked" and the card keeps running. You can always stop it by hand.

## What stops a card

| what | when |
| - | - |
| **a limit** | `stop after N runs`, or a cap that a firing would pass |
| **the budget** | a firing the budget cannot cover is skipped. The card keeps waiting until it can |
| **Stop this card** | you press it on the card page |
| **Stop all my plans** | you press it on the kill switch page. It also refuses new starts for you until you press "Allow plans to start again" |
| **a new version** | replacing a running card checks the new one first. The old one keeps running until the new one passes |
| **an operator's stop** | an operator can stop every card for every account |

Stopping a card ends its evaluation, releases the measures it was reading, and gives back what its pending decisions had set aside. A card does not wake on the next bar.

**What stopping does not do.** It moves no money and reverses nothing. A swap already sent is not undone. It stops what the card would decide next.

You can stop only your own cards. Every press is recorded, with who pressed it and how many cards it stopped. Starting again is a new start, and it goes through approval again. Allowing starts again starts nothing by itself.

## Where your money is while a card runs

A card acts through your account, with the same limits as the agent everywhere else: it can run steps from an approved list, it cannot send money to an address of its own, and only your wallet can take money out. See [Your account and your keys](https://docs.defiloops.com/kernel.md). A card can still make a losing trade inside its limits.

## Under the hood

This part is for readers who want the mechanism.

The approval is an EIP-712 signature. The older form signs the owner, the version, the card's tree hash, the derived line, the report and the limits. The newer form adds a digest of what widened and the version it was compared with. One check in front of every start holds the stored approval to the signed one, and the same function decides a start and a replace.

A card's firing is claimed by inserting a record in the same transaction that checks the caps, so two workers racing for the last place under a cap are in line, not both let through. The first firing of a rule goes through a durable workflow with an id made from the card and the bar. A live card books the fills of its executed runs into its own ledger, once each.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.