Non-Compensatory Security and Utility Gates for Blockchain Lifecycle Assessment: Framework Development and an Operational-Energy Application to the Ethereum Merge

Featured Application

The framework supports auditable sustainability and cyber risk assessment of cloud-integrated blockchain infrastructures, protocol upgrades, and public-sector or industrial distributed-ledger deployments.

Abstract

Environmental comparisons of blockchain systems are often reduced to electricity per transaction, although operational services also depend on validators, cloud gateways, storage, monitoring, key management, recovery, and hardware replacement. This study develops a lifecycle assessment framework with non-compensatory security and utility gates and applies its operational-energy module to Ethereum’s transition from proof of work (PoW) to proof of stake (PoS). Three units are separated: 24 h of observed network operation (FU-O), 24 h of fully security- and utility-qualified service (FU-Q), and one million included layer-1 transactions (FU-B, an attributional diagnostic). FU-Q is not evaluated because several mandatory gates remain UNRESOLVED. Matched 28-day activity windows are combined with dated network-energy estimates, not continuous metering over those windows. Using the independent Cambridge baseline, daily operational electricity decreased from 58,617.39 to 5.376 MWh, a factor of 10,903.5 and a reduction of 99.99083%. The CCRI replication factor was 8804.9, while an adverse bounded pairing still yielded a factor of 3424.7. Across 100,000 Monte Carlo realizations generated by the supplied executable workflow, the median FU-O reduction was 99.98698%, with a central 95% interval of 99.97492–99.99441%. Jansen sensitivity analysis identified post-Merge annual energy as the dominant input to the FU-O factor. The additional post-Merge cloud and annualized embodied burden required to eliminate FU-O parity was 21,408 GWh/year. The result is a bounded operational-energy application and does not establish the complete lifecycle, cloud, cybersecurity, or functional-equivalence framework.

1. Introduction

Blockchain systems transform electricity, hardware, communications, storage, cryptography, governance, and economic incentives into a shared digital state. Their environmental debate has focused primarily on proof-of-work mining, but a complete assessment must also consider validator infrastructure, embodied hardware, state replication, network communication, upgrades, forks, archival requirements, and end of life. Low operational electricity does not automatically imply low lifecycle burden, just as high transaction throughput does not establish equivalent security or utility [1,2,3,4,5].

The conventional denominator “per transaction” creates several distortions. Bitcoin mining energy is determined mainly by block rewards, fees, hardware efficiency, electricity price, and hashrate competition rather than by the number of transactions in a short interval. Smart-contract transactions vary by execution and storage demand. A rollup may represent thousands of off-chain operations in one base-layer commitment. Failed transactions consume resources without delivering utility. Permissioned ledgers can achieve high throughput partly because trust, governance, and validator admission are externalized.

Consensus mechanisms also produce different services. Proof of work purchases resistance through continuously expended computation. Proof of stake relies on bonded capital, slashing, protocol incentives, and validator diversity. Byzantine fault-tolerant systems rely on identified validator sets and explicit fault assumptions. Comparing their electricity without declaring the delivered security is analogous to comparing transport modes per vehicle rather than per safely delivered passenger.

The objective is to develop an auditable lifecycle assessment framework for cloud-integrated blockchain services and to demonstrate the bounded use of its operational-energy module through Ethereum’s transition from PoW to PoS. The application does not claim complete lifecycle coverage or full security and utility equivalence. Instead, it tests whether the framework can produce a reproducible module-specific result while explicitly narrowing the claim when mandatory evidence is unresolved.

Research Questions and Contributions

Three research questions guide the case: RQ1 asks how the transition changed operational energy and greenhouse-gas intensity per day of settlement service and per one million included layer-1 transactions; RQ2 asks how electricity mix, transaction throughput, cloud and embodied burdens, finality assumptions, and case-specific assurance-gate status modify the interpretation of the protocol-upgrade dividend; and RQ3 asks which uncertain inputs dominate the result and under what break-even conditions its direction would cease to be robust.

The contributions are: (1) an expanded system boundary covering consensus, execution, cloud delivery, storage, monitoring, key management, recovery, replacement, and end of life; (2) explicit separation of FU-O, FU-Q, and FU-B; (3) non-compensatory PASS/FAIL/UNRESOLVED assurance gates; (4) dimensionally consistent security lifecycle burden and intensity vectors; (5) an architecture-applicability map that separates established LCA, security, blockchain, and cloud concepts from their novel integration; and (6) a traceable operational-energy application with executable deterministic, Monte Carlo, Jansen, break-even, table, and figure generation.

2. Literature and Methodological Gap

2.1. Energy and Carbon Accounting

Studies of proof-of-work systems have estimated network electricity, carbon emissions, location-dependent generation mixes, marginal grid effects, and climate damages [1,6,7,8,9,10,11]. Other research has compared proof of work and proof of stake or evaluated the sharp energy reduction associated with Ethereum’s transition to proof of stake [12,13,14,15,16]. These studies demonstrate the importance of consensus design but also show wide uncertainty from miner location, hardware efficiency, electricity sourcing, system boundaries, and attribution methods.

2.2. Embodied Hardware and Electronic Waste

Mining relies on specialized ASICs whose economic life can be shorter than their physical life. Cradle-to-gate studies show that semiconductor production can contribute materially to lifecycle impacts, particularly in low-carbon electricity scenarios [17]. E-waste estimates are sensitive to assumed hardware lifespan, resale, repair, recycling, and whether obsolete mining devices have alternative uses [18,19]. PoS and permissioned networks use general-purpose servers, but lower per-device specialization does not eliminate embodied impacts when validator replication is large or hardware is overprovisioned.

2.3. Missing Functional Equivalence

Most comparisons normalize by transaction, block, market value, hashrate, or time. None guarantees equivalent trust production. A low-energy ledger with a small or concentrated validator set may not substitute for a globally adversarial settlement layer; conversely, a high-security public chain can be unnecessary for a closed consortium. The missing methodological element is a functional unit that requires equivalent useful transaction, finality, security, availability, and decentralization [2,3,4,5,20,21].

2.4. Positioning Relative to Adjacent Assessment Families

To make the incremental contribution explicit,

Table 1. Positioning of the proposed framework relative to adjacent blockchain-assessment families.

Assessment Family	Typical Unit and Boundary	Main Strength	Boundary Addressed by the Present Framework
Network-level energy and carbon accounting [1,6,7,8,9,10,11,22,23]	Network/year, day, or consensus operation; mainly operational electricity and GHG	Empirically tractable estimates of system-scale energy and emissions	Cloud services, embodied infrastructure, assurance, and functional equivalence are commonly outside the same decision model
Embodied hardware and e-waste assessment [17,18,19]	Device or hardware fleet across manufacture, use, replacement, and end of life	Makes manufacturing, lifetime, reuse, and retirement visible	Does not by itself establish the useful trust service delivered by the hardware
Transaction- or throughput-normalized comparison [10,11,12,13,14,15,16]	Transaction, block, gas/work unit, or throughput denominator	Provides an intuitive intensity metric and supports operational comparison	May imply marginal causation and may treat non-equivalent transactions or services as interchangeable
Consensus, decentralization, and security assessment [2,3,4,20,21,24,25,26,27]	Protocol, validator/miner set, attack surface, finality, and governance	Represents trust assumptions, attack resistance, and concentration	Environmental and cloud-service burdens are usually evaluated separately
Lifecycle, cloud, and cybersecurity standards [5,28,29,30,31,32,33,34,35,36,37,38,39]	Organization, information system, control lifecycle, and facility infrastructure	Provides mature boundary, governance, and control principles	Does not provide a blockchain-specific service denominator or protocol-transition calculation pipeline
Present framework	FU-O: 24 h observed operation; FU-Q: 24 h fully qualified service; FU-B: one million included L1 transactions; extended lifecycle boundary	Integrates provenance, non-compensatory gates, cloud/security modules, uncertainty, and break-even analysis	Reports a bounded module when evidence is incomplete and prohibits full equivalence claims when mandatory gates are unresolved

compares the proposed framework with the principal assessment families on which it builds. The comparison is not intended to diminish the value of narrower methods; it identifies the boundary that remains when energy, hardware, trust production, cloud delivery, and assurance are studied separately.

Table 1 shows that the novelty lies in the decision architecture rather than in any individual metric. The framework uses established LCA, security, and cloud concepts as inputs, then adds a declared service boundary, a non-compensatory eligibility rule, explicit provenance classes, and a reproducible uncertainty pipeline.

2.5. Structured Critical Evidence Synthesis and Framework Development

The evidence base was frozen on 23 July 2026 as a structured critical synthesis supporting framework construction and model-input selection; the article is not presented as a systematic review or meta-analysis, and exhaustive PRISMA screening counts are therefore not claimed. The source set combines peer-reviewed research, standards, protocol specifications, public-chain statistics, and primary institutional reports. Six reproducible query blocks covered blockchain lifecycle assessment, PoW/PoS energy, the Ethereum Merge, embodied hardware and e-waste, consensus and decentralization, cloud/off-chain infrastructure, cybersecurity governance, recovery, and protocol migration. The exact query blocks and their purposes are reported in Appendix A,

Table A1. Query blocks used to identify evidence for framework construction and case input selection.

Query Block	Representative Expression	Purpose
Energy and LCA	(blockchain OR distributed ledger) AND (life-cycle assessment OR energy OR electricity OR carbon)	Identify network-level energy/GHG methods and LCA boundaries
Consensus transition	Ethereum AND (Merge OR proof-of-stake OR EIP-3675) AND (energy OR electricity OR transaction OR block time)	Identify pre-/post-Merge empirical and institutional evidence
Hardware and end of life	blockchain AND (ASIC OR server OR embodied carbon OR electronic waste OR hardware lifetime)	Identify manufacturing, replacement, reuse, and e-waste evidence
Trust production	blockchain AND (consensus OR finality OR decentralization OR concentration OR validator diversity)	Identify functional-equivalence and assurance dimensions
Cloud and off-chain delivery	blockchain AND (cloud OR RPC OR indexer OR bridge OR oracle OR storage OR provider concentration)	Identify service-level infrastructure and common-mode dependencies
Cybersecurity and evolution	blockchain AND (cybersecurity lifecycle OR recovery OR migration OR cryptographic agility OR software supply chain)	Identify control burdens, residual risk, recovery, and migration processes

.

Evidence was classified into five domains: network energy and emissions; hardware manufacturing and end of life; consensus and decentralization; cloud and off-chain infrastructure; and cybersecurity governance and recovery. Every quantitative item was labelled as measured, source-reported, author-derived, or scenario-only. Model-driving evidence had to satisfy three mandatory conditions: direct relevance to the declared quantity, a traceable underlying method or dataset, and temporal/technical alignment with the case. Five supplementary quality criteria—system-boundary transparency, reproducible extraction or equations, uncertainty treatment, authoritative or peer-reviewed status, and funding/conflict transparency—were recorded but were not allowed to compensate for failure of a mandatory condition. Sources failing a mandatory condition were retained only as contextual studies and were excluded from numerical inputs.

Twenty-two core sources passed the source-use audit and are listed with their exact role in Appendix A,

Table A3. Twenty-two-source evidence-use register for framework construction and the Ethereum case.

