EigenLayer Protocol Governance (Part II)

[mdesim01]

PART II: EIGENLAYER GOVERNANCE STRUCTURE

In Part I: EigenLayer Governance Values, I presented what I believe to be an appropriate set of values for governing EigenLayer. The TLDR of that post is that EigenLayer should strive to implement a governance system that upholds the values of Ethereum itself—namely, Decentralization, Transparency, Inclusivity, Security, Flexibility, and Community.

In this post, I’ll get the ball rolling on community discussion around what EigenLayer’s governance structure should look like to uphold these values.

Why Should EigenLayer Protocol Progressively Decentralize?

As far as I’m aware, up to this point, the EigenLayer Team (LayrLabs) has been largely responsible for the development of the core EigenLayer protocol (as well as EigenDA) that is anticipated to be launched sometime in the next few months, but it is not without major thought contributions/insights from various people in the Ethereum community. While the centralized approach to governance of EigenLayer is absolutely appropriate today, prior to launch, and in the short term, there are arguments to be made for methodical, progressive decentralization rather soon after launch (if not immediately upon launch):

• As EigenLayer launches and inevitably gains more traction and is relied upon by many AVSs, the efforts needed to maintain the protocol and ensure its security and stability will only increase over time, thus requiring additional labor/contributions.
• Assuming that the EigenLayer protocol will collect a fee (this is an unconfirmed assumption and may thus be an incorrect assumption), there will be a continued expectation from ETH restakers, AVSs, and AVS users that the protocol will decentralize over time and distribute its generated fees in a way that is value accretive to the protocol (as seems to be the expectation from any protocol/product built on Ethereum or Layer 1s these days). Over time, if the EigenLayer Team does not decentralize and distribute its generated fees in a way that is community-aligned, it seems quite possible that another restaking protocol could come onto the scene and offer similar services but with incentives that draw restakers and/or AVSs away from EigenLayer.

What Inspiration Can Be Derived from Corporations?

As much as we in the crypto space like to rag on corporations, let’s be real–the efficient coordination of complex production at scale has largely been made possible by corporate hierarchical management structures that organize labor. Within this hierarchy, seniority should ideally reflect an employee’s competence and the company’s level of confidence in them. The more competent an employee is deemed to be, the greater their responsibility, influence, and compensation.

To facilitate a meritocratic division of labor and authority, EigenLayer should aspire to implement a governance structure in which decision-making power is based on a fairly assessed contribution of value, while still maintaining the values of decentralization, transparency, and inclusivity.

Therefore, we start at assessing valuable work performed for the EigenLayer protocol.

Why Introduce an EigenLayer Token? Why Introduce Reputation?

What I’m about to propose below is heavily influenced by prior work done by the folks at Colony. If you ask me, they are masters in the DAO space, and have been heads-down building what I think has the potential to become a revolutionary framework on which DAOs can build (see the Colony whitepaper here for reference). I believe that the DAO framework that the Colony team is building can and should be used by EigenLayer if the EigenLayer team is considering progressive decentralization.

Let me explain what I had in mind longer term for EigenLayer:

I propose that ETH-denominated fees paid to the EigenLayer protocol be deposited into a Treasury managed by an EigenLayer DAO and that, for every amount of ETH that goes into the EigenLayer Treasury, the EigenLayer Governance and Reputation System automatically mints a proportional amount of its own ERC20-compatible native token.

Contributors to the EigenLayer protocol receive compensation from the EigenLayer Treasury in ETH and receive an equal amount of EigenLayer’s native token. When compensation is received in EigenLayer’s native token, the recipient is also rewarded with Reputation for their contributions within the specific domain of expertise in which they were compensated. Reputation serves as a measure of a member’s historical contributions and helps to ensure that contributors are fairly compensated. A contributor’s Reputation in a particular domain of expertise corresponds to their decision-making power within that domain. Reputation is non-transferable and gradually decays over time to reflect recent contributions that benefit the EigenLayer protocol. Due to the complexity of calculations involved, Reputation updates require use of a DAO Framework like Colony (upon which this proposed concept is based) or a similar Reputation System AVS secured by restaked ETH to underwrite the accuracy of on-chain updates to contributors’ Reputation.

While it may be advantageous in some contexts to just directly use the ETH fees that the EigenLayer Treasury accrues in order to track Reputation (instead of using a native token specific to EigenLayer), it’s worth noting that doing so would weaken the incentive alignment underpinning the game theoretic security of the EigenLayer protocol, in that the value of ETH is not 100% tied to the performance/value of the EigenLayer protocol. Conversely, EigenLayer’s performance/value should be considered to be tied quite heavily to the performance of ETH, thus lending some credence to the idea that the EigenLayer DAO should mandate maintenance of a certain % (if not all) of its total Treasury in ETH.

It also may be argued that payments in both ETH and EigenLayer’s native token to assign Reputation (rather than just EigenLayer’s native token) would be beneficial; however, doing so could feasibly result in tricky exchange-rate problems, such as incentives to receive more of a less valuable token to earn more Reputation.

Below is just one simple example of how such a Decentralized, Reputation-Weighted Governance System could be beneficial to EigenLayer:

If the EigenLayer DAO approved the payment of its native token to smart contract security auditors for auditing AVS contracts built on EigenLayer, the recipient contract security auditor would also receive some amount of Reputation in the Contract Security Auditing Domain (over time, the granularity of the domain of expertise can be increased further; for example, to identify Reputation in just auditing oracle services or just auditing bridging services). This Reputation in the Contract Security Auditing Domain would then be used to assign variable-weighted veto powers to auditors to veto unintended or malicious slashing events triggered by AVSs built on EigenLayer; this concept of a time-decaying reputation-weighted slashing veto power is generally consistent (and arguably more value-aligned) with the EigenLayer team’s plan to elect a Slashing Veto Committee, which is ultimately needed due to the fact that the slashing contracts are immutable on the Ethereum chain.

But What About Voting?

While a governance framework like Colony encourages the use of reputation as the primary sibyl-resistance mechanism, there are situations where tokens are more appropriate. Specifically, if reputation is a proxy for “labor”, and tokens are a proxy “capital” or “investors”, then token-weighted voting is appropriate whenever a decision must be made by capital, rather than by labor.

Nonetheless, it would be expected that day-to-day operation and maintenance of a decentralized EigenLayer protocol would be done via decisions made by “labor”—those having accrued Reputation for the contributions to the protocol in their given Domains of Expertise.

As is the case with Ethereum governance, it should be the goal for EigenLayer to make as many decisions as possible on the basis of rough consensus. Under the proposed reputation-based governance framework, EigenLayer contributors are expected to monitor each other’s behavior but should only need to intervene in rare cases in which there’s a need to dispute another contributor’s attempted on-chain conduct, in which case the suspecting contributor can attempt to intervene with a motion. In this framework, the motions system is a self-regulating mechanism that incentivizes contributors through a balanced system of rewards and punishments, promoting coordination/communication and deterring bad behavior and fraud.

Now, I know that this opens the door to a whole slew of questions, as a lot of what is presented above is a bit vague…but this is mainly just intended to get the juices flowing and get people talking more about the future EigenLayer governance. This is a governance forum after all, so let’s get the discussion going!

Cheers!

[CryptoBanker]

Really great thoughts, thanks for posting!

EigenLayer is definitely aiming to decentralize over time, and we certainly appreciate both ideas on how to approach the process + visions for the future, like those you’ve provided.

I personally think a progressive approach to decentralization is the only reasonable or responsible approach – people love to imagine “just launching governance”, but that is not realistic – you have to build the community, help educate and prepare people, and build the tools for governance to succeed, which all aligns with a gradual diffusion of power & responsibility rather than some sudden radical shift. It sounds to me like the reputation-based system you’re suggesting would facilitate this shift, which is a really cool and exciting idea! Especially enjoying the idea of reputation decaying over time, as a way to ensure that people have to keep contributing to maintain the same power.

A couple questions I have about your ideas:

1. How do you envision Reputation points being assigned? Seems necessarily somewhat subjective to me, but I’d be curious to hear any ideas you may have on more objective criteria. I believe Optimism has made some efforts at retroactive funding, which this certainly brings to mind.
2. Relatedly, your idea that reputation updates could themselves be done by an “Reputation System AVS” raises an interesting kind of “bootstrapping” problem. I get the sense that such a system continue fine after an initial startup process, but do think it may present some security issues (e.g. does the restaked value on this AVS then effectively cap the total economic security that EigenLayer can offer?).
3. How do you envision duties being delegated? Seems like you are perhaps imagining something like different spheres of responsibility falling primarily to small groups / individuals, but with some delay to take effect, where a larger contingent can then “veto” or otherwise cancel the planned action?

[sam.omw1]

very interesting stuff

after watching different podcast from sreeram, there is a topic that came back on the table so would like to make a small summary about it and share some thoughts :

