A Solana developer preparing to test a smart contract faces a practical workflow problem: managing accounts across devnet, testnet, and mainnet requires isolating funds, maintaining separate keys, and switching networks frequently without risking production assets. The standard approach uses command-line tools and file-based keypair management, which is effective but operationally cumbersome when iteration cycles are tight. A more integrated approach uses a browser-based web3 wallet that can hold multiple accounts and switch networks without leaving the development environment.

Phantom has become the dominant choice for this workflow because it combines non-custodial account control, multichain support including Solana, and a deliberate design around dapp interaction. Unlike custodial exchanges or centralized services, Phantom keeps private keys under the developer’s control while enabling rapid account switching and test-token management. However, using Phantom for devnet testing requires understanding several setup steps that differ from typical user workflows: network configuration, account isolation, and recovery-phrase security in a development context.

Installation and account creation for devnet workflows

The first step is acquiring and installing the wallet. When you perform a phantom wallet download from the official source, you gain access to a browser extension or mobile app with built-in Solana support. For developers, the browser extension is typically the better choice because it integrates into the development environment and allows rapid switching between wallets and networks during testing cycles. The extension is available for Chrome, Brave, Edge, and Opera, meaning most developers can install it into their existing browser without changing tools.

During installation, Phantom prompts you to either create a new wallet or import an existing one using a recovery phrase. For devnet testing, the standard practice is to create a new wallet specifically for development work, keeping it entirely separate from any mainnet or production accounts. This isolation prevents accidental transaction broadcasts to the wrong network. When you create a fresh wallet, Phantom generates a 12-word Secret Recovery Phrase that becomes the master key for all accounts derived from that seed. This phrase must be stored securely offline—ideally in a password manager with strong encryption or written on paper kept in a secure location, never in a browser bookmark or shared note.

After creating or importing the wallet, you will see a single account with a Solana address. This is your default account on the current network. For devnet testing, you typically need at least two accounts: one that receives airdropped devnet SOL and another that receives SPL tokens or serves as a test counterparty. Phantom supports multiple accounts derived from the same recovery phrase, which you can add by clicking the account selector and choosing to create a new account. Each derived account has its own Solana address, meaning you can receive devnet funds independently for each testing scenario.

Switching between Solana mainnet and devnet

One of the most critical operational steps in devnet testing is network selection. By default, Phantom connects to Solana mainnet when first installed. However, mainnet is where real SOL has value, and broadcasting a test transaction to mainnet by mistake can be costly. Phantom provides a network selector in the settings menu that allows you to switch between Solana mainnet, testnet, devnet, and custom RPC endpoints. For development, you will spend most time on devnet because it resets periodically and allows unlimited airdropped SOL for testing.

To switch to devnet, open Phantom settings, navigate to the network settings section, and select Solana Devnet. The interface will immediately change the connection to the devnet RPC cluster. Your account addresses remain the same across networks—the same public key works on mainnet, testnet, and devnet—but the balance and transaction history will be completely different on each network. This is why account isolation matters: if you maintain separate wallets or accounts for devnet versus mainnet, you eliminate the risk of sending a test transaction using a mainnet account.

Phantom also supports custom RPC endpoints, which is useful if you are running a local Solana validator for rapid testing cycles. Instead of using the public devnet cluster, you can configure Phantom to connect to localhost:8899, which is the default endpoint for a local validator. This gives you full control over the blockchain state, allows faster transactions without network latency, and lets you simulate validator behavior and transaction finality. To add a custom network, select the network dropdown, choose “Custom RPC,” and enter the endpoint URL and cluster name.

Managing test tokens and devnet SOL

Once you have switched to devnet and created a secondary account, the next workflow is acquiring test tokens. Devnet has no real value, so Solana provides an airdrop system for testing. In the Phantom interface or using the Solana CLI, you can request an airdrop of devnet SOL to your account address. The Phantom settings include an “Airdrop” button that, when clicked on devnet, automatically requests SOL to be deposited to your current account. A single airdrop provides 2 SOL, which is sufficient for testing most transactions and contract interactions.

For SPL token testing, the process differs. Standard SPL tokens do not have built-in airdrop mechanisms. Instead, you must mint tokens using a test program or receive them from another account. If you are testing a token contract, you would typically mint tokens to an account you control, then transfer them to another account for testing. Phantom’s token display shows all SPL tokens associated with your account, making it straightforward to verify balances and confirm transfers.

One important distinction: testnet and devnet behave differently with respect to token persistence and cluster resets. Solana devnet resets periodically, clearing all transaction history and resetting validators. This means any tokens or SOL you acquire on devnet will eventually disappear when the cluster resets. Testnet is more stable but receives less traffic and has less predictable behavior. For rapid iteration and feature testing, devnet is preferred; for longer-term validation, testnet may be more appropriate. Your account addresses and keys remain valid across resets, but balances will be zero until you airdrop again.

Multi-account testing and transaction approval workflows

As your smart contract testing becomes more complex, you may need to simulate interactions between multiple accounts. For example, testing a decentralized exchange contract might require a liquidity provider account, a trader account, and an intermediate escrow account. Phantom’s account switcher allows you to rapidly change between accounts without leaving the browser, making this workflow intuitive. Each account has its own balance, associated tokens, and transaction history on the current network.

When you interact with a dapp through Phantom, the wallet displays an approval window showing the transaction details before you sign. This approval mechanism is central to security: you should never approve a transaction you do not fully understand. For devnet testing, review each transaction to confirm the correct account is being used, the intended contract is being called, and the parameter values match your test expectations. Common mistakes include approving a transaction with the wrong account, calling an incorrect program address, or setting incorrect token amounts.

Phantom’s approval UI also shows any token approvals or account authorizations required by the dapp. Some contracts require you to authorize a program to transfer tokens on your behalf, similar to an ERC-20 allowance on Ethereum. Devnet allows you to test these authorization flows without risk, but the same patterns will apply to mainnet. Understanding the approval workflow during devnet testing ensures you are not surprised when deploying to production or when advising users about security implications.

Private key management and recovery in development environments

Phantom’s non-custodial design means you control the private keys for every account. The wallet derives keys from your recovery phrase using a standard hierarchical deterministic (HD) wallet scheme, which is why the 12-word phrase is so critical. If you lose the phrase, you lose access to all accounts derived from it. For devnet-only wallets used strictly for testing, the security requirements are lower than for production accounts, but maintaining the recovery phrase backup is still important because losing access interrupts your testing workflow.

The practical approach for development is to keep the recovery phrase for your devnet wallet in a secure password manager or encrypted file accessible only to you. Never commit the recovery phrase to version control, email it, or store it in cloud notes. A common pattern is to maintain one recovery phrase for devnet testing and another entirely separate recovery phrase for any mainnet or production accounts. This separation ensures that compromised development credentials do not expose production funds.

If you need to change machines or reinstall the browser, you can recover your devnet wallet by importing the recovery phrase into a fresh Phantom installation. During the import process, Phantom will regenerate all accounts associated with that phrase. This is one of the few cases where you explicitly access the recovery phrase after initial wallet creation, and it underscores why secure storage is essential. Test recovery procedures on devnet well before you need to rely on them for production accounts.

Network configuration for multichain and custom setups

Beyond Solana, Phantom supports Ethereum, Base, Polygon, Bitcoin, Sui, and HyperEVM, making it useful for developers testing contracts across multiple chains. The network selector in Phantom allows you to maintain separate accounts and balances on each supported network while using a single recovery phrase. For developers working in a multichain environment, this consolidation reduces the number of recovery phrases to manage and simplifies account organization.

Custom RPC configuration also applies to other networks, not just Solana. If you are running a local Hardhat or Anvil node for Ethereum testing, you can add that endpoint as a custom network in Phantom. This allows the same rapid, isolated testing workflow on Ethereum that you use for Solana. The key step is ensuring your custom network is configured correctly: wrong RPC endpoints cause connection errors, while correct endpoints allow seamless interaction with local development validators.

One operational note: switching between networks in Phantom does not switch your browser’s web3 provider. If you are using a dapp that relies on the wallet’s injected provider, the dapp may continue using the previous network until you refresh the page. This is why explicit network verification in the Phantom UI before signing transactions is important; the dapp interface may not always reflect the wallet’s current network selection. Developers testing contracts should explicitly verify the network shown in Phantom’s header before approving any transaction.

Best practices for testing workflows and security isolation

A mature development workflow uses Phantom with deliberate separation between environments. Your mainnet account with any real SOL should be in a separate wallet using a distinct recovery phrase, never imported into a development browser where you test unfamiliar dapps. Your devnet wallet should be used only for testing and should not hold any recoverable value. Consider creating multiple devnet wallets if you are testing untrusted code: one wallet for each contract or dapp reduces the scope of exposure if something behaves unexpectedly.

When you begin testing a new smart contract, create a new secondary account in your devnet wallet specifically for that contract. This account isolation makes it easier to trace transactions associated with a single test, simplifies cleanup, and prevents one broken contract from affecting your other testing accounts. Request an airdrop to the new account, interact with the contract, and review the transaction history on a block explorer like Solana Beach or Solscan to confirm behavior matches your expectations.

To further strengthen your workflow, use environment variables or configuration files to manage RPC endpoints and contract addresses, never hardcoding them into contract code or dapp frontends. This practice keeps devnet, testnet, and mainnet configurations clearly separated in your version control and prevents accidental mainnet deployments of test code. When you are ready to move from devnet to mainnet, change the configuration and ensure the contract addresses point to audited, production deployments rather than test programs.

Security considerations also extend to the browser itself. Phantom runs as a browser extension with access to all pages you visit, meaning a malicious website can attempt to interact with your wallet without explicit authorization from you. While Phantom requires explicit approval for each transaction, reducing the risk of unauthorized transfers, the approval UI can be spoofed by a compromised website. To mitigate this, ensure you are visiting the correct dapp URL before approving transactions, and consider using a dedicated browser profile or isolated virtual machine for contract testing if you are testing untrusted or experimental dapps.

Troubleshooting common devnet testing issues

One frequent issue is requesting an airdrop on devnet and receiving no funds. This typically occurs because devnet is congested, the airdrop system is temporarily unavailable, or your account has already received the maximum number of airdrops in a given period. The solution is to wait and retry, or to acquire devnet SOL from another source such as a faucet or from another account. If you are running a local validator, you can also configure local devnet to mint SOL directly without relying on public infrastructure.

Another common problem is a transaction failing with an “insufficient funds” error despite showing a positive SOL balance in Phantom. This occurs because transactions require fees, and the fee reserve is calculated based on the rent-exempt minimum for accounts being created or modified. The solution is to request an additional airdrop to increase your available balance, or to check the estimated fee in your transaction approval window before signing. For development, this is a useful reminder that production contracts should account for transaction fees in their logic.

Network connectivity issues also arise when switching between public devnet and a local validator. If you configure a custom RPC endpoint but the local validator is not running, Phantom will show a connection error. Verify that your local validator is started and listening on the configured port, then refresh the browser. If you continue experiencing issues, check the validator logs for startup errors or port conflicts. Switching back to public devnet allows you to continue testing while you troubleshoot the local setup.