Arc Blockchain Development: Architecture, Tools, and Tech Stack

Arc blockchain development combines familiar EVM development with an architecture built around stablecoin-based applications. Developers can use Solidity and established Ethereum tools, while Arc uses Malachite for consensus and a Reth-based execution layer with Revm for EVM execution.

If you already understand what Arc blockchain is, the next step is understanding how its architecture affects development. Arc introduces key differences in native USDC, gas fees, transaction handling, and chain-specific behavior that developers must account for.

USDC serves as Arc’s native gas asset, while Circle infrastructure adds services for wallets, cross-chain transfers, unified liquidity, and application integration. Production development therefore requires the right EVM tools alongside Arc-specific testing and deployment practices.

How Arc's Development Architecture Works

Arc's architecture is easier to understand as two cooperating layers than as one monolithic chain.

Arc as an Independent Layer 1

Arc is an independent Layer 1 with its own consensus infrastructure and an EVM execution environment. Validators are permissioned today, and the public mainnet has been live since September 16, 2026.

Consensus Layer: Malachite BFT

Malachite is Arc's consensus engine, and it uses a Byzantine fault-tolerant design to agree on blocks. Once a block is finalized, it will not be reorganized, which gives applications deterministic finality within a second.

On probabilistic chains, developers wait through several confirmations before treating a payment as safe to act on. Deterministic finality removes that waiting period, which matters for payments, treasury operations, and other financial applications.

Execution Layer: Reth and Revm

Arc's execution client is built on Reth, which processes transactions and maintains the full blockchain state. Revm provides the core EVM implementation through the Reth SDK, so bytecode runs the way Solidity developers expect.

The Arc Reth client extends this base with custom EVM behavior, gas logic, transaction validation rules, and network-specific precompiles. Saying that Arc simply uses the EVM hides this detail, and the detail matters when something behaves unexpectedly.

How Consensus and Execution Communicate

A transaction enters the pool, gets included in a proposed block, and passes through Malachite consensus. Reth then executes the block, updates state, and the result is finalized for every node on the network.

Arc keeps the two layers separate and connects them through the Ethereum Engine API, the same interface Ethereum clients use. The Arc node architecture documentation on GitHub describes this split in more detail for node operators.

Arc's EVM Development Environment

Arc provides an Ethereum-compatible EVM environment, allowing developers to use familiar Solidity tools, libraries, wallets, and development workflows.

Solidity and Ethereum-Compatible Development

Arc Solidity development uses the same compiler, the same contract patterns, and the same wallet interactions as Ethereum. Arc's compatibility guide confirms that existing EVM teams can keep most of their familiar workflows, including these:

• Solidity contracts: You write, compile, and deploy contracts in Solidity exactly as you would for any other EVM network.
• Address format: Accounts use Ethereum-style addresses, so existing address validation and display logic keeps working without changes.
• JSON-RPC access: Applications talk to the network through standard JSON-RPC methods, which every major client library already supports.
• ABI interaction: Contract calls rely on ABI definitions, so generated bindings and typed clients carry over from Ethereum projects.
• Signing scheme: Transactions use secp256k1 signatures, which means common hardware and software wallets can sign for Arc accounts.
• Fee model: Arc follows EIP-1559 transaction patterns, so fee estimation code written for Ethereum needs only small adjustments.

If you want a refresher on how contracts are compiled, deployed, and executed, check how smart contracts work.

What Existing Ethereum Projects Can Reuse

Teams moving to Arc can often reuse or port their existing code with limited changes rather than rewriting. Solidity contracts, contract libraries, ABI definitions, and deployment scripts usually transfer with only configuration edits.

Frontend architecture, wallet integration patterns, and RPC clients also carry over because Arc speaks the same protocol. Most importantly, the EVM knowledge your developers already have remains useful, which shortens onboarding for Arc smart contract development.

Where Arc Differs From Standard EVM Chains

Arc EVM compatibility is broad, but native value behaves differently, and that difference touches many contracts and indexers. The native asset is USDC rather than ETH, and Arc applies its own rules to native value transfers.

