Skip to main content
Arc’s execution layer is built on 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 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.
ExtensionStatusFunction
Fee ManagerLiveStabilizes gas fees using USDC as the unit of account with EWMA smoothing.
CallFrom precompileLivePreserves msg.sender across delegated calls, powering the Memo and Multicall3From contracts.
ArcaneVMPlannedConfidential execution environment for Solidity contracts, composing synchronously with the public EVM.
Stablecoin ServicesPlannedPowers crosscurrency 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. For runtime parameters, see 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 (0x9702...) — Attaches memo metadata to contract calls and emits indexed Memo events.
  • Multicall3From (0xEb7c...) — Batches multiple calls like Multicall3, but each subcall retains the original msg.sender.
For contract addresses and integration details, see transaction extensions. For how this differs from standard Ethereum behavior, see EVM compatibility.

​
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.
PrecompileAddressFunction
Native Coin Authority0x1800..0000Mint, burn, and transfer operations for the native USDC balance.
Native Coin Control0x1800..0001Address blocklist for the native coin.
System Accounting0x1800..0002Gas fee ring buffer used by the Fee Manager.
Call From0x1800..0003Powers the Memo and Multicall3From contracts described above.
PQ Signature Verify0x1800..0004Post-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.

​
ArcaneVM

ArcaneVM is on the roadmap and not yet available on Arc.
ArcaneVM is a confidential execution environment for Solidity contracts that runs alongside Arc’s public EVM. Contracts deployed to ArcaneVM keep state and transaction data confidential while finalizing in the same block as public state, under default-deny contract isolation. See opt-in privacy for the planned design.

​
Stablecoin Services

Stablecoin Services are on the roadmap and not yet available on Arc.
Stablecoin Services will provide crosscurrency settlement, paymaster-sponsored transactions, and multi-stablecoin gas payments at the protocol level. See 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.
  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 ArcaneVM or Stablecoin Services functionality, 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.