Building Financial Applications on Arc: Four Things That Work Differently

Quicknode

October 8, 2026 — 6 min read

Share

Add as preferred source

Arc is designed for applications that move real-world value. It keeps the EVM execution environment, so existing Solidity contracts and familiar Ethereum tooling remain useful, while moving fees, settlement, and other financial requirements into the network itself.

Those choices change the systems around the contract. Two of the four differences below are live on Arc today; the other two are roadmap items and should be read as direction, not capability.

1. USDC as gas

A stablecoin application often needs two assets to complete one action: the stablecoin being moved and a separate token to pay for execution. That creates another balance to fund, another asset to price, and another failure mode when a user has money but not enough gas.

Arc removes that split by making USDC its native gas asset. Transaction fees and application value share the same unit of account, so users can transact without acquiring a separate gas token. Treasury and accounting systems can also record the transfer and its execution cost in dollars without introducing another price-conversion step. Arc's fee design smooths changes in network demand to make costs easier to estimate, while standard fee RPC methods let applications read current values at runtime.

One integration detail is worth designing around. Native USDC uses 18 decimals for gas and EVM value transfers, while its ERC-20 interface uses the familiar 6-decimal USDC representation. They are two views of the same balance, not two assets. Wallets and ledgers therefore need to normalize the views rather than display or total both. Indexers need the same discipline because ERC-20 activity can produce both a native system event and an interface event for one movement, while native sends produce only the system event. A mainnet example in our Arc USDC indexing guide shows four transfer-shaped logs for two actual USDC movements. The takeaway: Arc removes the separate gas asset, not the need for one canonical view of USDC.

2. Deterministic finality

On many networks, seeing a transaction in a block does not mean an application can safely treat it as settled. Services wait for more confirmations, keep recent activity provisional, and retain rollback paths in case the chain reorganizes.

Arc's Malachite BFT consensus removes that intermediate state. A transaction is either unconfirmed or final, and a committed block cannot be reorganized. Applications can act when the block commits instead of translating confirmation depth into a confidence score.

That simplifies workflows that begin somewhere else after an onchain result: updating a ledger, releasing inventory, notifying another service, or starting the next transaction. Confirmation thresholds and reorg rollback logic can leave the application state machine. Arc documents irreversible settlement in under one second as a network design property, not a measured production service-level agreement, so teams should still measure the complete path their users experience.

Finality does not replace operational reliability. Connections fail, consumers restart, deliveries retry, and databases time out. Durable ingestion, idempotent writes, replay-safe effects, and reconciliation remain essential. Arc makes the chain's answer final. The application still has to process that answer reliably.

3. Privacy as a separate execution model

Financial applications often need confidentiality without moving activity into a disconnected system. Transaction terms, balances, positions, or counterparties may require controlled disclosure, while the resulting value movement still needs to compose with public onchain activity.

Arc Privacy Sector (APS) is Arc's planned answer. It is on the roadmap and is not yet available, so it should inform future architecture rather than current product promises.

APS is designed as a confidential execution environment for Solidity contracts alongside the public EVM. Public and private states would be committed in the same block, allowing contracts in both environments to interact atomically. A workflow could keep a sensitive state private while settling a related public effect without relying on a separate bridge or delayed messaging layer.

The privacy boundary would be explicit. Functions, storage, and events are hidden by default, and applications decide what can be exposed and which contracts can interact. This makes confidentiality part of execution design rather than a layer that attempts to obscure public data after it has already been produced. APS is not available today, but its intended advantage is clear: privacy without giving up Solidity or atomic composition.

4. Post-quantum wallet signatures

The signature schemes protecting wallets today may not remain secure against sufficiently capable quantum computers. For applications that hold long-lived value, preparing for that possibility is a migration problem, not a last-minute software update.

Arc's post-quantum roadmap begins with beta, opt-in support for SLH-DSA-SHA2-128s wallet signatures at mainnet. A wallet that opts in can use the new scheme to authorize transactions. That protection applies to the wallet. It does not extend to validator signatures or make Arc consensus post-quantum.

Protocol support is only the first step. Hardware wallets, signing services, SDKs, custody policies, recovery systems, and transaction tooling all need to handle the scheme correctly. Standards are still evolving, so Arc expects adoption to happen through a transition rather than an immediate switch.

The roadmap expands protection in stages. Post-quantum encryption for private execution and upgrades to offchain infrastructure follow the wallet work, while validator signatures remain a long-term item. The practical value of the beta is therefore specific: it gives participating wallets an early path to test and adopt a post-quantum authorization scheme without overstating the protection available across the rest of the network.

From network design to application behavior

These differences share one purpose. Arc is moving recurring financial requirements closer to the network: a stable unit for value and fees, a clear settlement boundary, a path to confidential execution, and a way to evolve wallet authorization. EVM compatibility lets developers use that foundation without abandoning the contracts and tools they already know.

Applications still need correct accounting, reliable data pipelines, deliberate access controls, and secure wallet infrastructure. Arc changes the foundation beneath those systems, removing some familiar complications and introducing new boundaries that need to be understood precisely.

Quicknode supports Arc through JSON-RPC and WSS endpoints, full archive access with debug and trace namespaces, WebSocket subscriptions, Webhooks, and Streams. Start building on Arc with Quicknode today.