The Stack Audit · Methodology v1

What gets checked, and how it's proven.

Every rating on this site reduces to on-chain facts you can re-run yourself. This page is the full rubric.

no tokenno feesno launchpadno paid ratings

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 four here.

Layer 01Contracts

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.

explorer /smart-contracts/<addr> → is_verified, source, ABI

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.

eth_getStorageAt EIP-1967 impl 0x360894…382bbc · admin 0xb531…6103 · selectors 3659cfe6 / 4f1ef286

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.

owner() 8da5cb5b · enumerate onlyOwner fns · scan bytecode for withdraw / mint / pause / setFee

Token model

Ownerless, fixed supply, no mint path, no transfer tax, and ideally a clone of a verified implementation.

totalSupply · owner() · mint selector 40c10f19 · EIP-1167 363d3d373d3d3d363d73 → impl

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.

NFPM/PositionManager balanceOf(factory|deployer|0xdead|locker) · locker getLocksForToken → tgeDate + owner

Trap selectors in bytecode

Mint, blacklist, pause, trading switches, and adjustable tax that can be raised after you buy.

eth_getCode → static selector presence scan

Layer 02Web & infrastructure

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.

bundle scan → *.g.alchemy.com/v2/<key> · lb.drpc.org · supabase anon/service keys

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.

resource audit → viem/ethers origin, subresource-integrity present?

Security headers

CSP, HSTS, X-Frame-Options, nosniff. Absence is not fatal on its own, it is a hygiene signal.

response header inspection

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.

flow review + which operations never touch the chain

Layer 03Claims versus reality

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.

balanceOf(0xdead) · totalSupply · mint/burn Transfer logs · code present on the claimed chain

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.

site-published CA + handles vs explorer search for same-name tokens

Layer 04Governance

Who holds the keys, and what standing between them and a mistake.

Renounced / no owner, nothing to compromise.
Timelock, changes are visible before they take effect.
Multisig, no single key is sufficient.
Single EOA, one hot key. Acceptable only when its powers are narrow and provably cannot reach funds or LP.

RatingsWhat the tiers mean

Tier	Meaning
t1	Verified, immutable, ownerless, LP provably unpullable. Cannot rug by construction, not by promise.
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.

PolicyHow findings are handled

Good work gets said out loud. Praise is scoped strictly to what is independently verifiable, a verified router, an immutable factory, never to a token or to code that has not been published.
Issues go to the project first. Private channel where one exists. Public only when a project publishes no reachable contact at all, and then framed as a fix, not a verdict.
Facts, not labels. Entries state what the contract does and where to confirm it. Conclusions about intent are left to the reader.
Corrections are published. Ratings move in both directions, and re-checks that upgrade a project are recorded the same as ones that downgrade it.
Every project has a right of reply. If you build something listed here and a finding is wrong, outdated, or missing context, send the address and the call that disproves it. It gets corrected and the change is dated on the entry. Reach me at @defiauditccie on X.

LimitsWhat this is not

This is not a formal security audit, and it is not a substitute for one.
Every entry is point-in-time. Contracts get redeployed, keys rotate, sites change. Check the verified date on the entry.
A high tier means specific failure modes were ruled out. It is not a prediction about price, competence, or intent.
Nothing here is financial advice.