Emission Impossible: privacy-preserving carbon emissions claims

Anil Madhavapeddy; Jessica Man; Martin Kleppmann; Patrick Ferris; Sadiq Jaffer

REVIEW 3 major objections 4 minor 42 references

Emission Impossible: privacy-preserving carbon emissions claims

T0 review · 3 major / 4 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The paper proposes a zero-knowledge proof system that lets cloud providers make verifiable carbon-emissions claims without disclosing confidential business data.

desk verdict An honest, well-scoped workshop paper that proposes a plausible zk-SNARK architecture for privacy-preserving carbon claims from cloud providers, but the abstract oversells what the proof actually guarantees about input truthfulness. read the letter →

arxiv 2506.16347 v1 pith:QVJP4XOO submitted 2025-06-19 cs.CR

Jessica Man , Sadiq Jaffer , Patrick Ferris , Martin Kleppmann , Anil Madhavapeddy This is my paper · ORCID

classification cs.CR

keywords carbonemissionsreportingzero-knowledgeproofszk-SNARKcloudcomputingsupplychaintransparencygreenwashingprivacy-preservingverification

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper argues that the reason carbon claims from cloud providers are currently unverifiable is a conflict of incentives: companies do not want to disclose the sensitive inputs behind their numbers, and no third party can check every report. It proposes a cryptographic fix: a reporting company attaches a zero-knowledge proof showing the claimed figure was computed correctly from trusted, signed source data, while revealing only the final claim and a public key. If this works, a cloud customer can verify its own carbon footprint without seeing the provider's total energy use, other customers' shares, or supplier details. The harder question of whether the source data themselves are truthful is left mostly to signed smart meters and occasional manual audits.

What carries the argument

The load-bearing object is the zk-SNARK circuit: a public set of constraints encoding the emissions formula $CE = I \cdot X \cdot C$, the verification of signature chains that run from smart meters through manufacturers and suppliers to a certificate authority, and the designation of which inputs are private witnesses. The circuit is the same for every report, so the calculation methodology becomes standardised and auditable. Its soundness is what lets a verifier accept a claim without seeing the private data, and its succinctness is what makes frequent automated verification practical.

What would settle it

Bypass one smart meter so its signed reading understates a data centre's actual power draw, have the provider generate a proof from that reading, and check whether a verifier accepts the resulting emissions claim; if it does, the source-data gap the paper acknowledges is confirmed, since the proof checks only consistency with supplied inputs, not their accuracy.

Watch

Extended reading notes

Core claim

The paper's central claim is that a zk-SNARK can turn carbon-emissions reporting into a verifiable computation: the data centre operator proves knowledge of private inputs (carbon intensity $I$, total energy $X$, and customer share $C$) that satisfy the standard formula $CE = I \cdot X \cdot C$, along with valid signatures on the meter readings and intensity figures. The verifier, who may be a customer, investor, or regulator, checks only the proof plus the claimed emissions figure and a certificate-authority public key. What the proof establishes is that the arithmetic and the signature checks are correct, not that the underlying measurements are accurate.

Load-bearing premise

The proof guarantees the arithmetic is consistent with the inputs it was given, but not that those inputs describe what actually happened; a provider that feeds false but correctly signed meter readings and customer shares still produces a valid proof.

Editorial extensions

If this is right

Cloud customers would be able to verify their reported emissions figure against signed meter readings and signed carbon intensity without learning the provider's total energy use or any other customer's share.
Providers could be held accountable for arithmetic errors or tampered signature chains, because any such proof would fail verification.
The same proof circuit could run through the whole supply chain, from energy supplier to data centre to cloud service provider, making Scope 3 reporting more credible.
Because proofs are only a few kilobytes, they could be bundled with regular emissions reports, allowing frequent automated verification at almost no extra cost.
Adoption would require a standardised emissions-calculation methodology, but once that exists the cryptographic layer can complement existing data-exchange standards.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

An implication the paper leaves implicit is that the weakest link shifts from the reporting company to the metering hardware and certificate authorities: whoever controls a signing key can produce a valid proof for a false reading.
The same circuit pattern could be applied to other privacy-sensitive sustainability metrics, such as water use, waste, or embodied emissions, wherever the metric is a calculation over signed inputs.
A concrete testable extension is to benchmark proof generation for circuits with many customers and many meter readings, to see whether splitting one large proof into many smaller recursive proofs is faster than the paper's single-circuit sketch.
Linking the emissions proof to financial accounting, for example proving that reported energy purchases match supplier payments, would make the source-data layer harder to fake.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Here's the short version: this is an honest, clearly written position paper outlining a zk-SNARK-based approach to privacy-preserving carbon emissions claims for cloud providers. The problem is real, the high-level design is plausible, and the authors are refreshingly explicit about their own limitations. But the abstract's claim that the system would hold providers 'accountable for producing accurate carbon emissions data' is stronger than what the protocol actually delivers: a proof of arithmetic consistency over prover-selected inputs, not a proof that the emissions figure reflects reality. The authors admit this in Section 5—providers could leave out meter readings or invent customer shares—and the Completeness Principle (all customer shares summing to 100%) is explicitly left out of scope in Section 4.2. So the central limitation is acknowledged, but it is still a load-bearing gap relative to the abstract's promises.

What is actually new: the concrete architecture for cloud data centres, with signed smart meter readings anchored through a CA chain, the simple CE = I × X × C formula, and the suggestion of recursive ZKPs for carbon intensity. Heiss et al. applied ZKPs to supply-chain carbon accounting generally; this paper adapts that idea to the cloud context with specific certificate chains and a clear threat model. The critique of existing tools (Microsoft's Emissions Impact Dashboard, Google's methodology) is fair—those don't offer independent verification—and the discussion of business incentives around greenwashing is solid.

The soft spots are mostly matters of completeness rather than correctness. There is no implementation, no circuit, no benchmarks; the three stages are described but not built. The only worked example uses one meter, one signature, one customer, and scalability is waved at with a sentence about 'investigating methods.' The completeness problem is genuinely unsolved and not minor: without it, the proof doesn't prevent a provider from fabricating customer shares or creating fictitious customers. The paper also doesn't tie inputs to physical reality—signature chains prove where a reading came from, not that the meter wasn't bypassed or that the reading is complete.

Citation pattern is fine; Heiss et al. is credited, and the paper leans on standard cryptographic results and external accounting standards, which is appropriate. No self-citation red flags.

Who this is for: researchers working at the intersection of ZKPs and carbon accounting, and regulators or practitioners thinking about how to make green claims cryptographically verifiable without leaking trade secrets. As a workshop position paper, it is a useful discussion piece; as a system paper, it would need far more substance.

Recommendation: yes, send it to peer review. A serious referee should push the authors to either implement a minimal proof of concept or reframe the abstract to promise only 'proof of correct computation from signed inputs,' and to engage seriously with the completeness problem. I would accept it in a workshop track, and ask for revision if it aims at a full venue.

Referee Report

3 major / 4 minor

Summary. The paper proposes a privacy-preserving carbon emissions reporting scheme for cloud supply chains using zk-SNARKs. The central idea is that a cloud provider (the prover) can convince a customer (the verifier) that a reported emissions figure was computed as CE = I × X × C (carbon intensity × total energy × customer share) from signed smart-meter readings and signed carbon intensity data, without revealing the sensitive inputs. The paper motivates the problem through greenwashing and regulatory pressures, reviews related work, outlines a three-stage zk-SNARK application (circuit definition, proof generation, verification), and candidly discusses a range of caveats and future work. No implementation, concrete circuit, formal protocol specification, or security analysis is provided.

