diff --git a/EIPS/eip-1.md b/EIPS/eip-1.md index 9391094092c3a6..aa39a3ca848c69 100644 --- a/EIPS/eip-1.md +++ b/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. diff --git a/EIPS/eip-8235.md b/EIPS/eip-8235.md new file mode 100644 index 00000000000000..ec8635a1fe0a27 --- /dev/null +++ b/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. | + + +#### 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. | + + +#### 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 | + + +#### 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. | + + +## Rationale + + + +## Security Considerations + +No security issues found. + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md). diff --git a/eip-template.md b/eip-template.md index 4a1806af828421..eb2ff4912ac3e8 100644 --- a/eip-template.md +++ b/eip-template.md @@ -8,6 +8,7 @@ type: category: # Only required for Standards Track. Otherwise, remove this field. created: requires: # Only required when you reference an EIP in the `Specification` section. Otherwise, remove this field. +tags: # EIP tags, optional for non-core EIPs ---