EIGEN: The Universal Intersubjective Work Token

Towards the Open Verifiable Digital Commons

Eigen Labs Team


In this whitepaper, we introduce the structure of the EIGEN token, which can function as a universal intersubjective work token. We will unpack this term here: work token refers to a token that needs to be staked (i.e., locked up), in order to perform some work. This is similar to taxi medallions, which are required to drive taxis in some cities. Work tokens are employed by many existing proof of stake blockchain platforms to perform validation of the blockchain, using a mechanism called staking. Work tokens are used not only as entry conditions for participating in the performance of digital work, but also for punishing non-compliant workers through a 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 two limitations:

(a) they are special-purpose: i.e., they are created specifically for a particular enshrined digital task (as an example, the ETH token is used for validating Ethereum blocks), and (b) they are objective: enforceable only when the violations of the digital worker are clearly attributable onchain (via a programmatic proof). Our earlier work created EigenLayer, a restaking (or more accurately, permissionless programmable staking) platform, which expanded the scope of the ETH to become a universal “objective” work token so that it can be staked to participate in all kinds of tasks. But the punitive slashing can only be applied for tasks that are objectively verifiable on Ethereum. In this paper, we build a new staking model that breaks both these limitations simultaneously: (a) a universal work token: which can be used across all digital tasks, which are (b) intersubjectively verifiable, i.e, any task for which we can have intersubjective agreement, i.e, any two reasonable, observant humans will agree whether a digital worker failed to carry out the task correctly. This token significantly expands the types of credible commitments that digital workers can make with cryptoeconomic security, and hence significantly expands the scope of digital tasks that blockchains can offer their users securely. We view this intersubjective work token as a first step towards our goal of building the Verifiable Digital Commons.

  1. Introduction

    1. Background

      The significant evolutionary advantage of humans rests in our ability to cooperate in large numbers. Large- scale cooperation requires trust, which is usually provided by intermediating institutions. The modern econ- omy has seen the rise of digital platforms such as Facebook, Uber, Airbnb, Visa, iTunes, Ebay and Amazon marketplace which allow global communication, efficient markets and cooperation at scale. One might say that these digital platforms form a system of digital commons, somewhat akin to the physical commons, such as forests, fisheries, national parks and oceans, that we have in the real world.

      While existing digital platforms rival physical commons in access, importance and reach, they do not fully qualify as digital commons as they are controlled without democratic governance, leading to significant frictions, such as: (i) centralized information and control silos, where users or innovative solutions can be de-platformed any time, (ii) platforms enshrine somewhat subjective positions, such as the specific recom- mendation engine, moderation policy, and mechanisms to evaluate driver behavior, credit or renter behavior,

      (iii) innovations on top of these platforms require permission of the platform creators, and this significantly constrains the innovation velocity, and (iv) platforms can unilaterally alter policies that affect users without seeking their inputs.

      Blockchains offer an alternative paradigm for building the global digital commons where it is possible to have

      (i) permissionless user access, (ii) native user governance, (iii) programmatic incentives to share value across the various participants and (iv) permissionless innovation. All of these properties arise because blockchains

      have two main properties: (a) openness, which comprises of censorship resistance and permissionlessness and (b) verifiability, which ensures that the nodes participating in the blockchain are performing their duties correctly. Thus we can say that blockchains offer a new paradigm for building the open, verifiable digital commons.

      Staking via a work token. This brings us to the question of how one can create a digital commons platform, which is at the heart of blockchain architecture design. Instead of a legal solution of ensuring openness and correctness via laws, blockchains strive to create a neutral digital platform by ensuring that no single party is responsible for creating and maintaining the platform. That is, blockchains decentralize the ability to partici- pate in the upkeep of the platform, by which we can achieve credible neutrality. A popular mechanism that blockchains employ to achieve this decentralization is using proof-of-stake protocols: creating a token that anyone can use to participate in the digital work required for the upkeep of the blockchain [1]. One can think of these staking tokens as work tokens, designed specifically for the particular digital task of participating in the operations of running that particular blockchain. Similar to how a taxi medallion is required to drive a taxi in certain cities, these work tokens are required to participate in the digital work associated with the upkeep of the blockchains.

      Slashing. A major advantage of proof-of-stake protocols is that if the participating stakers violate the com- mitments required for the digital work, then they can lose their staking tokens using a mechanism called slashing. Slashing ensures that even if all the validators try to collude to break the commitments inherent in running the blockchain, they will lose their staking tokens. This creates a system of Karma: the law of attri- bution and enforcement. Ethereum, again, pioneered this structure of “cryptoeconomic security” [2]. Crypto

      - alludes to attributability of the fault to agents using cryptographic methods like signatures, and economic - alludes to loss of economic value associated to stake for agents who commit faults. Cryptoeconomic security is a significant advance in the ability of individual agents to cooperate to perform digital work, thus creating an emergent digital platform which can make credible commitments of neutrality and correctness.

      EigenLayer makes ETH as a Universal Objective Work Token. In prior work, we created EigenLayer restaking, a universal mechanism to share the same stake across a variety of different digital tasks, thus making ETH a “universal work token”. While prior staking mechanisms coupled a given type of stake / token with an enshrined set of digital tasks in the platform, restaking enables the same token to participate in a variety of digital tasks including new consensus mechanisms, optimistic rollups, bridges and MEV management solu- tions, which third parties can permissionlessly create and innovate upon. Thus EigenLayer expands the scope of staking ETH from a single enshrined task of participating in consensus to a variety of digital tasks that can be built permissionlessly on top of the common blockchain. However, restaking provides cryptoeconomic security via slashing only for digital tasks whose faults are objectively attributable, i.e., clearly verifiable on- chain. Examples of such onchain attributable faults include: double spending (the same coin should never be spent twice in a payment chain), double signing (there can be no two blocks with the same block index), invalidity (creating a new state of the system which is not correctly transitioned from the previous state given the intervening transactions). Thus we can say that EigenLayer converts ETH into a Universal Objective Work Token.

      Limitations of restaking: non-onchain attributable tasks exist. There are many categories of faults that dig- ital workers can commit that do not have objective attribution on chain. 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. This is because blockchains are purely deterministic state machines and to preserve the determinism and objectivity these subjective claims are excluded from intrinsic verification in the blockchain. There are other examples of claims that are not verifiable onchain: bridges (claims about the state of a different blockchain on another blockchain), data availability (i.e, verify- ing whether a data item has been published in public), censorship (not incorporating some transactions into a ledger). Another major problem with enforcing slashing onchain is that immutable code for slashing is difficult to get right - if there is any error in the code, then honest nodes may get slashed.

      Current state-of-the-art mechanisms to resolve non-onchain attributable frauds. There are two classes of mechanisms that have been proposed for this purpose of non-onchain attributable tasks:

      1. Penalize (i.e., slash) divergent claims of a node relative to the majority of the nodes. However, such a mechanism is subject to the tyranny-of-majority. If the majority of workers are dishonest, then a minority honest agent can be slashed. This is clearly unacceptable.

      2. Utilize an entrenched committee to verify the veracity of a node’s claims and issue slashing authoriza-

      tions. The problem with this model is that if the committee is malicious, they can slash honest workers. The crux of the problem here is the tyranny-of-majority (of token holders, or an entrenched committee) and, even more fundamentally, it boils down to the question of: who watches the watchers/committee?

      Both scenarios are vulnerable to tyranny-of-majority.

    2. Categorization of Faults in Digital Tasks

      We can categorize faults made while performing digital tasks into three categories based on the ability to attribute them: (i) onchain attributable fault, (ii) intersubjectively attributable faults and (iii) non-observable faults.

      The first category is objectively attributable faults - which are attributable purely mathematically and hence cryptographically. A clear example is execution validity: if a node runs a piece of code on a deterministic virtual machine, and certifies the input and output, then it can be verified onchain later. A second example of this is double-signing: in a consensus protocol, if a node is not supposed to sign two conflicting blocks but it does, then it can be proven onchain that the node has committed an onchain attributable fault. We furthermore note that the former fault (validity) is proactively attributable - for example, the chain can run a verifier for a ZK proof and ensure the correctness, whereas the latter (double-signing) is only retroactively attributable: you can prove that a node committed the fault *after* it committed the fault but not as soon as you receive a first signature.

      The second category is intersubjectively attributable faults: the set of faults which can be attributed with broad agreement by all observant outside observers. This set is a superset of purely onchain attributable faults, since anything that is attributable on chain can also be attributed offchain. We can further subdivide this category of faults into (i) retroactively attributable, which can be attributed at any point in time, vs, (ii) concurrently attributable faults, which need the observer to be online and observing at the time of the fault in order to be at- tributed. Some examples of retroactively observable intersubjective faults: (a) oracle price inputs - if the price input by a oracle node is clearly different from the actual price by a significant margin, all outside observers can come to a consensus on whether the price is correct or not, and whether the oracle should be slashed. (b) objective faults for which it is hard to write slashing conditions - as an example, running a specific instance of an AI / ML code. Some examples of concurrently observable intersubjective faults are: (c) Data availability

      - if a data item is published transparently into a peer-to-peer network or not can be attributed by all those observing the peer to peer network, (d) censorship - if a transaction that has been propagated in the peer to peer network has not been included due to a malicious collusion, then it can be intersubjectively attributed.

      The fault observability in concurrently attributable faults can be enhanced by reducing the monitoring cost of the observer so many more nodes can observe the faults. We note that this phenomenon is not unique to digital platforms, and in fact, in the breakthrough work [3] on “Governing the Commons” by Elinor Ostrom, winner of the Nobel Memorial Prize in Economics, it is observed that reducing the monitoring cost of viola- tions is a prerequisite to a well-functioning commons.

      For example, light nodes can sample portions of the data claimed available using a method called Data Availability Sampling. Light nodes can randomly sample the transactions in the p2p network (rather than monitoring all the transactions) to attribute censored transactions. Another factor that significantly boosts attributability is circumstantial evidence downstream of the digital task manipulation: for example, was an oracle manipulation then used downstream to attack a lending protocol, or if data might have been purposely withheld to pass an invalid claim through a fraud proof, or a oracle transaction censored in order to manip- ulate liquidations etc. In all of these cases, there will be strong social agreement on whether the system was purposely attacked.

      The third category of faults is not attributable outside the victim of the fault. For example, consider a secret- sharing system where anyone who wants to store a secret can split the secret into smaller chunks of infor- mation and different nodes store different subsets of the data; and the secret is revealed only after a certain amount of time. In this case, if the nodes collude together to break the privacy and reveal the secret, it is possible for the secret storer to know that his / her secret is revealed but a third party cannot disambiguate between whether the storer is malicious or the system is majority malicious. Since it is not possible to attribute and punish for these faults, it is only possible to avoid these faults by making the validators decentralized and hence collusion resistant.

      Fig. 1 illustrates the above categorization of digital tasks.

      Figure 1: Categorization of faults in digital tasks.

  2. Core Idea

    The main question that we wish to address is whether we can extend cryptoeconomic security to digital tasks on EigenLayer in the context of intersubjective faults. We answer this question in the affirmative by creating EIGEN: the universal intersubjective work token.

    1. Chain forking in Ethereum

      Before we get to the description of the protocol on how to get cryptoeconomic security for intersubjectively attributable tasks, we glean some key insights on how we escape the problem of the tyranny of majority in existing protocols like Ethereum. Ethereum has been a leader in recognizing the importance of the layers of social consensus, which surround and moderate the objective consensus mechanisms of the blockchain. Each layer reveals a form of watching the watcher, which is already implicit in Ethereum.

      We can easily distinguish two layers of consensus that are integral to the operation of Ethereum:

      1. Chain Validity

        1. which rule for determining the validity of a given chain of blocks is to be used.

        2. whether a given chain of blocks is valid, according to a given validity rule (see [4] for details).

      2. Chain canonicity

        1. which chain of blocks, valid under a given validity rule, constitutes the canonical chain at a given point in time.

      While it might seem that a majority of Ethereum validators would have carte-blanche power to completely determine the content of the canonical chain, this is not true. Suppose that the majority of Ethereum validators were to turn malicious and collude in order to sign off on a block that was invalid under the validity rule held to by the overall user community of Ethereum users. This would set in place the following sequence of events:

      1. any validator not a part of the colluding set would reject these blocks as invalid under the current validity rule.

      2. by running full nodes or by listening to the testimony of trusted full node operators, end users would be able to ascertain the basis for the appearance of two forks of the original singular chain.

      3. as one fork of the chain would be in violation of the validity rule uphold by the overall social consensus, members of this community would choose not to interact with this fork, opting instead to follow the chain being maintained by the minority set of validators.

      4. the digital assets of the majority chain would be excluded from any interface between on-chain and off-chain1, their market value would tend to zero.

        1Examples are exchanges, real-world shops where crypto is accepted as medium of exchange for physical goods, etc.

        Figure 2: A high-level overview on how intersubjective staking in EigenLayer resolves intersubjective faults without overloading ETH’s social consensus.

      5. in the event of such chain forking contingencies, Ethereum also makes special provision for an “inac- tivity leak” which would result in the colluding operators being fully slashed over the course of time in the canonical fork [5].

      Thus, on inspection we find that the influence of Ethereum validators ultimately extends only to determining which of any possible set of valid blocks should be added to the canonical chain at each moment in time. In particular, we see that there exists an easily overlooked but powerful social consensus about which protocol the validators ought to be executing (refer to step 3 above where the social consensus decides on which va- lidity rule to upheld). Even if a majority of Ethereum validators were to collude and accept a block that was invalid according to this social consensus, by simply filtering out this now erroneous fork of the chain and paying attention to the validators faithfully executing the preferred protocol of social consensus, end users can neutralize the attempted majority take-over and slash the offending validators (step 5 in the above sce- nario). See fig. 2(a) for an illustration. This is an illustration of how social consensus is protecting Ethereum ecosystem from tyranny-of-majority of the Ethereum’s validator set. Unlike the set of validators staked on the chain, a key observation is that the coverage of social consensus is the set of all possible observers, and is an unsized and potentially infinite set. Even if all the nodes that are running the software agree on a malicious fork, new nodes that come in might detect this problem and choose only to build on the truthful fork. Thus truth becomes a self-enforcing equilibrium, and becomes nearly impossible to takeover by an adversary.

    2. The Two Phases of Intersubjective Agreement

      Systems that utilize intersubjective agreement proceed in two phases usually. There is a setup phase, in which the rules of intersubjective agreement are codified, and then there is a second phase, called the execution phase, in which the pre-agreed rules are executed. As a first example, consider the establishment of a modern nation state. The setup phase comprises of codifying a constitution which all later laws must then follow. The execution phase then requires the creation of laws, which must then comply with the constitution. The clearer the constitution is, the easier it is to agree on whether a given law complies with the constitution.

      Lets take as a second example, blockchains. The setup phase for blockchains involve specifying the fork- choice rule of the consensus protocol (for example, the longest chain rule specifies that the current block is the tip of the longest chain of blocks). In the execution phase, any node can now identify, based on its

      Figure 3: An illustration of setup and execution phase for for different scenarios in government setting and blockchain setting.

      observed chain of blocks, which is the current block. Thus, the setup phase requires consensus, and later, the execution phase requires purely local information. This is an example of a powerful intersubjective sys- tem, as there is little ambiguity left to the execution phase. As a more complex example, in a proof-of-stake blockchain, there are two distinct consensus rules possible: (i) light-node-rule: accept any block header signed by 67% of the nodes, or (ii) full-node-rule: accept only blocks that you can download and that are valid and that are signed by 67% of the nodes. It is pre-agreed in the setup phase of the blockchain that the full-node- rule is the real rule, and the light-node-rule is a proxy, so when there is a disagreement between the two rules, nodes already know that they should go with the full-node rule during the execution phase.

      As another complex example, consider two distinct kinds of rollups: (a) standard rollup, where the setup phase defines the current block in the chain as the latest valid block written to the bridge contract, and a

      (b) sovereign rollup, where the setup phase defines that the current block in the chain is the latest valid block written to the bridge contract, except if it is reverted by social consensus. In the standard rollup case, the execution phase is totally self-evident: each node can find the current block directly without requiring to talk to each other. In the sovereign rollup case, it is required for the nodes to talk to each other in order to know if social consensus has reverted that block or not. The more an intersubjective system makes the execution phase self-verifiable, the stronger the intersubjective cohesion is, i.e., participants will agree on the right version of the world easier. If there is too much coordination required during the execution phase, it is possible for the system to experience intersubjective collapse, i.e., participants disagree on the right version of the world.

    3. Extending the power of social consensus beyond chain validity

      Don’t overload Ethereum’s social consensus. Given the benefit of using social consensus of Ethereum to resolve any take-over of Ethereum’s validator set to attack chain validity, an immediate step would be to extend the usage of social consensus beyond chain validity. One example of services that can benefit from using Ethereum’s social consensus to resolve tyranny-of-majority are any tasks which are potentially verifi- able such as oracles or data availability (see sec. 1.2). In such services, fraud can’t be attributed objectively by submitting any fraudproof or ZK proof as part of execution of chain state. However, the fraud is subjec- tively visible from any outisde observer. As a concrete example, if an oracle reported that 1BTC is equal to 1USD, which is far away from the real truth, this fraud is obvious from the outside. A naive solution would require Ethereum validators participate in such services (for example, the validators vote on price feeds as part of block proposal) and assume (super-)majority of Ethereum validators are honest. In case of adversarial take-over of majority of Ethereum validators to break this oracle, the social consensus of Ethereum would just subjectively step in to resolve the tyranny-of-majority of Ethereum validator set. However, the problem is that this overloads the Ethereum’s social consensus layer as any end user would now have to make decision for forking the chain for lot more digital tasks, some of which are more high-risk than others [6]. See fig. 2(b) for an illustration.

      Extending the power of social consensus. Our proposal to extend the benefit of social consensus in resolving tyranny-of-majority without overloading Ethereum is as follows:

      • Restaking: Tap into Ethereum’s social consensus only for resolving objectively attributable faults. Any digital task where fault can be objectively attributed and malicious operators can be penalised programmatically should accept only native ETH or LST as stake on EigenLayer. In such tasks, the

        dispute resolution can be programmed within the chain state as a smart contract2 and, thus, correct execution of the dispute resolution is subsumed into chain validity. Therefore, cryptoeconomic security for digital tasks with objectively attributable fault is directly tapping into Ethereum’s social consensus for resolving tyranny-of-majority of operators without overloading.

      • 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 gran- ularities 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 tokens for any potentially verifiable digital task. EIGEN provides a primitive for unconditional slashing of the EIGEN staked by malicious operators on EigenLayer through tapping into the power of EIGEN’s social consensus to canonize the fork of EIGEN token that penalizes the malicious operators without forking the Ethereum chain itself.

      EIGEN features its own social consensus for resolving intersubjective faults of potentially verifiable tasks. This responsibility of resolving intersubjective faults is now no longer being imposed on Ethereum’s social con- sensus, thus, not overloading it. Now, AVSs on EigenLayer tap into the ETH quorum for objective faults but tap into EIGEN quorum for intersubjective faults. See fig. 2(c) for an illustration. Now there could be forking in EIGEN for resolving intersubjective faults without requiring forking the chain state of Ethereum itself.

      Prior Work. The intellectual precursor to this work is the pioneering work by Vitalik Buterin documented in the Ethereum blog (circa 2014-2015): [7], [8], [9]. To the best of our knowledge, Augur built on these posts and introduced the idea of designing a token that forks at an application layer of Ethereum in the context of prediction markets [10]. In this paper, we build on this core idea to design EIGEN expanding it in several ways: (i) building a universal intersubjective token rather than a solution for a specific problem, (ii) solving how to utilize a forking token in fork-unaware applications, (iii) ensuring that the cost of social consensus is metered and the value distributed to those who partake in it, and finally (iv) designing mechanisms to utilize the intersubjective fork for compensating users against faults of the stakers, rather than only punishing them.

      EIGEN unleashes more open innovation. EigenLayer enabled anyone to create new Actively Validated Ser- vices (AVS) that have objective slashing conditions to incorporate security from ETH rather than restricting the amount of security for their AVS to be capped by its own new token, solving a major bootstrapping problem. However, there is a significant limitation that if the AVS had an intersubjective fault, it cannot resort to the cryptoeconomics of ETH but is forced to use its own token because its own native token at least inherits token toxicity (a downward price pressure if a majority of the token stakers act). In our previous work [11], we showed that token toxicity is insufficient under adversarial circumstances to be protective, and slashing is indeed necessary. In this work, we create the first universally intersubjectively slashable system, so that stakers can make a wide range of commitments about the digital work that they perform. This en- ables a wide range of new AVSs to utilize the cryptoeconomics of EIGEN without being capped to their own economic value. We envision a renaissance in the design of new services structured as AVSs utilizing EIGEN cryptoeconomic security, in addition to ETH security. Any Actively Validated Service (AVS) on EigenLayer which has intersubjectively attributable digital faults can now obtain the cryptoeconomic safety guarantee of EIGEN. In order to make the faults intersubjectively attributable, the AVS may need to focus on developing robust monitoring infrastructure including light clients. This can lower the cost-of-monitoring, ensuring that there will be a wide net of community members from EIGEN’s social consensus who will operating the AVS’s light node software for monitoring the EigenLayer operators who are opted into the AVS.

      The importance of comprehensiveness of setup phase reflects the need for any AVS that is using intersubjec- tive staking to be very clear on their constitution that they adopt during setup phase. That means specifying, without any ambiguity, under what conditions/scenarios can a staker be considered to be malicious and subjected to intersubjective slashing. For example, if an AVS developer wants to run a rollup VM using intersubjective staking without deploying any dispute resolution contract3 on Ethereum, then the AVS must specify which version of the VM code should any operators opted into the AVS run. More deterministic this VM is, less likely that there will be confusion if there is challenge against operators giving wrong output to the VM execution.

      2Any evidence of objective fault can be submitted as a fraudproof or ZK proof to the chain. Here, the assumption is that there is at least one honest participant who will submit this evidence. This submission of evidence will be subjected to Ethereum’s censorship- resistance.

      3ZK verifier contract or optimistic challenge contract

    4. Interaction between intersubjective staking and DeFi

      1. Existing PoS protocols

        Any PoS protocol features only a limited amount of their native tokens being staked at any given time, while the remaining tokens are utilized for other purposes such as DeFi, or users holding the staking token without deploying it. A similar scenario is expected to happen with EIGEN. In this section, we will try to under- standing how intersubjective (forking) nature of EIGEN makes the interaction bit complex. To understand this interaction, we will understand the interaction in two existing protocols.

        We note that in chains like Ethereum, the native ETH token forks along with the chain, so as long as the ETH is deployed into DeFi protocols deployed in the same chain, the protocols always the right version of the ETH. We coin the term intersubjective frame-of-reference, in order to understand from which frame forking is happening. Protocols and (standard) tokens that share chain fork together when the underlying chain forks, so they can be said to inherit the intersubjective frame of reference from the chain. With EIGEN, the token has its own intersubjective frame of reference, so if the token forks, DeFi protocols may not know that it has forked, and will need to handle it with care. This consideration is shown in Fig. 5a.

      2. Solid representation: Isolation barrier between intersubjective staking and DeFi

        Interaction between intersubjective staking of EIGEN and using EIGEN of DeFi is 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 have agreed upon a new canonical fork but the EIGEN which were locked in non-staking applications such as DeFi would be still representing the stale version of EIGEN token from before the fork. In order to solve this problem, we propose creating an isolation chamber between the DeFi usecases of EIGEN and the staking usecases of EIGEN. We term a representation of EIGEN as a solid representation, if that representation can be redeemed for whichever fork of the underlying EIGEN token that the holder desires. See fig. 5a for an illustration.

        In order to achieve solid representation for EIGEN, we proposed 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 which imparts the behavior corresponding to a solid representation. 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.

    5. Compensating for the Cost of Intersubjective Consensus

      We observe that intersubjective (social) consensus incurs a cost, and if it is not metered properly gives rise to two kinds of problems: (i) if it is free, then it might lead to grieving attacks, where someone tries to abuse social consensus without incuring a cost, and (ii) if the users who participate in social consensus are not correctly compensated, then it might lead to users not participating in it. These two lead to core principles: (i) anyone who tries to fork the token should incur a cost, and (ii) some portion of the cost should be distributed to users who participate in social consensus.

      We formalize this by requiring two types of economic costs in the original token bEIGEN1 and the forked token bEIGEN2:

      • Deflation-per-fork (DPF). DPF represents the minimum fraction of total bEIGEN1 that should be tagged as malicious and slashed while creating the fork bEIGEN2. If bEIGEN2 ends up being considered as the

        canonical fork, then each unit of bEIGEN2 would appreciate by 1



        multiplication factor. If the chal-

        lenger intersubjective challenge isn’t slashing at least DPF fraction of total bEIGEN1, then that challenge will not be considered legitimate.

      • Commitment-per-fork (CPF). CPF represents the ratio between total bEIGEN1 that needs to be committed by the challenger for triggering the intersubjective challenge. Here commitment refers to the fact that the challenger will burn CPF fraction of bEIGEN1 so that they cannot access this portion of tokens if the original token bEIGEN1 is continued to be considered the cnaonical fork. The challenger will in return be able to redeem these tokens if bEIGEN2 is the correct version of the fork. An important to note is

      Figure 4: Simple illustration of CPF and DPF. Here bEIGEN2 is a fork of bEIGEN1 as a consequence of an intersubjective challenge.

      that the challenger has to be convinced of the intersubjective fault that has happened as it is burning its bEIGEN1 holdings and is betting on the value extracted from the bEIGEN2 that it is getting as part of the challenger reward. So, anyone harmed by the intersubjective fault in the AVS has the highest incentive to raise the challenge.

      Both the parameters DPF and CPF are enshrined in the setup phase of EIGEN token. Setting the values of DPF

      and CPF properly is critical to ensuring the healthy functioning of the system.

      Here, DPF pays off the cost for the social consensus to switch from bEIGEN1 to bEIGEN2. This switching cost comes in the form of the need for the social consensus to validate the claim of intersubjective fault, gas cost of redeeming bEIGEN2, gas cost of against staking bEIGEN2, etc. On the other hand, CPF acts as a deterrence against any adversary raising vacuous intersubjective challenge. Even in the case of vacuous intersubjective challenges, anyone participating in the social consensus has to verify the authenticity of the fault before rejecting the challenge, which incurs a cost. CPF serves as a mechansim to pay off for that social cost. See fig. 4 for an illustration.

      1. Setting values for CPF and DPF

        CPF pays off for the social cost of malicious fork, acting as a deterrent against an adversary raising vacuous challenges and requiring everyone in the social consensus to verify the authenticity of the challenge and re- ject it. If CPF is set too large then there is a need for large off-chain coordination to pool enough bEIGEN1 for raising the intersubjective challenge. This sets an upper bound on the value of CPF.

        On the other hand, DPF pays off the cost for the social consensus to switch from bEIGEN1 to bEIGEN2. This switching cost comes in the form of the need for the social consensus to validate the claim of intersubjective fault, gas cost of redeeming bEIGEN2, gas cost of against staking bEIGEN2, etc. The deflation is created because there is some amount of stake slashed in the forked token. Therefore, if DPF set too high, then it imposes a requirement on the AVS that at least DPF fraction of stake is attributable and slashable when a fault happens on the AVS. This sets an upper bound for DPF.

    6. Overview of protocol for intersubjective staking on EigenLayer

      Next, we will give a very high-level explanation for the intersubjective staking on EigenLayer.

      1. Naive Design

        We start with a baseline design for the intersubjective protocol that features a single token model. This is described as follows:

        1. Intersubjective staking with EIGEN. Stakers stake the EIGEN for staking into EigenLayer. By staking EIGEN, the staker is opting to respond to digital tasks and subjecting its stake to intersubjective slashing.

          1. Simple illustration of solid representation.

          2. A simplified illustration of V1. Here, bEIGEN2 is fork of bEIGEN1 after the intersubjective challenge is raised.

          3. An simplified illustration of V2. Here, bEIGEN2 and EIGEN2 are corresponding forks of bEIGEN1 and EIGEN1 after the intersubjective challenge is raised.

            Figure 5: Overview of the intersubjective forking protocol that is being enabled by EIGEN.

            Here, EIGEN is an ERC20 token. The staking contract ensures that withdrawal from staking is subject to a withdrawal lag - this lag is important as it allows a time period for the token to fork before affecting other holders.

        2. Intersubjective forking and intersubjective slashing. In order to raise a challenge against an intersub- jectively attributable fault, the challenger must burn some amount of EIGEN and intersubjectively fork EIGEN. Intersubjectively forking the EIGEN requires the challenger to deploy: (a) a new ERC20 contract that represents a new fork of EIGEN (recall that the existing EIGEN was also an ERC20 contract) and, (b) a fork distributor (FD) smart contract that specifies how stakers and other holders of existing EIGEN can redeem tokens from this new ERC20 contract. We call this new ERC20 contract as a fork of EIGEN. This FD should allow stakers delegated to honest operators and the challenger to claim token from this new fork of EIGEN whereas stakers delegated to malicious operators should not be able to redeem tokens from the new fork. For simplicity of explanation, we call the tokens from pre-forked EIGEN as EIGEN1 and post-forked EIGEN as EIGEN2.

        3. Redemption mechanism. The FD also specifies how a non-staked holder can redeem the fork. Any holder of EIGEN1 is able to redeem EIGEN2 by locking their EIGEN1 in the FD of EIGEN2 for a period of Tlock slots. This redemption is permitted for a period of Tredeem slots after the attack has happened. Note that here it is necessary to have Tlock > Tredeem in order to avoid the issue of double redemption4.

          By including the details on who is not able to redeem EIGEN2 tokens, the challenger is effectively slashing certain existing stakers who had staked EIGEN1. This slashing is intersubjective in nature as others might not agree with the challenger and can ignore the EIGEN2. In such a case, EIGEN1 will continue to be held as the canonical fork of EIGEN by the social consensus. Therefore, we call such a slashing as intersubjective slashing. Ideally, the challenger should deploy the EIGEN2 and its FD after deliberation with rest of social consensus.

          Lack of ”Solid representation”. The baseline design lacks ”solid representation”. If an EIGEN1 holder is not active for the period of Tredeem slots after the malicious attack was executed by operators, then the holder will never be able to redeem EIGEN2. Therefor, the baseline design doesn’t offer solid representation. In the next few sections, we will give a high-level outline an intersubjective forking protocol that will progressively achieve this property. We also want the intersubjective protocol to be resilient against malicious behavior of the security council5 of the staking contract.

      2. V1: Two-token model for the intersubjective staking protocol

        Following is the high-level overview of V1 version of the intersubjective forking protocol on EigenLayer. For full description of V1, please refer to Appendix. A.1.

        1. The protocol has two separate tokens but with different functionalities: bEIGEN and EIGEN. The bEIGEN is used for staking and the EIGEN is used for non-staking applications. The EIGEN contract is a wrapper on top of bEIGEN.

        2. Any challenge against an intersubjective fault requires submission of challenge bond along with the forking of bEIGEN and its associated FD contract (see sec. A.1.2 for details).

        3. The governance of EIGEN contract makes decisions on which fork of bEIGEN should the EIGEN wrapper configure to and then pushes for an upgrade which is subjected to a governance lag (see sec. A.1.3 for details).

        4. Anyone can instantly wrap bEIGEN to get EIGEN and instantly unwrap from EIGEN to bEIGEN. Unwrap- ping will return the current fork of bEIGEN that the EIGEN wrapper is configured to. As for wrapping, the EIGEN wrapper contract will only accept the current fork of bEIGEN that the wrapper is configured to (see sec. A.1.3 for details).

        5. Any withdrawal from staking bEIGEN is subjected to a withdrawal lag. Withdrawal can be done directly from the staking contract or via the UI (see sec. A.1.1 for details).

        6. For any new legitimate fork of bEIGEN, there is a limited redemption period for redeeming tokens belonging to the new fork of bEIGEN. To redeem post-forked bEIGEN, the holder of pre-forked bEIGEN

          4By ”double redemption”, we mean that for the same 1 unit of EIGEN1 token, the holder or staker shouldn’t be able to redeem more than 1 unit of EIGEN2 token.

          5We partition the governance of the staking contract into two parts: (1) governance for regular contract upgrades for adding new

          features and will have lags in place for these upgrades, (2) security council for triggering emergency upgrades or pausing. Clearly, the security council has a lot of power.

          has to lock its tokens for a limited period (see sec. A.1.4 for details). The EIGEN holders can be passive if it agrees with the decision of EIGEN governance. However, if it doesn’t, then the holder has time to unwrap to bEIGEN during the governance lag period (see sec. A.1.5 for details).

          See fig. 5b for a high-level illustration.

          V1 makes the following assumptions:

          1. Governance of EIGEN wrapping contract is honest, or, EIGEN holders are engaged in non-staking activi- ties have not locked their token for more than a certain period.

          2. Security council governing EIGEN staking contract is honest.

          If the governance of staking contract is honest, then EIGEN will always point to the right version of bEIGEN. However, if the governance is not honest, and the EIGEN wrapper’s governance decides to reconfigure to a new fork of bEIGEN which EIGEN holder disagrees with, then this EIGEN holder can unwrap to their bEIGEN and then redeem the correct fork. However, if they are locked for more than the redemption period, then they will not have this ability to redeem the right fork, even when governance is dishonest.

          If the security council governing the staking contract is malicious, then they can take the staked amounts and convert them without imposing a temporal lag. The core reason for this problem is that the temporal lag is enforced by the staking contract rather than being enforced unconditionally.

          See lemma 1 for further details. With some additional upgrade in V2 as described in next section, we achieve solid representation.

      3. V2: Getting solid representation

        In addition to the features described for V1, we certain new features to achieve solid representation in V2. For full description of V2, please refer to Appendix. A.2.

        1. The wrapper contract EIGEN is now immutable contract. This immutability requires that the wrapper EIGEN contract can now also be forked socially. A legitimate intersubjective challenge now requires forking EIGEN which is in addition of forking bEIGEN and launching FD contract. See sec. A.2.2 for details.

        2. A legitimate intersubjective challenge against an intersubjectively attributable fault must also stop fur- ther wrapping in the canonical pre-forked EIGEN to pre-forked bEIGEN. See sec. A.2.1 for details.

        3. An additional redemption clause is added to get solid representation. Suppose a pre-fork EIGEN holder has unwrapped to pre-forked bEIGEN after the redemption period of post-forked bEIGEN is over. This unwrapping action is recorded in the storage of the pre-forked EIGEN contract. Now, this user can just submit the proof of this unwrapping to be able to redeem post-forked EIGEN. See sec. A.2.3 for details.

          See fig. 5c for a high-level illustration.

      4. V3: Making intersubjective staking protocol resilient to corruption of security council

        To make the protocol resilient to an attack by the security council governing the staking contracts, we can add a separate lag via an immutable gateway contract.

        In addition to the features in V3, following are the additional features:

        1. All staking and withdrawal is done by a governance-free gateway contract. Only the accounting is done in the staking contract. The withdrawal lag is now imposed by the gateway contract and anyone can raise a challenge that stops withdrawal if there is a malicious withdrawal by the security council of staking contract’s governance.

          For further details on the full description of V3, please refer to Appendix. A.3.

      5. Summary

        Following table summarizes the differences between different protocols:

        Solid representation

        Resilient against a malicious security council?










  3. Intersubjective Staking for Actively Validated Services

    EigenLayer enables services beyond consensus to inherit security from a shared security system, which com- prises of a pool of stake as well as operators, who are equipped to run various software. These services are called as actively validated servies (AVSs) and there is a wide variety of AVSs including new chains, data availability (DA) layers, oracles, verifier-as-a-service, fast-finality-layer, and coprocessors.

    In this section, we talk about how EigenLayer can be used to share security across AVSs using intersubjective staking. When an intersubjective token such as bEIGEN is staked, in the event of fork in bEIGEN, the AVS has to decide whether it wants to accept the new fork of bEIGEN or not. This leads to a new complexity that was not present when staking objective tokens like ETH and other ERC20 tokens in EigenLayer.

    In the next section, we consider the case when there is only one AVS using bEIGEN for intersubjective staking and describe how this AVS handles forking of bEIGEN. For the purpose of explanation, we represent the canonical bEIGEN before the intersubjective challenge as bEIGEN1 and the new fork of bEIGEN arising out of the challenge as bEIGEN2.

    1. Single AVS with Intersubjective Staking

      Figure 6: An illustration of how AVSs would handle intersubjective forking,

      Consider a single AVS that is built on top of intersubjective staking of bEIGEN. We note that in the two-token system explained earlier, bEIGEN is the staking token, which needs to be fork-aware and EIGEN is the fork- unaware token which can be used in non-staking applications. Let us consider the initial case where bEIGEN1 is staked into a single AVS and no other AVSs are present.

      Suppose that some of the stakers are attributed to have participated in an intersubjective fault in the AVS. This results in bEIGEN1 being subjected to an intersubjective challenge, and a new fork bEIGEN2. The governance of the AVS now needs to make a decision on whether to accept bEIGEN2 for intersubjective staking or not and to enact that policy at the smart-contract-level. At any point in time, it is natural for the AVS governance to accept only one fork of the bEIGEN depending on whether the forked token is correct or the original one is correct.

      Assume that the governance of the AVS agrees with the intersubjective challenge and the forking. See fig. 6 for a timing diagram. In order to ensure that the stakers have enough time to redeem bEIGEN2 and opt into the AVS with the new bEIGEN2 quorum, there is a need for governance lag before the AVS starts accepting bEIGEN2. Furthermore, the lag before opting into a fork ensures that AVS users who do not agree with the fork can gracefully move on to a different AVS that actually accepts the correct fork. Therefore, the AVS governance must make an announcement that after Tredeem slots since the attack was executed:

      After Tredeem slots from the attack, the AVS will accept only bEIGEN2 stake (instead of bEIGEN1).

      The governance will have to queue a governance upgrade for this decision soon after the intersubjective challenge of bEIGEN is finalized on Ethereum and this upgrade will be executed at Tredeem slots from when the attack was executed. During the interval of Tredeem slots since the attack happened, any bEIGEN1 staker who agrees with the intersubjective challenge will be able to redeem bEIGEN2 from its associated FD and then again stake with EigenLayer and opt into the AVS. On the other hand, those bEIGEN1 stakers who don’t agree with the AVS governance’s decision would be able to simply opt out of the AVS.

      In the intervening period, bEIGEN1 stakers are still responsible for runnning the AVS. This is important, because, in case the challenge is malicious and the AVS governance is malicious, the AVS users are still protected by bEIGEN1 staking. On the other hand, if the challenge and the AVS governance are correct, then the bEIGEN1 stakers may engage in continued malicious behavior. Therefore, when performing a cryptoeconomic analysis, it is important to ensure that the penalty incurred by the bEIGEN1 stakers is greater than the harm that they can inflict throughout this Tredeem period.

    2. Cryptoeconomic Analysis of Intersubjective Staking

      In this section, we will analyze the cryptoeconomic guarantees of the intersubjective staking continuing on the single AVS case.

      1. Pooled security for Single AVS

        In the case of when there is only a single AVS using the EIGEN quorum, profit-from-corruption is computed by evaluating the total cost that all the consumers on top of the AVS will incur in a period of length Tredeem slots if the malicious operators attack. We note that this is because, the AVS is allowed to switch to a different quorum only after the Tredeem period, which is important to ensure AVS users are protected in case of a malicious challenge (see sec.3.1 for details). In case that the challenge is correct, though, the malicious operator with bEIGEN1 stake can continue to attack the AVS during this period.

        Therefore, for the AVS to be considered to be cryptoeconomically secure, it is essential that:

        Cost-of-corrupting the AVS Profit-from-corrupting the AVS in any interval of length Tredeem slots (1)


        The cost of corrupting the AVS is measured by the amount of stake that is slashable. For any AVS, it is possible to calculate the fraction of stake that is attributable as malicious if there was any safety violation in the AVS. We call this parameter Fraction-slashable-for-AVS, emphasizing that this parameter depends on the structure of the AVS. For example, for a standard BFT consensus protocol with quorum threshold 2 , the


        Fraction-slashable-for-AVS is 1 [12].

        Cost-of-corrupting the AVS = Stake slashable for AVS safety failure (2)

        = Fraction-slashable-for-AVS × Amount-staked (3)

        Recall that cost-of-corruption is defined as the cost incurred by any adversary to attack a system. From the definition of DPF, it is evident that the adversarial stake can be slashed in an AVS only if at least DPF fraction of total bEIGEN1 has behaved maliciously in the AVS. Therefore, we must have

        Fraction-slashable-for-AVS × Amount-staked DPF × Value(bEIGEN1), (4)

        ⇐⇒ Fraction-slashable-for-AVS × Fraction-staked DPF. (5)

        Satisfying this condition will ensure that a ”socially” legitimate intersubjective challenge can be raised to slash adversarial bEIGEN1 stake via intersubjective forking.

      2. Attributable Security for Single AVS

        An important caveat for pooled security is that it is not possible for the EigenLayer protocol to know the profit-from-corruption for the AVS. So, there is no in-protocol guarantee whether the security invariant in eq. 1 is being satisfied or not. Moreover, assuming eq. 1 is satisfied, even if the malicious operators’s stake is slashed in the event of attack, there is no redistribution to the harmed parties: AVS and consumers of AVS. An important primitive that we want to achieve is

        Strong Cryptoeconomic Security

        Any honest users should be appropriately compensated in the event that the AVS stakers behave maliciously.

        We call this guarantee as strong cryptoeconomic security and design a mechanism to actually satisfy this prop- erty. This notion was introduced in [13] and analysed for a single proof of stake system. Here we extend it to intersubjective staking for a single AVS and in later sections to multiple AVSs.

        Consider that there is a legitimate intersubjective forking from bEIGEN1 to bEIGEN2. See fig. 7 for an il- lustration. In the pooled security model, all of the adversarial stake is slashed and burnt. Instead, in the attributable security mechansism, only a fraction of the adversarial stake is burnt by the FD of bEIGEN2 (that is, remains non-redeemable under bEIGEN2’s redemption mechanism). The remaining adversarial stake is instead redistributed to the harmed AVS. In the general case where there are multiple AVSs, a mechanism is needed to apportion the redistribution across the various AVSs. However, in the case of a single AVS, all of the redistributed funds will obviously go to that AVS.

        Even though redistribution is the key property we seek here, the mechanism ensures that there is a portion of adversarial stake that is burnt during the fork. This is necessary for mitigating any grieving attack, where an adversary represents all the malcious stake but also holds redistribution claims for the AVS, thus making sure it does not suffer any loss. This strategy becomes unprofitable with the burning mechansism as a portion of the stake is burnt and not returned to the redistribution. Furthermore, a portion of the stake has to be burnt in order to satisfy the deflation conditoin for the fork, to pay off for the social cost of forking.

        DPF × value(bEIGEN1) ≤ γburn × Stake-slashable. (6)

        ⇐⇒ DPF γburn × Fraction-slashable-for-AVS × Fraction-staked (7)

        When slashing happens, out of the amount slashed, γburn is burnt and γ = 1 γburn is redistributed to the AVS. Therefore

        Attributable-security = γ × Stake slashable for an AVS safety fault (8)

        = γ × Fraction-slashable-for-AVS × Amount-staked (9)

        For the system to be strongly cryptoeconomically secure, we need the attributable security to be greater than the harm that any user of the AVS can suffer during the entire Tredeem period. This is because, switching from one fork of bEIGEN to the other incurs a delay of Tredeem, and the adversarial stake can cause harm throughput this Tredeem period. We need for strong cryptoeconomic security,

        Attributable-security Harm-from-corruption for AVS in Tredeem period. (10)

        Example 1: As a simple example, consider a fast bridge AVS for a rollup, which has a (X, T)-rate-limit, i.e., that it does not allow more than X total transaction value in any T period. Now if the bridge had (X, Tredeem) as the rate-limit, then we know that the total value transacted by the bridge is less than X during any attack

        period, and therefore the harm from corruption for the Tredeem period is less than or equal to X. If the attributable security is greater than X then this AVS works correctly. For this example, then we have the following condition for strong cryptoeconommic safety.

        γ × Fraction-slashable-for-AVS × Amount-staked X. (11)

        Example 2: Consider an oracle for price feed that requires any operator participating in the oracle to re- spond with the price feed at every fixed time. These operators are required to stake bEIGEN1 in order to participate in the oracle (we assumed that the pre-forked bEIGEN is called as bEIGEN1 and post-forked bEIGEN is called as bEIGEN2). In the event that operators behave maliciously that impacts the price-feed from the oracle, then bEIGEN1 will be intersubjectively forked to bEIGEN2. Under attributable security, the oracle must beforehand evaluate the profit that any malicious operators can extract by corrupting the price feed over the next period of length Tredeem slots (here the oracle is designed to not pause when a challenge is raised but instead continues to use bEIGEN1 as the stake until the redemption period of bEIGEN2 is over). The adversary will extract this profit from the Dapps or co-processors who might utilize this corrupted price feed. The oracle has to purchase attributable security equal to this profit every Tredeem slots (assuming this is less than γ × Value of total number of bEIGEN1 staked). The oracle must utilize some form of circuit breakers to ensure that, over the course of a period of Tredeem slots, the Dapps and co-processors who are sourcing their on-chain price feed from this oracle can be harmed at max the attributable security that it purchased. This ensures all

        users of the oracle are compensated for the harm that has been caused to them due to the attack.

      3. Multiple AVS Case: Synchronized Quorum Forking

        One of the core features of EigenLayer is to have same stake to be used for multiple AVSs which enables capital efficiency, while ensuring that the cost-of-corruption in EigenLayer remains greater than the profit- from-corruption. We want to have the similar feature for intersubjective staking.

        Figure 7: Assume that there are 7 stakers with equal stake of bEIGEN1 who are opted into the AVS and self- delegated to themselves. Consider that stakers 2, 3, 4, 6 participated in an attack that successfully corrupted the AVS. Here, γburn represents the fraction of total stake delegated to an operator that is earmarked for burning if the operator gets slashed. γ represents the fraction of total stake delegated to the operator that is earmarked to be claimable by the AVS in the event of the operator gets slashed in any intersubjective fault of the AVS.

        Consider that there are multiple AVSs who are using bEIGEN1 as their quorum for resolving intersubjective faults in their AVS. Suppose that bEIGEN1 is subjected to an intersubjective challenge for a fault in one of the AVS, say AVSk, which results in a new fork bEIGEN2. Consider any other AVS AVSj. If the governance of AVSj agrees with both the intersubjective challenge in the context of a fault in AVSk and with the fork, then the AVSj governance must make an announcement that:

        After Tredeem slots from the attack, the AVS will accept only bEIGEN2 stake (instead of bEIGEN1).

        This governnace upgrade for this should be queued as soon as the transaction for the intersubjective challenge is finalized. The interesting thing with this policy is that all of the AVS switches to the new quorum at the same time, which is Tredeem time slots after the attack.

        There are lots of complex timing games, where an attacker may attack an AVS and then, while that AVS is transitioning to a forked quorum (within the Tredeem period), attack a different AVS. We need to make sure that both in the pooled security and attributable security case, this effect is accounted for.

        In the next section, we will analyze the pooled security of intersubjective staking under multiple AVSs. There is a general case of where some stakers are opted into some AVSs. But, for the simplicity of explanation, here we only consider Full Staking: every operator in the bEIGEN1 quorum is opted into every AVS. The set of AVSs who are considered to be part of full staking are assumed to be whitelisted by the EigenDAO. We leave the analysis for the general setting for future research.

      4. Pooled Security for multiple AVSs under Full Staking

        We take a very conservative action that if an EigenLayer operator who has in the bEIGEN1 quorum behaves maliciously in an intersubjective fault in one AVS, then the bEIGEN1 stake of that operator is completely slashed and burnt.

        Cost-of-corruption-for-AVSi = Fraction-slashable-for-AVSi × Amount-staked (12) To attack the system, the attacker needs to attack at least one AVS. Thus a simple bound says,


        Cost-of-system-corruption = {min Fraction-slashable-for-AVS } × Amount-staked (13)


        Hence the system is cryptoeconomically safe as long as the following security invariant is guaranteed:


        Profit-from-corrupting AVSi in an interval of length Tredeem slots. (14)


        We note that we need to make sure that the amount slashed and burnt satisfies the DPF constraints for forking, i.e., the amount burnt should be greater than a DPF fraction.