EIPs
EIPs copied to clipboard
ethereum
One-time NFT Sale of unused EIP numbers.
Problem
- We could use funding to pay for full time editors.
- Users want to be able to choose their EIP numbers.
- We want to maintain credibly neutrality and not give number preference to "friends of editors".
Solution:
We do a one time auction of all unused EIP numbers between 1 and 5000 in the form of NFTs. When a user wants to create an EIP, they can either get a number assigned to their EIP (following current or new selection strategy), or they can burn one of the NFTs just before their draft is merged and we'll let them have that number.
The proceeds would go toward funding EIP editors (specifically, funding to hire someone to replace me). Additional things we could spend money on should the proceeds be particularly high:
- Full time staff to work on process automation.
- Fund development/enhancement/maintenance of the executable and consensus specs repositories.
- White glove service assisting people with EIP authoring.
- Authoring and maintaining of external resources related to upcoming Ethereum standards.
What chain would this be on? If it was on Ethereum, the fees would be prohibitive. If it was on e.g. Gnosis chain, then, well, it wouldn't be on Ethereum.
It would be on Ethereum, because none of the current L2 chains are censorship resistant (they don't align with the ethos of Ethereum currently). I don't think the fees would be too prohibitive on L1 though. We would need to think through auction design, and potentially we could do the auction off-chain but proven on-chain with some kind of ZK prover system (high engineering cost, but very cool).
I'm very much down for designing and implementing this. I'd suggest an eventual goal as maybe having all the EIPs accessed via IPFS with the hash stored/updated on-chain.
Making the EIP process more sustainable is a great aim.
I would want to see any number with potential value up for auction rather than just limited to below 5000.
Auto assigned numbers could be large, e.g. 6 or 7 digits, with no repeating single digit, double digit or triple digit patterns and not ending in zero. Remove the majority of value from such auto-assigned numbers and avoid EIP editors having to make subjective choices on number usage.
There are many numbers that are "special" like 1337, palindromes, etc. I think figuring out what numbers people will want in advance will likely result in missing some. Also, it makes it harder to assign new numbers because we now have to check to see if a particular number has already been auctioned or not.
We can always auction unused numbers < 6000 auctioned once the repository hits 6000 issues. 🤷
I'd basically say all EIP#NFTs will be assigned to an EIP editor multisig by default. Then the EIP editors can decide who gets them :)
Would you like it if I started working on an impl?
I'm working on an implementation (https://github.com/Pandapip1/EIPNumberNFT/), whether or not it'll be used. It should be able to be used to do what is described above. Collaborations are welcome!
The following is a pdf of images that I made: EIP # NFT (1).pdf
Not owned: owned by EIP editor multi-sig. Owned: owned by a different address Claimed: burnt token. Burned tokens are not removed (instead, they are sent to the one address) to ease implementation and prevent confusion.
While I very much love this idea in theory, I want to mention a couple possible drawbacks:
- Editors now have to think about whether an EIP number is auctioned or not; and
- It's a blatant cashgrab that might hurt the reputation of the EIP process; and
- We've explicitly renumbered EIPs because they tried to snipe a number. Auctioning off those numbers now, while letting other EIPs keep theirs seems unfair.
I don't think either of those are dealbreakers.
As for the mechanism, if we go ahead with this, I think we should generalize it to work forever, not just the first 5000 numbers. Maybe we do a special auction for the unused numbers in the first 5000, however.
I'd suggest dividing the EIP space into chunks of 1000. EIP numbers in the next chunk (so 6000-6999 at the time of commenting) would be available for purchase. Once the "free" counter gets close to that range, that chunk locks and the following one unlocks for purchase.
Or... I guess we could just do it adhoc and deploy new contracts as we see fit?
@Pandapip1 how would you feel about burning the NFT to use the number?
I really did this idea, although I wish it was implemented sooner 😅
Anyway, a simultaneous dutch auction for each of the numbers seems like the right mechanism to sell the numbers.
I wonder if a fork of ENS might be the right solution for ownership, so there is ongoing cost/revenue for squatting numbers? Once they are burned, there would obviously be no ongoing cost.
@Pandapip1 how would you feel about burning the NFT to use the number?
I thought that was the plan. Anyways, what my idea was is that every eip number (including already assigned ones, which must be burned by the multisig, and >4 digit ones, up to the integer limit) is by default assigned to the multisig (i.e. ownerOf(X) is the multisig by default).
Then the EIP editors can decide the best way to auction these off.
+1 to @auryn-macmillan, feels best to avoids treating an existing incremental counter as a scarce resource. ENS for EIPs makes a lot of sense to me.
Either implemented as ENS subdomains (imagine we had *.proposals.eth or similar) or as an ENS-style top level resolver (e.g. *.eip), and there would be a fee to register a "display name" for your EIP that will point to it, this fee would go towards similar funding goals as mentioned above.
For example, instead of EIP-1559 we could register it and refer to it as feemarket.eip or feemarket.proposals.eth.
EIPs that get merged will be permanently cemented with their display name (perhaps merged EIPs get a free display name if they don't have one), and ones that don't get merged need to be renewed to maintain.
@SamWilsn I think we should generalize it to work forever
Whilst it should be usable forever, I assume the bulk of the value will be in the early available numbers, with the highest value being single digit, then double, then triple digit numbers. Need to make sure that the value is captured by the sale of these low digit numbers and avoid squatters/speculators.
ENS does price differently based on the length of the name, but given EIPs only use digits, then the rarity is much higher, which should be matched in the price. Especially assuming that renewal fees only need to be paid until an EIP number is used/burnt.
https://docs.ens.domains/permanent-registrar-faq#how-much-will-the-yearly-renewals-cost
Yearly renewals cost $5/year for names that are 5 characters or longer. 4 character names cost $160/year, and 3 character names cost $640/year. Fees are paid in ETH. The ETH/USD exchange rate is set by the Chainlink ETH/USD oracle.
Ideally all EIP numbers would be obtained in the same way, so remove any EIP discretion on numbers being used from the EIP editors.
EIP creators could use much lower cost longer digit numbers (e.g. 5 digits). It would also add a non-zero cost to creating an EIP which could reduce some of the volume of EIPs being created.
Ideally ideas and even code could be reused from ENS to not be a distraction for EIP editors.
Ok, just went out on a limb and grabbed eip.eth. Happy to donate it to this effort.
For each of the existing EIPs, we should register and burn (send to address(0)) the corresponding number subdomain.
I'd like to see an multisig of the EIP editors as the registrant and a contract as the controller. I'd suggest that the controller contract should allow anyone, at any time, to kick off a one-week dutch auction starting at some ridiculously high ETH price and decreasing linearly over the course of the week. The first person to press the "buy" button gets the domain, at whatever the current price is. I naively assume that this could probably be implemented with some minimal changes to the contracts that handle ENS' premium pricing after expiry.
After the auction, the subdomains should follow the same pricing model as ENS domains, but the content should only be settable by the EIP editor's multisig.
I really dislike that. Since EIP process is based on BIPs, which is based on PIPs, which is based on RFCs I am not sure that the culture of selling numbers would follow the origins of the process.
EIP creators could use much lower cost longer digit numbers (e.g. 5 digits). It would also add a non-zero cost to creating an EIP which could reduce some of the volume of EIPs being created.
How about if the namehash ends with 0, then it's a free one that is owned by the EIP editors?
I'd suggest dividing the EIP space into chunks of 1000. EIP numbers in the next chunk (so 6000-6999 at the time of commenting) would be available for purchase. Once the "free" counter gets close to that range, that chunk locks and the following one unlocks for purchase.
@SamWilsn I'm not opposed to auctioning off more numbers later, but I am hesitant to over-engineer for that. The number of available numbers between 1 and 5000 I suspect will be enough to last us many years at the current rate of EIP creation, less if we assume some amount of acceleration of EIP creation but still quite a bit. Also, I suspect we'll learn lessons if we do this once and we can apply those lessons to future auctions if we don't lock-in now.
Lastly, I am hesitant to auction numbers higher than the current PR/Issue number because that complicates the editor number assignment process.
@Pandapip1 how would you feel about burning the NFT to use the number?
I was thinking today about maybe turning the NFT into a soulbound token upon redemption, so the author can retain it as a cool thing. I'm not a fan of any of the current soulbinding EIPs as I feel pretty strongly that the "soul" should not be an Ethereum address but instead should be an NFT (e.g., an ENS name), but perhaps as part of this process we can work on developing a better soulbinding standard, or at least prototyping one.
I really dislike that. Since EIP process is based on BIPs, which is based on PIPs, which is based on RFCs I am not sure that the culture of selling numbers would follow the origins of the process.
@radeksvarz Was there something specific about this proposal that bothers you? I'm not personally a big fan of blindly doing as others have done just because they did it, but perhaps there is some reason that others haven't done this in the past that would apply to us?
Ideally all EIP numbers would be obtained in the same way, so remove any EIP discretion on numbers being used from the EIP editors.
I think it is important that creating an EIP is costless for someone who wants to. I don't think we should develop a system that requires people to pay to create an EIP, which includes paying to buy a number. I would be particularly worried about someone buying up all of the numbers from 1 to 10,000 and then you have a situation where EIPs numbered 10,000+ are second class citizens written by self-identified poor people.
I think it is important that creating an EIP is costless for someone who wants to.
I second this. This is why I proposed that numbers with a namehash ending in zero (or some other semi-random criteria, such as ending in 0-8) should only be assignable by the EIP editor multisig.
EDIT: I also re-propose that my EIP (https://eips.ethereum.org/EIPS/eip-4834) combined with NFTs would be a better system for this than ENS, as it means that registration of an EIP can follow a consistent standard.
I think it is important that creating an EIP is costless for someone who wants to.
My biggest worry is also along these lines, I worry that people will think you need to own the NFT to raise a proposal and this could put people off from doing it.
There is no doubt that finding better ways to fund this process would be great and should be found I just worry that financalising the numbers won't end well and speculators who will not ever make a proposal will scoop up all fancy ones as with ENS names making the process less open and free.
Also one thing to note is that @blmalone made a cool NFT token project for final EIPs last year which could be used for reference in some way e.g. this one from 2981 https://opensea.io/assets/ethereum/0x5d96a22daae62e6c18dcdc32b5c102c317a0187a/100298100002
Could other ways be found to fund this public good?
Was there something specific about this proposal that bothers you? I'm not personally a big fan of blindly doing as others have done just because they did it, but perhaps there is some reason that others haven't done this in the past that would apply to us?
I understand your point. My point is about the culture. Selling EIP numbers does not resonate (at least to me) with the current welcoming culture.
James stated the concrete concerns well in https://github.com/ethereum/EIPs/issues/5082#issuecomment-1133959224
My concerns echo those of @jamesmorgan 's.
Late last year I made eipnft.io. It was an attempt to reward contributors for getting their EIPs into FINAL status.
My thinking was that it be cool to recognize contributions to the Ethereum ecosystem through NFTs. This idea, coupled with the possibility of the tokens being sold on the secondary market made for an interesting experiment.
For example, @fulldecent as a co-author on EIP-721, was able to mint an NFT representing his contributions to the original NFT specification: here's the nft
It's most certainly more of a retroactive public goods funding model; which to be honest I haven't pushed very hard so I think it's still tbd if it's effective.
@radeksvarz @jamesmorgan @blmalone The intent is that there will always be the option of being able to create an EIP with a number assigned to you by the EIP editors (I feel incredibly strongly about this and am hard-lined against requiring a fee of any kind to create an EIP). The NFT numbers are for people who want to pay extra for a vanity number is all.
Let's reserve all the numbers through 10,000!
The Editors clearly have and have had authority to assign numbers. And this is a reasonable way to do it.
I support this initiative.
Now regarding the money.
- White glove service assisting people with EIP authoring. I offer this already in each week for free at https://twitter.com/fulldecent/status/1475851800322453504 and I offer it as a paid service https://phor.net.
- Funding projects is hard, picking which implementations to fund is hard. These decisions should not be in scope of this repository. Two default choices are to burn the Ether (yes really) or to send it to the Ethereum Foundation treasury.
I might be interested in your role unpaid, especially if I can do it without much work (and have plans on that).
As I see it, there are three sides and here are their arguments:
- NFTs are not the right way to do this, and a fork of ENS should be used instead.
- EIPs should not cost anything to submit
- EIP numbers should not be scarce
- ENS could be used to store actual EIP data
- EIP editors should not have to decide how to distribute EIP numbers
- Basic NFTs are the right way to do this
- EIP numbers can be distributed by the EIP editors to maximize funding for the EIP editors (which would encourage new EIP editors)
- The small fee would cause fewer EIPs to be submitted, reducing the turnaround time
- A complex system need not be developed
- A complex system involving NFTs would be the best way to do this
- EIP numbers can be distributed by the EIP editors to get a reasonable amount of funding for the EIP editors (which would encourage new EIP editors)
- The contract could, by using EIP2771, allow free minting of EIP numbers, so it's possible to make registering an EIP number zero-cost if that is a concern
- The system could implement complex rules for the changing of EIP data
For the sidechain issue: There are many sidechains with just as much security as the Ethereum Mainnet (due to zk-rollups).
If persistence is a concern, then it's always possible to, using bridges, copy the EIP data verifiably over to the Ethereum Mainnet.
There are many sidechains with just as much security as the Ethereum Mainnet (due to zk-rollups).
There are no L2 networks that are censorship resistant, permissionless, and trustless at the moment. The side chains mentioned are not functionally not censorship resistant.
EIP-2771 is stagnant (not final), so we cannot use it as a standard. However, we could use the ideas presented there in a non-standard way if we wanted. The problem with metatransactions is that someone still has to pay for gas, and if that isn't the user then it is someone else who can be griefed.
@Pandapip1
a fork of ENS should be used instead
I think I originally suggested an ENS fork, however since then I realized that a subdomain of the canonical instance of ENS is probably a much better option.
NFTs are not the right way to do this
ENS names are also NFTs ¯_(ツ)_/¯
For the sake of simplicity, future flexibility, and minimizing workload, I'd opt for the ENS subdomain option.
I also don't think metatransaction/gas abstraction are important for this, at least not initially. Better to solve one problem at a time.
How much money is this trying to raise?
Why can't the community pitch in? How long is this auction for? The enforceable EIPs (e.g. JSON-RPC have been moved out of this repo, will this cover those repos that contain EIPs now as well?
Why can't the foundation fund this? Would it be a better idea for the foundation to gift some validator nodes that way there is a sustainable source of financing EIP editors / activities without having to auction off a fictional namespace as an nft?
How much money is this trying to raise?
Unspecified. Ideally, enough that we can afford to pay one or more full time EIP editors and/or tooling developers for a substantial time into the future. However, any amount would help toward partially achieving this goal.
How long is this auction for?
Undefined at this time. This issue is to just float the general idea.
The enforceable EIPs (e.g. JSON-RPC) have been moved out of this repo, will this cover those repos that contain EIPs now as well?
My assumption is that the keyholders for the assets would be some trusted set of people ethos-aligned with Ethereum and they would be used primarily to cover standardization costs (which would include executable specs, EIPs, JSON-RPC, etc.). I wouldn't personally be opposed to excess funds being directed toward other ecosystem benefiting things tangential to that, but that complicates things so perhaps it is easiest to focus on "standardization and change control processes"?
Why can't the foundation fund this?
Currently, the Ethereum standardization process is not funded by the EF. I don't know who is funding the development of the executable spec. EIP editors are not funded at all. I think someone was funding JSON-RPC standardization for a while but I believe they aren't any longer. In theory anyone could fund any of these things but no one does at the moment.
The general idea here is that the EIP editors control an asset that some people value very highly, and the editors value very little. Since we need funding, selling off that asset feels like an obvious way to address two problems at the same time.
