This document is intentionally public before approval. It was generated with AI assistance (OpenAI ChatGPT) from the published EthTrust v3 specification, activated Ethereum Improvement Proposals and public GBBC Capital Markets Risk Mitigation Framework materials.
It has not been technically reviewed, approved or adopted by the EEA EthTrust Security Levels Working Group or the Enterprise Ethereum Alliance. It MUST NOT be represented as an EEA standard or approved certification baseline. References to GBBC and RMF participants describe the external framework and do not imply that GBBC or any participant has reviewed or endorsed this draft.
The purpose of publishing this page is to make review easier: reviewers can see the proposed changes from v3, the candidate normative language, the Ethereum upgrade rationale and the areas where expert validation is specifically requested.
Version 3 remains the baseline. Version 4 is currently drafted as a delta: unchanged v3 requirements are not rewritten here. The proposed changes are concentrated where Ethereum execution semantics or the security review environment changed after the v3 technical baseline.
Stops treating “EOA has no code” as a security boundary and updates tx.origin, authorization, initialization and storage assumptions.
Adds requirements around transaction-scoped state lifetime, reentrancy and DELEGATECALL ownership.
Retains v3's prohibition but corrects obsolete assumptions that code and storage are normally deleted.
Adds a liveness check for security-critical atomic operations under Fusaka's per-transaction execution bound.
Adds conditional validation guidance for BLS12-381 and P-256 verification used in security-critical logic.
Replaces a late-2023 static cutoff with a requirement to check current compiler security advisories at certification time.
| Area | Version 3 | Proposed Version 4 | Change |
|---|---|---|---|
| Account model | EOA / contract distinction reflects the pre-7702 account model. | Review assumes EOAs can execute delegated code; code presence is not a general authorization boundary. | New |
tx.origin | Strongly discouraged; qualified use can be reviewed. | Qualified review must test delegated-account execution and cannot rely on historical top-level-call invariants. | Modified |
| Transient state | No TLOAD/TSTORE requirements. | Explicit lifetime, same-transaction reuse, reentrancy and delegatecall checks. | New |
SELFDESTRUCT | Prohibited by default, but explanatory text reflects older deletion semantics. | Same prohibition; allowed-use review reflects EIP-6780 semantics. | Modified |
| Execution bounds | General gas / DoS analysis. | Security-critical atomic flows must fit the EIP-7825 transaction gas cap or have a safe bounded alternative. | New |
| Cryptographic precompiles | Existing crypto/signature requirements. | Conditional requirements for correct new-precompile input, output and verification semantics. | New |
| Compiler bugs | Explicit bugs through SOL-2023-3; good practice asks reviewers to check newer issues. | Current security-advisory check becomes part of the certification requirement. | Modified |
| Institutional risk mapping | No GBBC RMF mapping. | Non-normative crosswalk proposed so EthTrust can serve as a smart-contract security control reference inside broader RMF risk categories. | New |
All wording and requirement levels below are provisional. The purpose of this section is to expose concrete language for review rather than ask reviewers to react to a high-level proposal.
Tested Code MUST NOT use EXTCODESIZE, EXTCODEHASH, Solidity address.code.length, address.codehash, or equivalent account-code introspection as the sole basis for asserting that an address is non-programmable, cannot execute delegated logic, cannot make multiple calls in one transaction, cannot re-enter Tested Code, or is therefore trusted or eligible for elevated authorization.
Account-code introspection MAY be used for other documented purposes where its result is not treated as a security boundary.
tx.origin Under Delegated Account ExecutionFor Tested Code that uses tx.origin, each use MUST be reviewed under EIP-7702 semantics. The review MUST NOT assume that tx.origin == msg.sender can only occur in the topmost execution frame or that such equality prevents programmable multi-call execution.
Where tx.origin participates in authorization, reentrancy protection, flash-loan or atomic-execution restrictions, anti-bot logic, or other security-sensitive behavior, the reviewer MUST document and test behavior when the originating account has delegated code. The existing v3 [S] No tx.origin requirement remains the preferred baseline.
Tested Code that acts as an EIP-7702 delegate implementation, constructs or verifies delegated-operation authorizations, or relays delegated operations MUST ensure that security-sensitive authorizations bind the information necessary to prevent unintended execution, including as applicable replay protection / nonce, intended chain or explicit cross-chain behavior, execution target, calldata or operation payload, transferred value, griefing-sensitive execution bounds, and the authority whose privilege is exercised.
Any intentional omission MUST be documented and shown not to violate the security objectives of the Tested Code.
Where Tested Code executes as EIP-7702 delegated code, privileged initialization MUST be authenticated and protected against front-running; storage layout MUST prevent unintended collisions or provide an equivalent migration-safety mechanism; delegation changes MUST be treated as security-sensitive upgrades; and modules, session keys, relayers or sub-keys MUST follow least privilege.
For each transient storage value that affects authorization, reentrancy protection, accounting, settlement, pricing, or another security invariant, Tested Code MUST document its intended lifetime; MUST NOT rely on it persisting across transactions; MUST account for multiple calls within the same transaction; and MUST ensure that a non-zero value left after a call cannot cause unintended behavior in a later same-transaction call.
Where a transient value is intended to be scoped to a call rather than the transaction, Tested Code MUST explicitly restore or clear it before the relevant call completes.
DELEGATECALLWhere Tested Code combines transient storage with DELEGATECALL or CALLCODE, the reviewer MUST verify transient-storage ownership and slot usage in the caller's context and MUST test for collisions or unsafe state sharing between delegated modules.
SELFDESTRUCT — EIP-6780selfdestruct() / [M] Protect Self-destructionThe existing v3 prohibition remains appropriate. The explanation should state that after EIP-6780, SELFDESTRUCT normally transfers the account balance and halts the frame without deleting code or storage, except when invoked in the same transaction in which the contract was created.
Any reviewed exception MUST NOT rely on later deletion of deployed code/storage, later CREATE2 redeployment of different code at the same address, or other pre-Dencun lifecycle assumptions.
Where safe operation depends on an administrative, recovery, upgrade, settlement, liquidation, migration, emergency, or other security-critical transaction completing atomically, the reviewer MUST establish that it can execute within the transaction gas cap of the intended network under the documented worst-case state.
If it may exceed that bound, Tested Code MUST provide a safe bounded/chunked alternative or the limitation MUST be documented and shown not to create an unacceptable denial-of-service or asset-locking condition.
Where Tested Code depends on a cryptographic precompile for authentication, authorization, consensus proofs, bridge verification, or asset-control decisions, it MUST validate precompile-specific input encoding and bounds, distinguish successful EVM call execution from successful cryptographic verification, validate the exact expected return length/value, apply appropriate replay protection and domain separation, and document curve-specific assumptions on which security depends.
For EIP-7951 specifically, callers MUST NOT treat a successful STATICCALL alone as proof of a valid P-256 signature.
At certification time, the reviewer MUST check the Solidity compiler version(s) used by the Tested Code against current Solidity security-advisory / known-bugs sources and determine that no known applicable compiler vulnerability invalidates the certification requirements.
The certification record MUST identify compiler version(s), relevant compilation configuration, advisory sources checked, and the date of the check.
A previously certified contract SHOULD be reassessed when a network upgrade changes an opcode, precompile, account model, gas bound, or execution semantic on which its security assumptions depend. A protocol upgrade with no relevant effect on the Tested Code does not by itself require recertification.
For the candidates that modify or replace existing requirements, this shows the exact current v3 normative text (pulled from the approved v3 specification, each linked to its anchor) beside the proposed v4 language, so reviewers can judge the delta precisely. Candidates with no v3 counterpart follow in the table below.
Tested code MUST NOT contain a tx.origin instruction unless it meets the Overriding Requirement [Q] Verify tx.origin Usage.
For Tested Code that uses tx.origin, each instance MUST be consistent with the stated security and functionality objectives of the Tested Code, and MUST NOT allow assertions about contract functionality made for [Q] Document Contract Logic or [Q] Document System Architecture to be violated by another contract, even where that contract is called by a user authorized to interact directly with the Tested Code. This is an Overriding Requirement for [S] No tx.origin.
For Tested Code that uses tx.origin, each use MUST be reviewed under EIP-7702 semantics. The review MUST NOT assume that tx.origin == msg.sender can only occur in the topmost execution frame or that such equality prevents programmable multi-call execution. Where tx.origin participates in authorization, reentrancy protection, flash-loan or atomic-execution restrictions, anti-bot logic, or other security-sensitive behavior, the reviewer MUST document and test behavior when the originating account has delegated code. The existing v3 [S] No tx.origin requirement remains the preferred baseline.
Tested code MUST NOT contain the selfdestruct() instruction or its now-deprecated alias suicide() unless it meets the Set of Overriding Requirements [M] Protect Self-destruction, and [M] Document Special Code Use.
Tested code that contains the selfdestruct() or suicide() instructions MUST ensure that only authorised parties can call the method, and MUST protect those calls in a way that is fully compatible with the claims of the contract author, unless it meets the Overriding Requirement [Q] Enforce Least Privilege. This is an Overriding Requirement for [S] No selfdestruct().
v3's surrounding explanation still describes pre-Dencun deletion semantics.
The existing v3 prohibition remains appropriate. The explanation should state that after EIP-6780, SELFDESTRUCT normally transfers the account balance and halts the frame without deleting code or storage, except when invoked in the same transaction in which the contract was created. Any reviewed exception MUST NOT rely on later deletion of deployed code/storage, later CREATE2 redeployment of different code at the same address, or other pre-Dencun lifecycle assumptions.
Check [solidity-bugs-json] and other sources for bugs announced after 1 November 2023 and address them.
In v3 this is a Recommended Good Practice — optional, with a fixed cutoff date; explicit compiler-bug requirements cover issues through SOL-2023-3.
At certification time, the reviewer MUST check the Solidity compiler version(s) used by the Tested Code against current Solidity security-advisory / known-bugs sources and determine that no known applicable compiler vulnerability invalidates the certification requirements. The certification record MUST identify compiler version(s), relevant compilation configuration, advisory sources checked, and the date of the check.
| Candidate | v3 today | Nearest existing v3 requirements (context only — not modified by this draft) |
|---|---|---|
| [S-v4-01] Account code as security boundary | No requirement; review reflects the pre-7702 account model. | — |
| [M-v4-03] 7702 delegation logic | No requirement. | — |
| [M-v4-04] Delegated account init & storage | No requirement. | — |
| [M-v4-05] Transient storage lifetime | No TLOAD/TSTORE requirements. | — |
| [M-v4-06] Transient storage under DELEGATECALL | No TLOAD/TSTORE requirements. | — |
| [M-v4-07] Transaction gas cap bound | General gas/DoS analysis only; no per-transaction execution bound. | [Q] Manage Gas Use Increases · [Q] Protect Gas Usage |
| [M-v4-08] Cryptographic precompile results | No precompile-specific requirements. | [M] Proper Signature Verification |
| [GP-v4-10] Reassess after network upgrades | No reassessment trigger exists. | — |
Disagree with a pairing or classification? That is exactly the "v3 → v4 comparison" feedback type in the review form.
This is a first-pass classification for expert review. The intent is to show that v4 has considered the execution environment systematically, while avoiding unnecessary requirements for EIPs with no direct smart-contract security consequence.
| EIP | Upgrade | Initial classification | EthTrust implication |
|---|---|---|---|
| 1153 | Dencun | Normative | Transient state lifetime, reentrancy and delegated execution. |
| 4788 | Dencun | Guidance | Consensus-root consumers should document proof/finality assumptions. |
| 4844 | Dencun | Guidance | No general new smart-contract vulnerability identified. |
| 5656 | Dencun | Guidance | Tooling/static analyzers should recognize MCOPY. |
| 6780 | Dencun | Normative update | Correct obsolete SELFDESTRUCT lifecycle assumptions. |
| 7516 | Dencun | Guidance | Blob-base-fee users should include economic-input assumptions in review. |
| 2537 | Pectra | Conditional normative | Security-critical BLS12-381 callers need exact verification semantics. |
| 2935 | Pectra | Guidance | Historical block-hash consumers should document time/reorg assumptions. |
| 7702 | Pectra | Normative | Changes account-model, authorization and composability assumptions. |
| 7825 | Fusaka | Normative | Hard per-transaction execution bound can affect recovery/liveness guarantees. |
| 7883 | Fusaka | Guidance | MODEXP repricing can affect crypto-heavy gas assumptions. |
| 7939 | Fusaka | Tooling | Static-analysis/opcode inventories should recognize CLZ. |
| 7951 | Fusaka | Conditional normative | P-256/passkey/HSM use requires exact result validation. |
The final v4 work should expand this into an exhaustive post-v3 mainnet EIP matrix, including entries explicitly classified “reviewed — no EthTrust impact.” Draft/future-fork proposals should not become normative merely because they are under discussion.
The proposed relationship is deliberately narrow: GBBC RMF provides a broader institutional non-financial risk framework; EthTrust provides detailed Ethereum smart-contract security controls. Where the RMF identifies application-layer or smart-contract security risks, an approved EthTrust version could serve as a technical implementation/reference standard rather than duplicating the RMF.
Why this is strategically relevant: GBBC describes the RMF as an industry-led standard for blockchain infrastructure used by regulated financial institutions, developed with more than 30 contributing institutions. Phase 1 addresses public Layer-1 infrastructure. Phase 2 extends to Layer-2 infrastructure and application risks for digital payments and tokenized securities.
No endorsement is implied. The organizations below are participants in the GBBC RMF initiative according to GBBC's public RMF site. Their inclusion here does not mean they have reviewed, approved or endorsed EthTrust v4.
This draft is most useful if reviewers focus on correctness and testability rather than editorial polish.
Before a final v4 release, approved changes should be merged into a complete self-contained specification and checklist, reviewed through the EEA Working Group process, and clearly separated from this AI-generated initial draft history.
Copyright © 2020–2026 Enterprise Ethereum Alliance. Review draft only.