diff --git a/complexity_assessments/EIPs/EIP-4758.md b/complexity_assessments/EIPs/EIP-4758.md
new file mode 100644
index 0000000..bbe09bb
--- /dev/null
+++ b/complexity_assessments/EIPs/EIP-4758.md
@@ -0,0 +1,282 @@
+# EIP-4758: Deactivate SELFDESTRUCT
+
+Link: https://eips.ethereum.org/EIPS/eip-4758
+
+## Execution Specs
+
+### Specs
+
+TBD
+
+### Testing
+
+#### Anchors
+
+All anchors are scored on a 0–3 scale. A score of 4 may be used in exceptional circumstances where the complexity or impact exceeds the defined anchors.
+
+##### EVM Gas rule changes
+
+New EVM gas accounting rules
+- 0. No gas accounting changes.
+- 1. Existing gas accounting mechanism is updated.
+- 2. A new gas accounting mechanism is introduced but it does not affect existing mechanisms nor does it affect existing tests.
+- 3. A new gas accounting mechanism is introduced and affects existing mechanisms which in turn affect existing tests.
+
+##### Blob gas accounting changes
+
+New Blob gas accounting rules which potentially affect pre-existing tests
+
+- 0. No blob gas accounting changes.
+- 1. Existing blob gas accounting mechanism is updated.
+- 2. A new blob gas accounting mechanism is introduced but it does not affect existing mechanisms nor does it affect existing tests.
+- 3. A new blob gas accounting mechanism is introduced and affects existing mechanisms which in turn affect existing tests.
+
+##### New EVM gas refund
+
+New gas-refund mechanism
+
+- 0. No new gas-refund mechanisms are introduced.
+- 1. A new simple gas-refund mechanism is introduced that does not affect either existing tests or existing gas-refund mechanisms.
+- 2. A new complex gas-refund mechanism is introduced or a simple mechanism that affects existing tests or existing gas-refund mechanisms.
+- 3. A new complex gas-refund mechanism is introduced that affects existing tests or existing gas-refund mechanisms.
+
+##### Patterns affecting pre-existing tests
+
+Implements a new validation mechanism or rule that translates in reworking pre-existing tests
+
+- 0. No pre-existing tests are affected by this change.
+- 1. Minor subset of existing tests are affected by this change.
+- 2. Considerable subset of existing tests are affected by this change but involves only a contrived category of tests.
+- 3. Major subset of existing tests are affected, including diverse category of tests (benchmarks, static, multiple forks, etc.).
+
+##### Transition-tool interface changes
+
+Modifies or adds new fields to the transition tool interface.
+
+- 0. No modifications to the transition tool interface are required.
+- 1. A single new field needs to be introduced to the transition tool interface.
+- 2. Multiple new fields or a new mechanism has to be introduced to the transition tool interface.
+- 3. Multiple new fields and a new mechanism has to be introduced to the transition tool interface.
+
+*Special consideration must be paid to this section if the EIP introduces a mechanism that requires the state transition tool to be aware whether the block it is processing is the fork-activation block.
+
+##### Cryptography
+
+Introduces new cryptography mechanisms or modifies existing functionality that involves cryptography
+
+- 0. No cryptography mechanisms are introduced.
+- 1. A new cryptography mechanism is introduced but it is a well known mechanism that is known to have vast resources to aid on its testing.
+- 2. Multiple new cryptography mechanisms are introduced that are well-known or a single but novel mechanism is introduced that is either untested or has limited resources.
+- 3. Multiple new cryptography mechanisms are introduced and at least one of them is a novel mechanism.
+
+##### Edge/boundary conditions
+
+Feature contains edge/boundary conditions.
+
+- 0. No discernible edge cases or boundary conditions are introduced.
+- 1. A single edge-case or boundary-condition prone mechanism is introduced.
+- 2. Multiple edge-case or boundary-condition prone mechanisms are introduced, but none of them requires an elevated number of cases to test.
+- 3. Multiple edge-case or boundary-condition prone mechanisms are introduced and at least one of them requires an elevated number of cases to test.
+
+##### Block syncing changes
+
+Modifies block RLP validation mechanisms that require test client syncing.
+
+- 0. No new RLP validation mechanism is introduced.
+- 1. A single simple RLP validation mechanism is introduced.
+- 2. Multiple simple RLP validation mechanisms are introduced or a single complex one.
+- 3. Multiple RLP validation mechanisms are introduced and at least one of them is deemed complex.
+
+##### Engine API changes
+
+Introduces new fields to the Engine API directives
+
+- 0. No new fields or communication mechanisms are introduced to the Engine API.
+- 1. A single new field is introduced in one of the Engine API endpoints.
+- 2. Multiple fields are introduced to one or multiple Engine API end points, or a new Engine API end-point is introduced.
+- 3. Multiple fields are introduced to one or multiple Engine API end points and a new Engine API end-point is introduced.
+
+##### Added system contracts
+
+Introduces new system contract, stateful or not
+
+- 0. No new system contracts are introduced.
+- 1. A new system contract is introduced that is not stateful nor does it trigger a new system action (e.g. requests to the consensus layer).
+- 2. Multiple new system contracts are introduced or a single new system contract that is either stateful or triggers a new system action (e.g. requests to the consensus layer).
+- 3. Multiple new system contracts are introduced and at least one of them is either stateful or triggers a new system action (e.g. requests to the consensus layer).
+
+##### Modified system contracts
+
+Modifies pre-existing system contracts
+
+- 0. No modifications to pre-existing system contracts are introduced, directly or indirectly.
+- 1. Does not directly modify any system contract, but its behavior has minor indirect effects on one or more system contracts.
+- 2. Does not directly modify any system contract, but its behavior has major indirect effects on one or more system contracts.
+- 3. At least one pre-existing system contract code or state is modified, which would involve irregular state transition or a similarly complex transition methodology.
+
+##### Added opcodes
+
+Introduces new opcodes
+
+- 0. No new opcodes are introduced.
+- 1. A new simple opcode is introduced (no data portion, no complex stack mechanics, and a constant gas cost).
+- 2. Multiple new simple opcodes are introduced, or a single new complex opcode is introduced (has data portion, or complex stack mechanics, or a dynamic gas cost).
+- 3. Multiple new opcodes are introduced, and at least one of them is complex (has data portion, or complex stack mechanics, or a dynamic gas cost).
+
+*Cryptography opcodes are not considered complex by default. Refer to the "Cryptography" section for a separate assessment.
+
+##### Modified opcodes
+
+Modifies pre-existing opcodes
+
+- 0. No pre-existing opcode modifications are introduced.
+- 3. At least one pre-existing opcode's behavior is modified (not including gas changes) or a pre-existing opcode is deprecated.
+
+##### Added precompiles
+
+Introduces new precompiles
+
+- 0. No new precompiles are introduced.
+- 1. A new simple precompile is introduced (constant input length, constant gas cost).
+- 2. Multiple new simple precompiles are introduced, or a single new complex precompile is introduced (dynamic input length or dynamic gas cost).
+- 3. Multiple new precompiles are introduced, and at least one of them is complex (dynamic input length or dynamic gas cost).
+
+*Cryptography precompiles are not considered complex by default. Refer to the "Cryptography" for a separate assessment.
+
+##### Modified precompiles
+
+Modifies pre-existing precompiles logic or gas-accounting
+
+- 0. No pre-existing precompiles are modified.
+- 1. At least one pre-existing precompile has its gas schedule modified.
+- 2. Multiple pre-existing precompiles have their gas schedule modified, or a single pre-existing precompile has its behavior modified.
+- 3. The behavior of multiple pre-existing precompiles, or a single complex pre-existing precompile modified.
+
+##### Encoding changes (RLP/SSZ)
+
+Introduces encoding changes at the transaction/block/interfaces level
+
+- 0. No encoding changes are introduced at the transaction, block, or interfaces levels.
+- 3. An encoding change is introduced at transaction, block or interfaces level (e.g. RLP -> SSZ).
+
+##### New transaction types
+
+Introduces a new transaction type
+
+- 0. No new transaction types are introduced.
+- 3. A new transaction type is introduced.
+
+##### New or modified transaction validity mechanisms
+
+Creates new or modifies pre-existing transaction types' validation mechanisms
+
+- 0. No changes are introduced to the validity rules of existing transaction types or to their intrinsic gas cost calculation.
+- 1. Minor adjustments are introduced to validity rules or intrinsic gas cost calculation, but they do not significantly affect existing tests.
+- 2. Changes to validity rules or intrinsic gas cost calculation affect existing tests, but require only limited updates to test cases and no redesign of the testing infrastructure.
+- 3. Changes to validity rules or intrinsic gas cost calculation require extensive rework or redesign of the tests or testing infrastructure.
+
+##### New block / header fields
+
+Introduces new block or block header fields
+
+- 0. No new block or header fields are introduced.
+- 3. A new block or header field is introduced.
+
+##### New fork activation mechanism
+
+Modifies state, internal variables, or similar, at the fork activation block
+
+- 0. No state modifications, internal variables or similar are modified at the fork activation block.
+- 3. Either a state modification or internal variables are modified at the fork activation block.
+
+*Initialization of new internal variable is not considered a modification.
+
+##### Performance risks
+
+Introduces or modifies mechanisms and requires performance validation.
+
+- 0. No new mechanisms are introduced that require performance validation.
+- 1. The introduced mechanisms can be benchmarked in isolation and do not affect existing performance behavior.
+- 2. The introduced mechanisms cannot be fully benchmarked in isolation, but they only have a limited impact on the existing performance benchmarks.
+- 3. The introduced mechanisms cannot be benchmarked in isolation and have a substantial impact on existing performance benchmarks or have complex interactions with existing mechanisms.
+
+##### Security risks
+
+Introduces or modifies mechanisms that could compromise the security of the chain, users, validators, or other stakeholders, if not implemented properly.
+
+- 0. No new mechanisms are introduced that could pose a security risk.
+- 1. The introduced mechanisms are self-contained, can be validated in isolation, and do not alter existing invariants that could pose a security risk for any stakeholders.
+- 2. The introduced mechanisms interact with a limited number of existing components, slightly altering their security assumptions and requiring a targeted security review or fuzzing.
+- 3. The introduced mechanisms interact with multiple existing components, including critical ones, substantially altering their security assumptions and requiring an extensive security review and fuzzing.
+
+##### Cross-EIP interactions
+
+Introduces or modifies mechanisms that affect other EIPs in either the same or past forks.
+
+- 0. Fully self-contained EIP that does not depend on, modify, or conflict with any other EIP.
+- 1. The EIP interacts with one or more other EIPs in a non-critical and limited way but can be tested independently for the most part.
+- 2. The EIP depends on or modifies one or more other EIPs such that coordinated testing and consideration is required, but interactions are limited in scope and not complex.
+- 3. The EIP has strong interdependencies with multiple EIPs, requiring extensive coordinated cross-EIP testing as well as potential re-design of existing test vectors.
+
+### Checklist
+
+| Anchor | Score (0–3) | Rationale |
+|---|---:|---|
+| **EVM Gas rule changes** | 0 |   |
+| **Blob gas accounting changes** | 0 |   |
+| **New EVM gas refund** | 0 |   |
+| **Patterns affecting pre-existing tests** | 1 |  |
+| **Transition-tool interface changes** | 0 |   |
+| **Cryptography-related testing** | 0 |   |
+| **Edge/boundary conditions** | 0 | Edge cases will be removed |
+| **Block syncing changes** | 0 |   |
+| **Engine API changes** | 0 |   |
+| **Engine API encoding changes** | 0 |   |
+| **Added system contracts** | 0 |   |
+| **Modified system contracts** | 0 |   |
+| **Added opcodes** | 0 |  |
+| **Modified opcodes** | 3 | Changes are extremely minor and use existing code paths |
+| **Added precompiles** | 0 |   |
+| **Modified precompiles** | 0 |   |
+| **Encoding changes (RLP/SSZ)** | 0 |   |
+| **New transaction types** | 0 |   |
+| **New or modified transaction validity mechanisms** | 0 |   |
+| **New block / header fields** | 0 |   |
+| **New fork activation mechanism** | 0 |   |
+| **Performance risks** | 0 |   |
+| **Security risks** | 0 |   |
+| **Cross-EIP interactions** | 0 | When extremely wide ranging EIPS (e.g. 8037) interact with SELFDESTRUCT, this EIP generally makes those EIPs simpler |
+
+**Total: 4**
+
+#### Special Considerations
+
+None
+
+#### Notes
+
+This scoring only considers the complexity of implementing this EIP in EL clients. The implications for the app layer may be significant, but are out of scope for this document.
+
+#### Final Assessment
+
+| Category | Description | Value |
+|-----------|--------------|:----:|
+| **Total Score** | Sum of all anchor scores (0–72) | **`4`** |
+| **Complexity Tier** | Computed from total score | 🟢 |
+
+##### Tier Interpretation
+
+| Tier | Range | Meaning |
+|------|--------|----------|
+| 🟢 **Low Complexity** | **<10** | Minor feature or localized change. Existing tests are largely unaffected. Does not require intensive cross-EIP testing. |
+| 🟡 **Medium Complexity** | **>=10<20** | Moderate change affecting multiple components. Requires moderate cross-EIP testing. |
+| 🔴 **High Complexity** | **>=20** | Broad or deep impact on protocol behavior; high regression risk; and/or requiring intensive cross-EIP testing. |
+
+
+## Consensus Specs
+
+### Specs
+
+### Testing
+
+### Notes
diff --git a/complexity_assessments/EIPs/EIP-7709.md b/complexity_assessments/EIPs/EIP-7709.md
new file mode 100644
index 0000000..be1dc52
--- /dev/null
+++ b/complexity_assessments/EIPs/EIP-7709.md
@@ -0,0 +1,282 @@
+# EIP-7709: Read BLOCKHASH from storage and update cost
+
+Link: https://eips.ethereum.org/EIPS/eip-7709
+
+## Execution Specs
+
+### Specs
+
+TBD
+
+### Testing
+
+#### Anchors
+
+All anchors are scored on a 0–3 scale. A score of 4 may be used in exceptional circumstances where the complexity or impact exceeds the defined anchors.
+
+##### EVM Gas rule changes
+
+New EVM gas accounting rules
+- 0. No gas accounting changes.
+- 1. Existing gas accounting mechanism is updated.
+- 2. A new gas accounting mechanism is introduced but it does not affect existing mechanisms nor does it affect existing tests.
+- 3. A new gas accounting mechanism is introduced and affects existing mechanisms which in turn affect existing tests.
+
+##### Blob gas accounting changes
+
+New Blob gas accounting rules which potentially affect pre-existing tests
+
+- 0. No blob gas accounting changes.
+- 1. Existing blob gas accounting mechanism is updated.
+- 2. A new blob gas accounting mechanism is introduced but it does not affect existing mechanisms nor does it affect existing tests.
+- 3. A new blob gas accounting mechanism is introduced and affects existing mechanisms which in turn affect existing tests.
+
+##### New EVM gas refund
+
+New gas-refund mechanism
+
+- 0. No new gas-refund mechanisms are introduced.
+- 1. A new simple gas-refund mechanism is introduced that does not affect either existing tests or existing gas-refund mechanisms.
+- 2. A new complex gas-refund mechanism is introduced or a simple mechanism that affects existing tests or existing gas-refund mechanisms.
+- 3. A new complex gas-refund mechanism is introduced that affects existing tests or existing gas-refund mechanisms.
+
+##### Patterns affecting pre-existing tests
+
+Implements a new validation mechanism or rule that translates in reworking pre-existing tests
+
+- 0. No pre-existing tests are affected by this change.
+- 1. Minor subset of existing tests are affected by this change.
+- 2. Considerable subset of existing tests are affected by this change but involves only a contrived category of tests.
+- 3. Major subset of existing tests are affected, including diverse category of tests (benchmarks, static, multiple forks, etc.).
+
+##### Transition-tool interface changes
+
+Modifies or adds new fields to the transition tool interface.
+
+- 0. No modifications to the transition tool interface are required.
+- 1. A single new field needs to be introduced to the transition tool interface.
+- 2. Multiple new fields or a new mechanism has to be introduced to the transition tool interface.
+- 3. Multiple new fields and a new mechanism has to be introduced to the transition tool interface.
+
+*Special consideration must be paid to this section if the EIP introduces a mechanism that requires the state transition tool to be aware whether the block it is processing is the fork-activation block.
+
+##### Cryptography
+
+Introduces new cryptography mechanisms or modifies existing functionality that involves cryptography
+
+- 0. No cryptography mechanisms are introduced.
+- 1. A new cryptography mechanism is introduced but it is a well known mechanism that is known to have vast resources to aid on its testing.
+- 2. Multiple new cryptography mechanisms are introduced that are well-known or a single but novel mechanism is introduced that is either untested or has limited resources.
+- 3. Multiple new cryptography mechanisms are introduced and at least one of them is a novel mechanism.
+
+##### Edge/boundary conditions
+
+Feature contains edge/boundary conditions.
+
+- 0. No discernible edge cases or boundary conditions are introduced.
+- 1. A single edge-case or boundary-condition prone mechanism is introduced.
+- 2. Multiple edge-case or boundary-condition prone mechanisms are introduced, but none of them requires an elevated number of cases to test.
+- 3. Multiple edge-case or boundary-condition prone mechanisms are introduced and at least one of them requires an elevated number of cases to test.
+
+##### Block syncing changes
+
+Modifies block RLP validation mechanisms that require test client syncing.
+
+- 0. No new RLP validation mechanism is introduced.
+- 1. A single simple RLP validation mechanism is introduced.
+- 2. Multiple simple RLP validation mechanisms are introduced or a single complex one.
+- 3. Multiple RLP validation mechanisms are introduced and at least one of them is deemed complex.
+
+##### Engine API changes
+
+Introduces new fields to the Engine API directives
+
+- 0. No new fields or communication mechanisms are introduced to the Engine API.
+- 1. A single new field is introduced in one of the Engine API endpoints.
+- 2. Multiple fields are introduced to one or multiple Engine API end points, or a new Engine API end-point is introduced.
+- 3. Multiple fields are introduced to one or multiple Engine API end points and a new Engine API end-point is introduced.
+
+##### Added system contracts
+
+Introduces new system contract, stateful or not
+
+- 0. No new system contracts are introduced.
+- 1. A new system contract is introduced that is not stateful nor does it trigger a new system action (e.g. requests to the consensus layer).
+- 2. Multiple new system contracts are introduced or a single new system contract that is either stateful or triggers a new system action (e.g. requests to the consensus layer).
+- 3. Multiple new system contracts are introduced and at least one of them is either stateful or triggers a new system action (e.g. requests to the consensus layer).
+
+##### Modified system contracts
+
+Modifies pre-existing system contracts
+
+- 0. No modifications to pre-existing system contracts are introduced, directly or indirectly.
+- 1. Does not directly modify any system contract, but its behavior has minor indirect effects on one or more system contracts.
+- 2. Does not directly modify any system contract, but its behavior has major indirect effects on one or more system contracts.
+- 3. At least one pre-existing system contract code or state is modified, which would involve irregular state transition or a similarly complex transition methodology.
+
+##### Added opcodes
+
+Introduces new opcodes
+
+- 0. No new opcodes are introduced.
+- 1. A new simple opcode is introduced (no data portion, no complex stack mechanics, and a constant gas cost).
+- 2. Multiple new simple opcodes are introduced, or a single new complex opcode is introduced (has data portion, or complex stack mechanics, or a dynamic gas cost).
+- 3. Multiple new opcodes are introduced, and at least one of them is complex (has data portion, or complex stack mechanics, or a dynamic gas cost).
+
+*Cryptography opcodes are not considered complex by default. Refer to the "Cryptography" section for a separate assessment.
+
+##### Modified opcodes
+
+Modifies pre-existing opcodes
+
+- 0. No pre-existing opcode modifications are introduced.
+- 3. At least one pre-existing opcode's behavior is modified (not including gas changes) or a pre-existing opcode is deprecated.
+
+##### Added precompiles
+
+Introduces new precompiles
+
+- 0. No new precompiles are introduced.
+- 1. A new simple precompile is introduced (constant input length, constant gas cost).
+- 2. Multiple new simple precompiles are introduced, or a single new complex precompile is introduced (dynamic input length or dynamic gas cost).
+- 3. Multiple new precompiles are introduced, and at least one of them is complex (dynamic input length or dynamic gas cost).
+
+*Cryptography precompiles are not considered complex by default. Refer to the "Cryptography" for a separate assessment.
+
+##### Modified precompiles
+
+Modifies pre-existing precompiles logic or gas-accounting
+
+- 0. No pre-existing precompiles are modified.
+- 1. At least one pre-existing precompile has its gas schedule modified.
+- 2. Multiple pre-existing precompiles have their gas schedule modified, or a single pre-existing precompile has its behavior modified.
+- 3. The behavior of multiple pre-existing precompiles, or a single complex pre-existing precompile modified.
+
+##### Encoding changes (RLP/SSZ)
+
+Introduces encoding changes at the transaction/block/interfaces level
+
+- 0. No encoding changes are introduced at the transaction, block, or interfaces levels.
+- 3. An encoding change is introduced at transaction, block or interfaces level (e.g. RLP -> SSZ).
+
+##### New transaction types
+
+Introduces a new transaction type
+
+- 0. No new transaction types are introduced.
+- 3. A new transaction type is introduced.
+
+##### New or modified transaction validity mechanisms
+
+Creates new or modifies pre-existing transaction types' validation mechanisms
+
+- 0. No changes are introduced to the validity rules of existing transaction types or to their intrinsic gas cost calculation.
+- 1. Minor adjustments are introduced to validity rules or intrinsic gas cost calculation, but they do not significantly affect existing tests.
+- 2. Changes to validity rules or intrinsic gas cost calculation affect existing tests, but require only limited updates to test cases and no redesign of the testing infrastructure.
+- 3. Changes to validity rules or intrinsic gas cost calculation require extensive rework or redesign of the tests or testing infrastructure.
+
+##### New block / header fields
+
+Introduces new block or block header fields
+
+- 0. No new block or header fields are introduced.
+- 3. A new block or header field is introduced.
+
+##### New fork activation mechanism
+
+Modifies state, internal variables, or similar, at the fork activation block
+
+- 0. No state modifications, internal variables or similar are modified at the fork activation block.
+- 3. Either a state modification or internal variables are modified at the fork activation block.
+
+*Initialization of new internal variable is not considered a modification.
+
+##### Performance risks
+
+Introduces or modifies mechanisms and requires performance validation.
+
+- 0. No new mechanisms are introduced that require performance validation.
+- 1. The introduced mechanisms can be benchmarked in isolation and do not affect existing performance behavior.
+- 2. The introduced mechanisms cannot be fully benchmarked in isolation, but they only have a limited impact on the existing performance benchmarks.
+- 3. The introduced mechanisms cannot be benchmarked in isolation and have a substantial impact on existing performance benchmarks or have complex interactions with existing mechanisms.
+
+##### Security risks
+
+Introduces or modifies mechanisms that could compromise the security of the chain, users, validators, or other stakeholders, if not implemented properly.
+
+- 0. No new mechanisms are introduced that could pose a security risk.
+- 1. The introduced mechanisms are self-contained, can be validated in isolation, and do not alter existing invariants that could pose a security risk for any stakeholders.
+- 2. The introduced mechanisms interact with a limited number of existing components, slightly altering their security assumptions and requiring a targeted security review or fuzzing.
+- 3. The introduced mechanisms interact with multiple existing components, including critical ones, substantially altering their security assumptions and requiring an extensive security review and fuzzing.
+
+##### Cross-EIP interactions
+
+Introduces or modifies mechanisms that affect other EIPs in either the same or past forks.
+
+- 0. Fully self-contained EIP that does not depend on, modify, or conflict with any other EIP.
+- 1. The EIP interacts with one or more other EIPs in a non-critical and limited way but can be tested independently for the most part.
+- 2. The EIP depends on or modifies one or more other EIPs such that coordinated testing and consideration is required, but interactions are limited in scope and not complex.
+- 3. The EIP has strong interdependencies with multiple EIPs, requiring extensive coordinated cross-EIP testing as well as potential re-design of existing test vectors.
+
+### Checklist
+
+| Anchor | Score (0–3) | Rationale |
+|---|---:|---|
+| **EVM Gas rule changes** | 0 |   |
+| **Blob gas accounting changes** | 0 |   |
+| **New EVM gas refund** | 0 |   |
+| **Patterns affecting pre-existing tests** | 1 |   |
+| **Transition-tool interface changes** | 0 |   |
+| **Cryptography-related testing** | 0 |   |
+| **Edge/boundary conditions** | 0 |   |
+| **Block syncing changes** | 0 |   |
+| **Engine API changes** | 0 |   |
+| **Engine API encoding changes** | 0 |   |
+| **Added system contracts** | 0 |   |
+| **Modified system contracts** | 0 |   |
+| **Added opcodes** | 0 |   |
+| **Modified opcodes** | 3 |   |
+| **Added precompiles** | 0 |   |
+| **Modified precompiles** | 0 |   |
+| **Encoding changes (RLP/SSZ)** | 0 |   |
+| **New transaction types** | 0 |   |
+| **New or modified transaction validity mechanisms** | 0 |   |
+| **New block / header fields** | 0 |   |
+| **New fork activation mechanism** | 0 |   |
+| **Performance risks** | 0 |   |
+| **Security risks** | 0 |   |
+| **Cross-EIP interactions** | 0 |   |
+
+**Total: 4**
+
+#### Special Considerations
+
+`BLOCKHASH` will read a storage key from outside the scope of the owning contract. This has never been done before and could result in novel situations (e.g. storage key is accessed, but account isn't).
+
+#### Notes
+
+None
+
+#### Final Assessment
+
+| Category | Description | Value |
+|-----------|--------------|:----:|
+| **Total Score** | Sum of all anchor scores (0–72) | **`4`** |
+| **Complexity Tier** | Computed from total score | 🟢 |
+
+##### Tier Interpretation
+
+| Tier | Range | Meaning |
+|------|--------|----------|
+| 🟢 **Low Complexity** | **<10** | Minor feature or localized change. Existing tests are largely unaffected. Does not require intensive cross-EIP testing. |
+| 🟡 **Medium Complexity** | **>=10<20** | Moderate change affecting multiple components. Requires moderate cross-EIP testing. |
+| 🔴 **High Complexity** | **>=20** | Broad or deep impact on protocol behavior; high regression risk; and/or requiring intensive cross-EIP testing. |
+
+
+## Consensus Specs
+
+### Specs
+
+### Testing
+
+### Notes
diff --git a/complexity_assessments/EIPs/EIP-8188.md b/complexity_assessments/EIPs/EIP-8188.md
new file mode 100644
index 0000000..9a9bff0
--- /dev/null
+++ b/complexity_assessments/EIPs/EIP-8188.md
@@ -0,0 +1,282 @@
+# EIP-8188: State Tiering by Write Age
+
+Link: https://eips.ethereum.org/EIPS/eip-8188
+
+## Execution Specs
+
+### Specs
+
+TBD
+
+### Testing
+
+#### Anchors
+
+All anchors are scored on a 0–3 scale. A score of 4 may be used in exceptional circumstances where the complexity or impact exceeds the defined anchors.
+
+##### EVM Gas rule changes
+
+New EVM gas accounting rules
+- 0. No gas accounting changes.
+- 1. Existing gas accounting mechanism is updated.
+- 2. A new gas accounting mechanism is introduced but it does not affect existing mechanisms nor does it affect existing tests.
+- 3. A new gas accounting mechanism is introduced and affects existing mechanisms which in turn affect existing tests.
+
+##### Blob gas accounting changes
+
+New Blob gas accounting rules which potentially affect pre-existing tests
+
+- 0. No blob gas accounting changes.
+- 1. Existing blob gas accounting mechanism is updated.
+- 2. A new blob gas accounting mechanism is introduced but it does not affect existing mechanisms nor does it affect existing tests.
+- 3. A new blob gas accounting mechanism is introduced and affects existing mechanisms which in turn affect existing tests.
+
+##### New EVM gas refund
+
+New gas-refund mechanism
+
+- 0. No new gas-refund mechanisms are introduced.
+- 1. A new simple gas-refund mechanism is introduced that does not affect either existing tests or existing gas-refund mechanisms.
+- 2. A new complex gas-refund mechanism is introduced or a simple mechanism that affects existing tests or existing gas-refund mechanisms.
+- 3. A new complex gas-refund mechanism is introduced that affects existing tests or existing gas-refund mechanisms.
+
+##### Patterns affecting pre-existing tests
+
+Implements a new validation mechanism or rule that translates in reworking pre-existing tests
+
+- 0. No pre-existing tests are affected by this change.
+- 1. Minor subset of existing tests are affected by this change.
+- 2. Considerable subset of existing tests are affected by this change but involves only a contrived category of tests.
+- 3. Major subset of existing tests are affected, including diverse category of tests (benchmarks, static, multiple forks, etc.).
+
+##### Transition-tool interface changes
+
+Modifies or adds new fields to the transition tool interface.
+
+- 0. No modifications to the transition tool interface are required.
+- 1. A single new field needs to be introduced to the transition tool interface.
+- 2. Multiple new fields or a new mechanism has to be introduced to the transition tool interface.
+- 3. Multiple new fields and a new mechanism has to be introduced to the transition tool interface.
+
+*Special consideration must be paid to this section if the EIP introduces a mechanism that requires the state transition tool to be aware whether the block it is processing is the fork-activation block.
+
+##### Cryptography
+
+Introduces new cryptography mechanisms or modifies existing functionality that involves cryptography
+
+- 0. No cryptography mechanisms are introduced.
+- 1. A new cryptography mechanism is introduced but it is a well known mechanism that is known to have vast resources to aid on its testing.
+- 2. Multiple new cryptography mechanisms are introduced that are well-known or a single but novel mechanism is introduced that is either untested or has limited resources.
+- 3. Multiple new cryptography mechanisms are introduced and at least one of them is a novel mechanism.
+
+##### Edge/boundary conditions
+
+Feature contains edge/boundary conditions.
+
+- 0. No discernible edge cases or boundary conditions are introduced.
+- 1. A single edge-case or boundary-condition prone mechanism is introduced.
+- 2. Multiple edge-case or boundary-condition prone mechanisms are introduced, but none of them requires an elevated number of cases to test.
+- 3. Multiple edge-case or boundary-condition prone mechanisms are introduced and at least one of them requires an elevated number of cases to test.
+
+##### Block syncing changes
+
+Modifies block RLP validation mechanisms that require test client syncing.
+
+- 0. No new RLP validation mechanism is introduced.
+- 1. A single simple RLP validation mechanism is introduced.
+- 2. Multiple simple RLP validation mechanisms are introduced or a single complex one.
+- 3. Multiple RLP validation mechanisms are introduced and at least one of them is deemed complex.
+
+##### Engine API changes
+
+Introduces new fields to the Engine API directives
+
+- 0. No new fields or communication mechanisms are introduced to the Engine API.
+- 1. A single new field is introduced in one of the Engine API endpoints.
+- 2. Multiple fields are introduced to one or multiple Engine API end points, or a new Engine API end-point is introduced.
+- 3. Multiple fields are introduced to one or multiple Engine API end points and a new Engine API end-point is introduced.
+
+##### Added system contracts
+
+Introduces new system contract, stateful or not
+
+- 0. No new system contracts are introduced.
+- 1. A new system contract is introduced that is not stateful nor does it trigger a new system action (e.g. requests to the consensus layer).
+- 2. Multiple new system contracts are introduced or a single new system contract that is either stateful or triggers a new system action (e.g. requests to the consensus layer).
+- 3. Multiple new system contracts are introduced and at least one of them is either stateful or triggers a new system action (e.g. requests to the consensus layer).
+
+##### Modified system contracts
+
+Modifies pre-existing system contracts
+
+- 0. No modifications to pre-existing system contracts are introduced, directly or indirectly.
+- 1. Does not directly modify any system contract, but its behavior has minor indirect effects on one or more system contracts.
+- 2. Does not directly modify any system contract, but its behavior has major indirect effects on one or more system contracts.
+- 3. At least one pre-existing system contract code or state is modified, which would involve irregular state transition or a similarly complex transition methodology.
+
+##### Added opcodes
+
+Introduces new opcodes
+
+- 0. No new opcodes are introduced.
+- 1. A new simple opcode is introduced (no data portion, no complex stack mechanics, and a constant gas cost).
+- 2. Multiple new simple opcodes are introduced, or a single new complex opcode is introduced (has data portion, or complex stack mechanics, or a dynamic gas cost).
+- 3. Multiple new opcodes are introduced, and at least one of them is complex (has data portion, or complex stack mechanics, or a dynamic gas cost).
+
+*Cryptography opcodes are not considered complex by default. Refer to the "Cryptography" section for a separate assessment.
+
+##### Modified opcodes
+
+Modifies pre-existing opcodes
+
+- 0. No pre-existing opcode modifications are introduced.
+- 3. At least one pre-existing opcode's behavior is modified (not including gas changes) or a pre-existing opcode is deprecated.
+
+##### Added precompiles
+
+Introduces new precompiles
+
+- 0. No new precompiles are introduced.
+- 1. A new simple precompile is introduced (constant input length, constant gas cost).
+- 2. Multiple new simple precompiles are introduced, or a single new complex precompile is introduced (dynamic input length or dynamic gas cost).
+- 3. Multiple new precompiles are introduced, and at least one of them is complex (dynamic input length or dynamic gas cost).
+
+*Cryptography precompiles are not considered complex by default. Refer to the "Cryptography" for a separate assessment.
+
+##### Modified precompiles
+
+Modifies pre-existing precompiles logic or gas-accounting
+
+- 0. No pre-existing precompiles are modified.
+- 1. At least one pre-existing precompile has its gas schedule modified.
+- 2. Multiple pre-existing precompiles have their gas schedule modified, or a single pre-existing precompile has its behavior modified.
+- 3. The behavior of multiple pre-existing precompiles, or a single complex pre-existing precompile modified.
+
+##### Encoding changes (RLP/SSZ)
+
+Introduces encoding changes at the transaction/block/interfaces level
+
+- 0. No encoding changes are introduced at the transaction, block, or interfaces levels.
+- 3. An encoding change is introduced at transaction, block or interfaces level (e.g. RLP -> SSZ).
+
+##### New transaction types
+
+Introduces a new transaction type
+
+- 0. No new transaction types are introduced.
+- 3. A new transaction type is introduced.
+
+##### New or modified transaction validity mechanisms
+
+Creates new or modifies pre-existing transaction types' validation mechanisms
+
+- 0. No changes are introduced to the validity rules of existing transaction types or to their intrinsic gas cost calculation.
+- 1. Minor adjustments are introduced to validity rules or intrinsic gas cost calculation, but they do not significantly affect existing tests.
+- 2. Changes to validity rules or intrinsic gas cost calculation affect existing tests, but require only limited updates to test cases and no redesign of the testing infrastructure.
+- 3. Changes to validity rules or intrinsic gas cost calculation require extensive rework or redesign of the tests or testing infrastructure.
+
+##### New block / header fields
+
+Introduces new block or block header fields
+
+- 0. No new block or header fields are introduced.
+- 3. A new block or header field is introduced.
+
+##### New fork activation mechanism
+
+Modifies state, internal variables, or similar, at the fork activation block
+
+- 0. No state modifications, internal variables or similar are modified at the fork activation block.
+- 3. Either a state modification or internal variables are modified at the fork activation block.
+
+*Initialization of new internal variable is not considered a modification.
+
+##### Performance risks
+
+Introduces or modifies mechanisms and requires performance validation.
+
+- 0. No new mechanisms are introduced that require performance validation.
+- 1. The introduced mechanisms can be benchmarked in isolation and do not affect existing performance behavior.
+- 2. The introduced mechanisms cannot be fully benchmarked in isolation, but they only have a limited impact on the existing performance benchmarks.
+- 3. The introduced mechanisms cannot be benchmarked in isolation and have a substantial impact on existing performance benchmarks or have complex interactions with existing mechanisms.
+
+##### Security risks
+
+Introduces or modifies mechanisms that could compromise the security of the chain, users, validators, or other stakeholders, if not implemented properly.
+
+- 0. No new mechanisms are introduced that could pose a security risk.
+- 1. The introduced mechanisms are self-contained, can be validated in isolation, and do not alter existing invariants that could pose a security risk for any stakeholders.
+- 2. The introduced mechanisms interact with a limited number of existing components, slightly altering their security assumptions and requiring a targeted security review or fuzzing.
+- 3. The introduced mechanisms interact with multiple existing components, including critical ones, substantially altering their security assumptions and requiring an extensive security review and fuzzing.
+
+##### Cross-EIP interactions
+
+Introduces or modifies mechanisms that affect other EIPs in either the same or past forks.
+
+- 0. Fully self-contained EIP that does not depend on, modify, or conflict with any other EIP.
+- 1. The EIP interacts with one or more other EIPs in a non-critical and limited way but can be tested independently for the most part.
+- 2. The EIP depends on or modifies one or more other EIPs such that coordinated testing and consideration is required, but interactions are limited in scope and not complex.
+- 3. The EIP has strong interdependencies with multiple EIPs, requiring extensive coordinated cross-EIP testing as well as potential re-design of existing test vectors.
+
+### Checklist
+
+| Anchor | Score (0–3) | Rationale |
+|---|---:|---|
+| **EVM Gas rule changes** | 3 |   |
+| **Blob gas accounting changes** | 0 |   |
+| **New EVM gas refund** | 0 |   |
+| **Patterns affecting pre-existing tests** | 1 |   |
+| **Transition-tool interface changes** | 0 |   |
+| **Cryptography-related testing** | 0 |   |
+| **Edge/boundary conditions** | 0 |   |
+| **Block syncing changes** | 0 |   |
+| **Engine API changes** | 0 |   |
+| **Engine API encoding changes** | 0 |   |
+| **Added system contracts** | 0 |   |
+| **Modified system contracts** | 0 |   |
+| **Added opcodes** | 0 |   |
+| **Modified opcodes** | 0 |   |
+| **Added precompiles** | 0 |   |
+| **Modified precompiles** | 0 |   |
+| **Encoding changes (RLP/SSZ)** | 3 | Account and storage RLP is changed |
+| **New transaction types** | 0 |   |
+| **New or modified transaction validity mechanisms** | 0 |   |
+| **New block / header fields** | 0 |   |
+| **New fork activation mechanism** | 0 |   |
+| **Performance risks** | 3 | If clients optimize disk formats with metadata, extensive benchmarking will be needed (if not, EIP is pointless) |
+| **Security risks** | 0 |  |
+| **Cross-EIP interactions** | 0 |   |
+
+**Total: X**
+
+#### Special Considerations
+
+This is the first ever change to the MPT Schema in the history of Ethereum.
+
+#### Notes
+
+None
+
+#### Final Assessment
+
+| Category | Description | Value |
+|-----------|--------------|:----:|
+| **Total Score** | Sum of all anchor scores (0–72) | **`10`** |
+| **Complexity Tier** | Computed from total score | 🟡 |
+
+##### Tier Interpretation
+
+| Tier | Range | Meaning |
+|------|--------|----------|
+| 🟢 **Low Complexity** | **<10** | Minor feature or localized change. Existing tests are largely unaffected. Does not require intensive cross-EIP testing. |
+| 🟡 **Medium Complexity** | **>=10<20** | Moderate change affecting multiple components. Requires moderate cross-EIP testing. |
+| 🔴 **High Complexity** | **>=20** | Broad or deep impact on protocol behavior; high regression risk; and/or requiring intensive cross-EIP testing. |
+
+
+## Consensus Specs
+
+### Specs
+
+### Testing
+
+### Notes
diff --git a/complexity_assessments/EIPs/EIP-8205.md b/complexity_assessments/EIPs/EIP-8205.md
new file mode 100644
index 0000000..0000ef3
--- /dev/null
+++ b/complexity_assessments/EIPs/EIP-8205.md
@@ -0,0 +1,282 @@
+# EIP-8205: Withdrawal credentials preregistration
+
+Link: https://eips.ethereum.org/EIPS/eip-8205
+
+## Execution Specs
+
+### Specs
+
+TBD
+
+### Testing
+
+#### Anchors
+
+All anchors are scored on a 0–3 scale. A score of 4 may be used in exceptional circumstances where the complexity or impact exceeds the defined anchors.
+
+##### EVM Gas rule changes
+
+New EVM gas accounting rules
+- 0. No gas accounting changes.
+- 1. Existing gas accounting mechanism is updated.
+- 2. A new gas accounting mechanism is introduced but it does not affect existing mechanisms nor does it affect existing tests.
+- 3. A new gas accounting mechanism is introduced and affects existing mechanisms which in turn affect existing tests.
+
+##### Blob gas accounting changes
+
+New Blob gas accounting rules which potentially affect pre-existing tests
+
+- 0. No blob gas accounting changes.
+- 1. Existing blob gas accounting mechanism is updated.
+- 2. A new blob gas accounting mechanism is introduced but it does not affect existing mechanisms nor does it affect existing tests.
+- 3. A new blob gas accounting mechanism is introduced and affects existing mechanisms which in turn affect existing tests.
+
+##### New EVM gas refund
+
+New gas-refund mechanism
+
+- 0. No new gas-refund mechanisms are introduced.
+- 1. A new simple gas-refund mechanism is introduced that does not affect either existing tests or existing gas-refund mechanisms.
+- 2. A new complex gas-refund mechanism is introduced or a simple mechanism that affects existing tests or existing gas-refund mechanisms.
+- 3. A new complex gas-refund mechanism is introduced that affects existing tests or existing gas-refund mechanisms.
+
+##### Patterns affecting pre-existing tests
+
+Implements a new validation mechanism or rule that translates in reworking pre-existing tests
+
+- 0. No pre-existing tests are affected by this change.
+- 1. Minor subset of existing tests are affected by this change.
+- 2. Considerable subset of existing tests are affected by this change but involves only a contrived category of tests.
+- 3. Major subset of existing tests are affected, including diverse category of tests (benchmarks, static, multiple forks, etc.).
+
+##### Transition-tool interface changes
+
+Modifies or adds new fields to the transition tool interface.
+
+- 0. No modifications to the transition tool interface are required.
+- 1. A single new field needs to be introduced to the transition tool interface.
+- 2. Multiple new fields or a new mechanism has to be introduced to the transition tool interface.
+- 3. Multiple new fields and a new mechanism has to be introduced to the transition tool interface.
+
+*Special consideration must be paid to this section if the EIP introduces a mechanism that requires the state transition tool to be aware whether the block it is processing is the fork-activation block.
+
+##### Cryptography
+
+Introduces new cryptography mechanisms or modifies existing functionality that involves cryptography
+
+- 0. No cryptography mechanisms are introduced.
+- 1. A new cryptography mechanism is introduced but it is a well known mechanism that is known to have vast resources to aid on its testing.
+- 2. Multiple new cryptography mechanisms are introduced that are well-known or a single but novel mechanism is introduced that is either untested or has limited resources.
+- 3. Multiple new cryptography mechanisms are introduced and at least one of them is a novel mechanism.
+
+##### Edge/boundary conditions
+
+Feature contains edge/boundary conditions.
+
+- 0. No discernible edge cases or boundary conditions are introduced.
+- 1. A single edge-case or boundary-condition prone mechanism is introduced.
+- 2. Multiple edge-case or boundary-condition prone mechanisms are introduced, but none of them requires an elevated number of cases to test.
+- 3. Multiple edge-case or boundary-condition prone mechanisms are introduced and at least one of them requires an elevated number of cases to test.
+
+##### Block syncing changes
+
+Modifies block RLP validation mechanisms that require test client syncing.
+
+- 0. No new RLP validation mechanism is introduced.
+- 1. A single simple RLP validation mechanism is introduced.
+- 2. Multiple simple RLP validation mechanisms are introduced or a single complex one.
+- 3. Multiple RLP validation mechanisms are introduced and at least one of them is deemed complex.
+
+##### Engine API changes
+
+Introduces new fields to the Engine API directives
+
+- 0. No new fields or communication mechanisms are introduced to the Engine API.
+- 1. A single new field is introduced in one of the Engine API endpoints.
+- 2. Multiple fields are introduced to one or multiple Engine API end points, or a new Engine API end-point is introduced.
+- 3. Multiple fields are introduced to one or multiple Engine API end points and a new Engine API end-point is introduced.
+
+##### Added system contracts
+
+Introduces new system contract, stateful or not
+
+- 0. No new system contracts are introduced.
+- 1. A new system contract is introduced that is not stateful nor does it trigger a new system action (e.g. requests to the consensus layer).
+- 2. Multiple new system contracts are introduced or a single new system contract that is either stateful or triggers a new system action (e.g. requests to the consensus layer).
+- 3. Multiple new system contracts are introduced and at least one of them is either stateful or triggers a new system action (e.g. requests to the consensus layer).
+
+##### Modified system contracts
+
+Modifies pre-existing system contracts
+
+- 0. No modifications to pre-existing system contracts are introduced, directly or indirectly.
+- 1. Does not directly modify any system contract, but its behavior has minor indirect effects on one or more system contracts.
+- 2. Does not directly modify any system contract, but its behavior has major indirect effects on one or more system contracts.
+- 3. At least one pre-existing system contract code or state is modified, which would involve irregular state transition or a similarly complex transition methodology.
+
+##### Added opcodes
+
+Introduces new opcodes
+
+- 0. No new opcodes are introduced.
+- 1. A new simple opcode is introduced (no data portion, no complex stack mechanics, and a constant gas cost).
+- 2. Multiple new simple opcodes are introduced, or a single new complex opcode is introduced (has data portion, or complex stack mechanics, or a dynamic gas cost).
+- 3. Multiple new opcodes are introduced, and at least one of them is complex (has data portion, or complex stack mechanics, or a dynamic gas cost).
+
+*Cryptography opcodes are not considered complex by default. Refer to the "Cryptography" section for a separate assessment.
+
+##### Modified opcodes
+
+Modifies pre-existing opcodes
+
+- 0. No pre-existing opcode modifications are introduced.
+- 3. At least one pre-existing opcode's behavior is modified (not including gas changes) or a pre-existing opcode is deprecated.
+
+##### Added precompiles
+
+Introduces new precompiles
+
+- 0. No new precompiles are introduced.
+- 1. A new simple precompile is introduced (constant input length, constant gas cost).
+- 2. Multiple new simple precompiles are introduced, or a single new complex precompile is introduced (dynamic input length or dynamic gas cost).
+- 3. Multiple new precompiles are introduced, and at least one of them is complex (dynamic input length or dynamic gas cost).
+
+*Cryptography precompiles are not considered complex by default. Refer to the "Cryptography" for a separate assessment.
+
+##### Modified precompiles
+
+Modifies pre-existing precompiles logic or gas-accounting
+
+- 0. No pre-existing precompiles are modified.
+- 1. At least one pre-existing precompile has its gas schedule modified.
+- 2. Multiple pre-existing precompiles have their gas schedule modified, or a single pre-existing precompile has its behavior modified.
+- 3. The behavior of multiple pre-existing precompiles, or a single complex pre-existing precompile modified.
+
+##### Encoding changes (RLP/SSZ)
+
+Introduces encoding changes at the transaction/block/interfaces level
+
+- 0. No encoding changes are introduced at the transaction, block, or interfaces levels.
+- 3. An encoding change is introduced at transaction, block or interfaces level (e.g. RLP -> SSZ).
+
+##### New transaction types
+
+Introduces a new transaction type
+
+- 0. No new transaction types are introduced.
+- 3. A new transaction type is introduced.
+
+##### New or modified transaction validity mechanisms
+
+Creates new or modifies pre-existing transaction types' validation mechanisms
+
+- 0. No changes are introduced to the validity rules of existing transaction types or to their intrinsic gas cost calculation.
+- 1. Minor adjustments are introduced to validity rules or intrinsic gas cost calculation, but they do not significantly affect existing tests.
+- 2. Changes to validity rules or intrinsic gas cost calculation affect existing tests, but require only limited updates to test cases and no redesign of the testing infrastructure.
+- 3. Changes to validity rules or intrinsic gas cost calculation require extensive rework or redesign of the tests or testing infrastructure.
+
+##### New block / header fields
+
+Introduces new block or block header fields
+
+- 0. No new block or header fields are introduced.
+- 3. A new block or header field is introduced.
+
+##### New fork activation mechanism
+
+Modifies state, internal variables, or similar, at the fork activation block
+
+- 0. No state modifications, internal variables or similar are modified at the fork activation block.
+- 3. Either a state modification or internal variables are modified at the fork activation block.
+
+*Initialization of new internal variable is not considered a modification.
+
+##### Performance risks
+
+Introduces or modifies mechanisms and requires performance validation.
+
+- 0. No new mechanisms are introduced that require performance validation.
+- 1. The introduced mechanisms can be benchmarked in isolation and do not affect existing performance behavior.
+- 2. The introduced mechanisms cannot be fully benchmarked in isolation, but they only have a limited impact on the existing performance benchmarks.
+- 3. The introduced mechanisms cannot be benchmarked in isolation and have a substantial impact on existing performance benchmarks or have complex interactions with existing mechanisms.
+
+##### Security risks
+
+Introduces or modifies mechanisms that could compromise the security of the chain, users, validators, or other stakeholders, if not implemented properly.
+
+- 0. No new mechanisms are introduced that could pose a security risk.
+- 1. The introduced mechanisms are self-contained, can be validated in isolation, and do not alter existing invariants that could pose a security risk for any stakeholders.
+- 2. The introduced mechanisms interact with a limited number of existing components, slightly altering their security assumptions and requiring a targeted security review or fuzzing.
+- 3. The introduced mechanisms interact with multiple existing components, including critical ones, substantially altering their security assumptions and requiring an extensive security review and fuzzing.
+
+##### Cross-EIP interactions
+
+Introduces or modifies mechanisms that affect other EIPs in either the same or past forks.
+
+- 0. Fully self-contained EIP that does not depend on, modify, or conflict with any other EIP.
+- 1. The EIP interacts with one or more other EIPs in a non-critical and limited way but can be tested independently for the most part.
+- 2. The EIP depends on or modifies one or more other EIPs such that coordinated testing and consideration is required, but interactions are limited in scope and not complex.
+- 3. The EIP has strong interdependencies with multiple EIPs, requiring extensive coordinated cross-EIP testing as well as potential re-design of existing test vectors.
+
+### Checklist
+
+| Anchor | Score (0–3) | Rationale |
+|---|---:|---|
+| **EVM Gas rule changes** | 0 |   |
+| **Blob gas accounting changes** | 0 |   |
+| **New EVM gas refund** | 0 |   |
+| **Patterns affecting pre-existing tests** | 0 |   |
+| **Transition-tool interface changes** | 0 |   |
+| **Cryptography-related testing** | 0 |   |
+| **Edge/boundary conditions** | 0 |   |
+| **Block syncing changes** | 0 |   |
+| **Engine API changes** | 0 |   |
+| **Engine API encoding changes** | 0 |   |
+| **Added system contracts** | 2 |   |
+| **Modified system contracts** | 0 |   |
+| **Added opcodes** | 0 |   |
+| **Modified opcodes** | 0 |   |
+| **Added precompiles** | 0 |   |
+| **Modified precompiles** | 0 |   |
+| **Encoding changes (RLP/SSZ)** | 0 |   |
+| **New transaction types** | 0 |   |
+| **New or modified transaction validity mechanisms** | 0 |   |
+| **New block / header fields** | 0 |   |
+| **New fork activation mechanism** | 3 |   |
+| **Performance risks** | 0 |   |
+| **Security risks** | 0 |   |
+| **Cross-EIP interactions** | 0 |   |
+
+**Total: X**
+
+#### Special Considerations
+
+The system contract is similar to pre-existing queue contracts.
+
+#### Notes
+
+> Evaluator notes that do not affect the score but are valid points that must be taken into consideration when the tests are being written.
+
+#### Final Assessment
+
+| Category | Description | Value |
+|-----------|--------------|:----:|
+| **Total Score** | Sum of all anchor scores (0–72) | **`5`** |
+| **Complexity Tier** | Computed from total score | 🟢 |
+
+##### Tier Interpretation
+
+| Tier | Range | Meaning |
+|------|--------|----------|
+| 🟢 **Low Complexity** | **<10** | Minor feature or localized change. Existing tests are largely unaffected. Does not require intensive cross-EIP testing. |
+| 🟡 **Medium Complexity** | **>=10<20** | Moderate change affecting multiple components. Requires moderate cross-EIP testing. |
+| 🔴 **High Complexity** | **>=20** | Broad or deep impact on protocol behavior; high regression risk; and/or requiring intensive cross-EIP testing. |
+
+
+## Consensus Specs
+
+### Specs
+
+### Testing
+
+### Notes