Beyond the 100M Gas Milestone: EIP-7928, Flashblock Access Lists, and the Real State of High-Throughput Trading on Base

Anyone building execution infrastructure for token launches on Base has felt the ground shift over the past year. Block space that used to be a hard constraint on batching strategy has loosened dramatically, a major Ethereum L1 upgrade aimed at parallel execution is working its way through devnets, and Base has started shipping its own independent upgrade cadence at a pace few L2s can match. It's a good moment to separate what's actually live from what's still on a roadmap slide — because for anyone architecting multi-wallet execution strategies around frfr.fun launches, the two are easy to conflate, and the gap between them changes what's worth building today.

This piece covers three things: the actual mechanics of EIP-7928 (Block-Level Access Lists) and where it stands in Ethereum's Glamsterdam upgrade, Base's real gas-limit trajectory and its own in-progress adaptation of BALs, and the gas-cost math that governs batched micro-buy execution against a bonding curve today, with what would change once block-level pre-warming actually ships.

1. The EVM's Serial Execution Problem

The starting problem hasn't changed and is worth restating plainly: EVM clients have historically executed transactions one at a time because they can't know in advance which storage slots a transaction will touch until it actually runs. Two transactions hitting the same liquidity pool can't safely run in parallel without a way to predict, ahead of execution, whether they'll conflict. That unpredictability is what has kept validators and block builders doing sequential disk reads and sequential execution, even on hardware that could otherwise run many threads at once.

Ethereum's answer to this is EIP-7928: Block-Level Access Lists (BALs). The proposal has real technical substance and a clear home on the roadmap, so it's worth being precise about it rather than treating it as already-shipped infrastructure.

2. What EIP-7928 Actually Is — and What It Isn't Yet

EIP-7928 requires block builders to attach a structured, deduplicated record of every account and storage slot touched during block execution, along with the resulting post-execution values. Unlike EIP-2930's optional, transaction-scoped access lists, a BAL is enforced at the block level and validated against the actual execution trace — if the declared access list doesn't match what the block really touched, the block is invalid (source: Ethereum Improvement Proposals, EIP-7928 specification, eips.ethereum.org). This is what unlocks parallel disk reads, parallel transaction validation, and — for stateless or partially stateless clients — executionless state updates.

EIP-7928 is one of two headline proposals in Ethereum's Glamsterdam hard fork, alongside EIP-7732 (Enshrined Proposer-Builder Separation). As of late June 2026, Glamsterdam reached its final devnet stage, locking in the bundle of EIPs — including BALs — that core developers expect to carry through public testnets to mainnet activation (source: The Defiant, June 17, 2026). But "final devnet" is not "live." Ethereum Foundation devops engineer Parithosh Jayanthi described this stage as the point before hardening and testnet shipping even begins, calling Glamsterdam probably the largest fork since the Merge (source: SpotedCrypto, June 16, 2026, citing CoinDesk). Multiple trackers place mainnet activation in the second half of 2026, with Q3 as an optimistic base case and no locked date as of this writing — the schedule has already slipped once, from an original mid-2026 target (source: Everstake, May 2026; SpotedCrypto, June 2026).

Bottom line: EIP-7928 is real, has cleared a major technical milestone, and is not live on Ethereum mainnet as of August 2026. Anyone budgeting engineering time around it should treat H2 2026 as a target, not a date.

3. Base's Gas Limit Didn't Stop at 100M — It Blew Past It Months Ago

Here's the more important correction for anyone building on Base specifically: framing "100M gas" as an upcoming milestone is already out of date. Base crossed that threshold in 2025 and has kept scaling aggressively since.

The timeline, pieced together from Base's own engineering blog and coverage of its announcements:

Mid-2025: Base ran at roughly 75 Mgas/s before beginning a steady series of scaling increases (source: Base Engineering Blog, "Scaling Base: Doubling Capacity in 30 Days," October 2025).
November 6, 2025: Base founder Jesse Pollak announced an increase from 100 to 125 Mgas/s, with a stated year-end target of 150 Mgas/s (source: Coinspeaker, November 6, 2025).
December 18–19, 2025: Base raised its block gas limit to 375 million gas per block, a roughly 25% burst-capacity increase, alongside a minimum base fee adjustment (source: MEXC News / RootData, December 19, 2025).
Base's own stated target for early 2026 was 400–500 Mgas/s, contingent on the TrieDB database rework delivering faster state reads (source: Base Engineering Blog, October 2025).
As of the current Base documentation, the full block gas budget stands at approximately 400 million gas, with the first Flashblock carrying roughly 40 million gas of that budget (source: Base Documentation, "Throughput and Limits," docs.base.org, accessed August 2026).

So the honest framing isn't "Base is racing toward 100M gas" — it's that Base left the 100M mark behind by roughly Q4 2025 and is now operating at 4x that figure, on a chain that has also been shipping independent named upgrades roughly monthly:

Azul (Base's first fully independent upgrade, no longer tied to shared OP Stack release cycles) activated on mainnet May 28, 2026, two weeks later than its original May 13 target. It introduced the EIP-7825 per-transaction gas cap discussed below, a new multiproof withdrawal system combining TEE and ZK proofs, and Osaka-era opcode repricing (source: CryptoTimes, May 29, 2026; Base Engineering Blog, "Introducing Base Azul").
Beryl activated June 25, 2026, shipping the B20 native token standard (a chain-level token format built as Rust precompiles rather than Solidity contracts), a reduced withdrawal window, and a Reth V2 client upgrade (source: Base Engineering Blog, "Introducing Base Beryl"; CryptoBriefing, July 2026).
Cobalt, targeted for September 2026, is expected to bring native account abstraction, expanded B20 functionality including gas payment in B20 tokens, and a unified node binary (source: CryptoBriefing, June 2026; Chainstack, "What is B20?").

The one confirmed fact from the draft: the per-transaction gas cap

One number from the original brief holds up exactly: as of the Azul hardfork, Base enforces a protocol-level per-transaction gas maximum of 16,777,216 gas (2^24) via EIP-7825, rejecting any transaction that specifies a higher gas limit during block validation. Base adopted this specifically to maximize equivalence with Ethereum L1's own EIP-7825 cap (source: Base Documentation, "Execution Engine — Azul," docs.base.org). Deposit transactions are exempt, capped instead at 20,000,000 gas — the maximum includable in an L1 block. This means the structural constraint the original piece described — that no single transaction can carry an entire batch of thousands of micro-buys — is accurate and still binding today.

4. Base's Own Access-List Effort: Flashblock Access Lists (FAL) — Not EIP-7928 Itself, and Not Yet Live

This is the most significant correction to make. The original draft treats EIP-7928 as something Base is already implementing. That's not quite right on two counts.

First, Base isn't adopting L1's EIP-7928 verbatim — it's building its own adaptation. Base's engineering team, working with OP Labs, has been exploring Flashblock Access Lists (FAL), described as "an adaptation of EIP-7928 for OP Stack chains that produce Flashblocks," aimed at the same goal — parallel disk reads, parallel transaction validation, and executionless state updates — but shaped around Base's 200ms Flashblock cadence rather than Ethereum's 12-second slot time (source: Base Engineering Blog, "Scaling Base: Doubling Capacity in 30 Days," October 2025). A technical specification for FAL exists and is documented alongside Base's Flashblocks reference material (source: BaseHub integration guides, accessed August 2026).

Second, and more importantly: FAL has not shipped, and it's slipped out of Base's own recent roadmap at least once. It was explicitly listed as a target for Base's "end of June 2026" upgrade — which became Beryl — alongside an enshrined token standard and Glamsterdam-aligned EIPs (source: Base Engineering Blog, "Introducing Base Azul," April 2026; Bankless, May 29, 2026). But when Beryl actually activated on June 25, 2026, it shipped only the B20 token standard, a shorter withdrawal window, and the Reth V2 client — Flashblock Access Lists were not included, and one contemporaneous analysis flagged this explicitly, warning readers not to assume roadmap items automatically ship on a given activation date (source: SpotedCrypto, "Base Beryl Upgrade," June 20, 2026). Coverage of the subsequent Cobalt upgrade target (September 2026) lists native account abstraction, expanded B20 functionality, and a unified node binary — but no confirmed FAL ship date has surfaced in available reporting as of this writing.

Practically, this means: there is currently no live block-level or Flashblock-level pre-warming mechanism on Base. Every micro-buy transaction against a bonding curve today pays the full EIP-2929 cold-access tax independently, exactly as it always has. The gas savings modeled in Section 6 below are a projection of what FAL or L1 BALs would unlock once live — not a discount available today.

5. What Still Governs Gas Costs Today: EIP-2929's Cold/Warm Access Rules

Absent block-level pre-warming, the constants that determine batch execution cost are the same EIP-2929 access costs that have applied since Ethereum's Berlin hard fork, and Base inherits them as an EVM-equivalent chain:

Cold account access: 2,600 gas
Cold SLOAD: 2,100 gas
Warm SLOAD: 100 gas
Base transaction cost: 21,000 gas

These are protocol-level constants, not frfr.fun-specific figures, and they apply identically to any EVM contract interaction on Base today.

Illustrative gas math for a bonding-curve micro-buy

The following walks through per-transaction gas cost for a token swap touching a small number of storage slots (a bonding curve's reserve variables plus a recipient's balance). This is a generic illustration of EVM gas mechanics, not a measurement of any specific frfr.fun contract:

Per transaction (cold access, no pre-warming — i.e., today's reality on Base):

$$21{,}000 \text{ (base)} + 2{,}600 \text{ (cold account)} + 6{,}300 \text{ (3× cold SLOAD)} + \approx 35{,}000 \text{ (execution)} = \approx 64{,}900 \text{ gas}$$

For a batch of 100 such micro-buys, each paying the cold-access tax independently: ≈ 6,490,000 gas.

Projected cost if block-level or Flashblock-level pre-warming (EIP-7928 / FAL) is live, and the target contract and storage slots are warmed once at the block-context level:

$$21{,}000 + 100 \text{ (warm account)} + 300 \text{ (3× warm SLOAD)} + \approx 35{,}000 = \approx 56{,}400 \text{ gas}$$

For the same batch of 100: ≈ 5,640,000 gas, a savings of roughly 850,000 gas, or about 13% — but again, this is a projection contingent on infrastructure that does not exist on mainnet yet, on either Ethereum L1 or Base.

6. Illustrative Architecture: A Batch Router Contract

The pattern below — a single contract that loops over an array of target calls and executes them in one transaction, each call routed to a bonding-curve buyToken function — is a standard, publicly documented batching pattern used across EVM chains; it isn't specific to frfr.fun and isn't drawn from any frfr.fun source code. The specific storage slot numbers (virtualEthReserves at slot 1, virtualTokenReserves at slot 2, a balanceOf mapping at slot 4) are illustrative placeholders for explaining the mechanic, not a confirmed layout of any deployed frfr.fun contract. frfr.fun's actual bonding curve storage layout is not publicly documented or verifiable through third-party sources, so readers should not treat these slot numbers as accurate for real contract interaction.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.26;

/**
 * @title IllustrativeBatchRouter
 * @notice Generic example of a multi-call batch router pattern for EVM bonding-curve
 *         contracts. Storage slot numbers referenced in comments are illustrative
 *         placeholders, not a verified frfr.fun contract layout.
 * @dev Per-transaction gas is bounded by Base's protocol-level cap of 16,777,216 gas
 *      (EIP-7825, live since the Azul hardfork), so batches spanning many micro-buys
 *      must still be split across multiple transactions within a block.
 */
interface IBondingCurve {
    function buyToken(address recipient, uint256 minTokensOut) external payable returns (uint256 tokensBought);
}

contract IllustrativeBatchRouter {
    address public immutable owner;

    error ExecutionFailed(uint256 index, bytes reason);
    error Unauthorized();

    struct MicroBuy {
        address targetContract;
        address recipient;
        uint256 amountInWei;
        uint256 minTokensOut;
    }

    modifier onlyOwner() {
        if (msg.sender != owner) revert Unauthorized();
        _;
    }

    constructor() {
        owner = msg.sender;
    }

    receive() external payable {}

    function executeBatch(MicroBuy[] calldata buys) external payable onlyOwner {
        uint256 total = buys.length;
        for (uint256 i = 0; i < total; ) {
            MicroBuy calldata item = buys[i];
            (bool success, bytes memory returnData) = item.targetContract.call{value: item.amountInWei}(
                abi.encodeWithSelector(IBondingCurve.buyToken.selector, item.recipient, item.minTokensOut)
            );
            if (!success) revert ExecutionFailed(i, returnData);
            unchecked { ++i; }
        }
    }

    function emergencyWithdraw() external onlyOwner {
        payable(owner).transfer(address(this).balance);
    }
}

Constructing an actual EIP-7928-style or FAL-style access-list manifest off-chain (as in Rust, using alloy types to enumerate target addresses and storage keys) is a reasonable engineering exercise to have ready — but until BALs or FAL are live on the network you're submitting to, there's no protocol-level mechanism for a builder to actually consume that manifest and pre-warm state on your behalf. Today, submitting an EIP-2930-style transaction access list still only warms state within that single transaction's own scope, not across a batch of separately submitted transactions.

7. Modeled — Not Measured — Throughput Comparison

Any table comparing "legacy calls" against "EIP-7928 access lists" against "FAL access lists" for a hypothetical batch of 1,000 micro-buys is, at this point, a simulated projection based on the gas-cost math in Section 5 — not a benchmark pulled from a running network, because the relevant infrastructure isn't deployed. If you want to include such a table for illustrative purposes, it should be labeled clearly as a modeled projection with the same caveat: real-world figures will depend on final FAL parameters, builder implementation, and whatever gas-repricing changes land alongside Glamsterdam (EIP-8037 and related repricing proposals are still part of that same bundle and could shift the underlying cold/warm constants themselves).

8. Risk and Regulatory Considerations

A few things worth naming plainly, since the original draft treated high-throughput multi-wallet batch buying purely as an engineering optimization problem:

Fairness and platform terms. Routing hundreds or thousands of micro-buys through distinct derived wallets specifically to acquire a disproportionate share of a token's early supply — regardless of the gas-optimization technique used — is a form of automated, coordinated trading that most launchpads' terms of service address in some form, and that other participants in the same launch are unlikely to view as a level playing field. Whether a given platform tolerates, restricts, or prohibits this kind of activity is a platform-specific policy question, not a purely technical one, and frfr.fun's specific policy on bot-driven or Sybil-wallet batch buying isn't something this piece can verify from public sources.

Market-structure and manipulation exposure. Regulators have shown increasing interest in coordinated trading patterns that create a misleading appearance of organic demand, particularly around new token listings. The March 17, 2026 joint SEC-CFTC interpretive release established a five-category taxonomy for crypto assets — digital commodities, digital collectibles, digital tools, stablecoins, and digital securities — clarifying which token types fall outside SEC jurisdiction, but the release is explicitly "descriptive, not determinative": how a token is offered, marketed, and traded can still bring it back into securities-law scope regardless of its underlying technical category (source: Forvis Mazars, March 27, 2026; Phemex Academy, March 2026). Wash-trading-adjacent or manipulative-trading concerns generally fall outside that taxonomy question entirely and are governed by existing anti-fraud and anti-manipulation authority regardless of a token's classification.

Legislative backdrop. The GENIUS Act (signed into law July 18, 2025) governs stablecoin issuance specifically and doesn't touch token launch mechanics. The broader market-structure bill, the CLARITY Act, remains unresolved: as of July 31, 2026, it has passed the House and cleared the Senate Banking Committee but has no scheduled floor vote, no cloture motion, and no date on the Senate calendar; Senate Majority Leader Thune has indicated he doesn't expect a floor vote before the chamber's early-August recess (source: Disruption Banking, July 31, 2026). Treat any framing of CLARITY as imminently resolved as premature.

None of this is legal advice, and none of it should be read as a claim about frfr.fun's specific compliance posture — it's general context for readers evaluating whether a given execution strategy carries risk beyond gas fees.

9. Conclusion

The two biggest technical claims in the original framing — that Base is racing toward a 100M gas ceiling, and that EIP-7928 is already reshaping execution on the network — both needed correction. Base passed 100M gas months ago and now runs at roughly 4x that figure per block. EIP-7928 is real, technically serious, and has cleared a major devnet milestone, but it's an Ethereum L1 proposal with no locked mainnet date, and Base's own adaptation (Flashblock Access Lists) has been explored publicly but was dropped from the last upgrade that was supposed to carry it, with no confirmed date since.

What is confirmed and stable: Base's per-transaction gas cap of 16,777,216 gas via EIP-7825, its 2-second block time subdivided into 200ms Flashblocks, and the underlying EIP-2929 cold/warm access costs that govern batch execution economics today. Anyone building execution infrastructure around frfr.fun launches should size their engineering effort against those confirmed constraints — and treat block-level pre-warming as a future unlock worth architecting toward, not a capability to build against today.

Corrections and Transparency Log

Removed all document metadata (title tags, author fields, publishing platform metadata) from the original draft per standard formatting.
Corrected the central premise: the original framed "100M gas limit Base" as an emerging milestone. Current Base documentation and multiple independent reports confirm Base's full block gas budget is approximately 400 million gas as of mid-2026, reached via a series of increases through late 2025 and into 2026 (125 Mgas/s in Nov. 2025 → 375M gas/block in Dec. 2025 → ~400M gas/block currently). The 100M figure is roughly eight months stale.
Corrected the EIP-7928 status claim: the draft implied EIP-7928 was an active part of Base's current infrastructure. In fact, (a) EIP-7928 is an Ethereum L1 proposal targeting the Glamsterdam hard fork, currently in final devnet testing with no locked mainnet date (base case H2 2026, possibly later); and (b) Base is not adopting EIP-7928 directly but developing its own adaptation, Flashblock Access Lists (FAL), which was targeted for Base's June 2026 (Beryl) upgrade but was not included when Beryl shipped, and has no confirmed ship date as of this writing.
Verified as accurate: the per-transaction gas cap of 16,777,216 gas (2^24) via EIP-7825, confirmed live on Base since the Azul hardfork (activated May 28, 2026) via current Base documentation.
Verified as accurate: Flashblock cadence (~200ms sub-blocks within a 2-second canonical block) and the first-Flashblock gas budget of ~40M gas, confirmed via current Base documentation.
Flagged as illustrative/unverified: all specific frfr.fun bonding-curve storage slot numbers (virtualEthReserves, virtualTokenReserves, balanceOf mapping position) are presented as generic pedagogical placeholders, not a confirmed layout of any deployed frfr.fun contract — frfr.fun's contract source is not independently verifiable through public third-party sources.
Relabeled the benchmark table: the original presented specific latency and throughput figures (P99 latency, parallelization multipliers, micro-buys-per-block counts) as if measured. These are modeled projections based on gas-cost arithmetic, not measurements from a running network, since the underlying infrastructure (BALs/FAL) isn't deployed. The rewritten piece keeps the projection but removes the specific unverified latency figures and states plainly that they cannot currently be measured.
Added regulatory context: the March 17, 2026 SEC-CFTC joint interpretive release (five-category token taxonomy), the GENIUS Act's actual scope (stablecoins only), and the current, verified status of the CLARITY Act (passed House, cleared Senate Banking Committee, no floor vote scheduled as of July 31, 2026).
Added a risk/fairness section addressing platform-terms and market-conduct considerations around coordinated multi-wallet batch buying, which the original treated purely as a gas-optimization exercise.
Flagged as unverifiable: any frfr.fun-specific claims (fee structures, platform policy on bot/Sybil trading) are not addressed with specifics because frfr.fun does not appear in independently verifiable third-party sources.