Ref.	Domain/Source Type	Primary Role in the Manuscript	Use Status and Provenance
[2]	Consensus survey; peer-reviewed	Consensus assumptions and finality	Contextual; source-reported
[3]	Architecture taxonomy; peer-reviewed	Blockchain architecture classification	Contextual; source-reported
[4]	NIST technical overview	Blockchain terminology and technical boundary	Contextual; authoritative
[6]	Network energy; peer-reviewed	PoW energy-estimation context	Contextual; source-reported
[7]	Network carbon; peer-reviewed	Location-sensitive carbon accounting	Contextual; source-reported
[10]	Network energy; peer-reviewed	Consensus energy and attribution critique	Contextual; source-reported
[11]	Systematic review; peer-reviewed	Research-rigour and boundary guidance	Contextual; source-reported
[12]	Consensus energy; conference study	Cross-consensus energy comparison	Contextual; source-reported
[13]	Consensus economics; peer-reviewed	PoS security/economic mechanism	Contextual; source-reported
[14]	Merge event study; peer-reviewed	Transition context and market event	Contextual; source-reported
[15]	Merge operation; preprint	Transaction, fee, and time dynamics	Contextual; source-reported
[16]	Protocol/institutional source	Ethereum energy and consensus context	Contextual; source-reported
[17]	Hardware LCA; preprint	Mining-equipment cradle-to-gate boundary	Contextual; source-reported
[18]	E-waste; peer-reviewed	Hardware lifetime and e-waste mechanism	Contextual; source-reported
[20]	Permissioned blockchain; peer-reviewed	BFT/consortium architecture	Contextual; source-reported
[21]	Decentralization study; peer-reviewed	Concentration and diversity evidence	Contextual; source-reported
[22]	Primary institutional dataset/report	Central pre-/post-Merge energy baseline	Model-driving; source-reported and author-annualized
[23]	Independent measured-hardware report	Replication branch and post-Merge bounds	Model-driving; source-reported and author-recalculated
[28]	ISO standard	LCA principles and system-boundary rules	Contextual; authoritative
[29]	NIST framework	Cybersecurity governance and control lifecycle	Contextual; authoritative
[31]	ENISA report	Cloud common-mode and provider risk	Contextual; authoritative
[40,41,42]	Public explorer statistics	Matched-window transactions, blocks, and block time	Model-driving; source-reported and author-aggregated

. Framework construction then followed four steps: definition of the trust service and functional equivalence; mapping of physical, cloud, protocol, and cybersecurity boundaries; formulation of allocation and lifecycle indicators; and empirical testing through matched pre-/post-Merge activity observations, dated energy estimates, Monte Carlo uncertainty, global sensitivity, and algebraic break-even analysis. This separation prevents contextual concepts, scenario bounds, and author-derived calculations from being presented as direct measurements [28,34].

The integrated physical, protocol, cloud, cybersecurity, and application boundary produced by the framework-development process is summarized in Figure 1. The layered representation makes the dependency of application utility on lower-level infrastructure and assurance services explicit.

Figure 2 complements the layered boundary by showing the temporal lifecycle through which hardware, software, state, cryptography, and governance knowledge are created, retained, migrated, or retired. The circular representation is used because a protocol upgrade may preserve some trust-producing assets while replacing others.

3. Blockchain Lifecycle System Model

This section introduces a unified system model for evaluating blockchain infrastructures from a lifecycle perspective. The model extends conventional assessments focused primarily on operational electricity consumption by considering the complete chain of physical, computational, and security-related processes required to provide a reliable blockchain service. The system boundary therefore includes hardware manufacturing and deployment, network operation, consensus execution, data storage, maintenance and component replacement, infrastructure expansion, and end-of-life treatment [4,28,34].

The proposed framework treats a blockchain not merely as a consensus algorithm but as a distributed cyber–physical service system. Its environmental and operational performance depends on the interaction between the ledger architecture, the consensus mechanism, the participating computing and communication infrastructure, the security requirements, and the useful workload successfully delivered to end users. Consequently, comparisons based only on electricity consumption per transaction may produce misleading results, particularly when the evaluated systems differ in transaction finality, availability, security assurance, or processing capacity.

To support consistent comparisons, the model associates every lifecycle phase with its corresponding physical processes, resource inputs, operational outputs, security functions, and measurable environmental burdens. The general lifecycle impact of blockchain system j can be expressed as

$$I_{LC,j}^{\left(c\right)}={\sum }_{x \in \mathcal{X}}{I}_{x,j}^{\left(c\right)}, c \in \mathcal{C}$$

(1)

where c denotes a homogeneous impact category, $𝒞$ is the set of reported categories, and $𝒳$ contains the embodied-hardware, operational, cloud, network, cybersecurity, maintenance, migration, and end-of-life modules. Each term retains the physical unit of category c; unlike categories, they are never summed.

Lifecycle impact categories are normalized only by an explicitly declared eligible service denominator. The framework does not multiply the denominator by a compensatory quality score. Instead, mandatory security, finality, availability, decentralization, privacy, and residual-risk conditions are evaluated before normalization. A FAIL blocks comparison, and an UNRESOLVED condition restricts the result to the module for which evidence is sufficient.

$${\iota }_{LC,j}^{\left(c\right)}={\displaystyle \frac{I_{LC,j}^{\left(c\right)}}{N_{eligible,j}}}, c \in \mathcal{C},$$

(2)

where ${\iota }_{LC,j}^{\left(c\right)}$ is the lifecycle impact of system j in category c and $N_{eligible,j}$ is the eligible service denominator declared for the comparison. Gate status is recorded alongside the category-specific intensity; it is neither multiplied into the denominator nor used as an environmental weighting factor.

3.1. System Boundaries

The lifecycle boundary shown in Figure 2 is circular because hardware, software clients, cryptographic libraries, ledger state, operational knowledge, and governance mechanisms may be retained across upgrades. Figure 3 separately defines the empirical boundary around The Merge: a 28-day PoW window, a seven-day transition exclusion, and a 28-day PoS window feeding one common calculation pipeline.

The minimum system boundary includes active consensus nodes, transaction execution, inter-node communication, ledger storage, cooling and auxiliary electricity, embodied node hardware, component replacement, protocol upgrades, and end-of-life treatment. The extended boundary additionally includes client and protocol development, user devices where their contribution is material, layer-2 systems, bridges, oracle infrastructure, off-chain storage, managed service components, and long-term archival. Token-market activity is not automatically attributed to the lifecycle burden of transaction processing; however, infrastructure that is directly required or induced by delivery of the declared blockchain service must be included.

The application of the proposed system boundary requires a clear mapping between lifecycle phases and the processes included in the assessment.

Table 2. Blockchain lifecycle phases, included processes, principal burdens, and required inventory records.

Phase	Included Processes	Principal Burdens	Required Records
Hardware	ASIC/server manufacturing, storage, networking, cooling	Embodied carbon, water, materials, toxicity	Device type, quantity, lifetime, reuse
Bootstrapping	Client development, genesis, validator recruitment, initial distribution	Development compute, duplicated infrastructure	Software versions, initial nodes, allocation
Consensus	Mining, validation, attestations, committee communication	Electricity, cooling, capital, availability	Power, hashrate/stake, validator count
Execution	Signature checks, virtual-machine execution, smart contracts	CPU/GPU time, memory, failed execution	Gas/work units, success status
State and data	Replication, history, state growth, indexing, snapshots	Storage, network, archival energy	State size, replicas, retention
Evolution	Updates, governance, forks, migrations, bridges	Parallel infrastructure, duplicated state, security risk	Versions, fork duration, migration
Retirement	Node decommissioning, hardware resale/recycling, archival	E-waste, residual storage, migration	Second life, recycling, archive

summarizes this mapping and identifies the principal activities, resource flows, environmental burdens, and inventory records associated with each phase. The table also indicates where primary measurements, operator data, hardware specifications, or secondary lifecycle inventory datasets may be used. This structure reduces the risk of excluding burdens that occur outside the operational stage, particularly hardware production, component replacement, cooling infrastructure, and end-of-life management [28,34].

3.2. Cloud-Integrated Service Boundary

Operational blockchain services rarely consist only of consensus nodes. The extended service boundary may include cloud-hosted validators, managed remote procedure call (RPC) gateways, load balancers, content-delivery networks, indexers, blockchain explorers, object and database storage, oracle services, bridge relays, monitoring platforms, key-management services, hardware security modules, backup systems, and disaster-recovery capacity. Each component may contribute operational-energy consumption, embodied hardware impacts, network traffic, cybersecurity exposure, and vendor-concentration risk [31,39].

Cloud services are included when they are necessary to deliver the declared functional unit. Optional analytics services and speculative market infrastructure should be reported separately. The impacts of multi-tenant cloud resources may be allocated using measured processor, memory, storage, and network consumption; reserved capacity; or another explicitly disclosed allocation proxy. Consequently, a low node-level energy estimate cannot be interpreted as a complete service-level footprint when a substantial part of the workload is transferred to managed RPC gateways, indexers, cloud databases, or off-chain storage.

Figure 4 consolidates the physical, protocol, cloud, cybersecurity, and application layers included in the extended system boundary. The central ledger should not be interpreted as a self-contained service because practical delivery depends on semiconductor and server infrastructure, validator operation, managed cloud components, cryptographic key protection, security monitoring, data storage, software maintenance, and end-of-life pathways. The different flows distinguish routine digital operation, cyber assurance, lifecycle transition, and circular hardware reuse.

3.3. Reference Blockchain Architectures

The lifecycle profile of a blockchain service cannot be evaluated independently of its technical architecture. The consensus mechanism influences computational demand, hardware specialization, infrastructure redundancy, communication intensity, finality, scalability, and exposure to different cybersecurity threats. Four representative configurations are therefore considered: public proof of work (PoW), public proof of stake (PoS), committee-based PoS, and permissioned Byzantine fault-tolerant (BFT) consensus [2,3,12,13,20].

These configurations are analytical archetypes rather than direct representations of individual commercial networks. Their purpose is to establish comparable system characteristics and identify the parameters that must be measured in an empirical application of the proposed framework.

Table 3. Architectural, operational, and security parameters used to characterize the compared blockchain systems.

Architecture	Security Production	Typical Hardware	Main Lifecycle Risk	Comparison Condition
Public PoW	Competitive hashing and economic expenditure	Specialized ASICs	High electricity consumption; short economic hardware life	High adversary public settlement
Public PoS	Bonded stake, slashing, distributed validation	General-purpose servers	Validator/client concentration; duplicated nodes	Equivalent public finality and attack resistance
Delegated/committee PoS	Elected or limited validator committee	Servers and networking	Governance concentration	Declared committee and recovery assumptions
Permissioned BFT	Identified validators and Byzantine fault tolerance	Enterprise servers	Externalized trust and admission governance	Consortium service with matched availability

summarizes their principal architectural, operational, and security properties.

The comparison demonstrates that consensus mechanisms cannot be differentiated only by their electricity demand. Hardware requirements, communication patterns, finality mechanisms, governance arrangements, and resistance to adversarial control jointly determine the quality and resource intensity of the delivered blockchain service.

3.4. Cybersecurity as a Lifecycle Service Requirement

Cybersecurity is treated as an integral characteristic of the functional unit rather than as an external qualitative consideration. A blockchain configuration with low electricity consumption but insufficient resistance to consensus manipulation, validator compromise, denial-of-service attacks, key-management failures, or unauthorized administrative control cannot be considered functionally equivalent to a system satisfying the declared security requirements [5,21,24,25,29,30].

Security mechanisms may themselves require additional computation, communication, storage, redundant infrastructure, monitoring, auditing, backup, and recovery capacity. These requirements must therefore be represented within the lifecycle inventory whenever they are necessary for delivering the declared service.

Table 4. Cybersecurity characteristics and lifecycle implications of representative blockchain consensus architectures.

Security Component	Public PoW	Public PoS	Committee PoS	Permissioned BFT
Consensus protection	Hash competition	Stake and slashing	Committee governance	Identity and BFT
DDoS protection requirement	High	High	High	Medium–high
Identity-management burden	Low protocol dependence	Medium	High	Very high
Key-management burden	Medium	High	High	Very high
Monitoring and patching	Decentralized and heterogeneous	Decentralized and heterogeneous	Semi-centralized	Centralized/consortium
Dominant capture risk	Mining-pool concentration	Stake/cloud-provider concentration	Committee capture	Consortium/governance capture

compares the main security mechanisms, residual risks, and potential lifecycle implications of the selected consensus architectures.

The resulting environmental–security relationship should not be interpreted as a simple trade-off in which greater electricity consumption automatically provides greater security. Security assurance depends on the distribution of computational power or stake, validator independence, identity management, protocol implementation, operational monitoring, and incident-response capability. These factors must be evaluated together with energy and carbon indicators.

3.5. Ethereum Merge Case Study and Data

Ethereum Mainnet was evaluated before and after The Merge on 15 September 2022. The matched network-activity windows were 15 August–11 September 2022 for PoW and 19 September–16 October 2022 for PoS; 12–18 September was excluded to avoid mixing the transition and immediate stabilization period. Daily transactions, block counts, and mean block time were obtained from public explorer series. The matched windows characterize network activity only. Pre- and post-Merge electricity was represented by dated network-level estimates and measured-hardware envelopes rather than by continuous metering over those same 28-day windows [16,22,23,40,41,42].

Energy estimates were treated as dated network snapshots rather than direct metering of every node. The Cambridge estimate of 21.41 TWh/year before The Merge and the first post-Merge power estimate of 224 kW formed the independent baseline [22]. CCRI supplied a measured-hardware replication branch and a post-Merge node-power envelope [23]. Reported source values were retained unchanged in the raw-input layer; annualizations, reductions, and functional-unit allocations were explicitly identified as author-derived.

Table 5. Ethereum pre-/post-Merge case inputs and operational-energy results.

Branch or Metric	Pre-Merge	Post-Merge	Basis or Unit	Reduction or Change	Evidence	Interpretation
CCAF baseline	21.41 TWh/year	1.9636 GWh/year	Operational electricity	99.99083%; 10,903.5×	CCAF; author annualization	Primary FU-O
CCRI replication	22.90032 TWh/year	2.60086 GWh/year	Operational electricity	99.98864%; 8804.9×	CCRI; author recalculation	Triangulation
Adverse bounded pairing	21.41 TWh/year	6.2516 GWh/year	Operational electricity	99.97080%; 3424.7×	Lower pre/upper post	Stress branch
Matched service window	1,070,662.64 tx/day	1,136,444.43 tx/day	Included L1 transactions	+6.14%	Etherscan; 28-day means	FU-B diagnostic

Note: FU-O represents 24 h of observed network operation. FU-Q is not evaluated because mandatory assurance gates remain UNRESOLVED. The matched-window transaction row supports FU-B as an attributional included-transaction diagnostic only; it does not imply that an individual transaction causes network electricity use. Cloud services, embodied hardware, water, materials, and avoided incidents are not presented as measured values.

summarizes the principal pre- and post-Merge input parameters together with the corresponding operational-energy calculations for the three evaluation branches used in this study.

The primary FU-O calculation used 8766 h/year. FU-B allocated daily network energy to one million included layer-1 transactions for comparability. Because aggregate explorer series do not establish receipt-level success or application usefulness, FU-B was retained as a secondary diagnostic. FU-Q was not calculated.

The assurance layer was applied before environmental interpretation using three case-specific states: PASS, FAIL, and UNRESOLVED. PASS indicates that the declared condition and evidence requirement were met; FAIL excludes direct comparison; UNRESOLVED permits reporting of a clearly isolated module but blocks a full security- and utility-equivalence ranking. Protocol continuity passed because the Ethereum Mainnet identity and execution state were retained. Finality definitions were documented separately. Historical service-level availability, decentralization/concentration, client diversity, cloud concentration, and calibrated residual cyber risk could not be harmonized across the selected windows and therefore remained unresolved rather than being assigned invented values.

Table 6. Case-specific application of non-compensatory assurance gates to the Ethereum Merge assessment.

Gate	Operationalization in the Present Case	Status	Decision Effect
Protocol and service continuity	Same Ethereum Mainnet identity and execution state were retained across The Merge	PASS	Supports a within-platform protocol-transition comparison
Observation boundary	Matched 28-day activity windows; separate dated energy estimates and hardware envelopes	PASS with bounded scope	Supports attributional operational-energy analysis, not continuous-window metering
Finality definition	PoW probabilistic confirmation and PoS checkpoint finality are declared separately	PASS as a profile	Prevents an unsupported claim of identical finality mechanisms
Availability	No harmonized service-level outage/availability series for both windows	UNRESOLVED	Blocks a complete service-equivalence claim
Decentralization and concentration	No matched-window, method-consistent mining/stake/operator concentration measure	UNRESOLVED	No decentralization-superiority claim is made
Software-client diversity	No harmonized matched-window client-diversity dataset in the case inventory	UNRESOLVED	Client-diversity risk remains non-compensatory
Cloud-provider concentration	No service-level allocation of validators, RPC, storage, monitoring, and recovery by provider/domain	UNRESOLVED	Cloud common-mode risk cannot be converted into an energy credit
Privacy/confidentiality boundary	Public settlement is the declared service; private-service equivalence is not asserted	PASS for declared boundary	Privacy is not used to generalize to confidential applications
Residual cyber risk and recovery	No calibrated incident probabilities, control effectiveness, or recovery outcomes for both windows	UNRESOLVED	Energy reduction cannot compensate for unknown residual risk
Overall eligibility	FU-O operational module versus FU-Q complete security- and utility-qualified lifecycle equivalence	PASS/UNRESOLVED	FU-O is reportable; FU-Q remains UNRESOLVED and full equivalence is not established

makes the resulting gate application explicit. Its purpose is to show exactly which claim is supported by the case and which broader equivalence claims remain outside the available evidence.

The final row is deliberately asymmetric. The available evidence is sufficient to quantify the operational-energy module, but it is insufficient to certify complete equivalence across availability, decentralization, cloud concentration, client diversity, and residual cyber risk. The framework therefore returns a bounded result rather than forcing an all-or-nothing ranking.

3.6. Attributional and Consequential Perspectives

Attributional assessment assigns the observed burdens of the blockchain system to the services delivered during the selected assessment period. It describes how energy use, embodied impacts, infrastructure requirements, and emissions are distributed among the completed functional units under the existing system configuration [28,34].

Consequential assessment instead examines how environmental burdens may change when an additional transaction workload, application, protocol upgrade, infrastructure expansion, or alternative consensus architecture is introduced. For PoW systems, an additional transaction may have little immediate effect on mining electricity consumption, whereas long-term changes in transaction demand, fees, token value, and miner revenue may influence installed hashrate and total electricity use. In PoS and permissioned systems, marginal demand may initially be absorbed by existing capacity but may eventually trigger additional validators, cloud resources, storage, communication capacity, or backup infrastructure.

Both perspectives provide useful but conceptually different information. Attributional and consequential results must therefore be reported separately and should not be combined within a single per-transaction indicator. The selected perspective, assessment period, allocation procedure, marginal-response assumptions, and infrastructure-expansion thresholds must be explicitly stated.

The proposed system model consequently integrates lifecycle processes, cloud-supported service delivery, consensus architecture, cybersecurity assurance, and the selected modelling perspective. This structure provides the methodological basis for the calculation procedure, scenario comparison, sensitivity analysis, and interpretation of results presented in the following sections.

4. Observed, Qualified, and Attributional Units with Non-Compensatory Assurance Gates

Three units prevent observed operation, qualified service, and transaction allocation from being conflated. FU-O is the primary empirical unit and represents 24 h of observed Ethereum Mainnet operation within the stated boundary. FU-Q represents 24 h of fully security- and utility-qualified service and may be reported only when every mandatory gate is PASS. FU-B is a secondary attributional diagnostic representing one million included layer-1 transactions; it is not interpreted as the marginal electricity caused by one additional transaction.

The observed operational functional unit used in the case is defined as

$${\mathrm{F}\mathrm{U}-\mathrm{O}}_s :=24 \mathrm{h} of observed network operation within B_s$$

(3)

The fully qualified unit is FU-Q = 24 h of delivered service subject to all mandatory security, finality, availability, decentralization, privacy, and residual-risk gates being PASS. FU-Q is not evaluated in the present case because Table 6 contains UNRESOLVED mandatory gates. The secondary reporting unit is FU-B = 10⁶, including layer-1 transactions over the same observation period and operational boundary. FU-B remains an attributional diagnostic because public daily totals do not establish application usefulness or receipt-level success.

The distinction is causal as well as numerical. FU-O describes observed network-level operation, FU-Q denotes a fully qualified service only after every mandatory gate passes, and FU-B is an attributional allocation for comparison with the earlier literature. Failed, reverted, spam-related, or application-irrelevant operations must not be silently presented as useful outputs when receipt-level or application-level data are available.

Figure 5 illustrates how the proposed functional unit is derived from observable network activity. Raw submitted operations are progressively filtered according to execution success, finality, application utility, privacy compliance, and acceptable residual cyber risk. This filtering process prevents unsuccessful, insecure, or application-irrelevant activity from artificially increasing the denominator and consequently reducing the reported environmental intensity.

The qualified functional unit is formally eligible only when every mandatory gate is PASS:

$${\mathrm{F}\mathrm{U}-\mathrm{Q}}_s := 24 \mathrm{h} of qualified service, G_{q,s} = \mathrm{P}\mathrm{A}\mathrm{S}\mathrm{S} \forall q \in \mathcal{Q}$$

(4)

Here, $𝒬$ is the predeclared set of mandatory gates: security, finality, availability, decentralization, privacy, and residual risk. An UNRESOLVED gate does not satisfy FU-Q and cannot be converted into a favourable score; it restricts reporting to the module supported by the available evidence.

The attributional diagnostic is defined as

$${\mathrm{F}\mathrm{U}-\mathrm{B}}_s :={10}^6 included L1 transactions over the same T_s and B_s$$

(5)

FU-B allocates observed system burdens to a fixed block of included layer-1 transactions and does not imply marginal causation or full functional equivalence. When receipt-level evidence is available, the separately reported qualified count in Equation (6) should be used to disclose successful, finalized, useful, and constraint-compliant outcomes.

4.1. Useful and Finalized Transaction Count

The qualifying transaction count is calculated as

$$N_{useful,final,s}={\displaystyle {\sum }_{i=1}^{N_{submitted,s}}}\mathbb{1}[S_i=1]\mathbb{1}[F_i=1]\mathbb{1}[U_i=1]\mathbb{1}[C_i=1]$$

(6)

where 1[⋅] is the indicator function, S_i denotes successful execution, F_i denotes satisfaction of the selected finality rule, U_i indicates application-specific utility, and C_i represents compliance with the remaining service constraints.

The utility criterion is necessarily application-specific. For a payment system, utility requires a correctly settled value transfer. For a supply-chain application, it requires an accepted and non-duplicated provenance update. For a smart-contract service, the functional output may instead be expressed through a quality-adjusted computational work unit. The declared utility rule must be observable, reproducible, and applied consistently across all compared systems.

Layer-2 processing requires particular attention to prevent double counting. A batch may be represented by the number of valid user operations it contains or by the corresponding base-layer commitment, depending on the declared service. The same operation must not be counted simultaneously as both a layer-2 transaction and a base-layer transaction. Failed batch submissions, challenged state transitions, and reverted commitments must be reported separately [27].

4.2. Security Equivalence

Security cannot be represented completely by a single scalar indicator. The primary assessment therefore reports a multidimensional security profile containing at least [2,5,21,24,25]:

• The resources or economic cost required for a successful attack;
• Validator, stake, or mining-power concentration;
• Geographic and organizational validator diversity;
• Software-client diversity;
• Byzantine fault tolerance;
• Finality assumptions and reorganization exposure;
• Validator penalties or slashing exposure;
• Cryptographic key-management arrangements;
• Bridge, oracle, and cloud-service dependencies;
• Incident-detection and recovery capability;
• Exposure to governance capture.

Security assurance is represented by a dimensionless component vector ${\mathit{z}}_s$ rather than by a weighted Security Assurance Factor. Each component is mapped monotonically to [0, 1] using a declared, evidence-based measurement rule, and its acceptance threshold is fixed before comparison:

