EIP-8141: in-pool validation-prefix simulation for opaque frame transactions (Phase 2)

[Marchhill]

Changes

• Admit the opaque frame-tx validation prefixes the native resolver defers (RequiresSimulation: a deployed-code or EIP-7702 sender, a code-carrying paymaster, an unrecognized shape) by simulating the prefix in a bounded read-only EVM, resolving the payer at admission.
• Add IFrameTxPrefixSimulator in Nethermind.TxPool, implemented by FrameTxPrefixSimulator in Nethermind.Consensus over IReadOnlyTxProcessingEnvFactory. The narrow abstraction avoids a Consensus→TxPool cycle; it is injected optionally, so when unwired RequiresSimulation transactions stay deferred as before.
• Add ExecutionOptions.FrameValidationPrefixOnly and a prefix-simulation path in TransactionProcessorBase.FrameTx.cs that reuses the existing frame machinery: halts once the payer is set, bounds cumulative work by MAX_VERIFY_GAS, and always restores state.
• Add FrameTxValidationTracer enforcing the banned-opcode list, the GAS-before-call and expiry-verifier TIMESTAMP caveats, and SLOAD restricted to tx.sender.
• A successful simulation records the resolved payer and feeds the existing exposure path; a failing, over-budget or payerless one rejects with FrameSimulationFailed.

Natively-resolvable prefixes are unaffected: FrameTxSimulationFilter returns immediately when FrameTxPayerFilter already resolved the payer, so the standard shapes never enter the EVM.

Types of changes

What types of changes does your code introduce?

• New feature (a non-breaking change that adds functionality)

Testing

Requires testing

• Yes

If yes, did you write tests?

• Yes

Notes on testing

FrameTxSimulationFilterTests covers the fast path not invoking the simulator, the opaque path resolving and admitting, a failed simulation rejecting, and the unwired case deferring. FrameTxValidationPrefixSimulationTests covers payer resolution for a deployed-code sender and sponsor, the MAX_VERIFY_GAS bound, banned-opcode violations, revert and never-approves rejection, and that simulation leaves canonical state unchanged.

Documentation

Requires documentation update

• No

Requires explanation in Release Notes

• No

Remarks

Deferred, tracked as EIP8141: follow-ups: dependency-set-keyed result caching, and the first-deploy-frame carve-outs together with the CALL*/EXTCODE* target-existence and EIP-7702 trace checks — those prefixes are conservatively rejected for now, which stays spec-compliant. Simulations are serialized on one resettable world state, which bounds concurrent admission work.

[claude]

Claude finished @Marchhill's task in 11m 29s —— View job

---

Review: EIP-8141 Phase 2 — in-pool validation-prefix simulation

• Gather context (diff vs origin/eip8141-mempool-validation, Phase-1 base code)
• Review the simulation path in TransactionProcessorBase.FrameTx.cs
• Review FrameTxValidationTracer against the spec's Validation Trace Rules
• Review TxPool filter / DI wiring / threading
• Review tests
• Post findings (8 inline comments)

---

The architecture here is sound and the hard parts are done well. Reusing ExecuteFrame/ApplyApproval instead of reimplementing opcode semantics is the right call, the IFrameTxPrefixSimulator seam avoids the TxPool→Consensus cycle cleanly, isStatic: true for VERIFY frames matches the main path exactly, state is restored in a finally, and I verified the fast-path claim holds — FrameTxSimulationFilter returns before touching the EVM whenever PayerAddress is set. I also confirmed the arithmetic can't underflow (remainingVerifyGas), the TxFrame re-construction preserves argument order, and that a throwing simulation can't poison later ones (WorldState.EndScope calls Reset() on scope dispose). I cross-checked the banned-opcode list against the published EIP-8141 trace rules and it matches on every entry.

The findings below are about the trace rules being incompletely enforced relative to what the code claims, plus diagnostics and cancellation.

High

