Chainlink on Arc: Reading Price Feeds on a Dollar-Denominated Chain

Circle named Chainlink among the day-one integrations for Arc, alongside Uniswap, Aave, Morpho, MetaMask and Fireblocks. That is the only claim this page makes without qualification — which feeds are live, at which addresses, and whether Data Streams, CCIP and VRF are available all need confirming against Chainlink's own documentation before you ship. What is stable and worth understanding now is the shape of the problem: on a chain where the unit of account is already a dollar, the oracle demand curve is different from Ethereum's, and so are the integration mistakes.

This page covers Arc in its first weeks of mainnet. Where something is still settling we say so rather than guess, and we revise this page as the ecosystem fills in. Last reviewed: September 2026.

Is Chainlink live on Arc?

Chainlink is named by Circle among Arc's day-one integrations in its published Arc launch materials, and Arc's public mainnet went live on 16 September 2026. That is the claim we can make. Beyond that named presence, the specifics — which price feeds are deployed, at which proxy addresses, with what deviation thresholds and heartbeats, and which Chainlink product lines beyond Data Feeds have shipped — are not settled a few weeks into a chain's life.

So we do not publish a feed list here. Chainlink maintains its own directory for every network it supports, on the Price Feed Contract Addresses page in its documentation (docs.chain.link/data-feeds/price-feeds/addresses), with a network selector; that is the source of truth for which pairs exist on Arc, their proxy addresses, and each feed's deviation threshold and heartbeat. A list transcribed into an article is a list that is wrong within a week — and on a young chain it is wrong in the direction of feeds that exist now and did not when we wrote.

The same applies to the other product lines. Data Streams, CCIP, VRF, Automation and Proof of Reserve each roll out per-network on their own schedule, and support for Data Feeds implies nothing about the rest. Chainlink's documentation carries a supported-networks page per product; check the one for the product you need rather than reasoning from Chainlink's presence on Arc generally.

The reason to be this careful is specific. A feed address copied from another chain is a valid-looking address that will either revert or, worse, resolve to an unrelated contract. Read addresses from the official directory and assert on description() in your deployment script rather than trusting a config constant.

Why does a dollar-denominated chain need an oracle at all?

Because the thing an oracle is usually asked for on other chains — the dollar price of a volatile gas token — is the one question Arc does not need answered. Gas on Arc is paid in USDC, so there is no ETH/USD conversion in the fee path and no stablecoin whose peg your contract must continuously price. What you need instead is foreign exchange and non-USD asset prices, which is a materially different feed set.

Oracle demand on Arc clusters in four places. FX: Arc ships EURC alongside USDC, Circle has signalled regional stablecoins for BRL, JPY and MXN, and Arc's StableFX engine is an onchain FX layer — anything that quotes, hedges or settles across those currencies needs a rate. Non-USD asset valuation: BTC, ETH, equities, commodities and fund NAVs, exactly what a chain hosting BlackRock's BUIDL and DTCC's tokenised assets accumulates. Collateral pricing in lending markets — see Aave on Arc — where the borrowed asset is a dollar but the collateral is not. And proof-of-reserve or attestation feeds for wrapped instruments.

The inversion is worth stating plainly because it changes what you build: on Ethereum, most integrations start by pricing the volatile asset in dollars; on Arc, most start by pricing the dollar in something else. For the currency side, see EURC on Arc.

How do you consume a Chainlink price feed?

You call latestRoundData() on the feed's proxy contract through AggregatorV3Interface, read the answer and updatedAt fields, scale by the feed's own decimals(), and revert if the data is stale or non-positive. The proxy address is per-chain and per-pair; never reuse an address across chains.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

interface AggregatorV3Interface {
    function decimals() external view returns (uint8);
    function description() external view returns (string memory);
    function latestRoundData()
        external
        view
        returns (
            uint80 roundId,
            int256 answer,
            uint256 startedAt,
            uint256 updatedAt,
            uint80 answeredInRound
        );
}

A minimal consumer that fails closed rather than open:

contract PriceReader {
    error StalePrice(uint256 updatedAt, uint256 maxAge);
    error InvalidAnswer(int256 answer);

    AggregatorV3Interface public immutable feed;
    uint256 public immutable maxAge;   // seconds; set from the feed's heartbeat
    uint8   public immutable feedDecimals;

    constructor(address feedAddress, uint256 maxAge_) {
        feed = AggregatorV3Interface(feedAddress);
        feedDecimals = feed.decimals();
        maxAge = maxAge_;
    }

    /// @return price scaled to 18 decimals
    function priceWad() public view returns (uint256) {
        (, int256 answer, , uint256 updatedAt, ) = feed.latestRoundData();
        if (answer <= 0) revert InvalidAnswer(answer);
        if (block.timestamp - updatedAt > maxAge) revert StalePrice(updatedAt, maxAge);

        uint256 p = uint256(answer);
        return feedDecimals < 18
            ? p * (10 ** (18 - feedDecimals))
            : p / (10 ** (feedDecimals - 18));
    }
}

