Restaking has become the dominant theme in the Ethereum ecosystem this year. Restaking is the ability to secure multiple protocols with the same stake. Effectively this means using staked tokens and running software for additional protocols.
EigenLayer is the implementation of restaking on Ethereum; it is a marketplace for decentralized trust (i.e., staked ETH), that connects restakers, builders, and operators.
Builders are excited about EigenLayer because it allows them to bootstrap their protocols. EigenLayer also creates a flywheel for the Ethereum ecosystem because it makes things easier for builders and creates an ecosystem of modules that can be combined to create new and interesting services.
Stakers are excited about EigenLayer because of the potential for additional rewards. For helpful context, linked here is an article on key restaking terms, and here is a full step-by-step guide on how to restake ETH using EigenLayer through the Figment app. There are risks involved with any protocol, which is multiplied when you can opt-in to secure many protocols simultaneously through restaking. One of the most important considerations for restakers is choosing the operator they delegate to, i.e., who is running all of these protocols on your behalf?
Why is Selecting the Right EigenLayer Operator So Important?
EigenLayer is a fast-moving protocol with frequent updates. The deployment so far has been in stages, similar to the launch of Ethereum Proof-of-Stake (PoS). On Ethereum, – first came the launch of the Beacon Chain, then PoS took over for Proof-of-Work (PoW) with the Merge, then staking withdrawals went live. For EigenLayer, clarity is still needed with rewards flow as well as penalties, among other aspects. That said, on April 9th, 2024, EigenLayer launched EigenDA – the first AVS – along with the ability to delegate to operators. Since then, an additional nine AVSs have been launched.
In addition to the proliferation of AVSs, the number of operators has exploded. For instance, you can look at the testing happening on Holesky here, and see 320 pages of operators; there are twelve operators per page.
These dynamics potentially set up a situation where restakers add a significant amount of risk instantaneously and, perhaps, unknowingly. For the time being, penalties are not live on EigenLayer; the expectation is that these will go live during the third or fourth quarter of this year. The delay in activating penalties is good as participants become acquainted with EigenLayer, but it also risks catching some restakers off guard when launched; an especially risky situation for those that have delegated to an operator running as many AVSs as possible.
Know Your EigenLayer Operator
Choosing the right operator is arguably the most important decision a token holder makes when staking. Restaking is no different. In terms of complexity, AVSs run the gamut from simple appchains on one side to full-blown protocols on the other. Each AVS should be treated the same as any other network in terms of the level of diligence and care taken by the operator.
A proliferation of new and unproven operators can make this a daunting task. Operators with a long track record of operating many different networks is a good starting point. For instance, Figment has been running operator infrastructure for over five years and is currently running over three dozen networks and has run well into the hundreds of networks.
Safety is also vitally important. After all, what good are (re)staking rewards if a token holder’s stake is put in jeopardy? Many risks can create this situation like haphazard operations, insufficient security policies or ill-thought out reward maximization schemes. Figment runs infrastructure according to a philosophy of Safety Over Liveness, recognizing the fact that in many cases it is advisable to accept some downtime to assess a situation rather than risk a knee-jerk reaction causing a more severe outcome like slashing.
The security of operations is just as important as how infrastructure is being run. A flawless slashing record is useless if an attacker is able to gain access to sensitive data and information. Figment takes security seriously – From the meticulous design of our infrastructure to the rigorous security awareness training provided to our staff, all the way through achieving SOC II compliance, we ensure every aspect of our security framework is robust.
An operator’s performance is also very important, especially in terms of penalties and slashing. Understanding any prior incidents and the openness of an operator in communicating the incident to their customers and how the incident was handled along with remediation is important. Figment has one of the best records of slashing, including never having been slashed on Ethereum.
Know Your EigenLayer AVSs
Restakers, through operators, are effectively renting out their staked ETH to secure AVSs. Once slashing goes live, restakers will be risking their stake in order to earn additional rewards. Restakers should have a solid understanding of all of the AVSs their operator is running and the risk/reward profile of each. Being able to understand why the AVS needs the ability to slash, i.e., levy penalties on restakers, is important and should make sense. A helpful exercise is to understand where each AVS sits along the spectrum of other networks and AVSs in terms of its penalties. For instance, if an AVS has comparable penalties to Ethereum’s slashing penalties, a restaker should assess whether this is reasonable and makes sense.
Another potentially overlooked consideration is the viability of the AVS’s business. Which tokens does the AVS accept for security – staked ETH, its own token, or both? And which token(s) are used to pay rewards? Is there any risk to the AVSs’ ability to pay out rewards? This is an especially important consideration for AVSs offering points.
To get a sense of an AVS’s viability, it is important to understand where it fits in the larger Web3 ecosystem and the expected revenue in that area of Web3. For instance, Figment has an operator profile that is only running EigenDA – an AVS providing data availability services to rollups. Rollups have a proven business model and there are public resources that track their revenue and profit. EigenDA provides a competitive data availability service at a cheaper cost than what is currently available through Ethereum. In fact, EigenDA offers a service that competes with Danksharding, which could still be years away. Offering a valuable service to a profitable area of Web3 and one that appears years ahead of its time, is a strong indicator of a viable business.
Understanding the AVS’s attitude and stance toward security is also an important consideration. Code audits, bug bounties, and key management considerations for operators are all important aspects to assess. As an example, AVSs that require questionable operator key management, such as sharing of keys or requiring keys to be hosted in unsafe environments are likely red flags.
Know Your EigenLayer Operator’s AVS Policy
Finally, just as important as understanding each AVS that an operator runs is knowing the operator’s policy around adding or removing AVSs. AVSs are likely to vary greatly in terms of their risk/reward profile. So removing some AVSs and adding others has the potential to greatly change the risk/reward profile for restakers.
The starting point is understanding how an operator decides to add specific AVSs. Many of the points raised above are relevant here: understanding the AVS’s security stance, who their investors are and whether they have a viable business model are all important considerations. A telling factor is understanding if an operator has any “non-starters” – factors that would cause them to rule out running a specific AVS instantly.
Beyond these specific factors, how is the operator assessing them? Figment treats AVSs the same way we treat all new networks. In addition to the items previously discussed, significant testing, monitoring, data collection, reporting, and customer appetite are performed/assessed. Customer appetite is not just about business, it is about the ability to sustainably support new networks and AVSs. It does little good to a network/AVS or customers if an operator shuts down its support shortly after launching.
This brings up how and when an operator decides to deprecate the operation of a particular AVS. The operator might deprecate due to an AVS failing to meet expectations, lack of customer interest or de-prioritization. Regardless of the reason, this can be an inconvenience for restakers and is something that should be well understood before delegating to an operator.
Beyond the criteria for either adding or removing an AVS from an operator’s offering, understanding how these changes will be communicated is very important. Does the operator have a clear process for adding and removing AVSs from their offering and how will this be communicated? An inability to clearly outline these aspects should elicit caution. Currently, Figment is running single AVS operator labels, for instance, this is our EigenDA operator. For our single AVS operator labels, we will not be adding any additional AVSs, which assures restakers about the protocols they are securing and rules out drastic, unexpected changes in their risk/reward profile caused by changing AVSs.
If there was ever a time to be keenly aware of the risk, engaging with restaking is likely it. Figment has the experience, track record and risk management approach required to engage with restaking. Running every AVS possible is likely a recipe for disaster. Restakers should not be lulled into complacency due to the lack of slashing penalties currently. There is a compelling opportunity to add rewards (and risk) by restaking, but it should be done in a considered and measured way – don’t lose your stake by inadvertently multiplying your risk!
The information herein is being provided to you for general informational purposes only. It is not intended to be, nor should it be relied upon as, legal, business, tax, or investment advice. Figment undertakes no obligation to update the information herein.
