EOSCommunity.org Forums

A Proposal - Eden Governance as a Service

Hello EOS!

This write up is my humble attempt to start a more formal and open EOS community discussion on the recent events surrounding the SX Vault hack. More specifically this looks at the actions taken by EOS BPs to resolve the event and how access to those actions should be more widely available.

I will do my best to keep this short, but for you skim readers the headings and bulleted TLDRs can get you to the point.

Also please keep in mind that Eden on EOS is still very new! Anything I’m suggesting here is based on many more trial elections taking place and proving, among other things, that selecting for merit and trust are prevailing attributes of those who make it to the top.


  • EOS is awesome

  • Governance is better when merit counts

EOS has an opportunity to be the first blockchain to utilize the Eden political playoff system, which was invented by Daniel Larimer and described in his book More Equal Animals. Unlike traditional crypto quasi-governance entities (e.g. Bitcoin Foundation, Ethereum Foundation, Cardano Foundation) Eden on EOS can easily engage, identify, and promote its most dedicated and deserving community members to positions of influence. This meritocratic system levels the playing field by removing many of the advantages gained by deep pockets and difficult to obtain strategic relationships.

As Eden grows it’s members will represent an increasing percentage of the EOS community’s entire population. Eventually, more Eden groups will form around languages other than English, and this network effect will transform “Eden on EOS” into a truly global community of communities, or democracy of democracies.

What Can Eden Do?

  • Eden selects for trusted individuals from within the community

  • The Eden Board is trusted to judge on “intent of code” disputes

The more one learns about cryptocurrencies the more one realizes this is a revolution on many fronts. It is not just some nerdy, overly technical internet money, but an emergent voluntary global community. EOS still has the best tech but has struggled with the formation of its community, until now! Eden represents an opportunity for the EOS community, where whales and plebs have equal power, to arrive at consensus on not only what path project funding on EOS should take, but how a layer of trusted humans can be utilized in governance. Eden is an opportunity to reallocate the power of EOS back into the hands of the community members themselves and away from those that simply profit without giving back to the chain and token holders alike.

If we can agree that the majority of Eden members want what is best for EOS, we can then reasonably conclude (by trusting the Eden system) that most of the final round elected Eden members (the “Board”) will make decisions that are in the best interest of EOS and the EOS community as a whole. I understand this is a leap for some, as we are now trusting a novel process to identify and promote individuals that are to be “trusted.” Blockchains after all are often designed to be deliberately “trustless” so this might seem quite counterintuitive. The issue of course can be boiled down to the debate of “code is law” vs “intent of code is law.” Without passing judgement as to which of these two options is ideal, what I will say is EOS was designed and launched with “intent of code” being the dominant perspective. This was indicated by the initial constitution and creation of the EOSIO Core Arbitration Forum (ECAF).

The missing piece required to properly integrate the “intent of code is law” perspective is deciding who exactly gets to judge the intent. I, and many others, would suggest that the Eden process solves this. Those that make it to the Board after each Eden election playoff are trusted by the community such that if put in a position to arbitrate on an intent of code dispute, these individuals will pass the correct judgement. Therefore, they will do what is best for EOS and the entire EOS community.

Focusing on a Quick Win

  • Win-win outcomes with aligned incentives are ideal

  • Change should be minimal and deliberately gradual

  • We need a new deal between BPs and the community to allow for equal access to BP “god powers”

Part of my success in the first mock Eden election was focusing on the idea of getting a quick win, with a measurable outcome to define victory (Note: victory doesn’t need to be one-sided. The best victories are when all parties involved “win”). I will use that same strategy here. If we really want the BPs in control of the chain to accept any type of proposal that curtails their “god powers” we need to focus on keeping things simple. So simple in fact that it would require minimal coding and minimal changes to the status quo.

We all know about “change” and how it can be difficult to achieve. This especially if the final goal is radically different from where we are today. Therefore, in order to achieve great things, that involve substantial change, we are wise to target incremental progress along this path. There are many benefits to this approach, one being we actually might get somewhere. Another is that our current goal might not be ideal. Without focusing on gradual change, we lose opportunities to correct course and improve upon what that final outcome becomes.

I would suggest it is time for a new deal between the EOS community and the BPs that operate the EOS blockchain. This deal could be considered a “Peace Treaty” as explained in Dan’s book. This treaty should lay out the expectations of the community as to why, when, and how the BPs use their “god power” to influence the chain. The treaty would include details on who in the Community can access these powers, but more importantly how they can be accessed. We must ensure exploit and hack recovery are granted to as many dApp developers as possible. This will lead to a levelling of the playing field so that all EOS dApps, big and small, have an opt-in solution to resolving exploits and hacks that were previously only available to the well connected .

A Peace Treaty

The following example is a system that could be outlined in a potential Peace Treaty between accepting BPs and the EOS Community.

What if we create a solution that is opt-in for BPs and dApps alike? This system would include a fee mechanism for arbitration services when they are requested? The fee will prevent spamming this service and provide fair compensation for the time of those involved (BPs, trusted experts, and Eden members) to deal with the issue and bring it to resolution. The Eden Board is trusted to judge the intent of code dispute and then approve the BP’s use of their “god powers.” BPs would agree to never use these powers unless “Eden” approves it (Note: Eden here is loosely defined since ideally this would be a group of Edens collectively working together on these adjudications and not just the English one). The deliberations of the Eden Board(s) are publicly recorded no different than the elections themselves. The Eden Board(s) would need to achieve the same 2/3+1 vote to approve any action. For example, change account keys, move tokens within accounts, or whatever else these “god powers” may permit. The fee for services needs to be large enough to incentivise BPs, material experts, and Eden Board members to respond in a timely manner. The Eden Board members could make it known in advance what their intentions would be with the funds received from these services (i.e. donate it back to Eden for future round funding, or a hybrid with some compensation for time and inconvenience with excess donated).

The following is an example workflow of this process:

Set up:

  • A Peace Treaty is created with clear terms and rules of engagement. This includes details on how dApps can access these services and commitments from BPs on responsiveness when requested.

  • BPs signal their acceptance of the Peace Treaty. This becomes another metric used by the Eden voter proxy (and others) to consider when voting for BPs as not all will accept this deal.

  • dApps indicate to their users and signal to the BPs that they are participating and have opted-in to this deal. This should include an approval check from Eden that the dApp contracts have passed a trusted security audit. dApp users therefore agree that in the event of a hack/exploit, it is possible that some dApp functions will be halted, or related accounts that interact with the dApp may be temporarily affected (e.g. tokens frozen).

A hack occurs:

  • The affected dApp sends a signal to the BPs that a hack has occurred and submits a request for BPs to initiate atypical emergency actions. The format of this submission should be predefined. It would include, among other things, any details of the exploit/hack, the requested temporary action, the desired final outcome of this request, and if accounts are to be frozen the details needed to do that are also provided (e.g. account names with proof of theft/fraud). This signal should be accompanied by a bond to prevent spamming the BPs with false claims. The greater the severity of the claim, and the larger the number of affected accounts, the larger the required bond. The larger the bond the faster it is expected the BPs will act and can be detailed in the treaty. This bond could for example be a dApp’s “risk reserve” account.

  • Any action taken by the BPs at this stage is only temporary until the situation is reviewed by “Eden.”

Eden called to arbitrate:

  • A signal is sent to Eden from the BPs that their services are requested to review a claim.

  • The Eden Board members, as part of their duties, agree to be available within a certain time-frame to adjudicate claims. They can signal their availability and if a member of a Board is unavailable (planned or non-responsive) a random member from the playoff tier below the Board can be randomly selected to fill in. This tier of members will also signal their availability for urgent requests.

  • The Eden Board will assemble on a live recorded call with representatives from the BPs, the affected dApp, any material experts, and the defendant (if available).

  • The Eden Board must come to a 2/3+1 vote to permit the requested use of BP “god powers” to resolve the issue.

  • The fee schedule for these services should be known in advance. Any overpayment from the bond will be returned to the dApp owner(s) regardless of the outcome. BPs, material experts, and Eden retain their portion for services rendered.

Governance as a Service

Eden can be leveraged to provide many governance related services to the EOS Community. The funding of Eden could be used to build the following products and services:

  • Security tools for dApps that will decrease the likelihood of needing to request BP intervention (i.e. automated sanity check and signalling apps, secure withdrawal contracts with and without time-delays etc…)

  • Auditing services from an approved list of auditors.

  • A trusted list of security experts to support hack/exploit investigations.

  • Ricardian Contract review and support to ensure these are up to date and accurate.

  • Education services for dApp developers and users to understand the risks associated with smart contracts.

  • Applications that support the dApp submissions of exploits/hacks to BPs. This will streamline communications between dApps and BPs thereby facilitating faster and more accurate responses from BPs to temporarily mitigate any further damages.

  • An insurance product could be created for users and dApp owners to insure against potential losses.

  • An Eden Proxy can be created that will select BPs based on a fixed scoring/ranking system. This ranking system can be updated similar to Eden Bylaws.

That’s all I got… again this is just a set of suggestions to start a conversation. I expect much, if not all of this will be improved upon or removed and replaced entirely with a better proposal. Regardless, we need to come together as a community and have our voices heard. We need to make it clear that we are not ok with unequal access to special privileges by a select few.

We should strive to become more equal animals and amplify our power where 1+1=3.

Go EOS!!!



Love the idea and think it is definitely needed and not just for EOS, I believe the exact details on how it’s achieved will definitely need to be agreed on but you have my vote, well done on your proposal let’s hope it gets implemented soon as possible so people that are unlucky enough to lose funds have a way to get it back. Go EOS :grinning::+1::rocket:


Looks good, and it’s evident that there are really good standards being stood up for Eden leadership roles in the making.

This will take a huge load off the community with a protocol like this.

I support this v1 version.

Really good starting point!


Good start, I like the general tone and direction as well as the amount of thought put into it.

Here are a couple of my observations after a quick read:

Comments on A Proposal - Eden Governance as a Service

  1. A Peace Treaty
    • Example Workflow Process
      • A hack occurs:
        “The larger the bond the faster it is expected the BPs will act and can be detailed in the treaty.”

“The faster it is expected the BPs will act” should be deleted as speed of action should not be tied to the size of the exploit or those affected. This would again revert to a class divide where bigger Dapps, who would also tend to be the better connected, would have special treatment.

I do agree, the bond should be a percentage of the estimated amount of damage at risk, but BPs should be acting in order of when the claim was received, not whos claim is larger.

“The fee schedule for these services should be known in advance.”

I agree, this is essential. Because there are differently sized dapps and different level users who’s net worth changes constantly, it may be more advantageous to define the fees in terms of percentages of periodic snapshots rather than fixed amounts, or expected levels of protection ex. (10,000 EOS account size pack pays 2%/yr, 100,000 EOS account size pack pays 3%/yr, 1 Million EOS size pack pays 1%/yr (the numbers are chosen at random))

What we may find is that there may be a minimum amount established, where below this amount it is not worth it to the system to offer protection to these Dapps, and they’ll just have to be more careful not to get hacked, and the users as in any market, more wary of using these Dapps.


I agree with the general direction, but as always, the devil is in the details.
I would point out the things that I don’t think would work.

First a general comment; Eden is exciting but we don’t know how it would turn out. We can’t really rely on something until we see the real-world outcome. Getting access to resolve the hacks and whatnot might even incentivize Eden attacks. So I would suggest we let it run for a year or two, and at best pick people on top by hand and put them in a multisig for resolve situations.

Second is the idea that you can open BPs services to anyone. You can maybe do that with a couple of “community” BPs, but when the hack comes, you cant rely on their responsiveness, since there is no obligation and literally nothing you can do to punish them. The rewards won’t work as well, since hacker can easily pay them 100x as much to just stay silent for the day or 2.

What you actually need is access to the whole coordination mechanism they use, which can’t be offered to dapps, mainly because of their “bandwidth”, but also because nobody would want to present all the parts front and center (centralization optics).

Personally, I don’t see any way to make EOS a neutral platform for dapps with the god powers. Instead, we should offer mitigations where dapps can opt in into different multisig - with which they have an actual relationship with the key holders. Mind you, this is what made EOSX vault reversal possible - the relationships.
Lack of relationships (that BPs build with vote exchange and while coordinating system upgrades/resolving bugs) is what would always keep God powers access limited (both in ability to sign at all, and also in ability to coordinate in secret, + ability to sign it fast in time sensitive enviroment.

To put it simply; access to God powers does not (socially) scale.

I would soon put up the proposal to propose opt-in mitigations, and gradual removal of those powers that can’t be democratized - and probably shouldn’t be because of it damage to integrity of the public blockchain.


Thank you for your work on this, Chris.
You’ve really hit the ground running. It’s encouraging for all of us.
There are a lot of moving pieces here to work through. With the processes being outlined, including the new governing model, it’ll be great to see how things are tweaked over the next couple of years to streamline these efforts and hone them to peak efficiency.


Great work Chris. Hope the entire community will rally behind this version 1 so that we can iterate until we arrive at the best proposal possible.


Who takes part in the Eden Board?

1 Like

A lot of this is very appealing as a Dapp / Mapp developer.

I think these services provided to Dapp devs could also help the Dapps gain trust with potential users and token holders.

I’m also wondering will the arbitration delay have a negative impact on the ability of BPs to reverse TXs? if the funds change hands a lot, go to exchanges, off-chain, etc, it would get messy, right or wrong?

“BPs would agree to never use these powers unless “Eden” approves it”

This is a big ??? for me, as I think it’s cool that Eden could (under treaty) make requests to BPs, but I don’t think that this should become a requirement for BP action. If code is law, that’s just re-writing the law too much.


I think suspending transactions in the case of a legitimate hack of a well-audited Dapp should be quick and comparatively easy, assuming the suspension can not be argued as damaging to an entity, itself.
Eden can adjudicate carefully.
I would try the system where Eden recommends to the BPs but let’s try this with no enforcement hard-wired first. If Eden truly represents the community, the BPs would want to acquiesce rather than be voted out by the community. If possible, the BPs do not have their power compromised by a new mechanism as it may not be necessary.


thanks Nanga. An even better, more technically sound proposal was put forth here as well: EOS as Neutral Infrastructure

What’s great about Luka and Aarin’s proposal is that mine can work with it, which is awesome!

1 Like

When each Eden community has an election, the final round of that election process becomes the “Board.” Each Eden community will have its own Board and this Board is who chooses the winner (Satoshi) as well.

1 Like

You should check out this proposal as well. Its a better solution to providing equal access to resolution options to all dapps and can still include using Eden (or whomever) as a trusted arbiter in the case of disputes. https://forums.eoscommunity.org/t/eos-as-neutral-infrastructure/3547

Have a look at the other proposal that I’ve just linked a couple times. For the BP selection bit I expect we’ll eventually create an Eden proxy and see how much buy-in (via vote weight) we get from the community. The BPs will act accordingly if the Eden proxy becomes a legitimate force in their selection.