★ Contract unverified on Etherscan/Sourcify

Methodology how we score #

**What this measures** This factor determines whether a protocol's deployed contracts have their source code verified on a major block explorer (Etherscan, Sourcify, or equivalent) as of the launch date. Verification means the protocol's ABI is publicly readable and its bytecode can be matched against published source. An unverified contract at launch means no third party — whether auditor, security researcher, or user — can independently confirm that the deployed bytecode corresponds to any reviewed codebase.

**Why it matters** Source verification is the minimum transparency bar for any protocol claiming an audit or public security review. Without it, the ABI is opaque, any published audit report is unverifiable against the deployed code, and users have no way to confirm that the contracts they are interacting with correspond to any document they have been shown. Transit Swap ($21M, 2022) operated with closed-source contracts that prevented discovery of a critical allowance-drain vulnerability in the claimTokens function. MobiusDAO ($2.15M, 2025) used unverified contracts concealing an arithmetic error on a three-day-old protocol. OpenZeppelin's governance security guidelines note that accountability requires linking protocol actions to "publicly known" identities and auditable code — unverified contracts eliminate the code side of that equation entirely.

**Green / Yellow / Red** Green is assigned when all contracts holding user funds or controlling admin roles are source-verified on at least one major explorer as of the launch block. Yellow covers cases where core contracts are verified but peripheral contracts (fee routers, helper contracts) are not, or when verification is in progress within 48 hours of launch. Red is assigned when any contract that holds user funds, controls a key admin role, or executes the primary protocol logic is unverified at launch with no public ABI available.

**Common gray cases** This factor is grayed when the protocol operates on a chain where block explorer verification infrastructure is unavailable or immature (some newer L2s), provided alternative verification via Sourcify or equivalent is demonstrated.

**Notable historical examples** - **Transit Swap** ($21M, 2022): Closed-source claimTokens function concealed a critical allowance-drain path; no audit covered the unverified code. - **MobiusDAO** ($2.15M, 2025): Unverified three-day-old protocol; arithmetic error hidden in unreadable bytecode. - **Penpie** ($27M, 2024): Permissionless market registration accepted unvalidated external contracts — adjacent pattern where code opacity enabled the exploit. - **Cork Protocol** ($12M, 2025): Audit scope excluded CorkHook contract that held the exploited logic.

**★ Critical factor** This factor alone is sufficient to trigger a D or F grade under rubric v1.7.0 — a single red assessment here overrides all other category scores. An unverified contract at launch means no audit is verifiable, no monitoring is possible at the function level, and no user can assess what they are trusting — it is the foundational transparency floor of the entire scoring system.

Measurement what to look for #

Determine whether the protocol's deployed contracts have source code verified on Etherscan or Sourcify (public ABI available).

Data & output #

Scored protocols 80 carry this factor #

Linked hacks 9 historical incidents #