Blog

A user receives a notification: “Claim your airdrop now. Connect your wallet to verify eligibility.” The message looks official, the website appears legitimate, and the prospect of free tokens is genuine. But the actual transaction being submitted is not a simple claim. It is a request to grant unlimited spending permission to a contract that will immediately drain stablecoins, NFTs, or other assets from the wallet, leaving the user with worthless tokens or nothing at all. This pattern has become one of the most profitable attack vectors in cryptocurrency, disguised as generosity but structured as systematic asset theft.

The mechanics are deliberate. An attacker creates a fake airdrop site, stakes small amounts of legitimate-looking tokens, and broadcasts an invitation through social media, email, or token holder registries. When a user connects their wallet and approves the “verification” transaction, they are not claiming an airdrop. They are signing a smart contract interaction that sets token allowances to the attacker’s address, grants borrowing permissions, or activates a hidden drain function. By the time the user realizes what happened, the theft is already confirmed on-chain and irreversible. The challenge for wallet users is that these attacks rely on a gap between what the user intends and what the transaction actually does.

Why standard wallet approvals are the primary attack surface

The Ethereum approval mechanism exists for legitimate reasons. When a user interacts with a decentralized exchange, lending protocol, or staking contract, they must grant that contract permission to move specific tokens on their behalf. This is called an allowance. The contract needs this permission to execute swaps, deposits, or transfers as part of a normal operation. Without approvals, most DeFi interactions would be impossible because every action would require a separate transaction and explicit transfer.

Attackers exploit this necessity by requesting approvals in contexts where the user expects something different. An airdrop claim form asks the user to “verify wallet ownership” but actually requests an unlimited allowance to a malicious contract address. The transaction data appears cryptic in most wallets because it is encoded in hexadecimal, making it difficult to distinguish a legitimate approval from a theft setup. The visual interface may say “Verify” or “Confirm Eligibility,” obscuring the fact that the actual operation is granting permission for unlimited token spending.

The severity of unlimited allowances deserves emphasis. Setting an allowance to 2^256-1 (the maximum integer value) means the contract can move every token of that type from the wallet forever, even after the initial transaction. The user does not need to approve again. A subsequent transaction can drain the entire balance at any time. This is why seemingly innocent verifications have drained millions of dollars: the victim has granted permanent, unlimited access to their assets through a single click.

Legitimate protocols also request approvals, so the presence of an allowance request is not inherently suspicious. The difference is intention and transparency. A real exchange discloses why it needs the allowance and typically limits it to the amount being transacted or a reasonable cap. A scam request obscures the target contract, uses social engineering to make the approval feel necessary, and grants unlimited permissions. The problem is that users often cannot tell the difference in real time because the wallet interface does not always explain what the approval means.

Hidden drain mechanisms and disguised function calls

Beyond simple approvals, attackers have developed more sophisticated techniques. Some fake airdrop contracts include hidden functions that activate after a certain block number, after the user has sent other transactions, or only when called by a specific administrative address. The user signs a transaction that appears to do one thing—claiming tokens—but the contract includes code that will execute something completely different later. This is sometimes called a time-bomb or delayed drain.

Another common pattern is the bait-and-switch approval. The contract request appears to ask for permission to move Token A but actually sets up permission for Token B, which the victim may have more of. Because most users do not decode the transaction data before signing, they approve Token B without realizing it. The attacker then drains that token on a separate transaction or sells the victim’s balance immediately. Some versions of this exploit use compressed contract code or off-chain function calls (delegatecall) that make the actual operation nearly impossible to detect without specialized tools.

Flash loan attacks have also been wrapped into fake airdrop flows. The airdrop contract borrows a large amount of a valuable token using a flash loan, drains the victim’s connected wallet simultaneously, and repays the loan in the same transaction. From the victim’s perspective, one approval led to asset loss in a contract they thought was merely verifying eligibility. The transaction is permanent on-chain, but the attacker’s identity and location remain difficult to trace through the contract calls and routing.

Multi-step attacks are equally effective. The first transaction appears harmless—setting an approval or transferring a small amount of a worthless token. The victim approves because it seems like a standard interaction. A second transaction, submitted by the attacker minutes or hours later, uses that initial approval to drain a major asset. By spacing transactions apart, attackers reduce the chance that the victim will notice and cancel approvals immediately. The victim may not discover the loss until they attempt to use their funds for something else.

How transaction simulation reveals what you are actually approving

Rabby’s core security innovation is transaction simulation, a feature that displays what will actually happen to the user’s assets before any signing occurs. When a user attempts to approve an airdrop claim or any other contract interaction, Rabby executes the transaction in a sandboxed simulation environment. It calculates the expected balance changes, shows which tokens will be sent or received, displays newly created allowances, and flags any operations that appear unusual. This simulation happens locally, without sending anything to the blockchain.

