Atomic Transaction Batching
How Surf moves capital safely in one step, without partial states or custody risk
One of the most important safety principles in Surf is that capital movements must be:
Deterministic Atomic Non-custodial Free of intermediate exposure
This is achieved through transaction batching and atomic execution.
The Problem With Multi-Step Execution
In many DeFi systems, rebalancing looks like this:
Withdraw from Protocol A
Hold funds in an intermediate wallet or contract
Swap or bridge
Deposit into Protocol B
During these steps:
Funds sit temporarily in transit
Partial execution can occur
A failed step can strand liquidity
MEV and slippage can be exploited
Custody risk briefly appears
This is how “safe strategies” become fragile in real market conditions.
Surf’s Approach: Batched Atomic Transactions
Surf never performs multi-step moves as separate actions.
Instead, all steps are bundled into a single atomic transaction:
Withdraw Swap Route Deposit Position update
All executed together or not at all.
There is no moment where funds are left idle. There is no intermediate custody. There is no partial state.
Either the full rebalance succeeds, or the system remains exactly as it was.
How Atomic Execution Works
Step 1. Execution Path Construction
Before any transaction is sent:
The agent constructs the full execution path
Every venue, route, and parameter is defined
Slippage limits and liquidity depth are checked
Gas and bridge costs are simulated
Worst-case unwind is evaluated
The entire sequence is prepared as one unit.
Step 2. Guardian Layer Validation
The full batch is validated against:
Protocol allowlists
Exposure and concentration limits
Liquidity exit depth
Slippage thresholds
Circuit breaker conditions
Vault permission boundaries
If any step violates a rule, the whole batch is rejected.
Step 3. Single Signature, Single Transaction
Once approved:
The full batch is signed via MPC
The signature is bound to the entire execution path
No individual step can be modified
No sub-transaction can be reordered
This produces one atomic on-chain transaction.
Step 4. All-or-Nothing Settlement
On-chain execution guarantees:
Either every step executes
Or nothing executes
There is no:
Partial withdrawal
Temporary custody
Unhedged exposure
Stranded liquidity
Broken position state
Why This Matters for Safety
Atomic execution ensures:
No bridge-in-transit risk
No swap-failed-but-withdrawn state
No operator holding phase
No time window for attacks
No execution drift between steps
It also ensures clean accounting:
Vault balances remain consistent
Strategy state remains coherent
Risk metrics remain accurate
Simulation assumptions remain valid
User-Level Guarantees
From the user’s perspective, this means:
Funds never leave the vault control boundary
Rebalancing never creates temporary custody
A failed optimisation attempt cannot harm the position
Capital is either fully upgraded or fully untouched
Withdrawals are never blocked by half-completed moves
The Design Principle
Transaction batching and atomic execution enforce a simple rule:
If an action cannot be completed safely in one deterministic step, it should not be executed at all.
This is how Surf maintains institutional-grade execution discipline while operating fully on-chain and fully non-custodial.
Last updated