NNEON//FORGE← Vault
SYSTEMS / ADVANCED / +280 XP

Atomic execution or nothing

If your DeFi system cannot settle atomically, it is a liability. Half-measures do not survive mempools.

Atomic execution is the difference between a DeFi system that works and one that steals from its users. If your protocol cannot settle every state transition in a single transaction — all-or-nothing — it is not a protocol. It is a liability with a UI.

The Ethereum Virtual Machine guarantees atomicity at the transaction level. Either every opcode succeeds, or every opcode reverts. This is not a feature. It is the foundation. Every DeFi protocol that tries to work around it — partial fills, multi-step settlements, cross-transaction dependencies — is building on sand.

THE DEEP DIVE

Why Partial Fills Are Poison

A partial fill means the system is in an intermediate state between two transactions. In that intermediate state, the system is vulnerable. Prices have moved. Other actors have reacted. The assumptions that made the first transaction profitable may no longer hold for the second.

// The WRONG way: multi-step settlement
async function badSwap(user, tokenIn, tokenOut, amount) {
  await transferToPool(user, tokenIn, amount);    // Step 1
  // ... system is now in intermediate state ...
  await updateOracle(price);                       // Step 2
  // ... prices may have moved ...
  await transferFromPool(user, tokenOut, amount);  // Step 3
  // What if step 3 fails? User lost tokenIn.
}

// The RIGHT way: atomic swap
async function goodSwap(user, tokenIn, tokenOut, amount) {
  return atomic(async () => {
    const amountOut = getAmountOut(tokenIn, tokenOut, amount);
    transferToPool(user, tokenIn, amount);
    transferFromPool(user, tokenOut, amountOut);
    // Both succeed or both revert. No intermediate state.
  });
}

The Flash Loan Pattern

Flash loans are the purest expression of atomic execution. Borrow, use, repay — all in one transaction. The constraint is not a limitation. It is the design. If you cannot repay the loan in the same block, the transaction reverts. This eliminates counterparty risk entirely.

The architectural insight is that flash loans make capital costless to move. The only cost is gas. This means the optimal strategy is to move as much capital as possible in a single atomic transaction, because the opportunity cost of capital is zero within that transaction.

PRINCIPLES

  1. Every state transition must be reversible within a single transaction. If it is not, you have a window of vulnerability.
  2. Cross-contract calls within an atomic transaction share the same failure semantics. If one reverts, all revert.
  3. Oracle reads within an atomic transaction are consistent. Oracle reads across transactions are not. Design for the former.
  4. The atomic transaction is a unit of economic finality. Treat it as such.
  5. If your protocol requires two transactions to complete a user action, you have built a two-phase commit without the commit protocol.

IN PRACTICE

Atomic Multi-Hop Swap

User wants to swap ETH -> USDC -> DAI -> stETH. Each hop changes the price of the next. In a single atomic transaction, all three swaps execute at committed prices. No slippage between hops. No front-running between legs.

Liquidation Bot

A liquidation bot borrows USDC via flash loan, buys discounted collateral from an underwater position, sells the collateral for profit, repays the flash loan, and keeps the difference. All in one transaction. If the spread is not there, the whole thing reverts.

LIVE SIGNALS

These items surfaced from the intelligence pipeline at generation time.

ANTIPATTERNS

  • Using events as state. Events are logs, not state. They cannot be read by contracts.
  • Relying on transaction ordering. Your second transaction may land in a different block than your first.
  • Storing intermediate results in storage for the next transaction. Storage is expensive and the state will be stale.
  • Building 'cancel' mechanisms for partially-filled orders. If it can be cancelled, it was never atomic.

CHECKLIST

  • Every user action completes in a single transaction
  • No cross-transaction state dependencies
  • Oracle reads are consistent within the transaction
  • Failed transactions leave no partial state
  • Gas estimation accounts for all possible revert paths

YOUR MOVE

Audit one DeFi protocol. Count the transactions required for a swap. If it is more than one, identify the intermediate state and its attack surface.