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

# Execution layer

> Arc's execution layer runs Reth, a Rust Ethereum client that maintains blockchain state, executes EVM transactions, and extends the pipeline with stablecoin-native modules including a USDC-denominated Fee Manager and the CallFrom precompile.

Arc's execution layer is built on [Reth](https://github.com/paradigmxyz/reth), a
Rust implementation of the Ethereum execution client. Reth maintains the full
blockchain state, executes every transaction through the Ethereum Virtual
Machine (EVM), and produces the state root -- a cryptographic hash that
summarizes the entire ledger state -- that the
[consensus layer](/arc/concepts/consensus-layer) finalizes. Arc extends this
foundation with modules purpose-built for stablecoin-native finance.

## What Reth does

Reth handles three jobs on every block:

1. **Maintains the ledger.** Tracks accounts, balances, smart contracts, and
   transaction history. Every state change is recorded and addressable.
2. **Executes transactions.** Applies EVM logic for smart contract calls and
   transfers, deducts gas fees through the Fee Manager, and routes through
   Arc-specific modules where applicable.
3. **Produces the state root.** Computes a Merkle root -- a single hash derived
   from a tree of all state data -- of the updated state after all transactions
   in a block have been applied. The consensus layer finalizes this root, making
   the block irreversible.

Reth is written in Rust for performance, memory safety, and modular
extensibility. Arc leverages this architecture to plug in stablecoin-native
modules without modifying core EVM execution.

## Arc-specific extensions

Arc extends the standard Ethereum execution pipeline with modules that run
alongside core EVM logic at the protocol level -- meaning they are built into
the blockchain itself, not deployed as user-space smart contracts. You benefit
from these capabilities without deploying custom contracts or external services.

| Extension                                                                            | Status  | Function                                                                                                |
| :----------------------------------------------------------------------------------- | :------ | :------------------------------------------------------------------------------------------------------ |
| **[Fee Manager](/arc/concepts/stable-fee-design)**                                   | Live    | Stabilizes gas fees using USDC as the unit of account with EWMA smoothing.                              |
| **[CallFrom precompile](/arc/references/contract-addresses#transaction-extensions)** | Live    | Preserves `msg.sender` across delegated calls, powering the Memo and Multicall3From contracts.          |
| **[Arc Privacy Sector (APS)](/arc/concepts/opt-in-privacy)**                         | Planned | Confidential execution environment for Solidity contracts, composing synchronously with the public EVM. |
| **Stablecoin Services**                                                              | Planned | Powers cross-currency settlement, paymaster-sponsored transactions, and multi-stablecoin gas payments.  |

### Fee Manager

The Fee Manager replaces Ethereum's per-block EIP-1559 base fee recalculation
with an EWMA-smoothed fee curve denominated in USDC. Short demand spikes are
absorbed by the smoothing window rather than propagated into sudden fee jumps.
The base fee targets approximately \$0.01 per transaction under normal
conditions.

For the full fee model, see
[stable fee design](/arc/concepts/stable-fee-design). For runtime parameters,
see [gas and fees](/arc/references/gas-and-fees).

### CallFrom precompile

Standard Ethereum opcodes `CALL` and `DELEGATECALL` -- used when one contract
invokes another -- change `msg.sender` (the address of the immediate caller) at
each hop in the call chain. The CallFrom precompile preserves the original
caller's address through the call chain. Two predeployed contracts use this
precompile:

* **Memo** (`0x5294...`) -- Attaches memo metadata to contract calls and emits
  indexed `Memo` events.
* **Multicall3From** (`0x522f...`) -- Batches multiple calls like Multicall3,
  but each subcall retains the original `msg.sender`.

For contract addresses and integration details, see
[transaction extensions](/arc/references/contract-addresses#transaction-extensions).
For how this differs from standard Ethereum behavior, see
[EVM compatibility](/arc/references/evm-differences).

## Protocol precompiles

Arc exposes five custom precompiles in the `0x1800..` address range -- shorthand
for the addresses `0x1800000000000000000000000000000000000000` through
`0x1800000000000000000000000000000000000004`. These are built into the execution
layer at the protocol level rather than deployed as user-space contracts, and
they back the protocol-level features listed above.

| Precompile                | Address        | Function                                                         |
| :------------------------ | :------------- | :--------------------------------------------------------------- |
| **Native Coin Authority** | `0x1800..0000` | Mint, burn, and transfer operations for the native USDC balance. |
| **Native Coin Control**   | `0x1800..0001` | Address blocklist for the native coin.                           |
| **System Accounting**     | `0x1800..0002` | Gas fee ring buffer used by the Fee Manager.                     |
| **Call From**             | `0x1800..0003` | Powers the Memo and Multicall3From contracts described earlier.  |
| **PQ Signature Verify**   | `0x1800..0004` | Post-quantum `SLH-DSA-SHA2-128s` signature verification.         |

You typically interact with these precompiles indirectly through the predeployed
contracts and protocol features they support, rather than calling them directly.

### Arc Privacy Sector (APS)

<Info>
  Arc Privacy Sector (APS) is on the roadmap and not yet available on Arc.
</Info>

Arc Privacy Sector (APS) is a confidential execution environment for Solidity
contracts that runs alongside Arc's public EVM. Contracts deployed to APS keep
state and transaction data confidential while finalizing in the same block as
public state, under default-deny contract isolation. See
[opt-in privacy](/arc/concepts/opt-in-privacy) for the planned design.

### Stablecoin Services

<Info>
  Stablecoin Services are on the roadmap and not yet available on Arc.
</Info>

Stablecoin Services will provide cross-currency settlement, paymaster-sponsored
transactions, and multi-stablecoin gas payments at the protocol level. See
[stablecoin native model](/arc/concepts/stablecoin-native-model) for the design
rationale.

## Execution pipeline

A transaction moves through the execution layer in a linear pipeline. Reth
applies each transaction to the current state and produces a new state root,
which the consensus layer then finalizes into an irreversible block.

```mermaid theme={null}
flowchart LR
  TP["Mempool\n(unconfirmed txns)"] --> EVM["EVM execution\n(contracts & transfers)"]
  EVM --> FM["Fee Manager\n(USDC gas accounting)"]
  FM --> MC["Module calls\n(Privacy, Stablecoin Services)"]
  MC --> SU["State update\n(accounts, storage, logs)"]
  SU --> SR["State root\n(Merkle hash)"]

  style FM fill:#e8f5e9,stroke:#2e7d32
  style MC fill:#f5f5f5,stroke:#999,stroke-dasharray: 5 5
```

1. **Mempool.** Pending transactions wait in the mempool (a holding area for
   unconfirmed transactions) after passing initial validation (valid signature,
   sufficient balance, proper nonce).
2. **EVM execution.** Reth applies each transaction sequentially, running smart
   contract bytecode and processing native transfers.
3. **Fee Manager.** Gas fees are deducted in USDC using the EWMA-smoothed base
   fee. This step runs on every transaction.
4. **Module calls.** If the transaction invokes Arc Privacy Sector (APS) or
   Stablecoin Services, the relevant module processes the call. Standard
   transactions skip this step.
5. **State update.** Reth writes the resulting changes (account balances,
   contract storage, event logs) to the state database.
6. **State root.** Reth computes a Merkle root over the full updated state. This
   root serves as a cryptographic commitment -- a tamper-evident fingerprint of
   the entire ledger -- that the consensus layer finalizes.