One of EigenLayer’s primary goals is to expand builders’ toolkits. Restaking allows builders to bootstrap their protocols and gives them greater flexibility to define the rules and penalties for operators running their protocols. In other words, builders can move beyond Ethereum’s consensus rules and develop their own, specifically tailored to their protocol.
Restaking is an important step forward, but it does not cover all use cases. There are some faults that are not so easy to build into a protocol. An example mentioned in the EIGEN token whitepaper is an Oracle service that reports the price of BTC/USD. This task seems straightforward, but writing slashing conditions for an erroneous rate reported by an oracle operator is complicated.
This is a good example of something called an intersubjectively attributable fault, difficult to implement on-chain, but much easier for outside observers to agree on. Intersubjective staking, staking that penalizes intersubjectively attributable faults, can also be used to support digital tasks which could in principle be secured via objective fraud proofs, but where doing so would involve a large amount of technical complexity and associated risk. This is the problem EigenLayer has been working on a way to allow builders to incorporate intersubjectively attributable faults and punish operators for committing them.
For any builder that requires intersubjective staking, a system can be devised to adjudicate these faults off-chain. But how should these faults be penalized? Operators could be slashed, i.e., have some of their tokens taken away, but this solution has at least two problems.
- The ‘tyranny-of-majority’ problem – if a majority of operators (or those making the decision to slash) are malicious, they can decide to erroneously slash operators in contravention of a protocol’s rules.
- Slashing does not encourage legitimate disagreement. In some cases, there are well-balanced disagreements where neither side is clearly right nor wrong; the Ethereum Classic situation is a good example.
The EIGEN token ($EIGEN) provides a relatively smooth forking process, which relies on social consensus to determine the canonical fork in addressing intersubjectively attributable faults. Social consensus happens to be unsized and unlimited, which alleviates the ‘tyranny-of-majority’ issue, while also allowing for legitimate disagreement, i.e., allows for the co-existence of two or more distinct views.
In other words, the core idea of EIGEN is to recognize that the principle of intersubjectivity can apply to digital tasks other than that of the chain itself. In particular, EIGEN expands the idea of subjective choice from choosing a fork of chain to choosing a fork of token for tasks that have faults intersubjectively attributable in nature.
Builders can use restaked ETH, their own token, and/or the EIGEN token to secure their protocols (AVSs) depending on their needs and the nature of faults they face:
What is the EIGEN Token?
EIGEN is the token of the EigenLayer ecosystem. Its functionality is being rolled out in stages, initially, it will:
- be represented by two tokens – bEIGEN, or backing EIGEN, for staking and EIGEN which can be used in the broader ecosystem for non-staking applications. Both are ERC20 tokens. It should be noted that during the typical course of operation, the bEIGEN token is not intended to be held by users.
- It will act as another means to engage on EigenLayer. Holders will be able to stake the token and earn rewards on certain AVSs. EigenDA, for instance, is intended to accommodate a dual staking (or dual quorum) model – accepting either restaked Ether (ETH) or the EIGEN token.
- It will be possible to use the token in many of the same contexts that liquid staking tokens (LSTs) are used. For instance, many of the common use cases for LSTs like borrowing/lending, swapping, providing liquidity (on DEXes), and moving to L2s, could be possible, subject to EIGEN integrations.
- Importantly, the token can be used as a tool to facilitate forking. AVSs incorporating the EIGEN token will be able to set up the conditions upon which the fork occurs. Users in the social consensus of EIGEN will be able to decide if they agree with the fork or not and react accordingly.
- From an ecosystem perspective, it alleviates the risk of overloading Ethereum’s social layer.
Stakedrop Details
On May 10th the EIGEN stakedrop claim opened:
Some of the details along with an FAQ about this stake drop and future drops were mentioned:
Once EIGEN tokens have been claimed they can be staked; the process has a similar feel to depositing and restaking an LST.
Importantly, once slashing is implemented – likely in the third or fourth quarter of this year – EIGEN holders that are staking on EigenLayer will need to pay attention to any potential forks and act accordingly. Forking is an extreme event and is not anticipated to happen regularly, but EIGEN holders will need to be mindful.
How Does EIGEN Work?
As mentioned above, there are two representations of the token: EIGEN, the version that can be used in similar ways to other ERC20s wherever it has been integrated, and bEIGEN (‘backing EIGEN’), the staked version of the token, whose main relevance is within the EigenLayer protocol only. It is this dual representation that allows forking – users can unwrap EIGEN to obtain bEIGEN or a forked version of bEIGEN.
For an AVS that decides to use EIGEN, there are two broad phases: setup and execution. In the setup phase, the AVS needs to create the conditions upon which the token forks. One of the key aspects is codifying how faults are captured and how challenges are raised during the execution phase.
Beyond this, the AVS must also decide on the deflation-per-fork (DPF) and commitment-per-fork (CPF) amounts. The DPF is the minimum amount of tokens that should be burnt on the original fork that participated in executing the fault. In other words, the operators causing the fault should collectively have DPF burnt (or taken away). DPF is what dissuades faults, i.e., malicious operators, for instance; it also pays the cost of switching to a new canonical token.
CPF is the number of tokens that the challenger contributes – this is the number of tokens burnt if social consensus decides that the original fork will remain canonical, i.e., the challenge “fails”. The CPF discourages baseless challenges, i.e., griefing attacks.
In the chart below, bEIGEN2 represents the new canonical token, assuming the challenge is valid and bEIGEN1 represents the old token, i.e., the one being challenged.
Moving ahead to execution: assuming monitoring detects a potential fault on the AVS, there is some deliberation and a decision is made to move ahead with a challenge (all of these aspects were created/designed in the setup phase).
The challenger puts up the CPF amount, understanding that this amount will be burnt in the event that the challenge is unsuccessful.
The challenger (or someone who has been delegated the responsibility) needs to create:
- A new version of the token (bEIGEN2 in the diagram above),
- A new challenge contract for the fork – used for future forking if necessary, i.e., if a fault occurs with respect to the new bEIGEN2 token, and
- A new fork-distributor (FD) – identify malicious operators (via their addresses), the address of the bEIGEN1 contract, and the reward for the challenger.
Once a challenge is raised, EIGEN holders have a fixed amount of time to redeem their tokens for the new canonical token:
With subsequent releases, EIGEN holders will no longer face this time constraint, i.e., EIGEN will have achieved so-called solid representation: “if the tokens belonging to any fork of EIGEN can be redeemed for the same number of tokens belonging to any of its descendent fork of the EIGEN token that the holder desires“ (see EIGEN whitepaper, p 11).
It should be noted that with multiple AVSs using the EIGEN token, if/as forking occurs there is the potential to have different AVSs using different versions of the EIGEN token to secure their protocols.
Multi-Stage Rollout
The EIGEN token is being released in stages. Users, researchers, and the larger community need time to absorb the token’s design and functionality and provide feedback.
At the time of writing the token is in its so-called ‘meta-setup phase’ – a stake drop has occurred and EIGEN holders can do some things with their tokens, like stake them. That said, the tokens are not currently transferable and there is limited tokenomics information.
Following the meta-setup phase will be V1. V1 brings much of the functionality described above – the ability to fork given an intersubjectively attributable fault.
V2 will bring ‘solid representation’ – the capability for a token holder to redeem their version of the token for any subsequent version, assuming they were not previously staked to a malicious operator. In other words, this would remove the need to act within a certain timeframe as mentioned above.
V3, the anticipated final version, adds resilience to a malicious security council. V3 achieves this by migrating away from relying on governance and instead using an immutable gateway contract, which is used to stake EIGEN tokens.
Figment + EigenLayer
Figment is well-positioned to be a leading supporter of EigenLayer as it develops and grows.
Having already assisted customers with getting started on EigenLayer, Figment plans to continue onboarding more users wishing to leverage EigenLayer’s capabilities.
As an early tester, Figment will provide valuable feedback to improve EigenLayer and AVSs based on real-world experience operating AVSs via our staking infrastructure. Figment’s role transcends mere participation; it envisions being a cornerstone in EigenLayer’s architecture by providing robust support and insightful feedback. The mutually beneficial relationship between Figment and EigenLayer is forged through a shared vision of an innovative, secure, and more rewarding staking environment.
As EigenLayer continues to grow and attract more developers and protocols, we expect it to become a significant driver of value creation within the blockchain economy, catalyzing new opportunities for innovation. Figment’s continued support and integration signify a promising future for Ethereum stakers and restakers alike. With technical prowess and financial investment, Figment is dedicated to the success of EigenLayer, ensuring its growth and sustainability within the broader Ethereum ecosystem.
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.
