> For the complete documentation index, see [llms.txt](https://surf-2.gitbook.io/surfliquid-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://surf-2.gitbook.io/surfliquid-docs/infra-and-intelligence/execution-and-rebalancing-flow.md). # Execution and Rebalancing Flow #### Surf moves capital safely, deliberately and only when it is worth it.
Surf is not a system that constantly trades or churns funds. **It is designed to behave like a disciplined treasury operator**: * Patient * Risk-aware * Cost-sensitive * And fully controlled by deterministic rules The system is designed to answer one question repeatedly: **Is moving capital right now materially better than doing nothing, after risk, cost, and safety are considered?** Only if the answer is yes, execution is even allowed to begin. This page explains how capital actually moves inside Surf. *** ### High-Level Flow Every reallocation follows the same sequence: 1. Observe 2. Analyse 3. Simulate 4. Propose 5. Verify 6. Execute 7. Monitor No step is skipped. No action bypasses control. ***
#### Step 1: Continuous State Monitoring Surf continuously observes: * Lending and liquidity venues * Utilisation and borrow demand * Incentive emissions and decay curves * Liquidity depth and withdrawal capacity * Volatility and correlation shifts * Oracle deviations and price integrity * Gas, slippage, and execution cost * Cross-chain latency and bridge health The data is aggregated across all allowlisted chains and venues. This creates a real-time state model of the opportunity and risk landscape. *** ### 2. Risk-Adjusted Analysis Surf does not optimise for headline APY. It scores opportunities based on: * Net yield after gas, fees, and slippage * Liquidity available for exit * Protocol maturity and historical behaviour * Correlation with existing positions * Concentration impact * Cross-chain execution complexity **The result is a risk-adjusted return profile, not a raw rate comparison.** *** ### 3. Pre-Execution Simulation Before proposing any move, Surf simulates: * The full execution path * All intermediate states * Slippage impact * Liquidity drawdown * Post-move portfolio composition * Updated exposure and concentration metrics * Worst-case unwind scenarios If the simulation shows marginal improvement or elevated risk, the move is discarded. **Most potential actions never reach execution.** *** ### 4. Proposal Generation Only after passing the simulation does Surf generate a proposal: * Which assets to move * From which venues * To which venues * Through which routes * In what size * Under what timing assumptions At this stage, nothing has moved. This is only a structured plan. *** ### 5. Guardian Layer Verification The proposal is then evaluated by the Guardian Layer. It enforces: * Protocol allowlists * Exposure caps per asset and venue * Concentration limits * Slippage bounds * Liquidity exit thresholds * Cross-chain routing constraints * Portfolio health invariants * Stress and anomaly checks If any rule is violated: * The action is rejected * No funds move * A rejection reason is logged **This is what turns Surf from an optimiser into a constrained execution system.** *** ### 6. Deterministic Execution If and only if all rules pass: * Transactions are constructed * Signed via MPC (Multi-Party Computation) * Batched where possible * Executed atomically when supported Execution paths are predefined and auditable. There is no discretionary runtime behaviour. **Funds never leave user custody. Surf only operates within pre-approved execution bounds.** *** ### 7. Post-Execution Monitoring After execution: * Portfolio health is re-evaluated * Risk metrics are recalculated * Drift from targets is measured * Performance is recorded * New baselines are established The system returns to observation mode. *** #### When Rebalancing Does Not Happen Most of the time, the best action is no action. Surf explicitly avoids: * Chasing small yield deltas * Over-optimising for short-term incentives * Moving capital when costs exceed benefits * Increasing risk to marginally improve APY Rebalancing only occurs when: * The expected improvement is meaningful * Safety margins remain intact * Exit liquidity is preserved * Guardian constraints are fully satisfied *** ### Why This Matters Traditional yield optimisers focus on rate chasing. **Surf focuses on controlled state transitions.** This is the difference between: * “Where is the highest APY right now?” and * “Is it safe and worth changing the entire system state to get it?” Execution is not about being fast. It is about being correct, verifiable, and reversible. **This flow is intentionally conservative.** Surf optimises for: * Capital preservation first * Predictable behaviour * Long-term compounding * And user trust Not for: * Maximum short-term yield * High turnover * Or speculative positioning *** ### Key Properties * Surf never touches funds directly * All moves are simulated before being proposed * All proposals are rule-checked before execution * All executions are deterministic and auditable * All outcomes are continuously monitored *** ### In Simple Terms Surf behaves like this: > “Only move money when the benefit is clear, the risk is bounded, and the rules allow it.” **That is how automation becomes safe for on-chain savings. That is the execution standard Surf is built on.**