> 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/security/guarantees.md).

# Guarantees

The protocol provides six guarantees as properties of the **deployed bytecode** — they hold regardless of what any permission or fee policy does.

### 1. Custody isolation

The kernel cannot transfer Safe assets except through a manager dispatch that satisfies the named permission's evaluation. The kernel has no direct write access to the Safe outside the module dispatch path, and a dispatch whose `target` is the Safe itself is rejected (`AccountSelfTarget`) — blocking module-triggered self-reconfiguration.

### 2. Selective authorization

A dispatch succeeds only if the permission named in the manager's signature is registered for the account **and** returns true on evaluation. An unregistered permission reverts before evaluation (`PermissionNotRegistered`); there is no implicit allow-all state (deny-by-default).

### 3. Reentrancy safety

Permission evaluation occurs via `staticcall`, which prohibits state mutation — no re-entry path exists through the permission surface. The kernel's state-changing entry points are additionally `nonReentrant`.

### 4. Gas isolation

Each permission is called under a fixed gas cap (`PERMISSION_GAS_CAP = 150_000`; `BATCH_EVAL_GAS_CAP = 1_000_000` for batches). Exceeding it is treated as returning false. A malicious permission cannot deny service to the kernel or drain the manager's gas budget beyond the cap.

### 5. Constitutional fee caps

The protocol cut (`MAX_PROTOCOL_CUT_BPS = 2500`) and registration fee (`MAX_PERMISSION_FEE_WEI ≤ 0.01` native) cannot be exceeded under any governance procedure — they are immutable. The protocol cut is zero at launch; the registration fee is live at a small non-zero rate (see [Fees](/protocol/fees-and-governance/fees.md)).

### 6. Signer separation

The Permission Signer cannot move Safe assets (it never signs a dispatch). The Manager cannot register or revoke permissions (it never signs a registry op). The Safe owner can always revoke the manager (`setManager`) and can remove the kernel module entirely.

## Supporting mechanisms

These reinforce the six guarantees:

* **Fail-closed evaluation** — any false/revert/OOG/malformed return reverts the whole dispatch.
* **Nonce-epoch invalidation** — any restrictive signer op or manager rotation bumps the manager/batch nonce epoch (`1 << 128`), invalidating all of the manager's outstanding pre-signed dispatches.
* **Front-run-resistant account creation** — the CREATE2 salt binds the principals, so a counterfactual SMA address cannot be claimed with different principals.
* **Trusted-component allowlists** — only allowlisted Safe factories, singletons, module-setup helpers, proxy codehashes, and fee policies can be used, blocking attacker-supplied setup delegatecalls (Octane #1) and metamorphic fee policies.
* **Three nonce namespaces** — dispatch, batch, and signer operations cannot replay across each other.
* **Emergency pause** that still permits de-risking operations (revoke, rotate) while blocking value movement.

Several of these correspond to findings raised in the Octane security analyses (e.g. Octane #1, #4/#4a/#4b, #7, #16) and are addressed in the deployed bytecode. See [Octane security review](/protocol/security/audits.md).


---

# 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/security/guarantees.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.