This Request for Proposal was created by Madhur Shrimal and Ishaan. We welcome your thoughts, questions, collaborations, and proposals in the comments.
Problem Statement
Currently every AVS has their own registration CLI which lives in the AVS repo. EigenLayer CLI is just responsible for registering on EigenLayer. Every operator has to use a different AVS CLI to register their operator. There are few problems:
- Operators will have to download multiple binaries to register new AVSs.
- Operators are at the mercy of AVS for implementing remote signers and might not run an AVS if they are very security focused.
- Operators will have to share their ECDSA private key with AVS.
Proposed Solution, Requirements & Design Considerations
1. What is the idea? What’s the issue or challenge that needs to be addressed?
Goals
- Operators can use the EigenLayer CLI for AVS registration
Constraints
- Design should be flexible enough for other AVS to add their onchain interaction and offchain code
- Operator keys should be securely used for the process
Why?
- All AVS do not support remote signers (and enforcing them to implement a particular signer is painful) and operators don’t want to share their keys with them. EigenLayer CLI implements remote signers which can be re-used for this.
- One CLI to register to AVS - this will drive some standardization for operators
Why is it not trivial? It’s because all AVS have a different way of registering.
For example:
- EigenDA requires signature from churner and also BLS key signature
- Some other AVS might require another signature or a different business logic for registration
2. Graphic of the proposed architecture
3. Who will be the users of the idea?
Operators that want to run multiple AVSs.
4. Properties of the complete idea: details about what the proposed solution should include or accomplish and key factors that should be taken into account.
- Clear design specifications
a. How the design work with registration of multiple AVS
b. How will the implementation work - Customizable to be used by multiple AVS for their registration
a. How will an AVS define their registration specification
b. Where will an AVS plug-in the code - Robust Code
a. Proper error handling of invalid inputs
b. It should not have any obvious bugs
c. It should log helpful statements for the users to debug any issues
d. It should support private key hex, local keystore, fireblocks and web3 signer support from the CLI - Clear documentation of codebase
a. There should be enough documentation of what the code is doing
b. Documentation showing how to use the implemented commands - Clean documentation of how an AVS would implement this.
a. Example files and code on how AVS can implement it. - Adequate testing of newly added functionality
a. Unit test for testing happy and error use cases
b. Integration testing using local anvil chain - Support for testnet and mainnet AVS registration
5. Call-to-action: a list of tasks and duties that the proposer will need to accomplish.
- A clear specification of how an AVS will integrate their custom off-chain code and call to AVS Service Manager contract
- The codebase which understand the spec and call the business logic using EigenLayer CLI (EigenLayer CLI supports remote signers so it should be compatible with that)
- Granular CLI commands with documentation
a. AVS registration
b. Check Registration Status - Examples demonstrating successful registration of 2+ AVSs using supported signers
- A recording of the demo registering an operator to AVSs
a. The recording should show registration process of at least 2 AVS
b. The recording show show registration via local keystore and Web3 signer
6. How is this idea similar or different from existing designs, and why is it better?
Currently there are no existing solutions like this.
Submission Process & FAQ
1. How will an idea be evaluated and chosen?
- We expect design docs to be submitted from the community and based on that, we will evaluate the design and choose who we would like to move ahead to build this RFP.
- We also expect the community to include a timeline, specifying their intention to maintain the code afterwards.
2. Who can submit an idea?
We encourage all community individual contributors, engineers, and teams building this idea. Though it is likely that people/teams with backgrounds with Golang would be a good fit (not a necessary condition).
3. What is the submission format? Guidelines for how proposals should be structured and what information they should contain.
- A public design document shared by replying to this forum post
- Once our team sees the design doc and approves it, you can start contributing your code to the EigenLayer CLI
- Code submitted to the EigenLayer CLI repo will be reviewed and approved by EigenFoundation or a designee contributor.
- The complete project means that the design is approved and code is implemented, approved and works for at least 2 AVS registration
4. What’s the timeline for this RFP submission process?
- We expect the design doc to be finished with the review period from us within 4 weeks. Please submit your design doc by November 29th.
- We expect the implementation to be finished within 8 weeks after the design doc has been approved. We expect this to be a project that can be completed by one person working on it full time for 6 weeks or part time for 8 weeks.
5. What if my proposal does not fully meet the requirements?
Our team will give feedback on proposals to help it satisfy the requirements in the forum.
6. What are the milestones and bounty sizes for this RFP?
We are rewarding 7.5k EIGEN for the completion of the implementation of this project (fulfilling the entire properties & call to actions described in the RFP from above), subject to the terms and conditions, including a one-year EIGEN lock-up period, of a grant agreement with the selected contributor.
The grant will include the following delivery milestones:
- 10% - technical architecture and design
- 75% - build, and implementation of core logic + tests + docs, approved by Eigen Foundation or a designee contributor
- 15% - examples, readme, loom video
After implementation of the EigenLayer CLI, the selected contributor will be eligible for a small ongoing grant (e.g., 666 EIGEN per month) for the continuous maintenance of the repo after the implementation, for up to 3 months, renewed monthly.
Helpful Resources
- EigenLayer CLI
- Example AVS Registration Code - EigenDA
Disclaimer
By submitting the RFP, you agree to the Eigen Foundation Terms of Service and Privacy Policy.