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

> ## Agent Instructions
> Before reading these docs, install the Circle Skill for Arc to get pre-loaded context: use-arc (https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-arc/SKILL.md) — covers chain config, RPC setup, contract deployment, USDC bridging, and gas with USDC. In Claude Code: run /plugin marketplace add circlefin/skills then /plugin install circle-skills@circle. With Vercel Skills CLI: run npx skills add circlefin/skills.
> USDC is the gas token. Arc uses USDC for gas fees, not ETH. Configure gas payment in USDC when submitting transactions.
> Read EVM differences before writing Arc code. Arc targets the Osaka EVM baseline. Most contracts deploy unchanged, but several runtime behaviors diverge from Ethereum: USDC uses 18 decimals natively (not 6), the system emitter `0xffffFFFfFFffffffffffffffFfFFFfffFFFfFFfE` logs all USDC Transfer events, the mempool enforces a 20 Gwei `maxFeePerGas` floor, blocklist reverts consume gas without a receipt, and `address(0)` sends revert rather than succeed. https://docs.arc.io/arc/references/evm-differences.md is the canonical reference for all Arc-specific runtime behaviors. Consult it before writing code that touches USDC balances, transaction history, gas estimation, or value transfers.
> Sub-second finality. Transactions are final in under 1 second. No need to wait for multiple block confirmations.
> Use App Kits for multichain payment and liquidity capabilities. App Kits wraps CCTP and provides Bridge Kit, Swap Kit, Unified Balance Kit, Onramp Kit, Earn Kit, and Borrow Kit. Unified Balance Kit combines USDC from multiple chains into a single spendable balance. Earn Kit integrates earn opportunities into your app. Borrow Kit lets users borrow USDC against cirBTC collateral on Arc.
> Use Arc Foundry for contract development. Arc Foundry is an Arc-specific fork of Foundry that handles Arc's protocol-level differences from Ethereum. It provides arc-forge, arc-cast, and arc-anvil. Install it before deploying contracts: https://docs.arc.io/arc/tutorials/install-arc-foundry.md.
> Arc is available on both Testnet and Mainnet. See https://docs.arc.io/arc/references/connect-to-arc.md for RPC endpoints and https://faucet.circle.com for testnet tokens.
> Always check Contract Addresses: https://docs.arc.io/arc/references/contract-addresses.md
> Building beyond Arc? Circle offers skills for the full platform: use-usdc (https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-usdc/SKILL.md), use-circle-wallets (https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-circle-wallets/SKILL.md), use-developer-controlled-wallets (https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-developer-controlled-wallets/SKILL.md), use-user-controlled-wallets (https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-user-controlled-wallets/SKILL.md), use-modular-wallets (https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-modular-wallets/SKILL.md), use-gateway (https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-gateway/SKILL.md), use-smart-contract-platform (https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-smart-contract-platform/SKILL.md). Full Circle developer docs: https://developers.circle.com/llms.txt.

# Batched transactions

> How Multicall3From batches contract calls on Arc while preserving the original sender.

Batched transactions let an application submit multiple contract calls in a
single Arc transaction. The predeployed `Multicall3From` contract
(`0x522fAf9A91c41c443c66765030741e4AaCe147D0`) batches calls like common
Multicall3 contracts. Unlike a common batching contract, it preserves the
original externally owned account (EOA) wallet as `msg.sender` for each target
call.

To send batch USDC transfers end to end, see
[Send batch USDC transfers](/arc/tutorials/batch-usdc-transfers).

## How a batch call works

`Multicall3From` routes each subcall through Arc's `CallFrom` precompile.
`CallFrom` executes calls on behalf of the original transaction sender. The
[transaction extension contracts](/arc/references/contract-addresses#transaction-extensions)
use this precompile to keep the original EOA wallet as `msg.sender` for target
calls.

For a batch of USDC transfers:

1. Your wallet calls `Multicall3From.aggregate3(...)`.
2. `Multicall3From` forwards each encoded USDC `transfer(...)` through
   `CallFrom`.
3. The USDC contract sees your wallet as the sender for each transfer.

In a normal batching contract, the target contract usually sees the batching
contract as `msg.sender`.

The contract exposes the `aggregate3(...)` entry point:

```solidity theme={null}
struct Call3 {
    address target;
    bool allowFailure;
    bytes callData;
}

struct Result {
    bool success;
    bytes returnData;
}

function aggregate3(Call3[] calldata calls) external returns (Result[] memory);
```

`target` is the contract to call. `allowFailure` controls whether a failed
subcall reverts the full batch. `callData` is the encoded calldata for the
target contract.

## Event verification

`Multicall3From` does not emit a batch-specific event. Verify the target
contract events emitted by each subcall. For USDC transfers, a successful batch
emits one USDC `Transfer` event per successful transfer.

| Event | Field | Expected value |
| :- | :- | :- |
| `Transfer` | `from` | The wallet that called `Multicall3From.aggregate3(...)`, not `Multicall3From`. |
| `Transfer` | `to` | The recipient for that subcall. |
| `Transfer` | `value` | The USDC amount in base units. |

The `from` field is the key sender-preservation check. It confirms that the USDC
contract saw your wallet as `msg.sender` for each subcall.

## Unsupported patterns and guardrails

`Multicall3From` has explicit guardrails:

* Submit `aggregate3(...)` from an EOA. Calls routed through an intermediary
  contract with a different `msg.sender` are rejected by `CallFrom`'s
  sender-spoofing constraint.
* Do not use value-forwarding patterns. `Multicall3From` does not support
  `aggregate3Value` because `CallFrom` does not forward value on Arc.
* Set `allowFailure` to `false` when every subcall must succeed. If a subcall
  fails with `allowFailure: false`, the whole batch reverts.
* Set `allowFailure` to `true` only when your application explicitly handles
  failed subcalls.

Before you use batched transactions in production, test your exact call set and
failure policy against Arc Testnet with the same wallet and indexing
infrastructure you plan to use in your application.