The contract is clean - for now: catching crypto scams that survive launch-time checks

Most token scam detectors, including the one I work on, share one implicit assumption: the contract you analyze at launch is the contract people will trade. Read the source, simulate a buy and a sell, cluster the deployer, score it, done.

That is a snapshot. And a snapshot is exactly what a patient scammer plays against. Two token designs pass every launch-time check and then turn hostile later. This is how they work, and the two on-chain techniques we shipped this week to catch them.

Design 1: the delayed honeypot

A honeypot is a token you can buy but cannot sell. The classic version is non-sellable from block one, so a buy-then-sell simulation catches it instantly.

The patient version is sellable at launch. Early buyers sell fine, the chart looks healthy, the token earns a clean verdict from every checker that judged it at T0. Then, days later, the operator flips a switch:

a timed blacklist that rejects transfers after a block height or timestamp,
a setTrading(false) / pause() kill switch pulled once liquidity has accumulated,
a fee setter cranked to 100% on sells.

From that moment it is a honeypot. But the only verdict on record is the clean one from launch day. The detection ran once, at the worst possible time to run it.

Fix: re-simulate at J7

We keep post-launch snapshots of every token at J0, J7 and J30 (originally to catch slow rugs: volume collapse, late LP burns). The new piece re-runs the full buy/sell honeypot simulation at J7, but only for tokens that were genuinely sellable at J0. A clean-to-honeypot flip is the signal:

// Only for tokens sellable + tradable at J0 - a clean->honeypot flip is the point.
// Bounded per run because it is RPC-heavy.
const eligible = !j0.risk_flags.some((f) => J0_SKIP_RESIM_FLAGS.has(f));
if (rpc && eligible && resims < resimLimit) {
  const isNowHoneypot = await detectLateHoneypot(rpc, tokenAddress);
  if (isNowHoneypot) flags.push("late_honeypot"); // +40 risk at J7
}

One rule we hold to: an RPC hiccup never fabricates a late_honeypot. A failed re-simulation returns "not a honeypot" rather than inventing one. Better to miss a flip than cry wolf on a healthy token.

Design 2: the proxy whose implementation is the payload

A proxy is a thin contract that holds storage and forwards every call via delegatecall to a separate implementation contract that holds the logic. Completely legitimate, extremely common (every upgradeable token uses it). That is exactly why it is good cover.

The trick: you analyze the proxy address. Its bytecode is tiny - "delegatecall to whatever address is in this storage slot." Nothing to flag. The source, if verified, is boilerplate. Clean. Meanwhile the blacklist, the mint, the drain live in the implementation the proxy points to, which nobody looked at - and which an admin can swap in one transaction. The proxy address never changes, so explorers keep showing the same "contract."

So we taught the analyzer to follow the delegatecall.

Resolving the implementation on-chain

You do not need verified source to find the implementation. The proxy standards store the address in well-known storage slots. We read them in order:

// EIP-1967: slot = keccak256("eip1967.proxy.implementation") - 1
let implementation = await readSlotAddress(rpc, address, EIP1967_IMPL_SLOT);

// Beacon proxy: the beacon contract holds the address.
if (!implementation) {
  const beacon = await readSlotAddress(rpc, address, EIP1967_BEACON_SLOT);
  if (beacon) implementation = await callImplementation(rpc, beacon);
}
// then the OpenZeppelin legacy slot, then EIP-1822 / UUPS PROXIABLE.

Then we run the same bytecode analysis we run on any deployed contract against the implementation: function selectors, dangerous opcodes, and a known-scam-factory hash match. If the implementation is byte-identical to a known mass-scam template, the token gets proxy_implementation_known_scam - a clean-looking proxy delegating to a confirmed scam.

Two more signals fall out for free:

proxy_implementation_missing - the proxy points at an address with no code. A loaded trap: deploy malicious logic there (or repoint the proxy) once liquidity has piled up.
mutable_proxy_admin - the EIP-1967 admin slot holds a live address that can swap the implementation at will. A rug switch in plain sight.

One nuance worth stating, because it is a common false-positive trap: an empty admin slot does not mean immutable. UUPS proxies keep the upgrade authority inside the implementation, not the admin slot. So we only raise mutable_proxy_admin on a populated slot, and never claim immutability from an empty one.

The common thread: stop trusting the snapshot

Both detections come from the same shift. A launch-time verdict answers "is this a scam right now?" The questions that actually protect a buyer are "will it still be safe next week?" and "is the code I'm reading the code that will run?"

The delayed honeypot attacks the time axis: clean now, hostile later. Answer: re-judge at J7.
The proxy attacks the indirection axis: clean here, hostile one delegatecall away. Answer: follow the pointer.

Cost stays bounded: the honeypot re-sim only runs on J0-sellable tokens and is capped per cycle; the proxy resolution only fires when the bytecode actually contains a DELEGATECALL opcode, so the millions of non-proxy tokens pay nothing.

If you build anything that judges smart contracts: a clean verdict at launch is a statement about launch, not a promise about next week. Treat it that way.

Full write-up with more detail on the RektRadar blog.

推荐订阅源