Risk Assumptions
Surf is designed as an execution and risk-managed automation layer, not as a promise of risk-free returns.
All optimisation and protection mechanisms operate within a clearly defined set of assumptions about the environment in which the system runs.
These assumptions define the boundary conditions for the Guardian Layer, strategy logic, and emergency controls.
1. Blockchain and Infrastructure Assumptions
Surf assumes:
The underlying blockchain maintains liveness and finality within expected bounds.
Transaction ordering may be adversarial, but atomic execution and slippage bounds protect against harmful reordering.
Network congestion and gas spikes can occur and are treated as execution-risk inputs, not failure states.
Smart contract execution is deterministic and verifiable.
If a chain halts, reorgs beyond safe depth, or experiences systemic failure, Guardian circuit breakers suspend execution.
2. Oracle and Data Assumptions
Surf assumes:
Price oracles may lag, spike, or temporarily diverge.
No single oracle source is trusted blindly.
Statistical sanity checks, deviation bounds, and cross-source validation are required before any capital-moving action.
Oracle failure is treated as a first-class risk vector. Execution is blocked when price integrity falls outside allowed confidence thresholds.
Surf assumes:
Liquidity is dynamic and can vanish during stress.
Slippage is nonlinear in volatile regimes.
Utilisation, funding rates, and pool depth can change faster than human reaction time.
Therefore:
All strategies operate under strict liquidity, impact, and unwind-time constraints.
The system assumes that exit must always be possible within bounded loss, not just entry.
4. Protocol and Counterparty Assumptions
Surf assumes:
DeFi protocols can fail due to bugs, governance capture, oracle issues, or economic attacks.
No venue is permanently safe.
Risk is reduced through diversification, allowlists, exposure caps, and continuous health monitoring.
Protocols are treated as probabilistic risk surfaces, not as trusted black boxes.
5. Agent and Model Assumptions
Surf assumes:
AI models can be wrong.
Simulations are approximations, not guarantees.
Regime shifts can invalidate historical patterns.
For this reason:
AI is never allowed to directly execute capital.
All actions must pass deterministic rule validation.
“Propose only, never decide” is a core architectural invariant.
6. User Behaviour Assumptions
Surf assumes:
Users may withdraw suddenly.
Users may concentrate capital.
Users may act irrationally under volatility.
Vault isolation, liquidity buffers, and permissioned execution ensure one user’s behaviour cannot compromise others.
7. Adversarial Environment Assumptions
Surf assumes:
MEV searchers, arbitrageurs, and sandwich attackers are always present.
Economic attacks will target execution paths, not just contracts.
Social attacks (phishing, UI spoofing, key compromise) are ongoing threats.
Hence:
Atomic transaction batching, slippage ceilings, MPC signing, and execution path validation are mandatory.
Design Principle
Surf does not assume “normal conditions”. It assumes stress, manipulation, latency, and failure are the default state of open financial systems.
All strategies, vaults, and automation are built on the premise that:
Optimisation only happens after survival is guaranteed.
Last updated