The simulation result appears as a preview showing incoming and outgoing assets, NFTs, and permissions. If the airdrop claim is legitimate, the preview shows the expected number of tokens arriving in the wallet. If it is a scam, the preview shows assets leaving the wallet or allowances being granted to unfamiliar contract addresses. A user reviewing this information before signing can see immediately that the “airdrop claim” will actually drain their USDC balance or approve unlimited access to their Ethereum holdings.

This is fundamentally different from reading contract code or checking an address on a block explorer. Those approaches require technical knowledge and verification steps that most users do not perform. Transaction simulation shows results in the user’s wallet interface, in familiar language: “You will send 500 USDC” or “You will receive 0 tokens and grant unlimited permission to 0x1234…” The clarity removes the cognitive gap between intention and execution. A scammer’s entire approach relies on that gap. Once it is closed, the attack loses its power.

The simulation is also pre-sign security checking, meaning it operates before the user ever signs the transaction. There is no cost, no on-chain record, and no commitment. The user can review the preview, decide that something is wrong, and reject the transaction entirely. This is fundamentally more effective than post-transaction recovery, which is impossible on Ethereum. Once a transaction is signed and broadcast, it cannot be undone. A prevention-focused approach is the only real defense.

Risk alerts and the detection of common airdrop patterns

Beyond simulation, Rabby provides automated risk alerts that flag specific red flags common to airdrop scams. These include: approving an unfamiliar contract address for unlimited token spending, receiving tokens from newly created contracts, interacting with contracts that have been flagged by security databases, and transactions that show zero expected return (sending assets but receiving nothing in exchange).

When the user attempts to approve a fake airdrop, Rabby may alert: “Unusual approval to an unknown contract address. This contract has not been verified and could drain your tokens.” That alert is generated by comparing the target address against known legitimate contracts, checking whether the contract code matches established patterns from DEXs or protocols, and noting whether multiple users have flagged the address as malicious. A single user’s complaint does not trigger an alert, but if dozens of users have rejected similar transactions from the same address, Rabby’s database reflects that pattern.

The risk alerts also account for the context of the interaction. Approving a known DEX contract to spend your tokens is normal. Approving an unknown contract to spend unlimited amounts is suspicious. Receiving a newly created token in exchange for your stablecoins is a red flag because the token has no history, no price data, and no way to verify it is legitimate. Rabby presents this information as actionable warnings: “Low-confidence token received. Verify contract before trading.” A user who sees this warning and chooses to proceed is making an informed decision, not an accidental one.

The limitations of automated alerts are important to acknowledge. A sophisticated scammer can register their malicious contract in advance and accumulate legitimate-looking transaction history, making it harder to flag immediately. High-profile protocols may be temporarily unavailable, creating legitimate unusual approvals. New legitimate tokens are, by definition, previously unknown. The alerts are not foolproof, but they are statistically effective because they target the patterns that scammers use at scale. Combined with transaction simulation, they create a layered defense: first, show what will happen; second, warn if what is happening matches known attack patterns.

The difference between watching and protecting: How Rabby’s design prevents approval scams

Rabby is designed as a self-custodial wallet, meaning the user controls their private keys directly rather than delegating custody to a service. This architecture is essential for protection against airdrop scams because the wallet never grants anyone else the ability to move the user’s funds on their behalf. A custodial exchange or online wallet provider could theoretically approve transactions without the user’s knowledge, either through negligence or malice. Rabby eliminates that risk by making all approvals user-initiated and visible.

The wallet also supports hardware wallet integration, allowing users to sign transactions on a separate, offline device. This is especially valuable for protection against malware. If a user’s computer is compromised with keylogger or session-hijacking malware, the attacker can see the transaction and try to influence the user, but the attacker cannot sign on behalf of the user. The hardware wallet displays its own preview, independent of the computer’s display. A user can verify on the hardware device’s screen that they are approving the correct transaction, regardless of what their computer is showing.

For users without hardware wallets, Rabby’s browser extension architecture provides some additional isolation compared to web-based wallets. The extension operates in a sandboxed environment with its own local storage, separate from malicious websites. A fake airdrop website cannot directly access the extension’s state or private keys. It can only trigger wallet requests, which Rabby then displays and requires the user to approve. This gives the user a moment to review before commitment, even if their browser is otherwise compromised.

Watch-only accounts are another feature that aids security. A user can import a public address without the private key, allowing them to monitor balance and transactions without exposing the key. This is useful for receiving assets to an address that is managed elsewhere or for reviewing a transaction before approving it from a hardware device. Watch-only mode also reduces the risk of exposing private keys to malware: if the user primarily manages their wallet through a hardware device and only uses the software wallet for monitoring, the software wallet contains no key material to steal.

Network selection and automatic blockchain detection: Preventing cross-chain confusion

Airdrop scammers sometimes exploit network confusion. A user receives a notification to “claim your airdrop on Ethereum,” connects their wallet, and unknowingly approves a transaction on Polygon, Arbitrum, or another chain where the same contract address exists but with different underlying value. The user might approve a Token A contract on Ethereum expecting it to apply to Ethereum only, only to discover the approval also allows spending on other networks if the wallet was not paying attention to chain IDs.

Rabby provides automatic network selection, which detects which blockchain the dApp is attempting to interact with and confirms the network before any transaction occurs. When a user navigates to a website claiming to offer an Ethereum airdrop, Rabby checks the website’s network configuration and alerts the user if there is a mismatch. If the website is actually configured to operate on Polygon, Rabby warns the user and requires explicit confirmation. This prevents the accidental case where a user approves a token contract, thinking they are on Ethereum, but the wallet is actually on a different network.

The feature is paired with clear network display in the wallet interface. The currently active network appears at the top of transaction previews, and users can switch networks only through explicit wallet actions, never through a website request alone. A malicious dApp can request the wallet to switch networks, but the request appears as a prompt to the user, not an automatic action. This is different from some older wallets that silently switched networks or made the current network difficult to see, leading users to sign transactions on unexpected chains.

Building a personal airdrop defense: Practical steps before connecting to any claim site

Even with Rabby’s safeguards, the user’s own vigilance is the primary control. Before connecting to any airdrop claim website, users should verify the source. Official airdrops are announced through official channels: the project’s verified Twitter account, their registered website, SEC filings for regulated entities, or direct email to registered token holders. Any airdrop requiring a wallet connection should already be known to the user through an announcement they initiated finding, not through spam, ads, or unsolicited messages. If you did not know about an airdrop from an official source, it is almost certainly not real.

Checking the actual website domain is critical. Scammers register domains that look similar to legitimate ones: “airdop.com” instead of “airdrop.io” or “uniswap-claime.com” instead of “uniswap.org.” Browser bookmarks reduce this risk: store the official link to any protocol you use regularly and always navigate through the bookmark rather than searching or clicking links in notifications. For installation and setup guidance, users can refer to this guide to ensure they are accessing the legitimate Rabby wallet from the correct source.

The preview and simulation that Rabby provides should become a habit. Every single transaction, regardless of whether the user trusts the source, should be reviewed in Rabby’s preview before signing. If the preview shows the user will receive zero tokens but approve unlimited spending, the transaction should be rejected immediately. If the preview shows any asset leaving the wallet when the user expected only a verification step, that is a scam. The preview is the security checkpoint before any commitment.

Finally, users should separate assets across multiple wallets based on risk and frequency of use. A primary wallet for frequent transactions, DeFi interactions, and active trading should hold only the amount needed for immediate activity. A separate cold wallet, accessed less frequently, should hold long-term holdings. A watch-only account can monitor all balances without exposing keys. This strategy, called compartmentalization, limits the damage if one wallet is compromised. If the active trading wallet is drained through an airdrop scam, the main holdings remain safe elsewhere. It is an additional layer of friction, but it is friction that creates real security.

What happens after an airdrop scam: Why prevention is the only recovery

The sad reality is that once an airdrop scam transaction is confirmed on-chain, recovery is nearly impossible. A user who signs a malicious approval cannot ask Ethereum to undo it. There is no “reverse transaction” button, and the blockchain has no authority to overrule a digitally signed instruction. Even if the user reports the scam to law enforcement, the money is gone. The attacker’s address may be flagged as malicious, but if they have already moved the funds to a mixer, bridge, or exchange, the trail ends.

Some scams are profitable enough to attract criminal investigation, and law enforcement has occasionally recovered funds from centralized exchanges where attackers attempted to cash out. But this is rare and typically requires the victim to have significant losses and resources to pursue the case. Most users cannot recover stolen crypto, and most attackers operate from jurisdictions where law enforcement cannot easily reach them. The economic incentive for the attacker is enormous—they profit from every victim—while the recovery incentive for any single victim is much smaller.

This is why prevention-focused tools like transaction simulation, risk alerts, and clear pre-sign information are not optional conveniences. They are the actual defense. A wallet that makes approvals transparent and flags suspicious patterns prevents losses that cannot be recovered. Rabby’s design philosophy reflects this reality: the security feature that matters most is the one that stops an attack before it happens.