proto-Treasury system for ETC

[bpmckenna]

The issue is the discussion for https://github.com/ethereumclassic/ECIPs/pull/349 which proposes a Proto Treasury for ETC

[gitr0n1n]

The community also has the power to add members to the p-ECTS. Only MemberType.Client can be added. There is no limit to the number of clients.

Request: I would like to formally request a dev team named Ethereum Core, or E.C. for short, be added as a a MemberType.Client. Rough proposal: Upon receipt of the stable funding, we will fork a client that needs material improvement in order to acquire adoption, e.g. Besu. Adding Value to the network by developing this client to be a competitive option in the Ethereum Classic marketplace for those that particiant in the PoW side of the project (miners).

Thanks! - r0n1n ethereumcore.org

Client Fork Repo: https://github.com/ethereumcore-org/besu

[erdnapa]

This proposal should be rejected without regard to its merit, as it violates ECIP 1017, Monetary Policy and Final Modification to the Ethereum Classic Emission Schedule.

An easy fix would be to make the p-ECTS payment mandatory, however, there is plenty to be said with regard to its merit as well (funding should be competitive, voting should have costs to show vested interest, etc).

[nogo10]

"Votes will be counted as total locked ETC that has participated (voted yes/no) on each proposal." If I read it correctly, the votes one person can cast is based primarily on the number of ETC they stake? I think it is feasible and more robust to allow one per participant whether they be developers, miners or large ETC holders. All have equal sweat equity in the success of ETC.. Technically an open source captcha could be used to dissuade Sybil attacks. The upside is a higher of participants.. having quorum is easier to achieve if all participants voice has a chance to be heard with voting rather than drowned out by a whale.

TLDR: a developer who spent thousands of hours of his time should have equal say to a large holder essentially 'buying 'Votes'

[nogo10]

An anti Sybil protocol could be implemented with captcha bots on the Discord discussion channel..

Another broadband approach is to use a tipping bot on Discord or Reddit to issue voting tokens based on much more than ETC balance: a participating attribution, if you will: upvotes tipping bot etc balance channel seniority number of deployed dapps membership level referrals number of transactions

[nogo10]

Rough consensus in a GitHub channel brings open discussion and better transparency to the process and record keeping as well. Those are advantages. The 'show of hands ', so easy to do in meatspace, needs to happen to have some closure and finality to the process to move things forward. GitHub is asynchronous and scheduling problems can hinder participants. So instead use approval upvotes/survey to keep a running tab on current options with a well published timeline. Even something as simple as a doodle poll would be effective.

So in summary: participation open to all via comments + upvotes survey polls on a fixed timeline with issue tracking.

Disclosure: I've been working on a decentralized solution that can solve this type of problem. Will be posting alpha in the coming months.

[nogo10]

difficult to associate proposals as to which are competing and which are complementary.

That is more difficult to solve, I guess a member is assigned to moderate topics/process in discussion channels. Such a member would not be able to vote but can assign addresses to a votinglist. I believe Discord plugins exist for that purpose.

[q9f]

Will be difficult to rally support behind such a proposal if you desire to exclude parties right from the beginning.

[erdnapa]

I've mentioned this elsewhere, but will include it here as part if the official discussion:

Two main issues:

1. The treasury should NEVER be optional. Either everyone contributes or nobody does. Having the option to sending etc to a burn address turns the treasury into a donation model - the exact thing the treasury is supposed to replace.
2. The treasury should NOT have a fixed distribution, so no teams, individual developer ratios etc. Those lead to laziness , since teams will get paid no matter what.

A better treasury would fund submitted proposals based the the merit as judged by votes. I'll outline a 'back of the napkin' treasury system, that would fix some of the shortcomings of the current ECIP:

• 10% mandatory treasure fee per block
• anyone can submit proposals, as many as they want
• voting and funding every 6 months at a predetermined block number
• Fund distribution exactly 1 month later
• Proposal application fee is 1% of requested funds
• Maximum funding per proposal 150,000 ETC (a bit less than 50% of funds), no minimum funding level
• Voting:- each YES/NO vote costs 0.1ETC per address to vote for the entire balance of the address (=shares)- any ETC address can change its vote as often as it wants, but only the last vote before the voting block counts. There is no refund of the earlier 0.1 ETC vote fee.
• Funding:- if more ETC are requested than are available: the funding will be reduced at the same percentage for all proposals, down to 75% of requested funds- the proposals with the highest YES/NO ratio get funded in order, until a project will receive less than 75% of its request, this and all other proposals with lower YES/NO ratio will receive no funding
• Result Evaluation:- Funded proposals have to submit Software/Results/Progress Report... 10 months after funding.- If further development is possible or necessary: Projects can ask for renewal/extension of funding at the same or lower level than the original proposal for a new funding round without application fee (up to 2x).- Renewals go into the proposal pool and are voted on the same as other proposals

The system outlined above has several advantages over the current proposal: it assures that the proposals with the highest merit get funded, it eliminates fixed ratios to teams and rather funds those based on the quality of their proposals and work. The system assures that voters are vested in the outcome of the vote by charging a small but noticeable fee. Finally, application and vote fees ensure that the treasury itself has enough funding to ensure the process runs smoothly.

Also note: such a treasury system is not necessary limited to development only, proposals could be submitted for any kind of project. For example: new client/wallet/blockchain dev, running a HA rpc service for the community, sending Etc into space, gifting each crypto journalist that wrote about ETC an ETC ornament..... But the community will vote and decide what it deems necessary.

Tweaking and optimization are surely required.

[IstoraMandiri]

https://www.ethereumclassicclassic.org/