arXiv CSopen access

SuperPaymaster: Eliminating Centralized Signer Authority via Asset-Oriented Abstraction to Reconcile Usability and Decentralization in Account Abstraction

arXiv:2605.05774v1 [cs.CR] 7 May 2026

RESEARCH ARTICLE arXiv preprint

SuperPaymaster: Eliminating Centralized Signer Authority via Asset-Oriented Abstraction to Reconcile Usability and Decentralization in Account Abstraction Huifeng Jiao ∗ , Nathapon Udomlertsakul † Abstract. Most production ERC-4337 Paymasters rely on Process-Oriented Abstraction (POA): a centralized off-chain server signs each sponsorship request and therefore acts as a potential censorship bottleneck. We propose Asset-Oriented Abstraction (AOA), which encapsulates payment capability in a persistent, user-owned on-chain asset—the “Gas Card”— rather than in an off-chain signing process. Following Design Science Research, we implement SuperPaymaster on Optimism Mainnet. Its sponsorship validity is anchored in on-chain Soulbound Token state and deterministic policy rules, removing the off-chain signer as a hard validity gate. We evaluate gas cost on Optimism Mainnet using single-UserOp ERC-20 transfers (n=50 per system). Trace-level decomposition isolates an approximately 32kgas delta as the execution cost of eliminating centralized signing. In pure L2 execution gas, SuperPaymaster (167,830) is lower than both vendor-as-deployed commercial samples, including a 49% reduction against the DEX-routed ERC-20 baseline (328,937), because it replaces an on-chain liquidation path with an internal balance update. In total billed gas, the remaining gap to the cheapest baseline is explained primarily by bundler pricing rather than paymaster architecture. A failover simulation shows that non-cooperative relayers can be bypassed when an alternative relayer is available. These findings suggest that AOA can reduce the tension among usability, sponsorship decentralization, and economic efficiency. KEY WORDS 1. Account Abstraction 2. Asset-Oriented Abstraction 3. Paymaster 4. ERC-4337 5. Censorship Resistance 6. Design Science Research 7. Soulbound Token ∗ H. Jiao (huifeng [email protected]) is a PhD candidate at the International College of Digital Innovation (ICDI), Chiang Mai

University, Chiang Mai, Thailand. † N. Udomlertsakul ([email protected]) is with the International College of Digital Innovation (ICDI), Chiang Mai

University, Chiang Mai, Thailand. Corresponding author.

1

1.

Introduction

1.1. Background and Problem Statement—Blockchain technology, and Ethereum in particular,1, 2 introduced a model of decentralized and trust-minimized computation. To mitigate spam and compensate validators, Ethereum charges gas for every state-changing operation.1, 3 Gas is therefore a fundamental primitive of Ethereum’s security and economic design. However, the user-facing gas payment model remains a major usability bottleneck. Before completing a single application interaction, users may need to acquire ETH, often through a centralized exchange; navigate volatile fee markets; approve tokens; and, in many cases, bridge assets across chains. Industry surveys and Ethereum roadmap analyses consistently identify gas fees as a top-three barrier to dApp adoption, with abandonment rates exceeding 50% when users encounter unexpected fee requirements.4, 5 Early meta-transaction standards such as EIP-27716 attempted to abstract gas payment at the application layer through trusted forwarder contracts, but they remained app-specific and lacked a unified sponsorship interface. ERC-43377 later introduced the Paymaster primitive to abstract gas payment at the pseudo-protocol layer, yet practical deployments remain constrained by architectural choices that reintroduce centralized dependencies. Existing solutions exhibit two recurring limitations. First, most production Paymaster services rely on a centralized off-chain API server to sign each sponsorship request. If the server goes offline or blocks a specific user, the user is prevented from transacting, reintroducing a censorship vector at the sponsorship layer (see Figure 1). BundleBear data8 shows that a single paymaster provider processes over 71% of all sponsored UserOperations by volume, while the top three providers account for over 62% of total gas spend—concentrating sponsorship authority in a small number of API gatekeepers. Second, existing abstractions are tied to a particular dApp, session, or token list, so a seamless experience in one application does not carry over to another. We term this dominant pattern Process-Oriented Abstraction (POA): the system abstracts a discrete payment process within a specific, limited context, rather than encapsulating a reusable payment capability.

Fig. 1. Standard ERC-4337 Paymaster Architecture. The centralized API server

and signer (red, dashed) form the censorship bottleneck for gas sponsorship. An optimal solution must reconcile an intuitive user experience (analogous to a prepaid card) with decentralized on-chain verification. This paper introduces Asset-Oriented Abstraction (AOA) as that reconciliation. By encapsulating payment permission within an on-chain asset rather than an off-chain signing process, AOA shifts the locus of control back to the user’s wallet.

2

We operationalize the paradigm through SuperPaymaster, which instantiates the “Gas Card” metaphor along three principles (Figure 2 contrasts the two architectures): • Assetization: sponsorship capability is encapsulated in a tangible digital asset—a Soulbound Token (SBT), a non-transferable ERC-721. • Decentralization via Ownership: because the SBT is an immutable, on-chain proof of payment capability, discretionary off-chain signatures from a Paymaster API are no longer required for sponsorship validity. Standard Bundlers still handle transaction submission, but the permission to pay is enforced fully on-chain. • Universal Mental Model: holding a valid card supports portable payment capability across compatible dApps, without exposing relayer or bundler mechanics to the user. It is important to clarify that AOA does not replace POA at the protocol layer; it repositions what is abstracted. POA abstracts the process (and exposes its steps to the user whenever the abstraction leaks), whereas AOA abstracts the capability into an asset the user owns. SuperPaymaster therefore still uses ERC-4337 as the execution pipeline; the contribution is an architectural shift in how eligibility is proven and where sponsorship authority resides.

Fig. 2. Conceptual Comparison. Traditional POA (red) requires an off-chain server

to sign every transaction; SuperPaymaster (blue) validates sponsorship purely on-chain based on the user’s Gas Card. 1.2. Research Questions and Contributions—This research aims to design, implement, and evaluate SuperPaymaster to answer: • RQ1: How does AOA achieve removal of the off-chain paymaster signer as a hard validity gate at the paymaster-signer layer while maintaining a seamless user experience? • RQ2: How can the Gas Card metaphor reduce cognitive load and interaction complexity relative to POA approaches? • RQ3: To what extent does SuperPaymaster improve comprehensive economic efficiency compared to EOA baselines and standard ERC-4337 Paymaster implementations? This paper makes three contributions to Blockchain HCI and system design: 1. Conceptual. Definition and conceptualization of Asset-Oriented Abstraction as a design principle that systematically reconciles the usability–decentralization trade-off in gas payment mechanisms. 2. Artifact. The open-source SuperPaymaster system, comprising on-chain contracts (including the OpenCards SBT-based Gas Card standard and the OpenPNTs gas-token standard enabling permissionless community issuance) and a supporting SDK for UI integration. 3. Evaluation. A multi-method evaluation on Optimism Mainnet (n = 50 per system, 3

single-UserOp ERC-20 transfer) covering decentralization (failover simulation), usability (GOMS analytical modeling), and efficiency (gas profiling against industry POA baselines—Alchemy Gas Manager and Pimlico ERC-20 paymaster—with trace-level decomposition, bootstrap 95% CIs, and Cliff’s δ ). All system components—contracts, SDK, and deployment scripts—are released as opensource infrastructure to support reproducibility and community adoption. 1.3. Paper Structure—The remainder of this paper is organized as follows: • Section 2: Related Work reviews the theoretical foundations of HCI in Web3 and analyzes the limitations of existing “Process-Oriented” solutions. • Section 3: Methodology outlines the Design Science Research (DSR) framework used to guide the creation and evaluation of the artifact. • Section 4: Artifact Design details the system architecture of SuperPaymaster, including the “Gas Card” (SBT) and the Zero-Approve Gas Token Architecture. • Section 5: Evaluation presents the empirical results from our mainnet experiments, focusing on gas efficiency, contextual baselines, and censorship resistance. • Section 6: Discussion interprets the findings through the lens of “Asset-Oriented Abstraction” and discusses the theoretical implications for Web3 UX. • Section 7: Conclusion summarizes the research contributions and outlines future directions.

2.

Related Work and Problem Analysis

2.1. Theoretical Foundations— 2.1.1. An HCI Lens on Gas Payment—The usability of blockchain systems is a welldocumented challenge,9–11 and recent work in Blockchain: Research and Applications emphasizes the need for accessible smart contract architectures that reduce operational friction without weakening security invariants. Norman’s “gulf of execution”12, 13 captures the general gap between user intent and required actions; Nielsen’s usability heuristics14 pinpoint specific violations in the typical gas workflow. Users encounter (i) a poor match between system and the real world—“Gas Limit,” “Gwei,” and “Nonce” have no natural payment analog, whereas an auction-based fee market has no analog in users’ everyday payment experience; (ii) low flexibility and efficiency of use—a single intent is fragmented across Approve/Swap/Bridge/Execute steps; and (iii) inadequate error prevention—users routinely fall into “insufficient ETH for gas” dead ends even when holding sufficient token balances. These are systemic HCI failures, not local rough edges. A principled solution must therefore redesign the payment surface, not patch individual steps. 2.1.2. Perceived Ease of Use as a Gatekeeper—The Technology Acceptance Model15, 16 holds that adoption is driven by Perceived Usefulness (PU) and Perceived Ease of Use (PEOU). In Web3, PEOU functions as a gatekeeper to PU: users cannot appreciate a DeFi or gaming dApp’s utility if they cannot successfully execute a first transaction. The recurring friction of gas management therefore blocks users from ever reaching the point of value discovery, which is a primary driver of low retention and high drop-off in dApp onboarding funnels. 2.1.3. From Process-Oriented to Asset-Oriented Abstraction—The core HCI defect in current gas solutions is the prevalence of leaky abstractions. We categorize existing solutions

4

under a paradigm we term Process-Oriented Abstraction (POA): the system abstracts a discrete payment process within a specific, limited context. Because the abstraction is tied to a dApp, session, or token list, whenever the scoped context is exceeded, the underlying steps re-surface to the user. In contrast, we propose Asset-Oriented Abstraction (AOA): the system transforms the recurring payment process into a persistent, user-owned digital asset—the Gas Card. AOA is defined by three core principles (§1.1), which at the implementation layer decompose into three technical requirements: Assetization (the capability is reified as a standalone contract), User-Ownership (the asset’s state is controlled by the user’s Smart Account rather than a service contract), and Deterministic Verification (eligibility is evaluated against on-chain state under ERC-4337 validation constraints, without off-chain signatures). Two clarifications matter here. First, AOA is not a rejection of ERC-4337; SuperPaymaster is a concrete ERC-4337 Paymaster. AOA reframes what the abstraction targets—capability rather than process—and therefore changes where sponsorship authority resides. Second, POA and AOA describe design stances; they coexist on-chain today, and AOA is compatible with future Native AA proposals. Positioning AOA on the decentralization spectrum is useful here, because decentralization is not a binary state but a gradient along multiple dimensions (architectural, political, logical).17, 18 Current Paymaster deployments are architecturally decentralized (contract logic on-chain) but politically centralized (an off-chain signer decides who gets sponsored). AOA moves the political axis on-chain as well: the service logic that decides sponsorship eligibility is fully encapsulated in contracts, which aligns with the “hyperstructure” or code-as-law end-state described by Jacobs,19 where service logic is permissionless, immutable, and self-sustaining. 2.1.4. The Bootstrapping Paradox: A Preemptive Defense—A natural critique of assetbased abstractions is the Bootstrapping Paradox: does requiring a Gas Card merely shift the friction of acquiring ETH onto acquiring the Card? We argue that the acquisition channel is categorically different. Acquiring ETH almost always involves Centralized Exchanges and fiat onramps—“Centralized Gatekeepers” constrained by KYC, geography, and banking infrastructure. In the AOA paradigm, Gas Cards (SBTs) and community gas tokens (xPNTs) are issued by communities using open-source infrastructure; any DAO, game, or wallet can permissionlessly deploy this infrastructure and distribute Cards to their members. Crucially, acquisition is onetime rather than per-transaction: once a user holds a Card, subsequent sponsored transactions proceed without any further acquisition step, converting an otherwise perpetual per-transaction friction into an amortized onboarding cost. We therefore do not eliminate the initial “acquire an asset” action; instead, we move it from a recurring, gatekeeper-mediated cost to a one-time, permissionless setup. This shift is structurally decentralized, not a superficial relabeling. 2.2. Technical Foundations: Account Abstraction and Fee Mechanisms—Ethereum wallet addresses have reached 300 million.20 Account Abstraction (AA), and ERC-4337 in particular,7 introduces the Paymaster primitive for gas sponsorship. The ERC-4337 pipeline routes a UserOperation through a mempool and a Bundler into the EntryPoint, which validates the Smart Account and the optional Paymaster before execution (Figure 3); reference implementations of the singleton entrypoint and verifying paymaster are available.21, 22 2.2.1. Account Abstraction Standards in Context—The AA ecosystem now spans three tiers. Application-layer standards include ERC-4337 as the dominant production standard and ERC7562 for validation-phase restrictions protecting bundlers from DoS. Bridge mechanisms include 5

Fig. 3. Standard ERC-4337 Architecture. The EntryPoint coordinates validation

between the Smart Account and optional Paymaster. EIP-770223 in the Prague/Electra (Pectra) upgrade (activated May 7, 2025), which allows existing EOAs to temporarily function as smart accounts,24 alongside Passkeys/WebAuthn and Walletas-a-Service.25–27 Emerging protocol-level proposals for Native AA include RIP-756028 with supporting specifications RIP-7711 (bundle transaction type) and RIP-7712 (two-dimensional nonce) for L2s, EIP-770129 for Ethereum Mainnet, and EIP-8141 Frame Transaction,30 a Draft proposal under discussion for the Glamsterdam upgrade as of early 2026. While Native AA promises greater efficiency, ERC-4337 remains the dominant production standard today. Our research optimizes the user experience within ERC-4337 while remaining forward-compatible with Native AA. Surveys of ERC-433731, 32 report that its security benefits (social recovery, multi-sig validation) are widely recognized, but its usability impact remains mixed: Paymasters are typically deployed as Service Providers rather than Asset Issuers, producing session-scoped sponsorship that fails to compose across dApps.33 Native AA proposals absorb the bundler role into the execution layer but remain silent on who decides sponsorship eligibility. The paymaster-signer authority question—which user gets sponsored and under what conditions—is orthogonal to bundler-layer changes and persists regardless of the native AA timeline. AOA therefore retains independent contribution value in a post-Native-AA world. 2.2.2. Transaction Fee Mechanisms and the Mental Model Gap—The transition from first-price auctions to EIP-1559 improved the predictability of inclusion34 but introduced a twovariable cognitive burden (base fee + tip) that empirical analyses find non-trivial for non-expert users.35 At a more fundamental level, the mental model of “bidding for blockspace” is misaligned with users’ everyday expectation of “paying a fixed price” or using a prepaid service;10 this mismatch is a direct source of cognitive friction, as described by Sweller.36 This motivates an asset-based mental model in which the user sees balance rather than bids. 2.3. State-of-the-Art Analysis— 2.3.1. Incomplete Abstractions in Current Solutions—Existing academic and industry solutions from providers such as Pimlico,37 Alchemy,38 Biconomy,39 Stackup,40 and Coinbase41 have driven real progress in modular smart accounts,42 but most present an incomplete abstraction characterized by two recurring properties. First, leaky abstraction: users may no longer need ETH, but may need to acquire specific dApp-supported stablecoins or manage per-application gas tanks. Second, fragmented experience: gas sponsorship is typically tied to a specific dApp or vendor, so a seamless experience in one application does not carry over to another. 2.3.2. Industry Implementations and Market Concentration—Table 1 compares existing solutions against SuperPaymaster along five dimensions that matter for the research questions.

6

Table 1. Comparison of Industry Account Abstraction Solutions. Dimension

Alchemy38

Pimlico37

Biconomy39

SuperPaymaster (Ours)

Core Paradigm

Process-Oriented

Process-Oriented

Process-Oriented

Asset-Oriented

Sponsorship Gate

Off-chain API sig- Off-chain API sig- Off-chain API sig- On-chain SBT + denature nature nature terministic policy

Custom ERC-20 Gas

Yes swap)

(on-chain

Yes swap)

(on-chain

Limited (restricted token list)

Yes (Zero-Approve, no swap)

Paymaster-Signer Cen- No sorship Removed

No

No

Yes

Community-Issued

No

Limited

Yes (Permissionless)

Limited

The ERC-4337 paymaster market shows significant concentration across both dimensions. By transaction volume (Figure 4), a single provider (Alchemy) processes over 71% of all sponsored UserOperations—largely driven by high-volume, low-cost batch operations. By economic weight (total gas spend, Figure 5), the distribution is more balanced but still concentrated: the top three providers (Coinbase, Pimlico, Unknown) collectively account for over 62% of all paymaster gas expenditure.8 Both dimensions create long-term risks of monopoly, censorship, and systemic vulnerabilities analogous to MEV centralization.43

Fig. 4. Paymaster market concentration by UserOps volume. (Data source: Bundle-

Bear ERC-4337 Paymasters,8 retrieved February 2026.) 2.3.3. Cost and Scalability Considerations—High AA gas costs on Layer 1 necessitate Layer 2 deployment. Thibault et al.44 show that rollups reduce fees by 20–100× relative to Ethereum Mainnet, so we target L2 and report efficiency primarily in L2 execution gas units, complemented by receipt-level fee decomposition on OP Stack (L2 execution + L1 data availability + protocol overhead) when discussing end-user cost. 2.4. Research Gap—A clear gap emerges from this review: no existing gas payment solution simultaneously (i) reduces cognitive load (improving PEOU) and (ii) removes off7

Fig. 5. Paymaster market concentration by gas spend. (Data source: BundleBear,8

retrieved February 2026.) chain paymaster-signer authority from the sponsorship validity path. POA solutions trade trust-boundary size for convenience through centralized intermediaries; EOA models preserve decentralization but fail on usability. SuperPaymaster targets this gap through Asset-Oriented Abstraction instantiated as a Gas Card, offering prepaid-card usability with deterministic on-chain eligibility rules.

3.

Methodology

This research follows the Design Science Research (DSR) methodology of Peffers et al.,45 anchored by the seven design-science guidelines of Hevner et al.46 and the Framework for Evaluation in Design Science (FEDS) of Venable et al.47 Per FEDS, our evaluation is ex-post (evaluating a deployed artifact), artificial (controlled test harnesses and selected mainnet UserOps rather than broad in-the-wild usage), and summative (assessing whether the artifact achieves its design objectives). Our process iterates through the six standard DSR activities: problem identification (§1), objective definition (§2), design and development (§4), demonstration (controlled local environment plus Optimism Mainnet, §5), evaluation (mixed-evidence measurement against baselines, §5), and communication (§6–7). 3.1. Evaluation Strategy—To answer the research questions, we employ Empirical Benchmarking and Analytical Evaluation. Empirical Gas Profiling executes real transactions on Optimism Mainnet and a local Anvil network to produce deterministic, receipt-level gas measurements. Economic Scenario Analysis applies real-world market variables (gas-price and ETH-price volatility) to those measurements to reason about cost sensitivity under varying network conditions.

8

3.1.1. Experimental Setup—We define three workflows for a standard ERC-20 “Token Transfer” task: • Baseline A: Standard EOA ERC-20 Transfer on Optimism Mainnet (qualitative grounding; not directly comparable to UserOperations because execution paths differ fundamentally). • Baseline B: Centralized gasless services using standard ERC-4337 paymasters (Alchemy as API-verified representative; Pimlico as DEX-routed ERC-20 paymaster representative), sampled from on-chain UserOperationEvent logs filtered for single-UserOp bundles with ERC-20 transfer selector. • Workflow C (SuperPaymaster): The user holds a Gas Card (SBT) and xPNTs gas tokens and simply initiates the transaction. For Workflow C we executed repeated transactions on Optimism Mainnet and logged receiptlevel fee decomposition for two operation types: T1 (gasless token transfer via PaymasterV4 in prepayment mode) and T2.1 (gasless payment via SuperPaymaster in normal mode, which burns the user’s community gas token). Each operation type was executed N = 50 times to support descriptive statistics, bootstrap confidence intervals, and non-parametric effect size estimation in §5. The primary evaluation compares SuperPaymaster (T2.1) against industry POA baselines (Alchemy Gas Manager and Pimlico ERC-20 paymaster, n = 50 each) to validate AOA’s economic viability relative to the dominant process-oriented paradigm. The T1 (PaymasterV4) data serves as an internal cost-decomposition reference to isolate the gas overhead of specific AOA components (SBT verification, rate limits, credit state), since both PaymasterV4 and SuperPaymaster belong to the same AOA family and both remove the off-chain signer dependency. Experiment E1 — Paymaster-Signer Decentralization. To validate that sponsorship eligibility does not depend on an off-chain paymaster signing server, a primary Relayer A is configured to blacklist the user’s address and refuse to forward requests; the client automatically retries via a secondary honest Relayer B. Success is defined as successful on-chain mining via Relayer B without any new paymaster-server signature or discretionary approval. We distinguish bundler/relayer censorship (bypassable in principle: users can switch bundlers/relayers or, in some cases, submit directly to the EntryPoint via RPC; this role is also being absorbed into the execution layer by Ethereum’s native AA roadmap) from paymaster-signer censorship (a hard gate: if sponsorship validity depends on an off-chain signature, switching relayers cannot help when the signer refuses to approve). SuperPaymaster targets this hard bottleneck by moving sponsorship validity on-chain. 3.1.2. Evaluation Propositions and Metrics—Rather than framing the study as formal statistical hypothesis testing, we evaluate three propositions aligned with the evidence types: • P1 (Paymaster-signer gate removal). A Gas Card-based sponsorship eligibility rule enables transactions to remain valid without a discretionary off-chain paymaster signing service; non-cooperative relayers can be bypassed via failover when an alternative relayer is available. • P2 (Analytical usability improvement). The modeled workflow reduces interaction steps and extraneous cognitive operators related to gas management (GOMS-based analytical evaluation). • P3 (Comprehensive-cost trade-off). Moving sponsorship authorization on-chain in-

9

troduces measurable validation overhead relative to industry POA paymasters that rely on lightweight off-chain ECDSA signing, but can reduce comprehensive user cost by eliminating DEX-routed token liquidation paths and recurring ETH-balance management friction. We measure four dependent variables: Interaction Steps (S), a proxy for cognitive load; Total Time (T ) for efficiency; Total Cost (C) including gas fees, exchange fees, and service premiums; and Censorship Resilience (CR), a binary success/fail metric. 3.1.3. Data Analysis—Gas measurements are deterministic on-chain values tied to a specific execution harness (contract version, chain state, and bundler configuration; see Appendix I), so we treat them as engineering measurements and do not apply inferential significance testing.48 We report descriptive statistics (mean, median, σ ), bootstrap 95% confidence intervals (10,000 resamples)49 to quantify estimation uncertainty without distributional assumptions, nonparametric Cliff’s δ with standard thresholds (|δ | < 0.147 negligible, < 0.33 small, < 0.474 medium, ≥ 0.474 large)50 for pairwise effect sizes, and skewness/excess kurtosis for distribution diagnostics. Non-overlapping 95% CIs between systems are treated as evidence of a robust difference, consistent with engineering measurement conventions.48

4.

Artifact Design

4.1. Scope and Reproducibility—The evaluated artifact comprises on-chain components (Registry, SuperPaymaster, PaymasterV4, Gas Card SBT, xPNTsFactory, optional BLS Aggregator) and off-chain components (ERC-4337 Bundler, community Relayer/Operator, and SDK data-collection scripts). The Relayer is not a validity gate: payment eligibility is enforced on-chain. Canonical deployment addresses are listed in Appendix H, source repositories in Appendix J, and exact reproduction commands in Appendix K. The artifact enforces four invariants that tie its behavior to its threat model (§4.7): (1) No discretionary signature. Eligibility is determined by contract state (SBT ownership plus configured token policy), not by an operator signature that can censor specific users. (2) Cost cap. A cost cap bounds paymaster exposure per operation and uses the capped value for settlement. (3) Token sufficiency. A token sufficiency check prevents sponsorship unless the user can settle the required amount under supported-token and allowance constraints. (4) Replay safety. Replay safety at the AA layer is enforced by ERC-4337 UserOperation nonce rules, so the paymaster validates only sponsorship-specific constraints. 4.1.1. Two AOA Modes: PaymasterV4 and SuperPaymaster—The artifact provides two deployment modes within the AOA paradigm. PaymasterV4 is a single-community paymaster: the community deploys its own contract, manages its own ETH deposit, and configures a supported gas token. It requires Solidity development and DevOps capacity for deployment, funding, and monitoring. SuperPaymaster is a multi-community public infrastructure: communities register via a shared Registry and issue gas tokens through the xPNTsFactory without deploying any contracts. An operator manages the shared ETH deposit pool, reducing per-community operational overhead to near zero. Both modes remove the off-chain paymaster signer and share the AOA core property of on-chain eligibility verification. SuperPaymaster extends PaymasterV4 with SBT-based identity

10

binding, rate-limit governance, and multi-community management interface—features that support permissionless multi-community use but add ∼13k gas to the validation step (§5.3). The trade-off is explicit: higher on-chain verification cost in exchange for lower operational cost and broader accessibility. Table 14 (Appendix N) provides a detailed feature-by-feature comparison. 4.2. Design Principles—SuperPaymaster is built on four design principles, three grounded in HCI theory51–53 and one in the ecosystem’s structural requirement: 1. Asset-Centricity. Encapsulate sponsorship capability in a persistent, portable asset (the Gas Card), shifting control from service provider to user. 2. Metaphor Consistency. Adhere strictly to the prepaid-card metaphor: a Card works across merchants in the physical world and, in the on-chain analogue, across dApps that integrate the SuperPaymaster sponsorship interface. 3. Invisible Complexity. Bridge Norman’s gulf of execution12 by hiding the machinery— users see a balance, not Gwei or gas limits. 4. Permissionless Open Infrastructure. All core components are released under an opensource licence; any community can deploy its own Gas Card, paymaster, and gas token (or wrap an existing ERC-20) permissionlessly, with no gatekeeper authority over issuance. 4.3. System Architecture—The SuperPaymaster architecture is composed of three layers (Figure 6). The Asset Layer holds the Gas Card SBT (a non-transferable ERC-721 bound to a Smart Account, preventing theft and keeping reputation with the user) and the xPNTs gas token (an ERC-20 following the OpenPNTs protocol). The Protocol Layer contains the Registry, the SuperPaymaster contract (the on-chain verifier integrated with the ERC-4337 EntryPoint), and the EntryPoint itself. The Service Layer contains the Bundler, community Relayers/Operators, and Analytics/Monitoring services; the Service Layer is not a validity gate. 4.3.1. Paymaster Validation Pipeline—SuperPaymaster’s sponsorship validity does not rely on a discretionary off-chain signing server. Instead, it is enforced by deterministic on-chain state evaluation under ERC-4337 validation constraints. The validation pipeline proceeds through five stages: 1. Identity and asset verification. Eligibility is checked against on-chain Gas Card ownership and/or cached eligibility state. If SBT Balance of the sender is zero, or the cached eligibility flag is false, the transaction reverts. This step reads up to three storage slots (SBT ownership, eligibility cache, rate-limit counter) and constitutes the primary gas overhead relative to a minimal paymaster that performs only ECDSA verification. 2. Operator configuration resolution. The paymaster resolves the operator’s configured parameters—supported token list, exchange rate, per-card spending cap, and rate-limit window—from the Registry. These reads are O(1) SLOAD operations but contribute ∼5k gas cumulatively. 3. Cost estimation and capping. The paymaster computes a capped cost CappedCost = min(RequestedMaxCost, ProtocolHardCap), bounding exposure per operation. 4. Settlement capability verification. If the sender’s GasToken balance falls below CappedCost, the transaction reverts. This ensures the user can settle the expected cost through configured gas-token rules. 5. Execution and accounting. Settlement is applied via atomic token burn (xPNTs) and internal treasury transfer (aPNTs) under the configured policy mode; EntryPoint then

11

Fig. 6. SuperPaymaster three-layer architecture. Sponsorship validity is enforced at

the Protocol Layer; the Service Layer handles inclusion, not authorization.

12

executes the primary payload. Trace-level analysis reveals that validatePaymasterUserOp consumes approximately 48,625 gas for SuperPaymaster—compared to ∼16,000 gas for the off-chain ECDSA check in industry API-signature paymasters (e.g., Alchemy Gas Manager) and ∼35,549 gas for the same-family PaymasterV4. The ∼32k gas delta against ECDSA-based POA paymasters is the measurable on-chain execution cost of replacing the off-chain signer with deterministic state verification (SBT ownership, rate-limit counters, operator configuration, and credit-balance lookups). The ∼13k delta against PaymasterV4 isolates the additional cost of SuperPaymaster’s SBT eligibility and credit-state logic within the AOA family. This trace-level attribution is drawn from representative transactions on Optimism Mainnet (see Appendix L for transaction hashes). 4.3.2. Contract Dependency Graph—The core contracts form a layered logical dependency structure (Figure 7). At the base, the GToken (ERC-20 governance token) feeds into GTokenStaking (staking, lock, and slash logic) and the Registry (community configuration hub). The MySBT contract (Soulbound Token with reputation) depends on GToken, GTokenStaking, and Registry. The SuperPaymaster contract orchestrates gas sponsorship and is logically anchored to all four lower-layer contracts; the xPNTsFactory (gas token factory) is jointly controlled by SuperPaymaster and Registry. To respect the ERC-4337 / ERC-7562 validation-phase storage rules at runtime, the deployed SuperPaymaster (v3.2.2 on Optimism Mainnet) does not perform live cross-contract SLOADs into these lower-layer contracts during validatePaymasterUserOp. Instead, SBT-eligibility status is mirrored into a sbtHolders mapping inside the paymaster’s own storage (written by the Registry via the authorized updateSBTStatus entry point), and the ETH/aPNTs price is mirrored from Chainlink/DVT into a cachedPrice struct (written by an off-chain keeper through updatePrice/updatePriceDVT). The validation-phase entry point therefore reads only paymaster-self storage. This layered design ensures that each contract has a minimal, well-defined trust surface, while the mirror-and-stake pattern keeps the hot path bundler-compatible. §5.1 provides the per-rule mapping. 4.3.3. Core Object Relationships—Figure 8 illustrates the core object relationships across the three architectural layers. 4.3.4. Service Discovery and Community Modes—SuperPaymaster supports two operational modes. In Standard Mode, the SDK resolves the SuperPaymaster contract via the sp*.aastar.eth ENS entry point; operator configuration and supported-token lists are read from the Registry. Figure 9 shows the service discovery flow. In Open Community Mode, any community can permissionlessly deploy its own Gas Card and gas token via the xPNTsFactory and register it in the Registry. Figure 10 shows this flow. 4.3.5. Economic Circulation—The gas-payment loop becomes positive-sum when the marginal value of verified engagement exceeds the marginal cost of sponsorship. Communities pay gas via xPNTs allocation, and in return receive task completion, governance participation, or attention from the sponsored users. Figure 11 illustrates this circulation. 4.4. Zero-Approve Gas Token Architecture—A significant efficiency advantage stems from the xPNTs token’s built-in Auto-Approved Spender mechanism. In contrast to commercial ERC-20 paymasters (e.g., Pimlico) that require on-chain approve() plus DEX swap/transfer in postOp, xPNTs eliminates both: 1. Zero approve() transactions. The token’s allowance() returns uint256.max for trusted contracts (SuperPaymaster, Factory, MySBT), removing the separate approval 13

Fig. 7. Contract dependency graph. Arrows indicate read/callback dependencies

between on-chain contracts.

14

Fig. 8. Core object relationships across the Asset, Protocol, and Service layers.

Fig. 9. Service discovery flow via ENS resolution and Registry lookup.

15

Fig. 10. Open Community Mode: permissionless Gas Card and gas token issuance

flow.

Fig. 11. Economic circulation: community gas sponsorship creates a positive-sum

engagement loop. transaction (∼46,000 gas saved per first interaction). 2. Zero on-chain swap. Commercial ERC-20 paymasters must swap user tokens to ETH via on-chain DEX during postOp (+∼150,000 gas); SuperPaymaster burns the user’s xPNTs and transfers the equivalent aPNTs to the protocol treasury in a single atomic postOp step, avoiding any swap. 3. Firewall security. Despite unlimited allowance, a transferFrom firewall restricts auto-approved spenders to transfer funds only to themselves or to the registered SuperPaymaster address, preventing unauthorized extraction. A per-transaction cap (MAX SINGLE TX LIMIT, set to 5,000 ether in token units) acts as a circuit-breaker against implementation bugs. 4. UserOpHash authentication. The paymaster’s validatePaymasterUserOp receives and verifies the userOpHash, binding each sponsorship decision to a specific UserOperation and preventing replay or cross-operation misuse. The auto-approved spender list is not user-modifiable; adding or removing entries requires an authorized governance action (timelock/multisig). The per-transaction cap is a safety circuitbreaker, not an economic limit; community operators are expected to configure per-card spending caps at the SuperPaymaster policy layer to enforce economically meaningful bounds. This architecture directly explains the gas pattern observed in §5.3: SuperPaymaster’s L2 txGasUsed stays consistently near 167,830 gas, while Pimlico’s ERC-20 path varies between 226k and 638k gas because of its on-chain token swap. Table 2 contrasts the two settlement architectures to highlight the structural cost differences that drive the evaluation results in §5. 4.5. Design Alternatives Considered and Rejected—Before arriving at the SBT-based Gas Card architecture, we considered and rejected three alternatives, consistent with Hevner’s Guideline 6 (Design as a Search Process):46 (a) ERC-20 Voucher Tokens. A transferable ERC-20 voucher representing prepaid gas credits was rejected because transferable vouchers create secondary markets that incentivize Sybil farming (mint vouchers via fake accounts, sell on DEX). Non-transferability (SBT) eliminates 16

Table 2. Architectural comparison of ERC-20 Paymaster (DEX-routed) vs Super-

Paymaster (Zero-Approve) settlement paths. Dimension

ERC-20 Paymaster (Pimlico- SuperPaymaster style) Approve)

Token settlement

On-chain DEX swap (Oracle → Approve → Swap)

(Zero-

Internal SSTORE (account ledger: burn xPNTs + transfer aPNTs to treasury)

Gas overhead

∼100k+ gas for swap sequence

O(1) storage write (∼5k gas)

Price dependency

Real-time DEX liquidity

Operator-set rate (auditable onchain)

User approval

ERC-20 approve() required

No approval Approve)

Censorship surface

DEX + oracle + router contracts

Internal accounting only

needed

(Zero-

this attack vector while preserving the asset-ownership mental model. (b) Atomic On-Chain Swap at Validation Time. Performing a real-time token-to-ETH swap within validatePaymasterUserOp was rejected because DEX dependency adds ∼100k gas overhead per operation and introduces oracle manipulation and liquidity risks. This is the path taken by Pimlico-style ERC-20 paymasters, and our evaluation (§5.3) empirically demonstrates the gas cost of this approach. (c) Synchronous Off-Chain Settlement with On-Chain Fallback. A design where the paymaster first attempts off-chain settlement (via a trusted settlement server) and falls back to on-chain settlement on failure was rejected because it reintroduces the off-chain signer gate that AOA explicitly aims to remove. Any design where the “happy path” depends on an off-chain server preserves the censorship surface that motivates this research. These rejections shaped the final architecture: an on-chain SBT for identity binding, an internal account ledger for atomic settlement (burn xPNTs + aPNTs transfer to protocol treasury), and UserOpHash-bound sponsorship for replay safety. 4.6. User and Developer Journeys—For end users, the SuperPaymaster journey collapses traditional friction into a one-time setup plus single-tap execution: the user claims a Gas Card once, then interacts with any dApp that supports a standard ERC-4337 paymaster; the wallet automatically pays gas from the Card and the transaction confirms. There are no swaps, no bridges, and no insufficient ETH errors—complexity is absorbed by the artifact. For developers, integration requires only the SDK pointing to the single sp*.aastar.eth ENS entry point, which resolves to the SuperPaymaster contract and auto-selects a paymaster; complexity of paymaster selection is handled on-chain. Figure 12 illustrates the developer integration path.

Fig. 12. Developer journey: SDK integration via ENS entry point simplifies pay-

master selection.

17

4.7. Threat Model—The SuperPaymaster design addresses six threat vectors within its scope. (i) Sybil Attacks on Gas Card Issuance. Sybil attacks are mitigated by SBT non-transferability combined with issuer-level verification enforced through the community Registry. Because Gas Cards cannot be transferred or sold, an attacker cannot accumulate sponsorship capacity across fake accounts without individually passing each community’s issuance criteria. Each account registration requires burning a small amount of GToken, raising the cost of batch account creation. (ii) Gas Card Theft or Compromise. The SBT is non-transferable by design, so payment eligibility is immutably bound to the owner’s Smart Account. Key recovery is provided by the account’s programmable spending controls and social-recovery mechanisms (outside this paper’s scope). An attacker who compromises the account key gains access to the Card, but this is equivalent to general account compromise and is mitigated at the wallet layer. (iii) Paymaster Fund Drain. Malicious or buggy operations that attempt to drain the paymaster’s ETH deposit are constrained by MAX SINGLE TX LIMIT and operator-level circuit breakers that halt sponsorship on anomalous patterns. The per-transaction cap bounds worst-case exposure per operation. (iv) Centralized Sequencer Censorship. An L2 sequencer refusing inclusion is considered out of scope; the design inherits the underlying L1/L2 security assumptions and treats sequencerlevel inclusion as a separate concern (Section 6.1.3). Where the underlying rollup exposes a force-inclusion mechanism—e.g., OP Stack’s L1 deposit transactions, which allow an end user to force a UserOp into the L2 chain via the L1 OptimismPortal contract—a censored user retains a non-discretionary fallback path. This path requires no new paymaster-side signature, preserving the AOA censorship-resilience property at the rollup layer. (v) SBT Issuer and Registry Governance Centralization. The SuperPaymaster Registry that governs operator whitelisting and SBT issuance parameters introduces a governance centralization vector. The eligibility gate moves from an off-chain signer to the set of entities authorized to mint Gas Cards; a dominant issuer could still revoke or blacklist Cards, relocating rather than eliminating the censorship surface one layer up. Mitigation: Gas Cards are issued permissionlessly through MySBT when a user first registers with any community by burning GToken—no single issuer controls minting. Timelock on Registry parameter changes and multi-sig governance provide transparency; and if an issuer becomes non-cooperative, users can migrate to alternative Cards. We characterize this as decentralization-by-plurality rather than decentralization-by-construction. (vi) xPNTs Burn Safety. Because postOp atomically burns user xPNTs and transfers aPNTs to the protocol treasury, a malicious actor who somehow triggers postOp outside a valid UserOp context could attempt unauthorized burns. Three composed mitigations ensure that no xPNTs can be burned without a validly signed and verified UserOperation: • Caller restriction. The postOp function is callable only by the ERC-4337 EntryPoint contract (enforced by the inherited BasePaymaster access control), so external addresses cannot invoke it directly. • UserOp binding. Each sponsorship is bound to a specific userOpHash that is verified during validatePaymasterUserOp, ensuring that postOp settles only the operation it was authorized to settle. • Per-tx ceiling. MAX SINGLE TX LIMIT caps the xPNTs that any single sponsored 18

UserOp can burn, bounding the loss of any individual misbehaving operation.

5.

Evaluation

This chapter reports empirical and analytical results from our DSR evaluation activity. 5.1. Evaluation E1: Paymaster-Signer Decentralization (P1)—P1 targets a specific centralization layer: the off-chain paymaster signing server that POA services require for every sponsored transaction. BundleBear data8 shows a single provider processes 71% of all sponsored UserOperations; if that provider’s signing server refuses service or goes offline, those transactions cannot proceed—the signature is a hard validity gate at the ERC-4337 EntryPoint level. Architectural evidence. SuperPaymaster’s validatePaymasterUserOp performs zero off-chain calls. All eligibility reads are on-chain SLOAD operations confined to the paymaster’s own storage, satisfying the validation-phase self-storage rule formalized in ERC-7562 (STO-021 in the published rule index). Specifically, the deployed contract reads (i) operator configuration in operators[operator]; (ii) per-(operator, sender) state in userOpState; (iii) the cached price oracle in cachedPrice; and (iv) the SBT eligibility set in sbtHolders—all four reside in the paymaster’s own storage. Cross-contract dependencies on Registry, MySBT, GTokenStaking, and Chainlink are kept up to date by authorized writes outside the hot path: Registry.updateSBTStatus mirrors community SBT changes, while updatePrice/updatePriceDVT mirror Chainlink (or DVTaggregated BLS) feeds. The paymaster itself is staked at the EntryPoint (via addStake in BasePaymaster), which is the precondition under which the self-storage rule applies. This mirror-and-stake pattern is what makes the layered logical architecture of §4.3 bundler-compatible at runtime. The trust-dependency shift is summarized in Table 3: Table 3. Trust-dependency comparison. AOA moves the sponsorship validity gate on-chain; bundler and sequencer layers are identical in both models. Layer

POA (Alchemy-style)

AOA (SuperPaymaster)

Sponsorship valid- Off-chain API signature (hard ity gate)

On-chain SBT + policy state

Bundler/Relayer

Inclusion only (switchable)

Inclusion only (switchable)

Sequencer

L2 ordering (out of scope)

L2 ordering (out of scope)

Because sponsorship validity is determined entirely by contract state, any standard ERC-4337 bundler can process a SuperPaymaster-sponsored UserOp—the user is not bound to a specific service provider. Failover demonstration. To instantiate this architectural property, we conducted a failover simulation (N = 5 sequential attempts). Relayer A was configured as non-cooperative (all requests rejected with 403 Forbidden); Relayer B was cooperative. The client detected the failure, switched to Relayer B, and the transaction was executed on-chain with a ∼500 ms failover latency overhead—well within the 5–30 s median transaction confirmation window reported by Pacheco et al. for Ethereum-class networks.54 No new paymaster-server signature was required because none exists in the AOA model. Scope. This evidence validates that the off-chain paymaster signer is architecturally eliminated as a validity gate. It does not claim unconditional censorship resistance across all layers: 19

bundler selection, RPC access, and sequencer ordering remain separate inclusion surfaces (§6.1.3). Adversarial scenarios with sustained, coordinated attacks remain future work. Evidence supports P1. 5.2. Evaluation E2: Analytical Usability via GOMS (P2)—We employ the GOMS model (Goals, Operators, Methods, Selection rules)55 as an analytical evaluation of interaction complexity. Model A (Traditional EOA, failure-recovery path). A user encountering “Insufficient ETH” must: (M) perceive error; (M) decide strategy (bridge/swap/buy); (M) select external service; (P) navigate to it; (M) calculate amount needed under gas-price volatility; (P) execute swap/bridge; (W) wait for confirmation; (P) return to the dApp; (P) retry. Total: 4M + 4P + 1W. Cognitive load: High. Model B (SuperPaymaster, steady-state). (M) perceive transaction prompt; (P) click “Confirm” (Gas Card auto-deducts). Total: 1M + 1P. Cognitive load: Lower in the modeled workflow. The GOMS operator count reduction from 9 operators (4M + 4P + 1W) to 2 operators (1M + 1P) represents a 78% reduction in modeled interaction steps. The eliminated operators are exclusively gas-management steps (error recovery, service selection, amount calculation, swap execution, wait, return navigation) that are extraneous to the user’s primary intent of executing a token transfer. This reduction directly maps to Sweller’s concept of eliminating extraneous cognitive load.36 Scope and limitations. Model A captures the failure-recovery path (users acquiring gas tokens before retry); Model B captures steady-state usage after one-time Gas Card setup. Gas Card acquisition itself incurs a one-time onboarding cost, amortized across subsequent transactions. If the user already holds the required payment assets in both models, the EOA workflow also reduces to 1M + 1P; the GOMS comparison therefore illustrates the advantage of eliminating recurring gas-management operators, not a universal superiority claim. Operator counts are simplified step counts, not full GOMS timing predictions;55 we do not report operator-level timing estimates. Controlled user studies (SUS, NASA-TLX, task-completion and error rates) remain future work (§6.5). Evidence supports P2. Figure 13 visualizes the multi-dimensional friction comparison across the three workflows on the Steps, Cognitive Load, and Cost dimensions, summarizing the GOMS-derived ordinal estimates discussed above. 5.3. Evaluation E3: Gas Profiling on Optimism Mainnet (P3)—All measurements below are sourced from on-chain UserOperationEvent logs under the controlled conditions defined in §3.1; raw data and collection scripts are in Appendix K, and transaction hashes for independent verification are in Appendix L. Table 4 summarizes empirical L2 execution gas for each operation type (n = 50 per system, single-UserOp bundles with ERC-20 transfer selector). Figure 14 visualizes the means. Table 5 decomposes the ERC-4337 billing metric (actualGasUsed) into pure L2 execution gas (txGasUsed) and PVG overhead. Because PVG scales with bundler pricing strategies rather than paymaster architecture, extracting txGasUsed provides a more controlled basis for comparing architectural efficiency. Primary comparison: AOA vs industry POA baselines. The central evaluation question is whether AOA can achieve competitive gas efficiency while eliminating the off-chain pay20

Fig. 13. Multi-dimensional friction comparison across three workflows on three

dimensions (Steps, Cognitive Load, Cost; lower is better). The three bar groups, from highest to lowest friction, correspond to: EOA-direct (red, scores 10/9/9), POA paymaster (amber, 4/6/7), and AOA Gas Card (green, 2/2/3). Scores are GOMS-derived ordinal estimates over the workflows analyzed in §5.2, not absolute units.

Table 4. L2 execution gas (txGasUsed) per operation type with bootstrap 95% CIs (B=20,000). The metric is pure on-chain execution gas, stripping bundler PVG so that paymaster-architecture differences are not confounded with bundler pricing. Total billed gas (actualGasUsed) and its decomposition appear in Table 5. Operation

Label

n

EOA ERC-20 Transfer (USDC)

A EOA

50

Gasless terV4)

