Avalanche
| Slug | avax |
| Address format | EIP-55 checksummed hex, 0x… |
| Account path | m/44'/60'/0' — shared with Ethereum |
| Cloud stores | Ethereum's xpub. No separate key |
| Derivation | ✅ M/0/{i} — public, no Edge required |
| Chain ID | 43114 |
| Confirmations | 1, and it is final |
| Tokens | ERC-20 |
| Explorer | https://snowtrace.io/tx/{txid} · https://snowtrace.io/address/{address} |
ChainOS supports the C-Chain only. Avalanche also runs an X-Chain and a P-Chain, which use a
different address format and a different transaction model; neither is an EVM chain and neither is
monitored here. A 0x… address is always C-Chain.
The address is Ethereum's. Nothing else is.
Coin type 60', so an address issued for eth receives on Avalanche. No separate key, no separate
address. See Ethereum.
This is the chain where that sharing is most likely to mislead, because unlike BSC and Polygon there is no sense in which Avalanche is an Ethereum network. It has its own consensus, its own validator set, and no dependence on Ethereum at all. It shares an address model, and that is the whole of it.
Your Avalanche gas tank is derived at m/44'/60'/0'/1/0 — byte-identical to your Ethereum tank. It
is nonetheless a different balance on a different chain, and it holds AVAX. Funding the
Ethereum tank does nothing for it.
The console shows both, and the readiness panel reports them separately for exactly this reason. An operator who funds "the EVM tank" once and considers the matter closed has funded one of five.
Why one confirmation
Avalanche finalises under Snowman++, which reaches agreement by repeated sub-sampled voting rather than by accumulating work or attestations. A block that has been accepted is final in a second or two, and it cannot be reorganised out.
So confirmations: [1] here means what it means on XRP and Stellar — settled — and not what
Ethereum's twelve means, which is a probability judged good enough. There is no deeper number worth
waiting for on this chain, and offering one would imply a risk that does not exist.
deposit_detected and deposit_confirmed therefore fire close together, typically within seconds
of each other. That is not a misconfiguration.
Thresholds are not configurable. See Deposits.
Fees — EIP-1559
fee = gasUnits × (baseFee × 2 + priorityFee)
Same model as Ethereum, reporting baseFeeGwei, priorityFeeGwei, maxFeeGwei and gasUnits.
There is no L1 data fee and no second component of any kind: Avalanche is an L1 and publishes its own data. The fee breakdown carries exactly the four EIP-1559 keys, and a total that is the whole cost of the send.
Fees are denominated in AVAX. The C-Chain sometimes quotes gas in "nAVAX", which is the same unit Ethereum calls gwei — 10⁻⁹ of the native token. ChainOS reports gwei for consistency with the other EVM chains; the number is the same.
Tokens
| Symbol | Contract | Decimals |
|---|---|---|
| USDC | 0xB97EF9Ef8734C71904D8002F8b6Bc66Dd9c48a6E | 6 |
| USDT | 0x9702230A8Ea53601f5cD2dc00fDBc13d4dF4A8c7 | 6 |
| EURC | 0xC891EB4cbdEFf6e073e859e987815Ed1505c2ACD | 6 |
All three are issued natively on Avalanche by Circle and Tether respectively.
Bridged predecessors exist — USDC.e and USDT.e, both also 6 decimals — and ChainOS does not
monitor them. The same call is now made on Polygon and Base: a
bridged representation the issuer will not redeem is a different asset from the token it is named
after. If you expect bridged deposits, say so and we will add the contracts; a deposit in an
unmonitored contract is recoverable from your mnemonic but invisible to ChainOS until then.
ChainOS reports it as USDT. The symbol is a lookup key and the registry matches symbols
case-insensitively, so USDT and USDt cannot be two catalogue entries — carrying both would make
every lookup depend on the case of one letter. Before registry v2 this contract was reported as
USDt; if you branched on that string, branch on tokenContract instead, as you should everywhere
else.
Balances
{ "confirmed": "1000000", "available": "1000000", "reserved": "0", "decimals": 6 }
available == confirmed. Nothing is immobilised on Avalanche — there is no account reserve and no
rent, so INSUFFICIENT_RESERVE cannot occur here.
Operational notes
- Fund the AVAX tank. Restated because it is the failure this chain actually produces: an ERC-20 sweep needs native gas at the source address, and the source address holding ETH on Ethereum tells you nothing about whether it holds AVAX here.
- Snowtrace, not Etherscan. The address is the same string, so a customer will happily paste it into Etherscan and see nothing. Link them to Snowtrace.
- Reverted transactions cost the fee, as on every EVM chain.
- Subnets are not supported. Avalanche hosts many application-specific chains with their own
chain IDs. An address here is on the C-Chain (
43114); a customer sending on a subnet is sending to an address you control on a network nothing is monitoring.