What Are dApps, and How Do You Use Them More Safely?

What is a dApp, and how is it different from a normal app?

ethereum.org's technical introduction defines a dApp as "an application built on a decentralized network that combines a smart contract and a frontend user interface", with backend code "running on a decentralized peer-to-peer network" rather than on centralised servers (ethereum.org, Technical introduction to dapps). Take a decentralised exchange as the canonical example. The website you see is a front end, hosted conventionally, and replaceable: the actual exchange, the pools of tokens and the swapping rules, is a set of contracts on the chain. Nobody's server holds your balance; your wallet holds your assets, and a swap is you signing a transaction that hands the contract one asset and takes another by its coded formula. Lending markets, NFT marketplaces and on-chain games repeat the pattern with different rules.

"dApp" is an imprecise umbrella term, and it helps to separate four layers, because each can be run by different parties and each fails in its own way. The front end is the website or app, usually run by a team or company that controls its domain, hosting and the scripts and libraries it loads; it can restrict who uses it, for example by location, and it can be changed or taken down without the contracts changing. The smart contracts hold the assets and rules on the chain; some are fixed once deployed, while others can be upgraded or paused by holders of administrative keys. Governance is whoever can change the contracts or their parameters: a team's multisignature wallet, a vote of governance token holders, a foundation, or nobody, if the contracts are immutable. Centralised dependencies are the off-chain services the application relies on, such as node providers that relay requests to the chain, indexers and APIs that supply the data the front end displays, price oracles, bridges, and the issuers of any stablecoins it uses, some of whom can freeze tokens. Whether a particular dApp is decentralised is therefore a question to answer layer by layer, from its documentation, and the answer can differ for each.

Three consequences separate this from the apps you know. There is no account: your wallet address is your identity, and the same address walks into every application on that chain. That address is pseudonymous, and its full history is public; it can be linked to a person through exchange records, on-chain analysis, or data that a front end and its service providers collect, such as IP addresses. Access is also conditional in places: front ends can screen addresses or restrict regions, some contracts have allowlists or administrative controls, and an asset's issuer may be able to freeze it. In most cases there is no password reset or support desk that can reverse a confirmed action: the finality that protects your assets from others applies equally to your own mistakes. And the front end and the contracts can have different owners and different lifespans: the contracts can outlive the website, and a fake or compromised website can front perfectly real contracts or malicious ones. Two documented incidents show the second case. In December 2021, BadgerDAO's post-mortem describes a script injected into its front end through an API key on its Cloudflare account that, according to the post-mortem, had been created without the knowledge or authorisation of Badger engineers; the script "intercepted web3 transactions and prompted users to allow a foreign address approval to operate on ERC-20 tokens in their wallet", and the attacker then used those approvals to move users' funds to other accounts (BadgerDAO, Technical post mortem, December 2021). The post-mortem values the losses asset by asset at 2 December 2021 prices and says those values "should be taken as an indication and not absolute". In December 2023, Ledger's incident report describes malicious versions of its Connect Kit library, published after a former Ledger employee's package-registry account was phished, that injected drainer code into third-party dApps using the library. Ledger puts the time from the account compromise to resolution at approximately five hours, estimates that user assets were actively drained for less than two hours in total, and states that the attacker "did not at any time have access to any Ledger infrastructure, Ledger code repository, or to DApps themselves" (Ledger, Security incident report, 14 December 2023). In both cases, as the two reports describe them, the compromise sat in the page or library in front of the users, and the attacks worked through approvals and signatures the users gave.

What does connecting your wallet actually grant?

The connection step frightens beginners and deserves demystifying in both directions. What it grants is modest. MetaMask's documentation says a connected dApp "will be able to see the addresses of the selected accounts" and "can suggest transactions for those specific accounts", adding that "you will still have to manually approve these transactions" (MetaMask Help Center, "How to connect to a dapp"). Its dApp user guide is blunter: connecting "allows them to view your balance and suggest transactions, but they can't do anything with your assets unless you sign transactions they propose" (MetaMask Help Center, "User guide: dapps"). The connection itself adds proposals and nothing else: nothing new executes until you approve it. Earlier signatures are the exception, because they can keep working without a new request. An ERC-20 allowance lets the approved spender move tokens later through transferFrom, "using the allowance mechanism", up to the remaining allowance (OpenZeppelin, ERC-20 API reference). MetaMask's advanced permissions let a dapp act within limits granted once, for example spending up to 10 USDC a day "without requiring you to sign a transaction every day", until they are revoked or expire (MetaMask Help Center, "Understanding Advanced Permissions"). A connection from a wallet that has never granted such a permission, with zero signatures given, is a spectator relationship.

