Over the past few years, we at Eigen Labs have been developing a platform for advancing the concept of open, verifiable digital commons. This blog post summarizes the intersubjective forking protocol enabled by the EIGEN token. We will break down the significance of EIGEN, its core ideas, its high-level implementation, how it extends the utility of Ethereum, and the impact on open innovation via this new token design.

The intended audience for this post is engineers and researchers. You can also read the full EIGEN whitepaper here.

Introduction

Categorization of faults. 

Blockchains and other decentralized systems are enabled by protocols that enable disparate honest actors to coordinate towards goals with resilience to adversarial actors. These protocols generally work based on incentivizing protocol-consistent behaviors and disincentivizing malicious behaviors. One observation regarding these protocols is that not all behaviors, or "faults," can be rewarded/punished with the same level of precision. Broadly, we can categorize faults into four types: 

1. Objectively attributable faults are attributable purely mathematically and cryptographically without the need to ask the opinions of others, e.g., rollup execution validity. 
2. Intersubjectively attributable faults are a set of faults where there is a broad-based agreement among all reasonable active observers of the system, e.g., data withholding. 
3. Non-attributable faults are not observable to anyone other than the victim, such as privacy violation in decentralized-secret-sharing. 
4. Subjective “faults” are those where observers make their own judgments, with no guaranteed concordance across different observers. For example, what is the best restaurant in New York City?

Since non-attributable and subjective faults do not have broad concordance, in this work, we only consider objective and intersubjective faults.  

Importance of social consensus. The mechanisms currently being used in the industry for resolving intersubjectively attributable faults are: 

(a) slash the stake of operators whose response to the task diverged from the majority response, 

(b) use a committee to slash the operators whose claims are not concordant with the “true” answer, or

(c) slash the stake by forking the chain. 

Mechanisms (a) and (b) are vulnerable to tyranny of the majority. In such an attack, many more stakeholders besides the operators actively responding to the tasks or the stakers delegated to the operators will be affected. A nice feature of this broader group of stakeholders, colloquially called social consensus, is that it is an unsized and potentially infinite set. Mechanism (c) involves empowering social consensus to slash the adversarial operators in the event of majority corruption of the operator set. 

Restaking ETH.  Any task with an objectively attributable fault can be resolved onchain by integrating its dispute resolution mechanism within Ethereum’s chain validity through smart contracts. EigenLayer employs this property to restake ETH and expand the scope of staked ETH to secure Actively Validated Services (AVSs) with objectively attributable faults. 

Staking with EIGEN. The new EIGEN token introduces a complementary mechanism that is designed to specifically address “intersubjective” faults – faults that are not possible to address via ETH restaking alone. 

In essence, ETH restaking in EigenLayer expands ETH to become the Universal Objective Work Token and the universality of EIGEN makes EIGEN the Universal Intersubjective Work Token.

Core Ideas

We call staking with EIGEN intersubjective staking, which builds upon the following core ideas. 

Setup and execution phase. The social consensus underpinning intersubjective agreement typically proceeds in two phases: 

1. the setup phase at the genesis, where the rules of coordination among the system's stakeholders are codified;
2. the execution phase in which pre-agreed rules are executed, ideally locally, in a self-evident manner. 

It is important to note this separation, because the setup phase is where the coordination conditions are defined, and for any user that opts in, the execution phase is self-evident and self-executable. So we do not mean social consensus in the sense of users getting into a room or a discord channel to arrive at the resultant consensus. Instead, we refer to systems where users can self-execute conditions that they have pre-agreed to.

Slashing. Slashing offers a mechanism to penalize operators that violate the core rules of the AVS, by burning or redistributing their staked digital assets.

