If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/ethereum/EIPs shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 1d ago
• 44+ active contributors
• Distributed ownership (top contributor 14% of recent commits)
• CC0-1.0 licensed
• CI configured
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live ethereum/EIPs repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/ethereum/EIPs.

What it runs against: a local clone of ethereum/EIPs — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in ethereum/EIPs | Confirms the artifact applies here, not a fork | | 2 | License is still CC0-1.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of ethereum/EIPs. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/ethereum/EIPs.git
#   cd EIPs
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of ethereum/EIPs and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "ethereum/EIPs(\\.git)?\\b" \\
  && ok "origin remote is ethereum/EIPs" \\
  || miss "origin remote is not ethereum/EIPs (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(CC0-1\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"CC0-1\\.0\"" package.json 2>/dev/null) \\
  && ok "license is CC0-1.0" \\
  || miss "license drift — was CC0-1.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "EIPS/eip-1.md" \\
  && ok "EIPS/eip-1.md" \\
  || miss "missing critical file: EIPS/eip-1.md"
test -f ".github/CONTRIBUTING.md" \\
  && ok ".github/CONTRIBUTING.md" \\
  || miss "missing critical file: .github/CONTRIBUTING.md"
test -f ".github/CODEOWNERS" \\
  && ok ".github/CODEOWNERS" \\
  || miss "missing critical file: .github/CODEOWNERS"
test -f ".github/workflows/ci.yml" \\
  && ok ".github/workflows/ci.yml" \\
  || miss "missing critical file: .github/workflows/ci.yml"
test -f ".github/ISSUE_TEMPLATE.md" \\
  && ok ".github/ISSUE_TEMPLATE.md" \\
  || miss "missing critical file: .github/ISSUE_TEMPLATE.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/ethereum/EIPs"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

The Ethereum Improvement Proposals (EIPs) repository is the canonical source for standardization documents governing the Ethereum protocol, consensus rules, networking standards, and application-layer conventions. It hosts markdown-based proposals organized by category (Core, Networking, Interface, Meta, Informational) that describe proposed changes to Ethereum, tracked through a formal review process from Draft → Review → Last Call → Final status. Hierarchical document repository: EIPS/ directory contains numbered .md files (eip-1.md through eip-1155.md+) with YAML frontmatter headers defining status, type, and metadata. Jekyll-based static site generation (jekyll.yml workflow) renders these to https://eips.ethereum.org/. GitHub Actions workflows (.github/workflows/) automate validation, stale issue handling, and labeling. Auto-review bot and merge-repos action handle proposal triage and potential future multi-repo synchronization.

Ethereum protocol developers, client implementers, smart contract developers, and EIP editors who need to propose, review, and implement changes to Ethereum's consensus layer, networking stack, or application standards. Contributors range from core protocol researchers to application developers standardizing token contracts and wallet interfaces.

