Reading Smart Contract Calldata for Honeypot Indicators
A honeypot is a smart contract that lets you buy in but blocks you from selling out. Funds go in, funds do not come back. Some honeypots block sales entirely. Others apply a 99 percent transfer fee. Others only allow whitelisted addresses to sell. You cannot always tell from the UI, but the contract's calldata patterns and selector list often give it away.
Try it now
ABI Decoder
Runs in your browser, nothing leaves your device.
Every verified ERC-20 should expose the standard selectors: transfer, transferFrom, approve, balanceOf, totalSupply, name, symbol, decimals. A contract missing transferFrom or approve cannot be sold on most DEXes by design. A contract with extra suspicious selectors like setMaxTxAmount, setBlacklist, or setBuyTax is signaling that an admin can change behavior at will.
Selectors like 0x8da5cb5b (owner()), 0xf2fde38b (transferOwnership), and any setter prefixed set... point to admin control. If the owner has not been renounced, the deployer can change tax rates, blacklist addresses, or pause transfers at any time. A 5 percent transfer fee at launch is not the risk. The risk is the owner raising it to 99 percent the moment the pool fills with buyers.
Before buying, simulate a sell. Tools like Tenderly and tx simulators on block explorers run a transaction against current state without broadcasting. If the simulated sell reverts or returns a tiny fraction of the input, the contract is at minimum extracting heavy fees and at worst a flat-out honeypot. Honeypots that branch on tx.origin or msg.sender can fool simulators, so this is a necessary check, not a sufficient one.
Examples
Suspicious admin-only setter
Contract exposes selector 0xa457c2d7 (setMaxSellAmount(uint256))
An owner can shrink the maximum sell to 1 wei at any time, making sells effectively impossible. Confirm whether ownership has been renounced before trusting any token with such selectors.
Missing standard selector
ERC-20 token contract has no transferFrom selector in its dispatch table
DEXes use transferFrom to pull tokens during a sell. Without it, no router can sell the token. Almost certainly a honeypot or a broken contract.
Security context
Calldata analysis catches the obvious honeypots, the ones with naive admin setters and missing standard methods. The sophisticated ones use Solidity's storage layout and conditional branching to hide their behavior until a wallet has bought in. For any contract holding meaningful value, simulated transactions plus source code review beat selector inspection alone. Selector inspection is the first filter, not the last.
Frequently asked
Verification proves the source matches the deployed bytecode. It does not prove the source is benign. Verified honeypots exist. Read the source for owner-only setters, transfer hooks, and conditional reverts. Renounced ownership is a stronger signal than verification alone.
Some honeypots branch on tx.origin, block.number, or per-address sale counters. A first sell in simulation succeeds because the counter is zero, but the real broadcast hits a check that has since flipped. This class of honeypot is specifically built to defeat simulators.
Related techniques
Decoding EVM Transaction Calldata
Read Ethereum transaction calldata to identify which function is being called, what parameters were passed, and whether the transaction does what the UI claims.
Detecting Token Approval Phishing in Calldata
Spot malicious approve(), permit(), and setApprovalForAll() calls before signing. Learn the calldata patterns wallet drainers use to empty wallets in a single signature.
Reverse Lookup of EVM Function Selectors
Identify unknown 4-byte function selectors by computing keccak256 of candidate signatures. Useful when reading calldata against unverified contracts.
Decoding Raw RLP-Encoded Ethereum Transactions
Parse signed and unsigned Ethereum transactions in RLP form. Inspect nonce, gas, value, chain ID, and signature fields across Legacy, EIP-2930, and EIP-1559 transaction types.