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

# Execution Model

> Your account, your bundler, your paymaster — gas in USDC and no relayer anywhere

## The rule

**1tx builds calls. Your wallet executes them.** We hold no keys, take no custody, sponsor no gas
and operate no relayer. Every call in every bundle targets a lending protocol, a DEX router or
Circle's `TokenMessengerV2` — never an address we control.

That is not a policy note; it shapes the API. Bundles are wallet-neutral by construction, and the
simulation that validates them deliberately assumes nothing about which wallet you use.

## Accounts

<CardGroup cols={2}>
  <Card title="Smart account (recommended)" icon="star">
    An ERC-4337 account on EntryPoint v0.7. The bundle lands as one atomic user operation, gas is
    paid in USDC, and the account never needs native tokens on any chain.
  </Card>

  <Card title="EOA (supported, weaker)" icon="wallet">
    Works for plain deposits and withdrawals if calls are sent in order, each receipt awaited. No
    atomicity, and gas must be paid in the chain's native token.
  </Card>
</CardGroup>

A smart account is what the bundles are designed for. Some things only work there:

* **Atomicity** — the property the simulation proves is a property of the batch, and only a batch
  sender gets it.
* **Loops** — a dozen interdependent calls whose intermediate states are never meant to be
  observable. Sending them one at a time is not a supported way to open a levered position.
* **Cross-chain redemption plus deposit in one operation** — receive the mint and put it to work
  in the same atomic step, so a failing deposit leaves the CCTP nonce unused.
* **Gas in USDC** — no native-token balance to maintain on four chains.

## Gas: paid in USDC, by you

An ERC-20 paymaster charges gas in USDC out of the account's own balance. Pimlico's singleton
paymaster and Circle Paymaster both work; the choice, the bundler and the account are yours.

Three things follow, and they matter when sizing a deposit:

<AccordionGroup>
  <Accordion title="Leave room for the paymaster's maximum charge">
    A paymaster reserves an upper bound on what it may take, not the eventual cost — gas limits plus
    an execution penalty and postOp gas, at `maxFeePerGas`, converted at its USDC exchange rate. A
    deposit sized to the account's entire USDC balance leaves nothing for that bound and the operation
    fails. Size deposits to *balance minus the maximum charge*, roughly a USDC per chain in practice,
    and keep that reserve rather than sweeping it.
  </Accordion>

  <Accordion title="Put the paymaster approval in the batch">
    The paymaster needs a USDC allowance. When you cannot confirm the existing allowance is enough,
    prepend the approve to the batch: a redundant approve costs a few thousand gas, a missing one
    reverts the whole operation *after* paying for it. An allowance you could not read counts as zero.
  </Accordion>

  <Accordion title="No USDC paymaster means no execution on that chain">
    A chain with no ERC-20 paymaster is still scorable — you can read its instruments and compare
    their yields — but it is not executable from an account with no native gas, and there is no
    relayer fallback. Treat paymaster coverage as part of whether a chain is reachable.
  </Accordion>
</AccordionGroup>

`gasUsed` in a bundle's `simulation` block is the cost of the protocol calls alone. Your wallet's
own overhead — validation, the paymaster's postOp — sits on top of it and only your bundler can
quote it.

## Cross-chain: CCTP V2, no relayer

```
source chain, one operation:
    [approve USDC → TokenMessengerV2] + depositForBurn(
        mintRecipient    = your account,
        destinationCaller = your account,
        maxFee, minFinalityThreshold = 1000 fast | 2000 standard)
        ▼  MessageSent identifies the burn
Circle Iris: poll by source transaction hash until the attestation is ready
        ▼  check it against the burn: amount, recipient, destination caller, fee
destination chain, one operation:
    receiveMessage(message, attestation)      ← mints USDC to your account
  + [approve paymaster] + deposit calls       ← sized to what was actually minted
```

**`destinationCaller` is your own account.** Only you can redeem the burn — nobody can front-run
it, and nobody, us included, can relay it on your behalf. That is why no relayer exists in this
design rather than being an omission.

Rules that follow:

* **Build the destination bundle only after the attestation is ready**, sized to the amount that
  survived Circle's fee. Never at proposal time.
* **Redeem and deposit in the same operation.** If the deposit reverts, the redemption reverts with
  it, the CCTP nonce stays unused, and the destination side can simply be rebuilt.
* **A source burn is observed, never resent.** A destination operation is reconciled before any
  retry. A burn that cannot be matched to its attestation is terminal and is never redeemed
  automatically.
* **Fast versus standard** is `minFinalityThreshold`: `1000` settles in seconds against Circle's
  allowance for a quoted fee, `2000` waits for hard finality. The bridge calldata endpoint quotes
  `maxFee` for the route you ask for.

## Supported chains

| Chain        | Chain ID | CCTP domain | Fast transfer |
| ------------ | -------- | ----------- | ------------- |
| Base         | 8453     | 6           | Yes           |
| Arbitrum One | 42161    | 3           | Yes           |
| Unichain     | 130      | 10          | Yes           |
| Monad        | 143      | 15          | No            |

## Next steps

<CardGroup cols={2}>
  <Card title="Calldata API" icon="code" href="/api-reference/endpoints/calldata">
    Instrument and bridge bundles
  </Card>

  <Card title="Atomic Bundles" icon="bolt" href="/concepts/atomic-bundles">
    What the batch guarantees
  </Card>

  <Card title="Integration Guides" icon="book" href="/integration/overview">
    Smart account, EOA or agent
  </Card>

  <Card title="Chains API" icon="link" href="/api-reference/endpoints/chains">
    Live chain and CCTP configuration
  </Card>
</CardGroup>