Validator Redirected Revenue

[clesaege]

Validator Redirected Revenue

I. Executive Summary

1. Ethereum is stuck in a coordination failure: everyone benefits from shared improvements but no single actor wants to pay when others can free-ride. This creates a persistent deadweight loss that weakens Ethereum’s long-term competitiveness.

2. The proposal introduces 2 changes at the protocol-level to create a funding mechanism driven by validators, who configure

3. % of staking rewards redirected to ecosystem funding: If a majority of validators agree to part with a share of their staking revenue, the redirect rate becomes mandatory for all validators.

   The maximum amount in redirects is 10% of staking rewards, beyond which no increase would be possible, while the minimum is 0% (current status quo). At a protocol level, the parameter change is (UP/DOWN/ABSTAIN) where UP or DOWN increase or decrease the redirect amount by fixed rate e.

4. Preferred funding recipients: Validators also indicate their preferences for the recipient address where they want the funds to be redirected. Execution clients take in these static preferences to come to a consensus on a splitter contract dividing funds between the different addresses, based on the split that would win in a head to head duel against all other possible splits (a solution concept called a condorcet winner).

   At a protocol level, the parameter change is (KEEP/CHANGE/ABSTAIN) where KEEP maintains the existing splitter contract while CHANGE results in a new splitter dividing the redirects between the funding recipients indicated by validators.

5. The key advantages of the design are minimized governance overhead for validators who simply “set and forget” their inputted preferences on redirect amount & recipient addresses, with execution clients figuring the rest out (we expect healthy diversity in their implementations). Another advantage is simplicity at the Protocol level, which only cares about Increase or Decrease for the redirect amount and Keep or Change for the splitter contract determining where redirected funds go. The primary concern is principal-agent issues between staking operators setting the configurations and those delegating their ETH to them.

The goal of the post is not agreement on the proposed solution so much as discussion around the need to address underfunding at the protocol level and a “wrong answer” to spur debate. Accordingly, the next section focuses on the main issue in need of redressal (reducing deadweight loss in the Ethereum economy) before moving on to why validators have the incentive alignment to become a long term stakeholder that addresses it. The fourth and fifth sections respectively touch on the proposed solution and the open challenges they introduce.

II. Free Rider Problem and Deadweight Loss in the Ethereum Economy

The funding challenge in Ethereum resembles a classic prisoner’s dilemma.

Consider two actors who both care about Ethereum:

• If neither contribute, both retain their capital.

• If one contributes and the other does not, the contributor sacrifices while everyone else benefits at his expense

• If both contribute, the ecosystem grows and both benefit

Caption: Prisoners dilemma preventing actors from stepping up to fund shared infrastructure

While the third outcome is collectively optimal, each individual faces an incentive to defect from the funding coalition and free ride on the contributions of others.

This dynamic leads to Ethereum getting stuck in a stable but inefficient equilibrium where no one contributes, even though everyone would benefit from coordinated funding.

The same problem appears in many economic systems. Voluntary payment for public goods rarely succeeds because individuals hesitate to contribute when others can benefit without paying.

This creates a deadweight loss in the Ethereum economy, a concept that can be explained with the following example;

• A piece of shared infrastructure costs $50 per year to maintain.

• Six projects depend on it.

• Each project gains $10 in value from the infrastructure.

The total value created is $60, which exceeds the cost of $50. From the perspective of the ecosystem as a whole, the project should clearly be funded.

Economists refer to the $10 as deadweight loss, an irrecoverable cost making economies uncompetitive

However, no single project receives enough value individually to justify paying the entire $50. As a result, either

1. The infrastructure never gets funded, although it would benefit everyone collectively

2. The Ethereum Foundation funds the infra to reduce deadweight loss, either directly or by bearing the coordination cost of getting all relevant projects to cough up the $10

3. Some philanthropist steps in to cover the entire cost

Economies that reduce deadweight loss tend to outperform those that cannot. Successfully coordinating shared investment is essential to compete with both traditional economic systems that use coercive measures like taxation to reduce their deadweight loss and corporations that reinvest earnings back into future growth.

III. Validators Benefit from Ethereum Growth

At a structural level, validators have a clear incentive to support Ethereum’s growth.

When more applications, tools, and infrastructure are built on Ethereum, demand for blockspace increases. Greater demand for block space strengthens the network’s economic activity and overall network value.

Since validators stake ETH and earn rewards denominated in ETH, they directly benefit from the long-term growth of the ecosystem via the following positive feedback loop:

1. Validators fund ecosystem development.

2. Ecosystem development increases network demand.

3. Increased demand leads to more ETH burn.

4. Validators benefit from higher value rewards and increase in value of principal staked

Despite this alignment, why don’t we see much funding coordination by validators outside of promising but isolated efforts such as the DAO Security Fund or Octant?

