Base

Slug	base
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	8453
Confirmations	1, against the L1-finalized head
Tokens	ERC-20 (native USDC)
Explorer	https://basescan.org/tx/{txid} · https://basescan.org/address/{address}

Base is Coinbase's OP-Stack L2. It executes the EVM, settles to Ethereum, and inherits Ethereum's address model wholesale.

The address is Ethereum's, and so is the asset

Coin type 60', so an address issued for eth receives on Base. No separate key, no separate address. See Ethereum.

Base is the hardest member of that set to keep distinct, and it is worth being explicit about why. On Avalanche the shared address at least reports a different native symbol, so a balance rendered in the wrong place looks wrong. On Base the native asset is ETH. Same path, same address, same symbol, same 18 decimals — and a different chain, a different chain ID, a different explorer and a different balance. Nothing in a rendered balance distinguishes Base from Ethereum except the field that says which chain it came from.

The gas tank is a separate tank

Your Base gas tank is derived at m/44'/60'/0'/1/0 — byte-identical to your Ethereum tank, and it holds ETH, just as the Ethereum tank does. It is nonetheless a different balance on a different chain, and funding the Ethereum tank does nothing for it.

This is the one tank on the platform that shares both an address and an asset symbol with another chain's. An operator who reconciles by symbol will conclude the tank is funded when it is not; the readiness panel reports the two separately for exactly that reason.

Why one confirmation, and why it is slow

A Base block is produced by a single sequencer in about two seconds. Until the batch containing it has been posted to Ethereum and finalized there, that block is reversible — by the sequencer, or by an L1 reorg.

There is therefore no honest analogue of Ethereum's twelve or Polygon's 128. Any block count would be a guess about how much sequencer risk and how much L1 risk to accept, handed to you as though it were a threshold. So ChainOS does not report the chain tip as the head. It reports the L1-derived finalized head, and confirmations: [1] against it means precisely:

Ethereum has finalized the batch containing this block.

Measured against mainnet, that head runs 25–35 minutes behind the tip, and it advances in steps as L1 epochs finalize rather than smoothly. A deposit therefore confirms somewhere in that band.

This looks like a stalled node, and is not

A head that lags by half an hour and jumps in increments is exactly what a broken RPC endpoint also looks like. If you are comparing ChainOS's reported height against eth_blockNumber from your own node, they will not agree, and they are not supposed to.

deposit_detected fires on inclusion, so it arrives within seconds. deposit_confirmed waits for finality. Unlike Avalanche, where the two fire close together, on Base they are half an hour apart — credit the customer on whichever of the two your risk appetite justifies, not on whichever arrives first.

Trading finality for latency

chainos.chains.base.commitment selects the tag, and it is a genuine product decision rather than a tuning knob:

Setting	Lag behind tip	Defeats
finalized (default)	25–35 min	A sequencer that equivocates and an L1 reorg
safe	20–60 s	A sequencer that equivocates only

safe means the batch is in an L1 block but Ethereum has not finalized it. Both settings are honest; only finalized is final. Solana reads the same setting for the same reason — both chains express confirmation depth as a commitment level rather than as a count.

Fees — EIP-1559 plus an L1 data fee

fee = gasUnits × (baseFee × 2 + priorityFee)  +  l1DataFee

Execution gas works exactly as it does on Ethereum, reporting baseFeeGwei, priorityFeeGwei, maxFeeGwei and gasUnits. Base adds a fifth key that no L1 has:

Key	Meaning
l1DataFeeWei	What this transaction pays Ethereum for its own data availability

A rollup publishes its transaction data to Ethereum, and the sender pays for that. The charge is deducted at execution time and appears in no field of the transaction — you cannot bid it, cap it, or read it off the signed payload.

Since EIP-4844 it is usually small, single-digit gwei against Base's execution gas. Its size is not the reason it is reported. The reason is that it tracks Ethereum's blob market, not Base's gas price, so its ratio to the execution fee is a market condition rather than a property of your transaction — and it is therefore not bounded by anything you can inspect locally.

It is included in the fee total, not reported beside it. The total is what the pre-flight check compares your balance against, and a fee the sender pays but the estimate omits is a withdrawal that passes the check and then fails on chain.

When the key is absent

l1DataFeeWei appears only when it could be determined. ChainOS reads it from the OP-Stack GasPriceOracle predeploy at 0x420000000000000000000000000000000000000F; if that call fails, the estimate still returns with correct execution gas and the key omitted rather than failing outright — which would take balance enquiry and withdrawal building down with it. An estimate with no l1DataFeeWei on Base understates the true cost of the send.

The other four EVM chains report no such key. Emitting "l1DataFeeWei": "0" on Ethereum would add a field to four chains' fee breakdown to describe something those chains do not have.

Tokens

Symbol	Contract	Decimals
USDC	0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913	6
RLUSD	0x8D58c0C60b8d6b88fA98b291A646dB34d0f98258	18
EURC	0x60a3E35Cc302bFA44Cb288Bc5a4F316Fdb1adb42	6
cNGN	0x46C85152bFe9f96829aA94755D9f915F9B10EF5F	6

Circle issues USDC natively on Base.

An older bridged variant, USDbC (0xd9aAEc86B65D86f6A7B5B1b0c42FFA531710b6CA, also 6 decimals), still circulates and ChainOS does not monitor it — the same call made on Avalanche and, since registry v2, on Polygon too. A USDbC deposit is recoverable from your mnemonic but invisible to ChainOS. If you expect bridged deposits, say so and we will add the contract.

As everywhere else, branch on tokenContract rather than on tokenSymbol.

Balances

{ "confirmed": "1000000", "available": "1000000", "reserved": "0", "decimals": 6 }

available == confirmed. Nothing is immobilised on Base — no account reserve, no rent — so INSUFFICIENT_RESERVE cannot occur here.

Operational notes

• Fund the Base tank separately. Restated because the shared ETH symbol makes this the easiest gas-tank mistake on the platform to make and the hardest to notice.
• Basescan, not Etherscan. The address is the same string, so a customer will paste it into Etherscan and see nothing.
• Confirmation is half an hour, by design. Before treating it as an incident, check the commitment setting and read the finality section above.
• Withdrawal quotes go stale differently here. The L1 data component moves with Ethereum's blob market, so a quote can drift for reasons that have nothing to do with Base's own congestion.
• Reverted transactions cost the fee, as on every EVM chain — including the L1 data fee, which is charged for publishing the data regardless of whether execution succeeded.
• Other OP-Stack chains are not supported. Optimism, Zora and others share Base's address format and its 0x… shape. An address here is on Base (8453); a customer sending on another OP-Stack chain is sending to an address you control on a network nothing is monitoring.