Significance. The topic is timely and relevant: applying zk-SNARKs to carbon accounting is a plausible way to address the privacy and competitiveness barriers to verified emissions data. The paper is honest about its limitations and does not fit parameters or derive results from circular assumptions; it builds on standard cryptographic theorems and external carbon accounting standards. However, as it stands, the contribution is a high-level design proposal rather than a fully specified or validated system. The strongest claim in the abstract and conclusion—that the system enables 'verifiable emissions reporting' and holds providers 'accountable for producing accurate carbon emissions data'—is not supported by the described circuit, which proves arithmetic consistency of prover-selected inputs rather than their accuracy or completeness. The paper explicitly defers the Completeness Principle and other data-integrity checks to future work. If revised to either scope the claims precisely or extend the circuit to enforce completeness and aggregation, the approach could become a solid foundation for further research.

major comments (3)

[§4.2, §4.3, §5, Abstract] The load-bearing gap is that a valid proof does not imply the emissions figure reflects real emissions. The relation actually proved is CE = I × X × C plus signature checks on individual inputs; nothing ties X to the complete set of meters or C to a legitimate allocation. The paper itself concedes in §4.2 that the Completeness Principle (all customers' shares sum to 100%) is 'beyond the scope of this paper' and in §5 that a provider may input wrong meter readings, omit meters, or fabricate customer shares. A dishonest prover can therefore produce a valid proof for an arbitrary figure, and knowledge soundness does not help because the dishonest witness satisfies the circuit. This is not an internal inconsistency, but it means the abstract's claims of 'verifiable emissions reporting' and accountability for 'accurate carbon emissions data' are stronger than the construction supports. The authors should either revise the abstract and conclusion to say that the proof verifies correct computation from signed inputs, or extend the circuit to enforce completeness of meter aggregation and share allocation (e.g., include all meter readings, sum of shares = 100%, and binding to a transparency log).
[§4.3] The paper does not define a concrete circuit or formal SNARK relation. It names Circom and zkVMs and gives illustrative JSON, but it does not specify the arithmetic circuit R, the exact public/private input vector, the EdDSA signature verification constraints, or how the certificate-chain checks are encoded. Consequently, the security properties (zero-knowledge, knowledge soundness) are asserted from generic zk-SNARK theory rather than demonstrated for this system. Similarly, the conclusion's claim that proofs are 'a few kilobytes' and verification is fast is not backed by any constraint estimate or benchmark. For a journal publication, a precise relation, a proof sketch of the security properties relative to the trust assumptions, or at minimum an implementation with measurements is necessary to support the central claims.
[§4.3 Stage 3] The public witness in the running example contains only the emissions claim and the CA public key. As the paper notes in passing, a real deployment needs fields binding the proof to a specific customer, reporting period, and data centre operator. Without these bindings, the proof is not end-to-end verifiable for the stated use case (e.g., a customer comparing AI chatbot emissions), and a proof could potentially be replayed or misattributed. The paper should either extend the example to include these fields or explicitly state that the example is a stripped-down illustration and specify how the bindings are realized in practice.

minor comments (4)

[§2.2] The sentence 'Companies can provide proofs that their claims on the carbon emissions report are all true' overstates what the scheme can prove; it should be qualified as 'proofs that the reported figures were computed correctly from the signed inputs,' consistent with the caveats in §5.
[Figure 2] The certificate chain figure is hard to parse without a detailed caption; consider adding a step-by-step walkthrough of the trust chain from CA to smart meter and electricity supplier.
[Throughout] The notation for CO2e is inconsistent (e.g., 'kgCO2𝑒' with a non-standard subscript). Please use uniform formatting such as kgCO2e or kg CO2-e.
[References] Some references contain proxy or non-canonical URLs (e.g., reference [2] uses 'https://www-acm-org.ezp.lib.cam.ac.uk' rather than the ACM page); please ensure all URLs are direct and stable.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the zk-SNARK circuit implements an explicit arithmetic relation over externally signed inputs, all trust assumptions are disclosed, and no self-citation is load-bearing.

full rationale

The paper defines the emissions computation as CustomerEmissions = Intensity × TotalEnergy × Share (§4.1) and proposes a zk-SNARK circuit that proves in zero knowledge that this claim was computed from a signed meter reading, a signed carbon intensity, and a customer share. Nothing in the derivation chain is fitted: the inputs are anchored to external trust roots (meter manufacturer and electricity supplier certificate chains ending at a CA), and the emission claim is the output of the arithmetic rather than a quantity used to define its own inputs. The paper is also explicit about the one point where a reader might suspect the conclusion is smuggled in, namely that proof validity implies real-world accuracy. Section 5 states 'A ZKP alone cannot guarantee everything. For example, if a cloud provider gets meter readings from multiple data centres, there is a chance that they might input the wrong ones or leave out the reading from some meters,' and Section 4.2 explicitly leaves the Completeness Principle (all customers' shares sum to 100%) 'beyond the scope of this paper.' These are disclosed trust assumptions and acknowledged scope limits, not premises that contain the claimed result. There are no fitted parameters called predictions, no empirical claims validated on the same data they derive from, and no self-citations: none of the 42 references is authored by Man, Jaffer, Ferris, Kleppmann, or Madhavapeddy. The gap between the abstract's 'held accountable for producing accurate carbon emissions data' and the protocol's actual guarantee (arithmetic consistency of whatever signed inputs the prover selects) is an overclaim that the paper itself flags in Section 5 ('ZKP alone cannot guarantee everything'); it is a correctness caveat about the strength of the claim, not a circular derivation. The cryptographic building blocks (knowledge soundness of zk-SNARKs, EdDSA, CA chains) are external well-studied results applied as components, and the construction is self-contained against those assumptions.

Assumptions & free parameters 0 free parameters · 6 assumptions · 0 invented entities

The proposal has no fitted parameters and introduces no new physical or cryptographic entities. It borrows existing building blocks (zk-SNARKs, EdDSA, CAs, smart meters) and rests on assumptions about the truthfulness of signed inputs and the security of these building blocks. The paper's own caveats in Section 5 identify the most fragile of these assumptions.

assumptions (6)

standard math zk-SNARK knowledge soundness and zero-knowledge properties hold for the chosen proof system
The scheme in Section 4.3 relies on the standard security properties of zk-SNARKs (e.g., Groth16) as established in the cited literature; if these properties fail, a prover could produce false proofs.
domain assumption Smart meters are correctly installed, not bypassed, and the readings they sign correspond to actual electricity consumption
Stated in Section 4.2: 'We have to assume that the smart meter is correctly installed and not bypassed.' The proof cannot detect a meter that is tampered with at the physical level.
domain assumption The carbon intensity values signed by electricity suppliers are accurate and represent the correct grid mix and commercial arrangements
Section 4.2 assumes the supplier signs the carbon intensity; the ZKP only checks the signature, not whether the value reflects the true carbon content.
domain assumption Customer shares of total energy consumption are honestly allocated and sum to 100% of the data centre's power consumption
The Completeness Principle is referenced in Sections 4.2 and 5, but the paper states that proving this is beyond its scope. The system as described would accept a claim even if the provider invented shares or omitted customers.
domain assumption The certificate authorities at the root of the signature chains are trusted to verify the identities of meter manufacturers and electricity suppliers
The certificate chain in Section 4.2 has the CA's public key as the only disclosed trust anchor; a dishonest or compromised CA breaks the system.
domain assumption The GHG Protocol or an equivalent standardised accounting methodology is used consistently by all parties
Sections 4.1 and 4.3 assume a shared accounting methodology so that emissions figures are comparable across companies; the paper notes that adoption of such standards is an open question.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Emission Impossible: privacy-preserving carbon emissions claims." pith.science (2026). https://pith.science/paper/QVJP4XOO

@misc{pith2026250616347,
  author       = {Pith},
  title        = {Pith review of: Emission Impossible: privacy-preserving carbon emissions claims},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/QVJP4XOO}},
  note         = {Machine review of arXiv:2506.16347}
}

