feat: transfer da ownership zeus scripts

.env.example

@@ -1,5 +1,3 @@
 RPC_MAINNET="https://eth.llamarpc.com"
-# RPC_MAINNET="https://mainnet.infura.io/v3/API-KEY"
-RPC_GOERLI="https://ethereum-goerli.publicnode.com"
 RPC_HOLESKY=""
 ETHERSCAN_API_KEY="API-KEY"

.github/workflows/automation.yml

@@ -5,21 +5,21 @@ on:
     types: [opened, edited, synchronize]
 
 jobs:
-  triage:
-    runs-on: protocol-x64-16core
-    name: Labels
-    permissions:
-      contents: read
-      pull-requests: write
+  # triage:
+  #   runs-on: protocol-x64-16core
+  #   name: Labels
+  #   permissions:
+  #     contents: read
+  #     pull-requests: write
 
-    steps:
-      - name: Checkout code
-        uses: actions/checkout@v4
+  #   steps:
+  #     - name: Checkout code
+  #       uses: actions/checkout@v4
 
-      - uses: actions/labeler@v5
-        with:
-          repo-token: "${{ secrets.GITHUB_TOKEN }}"
-          sync-labels: true
+  #     - uses: actions/labeler@v5
+  #       with:
+  #         repo-token: "${{ secrets.GITHUB_TOKEN }}"
+  #         sync-labels: true
 
   lint-pr-title:
     runs-on: ubuntu-latest

.github/workflows/foundry.yml

@@ -5,14 +5,11 @@ on:
   pull_request:
   push:
     branches:
-      - "dev"
+      - main
 
 
 env:
   FOUNDRY_PROFILE: medium
-  RPC_MAINNET: ${{ secrets.RPC_MAINNET }}
-  RPC_HOLESKY: ${{ secrets.RPC_HOLESKY }}
-  CHAIN_ID: ${{ secrets.CHAIN_ID }}
 
 jobs:
   # -----------------------------------------------------------------------
@@ -72,6 +69,7 @@ jobs:
           esac
         env:
           FOUNDRY_PROFILE: ${{ matrix.suite == 'Fork' && 'forktest' || 'medium' }}
+          RPC_MAINNET: https://billowing-capable-sound.quiknode.pro/
 
   # -----------------------------------------------------------------------
   # Forge Test (Intense)
@@ -80,8 +78,8 @@ jobs:
   continuous-fuzzing:
     name: Test (Intense)
     runs-on: protocol-x64-16core
-    # Only run on push events to dev branch, not on PR events
-    if: github.event_name == 'push' && github.ref == 'refs/heads/dev'
+    # Only run on push events to main branch, not on PR events
+    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
     strategy:
       fail-fast: true
     steps:
@@ -120,7 +118,7 @@ jobs:
           echo -e "\033[1;33mWarning: This workflow may take several hours to complete.\033[0m"
           echo -e "\033[1;33mThis intense fuzzing workflow is optional but helps catch edge cases through extended testing.\033[0m"
           FOUNDRY_PROFILE=intense forge test -vvv
-  
+
   # -----------------------------------------------------------------------
   # Forge Storage Diff
   # -----------------------------------------------------------------------
@@ -164,13 +162,15 @@ jobs:
   run-coverage:
     name: Coverage
     runs-on: protocol-x64-16core
-    # Only run coverage checks on dev, testnet-holesky, and mainnet branches, or PRs targeting these branches
+    # Only run coverage checks on main, preprod, testnet, and mainnet branches, or PRs targeting these branches
     if: |
-      github.ref == 'refs/heads/dev' ||
-      github.ref == 'refs/heads/testnet-holesky' ||
+      github.ref == 'refs/heads/main' ||
+      github.ref == 'refs/heads/preprod' ||
+      github.ref == 'refs/heads/testnet' ||
       github.ref == 'refs/heads/mainnet' ||
-      github.base_ref == 'dev' ||
-      github.base_ref == 'testnet-holesky' ||
+      github.base_ref == 'main' ||
+      github.base_ref == 'preprod' ||
+      github.base_ref == 'testnet' ||
       github.base_ref == 'mainnet'
     strategy:
       fail-fast: true

CONTRIBUTING.md

