Inside a 12,000-Contract Honeypot Operation on Avalanche

This investigation started with a database cleanup.

While reviewing a few thousand suspicious tokens in Prelisted's monitoring database, I noticed a cluster of Avalanche contracts that all reported the same absurdly specific totalSupply():

100,018,746,193,931,376,489,308,801,730

Not a round number. Not 1,000,000,000 × 10¹⁸. Something oddly precise, repeated across many unrelated-looking tokens. My first guess was that I'd found a mass-deployment template — some bot spraying out cheap ERC-20s.

I had. But the template wasn't the interesting part.

Following that one number led to 5,746 contracts sharing an identical contract family, thousands of blacklist calls targeting distinct on-chain addresses, a hardcoded wallet with administrative control that survives ownership renunciation, and a second wallet that repeatedly minted fresh tokens out of thin air and dumped them through a DEX.

Then the cluster got bigger. An earlier Avalanche campaign from 2025 — deployed by a different wallet, using a different supply number — turned out to carry the same hardcoded manager address in its bytecode. Together, the known Avalanche operation now covers roughly 12,000 contracts across at least 13 months.

And it isn't historical. The management wallet was still issuing blacklist calls on August 12, 2026. The drain wallet executed its most recent swap on August 14, 2026 — the day I finalized these notes.

Then, while mapping the funding, I found the same operation running on Polygon.

This is the story of how a strange database artifact turned into a live, multi-chain on-chain fraud investigation — and how the Avalanche side actually works. Here's the whole machine on one page; the rest of the article is how each piece was found and verified.

---

The number led to thousands of contracts

The supply constant was the thread. I reverse-searched it across Avalanche and pulled every contract whose totalSupply() matched byte-for-byte.

5,746 contracts. All deployed inside a two-week window in April–May 2026, by a tight cluster of three wallets. All Avalanche-native — those deployers have zero transactions on BNB Chain, Ethereum, Polygon, Arbitrum, Base, or Optimism. And all sharing the same compiled runtime bytecode: solc 0.8.19, ~8,428 bytes (16,856 hex characters), differing only in the constructor arguments that set each token's name and symbol.

This wasn't a handful of scams that happened to look alike. It was one production line.

The tickers gave away the intent. Extracting symbol() from all 5,746 contracts returned 5,137 unique tickers, and they cluster into recognizable bait categories: stablecoin decoys (DAI, DUSD, VUSD, USDM, TUSD, FDUSD), memecoin culture (PEPE, WOJAK, ANDY, MOG, GOAT), brand impersonation (GME, TON, BTCST, BRLA), and layer-1/L2 names (DOT, ADA, MATIC, ARB, OP, SUI, SEI). The set is engineered to catch someone searching a DEX aggregator for a real project by ticker — type "PEPE," route into one of the pipeline's PEPE contracts, and buy.

(For the record: 16.3% of the tickers match a project that has held a tier-1 CEX listing at some point, against a 12.1% baseline for random tokens on the same date. A modest over-selection — the operator was chasing hot narratives, not systematically front-running future listings.)

So I had a warehouse of look-alike tokens. The obvious question was: what's actually inside them?

---

Then I opened the bytecode

None of these contracts had verified source on Snowscan, so I fetched the runtime bytecode directly and ran it through a decompiler. Underneath a standard-looking ERC-20, every contract exposes three functions that are not part of the ERC-20 standard:

All three are gated the same way — they run only if the caller is the nominal owner or a specific address hardcoded directly into the contract's bytecode:

// gate: caller must be the hardcoded manager (Address A) or the current owner
require(msg.sender == 0xce54c175880ff4edaa5d80b2dc66dda0e34a36ac
     || msg.sender == _owner);

That hardcoded address — 0xce54c175…, which I'll call Address A — is the entire game. It's baked into the compiled code of every contract, so it can't be removed, transferred, or renounced. Whoever holds Address A's key holds permanent admin rights over all of these tokens, no matter what the visible owner() says.

Here's the single most important function, proof(uint256), straight from the decompile:

require(msg.sender == 0xce54c175880ff4edaa5d80b2dc66dda0e34a36ac
     || msg.sender == _owner);
