A user new to cryptocurrency faces a foundational choice at the outset: whether to hold assets through a third-party service or to maintain direct control through a self-custodial wallet. The difference is not merely technical. It determines who can access the funds, who bears the cost of security breaches, and what happens when passwords are forgotten or transactions need to be reversed. A self-custodial cryptocurrency wallet places that responsibility entirely on the user, alongside the freedom to move assets without waiting for approval or worrying about account freezes.

Rabby Wallet is designed to make that choice practical for users managing assets on Ethereum and compatible networks. Available as a browser extension, mobile application, and desktop client, it combines DeFi integration, NFT support, and transaction transparency with an open-source codebase available for inspection. But self-custody is not a feature that can be toggled on or off. It is a commitment to maintaining security practices that many users, accustomed to centralized exchanges and password recovery, have never before needed to implement. Understanding what that commitment entails is the first step toward using Rabby safely.

What self-custody means and why it differs from exchange accounts

A centralized exchange holds user funds on behalf of customers. The exchange controls the private keys—the cryptographic credentials that unlock assets—and users access their holdings through a username and password. If a user forgets the password, the exchange can reset it. If the exchange is hacked or seized, customer funds may be frozen or lost despite the user’s own behavior being secure. Conversely, the exchange takes on the operational burden of protecting millions of keys simultaneously, maintaining secure infrastructure, and managing legal and regulatory exposure.

Self-custody inverts that structure. A user generates and stores their own private keys. The wallet application (whether Rabby or another) provides an interface for viewing balances, creating transactions, and managing assets, but the application does not hold the keys. The user alone decides when keys are created, where they are stored, and how they are backed up. This means the user also bears full responsibility for security. A lost recovery phrase cannot be recovered through a support ticket. A mistaken transaction sent to the wrong address cannot be reversed by customer service. A device compromised by malware can expose keys to an attacker with no insurance or recovery process.

The advantage of self-custody is control and certainty. No third party can freeze, seize, or mismanage assets on behalf of users. No exchange rate delays, withdrawal limits, or account verification requirements stand between a user and their cryptocurrency. A self-custodial cryptocurrency wallet like Rabby Wallet makes that independence visible and practical, but it does not eliminate the underlying risk. It simply places it entirely in the user’s court.

Understanding this boundary is essential before installing any wallet. A user who expects Rabby to offer password recovery, transaction reversal, or protection against loss is expecting something the wallet architecture fundamentally cannot provide. Those protections require a trusted third party. Self-custody explicitly rejects that model in exchange for complete control. The trade-off is intentional and cannot be made safer by better user interface design.

Rabby Wallet’s approach to accessibility and transparency

Rabby is structured around the premise that users should be able to understand what they are approving before signing a transaction. The wallet includes transaction simulation, which previews the likely effects of a transaction—what tokens will be sent, what will be received, and what the intermediate steps might be. This is particularly valuable in DeFi interactions, where a single user action can trigger multiple contracts and produce unexpected results. A user swapping tokens through a decentralized exchange, for instance, can see in advance whether the slippage is acceptable and whether the transaction outcome matches intent.

Token approval review is another transparency layer. When a user grants a smart contract permission to spend tokens on their behalf, Rabby displays what permission is being requested and for how long. Many users approve unlimited spending without realizing it, granting contracts permanent access to withdraw arbitrary amounts. Rabby’s interface reduces that carelessness by making the permission explicit and allowing custom limits. A user can approve a contract for exactly the amount needed for a single transaction, or review and modify permissions granted in the past.

The wallet is also open-source, published on GitHub, allowing developers and security researchers to inspect the code and verify that the application does what it claims. A user does not need to be a programmer to benefit from this transparency: the existence of auditable code means that the security claims can be tested by the broader cryptocurrency community rather than being taken on faith. If the rabby wallet developers were secretly stealing keys or recording passwords, the community would likely detect it through code review.

These features make Rabby beginner-friendly, but they do not eliminate the need for careful user behavior. Simulation is helpful but not infallible if network conditions change between preview and execution. Approval limits prevent unlimited access but require the user to understand what each approval does. Open-source code can be reviewed, but most users will not review it themselves and must trust that others have done so competently. Accessibility is not the same as removing risk entirely.

Multi-chain support: Ethereum and EVM-compatible networks

Rabby Wallet is designed specifically for Ethereum and blockchains that use the Ethereum Virtual Machine (EVM)—a technical standard that makes Ethereum-based tools and applications compatible across multiple networks. This includes major chains such as Arbitrum, Optimism, Polygon, BNB Smart Chain, and others. A user can hold assets on any of these networks within the same Rabby Wallet instance, viewing all balances and managing all assets from a single interface without installing separate wallets for each chain.

This multi-chain architecture is useful for users who interact with decentralized exchanges, lending protocols, and cross-chain bridges. Instead of switching between different wallets or applications, a user can access DeFi services across multiple blockchains directly through Rabby. But this convenience creates a concentration risk: if a device is compromised, lost, or reset without a proper backup, every asset on every connected chain may be affected simultaneously. A centralized approach also means that if Rabby itself contains a vulnerability or if a user installs a counterfeit version, multiple networks could be exposed at once.

Importantly, Rabby is not suitable for Bitcoin, Solana, or other non-EVM blockchains. Users holding significant assets on those networks will need separate wallets or multi-coin applications. This limitation is not a flaw but a deliberate design choice: by focusing on EVM networks, Rabby can provide deeper integration with Ethereum-based DeFi and avoid the complexity of supporting fundamentally different blockchain architectures.

Hardware wallet compatibility extends the multi-chain flexibility. Rabby can work with Ledger, Trezor, and other hardware wallets, allowing users to keep private keys isolated on a dedicated device while using Rabby as a transaction interface. This is a common setup for higher-value accounts: the hardware device signs transactions, ensuring that keys never touch an internet-connected computer, while Rabby provides the usable interface for interacting with DeFi protocols and NFT marketplaces.

The critical role of recovery phrases and key management

When a user first creates a Rabby Wallet account, the application generates a recovery phrase—typically 12 or 24 randomly selected words in a specific order. This phrase is the master key to all assets in that wallet. Anyone who knows the phrase can recreate the wallet, access the funds, and move them without permission. The phrase is not stored on Rabby’s servers or on any cloud service. It is generated on the user’s device and never leaves unless the user deliberately records or shares it.

Storing the recovery phrase correctly is the single most important security task a user undertakes. The phrase must be written down by hand, stored offline in a secure location, and protected from unauthorized access. Writing it in a digital file, storing it in a notes application, or texting it to someone for safekeeping violates the entire purpose of self-custody. If a recovery phrase is exposed, an attacker can drain the wallet at any time, regardless of how strong the user’s device password is or how carefully they use the interface.

The second critical habit is testing the recovery process without delay. A user should create a second test wallet using their recovery phrase to confirm that the phrase was written down correctly and that the derived wallet matches the original. This test should happen before significant funds are deposited. A phrase transcribed with one incorrect letter or word will generate a different wallet entirely, a mistake that often goes unnoticed until funds need to be recovered and the correct wallet cannot be found. Discovering this error after losing access to the original device is the kind of irreversible mistake that self-custody cannot prevent.

Users must also accept that Rabby cannot recover lost recovery phrases. If the phrase is forgotten, destroyed, or written incorrectly, there is no support ticket, no password reset, and no way to retrieve the assets. This is not a limitation of Rabby’s design but a fundamental property of cryptocurrency wallets. The security that makes self-custody valuable—the fact that no third party has access to keys—is the same property that makes loss permanent.

Security practices specific to multi-device setups

Many users want to access their wallet across multiple devices—a desktop browser for DeFi interactions, a phone for mobile access, and perhaps a laptop when traveling. Rabby supports this through a single recovery phrase: importing the same phrase into multiple installations derives the same wallet on each device. However, spreading the same keys across multiple devices multiplies the exposure points. A compromise on any device could potentially expose the keys, especially if the device is shared with others, used on public WiFi, or infected with malware.

A practical approach for beginners is to keep the most valuable funds on a hardware wallet or a single device that is only used for that purpose, and use a separate hot wallet (a wallet on an internet-connected device) for frequent transactions and DeFi interactions. This approach splits the risk: if the hot wallet device is compromised, only the smaller active balance is at risk, while the larger reserve remains on isolated hardware. The recovery phrase for the hot wallet should be treated as continuously exposed and rotated periodically if feasible, or kept only on the active device rather than written down and distributed.

Device-level security also matters. Enabling device lock with a strong PIN or biometric, encrypting the device storage, and installing security updates promptly can reduce the window of opportunity for attackers. These protections do not replace key management but complement it. An attacker with physical access to an unlocked device can potentially extract keys or create new transactions, while an attacker with only remote network access cannot do so as easily if the device is otherwise secure.

Keeping Rabby itself up to date is another often-overlooked security requirement. Updates may patch vulnerabilities or improve transaction safety. A user should not disable automatic updates and should periodically check that their Rabby Wallet installation is the latest version. Before logging into a wallet after a long absence, a user should also verify that the installed application has been updated and that they are using the correct application version, not a counterfeit or modified copy.

DeFi interaction and transaction risk management

One of Rabby’s main advantages is its deep integration with decentralized finance protocols. A user can access lending platforms, decentralized exchanges, liquidity pools, and yield farming opportunities directly through the wallet without navigating to separate websites or managing multiple approvals. However, this accessibility also means users can approve complex contracts with minimal friction, and complexity in DeFi often hides risk.

The transaction simulation feature helps but has limits. If a user is interacting with a contract they do not understand, the simulation may show what the contract will do under current conditions, but future contract behavior may differ. A seemingly safe swap could interact unexpectedly with a contract if the contract code is buggy or malicious, or if the state of the blockchain changes between simulation and execution. Rabby cannot guarantee that every simulated transaction will execute as expected, particularly in rapidly changing market conditions.

Users should adopt the habit of approving only what is necessary for each interaction. Rather than granting a decentralized exchange unlimited access to all tokens, approve the exact amount needed for the transaction. For frequently used contracts, a time limit on approvals (if the contract supports it) can reduce the window of risk if the contract is later exploited or compromised. Revoking unused approvals through Rabby’s token approval interface is also a reasonable precaution, though it requires paying a transaction fee.

Slippage, liquidity, and price impact are additional DeFi-specific risks. Rabby can help users see the quoted price and estimate the cost of their trade, but market conditions can move quickly. A trade that appears favorable during simulation might execute at a worse rate if the network is congested or if the liquidity pool is depleted. Setting slippage tolerance too high (allowing larger price changes) can expose users to significant unexpected costs. Conversely, setting it too low can cause transactions to fail. There is no setting that automatically makes DeFi safe; users must evaluate the trade-off for each transaction.

NFT management and marketplace risks

Rabby includes built-in NFT management, allowing users to view, send, and trade non-fungible tokens directly from the wallet. The interface displays NFT galleries and allows users to interact with NFT marketplaces without leaving the wallet. This is convenient, but NFT transactions carry additional risks that many beginners underestimate. NFT prices are often volatile, liquidity is limited, and the market includes numerous scams and counterfeit collections.

When approving an NFT marketplace contract, users grant it permission to transfer NFTs on their behalf. A malicious or compromised contract could drain an entire NFT collection. Rabby’s approval review system helps users see what permissions they are granting, but once approval is given, the contract has full authority to transfer approved assets. Users should revoke marketplace approvals after completing trades and should be cautious about approving contracts for an unlimited number of NFT transfers.

