- Total Prize Pool: $90,500 USDC
- HM awards: $56,250 USDC
- QA report awards: $7,500 USDC
- Gas report awards: $3,750 USDC
- Bot race awards: $7,500 USDC
- Judge awards: $9,000 USDC
- Lookout awards: $6,000 USDC
- Scout awards: $500 USDC
- Join C4 Discord to register
- Submit findings using the C4 form
- Read our guidelines for more details
- Starts April 27, 2023 20:00 UTC
- Ends May 04, 2023 20:00 UTC
Automated findings output for the contest can be found here.
Note for C4 wardens: Anything included in the automated findings output is considered a publicly known issue and is ineligible for awards.
EigenLayer has completed one security audit with Consensys Diligence and is currently concluding a second independent audit with Sigma Prime. We note that the scope for the Sigma Prime audit is expanded relative to the scope of this contest, and that the report provided here is in draft form, so it does not yet capture any mitigations taken by the team. All findings of the following audits are considered out-of-scope:
EigenLayer (formerly 'EigenLayr') is a set of smart contracts deployed on Ethereum that enable restaking of assets to secure new services. At present, this repository contains both the contracts for EigenLayer and a set of general "middleware" contracts, designed to be reuseable across different applications built on top of EigenLayer.
Note that the interactions between middleware and EigenLayer are not yet "set in stone", and may change somewhat prior to the platform being fully live on mainnet; in particular, payment architecture is likely to evolve. As such, the "middleware" contracts should not be treated as definitive, but merely as a helpful reference, at least until the architecture is more settled.
The EigenLayer whitepaper is available on our website, as well as introductory information and links to other documentation.
This repo contains our developer-oriented documentation; you can click the links in the Table of Contents below to access more specific documentation, or simply browse the /docs/ folder. We recommend starting with the EigenLayer Technical Specification to get a better overview before diving into any of the other docs.
Code4rena-specific note: The scope for this Code4rena contest is somewhat limited. We recommend reading through the contest scope section below before diving too deep into the specifics.
Design Docs
Flow Docs
- EigenLayer Withdrawal Flow
- EigenLayer Deposit Flow
- EigenLayer Delegation Flow
- Middleware Registration Flow for Operators
All files not listed above. Semi-complete list:
- src/contracts/interfaces/IDelegationTerms.sol
- src/contracts/interfaces/IVoteWeigher.sol
- src/contracts/interfaces/IPaymentManager.sol
- src/contracts/interfaces/IRegistry.sol
- src/contracts/interfaces/IQuorumRegistry.sol
- src/contracts/interfaces/IBLSPublicKeyCompendium.sol
- src/contracts/interfaces/IWhitelister.sol
- src/contracts/interfaces/IBLSRegistry.sol
- src/contracts/interfaces/IDelayedService.sol
- src/contracts/pods/BeaconChainOracle.sol
- src/contracts/libraries/BytesLib.sol
- src/contracts/libraries/MiddlewareUtils.sol
- src/contracts/libraries/StructuredLinkedList.sol
- src/contracts/libraries/BN254.sol
- src/contracts/strategies/StrategyWrapper.sol
- src/contracts/operators/MerkleDelegationTerms.sol
- src/contracts/core/Slasher.sol
- src/contracts/core/DelegationManager.sol
- src/contracts/core/DelegationManagerStorage.sol
- src/contracts/middleware/*
- src/test/*
- script/*
- certora/*
- If you have a public code repo, please share it here: https://github.com/Layr-Labs/eigenlayer-contracts/
- How many contracts are in scope?: 24
- Total SLoC for these contracts?: 1393
- How many external imports are there?: 10
- How many separate interfaces and struct definitions are there for the contracts within scope?: ~11 interfaces, ~10 structs
- Does most of your code generally use composition or inheritance?: Inheritance
- How many external calls?: 6
- What is the overall line coverage percentage provided by your tests?: 95
- Is there a need to understand a separate part of the codebase / get context in order to audit this part of the protocol?: true
- Please describe required context: We will be excluding some parts of the protocol from scope, but understanding their interfaces and/or broad purposes may still be necessary. We are also doing proofs against Beacon Chain state, so understanding the details of the Beacon Chain & Execution Layer will be very helpful.
- Does it use an oracle?: Others; Part of it is designed to interface with an oracle, but the exact details of the oracle are still TBD, and the oracle itself is considered out-of-scope. It is a custom oracle for bringing Beacon Chain roots to the Execution Layer (for proving against Beacon Chain state). The IBeaconChainOracle interface is included in the scope since the EigenPodManager will interact with this oracle for fetching state roots.
- Does the token conform to the ERC20 standard?: N/A
- Are there any novel or unique curve logic or mathematical models?: N/A
- Does it use a timelock function?: no
- Is it an NFT?: no
- Does it have an AMM?: no
- Is it a fork of a popular project?: false
- Does it use rollups?: no
- Is it multi-chain?: no
- Does it use a side-chain?: false
- Describe any specific areas you would like addressed. E.g. Please try to break XYZ.": We are most concerned with a loss of user funds.
We’re aiming to launch with a very conservative design, in which all withdrawals from the system have a minimal enforced delay; we can then respond to observations of any anomalous withdrawal behavior by pausing functionality and subsequently upgrading the contracts. As such, any method to defeat these safeguards (i.e. to avoid the enforced minimum withdrawal delay) would also be of significant concern.
We’re also quite concerned with privilege escalation or the compromise of trusted roles; our docs will provide more details on trusted roles and the design philosophy we’ve taken here.
Another more specific concern we have is ensuring the correctness of the native restaking flow, i.e. “EigenPods” and their related functionality. This is a rather complicated system with a lot of moving parts, and ensuring that our code accurately reflects the specification of the Consensus Layer is important.
This repository uses Foundry as a smart contract development toolchain.
See the Foundry Docs for more info on installation and usage.
foundryup
forge installPrior to running tests, you should set up your environment. At present this repository contains fork tests against ETH mainnet; your environment will need an RPC_MAINNET key to run these tests. See the .env.example file for an example -- two simple options are to copy the LlamaNodes RPC url to your env or use your own infura API key in the provided format.
The main command to run tests is:
forge test -vv
solhint 'src/contracts/**/*.sol'
slither .