Token Forking. While slashing can be implemented via smart-contracts for objective faults, for intersubjective faults, smart-contract implementation is insufficient. This is because, from inside the EVM, it is not clear whether the intersubjective fault occurred or not, whereas it is clear to the observers in an external frame-of-reference. We note that the value of a token arises from the external frame-of-reference or the social consensus that one particular token is canonical. Token forking is a mechanism that seeks to utilize this external frame-of-reference in value allocation in order to induce cryptoeconomic penalties. The core idea is that if there is a fault induced by misbehavior of a (super-)majority of EIGEN token stakers, any challenger can create a fork of the token, in which the malicious stakers are slashed. Now this creates two possible versions of the EIGEN token, and users as well as AVSs can freely decide which one to respect and value. If there is general agreement that the slashed stakers misbehaved, then the users and AVSs will value only the forked token rather than the original token. Since in the forked token, the malicious stakers do not have any allocation, they lose the original value inherent in their stake. We call this mechanism slashing-by-forking.  This idea was pioneered by Vitalik Buterin documented in the Ethereum blog (circa 2014-2015): The p + epsilon attack, Schellingcoin, The subjectivity / exploitability tradeoff. A grounding principle in the EIGEN token is to ”slash stakers” only when their fault is beyond a reasonable doubt. Under these conditions, slashing requires large collusion as well as a large potential loss of funds, and this suffices to ensure honest behavior. Thus we expect EIGEN forking to be a last-resort nuclear option, but nevertheless one that is needed to ensure that the stakers behave correctly.

Different from previous mechanisms for token forking, EIGEN presents four new features. 

1. Universality. EIGEN is a universal intersubjective token, which means, it is designed in its Setup phase to fork-and-slash for intersubjective faults committed by EIGEN stakers across any AVS in EigenLayer. In specialized systems like Augur, there is an application dependent mechanism to figure out the total value of cryptoeconomic risk (profit-from-corruption) to ensure the system is safe. In order for EIGEN to be used universally across applications, we have designed an application-independent mechanism for ensuring the system remains cryptoeconomically secure. 
2. Isolation. While EIGEN needs to have the ability to fork, this induces an externality on all applications and users as they need to be fork-aware. For example, in a lending market where there is no fixed term for the loan, the forking token cannot be accepted as collateral, as it is possible that the token will fork in which case the smart contract needs to go and redeem that fork. In order to prevent this problem, the EIGEN protocol uses a two-token system where one token can be used in fork-unaware applications and another forkable token is utilized for staking and forking. Of course, there should be a binding relationship between these two tokens. We term the former “fork-unaware” token as a “solid representation” if it allows holders to redeem an equivalent number of tokens from any of its descendant forks at any future time. This property makes it easy for anybody to use the solid representation in applications like a lending protocol. We have designed EIGEN such that it achieves isolation and solid representation properties. 

3. Metering. Resolving any intersubjective fault incurs a cost to social consensus for switching from one token to another, or rejecting a malicious fork. Therefore, the whitepaper proposes that any claim to fork the token (termed an intersubjective challenge) should require depositing a bond in EIGEN to deter malicious challenges. This bond needs to be higher than the cost incurred by the social consensus (users and AVSs) to consider and reject a malicious fork. Additionally, any successful challenge results in a significant cost to the broader ecosystem in the form of contract upgrades for incorporating the new fork in daily operations. A challenge, therefore, should only be raised if a sufficient amount of staked EIGEN can be considered malicious and burnt resulting in a lower token supply and higher utility for the remaining EIGEN. These social costs need to be built into the core protocol to appropriately meter the costs and tradeoffs of social consensus.
4. Compensation. The protocol for intersubjective staking ensures that if an AVS is attacked due to a malicious quorum of EIGEN stakers, that AVS is able to slash and redistribute the malicious stake back to the AVS users. If the AVS ensures that this “attributable security” is greater than the harm done to its users, then it achieves “strong cryptoeconomic security” which specifies that no honest user suffers any harm. Previous definitions of cryptoeconomic security required that the adversary have a smaller profit from corruption than the cost induced by slashing, and thus had a major shortcoming in that it is not possible for a protocol to know comprehensively the ways in which an adversary may profit from an attack (for example, using an external short position). Strong cryptoeconomic security, on the other hand, is a user-centric characterization and does not need to make any assumptions on the adversary or even the other users’ incentive structure. For example, when there are multiple AVSs, as long as a given AVS ensures that it has enough attributable security, this particular AVS is protected even if the system is in sum total not secure because other AVSs do not have enough security. 

A World with Intersubjective Staking of EIGEN

Complementary roles of EIGEN and ETH.  EIGEN staking and ETH restaking can each fill complementary roles within a staking system such as EigenLayer. Many mature AVS protocols consist of both safety properties that can be secured via objective slashing and liveness or censorship-resistance properties that would previously depend on majority-assumptions which rest on stake decentralization. For a service that uses restaking for safety and intersubjective staking for liveness, fees can be split between the two quorums. Furthermore, for core services provided to the Ethereum ecosystem, we envision many services that will use dual staking between ETH and EIGEN, where the native restaking absorbs the decentralization / collusion resistance and operator alignment that comes with ETH restaking, and the EIGEN staking can actually support cryptoeconomic slashing. In this model, the former serves as a mechanism to obtain majority trust from the Ethereum participants, and the latter serves as a mechanism to obtain economic security.  For example, an oracle built in this model can be thought of as a hybrid between the enshrined oracle model proposed by Justin Drake and the cryptoeconomic oracle model proposed in Augur and in this post.

EIGEN enables a higher rate of innovation in objective AVSs. Intersubjective staking 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. In particular, in envisioning the lifecycle of a new objective AVS, we can identify a progression that leverages intersubjective staking for security early in the bootstrapping phase of the protocol and transitions to restaking or even native protocol adoption as the protocol matures and ossifies and more faults can be made objective. 

Quorum composition.  In keeping with the spirit of open innovation, EigenLayer allows AVSs to mix and match these two modalities of objective staking from ETH and intersubjective staking from EIGEN in addition to utilizing the native AVS tokens for providing additional validation from an aligned community of AVS token stakers. 

Examples. Intersubjective staking with EIGEN unlocks a vast range of previously impossible AVSs on Ethereum with strong cryptoeconomic security. This opens the door to innovations for: Oracles, Data Availability layers, Databases, AI systems, Gaming VMs, Intent & Order Matching & MEV engines, Prediction markets, etc.  

Roadmap

The launch of EIGEN introduces intersubjective staking. This has broad ramifications for the crypto ecosystem as a whole. With its design being completely novel, the concept needs to be absorbed and discussed widely by the ecosystem participants. The initial implementation of intersubjective staking at this launch mirrors the full protocol to only a limited extent. However, there are still several parameters that need to be determined for full actuation. To accomplish that, EIGEN is being launched in a meta-setup phase. This meta-setup phase will serve as a call-to-action where researchers, experts, and the broader community engage in public discourse to discuss the necessary parameters to make the protocol and its interaction with the rest of the Ethereum ecosystem most effective.

Conclusion

The EIGEN system's new functionalities effectively open up new vistas for open innovation. It solves fundamental challenges like universality, isolation, metering, and compensation. By using social consensus and forking, EIGEN empowers the secure execution of diverse digital tasks with cryptoeconomic security, effectively paving the way for the construction of an open, verifiable, digital commons. 

As developers and researchers continue to refine and adopt EIGEN, we are excited to help you learn more about EigenLayer and hear from you. Below are some resources:

• Read the full EIGEN whitepaper here.
• Reach out to us via our builder form: https://bit.ly/avsquestions 
• AVSs that are live: https://app.eigenlayer.xyz/avs 
• Resources for how to build an AVS: https://github.com/Layr-Labs/awesome-avs 
• Get inspired on more AVS ideas: https://www.blog.eigenlayer.xyz/eigenlayer-universe-15-unicorn-ideas/