Introduction: Account abstraction infra in a post-quantum world

ERC-4337 brought account abstraction (AA) to Ethereum without protocol changes, built on a dedicated mempool and a singleton EntryPoint. EIP-8141 targets the same goal at the protocol level, replacing the bundler -> EntryPoint pattern with a composable frame transaction type.

This post analyzes how post-quantum cryptography affects account abstraction, focusing specifically on the roles of paymasters and bundlers, and considers what happens when, and if, AA shifts to being powered by frame transactions.

Part I stays inside ERC-4337. We map the structural limits of bundlers and paymasters under hash-based post-quantum signatures, then propose a design (the PQ-anchored middleware) that merges bundler and paymaster into a stable-identity contract, delegating external execution to a chain of just-in-time funded ephemeral EOAs. The pattern is 4337-native and reaches end-to-end PQ security without protocol modifications.

Part II crosses the EIP-8141 fork. We show that the abstractions the middleware depends on change nature under frame transactions, and the pattern does not survive the model shift intact. We isolate what does carry over (the multi-stream paymaster works identically in both worlds) and what needs reformulation.

The post uses FORS+C as reference scheme throughout, as it is the converged choice of our Ephemeral Keys Protocol and other independent designs.

---

Part I. ERC-4337

1. Bundler limits under post-quantum signatures

Under ECDSA the ERC-4337 bundler is an MEV optimizer with sandbox rules on the validation prefix. The Calldata cost constraint introduces two structural constraints, both of which are properties of the scheme rather than the implementation.

1.1 The Calldata cost constraint

An ECDSA signature on secp256k1 takes 65 bytes. A FORS+C signature at 128-bit NIST L1 security (k=26, a=5, n=16) takes 2,448 bytes. A 38× overhead per UserOp. At 16 gas per non-zero byte, that is about 60k gas of pure calldata per signature, in the same order of magnitude as verification itself (~35k gas). Calldata plus verification cost ~95k gas per signature, and a bundle of 50 UserOps pays roughly 4 million gas in signature calldata alone before touching a single verification opcode.

Blobs (EIP-4844) are not accessible from the EVM without additional KZG opening proofs, so on L1 calldata remains the only path. ZK L2s shift the cost structure since the rollup validity proof is blob-based and the signature bytes are amortized inside the proof rather than posted as calldata, but the verification still has to happen somewhere in the circuit and the exact savings depend on the specific rollup architecture.

1.2 The "one UserOp per sender per bundle" constraint

ERC-4337 forbids bundlers from including multiple UserOps from the same sender in one bundle by default, because state written during validateUserOp of one operation is not visible to simulation of another in the same bundle. Under ECDSA the constraint rarely bites, because users do not submit UserOps in bursts. Under rotation-based schemes like Ephemeral Keys it becomes the dominant bottleneck : each UserOp commits its current key serially, and per-user throughput is bounded by the block time.

The constraint applies explicitly to sender state. But if the paymaster also writes state during validation, as FORS+C rotation requires, bundlers including UserOps from different senders that share the same paymaster in the same bundle face the same state visibility problem. Few bundlers handle this interaction explicitly today, and no current spec clarifies it.

---

2. Paymaster limits under post-quantum signatures

The ERC-4337 paymaster sponsors user gas, custodies ETH in the EntryPoint deposit, and authorizes sponsorships via validatePaymasterUserOp. Standard stack uses an operator ECDSA key to sign each sponsorship. Under a concrete quantum threat, leaving the paymaster on ECDSA creates a secutity problem.

2.1 The paymaster becomes the quantum target

If the sender signs with FORS+C while the paymaster signs with ECDSA, a CRQC-equipped attacker ignores the sender and attacks the paymaster key directly. A single ECDSA signature from the paymaster observed in mempool is sufficient to recover the private key via Shor. At that point the attacker can authorize arbitrary sponsorships from the compromised paymaster until its EntryPoint deposit is exhausted, and depending on the paymaster contract's withdraw policy may also withdraw the deposit directly.

2.2 Rotation serializes throughput

Under FORS+C with 1-per-signature rotation (the standard few-time signing mode to preserve NIST L1 security) the paymaster cannot sign a second sponsorship with a different message until the first is included in a block and the current key has been rotated. The key is committed until inclusion, and signing a sponsorship with a different userOpHash in the meantime produces implicit q=2: graceful degradation, with security dropping from ~128 bits to ~104 bits.

The practical consequence is that the paymaster's operational throughput is one distinct sponsorship per block. This means potentially up to tens-of-thousands sponsorship per day, which a paymaster serving high-volume services (exchanges, dApps with integrated sponsorship, payment rails) saturates immediately.

The natural temptation is to raise FORS+C parameters to allow q > 1 at NIST level 1, but the math does not cooperate: at constant 128-bit security, each unit of q costs 10 to 40k extra gas per signature in signature size and verification, making it quickly unfeasible.

Dropping rotation for a stateless scheme removes the serialization but raises the cost significantly. As of today, stateless PQ signatures (e.g. SPHINCS+, Dilithium) have both gas cost and verification cost significantly higher that a stateful scheme like FORS+C. This increase in cost can maybe be accettable for a signle user doing sparse, high value, transactions, but a paymaster or a bundler needing to sign over a large volume of transactions cannot afford that.

---

3. A 4337-native solution: the PQ-anchored middleware

The solution described in this section is 4337-native. It uses exactly the abstractions ERC-4337 introduces (EntryPoint as singleton, bundler as application-level role, UserOp as a transportable object) to insert a stable-identity layer in the middle. The pattern is PQ-anchored, not strictly end-to-end PQ: the identity and authorization root is FORS+C, but the outer transaction submission still rides on ephemeral ECDSA. While EIP-8141 is still in an early adoption phase, this middleware is the closest approximation to end-to-end PQ buildable without protocol changes.

The previous two sections isolated two structurally different but intertwined problems:

1. The bundler has calldata and per-sender state constraints that do not disappear under PQ.
2. The post-quantum paymaster inherits a rotation bottleneck that serializes throughput.

The natural question is whether a single design can address both together rather than treat them separately.

The proposal is a single contract, call it the middleware controller, that merges paymaster and bundler into one onchain identity, custodies the FORS+C state directly, and delegates external execution to a chain of just-in-time funded ephemeral EOAs.

3.1 The principle: decompose identity and execution

Both Bundler's and Paymaster's EOA keys are a quantum weak point: a single signature in mempool exposes the public key, and a sufficient CRQC reconstructs the private key.

The middleware controller decomposes the problem along two axes:

• Identity is stable, preserved by the contract address. Every tx approved by the contract must pass its internal authorization, which is purely FORS+C, therefore PQ-safe.
• Execution onchain still requires an EOA, because the Ethereum mempool today accepts only ECDSA-signed transactions, but that EOA is single-use: using an ephemeral EOA reduces the attack window for this transport to seconds.

The contract’s FORS+C state is the durable authority domain: it anchors identity, commitment rotation, and transaction authorization. The ephemeral ECDSA account is only a transport layer for one broadcast window; its security depends on the latency assumption, not on long-term ECDSA strength.

Ephemeral ECDSA severely shrinks the exposure window: the key is useful for one outer transaction, then discarded. Even if recovered, the EOA without a FORS+C signature has no authority over the controller’s FORS+C-gated state or future contract actions; at most, the attacker can interfere with that cycle’s transaction submission.

3.2 The full cycle

The mechanics are clearest if we frame "cycle n" as the current execution, with an EOA addr_n already existing and funded from the previous cycle. The pattern bootstraps once: the operator funds addr_0 from external ETH, and every subsequent transponder gets its funding through the EntryPoint beneficiary mechanism plus, if needed, a controller top-up.

The offchain operator generates the ECDSA pair for the next cycle, (sk_{n+1}, addr_{n+1}). It constructs a message that commits addr_{n+1}, the hash of the UserOp bundle to sponsor in cycle n, and the commitment of the next FORS+C signer c_{n+1}. It signs the message with the current FORS+C key K_n.

The current transponder addr_n submits a transaction to the controller calling activate(forsSig, bundleData, addr_{n+1}, c_{n+1}). The controller verifies the FORS+C signature against the stored commitment c_n, atomically rotates the commitment to c_{n+1}, and calls EntryPoint.handleOps(bundleData, addr_{n+1}) with the next transponder as beneficiary. The EntryPoint pays the bundle gas refund directly to addr_{n+1}, funding the next cycle in the same transaction. If the EntryPoint refund is not enough to cover the next cycle's outer transaction cost in full, the controller adds a top-up to addr_{n+1} from its own balance, sourced from the paymaster deposit.

This routing has one consequence that is worth stating explicitly. The top-level transaction gas of cycle n is paid by addr_n and any unused outer gas refund goes back to addr_n after the transaction completes, because that is how Ethereum's transaction-level gas accounting works. The controller cannot redirect the outer refund inside activate(). The implementation has two options for handling this leftover:

• Tight prefunding. addr_n is funded with exactly the gas it needs for the outer transaction. Any leftover is small and stranded on addr_n when the operator discards sk_n.
• Delayed sweep. The operator retains sk_n for a short window after cycle n and uses it later to sweep the stranded leftover. This weakens the "burn immediately" property: sk_n exists longer than the single cycle, extending the ECDSA exposure window beyond the latency assumption stated in §3.1.

At cycle end, addr_n has been emptied of all but a small leftover and is cryptographically exhausted. Its public key is onchain, but sk_n is discarded and addr_n will never sign again. addr_{n+1} is funded by the EntryPoint beneficiary refund (plus optional top-up) and queued for cycle n+1.

3.3 PQ-safe operational authentication under a stable contract address

Currently, the paymaster is an address operated by a quantum-vulnerable EOA. The naive PQ replacement is to make the operator a PQ signer, e.g. using Ephemeral Keys-style FORS+C with key rotation. Applying this to the paymaster contract itself would require adding logic to track the constantly moving signer's identity, and would require the paymaster to be bound to a specific kind of implementation once deployed.

The middleware controller resolves this by absorbing the rotation logic. The contract address on the paymaster remains stable as the only source of authorization and the paymaster itself is blind to any custom rotation logic. The transponder ECDSA layer underneath still exists as transactional plumbing for mempool submission, but carries no trust weight of its own.

This is what we mean by "PQ-safe operational authentication": the authorization root is FORS+C, custodied and rotated inside the middleware, queryable through standard onchain reads, and bound to the same address that holds the deposit and that dApps integrate with.

---

Part II. The transition to EIP-8141

4. What changes with frame transactions

EIP-8141 introduces a new transaction type (0x06) with structure [chain_id, nonce, sender, frames, ...]. The transaction belongs to an account, and frames are composable operations internal to that account's transaction, each frame has a mode (VERIFY, SENDER, DEFAULT), a target, and data opaque to the protocol. Notably, sender can be a contract account: EIP-8141 explicitly suspends EIP-3607's ban on code-bearing senders for frame transactions, so a smart contract at the tx.sender slot is allowed.

Two structural shifts from the 4337 model matter to this discussion.

• The bundler as application-level role disappears. In 4337 the bundler is msg.sender of handleOps, an EOA that signs a transaction containing N UserOps from different senders. Under 8141 every frame transaction is single-sender, so cross-user bundling migrates to the block builder, which packs N frame transactions (from different senders) in the same block under standard fee-sorting rules.
• State write constrained during VERIFY: The 8141 spec distinguishes a validation prefix (the sequence of VERIFY frames before the sender_approved and payer_approved flags are set) from an execution suffix (the SENDER and DEFAULT frames executed after). State writes are banned in the prefix: no SSTORE, no CALL to unknown contracts barring exceptions. At the end of verification, depending on the result, it is emitted:
  • APPROVE(0x0) for no authorization
  • APPROVE(0x1) for payment approval
  • APPROVE(0x2) for execution approval
  • APPROVE(0x3) for both payment and execution approval.

