Arc Blockchain Security & Audit Checklist

Building on Arc Network or deploying to Arc Mainnet? This Arc blockchain security guide covers the chain-specific risks to test before deploying Solidity smart contracts. Arc is an EVM-compatible Layer 1, but its native USDC model and execution rules can introduce bugs when teams port Ethereum contracts or build new applications with familiar EVM tooling.

Imagine an automated market maker (AMM) that accepts USDC through Arc’s native-value interface but records amounts through the familiar ERC-20 balanceOf() interface. Both reads appear to represent USDC. In reality, they use different decimal scales: native values use 18 decimals, while the ERC-20 view uses 6.

If the contract mixes those raw values in swap calculations, liquidity-share accounting, or fee calculations, the result can be wrong by a factor of 10¹². The transaction can execute successfully while the protocol records the wrong amount.

This matters for teams building decentralized exchanges (DEXs), AMMs, staking and restaking systems, stablecoin payments, treasury tools, onchain FX, tokenized assets, and DAO applications on Arc. Familiar Solidity and EVM tooling reduce migration effort, but do not remove the need to test Arc-specific behavior.

This guide covers Arc blockchain security risks involving native USDC accounting, value-transfer rules and payout reentrancy, EVM differences, CallFrom-based Memo and Multicall3From behavior, oracle and cross-chain integrations, finality, and offchain systems. Use it as an Arc smart contract audit checklist alongside a review of your application’s accounting, access control, and economic design.

Arc Network EVM compatibility is a starting point, not a security review#

Arc Network is an open, EVM-compatible Layer 1 blockchain. Solidity contracts and familiar tools such as Foundry, Hardhat, viem, and ethers.js remain useful, and many existing contracts can be deployed without source changes. Arc targets Ethereum’s Osaka hard fork as its baseline and ships selected Amsterdam-track features early, notably EIP-7708 Transfer logs for native value. But compatibility at the development interface does not mean that every execution detail is identical to Ethereum.

Arc was created by Circle for financial applications that need predictable dollar-denominated fees and fast, deterministic settlement without requiring users to hold a separate volatile gas token. Developers can deploy contracts openly, while a permissioned validator set operates consensus. Intended uses include cross-border payments, 24/7 foreign exchange, tokenized-asset settlement, collateral and lending, treasury operations, and programmable payments by software agents.

USDC is both Arc’s native asset and its fee currency, and Circle’s payment and cross-chain services connect Arc transactions to broader financial flows. Those choices change familiar EVM assumptions: native and ERC-20 USDC share one balance, one transfer can appear in two event streams, and an Arc-finalized transaction may be only one step in a larger settlement flow.

Arc documents specific differences involving native USDC, value transfers, SELFDESTRUCT, PREVRANDAO, event emission, fee handling, and block timestamps. These differences matter most when a protocol was designed around assumptions inherited from another chain.

Think of the review in two layers. First, confirm that the contract’s business logic is sound. Then verify that its assumptions about balances, transaction execution, external assets, events, and finality match Arc’s actual behavior.

A successful compile or a passing test suite on a standard local EVM is not evidence that Arc-specific execution paths have been tested.

Arc also provides builder resources such as Arc Studio and Arc-specific predeploy checks. These are useful additional layers, but Arc’s own security guidance says those checks are not a guarantee that an application is secure and do not replace independent review. Treat automated checks as part of the process, not as sign-off. See Security on Arc.

Native USDC on Arc Chain: one balance, two interfaces, two decimal scales#

The most important Arc-specific concept to understand is that USDC is the native gas asset. Arc exposes the same underlying USDC balance through two interfaces:

Interface	Typical use	Precision for raw values
Native balance / `msg.value`	Gas accounting, native sends, native value	18 decimals
ERC-20 USDC interface	`transfer`, `approve`, `allowance`, `balanceOf`	6 decimals

One USDC is represented as 1e18 through the native-value interface and 1e6 through the ERC-20 interface. The values refer to the same underlying asset; they are not separate pools of USDC. The conversion factor between the raw representations is 1e12.

There is a second precision trap. The ERC-20 view truncates the last 12 decimal places of the native balance. A native balance containing less than 0.000001 USDC may still be non-zero even when USDC.balanceOf(account) returns zero. A zero ERC-20 balance therefore does not prove that an account has no native USDC.

Keep accounting in one canonical unit#

Choose one internal unit for each accounting domain and convert explicitly at its boundaries. Do not compare raw msg.value against USDC.balanceOf() or add those values together without normalization. In particular, a pool that treats native USDC and the ERC-20 USDC interface as two separate assets models one asset twice and can overstate its reserves.

Arc’s own AMM porting guidance is to use the ERC-20 USDC interface (0x3600000000000000000000000000000000000000) as the pool token and for reserve math, and not to deploy a WETH-style wrapper or a WUSDC. Do not alias the EIP-7528 native-asset sentinel to that address either, because that conflates native value transfers with ERC-20 transfers.

If a protocol accepts native USDC but its internal ledger only supports six-decimal amounts, decide what should happen to values that cannot be represented exactly. One conservative pattern is to reject unsupported precision rather than silently rounding it away:

uint256 constant NATIVE_TO_ERC20_SCALE = 1e12;

error UnsupportedNativePrecision();

function toSixDecimalUnits(uint256 nativeAmount)
    internal
    pure
    returns (uint256 amount6)
{
    if (nativeAmount % NATIVE_TO_ERC20_SCALE != 0) {
        revert UnsupportedNativePrecision();
    }

    amount6 = nativeAmount / NATIVE_TO_ERC20_SCALE;
}

This is an illustrative conversion, not a drop-in accounting library. A protocol that needs sub-micro-USDC precision should retain 18-decimal precision internally instead of discarding the remainder. Test deposits, withdrawals, swap amounts, liquidity shares, fees, and rounding in both directions.

Test the conservation rule at the precision boundary#

For an account a, the two views are related, in raw units, by:

USDC.balanceOf(a) = floor(nativeBalance(a) / 10^12)

Rounding must be consistent at every native or ERC-20 boundary, including msg.value deposits, transferFrom deposits, withdrawals, and sweeps. If the mint and redeem paths round inconsistently, cycling between them can over-credit shares; where they are symmetric, native fractions below 0.000001 USDC simply remain as dust.

The precision boundary makes this measurable. Fund a recipient with 10^12 - 1, 10^12, and 10^12 + 1 native raw units and compare both balance views. A transfer of one raw ERC-20 unit (0.000001 USDC) should add exactly 10^12 native units to the recipient. Apply the same boundary cases to share pricing, collateral, and every deposit and outflow route.

Two further points are easy to miss. Native sends such as call{value: ...} need their own authorization checks, because an ERC-20 allowance does not limit them. For the same reason, a contract that is meant to hold USDC only as an ERC-20 balance must not expose a native-balance sweep: native and ERC-20 USDC are one balance, so the sweep also moves the ERC-20 balance. And when comparing a sender’s balance before and after a transaction, include the separate USDC gas debit: gas and transfers share one balance, so the displayed ERC-20 balance may exceed the maximum amount the account can actually send.

Official reference: Arc’s stablecoin-native model.

Arc Mainnet USDC transfers can fail even when the sender has enough#

On a conventional EVM chain, developers often expect a native transfer to succeed if the sender has enough balance and the recipient can receive the call. Arc adds value-transfer rules because native value is USDC.

Arc’s documented value-transfer rules say a transfer may revert in these cases:

The transfer sends non-zero value to the zero address (a zero-value transfer to 0x0 succeeds).
The sender or recipient is blocklisted.
The transfer would burn value, including certain SELFDESTRUCT cases.
The transfer targets an account that has already self-destructed.
A contract forwards native value to a destination where one of these rules applies.

Some third-party references also report that value sent to certain precompiles reverts. The current official rule list does not include that case, so treat it as something to test on Arc rather than a documented rule.

