Circle Arc Mainnet: Architecture of a Stablecoin-Native Layer 1

Most blockchains ask a payments team to hold a volatile token just to move dollars. The Circle Arc mainnet, which went live on September 16, 2026, removes that step: gas is paid in USDC, finality is deterministic in under a second, and the validator set is a curated group of financial institutions rather than an open market of stakers.

That is a genuine architectural departure, and it is easy to misread from headlines. Arc is not a rollup, not a fork of Ethereum, and not yet a proof-of-stake network. It is an EVM-compatible chain built from a Rust BFT consensus engine, an Ethereum execution client, and a handful of finance-specific modules.

This post walks through what is documented, what is only planned, and where the trade-offs sit. You will leave with a working mental model of the stack, the fee math, the validator trust model, and the questions to ask before building on it.

What this covers: the consensus and execution stack, the USDC fee model with worked numbers, StableFX and cross-chain plumbing, the permissioned governance model, and honest limits.

Systems analysis only. Nothing here is investment, legal or financial advice, and no view is offered on any token or price.

Context and Background

Stablecoin settlement has so far run on general-purpose chains that were designed for something else. Ethereum optimizes for open participation and credible neutrality. Solana optimizes for raw throughput. Both charge fees in a native asset whose price moves independently of the dollars being transferred.

For a payments operator this creates three recurring frictions. Treasury must hold and rebalance a second asset for gas. Fee budgets become unpredictable when the native token or network demand swings. And finality is either probabilistic or delayed, which complicates reconciliation. We covered the settlement side of this in our guide to stablecoin payment infrastructure in 2026.

Circle, the issuer of USDC and EURC, announced Arc in 2025 as a purpose-built Layer 1 and opened a public testnet in late October 2025. The design premise is that if the dominant use of the chain is moving regulated stablecoins, the chain should be shaped around that use: predictable dollar-denominated fees, instant irreversible settlement, and a validator perimeter that compliance teams can reason about.

By the launch announcement, Circle reported that USDC circulation stood at about $74 billion, that the testnet had processed more than 700 million transactions in under a year, and that more than 100 applications were live on day one. These are Circle’s own figures from its mainnet press release, and they are company-reported rather than independently audited.

The institutional angle matters as much as the technology. On August 5, 2026, Circle named eleven founding validators: BlackRock, DTCC, Galaxy, Global Payments (formerly Worldpay), ICE, Mastercard, MoneyGram, SBI Group, Standard Chartered, Sumitomo Corporation and Visa. Those firms sit across asset management, market infrastructure, card networks and banking. That mix tells you which workloads Arc is aimed at: tokenized funds, securities post-trade, and cross-border payments. For the asset side of that picture, see our breakdown of RWA tokenization architecture.

A note on sourcing. Several details in early coverage conflict or are vague, for example whether all eleven validators were producing blocks at launch or joining in phases. Where documentation and press disagree, this post says so.

The Arc Reference Architecture: Consensus, Execution and Stable Fees

Arc is a two-process chain: a Malachite BFT consensus engine decides block order and finality, while a Reth-based execution client runs the EVM. Fees are paid in USDC, validators are permissioned, and blocks are final in under a second with no reorganization risk, according to Arc’s documentation.

Figure 1 shows the path a transaction takes.

Figure 1: Transaction lifecycle on the Circle Arc mainnet, from JSON-RPC submission through Malachite consensus, Reth execution and Arc-specific modules.

The diagram separates concerns cleanly. Full nodes and wallets speak ordinary Ethereum JSON-RPC. The mempool enforces a fee floor. The consensus layer orders and finalizes, and the execution layer runs the state transition. Arc modules such as the Fee Manager sit inside the execution pipeline. The Privacy Sector and Stablecoin Services modules are shown dashed because the documentation lists them as planned.

Consensus: Malachite, a Tendermint-family BFT engine

Arc’s consensus client is Malachite, described in Arc’s docs as a high-performance Tendermint BFT implementation written in Rust. It originated at Informal Systems, the team that also maintained CometBFT, and that team has since joined Circle. The Malachite repository is Apache-2.0 licensed and organized into three layers: a Core holding the Tendermint state machine, an Engine handling networking and sync, and an App interface with a write-ahead log.