For the sender the path is straightforward: SENDER frames are part of normal execution, and rotation of the sender's key happens in one of them, inside the same transaction that key has authorized and entirely under sender control.

The paymaster case is subtler. The spec does allow execution frames targeting the paymaster: the canonical sponsored-transaction example includes a post-op frame with target = paymaster after the sender's frames, which the paymaster uses for accounting, refunds, or in our case rotation. An execution path therefore exists, but the spec stops short of decoupling that path from the sender: the post-op frame lives in the transaction's frame list, and the frame list is signed by the sender as part of the canonical signature hash, so the paymaster authors no frames of its own in the standard sponsored flow. It signs a VERIFY frame that authorizes payment for a transaction whose frame structure (including any post-op rotation frame) was assembled by the sender.

This sender-mediated execution path is theoretically feasible but carries tradeoffs. To use it for FORS+C rotation the sender would need to include a rotation frame dedicated to the paymaster in the transaction. This requires cooperation between user and paymaster and the latter would still need to inspect over all transaction frames to ensure it's signing over a valid rotation for itself, making this path practically unfeasible.

In 4337 the external flow is always EOA → EntryPoint, and the middleware inserts itself in the middle to provide stable identity for the paymaster role. Under 8141 the ephemeral EOA layer is no longer required: a contract account can be tx.sender directly, with PQ authentication via its own VERIFY frame. The middleware pattern as constructed in Part I, with ECDSA transponders driving a contract for mempool reach, becomes unnecessary in 8141 because the contract reaches the mempool natively.

---

5. What carries over: the multi-stream paymaster

The piece that survives the abstraction shift is the multi-stream paymaster. The reason it survives, and the reason it remains necessary, is the asymmetry §4 made explicit. The sender gets native atomic key rotation in 8141 via its own SENDER frames. The paymaster has a path through sender-mediated execution frames, but that path is cooperative and carries leak, censorship, and gas tradeoffs. Either way, neither regime gives the paymaster autonomous high-throughput rotation. Multi-stream is the structural answer for the paymaster in both 4337 and 8141.

5.1 The serialized rotation problem is paymaster-specific under 8141

Under FORS+C with Ephemeral Keys, any rotation-based PQ signer that authorizes M > 1 concurrent operations per block faces the same bottleneck: the current key is committed until inclusion, and any other operation with a different message signed under the same key produces implicit q=2. Under 4337 this constraint binds both sender and paymaster because both write state during validation under sandbox rules, and the rotation has to happen inside the validation function itself.

Under 8141 the constraint splits. The sender writes its rotation in a SENDER frame, atomically with the operation it has authorized. There is no serialization beyond what the user naturally produces (a human submitting transactions every few minutes, well over block time).

A paymaster serving thousands of users per day cannot use a single key for all those sponsorships, because there is no way to support concurrent signing on the same key without sacrificing the 1-per-signature property.

5.2 The solution: K parallel commitments

Instead of reusing a key across multiple signatures, the paymaster maintains commitments for K independent parallel keys, each with q=1 and full security. The paymaster custodies K storage slots, each with a different current commitment, derived from a single master seed via separate BIP-44 paths (m/44'/60'/0'/paymaster'/stream_i'/n_i). The signature includes a 1-byte stream index in the payload, the verifier loads the indicated slot, verifies the signature against that commitment, and rotates only that slot. The other K-1 keys remain available to sign in parallel.

Cost per sponsorship is identical to the q=1 base,no larger signature, no more expensive verifier. The overhead is almost negligible while the security stays at NIST level 1 for q=1.

5.3 Offchain coordination: atomic stream reservation

The signer service needs a mechanism to prevent two concurrent requests from signing on the same key. Per-stream state has three values: free, in_flight, burnt. When a sponsorship arrives, the signer atomically reserves a free stream, signs, marks the stream in_flight. When the transaction is included, the stream "frees up" automatically because the onchain slot has been rotated, and the signer updates currentIndex[streamIdx]. If the transaction dies in mempool, the signer has two options. Either redeclare the stream free with the original key, accepting controlled q=2 (~104 bits, below NIST L1 but above the practical security floor for low-value transactions), or use another valid key to manually rotate the used slot to a new signer.

5.4 A dedicated paymaster-authored rotation frame

A nice addition that requires a protocol extension, would be a new frame class, call it provisionally PAYMASTER_ROTATE, valid only after a pay VERIFY frame has successfully called APPROVE(APPROVE_PAYMENT). The frame would be targeted to the approved payer/paymaster, carry no value, have a bounded gas limit, and declare the storage slot it intends to update, e.g. (stream_idx -> commitmentSlot(stream_idx)). Unlike today's DEFAULT post-op frame, which is structurally a sender-supplied frame that the paymaster must inspect and accept, a PAYMASTER_ROTATE frame would be authenticated by the paymaster itself. The paymaster's VERIFY signature would bind both the sponsorship and the rotation payload: (chain_id, sender, nonce, frame_hashes, stream_idx, c_current, c_next, expiry).

Payment approval and signer rotation must be one domain-separated signed message, otherwise the mechanism reintroduces the q=2 reuse problem it is meant to avoid. With that constraint, the frame gives the paymaster an explicit self-rotation path without treating rotation as an ordinary user-authored DEFAULT call.

---

6. Design space

Once rotation is fixed as the commitment lifecycle, one structural variable remains, namely how many commitments live onchain in parallel: a single slot is one stream, and K slots are K independent streams. Verification, calldata, and the rotation SSTORE cost the same no matter how many slots exist, so configuration changes only the number of concurrent commitment chains.

Ephemeral Keys protocol sits at K = 1, a single rotation slot acting as the user signer. Each signature consumes the current commitment and writes its successor in the same transaction, and the paymaster analysis builds directly from this design. Multi-stream sits at K > 1, with K parallel rotation slots serving the server-side paymaster. Because the K commitment chains advance concurrently, K in-flight operations never contend for the same successor slot.

Adding parallelism is cheap. Both configurations cost roughly 74k gas per signature (35k verify, 39k calldata), and K never enters the per-signature path: every stream verifies and rotates exactly as the single-stream wallet does. What K scales is deployment and handling complexity, since each stream needs one committed slot written once at initialization from K different derivation paths. Going from one stream to K is a one-time storage cost linear in K, with no marginal penalty per signature afterward.

The two configurations serve different operational regimes: a user wallet with perpetual rotation maps to Ephemeral Keys at K = 1, and a high-throughput server-side paymaster maps to multi-stream at K > 1. Any K is reachable, limited only by the deployment storage one is willing to commit up front and the added complexity in the offchain handling of the K streams.

---

Conclusions

Under ERC-4337, today, the closest approximation to end-to-end PQ buildable without protocol changes is the middleware controller of §3, merging bundler and paymaster into a stable-identity contract with PQ-anchored authentication and an ephemeral ECDSA execution boundary. The PQ guarantee covers identity, deposit ownership, and authorization root, while the outer transaction submission still rides on ECDSA, with security from how short the exposure window is rather than from the strength of ECDSA itself.

Under EIP-8141 the picture changes: the spec allows for contracts to be transaction senders, so a PQ paymaster or PQ account can reach the mempool natively without an ECDSA shim. What does not disappear is the rotation bottleneck for stateful PQ paymasters serving concurrent high-volume sponsorship, to which multi-stream remains the portable answer in both regimes.

The practical point for builders today is that both horizons matter. The 4337 middleware is a complete operational design for the current protocol model, but anticipating the 8141 transition informs choices about state layout, monitoring, and interfaces from day one. The multi-stream paymaster instead is an investment that is necessary in both worlds.

---

References.

• ERC-4337: Account Abstraction Using Alt Mempool.
• EIP-8141: Frame Transactions.
• ERC-7562: Account Abstraction Validation Scope Rules.
• EIP-7702: Set Code for EOAs.
• Ephemeral Keys Protocol. Riva Labs Core.
• Native Ephemeral Key Rotation via Frame Transactions. Riva Labs Core.
• FORS / FORS+C: foundation in SPHINCS+ (NIST PQC), with checksum variant for selective-forgery resistance.

---