Native USDC uses an 18-decimal representation, while the ERC-20 interface for the same balance uses 6 decimals. Arc also emits its own transfer events for native movements, which changes how indexers must read the chain.

Arc's documentation warns that a standard ERC-20-only indexer can miss native transfers or double-count transactions. Contracts that assume native value behaves like ETH, plus chain-specific addresses and integrations, also need a careful review.

How USDC Works as Native Gas on Arc

Arc USDC gas changes application design more than any other feature, so it deserves careful attention.

Paying Transaction Fees in USDC

Every transaction on Arc requires gas fees, which are denominated and paid in USDC rather than ETH. This means users and applications do not need to maintain a separate volatile asset solely to cover transaction costs, simplifying fee management across Arc-based applications.

Because USDC holds a stable value, one source of dollar cost uncertainty disappears from fee planning and budgeting. That said, fees are not permanently fixed, and applications should still estimate gas before every transaction.

Arc's Gas Market

Arc uses an EIP-1559-inspired fee model, so a base fee moves in response to network demand. The network applies fee smoothing, which reduces sudden jumps but does not eliminate variation between blocks. Predictable fees are not identical fees, so budget for a range rather than a single hard-coded number.

One USDC Balance, Two Interfaces

Arc links one underlying USDC balance to two interfaces, and understanding both prevents a whole class of bugs.

• Native USDC: This interface carries native value, pays transaction fees, and represents balances with 18 decimal places.
• ERC-20 USDC: This is the standard token contract interface, used for ERC-20 interactions, and it reports 6 decimals.
• Shared balance: Both interfaces read and write the same underlying USDC, so a transfer through one changes the other.

Common USDC Integration Mistakes

Most Arc integration bugs come from treating USDC like ETH or like a plain ERC-20 token, not both.

• Decimal mixing: Combining 6 decimal and 18 decimal values in one calculation produces balances off by a factor of one trillion.
• ETH assumptions: Assuming native USDC behaves exactly like ETH ignores Arc's own transfer rules and its custom event model.
• Double counting: Indexers that record both the native event and the ERC-20 event for one transfer inflate every total.
• Separate assets: Treating native and ERC-20 USDC as two different assets leads to phantom balances and broken accounting.
• Display errors: Frontends that format 18-decimal native values with 6 decimal logic show users nonsense numbers.
• Transfer failures: Native value transfers can fail for Arc-specific reasons, so handle reverts instead of assuming success.

Arc Blockchain Development Tech Stack

The Arc blockchain tech stack combines familiar EVM tools with Circle services, and this table maps each layer.

For deeper coverage of Foundry, Hardhat, OpenZeppelin, security tooling, and verification, see our full breakdown of smart contract development tools.

Core Development Tools for Building on Arc

Arc blockchain development tools are mostly the tools Ethereum developers already know, with one important Arc-specific addition.

Foundry

Foundry compiles Solidity quickly and lets you write tests in Solidity itself instead of switching to JavaScript. It supports fuzz tests that throw random inputs at functions and invariant tests that check properties across sequences. Deployment scripting, detailed traces, and step-by-step debugging round out the toolkit for most contract work.

Arc Foundry

Arc Foundry is a modified distribution of Foundry that reproduces Arc's network behavior in your local environment. Arc's compatibility documentation recommends it, and the package ships three tools named arc-forge, arc-cast, and arc-anvil.

Standard Anvil and other generic local EVMs do not include Arc's precompiles, transfer events, or blocklist enforcement. Tests that pass on plain Anvil can therefore fail on Arc, which is exactly the gap Arc Foundry closes.

Hardhat

Hardhat suits teams that prefer JavaScript or TypeScript for their compilation, testing, and deployment workflows. An Arc Hardhat setup mainly involves adding the network's RPC endpoint and chain ID to the configuration file. From there, the usual plugins handle testing, deployment automation, and contract verification against Arc's explorer.

OpenZeppelin Contracts

