ECIP-1051 Ethereum Classic Treasury system [EthereumCommonwealth]

[Dexaran]

ECIP: ?
Title: Ethereum Classic Treasury system
Status: Draft
Type: Standard Track - Consensus
Author: Dexaran, dexaran@ethereumclassic.org
Created: 2018-12-31

Abstract

The following describes the possible implementation of a development funding mechanism.

Motivation

The crypto industry is actively developing. This also applies to Ethereum Classic. In order for the development of the project to continue it is necessary to incentivize developers to take part in it. Having a professional development team also requires a permanent source of funding.

We have a precedent of one of the main ETC development teams being shutdown due to lack of funding. (announcement reference)

Ethereum Commonwealth, the other ETC development team, adheres to the policy of financial transparency. According to our public financial report, you can see that we did not receive any funding since July 2017 to the end of 2018.

Summarizing the above, I can conclude that a permanent source of development funding is essential for further growth and maintenance of the project and ecosystem. This source of funding should be implemented at the protocol level.

The source of funding must ensure:

• financial transparency - this is ensured by the ability to track transactions.
• constant cash flow which must be used to incentivize contributors to develop Ethereum Classic core OR ecosystem.
• agnosticism - third party contributors must have access to the source of funding even if they never contributed to ETC development before.

Specification

General

The proposed solution is based on Callisto Network Treasury.

Callisto Network Treasury advantages:

1. Has a working implementation (geth / parity)
2. Already tested in real market environment.
3. Simple and secure to implement/rollback.
4. Compatible with ECIP-1017: ETC monetary policy.

Technical

The proposed treasury system relies on two system addresses that receive funding at the protocol level. The protocol-level funding is a split of a base block reward. When a new block is mined, the reward is represented by three values: miner's block reward, X and Y where:

• X goes to the first Treasury address.
• Y goes to the second Treasury address.
• (base block reward - (X + Y)) goes to miner's address.

This is possible to implement the described scheme without changing the base block reward, thus keeping the original 5M20 Ethereum Classic monetary policy unaffected.

[Dexaran]

The first Treasury address.

There is an "official" Community Fund in Ethereum Classic.
The community fund multisig is an open source software. Smart contract passed a security audit.

Thus, I propose that the first Treasury address should be the official ETC fund multisig: 0x48dbda9443746a99ef1b26ab01dd94ac50d7014b

[OmniEdge]

This source of funding should not be implemented on protocol level. Contested HF will cause a split in the network. Even if HF's feel democratic a contested HF needs to be avoided. IMHO, dealing with this tragedy of commons is more acceptable then adding a treasury/gov system on L1 and L2. But L2 treasury is permissionless...

[stevanlohja]

A sum levied on users to fund a collective of developers would be a Developer Tax. This type of tax is centralized implementation on a protocol level and not for Ethereum Classic, Bitcoin, or any other "decentralized" network for that matter. A Developers Tax is not equal to a Consumption Tax on public decentralized networks. A treasury associated with ETC development not on the protocol level is a much better way to improve the ETC development community.

[phyro]

Agree with @OmniEdge and @stevanlohja. We should keep the L1 clean and as simple as possible. These problems are outside of what the protocol should care about.

[stevanlohja]

Meant to comment not close issue lol.

[realcodywburns]

@Dexaran can you please submit this as a PR can it can get a number and get recorded

[drd34d]

A treasury proposal without a governance proposal feels incomplete to start.