Skip to content

EIP-8141 Implementation Tracker: Frame Transaction #2829

Open

Description

@spencer-tb

EIP-8141: Frame Transaction

Target Fork

Bogota

Instructions

  • Assign issue to EIP specification and testing owner(s).

Important

A specifications specialist and a testing specialist should ideally share ownership of the EIP.

  • Add the issue to the target fork milestone if applicable (i.e., the EIP is at least in the CFI stage).

Guidance for Marking Items Complete

An item should only be checked off once the EIP is considered stable. In this context, stable means:

  • No major issues or ambiguities are still being uncovered in the specification or tests.
  • There are no open discussion points awaiting resolution.
  • Client implementations have been consistently passing the tests for at least a week.

It is ultimately up to the owners' discretion to decide when an item should be marked as complete, using this guidance as the basis for that decision.

In exceptional cases, an EIP may require changes after some items have been marked complete or even after the entire issue has been completed and closed. This can happen, for example, when significant design optimizations are identified and agreed upon in ACD, or when critical security issues surface and require updates to the specification or tests.

When this occurs, owners should either unmark the relevant checkboxes if the issue is still open, or create a new tracking issue for the modifications if the original issue had already been closed.

Specification Changes Tracker

Specification + Testing Status

  • Testing complexity assessed and documented. See here
  • Test case tracker created. See here
  • Specification implementation merged to eips/<fork>/eip-<eip-number> (skip if the fork branch merge below is already complete).
  • Specification updates merged to the corresponding forks/<fork> branch.
  • EIP updates proposed in case of architectural choices surfaced during implementation.
  • Required testing framework modifications implemented.
  • Test suite implemented.
  • Full code coverage for all changes.
  • No regressions or failures in tests from prior forks (including static tests).
  • Testing checklist complete.
  • Hardening session completed.
  • Benchmarking tests written and results documented.
  • Ran tests using execute to ensure compatibility, and marked specific tests to be skipped when they cannot be executed on live networks.
  • Added Mainnet-marked tests (example test).

Process Status

  • Hive tests passing on at least two implementations.
  • EIP included in a devnet.

Activity

  1. added
    A-spec-specsArea: Specification—The Ethereum specification itself (eg. `src/ethereum/*`)
    C-eipCategory: tracking implementation of an EIP
    C-testCategory: test
    A-spec-testsArea: tests for specifications e.g. json_infra
    on May 9, 2026
  2. added this to the milestone on May 9, 2026
  3. added theissue type on May 9, 2026
  4. github-actions commented on Jul 12, 2026

    @github-actions
    Contributor

    This issue has had no recent activity and has been marked as stale.

  5. added
    staleThe Issue/PR has not had any activity for 60 days. PRs will be automatically closed.
    on Jul 12, 2026
  6. removed
    staleThe Issue/PR has not had any activity for 60 days. PRs will be automatically closed.
    on Aug 8, 2026
  7. kevaundray commented on Aug 9, 2026

    @kevaundray
    Contributor

    Not sure where to note this, so leaving here :) : A few EIPs like recent roots are built ontop of 8141 and they add new bytecode. This is a tracker to just specify that we eventually will need to freeze and audit that bytecode

  8. chugarchugarr commented on Aug 26, 2026

    @chugarchugarr

    Cross-EIP hardening finding: #3443 covers the EIP-8141 / EIP-7778 storage-refund boundary. Frame settlement correctly refunds the payer, but block execution gas must remain pre-refund. Regression coverage is included in the PR.

  9. chugarchugarr commented on Sep 7, 2026

    @chugarchugarr

    Cross-EIP contribution in progress for the EIP-8141 × EIP-7805 boundary described by EIP-8369.

    I’m turning a complete executable model into upstream spec/test contributions for Profile-2 eligibility rather than treating Frames and FOCIL as separate test surfaces. The concrete scope is:

    • deterministic Profile-2 classification for Frame transactions;
    • builder-claimed evaluation index with end-of-payload default semantics;
    • authenticated state-at-index reconstruction;
    • bounded validation-prefix replay over the permitted AA-VOPS surface;
    • keyed-nonce / recent-root / payer / code dependency handling;
    • consensus-visible convergence on the same inclusion_list_satisfied result across implementations.

    The invariant I’m targeting is simple: given the same IL, payload, parent state, claims, fork context, and profile rules, conforming implementations must derive the same omission verdict.

    I’ll keep the first upstream changes focused on executable specification + conformance vectors and link the PRs here as they land.

  10. removed this from the milestone on Sep 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

A-spec-specsArea: Specification—The Ethereum specification itself (eg. `src/ethereum/*`)A-spec-testsArea: tests for specifications e.g. json_infraC-eipCategory: tracking implementation of an EIPC-testCategory: test

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions