A user creates a Monero wallet on their personal device and immediately faces a critical decision: how is the recovery phrase protected, where do the private keys live, and who can access them if the device is powered on? The conventional answer for most cryptocurrency wallets is that some degree of key material reaches a company’s servers, gets encrypted there, or relies on a service to verify transactions. XMRWallet operates on a fundamentally different model. The private keys never leave the user’s device, encryption happens entirely on the client side, and the architecture is deliberately non-custodial from the moment a wallet is generated.

This design choice has practical consequences that ripple through every operation: login, balance checking, sending funds, and backup. Understanding client-side encryption is not an academic exercise. It determines what actually happens when a password is entered, how a recovery phrase functions, what the server can see, and what remains protected even if the device is seized or the web interface is compromised. The difference between client-side and server-side encryption is not a marketing distinction. It is the difference between a user who controls cryptographic keys and a user who trusts that someone else is not misusing theirs.

The architecture of client-side key generation

When a user creates a new monero wallet through XMRWallet, no server generates the keys. Instead, the browser or client application running on the user’s device generates cryptographic key material locally using industry-standard algorithms. The seed phrase—typically a 25-word mnemonic that represents the wallet’s master secret—is created entirely offline and never transmitted to any service. This is a departure from many web-based wallets, which generate keys on the server and encrypt them before sending the result back to the user.

Monero’s key derivation process follows a specific mathematical structure. The recovery phrase is converted into a scalar (a large integer used in elliptic curve cryptography), and that scalar is then used to derive the spend key and view key through additional cryptographic steps. The spend key is what allows the user to authorize transactions. The view key is what allows the user (or a trusted party) to see incoming transactions without having the ability to move funds. For maximum security, both keys are derived entirely on the client, meaning the device performing the computation is the sole source of these secrets.

The implication is straightforward: if the server hosting the monero wallet does not have access to the seed phrase or private keys, it cannot be compelled to reveal them, and a breach of the server cannot expose them. The server’s role becomes narrowly defined: receive requests to scan the blockchain, return matching transaction information, relay broadcasts, and perform other functions that do not require knowledge of keys. This architecture eliminates an entire class of risks that plague custodial and even many nominally “non-custodial” wallets that still process keys on their infrastructure.

However, this benefit depends on the client-side software being trustworthy. If the interface served by the server contains malicious code, or if a user’s device is already compromised, client-side generation provides no protection. The code must be inspected, the source should be verifiable, and the network connection should be trusted or at minimum monitored. Many users access XMRWallet through HTTPS, which prevents active modification in transit, but the initial code delivery remains a critical trust boundary.

How password-based encryption protects the recovery phrase

Once the recovery phrase is generated on the client device, the user is prompted to set a password. This password is not transmitted to the server; instead, it is used locally to encrypt the recovery phrase using a key derivation function and symmetric encryption algorithm. The standard approach uses a password-based key derivation function (PBKDF2, Argon2, or similar) to convert the password into a cryptographic key, which then encrypts the recovery phrase using AES-256 or another authenticated encryption scheme.

The encrypted recovery phrase is what gets stored, either locally on the device, in browser storage, or on the server. The critical point is that the encryption key is derived from the user’s password alone—not from the server, not from a shared secret, and not from any external key management system. If the user forgets the password, the recovery phrase cannot be decrypted. If the password is weak, an offline attacker who obtains the encrypted recovery phrase can attempt to guess it through brute force. If the password is strong and the key derivation function is properly tuned with adequate computational cost, the time and resources required to crack it become prohibitive.

This model shifts security responsibility to the user. A password-protected wallet is only as secure as the password itself and the care with which the user stores or remembers it. Unlike server-side systems where the service operator can enforce password policies, set complexity requirements, or reset accounts, a client-side system has no such mechanism. The user must choose a strong password, protect it from keyloggers and phishing, and remember it or store it securely. If the password is lost, the recovery phrase is locked away. If the recovery phrase itself is also lost or destroyed, the wallet funds are irretrievable.

The practical workflow is therefore more restrictive than some users expect. When accessing the wallet on a new device or after clearing browser storage, the user must enter both the recovery phrase (if stored separately) and the password. The combination of the two—recovery phrase for the wallet itself, password for decrypting the recovery phrase—creates a two-factor recovery process. This is more robust than a password alone, but it requires the user to maintain both pieces separately and securely.

Private key management and non-custodial control

The spend key and view key derived from the recovery phrase are never serialized, transmitted, or stored in plain form. During wallet operations—such as when a user wants to send Monero—the private spend key is decrypted from storage on demand, used to sign the transaction, and then immediately discarded from memory. Modern browsers and JavaScript environments do not guarantee that memory is completely cleared after use, so some risk of key material remaining in RAM exists, but the duration is minimized and the exposure is confined to the user’s own device.

For view-only wallets, XMRWallet creates a derivative that uses only the view key. A view-only monero wallet can receive funds and observe all incoming transactions without ever possessing the spend key. This is useful for cold storage scenarios, transparent accounting, or delegation: a user can share their view key with an accountant, auditor, or another trusted party without giving that party the ability to move funds. The view key is still encrypted locally using the same password-based encryption, so even a view-only wallet requires authentication to access.

Non-custodial control means the user’s device is the sole source of authorization. No escrow system, no multi-signature scheme managed by a third party, and no recovery mechanism that requires contacting the service operator. If the wallet is locked with a password that the user forgets, there is no “forgot password” button that contacts a server. The recovery phrase is the only way back in, and it must have been preserved separately. This is a trade-off: users gain absolute control and protection from service outages or account seizure, but they also gain absolute responsibility for their own backups and security.

Transaction signing and broadcast without key exposure

When a user constructs a transaction to send Monero, the client-side application performs several steps: it retrieves unspent outputs from the blockchain, selects which outputs to spend, constructs the transaction structure, and signs the transaction using the spend key. All of these operations happen on the user’s device. The signature proves ownership of the funds without revealing the private key itself—a fundamental property of public-key cryptography that Monero depends on.

Once the transaction is signed, it is broadcast to the Monero network through one or more nodes. At this point, the transaction is public on the blockchain, but it contains no information that links it to the user’s identity, because Monero’s protocol uses ring signatures (mixing the user’s input with decoys), stealth addresses (making each recipient unique and unlinkable), and confidential transactions (hiding amounts). The fact that the private key was never transmitted, never stored on a server, and never handled by any third party means that even if the server is fully compromised, the transaction’s cryptographic validity cannot be undermined.

The server’s role in transaction submission is strictly functional: receive the signed transaction and relay it to peers. The server does not validate signatures using the private key (only the public key is needed for verification), does not modify the transaction, and does not require authentication based on the wallet’s secrets. From the user’s perspective, using multiple servers or a public node list provides redundancy and reduces the risk that any single service can prevent transactions from being broadcast.

Why client-side encryption is not bulletproof

Client-side encryption dramatically improves security compared to traditional custodial models, but it does not eliminate risk. A compromised device, malware that captures keystrokes or screen contents, a phishing attack that tricks the user into entering credentials on a fake site, or a browser extension with excessive permissions can all expose the password or recovery phrase. Additionally, browser-based wallets are vulnerable to supply-chain attacks: if the server is hacked and malicious code is injected into the HTML or JavaScript served to users, that code can capture sensitive information before encryption occurs.

XMRWallet mitigates these risks through code inspection, HTTPS enforcement, and encouraging users to download and verify the code independently. Some users prefer to run the wallet software locally rather than through a web browser, which reduces reliance on the server for code delivery. Others use hardware wallets in combination with a view-only web wallet, keeping the spend key offline and using the view-only wallet only to check balances and construct unsigned transactions.

Password strength is also a constant vulnerability. A user who chooses a simple password like “123456” or a dictionary word will find that their encrypted recovery phrase can be cracked quickly by an attacker with modest computing resources. The security of a client-side monero wallet is therefore only as strong as the password protecting it, combined with the security of the device on which the wallet is accessed. No amount of sophisticated cryptography can compensate for a password that is weak or exposed.

The server cannot authenticate the user without the password, because the password is never sent to the server. Instead, the user’s browser decrypts the recovery phrase using the password, derives the keys, and uses those keys to prove ownership by signing a message or performing another cryptographic operation. This means the server never needs to validate the password itself, and it cannot be tricked into revealing data associated with an account if the correct password is not provided. However, it also means there is no account recovery if the password is forgotten, unless the user has preserved the recovery phrase separately.

Backup and recovery without centralized dependency

The recovery phrase is the master backup for any monero wallet. If the device is lost, the wallet is deleted, or the browser storage is cleared, the recovery phrase can be used to regenerate the entire wallet on any compatible device. Because the recovery phrase is generated locally and represents the complete cryptographic secret, it is also the critical point of failure: if the recovery phrase is lost, the funds are gone unless a secondary backup exists.

Secure backup therefore becomes the user’s responsibility, not the service’s. The recovery phrase should be written down on paper, stored in a secure physical location, and protected from theft, fire, and accidental disclosure. Some users use additional security measures such as splitting the phrase across multiple locations, using encryption even for the written copy, or memorizing parts of it. The trade-off is always between security (more obscurity and distribution of the phrase) and accessibility (being able to recover quickly if needed).

XMRWallet’s web interface provides no automatic cloud backup of the recovery phrase, and this is by design. Cloud backups would introduce a centralized dependency and a potential point where the phrase could be exposed. Instead, users are responsible for exporting, encrypting, and storing the recovery phrase themselves. This shifts burden to the user, but it also means no service can accidentally leak wallet backups, and no regulatory demand can force the service to disclose recovery information, because the service does not retain it.

For users who want additional security, keeping the recovery phrase entirely offline and using a view-only wallet for day-to-day balance checks and payment construction provides a good balance. The view-only wallet can be accessed frequently and even shared with trusted parties without risking the spend key. When a transaction needs to be signed, the user can move to a secure offline device, sign the transaction, and then broadcast it using the online view-only wallet. This approach dramatically increases the security boundary while still maintaining the convenience of a web-based interface.

Verifying client-side encryption in practice

A user seeking to verify that XMRWallet actually performs encryption on the client side can perform several checks. First, the code should be inspectable through the browser’s developer tools or by viewing the page source. Second, the JavaScript should include recognizable cryptographic libraries such as libsodium, tweetnacl, or similar, which handle the actual encryption. Third, network monitoring tools can show that the recovery phrase or password is never sent to the server in plain form. Fourth, the wallet should work with JavaScript disabled for non-essential functions, or at minimum, critical operations should be explainable through the visible code.

For users who are technically inclined, running the XMRWallet code locally—either by downloading the source code or by using a local copy served from a trusted environment—eliminates the dependency on the server for code delivery. This approach is more complex and requires some technical knowledge, but it provides the highest assurance that the client-side encryption is actually being performed without interference.

Trusting client-side encryption ultimately requires trusting the implementation. Cryptographic code is difficult to write securely, and subtle bugs can undermine security properties. However, client-side encryption is more auditable than server-side encryption, because the user can observe what code is being run and what data is being sent over the network. A service that claims to encrypt keys server-side requires the user to trust the service’s representation; a service that encrypts client-side allows the user to verify the claim by inspection. This transparency is one of the fundamental advantages of the client-side model.

Comparing client-side to other key management models

Custodial wallets (where a service holds the keys on the user’s behalf) are simple to use but introduce counterparty risk. The service could be hacked, the keys could be misused, regulatory action could freeze the account, or the service could simply disappear. Key management becomes the service’s responsibility, and the user has no technical assurance of security.

Multi-signature wallets distribute key material across multiple devices or services, so no single point of failure can compromise funds. However, setting up multi-signature wallets is complex, and the user must manage multiple keys across multiple devices or services. For Monero specifically, standard multi-signature support is more limited than for Bitcoin, because Monero’s privacy mechanisms work differently.

Client-side encryption, as implemented in XMRWallet, gives the user control while maintaining the simplicity of a single-device setup. The trade-off is that the user becomes responsible for password security and backup management. For many users, this is an acceptable and even preferable trade-off, because it eliminates a service as a point of failure. For users who prefer simplicity over control, custodial solutions may remain more appealing despite the security disadvantages.

Hardware wallets represent another approach: they use dedicated devices to generate and sign transactions, ensuring that private keys never touch a general-purpose computer. Hardware wallets can be combined with a view-only monero wallet on a networked device, providing the security benefits of both approaches. The hardware device handles key material, while the networked device handles blockchain scanning and transaction construction. This combination is considered the highest-security configuration for serious users.