The Stack Audit · Methodology v1
Every rating on this site reduces to on-chain facts you can re-run yourself. This page is the full rubric.
Why the whole stack. Most safety boards ask one question: can the contract rug? That misses how projects actually fail. A contract can be immutable and ownerless while the site leaks an RPC key, loads its wallet-signing library from a third-party CDN with no integrity check, or holds user funds off-chain behind a login. Contracts are layer one of five here.
Read from the chain directly, never from the project's own claims.
Is the source verified?
Unverified means the rules are unreadable. A project that says "verify everything" while shipping unverified contracts fails its own pitch.
Is it upgradeable?
An upgradeable factory under one key means today's audit describes code that can be replaced tomorrow. "Enforced by code" and a proxy do not mix.
What can the owner actually do?
Not "is there an owner" but "what is the owner able to reach." Fee config is tolerable. Withdraw, mint, or LP access is not.
Token model
Ownerless, fixed supply, no mint path, no transfer tax, and ideally a clone of a verified implementation.
LP custody, the decisive check
"Liquidity locked" is the most abused claim in the category. What matters is who holds the LP receipt, and until when.
Trap selectors in bytecode
Mint, blacklist, pause, trading switches, and adjustable tax that can be raised after you buy.
Oracle dependence, where a contract prices, lends, or redeems
A protocol that reads its price from a single pool's spot balance can be moved with one flash-loaned swap. This does not touch a plain bonding curve; it applies to lending, RWA-backing, and redemption logic that trusts a feed.
The layer contract-only boards skip entirely. Most real-world losses start here.
Leaked API keys
Live provider keys shipped in the browser bundle. Found repeatedly on pads otherwise rated "safe" elsewhere.
Supply chain of signing code
If the library that builds and signs your transaction is fetched from a third-party CDN with no integrity pinning, a CDN compromise is a wallet compromise.
Security headers
CSP, HSTS, X-Frame-Options, nosniff. Absence is not fatal on its own, it is a hygiene signal.
Off-chain custody
Managed wallets, delegated signing, or balances held behind a login cannot be verified on-chain at all. That is a disclosure, not a rating.
Responsible-disclosure surface
A well-formed security.txt gives a researcher a way to report a bug before it is exploited. Its absence is a hygiene signal, not a failure; its presence is the mark of a team that expects scrutiny.
Every headline number is re-derived from the chain. Marketing is treated as an assertion to test.
Are the published numbers true?
Burn percentages, supply, TVL, "live on mainnet", "locked forever", "audited". These diverge from reality more often than contracts do.
Can the official project be identified?
If a site publishes no contract address and no social handle, users cannot tell the real token or account from impersonators. Name-squatting is common.
Who holds the keys, and what standing between them and a mistake.
The first four layers ask whether someone can take your money. This one asks whether the float is arranged so insiders can legitimately sell into you. A token can be structurally un-ruggable and still be a bad hold, and that is not a contradiction.
Insider and treasury concentration
A dev or treasury wallet holding a large share is a standing sell order. Un-ruggable does not mean un-dumpable, and the two get conflated constantly.
Continuous accrual (fee-on-transfer)
If a wallet takes a cut of every trade, it is a permanent sell-pressure engine: the position refills after every exit, so the holder can sell forever without ever running out.
Effective concentration (sybil clustering)
A max-wallet cap makes a row of identical ~2% holders look decentralised. Funding traces routinely collapse them into two or three actors, so real concentration is far higher than the holder list suggests.
Pool share and net flow
The liquidity pair shows up in holder lists and is constantly misread as a whale. What matters is the direction: a pair's token balance rising means net selling into the pool, which is the mechanical signature of a fade.
Vesting held on-chain, not on trust
"Team tokens are vested" is meaningless if the allocation sits in an ordinary wallet that can move any time. Enforcement has to be a locker or vesting contract with a readable schedule, not a line in a doc. Relevant only where a project actually claims a team or treasury allocation.
| Tier | Meaning |
|---|---|
| t1 | Verified, immutable, ownerless, LP unpullable. No rug path found in the contract itself, structural not promised. |
| t2 | Same structural safety, with one narrow caveat: a limited owner power, an unproven claim, or an unused flagship feature. |
| t3 | Sound design undermined by operational gaps: unverified contracts, leaked keys, or supply-chain exposure. |
| t4 | Upgradeable core under a single key. Existing funds may be locked today, but the rules can be rewritten. |
| t5 | A live path from an admin key to user funds. |
| t6-t7 | Unverifiable end to end, or the published claims and the chain disagree materially. |