Skip to content

Replace placeholder MIP-3, MIP-4 and MIP-7 chat sources with reviewed facts #57

Closed

Description

@portdeveloper

content/mips/mip-3.md, mip-4.md and mip-7.md still contain TODO(author) for status/specification and other sections. getKnowledgeBundle() loads these files into the chat context, and the public Markdown routes expose them. The MIP-12 correction in #56 does not fill these remaining source gaps.

The first upstream drift report also flags changes since the initial reviewed baseline. The pinned upstream comparison includes MIP-3's exceptional-halt wording, MIP-4 validation/gas clarification, and MIP-7's missing-selector rule. MIP-8 and MIP-12 status changed upstream too; the site already has separately sourced activation material for those two.

Approved scope:

  • Replace the three placeholder Markdown documents with concise, accurate summaries of their canonical specifications. Include proposal status, exact source revision, review date, and the canonical discussion link.
  • Cover the 8 MB call-frame memory limit and exceptional-halt gas behavior for MIP-3; MIP-4's CALL-only precompile, exact calldata and failure semantics; and MIP-7's selector restrictions, undefined selectors and trailing EXTENSION byte behavior.
  • Separate proposal status from network activation. Cite official activation evidence when available; otherwise say activation is unverified. Do not infer activation from a Final status.
  • Test the actual knowledge bundle and Markdown routes for these facts and absence of placeholders. Preserve the MIP-8 and MIP-12 factual corrections.
  • Review each of the five entries in upstream-sources.json against the linked diff and current content before advancing its hashes. Record the disposition for each MIP in the PR, including any remaining UI mismatch. Do not refresh hashes just to silence the checker; leave an entry flagged and link a follow-up if its content still needs work.

Keep this to source documents, their regression coverage and reviewed-source metadata. #52 owns the server's citation/prompt behavior, and #35 owns the MIP-4 interactive redesign.

Comment to claim and wait for maintainer approval before starting. One active claim per person across the pool.

Activity

  1. natureloved commented on Oct 5, 2026

    @natureloved
    Contributor

    I'd like to claim this issue.

    I understand the approved scope and constraints:

    1. Replace content/mips/mip-3.md, mip-4.md, and mip-7.md placeholders with concise, accurate summaries of canonical specs (including proposal status, exact source revision, review date, and canonical discussion link).
    2. Clearly separate proposal status from network activation (cite official activation evidence where available; state unverified otherwise).
    3. Document canonical behaviors accurately:
      • MIP-3: 8 MB call-frame memory limit and exceptional-halt gas behavior (consuming all remaining gas).
      • MIP-4: CALL-only precompile, exact calldata validation ordering (reject non-CALL, value > 0, calldata > 4 bytes), and all-gas-consuming revert semantics.
      • MIP-7: extension selector restrictions (excluded 0x5B and 0x60-0x7F), undefined selector exceptional halt, and trailing EXTENSION byte behavior.
    4. Review the 5 entries in upstream-sources.json against the pinned upstream diff (d2fe4081...b49e9034) before updating hashes, recording the disposition for each in the PR.
    5. Add regression tests verifying getKnowledgeBundle() and public .md routes for the reviewed facts and absence of placeholders, while preserving the MIP-8 and MIP-12 corrections.
    6. Restrict changes strictly to source docs, regression tests, and metadata (leaving server citation prompts to Give chat status answers dated sources and separate activation evidence #52 and MIP-4 interactive UI to Redesign the MIP-4 bundler comparison as a Bundle Rescue demo #35).

    I have no other active claims across the pool repos.

  2. portdeveloper commented on Oct 5, 2026

    @portdeveloper
    OwnerAuthor

    @natureloved approved, it's yours. Please build on #58's source and status format once it lands, and keep its citation rules intact. Review each upstream change before advancing the recorded hashes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions