Uh. Or just add a column to the spreadsheet with a name 
For the fee change EIP, Vitalik was the original author, Eric helped out, now Rick is the working group lead. So, champion / point of contact is Rick.
A working group column would be good too.
Also, code centric dudes, the point of contact doesnât need to be an engineer â just someone who is helping with coordination and project management.
That is fine too 
It solves the problem for me
But not sure it solves ^
I am confident I am not the only person who runs into this issue.
Also
Yes
Can you please explain why should it be possible that thereâs no technical person as a point of contact for a protocol changing Core EIP? I can understand that could be the case for ERCs or non-Core EIPs.
Core EIPs should be serious specifications and there should be an obvious way to reach someone capable of answering specific technical questions about a specification. If there are multiple hops someone has to go through to reach a technical person, then I do not think such a Core EIPs should have a chance to be accepted. If there is no technical person willing to champion it, that signals to me there is no technical need for it.
At the specification stage (e.g. Draft mode) there must be a technical champion. When the specification is clear and coordination focuses around implementing the change in second and subsequent clients, there I could see non-technical coordinators to play a big role.
Yes technical people need to be involved. To pick on @MadeofTin, heâs not going to be able to defend a Blake2b precompile. But he could coordinate whatever is happening in the GitHub / Gitcoin thread.
EIPs with multiple authors needs to have one POC, a team (eg Parity or a Working Group) having a single point of contact for multiple EIPs, etc
This is all theoretical so letâs just do the work of filling out the spreadsheet. Iâd like to capture the name not just GitHub handle.
@MadeofTin there are lots of things we canât see by looking at an EIP, which is why weâre going to need to track things outside of a Markdown file
Accepted as a Draft? Maybe the EIP-1 requirements need to be updated because that wasnât on the list when I submitted blake2b nor 2025.
Your role as the champion is to write the EIP using the style and format described below, shepherd the discussions in the appropriate forums, and build community consensus around the idea.
As far as I can tell, that is exactly what I am doing. Of course, anything beyond being accepted as a Draft I understand. Why âaccepted as draftâ is the gatekeeper for this I donât understand. I will respect it, I just donât understand it.
What is the issue in labeling an EIP as Draft? Being draft doesnât mean you are going to be accepted. Being draft doesnât mean the core-devs need to bring it up on calls. After it is accepted by an editor it could never be brought up again. It is the first stage in the rest of the process. My previous understanding was that the requirements to be made a draft is that it was correctly formatted.
Draft â If agreeable, EIP editor will assign the EIP a number (generally the issue or PR number related to the EIP) and merge your pull request. The EIP editor will not unreasonably deny an EIP.
Draft â Reasons for denying draft status include being too unfocused, too broad, duplication of effort, being technically unsound, not providing proper motivation or addressing backward compatibility, or not in keeping with the Ethereum philosophy.
Draft â Once the first draft has been merged, you may submit follow-up pull requests with further changes to your draft until such point as you believe the EIP to be mature and ready to proceed to the next status. An EIP in draft status must be implemented to be considered for promotion to the next status (ignore this requirement for core EIPs).
What is the resistance to marking things as Draft? I am not upset, I just want to understand where I am wrong on this.
This is our first time through the EIP driven network upgrade process, so I donât think any of these rules are hard and fast but are taken more of a measure of what EIPs are viable for this specific network upgrade. The fact there is a document that can be pointed to and a person willing to attend calls and advocate on FEM I think are the two strongest indicators, aside from the next checkpoint which is actual implementation in clients.
I know the deadline have passed but I would like to add a last minute proposal (EIP-2075) since it relates to 2 proposals already part of 1679 (EIP-1706 and EIP-1930).
See PR for hardfork : https://github.com/ethereum/EIPs/pull/2077
Hope that is fine, thanks.
EIP-1 currently requires a âtechnically soundâ specification.
Also from EIP-1:
The main point of being Draft and having a somewhat comprehensible Specification is to allow actually useful discussions to happen around it. If a Draft doesnât have any specification, then how will it be discussed?
I actually like @timbeikoâs proposal clarifying the EIP-1 text:
My understanding based on this is that EIPs without specification should not be drafts, but rather discussions in appropriate forums, such as FEM.
Updated http://eips.ethereum.org/EIPS/eip-1679 to reflect the current status as per todayâs ACD call.
S
Ilan from Kyber
we would like to test and prepare our code for Istanbul fork.
anyone can share a working ganache version. Or any other working client?
Thanks
Ilan Doron
Solidity developer
Kyber Network
Pantheon 1.2.2 release has a full implementation - https://pegasys.tech/solutions/pantheon/#installation-links
Gethâs git head also has a full implementation, and is fairly straightforward to build - https://github.com/ethereum/go-ethereum
I have reviewed this EIP and all its dependencies. My complete list of outstanding review comments follows: