Add EIP: EIP tagging

EIPS/eip-1.md

@@ -140,6 +140,8 @@ Each EIP must begin with an [RFC 822](https://www.ietf.org/rfc/rfc822.txt) style
 
 `requires`: *EIP number(s)* (Optional field)
 
+`tags`: *List of EIP tags*  (Optional field, only required for core EIPs to finalize)
+
 `withdrawal-reason`: *A sentence explaining why the EIP was withdrawn.* (Optional field, only needed when status is `Withdrawn`)
 
 Headers that permit lists must separate elements with commas.
@@ -192,6 +194,16 @@ EIPs may have a `requires` header, indicating the EIP numbers that this EIP depe
 
 A `requires` dependency is created when the current EIP cannot be understood or implemented without a concept or technical element from another EIP. Merely mentioning another EIP does not necessarily create such a dependency.
 
+### `tags` header
+
+The `tags` header is for tags that describe the scope of the EIP. If defined, tags MUST be minimal and MUST comprehensively cover all aspects of the EIP.
+
+Tags MUST be defined on all core EIPs for them to finalize but are also RECOMMENDED on all EIPs.
+
+Draft EIPs SHOULD use the `meta:experimental` instead of defining new tags.
+
+The list of acceptable tags and the process governing modifications to the list is described in [EIP-8235](./eip-8235.md).
+
 ## Linking to External Resources
 
 Other than the specific exceptions listed below, links to external resources **SHOULD NOT** be included. External resources may disappear, move, or change unexpectedly.

EIPS/eip-8235.md

@@ -0,0 +1,123 @@
+---
+eip: 8235
+title: EIP tagging
+description: Requirements and governance process for the modification of EIP tags and the list of well-defined tags.
+author: James Kempton (@SirSpudlington), et al.
+discussions-to: https://ethereum-magicians.org/t/meta-eip-8235-eip-tagging/28275
+status: Draft
+type: Meta
+created: 2026-04-18
+requires: 1
+---
+
+## Abstract
+
+This document defines the set of well-known tags that EIPs may use to categorize themselves. The process and governance rules for appending to this list are also defined within this document
+
+## Specification
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119) and [RFC 8174](https://www.rfc-editor.org/rfc/rfc8174).
+
+### Tag structure
+
+EIP tags must follow the structure of `namespace:category[/subcategory]` with the `[/subcategory]` section of a tag
+being optional if an EIP covers the majority of the parent tag.
+
+### Tag requirements
+
+All defined tags MUST adhere to the following conditions:
+
+- Tags MUST be generic. They MUST NOT specify how something is done, they can only specify the outcome of the proposal.
+- Tags MUST belong to exactly one namespace, if a tag could span multiple namespaces it SHOULD be duplicated per namespace.
+- Tags MUST be accompanied by a definition of the tag's scope. Tag definitions MUST NOT introduce ambiguity with existing tags.
+- Tags SHALL be short and human readable.
+- Tags SHALL be mutually exclusive of each other. Tags should not depend on any other tag than its parent tag.
+
+
+### Creation of new tags
+
+Newly proposed tags MUST satisfy at least one of the following conditions:
+
+- The tag is required to allow EIP with the `meta:experimental` tag to finalize
+- The tag describes behaviour that is present within a reasonable implementation of protocol
+
+Should editor consensus be reached that a proposed tag meets the above requirements, the tag name and definition
+MUST be appended to this document's [Defined Tags](#defined-tags) section. 
+
+### Removal of existing tags
+
+If any defined tag fails to satisfy any of the requirements for creation, it MUST
+be removed from this document. It MAY be added again if it once again meets the
+creation requirements.
+
+Final, Withdrawn or Stagnant EIPs MUST NOT be modified if a dependent tag ceases to exist.
+
+All other EIPs MUST remove any references to removed tags before they can finalize.
+
+### Defined tags
+
+The currently defined tags that are permitted in an EIP are defined below.
+
+#### The `el` namespace
+
+| Tag name | Description |
+|-|-|
+| `el:block` | Modifications to the structure, processing or handling of blocks. (Excluding EVM processing) |
+| `el:cryptography` | Introduction or modification of any new cryptographic primitive or algorithms. |
+| `el:data-availability` | Introduction or modification of any system with a primary purpose of providing data availability to external consumers outside of the EVM. |
+| `el:evm` | Introduction or modification of the processing or structure of EVM bytecode. |
+| `el:evm/opcode` | Introduction or modification of specific EVM opcodes. |
+| `el:evm/precompile` | Introduction or modification of precompiled contracts. |
+| `el:receipt` | Modifications to the structure or handling of transaction receipts.  |
+| `el:state` | Changes to how the state is structured or processed. |
+| `el:transaction` | Modification or introduction of a transactions structure or processing **or** introduction of new transaction types. (Excluding EVM processing) |
+| `el:transaction/type` | Introduction of new transaction types. (Excluding EVM processing) |
+| `el:validator` | Changes to how validators are processed on the execution layer. |
+<!-- More TBD -->
+
+#### The `cl` namespace
+
+| Tag name | Description |
+|-|-|
+| `cl:cryptography` | Introduction or modification of any new cryptographic primitive or algorithms. |
+| `cl:data-availability` | Introduction or modification of any system with a primary purpose of providing data availability to external consumers outside of the EVM. |
+| `cl:finalization` | Changes to how blocks are finalized. |
+| `cl:fork-choice` | Changes to how the the next correct block is selected. |
+| `cl:light` | Systems that have a primary purpose of providing for light clients. |
+| `cl:slot` | Modifications to the structure, timing, processing or handling of slots. |
+| `cl:validator` | Changes to validator operation or processing. |
+<!-- More TBD -->
+
+#### The `net` namespace
+
+| Tag name | Description |
+|-|-|
+| `net:transports` | Changes to how messages are passed between clients. |
+| `net:discovery` | Changes to how clients discover and peer with each other. |
+| `net:identification` | How peers may identify themselves to other peers. |
+| `net:protocol` | Introduction or changes of specific protocols. |
+| `net:protocol/execution` | Protocols for execution bound messages. |
+| `net:protocol/sync` | Protocols that have a primary purpose of syncing with other peers. |
+| `net:protocol/consensus` | Protocols for consensus bound messages. |
+| `net:protocol/light-client` | Protocols that have a primary purpose of providing light clients with chain information. |
+| `net:protocol/rpc` | Protocols for communication of chain data between clients |
+<!-- More TBD -->
+
+#### The `meta` namespace
+
+| Tag name | Description |
+|-|-|
+| `meta:experimental` | EIPs that have functionality that does not fit into pre-existing tags. EIPs with this tag cannot finalize, tags should be created to replace this tag before finalization. |
+<!-- More TBD -->
+
+## Rationale
+
+<!-- TBD -->
+
+## Security Considerations
+
+No security issues found.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).

eip-template.md

@@ -8,6 +8,7 @@ type: <Standards Track, Meta, or Informational>
 category: <Core, Networking, Interface, or ERC> # Only required for Standards Track. Otherwise, remove this field.
 created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
 requires: <EIP number(s)> # Only required when you reference an EIP in the `Specification` section. Otherwise, remove this field.
+tags: # EIP tags, optional for non-core EIPs
 ---
 
 <!--