The first two articles built the machine. Part one explained why the authority to decide “what counts as a valid transaction” slid from the protocol into account code, and how the payment line splits the system into a heavily guarded before and a laissez-faire after. Part two dissected EIP-8141’s frame transaction: the protocol knocks in the name of 0xaa, and the account answers with one APPROVE instruction. This article puts a real post-quantum signature onto those rails, walking from the account’s birth all the way to the transaction landing in a block, and then confronts two larger questions: why the same signature carries prices a hundredfold apart on two different lanes, and where trust comes from once the equation “address equals private key” has been torn up.
The through-line in one sentence: account abstraction frees ownership from address derivation and turns it into “what the code says to APPROVE”; a Falcon signature’s cryptographic workload never changes from start to finish, and what changes is which lane it executes in, who prices it, and who is trusted.
The birth of an account: how code grows onto an address
Part one established that every account in the state tree is the same four-field tuple with no type field; the entire difference between an EOA and a contract is whether codeHash is the empty hash. So “installing code on an account” is, mechanically, “writing a non-empty codeHash into a state entry.” In the protocol’s entire history, only two primitives can do this, and every system is a combination of them.
Primitive one is creation: CREATE or CREATE2 executes initcode and writes runtime bytecode to a fresh address computed by the creation rule. A CREATE2 address equals the last 20 bytes of keccak(0xff ‖ deployer ‖ salt ‖ keccak(initcode)). The address is computed, and it has never had a corresponding private key. Primitive two is delegation, introduced by 7702: write a 23-byte delegation indicator, 0xef0100 ‖ target, into the code slot of an EOA address that already exists. Not real code, a signpost; when called, the EVM fetches the target’s code and runs it in that EOA’s own context.
The three generations of designs are three packagings of these two primitives. 4337 uses creation: a factory CREATE2s a contract account at a brand-new address. One intuition needs correcting on the spot: nowhere in 4337 does “installing code on an EOA” ever happen. A 4337 account is a new contract at a new address; the old EOA is merely a key that the new account’s logic chooses to honor. What the user does is not an upgrade but a move, and the assets have to be carried over piece by piece. 7702 uses delegation, the first surgery performed at the original address, and part one covered the price: the surgery is authorized by ECDSA, and after the operation the old key still holds the power to operate again. That is the backdoor. 8141 invents no new primitive; it adopts both. New accounts go the creation route, with a deploy frame plus EIP-7997’s deterministic factory predeploy, and because the deploy frame executes before authentication, protected only by the address’s commitment to the initcode, the initcode must be written so that anyone deploying it on your behalf is safe. That amounts to promoting 4337’s counterfactual deployment from an application-layer custom into a protocol primitive. Existing EOAs take the delegation route as before.
8141 also brings a third mode of existence, and note that it is not a third primitive: default code. When an ordinary codeless EOA sends a frame transaction, the protocol synthesizes virtual behavior for it out of thin air: in VERIFY mode, find a SECP256K1 signature and APPROVE on its behalf. Its codeHash remains the empty hash and not one bit of state is written. Not real code, not a signpost, a runtime phantom. And precisely because the protocol synthesizes it, it recognizes only ECDSA and has nothing to offer post-quantum users: to use Falcon, you must truly install code.
So an account A equipped with Falcon verification code has two possible origins, corresponding to two quantum exposure surfaces. A native smart account: the code slot holds verifier bytecode (or a signpost to a shared implementation), the address is a fresh CREATE2 product that never had a private key, and the account-layer quantum exposure is zero, the cleanest form. A migrated legacy EOA: the code slot holds 0xef0100 ‖ implementation, the old ECDSA private key still exists, and the signpost can be rewritten by it at any time. 8141 lets a migrated account’s daily operation avoid ECDSA entirely, but it cannot remove the rewriting power; the true cut has to wait for a future protocol-level step, the ECDSA-deactivation family part one mentioned. The execution side is fully provisioned too: the frame loop dispatches three ways on codeHash, empty hash to default code, indicator through the pointer, regular code executed directly; and EIP-3607’s old rule that accounts with code must not originate transactions is relaxed for frame transactions, since a SENDER frame’s originator is supposed to be a code-bearing account.
Ownership: the key moved house, it did not disappear
Native smart accounts are often described as “accounts without private keys,” and the description is half a notch off. The address indeed derives from no private key; it is the initcode’s shadow. But the user certainly holds a key, the Falcon private key sitting in the wallet. What changed is the binding. A traditional EOA’s ownership is burned into address derivation: the address is the public key’s shadow, the protocol hard-codes “only signatures matching this address count,” changing keys means changing address means moving house, immutable forever. A smart account’s ownership is mutable state: a public key in a storage slot, plus the code’s interpretation of it.
The new definition of ownership needs one sentence: whoever can make A’s code say APPROVE is A’s owner. On chain that is what the VERIFY frame asks; off chain the same shape holds, ERC-1271’s isValidSignature goes and asks the same code. The first dividend this definition buys is native key rotation: upgrading Falcon parameters, or switching outright to ML-DSA, is a storage write. The address stays, the assets never move. An EOA cannot do this, because its address is the key.
Recovery: from mathematical death sentence to design space
Losing an EOA’s private key is a mathematical death sentence with no mechanism of appeal, which is the root of the chain’s dormant-account problem. Once ownership becomes “storage plus code,” recovery turns from impossible into a menu.
The menu runs from austere to ornate. Write no recovery logic at all, sharing the EOA’s fate in exchange for the smallest attack surface. Social recovery: register N guardians’ on-chain addresses in storage, and M-of-N co-signing plus a timelock rotates the key, the whole flow staying on chain, no email required. Inactivity takeover: a backup key gains control after the main key has been silent for X days, the main key can cancel the countdown at any time, and the backup key can be a heterogeneous scheme, main key Falcon with an ML-DSA backup in cold storage, or even a transitional ECDSA backup. Third parties: custodial co-signing, passkeys (P256 already has native pricing at 6700 gas), and the zkEmail family that verifies email DKIM with zero-knowledge proofs. Note the change of station: third parties are demoted from a dependency the system imposes to an option on a menu, and each account’s code decides whether to plug them in and how much power to grant.
Two buckets of cold water must be poured on the spot. First: every recovery path is a second door you cut into your own house with your own hands. The guardian set, the backup key, the takeover logic are all attack surface, and a recovery mechanism must be audited as strictly as the main validation path, or the front door gets a quantum lock while the side door stands ajar. Second, colder: if a recovery path is ECDSA, quantum exposure walks back in through it. However hard the Falcon main key is, an attacker who breaks a secp256k1 guardian or backup key rotates your key all the same. This is the generalized form of the 7702 backdoor: the completeness of a quantum migration equals enumerating and upgrading every authorization path of the account, main validation, recovery, guardians, backup keys, not one left behind. Signature agility makes partial migration possible, and it also makes “believed migrated, actually not” a brand-new failure mode.
Five acts: a post-quantum transaction goes the distance
Now bring on the protagonist. Account A has Falcon-512 verification code installed and an 897-byte public key in storage, and wants to send B 100 ETH, paying its own gas, on the ARBITRARY lane, the form that runs the day 8141 ships. Set the master rule of authorization first: no longer “the address recovered by ecrecover equals the sender,” but “A’s own code executed APPROVE inside a VERIFY frame.”
Act one, the wallet constructs and signs. Off chain, A’s code still asleep:
chain_id = 1, nonce = 7, sender = 0xA11CE…frames = [ F0: [VERIFY, flags 0x3, target empty (→A), gas_limit 2_100_000, value 0] F1: [SENDER, flags 0x0, target 0xB0B…, gas_limit 40_000, value 100 ETH]]signatures = [ S0: [scheme ARBITRARY, signer empty, msg empty, signature 666-byte Falcon] ]S0’s three empties each mean something. Signer empty: the protocol does not understand arbitrary schemes and has no way to parse who the signer is, so this position must be empty by definition. Msg empty: part two’s self-reference symbol, declaring “what I signed is this very transaction’s canonical signature hash.” Signature to be filled. The pipeline follows part two’s rules: compute the canonical hash H under the excision rule (S0’s signature seat counted as blank), sign H with the Falcon private key, fill in the bytes. The wallet observes one discipline here, outputting a canonically encoded signature; the reason surfaces in act three.
Act two, the fork in the mempool. The node’s admission machine waves items through until the prefix simulation: the shape is legal, a single self-verify frame being one of the prescribed forms, but the budget explodes. The prefix gas limits plus the signature fee total 2,100,100 against a cap of 100,000, twenty times over. The public mempool declines. Mind the nature of the refusal: not a verdict of “invalid,” but a polite “we will not relay this.” The transaction is fully legal at the consensus layer; what stops it is the propagation layer, a live specimen of the mezzanine from part two’s ending. The way forward is a private mempool, or an MEV channel straight to a block builder. A structural tension is worth writing down here: post-quantum users get pushed systematically toward a handful of private channels, head-on against Ethereum’s censorship-resistance story.
Act three, network-wide execution. A builder packs the transaction into a block, and from then on every full node importing that block replays the frame loop; gas is the price of exactly this network-wide repeated labor. The protocol first passes the signature list: S0 is ARBITRARY, so it gets a structural check only, 100 gas, not one bit of cryptography touched (the customs office of the next section). Then the frame loop launches F0 with context caller equal to 0xaa, ADDRESS equal to A, STATICCALL semantics, and A’s bytecode wakes up to work:
① h ← TXPARAM(0x08) // read the canonical signature hash: the message to verify② SIGPARAM metadata: scheme is ARBITRARY? length about 666 bytes?③ SIGPARAM copy: copy the 666-byte signature into memory④ pk ← SLOAD own storage // sandbox-legal: reading only the sender's own storage⑤ canonical-encoding check: reject every non-canonical form and redundant byte⑥ Falcon-Verify(pk, h, sig): hash expansion, NTT, norm checks, ≈ 2,000,000 gas⑦ pass → execution reaches opcode 0xaa (APPROVE); fail → revert → whole tx invalidStep ⑤ collects the seed planted in act one. The signature bytes of ARBITRARY empty-msg entries were excised from the canonical hash, so a third party can rewrite those bytes without disturbing the authorization: the canonical hash stands still while the transaction hash changes. Part two told the story of ECDSA’s s-malleability and EIP-2’s low-s fix; the same ghost returns here in a new shape, and this time the duty of enforcing canonical encoding lands on your own verifier code. Protocol schemes have their malleability discipline written into the scheme table (8141’s SECP256K1 entry spells out the recovery-bit range and low-s); ARBITRARY carries its discipline alone.
Step ⑦’s “who executes APPROVE” deserves one more nail. APPROVE is an instruction, not a call, embedded in A’s bytecode; in the execution context ADDRESS is A, and the guard is precisely that ADDRESS must equal the frame’s target. It is A’s code, in A’s identity, speaking approval; 0xaa knocks, 0x8141 (absent from this example) watches the clock, and the only one signing anything, from beginning to end, is A itself. The instant APPROVE(0x3) lands, four things complete at once: the sender-approved flag sets, the payer becomes A, the nonce steps from 7 to 8, and gas money is pre-deducted at the transaction’s maximum cost.
Acts four and five, transfer and settlement. F1 executes with caller equal to A, and 100 ETH moves to B. Its authorization comes from no outer signature, for this transaction has no outer signature at all; it comes from that one APPROVE in act three. The frame loop’s final check sees the payer settled, unused gas returns to A, and per-frame receipts are written. See the master-servant relation clearly: the frame loop is the subject throughout all five acts; A’s code wakes exactly once, in act three, answers one yes-or-no question, and exits the stage. It does not know whether F1 ran, nor even whether the transaction finally made it into a block.
An epilogue of variations, every one of them just “append elements to two lists.” Put an expiry frame targeting 0x8141 at the front, and the mempool reads the transaction’s time-to-live statically. Replace F1 with three SENDER frames carrying the atomic bit, and you have an all-or-nothing approve, swap, transfer batch. Add a VERIFY frame targeting a paymaster after F0, and A can hold zero ETH and pay gas in USDC. Put two empty-msg entries in the signature list, one ECDSA and one Falcon, pair them with dual-verification account code, and you have the transitional hybrid double-signature, whose two signers, as part two showed, can sign in parallel and in any order. The format does not change; the authorization primitive does not change.
Two lanes: one signature, two prices
In act three the protocol charged S0 only 100 gas, then burned two million inside F0. That contrast is the entire story of the two lanes.
First see what the 100 gas buys. Everything the protocol does with an ARBITRARY entry is checking it as data, never as a signature: the four-tuple’s RLP shape, a recognized scheme number, signer left empty, msg either empty or exactly 32 non-zero bytes, signature a byte string of legal length billed per byte. Customs checks the manifest; it does not open the box. For contrast, the SECP256K1 entry’s fixed check fee is 2800, which buys a genuine native verification. The consequence chain deserves thinking through: an ARBITRARY entry stuffed with garbage bytes is perfectly legal at the protocol’s signature stage and gets caught only when the frame loop runs the account’s code, reverts, and voids the transaction. ARBITRARY defers the cost of recognizing garbage from a fixed fee at admission to simulation at execution, which is exactly why it must be fenced inside the hundred-thousand-gas prefix sandbox; a protocol scheme’s garbage is stopped at admission by the fixed fee. The two lanes intercept garbage at different moments, so they contribute to the mempool’s DoS surface in entirely different ways.
A verdict on the ARBITRARY lane. Its overwhelming advantage is exactly one: permissionless. It opens for traffic the day 8141 ships, needing no follow-up EIP, no governance fight over the scheme table, no persuading of any client team; any algorithm, any parameter set, any hybrid combination, upgraded any time, all of it the account’s household business. Signature agility in its most extreme form. The secondary advantage is that the bytes are introspectable, so expressiveness has no ceiling. The costs number four: verification gas in the millions; the public mempool closed forever, leaving private channels with their decentralization and censorship-resistance discount; permanent loss of aggregation eligibility, reasons next section; and malleability discipline carried alone.
The question worth chewing on is this: the same Falcon signature, the same number of hash expansions, NTT multiplications, and norm checks, not one bit of cryptographic work changed, so by what right do the two lanes differ a hundredfold in price? It decomposes into three factors.
Factor one, the unit price of the execution environment. On the ARBITRARY lane, verification runs as EVM bytecode: an interpreted 256-bit stack machine, where a modular multiplication that takes a few nanoseconds in native code becomes MULMOD plus stack traffic plus memory reads and writes, further saddled with a high-level language’s loops and bounds checks. On the protocol-scheme lane, the same verification runs as client native code and is billed one fixed price set from real CPU time; ecrecover’s 3000 and P256’s 6700 are the existing rows of that price list. The same dish, priced in one kitchen as “build a stove from toy bricks on site, then cook,” and in the other as “cook over the real burners in the back.” A cost model says it cleanest: verification cost C = α·hash bytes + β·modular multiplications + γ·on-chain bytes. The operation counts are identical across lanes; what changes are the environment coefficients α and β, with the EVM’s β two to three orders of magnitude above native. Switching lanes is a coefficient transform, not a workload transform.
Factor two, billing philosophy. Metering per opcode integrates over the execution trace: however the code runs, so grows the bill. Scheme-table pricing is a governance-set flat price, a table lookup. The flat price presupposes an implementation enforced by spec and predictable performance, and “what should the price be” demands an argument, cross-scheme, parameter-aligned, clean-methodology measurement. That pricing argument is precisely the battle any post-quantum scheme must win before it enters the table.
Factor three, the amortization of overheads. Bills unique to the EVM lane: deploying the verifier contract, memory-expansion fees for copying signature bytes, dispatch overhead, borne by each account or each library for itself. The native lane implements once and shares network-wide, and the copy step vanishes entirely, the bytes being invisible to the EVM, a 2-gas metadata read and done.
One symmetric term hides a beautiful structure: γ, the on-chain byte fee together with EIP-7623’s byte floor, is identical on both lanes; 666 bytes are 666 bytes. Keep the two books straight while we are here: the hundred-thousand-gas budget constrains the validation prefix’s execution gas, while the 7623 floor burns the payer’s wallet and consumes none of the budget; they are independent ledgers, and only a transaction passing both is a citizen of the public pool. The interesting part is how the two walls relate. On the ARBITRARY lane, execution gas of two million dwarfs a byte floor of tens of thousands (Falcon about 26,600; ML-DSA on ARBITRARY about 96,800), so the floor never shows. Switch to native verification and drop the execution side to a few tens of thousands, and the floor flips into the dominant term. Only after the wall of verification cost falls does the wall of the byte floor surface: the two walls run a relay, they do not stand in parallel. And the byte wall’s terminal solution, aggregation driving γ toward zero, opens only to the protocol-scheme lane. Why, the next section makes clear.
The aggregation ticket: excision and introspection, two switches that seal a fate
Part two ended holding an “aggregation ticket”: empty-msg signature bytes are by definition in nobody’s hash preimage, so they can someday be deleted wholesale and replaced by an aggregate proof without disturbing any authorization. Now add the second switch; the two together decide each scheme’s economic fate.
First, nail down why deletion is the whole point. Aggregation does not lay one more proof beside the signatures; it replaces N large per-transaction signatures with one small piece of collective evidence, and the savings are exactly those N sets of bytes. On-chain bytes cost money, with the byte fee and the 7623 data floor both charged per byte; keep the individual signatures in place and γ does not drop by a single unit, so aggregation degenerates into pure added overhead. The gain of aggregation is the deletion itself, which leaves exactly one real question: once these bytes are gone, does anything on chain break?
The second switch is introspection: can EVM code read the signature bytes? Every word in that sentence needs precision. The reader is contract code executing inside the EVM, not humans and not nodes: the raw bytes are public off chain, sitting in every block explorer, and nodes must run them through verification at admission. “Invisible” means the EVM offers no instruction that can copy these bytes into a contract’s execution environment, so no contract’s behavior can possibly depend on their content. And keep two different things apart: what lives in an account’s storage slot is the public key; signature bytes never live in any contract’s storage, they are part of the transaction body, arriving with it and leaving with it. The spec’s arrangement is that visibility precisely follows verification responsibility. Protocol schemes are verified natively by the client before any frame runs, so the EVM needs to know only the fact that “position i holds a valid signature by S over M”; the SIGPARAM instruction serves metadata only, and the bytes themselves are forever invisible to contract code. ARBITRARY is the reverse: verification is done by your own VERIFY code, and code that verifies must read bytes, so the copy instruction opens to it alone.
The crux: visibility kills aggregatability. Aggregation is a protocol-level refactoring, deleting per-transaction signature bytes and substituting one equivalent piece of collective evidence, and its safety premise is that nothing on chain depends on the deleted part. Protocol schemes satisfy the premise: the bytes are unobservable, only the validity fact is observable, and a fact can be vouched for by any equivalent evidence. ARBITRARY does not: deployed code is actively reading those bytes, delete them and it breaks; and the protocol cannot even distinguish which ARBITRARY bytes are “aggregatable signatures” and which are arbitrary data the code needs. Once bytes are exposed to Turing-complete code, they become load-bearing structure forever, Hyrum’s law in protocol form. “ARBITRARY can never be aggregated” is the conclusion of this logic, not a negotiable clause.
The hook is in fact already planted; run the thought experiment. Suppose ML-DSA someday enters the scheme table, and some block carries a thousand transactions, each with one empty-msg ML-DSA entry, raw signature bytes totaling about 2.4 MB. The block builder deletes them all and substitutes one block-level aggregate proof. Every transaction’s canonical signature hash stands perfectly still, because empty-msg bytes were never in anyone’s preimage, and every user’s authorization intent survives intact. What is missing is only the follow-up spec for where the proof lives and who verifies it; the hardest invariant to retrofit, that deleting the bytes is a semantics-preserving transformation, today’s format already guarantees. Compare 4337’s aggregator from part one: the same idea, but there it was a contract-layer interface convention held down by staking; 8141 sinks it into the transaction format itself.
A security conclusion drops out in passing. The signature bytes of ARBITRARY empty-msg entries are both excised and introspectable, so a third party can alter the bytes without touching the authorization while rewriting the transaction hash; the verifier must therefore enforce canonical encoding and reject every redundant byte, or the transaction’s identifier is freely rewritable. And so a matter that used to belong to standards compliance gets a promotion: the canonicity of Falcon’s compressed encoding, the uniqueness of ML-DSA’s encoding, are on this lane not engineering fastidiousness but a protocol-level security requirement against transaction-hash malleability. What EIP-2 once did for ECDSA, every member of the post-quantum family must redo; encoding canonicity is a tax Ethereum learned from real incidents, and every generation of signature schemes pays it again.
Where does a verifier’s trust come from
The ARBITRARY lane hands accounts complete freedom. The other face of freedom is a plain question: that Falcon verification code, why should anyone trust it?
Set the architecture straight first. The delegation target usually should not be a bare verifier, but two layers:
A's code slot: 0xef0100 ‖ account implementation │ (runs in A's identity: can APPROVE, can touch everything, │ audited as fully trusted) ▼account implementation: key management, recovery logic, frame checks, APPROVE │ (ordinary CALL: a pure-function question, returns a bool) ▼FalconVerifier: stateless pure verifier, bytes in → bool outThe upper layer holds the qualification to speak in your identity and is audited to the fully-trusted standard; the lower layer is a mathematical function that gets CALLed and can touch no state. The lower layer’s standardized interface already has a prototype, ERC-7913: the account stores a pair of verifier address and public key, the verifier is shared network-wide, and keys stop being bound to addresses.
Which address should FalconVerifier live at? Start from a counterintuitive fact: there is no “protocol-official” FalconVerifier, and none is needed; that is what the word permissionless on the ARBITRARY lane means. Three sources, three trust models. Deploy your own: compile it yourself, CREATE2 it yourself, point your delegation at your own instance; sovereignty maximized, trusting your own audit and build chain, at the cost of deployment gas and the full burden of self-assembled trust. The community shared singleton, the real-world default: a canonical instance deployed once and shared by millions of accounts, the Safe singleton and WETH being the pattern. Protocol officialization, which is really changing lanes: the verification logic enters the client, the address question evaporates whole, and the terminal answer to “please deploy an official address” is not an address at all but a row in the scheme table.
Where does the shared singleton’s “trustworthy” come from? The checklist will read familiar. Immutability: no owner, no upgrade path, no external call dependencies, sealed at deployment. Verifiable bytecode: source public, compiler version and optimizer settings pinned, so anyone can rebuild and compare the on-chain codeHash; reproducible builds are here not engineering fastidiousness but the trust-establishment mechanism itself. Deterministic address: CREATE2 makes the address commit to the initcode, so knowing the canonical address approximates knowing the code, provided you trust the factory; once EIP-7997 turns the factory into a protocol predeploy, the last link is de-trusted too, with same-address-across-chains thrown in. The address is a fingerprint. Audit and formal verification: for a stateless pure-function contract, bytecode-level correctness proofs are feasible and worth doing. Wallet whitelists: major wallets already whitelist 7702 delegation targets, so an ordinary user’s trust decision is pre-screened by wallet software. And the customary bucket of cold water: the migrated-EOA ceiling. The delegation itself is ECDSA-authorized, and the old key can rewrite the signpost at any time; for a migrated account, everything on this checklist lives under a ceiling pressed down by that one old key.
The three ages of trust
Gather the series’ thread so far into one arc.
In the age of the EOA, you trust mathematics. Address is key, the protocol hard-codes everything: no recovery, no rotation, no choice, but also no one to trust, one elliptic-curve equation has the final word. In the age of the ARBITRARY lane, you trust a social process. Open source, audits, deterministic deployment, reproducible builds, whitelists; the price of freedom is assembling trust yourself. In the age of protocol schemes, you trust consensus. The verifier lives in the client, trust is backed by a fork, the same standing as ecrecover. The bridge from the second age to the third is built of three things: credible cross-scheme benchmark data, a measurement discipline with aligned parameters and clean methodology, and a cost model that writes the EVM coefficients and the native coefficients separately. Win the pricing argument and a row gets written into the scheme table; lose it and you stay in the social-process age, assembling your own trust.
Recovery is the same arc’s reflection: from mathematically unrecoverable, to programmably recoverable in code, to the newly formed question that recovery paths themselves need post-quantum completeness audits. Trust keeps moving forward, and the attack surface moves house right behind it.
Summary
Compress it into one paragraph. Once 8141 tears up the equation of address and private key, an account’s birth reduces to two primitives, creation born keyless and delegation planting a signpost in place; 4337 is a house move, 7702 is surgery in place that leaves a backdoor, and 8141 adopts both while promoting counterfactual deployment into a protocol primitive and issuing codeless EOAs a runtime phantom that only speaks ECDSA. Ownership becomes “whoever can make the code say APPROVE,” key rotation becomes a storage write, and recovery turns from a mathematical death sentence into a design menu, but every recovery path is a second door, an ECDSA recovery path lets quantum exposure back in through it, and the completeness of a quantum migration means upgrading every authorization path without exception. A Falcon transaction can go the distance today: the wallet signs under the excision rule, the public pool declines on a hundred-thousand-gas budget, a private channel carries it into a block, the whole network replays two million gas of verification inside a VERIFY frame, one APPROVE instruction simultaneously authorizes, sets the payer, steps the nonce, and pre-deducts the fee, and transfer and settlement follow. The same signature’s two prices change nothing in the cryptography; what changes are the environment coefficients α and β, the billing philosophy, and the amortization of overheads. After the verification wall falls, the byte-floor wall surfaces in relay, and the aggregation ticket that drives byte fees toward zero is issued only to protocol schemes whose bytes are invisible, because visible means load-bearing and load-bearing means undeletable. A verifier’s trust today is assembled from social process, immutability, reproducibility, deterministic addresses, audits, whitelists, and in the endgame is backed by consensus; the bridge between the two is an argument made of measurement and pricing. There is no single magic move in the quantum migration: it is the engineering of upgrading every authorization path, every wall, and every age of trust, one by one.
Later articles in this series will come back to questions already pinned to the map: how the scheme-table pricing argument gets fought, what the follow-up spec for aggregate proofs might look like, and where the compositional route that runs opposite to 8141’s wholesale reconstruction, such as EIP-8202 with its claim on 0x05, will take signature agility.