These conditions can affect more than a simple payment. Consider an AMM settling a swap, a staking contract processing an unstake request, a pool returning assets, or an automated strategy moving funds. If the protocol assumes that every payout succeeds, a valid operation may revert at the point where it tries to move funds.

One failure sits outside the transfer itself: a blocklisted transaction sender is rejected by the RPC node before the transaction enters the mempool, which leaves no receipt at all, and a sender that becomes blocklisted between submission and execution is rejected at the pre-execution check. That differs from an included revert with status = 0, which spends the nonce and consumes gas up to the failing check. The two call for different retry and accounting behavior. Arc’s separate transaction-address denylist is another control to check on the deployed network.

Design explicit failure behavior#

Do not mark a withdrawal, swap, staking exit, or bridge operation as complete until the relevant transfer has succeeded. Do not ignore low-level call return values. Test how the protocol behaves when a transfer to or from a blocklisted address reverts, including whether failed operations remain clearly recorded and unaffected users can continue to operate.

A blocklist failure should not be “fixed” by weakening authorization or attempting to bypass the control. Define an operational response that respects the chain’s rules and the protocol’s legal and compliance requirements. Where an operation cannot complete, the contract and its monitoring should make the failure visible rather than silently treating it as settled.

Also review every path that sends native value to another contract. A receiver with a payable fallback is not a guarantee that the transfer will succeed under Arc’s native-value rules.

Preserve claims when payouts fail, and close reentrancy paths#

A native USDC payout made with call{value: amount} can execute recipient code. The recipient can call back into the payer before the first withdrawal finishes. A withdrawal should therefore consume or lock the user’s claim before the external call, then check the call’s success flag. If the call fails, the transaction should revert or leave a retriable claim; it must never record a successful payout.

A reentrancy guard is warranted when another entry point can spend the same liability. A receiver that calls back through both the same and a different withdrawal path should never take funds twice.

Destination checks can prevent predictable failures, but restrictions may change before execution, so they cannot replace failure handling. Try payouts to a blocked recipient, the zero address, and a previously destroyed account on Arc’s runtime, and probe precompile targets empirically. A failed payout must preserve the claim without preventing other users from exiting.

Reference: Arc’s EVM differences and value-transfer rules.

Arc EVM differences: review `SELFDESTRUCT` and `PREVRANDAO` assumptions#

SELFDESTRUCT deserves a targeted review if it appears in your contracts, dependencies, deployment helpers, or temporary-contract patterns.

On Arc, a contract’s USDC is held as its native balance. A successful SELFDESTRUCT that transfers that balance sends the USDC to the beneficiary. On a typical EVM chain, a contract’s ERC-20 USDC balance is held in the token contract and would not be moved merely because the holder contract self-destructs.

Arc also documents cases where SELFDESTRUCT reverts because the destination or source violates native-value rules. In addition, a non-zero-value call to an account that has already self-destructed in the same transaction reverts on Arc, even though a similar sequence can succeed on Ethereum.

The practical lesson is not to add SELFDESTRUCT support to a new design. It is to audit any existing use and confirm that the protocol does not depend on Ethereum-specific behavior for asset recovery, temporary contracts, deployment flows, or cleanup.

Review emergency sweeps and reachable SELFDESTRUCT paths alongside the payout paths above, since a contract’s native balance is USDC and SELFDESTRUCT can move it even under current code-deletion semantics.

Do not use `block.prevrandao` as a randomness source#

Arc documents that the PREVRANDAO opcode always returns 0. Any lottery, selection mechanism, shuffle, or other contract path that relies on block.prevrandao will therefore not receive the randomness it expects. Use a suitable randomness oracle or verifiable random function (VRF), and assess its request, fulfillment, timeout, and failure paths.

Arc also differs from Ethereum in its handling of certain beacon-root and blob-transaction features. If your contracts or dependencies read beacon-root data or rely on blob transactions, check the current EVM differences reference and the contract-porting checklist rather than assuming the behavior is portable.

Arc blockchain indexing: prevent duplicate USDC transfer events#