read the original abstract

Information and Communication Technologies (ICT) have a significant climate impact, and data centres account for a large proportion of the carbon emissions from ICT. To achieve sustainability goals, it is important that all parties involved in ICT supply chains can track and share accurate carbon emissions data with their customers, investors, and the authorities. However, businesses have strong incentives to make their numbers look good, whilst less so to publish their accounting methods along with all the input data, due to the risk of revealing sensitive information. It would be uneconomical to use a trusted third party to verify the data for every report for each party in the chain. As a result, carbon emissions reporting in supply chains currently relies on unverified data. This paper proposes a methodology that applies cryptography and zero-knowledge proofs for carbon emissions claims that can be subsequently verified without the knowledge of the private input data. The proposed system is based on a zero-knowledge Succinct Non-interactive ARguments of Knowledge (zk-SNARK) protocol, which enables verifiable emissions reporting mechanisms across a chain of energy suppliers, cloud data centres, cloud services providers, and customers, without any company needing to disclose commercially sensitive information. This allows customers of cloud services to accurately account for the emissions generated by their activities, improving data quality for their own regulatory reporting. Cloud services providers would also be held accountable for producing accurate carbon emissions data.

Figures

Figures reproduced from arXiv: 2506.16347 by the authors.

**Figure 2.** Signature chains for verifiable meter readings and carbon intensity [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗

**Figure 3.** zk-SNARK proof system for private data protected carbon emissions claims. Private data: [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

42 extracted references · 41 canonical work pages

[1]

2022.3Degrees Cloud Services Review Statement

3Degrees. 2022.3Degrees Cloud Services Review Statement. Google. https://services.google.com/fh/files/misc/3degrees_cloud_services_review_ statement_final.pdf

work page 2022
[2]

2021.ACM Technology Policy Council Releases TechBrief on Computing and Carbon Emissions

ACM. 2021.ACM Technology Policy Council Releases TechBrief on Computing and Carbon Emissions. ACM. https://www-acm-org.ezp.lib.cam.ac.uk/media- center/2021/october/tpc-tech-brief-climate-change

work page 2021
[3]

2024.Notice of 2024 Annual Meeting of Shareholders & Proxy State- ment

Amazon. 2024.Notice of 2024 Annual Meeting of Shareholders & Proxy State- ment. https://s2.q4cdn.com/299287126/files/doc_financials/2024/ar/Amazon- com-Inc-2024-Proxy-Statement.pdf

arXiv 2024
[4]

2021.Microsoft Sustainability Calculator 2 GHG Method- ology Assurance Statement

LLC Apex Companies. 2021.Microsoft Sustainability Calculator 2 GHG Method- ology Assurance Statement. https://download.microsoft.com/download/9/d/e/ 9de2b0ba-45f1-4f6c-bb82-1cddb4fc54e5/Microsoft_Sustainability_Calculator_ 2_GHG_Methodology_Assurance_Statement.pdf

work page 2021
[5]

José Azar, Miguel Duro, Igor Kadach, and Gaizka Ormazabal. 2021. The big three and corporate carbon emissions around the world.Journal of Financial Economics 142, 2 (2021), 674–696

work page 2021
[6]

Marta Bellés-Muñoz, Miguel Isabel, Jose Luis Muñoz-Tapia, Albert Rubio, and Jordi Baylina. 2022. Circom: A circuit description language for building zero- knowledge applications.IEEE Transactions on Dependable and Secure Computing 20, 6 (2022), 4733–4751

work page 2022
[7]

Eli Ben-Sasson, Alessandro Chiesa, Christina Garman, Matthew Green, Ian Miers, Eran Tromer, and Madars Virza. 2014. Zerocash: Decentralized anonymous payments from bitcoin. In2014 IEEE symposium on security and privacy. IEEE, 459–474

work page 2014
[8]

Eli Ben-Sasson, Alessandro Chiesa, Eran Tromer, and Madars Virza. 2014. Suc- cinct Non-Interactive Zero Knowledge for a von Neumann Architecture. In23rd USENIX Security Symposium (USENIX Security 14). 781–796

work page 2014

Show all 42 references

[9]

Nir Bitansky, Ran Canetti, Alessandro Chiesa, and Eran Tromer. 2012. From ex- tractable collision resistance to succinct non-interactive arguments of knowledge, and back again. InProceedings of the 3rd Innovations in Theoretical Computer Science Conference. 326–349. 1st Intern...

2012
[10]

Esther Calderon-Monge, Ivan Pastor-Sanz, and F Javier Sendra Garcia. 2020. Analysis of sustainable consumer behavior as a business opportunity.Journal of Business Research120 (2020), 74–81

2020
[11]

2025.Carbon Footprint reporting methodology

Google Cloud. 2025.Carbon Footprint reporting methodology. Google. https: //cloud.google.com/carbon-footprint/docs/methodology

2025
[12]

2023.Proposal for a Directive on Green Claims

European Commission. 2023.Proposal for a Directive on Green Claims. European Union. https://environment.ec.europa.eu/publications/proposal-directive-green- claims_en

2023
[13]

2021.Should estimating the power consumption of A WS EC2 instances really be quite this hard?https://www.thestack.technology/power- consumption-of-aws-ec2-instances/

Benjamin Davy. 2021.Should estimating the power consumption of A WS EC2 instances really be quite this hard?https://www.thestack.technology/power- consumption-of-aws-ec2-instances/

2021
[14]

2022.Private Report Shows How Amazon Drastically Undercounts Its Carbon Footprint

Will Evans. 2022.Private Report Shows How Amazon Drastically Undercounts Its Carbon Footprint. https://revealnews.org/article/private-report-shows-how- amazon-drastically-undercounts-its-carbon-footprint/

2022
[15]

2023.Pathfinder Framework: Guidance for the Accounting and Exchange of Product Life Cycle Emissions

Partnership for Carbon Transparency. 2023.Pathfinder Framework: Guidance for the Accounting and Exchange of Product Life Cycle Emissions. https://www.wbcsd. org/wp-content/uploads/2023/01/PACT-Pathfinder-Framework-WBCSD.pdf

2023
[16]

Erol Gelenbe and Yves Caseau. 2015. The impact of information technology on energy consumption and carbon emissions.ubiquity2015, June (2015), 1–15

2015
[17]

Shafi Goldwasser, Silvio Micali, and Chales Rackoff. 2019. The knowledge com- plexity of interactive proof-systems. InProviding sound foundations for cryptog- raphy: On the work of Shafi Goldwasser and Silvio Micali. 203–225

2019
[18]

2018.The Companies (Directors’ Report) and Limited Liability Partnerships (Energy and Carbon Report) Regulations 2018

Gov.uk. 2018.The Companies (Directors’ Report) and Limited Liability Partnerships (Energy and Carbon Report) Regulations 2018. Gov.uk. https://www.legislation. gov.uk/uksi/2018/1155/contents/made

2018
[19]

Jens Groth. 2016. On the size of pairing-based non-interactive arguments. In Advances in Cryptology–EUROCRYPT 2016: 35th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Vienna, Austria, May 8-12, 2016, Proceedings, Part II 35. Spring...

2016
[20]

Jonathan Heiss, Tahir Oegel, Mehran Shakeri, and Stefan Tai. 2024. Verifiable Carbon Accounting in Supply Chains.IEEE Transactions on Services Computing 17, 4 (2024), 1861–1874. https://doi.org/10.1109/TSC.2023.3332831

2024
[21]

Daira Hopwood, Sean Bowe, Taylor Hornby, Nathan Wilcox, et al. 2016. Zcash protocol specification.GitHub: San Francisco, CA, USA4, 220 (2016), 32

2016
[22]

Jiahui Huang, Teng Huang, and Jiehua Zhang. 2022. zkChain: An Efficient Blockchain Privacy Protection Scheme Based on zk-SNARKs. InInternational Conference on Machine Learning for Cyber Security. Springer, 400–410

2022
[23]

Josefsson

S. Josefsson. 2017.RFC 8032: Edwards-Curve Digital Signature Algorithm (EdDSA). https://datatracker.ietf.org/doc/html/rfc8032

2017
[24]

Dimcho Karakashev, Sergey Gorbunov, and Srinivasan Keshav. 2020. Making renewable energy certificates efficient, trustworthy, and anonymous. In2020 IEEE International Conference on Communications, Control, and Computing Technologies for Smart Grids (SmartGridComm). IEEE, 1–7

2020
[25]

2025.Succinct Processor 1

Succinct Labs. 2025.Succinct Processor 1. https://docs.succinct.xyz/docs/sp1/ introduction

2025
[26]

Duc Anh Luong and Jong Hwan Park. 2022. Privacy-preserving blockchain- based healthcare system for IoT devices using zk-SNARK.IEEE Access10 (2022), 55739–55752

2022
[27]

2024.So much for green Google

Tobias Mann. 2024.So much for green Google ... Emissions up 48% since 2019. https://www.theregister.com/2024/07/02/google_datacenter_emissions/

2024
[28]

2025.Emissions Impact Dashboard

Microsoft. 2025.Emissions Impact Dashboard. https://www.microsoft.com/en- us/sustainability/emissions-impact-dashboard

2025
[29]

David Mytton. 2020. Hiding greenhouse gas emissions in the cloud.Nature Climate Change10, 8 (2020), 701–701

2020
[30]

2024.Greenwashing – the deceptive tactics behind environ- mental claims

United Nations. 2024.Greenwashing – the deceptive tactics behind environ- mental claims. https://www.un.org/en/climatechange/science/climate-issues/ greenwashing

2024
[31]

Assa Naveh and Eran Tromer. 2016. PhotoProof: Cryptographic Image Authenti- cation for Any Set of Permissible Transformations. In2016 IEEE Symposium on Security and Privacy (SP). 255–271. https://doi.org/10.1109/SP.2016.23

2016 doi
[32]

2025.Standards and Guidance

GreenHouse Gas Protocol. 2025.Standards and Guidance. https://ghgprotocol. org/standards-guidance

2025
[33]

2025.RiscZero

RiscZero. 2025.RiscZero. https://dev.risczero.com/api/zkvm/

2025
[34]

2024.Microsoft’s carbon emissions up nearly 30% thanks to AI

Dan Robinson. 2024.Microsoft’s carbon emissions up nearly 30% thanks to AI. https://www.theregister.com/2024/05/16/microsoft_co2_emissions/

2024
[35]

2024.AI is poised to drive 160% increase in data center power demand

Goldman Sachs. 2024.AI is poised to drive 160% increase in data center power demand. https://www.goldmansachs.com/insights/articles/AI-poised-to-drive- 160-increase-in-power-demand

2024
[36]

Ian Schneider and Taylor Mattia. 2024. Carbon accounting in the Cloud: a methodology for allocating emissions across data center users.arXiv preprint arXiv:2406.09645(2024)

2024 arXiv
[37]

2020.Cloud Jewels: Estimating kWh in the Cloud

Emily Sommer, Mike Adler, John Perkins, Joshua Thiel, Hilary Young, Chelsea Mozen, Dany Daya, and Katherine Sundstrom. 2020.Cloud Jewels: Estimating kWh in the Cloud. https://www.etsy.com/codeascraft/cloud-jewels-estimating- kwh-in-the-cloud/

2020
[38]

2025.ZK Jargon Decoder

Open source community. 2025.ZK Jargon Decoder. https://zkjargon.github.io/ definitions/succinct.html

2025
[39]

2018.Request from Amazon Stakeholders to Board Di- rectors on Climate Change

Amazon stakeholders. 2018.Request from Amazon Stakeholders to Board Di- rectors on Climate Change. https://drive.google.com/file/d/1_WprgbeUpic7_ t8ovirFsmzxf_J0w6h1/view

2018
[40]

2024.Google, Amazon and the problem with Big Tech’s climate claims

James Temple. 2024.Google, Amazon and the problem with Big Tech’s climate claims. https://www.technologyreview.com/2024/07/17/1095019/google-amazon- and-the-problem-with-big-techs-climate-claims/

2024
[41]

European Union. 2022.Directive (EU) 2022/2464 of the European Parliament and of the Council of 14 December 2022 amending Regulation (EU) No 537/2014, Directive 2004/109/EC, Directive 2006/43/EC and Directive 2013/34/EU, as regards corporate sustainability reporting (Text with ...

2022
[42]

Zhi Yang, Thi Thu Huong Nguyen, Hoang Nam Nguyen, Thi Thuy Nga Nguyen, and Thi Thanh Cao. 2020. Greenwashing behaviours: Causes, taxonomy and con- sequences based on a systematic literature review.Journal of business economics and management21, 5 (2020), 1486–1507

2020

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.

[1] [1]

2022.3Degrees Cloud Services Review Statement

3Degrees. 2022.3Degrees Cloud Services Review Statement. Google. https://services.google.com/fh/files/misc/3degrees_cloud_services_review_ statement_final.pdf

work page 2022

[2] [2]

2021.ACM Technology Policy Council Releases TechBrief on Computing and Carbon Emissions

ACM. 2021.ACM Technology Policy Council Releases TechBrief on Computing and Carbon Emissions. ACM. https://www-acm-org.ezp.lib.cam.ac.uk/media- center/2021/october/tpc-tech-brief-climate-change

work page 2021

[3] [3]

2024.Notice of 2024 Annual Meeting of Shareholders & Proxy State- ment

Amazon. 2024.Notice of 2024 Annual Meeting of Shareholders & Proxy State- ment. https://s2.q4cdn.com/299287126/files/doc_financials/2024/ar/Amazon- com-Inc-2024-Proxy-Statement.pdf

arXiv 2024

[4] [4]

2021.Microsoft Sustainability Calculator 2 GHG Method- ology Assurance Statement

LLC Apex Companies. 2021.Microsoft Sustainability Calculator 2 GHG Method- ology Assurance Statement. https://download.microsoft.com/download/9/d/e/ 9de2b0ba-45f1-4f6c-bb82-1cddb4fc54e5/Microsoft_Sustainability_Calculator_ 2_GHG_Methodology_Assurance_Statement.pdf

work page 2021

[5] [5]

José Azar, Miguel Duro, Igor Kadach, and Gaizka Ormazabal. 2021. The big three and corporate carbon emissions around the world.Journal of Financial Economics 142, 2 (2021), 674–696

work page 2021

[6] [6]

Marta Bellés-Muñoz, Miguel Isabel, Jose Luis Muñoz-Tapia, Albert Rubio, and Jordi Baylina. 2022. Circom: A circuit description language for building zero- knowledge applications.IEEE Transactions on Dependable and Secure Computing 20, 6 (2022), 4733–4751

work page 2022

[7] [7]

Eli Ben-Sasson, Alessandro Chiesa, Christina Garman, Matthew Green, Ian Miers, Eran Tromer, and Madars Virza. 2014. Zerocash: Decentralized anonymous payments from bitcoin. In2014 IEEE symposium on security and privacy. IEEE, 459–474

work page 2014

[8] [8]

Eli Ben-Sasson, Alessandro Chiesa, Eran Tromer, and Madars Virza. 2014. Suc- cinct Non-Interactive Zero Knowledge for a von Neumann Architecture. In23rd USENIX Security Symposium (USENIX Security 14). 781–796

work page 2014