Zero-Knowledge Proof Extensions for Digital Product Passports in Sustainability Claims Reporting and Verifications

Abstract

Digital product passports outline information about a product’s lifecycle, circularity, and sustainability-related data. Sustainability data contains claims about carbon footprint, recycled material composition, ethical sourcing of production materials, etc. Also, upcoming regulatory directives require companies to disclose this type of information. However, current sustainability reporting practices face challenges, such as greenwashing, where companies make incorrect claims that are difficult to verify. There is also a challenge of disclosing sensitive production information when other stakeholders, such as consumers or other economic operators, wish to verify sustainability claims independently. Zero-knowledge proofs (ZKPs) provide a cryptographic system for verifying statements without revealing sensitive information. The goal of this research paper is to explore ZKP cryptography, trust models, and implementation concepts for extending DPP capability in privacy-aware reporting and verification of sustainability claims in products. To achieve this goal, first, formal representations of sustainability claims are provided. Then, a data matrix and trust model for generating proofs are developed. An interaction sequence is provided to show different components for various proof generation and verification scenarios for sustainability claims. Lastly, the paper provides a circuit template for the proof generation of an example claim and a credential structure for their input data validation. The proposed approach is assessed using a scenario-based evaluation to check the performance metrics for data credential verification and proof generation for verifying material composition in a product.

1. Introduction

Digital product passports (DPP) specify information about a product and its lifecycle, including component suppliers, manufacturer, validity period, information that enables its circularity, and sustainability-related information [1]. Sustainability claims in DPP are data claims that specify certain regulatory and quality properties in a product. Such claims may outline specific material composition in a product, carbon footprints, recycled material content, etc. Sustainability claims, especially in consumer products, are becoming a regulatory necessity, particularly with the European Union’s upcoming DPP requirements and Green Claims Directive [2,3]. Companies must disclose data such as carbon footprint, recycled content, material compositions, and sourcing practices to comply with these rules. In addition, sustainability claims also specify product quality attributes that help build consumer trust in a product [4]. For instance, eco-conscious consumers are more likely to purchase an organic product over a non-organic one of similar quality. They will also choose products with lower carbon footprints and more recycled content over similar products without these properties, as the former adopts environmental conservation practices during its production. Some research studies have proposed an AI-based approach for the efficient use and extension of a product’s lifecycle [5,6]

However, current practices face two major challenges. First, consumers and regulators struggle to verify sustainability claims, which can lead to greenwashing and erode confidence in environmental information [7]. Second, companies are reluctant to disclose detailed product and supply chain data due to concerns over intellectual property, trade secrets, and competitive advantage. This tension between transparency and confidentiality creates a pressing need for a system that ensures verifiable, trustworthy sustainability claims while safeguarding sensitive business information.

Privacy-aware computation provided in ZKP systems provides the possibility of verifying sustainability claims in products without revealing sensitive business information. ZKPs are a cryptographic protocol that enables a prover to prove the correctness of a statement without revealing sensitive information about the statement [8]. Using selective disclosure mechanisms within ZKPs, companies can prove statements such as “this product contains at least 30% recycled material” or “its carbon footprint is below a regulatory threshold” without revealing confidential raw data. Stakeholders, such as manufacturers, auditors, regulators, and consumers, will benefit from trusted, machine-verifiable sustainability information tailored to their needs. The value proposition lies in enabling compliance with emerging regulations, protecting intellectual property, preventing greenwashing, and enhancing consumer trust in sustainable products.

The objective of this paper is to formally describe sustainability claims in consumer products and provide a ZKP-based system for verifying these claims while protecting sensitive information related to the claims. The main contribution of this work lies not in introducing new zero-knowledge primitives, but in providing a claim-agnostic methodology that unifies (i) formal claim specification, (ii) trust-aware input validation, and (iii) privacy-preserving proof generation within a DPP-compatible architecture. This contribution clearly differs from previous research studies on single-claim sustainability attribute verification (e.g., carbon emissions or provenance) [9,10]. This work focuses on producing a generalized sustainability verification framework for DPP based on ZKPs.

The rest of this paper is structured as follows: Section 2 provides background and related literature review. Section 3 provides a formal description of various sustainability claims. Section 4 describes the data types and the trust model scenarios for the input data used in proof generation. Section 5 outlines the interaction sequences for the relevant stakeholders and entities for the proof generation and verification lifecycle. Section 6 shows the necessary algorithms for implementing the ZKP system for sustainability claim verifications. Section 7 provides scenario-based experiments to evaluate the concepts developed in this paper. Section 8 provides the discussions resulting from this work. Section 9 provides the conclusion of this work, along with the limitations and future work.

2. Background and Related Works

2.1. Technical Concepts

• Blockchain: This is a p2p network of nodes that executes and stores transactions in an immutable ledger using cryptography to ensure that data stored in the network cannot be modified, and with formal consensus mechanisms, it specifies conditions for adding new data to the network [11].
• Smart contracts: These are self-executable computer programs running on various blockchain networks and do not require any centralized entity to enforce business conditions defined in them. Solidity is the common programming language for writing smart contracts [12].
• zk-SNARK: This is a cryptographic framework for developing general ZKP systems covering different problem types. Due to their non-interactive verification process and fixed proof size, they are commonly used in decentralized applications. Logic conditions and signals that satisfy these conditions are represented as formal circuits in zk-SNARKs [13].
• Circom: This is a high-level human-readable language for realizing zk-SNARKs circuits. Several open-source libraries and IDEs, like the REMIX tool, can be used to implement Circom codes and generate proofs. These open source tools can also be used to generate the verifier scripts for zk-SNARK circuits. These verification scripts can be realized as Solidity code for smart contracts [14].
• Verifiable Credential: VCs contain a collection of data claims and digital signatures that validate the claims. The credential is issued by an issuer (who signs the claims) to the holder (who makes the claims). In a VC structure, usually specified as JSON, the upper layer outlines the information subject of the claim and the issuer of the signature. The middle layer contains a list of claims. The bottom layer contains the digital signatures signed by the issuer on each of the claims [15].
• Decentralized ID: This is a unique identifier that addresses the entities in a verifiable credential, such as the issuer, holder, and data subjects. To verify the data claims in a VC, a verifier uses a DID resolver, which is software that retrieves public keys associated with a DID to verify the digital signatures in a credential [16].

2.2. Related Works

2.2.1. DPP Architecture and Product Sustainability Information

To describe the architecture of DPP, we use a metamodel derived from the conceptual definition of DPP components following the CIRPASS initiative and GS1 standards. Both CIRPASS and GS1 are two successful EU-wide projects that seek to provide frameworks and standards for describing and implementing DPP for different industry sectors and use cases [17]. According to CIRPASS, a DPP is simply defined as a structured collection of product-related data focused on sustainability and circularity [18]. GS1 describes DPP as a unique representation of a product/product information, composed of multiple component entities representing sub-parts or materials of the product. Each product and component can carry associated sustainability objects that capture specific environmental or social metrics [17]. Some of the sustainability information represented in DPP includes carbon footprint values, percentage of recycled material content, material composition details, or ethical raw material sourcing certifications, which are contextualized by a relevant lifecycle stage of the product (such as manufacturing, use, or end-of-life phase). The sustainability information specified in DPP may also include digital attestation (credentials). Figure 1 shows a metamodel schema that provides a structured representation of a DPP that applies to real-world DPP implementations across multiple industries, enabling interoperability and trustworthy disclosure of sustainability claims.

Figure 1 outlines the UML class diagram of a DPP metamodel, showing the key classes such as the Product, Component, LifecycleStage, SustainabilityClaim, and VerificationCredential with their attributes. A product is composed of zero or more components, and each component is part of a product. In that case, a component of a product can also be an independent product. A product can have multiple lifecycle stages, each representing a phase (e.g., manufacturing, usage, end-of-life) with start and end dates. Each lifecycle stage is associated with at least one product. Each instance of a sustainability claim can be linked to either a product or a component. Hence, a product or component may have many sustainability claims. A sustainability claim may have a digital credential for its attestation with a verification method. The goal of the current paper is to describe a privacy-preserving method for verifying sustainability claims in DPPs using ZKPs.

2.2.2. ZKPs in Supply Chain Verifications

There is an increasing body of research about applying ZKPs for verifications in supply chain and production processes [19]. These works have integrated ZKPs in supply chains for product authenticity verifications [20], product integrity and counterfeit checks [21,22], and supply chain data privacy in public blockchains [23,24]. Still, the research for applying ZKPs in verifying sustainability claims in the supply chain of consumer products is still in the early phase. The work [25] applied chain of custody models in DPPs for tracking and validating sustainability attributes of products throughout supply chains. The research [26] applied range proofs in ZKPs to provide origin information for a supply chain product without revealing its exact location. Proof of product origins is essential for providing compliance and ethical raw material sourcing. Similarly, the research applied ZKPs to validate adherence to sustainability standards, origin, and handling procedures without revealing sensitive supply chain data [27]. Lastly, the research works applied ZKPs for proving carbon emissions claims in production and green product labeling [10,28]. Our work follows a generalized framework for sustainability claims verification by first formally describing different sustainability claims and describing various trust models for verifying these claims based on different public and private data inputs in the claim generation. Although the field of sustainability verification research is still evolving, and there is no defined list of sustainability claims, our work provides an extendable approach for verifying different types of sustainability claims information in DPPs.

3. Formalization of Sustainability Claims in DPP

3.1. Product Carbon Footprint

The carbon footprint of a product is derived from the sum of the emission indexes of activities during its production, divided by the total units produced [29]. Activities may include inbound and outbound logistics, energy consumption, etc. Different product groups have a well-established list of activities used in estimating their carbon footprints. Each activity type has an emission index associated with it. Different means of moving products (air, sea, land, rail, etc.) have different emission indices, and the emission index in production energy consumption for renewable energy is expected to be lower than that of fossil fuels when used in production factories. Formulating a specific carbon footprint formula is beyond the scope of this paper. Still, while the paper does not prescribe a specific lifecycle assessment model, the formalization is compatible with established methodologies such as ISO 14067 and the GHG Protocol Product Standard [30,31], which define system boundaries, activity categorization, and emission factor sourcing for product-level carbon accounting.

$${\displaystyle \frac{{\sum }_{i=1}^n\left(QtyAc{t}_i·E_i\right)}{T_u}}=PxTC{O}_{2}e$$

(1)

$${\displaystyle \frac{{\sum }_{i=1}^n\left(QtyAc{t}_i·E_i\right)}{T_u}}\le MaxPxTC{O}_{2}e$$

(2)

where

• $QtyAc{t}_i$ is the quantity of energy consumed in production activity i.
• $E_i$ is the emission index of activity i.
• $T_u$ is the total product units produced.
• $PxTC{O}_{2}e$ is the carbon footprint for the product x.
• $MaxPxTC{O}_{2}e$ is the maximum allowed carbon footprint for the product x.