Arc emits standard Transfer events for native USDC movements through its implementation of EIP-7708. This improves visibility, but it creates a subtle accounting issue for indexers and offchain systems.

USDC movements can appear from two emitters:

Event source	Address	Precision
Native USDC system emitter	`0xffffFFFfFFffffffffffffffFfFFFfffFFFfFFfE`	18 decimals
ERC-20 USDC contract	`0x3600000000000000000000000000000000000000`	6 decimals

A native send emits the system event. An ERC-20 transfer() emits a log from the ERC-20 contract and a corresponding system log. If an indexer sums both event streams as though they were separate transfers, it can count the same movement twice and corrupt deposit totals, user balances, TVL calculations, or reconciliation reports.

Filter by the emitting address and interpret each event using its documented decimal scale. Use transaction hash, block number, transaction index, and log index to identify and order records.

Treat the system-emitter stream as canonical#

On current Arc mainnet, the system emitter logs explicit USDC movements at 18-decimal precision. The system log also covers contract creation with an endowment, SELFDESTRUCT balance transfers, and the mint and burn operations behind the ERC-20 interface (expressed as transfers from or to the zero address). The system log is emitted first in the transaction’s log order. A nonzero ERC-20 USDC transfer between distinct addresses also logs a 6-decimal Transfer from the token contract, and those two logs represent one economic movement. A native send has the system log alone. Zero-value and self-transfers produce no system transfer log. Mainnet has used the EIP-7708 format since genesis. Historical testnet blocks before the Zero5 hard fork used custom NativeCoin* events from 0x1800000000000000000000000000000000000000, so testnet backfills across that boundary should read both formats.

The system-emitter stream is the canonical record of explicit USDC transfers on current mainnet. ERC-20 logs can cross-check which interface was used, but they must not create another credit. Store each system movement under (chainId, txHash, systemLogIndex). That key makes the canonical stream idempotent, but it cannot by itself merge the companion ERC-20 log, which has a different index.

A credit should follow a successful receipt and the system log’s actual sender, recipient, and 18-decimal amount. The transaction’s from may be a relayer, and tx.value does not describe every internal transfer. Test with one native and one ERC-20 payment to the same deposit address: each must produce exactly one credit. Reverted calls, several transfers in one transaction, and a transaction that pays gas without making a payment expose false-credit paths. Gas debits emit no Transfer log, so reconcile a sender’s balance using the receipt’s gasUsed × effectiveGasPrice as well.

References: USDC system events and Index Arc events.

Arc Memo and Multicall3From: CallFrom precompile security risks#

Arc’s predeployed Memo (0x5294E9927c3306DcBaDb03fe70b92e01cCede505) and Multicall3From (0x522fAf9A91c41c443c66765030741e4AaCe147D0) contracts route target calls through the CallFrom precompile; they are the only contracts permitted to call it. Unlike a conventional Ethereum batching contract, the target sees the transaction-signing externally owned account (EOA) as msg.sender, not the extension contract. Both routes require a direct EOA call, and an intermediary smart-contract wallet is rejected. Multicall3From also cannot forward native USDC value. An application that authorizes by msg.sender, or assumes a batch can send msg.value, should be exercised through both its direct path and these Arc routes, including a contract-wallet rejection case. Offchain compliance and blocklist monitors must also include both contract addresses and attribute routed activity to the original sender, or they will miss the true sender in subcalls.

Multicall3From and partial failure#

For Multicall3From.aggregate3, a subcall marked allowFailure = true can revert while the outer transaction succeeds. The extension emits no batch event, and a successful receipt does not expose per-call return values or prove that every leg succeeded. Credit each payment only after a successful receipt and a matching canonical USDC movement for its sender, recipient, and amount, and verify other subcalls against their resulting contract state. In a test, inspect the returned Result[] or an execution trace as well.

For example, batch two USDC transfers with one blocklisted recipient and credit the successful transfer only. Set allowFailure = false when both payments are required.

Memo and invoice matching#

The Memo contract emits BeforeMemo(memoIndex) before the child call, the target’s events during it, and Memo(sender, target, callDataHash, memoId, memo, memoIndex) after it succeeds. The memo ID and bytes are caller-supplied, and memo calls can nest. Use memoIndex, event order, and the hash of the expected calldata to associate metadata with the intended call, then require Arc’s canonical USDC transfer to match the expected sender, recipient, and amount. An underpayment with a matching memo ID must leave the invoice open.

Arc finality and block timestamps: what developers need to know#

Arc documents deterministic finality: a transaction is final once it is included. That differs from networks where applications wait for several confirmations to reduce reorganization risk. A protocol or indexer can use Arc’s finality model instead of importing an arbitrary confirmation-depth delay from another chain.

But finality is not a substitute for correct transaction processing. Offchain services still need idempotency, restart recovery, monitoring, and clear handling of RPC failures. If an indexer reconnects and replays a block range, it should not credit the same deposit twice. If a transaction initiates a cross-chain transfer, finality on Arc does not mean the destination chain has already completed its part of the flow.

Arc also documents that block timestamps are non-decreasing rather than strictly increasing. Because blocks can arrive faster than the timestamp’s one-second granularity, multiple blocks may share the same block.timestamp.

Avoid using timestamps as unique event identifiers or as the only ordering key for offchain processing. Where order matters, use block number and transaction/log indexes. Where time matters, test cooldowns, deadlines, auctions, and scheduled actions under repeated timestamps as well as normal progression.

Model payment states#

Arc finalizes blocks through its permissioned validator consensus when more than two-thirds of voting power precommits. Finality establishes the Arc block’s status under that consensus model. It does not establish that an included call succeeded, or that validators will include a later transaction.

A payment therefore needs distinct states for submission, rejection or dropping without a receipt, inclusion with a revert, and inclusion with the expected effect. A fee cap below the network’s current minimum can leave no receipt, so an operator should confirm nonce state before repricing or retrying. Fulfillment requires both a successful receipt and the intended balance or contract-state change. Exercise each state to show that a rejected or reverted transaction cannot advance an order or consume a user’s claim.

Pin privileged controls#

USDC issuer controls, the transaction denylist, validator membership, and protocol configuration are distinct control surfaces, and they need a different kind of proof. A core protocol review should pin the deployed proxy implementations and role holders for the validator registry, transaction denylist, protocol configuration, and upgrades. Unauthorized callers must be unable to change voting power, denylist entries, fee rules, or implementation addresses, and controlled role tests should show the expected state and events after authorized changes. Applications should monitor changes that affect their own availability, while treating documented validator or issuer power as a trust assumption unless it causes a concrete failure.

Reference: Deterministic finality and settlement.

Arc oracle and cross-chain security for DeFi applications#

A stablecoin-native chain does not eliminate oracle risk. DEX pricing modules, automated market makers, staking systems, tokenized-asset protocols, and treasury applications still need to verify that market data is appropriate for the action being taken.

Chainlink has announced Arc Mainnet support for Data Feeds, Data Streams, and CCIP, rolled out in stages around Arc’s September 2026 mainnet launch. That does not mean every asset feed, stream, or cross-chain route is available or appropriate for a particular protocol. Verify the exact deployment and supported integration in the provider’s current documentation before hardcoding an address or launching an automated strategy.

For each price feed, review at least the following:

Confirm the feed address belongs to the intended asset and Arc network.
Read the feed’s decimals() value instead of copying a precision assumption from another deployment.
Validate the answer and timestamp, and define an application-specific staleness policy based on the feed’s documented heartbeat and deviation behavior.
Decide how swaps, minting, redemption, rebalancing, and other price-sensitive actions behave when data is invalid or too old.
Test decimal normalization and rounding with values near the protocol’s thresholds.

A transaction can be final while its oracle data is stale or economically unsuitable. Make freshness and failure policy explicit rather than assuming that Arc’s settlement properties make the underlying data current.

Cross-chain transfers are still asynchronous#

