Supervisor-as-a-service in Eco Governance

Blockchain technology is rapidly gaining popularity for its decentralized nature and ability to provide secure and transparent transactions. However, decentralized systems require effective governance to ensure that updates and changes to the system are made in a way that benefits the entire network. This is where the role of the Supervisor comes into play.

Vision (Why)

The Supervisor is a software needed to call governance functions. These functions are called “Supervisor Functions” and include deploying community governance voting and scheduling protocol phases. The Supervisor is responsible for ensuring that the Eco protocol is upheld in a manner that serves the interests of the community.

In service of the protocol, the Eco Association is hosting an automated program that calls these critical state transition functions on a proper cadence, but any other actor is welcome to do the same for redundancy — there is no privileged access.

In the past, only the ECO Association operated a Supervisor service, which means that if their server went down, governance operations stop. The eco-system is more securely protected the more Supervisors that are run by the community.

Objectives (What)

Other than calling functions, there is no reliable way to determine whether a Supervisor is active. We would not be able to verify if operators who claim to have a Supervisor actually do so. The only way to tell if a Supervisor is active is if it triggers functions that can potentially result in a reward. To make up for all the times a Supervisor didn’t trigger a function and encourage the operator to keep maintaining the Supervisor, the incentive must be rational.

Since most entities are generally motivated by personal interests or advantages, an incentive system with a rationale offers advantages to attract participation. The financial incentive can be easily satisfied by adjusting reward amounts, and the eco-system may ensure that individual and group interests are aligned. Otherwise, participants can operate selfishly to maximize their own interests, which can lead to alarming scenarios.

The three main concepts on which the plan to use incentives for Supervisors is built are as follows:

Honesty - Dishonest behavior might occur if being dishonest provides benefits. A strong incentive should be able to motivate the participants to act honestly. Such a sincere incentive makes it possible for a system to function over the long term.

Fairness - An entity should be rewarded in a way that is commensurate with the contribution it made. The eco-system must be able to provide the participants with the necessary sum in a timely manner. Also, fairness promotes moral conduct and motivates them to contribute as much as possible.

Automation - Distributed systems like Eco require less centralized control for an incentive system to work with their decentralization. It should be automatic to reward triggering functions and distribute its incentives. Automation, which is usually accomplished by integrating incentive mechanisms into Smart Contracts, also eliminates the weaknesses in centralized incentive management.

Eco Governance Generation and Supervisor Functions:

Strategy (How)

As there are currently 2 extra community Supervisors, the incentive will be deemed successful if the existing Supervisors continue to serve or if new Supervisors emerge from the community. It is advised to put into practice a plan to reward Supervisors in two phases, in accordance with the philosophy of retroactive incentives as well as protocol-level long-term objectives of Eco protocol.

1st Stage: Retroactive rewards via Builders Ecollective

I first base the reward on a set of general requirements regarding properties and costs for evaluating the effectiveness of different scenarios. Supervisors have at least 8 fundamental actions to trigger per month but most likely the same Supervisor will not trigger all the actions. Some costs associated with the Supervisor include an average server, an Infura Developer Plan, and ETH in the Supervisor’s address to pay network fees for transactions.

If the incentive for Supervisors isn’t set properly, it could result in an imbalance of incentives and have a negative impact on the Eco consensus’ ability to function reliably. I suggest incentivizing each Supervisor for a maximum of three functions every 2 generations, equalling 1 month:

  • 1st function = 5000 ECO
  • 2nd function = 1500 ECO
  • 3rd function = 500 ECO

To strike a balance between honesty and fairness, the reward should get smaller with each subsequent installment. If we overcompensate Supervisors, a race to maximize setup and surpass low-end setups may emerge.

As centralized third parties, the Builders will manage, organize, and carry out these incentive mechanisms. Nevertheless, in fact, they are not entirely trustworthy because rewards are not automated and must be requested in advance via an EGP if funds are not available. Additionally, the manual implementation of their centralized incentive mechanism adds extra time and complexity to the process of allocating incentives.

2nd Stage: On-chain rewards via the Eco Protocol

The eco-system should have a superior mechanism to incentivize Supervisor Functions, which include rewards (or Supervisor Incentives), for successfully invoking governance functions.

By incorporating blockchain into the incentive mechanism, friction brought on by a centralized entity is removed as a decentralized incentive execution is supported. At the same time, the practicality and effectiveness of incentive mechanism design will be sustained by smart contract technology which can distribute Supervisor Incentives automatically and avoid disagreements.

Similarly to the rewards of a miner that generates a confirmed block in Ethereum, the underlying protocol level Supervisor Incentives mechanism in the eco-system should provide essential incentives to the Supervisors, so they ignore the ulterior motive to act dishonestly. Motivating system entities to participate and behave cooperatively is an economically effective approach to suppress the influence of selfish behavior.

Assumptions & Risks

Denial-of-Service (DoS) attacks involve purposefully targeting flaws in a system protocol or physically exhausting an item being attacked of all of its resources. Attackers can use malicious behaviors to prevent honest participants from receiving incentives by preventing them from triggering functions that will result in unsustainability in terms of monthly expenses, stopping Supervisors, and causing the Eco Protocol to stop consensus. For the protocol-level Supervisor Incentives the protocol update should have this into consideration, any way that accesses and exposes the IP where the Supervisor apps are hosted (similar to validator nodes) can result in drastic outcomes.

Over-Incentivization a system in which actions are rewarded when they are repeated will lead to a situation where participants are aware that their greater efforts would directly affect their wallets. The correct incentives are essential for encouraging healthy competition, having well-defined goals, and increasing supervisor retention. If the incentivization is wrong at the protocol level in a way that it allows participants to be motivated by selfish behavior, it will result in built-in limitations and provoke resentment within the participants, which will end up in manipulation.

Reputation opens a good possibility for reputation-based incentives that focus more on motivating Supervisors. There is potential for a hybrid system that establishes rigorous and explicit protocol-level incentivization and afterward engages in retroactive incentives with manual actions that may even employ arbitrary time periods. Reputation-based incentives typically use reputation values to control behaviors with a variety of factors, including how long a Supervisor is running, free market considerations, particular third-party difficulties arising from unexpected outcomes, and more.


This document discusses the importance of effective governance in decentralized systems like blockchain and introduces the role of the Supervisor in ensuring that updates and changes to the system benefit the entire network. The document proposes an incentive system for Supervisors based on the concepts of honesty, fairness, and automation, and outlines a two-phase plan for rewarding Supervisors. The document also identifies potential risks, including denial-of-service attacks, over-incentivization, and reputation concerns.


I think this is not a choice but a necessity. Thanks for preparing this.

With ~26 generations a year, the maximum incentive for a supervisor would be 182k $ECO if the supervisor performs all functions (1st, 2nd, 3rd gen function in each cycle). Meaning that the total budget planned for this is 182k $ECO in total. Is that correct?

The docs are not clear on this but would only the “winning” supervisor that performs the function be rewarded in your model? If so, I think there may not be a need to limit the number of supervisors. But if all supervisors are intended to be rewarded, it may make sense to limit the number.

1 Like

Stefan, I appreciate your input! I’m thrilled you agree that this initiative is worthwhile since I’m extremely happy to have it started. There was a typo in the post and I fixed it right after making the post, I meant 3 rewards every month, not per generation.

I advocate for a monthly retroactive reward for two key causes:

  • Builders will need to manually monitor on-chain functions, thus keeping it to once a month will help with the burden;
  • The Infura plan is a requirement, and there are monthly and annual payment options. Most developers choose the annual plan to obtain a better deal, but if someone chooses to pay on a monthly basis, the incentives can be synchronized with it.

These are some statistics that led me to the aforementioned recommendations:

  • One year has ~26 generations
  • One supervisor in the best scenario possible gets 39 rewards per year
  • A maximum a supervisor gets would be 91,000 ECO per year

Supervisors will not trigger all functions, however, here are some calculations if they did:

  • 1st function: 13 * 5000 = 65,000 ECO
  • 2nd function: 13 * 1500 = 19,500 ECO
  • 3rd function: 13 * 500 = 6,500 ECO
  • Totals: 91,000 ECO

Supervisor setup expenses for one full year:

  • Infura plan: 12 * $50 = $600
  • Lowend server: 12 * $10 = $120
  • ETH for fees: 12 * $16 = $192
  • Totals: USD $912

Incentive vs expenses:

  • Best possible scenario for rewards equals USD $1820 per year at the current rate;
  • One-year expenses of a supervisor equals $912 per year.

Current supervisors in the wild:

  • Association: censured
  • Shahrukh: censured
  • Flarcos: 0x46Dc03769aa89D0754C788941C5DBFEff05b8944
  • Saulo: 0x0e8a50C4442e402df1EE088a459dA8770A343c79


  • My supervisor is on a Raspberry Pi 4 configured locally, which is acting as a backup and will not compete with high-end VM on AWS, that’s my plan and on purpose;
  • Supervisors will not trigger all functions! A supervisor won’t receive all 39 prizes each year, it would only happen if there was just one supervisor which is not the case, so the 39 rewards will be divided among all active supervisors;
  • The incentive for the 1st function is higher to cover 1 monthly expense, all consequent rewards are extra likely to not happen often;
  • Monthly expenses are around USD $70, if one supervisor triggers one function gets at least USD $100 worth of ECO per month;
  • There will be increased competition as more supervisors emerge;
  • The suggested incentives is just a starting point, it may change based on community or Association feedback.

Great plan, I am really happy to see that we are finally moving forward with this initiative. The importance of the supervisor cannot be overstated, our entire governance system depends on it, and proper decentralization can only be achieved if the incentive mechanics are in place. We can’t compromise on this issue, and the rewards Saulo suggested are very appropriate and well thought out. I will support the implementation of this incentive system, thank you Saulo for presenting this document.

1 Like