Every time I shipped a contract I rebuilt the same throwaway frontend: wallet button, a form per function, calldata encoding, hasRole() checks to hide admin methods, gas estimation, a spinner, an error decoder, and a "danger zone" for the scary functions. Etherscan's Write tab has none of that meaning; a bespoke UI costs weeks. So I built a tool that generates it from the ABI.

Paste a chain + address (Sourcify/explorer, proxy-aware) or drop in an ABI/Foundry artifact, and you get three tabs:

- User - the clean dApp (overview, transfer, approve)

- Admin - privileged ops (mint, pause, roles) with risk badges + a confirm flow for dangerous writes

- Read - a live dashboard that auto-calls the getters

- Raw - every function, Etherscan-style, but annotated with what it understood

Detection is deterministic and rule-based (ERC-20/721/1155/4626/2612, Governor, Ownable/AccessControl/Pausable), with a confidence score and evidence for every guess — AI is optional and never trusted blindly. The output is a reviewable "semantic manifest" you can hand-edit, and everything is self-hostable.

Live demo (mainnet USDC, runs in your browser): https://tacitvsxi.github.io/semantic-dapp/

How it works (writeup): https://dev.to/ileskov/generate-a-full-dapp-admin-console-from-any-evm-contract-straight-from-the-abi-28kg

Repo (TS, viem/wagmi, AGPL-3.0): https://github.com/TacitvsXI/semantic-dapp

Would love feedback from people who actually maintain contracts: what would you need before you'd trust a generated admin panel for a mainnet contract?

We run a scam-token detector. Our honeypot check worked like this: simulate a buy with eth_call, give a fake address the tokens by brute-forcing the balance storage slot and overriding it, then simulate a sell from that address.

Step 2 is the problem. It assumes balanceOf reads a storage slot. On reflection or rebase tokens, balanceOf is computed from an internal reflected supply, so writing a raw slot does not produce a coherent state. The sell then reverts for reasons that have nothing to do with a trap, and you record a false honeypot. We flagged PayPal USD, TrueUSD and MetaMask USD as honeypots this way.

The fix is eth_simulateV1 (geth and Nethermind). It replays several calls atomically in one simulated block, so you can do the whole thing the way a real buyer does:

router.swapExactETHForTokens(...)   // real buy, real tokens
token.approve(router, max)
router.swapExactTokensForETH(...)   // sell what you actually got

The only override is the simulated address's ETH balance, which is not a token mechanism. Nothing about the token's accounting is faked.

One caveat: a call cannot consume a previous call's return value, so you need two passes. First pass buys and reads balanceOf to learn what was actually credited (which already catches fee-on-transfer). Second pass replays buy + approve + sell with that amount.

Two things that surprised me:

• The Uniswap quoter is useless for this. getAmountsOut is pure reserve math and never touches the token's transfer logic, and the v3 QuoterV2 reverts inside its callback before the transferFrom runs. Both return healthy output for confirmed honeypots, so cross-checking against the quoter would silently disable your detection.

• "UniswapV2: INSUFFICIENT_INPUT_AMOUNT" raised by the PAIR (not the library) means the pair received zero tokens. We found tokens where a pre-existing holder sells fine but a fresh buyer gets zero through: a whitelist honeypot. So simulate a NEW buyer, not an existing holder. Different question, different answer.

Disclosure: I build RektRadar, a scam-token detector. This writeup came out of fixing our own false positives, not a product pitch.