DeFiPunk'd

EigenCloud

Restaking

TVL $5.8B
Type Restaking
Chain Ethereum
View on DeFiLlama ↗
Control criteria
Upgradeability Upgradeable Bug bounty docs.eigencloud.xyz Governance forum forum.eigenlayer.xyz Docs docs.eigencloud.xyz
About

EigenLayer, now presented under EigenCloud, lets users restake native ETH, EIGEN, LSTs and other supported ERC-20 assets to secure AVSs. Restakers deposit assets, delegate to operators, and later queue and complete withdrawals after an escrow delay. The distinctive mechanism is reusable slashable stake: AVSs can attach economic penalties and rewards to operators backed by restaked user assets.

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 18 addresses on file · 1 run Submit run ↗
  • Verifiability ✓ 4/4 models agree AI-only weak green — weak consensus margin Submit run ↗
  • Control ✓ 3/3 models agree AI-only weak orange — total support weight 1.23 below confidence floor (1.5) Submit run ↗
  • Ability to exit ✓ 5/5 models agree AI-only weak orange — weak consensus margin; total support weight 1.45 below confidence floor (1.5) Submit run ↗
  • Autonomy ✓ 3/3 models agree AI-only weak green — weak consensus margin Submit run ↗
  • Open Access ✓ 3/3 models agree AI-only weak green — total support weight 1.09 below confidence floor (1.5) Submit run ↗
  • Audit all 5 dimensions · one prompt Submit run ↗
  1. Verifiability tentative 4/4 models agree AI-only 3/4 with chat share link
    All core proxies and implementations verified on Etherscan via defipunkd ABI source 'etherscan'; public Layr-Labs/eigenlayer-contracts repo with version-pinned releases; multiple audits by recognized firms (Sigma Prime, Certora, Consensys Diligence).
    Verdict

    Choosing green because the rubric's green conditions are all satisfied: deployed bytecode is verified on Etherscan (proxy AND implementation per defipunkd's auto-resolution), a public source repo exists whose contents correspond to the explorer-visible source with version tags, and at least one audit from a recognized firm covers the protocol's currently-deployed contracts within a reasonable window (Certora's continuous engagement on slashing improvements; Sigma Prime's repeated engagements). Drift specifics for v1.12.0 vs the most recent in-scope public audit are not enumerated this run but recorded in unknowns[] per rubric guidance ('drift downgrades only when changes are material to fund-custody/settlement and no later audit covers the delta — when not sampled, record as unknown rather than auto-downgrade').

    Steelman argument
    Steelman argument All inspected proxies and implementations are verified on Etherscan; the public Layr-Labs repo corresponds to the deployed source with version tags pinned per the README; multiple audits from top-tier recognized firms (Sigma Prime, Certora, Consensys Diligence) cover the protocol; active Certora CI workflows and recent fix commits show continuous formal-verification engagement.
    Evidence (6)
    V1
    Defipunkd's /api/contract/abi for each inspected proxy returned 'abiSource: etherscan' (or 'sourcify' for the Operations Multisig and Executor Multisig Safe proxies), indicating bytecode verification. Proxies inspected: Community Multisig (Safe v1.3.0, GnosisSafeProxy verified, singleton 0xd9Db2...552 verified), Timelock 0xC06F...Aa2d (verified directly, no proxy), StrategyManager (TransparentUpgradeableProxy verified, impl 0x88582996...d394), DelegationManager (TUP verified, impl 0xE7022a12...Ce75), PauserRegistry 0xB876...806 (verified directly). For the Pauser/Executor/Operations Safes, the surfacer returned a bare 2-entry GnosisSafeProxy ABI, but the Safe singleton itself (0xd9Db2...552) was independently verified during the Community Multisig inspection.
    V2
    Public source repository at github.com/Layr-Labs/eigenlayer-contracts contains the deployed core contracts; README documents the Mainnet Ethereum deployment as v1.12.0 and links each contract to its tag-pinned source (DelegationManager → v1.6.0 source, StrategyManager → v1.12.0 source, EigenPodManager → v1.6.0 source, RewardsCoordinator → v1.12.0 source, AVSDirectory → v1.3.0 source, AllocationManager → v1.6.0 source, PermissionController → v1.3.0 source, EmissionsController → v1.12.0 source). The repo structure and the explorer-visible Solidity source match in file organization (one contract per file). Independent compile/bytecode-match not performed this run.
    V3
    Audit firms identified via the official audits page (https://docs.eigencloud.xyz/eigenlayer/security/audits): Sigma Prime and Certora named. Sigma Prime public-audits repo (github.com/sigp/public-audits) hosts EigenLayer Slashing Security Assessment Report v2.0. Certora published 'EigenLayer PEPE' report dated 2024-07 to 2024-08 covering EigenPod, EigenPodManager, and supporting libraries. Earlier audits include Consensys Diligence (2023) and a Code4rena contest (2023-04). Multiple audits exist; the most recent on-chain deployments (v1.12.0, v1.6.0) post-date the public 2024 audits — drift assessment in V5 below.
    V4
    Sigma Prime ✓ recognized (on the slice's recognized-firms list). Certora ✓ recognized (formal verification, explicitly named on the recognized list). Consensys Diligence ✓ recognized. All audit firms cited are top-tier.
    V5
    Post-audit drift: Mainnet is on v1.12.0; the 2024 Certora PEPE audit covered EigenPod/EigenPodManager at an earlier commit. The Sigma Prime Slashing audit covered an earlier slashing release. Subsequent versions (v1.6.0 → v1.12.0) include changes for Pectra hardfork compatibility (per HackMD audit handbook found in search), multichain extensions (CrossChainRegistry, OperatorTableUpdater), and additional features. Active Certora CI workflow runs and recent PR merges (e.g., 'fix: address Certora audit findings for Slashing UX Improvements') suggest continuous formal-verification engagement. Specific diff sampling for v1.12.0 vs the most recent in-scope audit commit not performed this run; recording in unknowns[].
    V6
    For each inspected TransparentUpgradeableProxy, the defipunkd surfacer auto-resolved the proxy and rendered the merged implementation ABI (e.g., StrategyManager surfacer showed both the proxy admin functions AND the implementation's depositIntoStrategy, owner, pauserRegistry, version=1.12.0 — confirming the implementation contract at 0x88582996...d394 is independently verified). DelegationManager similarly resolved to implementation 0xE7022a12...Ce75 with version 1.9.0. Both proxy AND implementation are verified.
    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 ↗ claude-sonnet-4-6 (autorun) no url gpt-5.5-thinking url ↗ grok-4 url ↗ View raw submissions ↗
  2. Control tentative 3/3 models agree AI-only 3/3 with chat share link
    T1 upgrade reachable via 10-day timelock proposed by 3-of-5 (Protocol Council) or 3-of-6 (Operations) multisig — delay clears 7 days, but proposing multisig fails Security Council size criterion.
    Verdict

    Choosing orange because the 10-day timelock (verified on-chain at getMinDelay=864000s) clears the 7-day green bar on delay alone, but the multisigs that sit on the T1 upgrade path (Protocol Council 3-of-5, Operations Multisig 3-of-6) explicitly fail the Security Council size criterion (≥7 signers) — the rubric calls this exact configuration orange ('a multisig failing one or more Security Council criteria sits on a T1/T2 path'). The Community Multisig (9-of-13) does pass on size/threshold but is positioned as emergency governance, and signer non-insider status was not verified on-chain this run; the routine T1 upgrade path operates through the smaller multisigs.

    Steelman argument
    Steelman argument The proposing multisigs that sit on the T1 upgrade path (Protocol Council 3-of-5, Operations 3-of-6) fail the Security Council size criterion (<7 signers), even though the 10-day timelock comfortably clears the 7-day exit-window bar — per the rubric this configuration is explicitly orange.
    Evidence (7)
    C1
    StrategyManager proxy owner() returns 0x369e6F597e22EaB55fFb173C6d9cD234BD699111 (Executor Multisig). DelegationManager has no owner() (pause-guarded only). Both are TransparentUpgradeableProxy with admin set to OZ ProxyAdmin 0x8b9566AdA63B64d1E1dcF1418b43fd1433b72444 per README deployment table.
    C2
    Upgradeability: TransparentUpgradeableProxy@OZ-4.7.1/4.9.0 for core (StrategyManager, DelegationManager, EigenPodManager, AVSDirectory, AllocationManager, RewardsCoordinator, PermissionController, EmissionsController). ProxyAdmin (0x8b9566AdA...) is the upgrade authority and is itself a smart contract gated by the Timelock per the published architecture.
    C3
    Uncontested fast path: Proposer multisig (Protocol Council 3-of-5 or Operations Multisig) → schedule() to TimelockController 0xC06Fd4F821eaC1fF1ae8067b36342899b57BAa2d (getMinDelay = 864000s = 10 days, read on-chain at block 25231788) → execute() by Executor Multisig 0x369e6F597e22EaB55fFb173C6d9cD234BD699111 → ProxyAdmin.upgrade(). Total uncontested delay: 10 days.
    C4
    Multisigs (per README and on-chain reads): Community Multisig 0xFEA47018D632A77bA579846c840d5706705Dc598 verified on-chain as 9-of-13 (getThreshold=9, getOwners returned 13 addresses, block 25231788). Pauser Multisig 0x5050389572f2d220ad927CcbeA0D406831012390 (per address_book and protocol blog: 1-of-9 emergency pause only). Executor Multisig 0x369e6F597e22EaB55fFb173C6d9cD234BD699111 (unpauser per PauserRegistry). Operations Multisig 0xBE1685C81aA44FF9FB319dD389addd9374383e90 (per address_book: 3-of-6). Protocol Council Multisig 0x461854d84ee845f905e0ecf6c288ddeeb4a9533f (per Eigen Foundation technical architecture: 3-of-5; 2 Eigen Foundation + 3 external). Signer identities and insider/non-insider classification not independently verified this run for the routine-upgrade proposers.
    C5
    No on-chain Governor / GovernorBravo / OZ Governor / Aragon Voting contract is part of the core architecture; governance is multisig-and-timelock. EIGEN token (0xec53bf9167f50cdeb3ae105f56099aaab9061f83) holders do not directly vote on upgrades on-chain at present.
    C6
    Emergency powers: Pauser Multisig (1-of-9) holds PAUSER role via PauserRegistry 0xB8765ed72235d279c3Fb53936E4606db0Ef12806 (unpauser() = 0x369e...111 verified on-chain). Pauser can call pause()/pauseAll() on core contracts without timelock; unpause requires Executor and is governance-gated. No on-chain MAX_PAUSE_DURATION constant in the contracts read this run.
    C7
    Highest reachable tier on the fast path: T1. The ProxyAdmin can upgradeAndCall() the implementation of fund-holding contracts (StrategyManager, DelegationManager, EigenPodManager) — replacing implementation can change accounting, fund flow, or drain user funds. Bound by the 10-day timelock delay on the schedule→execute path.
    Why is this consensus tentative?
    • total support weight 1.23 below confidence floor (1.5)

    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-4 url ↗ View raw submissions ↗
  3. Ability to exit tentative 5/5 models agree AI-only 3/5 with chat share link
    Permissionless 14-day queued withdrawal, but 1-of-9 Pauser can pause both queueWithdrawals and completeQueuedWithdrawal indefinitely (no on-chain time cap); unpause requires Executor.
    Verdict

    Choosing orange because the exit primitives are themselves permissionless (queueWithdrawals + completeQueuedWithdrawal callable by anyone with no admin signature, no frontend lock-in) but the contracts contain a pause framework gated by a 1-of-9 emergency Pauser with no on-chain time cap and (to the extent verified) no exemption for claims of already-finalized withdrawals — that defeats green. The literal red trigger ('pause held by a single EOA / 2-of-3 multisig with no time cap') doesn't apply because Pauser is 1-of-9, and the unpauser is the more robust Executor Multisig (governance-gated). The orange branch ('pausable with broad scope OR claims-of-finalized are exempt but new-request placement can be paused indefinitely by governance') fits best given the documented emergency-only scope and the separation between pause and unpause roles.

    Steelman argument
    Steelman argument The 1-of-9 emergency pauser sits below the green bar (no time cap, broad scope) but above the literal red trigger (the rubric reserves red for 'single EOA / 2-of-3 multisig with no time cap'); the unpause is held by a separate, governance-gated Executor; the 14-day queue means stakers know about the exit pipeline well in advance; in normal operation exit is permissionless.
    Evidence (7)
    E1
    User-facing exit functions read from DelegationManager (0x39053D...37A) ABI: queueWithdrawals((address[],uint256[],address)[]), completeQueuedWithdrawal((tuple),address[],bool), completeQueuedWithdrawals((tuple)[],address[][],bool[]), undelegate(address), redelegate(address,(bytes,uint256),bytes32). StrategyManager (0x858646...75A) exposes withdrawSharesAsTokens(address,address,address,uint256) (DelegationManager-only callable) and removeDepositShares (DelegationManager-only callable). EigenPodManager handles native ETH restaking exits via beacon chain proofs (not enumerated this run).
    E2
    Both queueWithdrawals (new-request placement) and completeQueuedWithdrawal (claim of finalized exit after 14-day wait) are gated by the contract's paused() / paused(uint8) state, which is managed through pauserRegistry. The two operations share the same pause framework — the ABI exposes pause(uint256) and pauseAll() write functions on DelegationManager.
    E3
    PauserRegistry 0xB8765e...2806 unpauser() = 0x369e6F597e22EaB55fFb173C6d9cD234BD699111 (Executor Multisig) verified on-chain. Pauser set (those for whom isPauser==true) and exact pause-bit-to-function mapping not enumerated in this run — hasRole/isPauser reads were not all run. No PAUSE_INFINITELY constant or MAX_PAUSE_DURATION constant present in the read ABI; pauses persist until unpaused.
    E4
    Emergency vs governance pause: Per protocol blog and address_book, the Pauser Multisig 0x5050389572... is a 1-of-9 (any single signer can pause for emergencies). The Executor Multisig is the unpauser and is governance-gated (typically operating through the 10-day Timelock for unpause and other governance actions). Direct 1-of-9 threshold not re-read on-chain this run (defipunkd surfacer did not merge Safe singleton ABI for this address).
    E5
    Queued redemption: minWithdrawalDelayBlocks = 100800 (verified on-chain on DelegationManager, block 25045790) — at 12s/block this is ~14 days. No daily withdrawal cap in the read ABI. The queue itself is pausable (queueWithdrawals is pause-guarded).
    E6
    No on-chain forced-exit / escape-hatch / permissionless emergency-exit mechanism is present in the read ABIs. Exit is permissionless in steady state but depends on contract state not being paused.
    E7
    All exit functions (queueWithdrawals, completeQueuedWithdrawal, undelegate, redelegate) are directly callable on-chain via Etherscan Write Contract tab or any wallet — no frontend dependency.
    Why is this consensus tentative?
    • weak consensus margin
    • total support weight 1.45 below confidence floor (1.5)

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

    Run your own prompt Submit run ↗
    Sources claude-opus-4-7 url ↗ claude-sonnet-4-6 (autorun) no url grok-4 url ↗ gpt-5.5-thinking url ↗ claude-sonnet-4-5 (autorun) no url View raw submissions ↗
  4. Autonomy tentative 3/3 models agree AI-only 3/3 with chat share link
    Core restaking has no external oracle / price-feed dependency, no bridge dependency for principal, and per-strategy isolation of underlying-asset risk — impacted TVS from any single external dependency failure: effectively 0.
    Verdict

    Choosing green because the A1–A9 inspection of DelegationManager and StrategyManager ABIs shows no external oracle/price-feed calls, no required off-chain committee to mint/burn shares, no bridge carrying user principal off-chain, and per-strategy isolation of underlying-asset risk. The Stage 2 anchor fits: failure of any single external dependency cannot cause loss of user principal in core restaking. AVS-level risk is opt-in per operator delegation (users choose which operators, who choose which AVSs to opt into) — outside core principal scope. The 14-day withdrawal queue further bounds exposure.

    Steelman argument
    Steelman argument Core restaking has no on-chain oracle dependency, no required off-chain committee for principal accounting, no bridge dependency for user principal (mainnet-only deposits), and per-strategy isolation prevents cross-market contagion — failure of any single external system the protocol touches cannot cause loss of principal for stakers in other markets.
    Evidence (9)
    A1
    No external oracle / price feed / AMM read in core contract ABIs. DelegationManager ABI (102 entries) and StrategyManager ABI (84 entries) read this run contain no calls to Chainlink/Pyth/Redstone interfaces, no latestAnswer/latestRoundData/getPrice methods, and no AggregatorV3 imports surfaced. Strategy shares are tracked in protocol-native accounting; conversion to underlying tokens is internal to each Strategy contract.
    A2
    No off-chain oracle committee reporting INTO core; restaking does not require off-chain valuation. For native ETH restaking via EigenPods, validator behavior is the substrate (Ethereum PoS) — per the rubric, this is NOT counted as an external dependency when operator diversity is broad; node operators are user-chosen per delegation and slashing is opt-in. AVS off-chain committees report into AVS-specific contracts, not into core restaking principal accounting.
    A3
    Cross-chain dependencies: EigenLayer's multichain protocol (CrossChainRegistry, OperatorTableUpdater, ECDSACertificateVerifier, BN254CertificateVerifier) transports AVS stake metadata from Ethereum (source) to Base (destination) for AVS verification. User principal stays on Ethereum mainnet — Base is destination-only for task verification, not for staking. No material TVL of user principal sits on a non-canonical bridge for this protocol.
    A4
    Underlying collateral risk: EigenLayer wraps third-party LSTs (stETH, rETH, cbETH, ETHx, ankrETH, OETH, osETH, swETH, wBETH, sfrxETH, lsETH, mETH) and the protocol's own EIGEN/bEIGEN into per-strategy isolated contracts. A failure of any one LST does NOT propagate to stakers in other LST strategies — risk is per-market opt-in. Per the rubric carve-out, this is not autonomy-red on its own.
    A5
    Fork lineage: EigenLayer is original protocol design (pioneer of restaking primitive); no forkedFrom relationship.
    A6
    Fallback / circuit breaker: The 14-day withdrawal queue (minWithdrawalDelayBlocks=100800, verified on-chain) acts as an extended exit window allowing users to react before any external counterparty's failure plays out. PauserRegistry exists for emergency pause (LIVE, in (i) activation state). No second-opinion oracle is required because no oracle is consulted.
    A7
    Sequencer / L1-liveness: EigenLayer is deployed on Ethereum mainnet (substrate, not A7 dependency). Base deployment is destination-only for AVS verification — Base sequencer failure would impact AVS verification on Base but not principal on Ethereum.
    A8
    Keeper / relayer / off-chain bot liveness: Users themselves call queueWithdrawals and completeQueuedWithdrawal — no keeper required to advance withdrawals. AVS-specific keepers exist within AVS contracts but are separate from core restaking principal flow.
    A9
    Governance-mutable dependency surface: The PauserRegistry can have its isPauser set changed by the unpauser. The proxy admin can upgrade any core contract implementation. However, A9 specifically asks whether governance can introduce a NEW EXTERNAL dependency without timelock. Core staking has no external dependency to introduce — strategies are per-asset and opt-in; users self-select which strategies to deposit into. The 10-day timelock guards core upgrades, giving stakers an exit window.
    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 ↗ grok-4 url ↗ gpt-5.5-thinking url ↗ View raw submissions ↗
  5. Open Access tentative 3/3 models agree AI-only 3/3 with chat share link
    depositIntoStrategy, queueWithdrawals, completeQueuedWithdrawal all permissionless on-chain; no contract-level KYC/whitelist on users; ecosystem of LRTs and third-party frontends provides multiple independent access paths.
    Verdict

    Choosing green because contracts are fully permissionless on user entry/exit (no whitelist, no KYC, no operator-approval-to-admit), independent access paths are abundant (public repo, LRT protocols, direct contract interaction), and per the rubric default 'when contracts are fully permissionless AND any A3b independent path exists, the default grade is green regardless of frontend ToS or A3-active enforcement on the official UI'. Frontend ToS posture is not the grade lever.

    Steelman argument
    Steelman argument Core contracts admit users unconditionally with no contract-level KYC, no on-chain sanctions check, no operator-approval requirement; multiple independent access paths exist (public source repo with integration tests, ecosystem of LRT protocols, direct Etherscan interaction); the rubric default for this profile is green.
    Evidence (7)
    A1
    No whitelist/allowlist modifier on user-facing entry points in the read ABIs. depositIntoStrategy(address strategy, address token, uint256 amount), depositIntoStrategyWithSignature(...), queueWithdrawals(...), completeQueuedWithdrawal(...), delegateTo(...), undelegate(...) are all callable without isKYCed/isAccredited/onlyWhitelisted checks. Strategy whitelisting on StrategyManager applies to which strategies can accept deposits, not to which users can deposit (anyone deploying a strategy via the permissionless StrategyFactory automatically gets it whitelisted per the README's 'Anyone can deploy and whitelist strategies for standard ERC20s by using the StrategyFactory').
    A2
    No off-chain operator approval required to admit a user deposit/withdrawal. The Pauser Multisig can pause but does not gate individual user admissions. No 'admit user' role found in the surfaced ABIs.
    A3
    Frontend ToS at https://docs.eigencloud.xyz/products/eigenlayer/legal/terms-of-service — direct fetch blocked by docs site bot protection this run. Frontend ToS posture is reported as context only and does not move the grade.
    A3b
    Independent access paths exist: (i) direct contract interaction via Etherscan Write tab on each proxy address; (ii) the public github.com/Layr-Labs/eigenlayer-contracts repo provides scripts and integration tests for SDK-style access; (iii) a large ecosystem of LRT protocols (Renzo, EtherFi, Puffer, KelpDAO, Swell, etc.) integrates with EigenLayer permissionlessly and routes user deposits through the core contracts — each is operated by a separate legal entity. Independent path existence is not in doubt.
    A4
    No on-chain sanctions / blocklist checks in core ABIs. PermissionController (0x25E5F8...0E5) per README is for UAM delegation (operator → admin permissioning), not user sanctions screening.
    A5
    Read access is permissionless (view methods are public on all proxies inspected). Write access: user-facing functions (deposit, queue, complete, delegate, undelegate) are public; operator-only / DelegationManager-only / AllocationManager-only functions exist for cross-contract calls per OnlyDelegationManager/OnlyEigenPodManager/OnlyAllocationManager errors — these are internal-coordination access controls, not user-admission controls.
    A6
    Verbatim ToS quote could not be extracted this run — docs.eigencloud.xyz returned bot-detection block. ToS URL recorded in unknowns[].
    Why is this consensus tentative?
    • total support weight 1.09 below confidence floor (1.5)

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

    Run your own prompt Submit run ↗
    Sources claude-opus-4-7 url ↗ grok-4 url ↗ gpt-5.5-thinking 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.

EigenCloud 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.

  • 17addresses
  • 3verified source
  • 3proxies
  • 2of 2 owners are Safes

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

ethereumTransparentUpgradeableProxy0xec53…1f83TVL + discproxy0x369e…91111/2 Safe
ethereumnull0x0000…0000TVL
ethereumTransparentUpgradeableProxy0x83e9…6e75TVLproxy0x369e…91111/2 Safe
ethereumTransparentUpgradeableProxy0xacb5…d8f7TVLproxy
Ethereumguardian (Pauser Multisig — 1-of-9, emergency pause only)0x5050…2390discoverymultisig
Ethereummultisig (Community Multisig — 9-of-13 emergency governance)0xfea4…c598discoverymultisig
Ethereummultisig (Executor Multisig — automated execution role only)0x369e…9111discoverymultisig
Ethereummultisig (Operations Multisig — 3-of-6, routine upgrades via timelock)0xbe16…3e90discoverymultisig
Ethereumpool (AllocationManager proxy — slashing/operator set allocation)0x948a…bc39discovery
Ethereumpool (AVSDirectory proxy — AVS registration)0x135d…f5afdiscovery
Ethereumpool (DelegationManager proxy — delegation and withdrawal)0x3905…f37adiscovery
Ethereumpool (EigenPodManager proxy — native ETH restaking)0x91e6…a338discovery
Ethereumpool (PermissionController proxy — UAM delegation)0x25e5…f0e5discovery
Ethereumpool (RewardsCoordinator proxy — rewards distribution)0x7750…addadiscovery
Ethereumpool (StrategyManager proxy — primary entry/exit for LST restaking)0x8586…075adiscovery
Ethereumtimelock (bEIGEN token upgrade timelock)0x7381…bc53discoverytimelock
Ethereumtimelock (primary upgrade timelock — 10-day minimum delay)0xc06f…aa2ddiscoverytimelock

Protocol Info

Links

[defillama] Source: DeFiLlama [:] Source: DEFI@home quorum
Twitter
@eigencloud
Governance forum
https://forum.eigenlayer.xyz

Security

[:] Source: DEFI@home quorum
Audits
9 audits
Security contact
unknown

Technical

[:] Source: DEFI@home quorum
Voting token
EIGEN Ethereum: 0xec53bf9167f50cdeb3ae105f56099aaab9061f83
Upgradeability
Upgradeable

Provenance

[defillama] Source: DeFiLlama [:] Source: DEFI@home quorum
Review status
listed
Updated
2026-06-02 19:51 UTC