Skip to main content

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.

Arc is an EVM-compatible Layer-1 blockchain targeting the Prague hard fork. Solidity, Hardhat, Foundry, Viem, and standard Ethereum wallets work without modification. You can deploy existing smart contracts, connect familiar development tools, and interact with Arc the same way you would with Ethereum. While the execution environment mirrors Ethereum’s, Arc’s stablecoin-native design, deterministic finality, and stable fee model (see also the gas and fees reference) introduce differences that are important to understand before you start building.

​
Key differences from Ethereum

The table below summarizes the areas where Arc’s behavior diverges from Ethereum mainnet.
AreaEthereumArc
Native tokenETH, volatile pricingUSDC, stable pricing with 18 decimals for gas
Fee marketEIP-1559 base fee per blockEWMA smoothing with bounded base fee
FinalityProbabilistic (12-15 min)Deterministic, <1 s
ConsensusProof-of-Stake (slot/epoch model)Malachite BFT, permissioned validators
Block timestampsDerived from slots and epochsWall-clock time; sub-second blocks may share timestamps
SELFDESTRUCTAllowed with value transfers to selfNot allowed during deployment
PARENT_BEACON_BLOCK_ROOTSSZ root of parent beacon blockkeccak256(RLP(header)); no beacon chain
PREV_RANDAORandomness mix of proposer revealsAlways 0; not usable for randomness
USDC blocklist handlingRuntime revert on transferPre-mempool rejection and runtime checks
EIP-4844 blobsSupported post-DencunDisabled
Most of these differences are transparent to application code. The areas most likely to affect your contracts are:
  • Gas denomination: Gas is priced in USDC (18 decimals), not ETH. Hardcoded gas-price assumptions based on ETH economics do not apply.
  • Timestamp behavior: Sub-second blocks may share the same block.timestamp. Contracts that rely on strictly increasing timestamps between blocks need adjustment.
  • No usable randomness: PREV_RANDAO always returns 0. Use an offchain oracle or verifiable random function (VRF) instead.

​
USDC dual-interface model

Arc uses USDC as its native gas token. Because USDC also needs to function as a standard ERC-20 token (the Ethereum token standard for fungible assets like stablecoins) for application-level transfers, Arc exposes two interfaces for the same underlying asset:
InterfaceDecimalsPurpose
Native18Gas accounting, native sends, and msg.value
ERC-206Application-level transfers, approvals, and allowances
These are not two separate tokens. A native send and an ERC-20 transfer both move the same balance. This dual-interface design means you can interact with USDC through whichever interface fits your use case while the protocol maintains a single, consistent balance underneath. For a full explanation of the stablecoin-native architecture, including EURC (Euro-backed stablecoin by Circle) and USYC (yield-bearing stablecoin) support, see Stablecoin native model.
For detailed integration guidance, common pitfalls, and per-use-case recommendations for working with Arc’s EVM differences, see the full EVM compatibility reference.