Domain Hacks and Address-Poisoning: Stopping Wallet Drains on ETH and SOL
Summary
Why the shift matters: from phishing links to infrastructure attacks
Crypto attackers have always exploited human error, but recent incidents show a pivot toward infrastructure and interface weaknesses that convert routine interactions into wallet drains. Two publicized trends illustrate this clearly: a domain compromise that funneled BONK and SOL users into an approval-driven drain, and a spate of so-called address-poisoning attacks on Ethereum that led to significant on-chain losses and public criticism of explorers.
For many traders, Bitcoin remains the primary market bellwether, but ecosystems built on EVM chains and Solana now face a growing class of attacks that target the tooling layer — the very explorers, websites, and wallet flows users rely on every day.
Recent incidents: what happened with BONK/SOL and the Etherscan controversy
BONK/SOL domain compromise and wallet drains
Researchers and reports show a domain-level compromise that exposed users to a wallet-draining exploit targeting communities around BONK and SOL. In that case, control of an official domain or hosting path allowed an attacker to serve malicious JavaScript or redirect traffic to a page that triggered wallet approvals and approvals-based drains. The incident highlights how a single domain hack can bypass many user-facing protections: the user thinks they are on an authoritative site, signs an approval, and later discovers funds swept from their wallet.
Read the incident write-up for details and timeline in the reporting on the compromise and resulting wallet drains: Bitcoinist coverage of the BONK/SOL domain hack.
CZ and the rise of address-poisoning attacks on Ethereum
Binance CEO Changpeng Zhao (CZ) publicly criticized Etherscan after a wave of losses attributed to address-poisoning attacks. The coverage examined how explorers and labeling systems can be abused, and why ecosystem tooling needs better defenses to prevent users from being misdirected or tricked into executing harmful transactions. The controversy pushed conversations about explorer responsibility and product-level mitigations into the open.
See the reporting on CZ's remarks and the issue of poisoning attacks: Cointribune on CZ's criticism of Etherscan.
Mechanics: how address-poisoning and domain-driven wallet drains work
Domain hacks that become wallet drains (high-level flow)
- Attacker gains control of an official domain, subdomain, or a CDN/hosting path (via compromised credentials, weak registrar controls, or DNS takeover).
- They modify the hosted JavaScript or redirect traffic to a phishing/rogue page that looks legitimate.
- The malicious page prompts the user to connect their wallet and request a token approval or initiate a transaction. Because the domain appears correct and the UX mirrors the real site, users approve without suspicion.
- The attacker uses the approval (often unlimited allowance) to move tokens out of the wallet — a classic wallet drain.
Domain-level compromises are powerful because they defeat brand trust and bypass many heuristics users rely on.
Address-poisoning on Ethereum: an explainer
Address-poisoning broadly describes attacks that corrupt the signal users see about addresses, contracts, or transactions so victims interact with malicious on-chain entities. Tactics vary, but common patterns include:
- Creating many malicious contracts or token contracts that appear in explorer search results or token lists, pushing a malicious address to the top of searches.
- Registering lookalike names or labels so an explorer or wallet UI shows a deceptive name-badge (or lacks provenance), leading users to click the wrong entry.
- Poisoning token lists or DEX pages with fraudulent pairs so swap flows default to attacker-controlled contracts.
The end result is similar to phishing: a user thinks they're approving or sending to a legitimate contract but instead grants approvals or swaps that allow drains.
What explorers, wallets, and exchanges should do (platform-level mitigations)
These recommendations are intended for security teams, exchange ops, and explorer product managers.
Strengthen domain and hosting security (for projects and exchanges)
- Enforce registrar best practices: 2FA at registrar, transfer locks, and tight contact/email hygiene.
- Use DNSSEC and monitor for anomalous DNS changes; treat zone changes as high-severity incidents.
- Require HSTS, TLS certificate transparency monitoring, and automated alerts on certificate issuance for organization domains.
- Apply Content Security Policy (CSP) and Subresource Integrity (SRI) so injected or third-party scripts are less likely to execute malicious payloads.
- Minimize on-site signing flows; prefer wallet pop-ups that clearly show the merchant origin and require deliberate user intent.
Explorer safety features to reduce poisoning risks
- Implement label provenance and an auditable verification process for address badges (who verified this? what is the on-chain evidence?).
- Show explicit risk scores for addresses and smart contracts based on heuristics (owner activity, crowd reports, verified source code, known scam patterns).
- Deploy poisoning-detection heuristics: abnormal proliferation of similar names, bulk creation of token contracts, or a sudden surge of new contracts matching a pattern.
- Introduce a "protected mode" where search results rank verified and widely interacted-with addresses higher; push unknown addresses into a review flow.
- Avoid auto-linking ambiguous off-chain names or potentially user-submitted labels without verification.
Exchange and custodial controls
- Enforce withdrawal whitelists (allowlist of destination addresses) and optional IP / MFA gating for whitelist changes.
- Mandate multi-approver workflows and time-locked withdrawals for large sums.
- Use on-chain spend limits or per-wallet spend caps to reduce exposure from a single approval.
- Offer customers an "allowance guard" feature that blocks or flags unlimited approvals and suggests revocation.
Smart-contract hygiene and verification
- Require verified source code for contracts to receive a "verified" badge; make the verification process strict (matching bytecode, reproducible builds).
- Promote the use of proxy-safe patterns and minimize trust-centralizing admin keys when possible.
- Encourage projects to use multisig, timelocks, and on-chain governance for admin actions.
- Integrate static-analysis tools (Slither, MythX) in CI pipelines and publish audit reports.
Practical checklist for advanced users and security-minded individuals
Follow this checklist to reduce your personal exposure to domain hacks and address poisoning:
- Always verify domains and bookmarks: use saved bookmarks for dashboards and admin panels; check TLS certificates and the domain exactness (subdomain vs main domain).
- Use hardware wallets for high-value accounts. Even if a malicious page asks for a signature, hardware prompts show the function signature and destination.
- Minimize approvals: never grant unlimited allowances; specify small custom amounts when possible and use revocation tools (for example, third-party revokers like revoke.cash or wallet-native allowance managers).
- Test with small transactions: before moving or approving large sums, execute a small test to confirm intended behavior.
- Check contract provenance: confirm a contract is verified on a reputable explorer, inspect the source code, and look for multisig or timelocks.
- Use separate wallets for high-privilege approvals (DeFi interaction) and long-term holdings. Keep the latter cold or hardware-secured.
- Maintain a revocation schedule: periodically review and revoke unused approvals.
- Be cautious with name-based search results: when pasting an address, copy from a trusted source; avoid clicking search results that lack provenance.
- Enable account recovery and notification mechanisms where available; some wallets allow transaction alerts or subtle UX warnings for risky approvals.
Product UX changes that matter
Small UX changes in wallets and explorers materially reduce human error and make poisoning attacks less effective:
- Present human-readable intent on approvals (decode function signatures; show token tickers and amounts).
- Require explicit confirmation for approvals that grant transferFrom/unlimited allowance, with educational copy explaining the risk.
- Use a "confidence" badge on addresses/contacts that aggregates on-chain history, third-party audits, and explorer verification.
- Allow users to pin or whitelist contracts in their wallet UI and warn when interacting with unpinned or new contracts.
Incident response playbook highlights
When a domain compromise or poisoning event is suspected, act quickly and decisively:
- Take down or isolate the compromised domain and notify users via alternate channels (social, twitter, verified signer) that do not rely on the compromised asset.
- Rotate any API keys, hosting keys, and update DNS registrar credentials; enable transfer locks.
- Push emergency UX warnings to the explorer and partnered wallets: flag affected addresses and add risk banners to related contract pages.
- Preserve forensic artifacts (server logs, DNS change history, CT logs) to enable attribution and remediation.
- Offer remediation support for victims: revoke affected sessions, provide transaction monitoring and blocking where possible, and consider compensation policies for platform-caused negligence.
Closing perspective: layered defenses beat single solutions
No single control will eliminate wallet drains. Domain security, explorer hardening, exchange policies, smart-contract best practices, and vigilant user behavior together create a resilient posture. The BONK/SOL domain compromise and the public debate around Etherscan and poisoning attacks show that attackers are adapting — defenders must tighten both the plumbing (DNS, registrar controls) and the interfaces (explorer UX, approval flows).
Security teams should instrument observability (alerts on domain changes, mass contract creation), and product teams should prioritize label provenance and approval risk UX. Advanced users must treat approvals as potentially irreversible and use hardware wallets, revocation tools, and spending partitions to limit catastrophic loss.
At a time when on-chain tooling defines trust, platforms like Bitlet.app and others can benefit from adopting layered mitigations and clear user-facing education — both to reduce risk and to preserve user confidence.