Transfer

(Paymas- T1

50

txGasUsed (mean ± 95% CI) Notes 43,334 ± 1,492 OP Mainnet direct transfer 152,008 ± 5 Prepayment mode

Gasless Payment (SuperPay- T2.1 master Normal)

50

167,830 ± 7

Alchemy (API-Verified)

B1 Alchemy

50

205,951 ± 3,222

EntryPoint v0.6 samples

Pimlico (DEX-Routed ERC- B2 Pimlico 20)

50

328,937 ± 21,679

EntryPoint v0.7 samples

21

Burns community gas token

L2 gas used (mean values) for each operation type (95% CIs in Table 4). All operations on OP Mainnet with receipts collected via eth getTransactionReceipt. Full trace analysis in Appendix L. Fig. 14.

Table 5. Gas decomposition. The PVG disparity between SuperPaymaster (∼119k)

and Alchemy (∼51k) reflects different bundlers: SuperPaymaster used a standard open-source bundler (Stackup/Rundler), while Alchemy samples were processed by Alchemy’s proprietary bundler with optimized PVG estimation. Differences in actualGasUsed therefore compound bundler-level pricing and paymaster architecture. Operation

Label

Billed (actualGasUsed)

Execution (txGasUsed)

EOA ERC-20

A EOA

N/A

43,334

N/A

PaymasterV4

T1

271,092

152,008

119,084

SuperPaymaster

T2.1

286,818

167,830

118,988

Alchemy

B1 Alchemy

257,299

205,951

51,348

Pimlico

B2 Pimlico

387,129

328,937

58,192

22

PVG overhead

master signer. We compare SuperPaymaster (n=50) against two representative industry POA paymasters—Alchemy Gas Manager (n=50, API-signature model) and Pimlico ERC-20 paymaster (n=50, DEX-routed model)—all on Optimism Mainnet, filtered for single-UserOp bundles with ERC-20 transfer selector. The industry samples are treated as vendor-as-deployed baselines rather than account-type-controlled experiments. In particular, Alchemy Gas Manager traffic is tightly coupled with Alchemy’s account stack, and our chain-level audit found the sampled Alchemy senders to be Alchemy modular/LightAccount-style accounts rather than SimpleAccount instances. We therefore interpret account-type heterogeneity as a residual confound and report both actualGasUsed (ERC-4337 billing) and txGasUsed (pure L2 execution, stripping bundler PVG noise) to separate ERC-4337 billing effects from L2 execution costs. Three structural cost drivers emerge: 1. SuperPaymaster vs DEX-routed paymasters (Pimlico, mean actualGasUsed 387k; mean txGasUsed 329k). SuperPaymaster replaces Pimlico’s Oracle → Approve → Swap sequence—which alone costs ∼100k+ gas per transaction—with an O(1) internal SSTORE settlement (∼5k gas). The DEX-liquidation path is an architectural requirement of Pimlico’s paymaster model, not a tunable choice; this constitutes a genuine structural advantage. In pure L2 execution, SuperPaymaster (168k) is less than half of Pimlico (329k). 2. SuperPaymaster vs API-signature paymasters (Alchemy, mean actualGasUsed 257k; mean txGasUsed 206k). Trace-level decomposition (§4.3) isolates the paymasterspecific cost: Alchemy’s validatePaymasterUserOp is a ∼16k-gas ECDSA check backed by off-chain signing infrastructure; SuperPaymaster’s validation is a ∼48k-gas onchain state resolution. The ∼32k-gas delta is the measurable execution cost of removing the off-chain signer gate. Because the Alchemy sample reflects its vendor-as-deployed account stack, this comparison should be read as an industry baseline rather than a strict account-type-controlled causal contrast. AOA’s structural avoidance of the DEX liquidation path remains the primary architectural advantage, while the validation cost itself is comparable. 3. PVG (bundler pricing) explains the remaining gap in actualGasUsed. SuperPaymaster’s actualGasUsed (287k) exceeds Alchemy’s (257k) despite lower L2 execution. The difference traces to pre-verification gas (PVG): our open-source bundler reserves ∼119k PVG versus Alchemy’s optimized bundler at ∼51k. PVG is a bundler pricing parameter, not a paymaster architectural property. Table 13 (Appendix M) confirms L1 data fees account for ∼8% of total ETH cost and PVG 31–38% of billed gas. Table 6 maps this onto execution modules. Representative transaction traces (hashes listed in Table 12 of Appendix L) confirm the decomposition. Table 6. Transaction-level trace decomposition. Execution Module

Alchemy (API-Verified)

SuperPaymaster (Normal)

Account Validation

∼12,000

∼12,000

Note SimpleAccount vs Alchemy modular/LightAccount

Paymaster Validation

∼16,000

∼48,625

On-chain SBT/credit vs. off-chain ECDSA

Operation Execution

∼45,000

∼47,000

ERC-20 transfer

EntryPoint + PVG Overhead

∼184,000

∼179,000

Bundler packaging

Total Billed (actualGasUsed)

∼257,000

∼286,000

Internal cost decomposition (PaymasterV4 as same-family reference). PaymasterV4 is

23

an earlier AOA implementation from the same project that also removes the off-chain signer; it therefore cannot serve as a POA baseline. However, comparing T2.1 (SuperPaymaster, mean actualGasUsed 286,818) against T1 (PaymasterV4, mean 271,092)—using identical EntryPoint v0.7, SimpleAccount, and bundler—isolates the additional gas cost of SuperPaymaster’s SBT eligibility, rate-limit, and credit-state logic: +15,726 gas (+5.80%). Trace-level decomposition attributes this to validatePaymasterUserOp (SuperPaymaster ∼48,625 vs PaymasterV4 ∼35,549; delta ∼13,076 gas). This internal decomposition clarifies where the gas goes within the AOA architecture, but the contribution validation rests on the AOA-vs-POA comparison above. Statistical analysis. Cliff’s δ for the AOA-family comparison (T1 vs T2.1) is −1.000 (large), reflecting complete separation—gas differences are structural properties of the validation logic rather than random variation. Distribution diagnostics (T1: σ ≈ 0, deterministic; T2.1: σ ≈ 430, range 1,704 gas; T1 skewness γ1 = 0.70; T2.1: γ1 = 0.02) support means as reliable estimates. The PVG-and-L1-fee decomposition is provided in Appendix M; L1 data fees account for ∼8% of total ETH cost under the current post-Dencun blob regime,56 and PVG (bundler overhead) is 31–38% of billed gas. Key finding on efficiency vs. decentralization. SuperPaymaster demonstrates that on-chain sponsorship validation is economically viable relative to industry POA paymasters. The ∼32k gas validation overhead versus ECDSA-based POA is the bounded, predictable cost of eliminating the centralized signer—a trade-off the architecture explicitly pays. Against DEX-routed POA, SuperPaymaster achieves lower L2 execution cost by replacing the Oracle → Approve → Swap sequence with an O(1) internal SSTORE. Beyond on-chain gas, SuperPaymaster converts gas payment into a programmable asset layer (Gas Card + community gas token), enabling invisible payment, policy-controlled sponsorship, predictable interaction under fee volatility, and a community value loop where gas spend can be funded by community incentives rather than forcing users to acquire ETH. Evidence supports P3. 5.4. Qualitative Analysis: Trust Architecture—Moving from POA to AOA relocates the trust boundary at the sponsorship layer. In POA the flow is User → off-chain server (API) → blockchain, requiring trust that the server will not censor specific addresses or refuse to sign.57 In AOA the flow is User → on-chain asset (Gas Card) → blockchain; validation is deterministic and requires no off-chain signature. Relayers and bundlers still influence inclusion, but they cannot retroactively invalidate a UserOp that satisfies on-chain eligibility. This narrows the trust boundary at the sponsorship layer while leaving inclusion-layer surfaces (bundler selection, sequencer ordering) as separate concerns (§6.1.3). 5.5. Summary—The evaluation indicates that the asset-oriented paymaster design can (i) remove discretionary paymaster-signer authority from sponsorship validity (P1); (ii) reduce modeled interaction complexity in gas-payment workflows (P2); and (iii) achieve competitive gas efficiency against industry POA baselines—lower L2 execution gas than both API-signature and DEX-routed paymasters—while paying a bounded ∼32k gas validation overhead as the measurable cost of on-chain eligibility verification (P3).

24

6.

Discussion

6.1. Interpretation of Findings—Our evaluation provides evidence that the asset-oriented paymaster design addresses three dimensions of the research problem—comprehensive economic cost, modeled cognitive load, and centralized paymaster-signer authority—with distinct but complementary evidence types. 6.1.1. Reducing Economic Cost (Comprehensive, Not Only Gas Units)—SuperPaymaster’s primary advantage is not minimizing raw on-chain execution gas relative to the EOA physical floor, but removing recurring categories of user friction: preparatory cost (acquiring ETH, navigating fee markets) and dApp-specific setup cost (token approvals, per-application gas tanks) common in session-scoped POA models. The gas profiling shows that this friction removal comes at a bounded architectural cost. Trace-level decomposition isolates a ∼32k gas validation overhead versus ECDSA-based POA paymasters—the measurable price of on-chain eligibility verification. Yet in pure L2 execution (txGasUsed), SuperPaymaster achieves the lowest gas among all evaluated AA paymasters (168k vs Alchemy 206k vs Pimlico 329k), because AOA eliminates the DEX liquidation path and uses a simpler account structure. The remaining actualGasUsed gap versus Alchemy traces to bundler PVG pricing, not paymaster architecture. This evidence suggests that the AOA paradigm can be economically viable while structurally eliminating the off-chain signer dependency. 6.1.2. Reducing Cognitive Load via Metaphors and Invisible Execution—The Gas Card metaphor, supported by the GOMS analytical evaluation (§5.2), addresses RQ2 by transforming an abstract, recurring technical process into a tangible, persistent capability. This shift from process to asset reduces the need for repeated context-dependent setup and decision-making. Beyond the visible metaphor, SuperPaymaster embodies Norman’s principle of invisibility:12 the best interaction is no interaction. By moving gas negotiation, relayer selection, and payment verification to the protocol layer (the “underwater” part of the iceberg), the user’s decision path collapses to a single confirmation. This invisibility is what minimizes extraneous cognitive load, allowing users to focus on their primary intent. GOMS evidence is analytical; large-scale user studies (NASA-TLX, SUS, error rates) remain necessary before claiming subjective satisfaction outcomes and are discussed as future work. 6.1.3. Narrowing the Trust Boundary at the Sponsorship Layer—Decentralization is multisurface; SuperPaymaster targets a durable bottleneck—paymaster-server signature authority as a validity gate. The failover simulation demonstrates that when an alternative relayer is available, a non-cooperative relayer cannot prevent execution of a valid sponsored transaction without obtaining a new discretionary signature from a centralized paymaster server. This does not imply unconditional censorship resistance in the full pipeline: bundler selection, RPC access, sequencer ordering, and client middleware remain potential inclusion bottlenecks. However, bundler/relayer censorship is bypassable in principle (users can switch bundlers or submit directly to the EntryPoint via RPC), whereas paymaster-signer censorship is not—it is the one gate that cannot be bypassed by simply choosing a different relay endpoint. 6.2. Theoretical Implications: The Asset-Oriented Paradigm—The most significant conceptual contribution is the conceptualization of Asset-Oriented Abstraction (AOA) as a design principle for Web3 UX. POA places a significant cognitive burden on users because sponsorship state must be re-established per process. AOA reifies that ephemeral process into a persistent,

25

tangible asset; instead of initiating a process to pay for gas, the user possesses a Gas Card that affords paying for gas. This aligns with Norman’s principle of affordance12 and bridges the Web2/FinTech mental model to Web3/Crypto implementation. According to Sweller’s Cognitive Load Theory,36 POA overloads working memory with transient state (pending approvals, current gas market, per-dApp token lists); AOA offloads this state onto the asset itself—the user checks “Card balance > 0” rather than reconstructing the process state. This is cognitive offloading, not elimination: the user retains a minimal monitoring task (balance awareness), which is substantially lower than multi-step process management. A concise way to state the core insight is that cognitive offloading does not require sovereignty offloading: the user delegates state-tracking to the Card without delegating sponsorship authority to a centralized server. The on-chain eligibility check incurs a ∼32k gas validation overhead compared to ECDSA-based off-chain signing in POA paymasters (§5.3), and we view this extra cost as the price of preserving sovereignty. It is also worth distinguishing the paymaster layer from the inclusion layer: even under on-chain sponsorship validity, inclusion still depends on bundler/sequencer behavior under ERC-4337. The Ethereum roadmap is actively absorbing the bundler into the execution layer itself, so over time that surface ceases to be an independent censorship bottleneck. The paymaster role—deciding who pays and under what conditions— remains a persistent economic role regardless of native AA, which is why decentralizing the sponsorship validity gate is the more durable contribution. 6.3. Practical Implications and Community Economics—For dApp developers, SuperPaymaster offers an open-source alternative to centralized paymaster services, with a simplified integration path via the SDK and a universal gas sponsorship solution without vendor lock-in. For end users, the design aims to reduce gas-related cost, latency, and cognitive load: the Gas Card provides a stable mental anchor that, prior literature suggests, can reduce the anxiety associated with blockchain interactions;58 controlled UX studies (SUS, NASA-TLX, task-completion) remain future work. At the community level, the gas-payment loop becomes positive-sum when the marginal value of verified engagement exceeds the marginal cost of sponsorship—communities pay gas via xPNTs allocation, and in return receive task completion, governance participation, or attention from the sponsored users. Whether this condition holds in practice depends on community-specific factors and requires empirical measurement (field studies of engagement value versus sponsorship cost), which we identify as future work. 6.4. Limitations—We acknowledge seven limitations. (i) L2 data costs. On Layer 2, the cost of posting calldata to L1 remains a significant fee component; SuperPaymaster optimizes execution cost but cannot eliminate this base data cost. (ii) Privacy. The current implementation reveals Gas Card balance and transaction history on-chain, which benefits auditability but raises a concern for privacy-sensitive users. (iii) Bootstrap centralization. While the protocol is permissionless and any community can deploy its own Card and paymaster, initial deployments rely on a limited set of relayers operated by AAStar; true decentralization requires a critical mass of independent community operators, which takes time to bootstrap. (iv) Lack of empirical user studies. Our cognitive-load evaluation relies on GOMS, an established analytical HCI method, but we have not yet conducted large-scale empirical studies (NASA-TLX, SUS) to validate subjective user satisfaction. (v) No component-level ablation. The trace-level decomposition above (paymaster validation pipeline) provides attribution of validatePaymasterUserOp cost across SBT verification, rate-limit, credit-balance, and operator-config reads, but we did 26

not deploy contract variants with each individual check disabled. We made this an explicit methodological choice for three reasons: disabling individual checks produces non-conformant ERC-4337 paymaster contracts whose gas measurements would be misleading; production traces on Optimism Mainnet provide stronger external validity than synthetic ablation contracts; and the released gas-profiling scripts allow independent reviewers to recompute per-component costs from on-chain data. Component-disabled benchmarks remain a useful direction for follow-up work in a controlled testnet harness. (vi) Empirical failure-case coverage is limited. Happy-path execution is verified on Optimism Mainnet (n = 50 per system), but adversarial paths—zero gastoken balance, revoked SBT mid-session, rate-limit exceeded, and operator-config change during a pending UserOp—are reasoned about analytically (Section 4.7) rather than empirically tested. Systematic adversarial fuzzing of these revert paths is left to future work. (vii) Account-stack heterogeneity in industry baselines. The Alchemy Gas Manager baseline reflects Alchemy’s vendor-as-deployed ecosystem rather than a SimpleAccount-controlled configuration. Our chainlevel audit found no SimpleAccountFactory-created accounts among 61,003 Alchemy Gas Manager UserOperations in the audited block range, while the observed traffic was dominated by Alchemy modular/LightAccount-style accounts. This is consistent with Alchemy’s paymaster and account infrastructure being deployed as an integrated stack. We therefore treat the Alchemy comparison as an external industry baseline, not as a strict isolation of account-type effects. The trace-level paymaster-validation comparison remains informative: Alchemy’s API-signature validation path costs approximately 16k gas, while SuperPaymaster’s on-chain state resolution costs approximately 48k gas, making the approximately 32k validation delta the observable cost of removing the off-chain signer gate. 6.5. Future Work—We propose three priority directions: (1) Zero-Knowledge Proofs to enable private gas sponsorship, letting users prove they hold a valid Card without revealing balance or identity to the relayer; (2) cross-chain interoperability (e.g., via LayerZero or CCIP) to turn the Card into a universal multi-chain asset, potentially laying groundwork for agent-toagent Web3 economies;59 and (3) controlled user studies (NASA-TLX, SUS, task-completion and error rates) to validate the analytical usability findings with subjective measures.

7.

Conclusion

7.1. Summary of Research—This paper set out to address the critical barrier of gas payment complexity in the Web3 ecosystem. We argued that the dominant pattern of Process-Oriented Abstraction produces fragmented experiences and leaky abstractions, ultimately hindering mass adoption. To resolve this, we proposed Asset-Oriented Abstraction (AOA) as a design principle that shifts the mental model from “managing a process” to “owning an asset,” and we instantiated the paradigm through SuperPaymaster—an ERC-4337 sponsorship system that binds eligibility to deterministic on-chain state (a Gas Card SBT plus policy state) rather than to an off-chain paymaster signing server. The design targets a specific, durable trust bottleneck: discretionary paymaster-signer authority as a validity gate. 7.2. Addressing the Research Questions—RQ1 (Decentralization). SuperPaymaster enforces sponsorship eligibility via on-chain state and executes without per-request centralized paymaster signatures. The failover simulation (§5.1) demonstrates that non-cooperative relayers can be bypassed when an alternative relayer is available, without a new discretionary paymaster-

27

server approval. This narrows the trust boundary at the sponsorship layer; it does not claim unconditional inclusion under all censorship surfaces. RQ2 (Usability). The GOMS analytical evaluation (§5.2) indicates that the Gas Card metaphor and invisible-execution design reduce modeled interaction complexity and extraneous gas-management operators in the steady-state workflow. This supports AOA as a plausible HCI pattern for Web3; subjective UX validation via controlled user studies remains future work. RQ3 (Efficiency). Mainnet gas profiling (§5.3) demonstrates that AOA achieves competitive efficiency against industry POA baselines. In pure L2 execution gas (txGasUsed), SuperPaymaster (167,830) is lower than both Alchemy Gas Manager (205,951) and Pimlico ERC-20 paymaster (328,937, n=50 each). Trace-level decomposition isolates the cost of decentralization: SuperPaymaster’s validatePaymasterUserOp (∼48,625 gas) adds ∼32k gas over Alchemy’s off-chain ECDSA check (∼16k gas)—a bounded, predictable trade-off for eliminating the centralized signer. Against DEX-routed paymasters, SuperPaymaster eliminates the Oracle → Approve → Swap liquidation path—saving the ∼100k+ gas that this on-chain token swap consumes per transaction. In total billed gas (actualGasUsed), SuperPaymaster (286,818) sits between Alchemy (257,299) and Pimlico (387,129); the gap to Alchemy is driven by bundler PVG pricing, not paymaster architecture. Comprehensive cost extends beyond gas units to include the eliminated preparatory steps (ETH acquisition, fee-market navigation) and per-dApp setup friction in realistic user journeys. 7.3. Contributions and Outlook—This paper makes three contributions: (1) a conceptual definition of Asset-Oriented Abstraction as a design principle for reducing cognitive load in decentralized systems; (2) the open-source SuperPaymaster artifact, including the Gas Card standard (OpenCards), the gas-token standard (OpenPNTs), and a competitive relayer SDK; and (3) a multi-method evaluation on Optimism Mainnet providing reproducible gas measurements against industry POA baselines (Alchemy Gas Manager and Pimlico ERC-20 paymaster), analytical usability evidence, and trust-boundary analysis of sponsorship validity gates. Building on §6.4, priority future directions are privacy-preserving sponsorship via ZKPs, cross-chain Gas Card interoperability, and empirical user studies. SuperPaymaster demonstrates that a user-centric gas sponsorship experience can be built without delegating sponsorship validity to centralized signing servers, providing a foundation for further research into scalable, privacy-preserving, and user-study-validated gas abstraction systems.

Acknowledgements The first author thanks his wife for her steadfast support, which has been the bedrock of focus throughout this research. He is also deeply grateful to his main advisor, Dr. Nathapon Udomlertsakul, for sharp insights, rigorous standards, and continuous mentorship that shaped this paper. The authors thank David Xu and the rest of the AAStar team and community; their robust engineering and reliable infrastructure made the empirical validation of this work possible.

Conflict of Interest The authors declare that they have no known conflicts of interest as per the journal’s Conflict of Interest Policy.

28

Notes and References 1 Wood, G. “Ethereum: A Secure Decentralised Generalised Transaction Ledger.” Ethereum Project Yellow

Paper 151.2014 1–32 (2014) accessed on 2026-02-26 URL https://ethereum.github.io/yellowpaper/ paper.pdf. 2 Buterin, V. accessed on 2026-02-26 “Ethereum White Paper.” (2013) Online URL https://ethereum.

org/en/whitepaper/. 3 Nakamoto, S. accessed on 2026-02-26 “Bitcoin: A Peer-to-Peer Electronic Cash System.” (2008) White

Paper URL https://bitcoin.org/bitcoin.pdf. 4 Etherspot

accessed on 2026-02-26 “Top 5 Account Abstraction Use Cases (2025 Edition).” (2025) Online Blog URL https://etherspot.io/blog/ account-abstraction-use-cases-you-can-build-today/. 5 Kim, C. accessed on 2026-02-26 “The Road to Account Abstraction on Ethereum.” (2024) Galaxy Research URL https://www.galaxy.com/insights/research/ the-road-to-account-abstraction-on-ethereum/. 6 Sandford, R., et al. accessed on 2026-02-26 “EIP-2771: Secure Protocol for Native Meta Transactions.”

(2020) Ethereum Improvement Proposals URL https://eips.ethereum.org/EIPS/eip-2771. 7 Buterin, V., et al. accessed on 2026-02-26 “ERC-4337: Account Abstraction Using Alt Mempool.” (2021) Ethereum Request for Comments URL https://eips.ethereum.org/EIPS/eip-4337. 8 BundleBear accessed on 2026-02-26 “Account Abstraction Statistics.” (2024) Online Dashboard URL

https://www.bundlebear.com/erc4337-paymasters/all. 9 Fröhlich, M., Waltenberger, F., Trotter, L., Alt, F., Schmidt, A. “Blockchain and Cryptocurrency in Human

Computer Interaction: A Systematic Literature Review and Research Agenda.” In Designing Interactive Systems Conference 155–177 (2022) doi:10.1145/3532106.3533478. 10 Saldivar, J., Martı́nez-Vicente, E., Rozas, D., Valiente, M. C., Hassan, S. “Blockchain (Not) for Everyone:

Design Challenges of Blockchain-Based Applications.” In Extended Abstracts of the 2023 CHI Conference on Human Factors in Computing Systems 1–8 (2023) doi:10.1145/3544549.3585825. 11 Alqaryouti, O., Siyam, N., Monem, A. A., Al-Emran, M. “The Adoption of Smart Contracts: A Systematic Review.” Blockchain: Research and Applications 100192 doi:10.1016/j.bcra.2025.100192. 12 Norman, D. The Design of Everyday Things: Revised and Expanded Edition. Basic Books (2013). 13 Vermeulen, J., Luyten, K., van den Hoven, E., Coninx, K. “Crossing the Bridge over Norman’s Gulf of

Execution: Revealing Feedforward’s True Identity.” In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems 1931–1940 (2013) doi:10.1145/2470654.2466255. 14 Nielsen, J. Usability Engineering. Morgan Kaufmann (1994). 15 Davis, F. D. “Perceived Usefulness, Perceived Ease of Use, and User Acceptance of Information Technology.”

MIS Quarterly 319–340 doi:10.2307/249008. 16 Marangunić, N., Granić, A. “Technology Acceptance Model: A Literature Review from 1986 to 2013.”

Universal Access in the Information Society 14 81–95 (2015) doi:10.1007/s10209-014-0348-1. 17 Buterin, V. accessed on 2026-02-26 “The Meaning of Decentralization.” (2017) Medium URL https: //medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274. 18 Walch, A. “Deconstructing ‘Decentralization’: Exploring the Core Claim of Crypto Systems.” In Crypto As-

sets: Legal and Monetary Perspectives Oxford University Press 39–68 (2019)doi:10.1093/oso/9780190077310. 003.0003. 19 Jacobs, J. accessed on 2026-02-26 “Hyperstructures.” (2022) Zora Media URL https://jacob.energy/ hyperstructures.html.

29

20 Etherscan accessed on 2026-02-26 “Ethereum Unique Address Growth Chart.” (2024) Online Dashboard

URL https://etherscan.io/chart/address. 21 Singh, A. K., Hassan, I. U., Kaur, G., Kumar, S. “Account Abstraction via Singleton Entrypoint Contract and Verifying Paymaster.” In 2023 2nd International Conference on Edge Computing and Applications (ICECAA) IEEE 1598–1605 (2023) doi:10.1109/ICECAA58104.2023.10212316. 22 Tirosh, D., Buterin, V., et al. accessed on 2026-02-26 “ERC-4337 Team Basic Paymaster Contract.” (2022)

GitHub Repository URL https://github.com/eth-infinitism/account-abstraction. 23 Buterin, V., Liber, S., et al. accessed on 2026-02-26 “EIP-7702: Set EOA Account Code.” (2024) Ethereum

Improvement Proposals URL https://eips.ethereum.org/EIPS/eip-7702. 24 Buterin, V. accessed on 2026-02-26 “What I Would Love to See in a Wallet.” (2024) Personal Blog URL

https://vitalik.eth.limo/general/2024/12/03/wallets.html. 25 a16z Crypto accessed on 2026-02-26 “State of Crypto 2024.” (2024) Online Report URL https:

//a16zcrypto.com/posts/article/state-of-crypto-report-2024/. 26 ZeroDev accessed on 2026-02-26 “Session Keys and Passkeys.” (2023) Online Documentation URL https:

//docs.zerodev.app. 27 Particle Network accessed on 2026-02-26 “Wallet-as-a-Service.” (2023) Online URL https://particle.

network. 28 Forshtat, Y., et al. accessed on 2026-02-26 “RIP-7560: Native Account Abstraction.” (2023) Rollup Im-

provement Proposals URL https://github.com/ethereum/RIPs/blob/master/RIPS/rip-7560.md. 29 Buterin, V., et al. accessed on 2026-02-26 “EIP-7701: Native Account Abstraction with EOF.” (2024)

Ethereum Improvement Proposals URL https://eips.ethereum.org/EIPS/eip-7701. 30 Buterin, V., et al. draft. Accessed on 2026-03-09 “EIP-8141: Frame Transaction.” (2026) Ethereum Improve-

ment Proposals URL https://eips.ethereum.org/EIPS/eip-8141. 31 Wang, Q., Chen, S. “Account Abstraction, Analysed.” arXiv preprint arXiv:2309.00448 doi:10.48550/arXiv.

2309.00448. 32 Lin, Z., Wang, T., Zhao, C., Zhang, S., Yang, Q., Shi, L. “A Measurement Investigation of ERC-4337

Smart Contracts on Ethereum Blockchain.” In 2024 International Conference on Computing, Networking and Communications (ICNC) IEEE 1164–1170 (2024) doi:10.1109/ICNC59896.2024.10556301. 33 OpenZeppelin

accessed on 2026-02-26 “ERC-4337 Account Abstraction Incremental Audit.” (2024) Online Blog URL https://blog.openzeppelin.com/ erc-4337-account-abstraction-incremental-audit. 34 Roughgarden, T. “Transaction Fee Mechanism Design for the Ethereum Blockchain: An Economic Analysis

of EIP-1559.” Journal of the ACM 71.4 1–63 (2024) doi:10.1145/3674143. 35 Liu, Y., Lu, Y., Nayak, K., Zhang, F., Zhang, L., Zhao, Y. “Empirical Analysis of EIP-1559: Transaction Fees,

Waiting Time, and Consensus Security.” In Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security 2099–2113 (2022) doi:10.1145/3548606.3559341. 36 Sweller, J. “Cognitive Load During Problem Solving: Effects on Learning.” Cognitive Science 12.2 257–285

(1988) doi:10.1207/s15516709cog1202 4. 37 Pimlico accessed on 2026-02-26 “Paymaster and Bundler Service Documentation.” (2023) Online Documentation URL https://docs.pimlico.io/references/paymaster. 38 Alchemy accessed on 2026-02-26 “Account Abstraction Infrastructure.” (2023) Online URL https://www.

alchemy.com/account-abstraction. 39 Biconomy accessed on 2026-02-26 “SDK for Account Abstraction.” (2023) Online URL https://www. biconomy.io. 40 Stackup accessed on 2026-02-26 “ERC-4337 Bundler and Paymaster.” (2023) Online URL https://www.

stackup.fi.

30

41 Coinbase accessed on 2026-02-26 “Base Chain and Smart Wallet.” (2023) Online URL https://www.

coinbase.com/wallet/smart-wallet. 42 Safe Team accessed on 2026-02-26 “Understanding Safe’s Modular Smart Account Architecture.” (2024) Online Documentation URL https://docs.safe.global/advanced/smart-account-overview. 43 Daian, P., et al. “Flash Boys 2.0: Frontrunning in Decentralized Exchanges, Miner Extractable Value,

and Consensus Instability.” In 2020 IEEE Symposium on Security and Privacy (SP) IEEE 910–927 (2020) doi:10.1109/SP40000.2020.00040. 44 Thibault, L. T., Sarry, T., Hafid, A. S. “Blockchain Scaling Using Rollups: A Comprehensive Survey.” IEEE Access 10 93039–93054 (2022) doi:10.1109/ACCESS.2022.3200051. 45 Peffers, K., Tuunanen, T., Rothenberger, M. A., Chatterjee, S. “A Design Science Research Methodology

for Information Systems Research.” Journal of Management Information Systems 24.3 45–77 (2007) doi: 10.2753/MIS0742-1222240302. 46 Hevner, A. R., March, S. T., Park, J., Ram, S. “Design Science in Information Systems Research.” MIS

Quarterly 28.1 75–105 (2004) doi:10.2307/25148625. 47 Venable, J., Pries-Heje, J., Baskerville, R. “FEDS: A Framework for Evaluation in Design Science Research.”

European Journal of Information Systems 25.1 77–89 (2016) doi:10.1057/ejis.2014.36. 48 Jain, R. The Art of Computer Systems Performance Analysis: Techniques for Experimental Design, Measure-

ment, Simulation, and Modeling. Wiley (1991). 49 Efron, B., Tibshirani, R. J. An Introduction to the Bootstrap. Chapman & Hall/CRC (1993) doi:10.1007/ 978-1-4899-4541-9. 50 Romano, J., Kromrey, J. D., Coraggio, J., Skowronek, J. “Appropriate Statistics for Ordinal Level Data:

Should We Really Be Using t-test and Cohen’s d for Evaluating Group Differences on the NSSE and Other Surveys?” In Annual Meeting of the Florida Association of Institutional Research 1–33 (2006) . 51 Shneiderman, B., Plaisant, C. Designing the User Interface: Strategies for Effective Human-Computer Interaction. Addison-Wesley 5th edition (2010). 52 Nielsen, L. Personas – User Focused Design. Springer (2013). 53 Hollender, N., Hofmann, C., Deneke, M., Schmitz, B. “Integrating Cognitive Load Theory and Concepts

of Human–Computer Interaction.” Computers in Human Behavior 26.6 1278–1288 (2010) doi:10.1016/j.chb. 2010.05.031. 54 Pacheco, M., Oliva, G., Rajbahadur, G. K., Hassan, A. “Is My Transaction Done Yet? An Empirical Study of Transaction Processing Times in the Ethereum Blockchain Platform.” ACM Transactions on Software Engineering and Methodology 32.3 1–46 (2023) doi:10.1145/3549542. 55 Card, S. K., Moran, T. P., Newell, A. The Psychology of Human-Computer Interaction. Lawrence Erlbaum

Associates (1983). 56 Ultra Sound Money accessed on 2026-02-26 “Ethereum Supply and Burn Statistics.” (2024) Online Dashboard URL https://ultrasound.money/. 57 Sun, P., Ding, M., Zhao, Z. “Centralization Risks in Blockchain Infrastructures: A Comprehensive Survey.”

Blockchain: Research and Applications 100185 doi:10.1016/j.bcra.2025.100185. 58 Geng, S., Huang, Z. “A Comprehensive Survey on Web3 Usability and User Experience Barriers.” Blockchain:

Research and Applications 100210 doi:10.1016/j.bcra.2024.100210. 59 Gorzny, J., Heidari Soureshjani, F., Derka, M. “Account Abstraction for Enforcing Blockchain-Based AI Agent Non-Functional Requirements.” In 2025 IEEE 33rd International Requirements Engineering Conference Workshops (REW) Valencia, Spain 359–364 (2025) doi:10.1109/REW66121.2025.00053.

31

Appendix H:

Optimism Mainnet Deployment Addresses

Table 7. Canonical deployment addresses used in the mainnet evaluation.

Component

Address

Registry

0x997686219F31405503D32728B1f094F115EF24e7 SuperPaymaster 0xA2c9A6e95f19f5D2a364CBCbB5f0b32B1B4d140E PaymasterV4 0x67a70a578E142b950987081e7016906ae4F56Df4 EntryPoint (ERC-4337 v0.7) 0x0000000071727De22E5E9d8BAf0edAc6f37da032 xPNTsFactory 0x864971a26384d9DCC7115f0bBC428e2623F28b6e gToken 0x8d6Fe002dDacCcFBD377F684EC1825f2E1ab7ef6 Gas Card SBT 0x28eBFc5fc03B1d7648254AbF1C7B39DbFdef1a94 BLS Aggregator 0x1C305372ecc5a36CBef1FA371392234bCD55eB19 SimpleAccountFactory (infra) 0x91E60e0613810449d098b0b5Ec8b51A0FE8c8985 All addresses above are independently verified on Etherscan / Blockscout; the canonical verification index is published at https://docs.aastar.io/guide/deployments/verify. optimism.contracts.html. EntryPoint and SimpleAccountFactory are the canonical ERC4337 v0.7 infrastructure contracts and are pre-verified upstream; all other contracts in Table 7 are AAStar deployments verified by the project. The empirical measurements in §5 are scoped to this exact contract set.

Appendix I: I.1.

Core Contract Logic

Zero-Approve Engine (Simplified Solidity)—

// Simplified from xPNTs gas token contract function allowance ( address owner , address spender ) public view override returns ( uint256 ) { if ( _ is Au toA pp ro ved Sp en der ( spender ) ) { return type ( uint256 ) . max ; } return super . allowance ( owner , spender ) ; } function transferFrom ( address from , address to , uint256 amount ) public override returns ( bool ) { if ( _ is Au toA pp ro ved Sp en der ( msg . sender ) ) { // Firewall : auto - approved spenders may only transfer // to themselves or to the registered SuperPaymaster . require ( to == msg . sender || to == superPaymaster , " xPNTs : ␣ unauthorized ␣ destination " ); require ( amount <= MAX_SINGLE_TX_LIMIT , " xPNTs : ␣ exceeds ␣ cap " ) ; _transfer ( from , to , amount ) ; return true ; }

32

return super . transferFrom ( from , to , amount ) ; } Listing 1. Zero-Approve Engine from xPNTs gas token contract (simplified).

Appendix J:

Project Repositories Table 8. Open-source project repositories.

Component

Repository

SuperPaymaster

https://github.com/AAStarCommunity/SuperPaymaster https://github.com/AAStarCommunity/AirAccount https://github.com/AAStarCommunity/Registry https://github.com/AAStarCommunity/Faucet https://github.com/AAStarCommunity/aastar-sdk

AirAccount Registry Faucet AAStar SDK

Pinned commits. For exact reproducibility, the empirical results in §5 were generated against the pinned revisions in Table 9. Table 9. Pinned source revisions for the empirical results in §5. Repository

Tag / commit

Date

Notes

SuperPaymasterv4.4.0-optimism-2026-02mainnet 11 (910d1f7) ∗

Contract sources whose compiled bytecode is deployed at the addresses in Table 7; reported version() string is SuperPaymaster-3.2.2.

03d0ca9 †

Analytics scripts and pre-collected snapshots used in §5.

aastar-sdk

Appendix K:

2026-0415

Reproducible Data Collection

Run from the aastar-sdk repository to reproduce the CSV evidence and summary tables used in §5: pnpm install pnpm -s tsx scripts / c o l l e c t _ e o a _ e r c 2 0 _ b a s e l i n e . ts \ -- network op - mainnet \ -- rpc - url https :// mainnet . optimism . io \ -- token 0 x 0 b 2 c 6 3 9 c 5 3 3 8 1 3 f 4 a a 9 d 7 8 3 7 c a f 6 2 6 5 3 d 0 9 7 f f 8 5 \ -- token - name USDC \ -- from - block 147803000 --to - block 147804169 \ --n 50 -- window 20 \ -- out packages / analytics / data / eoa_erc20_baseline . csv Listing 2. Baseline data collection command.

Full commercial-baseline collection and summary scripts reside in packages/analytics/scripts/ of the pinned aastar-sdk (commit 03d0ca9, see Appendix J). Table 10 lists the four scripts and their block windows. All generated CSVs land under packages/analytics/data/, and the date-stamped snapshots used by this paper reside under packages/analytics/data/paper gas op mainnet/; 33

Table 10. Data-collection scripts and block windows on Optimism Mainnet.

Script

Purpose

Block window

collect eoa erc20 baseline.ts collect industry baseline.ts collect paymaster baselines.ts compute cost summary.ts

EOA-direct ERC-20 transfer baseline (n=50, sampling window 20).

147,803,000– 147,804,169 Alchemy / Pimlico paymaster traces. 145,864,449– 147,864,449 SuperPaymaster (T2.1) and Paymas- same as above terV4 (T1) trace collection. Aggregates the four CSVs into the per- — system mean / 95% CI tables in §5.3.

both sets are immutable evidence anchors. Table 11 lists the files used. Table 11. Generated CSV outputs and date-stamped snapshot directories. Artifact

Path under packages/analytics/data/ eoa erc20 baseline.csv Industry baselines CSV industry paymaster baselines.csv Industry baselines (en- industry paymaster baselines enriched.csv riched) Combined dataset complete dataset.csv Per-tx attribution attribution dataset.csv Snapshot 1 paper gas op mainnet/2026-02-17/ Snapshot 2 paper gas op mainnet/2026-02-18/ Snapshot 3 paper gas op mainnet/2026-02-21/ EOA baseline CSV

