Depositing ETH and ERC-20 tokens from Ethereum L1 to Base is the foundational integration pattern for exchanges, custodians, and wallets. Unlike a simple transfer, a deposit is an L1 transaction that emits an event instructing the Base sequencer to credit funds on the L2. Integrators must interact with the correct L1StandardBridge and OptimismPortal proxy contracts, not the implementation contracts, to ensure upgrade compatibility. The canonical addresses for these proxies are fixed and must be hardcoded into any deposit service.
Protocols
Bridging ETH and ERC-20s to Base
A technical integration guide for exchanges, custodians, and wallets on depositing ETH and ERC-20 tokens to Base via the canonical bridge. Covers contract addresses, L1 finality, and programmatic deposit tracking.
introduction
CANONICAL DEPOSIT PATTERNS
Introduction
Operational guide for moving ETH and ERC-20s from Ethereum L1 to Base using the canonical bridge contracts.
The operational challenge is not the transaction submission but the deposit monitoring lifecycle. After an L1 transaction is confirmed, the corresponding L2 credit is not instant. The sequencer must include the deposit in a batch, and the L2 block must reach a safe confirmation depth. For exchanges, this means a deposit is not spendable until the L2 transaction receipt is observed with sufficient finality. Using the TransactionDeposited event from the OptimismPortal as the sole trigger is insufficient; integrators must correlate the L1 event with the L2 eth_getTransactionByHash result to confirm the deposit's indexed status on Base.
ERC-20 deposits introduce an additional layer of complexity: the distinction between bridged representations and native assets. Tokens deposited via the canonical bridge become bridged versions (e.g., USDC.e), which are distinct from native tokens issued directly on Base (e.g., native USDC via Circle's CCTP). Integrators must map the correct L2 contract address for each asset and understand the liquidity and trust implications of each representation. Chainscore Labs can audit a team's deposit-flow logic, address-mapping registry, and finality-monitoring service to prevent misrouted funds and ensure alignment with Superchain-wide conventions.
BRIDGING ETH AND ERC-20S TO BASE
Integration Quick Facts
Operational facts for exchanges, custodians, and wallets integrating native ETH and ERC-20 deposits to Base via the canonical bridge.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Deposit finality | Deposits are not final until the L1 transaction has enough confirmations and the sequencer includes the deposit on L2. The L1 finality delay is a critical risk window. | Exchanges, custodians, wallets | Do not credit user accounts until the deposit transaction is indexed on Base with a safe number of L2 block confirmations. |
Canonical bridge contracts | Deposits must be sent to the L1StandardBridge or L1CrossDomainMessenger proxy contracts on Ethereum L1. Using an incorrect address results in permanent fund loss. | All integrators | Verify the canonical bridge contract addresses against the official Base documentation before integrating. Do not hardcode addresses without a review. |
ERC-20 token mapping | An ERC-20 on L1 is not automatically available on Base. It must be deployed or mapped via the bridge, creating a distinct L2 token address. | Wallet teams, DeFi protocols | Maintain a strict mapping between L1 and L2 token addresses. Do not assume the L2 address is the same as the L1 address. |
Deposit monitoring | A deposit transaction on L1 does not emit an event on L2 until processed by the sequencer. Monitoring only the L1 transaction is insufficient. | Backend services, indexers | Monitor both the L1 deposit transaction and the resulting L2 transaction receipt to confirm a successful deposit. Use the Optimism SDK or indexer for reliable tracking. |
ETH deposit method | Sending ETH directly to the bridge contract will not trigger a deposit. The correct method is to call | Wallets, exchanges | Ensure your integration calls the correct function on the bridge contract with the appropriate gas limit. Test on Base Sepolia first. |
Gas costs | The cost to finalize a deposit on Base includes the L1 transaction gas and the L2 execution gas, which is paid by the depositor on L1. | Wallets, exchanges | Accurately estimate and display the total L1 gas cost to users before they submit a deposit transaction. Use the GasPriceOracle precompile for L2 fee estimation. |
Sequencer downtime | If the Base sequencer is down, deposits initiated on L1 will be delayed until the sequencer restarts and processes the backlog. | All integrators, risk teams | Implement monitoring for sequencer health. Communicate deposit delays to users and have a support process for stuck transactions. |
technical-context
L1 TO L2 MESSAGE PASSING
Deposit Architecture and Lifecycle
The canonical path for moving ETH and ERC-20s from Ethereum mainnet into Base relies on a set of immutable bridge contracts and a deposit lifecycle governed by L1 finality.
Depositing assets to Base is not a simple token transfer but an L1-to-L2 message-passing operation. Users and integrators must interact with the canonical L1StandardBridge or the OptimismPortal proxy contracts deployed on Ethereum mainnet. For ETH deposits, value is sent directly to the OptimismPortal, which emits a TransactionDeposited event. For ERC-20s, the L1StandardBridge locks tokens on L1 and sends a message to mint a corresponding representation on Base. The exact contract addresses are fixed per network and must be verified against the official Superchain registry to avoid interacting with malicious clones.
The deposit lifecycle has two distinct phases: L1 finality and L2 execution. After an L1 transaction is included in a block, integrators must wait for a configurable number of block confirmations—typically 12 to 15 blocks on Ethereum—before the sequencer will include the deposit in a Base block. This finality delay is a critical safety parameter that prevents deposit inclusion from reorganizing out of the canonical chain. Once the deposit is picked up by the sequencer, the corresponding ETH or ERC-20 balance is credited on Base, and the transaction appears as a deposit type in the block. Monitoring this lifecycle requires indexing both L1 TransactionDeposited events and the resulting L2 transaction receipt.
Operational risk concentrates on the L1 finality window and the bridge contract upgradeability. While the OptimismPortal and L1StandardBridge implementations are immutable in practice, the proxy pattern means the Security Council retains the theoretical ability to upgrade the logic. Teams running automated deposit systems must build in configurable confirmation depth, handle reorg detection on L1, and reconcile internal ledgers against both the L1 event and the L2 balance state. A deposit that appears confirmed on L1 but is not yet executed on Base represents an in-flight state that must be tracked explicitly in any accounting system.
BRIDGING INTEGRATION IMPACT
Affected Systems and Teams
Exchange and Custody Integration
Exchanges and custodians must implement a deposit monitoring system that watches for TransactionDeposited events emitted by the OptimismPortal contract on L1. Unlike standard Ethereum deposits, funds are not immediately available; services must track the L1 finality delay and the sequencer's batch inclusion before crediting users.
Critical actions:
- Monitor the canonical
OptimismPortalproxy address on L1 for deposit events. - Do not credit user balances until the deposit transaction is included in a Base block and the block has reached a safe confirmation depth.
- Implement withdrawal processing that handles the three-stage lifecycle: initiation on Base, proving on L1 after the fault-proof window, and finalization.
- Reconcile fee accounting to include the L1 data fee component in any pass-through cost models.
Chainscore Labs can review your deposit-flow architecture and withdrawal relayers to prevent mis-crediting or loss of funds.
implementation-impact
BRIDGING ETH AND ERC-20S TO BASE
Implementation Workflow and Patterns
Canonical patterns for exchanges, custodians, and wallets to integrate native ETH and ERC-20 deposits to Base. Covers contract addresses, finality delays, and programmatic deposit monitoring.
02
L1 Finality and Deposit Confirmation
A deposit is not final on Base until the corresponding L1 transaction achieves sufficient finality. Exchanges and custodians must wait for a minimum number of L1 block confirmations before crediting a user's Base account. This delay protects against L1 chain reorganizations that could invalidate the deposit. The recommended confirmation depth is a risk parameter that should be tuned based on the value of the deposit. Monitoring services should track the deposit transaction's status on L1 and only emit a 'complete' event after the required number of confirmations.
03
Programmatic Deposit Monitoring
To track a deposit lifecycle, monitor the TransactionDeposited event emitted by the OptimismPortal contract on L1. This event contains the sender, recipient, and calldata for the L2 transaction. After the L1 block is finalized, the sequencer will include the deposit in a future L2 block. Backend services should index these events and correlate them with the resulting L2 transaction receipt to provide users with a complete deposit status. A robust monitoring service must handle reorgs on both L1 and L2 to prevent double-crediting.
04
ERC-20 Token Mapping and Gateway Logic
Standard ERC-20s are bridged via the L1StandardBridge to a corresponding L2StandardERC20 contract on Base. The L2 token address is deterministically derived from the L1 token address. For non-standard tokens, the L1CustomGateway allows for custom bridging logic. Integrators must not assume all tokens use the standard bridge. A pre-integration audit should verify the correct gateway for each token and confirm the L2 representation's behavior, including decimals and metadata, matches expectations to avoid display errors in wallets and exchanges.
BRIDGING ETH AND ERC-20S TO BASE
Integration Risk Matrix
Operational risks and required actions for exchanges, custodians, and wallets integrating the canonical Base bridge for deposits.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Deposit Finality | Deposits are not final until the L1 transaction has enough confirmations and the sequencer includes the corresponding L2 transaction. This is not instant. | Exchanges, Custodians | Implement a deposit monitoring service that tracks L1 finality and L2 inclusion. Do not credit users before L2 block confirmation. |
Canonical Bridge Contracts | Funds must be sent to the correct L1StandardBridge or L1CrossDomainMessenger proxy addresses. Using an incorrect or outdated address results in permanent loss. | Wallets, Exchanges, Protocols | Hardcode and verify the canonical bridge contract addresses against the official Base documentation and Superchain registry before any mainnet transaction. |
ERC-20 Token Mapping | An L1 token is not automatically available on Base. A bridged representation must exist. Sending to the bridge without a mapped L2 token can lock funds. | DeFi Protocols, Wallets, Custodians | Verify the L2 token address mapping for every ERC-20 before initiating a deposit. Query the bridge contract's state to confirm the mapping exists. |
Sequencer Downtime | If the Base sequencer is down, L1 deposits will not be processed into L2 blocks. Funds are safe in the bridge contract but inaccessible on L2. | Exchanges, Wallets, Users | Monitor the sequencer status endpoint. Display a clear warning to users during downtime and delay deposit crediting until L2 inclusion is confirmed. |
Deposit Monitoring Logic | A naive block explorer API call may miss a deposit transaction if it is reorged or delayed. This leads to incorrect user balances. | Exchange Backend Engineers, Data Teams | Build a resilient monitor that uses L1 block confirmations and L2 transaction receipts. Do not rely solely on L2 block explorers for deposit status. |
Gas Cost Estimation | Deposits are L1 transactions. The gas cost is paid in ETH on L1 and is unrelated to L2 gas fees. Underestimating L1 gas can cause stuck deposits. | Wallets, Custodians | Clearly separate L1 gas estimation for the deposit transaction from L2 execution fees. Use an L1 gas oracle for accurate estimates. |
Bridge Upgradeability | The canonical bridge contracts are upgradeable proxies. A future upgrade could alter deposit logic, introduce fees, or pause the bridge. | Risk Teams, Protocol Architects | Monitor governance proposals and multisig activity for bridge contract upgrades. Assess the trust assumptions and operational impact of any change. |
Self-Operated Bridges | Running a custom bridge relayer or using a non-canonical bridge introduces additional smart contract risk and liveness dependencies. | Protocols, Institutional Operators | Conduct a full security audit of any alternative bridge contract. Chainscore Labs can review the integration path and failure modes for custom bridge solutions. |
BRIDGING ETH AND ERC-20S TO BASE
Deposit Integration Rollout Checklist
A step-by-step verification checklist for exchange, custody, and wallet engineering teams integrating ETH and ERC-20 deposits from Ethereum L1 to Base. Each item confirms a critical integration point is correctly implemented and monitored before production rollout.
Verify that your integration uses the correct, immutable L1 contract addresses for the Base bridge system. Using an incorrect or unofficial address will result in a permanent loss of funds.
- What to check: Hardcode or configure the
L1StandardBridgeproxy address (0x3154Cf16ccdb4C6d922629664174b904d80F2C35) and theOptimismPortalproxy address (0x49048044D57e1C92A77f79988d21Fa8fAF74E97e) on Ethereum mainnet. For ERC-20s, ensure theL1StandardBridgeis the target, not theL1CrossDomainMessenger. - Why it matters: These proxy contracts are the sole entry point for canonical ETH and ERC-20 deposits. Deposits sent to the implementation contracts or an old portal will be lost.
- Readiness signal: Your integration test successfully deposits testnet ETH and an ERC-20 via these exact addresses and the funds are credited on Base testnet. Mainnet addresses are confirmed against the Base documentation and the Optimism Superchain Registry.
resource-links
BASE BRIDGE INTEGRATION REFERENCES
Canonical Resources
Use these sources to verify Base bridge behavior, contract metadata, operational status, and indexing assumptions before enabling ETH or ERC-20 deposits in production.
Chains We Build On
Looking to build on a specific blockchain?
We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.
EVM ecosystems
- Ethereum
- Arbitrum
- Optimism
- Polygon
- Avalanche
- Cronos
Non-EVM ecosystems
- Solana
- Sui
- Aptos
- Hedera
- Stellar
- NEAR
Additional ecosystems
- Polkadot
- Cosmos
- TON
- Cardano
- Algorand
- Tempo
Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.
BRIDGING ETH AND ERC-20S TO BASE
Frequently Asked Questions
Operational questions for exchanges, custodians, and wallets integrating the canonical deposit flow for ETH and ERC-20 tokens on Base.
Monitoring must cover the L1 canonical bridge contracts, not the L2 token addresses.
What to check:
- L1StandardBridge:
0x3154Cf16ccdb4C6d922629664174b904d80F2C35(Ethereum mainnet). This is the primary entry point for ETH and standard ERC-20 deposits. - L1CrossDomainMessenger: Used internally by the bridge for message passing. While direct user interaction is rare, monitoring this contract can provide an early signal of deposit initiation.
- OptimismPortal: The final L1 contract that emits
TransactionDepositedevents. This event is the canonical signal that a deposit has been sequenced.
Why it matters:
Monitoring only the L2 token contract will miss the deposit entirely. A deposit is an L1 transaction; its existence is proven by the TransactionDeposited event emitted by the OptimismPortal.
Signal of readiness:
Your indexer successfully parses TransactionDeposited events where the from address is the L1StandardBridge and the to address is the target on Base.
Trusted by Industry Leaders
Delivering blockchain solutions for 5+ years.
We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.
Selected Partners & Clients
“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”
L
Lee Erswell
CEO, Telos Foundation
how to get started
How to get started?
If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.
01
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
02
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
03
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
04
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
Explore More Solutions
Discover our
blockchain development services.
We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.
Book a Call
Start a build
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.