The history of honeypots: a complete breakdown of contract vulnerability vectors
Honeypots did not appear fully formed. They evolved — from crude balance traps to proxy contracts that rewrite themselves after you buy. This is the field guide to every major vector, and how to read a contract before it reads you.
Why the trap works
A honeypot is a smart contract engineered to look like an opportunity and function as a cage. You can buy. You can watch the chart. You simply cannot sell — or you can, and 90% of the proceeds vanish into a fee you were never shown. The trap works because a token's page is marketing, and marketing is not enforced by code. The code is.
Reading the code is the only defence, and the vectors below are, in rough order, how contract-level fraud evolved. Each is still in circulation, because each still catches people who trusted the interface instead of the bytecode.
1. The transfer revert — the original honeypot
The earliest and crudest trap: the contract's transfer or sell path contains a condition that reverts for everyone except the deployer. Buys succeed and pump the chart; every sell attempt fails. Your balance is real, your ability to realise it is zero.
How to read it: a static read of the source can miss it, because the revert is often hidden behind an innocuous-looking modifier. Simulating a sell is decisive — the dry run reverts, and you have your answer for free. Bugglo models the sell path before you ever sign.
3. Blacklists and transfer gating
A blacklist function lets the owner mark specific addresses as unable to transfer. Sold to some holders as an anti-bot measure, it doubles as a selective honeypot: let the crowd in, then blacklist the addresses that try to take profit. Its cousins are pause(), which freezes all transfers, and whitelist-gated trading that only the owner controls.
How to read it: the presence of a blacklist, pause, or trading-toggle function is a standing risk regardless of whether it has been used yet. The question is never "has the owner abused this?" — it is "can they, at any time, without your consent?"
4. Upgradeable proxies — the contract that rewrites itself
The most dangerous vector is also the most respectable-looking, because upgradeability is a legitimate engineering pattern. A proxy contract holds the state while delegating its logic to an implementation address the owner can swap. The token you audited on Monday can become entirely different code on Tuesday, with the same address and the same chart.
How to read it: a clean audit of a proxy is only an audit of this instant. Detecting the upgradeable-proxy pattern is essential, and an unrenounced admin key on that proxy means every other check has an expiry date. Bugglo flags proxy status explicitly, because "safe now" and "safe" are not the same sentence.
5. Mint functions and unbounded supply
If the owner can mint new tokens, the supply you divided the market cap by is fiction. A hidden or owner-only mint() lets the deployer print an arbitrary amount and sell it into the liquidity you provided — a dilution rug that needs no revert and no blacklist, just arithmetic.
How to read it: look for mint capability that is not renounced or hard-capped. "Renounced ownership" is only meaningful if the powers being renounced actually included minting — a deployer can renounce a decorative owner role while keeping a minter role on a separate access-control list.
6. Liquidity traps
Even with honest token code, the exit depends on the pool. If liquidity is unlocked, the deployer can pull it and leave holders with tokens that trade against nothing. Thin liquidity means a size that looks tradeable on the chart moves the price to zero on the way out. And liquidity concentrated in the deployer's own wallet is a rug with a countdown, not a market.
How to read it: check whether liquidity is locked and for how long, how deep it is relative to the position you intend to take, and how it is distributed. Deep, locked, broadly-held liquidity is the floor under everything else.
Reading the contract before it reads you
No single check is sufficient, because these vectors combine. A contract can pass a rug check on ownership and liquidity while carrying a mutable tax behind an upgradeable proxy — three green lights and one fatal one. This is why Bugglo runs the full battery and, crucially, reports what it could not verify as unknown rather than as a pass.
You can run the same battery yourself in one command, with no account and no key:
npx bugglo 0x2103faA9D1762e27a716C61718b3aCf3Ec1F9bf1
It reports contract existence, ownership, upgradeable-proxy status, privileged powers, and DEX liquidity — the exact vectors above — straight from Robinhood Chain. For agents, bugglo-mcp exposes the same engine over the Model Context Protocol. The history of honeypots is a history of trusting the interface. The defence has always been the same: read the code, and treat every unread check as unread.