We take a cut of all auctions facilitated by our smart contract, but we put no restrictions on owners' ability to transfer or sell their Kitties outside our site. In fact, CryptoKitties is the first smart contract to implement the draft ERC-721 standard, which attempts to make NFTs (non-fungible tokens) as interoperable as ERC-20-compliant fungible tokens. https://github.com/ethereum/EIPs/issues/721
In People have spent over $1M buying virtual cats on the Ethereum blockchainethereum
EIPs
Python2016–2026
ethereum / EIPs
EIPs
The Ethereum Improvement Proposal repository
48Distinct people
54Mentions
0Explicit recommenders
14.1KGitHub stars
What to know before exploring
What it is
The Ethereum Improvement Proposal repository
GitHub
Where it is used
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- ethereum/pm · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 2:59:53 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year54 dated mentions
Observed mentions: 2016-03-03 04:37:54 UTC to 2026-09-08 01:43:21 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 14 | 2 | 12 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 12 | 5 | 7 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 5 | 3 | 2 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 4 | 2 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 7 | 2 | 5 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Ethereum Improvement Proposals (EIPs)
ATTENTION: The EIPs repository has recently undergone a separation of ERCs and EIPs. ERCs are now accessible at https://github.com/ethereum/ercs. All new ERCs and updates to existing ones must be directed at this new repository. The editors apologize for this inconvenience.
The goal of the EIP project is to standardize and provide high-quality documentation for Ethereum itself and conventions built upon it. This repository tracks past and ongoing improvements to Ethereum in the form of Ethereum Improvement Proposals (EIPs). EIP-1 governs how EIPs are published.
The status page tracks and lists EIPs, which can be divided into the following categories:
Core EIPs are improvements to the Ethereum consensus protocol.
Networking EIPs specify the peer-to-peer networking layer of Ethereum.
Interface EIPs standardize interfaces to Ethereum, which determine how users and applications interact with the blockchain.
ERCs specify application layer standards, which determine how applications running on Ethereum can interact with each other.
Meta EIPs are miscellaneous improvements that nonetheless require some sort of consensus.
Informational EIPs are non-standard improvements that do not require any form of consensus.
Before you write an EIP, ideas MUST be thoroughly discussed on Ethereum Magicians or Ethereum Research. Once consensus is reached, thoroughly read and review EIP-1, which describes the EIP process.
Please note that this repository is for documenting standards and not for help implementing them. These types of inquiries should be directed to the Ethereum Stack Exchange. For specific questions and concerns regarding EIPs, it's best to comment on the relevant discussion thread of the EIP denoted by the discussions-to tag in the EIP's preamble.
If you would like to become an EIP Editor, please read EIP-5069.
Preferred Citation Format
The canonical URL for an EIP that has achieved draft status at any point is at https://eips.ethereum.org/. For example, the canonical URL for EIP-1 is https://eips.ethereum.org/EIPS/eip-1.
Consider any document not published at https://eips.ethereum.org/ as a working paper. Additionally, consider published EIPs with a status of "draft", "review", or "last call" to be incomplete drafts, and note that their specification is likely to be subject to change.
Validation and Automerging
All pull requests in this repository must pass automated checks before they can be automatically merged:
eip-review-bot determines when PRs can be automatically merged 1
EIP-1 rules are enforced using eipw2
HTML formatting and broken links are enforced using HTMLProofer2
Spelling is enforced with CodeSpell2
False positives sometimes occur. When this happens, please submit a PR editing .codespell-whitelist and ONLY .codespell-whitelist
Markdown best practices are checked using markdownlint2
It is possible to run the EIP validator locally:
Make sure to add cargo's bin directory to your environment (typically $HOME/.cargo/bin in your PATH environment variable)
cargo install eipw
eipw --config ./config/eipw.toml <INPUT FILE / DIRECTORY>
Build the status page locally
Install prerequisites
Open Terminal.
Check whether you have Ruby 3.1.4 installed. Later versions are not supported.
ruby --version
If you don't have Ruby installed, install Ruby 3.1.4.
Install Bundler:
gem install bundler
Install dependencies:
bundle install
Build your local Jekyll site
Bundle assets and start the server:
bundle exec jekyll serve
Preview your local Jekyll site in your web browser at http://localhost:4000.
More information on Jekyll and GitHub Pages here.
Footnotes
https://github.com/ethereum/EIPs/blob/master/.github/workflows/auto-review-bot.yml ↩
https://github.com/ethereum/EIPs/blob/master/.github/workflows/ci.yml ↩ ↩2 ↩3 ↩4
Read the full README on GitHubWhat Hacker News says
14 sourcesThere's a good chance that the unspendable ether problem gets solved in the next one or two protocol upgrades
https://github.com/ethereum/EIPs/issues/156
In Ethereum Now Handles More Transactions Than All Digital Currencies CombinedEthereum doesn't use UTXO like Bitcoin, so there is no inherent need to spend from multiple accounts. If you still want to do so, it's easy to write some smart contracts that allow you to do this. I don't see the use-case though.
Also, there are checksums for addresses: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-55.md I don't know anyone who would manually type an address though.
In Ethereum Now Handles More Transactions Than All Digital Currencies CombinedAs seanwilson says above, blockchains work by consensus. Leaving aside the "better", that does mean it is different. The instructions are still executed by computers as it was programmed as you say, but if enough users/miners agree this was not the intention of the contract/code, they can fork.
I do think that calling blockchains "immutable" can be confusing to users not familiar with the concept and its nuances. And I personally hold no opinion on whether the currently locked up funds need to be returned to their owner with a fork. There is something to be said for both options, specifically in this case where there the "rightful owner" is clear (like the other cases mentioned in https://github.com/ethereum/EIPs/issues/156 ).
In Parity Wallet security alertIt's pretty bad when the type of wallet that is supposed to be more secure has bugs like this multiple times. For reference, this only affects multi-signature wallets, not normal wallets. Very few normal users use multi-signature wallets.
The previous bug with these was very trivial and could have been caught by a unit test or a simple code review, and it resulted in around 9 figures (USD) of Ether being stolen.
This bug looks like it's exactly the same. A very simple bug that could have been caught by a simple test or manual audit, and has resulted in 9 figures USD being locked instead of stolen this time.
As mentioned by others it's possible at some point (not any time soon) that this frozen ETH can be recovered (https://github.com/ethereum/EIPs/issues/156) by adding rules to recover it in the next Ethereum hard fork. Not creating a sp
Read the rest
ecific hard fork just for this, but adding it to one that is planned in the future. That might come across as controversial, and cannot be guaranteed though.
For safely storing Ethereum I would advise to keep it out of smart contracts, period. Cold storage and hardware wallets exist, and they are much less likely to have critical bugs related to them than a smart contract is.
So I see this as a growing pain. But this is something that has already been thought of as something that could happen, and there is work looking into how to solve it going back a ways: https://github.com/ethereum/EIPs/issues/156
It looks like if this EIP is implemented in the future, the address that created the original multi-sig wallet contract created after July 20th, would just be sent the ether balance in the wallet. I'm not sure on this, but it seems like, if implemented in the future, an owner of a multi sig wallet that is frozen can call this contract from the same address they created the wallet with and it will retrieve the ether from the address where the contract is now blown away?
Another option would be during the next planned fork (upgrade), to just say, any contract that matches the byte code of the frozen wallet one, jus
Read the rest
t replace the code with this code and move on. Although the first option is MUCH nicer and future proof.
People will write bad code and things like this will happen. I think the more often and earlier on we find these types of flaws and can fix them, the better for the whole ecosystem. It's $300 million today... in 10 years, a mistake like this that hasn't been worked out could cause a shock to the entire world economy. (run on the banks, but there are no banks and everyone's funds are frozen...panic!)
So better now than later!
> Also, this hardfork seems to have been decided behind closed doors. Where is the mailing list discussion? Where did community members have a chance to raise concerns?
https://github.com/ethereum/EIPs
https://github.com/ethereum/pm/tree/master/All%20Core%20Devs...
These changes should be no surprise to anyone who's made any effort at all to follow Ethereum development.
In Byzantium Hard Fork AnnouncementI think the reference is EIP 101: Crypto Abstraction which is planned for the Serenity release.
https://github.com/ethereum/EIPs/issues/28
In Bitcoin Tumbles as PBOC Declares Initial Coin Offerings IllegalPL people often direct their "it should be functional and use strong typing" critique at the EVM rather than Solidity. Solidity is just one HLL (higher level language) that compiles to EVM bytecode.
A lot of the limitations of Solidity are due to constraints of the EVM, but the EVM is evolving. For instance, the next planned hard fork will enable the EVM to pass dynamically sized data (e.g. solidity arrays or strings) between call stacks. Previously arrays had to be fixed-size, so you'd have to define a fixed maximum size, then always return data of that size (usually a lot of empty elements). This feature, like many others, is somewhat challenging to design because every execution step of the EVM must be metered by a "gas fee"; the first version of the EVM kept it simple by only allowing return data to be a fixed size. See these issues f
Read the rest
or background https://github.com/ethereum/solidity/issues/164
https://github.com/ethereum/EIPs/pull/211
Also, the longer-term proposal is to adopt WebAssembly for EVM 2.0: https://github.com/ewasm/design. Then users can write contract code using any language with an llvm compiler (rust, ocaml, etc.).
There is an EIP that is slated to land in the upcoming hardfork that adds an EVM opcode for effectively "const" call that is enforced by the runtime:
https://github.com/ethereum/EIPs/pull/214/files
There are also proposals out for a number of the issues you have mentioned. I believe that people _do_ want to make Solidity into a better language for safe code authoring, but some things require EVM changes which requires a hard fork, and other things simply require time (discussion and engineering). The impression I get is that at this point there _are_ some voices of reason involved in the Solidity language process, but it will take time before those voices can enact all of the changes listed here.
Also, keep in mind that when Ethereum launched it did so like any scrappy startup, with an MVP that was "good enough" to move things forward.
Read the rest
Now that Ethereum is a leading contender in the blockchain race it is starting to have to pay for some of those early decisions.
How is that technically possible to prevent?
The miners in the two chains gain from listening to what is going on in the other chain, and could just copy transactions and take the commission.
Have no miner attempted to grab some fees? Or maybe the price of ETC is so low that it would be unprofitable?
----
Addendum:
It is addressed in EIP #155 [1], where they changed the signing of transactions and put some sort of chain identity to be included in the transaction signatures.
Which brings the question: Is there something changed in transaction signatures in the segwit2x hard fork? Is there already some chain identity in it?
[1] https://github.com/ethereum/eips/issues/155
In Bitcoin Is Having a Civil War as It Enters a Critical Month> long term harm to the value of ETH
I don't see why this is a problem. The goal of the Ethereum developers is to increase the utility of the network, not to artificially inflate the value of ETH.
In fact for one of the future Ethereum upgrades it's planned to convert ETH into a ERC20 token, so that it's at the same level as all the other tokens on the network. It wouldn't even get a special status in terms of transaction fees, as (IIRC) the plan is to allow miners to accept whatever tokens they prefer for the gas payment.
See https://github.com/ethereum/EIPs/issues/28 and https://www.reddit.com/r/ethereum/comments/572v7t/eth_as_an_...
In How can Ethereum systematically scale better?Istanbul Byzantine Fault Tolerance. Pluggable PBFT Consensus on Go-Ethereum
1 points · Open discussion