DeFiPunk'd

Nexus Mutual

Insurance

TVL $91.5M
Type Insurance
Chain Ethereum
View on DeFiLlama ↗
Control criteria
Upgradeability Mixed Bug bounty immunefi.com Governance forum forum.nexusmutual.io Docs docs.nexusmutual.io
About

Nexus Mutual is an Ethereum mutual where members buy cover for smart-contract, custody, slashing and depeg risks, stake NXM to underwrite products, and assess claims. The Capital Pool holds the assets backing NXM, receives cover premiums, pays accepted claims, and supports NXM minting or selling subject to mutual capital rules. V2-style modules include the Pool, Registry, TokenController, staking pools, cover products, RAMM and swap infrastructure.

Risk analysis

One card per dimension, sorted by severity. Only Verifiability and Autonomy carry automated signals in Phase 0. See methodology for scope.

Audit a dimension yourself · DEFI@home Contribute an LLM-run assessment — any model, any dimension. Three agreeing runs merge automatically into the public record.

DEFI@home is a distributed audit network modeled on SETI@home: instead of CPU cycles, it crowdsources LLM reasoning. Paste a slice prompt into Claude, ChatGPT, Gemini, or any browsing-capable model, and submit the JSON output as a pull request. The quorum bot merges it once ≥3 independent runs (from different models) reach the same grade — no single model, and no single contributor, can move the needle alone. How it works →

  • Address discovery 15 addresses on file · 1 run Submit run ↗
  • Verifiability ✓ 3/3 models agree AI-only weak orange — weak consensus margin Submit run ↗
  • Control ✓ 3/3 models agree AI-only weak orange — weak consensus margin Submit run ↗
  • Ability to exit ✓ 3/3 models agree AI-only weak orange — weak consensus margin Submit run ↗
  • Autonomy ✓ 3/3 models agree AI-only weak orange — weak consensus margin Submit run ↗
  • Open Access ✓ 3/3 models agree AI-only weak red — weak consensus margin Submit run ↗
  • Audit all 5 dimensions · one prompt Submit run ↗
  1. Verifiability tentative 3/3 models agree AI-only 3/3 with chat share link
    All major contracts verified; public repo exists; primary auditor (iosiro) not in broadly-recognized list; v3 Registry/Governor architecture may post-date last in-scope audit
    Verdict

    Choosing orange because (a) all main contracts are verified on Etherscan including their implementations (V1, V6 satisfied), (b) a public source repo exists at NexusMutual/smart-contracts (V2 satisfied), but (c) the dominant auditor (iosiro) is not on the prompt's broadly-recognized list — per V4 the rubric explicitly caps such cases at orange, and (d) the v3 Registry/Governor architecture providing fund-custody upgrade authority appears to post-date the last public audit by a meaningful interval. Green is unreachable under V4 without a recognized-firm audit on the current deployment; red is not warranted because verification, repo, and multiple audits (including iosiro's specialized history) all exist.

    Steelman argument
    Steelman argument Every major contract is verified on Etherscan (both proxy and implementation), the GitHub repo is public and active with 32 releases and a v3.3.0 release in Feb 2026, iosiro has been the consistent auditor since 2021 with deep familiarity, and Chaos Labs provided an economic audit of the RAMM tokenomics — but iosiro is not on the prompt's broadly-recognized list, which the rubric explicitly designates as orange-at-best, and the v3 Registry/Governor architecture has not been visibly audited by a recognized firm.
    Evidence (6)
    V1
    Etherscan / DeFiPunkd ABI-source reads confirm all surfaced contracts are verified: NXMaster (0x01BFd826...0cD07e) abiSource=etherscan; Registry (0xcafea2c5...236b9e) abiSource=etherscan; Governor (0xcafea606...82Ca32) abiSource=etherscan; Pool1 legacy (0xfD61352...E1884) abiSource=etherscan; MemberRoles (0x055CC48f...3926) abiSource=etherscan; NXMToken (0xd7c49CEE...4Cf3B) abiSource=etherscan; Emergency Pause Safe (0x422D71fb...2995D) abiSource=etherscan. Additional verified contracts cited via Etherscan: Capital Pool (0xcafea917...697cb), Pool V2 (0xcafea112...0627), Claims (0x813174d3...176139), Community Fund (0x586b9b2f...6e9), Legacy Claim Proofs (0xcafea81b...0B6775).
    V2
    Public source repository: https://github.com/NexusMutual/smart-contracts (181 stars, 6,863 commits, GPL-3.0). Latest release v3.3.0 published 2026-02-24; 32 total releases. The repo organization mirrors the on-chain contract structure (contracts/ directory with modules for cover/staking/governance/pool/oracle). Independent compile/bytecode-match not attempted this run — recorded in unknowns rather than treated as a downgrade signal.
    V3
    Audit timeline from official docs (newest to oldest): iosiro March 2025 (Cover Edit + Limit Orders + Staking Pool Fix), iosiro January 2025 (Product Pricing Changes), iosiro November 2024 (USD Price Feed Oracle), iosiro September 2024 (Long Term Limit Order), iosiro August 2024 (Staking Pool Fixes + NXM Batch Withdrawal), iosiro July 2024 (CoverProducts Refactor + Total Active Cover Fix), iosiro March 2024 (Swap Operator Asset to Asset), iosiro January 2024 (Safe Tracker), iosiro October 2023 (RAMM), Chaos Labs October 2023 (RAMM economic audit), iosiro November 2022 – March 2023 (V2 Audit of contracts/modules), iosiro May 2021 + June 2021 (multiple), G0 Group June 2020 / November 2020 / March 2021, Solidified April 2019.
    V4
    Auditor recognition: iosiro (the dominant auditor across 10+ Nexus Mutual audits since 2021) is NOT in the prompt's broadly-recognized list (Trail of Bits, Zellic, Spearbit, OpenZeppelin, ConsenSys Diligence, Certora, Quantstamp, Halborn, Peckshield, Sigma Prime, ChainSecurity, Ackee Blockchain, MixBytes, Statemind). Chaos Labs (economic audit, October 2023) is reputable for economic modeling but did not audit the smart-contract bytecode. Solidified (April 2019) and G0 Group are also outside the broadly-recognized list. No audit from a broadly-recognized firm on the currently-deployed contracts was found.
    V5
    Post-audit drift: The most recent in-scope audit is iosiro March 2025 (Cover Edit, Limit Orders, Staking Pool Fix). The GitHub repo's latest release v3.3.0 was published 2026-02-24 — approximately 11 months after the last audit. The v3 Registry / Governor / Pool architecture (Registry at 0xcafea2c5...236b9e, Governor at 0xcafea606...82Ca32) introduces materially new fund-control surfaces (Registry.upgradeContract, Registry.addContract, Governor.execute) whose audit coverage by a recognized firm is not visible from the public audits page. Specific drifted contracts (Registry, Governor) hold fund-custody upgrade authority, so this is material drift per the V5 SCOPE rule. Diff content not sampled this run — flagging in unknowns rather than treating as confirmed material drift, but the audit-staleness vector alone supports orange.
    V6
    Proxy + implementation both verified: NXMaster proxy 0x01BFd826...0cD07e → implementation 0xcafea223...A438 (etherscan); Registry proxy 0xcafea2c5...236b9e → implementation 0xcafeaC64...500E (etherscan); Governor proxy 0xcafea606...82Ca32 → implementation 0xcafea466...A830 (etherscan); MemberRoles proxy 0x055CC48f...3926 → implementation 0xcafea01C...d2B1 (etherscan); PooledStaking proxy 0x84EdfFA1...272f → implementation 0xcafea865...2829 (etherscan).
    Why is this consensus tentative?
    • weak consensus margin

    A fresh independent run can strengthen (or overturn) the verdict.

    Run your own prompt Submit run ↗
    Sources claude-opus-4-7 url ↗ GPT-5.5 Thinking url ↗ grok-xai url ↗ View raw submissions ↗
  2. Control tentative 3/3 models agree AI-only 3/3 with chat share link
    On-chain Governor with 4-day uncontested fast path can upgrade fund-holding Pool (T1); 2-of-6 emergency Safe holds pause role
    Verdict

    Choosing orange because the uncontested fast path is 4 days (3-day voting period + 1-day timelock, both read on-chain), which is below the 7-day bar required for green when T1 is reachable. The Governor's upgradeContract reaches a tier-1 outcome (replacing the Capital Pool implementation that holds member funds), and the optimistic-governance default-accept model means proposals pass unless 15% of NXM supply actively rejects. The 2-of-6 emergency-pause Safe fails Security Council criteria. The orange steel-man best fits because the 4-day delay does provide meaningful advance notice but is short of the 7-day standard and combined with low pause-multisig threshold.

    Steelman argument
    Steelman argument T1 is reachable but only through a multi-stage public process: 3-day voting period plus 1-day timelock gives users 4 days of advance notice to react, the pause role is split between proposer and confirmer roles (no unilateral pause), and the AB has 5 publicly-named members serving at member discretion.
    Evidence (7)
    C1
    Pinned 'proxy_admin' 0x01BFd826...0cD07e is the NXMaster proxy; its proxyOwner is 0x4A5C68...87900 and its registry() points to the new Registry at 0xcafea2c5...236b9e, which holds proxyOwner=0xcafea606...82Ca32 (Governor). The Governor is the upgrade authority for the active v3 architecture; the legacy NXMaster has an emergencyAdmin field set to 0x422D71...2995D.
    C2
    All major contracts use OwnedUpgradeabilityProxy with upgradeTo()/transferProxyOwnership() — upgradeable architecture. Registry's implementation is 0xcafeaC64...500E and Governor's implementation is 0xcafea466...A830; both contracts expose upgradeContract/upgradeTo paths controlled by the Governor.
    C3
    Uncontested fast path on Governor (0xcafea606...82Ca32): propose → VOTING_PERIOD = 259200s (3 days) → TIMELOCK_PERIOD = 86400s (1 day) → execute. Total uncontested delay = 4 days = 345600 seconds. Both constants read on-chain at block 25083310.
    C4
    Emergency Admin is a 2-of-6 Gnosis Safe v1.3.0 at 0x422D71fb...2995D (threshold=2, 6 owners read at block 25083311). Per docs, its only role is to enact emergency pause on RAMM or the entire protocol. 2-of-6 = 33% threshold fails Security Council criteria (≥51% threshold + ≥7 signers + ≥50% non-insider).
    C5
    Governor on-chain constants (block 25083310): PROPOSAL_THRESHOLD=100 NXM (100e18), MEMBER_VOTE_QUORUM_PERCENTAGE=15 (rejection quorum — optimistic governance, AB proposes default-accept), VOTE_WEIGHT_CAP_PERCENTAGE=5, ADVISORY_BOARD_SEATS=5, ADVISORY_BOARD_THRESHOLD=3. Optimistic model: AB-proposed default outcomes pass unless members meet 15% rejection quorum.
    C6
    Yes — emergency-pause role is distinct from upgrade authority. The Registry has separate proposePauseConfig/confirmPauseConfig functions with a ProposerCannotConfirmPause error, requiring two distinct actors (emergencyAdmin proposes, separate confirmer required). isEmergencyAdmin role is grantable by Governor via setEmergencyAdmin.
    C7
    Highest tier on the fast path is T1 (FUND-CRITICAL): the Governor can call upgradeContract on the Registry to replace the Capital Pool implementation that holds ~$61M of user funds. Per rubric, T1 reachable with uncontested-fast-path delay >0 but <7 days = orange. Optimistic governance (default-accept) means proposals pass without active member opposition.
    Why is this consensus tentative?
    • weak consensus margin

    A fresh independent run can strengthen (or overturn) the verdict.

    Run your own prompt Submit run ↗
    Sources claude-opus-4-7 url ↗ GPT-5.5 Thinking url ↗ grok-xai url ↗ View raw submissions ↗
  3. Ability to exit tentative 3/3 models agree AI-only 3/3 with chat share link
    NXM redemption requires MCR > 100% and is pausable via 2-of-6 emergency Safe + governance; pause has no on-chain time cap
    Verdict

    Choosing orange because (a) the pause path can prevent NXM-to-ETH redemption with no documented on-chain time cap, (b) the redemption is structurally gated by MCR > 100% which is a contract-enforced condition that can prevent exit under stress, and (c) the pause requires governance-vote confirmation rather than unilateral multisig action (consistent with orange's 'pausable through governance vote, not unilateral admin'). It does not meet red because the pause is split between proposer and confirmer roles, the MCR gate is a mutual-insurance feature rather than admin discretion, and finalized stake withdrawals can be claimed by the staker permissionlessly after the on-chain 30-day lock. It does not meet green because there is no time cap on pause and the MCR-conditional redemption falls short of unconditional permissionless exit.

    Steelman argument
    Steelman argument Pause requires two distinct actors (ProposerCannotConfirmPause prevents the multisig from acting alone), the MCR>100% constraint is a structural mutual-insurance feature (not an admin discretion), NXM transfers within the whitelisted member set are not pause-gated, and the legacy 30-day unstake lock auto-expires without admin involvement.
    Evidence (7)
    E1
    User-facing exit functions: (a) Pool.sellNXMTokens to redeem NXM for ETH (via RAMM); (b) MemberRoles.switchMembership(address) to migrate membership; (c) MemberRoles.recoverETH; (d) legacy PooledStaking.withdraw / withdrawForUser / withdrawReward / requestUnstake (30-day UNSTAKE_LOCK_TIME read on-chain = 2592000s); (e) v2 staking pool withdraw functions accessed via the StakingNFT. NXM transfer/sell is mediated by NXMToken whose transfers are gated by whiteListed(address).
    E2
    Exit functions are gated by isMember() + pause checks. The Registry encodes a Paused(uint256 currentState, uint256 checks) error and isPaused(uint256 mask) view, and contracts implementing IRegistry-aware logic call isPaused with module-specific masks. NXMToken transfers require both sender and recipient to be in the whiteListed set (managed by the TokenController = 0x540738...0B8).
    E3
    Pause role is held by addresses for which isEmergencyAdmin(address) returns true (managed via setEmergencyAdmin onlyGovernor) plus the legacy emergencyAdmin field on NXMaster, currently set to the 2-of-6 Safe 0x422D71fb...2995D. PauseConfig is a uint48 bitmap with proposePauseConfig (proposer) and confirmPauseConfig (must be a different actor per ProposerCannotConfirmPause). At block 25083310 getPauseConfig=0, getSystemPause.config=0 (not paused). No on-chain MAX_PAUSE_DURATION constant was found in the Registry/NXMaster ABIs read this run.
    E4
    Per docs, AB and Emergency Pause Safe both have pause powers; the on-chain split is between emergencyAdmin role (Safe) proposing and the Advisory Board / Governor confirming (or vice-versa) — two-actor confirmation prevents unilateral pause. The fast emergency pause is therefore at multisig speed (2-of-6) but requires a separate confirmer.
    E5
    Structural exit constraint: NXM-to-ETH redemption is only available when MCR (Minimum Capital Requirement) ratio > 100%. Per docs: 'Members can redeem NXM for ETH directly from the Mutual, but only when the minimum capital requirement ratio (MCR%) is above 100%.' This is an autonomous, contract-level exit gate that fires under adverse capitalization. Legacy PooledStaking exit has a fixed UNSTAKE_LOCK_TIME of 30 days (2592000s) read on-chain.
    E6
    No documented forced-exit / escape-hatch mechanism for adversarial-admin scenarios. The closest is MemberRoles.recoverETH (purpose unclear, governance-restricted) and the 30-day unstake lock that auto-expires. There is no permissionless emergency-exit independent of MCR/pause state.
    E7
    Exit functions are directly callable on the contract write tabs (sellNXMTokens, withdraw, requestUnstake) without the official frontend, but membership status is enforced on-chain via isMember(msg.sender) and NXM whitelisting, so a non-member EOA cannot acquire NXM in the first place. For an existing member, exit is frontend-independent.
    Why is this consensus tentative?
    • weak consensus margin

    A fresh independent run can strengthen (or overturn) the verdict.

    Run your own prompt Submit run ↗
    Sources claude-opus-4-7 url ↗ GPT-5.5 Thinking url ↗ grok-xai url ↗ View raw submissions ↗
  4. Autonomy tentative 3/3 models agree AI-only 3/3 with chat share link
    Capital Pool holds large LST/LRT positions (Lido stETH, rETH, Stakewise, EtherFi, Enzyme-Kiln); governance can add new external dependencies via 4-day timelock
    Verdict

    Choosing orange because the Capital Pool's documented exposure to multiple LST/LRT providers (Lido stETH at peak ~30,000 stETH plus rETH, weETH, Stakewise positions) is material — a major LST/LRT failure could materially change expected performance and trigger the MCR<100% exit gate, even though principal loss is bounded by diversification. Impacted TVS estimate: a worst-case single-LST failure (e.g., total stETH peg loss to 80%) would impair on the order of 10–30% of Capital Pool NAV (~$6M–$18M out of ~$61M reported on Etherscan), recoverable over time but materially affecting unclaimed yield and exit liquidity. Governance can introduce new dependencies via the same 4-day path used for control changes, so the dependency surface is mutable but not silently mutable. Module-level note: the legacy v1 pool (pinned 0xfd61352232157815cf7b71045557192bf0ce1884) has balance 0 and is decommissioned, so its share of TVS is ~0%; all current TVS sits in the v3 Capital Pool, weighted overall = orange.

    Steelman argument
    Steelman argument External dependencies are diversified across at least four independent LST/LRT providers, each addition requires a public 4-day governance vote with members able to reject, the MCR gate is a recoverable mechanism (capital recovers, MCR returns above 100%, exits reopen) rather than a permanent loss event, and there is no admin-only fast path to introduce new dependencies.
    Evidence (9)
    A1
    Capital Pool (current address 0xcafea917...697cb per docs, ~$61.5M balance) holds and reads from multiple external positions per the governance-approved investment allocations: Lido stETH (peak ~30,000 stETH), Rocket Pool rETH (~13,358 rETH from NMPIP 197), Stakewise V3 via Chorus One (4,989 ETH allocation under NMPIP 228), EtherFi weETH (1,586 ETH), and Kiln via Enzyme vault (6,624 WETH). USD Price Feed Oracle support (Chainlink-style) was audited in November 2024 — the protocol uses external price feeds for cover pricing in USD-denominated covers.
    A2
    Off-chain reporter critical to admission (not asset accounting): kycAuthAddress = 0x176c2797...4656 signs Registry.join(member, signature). A KYC-authority compromise would let unauthorized addresses join but does not directly enable theft of existing user principal. Advisory Board (5 named members) participates in optimistic governance default-outcome setting and pause confirmation.
    A3
    No bridge / cross-chain dependency for the core mutual — Nexus Mutual is Ethereum-mainnet only. The protocol issues USD-denominated covers but settles claims in ETH/USDC/cbBTC on Ethereum; cross-chain risk is limited to whatever bridge-risk products are covered (which is a customer-facing risk, not an autonomy risk of THIS protocol).
    A4
    Nested-collateral chains present via LRT (EtherFi weETH = ETH staked → restaked via EigenLayer). Depth: ETH → Lido/Rocket Pool/Stakewise validator → (for weETH) → EigenLayer AVS slashing surface. A coordinated slashing or LRT depeg could impair the Capital Pool's ETH-denominated value. Per investments page, allocations span at least 4 distinct LST/LRT providers, giving some diversification.
    A5
    Not forked — Nexus Mutual is an original protocol launched 2019 (Solidified audit). Not flagged in DeFiLlama's forkedFrom.
    A6
    Fallback mechanisms: (i) DOCUMENTED but not separately verified on-chain this run — RAMM (Ratcheting AMM) provides bounded price discovery for NXM/ETH swaps with audited tokenomics (iosiro Oct 2023, Chaos Labs economic audit Oct 2023). (ii) DOCUMENTED — MCR > 100% gate prevents NXM-to-ETH redemption when capital is insufficient (this is a fallback against bank-run scenarios). (iii) DOCUMENTED — claims must pass member-staked claims-assessment before payout. Live on-chain enforcement of MCR gate could not be confirmed in this run.
    A7
    No sequencer / L2-liveness dependency beyond the Ethereum L1 substrate. Nexus Mutual deploys on Ethereum L1 only.
    A8
    Limited keeper liveness dependency: legacy PooledStaking has processPendingActions (permissionless, anyone can call to settle pending burns/rewards/unstakes) with hasPendingActions=true at block 25083308. Withdrawal claims do not depend on keepers running — stakers can call withdraw directly. Cover claim payouts are governance-mediated (claims assessment + AB), not keeper-mediated.
    A9
    Governance-mutable external dependency surface is broad: Registry.addContract / Registry.upgradeContract (onlyGovernor) can register new SwapOperator / StakingPool / oracle implementations that touch user funds. The investment-allocation process is members-voted through the standard 4-day path (3-day voting + 1-day timelock), so new LST/LRT/yield-source dependencies can be added — but only after the public timelocked vote. There is no faster admin-only path to swap an external dependency without governance. This means dependency-surface changes inherit the same 4-day delay graded under the control slice.
    Why is this consensus tentative?
    • weak consensus margin

    A fresh independent run can strengthen (or overturn) the verdict.

    Run your own prompt Submit run ↗
    Sources claude-opus-4-7 url ↗ GPT-5.5 Thinking url ↗ grok-xai url ↗ View raw submissions ↗
  5. Open Access tentative 3/3 models agree AI-only 2/3 with chat share link
    Contract-level KYC whitelist on NXM transfers; Registry.join requires KYC-authority signature; 27+ jurisdictions blocked
    Verdict

    Choosing red because the rubric's red bar is met unambiguously: 'contract-level whitelist / KYC on user entry/exit' — NXMToken has whiteListed(address) gating transfers and Registry.join requires KYC-authority signature. This is not frontend-only ToS posture; it is enforced in immutable token bytecode (NXMToken is immutable per docs) and in the upgradeable Registry. Existence of an SDK / direct Etherscan access does not change this because no independent path allows non-KYC'd addresses to participate. The geographical restriction list (27 jurisdictions) is operationally enforced at the KYC step. This is a fundamental property of the discretionary-mutual model and is disclosed clearly to users.

    Steelman argument
    Steelman argument NXMToken has a contract-level whitelist on transfers (whiteListed modifier), Registry.join requires a signature from a single off-chain KYC authority (0x176c27...4656, an EOA), and 27 jurisdictions are explicitly excluded — this is contract-enforced KYC gating user entry, which the rubric explicitly designates as red.
    Evidence (8)
    A1
    NXMToken (immutable, 0xd7c49CEE...4Cf3B) enforces an on-chain whitelist via whiteListed(address) and addToWhiteList/removeFromWhiteList functions controlled by the operator (TokenController = 0x540738...0B8). Token transfers between non-whitelisted addresses are blocked at the contract level. Registry contract enforces onlyMember and NotMember errors on all member-only entry points.
    A2
    Registry.join(address member, bytes signature) requires a valid signature from kycAuthAddress = 0x176c27973E0229501D049De626d50918ddA24656 (an off-chain KYC authority, EOA). Without this signature, an address cannot become a member and therefore cannot hold NXM, buy cover, stake, or vote. This is admission-gated by a single off-chain operator.
    A3-active
    Frontend enforces KYC verification: per the membership page, prospective members must 'submit a photo of your government-issued identification, which will be used in the verification process' and pay a 0.0020 ETH JOIN_FEE (read on-chain in Registry.JOIN_FEE = 2000000000000000).
    A3
    Geographic restrictions enumerated explicitly: Nexus Mutual cannot accept members from 27 listed jurisdictions including Algeria, Angola, Bolivia, Bulgaria, Cameroon, China, Cote d'Ivoire, DRC, Haiti, India, Iran, Japan, Kenya, Laos, Lebanon, Mexico, Monaco, Myanmar, Namibia, Nepal, North Korea, Russia, South Sudan, Syria, Venezuela, Vietnam, and Yemen. This restriction is enforced via the KYC step.
    A3b
    Independent access paths exist for already-KYC'd members: an SDK is published at https://sdk.nexusmutual.io (linked from the GitHub repo README) and the contracts are directly callable on Etherscan for any whitelisted address. However, these paths do NOT bypass the contract-level whitelist — they only let an existing member interact without the frontend. There is no path by which a non-KYC'd address can hold NXM or buy cover.
    A4
    No explicit on-chain OFAC blocklist contract was identified in the surfaced ABIs. Sanctions enforcement is done off-chain via the KYC process; the KYC authority's signature is the on-chain enforcement point.
    A5
    Read access is fully permissionless — all view methods (member counts, proposal state, contract addresses) are openly readable. Write access (joining, buying cover, staking, voting, redeeming NXM) is gated to whitelisted members only.
    A6
    ToS / Member Agreement is linked from the membership page at https://uploads-ssl.webflow.com/62d8193ce9880895261daf4a/63d0f45aacb2752b543ddcaf_Nexus-Mutual-DAO-Member-Agreement-FIN.pdf — the membership-page summary confirms KYC/AML requirement: 'To become a member, you will need to verify your identity through the Know-Your-Customer / Anti-Money-Laundering process. If this fails, you won't be able to join the Mutual.' Verbatim quote captured from the docs page; the full PDF was not separately fetched this run.
    Why is this consensus tentative?
    • weak consensus margin

    A fresh independent run can strengthen (or overturn) the verdict.

    Run your own prompt Submit run ↗
    Sources claude-opus-4-7 url ↗ GPT-5.5 Thinking url ↗ grok-xai no url View raw submissions ↗

Stage

Preview of the Phase-3 maturity framework. DeFiPunk'd will adopt DeFiScan v2's stages verbatim; the section is rendered below in its intended shape so the structure is visible today.

Nexus Mutual has not yet been assessed under the DeFiScan v2 stage framework.
The walkaway test is the central criterion. Once stages land, protocols reach Stage 1 only if users can exit in the presence of malicious operators even when the emergency council disappears.
Scope of assessment
Stages are assessed per-protocol against DeFiScan v2's criteria: governance structure, upgradeability path, timelock durations, emergency-council scope, and the walkaway test. The analysis depends on onchain discovery (roles, owners, timelocks) and deeper review of deployed contracts — neither of which DeFiPunk'd automates at Phase 0.
Stage 0 requirements pending
Governance is largely off-chain, contracts are upgradeable with short or no timelock, and the protocol depends on a multisig or team with full discretion. At Phase 0 DeFiPunk'd does not automatically evaluate these; the assessment lands with crawler-based onchain discovery.
Stage 1 requirements pending
Users can exit or opt out on their own terms even if the team disappears. Upgrades run through a meaningful timelock with an emergency security council clearly scoped. The walkaway test is the headline criterion.
Stage 2 requirements pending
Protocol is fully permissionless and immutable, or upgrades require a supermajority of token holders with a long timelock and no emergency override. This is the terminal stage of the DeFiScan v2 framework.
Learn more about DeFiScan v2 stages →
Stages are an opinionated assessment of maturity, not a rating of security or safety. A protocol can sit at Stage 2 and still carry substantial technical or economic risk; the framework exists to incentivize decentralization, not to rank protocols.

Contract surface

Every contract in scope for this protocol — pooled from DeFiLlama's TVL adapter (mechanical) and DEFI@home discovery submissions (LLM-curated). Verified-source flags come from Etherscan + Sourcify; owner / multisig metadata is read on-chain when available. Reviewer audit context, not a slice score. A lending protocol's adapter set will list third-party collateral tokens alongside its own contracts; attribution is the grader's job.

  • 8addresses
  • 1verified source
  • 1proxies

TVL adapter pinned at 683d369. Sourcecode fetched 2026-05-06. Control fetched 2026-05-14.

ethereumOwnedUpgradeabilityProxy0x01bf…d07eTVL + discproxy
Ethereummultisig0x055c…3926discoverymultisig
Ethereumother0x27e6…2e5fdiscovery
Ethereumother0x8131…6139discovery
Ethereumpool0xfd61…1884discovery
Ethereumproxy0x84ed…272fdiscovery
Ethereumtoken0xd7c4…cf3bdiscoverytoken
Ethereumtreasury0x586b…86e9discoverymultisig

Protocol Info

Links

[defillama] Source: DeFiLlama [:] Source: DEFI@home quorum
Twitter
@NexusMutual

Security

[:] Source: DEFI@home quorum
Audits
16 audits
Security contact
https://docs.nexusmutual.io/resources/audits-and-security/

Technical

[:] Source: DEFI@home quorum
Voting token
NXM Ethereum: 0xd7c49CEE7E9188cCa6AD8FF264C1DA2e69D4Cf3B
Deployed contracts
https://sdk.nexusmutual.io
Upgradeability
Mixed (some immutable, some upgradeable)

Provenance

[defillama] Source: DeFiLlama
Review status
listed
Updated
2026-06-01 11:27 UTC