A user holds Ethereum and stablecoins in a self-custody wallet and wants to participate in decentralized finance—depositing into a lending protocol, trading on a decentralized exchange, or providing liquidity. The immediate question is not whether these actions are possible. It is how to connect a non-custodial wallet to smart contracts without losing control of private keys, how to understand what permissions are being requested, and how to estimate costs before approving a transaction. A Web3 wallet that supports browser extension integration and Ethereum dApp compatibility can streamline this workflow, but the mechanics matter more than the interface convenience.
Guarda Wallet functions as a Web3 wallet across multiple platforms—desktop, mobile, web browser, and browser extension—and maintains the core principle that private keys remain under the user’s control on their device. Unlike exchanges or custodial services, Guarda does not hold or manage assets on behalf of users. Instead, it enables direct interaction with smart contracts, token swaps, staking mechanisms, and Ethereum-compatible networks by injecting transaction-signing capability into the browser or application environment. That architecture creates a clear separation between holding assets and approving their use, but it also requires users to verify contract addresses, understand gas economics, and manage token approvals with precision.
How Guarda connects to Ethereum dApps as a Web3 integration layer
A Web3 integration means the wallet injects cryptographic signing capability into a web-based application without requiring the dApp itself to control or see private keys. When a user visits a decentralized exchange, lending protocol, or NFT marketplace through a standard browser, that website runs JavaScript code. If the wallet extension is installed, it makes a signing function available—typically through an injected `window.ethereum` object—that dApps can request for transaction approval.
Guarda’s browser extension integrates into this standard by supporting MetaMask-compatible requests. That compatibility matters because most Ethereum dApps expect the MetaMask API contract: the same method signatures, event handlers, and error responses. Guarda does not mimic MetaMask’s code; rather, it implements the same interface so that dApps can request signatures without modification. A user installing the Guarda Wallet extension gains the ability to approve transactions on any dApp that supports the standard injected provider pattern, whether it is a major protocol or a smaller project.
The connection process begins when a dApp detects that an Ethereum-compatible provider is available. Most will show a “Connect Wallet” button. Clicking it triggers a request to Guarda’s extension, which displays a modal asking the user to select which account they want to expose to that specific application. At this moment, the user is deciding whether to link their Ethereum address to the dApp. The address is public—it will eventually appear on the blockchain—but the decision of whether to reveal it now, on this particular site, remains under user control. After selection, the dApp receives the chosen address and can begin displaying balances, available contracts, and potential actions.
This initial connection is one of the most important security decisions because it is also one of the easiest to make carelessly. A phishing site mimicking a legitimate dApp can request wallet connection and receive a valid address. The user may then be prompted to approve a transaction or sign a message. Unlike a legitimate protocol, a fake site will direct that approval to a malicious contract or steal the signature itself. The address alone is not secret, but the approval permissions granted afterward are irreversible until explicitly revoked. Verifying the domain, checking the URL carefully, and confirming the wallet’s display before approving anything is more important than the speed of connection.
Understanding smart contract interaction and transaction approval
Once connected, a dApp typically displays functions available in one or more smart contracts. A lending protocol might show “Deposit,” “Withdraw,” “Borrow,” and “Repay” buttons. A decentralized exchange might show a swap interface with token selection and amount input. Behind each button is a function call targeting a specific contract address on a specific network. When a user clicks “Deposit,” the dApp constructs a transaction that encodes that function call, sets the amount and recipient, and asks Guarda to sign it.
At this point, the wallet’s role becomes critical. Guarda must display the transaction details clearly enough that the user can verify what they are actually approving. This includes the contract address being called, the network (Ethereum mainnet, Polygon, Arbitrum, or another EVM-compatible chain), the amount of native currency (ETH or the chain’s equivalent) being spent on gas, and the specific function parameters. A robust Ethereum wallet interface will show the decoded transaction—translating raw bytecode into human-readable function names and parameters—rather than forcing users to verify hex strings.
A common and dangerous interaction is the token approval. Before a user can deposit a stablecoin into a lending protocol, they must first approve the protocol’s contract to transfer that specific token on their behalf. This is not a transfer itself; it is a permission grant. The user signs a message that tells the token contract: “Allow [lending protocol address] to move up to [amount] of my tokens.” This permission is necessary because Ethereum’s ERC-20 standard requires explicit approval before a contract can move tokens from a user’s wallet. Without this, every dApp would need the user’s private key to execute transactions—an unacceptable security model.
But approval creates its own risks. If the approved contract is compromised or has a bug, the attacker could drain the approved amount. If the user approves an unlimited amount (a common default), the contract has permission to move that many tokens repeatedly, potentially forever. Guarda’s interface should allow users to set approval limits—approving exactly the amount they need for one transaction, or a slightly larger amount for repeated interactions, rather than a blank check. After the transaction is confirmed on the blockchain, that approval remains active. Revoking it requires another transaction, which costs gas. Some users maintain a revocation workflow: use an approval, then immediately revoke it to limit exposure. Others manage multiple tokens across multiple protocols and rarely track what they have approved. The risk is real, and the interface cannot entirely eliminate it; it can only make the cost and mechanics visible.
Gas fee estimation and transaction cost management
Every transaction on Ethereum requires payment in ETH to compensate miners and secure the network. This payment is called a gas fee. Gas is not a fixed cost; it depends on network congestion, the complexity of the transaction, and the user’s chosen priority. A simple approval might cost 60,000 gas units; a complex multi-step swap might cost 300,000. Gas price fluctuates, sometimes dramatically, based on demand. During network congestion, gas can spike from 30 gwei to 100+ gwei per unit, multiplying the dollar cost of the same transaction.
Guarda displays estimated gas fees before the user approves a transaction. The wallet queries the network’s current gas price, multiplies it by the estimated gas used for the specific function being called, and shows the result in ETH and the user’s preferred fiat currency. Most wallets also allow the user to adjust the “priority” of the transaction—setting a higher gas price to prioritize it in a congested block, or a lower price to save money at the risk of slow confirmation or temporary failure.
Understanding this trade-off is important for practical DeFi participation. A deposit into a lending protocol might cost $20 in fees when the network is quiet and $200 when it is congested. Approving a token for the first time costs money; approving it again for a different contract costs money. If a user plans to deposit $100 into a protocol and the gas fee is $80, the economics change significantly. Some sophisticated users wait for periods of lower congestion, batch multiple transactions together, or use layer 2 networks like Polygon or Arbitrum where fees are substantially lower. Guarda supports these alternatives by allowing users to switch networks within the wallet and interact with dApps on those chains using the same interface.
The practical approach is to treat gas estimation as a forecast rather than a guarantee. The wallet cannot predict exact gas prices minutes in the future, especially during volatile periods. If a user sets a moderate gas price, the transaction might wait longer for inclusion but eventually succeed. If they set it too low, the transaction might remain pending until they accelerate it (paying additional fees to prioritize it retroactively) or cancel it. Guarda allows users to view pending transactions and manually adjust or cancel them from within the wallet interface, which reduces the sense of helplessness that can come from a transaction sitting indefinitely in the mempool.
Setting up and managing connected accounts and permissions
Most users do not connect the same account to every dApp they use. Instead, they might maintain separate Ethereum addresses for different purposes: one for active trading and swaps, another for longer-term staking or NFT holding, a third for experimental or high-risk contracts. Guarda supports multiple accounts within a single wallet, each derived from the same recovery phrase but with a distinct address and balance. When a dApp requests connection, the wallet can display all available accounts and let the user choose which one to expose.
After connection, the dApp knows which address is interacting with it, but it does not automatically know anything about the other addresses in the wallet. This compartmentalization reduces linkage between different activities. A user might connect one address to a privacy-focused DEX and another to a regulated trading platform without the two services being obviously connected in the public blockchain record. Guarda maintains a connection history—showing which dApps are connected to which accounts—and allows users to disconnect or revoke permissions at any time.
Revocation is particularly important for accounts that are no longer in active use or for connections to dApps the user no longer trusts. Within the wallet, users can view connected sites and disconnect them by clicking a single button. This removes the dApp’s ability to request new transactions from that account, but it does not undo past approvals or transactions. If the user previously approved a token transfer to a contract, disconnecting from the dApp does not automatically revoke that approval. The token approval remains active until explicitly revoked through a separate transaction directed at the token contract itself, which again costs gas.
Managing these permissions requires ongoing attention. A practical workflow is to periodically audit connected dApps, remove ones no longer in use, and review token approvals on services like Etherscan’s token approval tracker. This is not glamorous security work, but it reduces the risk that a compromised contract or a dormant dApp with a vulnerability could drain approved tokens.
Navigating network selection and cross-chain interactions
Ethereum is not the only network that uses the EVM (Ethereum Virtual Machine) model. Polygon, Arbitrum, Optimism, Avalanche, Binance Smart Chain, and dozens of others run compatible smart contracts with their own assets, dApps, and gas economics. Guarda supports interaction with many of these networks through the same browser extension interface. When a user visits a dApp running on Polygon, for example, Guarda can detect the network and automatically switch to Polygon mode, or the user can manually select it from a dropdown.
This flexibility creates convenience but also complexity. Assets on Ethereum do not automatically exist on Polygon. A user holding USDC on Ethereum must bridge or swap it to Polygon USDC if they want to use a Polygon dApp. Bridges are contract interactions themselves, adding another layer of transaction fees and approval permissions. Some bridges are official and operated by token issuers; others are community-run or operated by dApp protocols. The fees, security model, and trust assumptions differ.
A common mistake is to send tokens to a contract address on the wrong network. If a user approves a transaction to send ETH to a bridge on Arbitrum but accidentally confirms it on Ethereum, the ETH goes to the bridge’s Ethereum address instead, which might not exist or might not be set up to return funds. The asset is then inaccessible. Guarda’s interface should reinforce network awareness—displaying the current network prominently, warning when a connection changes, and confirming the network as part of the transaction approval flow.
For users actively engaging with multiple chains, a DeFi wallet that supports network switching without app restarts or cumbersome re-connection procedures is materially more usable than one that does not. The trade-off is that easier switching can lead to careless mistakes if the user does not maintain attention to which network they are on. Double-checking the network name in the wallet interface before approving any transaction is essential.
Transaction confirmation and on-chain settlement verification
After a user signs a transaction in Guarda and approves it, the wallet broadcasts it to the network. This is the moment the transaction becomes visible in the mempool—the queue of pending transactions waiting to be included in a block. Guarda will display a transaction hash, which is a unique identifier for that specific transaction. This hash can be used to track the transaction on a blockchain explorer like Etherscan, where anyone can view the transaction status, gas paid, and final outcome.
Confirmation takes time. On Ethereum mainnet, the average block time is about 12 seconds, so a transaction is typically included within one to several minutes if the gas price is reasonable. During congestion, it might take longer. The user can check the transaction hash in a block explorer to see if it has been included, how much gas was actually consumed, and whether it succeeded or failed.
Failures happen. A contract might revert because a condition was not met—for example, the amount of liquidity available for a swap is lower than expected, or the lending protocol is at capacity. A failed transaction consumes gas without completing its intended action. Some dApps offer a “simulation” or preview of whether a transaction will succeed before the user pays to execute it. Guarda’s integration with dApps that provide this feature can help users avoid paying gas for transactions that will definitely fail.
Once a transaction is confirmed on-chain, it is immutable. Reversing it, changing its destination, or undoing its effects requires another transaction. This finality is fundamental to blockchain security and is not negotiable. Users should treat the moment they click “confirm” as the moment their intention becomes irreversible. This is why interface clarity—showing exactly what contract is being called and what will happen—is not a luxury. It is a prerequisite for safe participation.
Security best practices when connecting to dApps through Guarda
Using Guarda as a Web3 wallet and crypto security tool requires discipline at multiple levels. First, device security: the wallet’s private keys are stored locally on the user’s device, protected by device-level encryption and password. A compromised device—one infected with malware or accessed physically by an attacker—can still be exploited. Using biometric authentication on mobile, enabling two-factor authentication where available, and keeping the operating system and browser updated reduces attack surface.
Second, backup security: Guarda generates a recovery phrase when the wallet is first created. This phrase is the master key to the entire wallet. If lost, the user cannot recover their assets. If stolen, an attacker can recreate the wallet and transfer all funds. The recovery phrase should be written down, stored in a secure location offline, and never typed into a computer or shared digitally. Testing the recovery phrase by creating a new wallet in a test environment is a good security practice, but it should be done carefully to avoid exposing the phrase online.
Third, dApp verification: before connecting to a dApp or approving a transaction, verify that the domain is correct. Phishing sites are common. A URL that looks similar to a legitimate dApp—using lookalike characters or a similar domain name—can trick users into connecting and then requesting harmful approvals. Bookmarking legitimate dApps and always accessing them through the bookmark, rather than through search results, reduces phishing risk. If a user finds a dApp through a recommendation, verifying that address through multiple sources is prudent.
Fourth, approval and permission management: approve tokens only for the amount and duration needed. Use protocol-specific addresses from official documentation, not from third-party lists. After a transaction completes, consider revoking approvals for contracts that are no longer in use. Use separate accounts for risky or experimental transactions, keeping most funds in a separately-held account. Guarda’s multiple-account feature supports this strategy directly.
Fifth, monitoring: periodically check connected dApps and revoke permissions for services no longer in use. Review token approvals through third-party trackers. Track balances and watch for unexpected transactions. If the device or recovery phrase is ever at risk of compromise, move funds to a new wallet immediately. The more actively a user participates in DeFi, the more important this ongoing monitoring becomes.
When to use Guarda versus hardware wallets or other alternatives
Guarda prioritizes accessibility and speed. The browser extension enables nearly instantaneous dApp connection and transaction approval. Hardware wallets like Ledger or Trezor provide stronger isolation between private keys and internet-connected devices, but they require additional hardware, slower transaction workflows (physically confirming each transaction on the device), and are less convenient for frequent trading or interaction.
For users managing smaller amounts, making occasional transactions, or learning DeFi, Guarda’s balance between security and usability is reasonable. For users controlling large amounts, trading frequently, or managing institutional funds, hardware wallets or multi-signature arrangements become more justified despite the added friction. Some sophisticated users use a combination: Guarda for frequent small transactions and testing, hardware wallets for holdings or high-value transfers.
The key question is not which tool is universally “best” but which aligns with the user’s actual risk and usage profile. A user holding $10,000 in tokens and executing one swap per month has different needs than someone trading daily with six-figure balances. Guarda’s non-custodial architecture and device-based key storage are strong for self-custody, but they do not eliminate the possibility of compromise if the device itself is compromised or if the user makes poor decisions about which dApps to trust or what permissions to grant.
Frequently asked questions
Can I connect the same Guarda account to multiple DeFi protocols at the same time?
Yes. Each connection is independent, and you can remain connected to multiple dApps simultaneously. Guarda maintains a list of connected sites and allows you to disconnect from any of them individually. Each connection reveals your address to that dApp but does not automatically share it with others. However, disconnecting from a dApp does not revoke past token approvals—those remain active until you explicitly revoke them through a transaction directed at the token contract itself.
What happens if I approve a token for unlimited use and the contract is later hacked?
If a contract you have approved is compromised and has a bug or is exploited, the attacker could potentially drain up to the approved amount from your wallet without additional permission. This is why setting specific approval limits—approving only the amount you need for a transaction—is safer than unlimited approvals. You can also revoke an approval by sending a transaction to the token contract setting the allowance to zero, though this costs gas and must be done manually.
Can I use Guarda on multiple devices with the same wallet?
Yes. Guarda generates a recovery phrase during wallet creation. You can import that same phrase into Guarda on a different device, and all accounts and balances will be restored. However, each device maintains its own local copy of the keys, and if one device is compromised, the keys on that device are at risk. For accounts holding large amounts or executing sensitive transactions, using separate devices or hardware wallets is more secure.