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.
| Chain | chainId | Status | Notes |
|---|---|---|---|
| Arc Testnet | 5042002 | Live public testnet | Routing hub USDC.b (mintable faucet twin). Native USDC (0x3600…) is Circle’s testnet / gas token, not faucet-mintable |
| Ethereum | 1 | Planned | Native gas ETH |
| BNB Chain | 56 | Planned | Native 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
decimalsas the mainnet reference token; - EIP-2612
permitwhere 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
| Page | Content |
|---|---|
| 2.1. Contract Addresses | Generated addresses, one section per chainId |
| 2.2. Asset Registry | Assets: mainnet reference, decimals, NXR feed route |
| 2.3. Pool Composition | Stable / FX / Crypto / Stocks cores; hub = USDC.b |