EthTrust v4 exploratory technical review

[M-v4-01a] Verify Account-Code Introspection

Account-code introspection MUST NOT be used by itself to establish that an address is an EOA, non-programmable, trusted, or incapable of executing contract behavior. The reviewer MUST document the purpose of each use and the independent controls supporting any security decision.

An introspection result MUST NOT be cached or relied on across transactions as a durable account classification or authorization fact. EIP-7702 delegation can be installed, changed or cleared between transactions with a valid authority authorization; observing the indicator does not establish trust in the account or its delegate.

EIP-7702 authorization processing occurs before the execution portion of a transaction. During execution, the delegation indicator cannot be installed, changed or removed. That stability MAY be relied on only for a documented decision specifically about that delegation state. It MUST NOT be generalized to stability of all account code or behavior: a constructor can call Tested Code before runtime code exists, and code can be deployed at a previously empty address later in the same transaction. A stable indicator also does not guarantee immutable delegate behavior.

The review MUST test constructor-originated calls, inspection before and after same-transaction deployment, and delegation changes between transactions, with expected outcomes tied to the stated security objectives. Other documented introspection uses MAY be accepted when they do not substitute for the independent controls above.

This is the Overriding Requirement for [S-v4-01] No Account-Code Introspection. A delegated EOA exposes a 23-byte 0xef0100 || address indicator to EXTCODE*; its code is visible. Zero runtime code is not proof of EOA status even without EIP-7702.

Sources: EIP-7702, OpenZeppelin Address documentation.

[M-v4-02a] Verify Delegated Account Balance and Nonce Assumptions

This review MUST be performed independently of whether Tested Code uses tx.origin. The reviewer MUST identify security assumptions about counterparties' native account balances and EOA nonces, including balance snapshots and nonce-derived address or ordering assumptions.

Tested Code MUST NOT assume that an account's balance can decrease only in a transaction originating from that account, or that an EOA's nonce cannot increase after transaction execution begins. A call to a delegated account can spend its balance; delegated code can execute a contract-creation operation that increases its nonce.

Where those assumptions affect security, the reviewer MUST test balance changes caused by a call from another account and nonce changes caused by contract creation during execution. If no relevant dependency exists, the review MUST record that finding and its basis. Absence of tx.origin is not grounds to skip this review.

Source for both candidates: EIP-7702, backwards compatibility.

[M-v4-03] Secure EIP-7702 Delegation Logic

For Tested Code implementing, verifying or relaying delegated operations, security-sensitive operation authorizations MUST bind the information needed to prevent unintended execution: replay nonce, intended chain or explicit cross-chain policy, target, calldata, value, griefing-sensitive gas bounds, and the authority whose privilege is exercised, as applicable. Any intentional omission MUST be documented and shown compatible with the security objectives.

The EIP-7702 protocol authorization installs a code pointer; it does not itself authorize every later operation. Review the delegate's operation-signature scheme separately from the protocol authorization tuple.

[M-v4-04] Protect Delegated Account Initialization and Storage

For Tested Code intended to execute as EIP-7702 delegated code:

• Privileged or security-sensitive initialization MUST be authenticated against the account authority and protected against front-running.
• Storage layout MUST prevent unintended collisions with prior or future delegates, or demonstrate equivalent migration safety.
• Delegation or implementation changes MUST be treated as security-sensitive upgrades.
• Privileges of modules, session keys, relayers and sub-keys MUST follow least privilege.

Namespaced storage is one possible mitigation, not a mandated implementation. Source: EIP-7702, security considerations.

[M-v4-05] Verify Transient Storage Lifetime

For every security-sensitive transient value, Tested Code MUST document its meaning and intended lifetime, account for repeated and reentrant calls in one transaction, and prevent stale values from changing later calls unexpectedly. It MUST NOT depend on persistence across transactions. Values intended to last only for a call MUST be restored or cleared before that call returns normally.

The review MUST account for rollback: reverting a frame undoes transient writes made since entry to that frame, including writes in its inner calls. Values established before entry survive that rollback. When a caller catches a failure, the review MUST establish which values survive and test both the caught-failure and propagated-revert paths.

Tested Code MUST NOT treat transient storage as frame-local memory or a drop-in substitute for in-memory mappings. A normal return does not clear it; later calls in the transaction can observe it. Any use for temporary data MUST enforce the documented lifetime and isolation explicitly.

[M-v4-06] Verify Transient Storage Under DELEGATECALL

Under DELEGATECALL or CALLCODE, transient storage belongs to the calling account, so modules executing in that account share one transient-storage namespace. Ordinary CALL uses the callee's namespace.

Delegated modules MUST NOT share transient slots unless the sharing is intended and documented. Slot derivation MUST be collision-resistant across modules. The review MUST test collisions and intended sharing across delegated modules, including rollback paths. Relate this analysis to v3's external-call and delegatecall requirements.

Source: EIP-1153.

[M-v4-07] Bound Security-Critical Operations to the Transaction Gas Cap

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 intended network's transaction gas cap under 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. Reviewers SHOULD test near-worst-case state rather than rely on deployment-time estimates. EIP-7825 sets the transaction gas-limit cap to 16,777,216 (2^24); a larger block gas limit does not override it.

Source: EIP-7825.

[M-v4-08] Verify Cryptographic Precompile Results

Where security depends on a cryptographic precompile, Tested Code MUST validate operation-specific input encoding and bounds, handle failed calls, verify exact expected output length and value, apply replay protection and domain separation, and document curve-specific assumptions. Successful EVM call execution alone MUST NOT count as cryptographic verification. The review MUST confirm availability and semantics on each target network/fork.

For EIP-7951, P-256 verification at 0x100 takes 160 bytes and returns exactly the 32-byte integer 1 on success. Invalid input or signature produces empty output without a verification-induced revert. Tested Code MUST reject failed calls, empty output and any unexpected result. The precompile does not enforce low-s: when signatures or their hashes are used as uniqueness/replay keys, Tested Code MUST enforce canonical s or equivalent application-layer non-malleability handling. Canonicalization does not replace signed-message/nonce replay protection. Relate this to v3 [M] No Improper Usage of Signatures for Replay Attack Protection and [Q] Intended Replay.

For EIP-2537, G1/G2 addition validates encoding and points on the curve (or infinity), but does not check subgroup membership. MSM and pairing do check membership. When adding externally supplied points where subgroup membership is required by the security scheme, Tested Code MUST check each point or establish that each was already checked. The review MUST cover malformed encodings, invalid points, inappropriate infinity cases, and empty inputs (which MSM and pairing reject).

MSM accepts 32-byte scalars without requiring a canonical value below the subgroup order. Distinct scalar encodings can produce the same group result. Tested Code MUST NOT assume the precompile enforces canonical scalar encoding or use unreduced scalar bytes as a uniqueness guarantee.

Sources: EIP-2537, EIP-7951.

[M-v4-09] Check Compiler Security Advisories at Certification Time

The reviewer MUST perform a final refresh of Solidity security-advisory and known-bugs sources immediately before certification is issued. This final issuance-stage refresh establishes one certification cutoff, recorded as a UTC date and time in the certification record. Earlier checks are preliminary and MUST NOT substitute for it. If issuance is delayed after that final review, the refresh and applicability assessment MUST be repeated and the cutoff replaced before issuance.

The reviewer MUST assess advisories published on or before that cutoff against every compiler version and configuration used for the Tested Code, and determine that no applicable compiler vulnerability invalidates the certification requirements. An unavailable required source or unresolved applicable advisory MUST prevent completion of this check; a stale snapshot MUST NOT be treated as a fresh review.

The certification record MUST contain:

• The single cutoff timestamp and the certification issuance timestamp.
• Exact compiler version(s), including build/commit identifiers where available.
• Compilation configuration, including optimizer settings/runs, IR pipeline, EVM target, libraries and other relevant settings.
• Tested source revision or content hashes and resulting artifact identifiers, sufficient to identify the reviewed build.
• Each advisory source URL and the date/time of the final consultation.
• An immutable source revision/version or archived snapshot with content hash for each source, sufficient to reproduce the advisory set reviewed at the cutoff.
• The applicable advisory IDs, applicability decisions, mitigations or corrected build, and evidence that the final build was reassessed.

Conformance under this candidate is assessed against that single recorded cutoff and evidence set. An advisory published later does not retroactively change the recorded determination; it SHOULD trigger reassessment when relevant to the certified code. It does not make the earlier cutoff a claim of continuing safety.

This is a manual reviewer duty at [M], changed from the earlier draft's [S-v4-09]. It would strengthen v3's optional advisory-freshness good practice. Existing enumerated per-bug [S] requirements remain in the baseline. Whether and how to extend them is unresolved; this candidate does not replace those checks.

Sources: Solidity known bugs, bugs.json, Solidity security alerts, public feedback #18.