What it can do

In short: this is everything a plan can do: supply collateral, borrow and repay on lending markets, swap one token for another, wrap ETH, move money between networks, and raise or cut the leverage on a loan in one step. If your collateral is falling and your loan is getting close to liquidation, the steps that help are repay, withdraw and deleverage, and one plan can chain them together. An operation is one thing DeFiLoops can do: supply collateral, borrow against it, swap one asset for another, move money to another network. A plan is a list of steps, and each step uses one operation. It can run 80 operations across 11 protocols and venues on 4 networks. New operations are added over time, so that page has the current answer. This page covers the rules that stay true as the list grows.

​

A plan uses a fixed set of actions

A plan can only name something on the list. There is no way to write “call this contract with this data” into a plan. This rule is enforced, and it is what makes the whole thing safe to hand to a model. A plan naming anything else is refused when it is written, rather than attempted and failed halfway. Adding to the list is cheap. A new venue is a new entry, not a change to how plans work, so plans written before it existed keep their shape. The fixed set of actions is what keeps plans safe, and adding to it quickly does not weaken that.

​

Every operation carries a version number

A step is written as lend.supply@v1.1. A bare name with no version is refused. A workflow can wait a long time while the software underneath it changes. Without a version pinned to it, a job that outlives an update could start doing something different halfway through, and nobody would notice. When several versions would do, it picks the oldest one that fits. The newest is code your plan was never shown.

​

Network coverage is not uniform

Almost every operation runs on Ethereum, Base and Arbitrum. Buying and selling property, and the four rent operations, run on Base only. HyperEVM carries a small set: sending, receiving, moving USDC to another network, and trading on Hyperliquid. Networks shows what runs where. This changes as we deploy. Operations that once ran on one network now run on all three, so a plan refused last week can work today.

​

Crossings between networks finish later

Most steps finish when their transaction goes through. Moving money to another network does not. It finishes when something outside the transaction happens, so the run has to wait rather than check a receipt. A crossing usually lands within a couple of minutes, and nothing here can hurry it. A plan is built around that wait, and a step on the far side cannot start early. Two crossings are in the catalogue: one moves USDC, the other moves USDC or WETH. Both finish the same out-of-band way, so the wait above applies to any crossing, not just one route. Moving between networks has the routes, the fee and the expected times.

​

Steps that share a transaction

Steps that belong together are merged into one transaction. A merged group is all-or-nothing. If the last call fails, the first is undone too. This has two effects:

• It is what makes “give permission, then supply” safe. The permission cannot survive a failed supply and sit there afterwards as a standing allowance.
• It is what makes a very long merge a bad idea. One failure at the end throws away everything before it.

Merging is free, so it stays maximal. Splitting a group so a later one can start sooner is a loss: it cannot reduce the number of waves and always costs an extra transaction.

​

Order is worked out, not taken from your list

You write steps top to bottom, but the run does not execute them that way. Steps that do not depend on each other run at the same time. What depends on what is derived from the plan itself, by looking at which steps touch the same balances and the same lending positions.

​

What a step produces

Two questions look like one here, and confusing them produces a plan that does something nobody meant.

• Does it produce anything? This decides whether a later step may refer to its result.
• What is that number? One step produces an amount of USDC. Another produces the identifier of a position. Both are large integers travelling down the same wire.

Without saying which, “swap what the last step produced” is a well-formed plan that swaps a position identifier as though it were an amount. Nothing raises an error, and the result is a trade nobody meant. The same applies to a step’s own amount. It can be an amount of an asset, a number of property shares, the identifier of a position, or all of whatever is there. That last one exists because collecting rent takes whatever has built up, and nobody knows that figure when the plan is written.

​

Under the hood

Useful if you are evaluating the design. Not needed to use the product.

​

What a step can carry

A step’s fields have fixed kinds: There is deliberately no “raw bytes” kind and no “anything” kind. Either would let a caller smuggle a raw instruction through a field, and then the agent could write instructions instead of only supplying these values. Three of those need more explanation. A market is a name, not an identifier. Some lending protocols let anybody create a market. An identifier would let a plan reach a market nobody vetted. A market decides the price at which you are liquidated, so that is a plan choosing the terms of its own liquidation. A property is separate from a market, even though both are curated lists, because they are curated for different reasons. A market is curated because it sets a price. A property is curated because it is a claim on a real building with exactly one contract behind it. They were once the same kind, and the plan designer offered lending markets for a field that wants a property token. A price is two whole numbers, never a decimal. A decimal has to be converted against two different token scales somewhere. Every place that happens is a place a limit can be multiplied by a million by mistake. As a pair of whole numbers there is nothing to convert.

​

Order has a failure mode, and it is silent

A step nobody has classified, or one that touches no balance, gets no entry in the dependency map. That means “wait for everything above it”. The result is correct but slow. The plan still runs, just one step at a time, and nothing says why. So adding an operation has an ordering consequence: classify it, or every plan using it runs serially from that step down. A declared dependency can add order and never remove derived order, so getting it wrong costs time and never money.

​

One step spending what the last one delivered

A swap’s output is not known when a plan is approved. There is a mechanism that lets the next step spend what the previous step actually delivered. It only works inside a single transaction. A producer in one transaction and a consumer in another finds nothing there and fails. The error names the step that was supposed to produce the value, so it reads as being about the step before. This matters because a network crossing is deliberately placed alone in its own transaction. Two steps running on the same network is necessary and not sufficient. The question is whether they share a transaction. Both settings that turn this on are off by default, because it changes how money moves.