Contract Addresses

This page is the address of record for every deployed BTR contract, and the one integrations should read. Each chain gets one section, generated from that chain’s deploy-time artifacts - never hand-typed - and regenerated after every deploy; deployed chains come first, chains without a deployment at the end. A section covers the deploy metadata, the oracle stack, the mock ERC-20s and their feed IDs, and the protocol singletons (Admin, Flash, PoolFactory, Pool implementation, reference oracle). Verify every address before sending funds; cross-check the block explorer link on each row.

Contract ABIs are served by the backend at GET /v1/abis/<ContractName> (the same endpoint @btr-protocol/sdk fetchAbi uses). Do not wire integrations to the SDK’s CONTRACTS[chainId] registry - it is a placeholder of zero addresses.

Network: Arc Testnet, chainId 5042002

Status: live public testnet (Deployments Overview §1). Hub token USDC.b; native USDC is Circle testnet / gas.

Explorer: Arc Testnet Explorer

Deploy metadata

Core contracts

Pools (shared implementation + ERC-1967 beacon proxies)

Further pools (permissionless deploys included): enumerate via PoolFactory.allPools. Every pool reads its implementation from PoolFactory, which is the beacon, so a single timelocked executeReferenceUpgrade changes the code of all of them at once.

Mock ERC-20s + oracle feeds

Every asset above carries an independent breaker feed <SYM>-USDC on refOracle (§ core contracts), used for the depeg band and never for quoting, except USDC, which is the pool base and has no <SYM>-USDC identity feed to bind. That is not pool membership: which core an asset sits in is Admin risk-config data rather than deploy-artifact data, and lives in Pool Composition.

A row reading “shares” is a faucet twin: it owns no feed and quotes off an existing one, so it carries that feed’s id rather than a blank. USDCB quotes USDT-USDC; EURCB quotes EURC-USDC. USDCB binds to USDT-USDC rather than to USDC because USDC is the pool base and has no identity feed of its own.

Roles

Authority is asymmetric by design: halting is guardian-or-owner, un-halting is owner-only. The full matrix is in Access Control.

Independent reference feeds

Pairs priced on refOracle (above), used only for the depeg-band / volatile refBand breaker, never for quoting. Pairs: AMD-USDC, ASML-USDC, AUDF-USDC, AVGO-USDC, BNB-USDC, CBBTC-USDC, EURC-USDC, INTC-USDC, JPYC-USDC, KRW1-USDC, META-USDC, MSFT-USDC, NVDA-USDC, ORCL-USDC, PAXG-USDC, PYUSD-USDC, QCAD-USDC, SPCX-USDC, TSLA-USDC, USD1-USDC, USDS-USDC, USDT-USDC, WBTC-USDC, WETH-USDC, XAUT-USDC.

USD unit reference

Reading this table once populated

Applies to every chain section.

• Core contracts: singleton, deployed once per chain, plain immutable logic (see Upgradeability below for the three upgrade paths); a redeploy changes the address.
• Reference oracle: refOracle is a second, independent ExternalOracle instance backing the depeg band and the volatile-asset refFeed breaker, never a swap quote (Oracles). Ref-bound pairs are marked per token row above.
• Pools: every pool is an ERC-1967 beacon proxy, not an immutable clone. All read PoolFactory.implementation(): the factory is the beacon. A pool’s address is permanent; its code is not. One owner transaction, PoolFactory.executeReferenceUpgrade() after the UPGRADE tier delay (7 days in production), re-points every live pool on that chain at a new implementation at once, including pools deployed permissionlessly by third parties. Vetoable by the owner or any guardian (cancelReferenceUpgrade); expires 7 days after maturity. See Deployment & Upgrades §4.1.
• Mock ERC-20s: testnet chains have no viable canonical token supply to seed pools, so every non-official pool asset is a BTR-deployed mock, mainnet-faithful in decimals and permit support. Mainnet reference addresses (feed mapping only) live in the Asset Registry. The “Ref-oracle bound” column is read off refFeeds; the note under that table explains what it does and does not mean.
• Feed IDs: keccak256(abi.encodePacked(token, USDC)), the primary ExternalOracle feed identifier the keeper pushes against.

Upgradeability

Three upgrade paths, identical on every chain.

1. Pool fleet (largest): the PoolFactory beacon - see its row above and Deployment & Upgrades §4.1. Monitor ReferencePoolUpgradeRequested / ReferencePoolUpgraded on PoolFactory. A pool logic change ships as a new implementation address plus a beacon swap: an in-place upgrade of every existing pool.
2. Admin and Flash: UUPS proxies over the shared UpgradeGate base (timelocked requestUpgrade / executeUpgrade; a direct upgradeToAndCall is rejected even from the authority). Table addresses are the proxies, which is what Pool bakes in as immutables; implementations are tracked separately as adminImpl / flashImpl.
3. No upgrade path: AccessControl (Ownable - rotatable owner, fixed code), PoolFactory (holds the fleet implementation pointer, own code fixed), both ExternalOracle instances, the LPToken implementation, and the four linked libraries (Pricing, PoolConfig, PoolLiquidity, NUQuartic).

Governance-critical DEX parameter changes - risk config, curve presets, feed additions - route through Admin’s timelock rather than through a contract upgrade, so the deployed code for those paths does not change at all; see Deployment & Upgrades.

Keeper on-chain touchpoints

Per chain, the oracle keeper is the only regular non-admin writer against the stack. It calls ExternalOracle.batchPushSigned(blob, sigs) (k-of-n EIP-712 NXR-signer quorum, at least 2-of-3) on a deviation-or-heartbeat trigger per feed; addFeed/updateFeed are owner-only setup/recovery calls, not part of the steady-state loop. Full trust model and signer set: Oracle Price-Push Security.

Other chains

These are deployment targets, each awaiting its launch. Addresses appear here the first time a chain is deployed, as its own generated section keyed by chainId, together with the matching machine-readable deployments.<chainId>.json. Until then a chain below has no BTR contracts and nothing to integrate against, so build on Arc testnet and switch the chainId when its section appears.

Reserved mainnet addresses

No mainnet chain has a BTR deployment, so no mainnet address appears in the tables above. Six addresses are nevertheless reserved for the eventual launch, mined in advance so the ceremony has nothing left to choose. They are the same on every chain BTR launches on.

Reserved is not deployed. Nothing holds code at any of these addresses today, on any chain, and nothing will until a launch ceremony runs and this page grows a section for that chainId. Treat an address here as a future constant, not as somewhere to send funds or point an integration - and treat anything that appears at one of them before that section exists as not ours.

Why the addresses can be known in advance: BTR deploys through a CREATE3 factory, where the resulting address is a pure function of the factory, the deployer key and a mined salt, and does not depend on the contract’s bytecode. That makes the address stable across chains and independent of which generation of a contract ships. The deployer key is part of the input, so only the reserved mainnet key produces these addresses; the same salts under the testnet key give the ordinary addresses in the Arc section above.

Contracts with no reserved address get one at deploy time and are published here afterwards. The Admin and Flash rows are the proxies; their implementations move on every upgrade and are never reserved. Pools and LP tokens are never reserved either - a pool address is derived by PoolFactory from its own salt, and an LP token by the pool from the leg.

The contract surface is identical across chains; the addresses are not, and neither is the native gas token.