Deployments

BTR is live on one chain: Arc public testnet, chainId 5042002. The other chains in §1 are deployment targets and carry no addresses. Every address, roster and asset mapping on these pages is generated from the per-chain deployment artifacts, never hand-edited; a redeploy regenerates them.


1. Testnet policy

Every chain is a row, keyed by chainId. Adding a chain adds a row.

ChainchainIdStatusNotes
Arc Testnet5042002Live public testnetRouting hub USDC.b (mintable faucet twin). Native USDC (0x3600…) is Circle’s testnet / gas token, not faucet-mintable
Ethereum1PlannedNative gas ETH
BNB Chain56PlannedNative gas BNB

Planned = deployment target awaiting launch, no contracts. Row backing is the chain-slug registry (dex-evm/deployments/chains.json) plus that chain’s manifest; a chain absent from both has no reservation and no row here, whatever the SDK’s broader wallet-metadata list carries. A row populates in Contract Addresses at deploy time from that chain’s artifacts; until then, point integrations at Arc testnet.

Native gas is not ETH everywhere: BNB Chain pays BNB, Arc native USDC. The authority for a given chain’s native currency is the SDK chain registry (@btr-protocol/sdk, src/eth/chains.ts), not this table.

Where the gas token is also a listed pool asset, a “max” send has to leave the fee behind. On Arc the native currency is USDC at 18 decimals while the ERC-20 view of the same balance at 0x3600000000000000000000000000000000000000 is 6, and there is no wrapped native token: USDC is flagged as the ERC-20 whose balance also pays the transaction fee. A transfer of the entire balance therefore reverts TransferFromFailed, and the app reserves a gas buffer on that input.

The app reads the published per-chain deployment artifacts for whichever chain is selected; Contract Addresses is generated per chainId the same way.

On testnet chains, pool assets are BTR-deployed ERC-20 mocks except official Circle USDC/EURC. Mocks are mainnet-faithful:

  • same decimals as the mainnet reference token;
  • EIP-2612 permit where the mainnet token has it (per-asset oddities in Asset Registry);
  • minted via on-app Faucet (TestnetFaucet) under daily caps.

Mainnet addresses are reference metadata only: they pin the NXR feed mapping and the mock fidelity target (decimals, permit behavior).

Marks for every listed asset arrive via the signed keeper push pipeline; provenance and on-chain verification in Oracle Keeper.

Which addresses can change, and under what delay: Contract Addresses §Upgradeability.

1.1. Block production and ordering, Arc

Block production on Arc is a permissioned validator set with Circle-gated membership and a single block assembler; the intra-block ordering rule is undocumented. maxPriorityFeePerGas = 0 is the documented recommendation, so no priority-fee auction runs, and no third-party ordering privilege is sold. The only announced MEV path routes proceeds to validator and staker rewards and to burn, not to applications - a statement about BTR’s rights on Arc, not a claim that Arc has no MEV: an opaque assembler still holds an unpriced ordering option and latency races persist. BTR has no ordering right to sell there. Permitted responses on Arc: lower the per-feed min_push_gap_s or the overshoot page threshold, raise the fee floor or the staleness premium, or escalate to Circle. Revisit only if Arc ships an application-addressable ordering primitive. Toxic-flow policy this responds to: Toxic Flow Mitigation §8.


2. Pages

PageContent
2.1. Contract AddressesGenerated addresses, one section per chainId
2.2. Asset RegistryAssets: mainnet reference, decimals, NXR feed route
2.3. Pool CompositionStable / FX / Crypto / Stocks cores; hub = USDC.b