> 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/limitations.md). # Limitations Honest statements of what Sail does **not** protect against. None of these are bugs — they are deliberate boundaries of the trusted core. Understanding them is a prerequisite to using the protocol safely. ## 1. Permission correctness is the author's responsibility The kernel guarantees a permission cannot harm the kernel or other accounts, and that a *failing* permission denies. It does **not** guarantee a permission is *correct*. If a registered permission's `evaluate` returns `true` for a call that drains the account, the kernel will execute that call. Consequences: * **Register only audited or trusted permission contracts.** A permissive bug in a permission is a loss for the accounts that registered it. * **Upgradeable permissions are a trust escalation.** The kernel binds authorization to a permission *address*. If that address is an upgradeable proxy, changing its implementation requires **no new kernel signature** — so a registered upgradeable permission can later behave differently than when it was approved. Prefer non-upgradeable permissions. (Whitepaper §8.2.) * The seven shared templates are deployed against the current kernel (see [addresses](/protocol/reference/addresses.md)) and were included in the [Octane security review](/protocol/security/audits.md), but they remain **reference implementations** — treat them as starting points to read, verify, and test, not as audited drop-in production contracts. ## 2. Manager-attested NAV (the self-managed-SMA framing) `collectFees` takes a `currentNav` supplied by the **manager**; the kernel does not verify it. The kernel enforces only that the requested `grossFee` does not exceed the fee policy's computed maximum — but that maximum is itself a function of the manager-supplied NAV. A dishonest manager could inflate `currentNav` to unlock a larger fee ceiling. * `StandardFeePolicy` trusts the NAV by design. This is appropriate for a **self-managed SMA**, where the owner *is* (or fully trusts) the manager. * For a manager the owner does **not** fully trust, use a fee policy that validates NAV through an oracle inside `computeFee`, rather than the reference policy. * Denomination must be consistent: `grossFee`, `currentNav`, and the `feeAsset` must use the same units, or the fee ceiling is meaningless. ## 3. Off-chain venue components are out of the kernel's view A permission can only check what is visible on-chain at dispatch time. It cannot reason about off-chain components of a venue — sequencer behavior, off-chain order books, oracle update cadence beyond the freshness bound it checks, or MEV in the surrounding transaction. Oracle-gated templates check `updatedAt` freshness and (should) gate on L2 sequencer uptime, but the quality of those protections is only as good as the oracle and the bounds the permission author configures. ## Also worth knowing * **No layered "AND" composition in the kernel.** Selective authorization evaluates exactly one named permission per dispatch. Compound rules must be expressed inside a single permission (or a batch permission), not by requiring several permissions to jointly approve. * **Force-sent ETH is unrecoverable** in `MandateFactory` (no sweep function); an accepted residual since `receive()` already blocks normal deposits. * **Governance is trusted within its caps.** Governance cannot exceed the constitutional caps or move user funds, but it does control tunable parameters and the trusted allowlists, behind the 48-hour timelock. If you find something here that looks like more than a documented limitation, report it: ****. --- # 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/limitations.md?ask=&goal= ``` `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.