DeFiPunk'd

Methodology

DeFiPunk'd grades DeFi protocols on five risk dimensions. A colored slice is an earned claim — backed by either a deterministic heuristic on raw DeFiLlama signals or a DEFI@home quorum of independent LLM runs that agree on grade and evidence. Where a slice is gray, no claim has cleared that bar yet. Every color traces to a re-verifiable source.

Where the data comes from

Every protocol is seeded from DeFiLlama via pnpm sync, which writes the full list into a committed JSON snapshot. Curators override individual fields by dropping a JSON file into data/overlays/ and opening a PR.

Every field carries a provenance tag, so you always know where the value came from:

The glyph only appears where there is evidence behind it; an em-dash means unsourced.

The 5-slice risk pizza

DeFiPunk'd uses the five assessment dimensions from DeFiScan v2: Control, Ability to exit, Autonomy, Open Access, and Verifiability. A gray slice is one no grade has been earned for yet.

Control — unknown Ability to exit — unknown Autonomy — unknown Open Access — unknown Verifiability — unknown
  • Control
    Who holds admin privileges, how contracts can be upgraded, and how quickly. Combines the old chain-ownership and upgradeability questions into a single assessment per protocol rather than per chain, because a split verdict across chains — one-chain-red, mainnet-green — hides more than it reveals.
  • Ability to exit
    Whether users can exit on their own terms if the protocol team disappears or acts adversarially.
  • Autonomy
    Whether a failure outside this protocol's own contracts (oracles, off-chain reporters, bridges, keepers, governance-mutable dependencies) can cause theft, loss of unclaimed yield, or materially change expected performance. Collateral counterparty risk lives here too.
  • Open Access
    Whether the protocol is reachable by anyone without an allowlist, KYC, geofence, or off-chain operator standing between a user and the contracts. Permissioned markets, whitelisted relayers, and frontends that gate withdrawals all live here.
  • Verifiability
    Whether anyone outside the team can independently verify what the code does: open-source status, audit quality and scope, bytecode-to-source correspondence at the deployed address, and whether post-audit changes were themselves reviewed.

What each slice checks

Every assessment works through a fixed checklist per slice — the same questions, in the same order, pinned into the prompt. Here is what each one looks for, in plain language, with the two endpoints of the grading scale.

Control
  • Who holds the admin / owner / governor keys on the live contracts — an EOA, a multisig, or on-chain governance.
  • How the contracts can be upgraded (proxy pattern, or immutable) and who controls the proxy admin.
  • How long the delay is between a privileged action being proposed and executed — the timelock, measured on the fastest uncontested path.
  • Every multisig that can touch the protocol: signer count, threshold, and whether signers are insiders.
  • For on-chain governance: proposal threshold, voting period, quorum, and the timelock between queue and execution.
  • Whether a separate emergency or guardian role can move faster than the main upgrade path.
  • The worst thing each privileged path can do — from replacing fund-holding code (most severe) down to routine operations.

Green — The most dangerous powers either can't touch user funds, or sit behind a ≥7-day delay plus a credible security council or broad on-chain governance.

Red — A single EOA or a 2-of-3 multisig can replace fund-holding code instantly, with no timelock.

Ability to exit
  • Every way a user gets funds out: withdraw, redeem, burn, claim, requestWithdrawal, exit.
  • Whether each exit path can be paused, and who holds the pause.
  • The maximum pause duration, and whether an uncapped or indefinite pause is reachable.
  • Whether emergency pauses and governance pauses are separate, each with its own time cap and actor.
  • For queued redemptions: maximum queue length, daily withdrawal caps, and whether the queue itself can be paused.
  • Whether a forced-exit or escape hatch exists for the case where admins turn adversarial.
  • Whether exit is callable directly on-chain, without the project's own frontend.

Green — Anyone can exit permissionlessly; pauses are absent, narrowly scoped, or capped at ≤7 days; already-finalized exits can never be frozen.

Red — Exit needs an admin's signature, finalized claims can be frozen indefinitely, there is no on-chain exit at all, or a single EOA / 2-of-3 multisig can pause exits with no time cap.

Autonomy
  • Every outside contract the protocol calls or reads — oracles, price feeds, pools, lending markets, yield wrappers — and what breaks if one fails.
  • Off-chain committees reporting data in (oracle sets, guardians, exit-bus signers): their size, quorum, and what mis-reporting could do.
  • Bridges or cross-chain messaging carrying material value, and who operates them.
  • Layered or restaked collateral, and whether a failure deep in the chain reaches user principal.
  • What safety nets exist (sanity checks, circuit breakers, fallback oracles, withdrawal queues) — and whether they're actually live on-chain today, not just proposed.
  • Reliance on keepers, relayers, or bots (liquidators, compounders, solvers) and what degrades if nobody runs them.
  • Whether governance can quietly swap in a new external dependency without giving users a window to exit.

Green — No outside failure can cost users their principal or unclaimed yield; every critical dependency has a live fallback; governance can't introduce new dependencies without an exit window.

Red — An outside failure can cause theft or principal loss — e.g. a single-source oracle with no fallback, or governance hot-swapping the oracle with no timelock.

