Cabinet
Back to Technology Insights
2026.09.16

Circle Opens Arc Public Mainnet: Where a Permissioned L1 With USDC Gas Breaks EVM-Compatibility Assumptions (18 vs 6 Decimals, No WETH)

Circle Opens Arc Public Mainnet: Where a Permissioned L1 With USDC Gas Breaks EVM-Compatibility Assumptions (18 vs 6 Decimals, No WETH)

What happened

Circle opened Arc's public mainnet on September 16. Until then it had run as a private mainnet with more than 100 institutional and ecosystem builders.

Arc is an EVM-compatible L1 that uses the Ethereum client Reth for execution and Malachite for consensus. Malachite is a Tendermint-derived BFT engine originally developed at Informal Systems and now maintained by Circle. Circle describes transactions as either unconfirmed or completely final: they are final once more than two-thirds of validators commit, with no reorganization risk. Blocks arrive about every 0.5 seconds.

Validation is permissioned (PoA), and Circle selects the validators. Alongside Circle, the eleven founding validators are BlackRock, DTCC, Galaxy, Global Payments, ICE, Mastercard, MoneyGram, SBI, Standard Chartered, Sumitomo Corporation and Visa. Anyone can deploy contracts and transact, but block production is limited to the selected institutions. A move to proof of stake and privacy features are planned for later upgrades. Circle minted 10 billion "ARC" tokens on launch day but called this a technical milestone, not a commitment to a public launch. Gas continues to be paid in USDC.

The problem it targets: volatile fees and ambiguous settlement

Arc's design choices address two problems. The first is fee volatility. On chains where gas is paid in a volatile asset, users must acquire that asset first, and businesses cannot quote fees in dollars. Arc prices gas in USDC and puts a floor under the base fee. Arc's documentation sets that floor at 20 gwei. A developer who queried a node directly on September 20 reports that every sampled block had a base fee of 20 gwei. A simple 21,000-gas transfer therefore costs about 0.00042 USDC.

The second is settlement ambiguity. On chains with probabilistic finality, users decide for themselves how many confirmations to wait. Payments, FX and securities settlement cannot accept that. BFT consensus with a bounded validator set makes finality binary.

Trade-offs: compatibility gaps, and who can stop a transfer

The first cost is a set of small gaps in EVM compatibility. The native asset is USDC, but it is counted in 18 decimals to match EVM conventions: eth_getBalance, msg.value and gas accounting all use 18 decimals. The ERC-20 contract representing the same balance (0x3600000000000000000000000000000000000000) uses 6 decimals, like USDC on other chains. The two are not separate assets but two views of one balance, with a conversion factor of 10^12. Arc's documentation warns that the ERC-20 view truncates anything below 1×10^-6 USDC, so a balanceOf of zero does not prove the native balance is zero.

Arc also has no WETH, because the native asset already has an ERC-20 face. Uniswap's deployment table for chain 5042 lists WETH9 as "Unsupported Protocol." The address holds a minimal contract that always reverts. Router paths that go through wrapping are stopped there by design.

The fee model has quirks of its own. Arc layers a moving average and a floor on top of EIP-1559, so under normal load the base fee sits on the floor and does not move. The same hands-on report found the next block's base fee published in the parent header's extraData. That makes fees knowable in advance and quotable in dollars. It also means the fee market behaves differently from Ethereum's: logic that relies on priority fees to win inclusion under congestion may not have the same effect. Arc also does not support EIP-4844 type-3 (blob) transactions, and wallets that accept arbitrary EVM transaction types need to reject them.

The second cost concerns censorship resistance and neutrality. Circle chooses the validators, and Arc's security page lists "validator-layer sanctions controls" as part of its operating model. Arc's documentation notes that a native transfer can revert even with a sufficient balance, for example because of the blocklist. For institutions that must meet regulatory obligations, this is a requirement. For designs that assume a permissionless chain, it is a different set of assumptions. The question is not which is better; integrators should choose against their own requirements.

Pitfalls to watch

The most likely failure is a silent error from mixing up decimals. Pass a 6-decimal ERC-20 amount straight into msg.value and you send one trillionth of what you meant. Pass a native amount into transfer and you attempt to send an absurdly large sum. Neither raises an error; both show up as wrong amounts. Issues in circlefin/arc-node report wallets displaying balances off by a factor of 10^12 in either direction.

Next is double counting in indexers. According to Arc's compatibility guide, a single ERC-20 transfer() call emits both an 18-decimal system event and a 6-decimal ERC-20 Transfer event, while a plain native send emits only the system event. A design that ingests both native sends and logs counts the same movement twice. The same goes for balances: summing eth_getBalance and balanceOf double-counts one balance.

Third is reusing address tables. Tools that assume other chains' canonical addresses do not carry over to Arc. According to the developer's hands-on report, Uniswap v3's canonical addresses from other chains hold a different contract on Arc that is not Uniswap v3. Do not trust an address without checking its code size and making at least one live call.

Fourth is identifying assets by ticker. Only one address, 0x3600…0000, is USDC on Arc, but anyone can give a contract any name or symbol. The same report found that within days of launch, a pair of a different token calling itself "USDC" against real USDC was trading heavily on a launchpad venue. Asset allowlists must be keyed on addresses, not tickers.

[Technical Insights & Actions]

  1. "EVM-compatible" means compatible instruction sets and tooling, not compatible amount units or native-asset semantics. On a chain whose native asset is a stablecoin, the decimal boundary appears in every payment path. [Integrators / Contract developers] Before integrating with Arc, centralize native (18-decimal) and ERC-20 (6-decimal) conversion in a single function, and require unit tests that check decimals on both msg.value and transfer.
  2. When one asset has several interfaces and several events, balance and history aggregation double-counts. Display and accounting break unless there is an explicit rule for which view is authoritative. [Integrators / Data platform teams] When building indexers and balance displays, define native balance as authoritative, add rules that deduplicate ERC-20 events against native system events, and verify on testnet that one transfer is never counted twice.
  3. A permissioned validator set with sanctions controls buys settlement certainty at the price of transfers that "can fail even with sufficient balance." This is a design premise, not a malfunction. [Product teams] When deciding whether to adopt Arc as a payment rail, write into your requirements the business flow for failed transfers (reverts due to blocklists and similar rules) and when to use Arc versus a permissionless route.

[Sources]

This article is a technical commentary based on publicly available information and is not investment advice.

Previous ArticleAddresses Signed With Old DCENT App Wallet Versions Drained at Scale: 11.75 Million XRP From 6,678 Wallets, and a Key History That No Patch Can EraseNext Article [Follow-up] Glamsterdam's Sepolia Fork Locked for 2026-10-06 13:53:36 UTC (Epoch 353024): First Clean Transition on Devnet-11, and the "Epoch 351232" Mismatch Explained