“but hey sreeram you will need to launch a token in order to ensure eigenlayer decentralization, dont you ?”

from my understanding (maybe im wrong), the way sreeram answers about it is to consider that eigenlayer is “just” pushing the rate of innovation of ethereum and allowing a free market between builders and stakers so a token is not necesarily needed and even consider that a token could incentives people to buy a large amount of the supply and so the gowernance power of the protocol could be in the hand of some people only.

i can definitely agree with the first part but not really with the second one and a good way to think about it is to take AAVE governance as example, how does it work and how would it look like for eigenlayer :

1- there is a period for a specific topic discussion that is fixed in advance, as mentionned by mdesim01, in the case of eigenlayer we could imagine an eigenlayer dao where there could be people from this dao to condense the different debates (maybe each week ?).
it’s obvious that it has to be filtered before going to the vote step, doesnt really make sense to have vote for question like “should sreeram wear red shoes today ?” with all due respect sreeram
so yeah, anyone could participate in the first step aka writing threads on the governance forum.

2- once filter is done, second step is a snapshot vote, to create it you need to have x amount of the governance token

3- if a quorum is reached and a majority agreed after the 2nd step then we get the third and last step aka the on-chain vote, to create it you need a way larger amount of x governance token since it leads to a modification within the protocol.

important note : the economic incentives here are useful to filter the vote creation but every token holder are able to vote and anyone can participate in the first step even the one who doesnt have governance token

second important note : there is no difference between the on-chain vote and the execution, in fact the on-chain vote consists of writing a mini smart contract (payload) that is going to interact with the governance’s smart contract and trigger the modification of the protocol if the result of the vote is positive.

this is very huge since there is no human intervention here.

[Jiawei]

Look forward to EigenLayerDAO

[mdesim01]

Thanks for the feedback @CryptoBanker! First of all, I wholeheartedly agree that a progressive approach to decentralization is critical to the success of a decentralization roadmap. Progressive decentralization is critical because: 1) the infrastructural tools required for effective decentralized governance at scale are still in their infancy, 2) these decentralized governance tools should first be dogfooded by the EigenLayer Team and the mechanisms for Reputation allocation and decision-making processes should be found to work among the Team and gradually scaled to include larger and larger groups of contributors, as more tooling is developed along the way to enable such scaling, and 3) it is still TBD what measures would be most effective to ensure value-aligned governance for EigenLayer.

Regarding your questions:

How do you envision Reputation points being assigned? Seems necessarily somewhat subjective to me, but I’d be curious to hear any ideas you may have on more objective criteria. I believe Optimism has made some efforts at retroactive funding, which this certainly brings to mind.

When it comes to assessing the value of a contribution—whether it’s regularly posting thought-provoking ideas/feedback on EigenLayer’s governance forum, onboarding new AVSs through BD efforts, contributing to EigenLayer’s core smart contracts, auditing the slashing contract of an AVS, or any other contribution that may be made to the EigenLayer protocol—at the time a given contribution is made, the value of that contribution is quite difficult to assess through a purely objective lens.

A person or entity’s contribution to the EigenLayer protocol may add “value” in various ways that are not necessarily purely financial/monetary in nature (at least not in the short term) but still align with EigenLayer’s mission and thus contribute value that ideally would be compensated; for example, a contribution might lead to more decentralization, more security, more Ethereum community engagement, etc.—things that are quite subjective to measure, as you fairly point out.

While some systems, like SourceCred, are building systems that ascribe value and Reputation points to contributors via tracking objective metrics, such as the number of “likes” on forum posts, the number of pull requests on GitHub, etc., use of such objective metrics to ascribe Reputation is highly subject to attack/gaming.

Real long-term sustainable value resulting from a person or entity’s contribution can only be viewed objectively over a long time horizon, after the effects of that contribution have had time to sink in and permeate the protocol upon implementation. And, even after “sufficient” time has passed, it would likely be impossible to segregate out the value resulting from one contribution from the value resulting from some other contribution.

With the above in mind, I’d argue that assignment of Reputation should be pushed to the edges and should be governed by small teams who focus within highly granular “child domains” or “subdomains” of expertise (e.g., from my prior example, the Oracle AVS Contract Security Auditing Domain); and a contributor’s Reputation within a given domain would accrue proportional to the amount of EigenLayer internal token that the subset of contributors (with preexisting Reputation) in that domain subjectively permits a contributor to receive from their domain’s percentage allocation of the EigenLayer Treasury.

A system like Colony is flexible and enables an array of options for earning Reputation—EigenLayer’s internal token (and, in turn, Reputation) can be earned retroactively well after a contribution has been made, similar to the Optimism Collective’s approach, or it can be earned daily, weekly, monthly, or even streamed on a block-by-block basis. Payment of EigenLayer’s internal token to a contributor would be initiated (and terminated) via a “motion” that the contributor or anyone else with Reputation in that domain makes on-chain to initiate (or terminate) that one-time/recurring/streaming payment; typically, such a motion is first preceded by an off-chain agreement among contributors that, when combined, have sufficient Reputation within that domain to confidently stake their EigenLayer internal tokens on the motion to get the motion to pass. Even after a motion for payment is fully staked with the EigenLayer internal token, if there is an objection to that motion, anyone could submit a motion to object within a given objection time window. If/when the objection motion is fully staked on the objecting side, the motion for payment to the contributor would go into arbitration—a Reputation-weighted vote to determine whether the motion for payment should pass, which results in loss/gain of stake depending on the outcome (You can watch a short demo here to see more specifically how Colony does it).

The main reasons that I’m a big proponent for Colony’s “lazy consensus” model is it enables nimble, rapid decision-making and resource allocation seen in centralized businesses, while still staying true to the principles of decentralization and permissionlessness (i.e., anyone can come along and contribute and gain Reputation); furthermore, in my opinion, this model does not oversimplify the inevitable complexities that come with ascribing Reputation and decision-making power, as it does not rely on simple objective metrics to measure Reputation that are often gameable and short-term-oriented. Lastly, it largely avoids the pitfalls of token-weighted voting which lead to poor and uninformed decisions being made by investors instead of the people with the most knowledge, involvement, and experience in the project…it’s the same reason that publicly traded companies don’t rely on their stockholders to make day-to-day decisions about resource allocation and rather rely on employees!

Relatedly, your idea that reputation updates could themselves be done by a “Reputation System AVS” raises an interesting kind of “bootstrapping” problem. I get the sense that such a system continues fine after an initial startup process, but do think it may present some security issues (e.g. does the restaked value on this AVS then effectively cap the total economic security that EigenLayer can offer?).

This is a fantastic question and one that I’m sure the Colony team could weigh in on if you’d like. First, I’d recommend reading Section 5 (specifically Section 5.5) of the Colony whitepaper regarding the security of their Reputation Mining System.

So long as there is one honest Reputation Miner who is online/responding to challenges to the Reputation state if they are made, Reputation scores cannot be falsified…unless an attacker were to gain control of the chain on which the Reputation Mining System is built, such that the attacker could selectively drop transactions involved in the Reputation Mining process to cause an incorrect Reputation state to be accepted. In the case of Colony, their Reputation Mining System is currently built on Gnosis Chain, so an attacker would have to 51% attack Gnosis Chain in order to push through an incorrect Reputation state transition.

I would imagine that, if EigenLayer were to build on Colony’s reputation-based governance framework and enough value were to be secured by EigenLayer that made it economically viable for an attacker to gain 51% control of Gnosis Chain to maliciously alter the Reputation scores of EigenLayer’s governing body, there would be a push to migrate Colony’s Reputation Mining System to Ethereum long before such an attack were to become a legitimate concern.

In short, there doesn’t seem to be a major bootstrapping problem using a protocol like Colony to manage contributors’ Reputation.

How do you envision duties being delegated? Seems like you are perhaps imagining something like different spheres of responsibility falling primarily to small groups / individuals, but with some delay to take effect, where a larger contingent can then “veto” or otherwise cancel the planned action?

That’s pretty much correct. What is being proposed promotes a meritocratic distribution of decision-making power and resource allocation power within “parent” domains and smaller and more granular “child” domains of expertise/focus. In my view, doing so will organically lead to delegation of responsibilities/duties among individuals, as such a system creates a natural hierarchical governance structure. Reputation is earned in a hierarchy, and when an individual earns or loses Reputation in a domain, the Reputation in all “parent” domains changes by the same amount. Below is a graphic taken directly from Colony to illustrate that point.

As for checks and balances and the ability to “veto”, this is built into the governance framework, as described a bit in my response to your first question (see above).

[jinzi]

• As EigenLayer launches and inevitably gains more traction and is relied upon by many AVSs, the efforts needed to maintain the protocol and ensure its security and stability will only increase over time, thus requiring additional labor/contributions.

[hailey.wood]

didnt understood this article(

[Rahulnlr]

its is realy to say the people of the community and they always be help ful

[Mannwan]

Great topics to come