_totalSupply += amount;
_balanceOf[msg.sender] += amount;
emit Transfer(address(0), msg.sender, amount);

Nothing about the name proof hints at what it is: an uncapped mint. The caller can create any quantity of the token, to their own balance, at any time. And it emits a Transfer event from the zero address — so on a block explorer, the mint is indistinguishable from an ordinary initial token issuance.

That's the hidden controller. Now the trap.

---

How the honeypot actually works

Execute(address) adds an address to an internal blacklist mapping. Approved(address) removes it. Both are gated to Address A or the owner. On their own, a blacklist is not unusual — plenty of legitimate tokens have one.

What makes it a honeypot is what the blacklist does inside the transfer logic. In the internal _transfer function, there's a single check:

require(!mapping_1[sender], 'Recipient is Gwei');

Read that carefully. The check tests the sender's blacklist status — but the error message blames the recipient. The result is misleading by construction: a blacklisted holder who tries to sell gets an error that gives no indication their own address has been blocked. It looks like a problem with the exchange, the destination, or the wallet — anything but the truth. They keep tokens they can never move.

Put the pieces together and the attack is clean:

1. Deploy a honeypot token — Address A is hardcoded in from birth.
2. Add liquidity on a DEX so the token is buyable.
3. Let real users buy. Nothing blocks a purchase.
4. Blacklist the buyers with Execute(target) — now they can't sell.
5. Mint fresh supply to the operator via proof(huge_amount).
6. Dump that fresh supply into the pool, drain the AVAX, move on.

Renouncing ownership means nothing here

These contracts implement the standard renounceOwnership() function. Anyone — including an automated trust-scoring tool — can check "is ownership renounced?" and get a reassuring "yes." That answer is a decoy, because every privileged function also accepts Address A:

require(msg.sender == 0xce54c175880ff4edaa5d80b2dc66dda0e34a36ac
     || msg.sender == _owner);

Finding malicious code is one thing. Finding someone actively using it is another.

---

Then I found the drain wallet

The contracts told me the machine could rug anyone. The next wallet showed it being used.

Tracing who actually called proof() and the swap functions led to a second wallet — 0x6b89422…, Address B. Between May 5 and August 14, 2026, it executed 30,758 transactions. Grouped by method, an extremely repetitive pattern falls out:

The core loop, run against contract after contract, is always the same three steps:

1. approve the LFJ router to spend Address B's balance of pipeline token X.
2. proof(…) — mint a fresh block of token X to Address B.
3. swapExactTokensForNATIVE(X → AVAX) — sell the fresh mint, send the AVAX to a collector.

Then repeat. Thousands of times.

Address B isn't only the drainer, either. The verification pass turned up something I'd initially missed: Address B is also one of the hardcoded manager keys. Sampling 100 of the April–May contracts, Address A is baked into 65 of them and Address B into the other 35 — each appearing ten times over as a PUSH20 constant, with identical admin powers. The operator runs two manager keys and splits the inventory between them. What first looked like a coverage gap in Address A was just the second key doing its half of the work.

---

10,054 swaps — and the fingerprint explains itself

Add the two swap variants together and Address B executed 10,054 successful drain swaps. Every one sold freshly minted tokens for AVAX, and every one set amountOutMin = 0 — accept whatever the pool gives, never fail on price. That's bulk extraction, not careful trading.

Then I looked at how much each proof() call minted. It was the same number every time:

18,746,193,931,376,489,308,801,730

That number looked familiar. It should — it had been sitting inside the fingerprint that started the whole investigation.

   100,018,746,193,931,376,489,308,801,730  ← the supply constant I first noticed
−  100,000,000,000,000,000,000,000,000,000  ← a clean 100,000,000,000 × 10¹⁸
=       18,746,193,931,376,489,308,801,730  ← the exact amount minted on every drain

The "absurdly specific" supply number wasn't random at all. It's a round 100-billion base plus the operator's fixed drain quantity, engineered so the same mint amount could be reused across every contract. The anomaly I'd used to find the pipeline was the anomaly that made the pipeline work — and it only explains itself at the moment of the drain. The clue and the mechanism were the same number the whole time.

