A cryptocurrency user managing assets across Ethereum, Solana, Polygon, and a dozen other networks faces a practical problem: consolidating wallets for convenience often means accepting centralized intermediaries or fragmented key management across multiple applications. The Bitget Wallet extension addresses this by providing non-custodial access to over 90 blockchains directly from a browser, eliminating the need to switch between specialized wallets for each network while retaining cryptographic control of private keys.
Understanding which chains are supported and how to configure them correctly is essential for avoiding transaction errors, missed opportunities in DeFi or NFT markets, and unnecessary platform switching. The Bitget Wallet extension, previously known as BitKeep, has evolved into a comprehensive multi-chain solution that spans layer-one networks, sidechain scaling solutions, and niche ecosystem tokens. This guide examines the full supported chain list, explains the mechanics of network switching, and clarifies the practical distinctions between chains that appear similar but operate under different economic and security models.
The architecture of a multi-chain wallet extension
A multi-chain wallet extension must solve a fundamental design problem: how to manage a single set of cryptographic keys while interacting with blockchains that have different address formats, signature schemes, and fee structures. The Bitget Wallet extension achieves this by maintaining one or more BIP-44 hierarchical deterministic wallets that can derive addresses on multiple chains from the same recovery seed. This means that a user can back up a single 12 or 24-word phrase and access wallets on Ethereum, Solana, Polygon, Bitcoin, and dozens of others without storing separate recovery information for each network.
However, this architectural efficiency masks important distinctions. Ethereum-compatible chains (EVM chains) all use the same address format and signing mechanism, which means an address like 0x742d35Cc6634C0532925a3b844Bc9e7595f42bE can theoretically exist on Ethereum, Polygon, Avalanche, Fantom, and other EVM networks simultaneously. A non-custodial Ethereum wallet or Solana wallet must handle this reality carefully: sending funds to the correct chain matters absolutely, because sending ETH to an Ethereum address on the Polygon network will not arrive on Ethereum, and recovery requires knowledge of the receiving wallet on Polygon.
The Bitget Wallet extension reduces this risk by enforcing network selection before transaction signing. When a user initiates a transfer, they must confirm both the destination address and the selected network. That confirmation step is not merely a convenience; it is a critical control that prevents the most common class of multi-chain wallet errors: sending an asset to the correct address but the wrong chain. The extension also stores private keys locally on the user’s device, encrypted according to standards such as the OWASP Cryptographic Storage Cheat Sheet, rather than holding them on a server.
Multi-platform availability across Chrome extension, iOS, Android, Windows, and Mac introduces a secondary consideration: the private key encryption standard should be consistent across platforms, and biometric authentication should integrate with the operating system’s secure enclave or equivalent hardware security features. The bitget wallet extension uses local encryption and device-level biometric support, meaning that the wallet software itself does not hold decrypted keys in memory longer than necessary, and unlocking the wallet on a phone requires facial recognition or fingerprint verification backed by hardware security.
Ethereum, Polygon, and the EVM ecosystem within the extension
Ethereum represents the largest and most mature smart contract ecosystem, and compatibility with Ethereum’s virtual machine (EVM) has become the de facto standard for blockchain interoperability in Web3. The Bitget Wallet extension supports Ethereum mainnet, and because Ethereum wallets operate within a standard EVM framework, the extension can also support any blockchain that implements EVM compatibility. This includes Polygon, Avalanche (C-Chain), Fantom, Optimism, Arbitrum, Base, Linea, Scroll, and dozens of others, all within the same extension interface.
The distinction between these networks is not merely one of naming or cosmetic branding. Ethereum mainnet settles transactions approximately every 12 seconds and incurs gas fees denominated in ETH. Polygon, a sidechain using a delegated proof-of-stake consensus model, settles transactions in approximately 2 seconds with fees denominated in MATIC. Optimism and Arbitrum are layer-two rollups that batch transactions off-chain, settle periodically to Ethereum, and charge fees in ETH but at a fraction of mainnet costs because they compress multiple user transactions into a single on-chain batch. An Ethereum wallet managing assets across multiple EVM chains must therefore understand that each network has distinct fee dynamics, confirmation times, and economic security assumptions.
Interacting with these networks through the extension follows a consistent pattern: the user selects the network from the dropdown menu, confirms their balance in the native asset of that chain, and initiates transactions. However, balance display requires care. An address on Ethereum mainnet will have a different balance than the same address on Polygon, Arbitrum, or Optimism, because transactions do not automatically propagate between chains. A user who sends 1 ETH to an address on Ethereum cannot spend that ETH on Polygon without explicitly using a cross-chain bridge, which introduces additional steps, fees, and temporary liquidity risk during the bridging process.
The extension’s built-in DEX aggregation helps, as it can route swaps across liquidity sources on multiple chains, but each transaction remains chain-specific unless a cross-chain protocol explicitly coordinates the transfer. Ethereum.org provides detailed documentation on how EVM networks operate and how addresses are derived, and users who switch frequently between chains benefit from consulting this reference to understand transaction finality and the role of gas fees in network economics.
Solana, non-EVM architectures, and address format differences
Solana represents a fundamentally different blockchain architecture than Ethereum or its EVM-compatible clones. Rather than using the EVM’s stack-based bytecode execution model, Solana uses a parallel processing architecture where validators execute transactions concurrently across many cores. This architectural difference changes how addresses work, how transactions are signed, and how wallets interact with the network. A Solana wallet does not reuse the same 0x-format address as Ethereum; instead, Solana addresses are base-58 encoded strings that begin with a letter, such as 9B5X3cg7NZwvG7YRZN5j8k2mL4pQ6rStU1vW3xYzA.
The Bitget Wallet extension generates a separate Solana address from the hierarchical deterministic seed, so the user’s Solana address differs from their Ethereum address even though both derive from the same recovery phrase. This separation is by design: Solana and Ethereum use different signature schemes and address formats, and an address format mismatch is the fastest way to permanently lose funds sent to the wrong network. The extension manages this by clearly displaying the selected network and the address format associated with it; a user switching from Ethereum to Solana in the network dropdown will see the Solana address immediately, not the Ethereum address.
Solana’s performance characteristics also differ. Transactions confirm in approximately 6-12 seconds under normal network conditions, and transaction fees are measured in SOL and typically cost less than one cent per transaction, even during periods of moderate congestion. This low fee environment has enabled high-frequency trading, arbitrage, and on-chain gambling without economic friction, but it has also created a target for transaction front-running and sandwich attacks, where bots observe pending transactions and insert their own transaction between the user’s transaction and its confirmation.
The Solana wallet functionality integrated into the extension therefore serves a different use case than the Ethereum wallet. Users who frequently execute small transactions, trade on Solana-based DEXes, or participate in GameFi assets on Solana may find the Solana wallet component indispensable for cost efficiency. Those primarily using Ethereum or interested in larger DeFi positions may use the Solana component rarely. The extension’s support for both networks side-by-side allows users to optimize for each use case without maintaining separate wallets or recovery phrases.
The complete chain list: layer-ones, sidechains, and token-specific networks
The 90+ supported blockchains break down into several categories. Major layer-one networks include Ethereum, Solana, Bitcoin, Cardano, Polkadot, Cosmos, and Tezos. Layer-two scaling solutions built on Ethereum include Optimism, Arbitrum, Polygon, Skale, and Starknet. Cosmos-based blockchains accessed through the extension include chains like Osmosis, Juno, and Akash, which share a common SDK but operate as independent networks. Bitcoin and its derivatives, including the Stacks layer-two for Bitcoin smart contracts, represent another category. EVM-compatible sidechains and testnets include a variety of networks that are either discontinued, used for development only, or operate as smaller ecosystem alternatives.
The complete list includes Ethereum, Polygon, Solana, Bitcoin, Optimism, Arbitrum, Avalanche, Fantom, Binance Smart Chain, Cosmos, Polkadot, Cardano, Litecoin, Dogecoin, Ripple (XRP Ledger), Tezos, Neo, EOS, Tron, Stacks (Bitcoin layer-two), Harmony One, Celo, Aurora (NEAR scaling), Sui, Aptos, Moonbeam, Moonriver, Acala, Karura, Astar, Shiden, Algorand, Hedera, Zilliqa, Polygon Zkevm, Linea, Scroll, Base, Zora, Mantle, Taiko, Manta, and dozens of additional networks covering both large established ecosystems and emerging layer-two or alternative-execution-model blockchains. Each network has its own token standard, fee structure, finality assumption, and DeFi ecosystem, meaning that a multi-chain wallet extension must handle significant complexity to present all options coherently.
The wallet’s handling of this diversity requires users to be cautious about network selection. A token symbol like “USDC” exists on Ethereum, Polygon, Solana, Arbitrum, Avalanche, and numerous other networks, but the USDC on Ethereum is not identical to USDC on Polygon—they are distinct assets managed by different smart contracts, even though they are designed to maintain price parity and can be converted through official bridges. Sending Ethereum-based USDC to a Polygon address will not convert it to Polygon USDC; instead, it will either fail or be received as a smart contract token that is not recognized as USDC on Polygon.
Adding networks and switching between chains in the extension
The process of adding a new network to the Bitget Wallet extension begins with opening the network selection menu, typically located in the top-right or left area of the extension interface. Most major chains are pre-loaded, requiring only a single click to activate. However, for smaller or newer blockchains, or for custom rollups and testnets, the extension provides an “Add Network” or “Add Custom RPC” option that requires manual configuration.
To add a custom network, the user must provide the RPC endpoint (the server address used to communicate with the blockchain), the chain ID (a numeric identifier that prevents transaction replay across chains), the currency symbol (typically the native token of the network), and optionally the block explorer URL. This information is available from official blockchain documentation or chain specification databases. For example, Polygon mainnet has a chain ID of 137, uses MATIC as its currency, and has public RPC endpoints provided by the Polygon Foundation and by commercial services such as Alchemy or Infura.
The extension stores these custom network configurations locally on the user’s device. They do not synchronize across devices by default, meaning that a custom network added to the Chrome extension will not automatically appear on the iOS mobile wallet unless the user repeats the configuration. This local-storage approach enhances privacy—the wallet does not log which networks a user has configured—but it requires manual setup if the user wants identical configurations across platforms.
Switching between networks is straightforward: the user clicks the network selector and chooses a network from the list. The extension updates the displayed address, balance, and transaction history to reflect the selected network. However, the speed of balance updates depends on the RPC endpoint’s responsiveness and how recently the blockchain has confirmed new blocks. If a user sends a transaction on Ethereum and immediately switches to Polygon, they should expect to see the Ethereum balance update within a few seconds once the transaction is confirmed, but they will not see that same transaction in the Polygon transaction history because it never occurred on Polygon.
Security considerations across 90+ chain support
Supporting 90+ blockchains introduces a surface area for error that single-chain wallets do not face. The most obvious risk is sending an asset to the wrong chain. Less obvious risks include using an RPC endpoint that is not trusted, configuring a custom network with incorrect parameters, and failing to understand the distinct privacy or security properties of each blockchain. A transaction on a small sidechain with ten validators has different security assumptions than a transaction on Ethereum mainnet with thousands of validators. A transaction on Monero has privacy properties built into the protocol; a transaction on a transparent blockchain like Ethereum is permanent and publicly visible, even if the user attempts to conceal their identity.
The Bitget Wallet extension uses local encryption for private keys according to standards established in NIST cryptographic guidelines, and it supports biometric authentication and two-factor authentication to prevent unauthorized access to the wallet on a user’s device. However, these controls apply only if the user’s recovery phrase has been backed up securely and the backup is not stored in a location that an attacker can access, such as cloud storage, a text file on the desktop, or an email account.
Hardware wallet integration with Ledger and Trezor provides an additional layer. Rather than storing private keys in the extension, the user can connect a hardware device and authorize transactions on the device itself. This means that even if the computer running the extension is compromised, the private keys remain isolated on the hardware wallet and an attacker cannot sign transactions without physical access to the device. The trade-off is a slightly slower transaction workflow, as each transaction requires confirmation on the physical device.
Cross-chain bridge security represents another category of risk distinct from wallet security. If a user uses the extension to access a token swap that involves bridging between networks, they are trusting the bridge contract in addition to the wallet. Bridge exploits have resulted in loss of funds on multiple occasions; the bridge risk is not eliminated by using a non-custodial wallet, because the user’s private key signs the transaction that initiates the bridge operation, but the bridge protocol itself can be vulnerable to attacks independent of wallet security. The FCA has published guidance on cryptocurrency wallet risks, which includes discussion of third-party protocol risk.
DeFi integration and yield farming across multiple chains
One of the primary advantages of the Bitget Wallet extension is built-in integration with decentralized finance protocols on all supported chains. Rather than navigating to a separate website and connecting the wallet through a Web3 provider, users can access token swaps, liquidity pools, and yield farming opportunities directly from within the extension interface. The integrated DEX aggregation searches multiple decentralized exchanges on the selected chain and displays the best available rate for a token swap, accounting for slippage and fees.
Yield farming opportunities vary significantly by chain. Ethereum mainnet hosts large, well-established DeFi protocols with billions in total value locked, but gas fees for entering and exiting positions are substantial—often $50 to $500 for a single transaction depending on network congestion. Polygon, Arbitrum, and Solana offer lower-fee DeFi, but with smaller total liquidity pools and higher relative risk of smart contract exploits on less-tested protocols. The Bitget Wallet extension’s ability to monitor positions across all chains simultaneously is useful, but it does not eliminate the need to evaluate each protocol’s security audit status and the reliability of the validators securing each chain.
Users engaging in yield farming should also understand impermanent loss, which occurs when the relative prices of two assets in a liquidity pool diverge significantly. Providing liquidity to a pool that pairs two volatile assets can result in a loss even if the user’s total asset value increases in nominal terms. The extension displays APY (annual percentage yield) estimates from integrated protocols, but these are forward-looking projections and do not account for the user’s personal entry and exit timing or price volatility.
NFT marketplace and asset management features
The Bitget Wallet extension includes an integrated NFT marketplace and gallery. This feature allows users to view NFTs held in their wallet across all supported chains, browse listings on decentralized NFT marketplaces such as OpenSea, Magic Eden, and others, and execute purchases directly from the extension without navigating to external websites. The gallery display aggregates NFTs across all chains and provides metadata, including rarity rankings if available from the original collection.
NFT transactions carry the same chain-specific risks as any other crypto transaction. An NFT purchased on Solana is not automatically accessible on Ethereum; the user must bridge it explicitly or manually transfer it using a cross-chain bridge protocol. Marketplace smart contracts can be exploited, and popular collections have been subject to rug pulls, where creators suddenly withdraw liquidity or cease development. The Bitget Wallet extension’s integration of marketplace features does not perform security auditing of the NFT smart contracts themselves; it provides access and transaction execution, leaving evaluation of NFT legitimacy and project sustainability to the user.
GameFi assets, which include in-game tokens and NFTs that function as characters, items, or land in blockchain-based games, are supported in the same manner as standard NFTs and tokens. The wallet can display GameFi asset balances and facilitate transfers between wallets or to gaming platforms, but the liquidity, price stability, and long-term viability of GameFi tokens vary widely by project and are subject to game development decisions outside the wallet’s control.
Frequently asked questions
Does the bitget wallet extension support all of the blockchains I need, and how do I check the complete chain list?
The extension supports 90+ blockchains including Ethereum, Solana, Polygon, Bitcoin, and numerous others across layer-ones, sidechains, and layer-twos. To view all supported networks, open the extension and click the network dropdown menu. Most major chains are pre-loaded; additional networks can be added through the “Add Custom RPC” option if you have the official RPC endpoint and chain ID.
Can I use the same address across multiple chains in the bitget wallet extension?
EVM-compatible chains (Ethereum, Polygon, Avalanche, Fantom, Optimism, Arbitrum, and others) use the same address format and the same address is technically valid on all of them. However, balances and transaction history are distinct for each chain. Solana, Bitcoin, Cosmos, and other non-EVM networks use different address formats and generate separate addresses from your recovery phrase. Never send an asset to an address without confirming the network, even if the address format appears familiar.
What is the risk of using the bitget wallet extension with so many blockchains supported?
The primary risk is sending assets to the wrong network; the address may be valid, but the asset will not arrive on your intended chain and recovery is complex or impossible. Secondary risks include RPC endpoint security (which affects transaction visibility but not private key safety), smart contract risk on smaller chains with fewer validators, and bridge risk when converting between networks. Always verify the network selection before signing a transaction, and use a hardware wallet for large balances.
