# Hegotá is for Hardness > Geth’s EIP tier list for H*. As outlined in our [headliner memo](https://notes.ethereum.org/@lightclient/h-is-for-hardness), we believe H* should be an opportunity to de-emphasize scaling work and focus more deliberately on security and protocol hardening. This perspective guided our tiering process and is reflected in the final rankings.  [View the rankings on Forkcast](https://forkcast.org/rank/#r=S:7906,8077,8151,8298;A:3298,8116,8131,8250,8253,8272,8279,8304,8334,8355,8368,8371,8374;B:5920,7668,7709,7979,8094,8163,8188,8237;C:2488,7923,8182,8200,8219,8358,8372;D:7645,7666,7807,7819,7862,8115,8142,8243,8379). ## Methodology Our ranking methodology has evolved somewhat since [Glamsterdam](https://notes.ethereum.org/@fjl/geth-glamsterdam-eip-ranking). - **S tier — showcase:** EIPs we want to highlight above the rest. These proposals may represent views that are not yet widely shared, making them especially important to the broader prioritization discussion. We consider them critical to improving Ethereum’s security and resilience. - **A tier — core fork work:** EIPs that we believe are valuable, sufficiently mature, and ready to ship, but that do not quite meet the threshold for **S** tier. - **B tier — supportive, but not advocating:** EIPs we generally support but are not actively pushing for. We could see them moving into **A** tier if they receive strong support from other client teams. - **C tier — worthwhile, but probably not now:** EIPs we support in principle but consider either underdeveloped or insufficiently valuable to prioritize for this fork. - **DFI tier — do not include:** EIPs we believe should not be included, either because the proposed change is not sufficiently compelling or because this is the wrong fork in which to pursue it. ## Comments on Individual EIPs ### EIP-5920: PAY Opcode This is more compelling now that EIP-7708 provides logs for ETH transfers. ### EIP-7686: Linear EVM Memory Limits A good idea, but it requires a meaningful amount of work and is not a high priority for this fork. ### EIP-7819: SETDELEGATE Instruction We prefer the SETCODEFROM approach. ### EIP-7851: Code-Controlled EOA Delegation We prefer the SETCODEFROM approach. ### EIP-7862: Delayed State Root We want to evaluate this after seeing how Glamsterdam affects the surrounding design space. ### EIP-7906: Transaction Assertions via State Diff Opcode We consider this one of the most critical security improvement to Ethereum. During the [Trillion Dollar Security](https://ethereum.org/reports/trillion-dollar-security/) project, transaction asserts were identified as one of the highest leverage improvements we can make to Ethereum. It also has good synergy with the headliner: Frame tranaction. ### EIP-7979: Call and Return Opcodes for the EVM This is a promising idea, but not a high priority for the fork. Greater engagement from the Solidity team would also be helpful. ### EIP-8142 We want faster blocks, but it deserves a separate EIP which will pursue for Hegotá instead. ### EIP-8182: Private ETH and ERC-20 Transfers We are generally supportive, but the cryptography still feels premature. ### EIP-8200: EVMification We are not opposed in principle, but this appears to be a substantial project with limited near-term benefit. ### EIP-8219: Checked Arithmetic Opcodes This is a reasonable improvement, but we are unsure whether this is the right fork in which to prioritize general EVM enhancements. ### EIP-8250: Keyed Nonces for Frame Transactions We are generally supportive, but not sure whether a nonce system contract is the best storage model. Ideally, the nonce would live alongside the account itself. However the keyed nature of it would require a new trie which brings with it a lot of complexity. ### EIP-8272: Recent Roots for Frame Transactions Considering this EIP does not need to change the protocol rules for frame tx and only needs a canonicalization in the mempool, it is an easy win for us. It is also an important addition for achieving good privacy on L1. ### EIP-8279: Block Access List Byte Floor Bounding the worst case can reasonably be considered part of protocol hardening, but we want to caution ourselves and avoid signing up for significant repricing work in H*. ### EIP-8298: SETCODEFROM Code Reuse Instruction This is an important component of Ethereum’s post-quantum strategy, because it allows EOAs to fully deactivate their k1 key. It additionally addresses some long desired in-protocol proxy functionality for developers. ### EIP-8304: Trustless Log and Transaction Index We believe this is a critical EIP for trustless interactions on Ethereum and a major improvement to what the log bloom wanted to be. ### EIP-8355: ML-DSA Verification Precompiles We would like this fork to include meaningful progress on post-quantum cryptography. ML-DSA appears to be a strong candidate, though we remain open to alternatives. ### EIP-8358: Net Gas Metering for Account Changes The proposal is reasonable, but it would require substantial work for relatively limited benefit. ### EIP-8368: CPSB Recalibration for New Gas Limit If a new CPSB measurement is required, it should be updated as part of this fork. ### EIP-8372: Normalized State Gas Limit We do not yet understand the proposal well enough to take a strong position. ### EIP-8374: Persist Warm Access Sets Across Reverts Our review of EIP-2929 suggests that reverting warm access sets was largely a consequence of reverting other state, rather than a decision grounded in a deeper protocol requirement.