Verifying the legitimacy of an NFT collection and marketplace before trading is a user responsibility that Rabby cannot fully automate. Phishing links, fake collections, and misleading listings are common. The interface cannot tell the difference between a legitimate collection and a counterfeit with a similar name. Users must verify collection contracts through external sources such as OpenSea or Etherscan, check social media accounts, and confirm that the marketplace URL matches the official domain. If an offer seems unusually favorable, it likely is a scam targeting users who are distracted or inexperienced.

What Rabby Wallet cannot protect against

Understanding the limits of what Rabby can do is as important as understanding its capabilities. The wallet cannot protect against lost or mismanaged recovery phrases. It cannot reverse sent transactions or restore funds sent to incorrect addresses. It cannot prevent users from approving malicious contracts or sending money to scammers. It cannot verify that a website is legitimate or that an NFT collection is genuine. These are user responsibilities that no interface design can fully eliminate.

Rabby also cannot protect against device compromise. If a device is infected with malware that can log keystrokes, take screenshots, or record the screen, the attacker may be able to capture the recovery phrase, observe the password, or watch transactions being signed. Hardware wallets can reduce this risk by keeping keys isolated, but even they can be compromised if the device itself is infected with firmware-stealing malware. The security model assumes a reasonably clean device, not an environment where an attacker has root access.

Blockchain transactions are permanent and immutable. Rabby cannot contact miners or validators to undo a transaction. It cannot retrieve funds sent to a contract that has a bug and locks deposits permanently. It cannot recover from mistakes in contract interaction or token swaps. Once a transaction is signed and broadcast, it becomes part of the permanent ledger. This is a feature of blockchain technology itself, not a limitation of Rabby, but users must understand it before treating self-custodial transactions as reversible.

Rabby Wallet also has no role in contract or token legitimacy verification. A token displayed in the wallet with a familiar name could be a scam token that mimics a real asset. A contract interaction that appears safe could be a phishing attempt designed to trick users into approving theft. The wallet displays what is on the blockchain, but it cannot verify authenticity without external context that only the user can provide.

A user receives a Bitcoin payment to their Ledger wallet, connects the device weeks later, and finds that the receiving address has changed. Another user notices their Ethereum address is different from the one they copied last month. Neither has moved funds or reset their device. The cause is not corruption or a security breach. It is the standard behavior of hierarchical deterministic wallet derivation, a feature that improves both privacy and key management but often confuses people accustomed to single-address wallets or centralized exchanges.

Understanding why a ledger wallet generates multiple addresses for the same account, and how those addresses relate to a single Secret Recovery Phrase, is essential for secure fund management and recovery. The mechanism protects against address reuse tracking, simplifies backup, and makes account restoration straightforward. Yet the implementation details matter. A user who misunderstands address derivation may unnecessarily resend funds to a “new” address, lose track of which addresses hold value, or misjudge the security relationship between their hardware device and the application interface.

The core principle: one seed, infinite addresses

A Ledger hardware wallet stores a single Secret Recovery Phrase (typically 24 words) that becomes the root of an entire tree of key pairs. This phrase is never exposed to the computer or phone running the companion software; it remains on the device. From that root, the wallet uses a standardized mathematical process called BIP32 (Bitcoin Improvement Proposal 32) to derive child keys. Each child key can then produce its own child keys, creating a hierarchy that extends down many levels.

In practice, the hierarchy is organized to separate concerns. The first level of branching differentiates cryptocurrencies: a separate path for Bitcoin, another for Ethereum, another for Litecoin, and so on. The next level typically separates account instances (your “main” Bitcoin account from a “savings” account, for example). Below that, addresses are generated sequentially. This structure means that a single Secret Recovery Phrase can control thousands of addresses across dozens of cryptocurrencies, and every single one of those addresses is mathematically derived from the same 24-word seed.

The benefit is that you need only secure and backup one phrase. If your Ledger device is lost, stolen, or damaged, you can purchase a new one, enter the same Secret Recovery Phrase, and every address and every fund associated with the original device will be accessible again. No per-address backup is needed. No separate recovery method for Bitcoin, Ethereum, or any supported coin is required. The phrase is the universal key.

However, the fact that this derivation is automatic and deterministic means that the addresses are not random. They follow a pattern known to anyone who has the Secret Recovery Phrase. This is why protecting the phrase is paramount. An attacker with the phrase can derive all addresses and spend all funds. An attacker without the phrase cannot. The ledger wallet application running on your computer knows some of these derived addresses but does not need to store the phrase itself.

Why Ledger Wallet generates a new address for each transaction

One address per transaction is not a requirement of Bitcoin or Ethereum protocol. Both cryptocurrencies allow a single address to receive multiple payments. Many centralized exchanges use this model: you have one deposit address that accumulates all your transfers. However, there are significant privacy and operational disadvantages to address reuse. When you publish the same address repeatedly, every payment to that address becomes explicitly linked in the public blockchain. An observer can easily sum all payments to that address and identify you as the receiver of that total amount.

A Bitcoin wallet that generates a new address after each transaction (or in preparation for each receiving action) prevents this simple aggregation. Each payment goes to a different address, making it harder for an external observer to connect them to a single owner. This is not absolute privacy—sophisticated analysis can still make inferences from timing, amounts, and transaction patterns—but it raises the cost and reduces the obviousness of the tracking.

The ledger wallet application manages this by maintaining a counter for each account. When you open the account view and request a receiving address, the application queries the Ledger device to derive the next address in sequence. That address is displayed on the screen and on the device’s display (if you approve it). The application tracks which addresses have been used and typically displays the first unused address when you request a receive operation again.

For Ethereum and ERC-20 tokens, the benefit of address derivation for privacy is lower because Ethereum transactions show balances and interaction histories on-chain regardless of address reuse. However, the same mechanism still applies. Each address in an Ethereum account is derived from the same master key, and the application can still present an unused address for each receiving action, maintaining consistency with the Bitcoin model even though the privacy improvement is modest.

Understanding the gap limit and address scanning

The ledger wallet application cannot derive every possible address at startup because there are infinitely many. Instead, it uses a concept called the “gap limit”—typically set to 20 addresses. The application derives addresses sequentially and stops when it encounters a certain number of consecutive addresses with no transaction history. If addresses 0 through 15 have received payments, address 16 is unused, address 17 is unused, and so on up to address 20, the application assumes that address 21 and beyond will not receive funds (or have not yet received them in a way the wallet has detected).

This approach is efficient for most users but creates an edge case. If you manually request a receiving address, and that address is far ahead of the highest address ever used, the application might not detect it if you switch devices or wallets. For example, if you generate address number 35 manually and then close the application, and later open a different wallet app that also derives from the same Secret Recovery Phrase, that second app might not scan beyond address 20 and would miss the funds sent to address 35.

In practice, this is rare because the ledger wallet application keeps track of the highest address index it has encountered and adjusts the gap limit intelligently. If you regularly use the application and generate addresses through its interface, the wallet learns your pattern. But the possibility underscores an important principle: the address is derived from the phrase, not stored in the application. If you ever need to recover using a different wallet software (importing the Secret Recovery Phrase), you may need to manually adjust the derivation depth or gap limit settings to ensure that all addresses are scanned.

How hardware signing protects derived addresses

The fact that the ledger wallet application can see and display addresses does not mean it can spend from them. When you initiate a transaction, the application prepares the transaction details and sends them to the Ledger device. The device verifies the transaction, checks that the destination address is not one of your own addresses (as a fraud prevention measure), and then signs the transaction using the private key corresponding to the address you selected. The signature is sent back to the application, which broadcasts the signed transaction to the blockchain.

The private keys for all derived addresses live on the device and never leave it. The computer application has no access to these keys. This is why connecting a Ledger device to a compromised computer does not automatically expose all your funds: the computer can see addresses and balances, but it cannot initiate a valid transaction without the device’s physical confirmation and the cryptographic signature that only the device can produce.

Address derivation path information is not secret. Anyone can derive the same addresses from the Secret Recovery Phrase. But deriving an address is not the same as deriving the private key associated with it without knowing the phrase. The blockchain can see that a transaction is coming from a particular address, but no observer can spend from that address unless they have the phrase and the corresponding private key derivation capability.

This separation is also why it is safe to use a Ledger hardware wallet on a public computer or a device you do not fully control, provided you physically verify transaction details on the device’s screen before approving them. The application might show a fraudulent destination address on the screen, but if you confirm the details on the device itself, you can catch the deception because the device will display the actual address being signed.

Reconciling multiple wallets and recovery scenarios

A user who has backed up their Secret Recovery Phrase can theoretically restore their full account history using any wallet software that implements the same derivation standard (BIP44 for Bitcoin, BIP32 for others). Downloading and installing Ledger’s official software at ledger wallet onto a new computer, or even using a different vendor’s wallet software, should derive the same addresses from the same phrase.

In practice, variations exist. Different wallets may use slightly different default derivation paths. Some wallets apply additional steps (like account name derivation) that others do not. A wallet might have a higher or lower default gap limit. Segwit vs. legacy address format choices also affect the final address for Bitcoin. These differences mean that if you restore a phrase into a wallet using different settings, you might see fewer detected addresses or different address formats than you expect.

For this reason, it is important to understand which derivation path and address type your Ledger wallet is using. The application typically shows this information in settings (for Bitcoin, you can see whether you are using native Segwit, Segwit, or legacy addresses). When recovering funds after a hardware failure, using the same Ledger official application, with the same settings, ensures that addresses match perfectly.

An Ethereum wallet or Bitcoin wallet created from the same phrase in a different application might display different balances temporarily because the scanning depth differs, but connecting the Ledger device itself to that new application and re-scanning with a higher gap limit should reveal all funds. The phrase is the authoritative source; the application is a tool for accessing it.

Privacy considerations: address reuse and external observation

Even though the ledger wallet application generates a new address for each receiving operation, users sometimes manually record an address and reuse it to receive multiple payments (from an employer, a service, or a trusted contact). This is not unsafe from a security standpoint—both payments to the same address are equally valid and spendable—but it does reduce privacy. An observer can easily see that both payments went to the same address and attribute them to a single recipient.

The application discourages this by presenting the next unused address whenever possible, but the user always has the option to copy or share an old address. Over time, if you reuse an address, all payments to it become explicitly associated. When you eventually spend from that address, the blockchain will show the combined input value, potentially revealing the total amount received.

Some users also notice that they can see the same Ethereum address across different explorers or applications because Ethereum derivation is not address-sequence-based in the same way Bitcoin is. For Ethereum, each account typically has a single “receiving” address (because Ethereum does not have change addresses). Receiving multiple payments to the same Ethereum address from your Ledger wallet is normal and expected; it does not reduce security, only privacy against observers analyzing the blockchain.

Practical steps for managing addresses securely

First, use the ledger wallet application regularly to check your balances and receive transactions. Do not manually record an address for regular use; instead, request a fresh address from the application each time you need to receive payment. This keeps your interaction model aligned with the wallet’s automatic address advancement.

Second, when you copy a receiving address to share with someone else, do so from the application display, and verify the address on your Ledger device’s screen if available. Some models display the address on the device when you confirm receiving operations, allowing you to verify that the application is showing the same address you are about to share.

Third, back up your Secret Recovery Phrase carefully and test your recovery process. Do this by restoring the phrase into a separate Ledger device (if you have one available) or by using the official ledger wallet software on a fresh computer to ensure that you can derive the same addresses. Do not test recovery by entering the phrase into an online tool or non-official software.

Fourth, if you intend to use the same phrase with multiple applications or devices, document the derivation path and address format settings used by each. This prevents confusion when balances appear different or addresses do not match immediately. Keep notes on which application was primary, which addresses have been actively used, and whether you have high-value addresses that are far ahead in the derivation sequence.

Looking ahead: standardization and future wallets

Address derivation standards like BIP32 and BIP44 have been widely adopted, making it increasingly likely that different wallet applications will derive the same addresses from the same phrase. However, new standards and wallet features continue to emerge. Silent Payments on Bitcoin, for example, represent an alternative receiving model that does not use sequential addresses at all; instead, a sender uses a single public key to derive a unique address for each payment.

Ledger’s continued support for Bitcoin, Ethereum, and other standards means that as these standards evolve, the hardware wallet’s core function remains unchanged: secure key derivation and signing. The ledger wallet application will adapt to support new standards while maintaining compatibility with existing accounts. Users should expect that understanding address derivation remains relevant because the principle—one master seed, infinite derived keys—is foundational to how modern hardware wallets work.

The most important takeaway is that address change is not a flaw or a sign of trouble. It is a deliberate privacy and operational feature. Your Bitcoin wallet, Ethereum wallet, or any account derived from your Secret Recovery Phrase will continue to generate new addresses because that is how the standard design protects you. Trusting that process, rather than fighting it by manually reusing addresses, is the best path to both security and privacy.

A user receives a Bitcoin payment to their Ledger wallet, connects the device weeks later, and finds that the receiving address has changed. Another user notices their Ethereum address is different from the one they copied last month. Neither has moved funds or reset their device. The cause is not corruption or a security breach. It is the standard behavior of hierarchical deterministic wallet derivation, a feature that improves both privacy and key management but often confuses people accustomed to single-address wallets or centralized exchanges.

Understanding why a ledger wallet generates multiple addresses for the same account, and how those addresses relate to a single Secret Recovery Phrase, is essential for secure fund management and recovery. The mechanism protects against address reuse tracking, simplifies backup, and makes account restoration straightforward. Yet the implementation details matter. A user who misunderstands address derivation may unnecessarily resend funds to a “new” address, lose track of which addresses hold value, or misjudge the security relationship between their hardware device and the application interface.

The core principle: one seed, infinite addresses

A Ledger hardware wallet stores a single Secret Recovery Phrase (typically 24 words) that becomes the root of an entire tree of key pairs. This phrase is never exposed to the computer or phone running the companion software; it remains on the device. From that root, the wallet uses a standardized mathematical process called BIP32 (Bitcoin Improvement Proposal 32) to derive child keys. Each child key can then produce its own child keys, creating a hierarchy that extends down many levels.

In practice, the hierarchy is organized to separate concerns. The first level of branching differentiates cryptocurrencies: a separate path for Bitcoin, another for Ethereum, another for Litecoin, and so on. The next level typically separates account instances (your “main” Bitcoin account from a “savings” account, for example). Below that, addresses are generated sequentially. This structure means that a single Secret Recovery Phrase can control thousands of addresses across dozens of cryptocurrencies, and every single one of those addresses is mathematically derived from the same 24-word seed.

The benefit is that you need only secure and backup one phrase. If your Ledger device is lost, stolen, or damaged, you can purchase a new one, enter the same Secret Recovery Phrase, and every address and every fund associated with the original device will be accessible again. No per-address backup is needed. No separate recovery method for Bitcoin, Ethereum, or any supported coin is required. The phrase is the universal key.

However, the fact that this derivation is automatic and deterministic means that the addresses are not random. They follow a pattern known to anyone who has the Secret Recovery Phrase. This is why protecting the phrase is paramount. An attacker with the phrase can derive all addresses and spend all funds. An attacker without the phrase cannot. The ledger wallet application running on your computer knows some of these derived addresses but does not need to store the phrase itself.

Why Ledger Wallet generates a new address for each transaction

One address per transaction is not a requirement of Bitcoin or Ethereum protocol. Both cryptocurrencies allow a single address to receive multiple payments. Many centralized exchanges use this model: you have one deposit address that accumulates all your transfers. However, there are significant privacy and operational disadvantages to address reuse. When you publish the same address repeatedly, every payment to that address becomes explicitly linked in the public blockchain. An observer can easily sum all payments to that address and identify you as the receiver of that total amount.

A Bitcoin wallet that generates a new address after each transaction (or in preparation for each receiving action) prevents this simple aggregation. Each payment goes to a different address, making it harder for an external observer to connect them to a single owner. This is not absolute privacy—sophisticated analysis can still make inferences from timing, amounts, and transaction patterns—but it raises the cost and reduces the obviousness of the tracking.

The ledger wallet application manages this by maintaining a counter for each account. When you open the account view and request a receiving address, the application queries the Ledger device to derive the next address in sequence. That address is displayed on the screen and on the device’s display (if you approve it). The application tracks which addresses have been used and typically displays the first unused address when you request a receive operation again.

For Ethereum and ERC-20 tokens, the benefit of address derivation for privacy is lower because Ethereum transactions show balances and interaction histories on-chain regardless of address reuse. However, the same mechanism still applies. Each address in an Ethereum account is derived from the same master key, and the application can still present an unused address for each receiving action, maintaining consistency with the Bitcoin model even though the privacy improvement is modest.

Understanding the gap limit and address scanning

The ledger wallet application cannot derive every possible address at startup because there are infinitely many. Instead, it uses a concept called the “gap limit”—typically set to 20 addresses. The application derives addresses sequentially and stops when it encounters a certain number of consecutive addresses with no transaction history. If addresses 0 through 15 have received payments, address 16 is unused, address 17 is unused, and so on up to address 20, the application assumes that address 21 and beyond will not receive funds (or have not yet received them in a way the wallet has detected).

This approach is efficient for most users but creates an edge case. If you manually request a receiving address, and that address is far ahead of the highest address ever used, the application might not detect it if you switch devices or wallets. For example, if you generate address number 35 manually and then close the application, and later open a different wallet app that also derives from the same Secret Recovery Phrase, that second app might not scan beyond address 20 and would miss the funds sent to address 35.

In practice, this is rare because the ledger wallet application keeps track of the highest address index it has encountered and adjusts the gap limit intelligently. If you regularly use the application and generate addresses through its interface, the wallet learns your pattern. But the possibility underscores an important principle: the address is derived from the phrase, not stored in the application. If you ever need to recover using a different wallet software (importing the Secret Recovery Phrase), you may need to manually adjust the derivation depth or gap limit settings to ensure that all addresses are scanned.

How hardware signing protects derived addresses

The fact that the ledger wallet application can see and display addresses does not mean it can spend from them. When you initiate a transaction, the application prepares the transaction details and sends them to the Ledger device. The device verifies the transaction, checks that the destination address is not one of your own addresses (as a fraud prevention measure), and then signs the transaction using the private key corresponding to the address you selected. The signature is sent back to the application, which broadcasts the signed transaction to the blockchain.

The private keys for all derived addresses live on the device and never leave it. The computer application has no access to these keys. This is why connecting a Ledger device to a compromised computer does not automatically expose all your funds: the computer can see addresses and balances, but it cannot initiate a valid transaction without the device’s physical confirmation and the cryptographic signature that only the device can produce.

Address derivation path information is not secret. Anyone can derive the same addresses from the Secret Recovery Phrase. But deriving an address is not the same as deriving the private key associated with it without knowing the phrase. The blockchain can see that a transaction is coming from a particular address, but no observer can spend from that address unless they have the phrase and the corresponding private key derivation capability.

This separation is also why it is safe to use a Ledger hardware wallet on a public computer or a device you do not fully control, provided you physically verify transaction details on the device’s screen before approving them. The application might show a fraudulent destination address on the screen, but if you confirm the details on the device itself, you can catch the deception because the device will display the actual address being signed.

Reconciling multiple wallets and recovery scenarios

A user who has backed up their Secret Recovery Phrase can theoretically restore their full account history using any wallet software that implements the same derivation standard (BIP44 for Bitcoin, BIP32 for others). Downloading and installing Ledger’s official software at ledger wallet onto a new computer, or even using a different vendor’s wallet software, should derive the same addresses from the same phrase.

In practice, variations exist. Different wallets may use slightly different default derivation paths. Some wallets apply additional steps (like account name derivation) that others do not. A wallet might have a higher or lower default gap limit. Segwit vs. legacy address format choices also affect the final address for Bitcoin. These differences mean that if you restore a phrase into a wallet using different settings, you might see fewer detected addresses or different address formats than you expect.

For this reason, it is important to understand which derivation path and address type your Ledger wallet is using. The application typically shows this information in settings (for Bitcoin, you can see whether you are using native Segwit, Segwit, or legacy addresses). When recovering funds after a hardware failure, using the same Ledger official application, with the same settings, ensures that addresses match perfectly.

An Ethereum wallet or Bitcoin wallet created from the same phrase in a different application might display different balances temporarily because the scanning depth differs, but connecting the Ledger device itself to that new application and re-scanning with a higher gap limit should reveal all funds. The phrase is the authoritative source; the application is a tool for accessing it.

Privacy considerations: address reuse and external observation

Even though the ledger wallet application generates a new address for each receiving operation, users sometimes manually record an address and reuse it to receive multiple payments (from an employer, a service, or a trusted contact). This is not unsafe from a security standpoint—both payments to the same address are equally valid and spendable—but it does reduce privacy. An observer can easily see that both payments went to the same address and attribute them to a single recipient.

The application discourages this by presenting the next unused address whenever possible, but the user always has the option to copy or share an old address. Over time, if you reuse an address, all payments to it become explicitly associated. When you eventually spend from that address, the blockchain will show the combined input value, potentially revealing the total amount received.

Some users also notice that they can see the same Ethereum address across different explorers or applications because Ethereum derivation is not address-sequence-based in the same way Bitcoin is. For Ethereum, each account typically has a single “receiving” address (because Ethereum does not have change addresses). Receiving multiple payments to the same Ethereum address from your Ledger wallet is normal and expected; it does not reduce security, only privacy against observers analyzing the blockchain.

Practical steps for managing addresses securely

First, use the ledger wallet application regularly to check your balances and receive transactions. Do not manually record an address for regular use; instead, request a fresh address from the application each time you need to receive payment. This keeps your interaction model aligned with the wallet’s automatic address advancement.

Second, when you copy a receiving address to share with someone else, do so from the application display, and verify the address on your Ledger device’s screen if available. Some models display the address on the device when you confirm receiving operations, allowing you to verify that the application is showing the same address you are about to share.

Third, back up your Secret Recovery Phrase carefully and test your recovery process. Do this by restoring the phrase into a separate Ledger device (if you have one available) or by using the official ledger wallet software on a fresh computer to ensure that you can derive the same addresses. Do not test recovery by entering the phrase into an online tool or non-official software.

Fourth, if you intend to use the same phrase with multiple applications or devices, document the derivation path and address format settings used by each. This prevents confusion when balances appear different or addresses do not match immediately. Keep notes on which application was primary, which addresses have been actively used, and whether you have high-value addresses that are far ahead in the derivation sequence.

Looking ahead: standardization and future wallets

Address derivation standards like BIP32 and BIP44 have been widely adopted, making it increasingly likely that different wallet applications will derive the same addresses from the same phrase. However, new standards and wallet features continue to emerge. Silent Payments on Bitcoin, for example, represent an alternative receiving model that does not use sequential addresses at all; instead, a sender uses a single public key to derive a unique address for each payment.

Ledger’s continued support for Bitcoin, Ethereum, and other standards means that as these standards evolve, the hardware wallet’s core function remains unchanged: secure key derivation and signing. The ledger wallet application will adapt to support new standards while maintaining compatibility with existing accounts. Users should expect that understanding address derivation remains relevant because the principle—one master seed, infinite derived keys—is foundational to how modern hardware wallets work.

The most important takeaway is that address change is not a flaw or a sign of trouble. It is a deliberate privacy and operational feature. Your Bitcoin wallet, Ethereum wallet, or any account derived from your Secret Recovery Phrase will continue to generate new addresses because that is how the standard design protects you. Trusting that process, rather than fighting it by manually reusing addresses, is the best path to both security and privacy.

A user receives a Bitcoin payment to their Ledger wallet, connects the device weeks later, and finds that the receiving address has changed. Another user notices their Ethereum address is different from the one they copied last month. Neither has moved funds or reset their device. The cause is not corruption or a security breach. It is the standard behavior of hierarchical deterministic wallet derivation, a feature that improves both privacy and key management but often confuses people accustomed to single-address wallets or centralized exchanges.

Understanding why a ledger wallet generates multiple addresses for the same account, and how those addresses relate to a single Secret Recovery Phrase, is essential for secure fund management and recovery. The mechanism protects against address reuse tracking, simplifies backup, and makes account restoration straightforward. Yet the implementation details matter. A user who misunderstands address derivation may unnecessarily resend funds to a “new” address, lose track of which addresses hold value, or misjudge the security relationship between their hardware device and the application interface.

The core principle: one seed, infinite addresses

A Ledger hardware wallet stores a single Secret Recovery Phrase (typically 24 words) that becomes the root of an entire tree of key pairs. This phrase is never exposed to the computer or phone running the companion software; it remains on the device. From that root, the wallet uses a standardized mathematical process called BIP32 (Bitcoin Improvement Proposal 32) to derive child keys. Each child key can then produce its own child keys, creating a hierarchy that extends down many levels.

In practice, the hierarchy is organized to separate concerns. The first level of branching differentiates cryptocurrencies: a separate path for Bitcoin, another for Ethereum, another for Litecoin, and so on. The next level typically separates account instances (your “main” Bitcoin account from a “savings” account, for example). Below that, addresses are generated sequentially. This structure means that a single Secret Recovery Phrase can control thousands of addresses across dozens of cryptocurrencies, and every single one of those addresses is mathematically derived from the same 24-word seed.

The benefit is that you need only secure and backup one phrase. If your Ledger device is lost, stolen, or damaged, you can purchase a new one, enter the same Secret Recovery Phrase, and every address and every fund associated with the original device will be accessible again. No per-address backup is needed. No separate recovery method for Bitcoin, Ethereum, or any supported coin is required. The phrase is the universal key.

However, the fact that this derivation is automatic and deterministic means that the addresses are not random. They follow a pattern known to anyone who has the Secret Recovery Phrase. This is why protecting the phrase is paramount. An attacker with the phrase can derive all addresses and spend all funds. An attacker without the phrase cannot. The ledger wallet application running on your computer knows some of these derived addresses but does not need to store the phrase itself.

Why Ledger Wallet generates a new address for each transaction

One address per transaction is not a requirement of Bitcoin or Ethereum protocol. Both cryptocurrencies allow a single address to receive multiple payments. Many centralized exchanges use this model: you have one deposit address that accumulates all your transfers. However, there are significant privacy and operational disadvantages to address reuse. When you publish the same address repeatedly, every payment to that address becomes explicitly linked in the public blockchain. An observer can easily sum all payments to that address and identify you as the receiver of that total amount.

A Bitcoin wallet that generates a new address after each transaction (or in preparation for each receiving action) prevents this simple aggregation. Each payment goes to a different address, making it harder for an external observer to connect them to a single owner. This is not absolute privacy—sophisticated analysis can still make inferences from timing, amounts, and transaction patterns—but it raises the cost and reduces the obviousness of the tracking.

The ledger wallet application manages this by maintaining a counter for each account. When you open the account view and request a receiving address, the application queries the Ledger device to derive the next address in sequence. That address is displayed on the screen and on the device’s display (if you approve it). The application tracks which addresses have been used and typically displays the first unused address when you request a receive operation again.

For Ethereum and ERC-20 tokens, the benefit of address derivation for privacy is lower because Ethereum transactions show balances and interaction histories on-chain regardless of address reuse. However, the same mechanism still applies. Each address in an Ethereum account is derived from the same master key, and the application can still present an unused address for each receiving action, maintaining consistency with the Bitcoin model even though the privacy improvement is modest.

Understanding the gap limit and address scanning

The ledger wallet application cannot derive every possible address at startup because there are infinitely many. Instead, it uses a concept called the “gap limit”—typically set to 20 addresses. The application derives addresses sequentially and stops when it encounters a certain number of consecutive addresses with no transaction history. If addresses 0 through 15 have received payments, address 16 is unused, address 17 is unused, and so on up to address 20, the application assumes that address 21 and beyond will not receive funds (or have not yet received them in a way the wallet has detected).

This approach is efficient for most users but creates an edge case. If you manually request a receiving address, and that address is far ahead of the highest address ever used, the application might not detect it if you switch devices or wallets. For example, if you generate address number 35 manually and then close the application, and later open a different wallet app that also derives from the same Secret Recovery Phrase, that second app might not scan beyond address 20 and would miss the funds sent to address 35.

In practice, this is rare because the ledger wallet application keeps track of the highest address index it has encountered and adjusts the gap limit intelligently. If you regularly use the application and generate addresses through its interface, the wallet learns your pattern. But the possibility underscores an important principle: the address is derived from the phrase, not stored in the application. If you ever need to recover using a different wallet software (importing the Secret Recovery Phrase), you may need to manually adjust the derivation depth or gap limit settings to ensure that all addresses are scanned.