Equations (1) and (2) show a generalized formulation of carbon footprints for a range of activity types $i\dots n$, for a total amount of product units $Tu$, such that each unit has a carbon footprint $PxTC{O}_{2}e$. For Equation (2), the carbon footprint value is expected to always be lower than or equal to a specified maximum carbon footprint value. These equations, when realized in a zk-SNARK circuit, allow specific activities (and other variables in the formula) that are not to be disclosed to the public to be hidden in the circuit. A proof can be generated that the computation of the carbon footprint calculation results in a given value $PxTC{O}_{2}e$. Specifically for Equation (2), the output of the equation can also be hidden, especially when doing so can result in a competitive advantage. Hence, a manufacturer can also prove that the carbon footprint of its product is less than a given amount of maximum allowed carbon footprint ($MaxPxTC{O}_{2}e$) without revealing the actual footprint. Such high boundaries of carbon footprint are usually specified by regulators for compliance purposes.

3.2. Product Material Composition

The percentage of the material composition is the ratio of a specific material to all other materials used in production. In the textile industry, the material composition of a product could include different percentage representations of materials such as cotton, wool, polyester, etc. The zk-SNARK provides the possibility to represent the material composition formula as a circuit and generate proofs for the material composition percentages, such that IP-protected materials and their compositions can be hidden in the circuit.

$${\displaystyle \frac{W_1{R}_1}{W_1{R}_1+W_2{R}_2+\dots +W_n{R}_n}}=R_{1}MC\%$$

(3)

where

• $W_i{R}_i$ is the weight of the raw material i.
• $R_{i}MC\%$ is the percentage material composition of $R_i$.

Equation (3) shows the material composition of a given input raw material $R1$ in comparison to all the raw materials $R1,R2,\dots ,Rn$ used in the production of a product. The raw materials’ composition in a product is a function of their weights in the product. Proofs of a percentage representation of materials $(R_{1}MC\%,R_{2}MC\%,\mathrm{etc}.)$ can be generated for specific materials, while the sensitive materials are hidden in the circuit.

3.3. Recycled Material Composition

Verification of recycled material composition shares a similar formula with material composition, such that the percentage of recycled material composition is the ratio of recycled materials to all materials used in production. Also the actual amount of recycled material and other IP-protected materials and their compositions can be hidden in the circuit. With zk-SNARK representation of the formula in a circuit, the proof of the composition of recycled material (ratio), not the actual amount, can be generated.

$${\displaystyle \frac{W_{Re}}{TWRM}}=ReMC\%$$

(4)

$${\displaystyle \frac{W_{Re}}{TWRM}}\ge MinReMC\%$$

(5)

where

• $W_{Re}$ is the weight of the recycled materials used in the production.
• $TWRM$ is the total weight of all materials used in the production of x.
• $ReMC\%$ is the percentage of recycled material composition of the product x.
• $MinReMC\%$ is the percentage of the minimum amount of recycled material composition required in a product x.

Equation (4) shows the material composition for a recycled material $Re$ in comparison to the total raw material $TRM$ used in production. The composition is represented as the weights of each material. In a case of special regulatory requirements, where a specified amount of recycled material is expected to be reused in a product, a manufacturer can provide proof that the recycled material content is greater than or equal to the minimum required recycled content composition $MinReMC$, as shown in Equation (5).

Recycled material in Equation (5) is a positive product property, unlike Equation (2), where carbon footprint is a negative product property. The higher the carbon footprint, the lower the quality of a product is, while the higher the recycled material, the higher the quality of the product is considered in terms of its sustainability properties. Hence, less than and greater than are used to express these attributes in Equations (2) and (5), respectively.

3.4. Other Sustainability Claims

Beyond the previously formalized sustainability claims, there are several other sustainability claims for regulatory compliance or to outline product quality, such as ethical raw material sourcing, raw material sources, suppliers, etc. A manufacturer can provide proof that materials used in the production of a product are ethically sourced or are within a specified location. Manufacturers can also provide proof that their suppliers are within a specified list of approved suppliers. These proofs can be provided without revealing the exact sourcing locations or revealing their product suppliers. Still, formalizing and implementing zk-SNARK circuits for these types of claims is beyond the scope of the current paper.

4. Sustainability Claims Data Matrix and Trust Model

4.1. Input and Output Data Sources

Outlining the sources of data used in the generation (and verification) of proofs for sustainability claim validation is necessary to understand the trust model necessary for the proof lifecycle. Equations (1)–(5) all have input data on the left side and output data on the right side. The trustability of generated proofs in sustainability claims verification is dependent on the source of data. The output data is not problematic since it is either provided by the circuit or by an external entity like a regulator. However, for the input data, which are mostly provided by the manufacturer, different types of trust models are needed to analyze the trustability of the proofs.

Table 1. Data sources for different claim types.

Claim Type	Data Object	Unit	Data Type	ZKP-C	EO	RD
Carbon footprint	Quantity of production activity	kWh	input		*
	Total product units	unit	input		*
	Activity emission index	TCO2e per unit activity	input			*
	Product carbon footprint	T CO2e per unit product	output	*
	Max. product C. footprint	T CO2e per unit product	input			*
Material composition	Raw material type	categorical	input		*
	Raw material qty.	kg	input		*
	Material composition perecentage	% (w/w)	output	*
Recycled material	Total raw material	kg	input		*
	Recycled material qty.	kg	input		*
	Recycled material composition percentage	% (w/w)	output	*
	Min. recycled material composition percentage	% (w/w)	input			*

