> For the complete documentation index, see [llms.txt](https://docs.sail.money/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sail.money/protocol/protocol.md).

# Overview

Sail Protocol is a minimal account-abstraction primitive for **onchain separately managed accounts (SMAs)**, implemented for the EVM. It wraps a [Safe](https://safe.global) smart account with a permission-gating layer so that a designated **manager** — typically an autonomous agent — can execute transactions on the account's behalf, but only within bounds the account owner has authorized on-chain.

## The problem

A separately managed account is the structure professional asset management is built on: capital is titled to the owner, a manager executes within a mandate, and the mandate can be narrowed or revoked at any time. DeFi never reproduced it. Three gaps:

* **Pooled vaults give up custody and attribution.** Depositors mint shares of a single strategy, surrender account-level custody, and inherit the strategy's full risk profile shared across every other depositor.
* **Smart wallets have no mandate.** Self-custodial wallets preserve custody but have no native concept of a manager bounded by enforceable rules.
* **Agents need signing authority *****and***** enforceable bounds.** An autonomous agent managing capital must be able to transact continuously, yet must be constrained by something stronger than a prompt.

Sail fills the gap between them: a self-custodial account whose manager has bounded, code-enforced, revocable authority.

## How it works

<figure><img src="/files/pSqE3rQbAgd6yqQIYAfq" alt=""><figcaption></figcaption></figure>

* Capital is held in the owner's **Safe**. The kernel never holds assets.
* The **mandate** is not a document — it is the set of permission contracts registered for the account.
* On each dispatch the manager's signature **names one** registered permission. The kernel evaluates only that permission, via `staticcall` under a fixed gas cap, and forwards the call to the Safe only if it returns `true`.
* Because permissions are arbitrary Solidity, **any DeFi primitive can be expressed as a permission**. Adding a new venue is a contract deployment, not a protocol upgrade.

## What's in the trusted core

| Component            | Role                                                                                                                                                                                  |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `SailKernel`         | Account registration, permission registry, EIP-712 signature verification, manager dispatch (single & batch), fee accounting, principal tracking. The only trusted execution surface. |
| `SailGovernance`     | Parameter store behind a 48-hour timelock: constitutional caps, the protocol cut, the registration fee, and the trusted Safe/fee-policy allowlists. Emergency pause with auto-expiry. |
| `TimelockController` | Standalone OpenZeppelin timelock (48h), deployed separately and injected into `SailGovernance`, which validates it at construction.                                                   |
| `MandateFactory`     | UX orchestrator bundling configure → register into one transaction. Holds no privilege; every inner call is independently signature-authenticated.                                    |
| `SafeModuleEnabler`  | Stateless one-shot helper that enables the kernel as a Safe module during account creation.                                                                                           |
| `StandardFeePolicy`  | Reference fee policy: management fee on AUM plus a performance fee above a per-account high-water mark.                                                                               |

Permission templates and fee policies live **outside** the trusted core. A bug in a template affects only the accounts that registered it.

## Where to go next

* New to the model? Start with [Concepts](/protocol/concepts.md).
* Want the component-level picture? See [Architecture](/protocol/architecture.md).
* Building a permission? Jump to the [Permission system](/protocol/permissions.md) and [Guides](/protocol/guides.md).
* Need addresses or signatures? See [Reference](/protocol/reference.md).

{% hint style="warning" %}
The trusted core and shared templates are deployed on 12 chains (10 mainnets + 2 testnets) and were reviewed by [Octane](https://www.octane.security), an AI source-code security scanner, across three analyses. A security review is not a proof of correctness — do not use with funds you are not prepared to lose.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.sail.money/protocol/protocol.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.