All protocol calls
PreviousNext
EIPIP126

EIP Improvement Process #126

2026-05-27 6 decisions 1773 transcript lines

Transcript

Call summary

Summary

EIPIP #126 closed several long-open calls for input, agreeing to render each EIP's real status in its citation (instead of always 'draft'), to treat Final rather than Living as the default end status for most proposals, and to keep allowing Solidity in proposals provided the version is stated. Editors set guidance on pre-final CAIP dependencies and on using AI as an editorial tool, discussed making office hours a feedback venue rather than a review fast-track, and worked through community dispute-resolution cases. RTO demoed the V2 next-generation EIP tooling (local multi-repo build system, Pagefind search, and a hard-fork index).

Decisions
  • •Citation status (call-for-input 405): merge the PR that shows each EIP's page status in its citation instead of always displaying 'draft', and close the call for input.
  • •Living vs Final (406): adopt Final as the default end status and avoid new Living EIPs except EIP-process/handbook documents; the proposal continues toward Final.
  • •Pre-final CAIP dependencies: linking to an in-review CAIP via a git commit hash (per EIP-1) is acceptable; a non-final CAIP does not block an ERC/EIP, and this is not enforced as a hard bot rule.
  • •Solidity in proposals remains allowed, but code blocks must include the Solidity version (pragma/major version).
  • •AI may be used as an editorial tool, but the editor retains full responsibility and must safeguard neutrality; no policy banning or mandating it.
  • •Authorship disputes: editors will not force-add authors; the original author approves edits and author additions, and no precedent to override this will be set.
Highlights
  • •Citation status: the PR renders each EIP's page status in square brackets in its citation, reflecting the status at render time rather than always showing 'draft'. Yam's separate idea of permalink/commit-hash references for draft EIPs cited by others is handled separately.
  • •Living vs Final: consensus that Final is the sustainable end status and new Living EIPs should be avoided except for EIP-process/handbook documents (e.g. EIP-1). For upgrade-nomenclature EIPs, accept all and let ACD pick the authoritative one.
  • •Pre-final CAIP dependencies (e.g. CAIP-19, in review since 2020): linking via a git commit hash per EIP-1 is acceptable and does not block an ERC/EIP; not enforced as a hard bot rule.
  • •Solidity in proposals stays allowed, but code blocks must state the Solidity version (pragma/major version) so future readers know what is referenced.
  • •AI in editorial work: allowed as a tool, but the editor keeps full responsibility and must protect neutrality; no ban and no mandate.
  • •Dispute resolution: editors will not force-add authors; the EVVM team's flagged Ethereum Magicians post was auto-removed after an author marked it spam, and editors advised submitting a PR and, if rejected, forking and advocating at ACD.
  • •RTO demoed V2 EIP working-group tooling: local multi-repo build system (build-eips), selective-proposal builds, editorial lint, revamped desktop/mobile navigation, Pagefind full-text search, and a hard-fork/network-upgrade index.
Action Items
  • •Matt - Take charge of the associate-EIP-editor call and its pull request
  • •Sam - Merge the citation-status PR; look into the Ethereum Magicians spam-flag/moderation issue; publish the glossary of terms that need not be defined (possibly as an Informational EIP)
  • •Yam - Open a PR requiring the Solidity version in code blocks and add guidance to contributing.md
  • •Editors - Review and comment on call-for-input 408 (external resources: OWASP, CT/PA, CAI)
  • •EVVM team - Submit a PR with the EIP-8250 suggestions; if not accepted, fork the proposal and advocate at All Core Devs
  • •Pooja / Editors - Progress the dispute-resolution guidelines proposal and the EIP-7723 (status vs network-upgrade stage) PR; editors to review async

Key decisions

  • Merge the PR that renders each EIP's page status in its citation (in square brackets) instead of always showing 'draft', and close call-for-input 405.

    Fixes eip.ethereum.org showing 'draft' in the citation for every proposal regardless of its real status.

  • Adopt Final as the default end status for proposals and avoid creating new Living EIPs, except for EIP-process/handbook documents such as EIP-1; the proposal in call-for-input 406 continues toward Final.

    Living EIPs can be edited indefinitely and create authority/permanence problems; Final gives a citable snapshot per fork.

  • A pre-final CAIP dependency (e.g. CAIP-19, in review) may be referenced via a git commit hash per EIP-1 and does not block an ERC/EIP from reaching Final; this will not be enforced as a hard bot rule.

    CAIPs have no body that can be pushed to move a spec to Final, so a hard rule would strand proposals.

  • Solidity remains allowed in proposals, but Solidity code blocks must state the version (pragma/major version) so future readers know which Solidity is referenced.

  • AI may be used as an editorial tool, but the editor retains full responsibility for the result and must protect the neutrality of the process; there is no ban and no mandate.

  • Editors will not force-add authors to an EIP; the original author approves edits and author additions, and no precedent to override this will be set.

    Raised via a community authorship dispute; changing this would open historic re-litigation.

Links

AI Disclaimer: Some content or metadata on EIPsInsight may be AI-inferred or automatically compiled. If you find any discrepancy, please contact us at dev@avarch.org.