Note: ZKP-C: data from ZKP circuit; EO: data from economic operator; RD: external data from regulatory database, *: status of data object on specific data source.

shows data objects associated with different sustainability claim types. The table shows that input data for proof generation are mostly produced by economic operators such as product manufacturers and external data sources like regulatory databases. The output is produced mostly from the circuit or from the regulatory databases when they are comparative outputs, like the maximum allowed carbon footprint or the minimum required recycled material in a product.

4.2. ZKP Input Data Validation Trust Model

Different trust levels are connected to different scenarios of input data validation for proof generation.

4.2.1. Economic Operator (EO) Validates Its Input Data

This is the minimum trust level where an economic operator, like a product manufacturer, provides input data for proof generation and validates the input data by issuing a credential certifying the data’s correctness. Since a sustainability claim is made by the same entity that certifies the input data, there is a potential risk that this economic operator can manipulate the data such that the proof generated is always valid for the claim made. This is particularly relevant for the carbon footprint claim, as shown in Equation (1), where the input data for this claim are internal production activities of the manufacturer.

4.2.2. EO Input Data Validated by Another EO

In this scenario, an economic operator that makes a claim provides the input data for the claim proof generation; however, another economic operator provides a credential that certifies the input data. In this setup, trust is distributed across multiple organizations for input data, and the risk of data manipulation by the economic operator that makes the claim is reduced. This scenario is relevant for a claim about material composition. As shown in Equation (3), the input data for this claim verification are raw materials used in the actual production of the product. Hence, suppliers of raw materials can each provide credentials that validate the quantity supplied to the manufacturer.

4.2.3. EO Input Data Validated by an Auditor

Another level of trust in proof generation for sustainability claims is the use of external auditors to verify and issue data credentials for the input data. In this setup, an economic operator that wishes to generate a proof about a sustainability claim will first obtain a credential from an external auditor that validates the input data. If an external auditor certifies the data, then proof can be generated for the claim made by the economic operator. In some designs of the DPP, auditors can have access to an external backup of data associated with a product. This can provide the auditor with an alternative data source to verify the correctness of the data provided by the economic operator. Besides that, auditors also have access to internal processes in production facilities; hence, they can validate the correctness of data provided by the economic operator. This level of distribution of trust between the economic operator and the auditor reduces the risk of input data manipulation, ensuring that the proof generated represents the correct situation in the production process.

4.2.4. EO Input Data Validated by Blockchain-Enabled Merkle Tree

In this setup, a Merkle tree is first used to aggregate all the data associated with a particular product of a DPP, and the root hash is stored on the blockchain. This prevents the product manufacturer from manipulating or changing the input data for the proof generation. Hence, a manufacturer provides the input dataset along with their Merkle proof to a verification service provider. This service provider verifies the input data by checking the Merkle tree such that the data provided along with the Merkle proofs matches the Merkle root stored on the blockchain. If the data supplied is correct, the service provider then generates the proof of the claim. In this setup, trust is distributed across the economic operator that provides the input data, the blockchain that stores the Merkle root, and a third-party verifier that checks the Merkle tree to verify the correctness of the input data.

5. ZKP Interaction Sequences

5.1. Auditor Issued Credentials for Input Data Validation

The ZKP lifecycle is largely divided into proof generation and proof verification processes. Figure 2 shows the sequences of activities in proof generation, where an external auditor issues credentials for input data for proof generation.

The sequence of activities starts with an economic operator selecting a claim type it wants to generate proof for. As already shown in Equations (1)–(5), each claim type has different formal representations, hence a different circuit for each sustainability claim. The verification service provider publicly hosts the zk-SNARK circuit files for different types of claims. To increase trustability, a hash of the circuit file can also be stored on the blockchain or copies of the circuit stored in manipulation-resistant databases like IPFS. The verification service provider returns the needed data type for the requested claim. The economic operator gets the data and shares the claim data with an external auditor to issue credentials for the datasets provided. The auditor internally verifies the data, issues a credential for the input data for proof generation, and shares the credential-backed claim data with the verification service provider for proof generation. The verification service provider verifies the credential validity, selects the correct zk circuit for the claim, and generates a proof of the sustainability claim. The generated proof and the public data associated with the proof are directly written into the DPP of the particular product for which the claim is made.

To verify the claim, a customer who wishes to purchase the product or another economic operator can read the proof data from the DPP and select a suitable verifier for the claim. The verifiers for specific circuits are hosted by the verification service provider. Also other economic operators can independently host and run the verifier for different proof circuits that have been established within the DPP system. The verifier checks the proof and the public statements to verify that they certify the conditions of the circuit on which the proof is based. The status of the verification is returned to the verifier.

5.2. Blockchain-Stored Merkle Root for Input Data Validation

Figure 3 shows the interaction sequences for blockchain-integrated input data validation. All previous interaction sequences (see Figure 2) are utilized, except those related to input data validation for proof generation. In this case, the economic operator obtains all the necessary input data for the selected claim type and then shares the data, along with the Merkle proof of the input data’s correctness, directly with the verification service provider. The verification service provider rebuilds the Merkle tree with the data provided by the economic operator and checks that the Merkle root matches the manipulation-resistant Merkle root previously stored on the blockchain.

6. ZKP Extensions Implementing Concepts

6.1. ZKP Circuit for Sustainability Claims

For sustainability claims in Equations (1)–(5), a separate zk-SNARK circuit has to be prepared for each of them to outline the signal conditions that satisfy the equation. In outlining the implementation concepts, this paper focuses on Equation (3) to show the input signals, output signals, and mathematical conditions for realizing the equation in a circuit in a textile material production scenario.

The material composition circuits represent the ratio of a particular material and the summation of the list of all materials used in textile production. Each material input is provided in weight, and zero input is provided when a material in the list is not used in the textile product. Using a list of all possible materials protects the circuit’s signals from linking to a specific manufacturer’s input material list. Since direct divisions are not easily implemented in zk-SNARK circuits, the inverse of the total materials’ weight is also provided. The input total inverse is validated with a condition in the circuit that checks that the multiplication of the inverse total supplied and the total produced in the circuit results in 1. The zk-SNARK circuits are designed for integer calculations; hence, the decimal number produced by the inverse total is scaled using a factor ${10}^x$ that ensures the number becomes an integer. The input inverse total validation becomes $total\times inv\_total\equiv 1\times {10}^x$. All arithmetic operations inside the zero-knowledge circuit are performed on the scaled integer values. Unit conversions and scaling are performed off-circuit and validated through externally issued verifiable credentials or standardized registries. The rest of the calculation follows basic arithmetic operations. The composition percentage, which is the output of the circuit, is the multiplication of the specific product weight and the validated inverse of the total weight. These are shown in the Circom code in Listing 1.

All sustainability claim computations are implemented using fixed-point arithmetic to ensure compatibility with zero-knowledge circuits, which operate over finite fields and do not support floating-point numbers. Each real-valued quantity $x\in \mathbb{R}$ is encoded as an integer $\tilde{x}=⌊x·{10}^p⌋$, where p is a globally agreed precision parameter. The precision parameter p is selected based on the semantic meaning of the quantity. For example, percentages are encoded with $p=2$ to preserve two decimal places, while emission factors are encoded with $p=6$ to allow micro-scale precision. Deterministic floor rounding is applied to avoid ambiguity across proof generators and to ensure circuit determinism.

To protect the variables in the circuit material composition, every possible material used in the product is mapped to an indexed ID, and the index number is used to represent the material on the circuit. The circuit template shown in Listing 1 provides an easy-to-understand overview for the readers; however, the circuit simulation experiment performed in Section 7 uses indexes to represent the materials in the circuit.

Listing 1. CIRCOM CODE: Material Composition Circuit.

Listing 1. CIRCOM CODE: Material Composition Circuit.

6.2. Verifiable Credential for ZKP Input Data Validation

The input data for proof generation can be verified by another party that issues a data credential to the party that makes the sustainability claim. The credential issuer can be a trusted entity (e.g., an auditor), another economic operator (e.g., a supplier), or a self-issued data credential by the economic operator that makes the sustainability claim (e.g., manufacturer). Figure 4 shows the changes in the credential structure as it moves from the issuer to the verifier. The core structure of the credential contains the credential metadata and the data claims. The metadata comprises the issuer DID, the subject (holder) DID address, and the type of credential. The data claims part consists of specific claims and values assigned to the claims, such as material type, material quantity, supply date, etc. The issuer of the credential signs all the claims in the credential. The product manufacturer aggregates all the credentials received from different suppliers using a verifiable presentation (VP), signs it, and shares the VP with a verifier. The verifier (which in this case is the entity that produces the proof) uses a DID resolver and associated DID document to verify the credentials before using the data in the VC for proof generation.

The credential example in Listing 2 is expressed as a W3C verifiable credential (VC) payload This choice is motivated by compactness and ease of transport in DPP deployments. The same credentialSubject claims can alternatively be represented using JSON-LD with Data Integrity proofs, without changing the ZKP design. DID-based verification follows standard DID resolution: the verifier resolves the issuer DID (issuer_did) to obtain the issuer DID document, extracts the appropriate verification method (public key), and verifies the credential signature against that key material. Key rotation is handled by DID document updates according to the DID method and resolution rules. Credential revocation or suspension is handled via the VC credentialStatus mechanism. In the workflow outlined in the paper, the proving/verifying service validates both the issuer signature and the credential status before accepting any credential-derived values as inputs to the ZKP circuit.

Listing 2. JSON: Material supply credential.

Listing 2. JSON: Material supply credential.

To use the credential structure provided in the JSON above for the circuit presented earlier, it is expected that the suppliers of the materials will provide credentials for the supply of cotton, wool, silk, and polyester with the following quantities: 3 tonnes, 2 tonnes, 5 tonnes, and 10 tonnes, respectively.

7. Evaluation and Threat Analyses

7.1. Scenario-Based Design Evaluation

This paper adopts a scenario-based approach for evaluating the privacy-preserving sustainability claims reporting and verification. The scenario-based evaluation provides a realistic system-level performance assessment that aligns with the actual supply chain workflows without necessarily implementing the complete PoC of designs outlined in this paper.

7.1.1. Scenario Description

The scenario described in this part of the paper provides a concise overview of the workflow for validating input data for proof generation, the actual proof generation, and verification. The following actors are relevant for the scenario-based evaluation, including Manufacturer, Suppliers, Prover/verifier Service, and Consumers. The Manufacturer (M) produces a product and generates a proof material composition through a verification service provider. The Supplier ($S_i$) issues signed credentials attesting to delivered material quantities. The Verifier/proofer Service ($Ps$) verifies the credentials and uses the specified quantities as input data for proof generation. The Consumer (C) verifies the proof contained in the DPP. The manufactured product (P) contains several sub-components/materials ($P{M}_i$), and the signature credentials provided by the suppliers for the materials are represented as ($V{C}_i$).

The following flow applies in the simulation of the evaluation scenario. Suppliers ($S_1\dots S_n$) issue signed credentials of supplied materials ($P{M}_1\dots P{M}_n$), and each of the credentials contains the material type and quantity, in a specific time where $V{C}_i=Sig(S_i,materialType,quantity,timestamp)$. The manufacturer collects the suppliers’ signed credentials and sends them to the proving service Ps for proof generation. Ps encodes the verified material quantities into the ZK circuit and generates a proof (e.g., $P{M}_i=x\%$ or $P{M}_i\ge x\%$). M embeds the proof into the DPP, and C verifies the proof over Ps before product purchase.

7.1.2. Performance Metrics and Workload

The main goal for the scenario-based performance evaluation of this work is to show how much effort (in time) it takes Ps to verify data credentials submitted by M and generate the proof. Proof verification time (and cost) is constant for zk-SNARK-based ZKPs and has been extensively evaluated in previous work [8]. Hence, it will not be considered in the scenario-based evaluation of the current work. The credential verification time is evaluated by gradually increasing the number of signed credentials ($V{C}_i$) in the VC provided by suppliers for production materials. A verifiable presentation (VP) is used by the manufacturer to aggregate the VCs provided by the suppliers, which includes the VP binding signature signed by the manufacturer. Hence, the service provider verifies the VP signature and VC signatures for each presentation, and the computation time is recorded. This is repeated over a specific number of iterations while gradually increasing the number of VCs in the presentation.

The proof generation time (for material composition) is evaluated by gradually increasing the number of materials ($P{M}_i$) that make up the product as defined in the zk-SNARK circuit. The computation time is measured for each proof generation iteration. It is assumed that validated input, which is the material quantity amount extracted from the VCs, as performed in the previous experiment, is used in the proof generation by the service provider. However, for the sake of simplicity, both experiments are performed in parallel. Furthermore, it is also assumed that each input material is supplied by a separate entity (has a unique VC). Hence, the total time required by the service provider to generate the proof is the sum of the time required to verify the input data credentials and the actual computation time for the proof generation.

7.1.3. Experiment Setup and Result

The first experiment, which is the credential verification experiment, is set up using a simple Python setup on a virtual computing environment. An Intel Xeon Platinum 8370C CPU @ 2.80 GHz is used as the Linux container. The Python code https://github.com/cjobuzor/Verifiable-credentials-signatuture-verification-experiment/tree/main (accessed on: 20 January 2026) implements the key generation function (two Ed25519 keys used in the experiment), the signature generation function, and the verification function. One key is used to sign the VCs, and the second key is used for the VP signature. Note that only signature verification is performed in the experiment, as it is assumed the addresses in the DID are already cached and reused in the Python code. Additional VC verifications, such as validity, revocation, etc., were not considered in the simplified experiment. The Ed25519 signatures were generated with OpenSSL, and the credential payload is formatted as a JSON JWT-VC for simplicity. Also for simplicity, it is assumed that each material used in a product has its own VC credential issued by a supplier. The VC verification time is recorded one time for a single VC. Since it is assumed the VC scales linearly (if all the other conditions remain the same), the VC time for each material composition is derived by multiplying by the number of materials (n). The VP verification time does not scale linearly with the number of credential proofs it contains; hence, the experiment is repeated for all the values of n, and the average time is recorded for the VP.

The second experiment, which is the proof generation experiment, is set up using GROTH16 zk-SNARK proof generation library on REMIX IDE on a standard laptop. The zk-SNARK framework is selected as the ZKP because of its non-iterative nature, and the generated proofs have a fixed proof size for all circuits. Groth16 is well supported by tooling such as Circom, SarkJs, and REMIX. The browser-based development environment REMIX IDE is selected for the circuit evaluation because it provides an easy-to-use interface for executing zk-SNARK circuits. The execution time is collected using the Firefox Profiler environment (https://profiler.firefox.com (accessed on: 20 January 2026)). The Circom ZKP Compiler is based on v2.1.8wasm and 14 PTAU on a 16K maximum constraint, which is the default configuration on REMIX IDE. Although zk-SNARKs require a trusted setup environment for proof generation, this can lead to fake proofs if the toxic waste from the setup process is not properly handled. Multi-party computation (MPC) has been suggested as a suitable solution to address this limitation. However, the MPC environment is not included in this experiment, as it is beyond the scope of this work and would draw the focus away from the paper’s main objectives, which address zk-SNARKs’ security limitations. The circuit (

Listing A1. CIRCOM CODE: adapted material composition circuit.

) and the input JSON data (

Listing A2. JSON: material composition for n:5.

,

Listing A3. JSON: material composition for n:10.

and

Listing A4. JSON: material composition for n:20.

) in Appendix A (Experiment Data) are used for this experiment. The circuit represents an adaptation of the initial circuit in Listing 1; however, indexes (M1, M2, M3, ..., Mn) are used to represent the materials in the circuit instead of the actual material name. The JSONs represent the input data used in generating the proof for every value of n. The experiment is repeated five times, starting with n = 5 and doubling the value of n, until n = 80.

The results of the two experiments are used in generating

Table 2. Performance evaluation with varying numbers of materials.

Experiment ID	Number of Materials (n)	VP Sign. Verification Time (ms)	VC Sign. Verification Time (ms)	Proof Generation Time (ms)	Total Time (ms)
1	5	17	75	1317	1408
2	10	17	151	1347	1515
3	20	17	302	1417	1736
4	40	17	604	1483	2104
5	80	17	1207	1881	3105

. Figure 5, derived from the table, shows the time (in milliseconds) required to generate the proof of material composition as the number of materials in the product increases. This total time represents the amount of time it will take a service provider to verify the material supply credentials issued for each material in a product, and the amount of time needed to generate the proof (using the zk-SNARK material composition circuit).

7.2. Threat Analyses

A threat model is used to outline the potential attack surfaces for the privacy-preserving sustainability claims verification system described in this paper and their mitigation strategies. In developing the threat model, the following assumption applies: the main actors (suppliers, manufacturers, or proofing service providers) can be compromised, the storage/communication network is untrusted, and customers trust only cryptographically verified sustainability claims.

7.2.1. Attack Surface Extraction

The current design of the system focuses on distributed input data validation to prevent fake proof generation by product manufacturers for their sustainability claims. Still, the system is open to additional threats, such as replay attacks, circuit substitution, and invalid proofs. Replay attacks can occur on the credential level (input data validation and proof generation) when old data is reused to generate the proofs. Replay attacks can also occur on the proof level (proof verification) when the same proofs are reused in similar products. This threat can be exploited by the product manufacturer. Circuit substitution occurs when a different circuit is used to generate the proof. This threat can be exploited by the verification service provider to generate fake proofs within the system. Other threats include the risk of proof/verification service centralization and the possibility of collusion attacks. Given the important role of the service provider that verifies the credentials and generates the proofs, there is a risk of centralization of the system. Collusion attacks, which are common in collaborative systems, can be exploited such that the manufacturer can collude with specific suppliers to generate fake credentials for the input data used in proof generation by the service provider.

7.2.2. Mitigation Strategies

Several strategies can be adopted to mitigate the replay attacks and circuit substitution threats that affect the sustainability reporting and verification system designed in this paper. The replay attack associated with credential reuse can be limited by introducing timestamps with expiration periods for the data credentials issued by product suppliers (or other supply chain entities) for proof generation. This ensures that the service provider that generates the proof on behalf of the manufacturer not only verifies the signatures in the data claims in the VC but also checks the expiration validity of the claims. The timestamp of the expiration period of the claim can be included as an additional property of the VC. For the proof associated with replay attacks, a nonce or binding batch ID can be used to connect the proof to a particular product group. This ensures that the proof cannot be reused for a different product.

The threat of the verification service provider arbitrarily switching the original circuit to generate fake proofs can be prevented by storing the circuit or the circuit fingerprint on-chain. The consumer (or any other entity) who wants to verify the proof (of a sustainability claim in a DPP) can check the circuit used to derive the proof verification logic to ensure that it matches the publicly stored circuit/circuit signatures on-chain. Since the verification logic of the switched circuit cannot match that of the original circuit, this attack can easily be detected.

Other threats, such as the risk of centralization by the service provider, can be reduced by distributing, reassigning, and rotating the proof generation roles between all the major players in the supply chain (product manufacturer and suppliers). In this way, there is no central entity for proof generation, as the role can be randomly assigned to any supply chain player. Still, such a scheme for role rotation has to be incentivized to ensure that all the important actors contribute meaningfully to the important processes, such as input data credential generation, credential verification, and proof generation. Collusion risks are difficult to address in these types of systems. However, they can be limited by introducing a reputation system backed by an incentivization mechanism for all the important actors.

8. Discussions

8.1. Research Implication

-

Sustainability fraud prevention and anti-greenwashing: The main implication of the research presented in this paper is that introducing verifiability to sustainability claims will potentially reduce greenwashing and other associated frauds. The privacy-preserving aspect of the verification provides additional motivation to economic operators and manufacturers to share verifiable claims without revealing sensitive product information. Still, the approach presented in this paper uses ZKPs for sustainability reporting and verification, which is not without inherent risks of manipulation. To reduce the potential risk of manufacturers using flawed production processes to generate fake proofs, the system relies on a blockchain network for data provenance from manufacturing operations, and auditors and other economic operators sign VCs for data validation. Still, the described verification system is prone to collusion attacks and data quality limitations. Hence, a robust governance system is necessary to manage stakeholder activities in the proof generation and verification process. The paper [32] proposes a consortium-based approach for governing stakeholders and managing infrastructure in decentralized applications. A token incentivization approach can also be adopted to reward the activities of economic operators and auditors in verifying data from other economic operators for proof generation [33]. Practically, manufacturers can generate proof for their sustainability claims without any data verification from an external entity. Hence, a rating system can be introduced for the sustainability claims—claims without any proof, claims with ZKP proof but without input data verification, or claims with proofs and input data validated by an external entity. The external entity that validates input data can be ranked based on its historical activities. In this way, the risk of fake proof generation due to collusion of economic operators is reduced. This approach of tokenized consortium governance of stakeholders in proof generation and verification also addresses the data quality concerns in ZKP proofs, addressing the problem of “garbage in data, valid proof out” with decentralized data verification.

-

Extendability of sustainability claims verification: The sustainability claims formalized in this paper do not cover claims like ethical sourcing, approved suppliers, geo-bounded provenance claims, and social impact labor practice claims. The goal of formalizing sustainability claims is to ensure that a formal circuit can be generated for their verification. Hence, this research provides a foundation for more research in designing ZKP circuits and schemas for different sustainability claims by following a similar approach applied in this paper. Furthermore, the current list of sustainability claims is non-exhaustive, as these types of claims are open to addition (or even removal) of claims due to the changing regulatory landscape in sustainability research [34,35]. Although it is practically impossible to formalize all sustainability claims and generate ZKP circuits or algorithms for each of the claims, a proper framework is needed to navigate this challenge and prioritize claim verifications that have the most impact for consumers. The current work formalized three claims, including carbon footprint, material composition, and recycled materials, and then provided a ZKP circuit template for verifying material composition.

8.2. Adoption Pathways and Socio-Technical Challenges

The adoption of ZKPs in reporting and verifying sustainability claims in consumer products faces three main challenges, including regulatory, technical (interoperability and computing), and user experience issues.

-

Regulatory readiness: ZKP provides an enabler for economic operators and manufacturers to report sustainability information about their products without revealing sensitive proprietary information. No regulation currently requires business organizations to use privacy-preserving technologies like ZKPs for their sustainability reporting. The question arises whether a separate regulation is needed for the adoption of ZKPs in supply chains and consumer-facing products. For instance, can manufacturers present ZKP proof to government compliance officers instead of full data disclosure for their auditing processes? The paper [36] discusses how ZKPs can help public and private entities verify compliance in business operations, raising conflicting dilemmas for government oversight. Furthermore, the work [37] notes that although the EU regulation on digital identity wallets mentions the use of ZKPs, no clear legal process has been established for their use. Hence, one of the steps necessary to ensure the adoption of ZKPs in product sustainability verification is to provide a clear legal framework for their use, especially in consumer-facing applications where trust and privacy are essential.

-

Interoperability and technical integration challenges: Beyond the CIRPASS and GS1, there are several other implementations of DPPs for different industry sectors [38,39]. Hence, developing a ZKP schema and algorithms for sustainability claims verifications and integrating them into different DPP implementations will be a daunting task. One approach to solving this is to develop an independent ZKP-based sustainability reporting and verification tool and provide an API for their optional integration into existing DPPs. The DPP component can provide a presentation layer for the sustainability claims and their proofs; however, proof generation and verification are handled by services outside of core DPP components. Besides interoperability challenges, there is also an operational computing challenge for generating and verifying ZKPs. Generating proofs consumes a lot of computing resources, especially for a large list of products in supply chains [40]. A well-designed token incentivization mechanism will ensure that entities that provide input data verification services, proof generation, and verification services are well compensated. Integrating verifiable sustainability claims to product information improves product quality and consumer goodwill; hence, entities and organizations that enable the verification process within supply chains should be rewarded for their contributions.

-

User experience challenges: Different stakeholders, consumers, manufacturers, and regulators have different expectations in using ZKPs to report and verify sustainability claims. For ZKPs to be widely adopted and accepted in supply chains, they have to be usable, especially for the consumer. The consumers’ interactions with ZKPs will mostly be for the claim verification process. For the ZKP interaction sequences presented in this paper, the consumer (verifier) will read the proof/claim data from the DPP and then verify the proof through the verification service provider components. This process can be automated through API exchanges between DPPs hosted by a supply chain entity and a verification service hosted by an external service provider. Hence, the usage of the verification service by the consumer is expected to be fast and incur no additional cost to the consumer. There are still system complexity challenges in setting and maintaining proof generation and verification [8]. If the proof generation and verification service is outsourced to a third-party service provider, the manufacturer only has to cover the additional cost of the verification services provided. The manufacturer has to balance the gains from product quality and consumer goodwill (due to verifiable sustainability claims) and additional costs that ZKPs introduce to each product. The manufacturer or economic operator can also prioritize consumer products where the goodwill gained balances their ZKP costs.

9. Conclusions

This work explored the application of ZKPs to extend the capabilities of DPP in presenting and verifying the sustainability claims in consumer products. Relevant sustainability claims were identified and formalized to identify necessary input and output data, useful for proof generation and verification. For instance, a range proof can be generated to show that the carbon footprint of a product is less than a specified amount. The actual amount of carbon footprint per product unit can also be presented as an output, whereas the input production activities used for their calculation are hidden from the public. The percentages of material composition or recycled content composition can be generated as the output of a proof, whereas other confidential materials and their compositions are protected from the public. A data matrix is presented for different sustainability claims, the data sources were also examined, and trust model scenarios for input data validation are presented. The validation of input data for proof generation is necessary to ensure trust in the generated proof; otherwise, the system faces a problem of “garbage input data, valid proof output”. The trust model shows different scenarios where manufacturers, other economic operators, and blockchain technologies play different roles in validating input supply chain data and generating trustable ZKP proofs. Furthermore, this work used sequence diagrams to show different components in the privacy-aware sustainability claims verification and the interactions necessary for proof generation and verification. Lastly, a SNARK circuit is used to provide a template for the proof generation schema of a sustainability claim, and a VC structure is used to present the schema for input data validation for the proof generation service. Scenario-based experiments are used to demonstrate the concepts developed in this paper by assessing the total time required to validate the proof input data and generate the proof of material composition.

This work has some limitations. First, the formalization of sustainability claims and circuit templates for the proof generation does not cover all the sustainability claims that can be represented in DPPs. Secondly, although this work provides template schemas for proof generation and input data validation, the output proofs have not been integrated into an actual DPP system to evaluate the performance and usability of the approach. The main future work that will evolve from the current work is a ZKP-based sustainability reporting tool, and will loosely integrate the proof presentation part into the DPP structure. The tool will expand the circuits to support different types of sustainability claims and enable automated proof generation for validated input data.