@@ -1,96 +1,144 @@
 # Contribution Guide
 
-Thank you for considering contributing to EigenLayer! To ensure a smooth and efficient collaboration, please adhere to the following guidelines when submitting a pull request (PR):
+Thank you for considering contributing to EigenLayer! This guide will help you set up your development environment and submit high-quality pull requests (PRs).
 
-## Requirements
+## Setting Up Your Environment
 
-- Foundry  
-- Git  
-- Node.js  
+### Requirements
 
-## Setup Repo
+- Foundry
+- Git
+- Node.js
+
+### Fork and Clone the Repository
+
+1. Fork the repository following [GitHub's instructions](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo)
+2. Clone your forked repository:
 
 ```bash
-git clone https://github.com/Layr-Labs/eigenlayer-contracts.git
+git clone https://github.com/<your_github_id>/eigenlayer-contracts.git
+cd eigenlayer-contracts
 ```
 
 ### Install Dependencies
 
+Set up your local development environment:
+
 ```bash
 npm install
 npx husky install
 forge install
 ```
 
-### Environment Variables
+### Run Tests
 
-Some of the tests and features of this repository require environment variables to be set up.
+Verify your setup by running the test suite:
 
-Copy the .env.example file to create a .env and populate it with the appropriate environment values that you have control over.
+```bash
+forge test
+```
 
-## Development Workflow
+Congratulations! You've successfully set up your repository and run the tests.
 
-- **Testing**: Ensure that your code is well-tested. Write unit and integration tests as appropriate.
-- **Branching**: Create a feature branch from the `dev` branch for your work. The `dev` branch contains the most up-to-date code for upcoming releases.
-- **Pull Requests**: Once your feature or fix is complete and tested, submit a PR to merge your feature branch into the `dev` branch.
-- **Code Review**: After your PR is approved, squash your commits into a single commit before merging to maintain a clean and concise commit history.
+## Submitting a Pull Request
 
-## Commit Message Format
+### Configure Remote Repositories
 
-When squashing and merging your commits, please follow the commit message convention below:
+All PRs should be submitted from your forked repository. Add the official EigenLayer repository as your upstream remote:
 
+```bash
+git remote add upstream https://github.com/Layr-Labs/eigenlayer-contracts.git
 ```
-<type>(<scope>): <subject> (#<PR number>)
 
-<motivation>
+Verify your configuration:
 
-<modifications>
+```bash
+git remote -v
+```
 
-<result>
+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)
 ```
 
-- **Type**: Indicates the nature of the change.
-- **Scope**: Specifies the section or module of the codebase affected (optional).
-- **Subject**: A brief description of the change.
-- **PR Number**: Reference to the pull request associated with this change.
-- **Motivation**: Describe the context and reason for the change.
-- **Modifications**: Detail the specific changes made.
-- **Result**: Explain the outcome or effects of the change.
+### Create Your PR
 
-### Example
+1. Create a new branch from your target upstream branch
+2. Make your code changes
+3. Commit your changes
+4. Push to your forked repository
+5. Create a PR from your branch to the appropriate branch in the upstream repository
 
-An example of a commit message:
+### PR Title Format
 
+Format your PR title as follows:
+
+```
+<type>: <subject>
 ```
-feat(StrategyManager): Implement new withdrawal flow (#123)
 
+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.
+
+### PR Description Template
+
+Use this template for your PR description:
+
+```markdown
 **Motivation:**
+- Describe the context and reason for the change
+
+**Modifications:**
+- Detail the specific changes made
+
+**Result:**
+- Explain the outcome or effects of the change
+```
+
+#### Example PR:
 
+```markdown
+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.
+- 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.
 ```
 
-### Commit Types
+## Testing and Continuous Integration
 
-Use the following types for your commit messages:
+- All PRs should include appropriate test coverage
+- Write unit and integration tests that verify your changes
+- Ensure all existing tests continue to pass
 
-- **feat**: A new feature.
-- **fix**: A bug fix.
-- **docs**: Documentation-only changes.
-- **style**: Changes that do not affect the meaning of the code (e.g., formatting).
-- **refactor**: A code change that neither fixes a bug nor adds a feature.
-- **perf**: A code change that improves performance.
-- **test**: Adding missing or correcting existing tests.
-- **chore**: Changes to the build process or auxiliary tools and libraries.
+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!
-

MAINTENANCE.md

@@ -0,0 +1,72 @@
+# Maintenance
+
+This document outlines basic procedures for maintenance of PRs, and releases that maintainers of the repository should follow.
+
+
+## Enrivonment Network
+
+Before getting into maintenance details, let's define environment network first.
+
+| Environment | Environment Network | Definition and Practices |
+|-------------|---------------------|--------------------------|
+| mainnet | mainnet-ethereum | - mainnet production env on Ethereum<br>- only one single mainnet in foreseeable future<br>- external facing |
+| testnet | testnet-holesky<br>testnet-sepolia<br>testnet-hoodi | - testnet envs on Ethereum testnets like holesky or sepolia<br>- can be 1 or more testnet env networks for EigenLayer<br>- external facing, long lived for both internal and external developers to test on |
+| preprod | preprod-holesky<br>preprod-sepolia<br>preprod-hoodi | - preprod envs on Ethereum testnets like holesky or sepolia<br>- can be 1 or more preprod env networks for EigenLayer<br>- long lived for internal development and testing, before moving to testnets |
+
+See blog [The Future of EigenLayer Testing: New & Improved Testnets & Tooling Coming Soon](https://www.blog.eigenlayer.xyz/the-future-of-eigenlayer-testing-new-and-improved-testnets-tooling-coming-soon/) for detailed motivation
+
+
+
+##  Development
+
+### Code Review
+
+Code reviewers take responsibility of making sure PRs are rigorously labeled, well formatted, well tested before merging them. 
+
+For first-time external contributors, a maintainer should review their PR carefully and then manually approve CI to run.
+
+
+### Branching Model
+
+#### Development Branches
+
+- `main (default)`: 
+    - The primary development and canonical branch where all new code are merged
+    - It should remain stable enough for internal and external testing, ensuring continuous integration (CI) runs smoothly on every commit
+    - Security audit will always happen on main by a given commit
+- `release-dev/xxx`:
+    - For large features with many commits that will be breaking changes and we want to all-or-none in `main`, maintainer should create a `release-dev/xxx` branch to develop on
+        - eg. release-dev/slashing-v1, release-dev/rewards-v2
+    - These branches branch off from `main` for development, should be constantly rebased to `main` to be compatible with canonical branch, and will be merged back into `main` when the development is done and ready to deploy
+    - release-dev branches should be merged into main for auditing, no auditing will be on release-dev branches
+
+
+### Merge PRs
+
+We classify PRs into two types:
+
+1. **Regular PRs** – Used for bug fixes, small changes, or incremental updates. Each PR is atomic itself.
+2. **Release-dev Merges** – Merging a release-dev branch into `main` after completing a major release. The release-dev branch and such a merge contains many regular PRs
+
+We use different merge rules for each PR type.
+
+- For regular PRs:  
+    - Always **rebase, squash, and merge**. Since multiple commits in a PR represent a single unit of work, merging them separately can be unnecessary or even break the code. Squashing ensures atomicity and keeps the commit history clean.
+    - demonstration: PR -> squash -> `main` or `release-dev`
+
+
+- For release-dev merges:
+    - Always **rebase and create a new commit to merge, never squash**
+    - All commit history should be preserved - a release-dev branch contains multiple independent units of work, and squashing would create a massive, monolithic commit that erases history, making it difficult to track and understand individual changes.
+    - The additional commit will act as a marker in `main` as end of a release-dev merge. With each release-dev merge having its own end marker, it will significantly simplify the cherry-picking process in release creation
+    - demonstration: `release-dev` -> merge -> `main`
+
+
+
+## Releases
+
+
+
+## Release Manager
+
+

README.md

@@ -62,7 +62,7 @@ We have a few fork tests against ETH mainnet. Passing these requires the environ
 
 Additionally, to run all tests in a forked environment, [install yq](https://mikefarah.gitbook.io/yq/v/v3.x/). Then, set up your environment by running the following command.
 
-`source bin/source-env.sh [goerli|local]`
+`source bin/source-env.sh [local]`
 
 Then run the tests: