Why
The only verifiable fact in this news is the six-team confirmation. Everything downstream of it — the mainnet timing, the throughput multiple — is conditional, and unusually, the minutes say so themselves. A date being attached and a date being decided are different states, and this is the rare case where the primary source records the difference explicitly. That is what makes the item worth a card: not the schedule, but a clean specimen of how a qualifier gets lost.
The loss has a predictable shape. A testnet slot is precise to the second, which makes it feel authoritative; the deferral clause is a sentence of prose, which does not. Precision travels and qualification does not, so a Sepolia timestamp becomes a mainnet expectation two hops downstream, and the mainnet figures now circulating do not reconcile with one another — which is the tell.
The substance underneath is real and touches this project directly. ePBS (EIP-7732) proposes moving block building inside the protocol, and this catalogue already has a card standing on the outside version of that market: pbs submits bundles as a searcher and watches mev-boost relay auctions. If 7732 lands, that card's subject stops being an out-of-protocol arrangement and becomes part of consensus. BAL (EIP-7928) opens parallel execution, and the two together are what the roughly threefold L1 throughput claim rests on. Read next to quick-slots-10s and l1-data-pricing-dimensions, which change the same substrate along the other two axes.
How it works
The status column that reporting leaves out
| Claim | Status in the primary source | How it travels |
|---|---|---|
| Sepolia fork at 2026-09-28 14:44:48 UTC | Proposed on the call, confirmed by six client teams without dissent | Verbatim — precision survives intact |
| That schedule is settled | Explicitly deferred to the next call | Dropped in the first retelling |
| Mainnet date | Does not exist | Invented downstream; circulating versions disagree |
| About 3x L1 throughput | Conditional on ePBS and BAL both shipping | Repeated as a property of the fork |
| 200M gas target | A final devnet target | Repeated as a mainnet number |
The rule this produces
Record the status, not the number. Every date in a protocol timeline belongs in one of three states — confirmed by named parties, deferred, or circulating without a primary source — and a timeline that only carries numbers has thrown away the one column that decides whether to plan against it. The 9/28 Sepolia slot, the 8/27 Hegotá PFI cutoff and the 9/10 preference-list deadline are three different states of certainty sitting on one line.
Why it is worth doing for a project, not just for reading
Any roadmap that says after the next fork is inheriting the weakest of these states without labelling it. Writing the status column once costs an afternoon and permanently changes what a dependency on an upstream schedule means — and the 200M gas figure is the specific one to watch, because a devnet target repeated as a mainnet number is exactly the shape of the error the table above is built to catch.
Where the date's shape comes from — ePBS buys time, BAL buys partition
The card above is about provenance: a Sepolia slot of 2026-09-28 14:44:48 UTC, confirmed by six client teams without dissent, in minutes that record the decision as deferred to the next call. The second half is why the schedule is shaped this way, and it is a dependency chain rather than a wish list.
- ePBS separates the payload from the beacon block. Execution validity no longer has to be established inside the attestation deadline — a proposer commits to a bid and the payload is checked in a later slot. The scarce resource it releases is wall-clock inside the slot.
- Block-level access lists publish what a block touches before it runs. A node can prefetch state and execute disjoint transactions concurrently. The scarce resource it releases is serial dependency.
They are not two features on one list. They relieve the two different constraints that jointly set how much work fits in a slot, which is why anything that wants more work per slot tends to need both.
The dependency claim is the part to verify at source, not repeat. The reading that EIP-8025 rests on both of these is exactly the kind of statement this card exists to be suspicious of — a plausible relationship, circulating without anyone citing the text. Open the EIP and check whether the dependency is stated there or inferred by the person who wrote the summary. Applying the card's own rule to the card's own sources is the whole point.
What the two levers do give you for free is a test for any mainnet date you see quoted: a mainnet slot is only credible once both levers have a testnet fork behind them, because they are the two that change block production timing. A mainnet number circulating before that has skipped a step, whatever its source.