What it does not do is the part worth internalising, because the misunderstanding runs both ways. Connecting does not give the site custody, does not by itself give it any new power to take your assets, and does not need to be feared as the dangerous moment. And in the other direction: disconnecting afterwards does not undo anything. MetaMask's guide states that disconnecting from a dApp does not revoke token approvals you granted while connected. Those permissions live on the chain, in the token contracts, and persist whether or not any website is connected, which is why allowance hygiene later in this guide is a separate discipline from connection hygiene.

Connection hygiene still matters for one reason: the connection is where you choose whom you are talking to. Phishing sites imitate real applications closely, reach victims through search advertisements, lookalike domains and links in replies and direct messages, and their goal is to be connected and then to propose requests that look routine. ethereum.org's security guidance puts the habit in one line: "Always check that you are on the right domain, especially after clicking a link" (ethereum.org, Ethereum security and scam prevention). Reaching applications through saved bookmarks or their verified official channels narrows that route at no cost.

What are you agreeing to when you sign? Messages, transactions and allowances

Message signatures

A message signature is a signature over data that is not itself a transaction. Applications use it for logins: you sign a statement to prove you control the address, costing no gas and moving nothing. Two standards shape what your wallet shows you. EIP-191 defines the format for signed data and prefixes it with a byte chosen so the signed message can never be mistaken for a valid transaction (EIP-191, Signed Data Standard, 2016). EIP-712 defines typed structured data so that a wallet can display the fields of what you are signing "for verification when signing" rather than an opaque string (EIP-712, Typed structured data hashing and signing, 2017).

The caution is that a typed message can carry a payload that is economically real. ERC-2612 extends the ERC-20 token standard with a permit function that lets a token's allowance be changed "using a signed message, instead of through msg.sender": you sign off-chain, somebody else submits the signature on-chain, and the allowance appears (ERC-2612, Permit extension for EIP-20 signed approvals, 2020). Uniswap's Permit2 contract extends permit-style approvals to any ERC-20 token, including tokens without a native permit. It works in two steps: the user first gives the Permit2 contract an ordinary on-chain approval for the token, and after that, signed messages either set allowances held in Permit2 with an expiry time or authorise a one-off transfer (Uniswap, Permit2 repository). Either kind of signature costs nothing to sign and can look like a login, while its consequence matches an approval or a transfer. MetaMask's signature-phishing page describes this trade: a phishing dapp "is designed to prompt users to sign off-chain messages", and users who think they are depositing tokens or listing an NFT "may be inadvertently handing over an unlimited token approval, or allowing all their NFTs to be listed". The same page says that dapps supporting Permit2 "can use the signature to transfer tokens relatively freely" and that a Permit2 signature "can be configured to remain valid for a specified duration" (MetaMask Help Center, "Signature phishing"). An ERC-2612 permit signature carries a deadline and a nonce, so a signature you regret stays valid until its deadline passes or its nonce is consumed, and revoking allowances that already exist on-chain does not cancel it (ERC-2612). Permit2 signatures also carry a deadline, and the Permit2 contract adds functions for invalidating unused nonces and for revoking its allowances in a batch, each of which is an on-chain transaction that costs gas (Uniswap, Permit2 interfaces IAllowanceTransfer and ISignatureTransfer). The blind signing guide covers reading typed-data requests in detail.

Transactions

A transaction signature authorises one specific call: a swap, a transfer, a mint. When the destination is a contract, ethereum.org explains that the transaction "will execute the contract code", and its data field names the function to call and carries the arguments (ethereum.org, Transactions). What you commit to is that call with those arguments, executed once. That one call can still have several effects: a swap can route tokens through several contracts, and some calls combine an approval with a transfer. Once confirmed, it generally cannot be reversed. The habit that matters is matching what the wallet says the transaction does against what you believe you clicked, because a malicious front end's power is precisely the gap between those two. ethereum.org's guidance is the same: "read the transaction message before signing" (ethereum.org, Ethereum security and scam prevention).

Token allowances

An allowance is a specific kind of transaction payload, and the one that deserves the respect beginners give to connections. The ERC-20 standard separates holding from spending. Its approve function "allows _spender to withdraw from your account multiple times, up to the _value amount"; allowance reports how much "is still allowed to withdraw"; and transferFrom is the call the spender uses to take the tokens (ERC-20, Token Standard, 2015). For a contract to take your tokens as part of doing its job, you first approve that contract for an amount. The design is legitimate and necessary: an exchange contract needs it to swap for you, and ethereum.org notes that the approve and transferFrom pattern is the standard way to deposit ERC-20 tokens into a contract (ethereum.org, ERC-20 Token Standard). NFT collections have an equivalent: under ERC-721, setApprovalForAll lets an owner approve an "operator" to "manage all of msg.sender's assets" in that contract, meaning all of the owner's NFTs in that collection (EIP-721, Non-Fungible Token Standard, 2018).

The risk lies in three properties. An allowance persists until it is changed. It is commonly requested at a value so large it is effectively unlimited: MetaMask's documentation says requests often ask "for access to so many tokens that it's essentially unlimited" and that "requesting essentially unlimited amounts of tokens is also how many malicious sites steal from unsuspecting web3 users" (MetaMask Help Center, "What is a token approval?"). And a contract with a live allowance can call transferFrom at any moment with no further click from you. That is the machinery the BadgerDAO front-end injection used, as its post-mortem describes it: users were tricked into signing approve or increaseAllowance calls that allowed the attacker's account to spend their tokens, and the attacker later moved the funds on the users' behalf (BadgerDAO, Technical post mortem, December 2021). The theft is signed before it happens, by the victim, in a moment that felt routine.

What habits reduce the risks of using dApps?

Arrival discipline first: reach applications through saved bookmarks or their verified channels, and treat search advertisements, direct messages and reply links as untrusted until verified. MetaMask's signature-phishing page says to "always double-check the URL of the site requesting your signature"; ethereum.org says the same about domains. This habit reduces exposure to lookalike-site impersonation. It does not address a compromise of the genuine site, as BadgerDAO and Ledger Connect Kit both showed, which is why the next three habits exist.

Reading discipline second: treat the wallet's description of a request as the reference, and the website's story about it as a claim. When the two disagree, or the wallet shows an unreadable blob, the answer is no. Refusing a request costs nothing and reverses instantly; a wrong signature does neither. Wallets that support EIP-712 show typed data field by field; a request that arrives as raw hex, or that asks to sign with a legacy method the wallet warns about, is a request you cannot verify.

Allowance discipline third and fourth. When an approval is needed, wallets that expose a spending cap let you set the allowance to the amount the action requires. MetaMask's interface, for example, prompts for a custom value, the account's full balance, or the site's suggestion (MetaMask Help Center, "How to customize token approvals with a spending cap"); ethereum.org's guidance is to set "spending limits to only the amount necessary for the transaction" (ethereum.org, Ethereum security and scam prevention). The cost is approving again next time. Then, on a schedule, review the allowances your address carries and revoke what you no longer use. Block-explorer approval checkers and dedicated revocation tools list them; because allowances are on-chain, revocation is itself an on-chain transaction and "you need to pay gas fees for each revocation" (MetaMask Help Center, "How to revoke smart contract allowances/token approvals"). The ERC-20 specification itself notes that changing an allowance from one non-zero value to another has a known race condition and suggests setting it to zero first (ERC-20, Token Standard, 2015). Old, forgotten, unlimited allowances to contracts you used once are the kind of permission drainer campaigns look for.

Wallet separation comes last, and it limits what the failures above can reach. In this arrangement, a wallet used for applications holds only amounts whose loss its owner would tolerate, and a separate wallet holds long-term holdings and never connects to a site or signs an application request. A bad signature, a compromised front end or a poisoned allowance then reaches only the application wallet's contents. The arrangement has costs of its own: two sets of keys and backups to protect, and a network fee each time assets move between the wallets. The academy's complete guide to keeping crypto safe takes the same principle further; this is its application-layer version.

Frequently asked questions

Can a dApp steal my crypto just from connecting?

Connecting on its own does not move anything: MetaMask's dApp guide says a connection "allows them to view your balance and suggest transactions", and the connection adds nothing that executes until you approve a request (MetaMask Help Center, "User guide: dapps"). Allowances and other permissions you granted earlier, to any application, are unaffected by connecting or disconnecting and can be used without a new request. The practical question after connecting to a site that turns out to be fake is what you signed while it was connected. If the answer is nothing, the site learned your address and balances, which are public anyway. If you approved anything, two places show it: the wallet's activity history lists transactions, including approvals, and an approval checker lists live allowances. A signed ERC-2612 permit leaves no on-chain record, and so appears in no approval checker, until someone submits it, which is why a signed message on a site you now distrust calls for the same attention as an approval (ERC-2612). Disconnecting the site is sensible housekeeping, and MetaMask's guide notes that it "does not affect token approvals".

What is the difference between a dApp and DeFi?

DeFi is the financial subset of the application layer: exchanges, lending, derivatives built as contracts. dApps are the whole layer, including NFT platforms, games and identity tools. The academy's DeFi guide covers the financial machinery and its risks in depth.

Do I have to pay to use a dApp?

Interacting on-chain costs network fees, covered in this cluster's guide to gas and network fees: each transaction, including an approval or a revocation, pays the going rate, and failed transactions still consume gas. Message signatures cost nothing, which is precisely why permit-style signatures are attractive both to honest applications and to drainers. Applications may add their own fees inside their contract logic.

How do I see and revoke my old allowances?

Block-explorer approval checkers and dedicated revocation tools list the allowances an address has granted and let you revoke each with a transaction, which costs gas (MetaMask Help Center, "How to revoke smart contract allowances/token approvals"). A signed but unsubmitted ERC-2612 permit is different: it stays valid until its deadline passes or its nonce is used, and revoking on-chain allowances does not cancel it (ERC-2612). For Permit2 signatures, the Permit2 contract's nonce-invalidation functions can cancel an unused signature with a transaction (Uniswap, Permit2 interfaces). The habit worth keeping is a periodic review, plus an immediate one whenever an application you have used discloses a compromise.

What should I do if I signed a malicious approval or permit?

Revoking the allowance, or for Permit2 invalidating the unused nonce or revoking its approvals, stops further use of that permission; it is an on-chain transaction that costs gas, and it cannot reverse transfers that have already been confirmed (MetaMask Help Center, "How to revoke smart contract allowances/token approvals"; Uniswap, Permit2 interfaces). The steps after a theft are set out in order in the guide to responding if your crypto is hacked or stolen. Reporting routes include the FBI's Internet Crime Complaint Center at ic3.gov in the United States; Report Fraud, which has replaced Action Fraud, for England, Wales and Northern Ireland at reportfraud.police.uk or on 0300 123 2040; Police Scotland on 101 in Scotland; and the local police elsewhere (City of London Police, December 2025). A report does not guarantee that anything is recovered. Anyone who then offers to recover crypto for an upfront fee fits a known follow-on scam: the FBI warns that such fraudsters take the fee and either stop responding or ask for more, and that private recovery companies cannot issue seizure orders (FBI IC3, PSA, 11 August 2023).

Is it safer to use dApps from a hardware wallet?

A hardware wallet keeps the private key off the computer and, with a clear display, helps you verify what you sign. It does nothing about an allowance you consent to. In the Ledger Connect Kit incident, Ledger's report describes drainer code in third-party dApp pages that asked users to sign approval and permit messages or transfers; a signature given on any kind of wallet had the same effect (Ledger, Security incident report, 14 December 2023). A hardware wallet also brings its own dependencies: the device and its firmware, and a recovery-phrase backup that has to be stored safely. Signing discipline and wallet separation reduce the cost of consented mistakes, and they apply identically whatever holds the key.

Sources and further reading

Primary and reference sources for this guide. URLs were checked on 23 September 2026; the seven MetaMask Help Center pages, the OpenZeppelin ERC-20 reference, the ethereum.org Transactions page, the EIP-721 text, the Permit2 repository, the BadgerDAO and Ledger reports, the FBI IC3 advisory and the City of London Police notice were checked on 24 September 2026.

