A Sept. 5 proposal for EIP-8141, Ethereum's proposed Frames transaction design, would convert the existing 100,000-gas validation maximum into a shared floor. Submitted by contributor AnkushinDaniil, the change would require nodes to propagate qualifying transactions within that allowance while allowing capable nodes to accept more expensive transactions locally. The proposal remains under review. The approach faces a significant privacy-proof cost gap. A Sept. 2 benchmark by mmjahanara measured an optimized Groth16 proof verifier at 190,628 gas, including 181,000 gas for its cryptographic pairing check. The benchmark modeled minimum costs of 211,828 gas for a single-note spend and 351,828 gas for an eight-note spend, including estimated overhead and 20,000 execution gas per nullifier, an identifier preventing a note from being spent twice. The benchmark has not been independently rerun by CryptoSlate, and its accounting differs from the companion EIP-8250 draft, which places fresh nonce keys under state gas rather than execution gas. The figures therefore describe the benchmark's model rather than verified costs under the latest combined proposals, although the reported verifier cost still exceeds the proposed allowance. The benchmark author recommends at least 250,000 gas for typical optimized transactions, a level that has not been adopted and remains below the modeled eight-note total. The model also assumes moving non-verification work into later Frames, optimizing verifiers and compressing proof inputs; its SHA-256 compression option increases proof-generation work on users' devices. For Tornado Cash and RAILGUN designs, replacing off-chain relayers with public submission would require proofs that nodes accept and relay. Even with a larger allowance, EIP-8250 would retain a limit of one pending public-mempool transaction per sender, while EIP-8141's local or private-mempool flexibility remains separate from block validity. Informational EIP-8369 outlines future transaction-inclusion rules, including for custom or direct submissions, but requires a binding protocol extension. The central design question is how to support privacy-proof validation while limiting node workload and denial-of-service exposure.