Highly mature and actively maintained. The repository is the official standard-setting body for Ethereum with established governance (EIP-1 process), active CI/CD via GitHub Actions (jekyll.yml, auto-review-bot.yml, stale.yml), and recent infrastructure changes (ERC/EIP separation via PR #7206). This is a production-critical repository serving as the authoritative reference for Ethereum standardization.

Minimal technical risk but high governance responsibility. The codebase itself is low-risk (primarily markdown with Jekyll templating), but delays in proposal review or editorial decisions have blockchain-wide implications. Single points of failure exist in the editor team (see CODEOWNERS); the recent major refactor separating ERCs (EIP #7206) shows the repository is actively evolving its scope and structure.

Recent major activity: separation of ERCs into ethereum/ercs repository (PR #7206 referenced in README), implementation of automated review workflows (auto-review-bot.yml, auto-review-trigger.yml), and stale proposal management (stale.yml, auto-stagnate-bot.yml). The repository is refactoring its scope from mixed EIP/ERC content to EIP-only, reflecting Ethereum's maturing standards body.

Clone and serve locally: git clone https://github.com/ethereum/EIPs.git && cd EIPs && bundle install && bundle exec jekyll serve. The repository uses Jekyll for static site generation; no package managers like npm are required. See .github/workflows/jekyll.yml for the canonical build process.

Daily commands: Development: bundle exec jekyll serve (requires Ruby bundle). Production rendering happens automatically via .github/workflows/jekyll.yml on push to main. View locally at http://localhost:4000. No npm/yarn/pip required.

• EIPS/eip-1.md — The foundational EIP governing the EIP process itself—all contributors must understand this meta-proposal before submitting or reviewing any EIP.
• .github/CONTRIBUTING.md — Defines contribution workflow, submission requirements, and review standards that every contributor must follow.
• .github/CODEOWNERS — Specifies which maintainers have authority over which EIP categories and files—essential for understanding review chain.
• .github/workflows/ci.yml — The CI/CD pipeline that validates EIP format, metadata, and correctness on every PR—defines what passes or fails.
• .github/ISSUE_TEMPLATE.md — Documents the standard issue reporting format and discussion protocols for the repository.
• CONTRIBUTING.md — Top-level contributing guide that onboards new contributors to the EIP ecosystem and process.
• .github/workflows/jekyll.yml — Deploys the static EIP documentation site—critical for understanding the public-facing artifact.

• EIP Markdown Files (EIPS/eip-*.md) (Markdown, YAML, Git) — Source of truth for each proposal; contains YAML metadata and specification text. Versioned in git.
  • Failure mode: Corrupted or malformed YAML halts CI; stale or conflicting content causes reviewer confusion and delayed consensus.
• CI Validation Pipeline (ci.yml) (GitHub Actions, YAML schema validators, shell scripts) — Gates PRs; ensures EIP numbering, metadata, and format comply with EIP-1 standards before merge.
  • Failure mode: If validation is too strict, valid EIPs are rejected; if too loose, malformed specs merge and break the site.
• CODEOWNERS & Review Routing (GitHub CODEOWNERS mechanism, auto-review-bot) — Directs PRs to subject-matter experts (Core, Networking, Interface reviewers); ensures quality and consistency per category.
  • Failure mode: Inactive or missing reviewers cause PRs to stall indefinitely; wrong CODEOWNERS mapping routes to incorrect reviewers.
• Jekyll Static Site Generator (Jekyll, Liquid templates, GitHub Pages) — Transforms EIP markdown and metadata into browsable, searchable status page; deployed to eips.ethereum.org.
  • Failure mode: Build errors prevent deployment; broken Liquid templates or CSS regressions degrade

Propose a New EIP

1. Read EIPS/eip-1.md to understand the template, status types (Draft, Review, Last Call, Final), and governance rules. (EIPS/eip-1.md)
2. Create a new markdown file in the EIPS/ directory following the naming convention eip-{number}.md with YAML frontmatter (title, author, status, type, created). (EIPS/)
3. Follow the content structure defined in EIP-1: Summary, Abstract, Motivation, Specification, Rationale, Backwards Compatibility, etc. (EIPS/eip-1.md)
4. Submit a pull request and reference .github/CONTRIBUTING.md to understand the review process and assign reviewers via CODEOWNERS. (.github/CONTRIBUTING.md)
5. Address feedback from maintainers listed in .github/CODEOWNERS; updates trigger the CI validation in .github/workflows/ci.yml. (.github/CODEOWNERS)

Update or Fix EIP Metadata

1. Identify the target EIP file in EIPS/ and edit its YAML frontmatter (status, discussion-to, updated date). (EIPS/)
2. Run or verify that .github/workflows/ci.yml validates the YAML structure and required fields (EIP number, title, author, status, type). (.github/workflows/ci.yml)
3. Commit and push; the CI pipeline will confirm metadata correctness before merge. (.github/workflows/ci.yml)

Manage Stale or Dormant EIPs

1. Review .github/workflows/stale.yml which automatically flags inactive PRs and issues after a configurable period. (.github/workflows/stale.yml)
2. The stale bot will apply labels or close EIPs per the workflow configuration; maintainers can reopen or update status as needed. (.github/workflows/stale.yml)

• Markdown + YAML Frontmatter — Human-readable, version-control-friendly format for specifications; YAML frontmatter enables automated parsing of metadata (status, author, type) without custom tooling.
• GitHub Actions — Native CI/CD with no external service dependency; automatic CODEOWNERS routing and stale-issue management reduce manual overhead.
• Jekyll Static Site Generation — Converts EIP markdown into a searchable, browsable status page (eips.ethereum.org) without database or backend services; GitHub Pages native support.
• Git + GitHub Pull Requests — Decentralized review and versioning; PR-based discussion and consensus aligns with Ethereum's open governance model.

• EIPs separated from ERCs into two repositories (ethereum/EIPs and ethereum/ercs)

  • Why: Reduce merge conflicts and simplify governance of distinct proposal types; ERCs are token/application standards while EIPs cover core protocol.
  • Consequence: Contributors must know which repo to target (EIP repo for core/networking/interface; ERC repo for token standards). Requires documentation and potential initial misdirection.

• Stateless, file-based storage (no database)

  • Why: Eliminates infrastructure complexity; git history serves as audit trail; accessible without external services.
  • Consequence: Bulk querying or filtered searches require parsing all markdown files; no real-time status notifications (relies on GitHub webhooks and email).

• Manual reviewer assignment via CODEOWNERS + auto-bot enforcement

  • Why: Transparent, predictable routing; CODEOWNERS is code-reviewed and historical.
  • Consequence: Requires careful maintenance of CODEOWNERS file; bottleneck if few reviewers per category or if reviewers are inactive.

• Not a real-time proposal tracking system; EIPs are asynchronous, discussion-driven.
• Does not enforce consensus or voting mechanisms—status changes are human-driven via PR reviews.
• Not a reference implementation repository; EIPs are specifications, not code.

No complex environment setup, but several non-obvious governance traps: (1) All new proposals must be pre-discussed on Ethereum Magicians (ethereum-magicians.org) or Ethresear.ch before submission—pull requests for undiscussed EIPs will be rejected; (2) The recent ERC/EIP split (PR #7206) means token/contract standard proposals should now go to ethereum/ercs, not here; (3) Jekyll requires Ruby with bundler; older systems may fail silently if bundle install isn't run; (4) The auto-review-bot expects specific YAML headers (eip, title, author, status, type, created) or it will request changes automatically.

• EIP Status Lifecycle — Understanding the progression (Idea → Draft → Review → Last Call → Final/Withdrawn) is critical for evaluating proposal maturity and implementation readiness; most confusion around EIP adoption stems from misunderstanding status definitions in EIP-1.
• EIP Categories (Core, Networking, Interface, Meta, Informational) — EIP type determines governance requirements and consensus burden; Core EIPs require client consensus, Networking EIPs affect all nodes, while Informational EIPs are advisory—misclassification delays acceptance.
• EIP Preamble/YAML Frontmatter — Machine-readable metadata (eip number, status, author, discussions-to URL) enables auto-review-bot validation and Jekyll site rendering; malformed headers are the leading cause of auto-bot rejection.
• Ethereum Magicians Discussion Requirement — Pre-proposal consensus-building on ethereum-magicians.org is a hard prerequisite before formal EIP submission; skipping this step results in automatic rejection and wastes author time.
• ERC → EIP Separation (Post-2024) — The recent split (PR #7206) redirects application-layer standards to ethereum/ercs repository; proposing token contracts or wallet standards in this repo will be rejected as out-of-scope.
• Jekyll Static Site Generation — EIPs are compiled to HTML via Jekyll and served at eips.ethereum.org; understanding Jekyll's Markdown + YAML processing explains why certain formatting rules (code blocks, tables, links) are strict in EIP templates.
• GitHub Actions Workflow Automation — auto-review-bot, auto-stagnate-bot, and stale.yml enforce governance without manual review; understanding these workflows explains automated comments on PRs and why certain changes trigger CI checks.

• ethereum/ercs — Split-off repository for application-layer standards (ERCs like ERC-20, ERC-721) as of 2024; new token and contract standards must be proposed there, not in EIPs.
• ethereum/execution-specs — Formal specification of Ethereum protocol rules and client behavior, implements many Core EIPs (1-6000 range) in executable Python code.
• ethereum/consensus-specs — Consensus layer (Proof of Stake) specification, formally documents Beacon Chain EIPs and network protocols; complements this repository's Core EIP definitions.
• ethereum/go-ethereum — Reference implementation of Ethereum execution layer; Go code here implements accepted Core and Networking EIPs; developers validate EIP feasibility against geth.
• ethereum-magicians/ethereum-magicians.github.io — Discussion forum platform (ethereum-magicians.org) where EIP ideas must be vetted before formal proposals; essential prerequisite for EIP submissions.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add EIP metadata validation workflow in CI pipeline

The repo contains hundreds of EIP markdown files in EIPS/ directory but lacks automated validation of required frontmatter (status, type, category, etc.) as defined in EIP-1. Currently, malformed EIP headers can be merged. Adding a GitHub Action to validate YAML frontmatter against EIP-1 requirements would catch errors early and reduce manual review burden.

• [ ] Review EIP-1.md to document required frontmatter fields for different EIP categories
• [ ] Create a new workflow file .github/workflows/eip-validation.yml that runs on pull requests
• [ ] Implement validation logic to check: status values (Draft/Review/Last Call/Final/Stagnant), required fields (title, author, created), valid EIP number format
• [ ] Ensure workflow blocks merge if validation fails, similar to existing ci.yml pattern
• [ ] Test against a few existing EIPs in EIPS/ directory to verify correctness

Create automated EIP number assignment helper action

New contributors frequently struggle with selecting the next available EIP number when creating proposals. There's no automated tool to detect the highest EIP number in use or suggest the next available number. A custom GitHub Action could assist contributors during PR creation by identifying gaps and suggesting appropriate numbers.

• [ ] Create new action in .github/actions/eip-number-suggester/ with action.yml
• [ ] Write logic to scan EIPS/ directory and parse all eip-*.md filenames to find highest number and gaps
• [ ] Output suggested EIP number(s) as action output variable
• [ ] Add workflow in .github/workflows/ to run on pull request comment (e.g., '/suggest-number')
• [ ] Document the feature in CONTRIBUTING.md with example usage

Add link validation and changelog tracking for EIP status transitions

With hundreds of EIPs referencing each other and external resources, broken links and incorrect cross-references accumulate. Additionally, there's no automated tracking when an EIP transitions between statuses (Draft→Review→Final). A workflow could validate intra-EIP links (e.g., EIP-123 references) and auto-comment on PRs when status fields change, improving auditability.

• [ ] Create .github/workflows/link-validation.yml to check all markdown links in EIPS/ against actual EIP files and external URLs
• [ ] Implement EIP cross-reference validation (e.g., detect 'EIP-1234' patterns and verify those files exist)
• [ ] Add logic to detect status field changes between base and head commits in pull_request events
• [ ] Post automated comment on PRs showing status transitions (e.g., 'EIP-5000: Draft → Last Call')
• [ ] Configure workflow to warn (not block) on broken external links, but error on missing EIP cross-references

• Review and update stale Draft-status EIPs (1-2 years old with no activity) to either Withdrawn or ensure they meet current EIP-1 standards; the stale.yml and auto-stagnate-bot.yml workflows identify candidates monthly.
• Add missing structured examples or test vectors to Core EIPs (e.g., eip-1014.md on CREATE2, eip-1052.md on STATICCALL) following the format in completed proposals like eip-1155.md; many protocol EIPs lack runnable pseudocode.
• Write validation tooling or documentation for the YAML frontmatter spec in EIP-1.md—currently auto-review-bot.yml is not open-source in this repo, so contributors can't easily test their EIP headers locally before submission.

The Ethereum EIPs repository appears to be a documentation-focused project with minimal direct security risks from code execution. Primary concerns are governance and process-related: explicit GitHub Actions permissions should be defined, issue templates should be reviewed to prevent sensitive data collection, and a formal security policy should be established. The repository lacks visible infrastructure-as-code or production dependencies that would typically introduce vulnerability risks. The documentation-centric nature (markdown files in EIPS/ directory) inherently reduces attack surface for injection attacks or code execution vulnerabilities. Overall security posture is reasonably good for a governance/documentation repository, but administrative and policy gaps should be addressed.

• Medium · GitHub Actions Workflow Permissions Not Explicitly Defined — .github/workflows/. Multiple GitHub Actions workflows (.github/workflows/*.yml) are present but the provided files don't show explicit permission declarations. This could allow workflows to operate with excessive default permissions, potentially enabling privilege escalation or unauthorized repository modifications. Fix: Add explicit 'permissions' declarations to all workflow files, following the principle of least privilege. Example: 'permissions: { contents: read, pull-requests: read }'
• Medium · Potential Sensitive Data in Issue Templates — .github/ISSUE_TEMPLATE/. The repository contains issue templates (.github/ISSUE_TEMPLATE/) that may inadvertently collect or expose sensitive information from users reporting issues or proposing changes. No indication of data sanitization is visible. Fix: Review all issue templates to ensure users are not prompted for sensitive data. Add clear warnings against including private keys, credentials, or personal information in issue descriptions.
• Low · Missing Security Policy — Repository root. No SECURITY.md or security policy file is evident in the repository structure. This makes it difficult for security researchers to report vulnerabilities responsibly. Fix: Create a SECURITY.md file following GitHub's recommended format to provide clear instructions for reporting security vulnerabilities responsibly.
• Low · No CODEOWNERS Verification — .github/CODEOWNERS. While a .github/CODEOWNERS file exists, the content is not visible. Without proper code owner assignments, critical changes may not receive appropriate security review. Fix: Ensure CODEOWNERS file contains appropriate security maintainers for sensitive paths, particularly .github/workflows/ and configuration files.
• Low · Renovate Configuration Present Without Visibility — .github/renovate.json. A .github/renovate.json file is present for dependency automation, but its contents are not visible. Misconfigured automation could introduce vulnerable dependencies. Fix: Review renovate configuration to ensure: 1) Security updates are prioritized, 2) Major version updates are properly tested, 3) Credentials are not stored in the config file.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.