How hardware signing protects derived addresses

The fact that the ledger wallet application can see and display addresses does not mean it can spend from them. When you initiate a transaction, the application prepares the transaction details and sends them to the Ledger device. The device verifies the transaction, checks that the destination address is not one of your own addresses (as a fraud prevention measure), and then signs the transaction using the private key corresponding to the address you selected. The signature is sent back to the application, which broadcasts the signed transaction to the blockchain.

The private keys for all derived addresses live on the device and never leave it. The computer application has no access to these keys. This is why connecting a Ledger device to a compromised computer does not automatically expose all your funds: the computer can see addresses and balances, but it cannot initiate a valid transaction without the device’s physical confirmation and the cryptographic signature that only the device can produce.

Address derivation path information is not secret. Anyone can derive the same addresses from the Secret Recovery Phrase. But deriving an address is not the same as deriving the private key associated with it without knowing the phrase. The blockchain can see that a transaction is coming from a particular address, but no observer can spend from that address unless they have the phrase and the corresponding private key derivation capability.

This separation is also why it is safe to use a Ledger hardware wallet on a public computer or a device you do not fully control, provided you physically verify transaction details on the device’s screen before approving them. The application might show a fraudulent destination address on the screen, but if you confirm the details on the device itself, you can catch the deception because the device will display the actual address being signed.

Reconciling multiple wallets and recovery scenarios

A user who has backed up their Secret Recovery Phrase can theoretically restore their full account history using any wallet software that implements the same derivation standard (BIP44 for Bitcoin, BIP32 for others). Downloading and installing Ledger’s official software at ledger wallet onto a new computer, or even using a different vendor’s wallet software, should derive the same addresses from the same phrase.

In practice, variations exist. Different wallets may use slightly different default derivation paths. Some wallets apply additional steps (like account name derivation) that others do not. A wallet might have a higher or lower default gap limit. Segwit vs. legacy address format choices also affect the final address for Bitcoin. These differences mean that if you restore a phrase into a wallet using different settings, you might see fewer detected addresses or different address formats than you expect.

For this reason, it is important to understand which derivation path and address type your Ledger wallet is using. The application typically shows this information in settings (for Bitcoin, you can see whether you are using native Segwit, Segwit, or legacy addresses). When recovering funds after a hardware failure, using the same Ledger official application, with the same settings, ensures that addresses match perfectly.

An Ethereum wallet or Bitcoin wallet created from the same phrase in a different application might display different balances temporarily because the scanning depth differs, but connecting the Ledger device itself to that new application and re-scanning with a higher gap limit should reveal all funds. The phrase is the authoritative source; the application is a tool for accessing it.

Privacy considerations: address reuse and external observation

Even though the ledger wallet application generates a new address for each receiving operation, users sometimes manually record an address and reuse it to receive multiple payments (from an employer, a service, or a trusted contact). This is not unsafe from a security standpoint—both payments to the same address are equally valid and spendable—but it does reduce privacy. An observer can easily see that both payments went to the same address and attribute them to a single recipient.

The application discourages this by presenting the next unused address whenever possible, but the user always has the option to copy or share an old address. Over time, if you reuse an address, all payments to it become explicitly associated. When you eventually spend from that address, the blockchain will show the combined input value, potentially revealing the total amount received.

Some users also notice that they can see the same Ethereum address across different explorers or applications because Ethereum derivation is not address-sequence-based in the same way Bitcoin is. For Ethereum, each account typically has a single “receiving” address (because Ethereum does not have change addresses). Receiving multiple payments to the same Ethereum address from your Ledger wallet is normal and expected; it does not reduce security, only privacy against observers analyzing the blockchain.

Practical steps for managing addresses securely

First, use the ledger wallet application regularly to check your balances and receive transactions. Do not manually record an address for regular use; instead, request a fresh address from the application each time you need to receive payment. This keeps your interaction model aligned with the wallet’s automatic address advancement.

Second, when you copy a receiving address to share with someone else, do so from the application display, and verify the address on your Ledger device’s screen if available. Some models display the address on the device when you confirm receiving operations, allowing you to verify that the application is showing the same address you are about to share.

Third, back up your Secret Recovery Phrase carefully and test your recovery process. Do this by restoring the phrase into a separate Ledger device (if you have one available) or by using the official ledger wallet software on a fresh computer to ensure that you can derive the same addresses. Do not test recovery by entering the phrase into an online tool or non-official software.

Fourth, if you intend to use the same phrase with multiple applications or devices, document the derivation path and address format settings used by each. This prevents confusion when balances appear different or addresses do not match immediately. Keep notes on which application was primary, which addresses have been actively used, and whether you have high-value addresses that are far ahead in the derivation sequence.

Looking ahead: standardization and future wallets

Address derivation standards like BIP32 and BIP44 have been widely adopted, making it increasingly likely that different wallet applications will derive the same addresses from the same phrase. However, new standards and wallet features continue to emerge. Silent Payments on Bitcoin, for example, represent an alternative receiving model that does not use sequential addresses at all; instead, a sender uses a single public key to derive a unique address for each payment.

Ledger’s continued support for Bitcoin, Ethereum, and other standards means that as these standards evolve, the hardware wallet’s core function remains unchanged: secure key derivation and signing. The ledger wallet application will adapt to support new standards while maintaining compatibility with existing accounts. Users should expect that understanding address derivation remains relevant because the principle—one master seed, infinite derived keys—is foundational to how modern hardware wallets work.

The most important takeaway is that address change is not a flaw or a sign of trouble. It is a deliberate privacy and operational feature. Your Bitcoin wallet, Ethereum wallet, or any account derived from your Secret Recovery Phrase will continue to generate new addresses because that is how the standard design protects you. Trusting that process, rather than fighting it by manually reusing addresses, is the best path to both security and privacy.