# Guardian Layer Overview

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

The Guardian Layer is the core safety and control system that sits between Surf and your funds.

It defines, in code, what is allowed and what is never allowed to happen on-chain.\
Surf can analyse, plan, and propose actions.\
The Guardian Layer decides whether those actions are permitted to execute.

**This separation is intentional.**

In most “AI DeFi” systems, intelligence and execution are fused. If the model is wrong, the transaction still goes through. That is how automation turns into accelerated loss.

Surf is built differently.

Here, automation operates inside hard boundaries that cannot be bypassed.

***

#### What the Guardian Layer Does

The Guardian Layer enforces deterministic rules before any capital movement:

**1. Protocol Allowlists**\
Funds can only be deployed to pre-approved, audited venues. No new protocol can be touched unless it is explicitly allowlisted.

**2. Exposure and Concentration Limits**\
Maximum allocation per protocol, per asset, and per vault. No single venue or position can grow beyond defined risk caps.

**3. Slippage and Liquidity Bounds**\
Every move must satisfy:

* Minimum liquidity depth
* Maximum acceptable price impact
* Safe exit assumptions under stress

**4. Risk and Health Thresholds**\
Utilisation spikes, oracle deviations, abnormal rate moves, or contract anomalies trigger automatic rejection or de-risking.

**5. Simulation Before Execution**\
Before any rebalance:

* Entry and exit prices are simulated
* Gas and routing costs are included
* Worst-case unwind is evaluated

  If the improvement is not real after costs and risk, the transaction is blocked.

**6. Circuit Breakers and Emergency Controls**\
If abnormal behaviour is detected:

* Execution can be frozen
* Positions can be isolated
* Capital can be unwound to safe assets

  All without giving discretionary custody to Surf.

***

#### Surf proposes. Rules decide.

The Guardian Layer makes a strict architectural statement:

**Surf is an optimisation system, not a custodian.**

It can:

* Scan markets
* Score risk-adjusted yield
* Simulate vault actions

It cannot:

* Bypass allowlists
* Exceed exposure caps
* Ignore slippage limits
* Break withdrawal guarantees
* Move funds outside vault scope

**If any rule is violated, the action is rejected. Nothing moves. A reason is logged.**

**When Surf is wrong, the outcome is not a loss. It is a blocked transaction and a recorded signal.**

***

#### Non-Custodial by Construction

**All execution happens inside user-owned vaults**

The Guardian Layer enforces:

* Vault-scoped execution only
* No external redirection of funds
* No operator withdrawal rights
* Atomic transactions for rebalance and exit
* Full user withdrawal control at all times

Surf never takes discretionary custody. The rules, not a team or a multisig, are the ultimate authority.

***

#### Why This Matters

As automation becomes more capable, the real risk is not intelligence. It is an uncontrolled execution.

The Guardian Layer is the missing control plane for autonomous finance:

* Deterministic instead of discretionary
* Enforced in smart contracts, not policy
* Auditable, verifiable, and non-bypassable
* Designed for real capital at scale, not experimental automation

This is the standard Surf introduces to the market: **automation that can optimise, but only inside provable, on-chain safety boundaries.**


---

# Agent Instructions: 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:

```
GET https://surf-2.gitbook.io/surfliquid-docs/security-control-layer/guardian-layer-overview.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.