Exchange Integration Checklist for Base

Monitor the OptimismPortal contract on L1 for TransactionDeposited events. Do not credit user balances until the corresponding L2 transaction is included in a block whose batch has been submitted to L1. The SentMessage event from the L1CrossDomainMessenger is the canonical signal for ETH and ERC-20 deposits initiated via the bridge, not internal mint events on L2. Exchanges must handle the ~15-minute L1 finality delay before initiating deposit crediting logic.

Withdrawals are a three-step process: initiation on L2, proving on L1 after the state root is submitted, and finalization after the 7-day challenge window. Exchanges must generate Merkle proofs against the state root posted to the L2OutputOracle and submit them to the OptimismPortal.proveWithdrawalTransaction function. Automate finalization via finalizeWithdrawalTransaction only after FINALIZATION_PERIOD_SECONDS has elapsed since the proposal. Missing the proof window or finalizing early can result in permanent fund loss.

Every Base transaction incurs an L2 execution fee and an L1 data fee. The L1 data fee is charged by the sequencer and can dominate costs during high L1 blob gas prices. Query the GasPriceOracle precompile at 0x420000000000000000000000000000000000000F to get l1BaseFee, l1BlobBaseFee, and the scalar values. Parse the l1Fee field from transaction receipts for accurate cost reconciliation. Failing to account for the L1 data fee in internal ledgers leads to balance mismatches.

Base uses standard Ethereum derivation paths (m/44'/60'/0'/0). Addresses derived from the same seed will be identical across Ethereum L1, Base, and other OP Stack chains. This is not a separate key type. However, exchanges must ensure their wallet infrastructure correctly sets the chainId (8453 for mainnet) when signing transactions to prevent replay across Superchain networks. Verify that internal address-generation logic does not apply any chain-specific salt or prefix.

Two USDC variants coexist on Base: bridged USDC.e (0xd9aAEc86B65D86f6A7B5B1b0c42FFA531710b6CA) and native USDC via Circle's CCTP (0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913). Exchanges must support both contracts, clearly label them in UIs, and never assume a single canonical USDC address. Deposit detection logic must monitor both contract addresses. Liquidity fragmentation means withdrawal paths may differ; native USDC can be burned and released on L1 via CCTP, while USDC.e requires the standard 7-day withdrawal flow.

Base's sequencer produces blocks every 2 seconds with a private mempool. While L2 reorgs are rare during normal operation, they can occur during sequencer failover or L1 reorgs that alter the derivation pipeline. Exchanges should wait for a minimum of 12 L2 block confirmations (24 seconds) before crediting deposits. For large withdrawals, monitor the L1 batch submission and state root proposal before considering funds as settled. Do not rely on a single RPC provider for confirmation; cross-reference against a self-hosted op-node.

Start with the official Base documentation when confirming chain metadata, RPC expectations, explorer references, bridge entry points, and developer-facing network behavior. Exchange teams should treat this as the first stop for integration assumptions, but should still validate production-critical details against live nodes and canonical contract registries before enabling deposits or withdrawals. Any internal checklist should record the Base mainnet chain ID, supported asset policy, RPC provider strategy, explorer fallback, and escalation contacts for incident handling.

Base is built on the OP Stack, so L1-originated deposits follow OP Stack deposit semantics rather than ordinary L2 transaction submission. Exchanges monitoring Base deposits should understand how deposits are initiated on Ethereum L1, relayed into the L2 execution environment, and represented in receipts and logs. This resource is useful when designing deposit crediting logic, distinguishing direct Base transactions from L1-originated deposits, and avoiding premature crediting before the L1 transaction and L2 inclusion path are both understood.

Withdrawals from Base to Ethereum L1 use the OP Stack withdrawal lifecycle: initiation on L2, proof on L1, and finalization after the applicable challenge period. Exchange withdrawal systems should model these stages explicitly instead of treating a Base withdrawal as a single transaction. This resource helps backend teams implement status tracking, user messaging, retry logic, proof generation checks, and finalization monitoring for withdrawals that exit Base through the canonical bridge path.

The Superchain Registry is the canonical source for OP Stack chain metadata used by infrastructure, wallets, explorers, and tooling. For Base integrations, use it to cross-check chain identifiers, public RPC metadata, explorer references, and Superchain-wide configuration assumptions. Do not hard-code registry-derived values without a review process; exchanges should pin known-good configurations, monitor upstream changes, and require change-control approval before modifying production deposit or withdrawal infrastructure.

The official Base node repository is the operational reference for teams running their own Base infrastructure rather than relying only on third-party RPC providers. Exchange and custody platforms should use it to validate op-geth and op-node deployment patterns, sync behavior, configuration files, and release notes. Running an internal node stack is especially important for independent deposit monitoring, reorg handling, receipt verification, and incident response when external RPC providers lag or disagree.

Use the Base status page as an operational signal for sequencer availability, RPC degradation, bridge delays, and network incidents. Exchanges should wire status-page checks into incident runbooks but should not rely on them as the only source of truth. Production monitoring should also include internal node health, L1 batch posting visibility, deposit latency, withdrawal proof and finalization queues, RPC error rates, and abnormal gaps between Ethereum L1 events and Base L2 observations.