diff --git a/complexity_assessments/EIPs/EIP-8141.md b/complexity_assessments/EIPs/EIP-8141.md
new file mode 100644
index 0000000..c00d071
--- /dev/null
+++ b/complexity_assessments/EIPs/EIP-8141.md
@@ -0,0 +1,282 @@
+# EIP-8141: Frame Transaction
+
+Link: https://eips.ethereum.org/EIPS/eip-8141
+
+## Execution Specs
+
+### Specs
+
+[EIP-8141](https://eips.ethereum.org/EIPS/eip-8141)
+
+### 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** | 2 | New per-frame gas isolation (`gas_limit` allocated per frame, not carried forward across frames) and new opcode gas costs (TXPARAM/FRAMEPARAM/SIGPARAM = 2, FRAMEDATALOAD = 3, FRAMEDATACOPY = 3 + word copy + mem expansion, APPROVE = 0). New mechanism, but applies only to type 0x06 frames and does not modify legacy tx gas accounting. |
+| **Blob gas accounting changes** | 0 | Frame tx carries EIP-4844 blob fields (`max_fee_per_blob_gas`, `blob_versioned_hashes`) but reuses existing blob gas accounting unmodified. |
+| **New EVM gas refund** | 3 | New complex refund mechanism: post-execution refund of gas to a designated `payer` resolved at runtime, plus full refund of skipped frames in failed atomic batches. Multiple refund paths; forces rework of existing refund-flow test infrastructure. |
+| **Patterns affecting pre-existing tests** | 1 | New tx type is self-contained; legacy/1559/blob/7702 tx flows unchanged. Only minor impact on pre-existing opcode tests (new opcodes APPROVE/TXPARAM/FRAMEPARAM/SIGPARAM/FRAMEDATALOAD/FRAMEDATACOPY are globally available in the EVM regardless of tx type, so their behavior must be defined when invoked from legacy txs). |
+| **Transition-tool interface changes** | 1 | No new block-environment fields, header inputs. Frame txs flow through standard EIP-2718 typed-tx dispatch. The one interface-side change is the receipt output schema, which gains a new shape for type 0x06: `[cumulative_gas_used, payer, [frame_receipt, ...]]` with a top-level `payer` field (resolved at runtime). |
+| **Cryptography-related testing** | 1 | Introduces P256 as a tx-authentication primitive for the first time via a scheme dispatcher (0x0 = SECP256K1, 0x1 = P256). Verification is defined as the P256VERIFY cryptographic operation. |
+| **Edge/boundary conditions** | 4 | Exceeds defined anchors: combinatorial explosion across mechanisms rather than a single elevated-case mechanism. Frame modes × flags × atomic-batch state × signature schemes × APPROVE scope matrix × default-code branches; further compounded by atomic batching, and cross-frame access. |
+| **Block syncing changes** | 2 | Two new RLP validation mechanisms that affect syncing clients: (1) the type 0x06 tx-RLP envelope; (2) the corresponding new receipt-RLP shape (important for receipts root). |
+| **Engine API changes** | 0 | No new or modified Engine API endpoints, fields, or communication mechanisms. |
+| **Engine API encoding changes** | 0 | None  |
+| **Added system contracts** | 1 | `EXPIRY_VERIFIER` at address `0x8141`, installed by clients at fork activation. |
+| **Modified system contracts** | 0 | None  |
+| **Added opcodes** | 4 | Exceeds defined anchors: six new opcodes in a single EIP (~2-3× typical precedent of 1-2). Frame introspection. Signature metadata access. Testing will involve interaction with legacy txs types as well. |
+| **Modified opcodes** | 3 | Behavior of some opcodes like `ORIGIN` changes under the new transaction type. |
+| **Added precompiles** | 0 | None  |
+| **Modified precompiles** | 0 | None  |
+| **Encoding changes (RLP/SSZ)** | 0 | All encodings remain RLP — no format migration. |
+| **New transaction types** | 3 | New tx type 0x06 (frame transaction). |
+| **New or modified transaction validity mechanisms** | 3 | New intrinsic gas formula (mixed per-frame + per-signature + sum-of-frame-limits + calldata over two separate RLP streams), upfront multi-signature validation, frame-level constraints (mode/value/flags/count), runtime payer-designation and sender-approval. Introduces a post execution validity check which is totally new to EELS. Requires extensive test-infrastructure rework (filler intrinsic-gas computation, multi-scheme signing helpers etc). |
+| **New block / header fields** | 0 | None  |
+| **New fork activation mechanism** | 3 | Clients install `EXPIRY_VERIFIER` runtime code at address `0x8141` at fork activation — a state modification at the activation block. |
+| **Performance risks** | 2 | Per-tx cost scales with frame count (≤64) and signature count, but is bounded and parameterizable. New opcodes individually benchmarkable. Main new concern is mempool DoS surface from validation-prefix work on rejected txs. This however is capped. Doesn't materially change existing performance baselines for legacy/1559/blob/7702 txs. |
+| **Security risks** | 3 | Interacts with multiple critical subsystems: tx authentication (new multi-sig + scheme based dispatch), mempool relay policy, the EOA-vs-contract invariant (EIP-3607 relaxation lets contracts execute under SENDER mode), and ORIGIN semantics. The EIP itself enumerates non-trivial attack vectors: timestamp-dependency attack, deploy-frame front-running, state-read amplification via explicit sender, cross-frame privacy leakage, paymaster griefing, and mempool DoS via invalid `tx.sender` probing. Requires extensive review and fuzzing across protocol and mempool layers. |
+| **Cross-EIP interactions** | 2 | Strong interaction with FOCIL: FOCIL relies on attesters performing lightweight static validity checks (nonce + balance) on inclusion-list transactions without executing them. Frame transactions break this assumption. |
+
+**Total: 38**
+
+#### Special Considerations
+
+> Evaluator must write here special considerations that make the EIP particularly complex to test due to reasons not directly included in this checklist.
+
+#### 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) | **`38`** |
+| **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