Protocol Allowlist Criteria
Surf does not route capital to “anywhere that pays”.
Every protocol, pool, and venue must pass a strict allowlist process before the AI is even permitted to consider it.
This is a foundational safety principle.
If a venue is not allowlisted, it does not exist to the system.
Why Allowlisting Exists
Most yield systems optimise first and ask questions later. Surf does the opposite.
We define where capital is allowed to go first. Only then do we allow optimisation to happen inside that universe.
This ensures that:
AI never explores unsafe venues
Risk is bounded by design
New integrations are deliberate, not opportunistic
Execution quality is predictable and auditable
Core Allowlist Dimensions
Every protocol must satisfy criteria across six layers.
1. Contract Security
Independent audits from reputable firms
No unresolved critical or high-severity findings
Formal verification where applicable
Upgradeability and admin key risk are clearly defined
Battle-tested code paths with real TVL and time in production
2. Economic Safety
Sustainable yield sources, not reflexive emissions
No dependency on circular leverage or fragile incentive loops
Clear liquidation mechanics and solvency guarantees
Stress-tested under drawdowns and liquidity crunches
3. Liquidity Depth
Sufficient on-chain liquidity for entry and exit
Proven ability to unwind positions under stress
No reliance on single LPs or thin books
Slippage behaviour measured across volatility regimes
4. Oracle and Pricing Integrity
Decentralised, manipulation-resistant price feeds
Redundant oracle sources where possible
Bounded deviation and update latency
No single-point oracle failure risk
5. Operational Maturity
Active development and incident response history
Transparent upgrade and governance processes
Clear emergency procedures and timelock controls
Public communication and post-mortem culture
6. Integration Compatibility
Clean adapter interface for Surf execution layer
Support for atomic entry and exit
Deterministic state transitions
No hidden side effects or asynchronous settlement risks
Continuous Re-evaluation
Allowlisting is not permanent.
Protocols are continuously monitored for:
TVL changes and liquidity decay
Exploit disclosures and new vulnerabilities
Governance changes
Oracle degradation
Correlation risk across the wider ecosystem
If a protocol degrades, it can be:
Soft-paused for new allocations
Gradually unwound
Immediately frozen via Guardian Layer
Fully removed from the execution universe
Guardian Layer Enforcement
Allowlists are enforced at execution, not UI level.
Even if:
The AI proposes a route
A strategy wants to rebalance
A simulation looks profitable
If the destination is not allowlisted, execution is impossible.
The transaction will fail before any capital moves.
Why This Matters
This is how Surf avoids:
Yield chasing into unsafe protocols
Narrative-driven integrations
Unvetted experimental risk
Black-box dependency chains
Allowlisting makes Surf:
Predictable
Institution-compatible
Auditable
Scalable without safety erosion
Optimisation happens inside a curated, risk-qualified universe.
That is how autonomous finance becomes safe enough for real capital.
Last updated