Where does the AVAX go? ABI-decoding the to parameter on the swap calldata answers it: on every successful drain, proceeds route to one address — 0xeec6d5994b7ed166e5cf7f5444d4bf0aaebce92d, the collector I've labeled C2 Root Funder.

As of August 14, 2026, the collector holds 462.79 AVAX attributable to DEX-router drains (≈ $20,000 at April 2026 prices) — 406.65 via the LFJ V2.2 router plus 56.14 via Trader Joe V1. A further 294 AVAX arrived from two other wallets whose relationship to the operation is still under investigation, which is why I don't fold it into the drain total.

The trajectory is stark. May 2026 was the industrial burst — roughly 8,500 mints, 8,400 approvals, and 8,400 swaps in a single month. June continued at about a fifth of that. July and August are down to single-digit transactions per day. The operation is winding down, but it is not off: Address B's most recent drain was August 14, 2026.

---

I thought the rest were dormant. I was wrong.

This is the point where my first theory fell apart — worth keeping in, because the correction is what opened up the real scale.

Early on, I checked the 5,746 contracts against the usual pool sources — DexScreener, Trader Joe V1, Pangolin V1 — and came up almost empty. Three contracts showed an indexed pool; the rest showed nothing. I wrote the pipeline off as a giant warehouse of dormant fake tokens, mostly never even wired up to a DEX.

That conclusion was wrong, and Address B's 10,054 swaps proved it. The tokens weren't dormant — I was looking at the wrong DEX. The operator built on LFJ Liquidity Book V2.2, whose concentrated-liquidity "bin" pools are not reliably indexed by the retail safety tools I'd checked first. Once I followed Address B's transactions into LFJ V2.2, the supposedly empty warehouse turned out to contain more than ten thousand real, successful drains.

It's also why the drains are nearly invisible to ordinary users. A one-sided LFJ bin pool — all token, no AVAX, which is the state each pool is left in after a drain — still exists on-chain but effectively can't be traded through. To DexScreener it looks like nothing is there. To the operator it's a completed job.

---

Anatomy of one trap

Aggregates are convincing but abstract. It helps to look at the handful of contracts you can still watch the operator touching by hand.

Of the 5,746 contracts, exactly three carry a currently-indexed DEX pool: BRLA (impersonating a Brazilian Real stablecoin), USTC (Terra Classic USD), and BTCST (Bitcoin Standard Hashrate Token). Each has a small Trader Joe pool — around $625 of liquidity, no meaningful volume — created the same day the token was deployed. Real brand names, tiny live pools, sitting in wait.

These three are the ones Address A still visits. As recently as August 10–12, 2026, Address A issued Execute(address) blacklist calls against all three — BRLA on Aug 12 at 09:22 UTC, USTC on Aug 12 at 02:02 UTC, BTCST on Aug 11 at 04:52 UTC. Each of those calls adds a specific address to the "cannot sell" list of a live, buyable token.

What's verifiable on-chain is every step except the victim's intent: the contract was deployed, the pool was created, Address A blacklisted specific addresses, Address B minted via proof() and sold the mint to the collector — all with timestamps and transaction hashes. The one link I don't assert is that each blacklisted address was definitely an innocent buyer about to sell; confirming that requires per-address purchase histories, which is a separate exercise. But the machinery around them is fully documented, and it's still running on these three contracts as of this month.

---

This wasn't the first campaign

The April–May 2026 deployment — call it Campaign 2 — was where the fingerprint led me. But Address A predates it.

Address A's Execute(address) history runs back to July 2025, against a completely different set of contracts: 4,887 tokens deployed by a single wallet (0x3eb8d668…) between July and October 2025. Call that Campaign 1. It uses different supply numbers — mostly a 490,255… constant and a clean 100,000,000,000 × 10¹⁸ — and a slightly different bytecode layout. On the surface, an unrelated batch of scams.

Except the bytecode says otherwise. I sampled 30 Campaign 1 contracts and found Address A hardcoded in all 30. Same master key, baked into a campaign nine months older, deployed by a different wallet, using different supply constants and a different funding path. Two campaigns that share nothing on an address graph — except the one address compiled into every contract's code. That's a single operator.

