Most users who install a browser extension for cryptocurrency management treat it as a simple transfer tool: paste an address, confirm the amount, wait for confirmation. Solflare wallet holders often follow the same pattern, moving SOL between accounts and clicking approve on familiar decentralized applications. But a Solana ecosystem user who has spent months or years with the extension may never have seen transaction simulation, custom gas configuration, selective token hiding, or the recovery mechanisms that exist in the settings menu. These features are present and functional, yet they remain invisible to anyone who does not search for them deliberately.

The distinction matters because discovery affects decision-making. A user who does not know that Solflare wallet extension includes transaction simulation might approve a contract interaction without understanding its actual effect, simply trusting the interface text. Another might leave all tokens visible in the gallery, not realizing that the wallet supports selective hiding or custom display preferences. A third might rely entirely on the standard account recovery path when alternative approaches exist for specific situations. These are not flaws; they are the result of designing a clean, accessible interface while relocating power-user features to a secondary layer. Understanding what exists—and where to find it—can transform Solflare from a convenient tool into a more deliberate and controlled part of your Solana ecosystem strategy.

Transaction simulation: seeing what will actually happen before you approve

When a Solana dApp requests approval to perform an action—whether swapping tokens, staking, or interacting with a smart contract—the transaction arrives at the wallet as a byte string and a human-readable summary. That summary is often correct, but it can also be incomplete, misleading, or the result of a phishing interface that mimics a legitimate application. Transaction simulation runs the proposed transaction through the Solana validator logic in a read-only mode, showing the actual state changes that would occur: which tokens would move, how much would be deducted as fees, whether any intermediate steps would fail, and what the wallet or connected account would look like afterward.

To access this feature, open a transaction approval dialog in Solflare and look for an inspection or simulation option—often presented as a chevron, “details” button, or expandable section within the approval screen. When expanded, it displays the simulated result of executing the transaction. This is particularly useful when approving transactions with conditional logic: a swap that depends on minimum output amounts, a complex instruction sequence, or an approval to a contract that you have not used before. The simulation does not guarantee that the on-chain execution will produce the same result if conditions change between the time you approve and the time the transaction settles, but it provides a much stronger basis for decision-making than the unverified summary alone.

The practical value becomes clear when comparing what the interface claims against what simulation shows. A malicious or confused interface might display “swap 10 SOL for USDC” when the actual transaction would swap 10 SOL for a wrapped stablecoin that is not USDC, or attempt to authorize a permanent allowance to a bridge contract. The Solflare wallet extension includes simulation as a safety layer precisely because the human-readable text layer can be unreliable. Users who know to activate it catch more errors; users who do not tend to approve based on the summary and trust that it will work as advertised.

One important caveat: simulation uses the current state of the blockchain. If the transaction depends on a price feed, liquidity pool depth, or account balance that changes between simulation and execution, the actual result might differ. Do not treat a successful simulation as an absolute guarantee. Instead, use it as a sanity check: if the simulation fails or shows a radically different outcome than the summary claims, reject the transaction and investigate why the discrepancy exists.

Custom gas settings and transaction priority in a flat-fee environment

Unlike Ethereum, Solana does not use a dynamic auction-based gas market where users bid higher fees to jump the transaction queue. Instead, Solana charges a fixed base fee per transaction (currently around 5,000 lamports, or approximately 0.000005 SOL) regardless of network congestion. This sounds like transaction priority should be irrelevant, yet Solflare wallet includes priority fee options that allow users to pay extra to increase their transaction’s likelihood of inclusion in an upcoming block, particularly during periods of high network load.

To configure priority fees, open a transaction approval in Solflare and look for a “priority” or “gas” section, often located near the bottom of the approval dialog. Here you can select from preset levels—low, medium, high, or custom—or enter a specific amount in lamports. The additional amount is paid on top of the base fee and goes directly to validators as an incentive to prioritize your transaction. During normal network conditions, the base fee is sufficient and adding a priority fee is wasteful. During congestion or when executing time-sensitive transactions like liquidations or claiming rewards before an epoch closes, a modest priority fee becomes worthwhile.

The key insight is that priority fees are optional, not mandatory. Most users never interact with this setting and never need to. Those who do discover it often make it their default, paying unnecessary premiums even when the network is idle. A better approach is to enable custom gas settings, observe the normal transaction time during periods when you are not in a hurry, and reserve priority fees for situations where speed genuinely matters: claiming staking rewards in the last hours of an epoch, executing a time-bound DeFi interaction, or recovering from a transaction that failed and must be retried immediately. Solflare wallet allows you to configure this per transaction rather than forcing a global default, which aligns with the principle of paying for what you actually need.

Token management and selective visibility in the NFT gallery

The Solflare wallet displays every SPL token and NFT associated with an account by default. For users with hundreds of tokens or NFTs—especially those acquired through yield farming, reward distribution, or accidental airdrops—the gallery becomes cluttered and navigating to a specific asset becomes slow. The wallet supports selective hiding, allowing you to remove tokens or NFTs from the primary display without deleting them or transferring them elsewhere.

To hide a token, locate it in the token list, and look for a menu icon (often three dots, a gear, or an arrow) next to the token name or balance. Select the hide or visibility option. The token remains in your account and on the blockchain; it simply does not appear in Solflare’s default gallery view. This is useful for deprecated tokens you plan to sell in the future, low-value dust holdings, or NFTs you prefer not to see every time you open the wallet. Some users maintain a hidden section for speculative holdings they want to segregate from their “serious” portfolio, or for NFTs they received but do not want to display publicly.

The inverse operation—showing hidden tokens again—requires navigating to the wallet settings or account view and toggling a “show hidden tokens” or “advanced view” option. Solflare wallet makes this discoverable, but the design assumes most users do not need it frequently. For power users managing multiple categories of assets, this feature prevents interface fatigue while maintaining a clear separation between active holdings and archival positions. The token management approach also extends to custom token imports: if you hold an SPL token that Solflare does not recognize automatically, you can add it manually by providing the token mint address, enabling it to appear in your balance and transaction history.

Advanced account recovery and multi-signature scenarios

The standard account recovery path in Solflare involves entering your seed phrase or private key into the wallet, which then derives your associated Solana accounts. This works for most users and most situations. But Solflare wallet supports additional recovery scenarios that most users never encounter because they do not need them—until suddenly they do.

If you have access to a Ledger device that signed accounts within Solflare, you can recover those accounts by reconnecting the Ledger rather than importing a seed phrase. This is valuable if your seed phrase was never backed up physically or if you prefer to avoid typing it into even a local browser extension. The Ledger hardware wallet retains the key material, and Solflare recognizes and re-derives the accounts without ever needing the seed phrase to exist on your computer.

For users managing multiple accounts or participating in protocols that use derived account structures, Solflare wallet allows you to recover and display multiple accounts from a single seed phrase. Most users create one account and never add another. Those who run bots, manage separate positions for tax purposes, or participate in protocols that require account separation can import the same seed phrase multiple times and derive different account indices from it. This is not a multi-signature scheme, but it achieves a similar organizational effect: one seed phrase, multiple Solana accounts, each with separate balances and transaction history visible within a single Solflare wallet interface.

A less obvious recovery scenario involves protocol-specific account recovery. If you have used a Solana ecosystem application that generated a sub-account or derived wallet for your benefit—some lending protocols, insurance schemes, or DAOs do this—Solflare wallet may support direct recovery of those accounts by importing the protocol-provided recovery credentials. This is protocol-dependent and not universally supported, but it exists as an option in situations where the original application becomes unavailable or you wish to access the account from a different interface.

Custom RPC nodes and validator selection

By default, Solflare connects to Solana’s public RPC endpoints and a set of pre-configured validators for network operations. For most users, this is adequate and transparent. For users running their own Solana validator, operating a node infrastructure company, or simply preferring not to route requests through public infrastructure, Solflare wallet includes the ability to configure custom RPC endpoints.

To access this setting, open the Solflare wallet settings menu (usually a gear or profile icon in the top-right corner) and navigate to network or RPC configuration. Here you can enter a custom RPC URL pointing to your own node, a private RPC service, or an alternative public endpoint. Solflare will send account queries, balance checks, and transaction broadcasting to your specified endpoint instead of the default. This is particularly relevant for users who value privacy and want to avoid broadcasting transaction data to Solana Foundation infrastructure, or for developers and operators who need to test against specific node configurations or run queries against historical data.

The Solflare wallet extension does not directly manage which validators you are staking with—that is determined by the delegation instruction you submit—but custom RPC configuration affects which nodes your wallet queries to check staking rewards, epoch information, and account state. For serious Solana ecosystem participants, this level of control becomes meaningful: you can separate the node infrastructure you trust for transaction broadcasting from the endpoint you use for balance checks and exploratory queries.

Native staking with reward tracking and epoch awareness

Solflare includes built-in staking functionality, allowing you to delegate SOL directly from the wallet without visiting an external staking interface. Most users who stake simply enter an amount and a validator address, then check their balance periodically. But the wallet contains staking features that experienced delegators often overlook: reward estimation, epoch countdown, and delegation history.

To stake SOL, navigate to the staking section within Solflare (often a dedicated tab or menu item), enter the amount and the validator public key, and approve the transaction. Once delegated, your stake begins earning rewards in the next epoch. Solflare displays your current staking balance, estimated rewards per epoch based on the validator’s commission and historical performance, and a countdown to the end of the current epoch. This countdown is crucial because rewards are applied only once per epoch—if you have pending staking that you think should have started earning, checking the epoch timer will reveal whether you are simply between epochs.

The Solflare wallet extension also maintains a history of your staking actions and can show you which validators have held your stake and when you delegated to each. This is useful for tax accounting, understanding your staking strategy over time, and identifying periods when your delegation was split across multiple validators or when you were unstaking. Experienced stakers use this information to optimize validator selection, track performance, and ensure they are not accidentally delegating to validators that have been marked as delinquent or are performing poorly.

One advanced pattern that Solflare enables but does not highlight: you can keep portions of your SOL staked to different validators simultaneously, effectively diversifying your validator risk while earning rewards on all delegated amounts. If one validator goes offline or becomes compromised, only the delegated portion is affected. Claiming rewards from multiple validators requires multiple transactions, each with its own Solana ecosystem fee, but Solflare’s interface makes this possible without switching wallets or using external tools.

Phishing protection features and dApp connection management

Solflare includes several anti-phishing mechanisms that work quietly in the background, most of which users never discover or configure. The most visible is a domain whitelist that appears when you interact with a dApp. Some dApps appear in a curated list, signaling that Solflare has recognized them and considers them legitimate. Others do not, triggering a warning that you are about to connect to an unrecognized domain.

This whitelist is not a guarantee of safety—it is a heuristic based on known, community-reported applications—but it provides a useful signal. If you are about to connect to a dApp and Solflare does not recognize it, that is a reason to pause, verify the URL manually, and check whether the application is new or whether you may have been directed to a phishing copy. The URL bar of your browser is the primary defense here, but Solflare’s recognition system adds a secondary check.

A more powerful feature, less frequently discovered, is the connected dApps management interface. In Solflare wallet settings, you can view every dApp to which you have granted connection permissions. From here, you can disconnect individually, removing the stored session without affecting your funds or previous transactions. Users who connect to many Solana ecosystem applications often accumulate dozens of active connections, each of which could theoretically be exploited if the dApp’s server was compromised or if the connection was intercepted. Periodically reviewing this list and disconnecting from applications you no longer use reduces the attack surface: even if a compromised dApp tries to request a transaction, Solflare will require you to re-authorize the connection, providing an opportunity to recognize that something is wrong.

Offline signing and hardware wallet integration for high-security scenarios

While most Solflare wallet users manage their private keys locally and sign transactions from the same device where they browse, the wallet supports hardware wallet integration with Ledger devices. This moves the actual key material and signing operation to a dedicated device, meaning your private key never touches the browser or computer running Solflare.

To set up Ledger integration, install the Solana app on your Ledger device, open Solflare, and select “connect Ledger” during account import. Solflare will communicate with your Ledger, derive your account address, and display your balance. When you approve a transaction, Solflare sends the transaction details to the Ledger, which displays them on its own screen for you to verify and confirm with a physical button press. The actual signing happens on the Ledger, and only the signed transaction is returned to Solflare for broadcasting.

This setup is more complex than importing a seed phrase and offers no additional convenience—in fact, it is slower. But it provides a meaningful security upgrade for users who hold significant amounts of SOL or participate in high-value DeFi interactions. The risk model changes: compromising your browser or computer cannot drain your Solflare wallet extension because the private key does not exist on that system. Only the Ledger device, which is under your physical control, can authorize transactions.

A related but distinct scenario involves offline transaction signing. Some users create a separate, air-gapped device running Solflare, generate an account on it, transfer funds to that account, and then use an online device with that account’s public address to view balances and construct transactions. The unsigned transaction is transferred to the air-gapped device (via USB or photographed QR code), signed there, and then transferred back for broadcasting. This is a more extreme setup than Ledger integration but achieves similar isolation. Solflare does not have built-in air-gapped modes, but the browser extension’s architecture allows this pattern if you are willing to manage multiple devices and transport transactions manually.