Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 18 additions & 15 deletions EIPS/eip-2025.md
Original file line number Diff line number Diff line change
@@ -1,16 +1,16 @@
---

Check warning on line 1 in EIPS/eip-2025.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

preamble is missing header(s): `description`

warning[preamble-req]: preamble is missing header(s): `description` --> EIPS/eip-2025.md | | = help: see https://ethereum.github.io/eipw/preamble-req/
eip: 2025
title: Block Rewards Proposal for funding Eth1.x
author: James Hancock (@madeoftin)
discussions-to: https://github.com/MadeofTin/EIPs/issues

Check warning on line 5 in EIPS/eip-2025.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

preamble header `discussions-to` should point to a thread on ethereum-magicians.org

warning[preamble-re-discussions-to]: preamble header `discussions-to` should point to a thread on ethereum-magicians.org --> EIPS/eip-2025.md:5:16 | 5 | discussions-to: https://github.com/MadeofTin/EIPs/issues | ----------------------------------------- required pattern was not matched | = info: the pattern in question: `^https://ethereum-magicians.org/t/[^/]+/[0-9]+$` = help: see https://ethereum.github.io/eipw/preamble-re-discussions-to/
status: Withdrawn
type: Standards Track
category: Core
created: 2019-04-20
requires: 1890
---

Check warning on line 12 in EIPS/eip-2025.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

body is missing section(s): `Security Considerations`

warning[markdown-req-section]: body is missing section(s): `Security Considerations` --> EIPS/eip-2025.md | | = help: must be at the second level (`## Heading`) = help: see https://ethereum.github.io/eipw/markdown-req-section/
## Simple Summary

Check warning on line 13 in EIPS/eip-2025.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

body has extra section(s)

warning[markdown-order-section]: body has extra section(s) --> EIPS/eip-2025.md | 13 | ## Simple Summary | ::: EIPS/eip-2025.md | 57 | ## Rewards Distribution Rationale | ::: EIPS/eip-2025.md | 118 | ## Accountability | ::: EIPS/eip-2025.md | 130 | ## Personal Notes and Disclosure | ::: EIPS/eip-2025.md | 152 | ## Implementation | ::: EIPS/eip-2025.md | 156 | ## FAQ | = help: see https://ethereum.github.io/eipw/markdown-order-section/

Add `0.0055 ETH` per block for 18 months (A total of 17050 ETH) as a developer block reward reserved for funding specific Ethereum1.X working groups. The working groups are State rent (750k), Better sync (360k), Finality gadget (360k), Fee market (360k), Testing infrastructure (360k). Governance of the funds will be through a multisig of trusted individuals from the ecosystem including client teams, the foundation, and the community.

Expand All @@ -22,7 +22,7 @@

## Motivation

The context for this proposal came from attending the [Core Dev Eth1.X Meeting](https://www.youtube.com/watch?v=Au1Qll-86v0) in Berlin. Development is needed to move Eth1.X forward, and I observed that a lack of funding is the primary barrier to this work. This work can only be effectively conducted by working groups forming around these issues, and these working groups need funding in order to pay dedicated contractors and project managers. This proposal is a plan for funding these groups and supporting their operation.

Check warning on line 25 in EIPS/eip-2025.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

non-relative link or image

warning[markdown-rel-links]: non-relative link or image --> EIPS/eip-2025.md | 25 | The context for this proposal came from attending the [Core Dev Eth1.X Meeting](https://www.youtube.com/watch?v=Au1Qll-86v0) in Berl... | = help: see https://ethereum.github.io/eipw/markdown-rel-links/

## Specification

Expand Down Expand Up @@ -55,19 +55,19 @@
```

## Rewards Distribution Rationale

```
Development loan repayment: 0.005 ETH per block: 15500 ETH total
Development loan interest (10% total over the period, simple interest): 0.0005 ETH per block: 1550 ETH total

Total Block Reward Increase = `0.0055` ETH per block: 17050 ETH Total
```

*With a price of Etheruem at $150.00 this will raise approx USD $2,325,000.00 for developing Eth1.X over the next 18 months.*

*With a price of Ethereum at $150.00 this will raise approx USD $2,325,000.00 for developing Eth1.X over the next 18 months.*

![Block Rewards Distribution](../assets/eip-2025/block_rewards_distribution.png) *Specific Addresses to be determined

* [FAQ - Why hardcoded values?]( #why-hardcoded-values )
- [FAQ - Why hardcoded values?]( #why-hardcoded-values )


## Rationale
Expand All @@ -90,12 +90,14 @@
`Development Loan: 0.005` over 3.1 Million blocks = 15500 ETH

**Funding Working Groups on 1.X**
* Funding Contractors, Coordinators, and project managers
* Working Groups defined with clear mandates

- Funding Contractors, Coordinators, and project managers
- Working Groups defined with clear mandates

Budget

Working groups

- State rent (750k)
- Better sync (360k)
- finality gadget (360k)
Expand All @@ -111,7 +113,7 @@



* [FAQ - How will the funding of the devs be organized?]( #how-will-funding-the-devs-be-organized)
- [FAQ - How will the funding of the devs be organized?]( #how-will-funding-the-devs-be-organized)

## Accountability

Expand All @@ -126,6 +128,7 @@
- Community

## Personal Notes and Disclosure

I want to address any concerns about conflicts of interests directly. My participation with Eth1.X currently has been as a volunteer. I am in talks about a possible funded role helping with testing and coordination. If my work for with Eth1.x is funded, I will accept no additional funding collected by the mechanism proposed in this EIP.

Eth1.X is the now of Ethereum and I would like to see it succeed. This is the intent of my proposal.
Expand Down Expand Up @@ -154,23 +157,23 @@

### Why Hardcoded Values?

Why not us a smart contract with some governance mechanism to allow changing the distribution of funds? Wouldn’t that be more flexible and effective?
Why not use a smart contract with some governance mechanism to allow changing the distribution of funds? Wouldn’t that be more flexible and effective?

*TLDR: This EIP is not about governance reform*

First, the payment of the loan will be hardcoded. Once agreed, the terms must be kept to give the lenders confidence in the repayment of the loan. As long as blocks are created the debt will be paid back. This is the essence of a trustless smart contract.

After the loan, there is the option to allow the amounts (limited to less than .05ETH), and the locations (orgs that receive ecosystem funding) to be changed throughout the emission schedule. It is pretty easy to imagine a smart contract or DAO fulfilling this role. However, there are three classes of options available today we can consider when governing changes.

* **Give the Keys to the Hands of the Few (Oligarchy)**
- **Give the Keys to the Hands of the Few (Oligarchy)**

Create a multisig that allows a group of individuals to update the smart contract. The most likely candidates for this are the Core Devs themselves, but it could also be a trusted few from the community/stakeholders. No matter how you slice it, there is a fundamental issue in deciding who gets to decide. There currently is not a trusted/adopted governance mechanism to make these decisions within the Ethereum ecosytem. Also, preventing changing the contract in self interest is difficult without a well-engineered governance system of checks and balances. This EIP does not claim nor aim to solve these issues.
Create a multisig that allows a group of individuals to update the smart contract. The most likely candidates for this are the Core Devs themselves, but it could also be a trusted few from the community/stakeholders. No matter how you slice it, there is a fundamental issue in deciding who gets to decide. There currently is not a trusted/adopted governance mechanism to make these decisions within the Ethereum ecosystem. Also, preventing changing the contract in self interest is difficult without a well-engineered governance system of checks and balances. This EIP does not claim nor aim to solve these issues.

* **Give the Keys to the Hands of the Many (Plutarchy)**
- **Give the Keys to the Hands of the Many (Plutarchy)**

Allow ethereum holders with coin votes to update the smart contract. Using holographic consensus could overcome the issue of voter turnout as it scales as participation scales, even to the size of the whole network. This has some benefits as the entire network can participate. However, the problem is that some individuals in the network are over represented -- the wealthy. Without a solution to identity that has been agreed to and implemented by the entire Ethereum Network, there is no way around giving more power in votes to the rich. This EIP does not claim, nor aim to solve these issues.

* **Use Ethereum Governance as it is Today**
- **Use Ethereum Governance as it is Today**

Criticisms or support aside, there is a system that governs Ethereum today. It is a mix of rough consensus among core devs, miners running nodes, clients implementing changes, and stakeholders adopting those changes. It includes yelling or not yelling on twitter and reddit. It is complicated and I don’t claim to understand it. Even without a clear view of how it works, there is evidence of its existence. This evidence is there are changes that have allowed to be implemented, and changes that have not allowed to be implemented in Ethereum.

Expand All @@ -180,30 +183,30 @@

### Why not allow current client implementors fund this work? (EF, Consensys, Parity, etc...)

Historically there has been a precedent that the Ethereum Foundation is solely responsible for funding the development of Ethereum. This process has evolved as the development has become more distributed. Aya Miyaguchi observed in a recent [Coindesk article](https://www.coindesk.com/ethereum-foundation-director-sets-new-vision-for-blockchain-non-profit), “it really is not only Ethereum Foundation people who are building [Ethereum]”. Yes, we could rely on the Ethereum Foundation to fund Eth1.X. But, why should we? This is a call for the network to come together and fund its own development. Ethereum _the network_ is not owned by any one organization or group of people. We are lucky to have the EF and I consider this EIP in support of their coordination efforts.
Historically there has been a precedent that the Ethereum Foundation is solely responsible for funding the development of Ethereum. This process has evolved as the development has become more distributed. Aya Miyaguchi observed in a recent [Coindesk article](https://www.coindesk.com/ethereum-foundation-director-sets-new-vision-for-blockchain-non-profit), “it really is not only Ethereum Foundation people who are building [Ethereum]”. Yes, we could rely on the Ethereum Foundation to fund Eth1.X. But, why should we? This is a call for the network to come together and fund its own development. Ethereum *the network* is not owned by any one organization or group of people. We are lucky to have the EF and I consider this EIP in support of their coordination efforts.

Check warning on line 186 in EIPS/eip-2025.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

non-relative link or image

warning[markdown-rel-links]: non-relative link or image --> EIPS/eip-2025.md | 186 | Historically there has been a precedent that the Ethereum Foundation is solely responsible for funding the development of Ethereum.... |

### How Will Funding the Devs be Organized

I do not profess to know the best way to organize these funds. There is work already in progress to organize these efforts championed by Alexey Akhunov. The following is a quote from a [recent medium article](https://medium.com/@akhounov/ethereum-1x-as-an-attempt-to-change-the-process-783efa23cf60):

Check warning on line 190 in EIPS/eip-2025.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

non-relative link or image

warning[markdown-rel-links]: non-relative link or image --> EIPS/eip-2025.md | 190 | I do not profess to know the best way to organize these funds. There is work already in progress to organize these efforts champion... |

> “Going from funding a few implementation teams continuously and letting them do 'their stuff' to funding more specific and temporary initiatives requires looking at funding through different lenses. How much 'due diligence' and oversight is too much (in terms of overhead), who can decide whether working groups actually deliver, etc. This is also solvable, and also more on this will come later (not in this post)."

My suggestion would be to create an Eth1.X core developer DAO using [DaoStack](https://daostack.io/) to coordinate membership and payment of the Core Devs, but ultimately they are capable of determining the system that works best for them. As long as the system is transparent and mature enough to distribute funds when the time comes, this is sufficient for now.

Check warning on line 194 in EIPS/eip-2025.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

non-relative link or image

warning[markdown-rel-links]: non-relative link or image --> EIPS/eip-2025.md | 194 | My suggestion would be to create an Eth1.X core developer DAO using [DaoStack](https://daostack.io/) to coordinate membership and p... |

### Isn't a loan considered a security, or is it?

I am not a lawyer and will seek further guidance from lawyers in the field on this point in particular. From the research I have done and conversations I have had there is a very good argument that a loan of this nature will not be considered a security by the US Supreme Court.
As the result of [REVES ET AL. v . ERNST YOUNG 1990](https://casetext.com/case/reves-v-ernst-young), the court stated that a home loan, consumer financing, a loan secured by a lien on a small business or some assets of a small business, short term notes, or notes that formalize a debt incurred in the ordinary course of business are not securities. If the note resembles the items listed above (home loans, etc.) then the note will not be deemed a security. The Supreme Court provided four factors to determine if a note sufficiently resembles the types of notes that are not classified as securities. ([source](https://www.invigorlaw.com/loan-subject-securities-regulations/))

Check warning on line 199 in EIPS/eip-2025.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

non-relative link or image

warning[markdown-rel-links]: non-relative link or image --> EIPS/eip-2025.md | 199 | As the result of [REVES ET AL. v . ERNST YOUNG 1990](https://casetext.com/case/reves-v-ernst-young), the court stated that a home l... |

Check warning on line 199 in EIPS/eip-2025.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

non-relative link or image

warning[markdown-rel-links]: non-relative link or image --> EIPS/eip-2025.md | 199 | As the result of [REVES ET AL. v . ERNST YOUNG 1990](https://casetext.com/case/reves-v-ernst-young), the court stated that a home l... |

**Family Resemblance Test**

1) The intentions of the company and the individual—if the company raised money for general use in a business enterprise, then the note is more likely to be a security; if the individual agreed to the loan primarily for the profit the note was expected to generate, the note is more likely to be a security.
2) The plan of distribution—the more widely the note is offered, the more likely it is to be found a security.
3) The expectations of the investing public—if the investors thought they were investing in a business to make a profit on their investment, the note is more likely to be found a security.
4) Other risk-reducing factor—if the note is collateralized or otherwise less risky than common notes, the note is less likely to be found to be a security.

The loan is for the specific use of supporting Eth1.X research and development. The distribution will not be widely offered and the note will be collateralized by the network itself, provided in ETH and repaid in ETH. In coordinating the collection of these funds recognise I may be legally liable for some of this work and I will do all of the due dilegence I can, seek legal counsel, and accept any legal repercussions resulting from this work.

####
The loan is for the specific use of supporting Eth1.X research and development. The distribution will not be widely offered and the note will be collateralized by the network itself, provided in ETH and repaid in ETH. In coordinating the collection of these funds recognise I may be legally liable for some of this work and I will do all of the due dilegence I can, seek legal counsel, and accept any legal repercussions resulting from this work.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).