Between the two Avalanche campaigns, Address A issued 4,999 Execute(address) blacklist calls against Campaign 1 contracts alone across July–October 2025 — a systematic, industrial-scale blacklisting effort. (Whether all 4,999 targets were confirmed buyers is, again, a separate per-address question I haven't closed for the full set.)

A June 2026 follow-on batch — Campaign 2B, 1,585 more contracts — completes the Avalanche picture. It's worth being precise about what 2B is and isn't. Beginning in June, Address B switched its swaps from the plain router path to the fee-on-transfer-compatible variant, and I initially suspected the June tokens had added a burn-tax mechanism. A bytecode diff of five Campaign 2A contracts against five Campaign 2B contracts disproved that: the two are byte-identical apart from constructor arguments — same runtime size, same 28 function selectors, no new state, no fee-on-transfer or burn tax at the token level. The router-path switch was operational, not a template change. I'm noting it because my own first suspicion was the opposite.

---

The template wasn't theirs either

One more thing the bytecode revealed: the operator didn't write this honeypot. They forked it.

The contract is a fork of a publicly available honeypot kit that security researcher Dev Swanson published on June 5, 2023 as a scam-education artifact — code meant to help auditors recognize exactly this hostile-mint / blacklist-trap pattern. The kit contains the whole shape the operator uses: the proof(uint256) mint gate, the Execute/Approved blacklist pair, the _transfer trap, even the specific sloppy artifacts — the misspelled _uzer parameter, the non-native "Gwei-ed" and "tronglisted" error strings, the deceptive "Recipient is Gwei" message, and a bool _decimals that should be a uint8.

That matters for two reasons.

First, attribution can't rest on code style. At first I read the broken English in the error strings as a fingerprint of the author's background. It isn't — every one of those artifacts is inherited verbatim from Swanson's public template. The operator's contribution isn't the language or the vulnerability pattern; it's the industrial application of it: fork the kit, swap in your own manager address, and deploy 12,000 instances over 13 months. All attribution in this report rests on on-chain evidence — funding trails, wallet clustering, the shared collector — never on how the code reads.

Second, the defensive lesson generalizes. Publishing a scam pattern so defenders can spot it is standard and useful, but it's also a gift to scaled abuse. Detection has to fingerprint the bytecode template itself and flag all its forks — not just the one hardcoded address any given operator happens to use. (To be clear: Dev Swanson bears no responsibility for this misuse. The kit is credited here only to trace the artifact chain and to explain why the code's surface features can't identify the operator.)

---

The Binance attribution point

The on-chain trail can name the operator's wallets. Naming the person would require one more link, and that link runs through Binance.

Both of the wallets that bootstrap Campaign 1 were funded, within a two-minute window, by Binance customer-withdrawal payouts:

2025-07-22 13:47 UTC   Binance 85  → Address A     (0xce54c175…)    1.996 AVAX   tx 0x88741657…
2025-07-22 13:49 UTC   Binance 110 → C1 deployer   (0x3eb8d668…)   97.996 AVAX   tx 0x5100523d…

Binance 85 and Binance 110 are Binance's own payout-batching wallets (labeled as such on Snowscan and in our database). Withdrawals like these are fulfilled from that shared internal infrastructure. So what the blockchain proves is narrow but real: two operational wallets — the deployer that built 4,887 contracts, and the master key hardcoded into all of them — were funded by Binance customer withdrawals two minutes apart. One is a ~$2,700 operational float, enough to cover deploy gas for the whole campaign; the other is a ~$53 top-up for the management key.

What the blockchain cannot prove is whether both withdrawals came from the same Binance account. That determination lives inside Binance's records, not on-chain. I want to be careful here: I'm not asserting a single customer, and I'm not claiming any upstream Binance hot-wallet link — I couldn't verify one.

The Campaign 2 deployers were funded more carefully, through a cluster of intermediary wallets fed by small DEX swaps that obscure the CEX origin. Campaign 1's cleaner Binance trace is the anchor — and Address A's presence in both campaigns is what carries the identity across.

---

12,000 contracts, 13 months, still active

Totaling the Avalanche side:

This is not dormant infrastructure being catalogued after the fact. Address A's most recent transaction was August 12, 2026; Address B's most recent drain was August 14, 2026. Blacklist calls are still going out against the live BRLA/USTC/BTCST pools. Whoever the operator is, they're still working the inventory as this is published — and there are almost certainly earlier or interstitial campaigns I haven't identified yet.

---

Then Avalanche led to Polygon

While mapping the funding, I found the same contract architecture running in parallel on Polygon — managed by 0xbfd4a51c…, active since July 8, 2025, which is 14 days before Avalanche's Campaign 1 began. Polygon wasn't a copy of the Avalanche operation. It was the pilot.

At first I was cautious about the link. The honeypot template is public, so an identical contract shape on a second chain proves nothing by itself — anyone can fork the Swanson kit. Code-based attribution would have been weak.

So I decoded the calldata of the Polygon manager's fee-on-transfer drain swaps to see where the drained POL actually went. 37 of its 42 decoded swaps (88%) route proceeds to 0xeec6d5994b7ed166e5cf7f5444d4bf0aaebce92d — the exact same C2 Root Funder that receives Avalanche's drained AVAX. (At first this looked like "0 POL to the collector": the value moves through an operator-controlled router intermediary, so it doesn't appear on the manager wallet's own internal-transaction ledger — until you decode the to parameter inside the router call.)

That's not template similarity. That's the same collector wallet receiving proceeds from two chains — the money trail carrying the attribution that shared code couldn't.

A preview of what Post 2 covers:

• 624 Polygon pipeline contracts over 13 months, managed by a single key, using Campaign 1's clean 100B × 10¹⁸ supply template.
• 1,154 blacklist calls, with a leaner "deploy widely, drain selectively" model — the manager has only directly drained ~40 contracts so far, leaving the rest as blacklist-managed inventory.
• The fee-on-transfer drain path that Avalanche only adopted in June 2026 was standard on Polygon from day one — Polygon trained the operator on the mechanic a year before Avalanche used it.

---

Why this matters

The 12,000-contract, 13-month, two-chain shape of this operation makes a few security-tooling points concrete:

1. renounceOwnership() is not a trust signal. Any tool scoring a contract on "is the owner renounced?" is defeated by a hardcoded backdoor. These contracts score better when renounced.
2. Function-name deception works. proof(uint256) looks like a check; it's an uncapped mint. Execute(address) sounds like a trigger; it's a blacklist. Scanners that match on function names or signatures — rather than inspecting what the implementation actually does — will pass these.
3. Bytecode fingerprinting catches what address-graphs miss. Two campaigns with different deployers, different supply constants, and different funding graphs are invisibly linked by one address compiled into every contract. Cluster by manager-constant and bytecode similarity, not by per-contract ownership status.
4. CEX-KYC traces still work even when later campaigns launder their provenance through DEX hops. Campaign 1's clean Binance withdrawal is the anchor that the rest hangs from.

The broader point: a user checking any single one of these 12,000 tokens through a mainstream safety tool would see renounced ownership, standard ERC-20 methods, and no unusual owner permissions. A user relying on those signals alone may have no indication that the entire class of tokens shares one hardcoded backdoor to a master wallet. Only cluster-level provenance — funding graphs plus bytecode signatures plus behavior — makes the structure visible.

---

What defenders can do right now

The operation is live: blacklist calls on Avalanche as of Aug 12, drains as of Aug 14, 2026. An action list by role:

Wallet & safety-scanner vendors

(Rabby, MetaMask, Blockaid, De.Fi, GoPlus, Wallet Guard.) Fingerprint the backdoor template's runtime bytecode — the proof(uint256) + Execute(address) + Approved(address) selector triad on a ~8,428-byte runtime should flag red regardless of what owner() returns. Flag the known manager constants 0xce54c175880ff4edaa5d80b2dc66dda0e34a36ac (Avalanche) and 0xbfd4a51c9f4c5b8109bdd462c8a57a5d268be3d0 (Polygon) as PUSH20 constants in bytecode. Detect on semantics — a mapping write gated by require(msg.sender == <hardcoded> || msg.sender == _owner) is a blacklist no matter its name.

LFJ & Avalanche ecosystem security

Identify remaining live Liquidity Book V2.2 pairs for any pipeline contract in the IOC list; consider LP-side friction or UI warnings on template matches. Any new deployment carrying the backdoor bytecode should be treated as likely continuation of this operation — or a copycat of the same public template — and flagged either way.

Binance compliance

The two withdrawals on 2025-07-22 (13:47 UTC, 1.996 AVAX → 0xce54c175… via Binance 85; 13:49 UTC, 97.996 AVAX → 0x3eb8d668… via Binance 110) merit review, and the corresponding account/withdrawal records are worth preserving. Those two addresses are directly tied to 12,000+ ongoing honeypot contracts across two chains.

Threat-intel & scanner companies

(Chainalysis, TRM, Elliptic, exchange trust & safety.) Ingest the IOC list, backfill historical risk scores on any pipeline contract that scored "safe," and search other chains for the template signature with substituted manager addresses. Two chains are confirmed; Ethereum, BNB Chain, Arbitrum, Base, and Optimism are all worth checking.

End users

Treat a low-visibility Avalanche or Polygon token that only trades on LFJ V2.2 (Avalanche) or a Uniswap V2 clone (Polygon) as unverifiable unless you can independently confirm its provenance — those are the venues used by this operation. And for these tokens, renounced ownership is not reassurance; the hardcoded backdoor bypasses ownership entirely.

---

Confidence, methodology & limitations

A short note on what's proven versus inferred, kept out of the story above on purpose.

Terminology. "Campaign 1 / 2A / 2B" are my labels for the three observed Avalanche deployment waves; "C2 Root Funder" is my label for the shared collector wallet. All are defined by on-chain behavior, not by any operator self-description.

---

Data & repro

An IOC package accompanies this piece:

• All 5,746 Campaign 2 contract addresses, plus the 4,887 Campaign 1 targets of Address A's Execute calls
• Full deployer and funder graphs; Address A + Address B activity histories
• The decompiled ABI for the Campaign 2 template
• A ~30-line detection heuristic that flags pipeline contracts from the hardcoded-manager signature in runtime bytecode

Format: CSV + JSON with a versioned SHA256 checksum, hosted publicly. Every claim above is meant to be independently checkable or falsifiable against it.

---

One number was the whole system

What began as a single malformed-looking supply value turned out to be an operational fingerprint. That one number connected thousands of contracts, two generations of Avalanche infrastructure, a live drain wallet, a shared cross-chain collector, and an earlier Polygon campaign that piloted the playbook. Each contract was built to look ordinary one at a time — renounced owner, standard ERC-20 methods, nothing amiss. The operation only became obvious once the contracts were treated as a system: clustered by the address compiled into every one of them, not judged token by token.

That initial cluster surfaced through Prelisted, the listing-intelligence system I built to detect anomalous pre-listing and exchange-related on-chain activity — and the same contract-safety layer that screens its alerts is what turned one malformed number into the map above.

---

Series context

• Post 1 (this piece) — the Avalanche 100B honeypot pipeline
• Post 2 — Polygon: the same operator's parallel, earlier operation, linked by the shared collector
• Post 3 — the April 2026 meme-launchpad wave, and how this operator's deploy burst was briefly mistaken for legitimate launchpad activity
• Post 4 — open-sourcing the safety layer: cluster provenance, bytecode-backdoor detection, and behavioral confirmation

---

Sources & methodology notes

• Contract metadata: Etherscan V2 API (getcontractcreation, getsourcecode, deep-paginated txlist)
• Funding graph: Etherscan V2 txlist per wallet, following first inbound value-carrying transactions
• On-chain state: eth_call for totalSupply()/symbol()/name()/owner() via Alchemy Avalanche RPC
• Bytecode: eth_getCode via Alchemy, keccak256 grouping + CBOR metadata extraction
• Decompilation: library.dedaub.com at solc 0.8.19
• DEX pools: DexScreener, Trader Joe V1 + Pangolin V1 getPair, LFJ Liquidity Book V2.2/V2.1 factory
• CEX wallet labels: Snowscan public tags for Binance 85 and Binance 110
• Address B drain analysis: Etherscan V2 txlist filtered by method ID, success via isError, calldata ABI-decode of the to recipient
• Cross-chain link: ABI-decode of the Polygon manager's fee-on-transfer swap to parameter