> 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/execution-security/atomic-transaction-batching.md).

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

1. Withdraw from Protocol A
2. Hold funds in an intermediate wallet or contract
3. Swap or bridge
4. 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 seemingly safe automation becomes 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 vault remains exactly as it was.

***

#### How Atomic Execution Works

**Step 1. Execution Path Construction**

Before any transaction is sent:

* Surf 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
* Vault 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.