Part two dissected EIP-8141’s transaction body, and part three walked a Falcon transaction through its life inside the protocol. But a transaction does not live in a vacuum. Around it are hundreds of millions of neighbors who never migrated, people who pay its bills, a relay network it must travel through, a market that decides whether it gets into a block, and a pile of risks that a middleman used to digest quietly. This article is about that world.
The through-line continues the series’ ledger. In the 4337 era, the bundler and EntryPoint, that pair of middlemen, digested five duties: compatibility for codeless users, escrow and settlement for sponsored payment, transaction propagation, block packing, and the absorption of DoS and frontrunning risk. Once 8141 evaporates the middleman, every one of those duties must find an heir. This article is an item-by-item reading of the will: codeless users go to default code, escrow and settlement go to the protocol’s direct debit and refund, propagation goes to a two-tier world of a public-pool covenant plus private channels, packing goes to the builder market, and risk goes to mathematics, discipline, pipeline ordering, and p2p reputation, shared by every node.
The codeless seat: default code
The master rule of frame-transaction authorization is one sentence: did your code execute APPROVE. That design has a built-in hole: what happens when a VERIFY frame lands on a codeless EOA, whose codeHash is the empty hash? There is no code, so who answers? Rule it a failure outright and hundreds of millions of legacy EOAs are locked outside the new world.
Default code plugs the hole. The protocol ships a hard-coded script inside the client; when a codeless account gets VERIFYed, it pretends code is there and answers on the account’s behalf. Answering needs evidence, and in a frame transaction evidence can live in exactly one place, the signature list the transaction carries. The script, in plain words: go to this transaction’s own signature list, look at a fixed seat, and check whether the record there is an ECDSA credential the client has already stamped, whose signer is precisely me, and which signed precisely this transaction; if so, speak APPROVE for this account.
Why must it be ECDSA? This is a necessity of the state model, not a designer’s taste. A codeless EOA at the state layer is [nonce, balance, empty storage, empty code hash]: no storage slots, no registered public key of any kind, no code to interpret anything. The only binding between this address and any key on earth is its birth certificate, the address being the last 20 bytes of keccak of an ECDSA public key. So the only proposition the protocol can check on its behalf is: does some ECDSA signature recover to this account. That is legacy’s ecrecover == sender, untouched, wearing frame-transaction syntax. The old constitutional clause was not repealed; it was demoted to the default template under a general programmable rule: write no code, and the old rules apply. This also completes the reason default code cannot support post-quantum schemes: not stinginess, but logical impossibility, since a codeless account has no storage, a Falcon public key has nowhere to register, and the protocol cannot know which post-quantum key this EOA would even want. To use PQ, install code first. The path of inertia is nailed to ECDSA, and the nail is the state model itself.
The script’s three checks each guard one thing. The scheme must be SECP256K1, the only scheme with a birth binding. The resolved signer must equal this account, the identity equation itself; note the division of labor, default code performs no cryptography at all, since SECP256K1 is a protocol scheme the client already verified for 2800 gas before any frame ran, so default code only compares metadata, asking whether entry i on the list of verified facts is signed by me. And msg must be empty, because authorization must anchor to this transaction; part two showed that an explicit msg only imports a fact, commits nothing to this transaction, and is replayable if relied on alone.
There is also a seating rule. A frame whose flags include execution approval checks index 0 of the signature list; one with pure payment approval checks index 1. Why fixed seats, and why two? Because one transaction can contain two codeless EOAs using default code in two roles at once: the sender approving execution, and another acting as paymaster approving payment. If the two ECDSA credentials fought over one seat, the pattern would be impossible. Fixed seats put each credential in its place, and carry a familiar bonus: full static decidability, so mempools and wallets know which signature goes where and which frame will check what, without executing anything.
Two examples nail the abstraction down. Example one, a codeless EOA paying for its own transfer, which is the true body of the official 139-byte minimal-transaction baseline:
sender = E (codeless EOA)frames = [F0: VERIFY, target=empty(→E), flags=0x3], [F1: SENDER, →B, 1 ETH]signatures = [S0: [SECP256K1, signer=empty(defaults→tx.sender), msg=empty, 65 bytes]]
client verifies S0 first (2800 gas, recovers signer == E)→ F0: E has the empty code hash → default code: scope includes execution → check index 0 → S0: right scheme, signed by E, msg empty → APPROVE(0x3) on E's behalf→ F1 runs with E as caller, transferringWhat is this? A legacy transaction reincarnated in frame syntax. Same key, same cryptographic check, same authorization semantics, new packaging, and new powers thrown in: want batching, append SENDER frames, the signature stays the same single entry. The signer left empty defaults to the transaction’s sender, saving another 20 bytes; 139 bytes was clawed out byte by byte like this.
Example two, a codeless EOA as paymaster:
sender = A (Falcon smart account), payer = P (codeless EOA holding ETH)frames = [F0: VERIFY→A, flags 0x2], [F1: VERIFY→P, flags 0x1], [F2: SENDER…]signatures = [S0: A's Falcon ARBITRARY entry (seat 0), S1: [SECP256K1, signer=P, msg=empty, 65 bytes] (seat 1)]
F0: A has code, its own code verifies Falcon → APPROVE(0x2)F1: P is codeless → default code: pure payment → check index 1 → three checks pass → APPROVE(0x1), payer = PThe seating shows its purpose here: A’s post-quantum credential and P’s ECDSA credential each take their own seat, one approving execution, one paying the bill. P deploys nothing at any point; the most ordinary EOA, through default code, is a competent payer. That paying role deserves a chapter of its own.
The payer’s evolution: three generations of paymaster
Ethereum’s genesis iron law says: every transaction’s gas is paid by the sender, in ETH, at the moment of inclusion. That rule locks three doors. The cold-start paradox: send 100 USDC to a fresh address and the owner “has money” yet cannot move a cent, since transferring needs gas, gas needs ETH, and swapping USDC for ETH itself needs gas; you need ETH to move your money, and you need to move your money to get ETH. Commercial sponsorship is impossible: a game wants to pay for its players, a company for its employees, and the protocol has no grammar for “I pay for him.” And the currency is locked: a wallet full of stablecoins, while gas takes only ETH. The need is plain, let the sender and the payer be two different people; and the whole difficulty of implementing that sentence safely lives in one asymmetry: the one who fronts money pays first, and the transaction succeeds or fails afterward; whoever fronts money stands exposed to being played. Three generations of design are three rounds of wrestling with this asymmetry.
Prehistory was the relayer era. The protocol would not help, so the community routed around it: the user sends no transaction, only signs a message; a relayer wraps the message in its own transaction, submits, and pays the gas; the target contract verifies the inner signature and acts in the user’s name. GSN and its kin tried to standardize the pattern. It worked, and it leaked everywhere: relayers could censor and stall; a user’s message could fail after the relayer had already paid, burning its money; contracts needed special retrofits; and a signed message is not a transaction, so the entire tooling stack was blind to it. The lesson settled into one line: sponsored payment cannot rest on off-chain gentlemen’s agreements; the sponsor’s risk needs an on-chain mechanism underneath it.
4337 made the paymaster a standard role, with a three-piece kit answering one risk apiece, all of which appeared in part one. Deposit escrow: the paymaster first deposits ETH into EntryPoint. Why mandatory? Because 4337’s settler is a contract, and a contract cannot reach into arbitrary accounts to take ETH; it can only dispose of money held with itself, so to guarantee collection, the money must sit with the settler in advance. Two hooks: at validation, validatePaymasterUserOp screens the order (is this user on the sponsorship list, does the op transfer me enough USDC), and after execution, postOp settles the bill; the fronting risk is managed between the two pieces of code. Stake and reputation: a paymaster’s validation is arbitrary code reading shared state, and one state change can invalidate thousands of pending UserOps that depend on it, so 4337 answers with economic governance, deposits, reputation scores, throttling and blacklists. In one line: a contract role plus escrowed funds plus economic punishment, running in a parallel system beside the protocol.
What 8141 does to the paymaster is as radical as what it did to EntryPoint: abolish the role, keep the action. The protocol no longer contains the noun “paymaster,” only an instruction semantics: any account that executes APPROVE inside a VERIFY frame whose flags include the payment bit becomes this transaction’s payer. A contract can, a smart account can, and the bare EOA from the previous chapter can. Around this one utterance, the three-piece kit is replaced item by item by protocol primitives.
Escrow disappears. Look back at the root: 4337 needed escrow because its settler was a contract that could not reach other people’s wallets; 8141’s settler is the protocol itself, and the state-transition function obviously has the power to debit any account directly. What it ever lacked was not capability but authorization, and APPROVE(0x1) is the authorization. The money flow straightens into a line:
pay frame APPROVE(0x1) → protocol pre-deducts the maximum cost from the payer→ frame loop completes → unused gas refunds straight to the payerNo intermediate account, no after-the-fact recovery, nobody fronting anything; the builder packs the transaction without advancing a cent. The protocol is its own escrow agent, so escrow as a mechanism evaporates. The two hooks change form: screening becomes the pay frame, now wielding the tool from part two, cross-frame introspection, so the payer’s code can check the contents of later frames on the spot, confirming “frame 3 really does transfer me 5 USDC” before nodding; settlement becomes the post_op frame, placed after the user’s frames, beyond the payment line, bound by no prefix rule at all, so the settlement logic can be as complex as it likes. A frame-order iron law backstops the logic: the payment-approval guard requires that the sender has already approved execution, so what the payer reviews is always a transaction the user has authorized and whose content is frozen; there is no “approve the money, then he edits the order.”
Stake and reputation are deleted wholesale, replaced by a purely structural two-tier governance. Delete economic governance and the old problem walks right back in: a payer’s balance is shared state, and one transfer can void a pool of transactions that depend on it, part one’s invalidation attack in a new coat. 8141 answers on two tiers. The canonical paymaster is the first-class citizen: the spec anoints one implementation’s bytecode, and any account whose runtime bytecode matches it byte for byte counts as canonical; not a singleton, but “the same model.” The reason to recognize bytecode is that this code makes a machine-verifiable promise to nodes, funds leave by exactly two exits, paying transaction fees or a time-locked withdrawal. With that promise, nodes dare to run reservation accounting:
available = on-chain balance − maximum costs reserved for other pendings − withdrawals inside the time lockadmission: available ≥ this transaction's maximum costThe balance cannot be quietly drained (the time lock buys nodes reaction time), reservations cannot oversell, and one canonical paymaster can back arbitrarily many pendings at once. Non-canonical is the second class: any other contract, or a bare EOA; nodes cannot read an arbitrary program’s promises about money, so they keep no books and simply cap the blast radius, at most one pending network-wide per such payer. The change of governing philosophy is plain: 4337 managed bad actors with economics, deposits, reputation, blacklists; 8141 prevents bad outcomes with structure, either bytecode identical enough that nodes can keep your books, or constrained until you cannot hurt anyone. Part one called the protocol’s two weapons shackles and collateral; by 8141, even the collateral weapon has been recast as a code wall.
A few boundary lines of this two-tier world are worth writing down. The fully on-chain trustless ERC-20 sponsorship pattern, a pay frame that introspects “the next frame pays me in tokens” before approving, must read the token contract’s balance, stepping outside the public pool’s rule of touching only the sender’s own storage; so it is consensus-valid but declined by the public pool, stuck in the same mezzanine as post-quantum transactions. What walks through the public gate is the canonical paymaster’s off-chain pre-signed sponsorship. The race between approval and inclusion, where a user front-runs to drain the ERC-20 they promised, is assigned by the spec to the sponsor’s own account, mitigated by off-chain screening, allowlists, and post_op settlement; a business problem, not underwritten by the protocol. And three post-quantum gaps: the current draft’s canonical implementation authorizes with ecrecover, so the official sponsorship track carries a quantum gap of its own; a post-quantum paymaster that wants Falcon to authorize its sponsorship decisions pays that pay frame’s gas out of the hundred-thousand prefix budget, hitting the same wall as a post-quantum sender; and an EOA sponsoring through default code speaks only ECDSA. On the migration-completeness checklist, the sponsorship path needs its own tick.
The chapter closes in one line: the same knot, how the one who fronts money avoids being played, sinks layer by layer, first into a standard (GSN), then into a contract (4337’s kit), finally into the protocol itself (direct debit and refund plus structural constraint); the mark of hitting bottom is that paymaster vanishes as a noun, leaving only the one utterance any account can make, APPROVE(0x1).
Commons and back roads: the truth about mempools
Twice above we said “declined by the public pool, private channels only.” To really understand that sentence, first demolish an illusion.
Consensus rules adjudicate exactly one thing from start to finish: blocks. What a valid block is, and what counts as a valid transaction inside one. How a transaction travels to the block producer, the protocol does not regulate with a single word. The so-called mempool is not an on-chain object or a global data structure; it is each node’s own waiting room, a patch of local memory holding transactions the node thinks might land in a block and are worth waiting on. The “public mempool” is a phenomenon that emerges when thousands of waiting rooms forward to each other over gossip: no boundary, no single state, no authoritative version.
Then what are the pages of mempool rules in the 8141 spec? The commons’ covenant of self-protection. The predicament of public gossip is that you relay transactions for strangers, free of charge, spending memory and bandwidth and possibly a round of simulation, with no guarantee the transaction lands or pays you anything. So every hop must judge, at rock-bottom cost, whether this parcel is worth carrying. The covenant is therefore necessarily conservative and necessarily statically decidable: four prefix shapes recognizable without executing code, the hundred-thousand-gas hard budget capping free computation, banned environment instructions keeping a simulation’s verdict valid tomorrow, one sender one slot capping seat occupancy. These rules never constrain “whether the transaction is valid”; they constrain the cost ceiling of speculating on a stranger’s behalf.
Why may private channels ignore the covenant? Because the trust topology changes, and with it the bearer of speculative risk. Hand that 2.1M-gas Falcon transaction directly to a builder: the party burning two million gas of simulation for you is exactly one, and happens to be the one who collects, since if the transaction lands the builder eats your fee. That is an economic bet it can price for itself, win or lose, with no third party conscripted into subsidy. Contrast the public pool: the same transaction would make thousands of nodes, unrelated to you and never paid by you, each simulate, store, and re-verify block after block; what the covenant refuses is precisely this socialization of cost. Private channels are no lawless zone either; builders run their own admission, minimum fees, client relationships, per-identity throttling. The DoS surface does not vanish, it is internalized to a counterparty capable of pricing it.
And why do covenant-breaking transactions still land on chain? Because the chain has exactly one compulsory gate, block validity. A builder may pack any consensus-valid transaction into a block, and verifying nodes ask only whether the state transition is correct, never how the transaction once traveled or whether it honored the gossip covenant. The postal analogy gathers it up: the covenant is the postal service’s parcel standard, letting every sorting office handle at low cost; a private channel is driving the parcel to the recipient’s door yourself, since the parcel standard binds the postal network, not the road; block verification is customs, the single gate everyone passes, checking authenticity, not the mode of transport. Three tiers line up: local, your own node’s waiting room reached by RPC, where the trust is in the operator; private, builder and order-flow relationships, the Flashbots lineage; public, the gossip commons. The two-tier world is not 8141’s invention, a sizable share of mainnet transactions already travels private order flow, and 4337’s alt-mempool is itself a parallel gossip network with its own covenant. 8141’s contribution is to write the boundary down as a spec constant (100000) for the first time: “which transactions can never walk through the front gate” turns from ecosystem bargaining into a computable proposition.
The block market: chance picks the person, economics picks the block
The terminus of a private channel is the builder, which belongs to another market, block production, an architecture called PBS, proposer-builder separation, running today in the form of MEV-Boost. Nail one thing down at the door: none of this architecture lives in the consensus protocol; like the mempool, it is market infrastructure grown alongside, and consensus recognizes exactly two things, validators and valid blocks.
Four roles populate the market. An ordinary full node runs standard clients, takes transactions from public gossip, keeps a waiting room, verifies every block, holds no stake, and never produces a block. A validator, the proposer, is a full node plus stake, proposing a block when drawn. A builder runs a modified client whose transaction sources include gossip plus private order flow, direct RPC endpoints, searcher bundles, exclusive flows, and uses proprietary algorithms to construct value-maximized blocks, then bids to sell them to proposers. The relay is the mutually distrusting notary between builder and proposer: it verifies the block, holds it in escrow, and shows the proposer only the header and the bid. The precise answer to “is everyone running the same client”: the verifying half is identical for everyone, necessarily, or you fork yourself off the chain, and the relay too runs full verification so it can warrant to proposers that the bid stands on a real block; the building half is a free market, since consensus defines what block is valid, not how to build one, and the default building algorithm shipped in clients, greedy filling by priority fee, is merely the market’s plainest contestant.
A slot’s twelve seconds go like this. RANDAO draws the slot’s proposer by stake weight, and this is the only moment of randomness in the whole pipeline. The drawn proposer has two options: build locally, using its own waiting room and the default algorithm, or ask relays for bids, take the highest, and blind-sign the header, with the relay releasing the full block body and broadcasting on its behalf only after the signature. Blind signing is a compact piece of trust engineering: the builder dare not hand the whole block over first, lest the proposer unbundle and steal its MEV strategies; the proposer dare not trust a hollow bid, since the block must be real and the money must arrive. The relay, chosen by both, verifies, escrows, and warrants the bid, buying liquidity for a mutually distrusting market at the price of one trusted third party, which is why it is also the centralized link on the critical path of block production; ePBS (EIP-7732) aims to protocolize this link too, the next stop of the protocolization wave.
Now the key intuition fix: consensus randomly picks the person, not the block. The drawn proposer faces a comparison problem, local block value versus highest bid, and takes the larger. So the ratio of public to private blocks is not a probability distribution but the statistics of hundreds of thousands of economic decisions, and it leans hard to one side year round: about nine in ten mainnet blocks come from builders, the precise share drifting month to month. Four reasons stack up. From the same pool of public transactions, a builder’s reordering can squeeze out arbitrage and liquidation value that local greedy filling cannot, same ingredients, different block value. More structural is the visibility gap: transactions in private order flow simply do not exist in a local waiting room, not declined but never seen, and exclusive order flow routes large wallet volumes to particular builders. Competition among builders hands most of the extracted value over as bids, so a proposer need not understand MEV, only how to compare two numbers. And the superset relation: a builder’s block typically contains the public transactions a local block would carry, plus the private increment, weakly better on nearly every axis. The remaining tenth has names too: some proposers set a minimum bid out of censorship-resistance conviction, preferring to self-build below the threshold, and occasional relay failures fall back to local. One more reality goes on record: the builder market is highly concentrated, with the top two or three eating most of the share for long stretches. The right to propose is nominally spread across hundreds of thousands of validators; the power to build has practically converged into single-digit hands, the bull’s-eye of Ethereum’s contemporary centralization debate.
Back to the Falcon transaction, whose fate can be written as an equation: inclusion probability ≈ the combined market share of builders willing to accept and process it × those builders’ bid win rate. The good news: nine in ten blocks already come from builders, so private-only delivery is no death sentence for throughput, and whether a builder will spend two million gas simulating your verification is a business it can price itself, say by requiring a higher tip. The bad news is structural: the transaction’s censorship resistance degrades from “any one benevolent node among thousands on gossip” to “whether anyone on an oligopoly’s list takes the order.” And one more edge to grind: FOCIL (EIP-7805), the censorship-resistance heavy weapon Ethereum is about to deploy, cannot protect it. Inclusion lists work by letting randomly drawn validators force-include transactions that the public mempool has been neglecting; a post-quantum frame transaction never enters the public pool, so it is outside the sourcing range. Protection designed for the commons naturally cannot shine on those who are not standing on it.
Close the chapter with a trichotomy and a funnel. Verification is a consensus duty, identical for all, asking only validity, never origin. Building is a free market, where the default algorithm is the weakest contestant. Selection is an economic act, highest bid wins, and nine-tenths going to builders is a market outcome, not a protocol rule; the only randomness in the whole journey is the instant RANDAO draws the person. Part two’s closing line, that the consensus-valid set strictly contains the publicly-propagatable set, now completes into a three-layer funnel: consensus-valid (customs, always open) ⊃ someone willing to pack (the builder’s business) ⊃ publicly propagatable (the gossip covenant). The post-quantum transaction is stuck at the third layer, lives by the second, and the first gate stands open to it forever.
Three relocations of risk
The first risk the middleman used to digest, speculating on strangers’ transactions, has been rehoused over the last two chapters: it went to the builder, voluntary and paid, which is the entire origin story of the two-tier pools. Two seams remain, exactly the ones the spec’s security-considerations section stares at.
The first is deploy frontrunning. Part three noted that the deploy frame must run before authentication, for chicken-and-egg reasons: authentication runs the account’s code in a VERIFY frame, and a counterfactual new account has no code yet, code arrives by the deploy frame. So a glaring fact cannot be dodged: at the moment the deploy frame executes, nobody in the world has proven anything yet. What protects you is mathematics: the address’s commitment to the initcode, address = f(factory, salt, keccak(initcode)), change one byte of initcode and you compute a different address. An attacker cannot, mathematically, install other code at your address; the only thing he can do is get there first, with the identical initcode, and install exactly what you were going to install at exactly your address, doing your work for free. So the attack is a trip, not a robbery: after his preemptive deployment, your transaction’s deploy frame lands on nothing and the whole transaction is rejected, but your assets face zero risk, the code at the address is precisely what you wanted; you lose one round trip, and he paid the deployment gas. The spec hands wallets a resend discipline: on detecting that your address already has code, drop the deploy frame and resend.
But “safe for anyone to deploy on your behalf” is a discipline, not an automatic property, and that is what this security consideration actually nails down. A counterexample takes one second: initcode that writes owner = msg.sender, or reads the owner from mutable external state. The address has not changed, an address commits to initcode bytes, not to their execution result; but the state installed has changed, the frontrunner became the owner. The disaster is that the standard play for counterfactual accounts is precisely to hand out the address for deposits first and deploy later; six months of deposits, and then an attacker deploys a wallet whose owner is him. The full discipline: initcode must be deterministic and parameter-complete, the owner’s public key burned into the initcode bytes, depending on no caller and no environment. That is also the precondition for “an address can commit to its owner” to hold at all. The whole package is 4337’s counterfactual-deployment discipline reincarnated at protocol level, with EIP-7997 standardizing the factory half as a predeploy.
The second seam is read amplification. Set the reference frame first: why is legacy garbage cheap to expose? Because identity is recovered from the signature. A garbage transaction costs a node one ecrecover, tens of microseconds of pure CPU with zero state access, recovering a random address, followed by one shallow state read. The key property: the attacker cannot choose whose state the node reads. 8141 loosens that defense on two axes at once. Axis one, identity moves from recovered to declared: sender is a plaintext field, so the attacker reads whomever he writes, naming real accounts with huge state, or enumerating a million distinct addresses to punch through the cache, turning every probe into a cold database read. Axis two, authorization moves from stateless to stateful: a frame transaction carrying only ARBITRARY entries has no stateless cryptographic gate at all, the structural checks pass (customs reads the manifest), while the answer to “is it authorized” lives in state, the codeHash, the code, the storage, up to a round of prefix simulation. The amplification inequality stands: the attacker’s cost is roughly network bytes; the defender’s cost is roughly database reads. The inequality existed in 4337 already, a UserOp has a declared sender too and is exposed by simulation too, but the bearer then was the bundler, few, professional, paid, and free to choose clients, a closed group able to price its own risk; 8141 deletes the middleman and socializes the burden to every full node’s txpool.
Two mitigations each have a clear logical station. Pipeline ordering: every stateless check goes first, type dispatch, RLP shape, flags, fee rates, protocol-scheme signature verification, with state reads always the last gate; this is filter economics, let the cheapest sieve eat the biggest flow, and let the expensive sieve see only survivors. Peer-layer throttling and scoring: transactions are anonymous and free to forge, but p2p connections have identities, so a peer that keeps feeding garbage that passes static checks and dies at state checks gets throttled, downscored, disconnected, pushing cost back along the only anchor that has an identity. One-sender-one-slot and nonce adjacency squeeze the probing space of any single account from the side. The four-rung DoS ladder then lines up: garbage that dies at static checks is nearly free; garbage that forces state reads is suppressed by ordering and reputation; whatever enters prefix simulation is capped at a hundred thousand gas; and the legal-but-mass-invalidatable is fenced by prefix shapes, trace rules, and eviction.
The chapter closes in one line: protocolization is not the art of eliminating risk but the art of rehousing it. Speculation went to the paid and willing builder, deployment trust went to mathematics plus discipline, and detection cost went to pipeline ordering plus p2p reputation, shared by all nodes. The seams of those three rehousings are the reason the spec’s security-considerations section exists.
Summary
Compress it into one paragraph. After 8141 evaporates the bundler and EntryPoint, the middleman’s five duties find their heirs one by one. Compatibility for the codeless goes to default code, a protocol-synthesized answering script that demotes the old ecrecover == sender constitution into a default template, thereby nailing the path of inertia to ECDSA. Sponsored payment goes to a single APPROVE(0x1): escrow vanishes because the protocol is its own settler, what it lacked was never capability but authorization; screening rides the pay frame with cross-frame introspection, settlement rides the post_op frame beyond the payment line; and trust in payers trades deposits and reputation for structure, canonical bytecode twins with reservation accounting, and a one-pending cap for everyone else. Propagation goes to a two-tier world: the public pool is a commons whose covenant caps the cost of speculating for strangers, private channels internalize the risk to a builder who collects, and the chain’s only compulsory gate is block validity. Packing goes to the PBS market: randomness lives only in the instant a person is drawn, selection is economics, nine in ten blocks come from a highly concentrated builder market, and the post-quantum transaction lives by that market while pawning its censorship resistance to an oligopoly’s list, beyond even FOCIL’s reach. Risk is rehoused: speculation to builders, deployment to address commitments plus initcode discipline, detection to pipeline ordering plus p2p reputation. Through all five inheritances runs the same recipe the series keeps meeting: cast economic walls into code walls, replace dynamic bargaining with static decidability, replace a middleman’s judgment with a protocol constant.
The next article dives one layer further down, into the machine where the replaying happens: after you submit a transaction, who burns CPU for it, where, and at what price; why the same piece of mathematics costs a hundred times more inside the EVM; what gas is really metering; and how a roster called precompiles decides which cryptography deserves to be cheap.