Read decimals() from the feed rather than assuming. Chainlink USD-quoted feeds have conventionally used 8 decimals and ETH-quoted feeds 18, but the value is a per-feed property and hardcoding it produces silently wrong valuations rather than reverts. On Arc this compounds with the 18-decimal native USDC context described in USDC's 18 decimals on Arc: you may normalise a 6-decimal bridged token, an 18-decimal native balance and an 8-decimal feed answer in one function, and every constant must come from the contract, not from memory.

What goes wrong, specifically?

The four failure modes that account for most oracle incidents are stale data accepted as fresh, decimals mismatch, a spot price used where a time-weighted or manipulation-resistant price was required, and a fallback path that is more dangerous than no fallback at all. All four are integration errors rather than oracle failures.

Staleness is the one Arc's performance profile makes easy to get wrong. Arc has deterministic sub-second finality — roughly 780ms — and testnet has been running around 13.5 million transactions per week as of mid-August 2026. A fast chain does not make a feed update faster. Push-based Data Feeds update on a deviation threshold or a heartbeat, both measured in real time, so on Arc your contract can execute dozens of blocks between two oracle updates. Set maxAge from the feed's documented heartbeat plus a margin, not from a block count, and never from intuition about how fast the chain is.

Manipulation resistance is the second Arc-flavoured trap. If a feed is not live and you substitute a spot price from a DEX pool — see Uniswap on Arc — the price becomes a function of pool depth in a single block, and on a young chain pool depth is thin by definition. A same-block flash-loan manipulation does not care that finality is 780ms. If you must use an onchain source, time-weight it over a window long enough that moving it costs more than the position it secures, and treat that as a stopgap.

Fallbacks deserve a sentence of their own: a fallback oracle less trustworthy than the primary converts an availability problem into a solvency problem, because an attacker who can stall the primary now chooses your price source. Prefer pausing to falling back.

What if the feed you need is not live yet?

Then design for the feed you will have, and gate the launch of the dependent feature rather than shipping a weaker price source into production. Put the oracle behind an interface, deploy with a governed setter for the feed address, and ship the feature disabled until a real feed exists.

interface IPriceSource {
    function priceWad() external view returns (uint256);
}

contract Vault {
    IPriceSource public priceSource;   // settable by governance
    bool public pricingEnabled;

    modifier priced() {
        require(pricingEnabled && address(priceSource) != address(0), "pricing off");
        _;
    }
}

This is unglamorous and correct. The alternative — hardcoding an assumption that a pair is at parity, or reading a thin pool — is how a launch-week exploit happens.

Two checks belong in your process before any of this reaches mainnet. Open Chainlink's Price Feed Contract Addresses page, select Arc in the network dropdown, and copy the proxy address for your pair along with the heartbeat and deviation-threshold columns beside it — those columns are what maxAge should be derived from. Then paste the address into Arcscan's search, open the Read Contract tab, and call description() and latestRoundData(). The description should read as the pair you expect, in the form ETH / USD, and latestRoundData should return a positive answer with an updatedAt timestamp within the feed's heartbeat of now. If either is not true, you have the wrong address or an unmaintained feed — better found at your desk than in production.

FAQ

Is Chainlink live on Arc mainnet?

Circle names Chainlink among Arc's day-one integrations in its published launch materials, and Arc mainnet went live on 16 September 2026. That establishes Chainlink's presence in the ecosystem. It does not establish which individual price feeds are deployed, at which addresses, or which Chainlink products beyond Data Feeds are available — confirm all of that against Chainlink's own official documentation before writing an address into a contract.

Which price feeds matter most on Arc?

FX pairs and non-USD asset prices, rather than the stablecoin-to-dollar feeds that dominate elsewhere. Because gas on Arc is paid in USDC and the unit of account is already a dollar, the questions your contracts need answered are typically "what is a euro worth in dollars" or "what is this collateral worth", not "what is the dollar worth". Arc ships EURC and Circle has signalled BRL, JPY and MXN stablecoins, which points the demand at currency pairs.

Can I reuse a Chainlink feed address from Ethereum or Base on Arc?

No. Feed proxy addresses are deployed per chain, and an address that is valid on one network is meaningless or, worse, occupied by an unrelated contract on another. Read addresses from Chainlink's official directory for the specific network, and add a deployment-time assertion on the feed's description() string so a wrong address fails your deploy rather than your users.

How stale can a price be before I reject it?

Set the threshold from the feed's documented heartbeat plus a margin sized to your risk, commonly the heartbeat plus 10 to 25 percent. Do not derive it from block times: Arc's sub-second finality means many blocks pass between oracle updates, and a block-count threshold will reject fresh data or accept stale data depending on load. Always revert on a zero or negative answer as well.

Does Arc's confidential transfer feature affect oracle reads?

Arc's opt-in confidential transfers shield amounts while leaving addresses visible, with view keys for auditors. Price feeds are public read-only contracts and are unrelated to that mechanism, so a latestRoundData() call is unaffected by whether the calling contract also handles confidential balances. The harder question — whether a position holding shielded balances can be valued and risk-managed like a transparent one, and what a liquidation engine does when it cannot read a size — is a design problem rather than an oracle problem, and the patterns around it are still being written. Confidential transfers on Arc sets out precisely what is shielded and what is not, which is where that design work starts.