$$G_{sec,s} = \left\{\begin{array}{cc}\mathrm{P}\mathrm{A}\mathrm{S}\mathrm{S}& z_{k,s} \ge {\tau }_k for all k \in \mathcal{K}\\ \mathrm{F}\mathrm{A}\mathrm{I}\mathrm{L}& z_{k,s} < {\tau }_k for any observed k \in \mathcal{K}\\ \mathrm{U}\mathrm{N}\mathrm{R}\mathrm{E}\mathrm{S}\mathrm{O}\mathrm{L}\mathrm{V}\mathrm{E}\mathrm{D}& \mathrm{o}\mathrm{t}\mathrm{h}\mathrm{e}\mathrm{r}\mathrm{w}\mathrm{i}\mathrm{s}\mathrm{e}\end{array}\right.$$

(7)

Here, z_k,s denotes the normalized evidence for the mandatory security component k and τ_k its minimum acceptable threshold. Equation (7) implements three-valued logic: all mandatory components must be observed and pass for PASS; any observed threshold violation produces FAIL; missing mandatory evidence produces UNRESOLVED. The gate is non-compensatory.

A scenario passes the security gate only when every mandatory component meets its threshold. A failed component cannot be offset by another component, and an unmeasured component yields UNRESOLVED rather than zero or an imputed mean. Optional decision-specific weighting may be reported separately only after gate eligibility, with the elicitation method and weight-sensitivity analysis disclosed.

4.3. Privacy and Confidentiality Compliance

Privacy requirements differ substantially among blockchain applications. Public transaction visibility may be acceptable for a public settlement network but unsuitable for healthcare, industrial, governmental, or supply-chain applications. The privacy factor P therefore evaluates compliance with the declared application requirements rather than assuming that maximum data secrecy is universally preferable [25,30,33].

The privacy profile may include transaction confidentiality, identity protection, metadata exposure, access control, data minimization, selective disclosure, regulatory compliance, and protection of off-chain data. Privacy-enhancing mechanisms such as zero-knowledge proofs, secure enclaves, encryption, permissioned access, or off-chain confidential storage may introduce additional computation, communication, hardware, and key-management burdens. These burdens must be included in the lifecycle inventory when the corresponding mechanisms are required to satisfy P_min.

4.4. Residual Cyber Risk

Residual cyber risk is evaluated by threat category after preventive, detective, responsive, and recovery controls. For threat category k and scenario s, the expected residual consequence is

$$r_{k,s}\left(T\right)=p_{k,s}\left(T\right)L_{k,s}\left(1-e_{k,s}\left(T\right)\right)$$

(8)

where T is the declared assessment horizon, p_k,s(T) is the probability or frequency of threat k over T, L_k,s is its consequence in a declared common unit, and e_k,s(T) is control effectiveness on [0, 1]. If calibrated probabilities are unavailable, the category remains ordinal or UNRESOLVED and is not converted into a spurious expected value.

The residual-risk result is the vector r_s = (r_1,s,…,r_K,s). Summation is permissible only when all consequences share a justified unit and dependence among events is addressed. Eligibility requires every mandatory category to satisfy r_k,s ≤ τ_k. This prevents low estimated risk in one category from concealing an unacceptable ledger-integrity, availability, key-management, bridge, cloud, or governance risk.

4.5. Functional Equivalence and Reporting Rules

Two blockchain configurations are considered fully functionally equivalent only when they deliver the same declared application outcome and satisfy the same minimum thresholds for security, finality, availability, decentralization, privacy, and residual risk. Gate status is three-valued. PASS permits the declared comparison; FAIL excludes the configuration; UNRESOLVED blocks a complete equivalence ranking but may permit a module-specific result when the system boundary, evidential limitation, and prohibited inference are stated explicitly. A system failing or lacking evidence for a mandatory condition must not be ranked as comprehensively superior merely because it consumes less energy.

For every comparative application of the framework, the following information should be disclosed:

• Number of submitted operations;
• Number and share of successfully executed operations;
• Number of finalized and subsequently reverted operations;
• Number of useful application-level outcomes;
• Excluded spam, churn, duplicate, and failed operations;
• Finality rule and observation period;
• Availability and outage definition;
• Security and decentralization thresholds;
• Privacy requirements;
• Residual-risk categories and control assumptions;
• Final qualifying functional-unit denominator.

The use of these reporting rules makes the environmental intensity indicator auditable and prevents changes in transaction classification from being mistaken for improvements in blockchain sustainability.

4.6. Operational Decision Sequence

The indicators are applied through a fixed decision sequence: (1) declare the service, system boundary, observation period, provenance classes, and impact categories; (2) use FU-O for observed operation, FU-Q only when every mandatory gate is PASS, and FU-B only as an explicitly labelled attributional diagnostic; (3) assign PASS, FAIL, or UNRESOLVED to each gate; (4) calculate outputs only for the eligible module; (5) propagate uncertainty and solve break-even conditions; and (6) add cloud, recovery, state-growth, and circularity modules without allowing them to conceal a failed or unresolved gate.

5. Cybersecurity Across the Blockchain Lifecycle

Cybersecurity is not a one-time property established during system deployment. It is a continuous lifecycle process that begins during architecture design and continues through implementation, commissioning, operation, maintenance, protocol evolution, incident recovery, cryptographic migration, and secure retirement. Security decisions made at each stage influence not only residual cyber risk but also energy consumption, hardware demand, storage growth, communication traffic, administrative effort, and the useful lifetime of the infrastructure [24,29,33].

Cybersecurity controls therefore form part of the blockchain service system defined in Section 3 and of the assurance conditions incorporated into the functional unit in Section 4. Their resource burdens must be included when they are necessary to meet the declared minimum security, availability, privacy, and residual-risk thresholds. At the same time, these burdens should be interpreted in relation to the operational disruption, data loss, hardware replacement, emergency migration, and loss of useful service that the controls may prevent.

5.1. Threat Modelling and Secure Design

The temporal organization of blockchain cybersecurity assurance is illustrated in Figure 6. The process is represented as a feedback loop because operational monitoring, vulnerability discovery, incident analysis, and technological change continually generate new requirements for system design and control implementation. Assurance consequently evolves through threat modelling, secure design, identity enrollment, continuous monitoring, vulnerability management, incident recovery, cryptographic migration, and secure retirement.

The cybersecurity lifecycle begins before deployment with asset identification, threat modelling, trust-boundary definition, attack-surface analysis, cryptographic selection, identity and key architecture, software-supply-chain controls, and recovery planning. The design stage should identify not only the consensus layer but also cloud accounts, RPC services, bridges, oracles, smart contracts, administrative interfaces, software repositories, signing infrastructure, monitoring systems, backup facilities, and external dependencies.

Relevant threats include consensus manipulation, validator or miner compromise, denial-of-service attacks, eclipse and routing attacks, smart-contract vulnerabilities, oracle manipulation, bridge compromise, cryptographic key theft, unauthorized or malicious upgrades, cloud-account takeover, software-supply-chain compromise, insider threats, and correlated infrastructure-provider failure. Threat scenarios should specify the exposed asset, attack preconditions, expected consequence, detection mechanism, recovery pathway, and corresponding control requirements [5,24,25,26].

Threat modelling also supports lifecycle inventory construction. For example, a requirement for geographic redundancy introduces additional servers, storage, network traffic, and embodied hardware impacts. A requirement for offline or hardware-protected signing introduces hardware security modules, backup key systems, and secure operational procedures. These additions should be connected explicitly to the risks they are intended to reduce.

5.2. Secure Deployment and Continuous Operation

Secure deployment includes authenticated network bootstrapping, validator enrollment, hardened system images, secure configuration, least-privilege access, secrets management, protected signing keys, logging, network segmentation, redundancy, and tested backup and recovery procedures. Hardware security modules or other trusted-key-storage systems should be included when they are necessary to satisfy the declared key-protection requirement [29,30,33].

Continuous operation includes system telemetry, intrusion detection, anomaly analysis, consensus-health monitoring, client-diversity monitoring, key rotation, certificate renewal, vulnerability scanning, security updates, access review, capacity protection, backup verification, and recovery exercises. The corresponding resource flows may include additional processor utilization, permanent telemetry collection, security-log storage, replicated monitoring services, redundant network capacity, and dedicated security appliances.

The lifecycle inventory should distinguish between resources consumed by normal blockchain operation and resources required specifically for cybersecurity assurance. This distinction does not imply that security is optional; rather, it makes the additional burden of maintaining a declared assurance level measurable and auditable. Shared infrastructure should be allocated using measured utilization, reserved capacity, or another disclosed allocation rule.

5.3. Vulnerability, Patch, and Incident Lifecycle

A detected vulnerability initiates a sequence of activities that may include technical triage, coordinated disclosure, patch development, code review, testing, external audit, validator communication, software distribution, adoption monitoring, emergency governance, state migration, smart-contract migration, and post-incident analysis. The lifecycle implications depend not only on the vulnerability itself but also on the speed and completeness of patch adoption across the network [26,29,33,35].

The associated footprint may include duplicate test networks, continuous-integration infrastructure, code-build and audit services, parallel client versions, temporary overprovisioning, delayed decommissioning, forensic data retention, emergency communication, and recovery operations. A serious incident may additionally require ledger rollback, compensating transactions, contract replacement, user migration, bridge suspension, or deployment of a successor network.

An architecture with low routine electricity consumption but weak vulnerability management, slow patch adoption, or inadequate recovery capability may deliver less useful lifecycle service than a moderately more resource-intensive but resilient system. The assessment should therefore report patch coverage, time to remediation, recovery time, and the fraction of affected service alongside the resource burden of vulnerability management.

5.4. Cryptographic Agility and Secure Retirement

Long-lived blockchain systems must support the migration of cryptographic algorithms, protocols, identities, and keys. This requirement is particularly important when algorithms become vulnerable, regulatory requirements change, or post-quantum cryptographic mechanisms are introduced. Cryptographic agility should therefore be treated as a lifecycle design property rather than an emergency feature [32,36,37,38].

Migration may require dual-signature periods, replacement of hardware security modules, new client software, smart-contract modification, key re-enrollment, data re-signing, and maintenance of compatibility with historical records. Larger keys and signatures may increase verification work, block size, network traffic, ledger state, archival storage, and synchronization time. These effects should be included when comparing current and migration-ready architectures.

Secure retirement includes service termination, user notification and migration, contract closure, state export, revocation or destruction of cryptographic keys, data-retention decisions, hardware sanitization, equipment reuse or recycling, and preservation of the minimum evidence required for legal, operational, or security audit. The retirement process must prevent abandoned credentials, unmanaged cloud resources, exposed backups, and obsolete nodes from remaining part of the attack surface.

5.5. Security Lifecycle Indicators

Security lifecycle burden is reported as a vector of homogeneous impact categories. For category c (for example, energy, GHG emissions, water, material mass, storage, or cost), the burden is calculated from security activity quantities and category-specific factors:

$${\mathrm{S}\mathrm{L}\mathrm{C}\mathrm{B}}_s^{\left(c\right)} = {\sum }_{p \in {\mathcal{P}}_{\mathrm{s}\mathrm{e}\mathrm{c}}}{q}_{p,s}{f}_{p,s}^{\left(c\right)}, c \in \mathcal{C}$$

(9)

Here q_p,s is the quantity of security activity p allocated to scenario s and $f_{p,s}^{\left(c\right)}$ is its characterization factor for impact category c. The set ${\mathcal{P}}_{\mathrm{s}\mathrm{e}\mathrm{c}}$ contains the security-related activities included within the system boundary, whereas $\mathcal{C}$ denotes the set of considered impact categories. Shared servers, backup capacity, monitoring, and other joint activities are assigned according to one disclosed allocation rule so that the same physical burden is not counted in both the operational and security modules.

Different impact categories are never summed. The category-specific components jointly define the security lifecycle burden vector for scenario s:

$$SLC{B}_s={\left(SLC{B}_s^{\left(c\right)}\right)}_{c\in \mathcal{C}}$$

The Security Lifecycle Intensity is calculated separately for each impact category and eligible functional unit:

$${\mathrm{S}\mathrm{L}\mathrm{C}\mathrm{I}}_s^{\left(c\right)} = {\displaystyle \frac{{\mathrm{S}\mathrm{L}\mathrm{C}\mathrm{B}}_s^{\left(c\right)}}{N_{eligible,s}}}, c \in \mathcal{C},N_{eligible,s}>0$$

(10)

Here, $N_{eligible,s}$ is the number of functional units in scenario s that satisfy the applicable eligibility criteria. If $N_{eligible,s}=0, {\mathrm{S}\mathrm{L}\mathrm{C}\mathrm{I}}_s^{\left(c\right)}$ is undefined and must not be reported as a qualified intensity.

The earlier residual-risk-adjusted utility scalar is removed because multiplication by (1 − R_res) would allow uncertain risk calibration to compensate continuously for environmental performance. Claim eligibility is instead represented by the conjunction of mandatory gates:

$$G_s = {\wedge }_{q \in \mathcal{Q}}{G}_{q,s}, \mathcal{Q}=\{\mathrm{s}\mathrm{e}\mathrm{c},\mathrm{f}\mathrm{i}\mathrm{n}\mathrm{a}\mathrm{l},\mathrm{a}\mathrm{v}\mathrm{a}\mathrm{i}\mathrm{l},\mathrm{d}\mathrm{e}\mathrm{c},\mathrm{p}\mathrm{r}\mathrm{i}\mathrm{v},\mathrm{r}\mathrm{i}\mathrm{s}\mathrm{k}\}$$

(11)

The resulting claim rule is

$${\mathrm{C}\mathrm{l}\mathrm{a}\mathrm{i}\mathrm{m}}_s=\left\{\begin{array}{cc}\mathrm{F}\mathrm{U}\mathrm{L}\mathrm{L} \mathrm{C}\mathrm{O}\mathrm{M}\mathrm{P}\mathrm{A}\mathrm{R}\mathrm{I}\mathrm{S}\mathrm{O}\mathrm{N}& if all G_{q,s}=\mathrm{P}\mathrm{A}\mathrm{S}\mathrm{S}\\ \mathrm{E}\mathrm{X}\mathrm{C}\mathrm{L}\mathrm{U}\mathrm{D}\mathrm{E}\mathrm{D}& if any G_{q,s}=\mathrm{F}\mathrm{A}\mathrm{I}\mathrm{L}\\ \mathrm{M}\mathrm{O}\mathrm{D}\mathrm{U}\mathrm{L}\mathrm{E}-\mathrm{S}\mathrm{P}\mathrm{E}\mathrm{C}\mathrm{I}\mathrm{F}\mathrm{I}\mathrm{C}& \mathrm{o}\mathrm{t}\mathrm{h}\mathrm{e}\mathrm{r}\mathrm{w}\mathrm{i}\mathrm{s}\mathrm{e} \left(\mathrm{U}\mathrm{N}\mathrm{R}\mathrm{E}\mathrm{S}\mathrm{O}\mathrm{L}\mathrm{V}\mathrm{E}\mathrm{D}\right)\end{array}\right.$$

(12)

Equations (11) and (12) use the same three-valued conjunction: PASS only if all mandatory gates pass, FAIL if any mandatory gate fails, and UNRESOLVED otherwise. This preserves the audit status of missing evidence and prohibits energy, carbon, throughput, or cost from compensating for a failed mandatory assurance condition.

5.6. Threat–Control–Burden Matrix

Security controls should be assessed both in terms of the incidents they prevent or mitigate and the lifecycle burdens they introduce. For example, denial-of-service protection requires redundant capacity and traffic filtering but may prevent prolonged availability loss and emergency migration. Hardware security modules introduce embodied hardware and operational electricity demand but reduce the probability of key extraction. Multi-client deployment increases testing and maintenance requirements but limits correlated software failure. Continuous monitoring requires telemetry, storage, and analysis while reducing the expected time to detection [24,25,26].

Table 7. Representative blockchain threats, controls, resource burdens, and avoided incident pathways.

Threat or Failure	Primary Exposed Asset	Representative Controls	Additional Lifecycle Burden	Principal Residual Risk	Avoided or Reduced Incident Pathway
Consensus manipulation	Ledger integrity and transaction finality	Validator diversity; economic penalties; quorum controls; attack monitoring	Additional validators; monitoring; communication; governance procedures	Validator collusion; concentration of stake or computational power	Chain reorganization; double spending; loss of finality
Validator or signing-key compromise	Validator identity and transaction authorization	Hardware security modules; offline backup; multisignature authorization; key rotation	Dedicated security hardware; backup systems; rotation procedures; recovery testing	Insider attack; backup-key exposure; administrative compromise	Unauthorized blocks; fraudulent transactions; validator slashing
Distributed denial-of-service attack	Service and node availability	Traffic filtering; redundant gateways; geographic distribution; reserved capacity	Additional servers; network appliances; bandwidth; continuous monitoring	Attack volume exceeding reserved or filtering capacity	Service outage; emergency migration; loss of transaction availability
Eclipse or routing attack	Node connectivity and network view	Peer diversity; route monitoring; authenticated peers; redundant network providers	Additional connections; routing monitoring; communication overhead	Correlated routing or provider failure	Node isolation; delayed blocks; manipulated network view
Smart-contract vulnerability	Application logic, state, and user assets	Code audit; formal verification; testing; access control; controlled upgrades	Development and testing computation; test networks; audit effort; parallel deployment	Unknown logic defect; governance misuse; incomplete migration	Asset loss; contract suspension; emergency compensating transactions
Oracle manipulation	Integrity of external data	Multiple data sources; signed feeds; anomaly detection; fallback mechanisms	Additional data feeds; computation; communication; monitoring	Correlated or economically manipulated data sources	Incorrect contract execution; settlement error; application failure
Bridge compromise	Cross-chain assets and messages	Threshold signatures; proof verification; rate limits; monitoring; emergency pause	Additional validators; verification computation; protected signing hardware	Signer collusion; implementation defect; governance compromise	Cross-chain asset loss; bridge shutdown; emergency migration
Cloud-account takeover	Cloud-hosted nodes and managed services	Least privilege; multifactor authentication; isolated accounts; audit logging; credential rotation	Identity services; security-log storage; administration; access reviews	Cloud-provider compromise; privileged insider; credential recovery failure	Validator loss; service interruption; unauthorized data access
Software-supply-chain compromise	Client software and deployment integrity	Signed releases; dependency verification; reproducible builds; code review	Build infrastructure; artefact storage; testing; auditing	Compromised maintainer; build-system compromise; malicious dependency	Malicious software update; widespread validator compromise
Common client failure	Consensus availability and correctness	Multiple client implementations; staged rollout; compatibility testing	Parallel software maintenance; additional testing; monitoring	Shared library defect; common specification error	Correlated validator failure; consensus disruption; network halt
Backup or recovery failure	Ledger state, cryptographic keys, and service continuity	Geographic backup; integrity verification; restoration exercises; recovery procedures	Replicated storage; network traffic; backup infrastructure; recovery testing	Correlated data loss; obsolete or inaccessible backup	Prolonged outage; permanent loss of state or cryptographic keys
Cryptographic obsolescence	Digital signatures, identities, and historical trust	Cryptographic agility; dual-signature transition; algorithm monitoring; planned key migration	Larger signatures; additional verification; state growth; replacement of security hardware	Incomplete migration; legacy incompatibility; delayed user transition	Signature forgery; identity compromise; loss of historical assurance

connects representative threats with exposed assets, corresponding controls, resource burdens, residual risks, and avoided incident pathways. It provides a structured inventory for integrating cybersecurity into the blockchain lifecycle assessment.

The same control may shift burdens between lifecycle stages or infrastructure components. Geographically distributed backup improves recovery capability but increases storage, replication traffic, and embodied infrastructure. Frequent key rotation reduces the period of exposure following key compromise but increases operational and archival complexity. Post-quantum signatures may improve long-term cryptographic assurance while increasing transaction size, verification work, network traffic, and state growth. These burden shifts must remain visible rather than being absorbed into a single security score.

5.7. Software Supply Chain and Smart-Contract Lifecycle

Blockchain security depends on client implementations, consensus libraries, compilers, container images, external dependencies, smart contracts, oracle adapters, bridge software, configuration files, and deployment scripts. Development, testing, audit, formal verification, bug-bounty programmes, patching, and contract migration collectively form a software lifecycle with computational, storage, organizational, and governance burdens [26,35].

The software lifecycle should be assessed from source-code creation and dependency selection through build, testing, deployment, monitoring, updating, and retirement. Relevant inventory items include continuous-integration workloads, test-network operation, artefact and log storage, audit infrastructure, code-signing services, parallel client maintenance, and temporary infrastructure created during migration.

Immutable deployment may preserve defective or vulnerable code. Recovery may consequently depend on proxy contracts, administrative controls, governance votes, emergency pauses, protocol forks, compensating transactions, or migration to replacement contracts. Each pathway may generate additional computation, communication, duplicated state, audit requirements, and user-coordination costs. These processes must be included when they materially affect delivery of the declared trust service.

The cybersecurity lifecycle framework makes the resource demand of assurance visible without treating security as an avoidable environmental overhead. By connecting threats, controls, burdens, residual risks, and avoided incident pathways, the framework supports comparison between blockchain architectures that provide equivalent levels of useful and secure service. It also establishes the variables required for the integrated lifecycle inventory and scenario calculations developed in the following sections.

6. Integrated Lifecycle Inventory and Allocation Model

The functional unit and cybersecurity framework defined in Section 4 and Section 5 require an inventory that connects physical infrastructure, blockchain operation, cloud services, security controls, software maintenance, and end-of-life processes. The inventory is organized by lifecycle stage and service component so that operational burdens are not confused with embodied impacts or incident-related recovery activities [28,34].

For each component k, the inventory records installed capacity, utilization, operating time, electricity demand, embodied impact, expected lifetime, replacement rate, data traffic, storage growth, and allocation factor. Inputs should be classified as measured, operator-reported, specification-derived, modelled, or illustrative. This classification must remain visible in the reported results because uncertainty differs substantially among direct power measurements, cloud-service estimates, hardware lifecycle datasets, and scenario assumptions.

The total lifecycle impact of blockchain scenario s is calculated as

$$I_{LC,s}^{\left(c\right)}={\sum }_{x \in \mathcal{X}}{I}_{x,s}^{\left(c\right)}, c \in \mathcal{C}$$

(13)

Equation (13) is the scenario-level, category-specific form of Equation (1) and uses the identical module set $𝒳$. The modules cover embodied hardware and infrastructure, operation and consensus, managed cloud services, communication, cybersecurity controls, maintenance and replacement, protocol/state/cryptographic migration, and end-of-life treatment. Every term is evaluated separately for each homogeneous category c.

6.1. Operational Energy

Operational electricity includes the energy used by consensus nodes, execution services, storage, communication equipment, cooling, power conversion, cloud-hosted services, cybersecurity monitoring, backup, and recovery infrastructure. Direct measurement is preferred whenever access to physical or virtual infrastructure is available.

For a component k, operational energy is estimated as

$$E_{op,k}=\left[P_{idle,k}+\left(P_{active,k}-P_{idle,k}\right)u_k\right]t_k$$

(14)

where $P_{idle,k}$ is idle power, $P_{active,k}$ is active power, u_k is average utilization, and $t_k$ is operating time. Facility overhead is incorporated using the power usage effectiveness factor [39].

$$E_{facility,k}=E_{IT,k}{\mathrm{P}\mathrm{U}\mathrm{E}}_k$$

(15)

When power measurements are unavailable, the estimation procedure should disclose the rated power, utilization assumptions, virtualization allocation, PUE, geographic location, and temporal resolution of the electricity data.

6.2. Embodied Hardware and Replacement

Embodied impacts include semiconductor manufacturing, server assembly, storage and network equipment, power systems, cooling infrastructure, transportation, and deployment. These impacts are allocated over the effective service life of the equipment [17,18,19,28,34]:

$$I_{emb,allocated,k}^{\left(c\right)} = I_{emb,total,k}^{\left(c\right)}{\displaystyle \frac{t_{share,k}}{t_{life,k}}}$$

(16)

where $t_{share,k}$ is the period during which component k supports the assessed blockchain service and $t_{life,k}$ is its effective lifetime. The allocation is performed independently for every impact category c.

Economic replacement should not automatically be treated as physical end of life. Specialized mining hardware may become economically obsolete while remaining technically operational, whereas general-purpose servers may be reassigned to other workloads. The assessment should therefore distinguish continued use, internal reassignment, resale, refurbishment, recycling, storage, and disposal.

6.3. Cloud-Service Allocation

Multi-tenant cloud infrastructure creates an allocation problem because the physical server, storage system, network, and cooling facility support multiple customers simultaneously. The preferred allocation basis is measured processor, accelerator, memory, storage, and network use. When these measurements are unavailable, reserved capacity, virtual-machine size, active time, or service-specific billing records may be used as proxies [28,31,34,39].

The allocated cloud impact is expressed as

$$I_{cloud,allocated,k}^{\left(c\right)}={\alpha }_{k,BC}{I}_{cloud,total,k}^{\left(c\right)}, 0 \le {\alpha }_{k,BC} \le 1$$

(17)

where ${\alpha }_{k,BC}$ is the fraction of cloud component k allocated to the blockchain service and must lie in [0, 1]. The factor is reported separately for computation, storage, communication, backup, and standby capacity because these resources may have different utilization profiles.

Reserved but idle capacity should be included when it is maintained specifically to satisfy the declared availability, security, or recovery requirement. In contrast, unallocated provider-wide spare capacity should not be attributed entirely to one blockchain service.

6.4. Shared Layers, Bridges, and Oracles

Layer-2 systems, bridges, and oracle networks introduce shared-service allocation. A layer-2 system consumes resources through off-chain execution, data availability, proof generation, sequencing, monitoring, and base-layer settlement. The same user operation must not be counted simultaneously as a full layer-2 service and as an independent base-layer transaction [27].

Bridge burdens may be allocated according to verified cross-chain messages, transferred service units, protected value, or another application-relevant driver. Value-based allocation should be used cautiously because market-price variation may change the result without changing the physical infrastructure.

Oracle burdens include data acquisition, authentication, aggregation, transmission, storage, and dispute resolution. When an oracle service supports multiple applications, its impacts should be allocated using request volume, computational workload, reserved capacity, or another disclosed service metric.

6.5. Forks, Failed Operations, and Recovery

Failed transactions, reverted operations, orphaned blocks, unsuccessful proof generation, duplicated relays, and abandoned forks consume resources but do not increase the useful functional-unit denominator. Their burdens remain in the lifecycle numerator.

The burden associated with a protocol fork is allocated according to the purpose and outcome of the fork. Routine planned upgrades are treated as maintenance or migration. Emergency forks following an incident are classified as recovery. Persistent competing chains are assessed as separate systems after the divergence point, while shared pre-fork infrastructure and development burdens are allocated using a declared rule.

Incident recovery may require forensic analysis, duplicated infrastructure, emergency cloud capacity, state reconstruction, contract migration, additional transactions, user compensation, and prolonged operation of legacy systems. These processes must be included when material.

6.6. Electricity, Carbon, Water, Materials, and E-Waste

Operational greenhouse-gas emissions are calculated using temporally and geographically appropriate electricity factors [6,7,8,9,10,11,28,34]:

$${\mathrm{G}\mathrm{H}\mathrm{G}}_{op} = {\displaystyle {\sum }_{r = 1}^R}{\displaystyle {\sum }_{t = 1}^T}{E}_{r,t}{CF}_{r,t}$$

(18)

where $E_{r,t}$ is electricity consumed in region r during period t and ${CF}_{r,t}$ is the corresponding temporally and geographically matched carbon-intensity factor.

Market-based renewable-energy claims should be reported separately from location-based results. Where possible, average and marginal electricity factors should both be presented because attributional and consequential assessments answer different questions.

Water indicators should distinguish direct facility water use from water consumed in electricity generation and hardware manufacturing. Material indicators should report critical materials, total hardware mass, recycled content, reuse, and final recovery. E-waste should be based on the mass and actual treatment pathway of retired equipment rather than on an assumed direct conversion of all replacement hardware into waste.

7. Cloud Deployment Scenarios and System-Level Indicators

Blockchain services can use the same consensus protocol while relying on substantially different physical and organizational infrastructures. Four deployment scenarios are therefore defined to examine the interaction among operational efficiency, cloud concentration, validator diversity, recovery capability, and lifecycle burden.

Figure 7 distinguishes the established foundations used by the framework from the novel integration proposed here. ISO lifecycle inventory and impact categories, cybersecurity risk and control assessment, blockchain consensus metrics, and cloud concentration/resilience analysis remain established methods. The contribution is their integration through provenance-coded inventory modules, non-compensatory functional-equivalence gates, module-specific claim boundaries, and one uncertainty/break-even workflow.

7.1. Fully Decentralized Scenario

The fully decentralized scenario distributes validators or miners across multiple independent operators, geographic regions, network providers, and hardware environments. It generally provides strong resistance to common-mode infrastructure failure but may require greater replication, heterogeneous hardware, additional communication, and less efficient capacity utilization.

The scenario should not be labelled decentralized solely because it has a large node count. Independence of ownership, cloud provider, region, network route, client implementation, and administrative control must also be evaluated.

7.2. Cloud-Concentrated Scenario

The cloud-concentrated scenario places a substantial share of validators, RPC services, storage, monitoring, and application infrastructure within one dominant cloud provider or a small number of correlated providers. Resource pooling and high server utilization may reduce operational energy per useful transaction. However, common identity systems, control planes, regions, network services, and administrative dependencies can create correlated cyber and availability risks [31].

Low energy intensity in this scenario must therefore be interpreted together with cloud concentration, independent failure domains, recovery readiness, and the ability to migrate the service to another provider.

7.3. Hybrid Cloud–Edge Scenario

The hybrid scenario combines cloud-hosted coordination and scalable application services with validators, key-management systems, monitoring, or recovery capacity distributed across independent edge or institutional sites. The architecture may reduce cloud concentration while retaining elastic computation and managed storage.

Its lifecycle performance depends on the balance between efficient shared cloud resources and duplicated edge infrastructure. Hybrid deployment may also increase management complexity, data synchronization, network traffic, and the number of security boundaries.

7.4. Consortium Scenario

The consortium scenario uses a restricted validator set operated by identified organizations. Permissioned Byzantine fault-tolerant consensus can provide high throughput, rapid deterministic finality, and low operational energy. Nevertheless, governance, membership control, identity infrastructure, and organizational independence become central parts of the delivered trust service.

The consortium scenario must disclose validator ownership, institutional relationships, cloud-provider overlap, geographic distribution, fault assumptions, and procedures for replacing a compromised or unavailable member.

Applicability depends on architecture-specific inventory and assurance evidence rather than numerical profile scores. Figure 8 routes the framework across public PoW, public PoS, committee/DPoS, permissioned BFT, and layer-2/modular systems. The common sequence is unchanged, while the dominant inventory processes, trust assumptions, and mandatory gates differ.

For public PoW, the inventory emphasizes mining electricity, specialized-hardware turnover, pool concentration, probabilistic finality, and geographic electricity mix. Public PoS shifts emphasis to validator/node electricity, stake and operator concentration, client diversity, slashing, checkpoint finality, and cloud dependence. Committee/DPoS requires explicit committee-selection and governance-capture evidence. Permissioned BFT requires identity, membership, quorum, organizational-independence, and recovery evidence. Layer-2 and modular systems additionally require allocation among sequencers, provers, data availability, bridges, and base-layer commitments, with explicit controls against double counting.

7.5. Cloud Concentration Risk

Cloud Concentration Risk (CCR) represents the degree to which service capacity depends on a limited number of cloud providers or correlated infrastructure domains. A basic concentration indicator can be calculated using a Herfindahl-type expression [31]:

$${\mathrm{C}\mathrm{C}\mathrm{R}}_s = {\displaystyle {\sum }_{p = 1}^P}{s}_{p,s}^2, {\displaystyle {\sum }_{p = 1}^P}{s}_{p,s} = 1, s_{p,s} \ge 0$$

(19)

where $s_{p,s}$ is the non-negative share of service capacity hosted by provider p in scenario s and the shares sum to one. CCR approaches one when the service is concentrated within one provider and decreases as capacity is distributed among independent providers.

Provider concentration alone is insufficient because several nominal providers may share regions, network routes, software platforms, identity services, or upstream facilities. The result should therefore be accompanied by a qualitative or quantitative common-dependency assessment.

7.6. Independent Failure Domains

The independent failure domain indicator (IFD) estimates the number of infrastructure domains whose failures are not expected to be strongly correlated. Domains may be defined by cloud provider, region, operator, autonomous network, client implementation, power supply, key-management system, or administrative authority.

A weighted effective-domain indicator may be expressed as

$${\mathrm{I}\mathrm{F}\mathrm{D}}_s={\left({\displaystyle {\sum }_{d=1}^D}{s}_{d,s}^2\right)}^{-1}, {\displaystyle {\sum }_{d=1}^D}{s}_{d,s}=1, s_{d,s} \ge 0$$

(20)

where $s_{d,s}$ is the non-negative share of service capacity associated with failure domain d in scenario s and the shares sum to one. IFD is the inverse concentration and therefore estimates the effective number of independent domains; higher values indicate greater distribution, while a value near one indicates concentration.

7.7. Recovery Readiness

Recovery readiness (RR) evaluates whether the service can restore its required functionality after node compromise, provider failure, key loss, software defect, or protocol incident. The indicator may include backup integrity, restoration testing, recovery time, key recovery, alternative hosting capacity, state portability, operator preparedness, and governance response.

A scenario-analysis score can be defined as

$${\mathrm{R}\mathrm{R}}_s={\displaystyle {\sum }_{k=1}^K}{w}_k{\rho }_{k,s}, {\displaystyle {\sum }_{k=1}^K}{w}_k=1, w_k \ge 0$$

(21)

where ${\rho }_{k,s}$ is normalized recovery component k and $w_k$ is its disclosed non-negative weight. The weights sum to one. Mandatory recovery conditions remain independent thresholds and cannot be compensated by high scores in less critical categories.

8. Empirical Ethereum Merge Assessment

The empirical assessment applies the framework to the Ethereum Mainnet before and after The Merge. This within-platform transition retains ledger identity and application state while changing the consensus mechanism, thereby providing a more defensible comparison than a numerical ranking of functionally different networks.

FU-O is the primary operational unit. FU-Q is not evaluated because mandatory gates remain UNRESOLVED. FU-B is reported as a secondary included-transaction allocation. Security, availability, finality, decentralization, privacy, and residual-risk conditions are assessed as eligibility gates and profiles; the analysis does not assert complete security equivalence between PoW and PoS.

8.1. Baseline Operational-Energy Results

Using the independent Cambridge baseline, daily operational energy decreased from 58,617.39 MWh before The Merge to 5.376 MWh after it. This corresponds to a factor of 10,903.5 and a reduction of 99.99083%. The CCRI measured-hardware replication branch produced a factor of 8804.9 and a reduction of 99.98864% [22,23].

A deliberately adverse bounded pairing combined the lower pre-Merge estimate with the upper post-Merge hardware estimate. It still yielded a factor of 3424.7 and a reduction of 99.97080%. The direction of the operational-energy change is therefore robust across the independent and measured-hardware branches, although neither branch constitutes a complete cradle-to-grave inventory.

Figure 9 presents the deterministic branches regenerated by analysis.py on a logarithmic energy axis. The workflow derives transaction statistics from the raw Etherscan exports before calculating the CCAF, CCRI, and adverse branches. The mean included layer-1 transactions increased from 1,070,662.64 to 1,136,444.43 per day (+6.14%), while mean block time decreased from 13.599 to 12.080 s (−11.17%). These service changes are descriptive and are not attributed solely to the consensus transition.

The matched-window FU-B diagnostic decreased from 54,748.70 to 4.7305 MWh per one million included transactions under the Cambridge baseline. Because the denominator does not yet isolate successful and application-useful receipts, this result is presented as an attributional diagnostic rather than as the primary finding.

The corresponding operational protocol-upgrade dividend is 58,612.01 MWh of avoided electricity per day under the Cambridge snapshots. This difference is attributional and does not include transition hardware, cloud services, embodied impacts, or avoided incidents.

Accordingly, the defensible result is a large and robust operational-energy change for the documented Ethereum transition, not a universal ranking of PoW, PoS, committee PoS, and permissioned BFT systems.

8.2. Inclusion of Embodied and Cloud Burdens

Historical cloud-service and complete embodied-hardware inventories were not available at a quality sufficient for point estimation. Their influence was therefore represented through scenario curves and algebraic parity thresholds rather than fabricated central values.

Under the Cambridge baseline, combined additional post-Merge cloud, supporting-service, and annualized embodied-hardware energy would have to reach approximately 21,408 GWh/year before the direction of the FU-O energy advantage disappears. This threshold quantifies the robustness margin; it is not evidence that the actual additional burden is negligible.

The threshold supports the bounded conclusion that non-consensus burdens may become relatively more important after The Merge without reversing the observed FU-O direction. Empirical application of the cloud and embodied modules requires separate measured inventories.

8.3. Security-Control Burden and Avoided Incidents

The security lifecycle burden increases with monitoring, redundant capacity, protected key storage, multi-client operation, backup, patching, recovery testing, and cryptographic migration. However, excluding these controls would create a functionally weaker comparison rather than an environmentally superior system.

The relevant analytical question is therefore not whether security controls consume resources, but whether alternative controls achieve the same assurance level with lower lifecycle burden and lower expected incident impact. For example, an HSM may add embodied and operational impacts while substantially reducing the probability of signing-key extraction. Multi-client operation may increase maintenance effort while reducing the probability of a network-wide software failure.

8.4. Residual-Risk Adjustment

Residual-risk adjustment is applied only after the case-specific gate status has been declared. In the present assessment, the missing matched evidence for provider concentration, client diversity, incident probability, control effectiveness, and recovery does not receive a favourable numerical score; these items remain UNRESOLVED in Table 6. The operational-energy result is therefore reported as a bounded protocol-transition module rather than as a residual-risk-adjusted ranking of PoW and PoS.

A configuration with a FAIL status for Secmin, Amin, Dmin, Pmin, or Rmax is excluded from direct comparison. A configuration with an UNRESOLVED mandatory gate may be used only for a module-specific comparison whose conclusion does not depend on the unresolved dimension. Only configurations with PASS status across all mandatory gates may be ranked as fully functionally equivalent using integrated lifecycle intensity indicators.

9. Sensitivity, Uncertainty, and Robustness Analysis

Uncertainty was propagated through one reproducible model using the triangular energy and carbon-intensity inputs listed in

Table 8. Stochastic inputs, distributions, ranges, and evidential roles used in the uncertainty model.

Input	Distribution	Lower	Mode	Upper and Evidential Role
Pre-Merge annual electricity	Triangular	21.41 TWh/y	21.41 TWh/y	22.90032 TWh/y; two independent network-estimation branches [22,23]
Post-Merge annual electricity	Triangular	0.8330 GWh/y	1.963584 GWh/y	6.2516 GWh/y; reported estimate and measured-hardware envelope [22,23]
Pre-Merge carbon intensity	Triangular	320 gCO2e/kWh	481.0396 gCO2e/kWh	560 gCO2e/kWh; bounded operational-GHG scenario
Post-Merge carbon intensity	Triangular	267.536 gCO2e/kWh	334.42 gCO2e/kWh	401.304 gCO2e/kWh; ±20% location-mix scenario
Pre-/post-Merge included transactions	Positive truncated normal (two inputs)	Means: pre 1,070,662.643; post 1,136,444.429 tx/day	Population SD: pre 28,605.580; post 61,979.092	Derived from 28 raw daily observations per window; FU-B diagnostic [40]
Random seed and dependence	Fixed/independent	20260723	—	No correlation matrix was imposed because the available evidence did not support one

and positive truncated-normal transaction inputs derived from the raw matched-window means and population standard deviations. The workflow used 100,000 Monte Carlo realizations, a fixed random seed (20260723), a separate 50,000-base-draw Jansen design, and algebraic break-even solutions. All deterministic branches, break-even values, and Figure 9 and Figure 10 were generated by the same executable script. FU-O is independent of transaction counts; FU-B propagates observed day-to-day transaction variability and remains an attributional diagnostic.

Table 8 distinguishes evidence-derived ranges from explicit scenario bounds. The distributions are screening representations of epistemic uncertainty, not fitted forecasts for a named operator or data centre.

Figure 10 is generated directly by analysis.py from new Jansen/Saltelli A, B, and hybrid sample matrices. For the log10 FU-O energy factor, the displayed total-order index is 1.0000 for post-Merge annual energy and 0.0016 for pre-Merge annual energy. For post-Merge energy per one million included transactions, the indices are 0.9860 for post-Merge annual energy and 0.0179 for post-Merge transactions/day. Avoided operational GHG is dominated by pre-Merge carbon intensity (0.9738) and pre-Merge annual energy (0.0210).

9.1. Monte Carlo Uncertainty Propagation

Pre-Merge and post-Merge annual electricity, the two operational carbon-intensity scenarios, and day-to-day transaction variability derived from the raw matched-window data were sampled according to Table 8. FU-O outputs were the energy factor and percentage reduction. FU-B combined the same energy draws with truncated positive-normal transaction draws parameterized by the raw 28-day means and population standard deviations. Operational-GHG outputs were the percentage reduction and avoided annual emissions. Cloud allocation, embodied hardware, water, materials, security-control energy, concentration, incident probability, recovery, and circularity were not assigned unverified stochastic point estimates.

The Monte Carlo model was executed with NumPy’s default random generator and seed 20260723. All aggregate inputs, equations, source roles, and generated summaries are contained in the accompanying reproducibility package. This design makes the reported uncertainty intervals independently regenerable while preserving the distinction between measured/reported values and scenario-only bounds.

The median FU-O reduction was 99.98698%, with a central 95% interval of 99.97492–99.99441%. The corresponding energy factor had a median of 7680.5 and a central 95% interval of 3987.7–17,877.9. The minimum simulated factor was 3452.9; every realization therefore exceeded the prespecified factor-of-100 robustness criterion by more than one order of magnitude.

The FU-B attributional diagnostic had a median reduction of 99.98771% and a central 95% interval of 99.97607–99.99478%. Operational-GHG reduction had a median of 99.99038% and a central 95% interval of 99.98011–99.99603%. The mean avoided operational GHG was 27,214 tCO₂e/day, corresponding to approximately 9.94 million tCO₂e/year.

These greenhouse-gas results cover operational electricity only. They do not constitute a cradle-to-grave carbon footprint, and the avoided-emissions result remains sensitive to the assumed pre-Merge electricity mix. The uncertainty model does not convert unresolved assurance conditions into environmental credits or penalties.

• Receipt success and reversion: Not inferred from aggregate daily charts; FU-B remains a labelled diagnostic.
• Electricity carbon intensity: Sampled explicitly for operational-GHG uncertainty.
• PUE: Retained as a scenario-only cloud parameter and not back-cast as a measured 2022 value.
• Hardware lifetime and replacement: Represented through lifecycle scenarios rather than the operational baseline.
• Embodied hardware: Expressed through parity thresholds until a verified inventory is available.
• Cloud allocation: Treated as an unresolved historical service-level input and bounded analytically.
• Storage and state growth: Retained in the framework but outside the measured operational case.
• Security-control energy: Scenario-only; no unverified point estimate was introduced.
• Cloud concentration: Evaluated as an assurance profile rather than converted into MWh.
• Validator and provider diversity: Applied as a non-compensatory eligibility condition.
• Control effectiveness: Retained as an ordinal or scenario parameter because calibrated probabilities were unavailable.
• Incident probability and consequence: Not monetized or converted into energy equivalents.
• Recovery time and success: Reported as assurance evidence and not used to offset environmental burdens.
• Reuse and recycling: Retained for future complete lifecycle inventories and excluded from the operational claim.

The uncertainty intervals were interpreted jointly with the non-compensatory assurance gates; a large environmental difference was not used to offset an unacceptable finality, concentration, key-management, or recovery condition.

9.2. Global Sensitivity Analysis

The FU-O energy factor and post-Merge energy per one million included transactions were log10-transformed to accommodate their multi-order-of-magnitude ranges. The transaction means and population standard deviations were derived from the 56 raw daily observations; truncated positive-normal draws propagate observed day-to-day activity variability in FU-B, while transaction inputs do not enter FU-O.

Post-Merge annual energy dominated the log10 FU-O energy factor (displayed ST = 1.0000; raw finite-sample estimate 1.0032), while pre-Merge annual energy contributed ST = 0.0016. For log10 post-Merge energy per one million included transactions, post-Merge annual energy contributed ST = 0.9860 and post-Merge transactions/day ST = 0.0179. Avoided operational GHG was dominated by pre-Merge carbon intensity (ST = 0.9738), followed by pre-Merge annual energy (ST = 0.0210).

The result identifies two evidence priorities: narrower post-Merge node-power and node-count bounds for the energy factor, and geographically resolved pre-Merge electricity-mix evidence for avoided operational GHG. It also shows that uncertainty priorities depend on the claim being made; improving the carbon estimate does not materially narrow the energy factor, and improving the energy estimate does not replace assurance-gate evidence.

9.3. Break-Even Analysis

Break-even values were solved algebraically rather than supplied as unsupported empirical inputs. The analysis covered combined additional post-Merge burdens, validator-equivalent node count, transaction throughput, successful-transaction share, and electricity carbon intensity.

FU-O energy parity requires approximately 21,408 GWh/year of additional post-Merge cloud and annualized embodied burden. Under central energy estimates, FU-B parity requires about 98 included transactions/day; at the observed post-Merge volume and 100% pre-Merge success, the analytical parity share is 0.008640%.

These values are decision boundaries, not estimates of actual missing burdens or successful-transaction shares. They show the margin required to reverse the operational result while preserving the obligation to measure cloud, embodied, and receipt-level quantities [43].

9.4. Data-Quality Assessment

Data quality should be evaluated across temporal, geographic, technological, and methodological dimensions. A suitable data-quality record includes:

• Source type;
• Measurement or modelling method;
• Reference year;
• Geographic applicability;
• Technological representativeness;
• Completeness;
• Uncertainty;
• Allocation procedure;
• Verification status.

Measured operational data should not automatically be treated as complete if cloud, network, embodied, or security-related processes remain outside the measurement boundary.

10. Discussion

10.1. From Transaction Efficiency to Trust-Service Efficiency

The case confirms that the choice of denominator changes interpretation but not the direction of the operational-energy result. FU-O avoids implying transaction-level marginal causation, whereas FU-B supports comparison with the transaction-normalized literature only as an attributional diagnostic. FU-Q is not reported because the mandatory assurance evidence is incomplete.

The assurance gates prevent the large numerical difference from becoming a universal equivalence claim. Protocol continuity and the declared public-settlement boundary passed, and finality was explicitly profiled; availability, concentration, client diversity, cloud-provider dependence, and calibrated residual risk remained unresolved. The case therefore demonstrates the framework’s ability to return a bounded result without converting missing evidence into a favourable score.

10.2. Security Is Neither Free nor Pure Overhead

Cybersecurity creates measurable lifecycle burdens through cryptography, monitoring, redundancy, logging, patching, key protection, backup, incident response, and migration. Treating these processes as zero-impact externalities underestimates the resources required to operate a trustworthy blockchain service [24,29,33].

At the same time, treating all security-related resource use as undesirable overhead ignores avoided incidents and preserved service utility. The appropriate comparison concerns alternative ways of satisfying the same security requirement, not the removal of controls required for functional equivalence.

10.3. Cloud Efficiency and Concentration Risk

After The Merge, cloud, storage, monitoring, key-management, and embodied-hardware burdens become relatively more important because consensus electricity is much smaller. The 21,408 GWh/year FU-O parity threshold shows that the direction of the operational result has a wide margin, but it does not measure the actual cloud or embodied inventory.

Future service-level inventories should report both allocation-based resource efficiency and provider, region, identity-plane, and recovery-domain concentration. A low energy result without these dependency profiles remains incomplete.

10.4. Protocol Evolution and Circular Trust Retention

Blockchain lifecycle assessment should recognize that upgrades and successor systems may retain hardware, software components, ledger state, cryptographic infrastructure, operational experience, governance procedures, and institutional trust. Retention can avoid repeated manufacturing, testing, enrollment, and validation burdens [32,35,36,37,38].

Circular trust retention is beneficial only when reused assets remain secure, maintainable, compatible, and functionally appropriate. Retaining vulnerable software, obsolete cryptography, compromised keys, or unmanageable historical state may increase rather than reduce lifecycle burden.

A circular trust retention indicator may be expressed as

$${\mathrm{C}\mathrm{T}\mathrm{R}}_s^{\left(c\right)}={\displaystyle \frac{V_{retained,s}^{\left(c\right)}}{V_{required,s}^{\left(c\right)}}}, c \in {\mathcal{C}}_V$$

(22)

where $V_{retained,s}^{\left(c\right)}$ and $V_{required,s}^{\left(c\right)}$ are verified retained and required capabilities within the same capability category c. CTR is reported category-by-category because technical, cryptographic, operational, and institutional capabilities are not directly commensurate.

10.5. State Growth and Ledger Lifetime

Persistent ledger-state growth creates long-term storage, synchronization, archival, and validator-accessibility burdens. A system with low short-term transaction energy may accumulate state that increases future node requirements and reduces participation diversity [27,28,34].

State-Growth Intensity (SGI) is defined as

$${\mathrm{S}\mathrm{G}\mathrm{I}}_s={\displaystyle \frac{{\Delta S}_s}{N_{useful,final,s}}}$$

(23)

where ΔS_s is the increase in the replicated and retained state and $N_{useful,final,s}$ is the useful finalized service count during the same assessment period. Both the storage boundary and unit are declared.

Ledger Lifetime Yield (LLY) relates cumulative useful service to cumulative lifecycle burden:

$${\mathrm{L}\mathrm{L}\mathrm{Y}}_s^{\left(c\right)}\left(T\right) = {\displaystyle \frac{{\displaystyle {\sum }_{t = 1}^T}{N}_{eligible,s,t}}{{\displaystyle {\sum }_{t = 1}^T}{I}_{LC,s,t}^{\left(c\right)}}}, c \in \mathcal{C}$$

(24)

Here, T is the declared horizon, $N_{eligible,s,t}$ is the eligible service delivered in period t, and $I_{LC,s,t}^{\left(c\right)}$ is the lifecycle burden in the same homogeneous category c. LLY is therefore reported separately by category and never divides service by a heterogeneous impact vector.

10.6. Protocol-Upgrade Dividend

The Merge provides an empirical example of a protocol-upgrade dividend. Under the Cambridge snapshots, 58,612.01 MWh/day of operational electricity was avoided, while the mean included transactions/day increased by 6.14% and the mean block time decreased by 11.17%. These accompanying service changes are descriptive rather than a causal attribution to consensus alone.

The general net protocol-upgrade dividend (PUD) remains

$${\mathrm{P}\mathrm{U}\mathrm{D}}_s^{\left(c\right)}\left(T\right)=\left[I_{baseline,s}^{\left(c\right)}\left(T\right)-I_{post,s}^{\left(c\right)}\left(T\right)\right]-I_{upgrade,s}^{\left(c\right)}\left(T\right), c \in \mathcal{C}$$

(25)

Here, $I_{baseline,s}^{\left(c\right)}\left(T\right)$ and $I_{post,s}^{\left(c\right)}\left(T\right)$ are the baseline and post-upgrade burdens in the same impact category and horizon, while $I_{upgrade,s}^{\left(c\right)}\left(T\right)$ is the additional transition burden. For the present case, PUD is reported only for operational electricity because complete transition, cloud, and embodied-hardware inventories were not observed; break-even analysis bounds the missing burden instead of treating it as zero.

10.7. Limitations

The proposed framework has several limitations. First, security, decentralization, privacy, availability, and residual risk cannot be represented completely by universal scalar indicators. The framework therefore uses disaggregated profiles and PASS/FAIL/UNRESOLVED gates. In the Ethereum case, several assurance dimensions remain unresolved; this is an explicit result of the framework rather than evidence of full PoW/PoS equivalence.

Second, cloud providers rarely disclose complete service-level energy, hardware, water, and network inventories. Allocation may consequently depend on measured utilization or documented proxies.

Third, the empirical case relies on dated network-energy estimates and measured-hardware envelopes rather than continuous metering of all Ethereum infrastructure over the matched activity windows. The result is therefore robust within the declared operational-energy evidence model but cannot be interpreted as a complete service-level cloud or cradle-to-grave inventory.

Fourth, the matched 28-day windows improve temporal comparability but do not identify The Merge as the sole cause of changes in transaction volume or block time. Transaction demand, fees, market conditions, software changes, and user behaviour may also vary.

Finally, FU-B uses included layer-1 transactions because receipt-level success, spam, and application usefulness were not inferred from aggregate daily charts. FU-Q is consequently UNRESOLVED rather than imputed. Historical cloud allocation, embodied hardware, water, materials, concentration, security-control energy, incident probability, and recovery outcomes were not reconstructed from weak evidence. These omissions narrow the claim to FU-O, while the parity analysis quantifies how large the missing energy burden would have to be to reverse that operational result.

Additional implementation details, datasets, executable scripts, and reproducibility resources are provided in the Supplementary Materials.

11. Conclusions

This study developed an auditable blockchain lifecycle framework with non-compensatory security and utility gates and applied its operational-energy module to Ethereum’s transition from PoW to PoS. FU-O represents observed daily operation, FU-Q requires every mandatory gate to pass, and FU-B remains a transaction-normalized attributional diagnostic. This separation prevents unresolved assurance evidence from being converted into environmental credit.

Using the independent Cambridge baseline, operational electricity decreased from 58,617.39 to 5.376 MWh/day, a factor of 10,903.5 and a reduction of 99.99083%. The CCRI replication factor was 8804.9, and the adverse bounded factor was 3424.7. The central FU-B allocation decreased from 54,748.70 to 4.7305 MWh per one million included transactions, but it remains an attributional diagnostic rather than a marginal-causation estimate.

Monte Carlo propagation produced a median FU-O reduction of 99.98698% and a central 95% interval of 99.97492–99.99441%; all 100,000 realizations exceeded a factor of 3400. The executable workflow also regenerated the deterministic branches, Jansen indices, break-even values, Table 5 and Table 8 source data, and Figure 9 and Figure 10.

The FU-O parity threshold for additional post-Merge cloud and annualized embodied burden was approximately 21,408 GWh/year. This establishes a wide operational robustness margin but does not establish the missing lifecycle, cloud, or assurance modules. Table 6 therefore supports a bounded FU-O conclusion while FU-Q remains UNRESOLVED.

The framework is transferable to other cloud-integrated ledgers when the system boundary, observation period, service denominator, provenance, uncertainty, and assurance-gate status are declared consistently. The principal planning rule is to report the strongest conclusion supported by the available evidence: a PASS permits the declared comparison, a FAIL excludes it, and an UNRESOLVED gate narrows the claim rather than being averaged away.