Our hypothesis is that it is due to validators getting stuck at the non-cooperative equilibrium in the prisoners dilemma, where they would greatly benefit from funding the ecosystem with their rewards at a non-zero amount, but the reality of defections by other validators makes most of them hesitant to contribute anything. Accordingly, we present a solution in the next section to address the free-riding problem.

IV. Validator Redirects: A Protocol-Level Coordination Mechanism

The core idea is a protocol level change where validators need to signal 3 things;

1. Ability to handle an increased gas limit (already exists)

2. % of staking rewards redirected towards the ecosystem (requires hard fork)

3. The recipient address that should receive these redirects (requires hard fork)

We will now separately tackle each of the 2 proposed changes;

1. Redirect Rate

The key element in (2) is a majority-trigger mechanism: If 51% of validators signal a redirect rate above 0, the contribution becomes mandatory for all validators. At that point, every validator contributes the specified portion and sees their rewards fall by the corresponding amount.

This approach addresses the free-rider problem. Validators can commit to funding without risking unilateral disadvantage, because the contribution only activates once a majority agrees.

In effect, the protocol would enable validators to move from a prisoner’s dilemma equilibrium toward cooperation. The Nash equilibrium we expect validators to converge on is,

Loss of staking revenue = E[Extra Value to ETH]

There is some free-riding still present as ETH price increases benefit everyone and not just stakers. So the mechanism would still underfund compared to the optimum as stakers would increase the share of funding up to the point where

Loss of staking revenue = E [gains from eth price appreciation for stakers only]

Where does the extra value E come from? Apart from the efficiency gains of reducing deadweight loss by collective investment, by helping us break out of the following loop

a) People are scared Ethereum is gonna lack funding in the future.

b) They decrease their estimates of Ethereum’s success.

c) They decrease their valuation of ETH.

d) ETH price decreases.

This design only partially addresses the free-rider problem, as ETH holders who are not staking would still benefit from redirects made by the validators. But within the set of all validators, redirects are optional for the group but mandatory for the individual. This is an improvement over the traditional economy’s solution to the problem of deadweight loss reduction (taxation) where there is no opt-out.

We propose capping the redirect rate to a maximum of 10%, as a natural schelling point given the history of tithe and norms around contributing 10% of earnings back to society. Moreover, the cap limits the theoretical worst case scenario of redirect dialled up to 100% for redistribution to a bad actor, which the next section tackles more comprehensively

At current levels of ~35-40 million staked ETH and 1.91% rewards, approximately 700k ETH per year is currently given to validators for keeping the chain secure. A redirection of even 5-10% provides significant funding to the ecosystem (approximately 50-70k ETH per year) without exerting undue force, since validators preserve the option of putting the redirect rate all the way down to 0% (status quo).

2. Redirect Recipients

While determining the redirect rate is relatively straightforward, a more complicated question is figuring out how the funds should be allocated.

We’ll divide this section into 3 questions; how validators indicate preferences, how they get aggregated, and final construction of the list of redirected recipients.

Q1: What changes do validators need to make under this proposal?

At a validator level, all that is required of them is specifying

1. the contract addresses or EOAs that should receive the redirected funds

2. the % amount to each.

For example, a validator may put 0xABC… as 60% and 0xXYZ… as 40%. Unlike other mechanisms that require frequent participation, the validator can simply set and forget, with the option of manually changing their preferences at any time (in practice, we expect defaults to become sticky once set). This approach ensures that validators, the ones who are parting with revenue they would have otherwise earned, retain control over how their money is distributed.

We can now move to the next question,

Q2: How do we aggregate heterogeneous validator preferences into a single splitter contract that defines how funds are distributed?

Upon execution of the proposal, the mechanism starts with a 0 redirect rate and a 0 address as redirect recipient. Every 128 blocks (approximately 5 minutes), the first validator can propose a new candidate splitter contract to become the new ‘King of the Hill’ by knocking out the existing one. If the candidate better aligns with the configured preferences of validators, it becomes the new King of the Hill splitter contract. If it is equal or lower in alignment to the validators preferred recipients, then the existing King of the Hill is maintained.

We have now reduced the problem in a way to tackle the final question on final list,

Q3: How do we gauge whether a candidate splitter contract better aligns with validator preferences than the current King of the Hill?

We propose that the mechanism use a distance metric (such as Manhattan distance) to determine whether the protocol should KEEP or REPLACE the existing king of the hill. As an example taking 3 redirect recipients;

Validator ideal distribution: [20%; 0%; 80%]

Existing King of the Hill splitter contract: [50%; 25%; 25%]. Distance of 30%+25%+55%= 110%

Candidate splitter: [30%; 50%; 20%]. Distance of 10%+50%+60%= 120%

So the validator automatically votes to keep the current king of the hill as it is closer to preferences compared to the proposed alternative.

