EIP vs ERC: How Ethereum Standards Work and Why They Matter for Security

EIP and ERC in One Minute

An Ethereum Improvement Proposal, or EIP, is a design document that proposes something for Ethereum: a protocol change, a networking change, a process change, or a standard that applications can follow. It is the formal way the community writes down a proposal, its rationale, and its specification.

An Ethereum Request for Comments, or ERC, is one category of EIP: the Standards Track proposals that define application-level conventions. ERC-20 tokens, ERC-721 NFTs, ERC-1155 multi-tokens, and ERC-4626 vaults are all ERCs. They do not change how Ethereum nodes behave. They define interfaces that contracts, wallets, and applications agree to follow.

So every ERC is an EIP, but most EIPs are not ERCs. EIP-1559, which changed how transaction fees work, is a Core EIP that every node had to implement in a network upgrade. ERC-20 is a standard that nothing forces anyone to adopt, yet almost every token does.

EIP Types and Categories

EIP-1, the living document that defines the process, describes three types of proposals. The Standards Track type is further divided into four categories, one of which is ERC.

How a Proposal Moves From Idea to Final

A proposal usually starts as an idea discussed with the community before anything is written formally. Once it is properly formatted and merged by an editor, it is tracked as a Draft. The author then requests peer Review, the proposal enters a final Last Call window, and if it survives, it becomes Final.

Three other statuses matter when you read a proposal. Stagnant applies to proposals in Draft, Review, or Last Call that have been inactive for six months or more. Withdrawn means the authors abandoned the proposal and its number cannot be reused. Living is reserved for documents meant to be updated continuously, such as EIP-1 itself.

EIP editors check that proposals are complete and correctly formatted; EIP-1 states that they do not pass judgment on the ideas themselves. Whether a Core EIP ships is decided by client developers through network upgrades. Whether an ERC matters is decided by adoption.

Only Final proposals have stable requirements. Building on a Draft means accepting that its interface may still change.

Why ERCs Now Live in Their Own Repository

For years, every proposal lived in one repository. In 2023, EIP-7329 split ERCs into a separate repository so that application standards and core protocol work could evolve at their own pace. ERCs are now maintained in the ethereum/ERCs repository and published at ercs.ethereum.org, while core and process proposals remain at eips.ethereum.org.

The numbering is shared, which is why you still see both EIP-20 and ERC-20 used for the same token standard. In practice, ERC is the conventional name for application standards and EIP for everything else.

Standards Developers and Auditors Meet Every Day

A small number of proposals appear in almost every codebase or affect how almost every contract behaves. Knowing what each one promises, and what it does not, is the difference between integrating a standard and merely calling its functions.

Where Implementing Standards Goes Wrong

Standards remove ambiguity about interfaces, but they leave plenty of room for unsafe implementations and unsafe assumptions. These are the patterns auditors check most often.

using SafeERC20 for IERC20;

uint256 before = token.balanceOf(address(this));
token.safeTransferFrom(msg.sender, address(this), amount);
uint256 received = token.balanceOf(address(this)) - before;
// credit the user with `received`, not `amount`

How Auditors Check Standards Compliance

Standards are written with RFC 2119 keywords: MUST, SHOULD, and MAY. Auditors check each MUST requirement against the implementation, note deviations from SHOULD requirements, and read the security considerations section of every standard the code implements or integrates. Integration review matters as much as implementation review, because a vault, lending market, or router usually depends on the behavior of tokens it did not write.

When a protocol intentionally deviates from a standard, the deviation should be documented, tested, and visible to integrators. Silent deviations are a common source of bugs in other people's code. Kann Audits Expert Security Audits review both sides: whether your contracts honor the standards they claim, and whether they stay safe when the contracts around them do not.

• List every standard implemented and every standard assumed of integrated contracts.
• Check MUST and SHOULD requirements, events, return values, and rounding rules.
• Test with non-standard tokens: fee-on-transfer, rebasing, missing return values, and unusual decimals.
• Bind every signature to chain, contract, nonce, and deadline.
• Revisit address and account assumptions after EIP-7702.

Questions About EIPs and ERCs

Short answers to the questions developers most often ask about Ethereum proposals and standards.