Tendermint-style consensus proceeds in rounds. A proposer broadcasts a block, validators cast a pre-vote if the block is valid, and if more than two-thirds pre-vote for it, they cast a pre-commit. When more than two-thirds pre-commit, the block is committed. There is no fork choice rule and no “wait for N confirmations” because a committed block is final by construction.

That property is the core of Arc’s settlement story. Ethereum mainnet finality is on the order of 12 to 15 minutes according to Arc’s own comparison, and optimistic rollups carry a challenge window of roughly a week. A BFT commit is binary: a transaction is either not yet final or final, with no intermediate probabilistic state.

Circle and Arc publish two different performance claims, and they should not be confused. Arc’s system-overview page cites 3,000+ transactions per second with 20 validators and finality under 350 ms. Arc’s consensus blog post, describing Malachite itself, cites about 780 ms average finalization at 100 validators with 1 MB blocks and roughly 13.5 MB/s, which it translates to around 50,000 transactions per second. These are benchmark configurations, not mainnet measurements. Real throughput depends on transaction size, geographic spread and validator hardware.

Execution: Reth and an Osaka-baseline EVM

Execution is handled by Reth, the Rust Ethereum execution client. Consensus and execution run as separate processes joined by the Engine API, over IPC or RPC. This is the same decoupling Ethereum adopted after the Merge, and it means Arc inherits mature EVM tooling: Solidity, Foundry, Hardhat, standard wallets, standard JSON-RPC on port 8545.

Arc’s EVM-differences page states that the hard-fork baseline is Osaka, with select Amsterdam features such as EIP-7708 (native value transfers emit Transfer logs). EIP-7702 set-code transactions, CREATE2 and EIP-2935 behave as on Ethereum. Mainnet uses chain ID 5042, and the testnet uses 5042002.

Stable fees: why USDC is both gas and unit of account

Arc’s most visible choice is USDC as the native gas token. Native USDC has 18 decimals for gas accounting, while the ERC-20 interface exposes the same balance with 6 decimals. Circle’s documentation warns developers to divide the native value by 10^12 for display and never to credit balances using the truncated 6-decimal figure.

The fee mechanism layers an exponentially weighted moving average on top of EIP-1559. Rather than reacting to a single block’s utilization, the protocol tracks a smoothed running average and adjusts the base fee against a target. We work through the numbers in the next section.

Deeper Analysis: Fee Math, StableFX and Cross-Chain Plumbing

Worked fee math (illustrative)

Arc documents a base-fee target of roughly $0.001 per ERC-20 transfer, a minimum base fee of 20 Gwei (the docs give this as the testnet minimum and instruct senders to set maxFeePerGas to at least 20 Gwei), and a maximum base fee of 20,000 Gwei. Because native USDC has 18 decimals, one “Gwei” here is 10^-9 USDC per unit of gas, not a fraction of ETH.

Take an ERC-20 transfer that consumes about 65,000 gas. This gas figure is an illustrative assumption; real transfers vary with token implementation and storage state.

• At the 20 Gwei floor: 65,000 x 20 x 10^-9 = 0.0013 USDC, about a tenth of a cent. That is consistent with Arc’s roughly $0.001 target.
• At the 20,000 Gwei ceiling: 65,000 x 20,000 x 10^-9 = 1.30 USDC. This is the worst case if demand saturates the market for a sustained period.

The ratio between floor and ceiling is 1,000 to 1. That bounded range is what lets a finance team put a hard cap in a budget. A payments firm sending one million transfers a day would spend about $1,300 at the floor, or as much as $1.3 million at the ceiling. The floor figure is a planning number; the ceiling is a stress bound, not a forecast.

Capacity gives a second view. The docs state 30 million gas per block, and roughly 60 million gas per second. Dividing implies about two blocks per second, or a block cadence near 500 ms. That is my derivation from two documented figures, not a stated block time; the docs do not specify one. At 65,000 gas per transfer, a block holds about 460 transfers, so simple transfers top out near 920 per second. Arc’s published roadmap talks about a Payment Sector targeting 100,000+ TPS, which would require a very different architecture from a single sequential EVM. It is a target, not a shipped feature.