• Technical introduction to dapps. ethereum.org, undated documentation. https://ethereum.org/en/developers/docs/dapps/ (accessed 23 September 2026)
• ERC-20 Token Standard. ethereum.org, undated documentation. https://ethereum.org/en/developers/docs/standards/tokens/erc-20/ (accessed 23 September 2026)
• Ethereum security and scam prevention. ethereum.org, undated documentation. https://ethereum.org/en/security/ (accessed 23 September 2026)
• Transactions. ethereum.org, undated documentation. https://ethereum.org/developers/docs/transactions/ (accessed 24 September 2026)
• ERC-20 API reference (approve, allowance, transferFrom). OpenZeppelin Contracts 5.x documentation, undated. https://docs.openzeppelin.com/contracts/5.x/api/token/erc20 (accessed 24 September 2026)
• Understanding Advanced Permissions. MetaMask Help Center, undated. https://support.metamask.io/more-web3/dapps/advanced-permissions/ (accessed 24 September 2026)
• ERC-20: Token Standard (approve, allowance, transferFrom). Ethereum Improvement Proposals, November 2015. https://eips.ethereum.org/EIPS/eip-20 (accessed 23 September 2026)
• ERC-191: Signed Data Standard. Ethereum Improvement Proposals, January 2016. https://eips.ethereum.org/EIPS/eip-191 (accessed 23 September 2026)
• EIP-712: Typed structured data hashing and signing. Ethereum Improvement Proposals, September 2017. https://eips.ethereum.org/EIPS/eip-712 (accessed 23 September 2026)
• ERC-2612: Permit Extension for EIP-20 Signed Approvals. Ethereum Improvement Proposals, April 2020. https://eips.ethereum.org/EIPS/eip-2612 (accessed 23 September 2026)
• How to connect to a dapp. MetaMask Help Center, undated. https://support.metamask.io/more-web3/dapps/connecting-to-a-dapp/ (accessed 24 September 2026)
• User guide: dapps. MetaMask Help Center, undated. https://support.metamask.io/more-web3/dapps/user-guide-dapps/ (accessed 24 September 2026)
• What is a token approval? MetaMask Help Center, undated. https://support.metamask.io/stay-safe/safety-in-web3/what-is-a-token-approval/ (accessed 24 September 2026)
• How to customize token approvals with a spending cap. MetaMask Help Center, undated. https://support.metamask.io/configure/tokens/how-to-customize-token-approvals-with-a-spending-cap/ (accessed 24 September 2026)
• How to revoke smart contract allowances/token approvals. MetaMask Help Center, undated. https://support.metamask.io/more-web3/learn/how-to-revoke-smart-contract-allowances-token-approvals/ (accessed 24 September 2026)
• Signature phishing. MetaMask Help Center, undated. https://support.metamask.io/stay-safe/protect-yourself/wallet-and-hardware/signature-phishing/ (accessed 24 September 2026)
• ERC-721: Non-Fungible Token Standard (setApprovalForAll, isApprovedForAll). Ethereum Improvement Proposals, January 2018. https://eips.ethereum.org/EIPS/eip-721 (accessed 24 September 2026)
• Permit2 repository and README. Uniswap, GitHub, undated. https://github.com/Uniswap/permit2 (accessed 24 September 2026)
• Permit2 interface IAllowanceTransfer.sol (permit, approve, invalidateNonces, lockdown). Uniswap, GitHub, undated. https://raw.githubusercontent.com/Uniswap/permit2/main/src/interfaces/IAllowanceTransfer.sol (accessed 24 September 2026)
• Permit2 interface ISignatureTransfer.sol (permitTransferFrom, invalidateUnorderedNonces). Uniswap, GitHub, undated. https://raw.githubusercontent.com/Uniswap/permit2/main/src/interfaces/ISignatureTransfer.sol (accessed 24 September 2026)
• BadgerDAO Exploit Technical Post Mortem. BadgerDAO, December 2021. https://badger.com/technical-post-mortem (accessed 24 September 2026)
• Security Incident Report. Ledger, 14 December 2023. https://www.ledger.com/blog/security-incident-report (accessed 24 September 2026)
• Scam Sniffer 2025: Crypto Phishing Losses Fall 83% to $84 Million. Scam Sniffer, 3 January 2026. Data provider report; scope is wallet-drainer phishing on EVM chains only, described by the authors as a lower bound. https://drops.scamsniffer.io/scam-sniffer-2025-crypto-phishing-losses-fall-83-to-84-million/ (accessed 23 September 2026)
• Increase in Companies Falsely Claiming an Ability to Recover Funds Lost in Cryptocurrency Investment Scams (PSA230811). FBI Internet Crime Complaint Center, 11 August 2023. https://www.ic3.gov/PSA/2023/psa230811 (accessed 24 September 2026)
• Report Fraud service goes live with full public launch in January 2026. City of London Police, December 2025. https://www.cityoflondon.police.uk/news/city-of-london/news/2025/december/report-fraud-service-goes-live-with-full-public-launch-in-january-2026/ (accessed 24 September 2026)
• 2025 Internet Crime Report. FBI Internet Crime Complaint Center, 2026. Context for overall crypto-related fraud losses (about $11bn reported); it does not break out approval or drainer theft. https://www.ic3.gov/AnnualReport/Reports/2025_IC3Report.pdf (accessed 23 September 2026)