1. CALL*/EXTCODE* prefixes are silently admitted, not "conservatively rejected" — FrameTxValidationTracer.cs:21-24

The <remarks> states that prefixes needing the deferred CALL*/EXTCODE* target-existence and EIP-7702 checks "are conservatively rejected here (declining is always spec-compliant)". The CREATE/CREATE2/SETDELEGATE/SSTORE half of that is true — those are banned outright. The CALL*/EXTCODE* half is not: nothing inspects call or extcode targets, so such prefixes pass the tracer clean and are accepted. The spec's rule is permissive-with-a-condition ("may target existing contracts or precompiles"), so omitting it admits too much rather than too little — a prefix that STATICCALLs an empty account is admitted and its validity then depends on that account staying codeless, an unindexed dependency, with head-change re-simulation also deferred. Fix the check or correct the comment; as written it tells reviewers a security-relevant rule is enforced when it isn't. Fix this →

Medium

2. TIMESTAMP exemption checks the address but not the code — FrameTxValidationTracer.cs:73-76. Spec: "except in expiry verifier frames executing canonical runtime code". If 0x…8141 holds non-canonical code, arbitrary TIMESTAMP use there is exempted. Eip8141Constants.ExpiryVerifierCode exists and FrameTxPayerResolver already tracks expiryCodeHash, so the possibility is already acknowledged in the stack.

3. _pendingGasRequiresCall is never flushed at a frame boundary — FrameTxValidationTracer.cs:50-60. A prefix ending in GAS (implicit STOP, or a following instruction that faults before StartOperation) never records the violation — under-enforcement. And a pending flag surviving into the next frame mis-attributes the violation reason, which is surfaced verbatim in the AcceptTxResult message. Peeking pc + 1 in the code removes both cases and the mutable field.

4. The post-frame MAX_VERIFY_GAS check is unreachable, so over-budget prefixes are misreported — TransactionProcessorBase.FrameTx.cs:429-449. Because frameGasLimit is pre-capped to remainingVerifyGas and gasUsed is computed off the bounded frame, verifyGasUsed ≤ MaxVerifyGas holds unconditionally and lines 446-449 can never fire. Budget exhaustion always surfaces as "validation prefix frame reverted" / FrameSimulationFailed, so AcceptTxResult.VerifyGasExceeded is unreachable from the simulated path. The existing test's own comment documents the symptom and asserts only TransactionExecuted is false, so it passes either way.

