[pull] master from ethereum:master

.gitattributes

@@ -1,3 +1,7 @@
 # GitHub highlighting for Solidity files
 # See https://github.com/github/linguist/pull/3973#issuecomment-357507741
 *.sol linguist-language=Solidity
+
+# Force Linux line endings on all files
+# Necessary for running eipw locally
+* text=auto eol=lf

.github/CODEOWNERS

@@ -0,0 +1 @@
+* @eth-bot

.github/CONTRIBUTING.md

@@ -0,0 +1,3 @@
+Please review [EIP-1](https://eips.ethereum.org/EIPS/eip-1) for EIP guidelines.
+
+<!-- RATIONALE FOR THIS FILE: IT IS DISPLAYED WHEN YOU CREATE AN ISSUE OR MAKE A PR -->

ISSUE_TEMPLATE.md → .github/ISSUE_TEMPLATE.md

@@ -1,12 +1,11 @@
-
 ATTENTION! If you would like to submit an EIP and it has already been written as a draft (see the [template](https://github.com/ethereum/EIPs/blob/master/eip-template.md) for an example), please submit it as a [Pull Request](https://github.com/ethereum/EIPs/pulls).
 
 If you are considering a proposal but would like to get some feedback on the idea before submitting a draft, then continue opening an Issue as a thread for discussion.  Note that the more clearly and completely you state your idea the higher the quality of the feedback you are likely to receive.
 
-Keep in mind the following guidelines from [EIP-1](./eip-1.md):
+Keep in mind the following guidelines from [EIP-1](https://eips.ethereum.org/EIPS/eip-1):
 
-> Each EIP must have a champion - someone who writes the EIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The EIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is EIP-able. Posting to the the Protocol Discussion forum or opening an Issue is the best way to go about this.
+> Each EIP must have a champion - someone who writes the EIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The EIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is EIP-able. Posting to the Protocol Discussion forum or opening an Issue is the best way to go about this.
 
-> Vetting an idea publicly before going as far as writing a EIP is meant to save the potential author time. Asking the Ethereum community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Ethereum is used.
+> Vetting an idea publicly before going as far as writing an EIP is meant to save the potential author time. Asking the Ethereum community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Ethereum is used.
 
-> Once the champion has asked the Ethereum community as to whether an idea has any chance of acceptance, a draft EIP should be presented as a Pull Request. This gives the author a chance to flesh out the draft EIP to make properly formatted, of high quality, and to address initial concerns about the proposal.
+> Once the champion has asked the Ethereum community as to whether an idea has any chance of acceptance, a draft EIP should be presented as a Pull Request. This gives the author a chance to flesh out the draft EIP to properly format it, ensure it is high quality, and address initial concerns about the proposal.

.github/ISSUE_TEMPLATE/bug-report.yml

@@ -0,0 +1,29 @@
+name: Bug Report
+description: File a bug report
+labels: ['bug']
+
+body:
+  - type: markdown
+    attributes:
+      value: Thanks for taking the time to fill out this bug report!
+  - type: input
+    id: pull-request
+    attributes:
+      label: Pull Request
+      description: Link to the pull request where the issue occurred
+    validations:
+      required: false
+  - type: textarea
+    id: what-happened
+    attributes:
+      label: What happened?
+      description: Also tell us, what did you expect to happen?
+      placeholder: Tell us what you see!
+    validations:
+      required: true
+  - type: textarea
+    id: logs
+    attributes:
+      label: Relevant log output
+      description: Please copy and paste any relevant log output. This will be automatically formatted into code, so no need for backticks.
+      render: shell

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,5 @@
+blank_issues_enabled: true
+contact_links:
+  - name: Do you want to discuss EIP ideas or ask questions about the process?
+    url: https://ethereum-magicians.org/
+    about: Use the Fellowship of Ethereum Magicians for EIP-related discussion!

.github/ISSUE_TEMPLATE/propose-process-change.yml

@@ -0,0 +1,13 @@
+name: Do you want to propose a change to the EIP process itself?
+description: Use this if you want to propose changes to the EIP process
+labels: ['enhancement']
+
+body:
+  - type: textarea
+    id: proposed-change
+    attributes:
+      label: Proposed Change
+      description: What do you think should be different?
+      placeholder: Describe your proposed change here
+    validations:
+      required: true

PULL_REQUEST_TEMPLATE.md → .github/PULL_REQUEST_TEMPLATE.md

@@ -1,3 +1,7 @@
+**ATTENTION: ERC-RELATED PULL REQUESTS NOW OCCUR IN [ETHEREUM/ERCS](https://github.com/ethereum/ercs)**
+
+--
+
 When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md
 
 We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

.github/actions/merge-repos/action.yml

@@ -0,0 +1,24 @@
+name: Merge ERCs
+
+runs:
+  using: 'composite'
+  steps:
+    - name: Checkout ERCs
+      uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+      with:
+        repository: ethereum/ERCs
+        path: ERCs
+    - name: Merge Repos
+      shell: bash
+      run: |
+        mkdir -p $GITHUB_WORKSPACE/ERCs/ERCS
+        mkdir -p $GITHUB_WORKSPACE/ERCs/EIPS
+        cp -rp $GITHUB_WORKSPACE/ERCs/ERCS/. $GITHUB_WORKSPACE/EIPS
+        cp -rp $GITHUB_WORKSPACE/ERCs/EIPS/. $GITHUB_WORKSPACE/EIPS
+        cp -rp $GITHUB_WORKSPACE/ERCs/assets/. $GITHUB_WORKSPACE/assets
+        cd $GITHUB_WORKSPACE/EIPS
+        find . -name "erc-*.md" -type f -exec sh -c 'echo mv "$1" "$(echo "$1" | sed s/erc/eip/)"' _ {} \; | sh
+        cd $GITHUB_WORKSPACE/assets
+        find . -depth -name "erc-*" -type d -exec sh -c 'echo mv "$1" "$(echo "$1" | sed s/erc/eip/)"' _ {} \; | sh
+        cd $GITHUB_WORKSPACE
+        rm -rf ERCs

.github/instructions/review.instructions.md

@@ -0,0 +1,132 @@
+---
+applyTo: "EIPS/**/eip-*.md,ERCS/**/erc-*.md"
+---
+
+# Copilot Instructions for Reviewing EIP/ERC Pull Requests
+
+You are an EIP editor reviewing pull requests to the `ethereum/EIPs` and `ethereum/ERCs` repositories. Your job is to enforce the rules defined in [EIP-1](https://eips.ethereum.org/EIPS/eip-1) and the editorial style guide. You do **not** judge the technical merit of proposals—only their formatting, structure, and compliance with the process.
+
+## Necessity
+
+Not every idea is a good fit for the EIP/ERC repositories. For example, does the proposal:
+
+- Specify a change to the core protocol? Allow.
+- Coordinate many implementations that must all be compatible? Allow.
+- Introduce a library that will only be implemented once? Disallow.
+
+Use your best judgement here, and err on the side of gently discouraging new proposals.
+
+## Repository Structure
+
+- Auxiliary files (images, test data) go in `assets/eip-N/` or `assets/erc-N/`.
+- New proposals use `eip-template.md` or `erc-template.md` as a starting point.
+
+## Preamble / Front Matter
+
+Every proposal must begin with an RFC 822-style (field name, colon, field value, newline) front matter block delimited by `---`. Headers must appear in this order:
+
+| Header | Required | Notes |
+|---|---|---|
+| `eip` | Always | The assigned number. |
+| `title` | Always | A few words, **not** a full sentence. Title case. |
+| `description` | Always | One short sentence. Sentence case. |
+| `author` | Always | Should contain the GitHub user that opened the pull request. |
+| `discussions-to` | Always | URL to the discussion thread. If missing, direct the contributor to [Ethereum Magicians](https://ethereum-magicians.org/). |
+| `status` | Always | Fixed enumeration. |
+| `last-call-deadline` | Last Call only | ISO 8601 date (`yyyy-mm-dd`). Required when status is `Last Call`. |
+| `type` | Always | `Standards Track`, `Meta`, or `Informational`. |
+| `category` | Standards Track only | `Core`, `Networking`, `Interface`, or `ERC`. Remove for non-Standards Track. |
+| `created` | Always |`yyyy-mm-dd`. |
+| `requires` | If dependency exists | Comma-separated EIP/ERC numbers. Only when the proposal cannot be understood without another proposal's concepts. Merely mentioning another proposal does not create a dependency. |
+| `withdrawal-reason` | Withdrawn only | A sentence explaining why. |
+
+Lists are comma-separated.
+
+## Status Transitions
+
+- **Draft** is the initial status for all new proposals.
+- **Draft -> Review**: Author marks the proposal ready for peer review.
+- **Review -> Last Call**: Author sets `last-call-deadline` (typically 14 days out). Normative changes during Last Call revert the proposal to Review.
+- **Last Call -> Final**: The PR moving to Final should contain **no changes other than the status update**. Content/editorial changes must be in a separate, prior PR.
+- **Stagnant**: Automatically applied after 6 months of inactivity in Draft, Review, or Last Call. Can be resurrected back to Draft or its earlier status.
+- **Withdrawn**: Permanent. Cannot be resurrected with the same number.
+- **Living**: Special status for continuously updated proposals (e.g., EIP-1).
+
+## External Links
+
+External links are **strongly discouraged** except for resources permitted in EIP-1. When you encounter a prohibited link, recommend the following actions:
+
+- Remove the link and summarize relevant content in the EIP/ERC
+- License/copyright permitting, copy the content into the `assets/...` directory
+- Apply to have the resource allowed, following the rules in [EIP-5757](https://eips.ethereum.org/EIPS/eip-5757).
+
+## Auxiliary Files
+
+- Images, diagrams, and data files go in `assets/eip-N/` (or `assets/erc-N/`).
+- Use relative links: `../assets/eip-N/image.png`.
+- Prefer SVG, then PNG, then other formats.
+- SVG images should support dark mode via `prefers-color-scheme` CSS media queries where possible. If not, they must be legible in light mode.
+
+## Motivation vs. Rationale
+
+Proposal authors often confuse the "Motivation" and "Rationale" sections.
+
+The "Motivation" section is where the author convinces the reader that this proposal is necessary and, importantly, that this proposal is the correct solution to the problem compared to other (potentially hypothetical) proposals. This section can contain background information on the problem/design space, use cases, who might be interested in the proposal, etc. This section should not contain any design decisions.
+
+On the other hand, the "Rationale" section must be used to explain technical choices made within the proposal itself. This section can contain, for example, why `uint64` was used instead of `uint256` or why a field is stored in a system contract vs. the account trie. The "Rationale" section cannot be used to justify the proposal as a whole.
+
+An analogy that conveys the difference is:
+
+> Motivation: The Ethereum community needs a shed because...
+> Rationale: We chose to use metal doors in the design of our shed because...
+
+## License
+
+Code within the proposal itself (`eip-1234.md`) **must** be CC0-1.0 licensed. Code without a `SPDX-License-Identifier` can be assumed to be CC0-1.0.
+
+Asset files are allowed to have most open source (but not copyleft) licenses.
+
+## Implementation Agnostic
+
+The specification should be implementation-independent. Authors must only mandate the externally visible behavior of an implementation, not the specifics of how implementations achieve that behavior. Implementation _hints_ are permitted, but cannot be mandatory for spec compliance.
+
+## Style Guide
+
+### Text
+
+- **Headings**: Title case. No trailing punctuation (no colon, period, etc.).
+- **Title field**: Title case.
+- **Description field**: Sentence case.
+- **RFC 2119 keywords** (`MUST`, `SHOULD`, `SHALL`, etc. in all caps): Only permitted inside the Specification section. If used, the Specification must begin with the standard RFC 2119/8174 boilerplate.
+- **EIP/ERC identifiers**: Do not use articles before bare identifiers (not "an ERC-20" but "ERC-20"). Articles are fine when the identifier modifies a noun ("an ERC-20 token").
+- **Initialisms**: Write in uppercase (e.g., NFT, not nft).
+- **Backticks**: Only for inline code. Do not use for emphasis or non-code terms. Contributors often try to hide external links using backticks. Watch out for that.
+- **Abbreviations**: Expanded form first, abbreviation in parentheses: "liquidity provider (LP)", not "LP (liquidity provider)".
+- **Hyphens**: "on-chain" and "off-chain" before nouns; "on chain" and "off chain" after nouns.
+- **"Ethereum"**: Never "the Ethereum".
+- **Example domains**: Use example/reserved domains in examples (e.g., `example.com`), not real services.
+- **Fork constants**: Do not include fork block numbers unless writing a fork meta EIP.
+- **Commercial products**: Avoid mentioning specific commercial products.
+- **Paragraph structure**: Avoid single-sentence paragraphs and sections that consist only of a bulleted list with no surrounding prose.
+
+### EVM Instructions
+
+Core EIPs that mention or propose EVM changes must refer to instructions by mnemonic and define the opcode at least once:
+
+```
+REVERT (0xfe)
+```
+
+### Tense
+
+Proposals should be written as if they were already in Final status. Sometimes authors will use future tense, leave visible TODOs, or reference ongoing work. It's really easy to miss this kind of content, and it looks silly in a Final proposal.
+
+## Common Review Issues to Flag
+
+1. The title doesn't uniquely identify the proposal.
+1. The description (in the preamble) essentially restates the title. The description should expand on the title, and be space-/character-efficient.
+1. The title/description contains "minimal" but the proposal itself doesn't actually make that argument.
+1. The proposal depends on the content of another proposal for correct/complete implementation, but the `requires:` field doesn't list it.
+1. Requirements (defined with UPPERCASE keywords) outside of the "Specification" section.
+1. Inline code should always be in backticks, even in headings.
+1. Security Considerations must be proposal-specific. Call out proposals that just have generic stuff like "audit your code" or "use best practices".

.github/renovate.json

@@ -0,0 +1,18 @@
+{
+  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
+  "extends": [
+    "config:base",
+    ":disableDependencyDashboard"
+  ],
+  "prConcurrentLimit": 100,
+  "ignorePaths": [
+    "**/assets/**"
+  ],
+  "ignoreDeps": [
+    "Pandapip1/jekyll-label-action",
+    "ethereum/eipw-action",
+    "ethereum/eip-review-bot",
+    "ethereum/EIP-Bot"
+  ],
+  "enabled": false
+}

.github/workflows/auto-review-bot.yml

@@ -0,0 +1,32 @@
+on:
+  workflow_run:
+    workflows:
+      - Auto Review Bot Trigger
+    types:
+      - completed
+
+name: Auto Review Bot
+jobs:
+  auto-review-bot:
+    runs-on: ubuntu-latest
+    name: Run
+    steps:
+      - name: Fetch PR Number
+        uses: dawidd6/action-download-artifact@246dbf436b23d7c49e21a7ab8204ca9ecd1fe615
+        with:
+          name: pr-number
+          workflow: auto-review-trigger.yml
+          run_id: ${{ github.event.workflow_run.id }}
+
+      - name: Save PR Number
+        id: save-pr-number
+        run: echo "pr=$(cat pr-number.txt)" >> $GITHUB_OUTPUT
+
+      - name: Auto Review Bot
+        id: auto-review-bot
+        uses: ethereum/eip-review-bot@dist
+        continue-on-error: true
+        with:
+          token: ${{ secrets.TOKEN }}
+          config: config/eip-editors.yml
+          pr_number: ${{ steps.save-pr-number.outputs.pr }}

.github/workflows/auto-review-trigger.yml

@@ -0,0 +1,59 @@
+on:
+  pull_request_target:
+  pull_request_review:
+  workflow_dispatch:
+    inputs:
+      pr_number:
+        description: Pull Request Number
+        type: string
+        required: true
+  issue_comment:
+    types:
+      - created
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
+  cancel-in-progress: true
+
+name: Auto Review Bot Trigger
+jobs:
+  trigger:
+    runs-on: ubuntu-latest
+    name: Trigger
+    steps:
+      - name: Write PR Number - PR Target
+        run: echo $PR_NUMBER > pr-number.txt
+        if: github.event_name == 'pull_request_target' && ((!endsWith(github.event.sender.login, '-bot') && !endsWith(github.event.sender.login, '[bot]')) || github.event.sender.login == 'renovate[bot]')
+        env:
+          PR_NUMBER: ${{ github.event.number }}
+
+      - name: Write PR Number - PR Review
+        run: echo $PR_NUMBER > pr-number.txt
+        if: github.event_name == 'pull_request_review' && !endsWith(github.event.sender.login, '-bot') && !endsWith(github.event.sender.login, '[bot]')
+        env:
+          PR_NUMBER: ${{ github.event.pull_request.number }}
+
+      - name: Write PR Number - Workflow Dispatch
+        run: echo $PR_NUMBER > pr-number.txt
+        if: github.event_name == 'workflow_dispatch'
+        env:
+          PR_NUMBER: ${{ inputs.pr_number }}
+
+      - name: Write PR Number - Comment Retrigger
+        run: echo $PR_NUMBER > pr-number.txt
+        if: github.event_name == 'issue_comment' && github.event.issue.pull_request && contains(github.event.comment.body, '@eth-bot rerun')
+        env:
+          PR_NUMBER: ${{ github.event.issue.number }}
+
+      - name: Check File Existence
+        uses: andstor/file-existence-action@20b4d2e596410855db8f9ca21e96fbe18e12930b
+        id: check_pr_number_exists
+        with:
+          files: pr-number.txt
+
+      - name: Save PR Number
+        uses: actions/upload-artifact@65c4c4a1ddee5b72f698fdd19549f0f0fb45cf08
+        if: steps.check_pr_number_exists.outputs.files_exists == 'true'
+        with:
+          name: pr-number
+          path: pr-number.txt