Is Guarda Wallet Truly Non-Custodial? Deep Dive Into Its Architecture and Claims

A user holds Bitcoin, Ethereum, and a collection of NFTs across multiple blockchains. The practical question is not whether a wallet application exists—dozens do—but whether the company running that wallet can access the funds at any point. For non-custodial wallets, the answer should be architectural: the application cannot access funds because it never controls the private keys. Guarda wallet operates under this model, but the distinction between „cannot access“ and „will not access“ depends on specific technical choices made during key generation, storage, and transaction signing.

The broader problem is that non-custodial claims often remain vague. A wallet may be open source but compiled from untrusted binaries. It may store keys locally but require internet access at vulnerable points. It may sign transactions without broadcasting them, creating an attack surface where the user’s approval is the only remaining control. Understanding whether guarda wallet truly protects user funds requires examining the specific mechanisms: where keys are created, how they are stored, what happens during a transaction, and whether the company’s infrastructure could intercept or modify operations even if policy prohibits it.

How Guarda wallet generates and stores private keys

The first step in evaluating non-custodial architecture is observing where private keys originate. In the guarda wallet ecosystem, key generation happens on the user’s device—desktop, mobile, or web browser—not on a company server. When a new wallet is created, the application uses the device’s operating system entropy to generate a random seed phrase, typically represented as 12 or 24 words. This seed phrase is the master secret from which all cryptocurrency keys derive. The crucial architectural fact is that Guarda’s servers never receive this seed phrase. No copy is transmitted during creation, no backup is sent to the company’s infrastructure, and no central record of the phrase exists in Guarda’s systems.

After generation, the seed phrase and the derived private keys must be stored somewhere. Guarda wallet employs encryption at multiple layers. On mobile platforms—iOS and Android—the wallet leverages device-level encryption provided by the operating system. iOS uses the Secure Enclave, Apple’s dedicated cryptographic processor, to protect sensitive material. Android uses the Keystore system, which provides hardware-backed or software-based protection depending on device capabilities. The private keys are not stored in plaintext on the device’s file system. Instead, they are encrypted using a password that the user provides during wallet setup. This password is not sent to Guarda’s servers; it remains on the device and is used only for local encryption and decryption.

Desktop versions for Windows, macOS, and Linux follow a similar pattern, though device-level encryption varies. On macOS, the application integrates with the Secure Enclave available on Apple Silicon devices, similar to mobile. On Windows and Linux, encryption relies on OS-level credential storage and application-layer encryption using industry-standard algorithms such as AES-256. The critical distinction is that the guarda wallet application encrypts keys locally using the user’s password as the encryption key. If someone accesses the device or steals the encrypted wallet file, they cannot recover the private keys without the password. The encrypted data itself is useless without decryption.

The web browser version and browser extension introduce a different consideration. Browser-based environments have less direct access to hardware encryption than native applications. However, guarda wallet’s browser implementation still generates keys locally within the browser’s JavaScript environment and encrypts them using the user’s password. The encrypted keys can be stored in browser local storage or synced to the user’s cloud account if they choose the optional recovery backup feature. Importantly, any cloud storage is encrypted before transmission—the keys never travel unencrypted to Guarda’s servers or any third-party cloud provider. The user can also operate the guarda wallet entirely offline in a web browser context, creating an airgapped environment where keys remain isolated.

Transaction signing and the question of key access during payments

A private key’s vulnerability often peaks during use. When a user wants to send cryptocurrency, the private key must be accessed to sign a transaction. If Guarda’s infrastructure could intercept the key during this moment, the non-custodial claim would collapse. Understanding the signing process is therefore essential to evaluating whether guarda wallet actually prevents the company from accessing funds.

The signing workflow in guarda wallet operates locally on the user’s device. When a transaction is initiated—entering a recipient address and amount, for example—the application constructs a transaction object. This object is then signed using the private key, but the signing happens entirely within the application on the user’s device. The signature, not the private key, is what gets transmitted to the blockchain network. The blockchain validates the transaction by checking that the signature matches the public key (which is publicly known and linked to the wallet address), but the private key itself never leaves the device.

This architecture means that Guarda cannot sign transactions on behalf of the user, and the company cannot intercept the private key at the moment of signing because the key never travels to Guarda’s servers. A potential vulnerability would exist if Guarda’s application software were modified—either through a compromised build, a trojan deployment, or malicious code injection—to extract the private key. However, users can verify this risk by reviewing Guarda’s open-source code repositories and checking that the compiled application matches the published source. Mobile applications distributed through Apple’s App Store and Google Play undergo code review, though the reviews do not guarantee absolute security. Users seeking maximum assurance can inspect the source code directly or rely on third-party security audits if available.

The practical implication is that Guarda cannot access a user’s private key without either compromising the user’s device, modifying the wallet application before installation, or obtaining the user’s password. The password itself is not transmitted to Guarda—it is used only locally to encrypt and decrypt the private keys stored on the device. A person with access to Guarda’s servers and databases cannot retrieve a user’s funds because the private keys are not stored there.

Recovery phrases and backup security

The seed phrase—the 12 or 24 words generated during wallet creation—is the single most critical secret in a non-custodial system. If an attacker obtains the seed phrase, they can regenerate all private keys and completely drain the wallet. Guarda wallet’s approach to recovery phrase security is therefore central to understanding whether the non-custodial model is actually secure in practice.

When a guarda wallet is first created, the application displays the seed phrase on the user’s screen and instructs them to write it down on paper or store it in an offline location. Guarda strongly recommends against storing the seed phrase digitally, in cloud services, or anywhere an attacker could access it remotely. The seed phrase is not automatically backed up to Guarda’s servers. The user is responsible for secure storage. This responsibility is both the strength and the weakness of self-custody: users gain complete control, but they also bear the full burden of protecting their recovery material.

Guarda offers an optional recovery backup feature that encrypts the seed phrase and allows users to store an encrypted copy in their cloud account or with a backup service. The encryption happens on the user’s device before transmission—the seed phrase is never sent unencrypted to Guarda or a cloud provider. A user who chooses this option must understand that they are trusting an encryption implementation with their most valuable secret. If Guarda’s encryption is weak, or if the encryption keys are compromised, the backup becomes a liability. Most security experts recommend that users store recovery phrases offline: written on paper, engraved on metal, or stored in a physical safe. This approach eliminates the risk of digital compromise at the cost of introducing physical loss or theft risk.

The fundamental point is that Guarda cannot force a user to back up their seed phrase, nor can the company require users to authenticate with Guarda to recover funds. A user with a written recovery phrase can regenerate their wallet using any compatible wallet application—Guarda’s or a competitor’s. This portability is a core feature of non-custodial design. It also means that a user should never be dependent on Guarda to access their funds. If the company disappeared tomorrow, users could import their recovery phrase into any other wallet supporting the same cryptocurrencies.

The role of Guarda’s servers and what they actually see

A non-custodial wallet still requires servers for some functions. Guarda’s infrastructure handles blockchain synchronization, which means it retrieves transaction history and current balance information from blockchain networks. It also facilitates connection to decentralized applications, handles exchange routing for in-wallet swaps, and provides services such as staking integration and NFT metadata retrieval. Understanding what Guarda’s servers see—and what they do not—clarifies the actual scope of the non-custodial claim.

When a user checks their balance in guarda wallet, the application queries blockchain data to determine how much cryptocurrency is associated with the user’s address. This query reveals the user’s address to Guarda’s server. An address alone does not expose the user’s identity unless they have already linked that address to their name elsewhere. However, the pattern of balance checks, the frequency of logins, and the timing of address queries could create a behavioral profile. A user concerned about this metadata exposure can configure guarda wallet to connect to a blockchain node that they control personally, or to use a privacy-focused node service. This option places the burden of infrastructure on the user but eliminates Guarda as a point of observation.

When a transaction is broadcast to the blockchain network, Guarda’s servers typically handle the relay to the network. The user’s application constructs and signs the transaction, but Guarda forwards it to blockchain nodes. At this moment, Guarda’s servers see the unsigned transaction data: the recipient address, the amount, and the transaction structure. They do not see the private key that created the signature (because the signature is created on the user’s device). However, they do see what is being sent and to where. A user seeking to hide transaction details from Guarda could route transactions through their own node or a privacy-focused relay service, though this requires technical setup.

The practical reality is that Guarda’s non-custodial design prevents the company from stealing funds, but it does not provide complete anonymity or hide metadata from Guarda’s infrastructure. Users who wish to operate guarda wallet with minimal information leakage should configure private node connections, use Tor or a VPN for network privacy, and understand that open blockchain transactions are inherently visible to anyone observing the network. Non-custodial means „the company cannot take your money,“ not „the company cannot see that you have money.“

Multi-platform synchronization and key security across devices

Guarda wallet operates across desktop, mobile, web, and browser extension platforms. A user might have the same wallet running on their iPhone, a Windows desktop, and a web browser. This convenience introduces a synchronization question: how are keys kept synchronized across devices without exposing them during transfer?

Guarda wallet does not replicate the private keys across devices automatically. Instead, each device independently derives the same keys from the seed phrase. When a user imports their recovery phrase into guarda wallet on a second device, that device regenerates the keys locally using the same seed phrase, producing identical key material without transmission. The encrypted private keys on each device are protected independently by that device’s encryption mechanisms and the user’s password.

However, users can optionally sync their wallet data—such as address labels, transaction history, and preferences—across devices through encrypted cloud backup. This synchronization of metadata is different from synchronizing private keys. The private keys themselves are never synced; only the encrypted backup of the seed phrase (if enabled) and wallet metadata are shared across devices. This design allows users to recover their wallet on a new device using their recovery phrase, while maintaining privacy-sensitive key material locally on each device.

A risk emerges if a user enables cloud synchronization and does not understand what is being synchronized. If the seed phrase backup is enabled and cloud credentials are compromised, an attacker could access the encrypted backup. However, the backup is encrypted before transmission, so a brute-force attack would be required. A user with a strong password and encrypted backup in a compromised cloud account is still protected, though the risk is elevated compared to offline storage. Users should enable cloud sync only if they understand the trade-off and have configured strong passwords.

Exchange, staking, and smart contract interaction risks

Guarda wallet includes built-in features for exchanging cryptocurrencies without leaving the application, staking coins for rewards, and interacting with decentralized applications. These features are convenient, but they represent additional trust points beyond the core non-custodial mechanism.

In-wallet exchange through guarda wallet connects users to liquidity providers and market makers. The user approves a swap, the private key signs the transaction locally, and the trade executes on the blockchain. The user never sends their private keys to an exchange, so the non-custodial property is preserved. However, the user must trust the exchange route selected by guarda wallet. A slippage error, a compromised liquidity provider, or a phishing-like address substitution could result in funds being sent to an unintended recipient. The transaction signing happens on the user’s device, so the user has the responsibility to verify the destination address before approving. Many users skip this verification step, trusting that the interface is honest. If Guarda’s application were compromised or if a user’s device were infected with malware, the destination address could be altered without the user’s knowledge.

Staking through guarda wallet typically delegates coins to a staking service selected by the company. The user’s private keys are not shared with the staking service; instead, a public address is delegated to a validator. The non-custodial property is maintained because staking does not require key transmission. However, the user trusts Guarda’s selection of staking partners. If Guarda recommends a malicious validator or one that performs poorly, the user’s staking rewards could be lost or reduced. Users should understand that staking through guarda wallet is a convenience, not a guarantee of optimal returns.

Smart contract interaction—using decentralized applications through guarda wallet’s Web3 integration—follows the same pattern: the user’s device signs transactions, but the user approves interaction with arbitrary smart contracts. A malicious contract could be designed to drain tokens or execute unintended actions. Guarda cannot prevent this attack because the user is the one authorizing the contract interaction. The wallet can provide warnings about suspicious contracts, but the final approval remains the user’s responsibility.

Verifying the non-custodial claim through code and third-party audits

The strongest evidence that guarda wallet is non-custodial comes from source code review and third-party security audits. Guarda publishes open-source repositories for many of its components, allowing security researchers to inspect the code for backdoors, key extraction vulnerabilities, or unauthorized transmissions. An open-source codebase does not guarantee security—the code must still be compiled and distributed, and users must verify that the compiled application matches the published source—but it enables transparency that proprietary applications cannot provide.

Third-party security audits, when published, offer additional assurance. An audit by a reputable firm examines the wallet’s key generation, storage, signing, and network communication mechanisms to identify vulnerabilities. If a published audit finds no mechanism for Guarda to extract keys, that finding carries weight. However, audits are snapshots in time. A wallet updated after an audit could introduce new vulnerabilities or malicious code.

Users seeking maximum confidence should consider a combination of approaches. Download guarda wallet from the official source, verify the application signature if available, enable automatic updates to receive security patches, review the open-source code yourself if you have the technical capability, and consult published security audits. Do not rely on any single assertion—especially not a company’s own claims—to prove non-custodial security. The architecture is verifiable, but verification requires effort and technical knowledge.