--- 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).