How the EWMA fee loop behaves

Figure 2: Arc’s base fee feedback loop. Block utilization feeds an exponentially weighted moving average, which is compared with a target and clamped between the floor and ceiling.

Ethereum’s EIP-1559 raises the base fee by up to 12.5% after a full block. That is fast and can double costs within minutes during a burst. Arc’s design smooths the input. The documented recurrence is utilization_ewma(n) = alpha x block_utilization(n) + (1 – alpha) x utilization_ewma(n-1), and the base fee scales in proportion to the ratio of the smoothed value to the target, clamped to the floor and ceiling.

Arc’s docs do not publish the value of alpha or the target utilization in the pages I reviewed. So I can describe the shape, not the tuning. A small alpha means a single congested block barely moves the fee, and fees also decay slowly after congestion ends. The docs frame this as a feature: it removes the retry loops and fee-bumping heuristics that wallets need on volatile fee markets.

Two operational details matter. First, unlike Ethereum, Arc does not burn the base fee. Both the base fee and priority fee are credited to the block beneficiary. Second, transactions priced below the floor can be dropped or remain pending indefinitely. Wallet code that estimates fees from an Ethereum assumption may produce underpriced transactions.

EVM compatibility with stablecoin-shaped edges

“EVM-compatible” hides real differences, and Arc’s differences page lists them. They cluster around one theme: a native asset that is regulated money.

• No burning. Non-zero transfers to the zero address revert. SELFDESTRUCT follows EIP-6780 semantics with extra constraints, and non-zero calls to a self-destructed account revert.
• Blocklist enforced at runtime. Native transfers to or from a blocklisted address revert. That mirrors the denylist behavior of regulated stablecoins, but it now applies to the gas asset itself.
• PREVRANDAO always returns 0. Any contract using it as a randomness source is broken by design. Use an oracle or VRF.
• No blob transactions. EIP-4844 type-3 transactions are rejected, BLOBHASH returns 0, and BLOBBASEFEE returns 1.
• Balance quirks. ERC-20 balanceOf at 6 decimals can read zero while the native 18-decimal balance is non-zero.

Two additions are aimed at composability. A CallFrom precompile and a Multicall3From contract preserve the original msg.sender across delegated and batched calls, and a Memo extension attaches metadata to contract calls. Memo fields map directly onto payment reference data such as invoice IDs, which our payment orchestration architecture guide treats as essential for reconciliation.

StableFX: onchain FX with payment-versus-payment settlement

The FX story is not a generic AMM. Circle’s StableFX is described as an enterprise stablecoin FX engine using request-for-quote (RFQ) execution. A participant sends an RFQ for a pair, the engine returns the most competitive executable price, the user confirms, and the trade is recorded onchain. Settlement uses payment-versus-payment: both legs settle, or neither does.

Figure 3: StableFX flow. Each counterparty funds an FxEscrow contract, and the escrow releases both legs together.

On Arc’s contract list, the settlement contract is FxEscrow, and Permit2 is required for approvals. The mechanism removes principal risk from the classic FX failure case, where one leg pays and the other does not, historically known as Herstatt risk. For deferred trades Circle describes a configurable risk buffer.

Eligibility is restricted: participants are businesses in what Circle calls respectable jurisdictions that pass Circle’s compliance screening, and users bring their own custody for local stablecoins. So StableFX is a permissioned service on top of a chain, not an open-market venue.

The stablecoin set is broad. Circle lists USDC and EURC plus active or onboarding local stablecoins such as BRLA, MXNB, QCAD, JPYC, KRW1 and GBPA, among others. Circle also says its Circle Payments Network is natively integrated on Arc, with 24/7 settlement rather than banking-hour cutoffs. This matters because real-time rails such as those in our FedNow, UPI and SEPA Instant comparison still leave cross-currency legs to correspondent banking.

Interoperability: CCTP, Gateway and the App Kit

Arc’s contract reference lists CCTP V2 contracts (TokenMessengerV2, MessageTransmitterV2, TokenMinterV2) with CCTP domain ID 26, plus Gateway contracts (GatewayWallet, GatewayMinter). CCTP burns USDC on a source chain and mints native USDC on the destination, which avoids wrapped-token pools. One caution: Circle’s launch press release does not mention CCTP explicitly, so the interoperability claim rests on the developer documentation.

