The Ethereum Classic (ETC) ecosystem is in the process of debating ECIP-1098 [1] [2], which is a proposal; called proto treasury, proto Ethereum Classic Treasury System, or p-ECTS for short; to establish a treasury system in the blockchain to provide incentives and finance client and protocol development.
Previously, I have written about why a treasury system should not be implemented in ETC due to centralization risks [3]; and later, after continued ecosystem support for a treasury system, I have written about in what conditions a treasury would be acceptable [4], which are essentially a time limit to the features.
After more research about the subject, gauging support for the proposal, and talking to several ecosystem participants, I am writing my final comments about the proto treasury, posing some questions about some of the details, and providing suggestions to the current design [5].
Comments
The format provides 100% fixed funding upfront with no apparent accountability from client members or Gitcoin grantees.
It does not make sense to send funds blindly to Gitcoin without knowing how they will be allocated, what they will finance, and with no control of what the grantees will do or even if they will do it. The Gitcoin member should be removed, in my opinion.
Terms as “wider community development”, “evolving development of the ETC platform”, “clear vision”, etc. are vague and blurry aspirational statements, but do not really provide any concrete requirement for plans or roadmaps from the client members.
That funds are directed to client members and then their proposals go through the ECIP process is a statement that provides a false sense of community control over funds and projects. The reality is that, once client members receive such large amounts of capital, they will gain significant control of the network and its future development.
Due to the above, and that voting is mapped 1 to 1 to ETC token units, also makes the “collective funding decisions” statement a false aspiration, as very few will decide future changes.
There is no advancement nor installation of a real decentralized “governance” system. The treasury just establishes three client members as the new dirigents of ETC. The ECIP process, the treasury proposal process, and the supposed ability to add or remove client members become a sort of “decentralization theatre” because the client members, by themselves or together with large staking voters, will have overriding power over the roadmap and decision making.
The “built in obsolescence” or “shut down” feature of the treasury is also a false sense of community control for the same reasons as above.
The miner ability to burn funds gives unnecessary power to miners as expressed in comments I made before in this issue [6]. Miners already have their role and power in the network so the miner tax burning feature should be removed, in my opinion.
The assumptions that client teams will provide updates and share decision making with the community also provides a false sense of community control. It seems incentives for client members are to actually shut down the community and implement their preferred projects.
The only real balance of power this proto-treasury establishes is whatever adversarial relationship the client members may have between themselves, and the normal adversarial relationship between client members, miners, and node operators.
In fact, the relationship between client members and miners and node operators will be similar to a provider-customer relationship. Very much how a large tech company provides services to enterprise customers, e.g. Red Hat. But paid by the network, not the customer.
As this proto treasury pushes funds to client members and Gitcoin a priori, there is no incentive for them to actually propose innovation, or efficient servicing of the network. As miners do today, they can just sell the ETC they get for USD, BTC, or ETH, and just continue acting as if they were interested in ETC. Or, they will keep enough funds and rich ETC owner allies to favorably vote for every proposal on the treasury.
For all of the above there will likely be no control over project lifecycles, timing, quality, nor any other assurance parameter.
In the case of the Gitcoin member, it is even worse because the separation and layers between treasury or community, and the final grantees are even more, and there is no control of delivery or assurances. Especially, for external marketing and other difficult to monitor and measure activities.
Questions About Some Details
The assumptions section mentions “smart contracts” in the following way:
“All smart contracts will go through one or more professional security audits before deployment. After deployment, independent parties will need to verify that the deployed contract corresponds exactly to the audited version. All ETC clients will include this in their actual hard fork proposal.”
What are “smart contracts” in this context? Is it the treasury smart contract itself?
The assumptions also mention “supply changes will require a hard fork”, does this “supply” refer to the 20% miner tax?
The voting description mentions a 60% threshold of yes votes over no votes, does this mean that a simple majority of 60% of votes is needed to effect changes to the treasury? Or, is there a different calculation or threshold for this voting mechanism?
The “quorum” is set at “1/3 of total ETC supply”, what does “supply” mean here? The total ETC supply of 117 million ETC? The stock of ETC in the treasury itself? Or the staking of ETC in each proposal? Other?
Suggestions
– Remove Gitcoin member.
– Remove the miner burn of funds feature.
– Change funding of client members from a priori funding, to a posteriori funding through the ECIP proposal mechanism. This transfers some real power back to “the community” and gives a real function to the ECIP process.
– If client members will not be incentivized to work for ETC if the funding will be conditioned by the politics of the ECIP process, then a portion of their allocation could be guaranteed to pay for fixed costs, and then their ECIP proposals could be further funded on a case by case basis as in the previous point. For example, the treasury could send 50% of the miner tax to client members (1/3 each), and the other 50% could be retained in the treasury to be paid to them only on an accepted or final status ECIP by ECIP basis, according to the formal ECIP process. This would also provide some control by the community and create more accountability from the part of the three client members.
– Put a definite termination term for the proto treasury where it will shut down automatically and the community has to hard fork to actually continue it. This is a stronger guarantee than having to vote to shut it down.
Notes and References
[1] ECIP 1098: Proto Treasury System- by Julian Mendiola, Nicolas Tallar, Brian McKenna: https://ecips.ethereumclassic.org/ECIPs/ecip-1098
[2] The Ethereum Classic Improvement Proposal Process Explained – by Donald McIntyre: https://etherplan.com/2019/08/07/the-ethereum-classic-improvement-proposal-process-explained/8504/
[3] Why Ethereum Classic Should Not Create a Treasury – by Donald McIntyre: https://etherplan.com/2020/08/14/why-ethereum-classic-should-not-create-a-treasury/12384/
[4] Ethereum Classic Protocol Compact 2020 – by Donald McIntyre: https://etherplan.com/2020/09/27/ethereum-classic-protocol-compact-2020/12822/
[5] Final Comments of The Ethereum Classic Proto Treasury Proposal – on Github – by Donald McIntyre (@TokenHash): https://github.com/input-output-hk/ECIPs/issues/2#issuecomment-761190746
[6] The boss in the system is the database – on Github – by Donald McIntyre (@TokenHash): https://github.com/input-output-hk/ECIPs/issues/2#issuecomment-701889931
Code Is Law
