Introduction to EIPs, ERCs, RIPs. EIP: Ethereum Improvement Proposal Protocol-level changes, enforced by the Ethereum clients. Activated via hardforks. Full nodes must upgrade, else fork to opt-out. ERC: Ethereum Request for Comments Application layer standards. Conventions for Solidity, calldata, storage, signatures. Opt-in. Adoption -> network effects. RIP: Rollup Improvement Proposal Provincial laws for rollup city-states. Opt-in for L2s. Opt-out for nodes within an L2. May lead to EIPs. The numbers are shared between EIPs, ERCs, RIPs, assigned sequentially by maintainers. To start one, you will first need to open an Ethereum Magicians forum thread, then make a draft which links to the thread. After which, the specific process depends. Examples: EIP-7939: Count Leading Zeros (CLZ) An opcode in the upcoming Fusaka hardfork that can speed up math operations with smaller bytecode. As a basic math operation that costs as much as a 256-bit `ADD`, this is most suitably implemented as an opcode, which is most suitably implemented as an EIP. ERC-7631: Dual Nature Token Pair Interfaces for how a co-joined fungible and and non-fungible token pair can signal their relationship. Opt-in standard. Allows for better discoverability, better UX. RIP-7767: Gas to Ether contract A contract that burns gas and returns a portion of the gas burned to the caller as the native currency. Due to the adventurous nature of this proposal, this could be piloted as a pre-compile / pre-deploy on rollups first. The tentative mainnet analog is EIP-7791 (GAS2ETH opcode). Difficulty to get adoption / inclusion: EIP > RIP > ERC (approximately) To explain why, each of these deserves their own elaboration in separate threads, best left for future content.