Basebridge transfers depend on the asset and destination network

The starting network determines the available route

Funds already in a wallet on another blockchain need a bridge supporting that exact connection to Base. The starting network identifies where the spendable balance exists. A wallet showing the same account address across networks does not combine those balances. The selected route must recognize both the source asset and its destination counterpart.

Funds held by an exchange create a different starting point. When the exchange supports withdrawals of the selected asset directly onto Base, it handles delivery through its withdrawal service. Sending those funds elsewhere first adds another transfer. Availability belongs to the exchange’s asset and network configuration, so support for one token does not establish support for another.

The former Base-operated bridge interface was deprecated. Existing standard bridge contracts and other supported interfaces provide separate paths; an old interface name does not establish current availability.

A supported token must arrive in a usable form

For ERC-20 transfers, the route must support the source token and its corresponding contract on the receiving chain. A ticker alone cannot distinguish separate tokens sharing a name. Standard bridging can lock an original token and mint its bridged representation elsewhere. Returning that representation reverses the corresponding accounting through burning and release. An application on Base may accept only a particular representation, even when alternatives describe the same underlying asset. Decide which contract the receiving application accepts before selecting the transfer. Otherwise, a technically completed bridge can leave a balance the intended application cannot use.

Standard deposits connect Ethereum execution to Base

Base’s standard bridge contracts support transfers of ETH and supported ERC-20 tokens between Ethereum and Base. Ethereum is the underlying layer-one network; Base processes transactions on its layer-two network. The contracts communicate across those networks to carry out the corresponding transfer. A deposit begins with an Ethereum transaction, whose recorded data lets Base derive the destination deposit transaction.

The source confirmation and destination execution are distinct events. An Ethereum receipt establishes what happened on Ethereum, while the Base transaction establishes destination execution. This distinction explains why confirmation in the sending wallet need not coincide with the receiving balance appearing. Deposit processing also differs from an ordinary Base transaction: the Ethereum deposit event supplies authorization for the derived transaction. A standard deposit does not follow the withdrawal proving process described below.

Why does a standard withdrawal need more than wallet confirmation?

A standard withdrawal needs proof and finalization on Ethereum after the initiating transaction on Base. The initial transaction records a withdrawal message. A proving transaction establishes that message against the relevant Base state. The challenge period gives network participants time to dispute an invalid state claim. Finalization releases the assets once the waiting period and other verification conditions are satisfied. Confirmation on Base therefore establishes initiation rather than completed delivery on Ethereum. Before choosing this path, account for the remaining transactions and the delay before finalization becomes available. A destination deadline may make a different supported route more suitable, provided its own delivery conditions fit the task.

Liquidity changes when the recipient can receive funds

Liquidity-based bridges can pay the recipient before a standard withdrawal finishes its settlement process. A provider supplies assets already available on the destination network, then settles its position through the bridge’s mechanism. The recipient’s earlier access comes from that available liquidity. It does not shorten the underlying standard withdrawal’s verification requirements.

This creates a different dependency: the route needs sufficient destination liquidity and an available provider for the selected transfer. A usable quote for one amount does not establish capacity for every amount. Compare the destination token and received amount alongside the expected delivery conditions. A route involving a swap also introduces an exchange between assets, so minimum-output conditions matter.

Other entry paths use different transfer systems

Transfers involving networks outside the Ethereum-to-Base standard bridge use their own supported mechanisms. Base has routes involving Solana and Bitcoin, with different asset formats and transfer infrastructure.

The Base-Solana bridge supports token transfers and messages between those networks. Bitcoin routes can deliver a representation usable on Base rather than native bitcoin on its original chain. The receiving asset’s identity therefore remains part of the route choice. A connection between networks does not imply universal support for everything issued on either network.

Open full-size image

Exchange withdrawals form another entry path, with the exchange handling the delivery request. Bridge compatibility, exchange withdrawal support and destination application acceptance are separate conditions.

The receiving account must work on the destination

The recipient must be an account you can control on the receiving network, or a supported deposit address. Smart contract wallets need particular attention because the same address on separate chains need not contain the same wallet code. An address copied from the starting network does not prove destination access. For an exchange recipient, its deposit service must accept the exact destination network and token representation. Some bridges allow a separate recipient address, but support varies. Resolve this before signing: changing the wallet’s network display afterward cannot change the recipient recorded in an executed transfer.

What does a token approval authorize?

A token approval authorizes a specified spender to transfer tokens within the allowance you grant. Standard token bridging may require this permission before the bridge can take the input tokens. An approval transaction alone does not complete the bridge transfer.

Review the token, spender and permitted amount as separate parts of the authorization. A larger allowance exposes more of that token balance to the spender’s permitted actions. Native ETH transfers use a different mechanism and do not require an ERC-20 allowance for ETH itself. Wallet connection, token authorization and transfer execution therefore have different effects. A signing request should correspond to the action being taken, rather than merely displaying a familiar application name.

Gas funding affects whether the transfer is executable

The sending account needs the gas asset required for its transaction, unless the chosen service explicitly handles payment another way. A sufficient token balance alone may not cover execution.

Base uses ETH for gas. Later activity on Base needs gas funding even when the incoming asset is another token. A standard withdrawal may also require transactions on Ethereum, creating a separate funding need there. Reserve the balance needed for those actions before committing the transfer amount.

Bridge fees and network fees describe different charges. Route selection should account for the expected destination amount and any additional transactions the route requires, without assuming the first displayed charge covers completion.

The next action depends on whether funds have moved

Before submission, an unavailable route leaves room to change the selection or stop without initiating a transfer. After submission, the transaction’s actual state determines the available action. A failed source transaction, a completed source transaction awaiting destination processing and a withdrawal awaiting finalization require different responses. Starting another transfer does not repair the original one and may commit additional funds. Retain the transaction identifier and use it to identify the existing transfer before taking further action. Once the destination account holds the intended asset, any return transfer is a new operation governed by the reverse route’s support and conditions.