EIP-7819: SETDELEGATE instruction

⌬LLM A single opcode is added, but its state-dependent net gas, multi-step stack behavior, state access, code/nonce mutation, and failure paths make it a complex opcode under the rubric.

⚇Human One complex opcode is added: it has dynamic access, write, and state-gas costs and mutates another account while returning its derived address.

⌬LLM SETDELEGATE adds another way to create an already-defined delegation object; it does not itself modify the behavior of a pre-existing opcode.

⚇Human No pre-existing opcode's result changes.

⌬LLM No precompile is introduced.

⚇Human No precompile is added.

⌬LLM Existing precompile behavior and gas schedules are not modified.

⚇Human No precompile logic or gas schedule changes.

⌬LLM No system contract is introduced.

⚇Human No system contract is added.

⌬LLM The proposal has no direct or specified indirect system-contract modification.

⚇Human No existing system contract is modified directly or indirectly.

⌬LLM The opcode introduces its own gas-accounting rule, including a state-dependent refund, while leaving the gas rules of existing opcodes unchanged. This is a new mechanism confined to the new operation.

⚇Human `SETDELEGATE` introduces a dynamic schedule composed of cold/warm access and an account-write charge. It does not change another opcode's schedule, but exact and repeat-write cases need dedicated accounting tests.

⌬LLM SETDELEGATE is a new state-accessing operation whose charge, warm-access, read, refund, and write positions require boundary testing. It does not change the ordering rule for an existing class of opcodes, so score 2 rather than 3 applies.

⚇Human A new state-accessing opcode must check state-independent access gas before reading the location, then calculate and charge state-dependent costs. BAL output changes at those boundaries.

⌬LLM No blob gas accounting mechanism is introduced or modified.

⚇Human No blob gas behavior changes.

⌬LLM No new transaction type is introduced.

⚇Human No transaction type is introduced.

⌬LLM Runtime opcode failure conditions do not modify transaction-envelope validity.

⚇Human Transaction validity and intrinsic gas rules are unchanged.

⌬LLM The proposal introduces no new block or header field.

⚇Human No block or header field is added.

⌬LLM No RLP, SSZ, or other interface-level encoding change is introduced.

⚇Human No transaction, block, or interface encoding changes.

⌬LLM No block RLP validation mechanism requiring sync testing is introduced.

⚇Human Block encoding and RLP validation are unchanged.

⌬LLM Enabling a new opcode requires no special activation mechanism as written.

⚇Human Activation only makes the opcode valid; it does not mutate state at the fork block.

⌬LLM No Engine API surface is introduced or modified.

⚇Human No Engine API field or endpoint changes.

⌬LLM Existing transition-tool interface shapes are sufficient as specified.

⚇Human The transition-tool request and result interfaces are unchanged.

⌬LLM Existing fork/opcode-validity coverage for byte 0xf6 must distinguish the activation boundary and the new behavior. That is a minor, localized subset of pre-existing tests; the broader SETDELEGATE matrix consists of new tests.

⚇Human Three fixture executions of one existing constant-gas opcode-sweep function flipped because `SETDELEGATE` is dynamic; the sweep now excludes it. No other existing test was reworked or parked.

⌬LLM The proposal does not require tests unrelated to SETDELEGATE to assert a new output or invariant.

⚇Human Tests unrelated to EIP-7819 gain no new assertion.

⌬LLM The new opcode's hashing, state access, fixed-size code write, and delegated call path require benchmarking, but the operation is bounded and can be benchmarked in isolation; the delegated execution mechanism already comes from EIP-7702.

⚇Human The opcode adds account reads and code/nonce writes, but it can be benchmarked in isolation and does not alter existing benchmark behavior.

⌬LLM Multiple boundary-prone mechanisms combine, and repeated same-location changes multiply success, failure, revert, refund, warm/cold, target, and call-timing cases. At least this repeated-update mechanism requires an elevated test matrix.

⚇Human Testing spans target truncation/padding, salt/address order, zero-target clearing, nonce zero/nonzero, exact and malformed collision code, cold/warm access, fresh/existing leaves and designations, exact/one-short gas, static mode, call contexts, and success/revert interactions. Several axes combine in elevated gas/state matrices.

⌬LLM Using an existing hash in a new derivation is not a new cryptographic mechanism.

⚇Human Address derivation reuses existing Keccak-256 and introduces no new cryptographic primitive.

⌬LLM SETDELEGATE strongly extends EIP-7702's shared delegation object, must coordinate access warming with EIP-2929 and non-empty-account preservation with EIP-7523, relies on the EIP-3541 marker convention, and is explicitly integrated into EIP-8141 deployment and mempool validation. These multiple interdependencies require coordinated cross-EIP execution, failure, introspection, and deployment tests.

⚇Human Coordinated cases cover EIP-7702 designation semantics, EIP-2929 warming, EIP-7523 nonce persistence, EIP-3541 collision reachability, EIP-6780 `SELFDESTRUCT`, EIP-7928 BAL observability, EIP-8037 state gas, and EIP-8038 access/write pricing. The base interaction level is 2; eight interacting EIPs add 1 for the five beyond the first three.

⌬LLM Clients need agreement on localized, constructible cases: the exact failure semantics and rollback boundary of both halt sites, and original-versus-current existence for refunds. Most other opcode behavior is specified, so the gaps are material but localized rather than a wholesale redefinition.

⚇Human The current EIP leaves localized consensus questions around post-EIP-8037 gas, operand order, prefix-only versus exact designation collisions, and the state point used for trie existence. The prototype records assumptions, but clients need agreement before production vectors are baselined.