Exploring the Power Consumption of ERC-4337 Bundling on Server Infrastructure

Exploring the Power Consumption of ERC-4337 Bundling on Server Infrastructure Claudiu-Nicu Bărbieru Alexandru Ioan Cuza University Iaşi, Romania claudiu.barbieru@gmail.com

Oana-Otilia Captarencu Alexandru Ioan Cuza University Iaşi, Romania oana.captarencu@info.uaic.ro

arXiv:2611.04033v1 [cs.NI] 2 Nov 2026

Valerio Schiavoni University of Neuchâtel Neuchâtel, Switzerland valerio.schiavoni@unine.ch

Pascal Felber University of Neuchâtel Neuchâtel, Switzerland pascal.felber@unine.ch

Cosmin-Nicolae Vârlan Alexandru Ioan Cuza University Iaşi, Romania cosmin.varlan@info.uaic.ro

Abstract—The Ethereum ecosystem offers the most widespread support for Decentralised Applications (DApps), with over 120 networks currently documented as using variants of the Ethereum Virtual Machine (EVM) for core execution logic. The ERC-4337 standard provides convenient access to DApps for users who do not possess the required cryptocurrency or prefer flexible authorisation of DApp actions. The infrastructure for ERC-4337 implementation can be deployed on any EVM network. However, to aggregate user requests and submit them to the EVM network, ERC-4337 requires operating a bundler, an additional component. Recently, the potential use of ERC4337 was boosted by another standard, EIP-7702, which can enable ERC-4337 utility for any existing user account. However, the use of the combined EIP-7702/ERC-4337 pattern remains considerably low at less than 6% of EIP-7702 activity. We believe that this underutilisation is at least partly caused by the low number of existing bundling services and their popularity, currently fewer than 15 publicly documented. Expanding the number of bundler nodes would benefit the ecosystem but would introduce operational costs, part of which is represented by the added nodes’ power consumption. In this paper, we provide a thorough view of the bundling power consumption aspect using server-grade infrastructure, evaluating both CPU and RAM consumption, as well as the overhead of container-based deployments specific to production environments. Index Terms—blockchain, ERC-4337, power consumption

I. I NTRODUCTION

The Ethereum [1] ecosystem is currently the largest conglomerate of blockchain networks that provide support for decentralised applications (DApps). At its core lies the main Ethereum network (L1), whose nodes rely on the Ethereum Virtual Machine (EVM) to execute smart contracts, small programs that implement the logic of functions changing the blockchain state. Users in the Ethereum ecosystem are normally identified by private-key controlled externally owned accounts (EOAs). Transactions sent by EOAs can be either cryptocurrency transfers or, more generally, calls to smart contracts. The network nodes group these transactions into blocks, subject to consensus, and securely chain them together, providing decentralised, immutable storage guarantees. Ethereum charges transaction fees to prevent network abuse and incentivise network participants. Over time, the increase

Emanuel Onica Alexandru Ioan Cuza University Iaşi, Romania emanuel.onica@uaic.ro

Boris Verdecia Echarte University of Neuchâtel Neuchâtel, Switzerland boris.verdecia@unine.ch

in the number of DApps backed by Ethereum smart contracts has led to network congestion and higher fees, a constant hurdle to onboarding new users. This resulted in a horizontal expansion via a multitude of secondary layer networks (L2). These adapt or reuse the EVM, process user transactions similarly, and submit different kinds of commitments to the main network (transaction data batches, state summaries), thereby maintaining a trust anchor on Ethereum. This helped reduce congestion and fees, but new user onboarding remains a problem due to the complete lack of cryptocurrency for paying transaction fees or for interacting with Ethereum DApps [2]. Account abstraction, standardised through ERC-4337 [3], introduces an independent accessibility layer that can be deployed on any EVM-based network. The effective component of this layer that facilitates user access is a Smart Contract Account (SCA), which acts as a user account and can replace EOAs. Users can express interactions with target contracts through UserOperations (UserOps), which are subsequently executed by their SCA. The SCA enables a variety of features that can enhance user experience, such as programmable transaction authorisation, fee sponsorship, transaction batching, and alternative authentication mechanisms, ultimately directing the UserOp to the target contract. To reach the SCA, UserOps are submitted to specialised nodes called bundlers, which package multiple operations and forward them to the underlying EVM network. We describe the full ERC-4337 messaging and interaction path in Section II. Although convenient for users without an EOA, ERC-4337 smart contract accounts may add identity indirection and require existing EOA users to transfer assets to the SCA. The introduction of EIP-7702 [4] further expands the potential of ERC-4337 by allowing an EOA to have an execution logic linked to a deployed smart contract, which can be a SCA. In this way, the delegated SCA logic executes in the context of the EOA, preserving its address and identity in calls to other contracts while having access to the assets held by the EOA. Account abstraction functionality can therefore be offered to existing accounts without requiring users to migrate their funds to newly initialised SCAs. Nevertheless, the combined use

of EIP-7702 and ERC-4337 remains limited, despite ERC4337 being envisioned as the primary use case for EIP-7702 delegations [5] and recommended as such in official Ethereum best practices [6]. Statistics from December 2025 showed that seven months after the adoption of EIP-7702, less than 6% of its monthly delegations used SCA facilities [7]. Still, the end of 2025 marked the milestone of passing 1M weekly ERC4337 UserOps in the context of EIP-7702 delegations, the figure rising to more than 2.5M in late June 2026 [8]. This might seem like a solid increase, but the weekly transactions involving EIP-7702 delegated EOAs outside the ERC-4337 context exceeded 176M during the same period. We think that a contributing factor to the above situation is the limited number of publicly available bundling services that handle ERC-4337 UserOps. Currently, there are no more than 15 officially documented bundlers on any of the major EVM networks [9]. Moreover, among these (excluding undocumented services), on each EVM network, only 3-4 bundlers account for more than 50% of the bundling activity. Bundlers charge an additional fee for their service, which includes a validation of the UserOps, and grouping these in bundles. Typically, this extra cost is computed as a percentage of the base transaction fee used on the EVM network. Currently, popular bundler services add a 5% overhead to this regular fee [10], [11] for UserOps. This somehow undermines one of the main functions of ERC-4337: transaction sponsorship. Users who cannot cover regular transaction fees can wrap these as UserOps and rely on ERC-4337 mechanisms that allow the associated SCA’s fees to be sponsored by a third party. Potential sponsors, however, may incur higher costs than they would for regular transactions. We believe that increasing the number of bundlers could foster wider adoption of ERC4337, reduce costs through stronger market competition, and overall enhance the availability and decentralisation of ERC4337 services. An expansion of the number of bundlers must, however, account for complete operational costs, including energy consumption. Power usage has long been a sensitive concern for blockchain networks due to their computational demands. Ethereum’s transition from Proof-of-Work to Proof-of-Stake consensus marked a significant reduction from an annual estimation of 21 TWh to 0.0026 TWh in its energy expenditure, an aspect that receives constant scrutiny [12]. Recent work [13] advocated co-hosting a bundler service alongside a regular Ethereum client implementation on the same node, which would naturally increase the number of bundlers. A bundler performs repeated simulations for validation purposes, transaction cost estimation requests, and even debug traces of UserOps, all of which are executed via RPC requests to an EVM client on the network. Therefore, co-hosting bundlers with EVM implementations would reduce communication overhead with the EVM network and also cut the costs of running separate bundler nodes. While energy costs may be of low importance to an independent operator running a limited number of bundler nodes, this cost significance is worth considering at the broader level of the ecosystem.

There is no exact number of Ethereum nodes due to variable network churn, but estimates currently put the number at around 11K [14]. The majority of L2 EVM-based networks do not use a decentralised consensus, which presumably makes their node counts much lower, but, altogether, even harder to estimate in the absence of official records. Furthermore, the L2 number is constantly expanding, recent studies [15] counting 129 networks. Running a bundler instance on each EVM node would likely be unnecessary, but determining the optimal bundler-to-network ratio is a complex problem that requires a more advanced scalability study that accounts for real-time variations such as network churn and load. Intrinsically, this makes determining a bundler’s power consumption a potentially important factor in such a volatile context. Evaluating the energy implications of emerging blockchain infrastructure is necessary before its deployment reaches ecosystem scale. Previous early results [13] indicate that operating an ERC4337 bundler does not inflict a substantial average power consumption overhead on an EVM client, and should not represent a concern at the level of an individual host. These estimates, however, were limited to empirical evaluations of CPU power consumption on mobile hardware and cannot precisely characterise the impact of deploying a bundler within the Ethereum ecosystem. They do not include measurements on production environments, which commonly rely on containerisation and consider server-grade infrastructure. In this paper, we investigate the power-consumption implications in a realistic setting that would fit a broader deployment of ERC4337 bundlers. We evaluate the average power consumption of both the CPU and memory across several server-grade configurations and quantify the power use of container-based deployments that are representative of production environments. We use SmartWatts [16] for our measurements, a well-established power-consumption estimation software whose accuracy has been confirmed in scientific evaluations [17]. Paper Organisation: In Section II, we provide additional background on the ERC-4337 communication flow and details on using SmartWatts for measuring the average power consumption. In Section III, we elaborate on a series of details that provide specificity to the evaluation of the bundler component in a production environment, and we also lay the groundwork for future, more in-depth investigation. We follow in section IV with the description of the experimental setup, the conducted evaluation and the results we obtained. We conclude in Section V. II. BACKGROUND In what follows, we start by discussing the ERC-4337 UserOp path and the involvement of a bundler in its processing. Then we continue with background on conducting power consumption measurements. A. The ERC-4337 UserOps Workflow Figure 1 illustrates the communication flow involving the bundler in ERC-4337. The other participants are the user’s smart contract account (SCA), the destination contract with

(1) Wraps Tx Call in UserOp DApp

(9) Compensates Bundler for UserOp Flow Cost

(2) UserOp

Bundler

(4) UserOpBundle (5) Validate UserOp

Destination Contract

(6) Validate UserOp Sponsorship

(3) Pre-Validate UserOp

(8) Effective Transaction Call

Entry Point Contract

Charge SCA Deposit if no Paymaster

Optional Paymaster

Charge Paymaster Deposit (7) Generic UserOp Execute

Smart Contract Account

Fig. 1. Transaction communication path in ERC-4337

which the user intends to interact, an EntryPoint contract on the Ethereum network, and an optional Paymaster - a contract willing to sponsor the user’s transaction. First, a DApp constructs a UserOperation (UserOp) message. The UserOp identifies the SCA as the sender, encodes the call to the destination contract into the callData field, and includes the custom signature required by the SCA’s validation logic (1). The UserOp is then submitted to the bundler (2). The bundler performs an initial validation of the UserOps received (3) and aggregates multiple valid operations into a bundle. Subsequently, it submits the bundle to the EntryPoint contract through a transaction (4). The bundler must initially pay the gas cost of this transaction. The EntryPoint then validates each UserOp, interacting with the SCA associated with the UserOp initiator (5). The UserOp can designate a third-party paymaster to sponsor the transaction fee. In this case, the EntryPoint also validates the UserOp through the Paymaster (6) and charges the execution costs to either the SCA or the Paymaster, depending on whether sponsorship is used. Then, the EntryPoint invokes a generic execution function in the SCA (7), forwarding the payload specified in the UserOp’s callData. This causes the SCA to perform a regular call to the destination contract (8). Finally, the EntryPoint compensates the bundler for the gas spent on the bundle transaction (9). We note that step (2) in Figure 1 can be more complex in practice, as some bundlers may share a common UserOp mempool. In this case, the UserOp may be further propagated among bundlers, potentially increasing the overhead of the bundler process. However, not all bundlers support this functionality. Also, this UserOp distribution relies on gossip-based propagation rather than broadcast, meaning that each bundler forwards the UserOp only to a limited set of peer nodes, with less impact on power consumption. Intuitively, the computational overhead introduced by the bundler process is expected to result primarily from the processing of UserOps. Steps (3) and (4) are performed via remote procedure calls (RPC). These use the JSON-RPC protocol supported by the EVM clients on the blockchain network. Hence, the bundler-side overhead associated with these steps

is largely limited to preparing, issuing, and processing the corresponding RPC requests and responses. A substantial part of the workflow (steps (5)–(8)) involves only the blockchain nodes that handle the execution of the relevant smart contracts. Therefore, these operations do not contribute directly to the computational workload of the bundler. Similarly, step (9) is a payment transaction, also executed on the blockchain nodes. We notice that the ERC-4337 flow introduces a more substantial overhead on the blockchain node running the EVM that executes the EntryPoint transaction. However, this overhead is inherent to the on-chain execution of the ERC4337 workflow and is therefore independent of where the bundler node is deployed. B. Power consumption estimation A computer’s power consumption is strongly affected by the software executed on the system [18], [19]. In general-purpose computing, the CPU is a major source of variation in power drawn, which correlates with the consumption of the entire system [18], [20]. Although various physical power meters can be used to measure the total power drawn by a node, isolation the power consumption of a specific software process is more challenging. A coarse estimate may be obtained by averaging the difference between multiple executions performed with and without the target software. However, this approach cannot isolate several factors that influence active power consumption: background activity from software dependencies and other processes, CPU voltage and frequency changes introduced by Dynamic Voltage and Frequency Scaling (DVFS), cache misses associated with the execution context, and transitions into low-power C-states during idle periods. These limitations have motivated the development of power models [18], [21]. Many combine system-level measurements with machinelearning techniques to provide more accurate estimates of CPU power consumption. Our study relies on SmartWatts [16], an open-source software that estimates the power consumption of software processes, containers, virtual machines, or applications running on a physical server. This is implemented as part of the

PowerAPI framework [18], [22], which leverages Running Average Power Limit (RAPL) [23]. RAPL is an interface developed by Intel that permits capturing the active power consumption of several hardware domains. This interface was introduced in Intel processors with the Sandy Bridge architecture and later adopted by AMD in the Zen architecture. RAPL provides energy measurements for the CPU package, separate processor cores, shared caches, DRAM and memory controllers, integrated graphics, depending on the processor architecture and the domains supported by the platform. Although RAPL enables software-based measurements of CPU power consumption, it provides only a global estimate whose accuracy may be limited [24]. To improve measurement precision, SmartWatts complements RAPL data with hardware performance counters (HwPCs) collected through the CPU’s performance monitoring units (PMUs). The monitored events include the APERF/MPERF ratio, which reflects the relationship between the effective and nominal core frequencies and captures turboboost and power-saving behavior, as well as unhalted core cycles, last-level cache misses that may trigger main-memory accesses, and completed instructions. III. B UNDLER P OWER C ONSUMPTION : P RODUCTION E NVIRONMENT C ONSIDERATIONS In this section, we outline specific details about running a bundler in a production environment and its implications for power consumption. We begin with a concise set of hardware considerations, followed by the essential software necessities and their potential relation to power consumption. We continue with brief considerations on power consumption measurement and conclude the section by pointing to advanced details of the bundling process that may be explored in future work. A. Hardware Setup Considerations To our knowledge, the only prior work that considered bundler power-consumption is [13]. This empirically estimated the overhead of the bundler running on an EVM client node, using a mobile processor that exposes the RAPL interface, an Intel i7-10870H. From a production environment perspective, a more accurate evaluation should consider server-grade CPUs, e.g., the Intel Xeon family or AMD EPYC. Server-grade processors typically have a higher baseline idle power consumption due to larger caches and, overall, more complex I/O and uncore subsystems. Besides that, larger caches may reduce DRAM accesses for cache-resident workloads, shifting consumption from DRAM toward CPU activity. On the other hand, server-grade setups typically come with much greater memory capacity and, consequently, higher idle power consumption for DRAM as well. This also prompts consideration of the memory power consumption measurement, which, to our knowledge, has not been performed before in bundler contexts. Finally, although the Thermal Design Power (TDP) is related to dissipated heat rather than power consumption, it still indicates a possible power envelope that is considerably higher for server-grade CPUs.

Although maintaining an empirical level for our observations, in our current work, we focus exclusively on servergrade hardware, which we consider considerably more relevant for the overall context of bundler node expansion. B. Baseline Software Considerations As discussed in the previous section, all ERC-4337 bundlers follow a common workflow. However, implementations may differ in specific internal stages, such as the ordering and grouping of UserOps when constructing bundle transactions, as well as validation practices, including simulation methods and the frequency of checks. Therefore, different bundler software can have varying impacts on power consumption. Currently, aside from the reference implementation [25], the diversity of bundler clients is relatively limited. Pimlico (Alto) [26], the bundler under scrutiny in the previous work [13], remains in the top three by total UserOps load handled in the EVM ecosystem. This bundler holds the first position on the main Ethereum network [27] and a couple of other EVM networks. Other top bundler services include Alchemy [28], Thirdweb [29] and Coinbase [30]. These four bundler providers concentrate more than 50% of the bundling activity [9]. Notably, Pimlico and Alchemy opensource their respective bundler implementations: Alto [26] and Rundler [28], respectively. By contrast, Thirdweb and Coinbase publish integration tooling, client libraries, and orchestration examples but do not currently disclose the server-side bundler implementations used by their production services. Besides differences in bundler software, power consumption variations are also amplified by the programming language used for bundlers’ implementations. Notable overheads that pass 20x have been observed between different languages, such as TypeScript, used by Alto, over Rust, used by Rundler [31]. If we consider running the bundler software on the same node as the EVM, the overall power consumption also depends on the EVM client node implementation due to frequent interactions with the bundler. The EVM node implementations also vary. Therefore, to isolate the bundler’s effective overhead, previous work [13] uses Anvil [32], a development node simulator. This provides a reference EVM implementation focused on the baseline operations of executing contracts and forming the chained blocks, rather than on ensuring consensus or other complementary operations. Finally, power consumption is affected by the logic of the executed transactions. While this logic is independent of the bundler implementation, specific workloads can indicate how significant power consumption may be. Previous work [13] has considered token transfers in particular. These are among the most popular transactions in the EVM ecosystem, with ERC-20 [33] reaching almost 2 billion trades by 2025 [34]. Moreover, Uniswap, which heavily uses ERC-20 tokens, is currently the decentralised exchange protocol with the widest spread, with more than 740 forks [35]. Therefore, we consider ERC-20 a proper use-case indicator.

C. Power Measurement Considerations The aforementioned prior work [13] used the SmartWatts [16] component of the PowerAPI toolkit [22] to estimate power consumption, taking as input the CPU exported RAPL data, complemented by HwPC. This data is mapped to processes using the separation provided by Linux control groups (cgroups). First, SmartWatts estimates the system’s idle power baseline and then applies a regression algorithm to obtain the active power consumption split per process group. The power consumption estimation model selects HwPC events based on their correlation with RAPL measurements and periodically recalibrates to maintain an error of less than 3.5%. [16] We consider a similar approach using SmartWatts, which allows us to maintain consistency with previous measurements, even though those were obtained on a completely different hardware setup. Still, since we use similar, albeit updated, software choices as discussed above, we can draw some baseline comparison with former results. This former work isolated the EVM client (Anvil) and bundler (Alto) processes by running them in transient scope units, which function as temporary cgroups, enabling SmartWatts to capture their distinct average power consumption. This can provide a perspective on native runs on bare-metal, server-grade infrastructure. However, in production environments, it is often preferred to run services in containers for isolation, portability, simplified dependency management, and easier scaling and rollback. In the current work, we focus on such a setting, using Docker containers. However, Docker containers could trigger potential power consumption overhead, which we investigate in our evaluation. D. Advanced Bundling Considerations Our current study evaluates a bundler’s power consumption overhead in the baseline environment described above, centred on token use, which is representative of typical blockchain workloads. However, ERC-4337 provides context for more complex use cases, such as sponsoring transactions through a paymaster contract and enforcing custom authentication. The impact of power consumption in such cases is mainly on the blockchain’s EVM node, which executes the transactions. Still, several aspects may be important to discuss in the context of bundling. While outside the scope of the current work, we consider the following for potential future exploration. Transaction Costs Estimation Traffic: A bundler may repeatedly execute simulation RPC calls to estimate UserOp costs (e.g., when servicing eth estimateUserOperationGas requests). This may involve simulating the transaction’s inner execution, incurring additional computational costs. Moreover, traffic also adds communication costs, which might be reflected in the bundler’s power consumption. Smart Contract Account Types: For the baseline in our study, we consider the reference SCA implementation (SimpleAccount) [36], with the default typical Ethereum ECDSA signing for submitted UserOps. However, SCA implementations can opt for more complex UserOp signature validation, including multisigs, session keys, passkeys and other custom

mechanisms. The signature verification can therefore produce a computational overhead. This is a generic factor, independent of the transaction logic, that can increase the EVM node’s power consumption during transaction validation. Validation Complexity: In addition to signature verification, the pre-validation of UserOps performed by the bundler may affect power consumption, depending on the complexity of the transaction validation logic and the contract call depth. A proposed standard, ERC-7562 [37], introduces validationscope rules intended to protect bundlers against DoS attacks. To enforce these rules, bundlers trace the validation phase and detect prohibited opcodes, restricted storage or code accesses, and other disallowed dependencies. Regardless of the ERC7562 tracing, a bundler will still trigger a simulation of the validation logic, which may increase the connected EVM node’s computations and power consumption. IV. E VALUATION We considered three production server configurations for our evaluation, as follows: Intel Xeon Gold (IXG): The first server is equipped with a 16-core (32 threads) 3rd Gen Intel Xeon Gold 6326 CPU, 185W TDP, running from a baseline frequency of 2.90 GHz up to a maximum turbo of 3.50 GHz. The server has 64 GB DDR4 memory installed, running at 3200 MT/s and uses a 512 GB NVMe SSD. The operating system on this configuration is Ubuntu 22.04.5, using the Linux 5.15.0-186-generic kernel. AMD EPYC (AMD): The second server is equipped with a 16-core (32 threads) AMD EPYC 7302P CPU, 155W TDP, with a baseline frequency of 3.00 GHz and a maximum boost of 3.50 GHz. This server has 32 GB DDR4 running at 3200 MT/s and uses a 480 GB SATA SSD. The operating system on this configuration is similar to the IXG. Intel Xeon Silver (IXS): The third server is equipped with a 12-core (24 threads) 5th Gen Intel Xeon Silver 4510 CPU, 150W TDP, with a baseline frequency of 2.40 GHz that goes up to a max turbo of 4.10 GHz. This server has 128 GB DDR5 running at 5600 MT/s and uses a 512 GB SATA SSD set in RAID 1 mode. The operating system on this server is Debian 13 as the base for the Proxmox 9.1 virtualisation environment, using the specific Linux 6.7.13-4-pve kernel build. For our software setup, we opted for the configuration described in the previous section. We used Anvil v1.7.1 as an EVM simulator and Alto as a bundler. To enable the ERC4337 flow, we deployed EntryPoint v0.7, which is currently the most used in the Ethereum ecosystem [38]. For the workload contents, we took a similar approach as previous work [13]. We considered bursts of ERC-20 transfer transactions, processed as UserOps via a set of distinct deployed SCAs that use the reference SimpleAccount implementation [36]. Unlike the aforementioned previous work, which performs an empirical evaluation locally confined to an end-user machine, we considered a production-oriented simulation in which we fed the UserOps from an external client machine to each server-hosted bundler. We prepared our Alto and Anvil services setup in two variants: one that runs the processes in Docker containers,

TABLE I W EIGHTED AVERAGE OF WATTS P OWER C ONSUMPTION ON I NTEL X EON G OLD Test Config

Alto CPU (Docker/Native)

Anvil CPU (Docker/Native)

Global CPU (Docker/Native)

Alto DRAM (Docker/Native)

Anvil DRAM (Docker/Native)

Global DRAM (Docker/Native)

System Idle

1.23 / 0.91

1.67 / 0.94

36.42 / 34.08

0.38 / 0.18

0.32 / 0.13

8.49 / 7.46

Variation of Throttling per UserOp with 100 UserOps Burst Load per Round and 12s Blocks Frequency 25ms Throttling

14.92 / 15.15

3.30 / 3.58

37.09 / 36.94

1.77 / 2.74

0.27 / 0.68

7.38 / 7.27

50ms Throttling

11.13 / 10.66

4.61 / 3.41

36.38 / 37.27

2.24 / 2.04

0.91 / 0.67

7.61 / 7.59

100ms Throttling

5.83 / 6.64

7.05 / 5.14

37.60 / 37.65

1.51 / 1.71

1.26 / 0.92

7.82 / 8.01

Variation of UserOps Burst Load per Round with 25 ms Throttling per UserOp and 12s Blocks Frequency 75 UserOp Burst

13.08 / 12.56

4.37 / 2.89

36.21 / 36.06

2.55 / 2.47

0.89 / 0.61

7.31 / 7.26

50 UserOp Burst

6.85 / 8.99

5.31 / 3.14

35.19 / 34.20

1.12 / 0.86

1.08 / 0.25

7.37 / 7.18

25 UserOp Burst

4.60 / 6.56

5.48 / 3.57

35.47 / 35.84

1.10 / 1.78

1.06 / 0.64

7.44 / 7.67

Variation of Block Frequency with 100 UserOps Burst per Round and 25 ms Throttling per UserOp 2s Block

25.22 / 27.91

12.01 / 7.31

44.96 / 44.27

4.26 / 4.90

2.06 /1.19

7.96 / 7.99

6s Block

19.37 /19.66

6.37 / 4.28

39.27 / 39.02

3.44 / 3.46

1.20 / 0.78

7.47 / 7.35

TABLE II W EIGHTED AVERAGE OF WATTS P OWER C ONSUMPTION ON I NTEL X EON S ILVER Test Config

Alto CPU (Docker/Native)

Anvil CPU (Docker/Native)

Global CPU (Docker/Native)

Alto DRAM (Docker/Native)

Anvil DRAM (Docker/Native)

Global DRAM (Docker/Native)

System Idle

1.42 / 2.98

18.31 / 14.25

66.41 / 64.48

0.19 / 0.11

7.26 / 5.06

13.41 / 11.56

Variation of Throttling per UserOp with 100 UserOps Burst Load per Round and 12s Blocks Frequency 25ms Throttling

17.36 / 16.16

9.07 / 12.78

55.85 / 59.78

2.03 / 2.40

1.04 / 1.80

6.52 / 7.94

50ms Throttling

12.57 / 12.79

11.05 / 13.13

56.81 / 59.77

3.27 / 1.64

2.60 / 1.49

9.68 / 7.03

100ms Throttling

7.97 / 5.86

11.85 / 13.46

60.17 / 58.30

0.88 / 0.69

3.41 / 1.73

8.91 / 7.34

Variation of UserOps Burst Load per Round with 25 ms Throttling per UserOp and 12s Blocks Frequency 75 UserOp Burst

14.86 / 14.89

10.61 / 12.10

57.57 / 56.04

3.39 / 1.80

2.96 / 1.44

10.32 / 6.71

50 UserOp Burst

11.28 / 10.78

12.77 / 12.51

59.35 / 56.14

1.40 / 1.44

1.51 / 1.41

7.22 / 6.48

25 UserOp Burst

7.96 / 7.39

12.37 / 13.43

59.35 / 52.79

0.83 / 0.91

1.47 / 1.59

7.16 / 6.44

Variation of Block Frequency with 100 UserOps Burst per Round and 25 ms Throttling per UserOp 2s Block

23.49 / 23.29

20.31 / 19.90

62.26 / 62.15

2.86 / 2.87

2.21 / 2.12

7.26 / 7.22

6s Block

22.01 / 20.74

12.84 / 12.22

60.25 / 56.79

3.70 / 2.50

2.37 / 1.33

9.29 / 6.52

which is more appropriate for a production scenario where isolation and portability are preferred, and another where the processes run natively on the server machines. Our evaluation focus was threefold. First, as in the previous study [13], we were interested in the overhead that the bundler brings to power consumption when running on an effective production node along with an EVM client. Second, we were interested in observing if production-oriented Docker setup brings a significant overhead compared to native runs. Finally, we wanted to observe how the different hardware architectures compare in the power consumption for Alto and Anvil. We leveraged SmartWatts to estimate the active power consumption scoped to the Alto and Anvil runs, supplemented by the global system load. The Intel server configurations expose both CPU and DRAM RAPL counters, allowing us to measure both values. The AMD configuration is limited to CPU data, similar to the evaluation context of the previous work [13]. The energy readings were captured at a 2Hz sampling interval, the default for SmartWatts, which can slightly vary depending on the hardware response. These sampling time variations

were captured in the final results weighted average, to which SmartWatts estimates an error in the range of 2 Watts. For most of our tests, we followed a methodology set in previous work [13]. We used UserOps burst loads of sizes from 25 to 100, addressed to different SCAs. We introduced various throttling between each UserOp sending. This simulates the variability of a real scenario, when the bundler could receive loads of requests triggered by certain events, but not all simultaneously. Finally, we varied the produced block frequency from 12 seconds, which is the Ethereum L1 standard, to lower values: 6 and 2 seconds, which are more specific for L2 EVM networks. The duration of the tests was set in the number of burst rounds, ranging from 50 to 300. One UserOp burst is typically processed in one or two blocks. Therefore, given the block intervals, the tests ran for at least 10 minutes. We summarise the weighted average power consumption across the various tests for the three configurations in Table I (IXG), Table II (IXS), and Table III (AMD). Overall, we observe the expected results: power increases with lower throttling, higher UserOp loads, and shorter block intervals.

80

Watts (W)

Intel Xeon Gold 70 Intel Xeon Silver AMD EPYC 60 50 40 30 20 10 0

1

2 3 Monitoring time sample (minutes)

4

5

Fig. 2. Power Consumption Sampling of Alto (100 UserOps bursts, 25ms throttling per UserOp, 12s block frequency)

TABLE III W EIGHTED AVERAGE OF WATTS C ONSUMPTION ON AMD EPYC Test Config

Alto CPU (Docker/Native)

Anvil CPU (Docker/Native)

Global CPU (Docker/Native)

System at Rest

0.84 / 0.88

6.52 / 1.64

41.50 / 41.18

Variation of Throttling with 100 UserOps Bursts and Blocks each 12s 25ms Throttling

16.44 / 16.78

6.83 / 6.60

43.96 / 43.70

50ms Throttling

13.09 / 13.39

7.31 / 6.28

44.50 / 47.46

100ms Throttling

6.01 / 7.65

8.28 / 5.88

46.32 / 46.95

Variation of UserOps Bursts with 25 ms Throttling and Blocks each 12s 75 UserOp Burst

15.69 / 14.85

9.92 / 6.32

43.59 / 42.74

50 UserOp Burst

12.44 / 13.13

9.76 / 6.09

42.43 / 41.41

25 UserOp Burst

7.58 / 9.12

9.05 / 4.65

41.17 / 40.43

Variation of Block Freq. with 100 UserOps Bursts and 25 ms Throttling 2s Block

27.33 / 28.49

13.25 / 9.09

49.25 / 49.05

6s Block

21.50 / 23.75

9.91 / 7.07

45.99 / 46.23

A first notable difference compared to previous empirical evaluations in [13] is that on all configurations Alto typically has a higher power consumption profile than the Anvil EVM client. The exceptions when Anvil tends to bypass Alto are the idle measurements and the tests with high throttling (100ms) or low UserOp burst load (25) at longer block intervals. This is explained by Anvil still running block production even with empty blocks. We believe that Alto dominates Anvil consumption in the rest of the tests because of the complexity of the ERC-4337 workflow compared to Anvil, which is a simulation client rather than a full EVM node. Further, Anvil was optimised starting from version 1.7 [39]. The important take-away remains the effective Alto overhead. While the average CPU power observed in previous mobile tests was below 4W, in production environments it can exceed 25W in the most demanding tests, with occasional spikes above 70W. For Docker-based and native runs, aside from a few outliers we attribute to concurrent operating system activity, their power consumption is rather similar. For tests using a 12-second block frequency, the average differences between Docker and native Alto are 0.69W for both Intel configurations and 0.61W for AMD.

Concerning the different hardware architectures, we observe that Intel Xeon Silver is the most power-demanding. Figure 2 displays a sample of the Alto power consumption captured on the test configurations. The difference between IXS and IXG can be explained by the fact that Xeon Silver uses a newergeneration processor, with a higher maximum turbo frequency. Given the burst characteristics of the workload, we noticed that the IXS CPU often reaches frequencies of 4̃GHz, which is higher than the maximum of the other processors. Also, the AMD CPU has a slightly higher base frequency than the IXG, resulting in a similar effect. Moreover, the Xeon Silver features 80 newer DDR5 PCIe 5.0 lanes, whereas the 6326 uses 64 DDR4 PCIe 4.0 lanes, which also contributes to the increase in power consumption. Regarding DRAM, we remark that this is considerably less significant than the CPU in the overall power consumption. For the tests that use a 12-second block frequency, Alto DRAM consumption does not exceed 20% of the CPU consumption, generally remaining below 3W. V. C ONCLUSION In this paper, we measured the power costs of ERC-4337 bundling on production server infrastructure. To our knowledge, this is the first evaluation of this kind, with previous work limited to estimations on mobile processors. We tested multiple configurations of UserOp workloads on three different representative server configurations: Intel Xeon Gold, Intel Xeon Silver and AMD EPYC. The highest weighted averages of the bundler were in the range of 25W, compared to 4W on the mobile platforms. This is expected for a production platform and can still be regarded as a low value in terms of costs, given that server-grade CPUs have considerably higher TDP (e.g., 185W for the Xeon Gold compared to 5̃0W or lower on mobile processors). Our findings confirm the feasibility of co-hosting the bundler with an EVM node from an energy-efficiency perspective. The correlated results of our study that show non-significant differences in running bundler services in containers also strengthen the idea of a colocated service. Future research can investigate the advanced bundling considerations that we identified, as well as the power consumption of other bundlers.

ACKNOWLEDGMENT This work was supported by CHIST-ERA-23-SMARTC-01SCEAL project, through a grant from the Romanian Ministry of Research, Innovation and Digitization, CNCS/CCCDI UEFISCDI, project number 86/2025 ERANET-CHISTERAIV-SCEAL, within PNCDI IV and from the Swiss National Science Foundation under Project 20CH-1 229451. R EFERENCES [1] G. Wood. (2025) Ethereum: A secure decentralised generalised transaction ledger. https://ethereum.github.io/yellowpaper/paper.pdf. [2] S. Chandra and S. Aggarwal. (2022) Web3: Onboarding the next billion users - The road ahead. [Online]. Available: https://cointelegraph.com/ news/web3-onboarding-the-next-billion-users-the-road-ahead [3] V. Buterin, Y. Weiss, D. Tirosh, S. Nacson, A. Forshtat, K. Gazso, and T. Hess. (2021) ERC-4337: Account abstraction using alt mempool. [Online]. Available: https://eips.ethereum.org/EIPS/eip-4337 [4] V. Buterin, S. Wilson, A. Dietrichs, and M. Garnett. (2024) EIP-7702: Set EOA account code. Ethereum Improvement Proposals. [Online]. Available: https://eips.ethereum.org/EIPS/eip-7702 [5] Turnkey.com. (2025) Account abstraction on Ethereum: From ERC4337 to EIP-7702. [Online]. Available: https://www.turnkey.com/blog/ account-abstraction-erc-4337-eip-7702 [6] Ethereum.org. (2025) Pectra 7702 Guidelines. [Online]. Available: https://ethereum.org/roadmap/pectra/7702/ [7] BundleBear.com. (2025) EIP-7702 2025 Year in Review. [Online]. Available: https://www.bundlebear.com/research/year-in-review/ eip7702-2025 [8] ——. (2026) EIP-7702 Metrics. [Online]. Available: https://www. bundlebear.com/eip7702-overview/all [9] ——. (2026) ERC-4337 bundlers. [Online]. Available: https://www. bundlebear.com/erc4337-bundlers/all [10] D. Coombs and D. Philipson. (2023) How user operation fees are estimated and charged. [Online]. Available: https://www.alchemy.com/ blog/user-operation-fee-estimation [11] Pimlico. (2026) Bundler FAQs. [Online]. Available: https://docs.pimlico. io/references/bundler/faqs [12] Ethereum.org. (2026) Ethereum’s energy expenditure. [Online]. Available: https://ethereum.org/energy-consumption/ [13] A. Arusoaie, C.-N. Bărbieru, O.-O. Captarencu, P.-F. Diac, E. Onica, and C.-N. Vârlan, “An introductory study on the power consumption overhead of ERC-4337 bundlers,” in 2025 9th International Symposium on Electrical and Electronics Engineering (ISEEE), 2025, pp. 1–6. [14] Etherscan.io. (2026) Ethereum Node Tracker. [Online]. Available: https://etherscan.io/nodetracker [15] G. Ishmaev, E. Anceaume, D. Frey, and F. Taı̈ani, “Ethical risk analysis of l2 rollups,” ACM Transactions on the Web, Dec. 2025. [Online]. Available: https://doi.org/10.1145/3786147 [16] G. Fieni, R. Rouvoy, and L. Seinturier, “SmartWatts: Self-calibrating software-defined power meter for containers,” in Proceedings of the 20th IEEE/ACM International Symposium on Cluster, Cloud and Internet Computing. IEEE and ACM, May 2020, pp. 45–54. [17] K. N. Khan, Z. Ou, M. Hirki, J. K. Nurminen, and T. Niemi, “How much power does your server consume? Estimating wall socket power using RAPL measurements,” ComputerScience - Research and Development, vol. 31, no. 4, p. 207–214, Nov. 2016. [18] M. Colmant, R. Rouvoy, M. Kurpicz, A. Sobe, P. Felber, and L. Seinturier, “The next 700 CPU power models,” Journal of Systems and Software, vol. 144, pp. 382–396, 2018. [19] H. Acar, G. I. Alptekin, J.-P. Gelas, and P. Ghodous, “The Impact of Source Code in Software on Power Consumption,” International Journal of Electronic Business Management, vol. 14, pp. 42–52, 2016. [20] S. Rivoire, P. Ranganathan, and C. Kozyrakis, “A comparison of highlevel full-system power models,” in Proceedings of the 2008 Workshop on Power Aware Computing and Systems, 2008. [21] T. Do, S. Rawshdeh, and W. Shi, “pTop: A process-level power profiling tool,” in Proceedings of the 2nd Workshop on Power Aware Computing and Systems. USENIX Association, 2009. [22] PowerApi.org. (2025) PowerAPI - Measuring power consumption of your applications. [Online]. Available: https://powerapi.org/

[23] Intel, “Intel 64 and IA-32 architectures software developer’s manual,” December 2022. [24] M. Colmant, M. Kurpicz, P. Felber, L. Huertas, R. Rouvoy, and A. Sobe, “Process-level power estimation in VM-based systems,” in Proceedings of the Tenth European Conference on Computer Systems. Association for Computing Machinery, 2015. [25] ETH-Infinitism. (2026) EIP4337 reference modules - Bundler. [Online]. Available: https://github.com/eth-infinitism/bundler [26] Pimlico. (2026) Alto Bundler. [Online]. Available: https://docs.pimlico. io/references/bundler [27] BundleBear.com. (2026) ERC-4337 bundlers - Ethereum network. [Online]. Available: https://www.bundlebear.com/erc4337-bundlers/ ethereum [28] Alchemy. (2026) Alchemy Rundler. [Online]. Available: https: //github.com/alchemyplatform/rundler [29] Thirdweb. (2026) Engine Core. [Online]. Available: https://github.com/ thirdweb-dev/engine-core [30] Coinbase. (2026) Paymaster and Bundler Examples. [Online]. Available: https://github.com/coinbase/paymaster-bundler-examples [31] R. Pereira, M. Couto, F. Ribeiro, R. Rua, J. Cunha, J. a. P. Fernandes, and J. a. Saraiva, “Energy efficiency across programming languages: How do energy, time, and memory relate?” in Proceedings of the 10th ACM SIGPLAN International Conference on Software Language Engineering, 2017, p. 256–267. [32] Foundry. (2025) Anvil - A fast local Ethereum development node. [Online]. Available: https://getfoundry.sh/anvil/overview/ [33] F. Vogelsteller and V. Buterin. (2015) ERC-20: Token standard. [Online]. Available: https://eips.ethereum.org/EIPS/eip-20 [34] S. Somin, Y. Altshuler, and A. Pentland, “Crypto-asset trading on top of Ethereum blockchain: comprehensive dataset,” Scientific Data, vol. 12, p. 1407, 2025. [35] DefiLlama. (2026) Uniswap (UNI) protocol stats. https://defillama.com/ protocol/uniswap. [36] ETH-Infinitism. (2025) Infinitism - Account abstraction. [Online]. Available: https://github.com/eth-infinitism/account-abstraction [37] Y. Weiss, D. Tirosh, A. Forshtat, and S. Nacson. (2023) ERC-7562: Account Abstraction Validation Scope Rules. Ethereum Improvement Proposals. [Online]. Available: https://eips.ethereum.org/EIPS/eip-7562 [38] Etherscan.io. (2026) EntryPoint v0.7.0. [Online]. Available: https: //etherscan.io/address/0x0000000071727de22e5e9d8baf0edac6f37da032 [39] Foundry. (2026) Release Log - v1.7.0. [Online]. Available: https: //github.com/foundry-rs/foundry/releases/tag/v1.7.0

Related documents

• A Comprehensive Tutorial and Survey of O-RAN: Exploring Slicing-Aware Architecture, Deployment Options, Use Cases, and Challenges#1379688
• Use Cases for Data Center Network Virtualization Overlay Networks#399304
• Enabling Real-Time Programmability for RAN Functions: A Wasm-Based Approach for Isolated and Deterministic dApps#1232679
• On the Optimal Co-location of Data Centers with Renewable Energy Sources in SIDS#1011691
• Ethereum Governance Discussion and Proposal Database for EIP/ERC Research, 2015-10-27 to 2026-02-12#122106