MethodologyWhat I check, in plain English, before I score.

Every verdict sits on top of a Claude Security reading that covers the same ground, every time, in the same order. The list below is the spine of that reading. Specific contracts trigger specific deeper checks, but nothing on this list is skipped. When Claude Mythos goes generally available, the spine stays; the reading deepens.

What I read, and in what order

1. Source verification. Is the source published on the chain's explorer and does the bytecode match? Unverified bytecode scores 1 or 2 — the refusal to publish source is itself the signal. The deployer can move the score the moment they publish source by re-commissioning a verdict.
2. Inheritance and imports. Every parent contract, every imported library. A clean child can inherit a dangerous parent. I read both.
3. Privileged actions. Who can mint, burn, pause, blacklist, redirect fees, set oracle addresses, withdraw treasury, upgrade. Every one of these is mapped to the controlling address and the controlling mechanism (EOA, multisig, timelock).
4. Upgradeability. Is the contract behind a proxy? Which pattern (transparent, UUPS, beacon)? Who controls the admin? Is the admin renounced, timelocked, multisig, or a single key? An upgradeable contract is a promise to be honest later, not a guarantee.
5. Supply control. Total supply, max supply, mint paths, burn paths. Hidden inflation surfaces. Treasury reserves and vesting. What can the team print and when.
6. Fee surface. Buy fee, sell fee, transfer fee, max wallet, max transaction. Whether the fee is bounded by a constant or by a setter the team can move. Whether the fee recipient is fixed or can be redirected.
7. Trading restrictions. Blacklist functions, anti-bot mechanisms, trading enable/disable toggles. Useful at launch, dangerous later if not removed.
8. External calls. Every call, delegatecall, and external contract dependency. What does each one do, what can each one return, and what happens if the called contract is upgraded or compromised.
9. Oracle dependencies. Price feeds, TWAPs, off-chain signers. Single-source oracles are flagged. Manipulable oracles are flagged louder.
10. Reentrancy and state ordering. Where state is updated relative to external calls. Checks-effects-interactions violations. Multi-step withdraw patterns that can be interleaved.
11. Access control patterns. Role-based permissions, ownership patterns, multisig posture. Whether onlyOwner means a single key or a governance process.
12. Withdrawal and rescue functions. Any function that lets a privileged actor remove value from the contract, including "emergency" or "rescue" functions. These are read carefully because they are the most common rug surface.
13. Event emissions. Whether state-changing actions emit events. Quiet contracts are harder to monitor and harder to trust.
14. Test surface. Whether the project publishes a test suite, what it covers, and what it doesn't.
15. Deployment context. Deployer history, related contracts, prior projects from the same address. Wallet age. Funding source where visible.

The deployer, and the wallet graph

The contract is the coin. The deployer is the mint. Most rug reads stop at the code; the unmodelled risk is the wallet that controls it. A flawless contract deployed by a sanctioned address is still false coin. A pausable contract behind a multisig of three audited names is closer to honest than the same contract behind a fresh EOA funded an hour before launch.

Today. Every on-chain verdict fetches the deployer and runs the full wallet pipeline. Two distinct sources, kept honest. The first is OFAC sanctions screening, which is a binary signal, the deployer is either on the OFAC SDN list or not. An OFAC sanctioned: true is a 1 or a 2 regardless of how clean the code reads. The second is wallet-graph analysis: the deployer's funding chain back through several hops, with every hop scored for mixer interactions, exchange-deposit reuse, dusting, rapid-forward patterns, control clusters (common recipients, round-trip flows, timing correlation), and bot indicators on the root. The mixer and exchange-hot-wallet classifications are maintained internally; OFAC is the only external signal. Each signal surfaces as a deployer-level finding in the verdict's findings list, feeding into the same single score as the contract-level findings, with the OFAC binary as the hardest weight.

Mythos. Today's trace covers the surface. Mythos lets it go further, into the second-order graph, the addresses that move in lockstep with the deployer's cluster, the bridge hops that obscure provenance across chains. The detector inventory does not change; the depth does. Coordinated launches betray themselves on-chain weeks before the token ships. When Claude Mythos lands, the spine stays and the reading deepens.

The Defacement is available from Day 0 alongside the verdict offering. When the disclosure window closes without a fix, anyone can commission a signed proof of exploit. A categorical mark publishes as an indexed event in a public on-chain registry, tied to both the contract and the deployer's wallet, with a tamper-evident hash of the private proof bundle recorded on-chain. The bundle itself ships only to the commissioning holder and the deployer. Categories on-chain, exploits off-chain, the same rule that governs the verdict. Mythos, when it lands, deepens the Defacement the same way it deepens the read.

The exploit surface this catches is the deployer's capability after the sale: hidden mints they can fire later, proxy admins they have not renounced, blacklist functions that lock holder wallets at will, fee-recipient setters that redirect cash flow at any block. A deployer with intent and mechanism is a deployer set up to exploit the token and the wallets that hold it. The current pass catches code-level evidence of that intent. The deeper pass catches the operator's pattern across other deployments before they fire it.

Vulnerability framework

Findings are categorised against the OWASP Smart Contract Top 10 (2026). The same ten categories shape the verdict's vulnerabilities_detected field and the on-chain vulnerabilityCategory on a Defacement, so a reader can map any single mark back to a published industry framework rather than my private taxonomy.

An internal static-analysis pre-pass feeds these categories: every detector hit maps to one of SC01-SC10. Claude's prose names the OWASP category by name in the verdict text, so a reader doesn't need the mapping to make sense of a finding.

The on-chain Diogenes registry carries the OWASP category as a readable string on every Defacement event. See the Changelog for the Defacement spec.

What I do not check

• Price action. Charts, candles, volume, holder distribution as a price signal. I am not an analyst.
• Marketing claims. I read the contract. The whitepaper, the website, the founder's Twitter bio are noise unless they make specific testable claims about the code, in which case I verify only the code.
• Roadmaps. Future promises do not affect today's score. If a future commit moves the score, the Update verdict will say so.
• Off-chain trust. Doxxed founder, audited by Firm X, partnered with Y. I note these as evidence but do not weight them. The code is the asset.

How the read gets done

The full reading happens in one Claude session per contract, with the soul (the system prompt) cache-loaded at the start. Claude reads the entire surface, end to end, without skipping, calling out to the tool stack as it goes. Wall-clock is seconds; the depth is what a careful manual reviewer would produce. The output is the verdict text, the score, the watch-fors, and any vulnerability category and severity surfaced against the OWASP Smart Contract Top 10 2026 rubric. What goes inside each tool stays mine; what comes out is the verdict.

Every verdict is tagged with the prompt version that produced it, so I can compare hit rates across versions and audit drift. The prompt is not edited mid-run; if it is, the version number bumps and the change is visible.

Where this comes from

The list above is the methodology spine, but it is not a checklist read mechanically. Claude reads each contract in context, applying these checks the way an experienced reviewer would, weighting what matters for that specific code, surfacing what is unusual. The score reflects the read, not the count of items flagged.

The closest analogue is a manual security review at a top audit firm, compressed into seconds instead of weeks, and aimed at a verdict for the holder rather than a report for the team. See what one looks like →

How this is different from existing tools

I am not a replacement for any of these. I am what fills the gap between "automated scanner" and "$50k manual audit": careful, reasoning-driven, publicly accountable, priced for the holder rather than the founder.