WETH on Arc is described as a bridged token, and cirBTC is Circle’s tokenized Bitcoin. The App Kit gives developers a unified SDK for bridging, swaps, on-ramps and yield. ERC-8004 registries for agent identity, reputation and validation are also deployed, which supports the agentic-payments positioning.

Governance and Trust: Who Actually Runs Arc

Arc’s trust model is its most important design decision and its most debated. The network runs a permissioned validator set under proof of authority. Full nodes are permissionless: anyone can run one and verify blocks. But only permissioned validators propose and vote.

Figure 4: Arc’s trust structure. A curated validator cohort forms the consensus quorum, while open full nodes and RPC providers verify but cannot vote.

What the validator set buys

Circle presents the permissioned model as a feature. Institutions with regulatory obligations want a defined governance perimeter: known operators, contractual accountability, and a place to send an incident report. DTCC, for example, said it will tokenize DTC-custodied assets on Arc, with its tokenization service expected in the second half of 2027. A bank or clearing utility cannot easily put regulated assets on a chain whose block producers are anonymous.

The numbers shape the fault model. Circle reported eleven founding validators, and The Defiant’s launch report described a cohort of eleven institutions plus Circle producing blocks. Treat twelve as a reported figure, not a documented parameter. With BFT quorum above two-thirds, twelve validators means a commit needs nine votes.

• Liveness: the chain halts if four or more validators go offline at the same time, because only eight would remain.
• Safety: two conflicting quorums of nine among twelve must overlap in at least six validators, so a safety violation requires six or more validators to sign conflicting blocks.

This arithmetic is illustrative and assumes equal voting weight and twelve validators. Arc’s docs do not publish validator count or weighting, so the real thresholds may differ.

The 2027 proof-of-stake question

Circle says a transition to proof of stake is planned for 2027. It also minted 10 billion ARC tokens at genesis, described as a digital commodity for security, utility and governance coordination. Circle states that this is not a commitment to a public token launch, and that network fees remain payable in USDC. Decrypt additionally reported a $222 million presale at a $3 billion valuation; that figure comes from press reporting and I could not confirm it in Circle’s own documents.

The design tension is clear. If ARC secures the network through staking, some form of validator selection must reconcile open economic participation with the compliance perimeter that institutions were promised. Circle has not published how. Until it does, the accurate description is a permissioned network with a stated intention to evolve.

Privacy and Post-Quantum Security: Live, Planned and Unclear

Institutional finance needs confidentiality: a fund cannot broadcast its positions to competitors, and a corporate treasury does not want supplier payments readable by anyone with an explorer. Arc addresses this in a planned module, and the status is worth stating carefully.

The Arc Privacy Sector is a roadmap item

Circle’s press release describes opt-in confidential transactions and balances with view keys as in development for network-wide release. Arc’s own privacy concept page is more specific about mechanism and more cautious about status: it says privacy features are on the roadmap and not yet available on Arc.

The documented design is the Arc Privacy Sector (APS), a confidential execution environment built on trusted execution environments (TEEs), meaning hardware enclaves. Users encrypt a transaction to the APS network public key and submit it as calldata to a precompile. The public ledger sees an opaque payload. Validators running APS inside enclaves decrypt and execute against private state, and only an acknowledgement and a predefined gas cost come back publicly.

Other properties in the docs include default-deny isolation (contract functions and storage are private unless explicitly opened), synchronous composability (private and public state finalize in the same block), and standard EVM semantics without bytecode changes.

There are two gaps between the press release and the docs page. The docs page does not describe confidential token transfers or view keys, and it describes privacy as binary rather than selectively disclosed. The concept index elsewhere mentions selective disclosure. Until the module ships with a spec, the safe reading is that the design intent includes auditability, but the mechanism is unpublished.

The TEE choice is a real trade-off. Enclaves are fast and EVM-compatible, unlike zero-knowledge proofs that impose circuit costs. But trust shifts to hardware vendors and enclave firmware, and TEEs have a history of side-channel research. That is a reasonable engineering bet for a permissioned validator set, and a weaker one if the set ever opens.

Post-quantum: one thing live, most of it staged

Arc’s post-quantum page reports that SLH-DSA-SHA2-128s signature verification is live on Arc mainnet through a PQ Signature Verify precompile, intended for application-layer authorization. Privacy encryption uses HPKE with the X-Wing KEM (X25519 combined with ML-KEM-768), HKDF-SHA256 and AES-256-GCM, which targets harvest-now-decrypt-later attacks.

The roadmap sequences the harder items. Native wallet transaction signing is in progress pending EIP-8141. Post-quantum privacy on mainnet is near-term. Post-quantum validator signatures are long-term. The stated rationale is that wallet keys have a narrower exploitation window than validator keys in a sub-second finality system, so wallets come first.

So “post-quantum support at launch” is accurate for one verification precompile, not for the chain’s core signatures. Today, consensus votes and standard transactions still rely on classical elliptic-curve signatures. Our analysis of the quantum threat to elliptic curve cryptography covers why that distinction matters for long-lived financial records.

Trade-offs, Gotchas, and What Goes Wrong

Every design choice above buys something and costs something. These are the tensions I would weigh before committing production volume.

Concentration and correlated failure. A small, curated validator set gives fast finality and clear accountability, but it also concentrates risk. If several validators share cloud regions, software builds or a single consensus client, one bug can halt the chain. Malachite’s own repository describes it as alpha software, unaudited and under heavy development. That note is from the open-source repo, and Arc’s production build may differ, but the reader should ask what audit and formal-verification work backs the mainnet release.

Issuer dependency. Gas in USDC means the chain’s basic economics depend on one issuer’s asset, reserves, compliance decisions and freeze powers. Circle’s own disclaimer states that gas fees depend on USDC availability. Blocklist enforcement at the runtime level extends the issuer’s controls to the gas asset. That is desirable for a compliance officer and uncomfortable for anyone building on credible neutrality.

No recourse on errors. Circle’s disclaimer notes the usual blockchain risks: smart contract vulnerabilities, network disruption, and no recourse for transaction errors. Deterministic finality makes a mistaken transfer irreversible in under a second. Institutions used to card chargebacks or RTGS recalls must build operational recovery elsewhere.

Fee floor mismatches. A wallet that assumes Ethereum-style fee estimation can underprice a transaction against the 20 Gwei floor, leaving it pending. Batch payout systems should test fee handling under a stressed base fee, not just at the floor.

Documentation churn. Several documents disagree at the edges: the 3,000 TPS and 50,000 TPS figures describe different benchmarks, the 20 Gwei minimum is labelled as a testnet value in one page and stated as a requirement in another, and validator rollout is described as phased in one source and as already producing blocks in another. Pin to the documentation version you tested, and expect parameters to change. Circle explicitly reserves the right to modify, delay or cancel features.

Decentralization is a stated pathway, not a present property. Arc lists no public route to becoming a validator. Judge the chain as a permissioned settlement network. That may be exactly what a regulated participant wants, but it is a different category of risk from a public permissionless chain.

Regulatory status. Circle states that Arc has not been reviewed or approved by the New York State Department of Financial Services or another regulator. It references the GENIUS Act for regulatory clarity, but no formal approval of the chain is documented. Compliance teams should not treat a validator list as a regulatory determination.

Practical Recommendations

For engineering teams evaluating Arc, the decision is less about ideology than about fit. Use the matrix below as a starting frame, then validate against your own regulators and counterparties.

Use case	Arc fit	Main reason	Key caveat
Cross-border treasury and FX between corporates	Strong	24/7 PvP settlement via StableFX, USDC gas	StableFX is permissioned and screened
Tokenized money market or Treasury funds	Strong	USYC and BUIDL on Arc, institutional validators	Custody and transfer-agent rules still apply
High-value confidential settlement	Conditional	Privacy Sector design targets it	Not live; TEE trust assumptions
Consumer micropayments at scale	Conditional	Fees near $0.001 per transfer, sub-second finality	Fee floor may exceed sub-cent needs
Censorship-resistant or permissionless DeFi	Weak	Permissioned validators, runtime blocklist	Different threat model
Long-lived records needing quantum resilience	Conditional	SLH-DSA verification live	Validator and wallet signatures not yet post-quantum

