Eips

The skill is based on the Ethereum EIPs repository (ethereum/EIPs), generated at 2026-02-25.

EIPs are design documents that specify features or conventions for Ethereum. This skill covers the EIP process (lifecycle, status, editors), document format (preamble, sections), categories, validation tooling, and best practices for writing and referencing EIPs. For the content of specific EIPs (e.g. EIP-155, EIP-712), read the source files in sources/eips/EIPS/eip-N.md or eips.ethereum.org.

Core References

Features

Best Practices

Generation Info

• Source: sources/eips (https://github.com/ethereum/EIPs)
• Git SHA: dc3dba6c7772d17b75556df7d41033c4f089705a
• Generated: 2026-02-24
• Supplemented: 2026-02-25 (core-editors-and-validation, features-erc-separation, features-commonly-referenced-eips, best-practices-referencing-eips; SKILL.md index)
• Docs used: README.md, EIPS/eip-1.md, eip-template.md, EIPS/eip-5757.md, EIPS/eip-5069.md, _config.yml, config/eipw.toml

Referencing EIPs and ERCs

EIP-1 and the eipw linter enforce consistent naming and linking so references are unambiguous and machine-checkable.

Naming

• Use the form `EIP-N` or `ERC-N` — with hyphen, no space (e.g. EIP-155, ERC-20). Not EIPN, EIP N, or eip-20 in prose.
• ERC vs EIP: Application-layer standards (tokens, name registries, etc.) are referred to as ERC-N; Core, Networking, Interface, and Meta are EIP-N.
• Do not put the reference in backticks in EIP documents — eipw flags EIP-N in backticks; use plain text or a markdown link.

Links

• Canonical URL: https://eips.ethereum.org/EIPS/eip-N. Use for citations and external docs.
• In-repo (EIPs repo): First mention in an EIP doc should use a relative link, e.g. [EIP-155](./eip-155.md) or [ERC-20](./eip-20.md).
• In code or external docs: Prefer the canonical URL so readers can resolve the spec regardless of repo layout.

In code comments and docs

When referring to a behavior specified by an EIP/ERC, cite the number and optionally the URL:

• Good: "Transaction signing follows EIP-155 (chainId in signature)."
• Good: "See https://eips.ethereum.org/EIPS/eip-712 for typed data encoding."
• Avoid: "See eip712" or "Implements EIP 712" (missing hyphen; ambiguous).

<!-- Source references:

• sources/eips/EIPS/eip-1.md (Linking to other EIPs)
• sources/eips/config/eipw.toml (markdown-re-eip-dash, markdown-no-backticks)

-->

Writing EIPs — Best Practices

Style

• Title/description: Do not include the word "standard" or the EIP number.
• One proposal per EIP; keep scope focused.
• RFC 2119: Use MUST, SHOULD, MAY etc. in Specification and cite RFC 2119/RFC 8174.
• Security Considerations: Required; must be sufficient for reviewers before Final.

External links

By default, do not link to external resources; they can disappear or change. EIP-5757 defines allowed origins and the approval process. Permitted origins (listed in EIP-1) must: uniquely identify a revision, have a history of availability, and not charge for access. Links must use the exact format and anchoring (e.g. commit hash, version, date) specified in EIP-1 for that origin (execution-specs, consensus-specs, devp2p, RFCs, W3C, etc.).

Tooling

• Use `eip-template.md` as the starting point; delete template comments before submitting.
• New EIP filename before merge: eip-draft_short_title.md; editor assigns number.
• Run eipw before opening a PR: eipw --config ./config/eipw.toml <file-or-dir> (from repo root).
• Put images and large assets in `assets/eip-N/` and link relatively.

Copyright and discussions

• Copyright: All EIPs must be CC0: Copyright and related rights waived via [CC0](../LICENSE.md).
• Discussion: Use discussions-to to point to a stable URL (Ethereum Magicians preferred); not GitHub PRs or ephemeral links.

<!-- Source references:

• sources/eips/EIPS/eip-1.md (Style Guide, Linking to External Resources)
• sources/eips/EIPS/eip-5757.md
• sources/eips/README.md
• sources/eips/eip-template.md

-->

EIP Editors and Validation

EIP Editors (EIP-5069)

Editors maintain the EIP repository: they publish proposals, facilitate discussion, and uphold minimal quality. They do not decide technical winners, assert correctness, manage implementations, or provide legal advice.

• Structure: EIP Editors plus one Keeper of Consensus (elected by editors). Keeper determines when rough consensus is reached and when to re-open settled matters.
• Formal decisions (add/remove editors, elect Keeper, controversial changes): call for input, quorum within 30 days, then rough consensus (Keeper decides). No veto except for add/remove-editor votes.
• Adding an editor: Quorum + candidate consent + no objection. Removing: Quorum + no objection from others.

Validation (eipw and CI)

PRs must pass automated checks before merge:

• eip-review-bot — Determines when PRs can be auto-merged.
• eipw — Enforces EIP-1 rules (preamble, sections, links, naming). Config: config/eipw.toml.
• Markdownlint, CodeSpell, HTMLProofer — Style, spelling, broken links.

Running eipw locally

cargo install eipw
eipw --config ./config/eipw.toml <file-or-directory>

What eipw enforces (summary)

• Preamble: Required headers (eip, title, description, author, discussions-to, status, type, created), order, allowed values for status/type/category, length limits (e.g. title ≤44 chars, description ≤140), discussions-to must be ethereum-magicians.org, last-call-deadline when status is Last Call, withdrawal-reason when Withdrawn.
• References: EIPs/ERCs referenced as EIP-N / ERC-N (not EIPN, not in backticks); references must point to existing eip-N.md files; requires dependencies must have valid status flow.
• Sections: Required sections present and in order: Abstract, Specification, Rationale, Security Considerations, Copyright (and optionally Motivation, Backwards Compatibility, Test Cases, Reference Implementation).
• Links: Relative links preferred; external links only to approved origins (see EIP-1 / EIP-5757).

When authoring or reviewing an EIP, run eipw before opening a PR to avoid CI failures.

<!-- Source references:

• sources/eips/EIPS/eip-5069.md
• sources/eips/config/eipw.toml
• sources/eips/README.md (Validation and Automerging)

-->

EIP Format and Preamble

EIPs are Markdown with a YAML front matter preamble (RFC 822–style, between ---).

Required preamble headers

Optional headers

• discussions-to — URL of discussion (e.g. Ethereum Magicians); no GitHub PRs or ephemeral links.
• last-call-deadline — When status is Last Call.
• requires — EIP number(s) this EIP depends on.
• withdrawal-reason — When status is Withdrawn.

Dates: ISO 8601 (yyyy-mm-dd). List headers (e.g. author) use commas.

Required sections

• Abstract — Short technical summary.
• Specification — Syntax and semantics; enough for interoperable implementations. Prefer RFC 2119 key words (MUST, SHOULD, MAY, etc.); if used, cite RFC 2119 and RFC 8174 at the start.
• Security Considerations — Mandatory; EIP cannot go Final without sufficient discussion.
• Copyright — Copyright and related rights waived via [CC0](../LICENSE.md).

Optional: Motivation, Rationale, Backwards Compatibility, Test Cases, Reference Implementation.

Linking to other EIPs

• First mention: [EIP-N](./eip-N.md) or [ERC-N](./eip-N.md) (relative path).
• Refer to ERC EIPs as ERC-N, others as EIP-N.

Auxiliary files

Put images and extra assets in assets/eip-N/; link as ../assets/eip-N/file.png.

<!-- Source references:

• sources/eips/EIPS/eip-1.md (What belongs in a successful EIP, EIP Header Preamble, Linking to other EIPs, Auxiliary Files)
• sources/eips/eip-template.md

-->

EIPs Overview

Ethereum Improvement Proposals (EIPs) are design documents that specify features or conventions for Ethereum. The EIPs repository holds the canonical source; EIP-1 governs the process.

Repository layout

• `EIPS/` — Individual EIP documents: eip-N.md (e.g. EIPS/eip-1.md, EIPS/eip-20.md).
• `eip-template.md` — Template for new EIPs.
• `README.md` — Repo overview, categories, validation tooling.
• `assets/eip-N/` — Auxiliary files (images, test data) for EIP number N.

Canonical URLs: https://eips.ethereum.org/EIPS/eip-N. Consider anything not on eips.ethereum.org a working draft; "Draft", "Review", and "Last Call" are incomplete and may change.

Categories

Note: New ERCs and updates are maintained in ethereum/ercs. This repo still lists historical ERCs and the EIP process.

Usage for agents

• Look up a spec: Resolve sources/eips/EIPS/eip-{N}.md or fetch from eips.ethereum.org.
• Cite: Use canonical URL, e.g. https://eips.ethereum.org/EIPS/eip-1.
• Naming: Refer to ERC EIPs as ERC-N (e.g. ERC-20); others as EIP-N.

<!-- Source references:

• sources/eips/README.md
• sources/eips/EIPS/eip-1.md

-->

EIP Process and Status

EIPs follow a defined lifecycle. Status is in the preamble status header.

Status flow

1. Idea — Pre-draft; not in the repo. 2. Draft — First tracked stage; merged when properly formatted. 3. Review — Author marks ready for peer review. 4. Last Call — Final review window; PR sets last-call-deadline (e.g. 14 days). Normative changes revert to Review. 5. Final — Final standard; only errata and non-normative clarifications afterward. PR to Final should only update status. 6. Stagnant — Draft/Review/Last Call inactive ≥6 months; can be moved back to Draft or earlier. 7. Withdrawn — Author withdrew; final, cannot resurrect same number. 8. Living — Intentionally updated (e.g. EIP-1).

Shepherding

• Author/champion: Write EIP, drive discussion, build consensus.
• EIP Editors: Assign numbers, merge when ready, enforce format/grammar; they do not judge technical merit.
• Core EIPs: Need client implementations for Final; typically presented on AllCoreDevs calls. Rough consensus required.
• Discussion: Vet ideas on Ethereum Magicians or Ethereum Research before writing; use discussions-to in preamble.

Validation

• PRs must pass CI (eip-review-bot, eipw, markdownlint, spelling, link checks).
• Run locally: cargo install eipw then eipw --config ./config/eipw.toml <file-or-dir>.

<!-- Source references:

• sources/eips/EIPS/eip-1.md (EIP Work Flow, EIP Process)
• sources/eips/README.md (Validation and Automerging)

-->

EIP Types and Categories

EIP types

• Standards Track — Affects implementations or interoperability (protocol, network, interface, or application standards). Has subcategory: Core, Networking, Interface, or ERC.
• Meta — Process, tooling, or governance; not protocol code. May require community consensus; users generally cannot ignore them.
• Informational — Design notes or guidelines; no consensus; implementers may ignore.

Standards Track categories

Core EIPs that touch the EVM should use opcode mnemonics and define them at least once (e.g. REVERT (0xfe)).

Finding EIPs by category

On eips.ethereum.org: Core, Networking, Interface, ERC, Meta, and Informational are listed by category. In the repo, _config.yml and the Jekyll site map these to pages (core.html, erc.html, etc.); the source of truth is the category (and type) in each EIP’s preamble.

<!-- Source references:

• sources/eips/EIPS/eip-1.md (EIP Types, Special requirements for Core EIPs)
• sources/eips/_config.yml

-->

Commonly Referenced EIPs

When implementing clients, wallets, or dapps, these EIPs are frequently cited. Resolve the spec at sources/eips/EIPS/eip-N.md or https://eips.ethereum.org/EIPS/eip-N.

Note: Many application-level standards (e.g. checksum addresses, signed message format) were numbered as EIPs but are now maintained as ERCs in ethereum/ercs. For ERC-20, ERC-721, etc., check this repo for historical text or ethereum/ercs for the current source.

<!-- Source references:

• sources/eips/EIPS/eip-1.md
• sources/eips/EIPS/eip-155.md
• sources/eips/EIPS/eip-712.md
• sources/eips/EIPS/eip-1193.md

-->

ERC / EIP Repository Separation

As of a recent change, ERC (application-layer) standards are maintained in a separate repository.

Where things live

Implications for agents and authors

• New ERCs or updates to existing ERCs — Submit to ethereum/ercs. Do not open ERC PRs against ethereum/EIPs.
• This repo (EIPs) — Still contains historical ERC documents and the EIP process (EIP-1, template, categories, validation). The status site (eips.ethereum.org) still lists ERCs; the source of truth for editing ERCs is ethereum/ercs.
• Referencing — When referencing an ERC in an EIP or in code, continue to use the form ERC-N and canonical URL https://eips.ethereum.org/EIPS/eip-N (or the ercs repo canonical URL if that becomes the official one for ERCs). Check the relevant repo for the latest ERC text.

When helping users "add an ERC" or "propose a new token standard," direct them to ethereum/ercs. When helping with EIP process, format, or non-ERC EIPs, use this repo (ethereum/EIPs).

<!-- Source references:

• sources/eips/README.md (attention notice)

-->