Per-transaction decomposition and recommended phrasing are documented in the OP Mainnet Gas Analysis Report. ‡

Appendix L:

Representative Transaction Hashes (On-chain Evidence)

Table 12. Representative transaction hashes for trace-level gas attribution. Workflow

Tx Hash

0x2b8ac4ef...c22af5bd § T1 (PaymasterV4) 0xf3ef2201...f79f23ebf ¶ T2.1 (SuperPaymaster) 0x7fcadac5...b1cf0f13 †† 0xe6ba7923...e72a4d19 ‡‡ B2 Pimlico B1 Alchemy

gasUsed

Note

215,410

Validation ∼16k (ECDSA); Alchemy modular/LightAccount-style account

152,018

Validation ∼35k; SimpleAccount

167,855

Validation ∼47,456 (SBT/policy, single-tx); SimpleAccount

295,627

Oracle + approve + token swap

Note on per-transaction validation gas. The “Paymaster validation ∼47,456 gas” reported above for T2.1 is the value observed in this single representative transaction. The canonical value reported in Section 5.3 and Table 6 is ∼48,625 gas, which is the average paymaster-validation gas across the n = 50 SuperPaymaster runs analyzed for this paper. Per-transaction values fluctuate within ±2% depending on storage-slot warm/cold state and bundler-side gas-estimation rounding; the n = 50 trace average is the authoritative figure.

Appendix M:

Gas Structure Decomposition

Note: The single-transaction representatives below are from an early trace session (2026-02-15) used for structural ratio analysis (L1 share, PVG share); the authoritative comparison metric ‡

https://github.com/AAStarCommunity/aastar-sdk/blob/main/packages/analytics/docs/OP_Mainnet_Gas_

Analysis_Report.md

34

is the n=50 mean actualGasUsed in Table 5 (T1=271,092 / T2.1=286,818). Single-tx values differ from n=50 means due to PVG estimation variance in early harness runs. Table 13. Gas structure decomposition (representative single transactions, OP Mainnet). Component

T1 (PaymasterV4)

T2.1 (SuperPM Normal)

actualGasUsed 245,299 244,101 txGasUsed (L2 execution) 152,042 167,855 PVG overhead proxy 93,257 (38.0%) 76,246 (31.2%) L1 data fee share of total ETH cost 7.6% 8.0% PVG is determined by bundler pricing policy, not paymaster logic. L1 data fees consistently account for ∼8% of total expenditure, suggesting that L2 execution optimizations can meaningfully reduce end-user costs under current fee regimes. The PVG share difference between this single-tx snapshot (∼31% of billed gas for T2.1) and the n = 50 mean reported in Table 5 (∼41% = 118,988/286,818) reflects bundler-side PVG-estimation maturation between sessions: the early 2026-02-15 trace was captured before the open-source bundler’s PVG buffer had stabilized, whereas the n = 50 production run sampled the bundler’s converged (and slightly more conservative) estimation regime. Both numbers are consistent in confirming that PVG, not paymaster architecture, dominates the residual actualGasUsed gap to Alchemy.

Appendix N:

PaymasterV4 vs SuperPaymaster Comparison

35

Table 14. PaymasterV4 and SuperPaymaster both implement AOA (on-chain spon-

sorship validity, no off-chain signer). SuperPaymaster extends the base with multi-community governance features at an additional ∼13k gas validation cost, trading on-chain overhead for operational accessibility. Dimension

PaymasterV4 (AOA Base)

SuperPaymaster (AOA+ Public Infrastructure)

Positioning

Single-community self-operated paymaster

Multi-community shared infrastructure

Deployment

Community deploys own con- No deployment needed; register via tract Registry

ETH Deposit

Community manages own de- Shared deposit pool; operator manposit, monitors balance, manu- ages funding ally tops up

Gas Token

Community configures an exist- One-click issuance via xPNTsFacing ERC-20 address tory (OpenPNTs standard)

Settlement

Community handles settlement directly

Atomic in postOp: burn user xPNTs + transfer aPNTs to protocol treasury

Identity Binding

None (token-balance only)

SBT-based Gas Card (nontransferable, reputation-bound)

Rate Limiting

None

Per-card rate-limit counters enforced on-chain

Payment Mode

Prepayment only

Burn xPNTs (atomic settlement via protocol treasury)

Operational Overhead

Requires Solidity + DevOps ca- Near-zero for community operators; pacity SDK one-line integration for developers

Validation Gas

∼35,549 gas ∼48,625 gas (+13k for SBT, rate(validatePaymasterUserOp) limit, credit state)

Target Users

Technical teams running their own projects

Any community (DAOs, games, wallets) regardless of technical capacity

Shared Property

On-chain eligibility, no off-chain signer

On-chain eligibility, no off-chain signer

36