Open Access
  • Whether user entry/exit functions carry a whitelist, allowlist, or KYC check in the contract itself.
  • Whether any off-chain operator's approval is required to admit a user action.
  • Whether at least one independent way in exists — a public SDK, a third-party frontend, a wallet integration, or an aggregator — that doesn't depend on the official site.
  • Whether the contracts screen addresses against an on-chain sanctions or blocklist.
  • The difference between read access (anyone can view state) and write access (transacting).
  • What the official site's terms and geo-restrictions actually say — recorded as context, not as the grade driver.

Green — No contract-level whitelist or KYC, no operator gatekeeping, and at least one independent access path exists. Frontend geo-blocking and terms of service are noted as context, not penalized.

Red — The contract itself gates entry/exit by whitelist or KYC, admission needs a single operator or small committee with no replacement procedure, or an on-chain blocklist is controlled by one party.

Verifiability
  • Whether the deployed bytecode is verified on the block explorer — both the proxy and its implementation if it's a proxy.
  • Whether the verified source corresponds to a public GitHub repo.
  • What audits exist: auditor name, date, and exactly which contracts or commit were in scope.
  • Whether the auditors are recognized firms.
  • Whether the deployed code has drifted in material ways since the last audit without a follow-up review.
  • For proxies: whether the implementation — not just the proxy shell — is verified.

Green — Bytecode is verified, a matching public repo exists, and at least one recognized firm has audited the currently-deployed contracts (with little drift, or the drift was re-audited).

Red — Bytecode is unverified (or the proxy is verified but its implementation isn't), there is no audit, or there is no public repo.

CEX special case

Protocols whose DeFiLlama category is exactly CEX are graded red across all five slices automatically. A centralized exchange is custodial off-chain infrastructure: the failure modes are the entire surface, and grading them per-slice would imply a separation that doesn't exist. The "DeFi" tab on the landing page filters CEX out by default.

Tier badges (bronze / silver / gold)

A medal next to a protocol's name signals how thoroughly its slice grades have been reviewed. Tier is computed from the assessments that have reached quorum, not from the grades themselves:

Tier is a review-depth signal, not a safety signal: a silver-tier protocol can have five red slices. Tier and grade are independent axes.

Family aggregation

Protocols deployed as a family (Uniswap v2/v3/v4, Aave v2/v3, Morpho Blue/MetaMorpho, …) appear as a single expandable row on the landing table. The family summary takes the grade of the highest-TVL child for every slice — so a small outlier deployment doesn't drag a well-graded family down — and the maximum tier badge across children. Expand the row to see each child's individual pizza and tier.

DEFI@home — distributed assessment

DEFI@home is how every non-heuristic grade is earned: a distributed, BOINC-style process where independent contributors run a pinned prompt through the LLM of their choice (Claude, ChatGPT, Gemini, …) and submit the JSON output as a pull request.

Each protocol page exposes an Audit a dimension yourself · DEFI@home section under the Risk analysis cards, with a Copy prompt button per slice plus an Audit all row that combines the five risk dimensions into one prompt. Submit run ↗ opens GitHub's new-file interface pre-pointed at data/submissions/<slug>/<slice>/ for one slice or data/submissions/<slug>/all/ for the combined JSON array. The prompt pins in the snapshot timestamp, prompt version, chains, GitHub repos, and audit links, so every re-run is verifiable against the same fixed evidence set.

A grade's authority comes from consensus across independent re-runs, not from any single LLM output. A quorum bot merges an assessment into data/assessments/ once at least 3 contributors using different models agree on grade and overlapping evidence; disagreements surface on a per-slug aggregation issue. A scheduled GitHub Action runs the same pinned prompts through the Anthropic API as an independent third voice, so coverage keeps advancing on its own. See /contribute for the full flow.

Curated metadata from DEFI@home

The same DEFI@home submissions that produce slice grades also carry a protocol_metadata block. When a slice reaches quorum, fields from the highest-weight submission propagate to the protocol detail page with the [:] glyph:

These fields are not graded — they're factual claims with citations in the underlying submission, inferred from the assessment work the contributor already did rather than re-asked separately.

Reconcile and the master file

After quorum lands the per-slice assessments, a scheduled reconciler runs Claude Sonnet over the merged assessments plus the raw submissions and writes a synthesized verdict to data/master/<slug>.json. The master file feeds the protocol detail page's narrative — findings, steel-man arguments, verdict, and noted dissent. It does not re-grade; it consolidates what the quorum already decided into prose a reader can scan.

Stages

The Stage column is reserved for an upcoming adoption of DeFiScan v2's stage framework. Today every protocol shows an em-dash there. The tier badge is the current "is this protocol reviewed?" signal — it answers a different question than a stage (review depth vs. decentralization milestone), so the two will coexist when stages land.

Inactive and delisted protocols

DeFiPunk'd mirrors DeFiLlama. Protocols flagged is_dead upstream show an "(inactive)" label on the landing table and are hidden by default behind a "Show inactive" toggle. If DeFiLlama removes a protocol entirely, DeFiPunk'd marks it delisted_at and serves a stub page explaining the removal for 14 days; after the grace window the protocol is dropped from the registry.

Corrections

Spotted a wrong field? Open an issue or a PR on github.com/guil-lambert/defipunkd — corrections ship on the next build.