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

# DeFiLoops

> How the platform, the kernel, the adapters, the tools and the skills fit together

**The execution layer for multi-step DeFi.** You describe a strategy in one
sentence; an agent compiles it into steps and keeps running it on an account
only you own. Non-custodial throughout: the agent signs and the relayer pays,
and neither can hold a token or was ever given your key.

These are the written explanation of that stack: what runs, what it is allowed
to do, and where each boundary is drawn.

These pages live in their own repository, separate from the code they describe,
so a change to the system and the change to the page explaining it are two
commits with no single diff that shows both: a discipline rather than something
the tooling enforces. Every page was written against the source at a named commit
and says which one, so a page that has gone stale can be told apart from one that
was never true.

## Start here

| page                                    | what it answers                                                                                                                            |
| --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| [FAQ](/faq)                             | The questions people actually arrive with: including custody, recovery and revocation. Start here if you are not sure which page you want. |
| [How it works](/platform)               | From a sentence to transactions on a chain: what happens in between, and what each part is trusted with.                                   |
| [Kernel](/kernel)                       | Whose account it is. The three keys, the smart account, and what each key cannot do.                                                       |
| [Adapters](/adapters)                   | The closed set of things the agent may do, and why it is closed.                                                                           |
| [The contracts](/protocol)              | The on-chain layer: what is deployed, what each contract decides, and why the addresses move.                                              |
| [Running it without you](/automation)   | Schedules, limit orders and chains: the three ways a plan starts when you are not there.                                                   |
| [Safe wallets](/safe)                   | Whether a Safe can drive an account directly, and the one thing it cannot do without a module.                                             |
| [Bounded execution](/routing)           | How a large order is sized, bounded and split, and why `costBps` is not what you pay.                                                      |
| [Slippage is not impact](/slippage)     | Two bounds in basis points that protect against opposite things, and what happens when you send both.                                      |
| [Does splitting cost less?](/splitting) | Breaking a large trade into slices: when it saves real money, and what the per-slice numbers hide.                                         |
| [the tool server](/tools)               | What the model is handed, and which of those tools spend money.                                                                            |
| [Skills](/skills)                       | What the model is told, how it retrieves it, and the rule that keeps it honest.                                                            |

The [FAQ](/faq) is the shortest way in: it answers in a paragraph and points at the
page holding the long version. Everything else is written to be read straight
through.

## The two sentences the rest of it hangs off

**The agent supplies parameters, never calldata.** The type the agent signs is a
closed struct of typed fields. There is no `To`, no `Data`, no route blob, so a
compromised planner or a prompt-injected model has no way to express "call this
address with this payload", because the type cannot represent it.

**The signer does not trust its caller.** Every intent is re-validated
independently at the signing service, even though the caller validated it first.
A caller that already validated loses nothing; a compromised one is stopped
there. Refusals are audited as carefully as approvals, because a refusal is
evidence.

Everything else here is one of those two sentences worked out in detail,
or a place where the built system does not yet reach them, which the pages say
explicitly rather than rounding up.

## How to read a page here

Claims are meant to be checkable. Where a page states something about the code
it names the file, and where it states something the code does **not** yet do it
says so in those words. Two failure modes this repository has paid for, and that
these pages try not to repeat:

* **A document that describes the design as though it were the build.** The
  [Kernel](/kernel) page keeps designed and built in separate columns for this reason.
* **A negative claim nobody re-checked.** "There is no adapter that waits for a
  price" was true, shipped, stayed on the page, and talked somebody out of the
  feature they were asking for. If you find one here, fix it in place; the git
  history behind every page is the record of what it used to say.


## Related topics

- [Does splitting cost less?](/splitting.md)
- [Bounded execution](/routing.md)
- [Safe wallets, and the one thing they cannot do](/safe.md)
- [FAQ](/faq.md)
- [How it works](/platform.md)