Which contract is the REAL token behind a ticker? A meme symbol routinely has ten or more look-alike contracts across chains, and buying the wrong one is a total loss. Fail-closed from live liquidity: genuine (one contract dominates), ambiguous (top two tied — NEVER certified), impersonation (the address you passed is not the dominant one), thin (nothing credible).

Given the contract, what powers does its deployer still hold over your money? The load-bearing idea, and why flag-listing scanners are noise: a dangerous capability only counts if someone can still FIRE it. Mintable with ownership renounced is inert; the same flag with a live owner is an armed rug. Merges a curated index (owner powers, LP locks) with a live trade simulation, because the index has never heard of a token minted ten minutes ago and the simulation cannot see who is in control. Never returns clean on simulation alone.

Is this a genuine Base-native B20 asset, or an ordinary ERC-20 wearing its address prefix? B20 is Base's standard for compliant issuance (stablecoins, RWA); its tokens sit at 0xb200… and run as a precompile, so a real one carries almost no EVM bytecode. As people learn to read that prefix as "official", a vanity-address ERC-20 inherits the credibility for free. Both answers matter: an impostor lacks the issuer controls the standard implies, and a GENUINE B20 lets its issuer freeze and burn a blocked holder's balance — a power no ERC-20 has and no ERC-20-shaped scanner looks for.

Who paid for this launch, and what else did they pay for? A token names its creator; a creator minted minutes ago names the wallet that funded it; and that funder usually funded others. Three free queries surface a cluster no buyer sees from a chart. Reports STRUCTURE, never intent — a shared paymaster proves shared control or shared infrastructure, and a launchpad is indistinguishable from a rug factory on the graph alone. What it does prove is that those tokens share fate.

Follow stolen funds from the victim's transaction to where the trail dies. moved: what actually left a wallet, marking which transfers are authentic — ERC-20 Transfer logs are attacker-controlled text, so only the transaction signer is authoritative. bridge: read a cross-chain exit; aggregators write the destination into their own calldata because the far side needs it, and chain ids are checked against a table before any field is called an amount. tron: walk a TRON account, detecting relay hops — an account forwarding what it received, within seconds, is a pass-through and not a destination.

Judge an offer to recover already-stolen funds. Answerable with certainty rather than a score, because the ask is the tell: recovery happens through the thief, a court, an exchange, or an issuer — never through the victim's wallet. A recovery needing your signature or an upfront fee is not merely suspect, it is structurally impossible as described, however credible the person sounds and however accurately they recite your loss (the theft is public; anyone can read it back to you). Never returns "safe".

Judge an inbound opportunity — podcast, interview, partnership, job, AMA — by what it ASKS, not by how good it looks. Built from a lure that worked on someone who verifies counterparties professionally: a 35-question production dossier citing his real work, using his own catchphrase, quoting his posts, and asking genuinely hard questions, because a flatterer never includes criticism and including it is what makes an approach read as journalism. The mechanism is effort as a trust signal: that much detail used to cost hours of human work, so nobody spent it on one target. That arithmetic no longer holds. So this does NOT score how convincing an approach is — that would give a forgery a good grade. It grades where a link actually points (a brand to the left of the registrable domain is a free label: wechat.web09eu.com is web09eu.com) and what the sender wants from you. Never returns safe.

Which doors into this wallet are still open? An ERC-20 approval is a standing permission to move your tokens without asking again, and it is the most common drain vector that does NOT need the private key: approved once for an unlimited amount, months ago, forgotten. Wallets do not surface these. The load-bearing discipline is that an Approval EVENT IS NOT THE CURRENT STATE — a later approval of zero revokes an earlier one silently — so the log supplies candidate (token, spender) pairs and every one is confirmed by calling allowance() on the chain right now. Four outcomes, never two: live, confirmed-revoked, not-applicable (the call reverted, which is a definitive answer), and COULD-NOT-CHECK. The first draft collapsed the last two and reported forty closed doors having verified nine; an unanswered call is not a closed door. Read-only — it tells you what to revoke, and can never revoke or sign.

What CHANGED around this wallet since we last looked? The other tools answer at a point in time; this one remembers, which is what turns them into a guard. Three unlimited approvals granted last year are a standing condition; a fourth appearing this morning is an event, and only the second deserves to interrupt anyone — a monitor that repeats its standing conditions teaches its reader to close it, and a closed monitor is worth nothing. Detects new live allowances and first-time counterparties, then JUDGES each one against a local known-bad screen and the explorer rather than merely announcing it. Uses transactions, not event logs, because an ERC-20 Transfer log names whoever the emitting contract chose. Reports its own blind spots every run: on a wallet monitor an empty alert list reads as "you are safe". First run is an inventory, not a set of events.

Is this agent safe to connect to, and safe to pay? Four checkable dangers, none needing trust in a description. It does not exist — a listing is not a service, and paying an endpoint that never answers is the simplest loss available. Its tools can move money — a name is marketing, the input SCHEMA is the capability, and only a QUANTITY field proves a payment surface, because a message has a recipient exactly as a payment does but you cannot move value without saying how much. It asks for key material — a schema field for a private key or seed is the whole attack, declared in the open. Or it is paid to an address with no past. HTTP 401/403 returns unauditable rather than unreachable: the agent is running and gated, which is neither a pass nor a fail. Deliberately does NOT grade how good the description reads, because a well-written tool listing is free to fabricate and scoring prose would hand a forgery a good mark. Introspects and never calls a tool.

Is a recovery phrase sitting in cleartext on this machine? "Self custody if you know how to keep your seedphrase safe" puts the whole condition in the sentence, and nothing ships that checks it: an antivirus answers "do you have a known virus", not "is my seed readable by anything that runs here". This question is DECIDABLE rather than scored, which is why it is worth answering. A keyword scan drowns — abandon, able, about and absent are ordinary English and all four are BIP-39 words — but a mnemonic is a RUN of 12/15/18/21/24 consecutive words from a 2048-word list, and BIP-39 puts a CHECKSUM in the last word, so a candidate is proven by arithmetic. It NEVER outputs the phrase: only the file, the line and the word count, because this output ends up in terminal buffers, logs and screenshots, and a scanner that prints the seed it found is a stealer with good intentions. Reports its own blind spots: it cannot read images, PDFs, password managers, browser storage or encrypted archives, so "nothing found" means nothing was found IN WHAT WAS READ. Read-only, no network, zero dependencies.

What key material is on this disk, and which of it is readable without a password? The companion to seed_exposure, and it exists because a real theft happened WITHOUT the phrase ever being written down: the key was exfiltrated. The trap is that a secp256k1 private key is 64 hex characters and so is every SHA-256 hash, every git object id and every transaction hash in a saved response — searching for the value SHAPE finds hashes by the thousand. Two things carry information instead: STRUCTURE (a Web3 Secret Storage keystore has version 3 and a crypto member with ciphertext, kdf and mac — nothing else looks like that, and finding one is not an exposure, it is an encrypted wallet whose strength is its password), and THE LABEL (cleartext keys are named by what needs them, so this matches PRIVATE_KEY and rejects PRIVATE_KEY_HASH). The finding people miss is RETAINED COPIES: rotating a secret does not remove it from the disk, because editor history, session caches and backup folders keep snapshots of what the file used to say — on the machine this was built for, one .env with three named keys had eighteen previous versions still readable. Also reports browser wallet vaults by PRESENCE only, since that is how a key leaves a machine when it was never in a text file. Never outputs key material, not even a prefix: a four-byte prefix narrows a brute force. Read-only, never decrypts, never derives an address.