> ## Documentation Index
> Fetch the complete documentation index at: https://docs.1tx.fi/llms.txt
> Use this file to discover all available pages before exploring further.

# Atomic Bundles

> Multi-step DeFi as one batch your account signs — and what atomicity does not cover

## The problem

Entering a yield position by hand is a sequence, and every step is a place to get stuck:

1. Approve USDC to a DEX
2. Swap USDC → EURC
3. Wait for confirmation
4. Approve EURC to the protocol
5. Deposit

Between steps the price moves, a leg fails and leaves the account holding the wrong token, and the
user is asked to sign four more times. Each protocol needs its own version of this sequence.

## The bundle

1tx returns the same work as **one ordered batch** of `{to, value, data}` calls, built for one
chain and one account:

```json theme={null}
"calls": [
  { "to": "0x8335…2913", "data": "0x095ea7b3…", "value": "0", "type": "approve" },
  { "to": "0x2626…4aD4", "data": "0x24856bc3…", "value": "0", "type": "swap" },
  { "to": "0x4e65…c0AB", "data": "0x6e553f65…", "value": "0", "type": "deposit" }
]
```

Sent through a smart account as a single user operation, the batch lands or reverts as a whole.
The swap and the deposit share one block and one price; there is no window between them, and no
state where the account holds an intermediate token it never asked for.

Every call targets the protocol directly. There is no intermediary contract to trust, so there is
also nothing to audit between you and Aave — the atomicity comes from your account's batching, not
from a router of ours holding your funds for the length of a transaction.

## Simulated before it is returned

A bundle is not a suggestion. Before you see it, all of its calls are executed against live state
at a pinned block, in order, as your account:

<CardGroup cols={2}>
  <Card title="Reverts never reach you" icon="shield-check">
    A bundle whose simulation fails — insufficient liquidity, a protocol cap, a paused market — is
    refused with a `400` rather than handed over to sign.
  </Card>

  <Card title="The output is measured" icon="ruler">
    `expectedOut` is the account's balance delta in the simulation, not a projection from a
    formula.
  </Card>

  <Card title="Slippage is written in" icon="lock">
    Where a swap is involved, `minOut` is compiled into the calldata. A price that moves too far
    before the batch lands makes it revert rather than fill badly.
  </Card>

  <Card title="Dust is bounded" icon="broom">
    `leftovers` states the most an exact-output leg can leave behind, so nothing is silently lost.
  </Card>
</CardGroup>

## Where atomicity stops

<AccordionGroup>
  <Accordion title="An EOA gives it up">
    An EOA sends calls one at a time. Each is atomic by itself; the sequence is not. Stop after the
    approve and you have an allowance; stop after the swap and you are holding EURC. The simulation
    modelled the batch, so only a batched sender gets what it proved. This is the main reason the
    execution model is built around smart accounts.
  </Accordion>

  <Accordion title="Simulation is not a guarantee of landing">
    The bundle is proven at `quoteBlock`. Between that block and inclusion, rates move, vaults fill and
    caps bind. That is a reverted transaction, not a lost one — but it is a reverted transaction you
    paid gas for. Rebuild a bundle that has been sitting around, and never replay one past `expiresAt`.
  </Accordion>

  <Accordion title="Atomic does not mean instant, across chains">
    A cross-chain deposit is two batches with Circle's attestation between them. Each is atomic on its
    own chain; the pair is not. What protects the middle is that the burn names your own account as
    the only party who can redeem it — not a guarantee that both halves run in one moment.
  </Accordion>

  <Accordion title="One bundle, one chain">
    Every call in a bundle is on the same chain, and a bundle is capped at 32 calls and 128 KiB of
    calldata. A plan that spans chains is a sequence of bundles, and your agent or app sequences them.
  </Accordion>
</AccordionGroup>

## Loops: the same idea, further

A levered loop is the extreme case of the pattern: borrow, swap, re-supply, repeated until the
requested leverage is reached — a dozen or more calls that are only safe together. Every amount is
computed at the quote block and hard-coded, every swap is exact-output, and the resulting health
factor is read back from the simulated block rather than modelled.

<Card title="Loops API" icon="layer-group" href="/api-reference/endpoints/loops">
  Leverage, e-mode, turns and the measured position
</Card>

## Next steps

<CardGroup cols={2}>
  <Card title="Execution Model" icon="wallet" href="/concepts/execution-model">
    Smart accounts, gas in USDC, cross-chain
  </Card>

  <Card title="Calldata API" icon="code" href="/api-reference/endpoints/calldata">
    The endpoint that returns the bundle
  </Card>

  <Card title="Instruments" icon="fingerprint" href="/concepts/instruments">
    What the id encodes
  </Card>

  <Card title="Integration Guides" icon="book" href="/integration/overview">
    Wiring it into your app or agent
  </Card>
</CardGroup>