1/ Congratulations to the @EigenLayer team on launching the EIGEN token! This is a *wildly* different design from anything we’ve seen to date so I’d like to share simple explanations of the most important concepts in EIGEN to help everyone grok it. Let’s dive in 👇
2/ Work Token Models
A work token model is one in which a user running a node agrees to provide certain services to the network that can then be consumed by other users. Examples of work token models include The Graph network’s nodes providing data to developers or Livepeer providing video transcoding to video distributors (e.g., YouTube). Work tokens are used not only as entry conditions for performing digital work but also for punishing non-compliant workers through a cryptoeconomic mechanism called slashing (i.e., when digital workers break the covenants inherent in the platform, they risk losing their work tokens).
Existing work tokens have at least one of two limitations: (a) they are special-purpose: created specifically for a particular enshrined digital task (e.g., the ETH token is used for validating Ethereum blocks), and/or (b) they are objective: enforceable only when the violations of the digital worker are clearly attributable onchain (via a programmatic proof).
A work token model is one in which a user running a node agrees to provide certain services to the network that can then be consumed by other users. Examples of work token models include The Graph network’s nodes providing data to developers or Livepeer providing video transcoding to video distributors (e.g., YouTube). Work tokens are used not only as entry conditions for performing digital work but also for punishing non-compliant workers through a cryptoeconomic mechanism called slashing (i.e., when digital workers break the covenants inherent in the platform, they risk losing their work tokens).
Existing work tokens have at least one of two limitations: (a) they are special-purpose: created specifically for a particular enshrined digital task (e.g., the ETH token is used for validating Ethereum blocks), and/or (b) they are objective: enforceable only when the violations of the digital worker are clearly attributable onchain (via a programmatic proof).
3/ ETH as the Universal Objective Work Token
EigenLayer removes the “special-purpose” limitation from ETH. Restaking expands the scope of ETH to become a ”universal” objective work token so that it can be staked to participate in all kinds of tasks, including new consensus mechanisms, optimistic rollups, bridges and MEV management solutions, which third parties can permissionlessly create and innovate upon.
However, the “objective” limitation of work tokens remains, as punitive slashing can only be applied to objectively verifiable tasks on Ethereum, such as double signing.
EigenLayer removes the “special-purpose” limitation from ETH. Restaking expands the scope of ETH to become a ”universal” objective work token so that it can be staked to participate in all kinds of tasks, including new consensus mechanisms, optimistic rollups, bridges and MEV management solutions, which third parties can permissionlessly create and innovate upon.
However, the “objective” limitation of work tokens remains, as punitive slashing can only be applied to objectively verifiable tasks on Ethereum, such as double signing.
4/ EIGEN as the Universal Intersubjective Work Token
There are many categories of faults that digital workers can commit that do not have objective attribution on the chain (we can call these types of faults intersubjective). For example, let us take the example of a price oracle required onchain, which brings the market price of a digital asset onchain. Price oracles are famously difficult to build slashing protocols for: if a digital worker performing an oracle task reports that 1BTC = 1USD (which is wrong by several orders of magnitude), the blockchain by itself has no locus to verify the correctness or otherwise of this assertion.
Intersubjectively verifiable faults are ones in which any two reasonable, observant humans can agree whether a digital worker failed to carry out the task properly. The EIGEN token removes the second limitation of work token models (that faults must be objectively verifiable) in order to significantly expand the scope of digital tasks that blockchains can offer their users securely.
There are many categories of faults that digital workers can commit that do not have objective attribution on the chain (we can call these types of faults intersubjective). For example, let us take the example of a price oracle required onchain, which brings the market price of a digital asset onchain. Price oracles are famously difficult to build slashing protocols for: if a digital worker performing an oracle task reports that 1BTC = 1USD (which is wrong by several orders of magnitude), the blockchain by itself has no locus to verify the correctness or otherwise of this assertion.
Intersubjectively verifiable faults are ones in which any two reasonable, observant humans can agree whether a digital worker failed to carry out the task properly. The EIGEN token removes the second limitation of work token models (that faults must be objectively verifiable) in order to significantly expand the scope of digital tasks that blockchains can offer their users securely.
5/ ETH+EIGEN: A solution to not overload Ethereum consensus
Vitalik’s excellent blogpost on not overloading Ethereum’s consensus had this key message: “The general rule of thumb that this post will attempt to defend is as follows: dual-use of validator staked ETH, while it has some risks, is fundamentally fine, but attempting to "recruit" Ethereum social consensus for your application's own purposes is not.”
Put simply, EigenLayer attempts to solve this problem by having EIGEN serve a fully complementary role to ETH with ETH staking powering objective fault slashing and EIGEN staking powering slashing for intersubjective faults. Breaking that down:
- Restaking: Tap into Ethereum’s security only for resolving objectively attributable faults. Recall that Ethereum’s security comes from the cryptoeconomic guarantee of staking + slashing and its social consensus. Any digital task where fault can be objectively attributed and malicious operators can be penalized programmatically within EVM should accept only native ETH or LST as part of restaking on EigenLayer. In such tasks, the mechanism for dispute resolution can be programmed within the chain state as a smart contract thus, correct execution of the dispute resolution is subsumed into chain validity. Therefore, cryptoeconomic security for digital tasks with an objectively attributable fault can uniquely tap into Ethereum’s cryptoeconomic guarantees without overloading the social consensus of Ethereum.
- Intersubjective staking: Tap into EIGEN’s social consensus for resolving intersubjectively attributable faults. The core idea of EIGEN is to recognize that the principle of intersubjectivity can apply at granularities other than that of the chain itself. In particular, EIGEN expands the idea of subjective choice from choosing a fork of a chain to choosing a fork of tokens for tasks that have faults intersubjectively attributable in nature. Resolving any potential faults in such tasks due to tyranny-of-majority requires the use of the technology of social consensus. In such tasks, EIGEN offers the tooling for unconditional slashing of the EIGEN staked by malicious operators on EigenLayer by tapping into the power of EIGEN’s social consensus to canonize the fork of EIGEN token that penalizes the malicious operators.
Vitalik’s excellent blogpost on not overloading Ethereum’s consensus had this key message: “The general rule of thumb that this post will attempt to defend is as follows: dual-use of validator staked ETH, while it has some risks, is fundamentally fine, but attempting to "recruit" Ethereum social consensus for your application's own purposes is not.”
Put simply, EigenLayer attempts to solve this problem by having EIGEN serve a fully complementary role to ETH with ETH staking powering objective fault slashing and EIGEN staking powering slashing for intersubjective faults. Breaking that down:
- Restaking: Tap into Ethereum’s security only for resolving objectively attributable faults. Recall that Ethereum’s security comes from the cryptoeconomic guarantee of staking + slashing and its social consensus. Any digital task where fault can be objectively attributed and malicious operators can be penalized programmatically within EVM should accept only native ETH or LST as part of restaking on EigenLayer. In such tasks, the mechanism for dispute resolution can be programmed within the chain state as a smart contract thus, correct execution of the dispute resolution is subsumed into chain validity. Therefore, cryptoeconomic security for digital tasks with an objectively attributable fault can uniquely tap into Ethereum’s cryptoeconomic guarantees without overloading the social consensus of Ethereum.
- Intersubjective staking: Tap into EIGEN’s social consensus for resolving intersubjectively attributable faults. The core idea of EIGEN is to recognize that the principle of intersubjectivity can apply at granularities other than that of the chain itself. In particular, EIGEN expands the idea of subjective choice from choosing a fork of a chain to choosing a fork of tokens for tasks that have faults intersubjectively attributable in nature. Resolving any potential faults in such tasks due to tyranny-of-majority requires the use of the technology of social consensus. In such tasks, EIGEN offers the tooling for unconditional slashing of the EIGEN staked by malicious operators on EigenLayer by tapping into the power of EIGEN’s social consensus to canonize the fork of EIGEN token that penalizes the malicious operators.
6/ Forking blockchains vs tokens
We are used to thinking about forking chains, but not so much tokens, because of something called the setup phase. Put very simply, the setup phase is the initial design and intent behind a protocol or token. Blockchains like Bitcoin and Ethereum have been established to embed forking into their designs based on their consensus rules. Forking is an important part of operating blockchains.
Tokens on top of blockchains (like ERC-20s) are almost never designed to be forked. The most famous forked token design is REP from the prediction market Augur. The REP token is staked
to report what happened in the real world to resolve the results of prediction markets (where the answer is binary, i.e., true or false). The REP token holders are slashed if they disagree with a majority of token holders, but if a certain-sized minority of REP holders dissent, they can initiate a forking event. The forking event now creates two ERC20 tokens, each of which represents a new forked version of the token corresponding to true/false (let’s call it REP1 and REP2). Over time, the community should align on one of these tokens, which will become the canonical token for Augur, while the other should trend towards zero.
This is a powerful design to resolve intersubjective faults, but has a number of drawbacks:
1. Specialization: Because Augur was application-specific (focused on prediction markets), it had a simple mechanism to measure the total value at risk (profit-from-corruption).
2. Fork-aware: Every holder of the REP token needs to be aware of forking and claim the right version of REP1 or REP2 tokens, even if they were not participants in the oracle. The original REP token in DeFi and CeFi now becomes stale and must be upgraded to the new version.
3. Parasitic (free-riding) behavior: It was possible for other protocols to build parasitic prediction markets on top of the prediction market. More severe than the Augur protocol losing fees, the protocol loses security properties in this setting.
We are used to thinking about forking chains, but not so much tokens, because of something called the setup phase. Put very simply, the setup phase is the initial design and intent behind a protocol or token. Blockchains like Bitcoin and Ethereum have been established to embed forking into their designs based on their consensus rules. Forking is an important part of operating blockchains.
Tokens on top of blockchains (like ERC-20s) are almost never designed to be forked. The most famous forked token design is REP from the prediction market Augur. The REP token is staked
to report what happened in the real world to resolve the results of prediction markets (where the answer is binary, i.e., true or false). The REP token holders are slashed if they disagree with a majority of token holders, but if a certain-sized minority of REP holders dissent, they can initiate a forking event. The forking event now creates two ERC20 tokens, each of which represents a new forked version of the token corresponding to true/false (let’s call it REP1 and REP2). Over time, the community should align on one of these tokens, which will become the canonical token for Augur, while the other should trend towards zero.
This is a powerful design to resolve intersubjective faults, but has a number of drawbacks:
1. Specialization: Because Augur was application-specific (focused on prediction markets), it had a simple mechanism to measure the total value at risk (profit-from-corruption).
2. Fork-aware: Every holder of the REP token needs to be aware of forking and claim the right version of REP1 or REP2 tokens, even if they were not participants in the oracle. The original REP token in DeFi and CeFi now becomes stale and must be upgraded to the new version.
3. Parasitic (free-riding) behavior: It was possible for other protocols to build parasitic prediction markets on top of the prediction market. More severe than the Augur protocol losing fees, the protocol loses security properties in this setting.
7/ EIGEN as a forking token
Imagine someone stakes an existing ERC20 token and proclaims this token should be forked if something bad happens in their newly designed oracle. This will not work because the token does not have the setup phase to permit it. The setup phase of the ERC20 token consists of what the people believe it will do (the concept of the token), and what functionalities the token allows. Both of these parameters are fixed when the token is created. If someone claims the token should be forked, it neither has this conceptual authority nor the technical ability (as forking the token will have downstream consequences on other applications of the token, which cannot be containerized).
A core part of EIGEN’s value prop is its setup phase, in which it is explicitly designed to adjudicate intersubjective faults and to fork the EIGEN token in order to slash and penalize malicious actors. This is why AVS’s would want to leverage EIGEN staking. EIGEN is universal, its users do not need to be fork-aware, and it is resistant to parasitic behavior.
Importantly, EIGEN is not a voting token! Forks are chosen entirely through social consensus.
Imagine someone stakes an existing ERC20 token and proclaims this token should be forked if something bad happens in their newly designed oracle. This will not work because the token does not have the setup phase to permit it. The setup phase of the ERC20 token consists of what the people believe it will do (the concept of the token), and what functionalities the token allows. Both of these parameters are fixed when the token is created. If someone claims the token should be forked, it neither has this conceptual authority nor the technical ability (as forking the token will have downstream consequences on other applications of the token, which cannot be containerized).
A core part of EIGEN’s value prop is its setup phase, in which it is explicitly designed to adjudicate intersubjective faults and to fork the EIGEN token in order to slash and penalize malicious actors. This is why AVS’s would want to leverage EIGEN staking. EIGEN is universal, its users do not need to be fork-aware, and it is resistant to parasitic behavior.
Importantly, EIGEN is not a voting token! Forks are chosen entirely through social consensus.
8/ You don’t need to do anything when EIGEN forks
If Ethereum forks, users must choose the canonical chain, but the ETH in DeFi and other applications is not impacted and remains fully useful and operational. It is still just ETH. ERC-20 token forking is unfortunately much more complicated.
There can be forking of EIGEN but there is no forking of the chain state of Ethereum and, by extension, the rest of the application layer on Ethereum. This leads to a complicated scenario where EIGEN’s social consensus has agreed upon a new canonical fork, but the EIGEN which were locked in non-staking applications such as DeFi or held on CEXes would still represent the stale version of EIGEN token from before the fork.
In order to solve this problem, EigenLayer is creating an isolation barrier between the CeFi/DeFi use cases of EIGEN and the staking use cases of EIGEN. Put simply, they propose an intersubjective forking protocol with two tokens: EIGEN and bEIGEN (i.e., backing EIGEN). bEIGEN will be used solely for intersubjective staking and EIGEN will be used for non-staking applications such as DeFi. The forking protocol is designed such that EIGEN is a wrapper over bEIGEN with special clauses on when and how wrapping and unwrapping can be executed. Even if bEIGEN is subjected to intersubjective forking, any EIGEN holder who is using it for non-staking applications doesn’t have to worry as it can redeem the forks of bEIGEN at any time later. For any developer of a non-staking application, as long as their surface area of interaction with the intersubjective forking is limited to only using EIGEN, the application can be agnostic of any intersubjective forking of bEIGEN.
Put very simply: EigenLayer tucks away the complexity inherent in the forking mechanism so that if you hold EIGEN in a non-staking capacity, you never have to worry about bEIGEN, forking, etc.
If Ethereum forks, users must choose the canonical chain, but the ETH in DeFi and other applications is not impacted and remains fully useful and operational. It is still just ETH. ERC-20 token forking is unfortunately much more complicated.
There can be forking of EIGEN but there is no forking of the chain state of Ethereum and, by extension, the rest of the application layer on Ethereum. This leads to a complicated scenario where EIGEN’s social consensus has agreed upon a new canonical fork, but the EIGEN which were locked in non-staking applications such as DeFi or held on CEXes would still represent the stale version of EIGEN token from before the fork.
In order to solve this problem, EigenLayer is creating an isolation barrier between the CeFi/DeFi use cases of EIGEN and the staking use cases of EIGEN. Put simply, they propose an intersubjective forking protocol with two tokens: EIGEN and bEIGEN (i.e., backing EIGEN). bEIGEN will be used solely for intersubjective staking and EIGEN will be used for non-staking applications such as DeFi. The forking protocol is designed such that EIGEN is a wrapper over bEIGEN with special clauses on when and how wrapping and unwrapping can be executed. Even if bEIGEN is subjected to intersubjective forking, any EIGEN holder who is using it for non-staking applications doesn’t have to worry as it can redeem the forks of bEIGEN at any time later. For any developer of a non-staking application, as long as their surface area of interaction with the intersubjective forking is limited to only using EIGEN, the application can be agnostic of any intersubjective forking of bEIGEN.
Put very simply: EigenLayer tucks away the complexity inherent in the forking mechanism so that if you hold EIGEN in a non-staking capacity, you never have to worry about bEIGEN, forking, etc.
9/ Wrapping up
EIGEN is a powerfully designed token model that serves the needs of the EigenLayer protocol, protects Ethereum consensus, and is highly useful for AVS’ to utilize in their designs.
While this thread focused on the EIGEN token, there is A LOT that we did not cover such as how staking actually works on Eigenlayer, staking for AVS’, cryptoeconomic security, wrapping and unwrapping, slashing, and most importantly, risks. Please read the whitepaper to learn more and keep in mind that this is a new system and to please exercise caution as you would with all new protocols.
If you’re keen to participate in Eigenlayer, you can
- read the EigenLayer whitepaper:
- learn more by reading Coinbase’s Guide to Eigenlayer:
- restake with Coinbase by following these instructions:
Congratulations again to the @EigenLayer team and community on this bold next step in building the Open Verifiable Digital Commons!github.com/Layr-Labs/whit…
coinbase.com/cloud/discover…
docs.cloud.coinbase.com/delegation/doc…
EIGEN is a powerfully designed token model that serves the needs of the EigenLayer protocol, protects Ethereum consensus, and is highly useful for AVS’ to utilize in their designs.
While this thread focused on the EIGEN token, there is A LOT that we did not cover such as how staking actually works on Eigenlayer, staking for AVS’, cryptoeconomic security, wrapping and unwrapping, slashing, and most importantly, risks. Please read the whitepaper to learn more and keep in mind that this is a new system and to please exercise caution as you would with all new protocols.
If you’re keen to participate in Eigenlayer, you can
- read the EigenLayer whitepaper:
- learn more by reading Coinbase’s Guide to Eigenlayer:
- restake with Coinbase by following these instructions:
Congratulations again to the @EigenLayer team and community on this bold next step in building the Open Verifiable Digital Commons!github.com/Layr-Labs/whit…
coinbase.com/cloud/discover…
docs.cloud.coinbase.com/delegation/doc…
• • •
Missing some Tweet in this thread? You can try to
force a refresh