There would be some degree of diversity in how execution clients implement methods of comparison between candidate and king of the hill splitters, such as convex utility functions (eg: either attribute a large amount to a mechanism, or none at all, but not something in the middle). Validators may also adjust the amount allocated to the splitter contract all the way down to zero if they are unhappy with how funds are being allocated. Overall, this “king of the hill” mechanism will converge to a distribution of funds that is a condorcet winner: a distribution that would beat out any other distribution in a head-to-head vote. It also ensures simplicity at the protocol level where the options are only to “KEEP” or REPLACE” the existing splitter contract.

V. Open Issues

While the proposal helps address coordination problems around funding, it raises some intractable concerns that must be addressed.

1. Validator Cartelization

The most significant risk is cartel formation.

If a majority of validators collude, they could theoretically crank up the redirect rate and redirect those funds back to themselves. For example, 51% of validators could vote to set redirect rate to the maximum 10% and set the redirect recipient to a splitter dividing the money between them, thus ‘stealing’ staking rewards from the other 49%. There is an element where the drop in price from collusion makes such malicious actions economically unprofitable.

2. Principal-Agent Problems

The problem raised in (1) becomes more acute when we take staking operators into account.

Currently, roughly 90% of ETH is staked through operators rather than solo stakers, who become validators using the capital provided by customers. Operators are typically incentivized by a percentage of staking rewards, whereas ETH holders care primarily about the long-term value of their principal.

If operators control the preference setting mechanism, they may prioritize redirects to projects that benefit them, such as an improved operator experience, which their users care little for. The best answer to this issue is a competitive market of staking operators that customers can migrate to if they don’t like their voting preferences for redirects.

3. Issuance Signaling

Another implication is that validators signaling willingness to contribute part of their rewards could be interpreted as evidence that Ethereum’s issuance rate is higher than necessary.

Validators’ willingness to give up 10% of their rewards could be interpreted as an ability to reduce issuance by 10%.

Rejoinder

Today, most users select operators based on purely financial value (yield and risk).

If such a mechanism were implemented, a new dimension of competition gets added where users choose operators based on values. For example, a user may prefer staking with an operator that sets redirect rate to 5% and recipient to a team making Ethereum quantum resistant. Some operators may also let users directly set their preferences.

Over time, this could reverse centralization of staking operators as values are inherently more pluralistic than the network benefits to scale that financial returns enjoy. It may also encourage more solo staking, since individuals would have direct influence over how important projects in the ecosystem get funded.

Moreover, under the voting mechanism we’re proposing, cartel behavior isn’t stable. That is to say, if we assume that validators are purely driven by greed and seek to use this process to funnel more money to themselves, the “king of the hill” option will never settle to a stable distribution that gives any validator more than they would get under the current status quo. See the appendix for a mathematical explanation.

The issuance reduction debate is broadly in 2 camps; one side believes that any cuts should only be made after lean ethereum to preserve reliability, given that institutions have built their staking products with certain assumptions in mind. The other side believes the issuance curve is flawed as it does not taper with more ETH staked, and an adjustment is required as early as Q1 2027. This proposal works independent of the issuance debate; nonetheless, given the need for core ethereum funding, there is a happy path where redirects serve as a better alternative to pure cuts.

Next Steps

We seek further feedback before working on a technical implementation to put forth as an Ethereum Improvement Proposal. The post immediately after this will have an FAQ that will be updated as questions come in.

Even if there are irresolvable concerns preventing acceptance of the EIP, we think it essential that there be a contingency plan that can be activated in an emergency so that we do not start at 0 during a crisis.

[clesaege]

Appendix 1: Stability of Cartel behavior

Here, we’ll dig into a bit of analysis around cartel formation/stability under some simple assumptions about validator preferences and voting rules. Here, a “cartel” is a small-ish number of validators with lots of voting power, who redirect block rewards towards themselves.

Setup:

Suppose we have n validators, \{a, b, c,\dots\} have voting power V_a, V_b, \dots, with all V_i's summing to 1.

A contract C distributes some share of rewards C_a, C_b, \dots to each validator, with C_i's summing to at most 1 (since the contract may also give some money to other entities).

Assume that validators are selfish: they prefer a greater share of the rewards, and don’t care how much other validators get.

Recall that we choose which of two contracts to use via a majority vote, weighted by voting power. A contract C' beats a contract C if there is a subset of validators S who prefer C' to C with \sum_{i \in S} V_i > 0.5.

We’ll use Nash Equilibria for our notion of stability. Imagine all the validators vote for their favorite contract, with the winner chosen by majority rule. Then a contract chosen in a Nash Equilibrium if no single validator could become better off by switching their vote to something else.

