Thank you for considering contributing to EigenLayer! This guide will help you set up your development environment and submit high-quality pull requests (PRs).
We use fork base PR mechanism. Contributions that do not follow our fork base PR practices will be automatically immediately closed and deleted, preventing branch pollution, keeping our repository clean, tidy, more readable and searchable.
- Fork the repository following GitHub's instructions
- Clone your forked repository:
git clone https://github.com/<your_github_id>/eigenlayer-contracts.git
cd eigenlayer-contracts
To set up this repo for the first time, run:
make deps
This will:
- Install the pre-commit hook
- Install foundry and its tools
- Install abigen
See the Foundry docs for more info on installation and usage of foundry. If you already have it, you can build this project with these commands:
foundryup
forge build
Verify your setup by running the test suite:
forge test
Congratulations! You've successfully set up your repository and run the tests.
We have a few fork tests against ETH mainnet. Passing these requires the environment variable RPC_MAINNET
to be set. See .env.example
for an example. Once you've set up your environment, forge test
should show these fork tests passing.
Additionally, to run all tests in a forked environment, install yq. Then, set up your environment by running the following command.
source bin/source-env.sh [local]
Then run the tests:
forge test --fork-url [RPC_URL]
- Install solhint, then run:
solhint 'src/contracts/**/*.sol'
- Install slither, then run:
slither .
- Install surya and graphviz:
npm i -g surya
apt install graphviz
- Then, run:
surya inheritance ./src/contracts/**/*.sol | dot -Tpng > InheritanceGraph.png
surya mdreport surya_report.md ./src/contracts/**/*.sol
make bindings
To update the storage reports in /docs/storage-report
run:
make storage-report
All PRs should be submitted from your forked repository. Add the official EigenLayer repository as your upstream remote:
git remote add upstream https://github.com/Layr-Labs/eigenlayer-contracts.git
Verify your configuration:
git remote -v
You should see:
origin https://github.com/<your_github_id>/eigenlayer-contracts.git (fetch)
origin https://github.com/<your_github_id>/eigenlayer-contracts.git (push)
upstream https://github.com/Layr-Labs/eigenlayer-contracts.git (fetch)
upstream https://github.com/Layr-Labs/eigenlayer-contracts.git (push)
The following applies if you submit a PR to upstream branch of either main
or release-dev/*
, which will refer to as <upstream-target-branch>
Create a local branch from the upstream branch:
git checkout -B <my-local-feature-branch> upstream/<upstream-target-branch>
Make your changes, then commit:
git add .
git commit -m "your message"
Push to your fork:
git push -u origin <my-local-feature-branch>
Go to GitHub, and open a PR from:
your-fork:<my-local-feature-branch>
**to**
Layr-Labs/eigenlayer-contracts:<upstream-target-branch>
GitHub should auto-detect this if branches match.
If you already have an open PR for this branch, just push more commits to <my-local-feature-branch>
, and the PR will update.
To stay in sync with upstream's <upstream-target-branch>
, whether it's main
or release-dev/*
:
git fetch upstream
git checkout <my-local-feature-branch>
git rebase upstream/<upstream-target-branch>
# or use merge if you prefer
# git merge upstream/<upstream-target-branch>
git push -f origin <my-local-feature-branch>
Use --force only if you're rebasing (not with merges).
Format your PR title as follows:
<type>: <subject>
Where:
- Type: Indicates the nature of the change
- Subject: A brief description of the change
Use one of these types:
Type | Description |
---|---|
feat | A new feature |
fix | A bug fix |
docs | Documentation-only changes |
style | Changes that don't affect code meaning (formatting) |
refactor | Code changes that neither fix bugs nor add features |
ci | Changes to continuous integration configuration |
perf | Performance improvements |
test | Adding or correcting tests |
chore | Changes to build process or auxiliary tools |
release | Merging a release-dev branch to main |
Remember to set the appropriate PR label as well.
Use this template for your PR description:
**Motivation:**
- Describe the context and reason for the change
**Modifications:**
- Detail the specific changes made
**Result:**
- Explain the outcome or effects of the change
feat: Implement new withdrawal flow in StrategyManager
**Motivation:**
The current withdrawal process is inefficient and leads to delays for users.
**Modifications:**
- Refactored the `withdraw` function in `StrategyManager.sol`
- Updated associated unit tests to reflect changes
- Modified documentation to explain the new withdrawal process
**Result:**
The withdrawal process is now more efficient, reducing wait times for users.
- All PRs should include appropriate test coverage
- Write unit and integration tests that verify your changes
- Ensure all existing tests continue to pass
For first-time external contributors: A maintainer will review your PR and manually approve CI to run.
By following these guidelines, you help maintain the quality and readability of the EigenLayer codebase. We appreciate your contributions and look forward to collaborating with you!