Arc supports stablecoin and interoperability integrations, but a cross-chain message remains a separate lifecycle from a transaction on the source chain. Validate the destination network, token, recipient, amount representation, and message sender. Track whether the source action was submitted, the destination action was executed, and recovery is possible after a failure or delay. Make message processing idempotent so retries cannot execute the same business action twice.

Use the canonical USDC model documented for Arc. Do not introduce USDC.e, wUSDC, or another wrapped variant as if it were Arc’s native USDC. For transfers through Circle’s CCTP or another supported bridge or messaging layer, confirm the current supported networks, contracts, domains, and destination behavior directly from its documentation. Do not treat a successful source-chain transaction as proof that a recipient has received funds on Arc or on another destination chain.

Circle integrations: stop at the actual settlement boundary#

A finalized Arc transaction proves only what happened on Arc. Applications using Circle services must verify the additional completion state:

CCTP: A finalized source burn is only the first leg. Match its message, domains, recipient, and amount to a successful destination mint under the chosen finality policy. A missing or failed mint must not be credited.
Gateway: An onchain deposit may precede an available Gateway balance. The supported deposit method and authorization must lead to the expected ledger state and destination mint before funds are treated as spendable there.
StableFX: One-sided escrow funding does not complete payment-versus-payment settlement. The signed terms, deadline, and final settlement or refund state determine whether either side has received the expected currency.

The security boundary is the moment an application grants value or advances state. On Arc, that decision must follow the actual USDC movement and, where relevant, the verified downstream settlement.

References: Arc contract addresses, Arc cross-chain guides, Chainlink Data Feeds, and Chainlink CCIP.

Keep keeper and relayer transactions operational#

Arbitrageurs, keepers, relayers, and paymasters can be part of a protocol’s operational safety model. If these services cannot get their transactions included, otherwise-correct onchain operations may not execute when expected.

Arc’s documented fee market denominates fees in USDC and uses an EIP-1559-style model with smoothing. The official gas guide currently documents a base-fee range of 20 Gwei to 20,000 Gwei and warns that transactions with a maxFeePerGas below the 20 Gwei floor may remain pending or be dropped without a receipt. Keepers that cap fees should size the cap against that range rather than a fixed small number. Fee assumptions can change, so fetch current fee data from the Arc RPC and confirm the latest protocol parameters before deployment.

For systems that perform time-sensitive actions, test transaction submission, fee estimation, replacements, RPC errors, missed triggers, and retries. A keeper should be observable and recoverable; it should not silently assume that a transaction was included simply because a send request returned successfully.

Reference: Arc gas and fees.

Arc Mainnet smart contract deployment security checklist#

Use this list during implementation review. Turn each relevant item into an automated test, a deployment check, or a documented operational control.

Asset accounting#

Define a canonical internal precision for native USDC and ERC-20 USDC values.
Test msg.value, address.balance, eth_getBalance, and USDC.balanceOf() with values that expose the 18-versus-6-decimal difference.
Test deposits, withdrawals, swap amounts, liquidity shares, fees, and rounding at boundaries.
Confirm the protocol does not treat native USDC and its ERC-20 interface as two assets.
Test 10^12 - 1, 10^12, and 10^12 + 1 native raw units and confirm USDC.balanceOf(a) = floor(nativeBalance(a) / 10^12).
Check mint and redeem rounding for any asymmetry that lets cycling over-credit shares.
Give native call{value: ...} sends their own authorization checks, do not expose native-balance sweeps on contracts that hold USDC as an ERC-20 balance, and include gas debits when comparing sender balances.

Transfers and execution semantics#

Test native-value transfers to the zero address and to contracts that forward value.
Exercise documented blocklist reverts and verify that accounting does not mark failed operations as completed.
Consume or lock a user’s claim before any external payout, confirm the USDC actually moved, and guard every entry point that can spend the same liability against reentrancy.
Try payouts to a blocked recipient, the zero address, a previously destroyed account, and (empirically) a precompile, and confirm other users can still exit.
Review SELFDESTRUCT usage, including balances held by temporary or self-destructing contracts, and treat emergency sweeps and reachable SELFDESTRUCT paths as outflows.
Search for block.prevrandao and replace it where randomness is required.
Review dependencies for beacon-root, blob-transaction, or other EVM-specific assumptions.

Events and offchain systems#

Distinguish native system Transfer logs from ERC-20 USDC Transfer logs to avoid double-counting.
Credit deposits from the canonical system-emitter log under (chainId, txHash, systemLogIndex), only after a successful receipt, using the log’s actual sender, recipient, and 18-decimal amount.
Test one native and one ERC-20 payment to the same deposit address, plus reverted calls, multi-transfer transactions, and gas-only transactions, and reconcile sender balances with gasUsed × effectiveGasPrice.
Use event emitter, block number, transaction index, and log index in event ingestion and reconciliation.
Make indexers and keepers idempotent and able to recover after RPC outages or replayed ranges.
Test behavior when multiple blocks share the same timestamp.

CallFrom, finality, and privileged controls#

Exercise msg.sender-based authorization and msg.value assumptions through both the direct path and the Memo and Multicall3From routes, including a contract-wallet rejection case.
Test allowFailure = true partial failures and verify each leg through a matching canonical USDC movement, Result[], or a trace.
Match Memo metadata with memoIndex, event order, and calldata hash, and confirm an underpayment with a matching memo ID leaves the invoice open.
Track submission, rejection without a receipt, inclusion with a revert, and inclusion with the expected effect as separate payment states.
Pin deployed proxy implementations and role holders for the validator registry, transaction denylist, protocol configuration, and upgrades.

Oracles and cross-chain flows#

Verify every oracle address and asset mapping against current provider documentation for Arc Mainnet.
Validate oracle precision, timestamps, freshness, and failure behavior for each value-sensitive action.
Confirm bridge or messaging contracts, network identifiers, token addresses, and destination execution requirements.
Model retries, delays, duplicate messages, partial failures, and destination-chain completion explicitly.
For CCTP, Gateway, and StableFX, credit value only after the destination mint, ledger state, or final settlement is verified.

Deployment and operations#

Test with Arc-aware tooling, such as Arc Foundry (arc-anvil --network arc, arc-forge test), rather than relying only on standard anvil behavior.
Run critical integration tests against Arc Testnet and validate the actual deployment configuration for Arc Mainnet.
Verify the network configuration and contract addresses from the official Arc docs and contract-address registry.
Confirm keepers, relayers, and indexers can handle current fees, retries, and RPC failures.

The security principle: do not rely on an EVM assumption simply because it worked on another chain. Identify the assumption, verify Arc’s documented behavior, and test the failure path before real value depends on it.

Arc blockchain security FAQ#

What is the Arc blockchain (Arc Network)?#

Arc, also called Arc Network (and sometimes searched as “Arc Chain”), is an open, EVM-compatible Layer 1 blockchain designed for financial applications and stablecoin-native settlement. Developers can use familiar Solidity and Ethereum tooling, but should check the official Arc documentation for network-specific behavior before deploying. Always verify the documentation, chain ID, RPC endpoint, and contract addresses for the intended Arc network.

Is Arc EVM-compatible for Solidity smart contracts?#

Arc supports EVM-compatible development, so many Solidity contracts and tools such as Foundry, Hardhat, viem, and ethers.js remain useful. Compatibility does not mean every assumption about native ETH, opcodes, events, timestamps, or transaction behavior carries over unchanged. Test the integration on Arc rather than relying only on a standard local EVM.

Is USDC the gas token on Arc?#

Yes. USDC is Arc’s native gas asset. Its native-value interface uses 18-decimal precision, while the ERC-20 interface uses 6 decimals. These interfaces expose the same underlying balance, so protocols and indexers must convert units correctly and avoid presenting or accounting for two separate USDC balances.

What should I test before deploying a smart contract on Arc Mainnet?#

At minimum, test native and ERC-20 USDC accounting, precision conversion, transfer failures, blocklist-related reverts, SELFDESTRUCT assumptions, PREVRANDAO usage, USDC event indexing, timestamp handling, oracle freshness, cross-chain message retries, payout reentrancy, Memo and Multicall3From behavior, and keeper fee handling. Use Arc-aware tooling and verify current network configuration against the official docs.

Do I need a smart contract audit before launching on Arc?#

Arc-specific developer tools can help catch implementation issues, but they do not prove that a protocol is secure. An independent smart contract security audit should review both general vulnerabilities in the protocol’s logic and assumptions that are specific to Arc, including USDC accounting, transfer semantics, integrations, and offchain components.

What makes Arc Chain security different from Ethereum security?#

The most important differences for application developers include USDC serving as the native gas asset, native and ERC-20 USDC using different decimal scales, specific native-value transfer restrictions, system-level USDC transfer events, CallFrom-based Memo and Multicall3From routing, deterministic finality, repeated block timestamps, and documented opcode behavior such as PREVRANDAO returning zero. The current Arc EVM differences reference should be checked during implementation and before deployment.

Can I deploy a DEX, AMM, or staking protocol on Arc without changing Solidity code?#

Some contracts may deploy without source changes, but the whole application still needs an integration review. DEX and AMM pools, staking systems, DAO tooling, indexers, keepers, bridges, and frontends can depend on assumptions about native USDC, EVM execution, and event behavior even when the Solidity contract compiles successfully. Review every component that reads balances, sends value, calculates prices, or reconciles transactions.

How should an indexer credit USDC deposits on Arc?#

Credit from the system emitter, which is the canonical record of explicit USDC transfers on current mainnet, and only after a successful receipt. Key each movement by (chainId, txHash, systemLogIndex). The companion ERC-20 Transfer log can cross-check the interface used, but it must not create a second credit. Use the log’s actual sender, recipient, and 18-decimal amount rather than the transaction’s from or tx.value.

Does a finalized Arc transaction mean the payment succeeded?#

No. Finality establishes the block’s status under Arc’s validator consensus. It does not establish that an included call succeeded, that a downstream CCTP, Gateway, or StableFX step completed, or that a later transaction will be included. Track submission, rejection without a receipt, inclusion with a revert, and inclusion with the expected effect as separate states, and advance an order only on the last one.

Need an Arc smart contract audit? Let’s talk.#

Arc gives developers familiar EVM tooling and a stablecoin-native environment, but those advantages do not remove the need to review protocol accounting, integration assumptions, and failure paths before deployment.

At Parapet Labs, we help Web3 teams identify vulnerabilities in smart contracts and protocol logic before they put user funds at risk. If you are building a DEX, AMM, staking or restaking system, DAO, or stablecoin application on Arc, migrating an EVM dApp, or preparing an Arc Mainnet launch, an independent review can test chain-specific assumptions alongside the protocol’s core logic. Explore our smart contract audit services or learn what a smart contract audit covers.

Building on Arc? Talk to Parapet Labs.

Primary documentation#

Use these primary sources to confirm current behavior, supported integrations, and deployed addresses before shipping.

Arc EVM differences - native USDC, value-transfer rules, opcodes, events, fee market, and block behavior.
Stablecoin-native model - how native and ERC-20 USDC interfaces share one balance.
Port a contract to Arc - practical porting checks and Arc-aware testing.
USDC system events - event emitters, precision, and duplicate-event considerations.
Index Arc events - indexing walkthrough for USDC, CCTP, and other events.
Deterministic finality - transaction finality and settlement behavior.
Gas and fees - fee parameters and transaction submission guidance.
Connect to Arc - network configuration, chain ID, RPC endpoints, and explorer.
Arc security resources - developer tooling, support programs, and vulnerability reporting.
Chainlink Data Feeds and Chainlink CCIP - provider documentation for oracle and cross-chain integrations.

Documentation checked on October 27, 2026. Arc and third-party integrations can change; recheck network parameters, contracts, feed addresses, and supported routes at implementation and deployment time.