EigenDA Operator Guide
This guide contains the steps needed to set up your node on the EigenDA testnet. The testnet is used to test the operational and performance requirements for running a node before deploying on mainnet. The testnet is under constant stress tests and has frequent updates to the node software and other network components. It’s important to check regularly for new updates to the software and documentation.
Operator System Requirements
Operators can determine their required EigenLayer node class by referencing their share of the total EigenDA quorum against the following table.
|Max % of Stake
|General Purpose - large
|0.03% (Solo staker)
|General Purpose - xl
|General Purpose - 4xl
Professional operators with large or variable amounts of delegated stake should
4xl node class. The
large class is intended to be used by solo
stakers with the minimal allowed quantity of stake.
We will update this specification to include new EigenLayer node classes as they are introduced.
Node Storage Requirements
EigenDA nodes must provision storage capacity (high performance SSD volumes) in order to store and serve all data passed to the node over a 2-week period.
The following table summarizes the amount of storage that is required for a node based on the amount of stake delegated to the operator.
|% of stake
EigenDA Churn Approver
The Churn Approver is responsible for managing the active set of Operator nodes in the EigenDA network. EigenDA uses an operator cap that limits the maximum number of active Operator nodes in the network in order to maintain the desired network performance and limit the L1 gas cost for aggregating signatures.
limited to 200 operators. We will review this operator cap on an ongoing basis, and explicitly communicate future changes. :::
In order to determine the current TVL of the top 200 operators, please visit our
AVS page and sort by
TVL Ascending.Observe the first 200 operators listed and the amount of ETH TVL
delegated to them.
When a new operator wants to opt-in but EigenDA has reached its operator cap, the newly-registering operator can request a signature from the Churn Approver. The Churn Approver will check that the newly-joining operator meets stake requirements, and provide a signature that approves removing the current lowest-stake existing operator. The operator will then opt-in to EigenDA, providing the churner’s signature and information on the lowest-stake existing operator as additional inputs to EigenDA’s smart contract. Finally, the smart contract will:
- Check the Churn Approver’s signature.
- Perform checks against the stake of the newly-joining and (to-be-ejected)
current lowest-stake operator:
- The new operator needs at least 1.1x the ejected operator’s stake.
- The ejected operator must constitute less than 3.33% of the total stake.
- Eject the current lowest-stake operator.
- Proceed with opting-in the new operator, as normal.
The parameters of checks performed in step 2 are configurable by the contract governance.
Operator Ejection Confirmation
Operators that have been ejected can verify the change in two ways:
- Visit the EigenDA AVS application to observe whether your Operator is present in the active operator set on the AVS page.
- Observe your EigenDA Operator log for the following logs. If you see this consistently, then your operator is not receiving any disperser traffic and you may have been ejected. This is not an error but if you only see this log line repeatedly then it means you may not be receiving any disperser traffic.
INFO [12-21|18:53:46.673|github.com/Layr-Labs/eigenda/node/node.go:233] Complete an expiration cycle to remove expired batches "num expired batches found and removed"=3 caller=node.go:233