5. Simulate takes no CancellationToken — IFrameTxPrefixSimulator.cs:28. P2P txs reach SubmitTx from Eth62ProtocolHandler.HandleSlow on the BackgroundTaskScheduler, which does hold a token and check it between transactions. A simulation runs up to MAX_VERIFY_GAS of EVM work and can additionally block behind other peers on FrameTxPrefixSimulator._lock (correctly serialized — the env isn't thread-safe — but unbounded in queue depth). None of that is cancellable, and the deferred wall-clock guard has nowhere to attach. Adding the parameter now is one line; later it's a breaking change on public API.

Low

6. FrameTxPayerResolver.Resolve runs twice per frame tx — FrameTxPayerFilter never rejects, so its resolution (including the FrameTxDependencySet the deferred caching phase will need) is computed and discarded. Carrying it on TxFilteringState also lets this filter drop its IReadOnlyStateProvider dependency. FrameTxSimulationFilter.cs:39-45

7. FrameTxPrefixSimulator — missing tx.SupportsFrames guard (a non-frame tx passed to the public interface would run a full transaction with neither Commit nor Restore; currently unreachable, and bounded by the scope reset, but worth validating at the boundary), and it reads the head from IBlockFinder while the pool's filters read state via IChainHeadInfoProvider — two head notions across one admission decision. FrameTxPrefixSimulator.cs:48-59

8. IsTracingReceipt => true on the tracer appears unnecessary — the simulation path calls ReportFrameTxReceipt unconditionally (unlike the main path, which gates on the flag) and never reaches MarkAsSuccess/MarkAsFailed. FrameTxValidationTracer.cs:35

9. An under-funded payer is reported as "frame transaction validation prefix never set a payer". ApplyApproval silently declines to set the payer when balance < MaxCost, so insufficient funds is indistinguishable from a prefix that genuinely never approves payment — and the natively-resolved path reports the same condition as PayerExposureExceeded.

10. Test coverage of the trace rules — the security surface of this PR — is thin: one banned opcode of ~20, and no coverage of the SLOAD scope rule, the GAS/*CALL allowance, the positive TIMESTAMP exemption, or cumulative-across-frames MAX_VERIFY_GAS. Details and a suggested [TestCase] shape are in the inline comment.

Notes (no action)

• The SLOAD-restricted-to-tx.sender rule is spec-correct as implemented — I verified it against the EIP. Worth being explicit that it means a code-carrying paymaster that reads its own storage is rejected at admission, i.e. the headline RequiresSimulation shape only works for storage-free paymasters. Spec-conformant, but a notable consequence to record.
• The 64-frame Eip8141Constants.MaxFrames cap bounds the prefix loop, so zero-gas frames (ExecuteDefaultCode returns gasUsed = 0) can't spin it — the gas bound isn't load-bearing for loop termination.
• Switching ExecuteFrame to ExecuteTransaction<OnFlag> when tracer.IsTracingInstructions is behaviour-preserving for block processing (the non-generic overload is <OffFlag>) and incidentally makes instruction tracing work on frame txs for the first time.
• Skipping the nonce-equality pre-flight is correctly reasoned and documented; CalculateEffectiveGasPrice does not throw for maxFee < baseFee, so low-fee frame txs aren't spuriously rejected.
• _api.Context.ResolveOptional has precedent (StartBlockProducer.cs:29), so the service-location shape is consistent with the codebase.

I could not verify compilation — dotnet build isn't in my allowed tools in this environment, so findings are from reading only. The PR states the Runner builds clean and the suites are green; CI will confirm.
• branch eip8141-mempool-phase2

[github-actions]

EVM Opcode Benchmark Diff

Aggregated runs: base=3, pr=3
Noisy rerun opcodes: PUSH28

Improvements (1)

Opcode	Base Median (ns)	PR Median (ns)	Delta	Abs Δ (ns)	Base CV	PR CV	Threshold	Uncertainty	Effective
MULMOD	933.181	181.550	-80.55%	751.631	2.2%	0.9%	±5.0%	±1.6%	±5.0%

[Marchhill]

Addressed the review findings (commit 3811261).

High — CALL*/EXTCODE* prefixes were silently admitted. Confirmed against the live spec: §Validation Trace Rules L816 rejects CALL*/EXTCODE* "to an address that is neither an existing contract nor a precompile, or to an address that uses an EIP-7702 delegation, except for tx.sender default-code behavior", and L853 permits existing contracts/precompiles. The tracer inspected no call targets, so those prefixes passed clean — the permissive deviation the finding described, not the conservative one the comment claimed. FrameTxValidationTracer now classifies each CALL/CALLCODE/DELEGATECALL/STATICCALL/EXTCODESIZE/EXTCODEHASH/EXTCODECOPY target (read from the operation stack) and rejects it when it is codeless-and-non-precompile or EIP-7702-delegated, exempting tx.sender (already a tracked dependency, covering its default-code behavior). New tests pin both the codeless-target rejection and the existing-contract allow case.

Medium — TIMESTAMP exemption ignored the code. Now checks the EXPIRY_VERIFIER code hash as well as the address (L788), via a new Eip8141Constants.ExpiryVerifierCodeHash; a non-canonical predeploy no longer exempts arbitrary TIMESTAMP code.

Medium — GAS rule leaked across frames. Replaced the cross-frame _pendingGasRequiresCall flag with a peek of the next opcode byte at pc + 1 (GAS has no immediate). A trailing GAS (implicit STOP / following fault) is now caught, and violations are attributed to the correct frame. The mutable field is gone.

Medium — post-frame MAX_VERIFY_GAS check was unreachable. A prefix frame capped to the remaining budget that then exhausts it is now rejected as over-budget (distinct reason) rather than surfacing as a revert; test updated to assert the reason.

Medium — Simulate cancellation. IFrameTxPrefixSimulator.Simulate now takes a CancellationToken (honored at entry; OperationCanceledException propagates rather than being masked as a rejection). Per-frame cooperative cancellation and threading the scheduler token through IIncomingTxFilter remain the documented follow-up.

Build clean (--no-restore -m:1 -tl:off, 0 errors/warnings). Nethermind.TxPool.Test (687 passed, 1 pre-existing skip) and the frame-tx/Eip8141 Evm suites green. The lower-severity findings (duplicate Resolve, IsTracingReceipt asymmetry, head-source divergence, broader banned-opcode coverage) are not in this commit.

[Marchhill]

@claude please re-review the latest changes (High CALL*/EXTCODE* tracer fix at 3811261).

[claude]

Claude finished @Marchhill's task in 7m 40s —— View job

---

Re-review: commit 3811261 (CALL*/EXTCODE* tracer fix + Medium follow-ups)

• Read the new tracer and verify the CALL*/EXTCODE* target rules against the spec
• Verify the TIMESTAMP code-hash check, GAS peek, and MAX_VERIFY_GAS reachability fixes
• Verify the CancellationToken addition
• Review the new tests
• Post findings (2 inline comments)

---

Verdict on the previous findings

#	Finding	Status
1 (High)	CALL*/EXTCODE* silently admitted	Fixed
2 (Med)	TIMESTAMP exemption ignored the code	Fixed
3 (Med)	_pendingGasRequiresCall cross-frame leak	Fixed
4 (Med)	over-budget prefix misreported	Partially — misreport now inverted (see below)
5 (Med)	no CancellationToken	Signature added; enforcement is entry-only
6–10 (Low)	duplicate Resolve, SupportsFrames guard / head source, IsTracingReceipt, under-funded-payer diagnostics, trace-rule test coverage	Open, explicitly deferred by the author

High #1 is genuinely closed. I checked the mechanics rather than the description:

• The stack indices are right — _targetStackIndex = 1 for CALL/CALLCODE/DELEGATECALL/STATICCALL ([gas, address, …]) and 0 for EXTCODESIZE/EXTCODEHASH/EXTCODECOPY, matching NativePrestateTracer.cs:137,149 and TraceStack.Peek's top-down indexing.
• The StartOperation → SetOperationStack handoff is safe: StartInstructionTrace (VirtualMachine.cs:1331) is the sole caller of both and always invokes them together with IsTracingStack true, so _targetStackIndex cannot survive into a different instruction. The stack.Count <= index guard is correct — a stack underflow halts the frame exceptionally and rejects the prefix anyway.
• IsContract before IsDelegatedCode is the right order for EIP-7702 (a delegated account has code), and tx.sender is exempted per the spec's default-code carve-out.
• Both new tests are meaningful: Simulate_PrefixCallsCodelessTarget_RecordsViolation (never-deployed AddressC) and Simulate_PrefixCallsExistingContract_Allowed, which pins the permissive side so the rule can't over-reject.

Medium #2 and #3 are closed, and I verified the two things that could have gone wrong:

• The TIMESTAMP address+code-hash pair closes the residual hole completely. A DELEGATECALL into the verifier's code leaves ExecutingAccount ≠ expiryVerifier → banned; a DELEGATECALL out of the verifier would keep ExecutingAccount but is impossible once the code hash matches, since ExpiryVerifierCode contains no DELEGATECALL. GetCodeHash resolves through IAccountStateProvider's default member (ValueHash256), so the comparison is well-typed.
• The pc + 1 peek is sound, which was not obvious: Nethermind has a second, pre-decoded dispatch loop (VirtualMachine.Stream.cs), and if it were used the pc handed to StartOperation would not be a raw code offset. VirtualMachine.cs:1287 gates the stream on !TTracingInst.IsActive, so an instruction-tracing run always takes RunByteCodeCore, where programCounter indexes stack.Code directly. EOF is not in the tree, so there is no section-relative-pc case either. GAS has no immediate, so pc + 1 is the next executed opcode.

---

New findings

Medium

capped inverts the misreport rather than removing it, because the loop bounds actual gas while the spec bound is on declared gas_limits — TransactionProcessorBase.FrameTx.cs:429-458

capped is derived from the declared limit but selects a reason about consumption, so the comment's invariant ("a frame capped to the remaining budget that then failed exhausted that cap") does not hold. An unrecognized-shape verify frame declaring 5M gas that REVERTs at 3k on a signature mismatch — the ordinary rejection — is now reported as MAX_VERIFY_GAS exceeded. An explicit ShouldRevert should never be attributed to the budget, and IsError isn't a reliable signal either since every exceptional halt consumes all remaining gas.

The root cause is worth fixing rather than patching the discriminator: MEMPOOL-RULES-DESIGN.md:46 records the bound as the sum of declared prefix gas_limit plus signature cost, which is what TryGetValidationPrefixVerifyGas / FrameTxVerifyGasFilter implement — but this loop accumulates actual frameGasUsed under a cap. Since TryGetValidationPrefixVerifyGas returns false for unrecognized shapes (precisely the shapes that reach the simulator), a prefix declaring 5M of verify gas but consuming 40k is admitted here while Direct Evaluation would reject it — the reverse of "Direct evaluation MUST apply the same limits as simulation." Accumulating declared limits and rejecting before execution makes the check exact, reachable, spec-aligned, and drops capped entirely. Suggested diff in the inline comment.

Also: the over-budget test uses SelfVerifyFrame, a recognized shape that FrameTxVerifyGasFilter rejects with VerifyGasExceeded before the simulator runs, so it doesn't cover the path this code actually serves.

Low

Per-frame cancellation is already available for ~4 lines, and would also stop burning budget after a violation — IFrameTxPrefixSimulator.cs:26-31

Honoring the token only at entry covers the moment the simulation is free. The interpreter already polls _txTracer.IsCancelled every 1024 opcodes (VirtualMachine.DispatchSpecialized.cs:62, gated by IsCancelable at VirtualMachine.cs:1256), so overriding IsCancelable/IsCancelled on FrameTxValidationTracer closes the deferred gap outright. Doing it as Violated || token.IsCancellationRequested also fixes a DoS-shaped detail that stands on its own: today a prefix that violates a rule on its first opcode still runs to completion, so each rejected tx costs a full MAX_VERIFY_GAS instead of ~0. The OperationCanceledException already has a handler and the processor's finally restores state, so nothing else moves.

tx.sender exemption and EIP-7702. Exempting sender from the target rules is right per the default-code carve-out, but when the sender is 7702-delegated the prefix's validity depends on the delegation target's code, which the dependency set does not appear to track (only the sender's own code hash, i.e. the designation). Harmless while re-simulation on head change is deferred, worth a line in the EIP8141: follow-up list.

Minor perf note (no action). IsDelegatedCode(Address) loads the target's full code, so an EXTCODESIZE on a 24 KiB contract pulls the whole code during admission. Bounded by MAX_VERIFY_GAS and code-cached; noting only because it's a per-opcode state read on a new path.

---

Still open from the prior review

Findings 6–10 are unaddressed by design, per the author's note. Of these, #10 is the one I'd still push on: the CALL*/EXTCODE* rule now has both a positive and a negative test, but the SLOAD-restricted-to-tx.sender rule (the only thing standing between a code-carrying paymaster and admission), the GAS; *CALL allowance, the positive TIMESTAMP-in-verifier exemption, and cumulative-across-frames gas remain untested, and the banned list still has one opcode of ~20 covered. A [TestCase]-parameterized body over the ban list is roughly the size of the current single test.

Not verified by execution — dotnet build/dotnet test aren't in my allowed tools here, so all of the above is from reading. The PR states the build is clean and the suites are green; CI will confirm.
• branch eip8141-mempool-phase2

[claude]

Claude finished @Marchhill's task in 7m 38s —— View job

---

Review: EIP-8141 Phase 2 — in-pool validation-prefix simulation

• Gather context (diff vs origin/eip8141-frame-txs-devnet7, prior review threads)
• Verify the SLOTNUM ban and the reporting changes in 58960e4
• Cross-check the tracer's ban list against the live EIP text, item by item
• Re-check the simulation path in TransactionProcessorBase.FrameTx.cs against the main path
• Review the TxPool filter, simulator, exposure accounting and wiring
• Post findings (3 inline comments)

---

Last round's High is genuinely closed, and I checked the mechanics rather than the commit message.

• The ban list is now complete. I fetched the published EIP and diffed it against the switch, entry by entry: GASPRICE, BLOCKHASH, COINBASE, TIMESTAMP(cond), NUMBER, PREVRANDAO, GASLIMIT, BASEFEE, BLOBBASEFEE, SLOTNUM, GAS(cond), CREATE, CREATE2, SETDELEGATE, INVALID, SELFDESTRUCT, BALANCE, SELFBALANCE, SSTORE. Every one is covered, and the two deliberate absences hold up: SETDELEGATE is 0xF6, which has no Instruction member and falls to InstructionBadInstruction, pinned by Simulate_PrefixUsesAnUndefinedOpcode_RejectedByTheBadInstructionHalt; the deploy-frame carve-outs are unreachable while the prefix is declined outright. The SLOAD, GAS and CALL*/EXTCODE* rules match the spec wording exactly, including the EIP-7702 clause.
• SLOTNUM is genuinely wired. Instruction.cs:70 defines 0x4B, and the new [TestCase(Instruction.SLOTNUM)] shares the TIMESTAMP body, so the ban is enforced whether or not EIP-7843 is active on the fork under test.
• The default: split is correct as far as the enum goes — Accepted is now reached by name, and both non-accepting arms increment. See Low Feature/jsonrpc #1 for the one way the fall-through can still be reached.
• The AcceptTxResult id shuffle is safe and self-pinning. FrameTxMissingSidecar 24 → 27 dodges KeyedNonceUnmet(24), FrameSimulationFailed(25) and the downstack 26, and AcceptTxResultTests reflects over every declared field and asserts pairwise inequality, so a future collision fails a test instead of silently aliasing two rejections.

Things I re-verified that hold: verifyGasUsed cannot underflow MaxVerifyGas - verifyGasUsed (CapFrameGas bounds the frame, ExecuteFrame computes gasUsed off the bounded one); FrameTxContext is built identically to the main path down to WorldState.GetNonce(sender) and the RecentRootReferences/NonceKeys tail; ORIGIN's relaxation is sound here because both paths set the frame caller to EntryPointAddress for VERIFY, and TLOAD's because ResetTransient() runs at every frame entry on both paths; TraceStack wraps the VM's stack memory without copying, so IsTracingStack => true costs a struct per instruction rather than a stack clone; the payer reservation has no leak path — AddCore settles it in a finally and on the !inserted branch; and the EnterReadLock → Undecided → Accepted chain keeps a node fault out of TxFloodController's disconnect path.

Three findings, all Low. No Critical, High or Medium.

Low

1. Accepted is the enum's zero value, so default(FrameTxSimulationResult) is the exact shape the new default: arm guards against — IFrameTxPrefixSimulator.cs:24. The struct's default carries Outcome == Accepted, Payer == null, which the filter turns into an admit with a null payer, no reservation and no counter — silent in exactly the way 58960e4 set out to prevent. Reordering so Undecided is zero closes the class rather than the instance.

2. The node-fault warn latch is never released — FrameTxPrefixSimulator.cs:92. Once one transient fault fires, every later fault logs at Debug for the rest of the process, so a genuinely systemic outage hours later is invisible at Warn. Clearing the flag on a successful simulation makes it once-per-episode, which is what the comment describes. One line, already inside the lock.

3. The new counter is a property, so it can only be bumped with a racy ++ — Metrics.cs:73. FrameTxPayerExposureFilter, in this same diff and the same filter chain, is declared as a field specifically so it can use Interlocked.Increment, with a comment saying the head read lock does not serialize submitters. That reasoning applies here verbatim, and this is the counter whose own description calls it the signal that payer exposure has stopped being accounted for.

Notes (no action)

• Still open, previously acknowledged with rationale and not re-raised as findings: the plain lock in FrameTxPrefixSimulator.cs:50 (the Monitor.TryEnter bound lands in the follow-up), the deploy-frame carve-out gap, the duplicate FrameTxPayerResolver.Resolve, the IBlockFinder vs IChainHeadInfoProvider head source, the missing tx.SupportsFrames guard on the public interface, and the token-less Simulate(tx) call site. On the lock: I read "so the simulator has to bound its own wait" as an obligation on the simulator rather than a claim that it already does, so I'm not re-filing it as a contradicting comment — but that reading is doing some work, and a reader who takes it as a statement of fact would be misled.
• PrepareValidationPrefixSimulation skips the main path's IsEip8250Enabled / IsEip8272Enabled / references.Length gates. Not reachable: FrameTxNonceKeysTxValidator and the 8272 reference validator (TxValidator.cs:246,277) both run pre-hash, before any filter can call the simulator. Worth knowing the guard lives upstream rather than here.
• The atomic-batch approval-scope sweep the main path runs over all frames is also absent, but the prefix loop rejects any IsAtomicBatch prefix frame and breaks at the first non-VERIFY one, so the "approval scope after a batch frame" shape can never be entered.
• Simulate_PricesTheApproveGateOnTheSameBudgetExecutionEscrows gets its -1 delta via maxGas + (ulong)(long)(-1) wrapping. Correct, and the two-case shape (floor covered / one wei short) is a good pin on the EIP-7623 fix — just an unusual way to spell maxGas - 1.
• InitializeBlockchainAuRa.CreateTxPool still builds its own pool with no simulator, so AuRa keeps the unwired path.

Not verified by execution — dotnet build/dotnet test need approval I don't have in this environment, so everything above is from reading plus fetching the EIP text. The PR reports the suites green; CI will confirm.
• branch eip8141-mempool-phase2

[wurdum]

The finding identified out of the scope of the changed files:

FrameTxVerifyGasFilter sits at TxPool.cs:193, several filters ahead of FrameTxSimulationFilter at TxPool.cs:218, and prices admission with ValidationWorkGas, whose fallback counts every frame when no grammar matches. A transaction of [verify gas=100k, execution gas=500k] sums to 600k and is dropped as FrameTxVerifyGasTooHigh before the simulator is consulted, although the simulation would price only the leading verify frame and resolve a payer. The unrecognized-shape class is therefore admissible only when its entire frame list fits under FrameTxMaxVerifyGas, which excludes anything carrying a normal execution body.

int counted = RecognizedPrefixLength(frames, transaction.SenderAddress) 
    ?? LeadingVerifyFrameCount(frames);

private static int LeadingVerifyFrameCount(TxFrame[] frames)
{
    int i = 0;
    while (i < frames.Length && frames[i].Mode == TxFrame.ModeVerify) i++;
    return i;
}