Porting Contracts to Arc: Native Value Rules and Key Implementation Differences

Arc keeps the EVM development model familiar for smart contract teams. The part that deserves closer attention is native value, because it affects msg.value, transfers, and a few runtime behaviors in ways Ethereum does not.

Arc is EVM-compatible, so contract structure, tooling, signing, and deployment all stay familiar. Existing contracts can usually deploy unchanged. The important differences start where native value is involved: USDC is the native asset, msg.value represents USDC, and native transfers follow rules that do not exist on a standard EVM chain.

This article focuses on those differences: how native value works on Arc, why some transfers can still revert, what changes around SELFDESTRUCT, and which DeFi or treasury assumptions are worth reviewing before mainnet.

What stays familiar for EVM developers on Arc

You will still write Solidity. You will still use Foundry, Hardhat, viem, and ethers. Standard contract deployment patterns still work. In many cases, an existing contract will compile, deploy, and run without structural changes.

That narrows the review surface. Contract teams do not need to treat Arc like a new virtual machine. They need to isolate the places where execution semantics diverge and focus there.

Review every path that uses native value

The first review step is to find every place your contracts depend on native value.

That includes:

• msg.value
• low-level call{value: ...}
• contract endowments
• payout paths
• settlement logic
• treasury distribution logic
• any path that assumes a native send succeeds if balance is sufficient

On Arc, native value is USDC. The native representation uses 18 decimals, and it is the same underlying asset exposed through the ERC-20 USDC interface. That is why contract review on Arc should start with native USDC code paths such as msg.value, native sends, and value-forwarding logic, rather than treating USDC only as a standard ERC-20 integration.

If a protocol already uses USDC heavily, this can look familiar at first. The important difference is that the same asset now sits behind gas, native sends, and msg.value.

When native USDC transfers can revert on Arc

On Ethereum, many teams carry a simple mental shortcut: if an address has enough native balance, a native transfer should succeed.

That assumption cannot be made on Arc.

Because native value is USDC, value transfers are subject to rules that do not exist on a standard EVM chain. A native transfer can still revert even when the sender has enough balance. The main cases Arc calls out are:

• transfers to the zero address; USDC sends to the zero address are considered burns, and only certain actors can burn USDC
• transfers to or from a blocklisted address; native USDC movement inherits the same blocklist restrictions.
• transfers to a self-destructed account; SELFDESTRUCT is the only way native USDC can be burned. A non-zero native send to an account that has already self-destructed reverts because it would otherwise burn the value

This matters most in protocols that forward value internally. A router, vault, distributor, or settlement contract may not be trying to do anything unusual, but a send that looks routine on Ethereum can still fail on Arc if it hits one of these rules.

That is why contract review on Arc should not stop at balance checks. Teams need to review the destination assumptions behind every non-zero native send.

Treat the zero address, the blocklist, and burn protection as runtime rules

These rules are easiest to reason about if you treat them as execution constraints, not edge cases.

On Arc:

• a value-bearing transfer to 0x0 reverts
• a non-zero native send to an account that has already self-destructed reverts
• a transfer involving a blocklisted address reverts at runtime

For DeFi and treasury code, this changes the safety profile of a few common patterns.

A contract that uses the zero address as a placeholder beneficiary needs review. A payout path that assumes an invalid destination will only fail in application logic needs review. A protocol that forwards native value through multiple hops should be tested against blocklist and destination failures, not only the happy path.

This is also why withdrawal, redemption, and settlement paths deserve explicit Arc coverage in tests. The transfer itself may be the thing that fails, even when the surrounding business logic is correct.

Understand what SELFDESTRUCT does differently on Arc

SELFDESTRUCT is one of the clearest places where Arc diverges from Ethereum in a way that matters for contracts.

Arc follows EIP-6780, but the value-transfer side of SELFDESTRUCT behaves differently because a contract's USDC is its native balance.

That means a successful self-destruct that moves value actually moves the contract's USDC balance. On Ethereum, an ERC-20 USDC balance lives in the token contract and is unaffected by account destruction. On Arc, the native balance sits on the account itself.

Arc also applies native value rules to SELFDESTRUCT. A self-destruct reverts when its value transfer would violate those rules, including cases where:

• the beneficiary is the contract itself and the balance is non-zero
• the beneficiary is the zero address and the balance is non-zero
• the source or beneficiary is blocklisted
• the beneficiary has already self-destructed

For contract teams, this means SELFDESTRUCT deserves review in cleanup paths, factory patterns, settlement flows, and inherited dependencies.

Review non-zero-value calls to destructed accounts

On Ethereum, teams may assume that sending value to an address that self-destructed earlier in the same transaction still succeeds. On Arc, that is treated as a forbidden burn.

Most teams will not run into this in the main flow of a protocol. It is more likely to appear in cleanup, migration, or teardown logic such as:

• factory cleanup
• upgrade or migration flows
• same-transaction lifecycle patterns
• settlement logic that sends value after teardown

A contract can look correct in a standard local EVM test and still fail on Arc if one of those flows sends non-zero native value to an account that has already been destroyed.

Review protocol assumptions, not just functions

Porting risk rarely lives in one line of code. It usually lives in a repeated system assumption.

On Arc, contract teams should review a few assumptions that often appear in ported systems:

• native USDC and ERC-20 USDC are not separate assets
• should not pass raw 6-decimal amounts into native-value fields, and raw 18-decimal amounts into ERC-20 calls
• native transfers are not always safe whenever balance is sufficient
• ERC-20 transfers are not the only way USDC enters a contract

This is especially important for AMMs, vaults, routers, treasury modules, and settlement systems. 

• A pool that pairs native USDC against ERC-20 USDC is meaningless on Arc because they are the same asset. 
• A contract that accounts based on both balance and balanceOf as if they represented different holdings needs review. 
• A treasury path that assumes native sends and ERC-20 transfers are interchangeable without conversion also needs review.

Test Arc-specific behavior against an Arc RPC endpoint

Standard local EVM tests are still useful, but they do not confirm Arc-specific behavior such as native USDC value rules, blocklist enforcement, EIP-7708 transfer logs, or Arc’s SELFDESTRUCT behavior.

Contract teams should run targeted tests against an Arc RPC endpoint for:

• non-zero native sends
• value-forwarding calls
• blocklist-sensitive flows
• self-destruct paths
• same-transaction destruction and send patterns
• any logic that mixes native 18-decimal amounts with ERC-20 6-decimal amounts

Where to go next

• For teams moving from review into implementation, the next step is to work through Arc's guides for DeFi integration, AMMs and pools, the stablecoin native model, and the full EVM differences reference.

• Explore open-source Arc apps built with Circle developer tools, from payments and FX to DeFi, wallets, and treasury flows.