A short evaluation checklist:

• Confirm the current gas, fee floor and finality parameters against the live documentation version, not this post.
• Test wallet and payout code with 18-decimal native USDC and 6-decimal ERC-20 views to avoid truncation.
• Do not use PREVRANDAO or blob transactions; redesign anything that depends on them.
• Model blocklist behavior: what happens to a payout batch if one recipient is frozen?
• Decide your exposure to a single-issuer asset and document a contingency chain for settlement.
• Ask the validator set for its incident and upgrade process, and its independent audit status.
• Treat privacy and post-quantum features as roadmap until a mainnet spec and audit exist.

For builders coming from Ethereum, the migration cost is low. The harder work is in the operating model: freezing, recovery, fee budgets and cross-chain treasury policy. For comparison of how these pieces fit across an entire payment stack, our stablecoin payment infrastructure guide covers issuance, custody, on-ramps and settlement layers.

Frequently Asked Questions

What is the Circle Arc mainnet?

The Circle Arc mainnet is a Layer 1 blockchain launched by Circle on September 16, 2026. It is EVM-compatible, charges gas in USDC, and reaches deterministic finality in under one second using Malachite BFT consensus and a Reth execution client. It currently runs a permissioned proof-of-authority validator set of institutions, with a proof-of-stake transition planned for 2027, according to Circle.

Does Arc use USDC for gas fees?

Yes. USDC is Arc’s native gas token, with 18 decimals for gas accounting and a 6-decimal ERC-20 view of the same balance. Fees follow an EIP-1559 model smoothed by an exponentially weighted moving average, with a documented target near $0.001 per ERC-20 transfer. The base fee is bounded between 20 Gwei and 20,000 Gwei and is credited to the block beneficiary rather than burned.

Who are Arc’s validators?

Circle named eleven founding validators: BlackRock, DTCC, Galaxy, Global Payments, ICE, Mastercard, MoneyGram, SBI Group, Standard Chartered, Sumitomo Corporation and Visa. The validator set is permissioned, and no public route to becoming a validator has been published. Some reports say Circle also produces blocks. Documentation does not state the exact validator count or voting weights, so any threshold arithmetic is an estimate.

Is Arc compatible with Ethereum tools and contracts?

Largely yes. Arc runs the EVM on Reth, targets the Osaka hard-fork baseline, and supports standard JSON-RPC, Solidity, CREATE2 and EIP-7702. Differences include PREVRANDAO always returning zero, no EIP-4844 blob transactions, no burning of native value, runtime blocklist enforcement, and dual 18 and 6 decimal USDC representations. Review the EVM-differences page before deploying existing contracts.

Is Arc private, and is it quantum-safe?

Not fully, yet. Confidential transactions through the Arc Privacy Sector, based on trusted execution environments, are on the roadmap and were not live in Arc’s documentation. Post-quantum SLH-DSA signature verification is live as a precompile, but native wallet signing and validator signatures are still classical, with post-quantum versions staged for later. Treat both as partially delivered.

How does Arc connect to other chains?

Arc’s contract references list Circle’s Cross-Chain Transfer Protocol version 2 contracts with domain ID 26, plus Gateway contracts, so USDC can be burned on one chain and minted natively on another. WETH is a bridged asset. The launch press release does not mention CCTP by name, so confirm current bridge routes and fees in the developer documentation before you design treasury flows.

Further Reading

• Stablecoin payment infrastructure in 2026: issuance, custody and settlement layers around chains like Arc.
• RWA tokenization architecture: how tokenized funds and securities are structured onchain.
• Payment orchestration platform architecture: where a chain fits behind routing and reconciliation.
• FedNow, UPI and SEPA Instant compared: fiat real-time rails that stablecoin chains complement.
• Circle’s Arc mainnet press release and the Arc developer documentation: the primary sources for every figure here.
• Malachite on GitHub: the open-source BFT engine behind Arc consensus.

This article is a technical systems analysis for educational purposes. It is not investment, legal, tax or financial advice and makes no prediction about any asset or price.

By Riju — about