Title: [Network Technical Assessment] Aave <> Arc
Author: Aave Labs
Date: 2026-09-14
Preliminary assessment status. Aave Labs had access to Arc and was able to perform this analysis before its public mainnet availability. A follow-up post will clarify should any statement in this assessment differ from conditions observed after public mainnet availability. Arc was in a private mainnet phase when assessed, before its announced public mainnet availability on 16 September 2026, and public access to the RPC, explorer, Alchemy, and Tenderly services remained gated.
Objective and independence of this assessment
This is an independent assessment of the technical components Aave Labs considers material for Aave software to run optimally on a candidate network, not a categorical judgment that Arc is good or bad, and not a requirement for Aave to deploy on Arc. That decision rests with Aave governance, independent of the views expressed here. Circle’s team was an important source of information throughout this assessment and was consistently forthcoming and supportive; everything in this report nonetheless reflects Aave Labs’ own independent criteria exclusively.
1. Introduction to Arc
| Field | Value |
|---|---|
| Network | Arc |
| Network operator | Circle |
| Network type | Permissioned proof of authority Layer 1 |
| Chain ID | 5042 |
| Target market | Aave, contracts targeting Cancun (all versions) |
Arc pairs a Byzantine Fault Tolerant consensus engine, a design that keeps the network in agreement even if some participants act dishonestly, with a standard, Ethereum compatible environment for running smart contracts. Committed blocks are final, with no reorganization risk. Consensus is run by a permissioned set of vetted institutions, while operating a non-validating full node is open to anyone. USDC is the network’s native gas asset: its native and ERC-20 forms are the same asset, sharing balances, with blacklist and freeze operations performed at the protocol level. Arc is a standalone Layer 1: it does not post data to Ethereum and has no external data availability layer.
2. Methodology
Each category in Section 3 is assessed with a simplified rating: ★★★ Strong, fully meets requirements or exceeds them; ★★☆ Acceptable, meets requirements with caveats; ★☆☆ Concern, meaningful gaps, missing data, or limited validation. Because Arc operates as a permissioned Layer 1 rather than a rollup, the criteria applied are the equivalent Layer 1 level checks (see Section 3.16), not the rollup specific assumptions the framework otherwise defaults to.
3. Evaluation
3.1 Oracles
Reliable oracle infrastructure is a baseline requirement for Aave on any network.
Chainlink publishes 28 Data Feeds for Arc mainnet, and each one verified live onchain within its published heartbeat, covering USDC, USDT, ETH, BTC, cbBTC, AAVE, LINK, EURC, PAXG, a set of forex pairs, and rate feeds for yield bearing assets. An AAVE Network Emergency Count feed, the emergency mode oracle Aave’s Guardian mechanism consumes, was also confirmed live. Arc is a Layer 1 with no rollup sequencer, so a Chainlink sequencer uptime feed is not applicable; the equivalent liveness risk is a validator coalition holding more than one third of voting power stalling the chain (see Section 3.15). A proof of reserve feed, cirBTC Reserves (0xEB0884a871ea1f6483B5FC10fd3D7dC5806411fc), exists for cirBTC, a wrapped Bitcoin asset; no proof of reserve feed exists for other backed or wrapped assets on Arc.
Rating: ★★★ Strong
3.2 Blockchain Explorer
Aave operations require a usable explorer environment after deployment.
A mainnet block explorer was confirmed functional during this assessment. Aave Labs was granted access, and the explorer is expected to be made public at launch. The public test network explorer, testnet.arcscan.app, is live and source verified.
Rating: ★★★ Strong
3.3 RPC Standard Compatibility
Aave relies on standard Ethereum RPC behavior across deployment, monitoring, and ongoing operations.
Arc’s RPC layer is served by reth, and standard eth/web3/net JSON-RPC calls behave normally, including eth_getStorageAt proxy slot reads. Two RPC methods, eth_createAccessList and txpool_status, are not yet supported on the assessed endpoint, and the default gas cap on eth_call simulations has been lowered, which can affect very large simulated transactions; the trace_ and debug_ method namespaces both work, including full call tracing.
Rating: ★★★ Strong
3.4 Account Format Compatibility
Compatibility with Ethereum’s address, key, and execution model helps preserve the assumptions built into Aave contracts, wallets, and operational workflows.
Account and address formats are standard secp256k1 keys and twenty byte addresses, with no transformation that would affect wallets or other tooling. Arc does not enforce EIP-55 checksum casing at the protocol or node level, and a checksummed address submitted as input resolves to the same twenty byte address as its lowercase equivalent. Since node version v0.7.0, Arc’s own logs, metrics, and JSON-RPC responses intentionally render addresses in lowercase hex rather than checksummed form, a display convention that does not affect address validity or interoperability.
Rating: ★★★ Strong
3.5 RPC Access & Providers
Reliable RPC access is required for Aave to function smoothly in production.
An official connection point for accessing Arc, and a separate one operated by Alchemy, a widely used blockchain infrastructure provider, were both confirmed active during this assessment. Multiple independent providers are otherwise engaged for Arc: QuickNode supplies the connection point in Safe’s official configuration, and dRPC, Blockdaemon, GetBlock, and MetaMask’s own infrastructure are also available for Arc.
Rating: ★★★ Strong
3.6 Custom Execution Layer Behavior
Execution layer differences need to be reviewed closely because Aave depends on predictable EVM behavior.
Arc’s chain identifier is unique, with no collision risk against another blockchain, and its smart contract environment fully supports the Ethereum software version Aave’s contracts are built for; testing found no missing capability, including SELFDESTRUCT support. The Solidity compiler settings the target Aave repos use, including the cancun EVM-version flag, are compatible with Arc without adjustment. Arc also layers a few additive capabilities on top of this standard environment: a CallFrom precompile (0x1800000000000000000000000000000000000003) that preserves the original caller’s identity, backing a dedicated Memo contract (0x5294E9927c3306DcBaDb03fe70b92e01cCede505) and a Multicall3From contract (0x522fAf9A91c41c443c66765030741e4AaCe147D0), a gas fee model denominated in USDC, and the native asset freeze list described in Section 3.15.
Two aspects of Arc’s block behavior differ from standard Ethereum’s, though neither has an impact on the Aave Protocol or Aave Governance. The PREVRANDAO value that would normally serve as a randomness source is fixed at zero, and block timestamps are non-decreasing rather than strictly increasing, so two blocks can potentially share the same timestamp.
The CallFrom precompile alters standard EVM msg.sender scoping. Calls routed through the Memo and Multicall3From contracts preserve the original caller’s msg.sender through subcalls, so the address observed downstream is the original caller rather than the intermediary contract; Arc’s documentation calls this out explicitly so that address based screening is not bypassed through batching. This does not have direct impact on the Aave protocol by itself.
USDC on Arc exists in two forms, a native version used for balances and gas payments and a familiar ERC-20 token version. A review of the Aave contracts already deployed on Arc found this split fully compliant with ERC-20 and verified compatible with the Aave protocol. The Aave protocol interacts exclusively with the ERC-20 form of USDC and does not hold, accept, or otherwise use the native form under any circumstances. A wrapper contract some Aave deployments use to accept the native asset directly is not needed on Arc, since the native and ERC-20 forms of USDC are treated as the same asset at the protocol level.
Standard local test environments, such as a default Anvil or Hardhat setup, do not natively include Arc’s custom precompiles, so an eth_call simulation or local execution involving CallFrom or the native USDC precompiles can revert locally while succeeding on an Arc node. Foundry, the standard developer testing tool Aave normally relies on, is affected the same way: it cannot yet simulate Arc’s native USDC contract offline, so testing has relied on direct checks against the live network instead. arc-foundry and Arc specific testnet endpoints reproduce this behavior accurately.
Rating: ★★★ Strong
3.7 Wallet Provider Support
Wallet support shapes whether users, delegates, service providers, and multisig signers can interact with the network through standard tooling.
Wallet support is broad, including hardware and institutional signing: Circle’s launch release names MetaMask, Ledger, Fireblocks, Binance Wallet, Kraken, and Upbit, with additional support noted for Privy, Turnkey, Dynamic, Rainbow, and Exodus. Ledger satisfies the hardware wallet requirement for high value signing, and Fireblocks covers institutional custody.
Rating: ★★★ Strong
3.8 Transaction Monitoring
Aave requires clear transaction visibility after deployment to support monitoring, incident review, and operational response.
Blockchain explorers, covered in Section 3.2, provide baseline transaction visibility on Arc. Hypernative support is available on top of this, including rules-based monitoring, business-rule deviations, threshold alerts, onchain monitoring, and fraud detection. Coverage is sufficient for risk operations and production oversight.
Rating: ★★★ Strong
3.9 Onchain Multisig Infrastructure
Aave depends on established multisig infrastructure for administrative actions and emergency response.
The complete Safe multisig contract suite, together with every deployment tool Aave’s scripts require, is deployed onchain. Safe’s own configuration service officially supports Arc, including a dedicated, responding transaction service, so Aave’s protocol and governance multisig accounts can be operated through the official interface once deployed.
Rating: ★★★ Strong
3.10 Transaction Simulation & Tenderly
Simulation and fork tooling supports the way Aave tests upgrades, validates proposals, and reviews edge cases before execution on mainnet.
Tenderly’s transaction simulation support was confirmed functional during this assessment.
Rating: ★★★ Strong
3.11 Bridging: Assets & Cross-Chain Messaging
Aave deployment readiness depends on functional governance execution and cross chain message delivery.
Circle’s own cross chain transfer service (CCTP V2, TokenMessengerV2 at 0x28b5a0e9C621a5BadaA536219b3a228C8168cf5d, paired with MessageTransmitterV2 and TokenMinterV2) moves USDC between Arc and other networks by burning and reissuing it directly, rather than through a wrapped token. Two independently operated, two way messaging services, LayerZero and Wormhole, are live and verified on Arc’s real network: LayerZero’s EndpointV2 (0x6f475642a6e85809b1c36fa62763669b1b48dd5b) connects to 129 confirmed destinations, including a confirmed return path from Ethereum, backed by five independent verification providers, LayerZero Labs, Nethermind, Canary, Horizen, and P2P, alongside one older, deprecated LayerZero Labs verifier no longer in the active set; and Wormhole’s Core contract (0xC8aD24fC6063c41cB5C12a8e3851AafC3b3CF027) runs on guardian set 7, the same 19 guardians, byte-identical, as the current Ethereum mainnet guardian set. Wormhole’s standard automated relay service is not yet available on Arc, though its newer Executor contract is deployed and registered for Arc, so using the relay would need that newer delivery mechanism or a custom integration. Two independent messaging providers meet Aave’s assessed minimum for cross chain governance message delivery, but leave no room for a three provider setup, and Chainlink’s competing messaging service is available only on Arc’s test network, not the live one.
Rating: ★★☆ Acceptable
3.12 Chain Data & Indexing
Data and indexing infrastructure supports the broader operating layer around Aave.
The Graph and Goldsky both register Arc mainnet for data indexing, though neither has been exercised with a live integration against it, and Dune has no Arc coverage. The execution layer behavior detailed in Section 3.6 must be considered when building indexing tooling for Arc. Regarding USDC specifically, Arc implements EIP-7708 and special care must be taken to avoid double counting asset movements. Because committed blocks are final with no reorganization risk (see Section 3.14), indexing and analytics tooling built for Arc needs no reorg handling logic, confirmation depth waiting, or rollback support.
Rating: ★★★ Strong
3.13 Data Availability
High throughput and rapid block production shape how much historical data a network can practically keep accessible, which affects Aave’s ability to reconstruct state and investigate past activity.
Arc is a standalone Layer 1: data availability rests entirely on its own validator and full node network, with no external data availability layer and no data posted to Ethereum. Full nodes are permissionless and can reconstruct state by replaying the chain, the practical state reconstruction path available today. Circle has not published a data retention or full node state reconstruction policy, so long term historical data guarantees remain undocumented.
Rating: ★★☆ Acceptable
3.14 Transaction Lifecycle
For Aave, transaction lifecycle and RPC behavior matter most for liquidations, keeper infrastructure, and other latency sensitive operations.
Arc’s block times run about 0.506 seconds, with committed blocks final and no reorganization risk. Block timestamps are non-decreasing rather than strictly increasing, so consecutive blocks can carry the same timestamp; this was verified onchain across two consecutive blocks sharing an identical timestamp. Interest accrual logic used by the Aave contracts deployed on Arc handles this correctly, short circuiting when the last update timestamp equals the current block timestamp rather than reverting or double accruing, and reverting only if the last update timestamp exceeds the current block timestamp, a condition non decreasing time makes impossible. Deadline checks and access control delays elsewhere in the deployed contracts compare against the current timestamp with a less than or equal test, so same timestamp blocks do not affect them.
Rating: ★★★ Strong
3.15 Network Security & Technical Model
Aave inherits the operating conditions of the underlying network into its own protocol risk.
At assessment, the onchain ValidatorRegistry (0x3600000000000000000000000000000000000002) recorded 15 active validators holding 26,000 total voting power under Arc’s permissioned proof of authority set, with the largest single validator holding 7.69%. Five validators holding 2,000 voting power each can halt finality, and nine can control more than two thirds of voting power; the founding institutions behind the set are named, but they are not mapped publicly to their onchain validator keys, and the operators of four validators are not publicly identified. Membership in the validator set is itself permissioned by the PermissionedValidatorManager (0x3600000000000000000000000000000000000003), and that control path was exercised onchain during the assessment window. Arc runs a single execution client (reth, version v1.11.3) and a single consensus client (Malachite); the latest arc-node release at assessment was v0.7.3 (20 July 2026). Arc is not a rollup, has no sequencer, forced inclusion mechanism, or permissionless exit path (see Section 3.14 for finality and block timing).
Arc’s system contracts, FiatToken (USDC, 0x3600000000000000000000000000000000000000), ProtocolConfig (0x3600000000000000000000000000000000000001), the ValidatorRegistry, the PermissionedValidatorManager, and a fifth system contract (0x3600000000000000000000000000000000000004), are transparent proxies whose proxy admin and owner roles all resolve to individually held keys rather than a multisignature account or a time delay, with no N-of-M signer set in any of the five upgrade paths; the PermissionedValidatorManager’s owner key, the one controlling who can join the validator set, was used to change validator membership during the assessment window. USDC’s own controls, including the blacklister role (0x2A2b7FF330F15F9A8c52af5Fec27D775f5138467) that can freeze an address, also rest with individually held keys, though the masterMinter role is implemented as a contract rather than a bare individually held key; since USDC is also the network’s gas asset, a freeze can stop an address transacting at all, not only moving USDC. Tracing this through Aave’s own contracts found a frozen borrower remains liquidatable and repayable by a third party, since neither action moves funds directly to or from the frozen address; a frozen liquidator, or a freeze on one of Aave’s own contracts, would be blocked from that action.
Circle operates an active bug bounty program on HackerOne open to security researchers, scoped to issues materially affecting network safety, liveness, correctness or reliability, that has already surfaced and disclosed a denial of service finding in the consensus engine, evidence it sees real use. A dedicated technical incident response channel between Aave and the Arc team is being established.
Rating: ★☆☆ Concern
3.16 Comparison with Similar Networks
Comparing Arc against networks already hosting Aave deployments puts its technical profile in context.
Arc’s closest comparable is a Tendermint style BFT Layer 1 with an Ethereum equivalent execution layer, not an optimistic or validity proof rollup, so the assumptions Aave typically applies to a Layer 2 do not transfer directly. Liveness risk is a validator coalition holding more than one third of voting power, not a single sequencer, and there is no forced inclusion path or Chainlink sequencer uptime feed to gate liquidations on; deterministic finality in well under a second removes reorganization risk entirely, which is stronger than any optimistic rollup’s confirmation window. Arc settles independently rather than to Ethereum, so all governance messaging depends on the third party providers assessed in Section 3.11, and USDC as the gas asset carries issuer freeze powers enforced at the protocol level rather than only within an ERC-20 contract. Concentration of consensus power among a small number of regulated institutions, with no permissionless exit, is a governance and legal risk profile distinct from any current Aave deployment.
Rating: ★★★ Strong
4. Summary
Technical assessment of Arc for Aave deployments whose contracts target Cancun.
Arc reaches finality in well under a second with no risk of chain reorganizations, its smart contract environment is fully compatible with what Aave’s contracts require, Chainlink price feeds are live for a broad set of assets, and two independently operated cross chain messaging providers, LayerZero and Wormhole, are confirmed live on the real network. The result reflects conditions observed before public mainnet availability, including a validator setup that currently runs on a single software implementation, a messaging provider count at the assessed minimum, and a system upgrade and validator membership control model that currently rests on individually held keys rather than a multisignature account (see Section 3.15).
Findings table
Ratings in this table use the same star notation as Section 3, matching the methodology in Section 2.
| Area | Key finding | Rating |
|---|---|---|
| 3.1 Oracles | 28 Chainlink Data Feeds live onchain within heartbeat, including the AAVE Network Emergency Count feed | ★★★ |
| 3.2 Blockchain explorer | Mainnet explorer confirmed functional, with the public test network explorer live and source verified | ★★★ |
| 3.3 RPC standard compatibility | Standard trace and debug tracing available; two RPC methods unsupported and the eth_call gas cap lowered |
★★★ |
| 3.4 Account format compatibility | Standard secp256k1 keys and addresses; lowercase rendering is a cosmetic difference only | ★★★ |
| 3.5 RPC access & providers | Official and third party connection points active | ★★★ |
| 3.6 Custom execution layer behavior | Full compatibility with Aave’s target software confirmed on the live network, with a few additional network specific features layered on top | ★★★ |
| 3.7 Wallet provider support | Broad wallet support including hardware and institutional signing | ★★★ |
| 3.8 Transaction monitoring | Hypernative provides rules based monitoring, threshold alerts, and fraud detection coverage for Arc | ★★★ |
| 3.9 Onchain multisig infrastructure | Full Safe multisig suite deployed onchain, with official configuration service support for Arc | ★★★ |
| 3.10 Transaction simulation & Tenderly | Tenderly mainnet support confirmed functional | ★★★ |
| 3.11 Bridging: assets & cross-chain messaging | Circle’s transfer service live for native asset bridging; two independent messaging providers meet the assessed minimum | ★★☆ |
| 3.12 Chain data & indexing | The Graph and Goldsky register Arc mainnet but unexercised; USDC’s duplicate transfer records require indexing tools to adjust | ★★★ |
| 3.13 Data availability | No external data availability layer; full nodes can reconstruct state by replaying the chain, but no data retention policy is published | ★★☆ |
| 3.14 Transaction lifecycle | Deterministic sub second finality; non-decreasing timestamps are handled correctly by the deployed interest accrual and deadline logic | ★★★ |
| 3.15 Network security & technical model | Deterministic finality on a single client validator stack, with system upgrade and validator membership control resting on individually held keys | ★☆☆ |
| 3.16 Comparison with similar networks | Deterministic finality and no sequencer exit path distinguish Arc from Aave’s typical Layer 2 deployments | ★★★ |
Disclaimer
Aave Labs has no formal or informal affiliation with Circle or its contributors beyond this technical assessment. Aave Labs has not been compensated by Circle or any related party in connection with this work.
Copyright
Copyright and related rights waived via CC0.