For a set of validators S with \sum_{i \in S} V_i > 0.5, we can call S‘s ‘‘cartel contract’’ a contract C^S where for i \notin S, C^S_i = 0 and for i \in S, C^S_i > V_i (i.e., the members of S are "making’’ more in rewards than they would as normal validators.

Analysis:

The main insight is that there is an interplay between the size of the cartel and its stability. In this model, cartels made of small numbers of powerful players are not stable. Cartels made of many smaller players are.

Let S be a subset of players and let x = \sum_{i \in S} V_i. S can instantiate a cartel contract C^S if x > 0.5, but the contract won’t be chosen in equilibrium as long as there exists a j \in S with x - V_j <0.5. This is because we can come up with an alternate contract C^{\neg S} with the following distribution

• C^{\neg S}_i = 0 for all i \in S \setminus \{j\}
• C^{\neg S}_i = \frac{\sum_k C^S_k - z}{n - |S|} for all i \notin S
• C^{\neg S}_j = C^S_j + z for the specific validator j we identified above

This contract gives j a reward of z for leaving the cartel, and redistributes the rest of the cartel’s takings among everyone who wasn’t in the cartel. Ultimately, C^S is not a Nash equilibrium contract because j becomes better off by voting for something else – namely, C^{\neg S}_j.

However, if the cartel has many members, its contract can hold in a Nash equilibrium. Suppose we have 100 validators, each with V_i=0.01. Then 52 of these validators can form a cartel, and an equilibrium-breaking contract like the one we found above doesn’t exist, since no one member can dissolve the cartel by choosing to defect. On the other hand, one could imagine a contract that, say, rewards 3 of the 52 members for defecting – now, if those 3 validators all can defect simultaneously, the cartel is in trouble. So, in other words, cartels with large numbers of players are stable in the Nash equilibrium sense, but not stable under more general notions of stability in which multiple players can defect at once.

This analysis was done under a very simple model of validator behavior, and relative to a very simple voting procedure. However, I hope it gets some basic ideas about cartel formation across – namely, that if validators are purely selfish, one shouldn’t expect cartel formation from small groups of powerful players.

[MicahZoltu]

@clesaege

The most significant risk is cartel formation.

If a majority of validators collude, they could theoretically crank up the redirect rate and redirect those funds back to themselves. For example, 51% of validators could vote to set redirect rate to the maximum 10% and set the redirect recipient to a splitter dividing the money between them, thus ‘stealing’ staking rewards from the other 49%. There is an element where the drop in price from collusion makes such malicious actions economically unprofitable.

Without solving this problem, or the problems that are created by various solutions to this problem, I think there isn’t much to gain from iterating on the rest of it.

Either the target you can direct capital to is centrally chosen (permissioned), or people can point their share wherever they want (free rider problem reintroduced), or you have some other game for capital allocation that is exploitable (form varies by implementation).

I am not aware of any solution to this, and it is why Ethereum (and other blockchains) haven’t done this sort of thing in the past. I would love to see someone solve this problem, but without a solution to this I think we will remain stuck where we are, with no public goods funding.

[mishudark]

Why not just use part of the fees being burned on every transaction?

[clesaege]

@MicahZoltu

Either the target you can direct capital to is centrally chosen (permissioned), or people can point their share wherever they want (free rider problem reintroduced), or you have some other game for capital allocation that is exploitable (form varies by implementation).

Well there is “exploitable in theory” and “exploitable in practice”. For example we can see that both Bitcoin and Ethereum are vulnerable to cartel formation.

• In Bitcoin you can do a 51% attack by rejecting all blocks outside of the cartel.
• In Ethereum you can do a 66% attack by not including attestations of validators outside of the cartel.

Why don’t we see that in practice:

• Majority is actually honest (thing which is easy to forget in game theory).
• Coordination at this scale is hard. Particularly in Ethereum where validators need other people ETH, trying to start a cartel basically tells the whole world “I am a dishonest actor”, which would likely lead to stakers changing operator.
• Cartels may not be stable, in a world of cartelisation, you are not guaranteed to be part of the cartel.
• If cartelisation were to happen, this would be seen as an attack, greatly tanking the price.
• There is always the social layer which can fork out the cartel (very true for Ethereum, a bit more complicated for Bitcoin).

In addition in this proposal there is an upper limit (10%) of what can be redirected, so a cartel could at maximum increase its yield by 10%.

• This means that the upside is very limited compared to all the previously cited downsides.
• The gains in term of ETH price increase with proper funding should be higher than the stolen yield. Indeed, if we had a cartel capable of 51% attacking the system, we would actually end up with a group of coordinated actors which would have an incentive to direct part of the stolen yield to ecosystem funding.

I do concede that with proposal we would go from:

• With 51%, we can break the system (by messing up with the gas limit).
• With 66%, we can steal other people yield and principal.

To

• With 51%, we can break the system (by messing up with the gas limit).
• With 51%, we can steal 10% of other people yield.
• With 66%, we can steal other people yield and principal.

Because we already have possibilities or cartelisation in theory, but never saw those in practice, I estimate this risk to be mostly theoretical (<1% and I am ready to take such a position in a conditional prediction market).

[clesaege]

@mishudark

Why not just use part of the fees being burned on every transaction?

I think that this would indeed be better than the status quo (and I would support such proposal).

I still prefer my proposal, because if we were to only take it from the burn fees, we may end up in a situation where validators would have incentives to reduce the gas in order to ensure that ecosystem can be funded (instead of keeping it low to favor growth in term of usage).
Here taking from the block reward means that we can independently decide of:

• How much ecosystem funding should we give?
• How much value should we capture?

[MicahZoltu]

@clesaege

• In Bitcoin you can do a 51% attack by rejecting all blocks outside of the cartel.
• In Ethereum you can do a 66% attack by not including attestations of validators outside of the cartel.

In both cases, you can censor, and in Bitcoin’s case you can reorg indefinitely deep (double spend). In neither case can you steal money from anyone nor redirect capital that wasn’t already headed your way (some caveats on poorly designed apps built on top of Ethereum). In this system, there is a pile of money up for grabs that can be redirected to a cartel. Very different incentive for attack

Also, depending on the specifics of the design there is no punishment for defecting against the greater good. The optimal strategy is to always try to get your name on the fund receiver list. If you fail you waste a bit of time. If you succeed you get free money. This is the public goods funding problem generally, if there is money up for grabs people will do what they can to try to acquire it. Social layer, coordinated takeover, etc.

[clesaege]

@MicahZoltu

In both cases, you can censor, and in Bitcoin’s case you can reorg indefinitely deep (double spend). In neither case can you steal money from anyone nor redirect capital that wasn’t already headed your way (some caveats on poorly designed apps built on top of Ethereum).

• In Bitcoin if you censor blocks outside of the cartel, the effective hashrate decreases while the rewards stay the same, so you do end up stealing from operators outside of the cartel. (+ you can do a bunch or things like double spend)
• In Ethereum, if you censor out of cartel block/attestations, you end up destroying a ton of ETH making your share of ETH higher and preventing anyone else from staking (as they know they would just lose their ETH over time without getting a yield). So the cartel ends up the stole recipient of ETH block rewards (it is not exactly a 1 for 1 due to the reward curve depending or participation, but you do end up stealing).

[MicahZoltu]

@clesaege

In Ethereum, if you censor out of cartel block/attestations, you end up destroying a ton of ETH making your share of ETH higher and preventing anyone else from staking (as they know they would just lose their ETH over time without getting a yield). So the cartel ends up the stole recipient or ETH block rewards (it is not exactly a 1 for 1 due to the reward curve depending or participation, but you do end up stealing).

The validator exit queue provides an opportunity for a social layer solution to this problem, including slashing a significant portion of the cartel.

I agree that Bitcoin can be bad beyond 51%, but I think what you are proposing here makes things meaningfully worse because it doesn’t require cartel coordination and synchronization. People can join the cartel whenever at no risk to themselves.

Ethereum socially slashing on “the charity you select is not legitimate enough” is unrealistic while socially slashing on “you censored every other block producer” is relatively easy to coordinate around.

[zeroproof]

The mechanism design here is well-constructed, but I think it’s aimed at the wrong problem.

Funding allocation doesn’t drive contribution. Conviction does. Linux kernel development has never had a coordination mechanism for compensating contributors, yet it has never lacked them. The reason is straightforward: contributing to the Linux kernel is so obviously valuable that the contribution itself functions as currency elsewhere. It converts directly into employment offers, consulting contracts, reputation, and access. Nobody needs to be incentivized to contribute to something the world recognizes as important. They compete for the chance.

The same holds for early Ethereum. In 2016-2018, people were building for free because the ecosystem had a credible claim to being the most consequential technical project of the decade. The free-rider problem wasn’t salient then, not because the game theory was different, but because the perceived value of participation was high enough to make the question of compensation irrelevant.

What changed isn’t the funding structure. What changed is conviction. When contributors look at the ecosystem and aren’t sure what it’s for beyond moving tokenized equities and stablecoins around, the expected reputational and career return of contributing drops. At that point, no allocation mechanism can compensate for the missing conviction. People who doubt the mission will find ways around any mandatory contribution, or simply leave.

This suggests the bottleneck isn’t “how do we distribute funding” but “what is Ethereum actually for.” If that question gets a compelling answer, the funding problem solves itself the way it solves itself in every thriving open-source ecosystem: people show up and build because they want to be part of it. If it doesn’t, redirecting validator rewards is optimizing the supply side of a demand that isn’t there.

[mister.plum]

@clesaege

Majority is actually honest (thing which is easy to forget in game theory).

Because Ethereum has successfully aligned profitability with honesty.

I don’t think we should implement anything that changes that, e.g. we should assume any system that can be exploited for profit will be (the whole ethos of blockchains). I saw Banteg resurface an old Vitalik post on a similar mechanisms implemented in other blockchains and why they don’t work. I can’t link it here, but it was called “Governance, Part 2: Plutocracy Is Still Bad” and was posted 2018-03-28.

I’m scared this also removes efficiency from the system, e.g. in the real world everywhere we see continued government and bureaucracy expansion, increased tax take, yet struggling productivity. If we set the max initially at 10%, what happens when things still aren’t getting done and 10% is allocated, do we set it to 12%? To quote a urban planning meme:

Just one more lane bro. I swear that’ll fix traffic.

Probably better to just lobby groups running validators for others (e.g. Lido, Bitmine, ETFs) to redirect a share of their profits to developers. They have the infrastructure to vet and evaluate performance of grants, and a financial incentive to do so.

[LefterisJP]

Hey @clesaege

Thank you for writing a thoughtful proposal and analysis around trying to solve the free rider problem of funding Ethereum core development.

A counter-challenge here would be to ask do we actually need this? Everything around the ecosystem is consolidating. And that is probably a good thing. Why not research and core development too? Over the past years it has been dragging on and on without a sense of urgency and at least to an outside but technical observer like me with a ton of unnecessary complexity.

Ethereum has a problem of overarching technical complexity and a serious case of the NIH syndrome. Just look at RLP, SSZ, RPLx as the top (but not only) examples. I don’t want to reward the development methodology and culture that has produced such work. Having core development more in sync and contact with reality and with the people who actually use Ethereum and suffer from their technical choices would be a blessing. And if a funding crunch will lead to that then that’s a good thing.

Now that aside and if we wanted to assume that a funding mechanism should exist I would also opt for burned ETH fees instead of % of validator proceeds. I acknowledge though that this introduces the gas usage issue that Clement pointed out above. But … perhaps that is preferrable to the cartel issue.

Regarding the validator proceeds proposal itself then the issue becomes indeed as @MicahZoltu also pointed out the cartel of the top stakers deciding who gets funded on everybody else’s expense. And the rest of the 49% are then essentially stuck funneling funds to the cartel’s choice.

The counter argument to this from what I read above seems to be that it can happen but then people would unstake from the cartel eventually weakening them enough to lose the majority. But this is not a solution and it is also making assumptions about the stickiness of staking share. I believe staking share is a lot more sticky than people assume and quite slow to move/change.

All in all I don’t believe this idea is a good change and it should not go forward.

[stonecoldpat]

I do believe it is important to find a mechanism that will pay for the development of Ethereum into the long-term; without relying on wealthy donors to step up and provide this support. Developers should be paid for the work they do and offered some form of job security to do so.

My main criticism in the current proposal is the following:

No-restriction on recipients. Validators should not be allowed to pick any recipient, but only from a set of pre-approved recipients. If Validators can pick anyone, then it opens them up to the world of lobbying. Many new entrants, likely undeserving of the funding, will immediately lobby Validators and pressure them for an allocation of funding. Being a recipient of protocol-level funds should be the highest privilege and honor. It should go beyond the set of validators to make this decision. I’d advocate for a list of pre-approved recipients who are only installed during hard-forks via rough consensus. This will slow down the ability for new entrants to get funding (i.e., every 6 months to 1 year), but this ensures the entire ecosystem must be convinced that the recipient should be eligible for funding. Whether they get any is then up to validators.

King of Hill too complicated. The King of the Hill mechanism to pick the best splitter contractor seems awfully complicated, especially in a multi-client ecosystem that needs to implement this. I do not really understand the strong motivation for it either. Why is it advantageous over just a simply % split contract based on the current set of preferences? Preferences could also just be updated every 24 hours at a fixed time and the new % implemented from then onwards.

I’m not sure whether this exact proposal should be implemented or whether funds should come from stake/burnt fees. But, the Overton window on how to fund on-going development, is probably overdue at this point. Alongside how to keep recipients of funds accountable and working on issues that impact the end-user (i.e., be more product focused).

[MicahZoltu]

@stonecoldpat

Validators should not be allowed to pick any recipient, but only from a set of pre-approved recipients.

If you can solve this, you have solved the hard problem of democracy and we are living in a reality where the government doesn’t work against the citizens. In such a world, we don’t need blockchains as we have solved human governance.

[axdfc]

why not send it to protocol guild?

[themandalore]

Love the post @clesaege , I think I’d want to see some actual deliverables discussed. Block explorers, node software development, research, marketing, events, or other. I’d love to have different voting methods tried (say token weighted, quadratic, etc.) and then we have the category percentages set and then we can vote on the top few to get funding (not just one, but lots of money going lots of places).

I really do think it solves a problem and this ecosystem has so much potential if we can just get around the mentality of “it game-theoretically fails, so we shouldn’t try”. We’re gonna try and we’re gonna fix it when it fails and then we’re gonna do it again and again.

[nay]

So, this has been a fascinating discussion, and I wanted to speak about some issues that I see and a possible solution to address what has already been proposed in this thread. The VRR proposal correctly acknowledges that everyone benefits from shared infrastructure, and no individual actor has sufficient incentive to pay. The majority-trigger redirect mechanism is an interesting solution to the free-rider problem within the validator set.

But the proposal combines two fundamentally different questions into a single mechanism.

Question 1: How much should validators collectively invest in ecosystem development?

Question 2: Which specific work should that investment fund?

The first question is a macroeconomic question that validators are well-positioned to answer. The majority-trigger mechanism handles it well by allowing validators to signal a redirect rate, and forcing the median to become binding. This addresses the free-rider problem.

The second question is an operational question. It requires domain expertise and knowledge of which protocol work is needed, which security vulnerabilities are unaddressed, and which tooling gaps are blocking developers. Validators, as a class, do not possess this knowledge.

They are infrastructure operators, not protocol researchers or security auditors. Asking them to also answer the second question by selecting recipient addresses, creates the allocation game that @MicahZoltu correctly identified as a crucial flaw:

@MicahZoltu

Either the target you can direct capital to is centrally chosen (permissioned), or people can point their share wherever they want (free rider problem reintroduced), or you have some other game for capital allocation that is exploitable (form varies by implementation).

This problem remains only within the frame where Question 1 and Question 2 are answered by the same mechanism.

I think if its heading in this direction, we should keep the VRR funding mechanism, but replace the allocation mechanism entirely.

You can still have validators who signal a redirect rate (0-10%), with the majority-trigger activation. Mandatory at 51% agreement, capped at 10%. All the same parameters. The same hard fork requirement. No changes.

The allocation mechanism must change though. Redirected ETH should not flow to addresses selected by validators. Instead, it should flow to a single protocol-controlled contract (an Ecosystem Work Fund or something like that).

The Fund does not distribute ETH to recipients chosen by a voting game. It funds a task economy.

Accredited institutions can define structured tasks with scoped deliverables, verification criteria, and $ETH compensation values. Contributors complete tasks, and upon verified completion, ETH is released from the Fund to the contributor.

This allows for the separation while maintaining the incentives and governance over domains. Validators decide how much to redirect, and the institutions who are closest to the work define the tasks. Validators should NEVER pick addresses. Institutions should NEVER control the funding rate. Each group answers the question it is competent to answer.

A question then becomes who are these institutions? Well, the initial set should be small and high trust. Protocol Guild, 2-3 established client teams, 1-2 security orgs, the EF…expansion can follow deliberate sequencing by proving that it works with trusted institutions before widening the trust boundary.

Each institution defines a task catalog for its domain. Work like auditing contracts, building tools, implementing EIP components, reviewing specifications etc, etc. Each task has a defined scope, deliverables, verification method, and compensation amount.

Doing this also forces institutions to adopt a process for managing a budget and setting priorities. The Funds total balance is allocated equally among all active institutions at the start of some defined time period. For example, if the Fund receives 8k ETH per quarter (at current staking levels with a 5% redirect) and there are 8 participating institutions, each one will receive a budget of 1k ETH.

Equal allocation is deliberate and important because it prevents any single institution from dominating the funding distribution and ensures that the diverse ecosystem domains represented by the institutions all receive attention. This eliminates the political games of “which institution deserves more”. Modifications to this distribution can be made collectively if the majority of institutions see some specific work as being necessary.

The budget constraints forces prioritization. Each institution needs to make decisions on what work matters the most. The scarcity of the budget can produce thoughtful task design rather than just enabling indiscriminate spending. You can’t fund everything, so you need to figure out what moves the needle.

As for the contributors, there are many ways you can present the available bounties/tasks to the public. I would leave this to the individual institutions to decide, but the core component of this is that if contributors claim/execute on the work proposed by an institution, they are then compensated from ETH through the Fund contract. Verification is also up to the institution, as some tasks will be straightforward, while others may require expert judgement.

The accountability mechanism is transparency. Every compensated contribution is onchain with verification, definitions, notes, etc. If an Institution approves low-quality work to drain its budget the contributor community and other Institutions will see it. Persistent abuse will erode credibility, and can be grounds for some type of de-accreditation.

I believe this type of system is a significant improvement over backroom grant programs, blind allocations, and popularity contests through retroactive funding.

I believe this setup or something similar to it, could address some of the problems mentioned in this thread.

First, there is no recipient address for Validators to vote on, and no splitter contract. We remove the king-of-the-hill game because allocation happens through tasks governed by domain expert institutions. Yes, institutions could create self-serving work, but the capture surface is narrower. Task completions produce visible deliverables and institutions operate under a mutual monitoring environment. The budget limits any damage, whereas the capture of the splitter contract captures everything. The allocation game still exists, but its much smaller and more transparent.

Second, the free-rider problem Cles brought up is also addressed. The majority trigger still operates as discussed. A validator cartel that captures teh redirect rate cannot form under this design because ETH flows to the Fund contract rather than a splitter contract where addresses are chosen by the Validators. They can control the rate, but not the destination.

I just wanted to share these thoughts/ideas to contribute to the ongoing dialogue around possible solutions.

Peace.

[rolfyone]

@clesaege

@mishudark

Why not just use part of the fees being burned on every transaction?

I think that this would indeed be better than the status quo (and I would support such proposal).

I still prefer my proposal, because if we were to only take it from the burn fees, we may end up in a situation where validators would have incentives to reduce the gas in order to ensure that ecosystem can be funded (instead of keeping it low to favor growth in term of usage).
Here taking from the block reward means that we can independently decide of:

• How much ecosystem funding should we give?
• How much value should we capture?

I’m not an economist, I need to call that out first…

My understanding of ‘the burn’ is that its to nullify inflation, and spending part of it is an inflationary act.

If that’s true, then we’d need to increase the burn by the amount we want to yield, so that the act is not inflationary I guess? but it seems like a slippery slope, you could easily see it being like a ‘GST’ where it starts small and grows over time. Could also see more actors wanting a piece of the pie if that kind of mechanism did exist I guess?

[ellierennie]

I’ll offer a framing point from some ethnographic work I’ve done on validator governance — mostly in Cosmos, where on-chain validator voting already exists (see published paper with Jason Potts and Josh Tan, ‘The Natural State of Blockchains: An ethnography of validator governance’ in ICS).

The thread has rightly converged on cartelisation. My concern is that the proposal is a category shift for Ethereum.

Today validator rewards and penalties are defined impersonally by the protocol. A 51%/66% attack lets you censor or destroy, but — as the exchange above concedes — not redirect a standing pool of capital toward yourself. VRR creates that pool and makes its allocation a discretionary, political decision. In institutional economics terms (see North, Wallis & Weingast (NWW)), that’s the manufacture of a rent plus a locus of discretionary power over it: the defining feature of a limited-access order, where a coalition of elites decides who is admitted to the flow of funds. The 10% cap bounds the size of the prize but it doesn’t change its nature.

The deeper issue is that the proposal’s safety case rests entirely on elite restraint whereby cartels can tank the price, the social layer can fork them out, the majority is honest, operator competition disciplines bad allocation etc. Each of these is a limited-access-order argument: order held together by interlocking elite self-interest and the threat of mutual destruction, rather than by impersonal rules that make capture impossible. It’s the ‘natural state’ in the NWW social order framework, not an escape from it. We should be looking for designs that constrain elite power structurally instead of trusting elites to constrain themselves.

On the operator-competition defence specifically (@clesaege’s rejoinder, and the “users migrate to operators whose values they like” mechanism): my fieldwork showed some flaws in this. The consistent finding across validators on DPoS chains was that delegators stake and forget. Validators who built newsletters, dashboards, and voting-intention disclosures to compete on governance reported almost no engagement and no measurable delegation gains — delegation tracked yield and brand, not governance behaviour. Staking share is definitely sticky. If delegators won’t switch operators over how their validator votes on protocol governance, there’s little reason to expect them to switch over where their validator redirects their rewards. The principal-agent problem isn’t softened by a values market.

And while decoupling impersonal rate-setting from discretionary allocation may separate out the political part, it relocates the limited-access boundary to whoever accredits the institutions, which is the same problem.

I also think the issue may be mis-specified in the VRR proposal. The framing here is “public goods / free-rider,” whereas what’s actually being funded is better understood as dependencies: which software, research and infrastructure other things rely on. That distinction matters, because if recipients are identified by tracing dependencies, “which addresses get funded” stops being a vote validators take and becomes something a contribution system computes. Protocol Guild already is a contribution system. Validators might be well-placed to signal the redirect rate (a collective macro question); they are the wrong body to choose recipients.

One caveat from having watched contribution systems up close is that contribution systems don’t abolish the limited-access boundary; they relocate it to whoever governs the metric and the membership. So the real design question, for any version of this — VRR, accredited institutions, a Protocol-Guild route — is where subjective judgement enters and how legible and contestable the reward function is to the people it’s imposed on (I have written about this elsewhere, including ‘Value through Contribution Systems’ which discusses validators specifically). Validator-selected recipient addresses puts that judgement at the most concentrated, least contestable point in the stack. A dependency-tracing system with broad, commons-style governance over its weights puts it somewhere more defensible, but it’s only as good as the contestability of those weights, which is where the design effort should go.

I am all for funding development. But minting a discretionary rent and handing allocation to the most concentrated layer of the stack builds limited-access institutions (aka feudal Italy), when the tools to compute allocation from contribution already exist and point the other way.

[clesaege]

@zeroproof

Funding allocation doesn’t drive contribution. Conviction does

Both conviction and funding drive contribution. When analysing work opportunities, people look at the utility they can get out of it:

• Skill increase (ex: internship).
• Self-realization (contributing to highly impactful projects, conviction).
• Payments (probably the most important).

Conviction alone doesn’t pay the bills. And when there are other conviction opportunities around (ex: AI, other L1), offering significant less payments means that we’ll get significant less talents.

Also contrary to Linux, in Ethereum, there is a class of people directly benefiting from contributions (ETH holders), so it may look unfair to ask people to contribute for free to enrich them (and I say that as an ETH holder not “paid to contribute”).