Add EIP-5976: Handbook for EIP Authors

EIPS/eip-5976.md

@@ -0,0 +1,77 @@
+---
+eip: 5976
+title: EIP Author Handbook
+description: Handy reference for EIP authors with specific suggestions of best practice
+author: Zainan Victor Zhou (@xinbenlv)
+discussions-to: https://ethereum-magicians.org/t/informational-eip-author-handbook/11754
+status: Draft
+type: Informational
+created: 2022-11-15
+---
+
+## Abstract
+
+A handy reference for EIP authors with specific suggestions of best practices for different kinds of EIPs.
+
+## Specification
+
+
+### Scoping
+
+1. Standard track EIPs are divided in 4 categories: Core, Network, Interface,
+and application(ERC) layer. A new EIP SHOULD ideally only address one layer of A new EIP SHOULD ideally only address one layer of  When unable to determine, Author is generally RECOMMENDED to break down the new EIP into multiple ones where each only address the scope of one layer.
+
+- Positive example(s): [EIP-1559](./eip-1559), [EIP-2718](./eip-2718.md), [EIP-2929](./eip-2929.md), [EIP-2930](./eip-2930.md) series.
+- Negative example(s): [EIP-712](./eip-712.md) that span across Interface and Application layers.
+
+### Identifying Related and Competing EIPs
+
+1. Authors of the New EIP SHOULD familiarize with related EIPs.
+2. For existing EIPs that the New EIP strictly depends on, Author SHOULD mention them in its Specification section and and `requires` field in the EIP preamble.
+3. For EIPs that could depend on or interact with the new EIP, Author is
+RECOMMENDED to properly describe how these EIPs could interact with new EIP.
+4. For EIPs that the new EIP _competes with_, Authors SHOULD describe in Motivation section how the new EIP addresses new areas of use cases old ones don't, and in
+Rationale section that how the design decisions in the new EIP compare with
+the existing competing EIPs.
+
+### Finalization
+
+1. New EIPs are RECOMMENDED to turn into FINAL when two or more versions of independent and different compliant implementations are built and deployed.
+
+### ERC EIPs
+
+#### Worthiness of ERC EIPs
+
+1. New ERC EIPs is RECOMMENDED to justify its "worthiness" by providing in its Rationale section:
+
+- A _massive pre-standardized adoptions_, e.g [EIP-721 Non-Fungible Token](./eip-721.md).
+- A _strong potential demand as seen elsewhere_, but couldn't yet be achieved on EVM due to lacking API consensus [EIP-137 Ethereum Domain Name Service](./eip-137.md).
+- A _novel use cases backed_ by interested future adopters., e.g. [EIP-4337](./eip-4337.md).
+
+### Core EIPs
+
+#### When requiring a hard-fork
+
+1. A new EIP requiring a hard-fork is RECOMMENDED to explicitly declare a place-holding number as a named parameter and recommend implementing clients to use such name as controlling parameter prior to rollout.
+
+#### When adding a new EVM instruction
+
+For a new EIP that adds EVM Instruction, here is a handy check-list
+
+- Its Category MUST be `Core`
+- It MUST specify a mnemonic
+- It MUST specify a opcode number. It should contains wording this opcode number are deemed subject to change. Do not use a placeholder opcode number so clients of different language can integrate before. Author SHOULD check other instruction-adding non-finalized EIPs to avoid picking a conflicting opcode.
+before finalize.
+- It MUST specify a gas cost. It MUST justify its gas cost choice in is Rationale section.
+
+## Rationale
+
+Help authors better streamline the authoring and reduce review round-trip time.
+
+## Security Considerations
+
+No security issues introduced.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).