OpenZeppelin provides audited implementations of token standards, access control, ownership patterns, and upgradeable proxies for Solidity projects. Using these libraries on Arc works the same as anywhere else, since the contracts compile to standard EVM bytecode.

viem and ethers.js

viem and ethers.js sit at the application layer and handle everything between your interface and the chain. They perform reads, submit writes, encode contract calls, connect to wallets, and manage RPC communication with Arc nodes. Both libraries treat Arc as another EVM chain, so you add a chain definition and keep your existing code.

Arc Studio

Arc Studio is an onchain coding agent that launched alongside Arc mainnet to generate deployment-ready application code. It can produce smart contracts, frontend screens, backend logic, and Circle integrations from a plain language description. Generated code still needs human review, security testing, and a proper audit before it handles real user funds.

Circle Infrastructure Available to Arc Developers

You can build on Arc with standard EVM infrastructure alone, but Circle's wider stack adds ready-made financial components. Circle currently presents Wallets, Contracts, Gateway, CCTP, App Kits, and Arc itself as one connected set of Circle developer tools.

Circle Wallets

Circle Wallets provide embedded wallet and account infrastructure, so applications can create accounts without asking users to install extensions. They also handle transaction signing, which simplifies Circle Arc development for teams building consumer-facing payment products.

Circle Contracts

Circle Contracts offers reusable contract templates and deployment infrastructure for common token and asset patterns. Teams that need a standard token quickly can deploy from a template instead of writing and auditing from scratch.

Arc App Kits

Arc App Kits are SDKs that package common financial flows, so you integrate one kit instead of several providers. Current kits cover sending, bridging, swapping, unified balances, onramping, and yield, though support varies by kit. Check each kit's documentation before committing, because coverage is expanding and some flows are newer than others.

Onramp Kit

Onramp Kit, released on September 24, 2026, handles fiat-to-USDC funding inside your application.

• Hosted widget: A prebuilt funding screen drops into your interface, so you avoid building payment forms yourself.
• TypeScript SDK: The SDK exposes the funding flow programmatically for teams that want tighter control over the experience.
• Embedded verification: Identity verification runs inside the flow, which removes a separate compliance integration from your roadmap.
• Lifecycle events: Funding events fire at each stage, so your backend can track deposits from start to settlement.

Arc Interoperability and Cross-Chain Development

Interop on Arc went live on September 23, 2026, and it connects Arc to other networks through Circle's protocols.

CCTP

CCTP is the underlying protocol for moving native USDC between chains without wrapped tokens or liquidity pools. The flow is simple: USDC burns on the source chain, an attestation is issued, and USDC mints on the destination. An Arc CCTP integration therefore deals with real USDC on both sides, which simplifies accounting for cross-chain apps.

Bridge Kit

Bridge Kit wraps the CCTP workflow into a higher-level SDK, so developers call one function instead of coordinating steps. It handles the burn, waits for attestation, and completes the mint while surfacing status updates to your application.

Circle Gateway

Circle Gateway gives applications a unified USDC balance that can be spent across supported chains without manual bridging. This chain abstraction reduces the liquidity rebalancing work that treasury and payment teams usually handle by hand. For an Arc Gateway setup, your application sees one balance while Circle routes liquidity behind the scenes.

Forwarding Service

The Forwarding Service relays destination chain transactions so users do not need to hold gas on the destination. That removes one of the most common points of failure in cross-chain user experiences, an empty gas balance.

How the Interop Stack Fits Together

Most applications call Bridge Kit, which then uses CCTP, Gateway, or the Forwarding Service depending on the request.

The official Arc developer documentation explains the supported networks and the exact API surface for each interop component.

RPCs, Nodes, Wallets, and Developer Infrastructure

Arc blockchain RPC access, node options, and infrastructure providers look much like the Ethereum ecosystem, just younger.

JSON-RPC Access

Arc exposes the standard Ethereum JSON-RPC interface, which is effectively the Arc blockchain API for most applications. Developers can use hosted RPC endpoints, WebSocket connections for subscriptions, or their own Arc nodes for full control.

Running an Arc Node

Anyone can run a full Arc node, even though validator participation remains permissioned for now. A node consists of the execution layer and the consensus layer running together on the same machine.

• Independent verification: Your node checks every block itself rather than trusting a third party's view of the chain.
• Local execution: Transactions and simulations run locally, which is useful for debugging and for latency-sensitive workloads.
• Direct RPC: You get a private RPC endpoint with no rate limits imposed by an outside provider on your traffic.
• Own state: Your application reads chain state from infrastructure you control, which supports compliance and uptime requirements.

Setup details live in the arc-node repository, and they change often enough that a tutorial here would age quickly.

Infrastructure Providers

Circle names Alchemy, QuickNode, and Blockdaemon among the infrastructure providers supporting Arc's mainnet ecosystem at launch. Using a provider means you skip node operations, but you should still keep a fallback endpoint for outages.

Oracles, Indexing, and Monitoring

Production applications also need oracle and data feeds, indexing, analytics, transaction simulation, security monitoring, and block explorers. Chainlink is among the named providers, giving contracts access to price and other external data. Indexers turn raw events into queryable data, but they must understand Arc's native transfer events to stay accurate.

Testing Smart Contracts and Applications on Arc

Testing Arc smart contracts follows the usual EVM playbook, with an extra layer for Arc's own behavior.

Local Contract Testing

Start with unit tests for individual functions and integration tests for how contracts interact. Add fuzz tests for unexpected inputs and invariant tests for properties that must hold no matter what happens. Our separate article on smart contract testing walks through each of these methods in depth.

Test Arc-Specific Behavior

Arc-specific differences can affect otherwise working Ethereum code, so test these behaviors directly rather than relying only on standard EVM compatibility.

• USDC transfers: Test both native USDC and ERC-20 USDC transfers, including the specific events each one emits.
• Decimal conversion: Verify every place your code converts between 18-decimal native values and 6-decimal token values.
• Payable functions: Confirm that payable functions receive native USDC correctly and reject amounts that violate your business rules.
• Blocklist failures: Simulate transfers involving blocklisted addresses so your application handles those reverts gracefully instead of crashing.
• Chain addresses: Check that every hard-coded contract address points to the correct Arc deployment, not another chain.
• RPC behavior: Exercise your RPC layer against a real Arc endpoint, since response details can differ from Ethereum.
• Cross-chain: Run CCTP and Gateway integrations end-to-end on testnet before trusting them with mainnet funds.
• Finality assumptions: Make sure your code relies on Arc's deterministic finality rather than counting confirmations the Ethereum way.

Arc Testnet Validation

Before mainnet, run the complete transaction flow on Arc testnet with real wallets and real Circle services. Validate contracts, USDC handling, frontend behavior, and backend processing together, because problems often appear only at the seams.

Security Considerations for Arc Development

Arc development requires both standard smart contract security and careful handling of Arc-specific integrations.

Smart Contract Security

The classic risks still apply on Arc: weak access control, reentrancy, unsafe external calls, and bad signature handling. Upgrade mechanisms, permission structures, and token handling code deserve the same scrutiny they would receive on Ethereum. Our overview of blockchain security best practices covers these fundamentals for teams that want a broader checklist.

Arc-Specific Integration Risks

Arc's native and ERC-20 USDC model creates risks that a standard Ethereum audit checklist will not catch. Decimal conversion errors, event indexing mistakes, and wrong assumptions about native value can all leak or lock funds. Custom precompiles and third-party contract addresses add further surface area, so verify each one against official sources.

Cross Chain Security

Cross-chain code inherits the assumptions of every bridge and protocol it touches, so document those assumptions explicitly. Validate CCTP messages and attestations properly, treat external contracts as untrusted, and design for partial failures mid-transfer.

Key and Infrastructure Security

Deployer keys and admin permissions should live behind multisigs, never in a single developer's environment file. Protect API secrets, limit RPC exposure to what your application needs, and monitor privileged actions continuously.

From Development to Arc Mainnet

Moving an application to Arc involves several stages, from development and testing through production deployment.

Build

Write and organize your contracts in Solidity, then use Foundry or Hardhat to compile and manage the project. Reusable libraries such as OpenZeppelin can provide established contract components and reduce the need to build common functionality from scratch.

Integrate

Add the wallet layer, USDC handling logic, and your frontend and backend services around the contracts. Bring in Circle infrastructure and interoperability components only where the application needs them, not by default.

Test

Start with local unit and integration tests, then run Arc-specific tests with Arc Foundry. Test key transaction flows, contract interactions, and failure cases before moving to testnet, where you can validate the complete application in an environment closer to production.

Deploy

Configure production RPC endpoints, finalize deployment scripts, and record every network address in version control. Set admin permissions deliberately, then verify contract source on the explorer so users can inspect what they use.

Monitor After Deployment

Watch for transaction failures, unexpected contract events, balance drift, privileged actions, RPC outages, and cross-chain delays. Teams without in-house blockchain operations often pair with blockchain development services that handle smart contracts, dApps, and ongoing support.

Recommended Arc Tech Stack by Application Type

These example stacks show practical starting points for common Arc-based applications.

These stacks are starting points, not mandatory configurations. Teams can adjust components based on their requirements and existing expertise. Tokenized asset platforms can combine OpenZeppelin token standards with Circle Contracts, following the principles behind real-world asset tokenization. For agentic applications, Circle Agent Stack is chain- and protocol-agnostic infrastructure rather than part of Arc’s core.

When Is Arc a Good Fit for a Blockchain Project?

Building on Arc blockchain makes the most sense when stablecoins, fast finality, or Circle services sit at the center of your product.

Stablecoin-Native Applications

If USDC payments and settlement are central to your product, Arc’s native gas and balance model can reduce friction around transaction costs and settlement. This makes it suitable for applications where stablecoin transactions are a core part of everyday operations.

Teams Already Using Solidity

Arc’s EVM compatibility allows existing Solidity teams to build and deploy without learning an entirely new programming environment. Teams can reuse familiar development tools, workflows, and much of their existing smart contract expertise when moving applications to Arc.

Applications That Need Fast Finality

Payments, trading, treasury, FX, and settlement workflows can benefit when transactions reach finality within about a second. Deterministic settlement allows these systems to release funds, update records, or complete financial operations without waiting through multiple confirmation stages.

Cross-Chain USDC Applications

CCTP, Gateway, and Arc Interop make Arc well-suited to applications that move USDC across multiple networks. Projects with cross-chain payment, liquidity, or settlement requirements can use these Circle infrastructure components to connect Arc with a broader stablecoin ecosystem.

Applications Already Using Circle Infrastructure

Teams already using Circle Wallets, USDC, CCTP, Gateway, or Circle Contracts may find Arc easier to integrate into their existing infrastructure. However, Arc is not automatically the right chain for every Web3 project, so teams should compare its architecture, costs, ecosystem, and requirements before committing.

What's Live on Arc Today vs What's on the Roadmap?

Arc already has its core network and developer infrastructure live, while several planned capabilities remain part of its longer-term development. The table below separates currently available features from roadmap items to give builders a clearer view of what they can use today.

The distinction is important when evaluating Arc for a production project. Features marked Live represent the current network and tooling, while roadmap and future items should not be treated as available capabilities. Circle may update these plans as Arc develops, so verify the latest official status before making architecture or deployment decisions.

Conclusion

Arc blockchain development combines a familiar EVM stack with Arc and Circle-specific infrastructure that most chains lack. On the familiar side, you have Solidity, Foundry or Hardhat, viem or ethers.js, and standard JSON-RPC access. On the Arc side, you have Malachite, Reth, USDC native gas, CCTP, Gateway, App Kits, and Arc Studio.

The right Arc developer stack depends on whether you build payments, tokenization, treasury, DeFi, cross-chain settlement, or agentic finance. Start with familiar tools, add Arc-specific testing early, and bring in Circle services only where they earn their place.