Base bridge
Base bridge transfers reach their destination through separate execution steps
Base bridge transfers move supported assets into or out of Base through contracts connecting separate blockchain networks. The selected path determines which tokens arrive, how the destination processes them, and whether another transaction must complete delivery. Ethereum deposits, standard withdrawals, and transfers involving other networks follow different mechanisms. A successful source transaction confirms its own operation; completion also requires the expected asset to reach the intended recipient on the destination network.
· updated
A successful source bridge operation initiates the transfer; destination execution determines whether the recipient receives the expected asset.
The destination token determines whether a route fits
A usable route must connect the actual source network to Base, or Base to the intended destination, while delivering a compatible asset. ERC-20 describes a token interface, not universal bridge support. For an ERC-20 transfer, the destination token contract must match the token supported by the selected bridge. Matching names or symbols do not establish that relationship.
The former Base-hosted bridge website was deprecated. Bridging remains available through other interfaces and protocols, including Ethereum and Solana paths. An interface may also support fewer tokens than its underlying contracts. For a transfer into an application, compatibility includes the token contract that application accepts. Route availability, supported assets, and transaction limits remain specific to the selected service.
Standard withdrawals require destination finalization
A standard withdrawal from Base to Ethereum requires a proof and finalization after initiation, so source confirmation cannot make the destination funds immediately available. Initiation records the withdrawal message in the
L2ToL1MessagePasser
contract. Once the relevant Base state becomes available on Ethereum, a proving transaction establishes the message’s inclusion.
The portal checks the applicable proof and waiting requirements before finalization can proceed. A finalizing transaction then relays the withdrawal to its destination. Elapsed time alone does not submit that transaction. Withdrawal status therefore matters alongside the applicable waiting period: initiation, proof submission, and successful finalization describe different events. These requirements belong to the standard Ethereum withdrawal path, rather than every transfer leaving Base.
Standard Ethereum deposit events become transactions on Base
A standard Ethereum deposit reaches Base because Base nodes derive a destination transaction from the deposit event the Ethereum transaction emits. Ethereum supplies the originating record; Base executes the corresponding operation. In this relationship, Ethereum is layer 1, or L1, and Base is layer 2, or L2.
Base nodes derive Ethereum deposit transactions from events emitted by the L1 deposit contract. This mechanism makes deposits part of protocol processing. It does not require the recipient to create a separately signed Base transfer. Destination execution still matters: the deposited transaction has its own receipt and can encounter an execution failure. Confirmation on Ethereum and successful execution on Base therefore answer different questions.
The Solana connection uses validators and message proofs
The Base-Solana bridge transfers tokens through a separate system of contracts, a Solana program, and validators that authorize cross-chain messages. Depending on the token’s origin and transfer direction, the system locks or burns tokens before minting or unlocking their corresponding representation.
For transfers leaving Base, the bridge commits outgoing messages into a Merkle tree. This structure permits a proof that a particular message belongs to the committed set. Validators relay the relevant root to Solana, where proving and finalizing the message completes delivery. In the reverse direction, validator approval precedes execution on Base. For Solana-to-Base transfers, an optional relayer can handle execution on Base when the Solana transaction includes the required relay payment.
For Solana-to-Base transfers with attached contract calls, the call must be executable on Base. An incompatible call can leave associated tokens locked.
Liquidity delivery and exchange withdrawals follow different paths
A liquidity provider can deliver destination funds before the underlying standard withdrawal settles, while an exchange withdrawal can fund Base without a personal bridge transaction. These entry paths change who performs the cross-chain work and what the recipient must track.
With a liquidity route, a relayer or market maker supplies destination assets under that protocol’s rules. Availability depends on its supported assets and capacity. Faster delivery does not remove the settlement obligations behind the service.
A supported Coinbase withdrawal can send assets directly to Base by selecting Base as the withdrawal network. The exchange handles the outgoing transfer. That path applies to eligible balances held with the exchange; it does not move an existing balance from another blockchain wallet.
Token approval authorizes spending before the bridge call
An ERC-20 approval gives a specified contract permission to spend tokens, while the subsequent bridge operation initiates the transfer. A successful approval alone does not establish a cross-chain deposit. Its receipt records permission, rather than destination delivery.
The allowance identifies a spender and a spending limit. Those values deserve attention before signing because the permission can remain after an abandoned transfer. The allowance belongs to the token contract on the source network. Changing the selected bridge interface does not automatically remove it. Native ETH follows a different authorization pattern: the transaction carries its value directly, rather than using an ERC-20 token allowance.
Each execution step contributes to the transfer cost
The total cost follows the transactions and services the route requires, including source execution, destination processing, and any provider charges. An approval may add a separate transaction. A withdrawal may also require later transactions whose fees differ from the initial estimate.
Ordinary Base transaction costs include execution on Base and the cost associated with publishing transaction data to Ethereum. Standard Ethereum deposits handle destination gas through the L1 deposit mechanism instead. Consequently, a gas balance on one network does not automatically cover every stage elsewhere. Compare the quoted destination amount with the input, and identify any fees paid separately. If the route includes a swap, its exchange terms also affect the received amount.
When has a bridge transfer actually finished?
A transfer has delivered its assets when successful destination execution credits the intended recipient with the expected token and amount. The source receipt establishes what happened on the originating network. A destination receipt or transfer event establishes the receiving operation.
Wallet displays can lag behind chain records. An application may also require stronger confirmation than initial block inclusion before crediting a deposit. Base distinguishes early confirmation, block inclusion, and Ethereum-backed finality. Those confirmation levels describe confidence in a transaction’s persistence; they do not replace a bridge’s own completion requirements. The relevant endpoint is the destination operation the request promised, with the confirmation level the receiving service requires.
A token mismatch stops the request before commitment
In this hypothetical example, a transfer preview shows a destination token contract different from the one a receiving application accepts on Base. The source balance, proposed route, displayed output, and application requirement are hypothetical. The intended Base wallet must receive the token the application accepts.
Before signing, the wallet owner compares the proposed output contract with the application’s accepted contract and rejects the unsigned request because they differ. Closing the unsigned request leaves the source balance unchanged. If an earlier approval already succeeded, its allowance remains a separate permission to review.
A revised request becomes usable only if a supported route delivers the accepted token and its other terms remain acceptable. Assuming those conditions hold, the wallet owner submits the transfer. Its source receipt records initiation; the destination record identifies the token, recipient, and delivered amount.
In this hypothetical transfer, the destination record confirms that the intended Base wallet received the accepted token and agreed amount. If the output contract had changed before signing, the wallet owner would have rejected the revised request. After submission, a missing destination record leaves the transfer unresolved; repeating the deposit would create another request rather than reconcile the first.
Execution failures require the original message status
A failed destination operation requires inspection of its message and execution records because the source transaction may already have succeeded. Source rejection, pending inclusion, and destination failure represent different states. A reverted source bridge call does not create the same recovery problem as a confirmed deposit whose destination call failed.
The cross-domain messenger contracts support replaying failed messages. That capability applies to the relevant messenger path, rather than every bridge integration. Recovery requires the original message details and a condition that permits successful execution. A repeated source deposit creates a new operation. It does not repair an earlier message or resolve incompatible destination logic.
Linked records explain the balance change
Reconciliation connects the source operation to the destination credit through transaction identifiers, bridge events, and the actual token contracts. The standard bridge emits initiation and finalization events with transfer details. These records distinguish the bridge amount from gas costs and unrelated wallet activity.
Retain the source transaction hash, destination transaction hash when available, recipient, and route details. Public transaction records expose addresses and transfer activity, so bridging does not make the movement private. A wallet balance alone cannot explain every difference. If the route changes the token representation or includes an exchange, reconciliation must use that output contract and amount rather than assume identical balances across networks.
Useful questions about Base bridge
Does switching my wallet to Base move my existing funds?
Switching networks changes which blockchain the wallet displays; it does not transfer a balance. An address can have separate balances on Ethereum and Base. Moving assets requires a supported transfer operation, while selecting Base merely connects the wallet to that network. A missing balance after switching does not by itself indicate a failed bridge.
Do I need ETH on Base to receive a bridged token?
Receiving a token does not necessarily require the recipient to pay a separate Base transaction fee. Standard Ethereum deposits purchase their destination gas through the deposit mechanism. Spending the received token later generally requires ETH on Base, unless a supported sponsorship or payment arrangement covers execution. Other bridge routes may require separately funded destination execution.
Can a bridge deliver directly to an exchange deposit address?
Direct delivery requires the exchange to support the exact destination network, token, and deposit method. A valid address alone does not establish that support. The exchange must also recognize the resulting transfer before crediting its internal balance. Any exchange-specific deposit requirements apply in addition to successful bridge execution.
What happens if I bridge on Base Sepolia?
A transfer involving Base Sepolia operates on the test network rather than Base mainnet. Base mainnet uses chain ID 8453, while Base Sepolia uses 84532. Test balances remain separate from production balances even when the wallet address matches. Changing the wallet network does not convert test assets into mainnet assets.
Is a bridge also a token swap?
A bridge moves value between networks, while a swap exchanges one asset for another. Some routes combine both operations. In that case, the destination amount reflects the exchange terms as well as transfer charges. A bridge-only transfer can still deliver a different token contract representing the originating asset, without exchanging it for an unrelated asset.
Will closing the browser cancel a submitted transfer?
Closing the browser does not cancel a transaction the network has already accepted. Processing continues independently of the page. A route requiring a later proof, claim, or finalization still needs that operation. Retaining the original transaction hash allows the transfer to be located again without creating a duplicate request.
How can an earlier pending transaction delay a bridge submission?
For an externally owned account on Ethereum or Base, an earlier pending transaction can block later transactions because that account’s transaction nonces must execute in order. This source-side delay occurs before bridge processing begins. Increasing fees on a later transaction does not remove the earlier nonce dependency. Wallet replacement options apply to the pending transaction and do not reverse a completed bridge.