A dual-QR blockchain-based authentication mechanism for agricultural anti-counterfeiting

1 Introduction

Counterfeiting in agricultural supply chains remains a persistent problem that undermines market transparency, damages producer reputation, and poses risks to consumer safety. Food fraud is estimated to impose annual losses on the global food economy in the tens of billions of US dollars and to affect a substantial share of commercially sold products Fernando et al. (2025); Everstine et al. (2024). Despite extensive research on anti-counterfeiting technologies, practical deployments continue to face significant limitations in terms of cost, scalability, and trust assumptions. Recent systematic reviews further indicate that many agri-food traceability solutions remain difficult to deploy at scale due to fragmented architectures, operational complexity, and limited real-world integration Vasileiou et al. (2025); Bekkouche and de Magistris (2025); Huang et al. (2025).

Among existing solutions, QR code–based systems are widely adopted due to their low cost and ease of integration. However, these systems typically rely on centralized databases for verification, which introduces both technical and organizational vulnerabilities. Public QR codes can be easily replicated and attached to counterfeit products, while centralized control enables potential data manipulation or collusion, allowing fraudulent records to appear legitimate Sunny et al. (2020).

In contrast, hardware-based approaches such as RFID and secure tagging technologies provide stronger protection but incur substantial deployment and operational costs, making them impractical for low-margin agricultural products Masekwana and Jokonya (2025). Recent blockchain-integrated RFID and NFC frameworks proposed in 2024–2025 Li et al. (2024); Subramaniam et al. (2025) further strengthen authenticity guarantees and traceability capabilities, but they continue to depend on specialized hardware infrastructure, limiting cost-effective deployment in large-scale agricultural environments.

Blockchain technology has emerged as a promising approach to address trust and transparency issues in supply chains by providing immutable and auditable records. Prior studies have demonstrated its effectiveness in enabling traceability and provenance tracking across agricultural and industrial domains Zhang et al. (2023); Chen et al. (2022). More recent studies integrating Ethereum, IPFS, and blockchain-enabled NFC infrastructures Sharma et al. (2025); Vakil et al. (2025); Subramaniam et al. (2025) further demonstrate the growing practical feasibility of decentralized traceability architectures. However, these approaches primarily focus on recording product histories rather than enforcing authenticity at the individual product level. In practical deployments, blockchain-based traceability solutions rely on publicly accessible identifiers, such as QR codes, to link physical products with their corresponding digital records. While blockchain ensures the integrity of recorded data, it does not inherently prevent the duplication or replay of physical-to-digital identifiers. As a result, the authenticity of individual product units remains unenforced, even when their provenance is immutably recorded. Recent surveys Pang et al. (2024); Alar et al. (2026) likewise identify unit-level authenticity enforcement through consumer-facing identifiers as a persistent unresolved challenge in blockchain-enabled agri-traceability systems.

This limitation highlights a fundamental gap in existing research. Current solutions do not simultaneously achieve (i) low-cost deployment suitable for large-scale agricultural products, (ii) resistance to identifier duplication and reuse, and (iii) trust-independent verification that does not rely on centralized authorities. This observation is consistent with recent scoping and systematic reviews Bekkouche and de Magistris (2025); Huang et al. (2025), which report that although blockchain adoption for provenance tracking has expanded rapidly, cost-effective and practically deployable mechanisms for unit-level authentication remain limited. These unresolved challenges motivate the need for a practically deployable authentication artifact capable of enforcing unit-level authenticity while preserving scalability, usability, and low operational cost.

To address this limitation, this study follows a Design Science Research (DSR) approach Hevner et al. (2004) to design a blockchain-enabled anti-counterfeiting artifact centered on a dual-QR authentication protocol. The proposed protocol separates public traceability from private authentication by assigning each product two QR codes: a public code for accessing general provenance information and a concealed private code that serves as a unique, single-use identifier. The private identifier is revealed only after package opening, reducing the risk of large-scale replication. Unlike conventional QR-based systems, the proposed protocol enforces one-time verification semantics by recording the first successful verification event on the blockchain, ensuring that each product identifier can be validated at most once and thereby preventing replay or duplication attacks.

To satisfy practical deployment requirements, the proposed artifact is implemented within a hybrid architecture that combines blockchain and centralized components. Blockchain is used as the execution layer for validation logic and state persistence in the proposed system Kamble et al. (2020), while centralized services provide efficient data management and low-latency interaction. An intermediary server handles transaction submission on behalf of users, removing the need for direct blockchain interaction, and the verification application is deployed on IPFS to ensure integrity and public verifiability Trautwein et al. (2022). This design balances security, usability, and operational cost, making it suitable for large-scale agricultural environments.

A functional prototype was implemented to evaluate the proposed artifact against the defined security and deployment requirements. The evaluation considers key metrics including QR code generation efficiency, verification latency, operational cost, and requirement-oriented security analysis. The results demonstrate that the proposed framework achieves practical deployability while maintaining low operational cost and strong security guarantees, indicating its suitability for real-world agricultural anti-counterfeiting scenarios.

This study focuses on the problem of product authenticity verification in settings where consumers trust the manufacturer but require assurance that a purchased item has not been replicated or reused by adversaries. The objective is therefore to protect product identity at the unit level, rather than to establish trust in the producer itself.

The main contributions of this paper are as follows:

• A blockchain-enabled dual-QR authentication artifact for low-cost anti-counterfeiting. We design a dual-QR authentication protocol that separates public traceability from concealed single-use authentication, enabling unit-level product verification without specialized hardware. The proposed artifact is formally grounded through an adversary model and a set of security and practical design requirements, including unforgeability, non-replayability, non-repudiation, trust independence, cost-effectiveness, scalability, and user-oriented accessibility.
• A hybrid architectural design balancing decentralized trust and practical deployability. We design a hybrid architecture integrating blockchain verification, IPFS-hosted decentralized applications, and off-chain coordination services to balance security, scalability, usability, and operational cost in practical agricultural deployment settings.
• A prototype instantiation and requirement-oriented evaluation. We implement the proposed framework on public blockchain infrastructure and evaluate it under realistic operational conditions through security analysis, performance measurements, and cost evaluation, demonstrating its feasibility, scalability, and deployability for large-scale agricultural anti-counterfeiting scenarios.

The remainder of this paper is organized as follows. Section 2 describes the adopted Design Science Research methodology. Section 3 formulates the problem, establishes the threat model, and defines the formal security and practical requirements. Section 4 reviews existing anti-counterfeiting approaches and blockchain-based authentication mechanisms. Section 5 presents the design of the proposed dual-QR authentication mechanism. Section 6 describes the system architecture and implementation. Section 7 reports the experimental setup and evaluation results. Section 8 discusses the findings, implications, and limitations. Finally, Section 9 concludes the paper.

2 Design science research methodology

This study adopts a Design Science Research (DSR) approach to guide the development and evaluation of a blockchain-enabled anti-counterfeiting artifact based on dual-QR authentication. The adopted methodology is informed by the Design Science paradigm proposed by Hevner et al. (2004) and the Design Science Research Methodology process model introduced by Peffers et al. (2007). Within this context, the primary research artifact is a dual-QR blockchain-based authentication protocol designed to support low-cost, unit-level anti-counterfeiting in agricultural supply chains while contributing architectural and methodological insights for blockchain-enabled authentication systems.

Figure 1 summarizes the overall DSR workflow adopted in this study. The research process begins with problem formulation, where the study first establishes the system context and operational characteristics of agricultural anti-counterfeiting scenarios, followed by the definition of the threat model and adversarial assumptions. Based on this analysis, the study formalizes the authentication problem and derives a set of design requirements for the proposed artifact. The study subsequently reviews existing anti-counterfeiting approaches and blockchain-based authentication systems to position the proposed artifact within the current research landscape and identify unresolved limitations in existing solutions, particularly replay vulnerability in conventional QR-based systems, the high deployment cost of RFID/NFC-based approaches, limited verification transparency, and insufficient deployability in large-scale agricultural environments.

The proposed artifact combines a public QR layer for provenance access with a concealed private QR layer containing randomized identifiers for one-time authentication. To support practical deployment, the study further proposes a hybrid architecture that combines blockchain infrastructure as the trusted verification layer with centralized database services as the high-performance operational layer. A working prototype implementing the proposed protocol and architecture is developed using public blockchain infrastructure and IPFS-hosted decentralized applications.

The resulting artifact is evaluated with respect to its security properties, architectural feasibility, and practical deployability in agricultural supply-chain environments. The evaluation includes security-oriented analysis, prototype-based implementation validation, operational cost analysis, and performance measurements for product registration and verification workflows.

Finally, the research outcomes are communicated through the formal specification of the proposed artifact, including the authentication protocol, system architecture, implementation details, and evaluation results presented in this study. To support transparency and reproducibility, the source code and smart contract implementation have been publicly released through a Zenodo repository with a permanent DOI Pham and Trinh (2026).

By structuring the study around DSR principles, the manuscript positions the proposed framework not merely as a software implementation, but as a systematically designed and rigorously evaluated artifact intended to address practical anti-counterfeiting challenges in agricultural supply chains.

3 Problem formulation and requirements

3.1 System context and problem overview

Counterfeiting in agricultural supply chains remains a persistent challenge, where genuine and counterfeit products are often indistinguishable to end users. This issue undermines consumer trust and causes substantial financial and reputational damage to legitimate producers. The problem addressed in this work is the authentication of individual product units in open and adversarial environments, without relying on specialized hardware or fully trusted administrative entities.

In a typical setting, a producer P releases a batch of products associated with a production project ϕ. Each product must be equipped with an identifier that enables consumers C to verify its authenticity after purchase. The verification process must prevent both the creation of counterfeit identifiers and the reuse of legitimate ones. At the same time, the solution must remain low-cost, easy to deploy, and compatible with high-volume, low-margin agricultural products.

Existing identifier-based systems fail to guarantee two essential properties: (i) uniqueness of identifiers across product instances, and (ii) single-use verifiability. In particular, publicly accessible identifiers can be reused across multiple physical items, violating the one-to-one mapping between product units and their digital representations. Consequently, the problem is to design a low-cost authentication mechanism that remains reliable even when publicly visible identifiers can be copied and administrative entities cannot be fully trusted.

3.2 Threat model and assumptions

We consider an adversary A operating in a partially trusted environment. The adversary is modeled as a probabilistic polynomial-time (PPT) entity Katz and Lindell (2020) with the following capabilities.

3.2.1 Capabilities

• A can observe and duplicate any identifier that is publicly visible on product packaging.
• A can manufacture counterfeit packaging and attach copied or fabricated identifiers.
• A can compromise the intermediary I, gaining the ability to intercept, delay, or fabricate responses to consumer queries.
• A can read all public records stored in the system registry.

3.2.2 Assumptions

• Standard cryptographic primitives are secure, i.e., A cannot invert one-way hash functions or forge digital signatures in polynomial time U.S. National Institute of Standards and Technology (2015); Katz and Lindell (2020).
• The registry, once updated, is immutable and cannot be altered retroactively.
• Certain identifiers may be physically concealed within product packaging and are inaccessible prior to package opening.

The final assumption is physical rather than cryptographic. It may be violated if an adversary can open and reseal packaging without detection, for example during supply chain interception. This limitation is discussed further in Section 8.

3.3 Formal problem definition

We formalize the product authentication problem as follows.

3.3.1 Entities

The system involves four types of entities:

• Producer P: an authorized manufacturer that issues products and registers their identities.
• Consumer C: an end user who verifies product authenticity.
• Intermediary I: an operational entity facilitating communication between users and system infrastructure, not assumed to be trusted.
• Adversary A: an entity attempting to introduce counterfeit products that pass authentication.

3.3.2 Problem statement

Given a production project ϕ and a batch of N products p 1 , p 2 , … , p N issued by P, design a protocol Π consisting of a registration phase, in which P registers product identities to produce a system state R (registry), and a verification phase, in which C submits a query for product p i and receives a result in AUTHENTIC, COUNTERFEIT, or ALREADY_VERIFIED.

3.4 Design objectives and challenges

Designing a practical authentication mechanism in this setting involves several fundamental challenges.

First, publicly visible identifiers are inherently vulnerable to duplication Wang et al. (2023); Chen J. et al. (2023). Since consumers rely on such identifiers for interaction, eliminating them is not feasible. However, allowing unrestricted reuse of public identifiers enables large-scale counterfeiting.

Second, reliance on centralized administration introduces a trust bottleneck Sunny et al. (2020); Vasileiou et al. (2025). A malicious or compromised authority can create, modify, or approve fraudulent records, thereby undermining the reliability of authentication results.

Third, stronger security mechanisms often conflict with cost and deployability constraints. Hardware-based solutions improve resistance to cloning but require specialized components and infrastructure, making them unsuitable for low-margin agricultural products Masekwana and Jokonya (2025); Subramaniam et al. (2025).

Finally, there exists a fundamental trade-off between usability and security Mbadlisa and Jokonya (2024). Authentication must be simple enough for end users to perform using standard devices, while still providing strong guarantees against identifier forgery and reuse.

These challenges collectively motivate the need for an authentication mechanism that separates publicly accessible information from secure, non-replicable identifiers while ensuring that verification outcomes remain trustworthy under minimal trust assumptions.

3.5 Design requirements

Based on the identified operational constraints, adversarial assumptions, and deployment challenges, the proposed anti-counterfeiting framework must satisfy the following design requirements, spanning both security and practical deployment considerations.

DR1 – Unforgeability. For any PPT adversary A, the probability that A produces an identifier that the system accepts as valid for some product p i, where no corresponding entry for p i exists in the registry R, is negligible.

DR2 – Non-replayability. For any product p i, at most one verification query for p i may result in AUTHENTIC. All subsequent queries must return ALREADY_VERIFIED.

DR3 – Non-repudiation. For any product p i, every verification that changes its registry state from unredeemed to redeemed must produce an immutable, timestamped, and publicly auditable record.

DR4 – Trust Independence. Verification correctness must not depend on the honesty of I. Even if compromised, I cannot fabricate valid results, alter records, or prevent independent auditing.

DR5 – Cost-effectiveness and Deployability. The mechanism must minimize manufacturing and operational costs by relying on widely available, low-cost components Masekwana and Jokonya (2025); Vu et al. (2024). It should integrate seamlessly into existing production and distribution workflows without requiring specialized hardware or significant process modifications.

DR6 – Performance and Scalability. The mechanism must support high volumes of product registration and verification requests with low latency Huang et al. (2025); Vu et al. (2024). In particular, it should enable efficient batch registration for producers while maintaining responsive verification for end users.

DR7 – User-oriented Accessibility. The authentication process must remain simple and accessible to end users Subramaniam et al. (2025); Li et al. (2025). Consumers should be able to verify product authenticity through standard interactions, such as scanning QR codes, without requiring specialized devices, dedicated applications, or technical expertise.

4 Background and related work

4.1 Technical background

This subsection briefly introduces the key technologies used in the proposed system, focusing on their roles in enabling secure and scalable product authentication.

4.1.1 Blockchain

In this work, blockchain is used to maintain a shared state of product identifiers and their verification status. Its append-only structure ensures that once a verification event is recorded, the corresponding state transition cannot be reversed without global consensus Huang et al. (2025); Kamble et al. (2020).

4.1.2 Smart contract

Smart contracts enable deterministic execution of verification logic on-chain. In this work, the smart contract maintains the product registry and enforces single-use redemption semantics, ensuring that each product identifier can be validated at most once Sharma et al. (2025); Anthony et al. (2023).

4.1.3 Cryptographic hash function

A cryptographic hash function is used to map secret identifiers to fixed-length digests stored on-chain. By relying on the preimage resistance of SHA-256, the system ensures that secret identifiers cannot be reconstructed from their on-chain representations, preserving confidentiality while enabling verifiable lookup Li et al. (2024).

4.1.4 QR code

QR codes serve as a low-cost interface for encoding product-related data and triggering verification workflows. Their compatibility with standard smartphones enables seamless user interaction without requiring specialized hardware Renushe et al. (2025); Wang et al. (2023).

4.1.5 IPFS

IPFS is used to host the verification application in a content-addressable manner. Each deployment is bound to a unique Content Identifier (CID), ensuring that users interact with an immutable and publicly verifiable version of the application Trautwein et al. (2022); Vakil et al. (2025).

4.1.6 Polygon Network

Polygon is adopted as the deployment platform due to its low transaction fees and fast confirmation times. These characteristics make it suitable for large-scale product verification scenarios where frequent on-chain interactions are required Sharma et al. (2025).

4.2 Related work

Anti-counterfeiting in supply chains has been widely explored across sectors such as pharmaceuticals, agriculture, consumer goods, and luxury products. Existing approaches span QR code systems, RFID/NFC-based authentication, physical anti-counterfeiting labels, and blockchain-supported traceability. This section reviews representative work in these four directions. Recent systematic literature reviews Vasileiou et al. (2025); Pang et al. (2024); Bekkouche and de Magistris (2025) likewise highlight persistent challenges related to scalability, deployment cost, trust assumptions, and unit-level authenticity verification, motivating continued research in this area.

4.2.1 QR code–based approaches

QR codes remain one of the most common authentication mechanisms due to their low cost and ease of deployment. In the pharmaceutical domain, Renushe et al. (2025) proposed a QR-based drug verification system that relies on a centralized hub to validate whether a scanned code is genuine or duplicated. Similar centralized architectures are found in commercial traceability systems, although they remain vulnerable to database tampering and public-QR duplication.

Several studies have sought to enhance QR codes with intrinsic anti-counterfeiting features. Wang et al. (2023) introduced QR codes with embedded random textures detectable through Fourier-domain analysis, while Chen J. et al. (2023) embedded watermarks into QR modules to identify copied or reprinted codes. These methods strengthen the QR medium itself but do not prevent replay attacks or mass duplication of public identifiers.

4.2.2 RFID and NFC-based approaches

RFID and NFC technologies have long been explored as reliable solutions for product identification and anti-counterfeiting in supply chains Masekwana and Jokonya (2025). RFID/NFC tags contain a hardware-embedded Unique ID (UID), enabling products to be authenticated through dedicated readers or NFC-enabled smartphones. Their non-line-of-sight scanning capability and resistance to casual duplication make them suitable for high-value goods.

In retail settings, Khalil et al. (2020) proposed a passive RFID–based authentication system that verifies product identity at the point of sale, allowing counterfeit detection during transaction processing. To further enhance security and usability, several hybrid approaches have been introduced. For example, Uwiragiye and Sumbiri (2025) implemented a hybrid RFID–QR model, in which the RFID tag stores secure authentication data while the QR code provides public-facing information for consumers. This division of roles reduces hardware requirements while maintaining robust verification, enabling real-time product checks without imposing additional device constraints on end users. Other studies explored integrating RFID with complementary sensing or traceability mechanisms. Such designs leverage the robustness of RFID as a hardware anchor while using additional data channels to improve usability, scalability, and consumer accessibility.

More recent studies have extended this direction by integrating NFC tags with blockchain for smartphone-based end-to-end product verification Subramaniam et al. (2025), and by combining RFID with optimized cryptographic hashing for agricultural traceability Li et al. (2024). These hybrid hardware–blockchain architectures improve auditability and reduce dependence on centralized backends. However, their reliance on per-unit hardware components remains a significant cost barrier for low-margin agricultural products, while reusable hardware identifiers still do not inherently prevent replay or repeated verification of duplicated identifiers.

4.2.3 Physical anti-counterfeiting labels

Beyond digital encoding methods, physical anti-counterfeiting labels have been widely explored for their ability to embed tamper-resistant features using optical, material, or microstructural properties. Chen H. et al. (2023) developed phosphorescent and quantum-dot–based labels functioning as Physical Unclonable Functions (PUFs), enabling multi-layered authentication using smartphone cameras. Likewise, Nguyen et al. (2024) employed photonic crystals to generate lighting-dependent structural colors, offering both overt and covert indicators difficult to replicate. Although effective, these approaches often require specialized materials or manufacturing processes, increasing cost and limiting scalability for mass deployment.

4.2.4 Blockchain-based approaches

Blockchain has been extensively explored in anti-counterfeiting applications because of its immutability, auditability, and decentralized trust model Kamble et al. (2020). Chen et al. (2022) introduced a consortium-blockchain system for managing luxury goods, in which each product receives a unique on-chain identifier bound to a physical tag. Ownership transfers are handled via smart contracts, and all provenance information is maintained within a permissioned ledger shared among manufacturers and retailers.

Anthony et al. (2023) introduced a decentralized authentication architecture built on Ethereum, in which product verification data and digital signatures are recorded through Ethereum smart contracts while descriptive metadata is stored on IPFS for scalability. The system employs event-triggered smart contracts to automate verification workflows, eliminating reliance on centralized validation servers.

In the agricultural sector, Zhang et al. (2023) developed a Hyperledger Fabric–based traceability framework that integrates IoT sensors to collect origin, environmental, and quality inspection data. All transactions are cryptographically linked in the permissioned ledger, ensuring tamper-resistant provenance throughout production, processing, and distribution stages.

Building on these foundations, recent studies have explored decentralized agri-food architectures that combine Ethereum smart contracts with IPFS to improve off-chain data integrity and traceability Sharma et al. (2025); Vakil et al. (2025). While these frameworks strengthen provenance immutability and stakeholder coordination, they primarily focus on traceability rather than enforcing unit-level single-use authentication on consumer-facing identifiers. Related work in pharmaceutical anti-counterfeiting Aziz et al. (2025) likewise leverages immutable ledger infrastructures to improve authenticity verification, but targets high-margin products that can accommodate higher verification and deployment costs than large-scale agricultural supply chains.

4.2.5 Discussion and research gap

A review of existing anti-counterfeiting research identifies four main approaches: QR-based methods, RFID/NFC systems, physical anti-tampering labels, and more recent blockchain-supported traceability frameworks. Despite their differences, all face notable limitations when applied to low-cost, mass-produced goods such as agricultural products. QR-based approaches primarily rely on static, publicly accessible identifiers, which limits their ability to enforce unit-level authenticity. In contrast, hardware-based solutions embed non-replicable identifiers but incur significantly higher costs, highlighting a gap between deployability and security. Blockchain-based approaches enhance transparency and traceability, yet typically focus on sensor-driven supply-chain monitoring or on-chain provenance management rather than preventing the duplication of consumer-facing identifiers. Recent reviews Huang et al. (2025); Bekkouche and de Magistris (2025); Alar et al. (2026) similarly observe that, despite the growing maturity of individual technology components, practical deployment of low-cost systems supporting unit-level authenticity verification remains limited in agri-traceability environments.

These limitations collectively indicate the need for an authentication mechanism that simultaneously supports low-cost deployment, resistance to identifier duplication and replay, and practical scalability for large-scale agricultural supply chains. This motivates a design that separates public traceability from private unit-level authentication while enabling verifiable single-use validation of concealed product identifiers.

5 Artifact design

Building upon the problem formulation and design requirements defined in Section 3, this section presents the proposed anti-counterfeiting artifact and its underlying authentication protocols. The proposed artifact specifies how dual-QR identifiers are generated, registered, and verified through blockchain-backed state transitions to achieve secure and practical unit-level authentication. Table 1 summarizes the notation introduced in this section and used throughout the proposed artifact. The overall design and core mechanisms are described in the following subsections.

TABLE 1. Notation used in the proposed solution.

5.1 Dual-QR authentication mechanism

At the core of the proposed method is a dual-QR code authentication mechanism that regulates the disclosure and verification of product information. Each agricultural product package is associated with two QR codes, each serving a distinct role across the product lifecycle.

The public QR code is printed on the exterior of the packaging and is shared among all products within the same cultivation project. When scanned, it provides consumers with general information such as product origin, traceability records, and quality certifications, if available. This code serves as a public information channel, enabling transparent access to verified data without exposing unit-level identifiers.

The private QR code is printed on the interior of the packaging and becomes visible only after the product is opened. It functions as a unique identifier for each individual unit, generated by the producer and registered on the blockchain through a dedicated smart contract. Upon the first successful scan, the smart contract records the verification event and marks the identifier as redeemed. Any subsequent scan of the same code triggers an alert, indicating potential duplication or reuse. Invalid or unregistered identifiers are similarly rejected.

This dual-QR design prevents counterfeiters from pre-printing fabricated labels or reusing legitimate ones, since verification depends on the on-chain state of the private identifier. Although counterfeit products cannot be detected prior to purchase, fraudulent items are immediately exposed once the package is opened and the private code is scanned. Moreover, when misuse is detected, the system enables traceability of the associated distribution channel, allowing producers or regulatory authorities to initiate appropriate enforcement actions.

5.2 QR code provisioning and blockchain registration

The provisioning process defines how the public and private QR codes are generated, registered, and managed to ensure both operational efficiency and data integrity across the system.

5.2.1 Public QR code generation

After harvesting and packaging, the producer generates a public QR code for each cultivation project, identified by a unique project identifier ϕ. The public code encodes a URL of the form: [https://ipfs.io/ipfs/[CID]/projects/projectId], where projectId corresponds to the encoding of ϕ in the application layer. The parameter CID (Content Identifier) denotes the immutable IPFS hash of the deployed decentralized application (dApp), ensuring that referenced data and scripts remain tamper-resistant and verifiable through the IPFS network Reddy et al. (2024). The resulting URL provides access to general project information such as production details or quality certifications. The same public QR code is shared by all products within the project, enabling high-level traceability without exposing unit-level identifiers. For efficient management and querying, project metadata and the corresponding public QR code are additionally maintained in an off-chain database.

5.2.2 Private identifier provisioning

Each product unit p i is assigned a unique secret identifier s i d i for unit-level authentication. Given a project ϕ and batch size N, the producer invokes the dApp to locally generate N independent identifiers s i d i ← G e n ( k ) using a cryptographically secure random number generator. The identifiers are retained within the producer’s trusted environment and are never disclosed outside it.

5.2.3 Blockchain registration

To enable on-chain verification, each identifier s i d i is deterministically mapped to a fixed-length digest h i = H ( s i d i ), which serves as the on-chain product reference. Only the hash values h i are submitted to the smart contract S C, ensuring that the original identifiers remain undisclosed under the preimage resistance of H ( ⋅ ).

For each project ϕ, the contract implements the registry R by maintaining two mappings: (i) a project-level mapping ϕ ↦ a d d r P, and (ii) a product-level mapping ( ϕ , h i ) ↦ s t a t u s i. The state variable s t a t u s i ∈ { unused , redeemed } indicates whether a product unit has been previously verified.

The contract enforces (i) uniqueness of project identifiers ϕ and (ii) authorization of the caller via a d d r P prior to accepting new entries, thereby preventing unauthorized insertion or modification of records. Additional batches may be appended to an existing project only if submitted by the same authorized producer.

5.2.4 Private QR code creation

After blockchain registration, the dApp outputs the set of secret identifiers { s i d i } i = 1 N for QR code generation. Each private QR code encodes a URL of the form: [https://ipfs.io/ipfs/[CID]/scan/[projectId]/secretId], where projectId and secretId denote the application-level representations of ϕ and s i d i, respectively. The parameter CID ensures that all verification requests reference the immutable dApp deployment stored on IPFS. The resulting QR codes are printed inside the packaging, such that each product unit is associated with a unique secret identifier revealed only upon package opening. Consequently, successful verification requires knowledge of s i d i, which is not accessible prior to physical access to the product.

The complete registration procedure is presented in Algorithm 1. The process is divided into two phases: local generation and on-chain registration. Specifically, all secret identifiers s i d i and the corresponding QR codes are generated locally within the producer’s environment (lines 7–12).

For each product p i, a hash value h i = H ( s i d i ) is computed and included in a batch set B. Only the hash digests h i are submitted to the blockchain via a single transaction (line 13), while the original s i d i values remain exclusively embedded in the private QR codes. As a result, the system minimizes the risk of identifier leakage and prevents direct reconstruction of s i d i from on-chain data under the preimage resistance assumption of H ( ⋅ ). Batch submission further improves efficiency by aggregating multiple product identifiers into a single blockchain transaction, thereby reducing gas costs and on-chain storage overhead.

Algorithm 1 Product registration.

The function Encode ( ⋅ ) deterministically constructs a URL by combining the IPFS content identifier C I D with a given set of parameters. Specifically, Encode ( C I D , ϕ ) produces a public URL associated with project ϕ, while Encode ( C I D , ϕ , s i d i ) produces a private URL bound to the corresponding product unit p i. The resulting URLs are subsequently rendered as QR codes for user interaction.

From a security perspective, the procedure contributes to requirement DR1 (unforgeability) by relying on cryptographically secure random generation of s i d i and the one-way property of the hash function. Additionally, requirement DR3 (non-repudiation) is supported through the immutable and publicly verifiable transaction that records the registration of ( ϕ , h i ) pairs on-chain.

5.3 QR scanning and verification workflow

The QR scanning and verification workflow specifies how user interactions with public and private QR codes are mapped to on-chain validation and off-chain data retrieval. Public scans provide project-level traceability, whereas private scans trigger unit-level authenticity verification through a state transition recorded on-chain.

5.3.1 Public QR scan

When a consumer scans Q R ϕ pub, the embedded URL redirects to the decentralized application (dApp) hosted on IPFS at [https://ipfs.io/ipfs/[CID]/projects/projectId]. Before returning any data, the dApp performs a read-only query to the smart contract S C to verify that ϕ (i.e., p r o j e c t I d) exists in the on-chain registry R. If the project is registered, the corresponding metadata (e.g., origin, production details, certifications) is retrieved from an off-chain database and presented to the user; otherwise, the request is rejected. This process provides a lightweight consistency check between the application layer and the on-chain registry, ensuring that only valid project identifiers resolve to metadata. As the interaction is read-only, it incurs no transaction fees while still leveraging blockchain state for validation. However, it does not provide unit-level authenticity guarantees, as verification is performed only at the project level.

5.3.2 Private QR scan

After opening the package, the consumer scans the private QR code Q R p i priv, which encodes a URL of the form [https://ipfs.io/ipfs/[CID]/scan/[projectId]/secretId]. This action initiates a unit-level verification request. Upon scanning, the application extracts the secret identifier s i d i (i.e., s e c r e t I d) and forwards it to the intermediary I, which submits a transaction to the smart contract S C by invoking the redeemProduct function with the corresponding project identifier ϕ.

5.3.3 Smart contract logic

Upon invocation, the contract computes h = H ( s i d i ) and checks whether the pair ( ϕ , h ) exists in the on-chain registry R. If no such entry is found, or if the associated state satisfies s t a t u s i = redeemed, the transaction is reverted. Otherwise, the contract updates the state to s t a t u s i = redeemed and emits an event recording the successful verification.

5.3.4 Verification outcome

After transaction confirmation, the dApp presents the verification result to the consumer, including the verification outcome and associated metadata such as the project identifier ϕ and the producer’s wallet address a d d r P. A successful verification corresponds to the outcome AUTHENTIC, indicating that the submitted identifier matches a valid and previously unredeemed product unit. If the transaction is reverted due to the absence of a corresponding entry ( ϕ , h ) in R, the outcome is classified as COUNTERFEIT. If the transaction is reverted due to s t a t u s i = redeemed, the outcome is ALREADY_VERIFIED. Since each identifier s i d i can be redeemed at most once, this mechanism enables reliable detection of duplication and reuse through on-chain state transitions. Verification outcomes are determined solely by on-chain state, enabling independent validation without reliance on the intermediary I.

The public and private verification procedures are formalized in Algorithm 2 and Algorithm 3, respectively. Algorithm 2 performs a read-only query to the smart contract to verify whether the project identifier ϕ has been registered on-chain. If the project exists, the procedure retrieves the associated metadata from an off-chain database; otherwise, it returns a failure indicator. As no state transition is triggered, the verification process incurs no transaction fees. This lightweight check reduces the risk of accepting arbitrary or unregistered project identifiers embedded in public QR codes. However, the procedure only confirms the existence of a project and retrieves its metadata, without providing any guarantee of product-level authenticity.

Algorithm 2 Public QR verification.

Algorithm 3 operates in three phases. Phase 1 (lines 4–11) performs a read-only pre-check against the blockchain state to determine whether the identifier exists and whether it has already been redeemed. This step enables early rejection of invalid or previously used identifiers without incurring transaction fees.

If the identifier is valid and unredeemed, Phase 2 (lines 12–15) submits a redemption transaction via an intermediary I, as end-users are not required to directly interact with the blockchain. Within the smart contract, the hash value is recomputed from the provided s i d i rather than relying on any client-side input, ensuring consistency with the on-chain registry and preventing manipulation of precomputed values. Upon successful execution, the contract marks the corresponding identifier as redeemed, enforcing a one-time verification property.

Algorithm 3 Private QR verification.

Finally, Phase 3 (lines 16–17) returns the verification result together with the associated transaction reference and emitted event data. These artifacts provide publicly verifiable evidence of the verification outcome and can be independently audited.

This algorithm contributes to all four security requirements. Requirement DR1 (unforgeability) is supported by the use of high-entropy secret identifiers s i d i generated via a CSPRNG and the preimage resistance of the hash function H ( ⋅ ), which together make it computationally infeasible to derive a valid identifier from on-chain data h i. Requirement DR2 (one-time verification) is enforced through the atomic state transition in the smart contract, ensuring that each identifier can be redeemed at most once. Requirement DR3 (non-repudiation) is achieved by the immutable transaction and the event emitted upon successful redemption, which publicly record the verification outcome. Finally, requirement DR4 (verifiability) is supported by the transaction reference and event data, which allow consumers to independently verify the on-chain record without relying on the intermediary I for trust.

6 Artifact realization

6.1 Architecture overview

To realize the proposed anti-counterfeiting artifact in a practical deployment setting, the study implements a hybrid architecture that integrates decentralized blockchain infrastructure with centralized coordination services. The resulting implementation operationalizes the authentication protocols defined in Section 5 while balancing security guarantees, scalability, deployment feasibility, and usability requirements. The overall architecture is illustrated in Figure 2.

At the core of the system is the Coordination Hub, which serves as the control layer responsible for orchestrating interactions between off-chain services and on-chain smart contracts. It consists of three modules. The Portal Gateway manages external requests and routes them to appropriate services. The Purchase Transaction Executor signs and submits blockchain transactions for product verification. The Blockchain Data Gateway provides verified read access to on-chain state for validation and auditing.

Built on top of this hub are two application-level portals. The Centralized Product Management Portal enables producers to manage project metadata, including project identifier, product descriptions, and provenance information. This metadata is maintained in a centralized repository and synchronized with blockchain records through the Portal Gateway when required.

The Decentralized QR Generation and Verification Portal, deployed as a decentralized application (dApp) on IPFS, serves both producers and consumers, ensuring tamper-resistant and highly available access without reliance on centralized hosting. Producers use this portal to generate QR codes and initiate registration, while consumers use it to perform product verification. The portal interacts with the Coordination Hub for all operations requiring blockchain access.

Underlying these components, the On-chain Product Registry Contract maintains the registry R and enforces all security-critical operations, including identifier validation and redemption. While the Coordination Hub orchestrates system interactions, all verification outcomes are ultimately determined by the contract.

6.2 Mapping from design to system components

The system architecture concretely realizes the authentication mechanisms and security objectives introduced in Section 3.5 by mapping each protocol component to specific architectural elements and their interactions.

The separation between public and private identifiers is implemented through the coordinated operation of the Decentralized QR Generation and Verification Portal and the On-chain Product Registry Contract. The portal generates public QR codes encoding the project identifier ϕ. Since ϕ must correspond to an existing on-chain project, adversaries cannot fabricate arbitrary public identifiers. For product-level authentication, the portal generates private identifiers s i d i, from which hash values h i = H ( s i d i ) are derived and registered on-chain by the producer. The Product Registry contract subsequently uses these hash values to validate verification requests and enforce single-use semantics. This design enables lightweight validation through public identifiers while preserving strong authenticity guarantees through private identifiers.

Trust independence from the intermediary I is enforced by isolating the Coordination Hub from all verification-critical logic. While the hub manages request routing and transaction submission, it interacts with the blockchain strictly through the Purchase Transaction Executor and the Blockchain Data Gateway. It neither computes identifier hashes nor determines verification outcomes. All validation checks and state transitions are executed within the Product Registry contract, ensuring that a compromised intermediary cannot forge, modify, or suppress authentication results.

Non-replayability is enforced by the on-chain state maintained in the Product Registry contract. Each product record ( ϕ , h i ) is associated with a redemption status that can be updated exactly once upon successful verification. The Purchase Transaction Executor submits verification transactions without the ability to influence this state transition logic, which is executed atomically on-chain. As a result, any subsequent attempts to verify the same identifier are deterministically rejected, thereby preventing reuse.

Cost efficiency is realized through a division of responsibilities between off-chain and on-chain components. The Decentralized QR Generation and Verification Portal performs local generation of identifiers, avoiding unnecessary data transmission. The Centralized Product Management Portal handles metadata storage off-chain, reducing on-chain storage requirements. At the blockchain layer, the Product Registry contract stores only compact hash digests and Boolean states, minimizing storage overhead. Registration transactions are batched by the producer prior to submission, amortizing gas costs across multiple products. This combination minimizes operational overhead without weakening the security guarantees enforced by the contract.

6.3 Smart contract specification

The system logic is enforced by a single smart contract, ProductRegistry, which implements the on-chain registry R referenced in Algorithms 1–3. The contract provides a minimal yet expressive interface for project registration, product authentication, and auditability. The complete Solidity implementation is available in the project repository Pham and Trinh (2026).

6.3.1 Data structures

The contract maintains two primary storage mappings. The first maps each project identifier ϕ to a Project record containing the producer’s wallet address ( a d d r P ) and an existence flag. The second maps each pair ( ϕ , h i ) to a ProductRecord containing an existence flag and a Boolean redemption status. This hierarchical structure ( ϕ → h i → P r o d u c t R e c o r d ) enables independent management of multiple projects while storing only compact Boolean values and 256-bit hash digests, thereby minimizing on-chain storage and gas costs.

6.3.2 Events

To support auditability, the contract emits three event types. ProjectCreated( ϕ , a d d r P ) is emitted upon project registration, establishing an immutable record of project ownership. ProductsRegistered( ϕ , count) records the batch registration of hashed identifiers. ProductRedeemed( ϕ , h i , a d d r P , timestamp) is emitted upon successful product redemption and serves as the immutable, timestamped verification record required by DR3, enabling independent auditing via blockchain explorers.

6.3.3 Contract functions

The contract exposes five functions that correspond directly to the system workflows. The registerProject ( ϕ ) function creates a new project record and binds it to the caller’s blockchain address ( m s g . s e n d e r ), which is recorded as a d d r P. A precondition enforces that ϕ must not already exist, ensuring the uniqueness of project identifiers. Upon successful execution, the function emits a ProjectCreated event.

The registerBatch( ϕ , [ h 1 , … , h n ] ) function records a batch of hashed identifiers for a given project, corresponding to Algorithm 1, Line 13. Access is restricted to the registered producer, i.e., m s g . s e n d e r = a d d r P. Each h i is inserted with an initial state r e d e e m e d = f a l s e, and a precondition ensures that no duplicate identifier exists in R [ ϕ ]. Batch processing amortizes transaction costs across multiple products. Upon completion, a ProductsRegistered event is emitted.

The redeemProduct( ϕ , s i d ) function performs product verification and redemption, corresponding to Algorithm 3, Line 12. The function computes h = H ( s i d ) internally and verifies that a corresponding record exists in R [ ϕ ] with r e d e e m e d = f a l s e. If both conditions are satisfied, the state is atomically updated to r e d e e m e d = t r u e and a ProductRedeemed event is emitted. Otherwise, the transaction reverts. By accepting the raw identifier s i d rather than a pre-computed hash, the contract computes H ( s i d ) during execution and uses it for verification. This prevents the intermediary I from supplying arbitrary identifiers, thereby preserving end-to-end integrity and enforcing trust independence (DR4).

The verifyProduct( ϕ , h ) → ( e x i s t s , r e d e e m e d , a d d r P ) function is a read-only (view) operation that returns the current state of a product record without modifying on-chain state, corresponding to Algorithm 3, line 5. It is used for efficient pre-validation prior to redemption and incurs no gas cost.

The projectExists ( ϕ ) → b o o l function is a read-only (view) operation that checks whether a project is registered, corresponding to Algorithm 2, line 4.

6.3.4 Security enforcement

The contract design directly enforces the security requirements defined in Section 3.3. Unforgeability (DR1) is achieved because redeemProduct computes H ( s i d ) internally using a preimage-resistant hash function, making it computationally infeasible to produce a valid identifier without knowledge of s i d. Non-replayability (DR2) is ensured through the atomic check-and-update of the redemption state, which guarantees that each identifier can be redeemed at most once. Non-repudiation (DR3) is enforced via the ProductRedeemed event, which provides an immutable, timestamped record of successful verification. Trust independence (DR4) is achieved because registration requires producer-signed transactions, verification relies on raw identifiers rather than externally supplied hashes, and all state transitions are executed on-chain beyond the control of the intermediary I.

Through this design, the smart contract functions as the authoritative verification layer for product authenticity, ensuring that verification outcomes remain deterministic, auditable, and resistant to manipulation while maintaining compatibility with large-scale agricultural supply-chain deployments.

7 Artifact evaluation

This section evaluates the proposed anti-counterfeiting artifact through prototype-based implementation analysis, performance measurements, cost analysis, and requirement-oriented evaluation. To assess practical feasibility, a functional prototype of the proposed framework was implemented and deployed in a realistic operational environment integrating blockchain infrastructure, decentralized application services, and off-chain coordination components. The implemented system components are summarized below.

• Blockchain Layer: the On-chain Product Registry Contract was deployed on Polygon ¹ , a public blockchain selected for its low transaction fees and high throughput. It serves as the immutable storage layer for hashed product identifiers and redemption records.
• Coordination Hub: deployed on AWS EC2 t2. medium (2 vCPUs, 4GB RAM, 50GB SSD), this component bridges the portals, blockchain, and database. It implements the Portal Gateway, Purchase Transaction Executor, and Blockchain Data Gateway, coordinating all off-chain and on-chain interactions.
• Decentralized Portal: the Decentralized QR Generation and Verification Portal was implemented as a React-based decentralized application (dApp) and deployed on IPFS. The compiled static build (HTML, CSS, JS) was pinned using the Pinata service to ensure immutability and persistent accessibility Trautwein et al. (2022).
• Centralized Portal: the Centralized Product Management Portal was implemented as a web-based interface for agricultural producers, supporting project registration, certification management, and provenance metadata management. It operates on the same backend infrastructure as the Coordination Hub.

7.1 Evaluation of QR code generation performance

We first evaluated the efficiency of the private QR code generation process. A batch of 100 secretId values was generated and registered on Polygon through the On-chain Product Registry Contract. The total execution time, measured from initiation on the dApp to blockchain confirmation, averaged approximately 5 s. This includes: (1) local generation and hashing of the secretId list ( < 1 s ), and (2) block confirmation ( < 4 s ). These results demonstrate that the system supports near real-time batch registration, which is suitable for industrial packaging processes.

7.2 Evaluation of QR scanning and verification latency

To simulate real-world user interactions, QR scanning experiments were conducted on Android (Pixel 5) and iOS (iPhone 12) devices.

7.2.1 Public QR scan

The total time from scanning to full page display averaged 5 s, including URL resolution (2s) and retrieval of provenance metadata (3s). This latency supports convenient pre-purchase authenticity checks.

7.2.2 Private QR scan

Scanning a valid product required approximately 30 s, primarily due to blockchain transaction confirmation and event retrieval. In contrast, scanning an invalid or previously redeemed QR code completed within 4 s, since no on-chain state update was executed. These results indicate that although blockchain confirmation introduces additional latency, the overall verification time remains acceptable for post-purchase authenticity validation. Table 2 summarizes the measured performance metrics across generation and verification scenarios.

TABLE 2. Performance metrics for identifier generation and QR-based verification.

7.3 Cost evaluation

System costs comprise three categories: infrastructure costs, QR code registration costs, and QR verification costs. A cost-sharing mechanism is further introduced to distribute operational expenses among participating producers.

7.3.1 Infrastructure cost

An AWS EC2 t2.medium instance running the Coordination Hub costs approximately 0.0058 USD per hour ² , equivalent to about 4.2 USD per month under continuous operation. The MongoDB Atlas database operates within the free 512 MB tier, which is sufficient because the system stores only lightweight metadata rather than full product histories or media content. For larger deployments exceeding the free storage limit, the MongoDB Atlas Flex plan ³ , priced at approximately 0.011 USD per hour, can be adopted without architectural modification. Consequently, total infrastructure costs remain below 5 USD per month for the current configuration and scale linearly with storage requirements, independent of the number of participating producers.

7.3.2 QR code registration cost

Hashed product identifiers are recorded on-chain in batches of 100 per transaction to reduce gas consumption. Given an average Polygon transaction fee of approximately 0.001 USD per transaction ⁴ , registering 100,000 products per year requires around 1,000 transactions, resulting in an estimated annual cost of roughly 1 USD.

7.3.3 QR verification cost

Only the first scan of each private QR code triggers a blockchain transaction, executed by the system’s wallet to avoid any cost to consumers. At an average Polygon fee of approximately 0.001 USD per transaction, verifying 100,000 products annually results in a total cost of roughly 100 USD, fully covered by the system operator.

7.3.4 Cost-sharing mechanism

Producers pay an annual participation fee proportional to production volume (e.g., 500 USD for 100,000 products) to cover shared infrastructure costs and the on-chain transaction fees associated with QR code registration and verification. Table 3 summarizes the annual cost distribution across cost categories and responsible stakeholders.

TABLE 3. Annual cost distribution by category and responsible stakeholder (100,000 products per producer).

In total, a medium-scale producer handling 100,000 products pays approximately 501 USD annually, comprising a 500 USD participation fee and about 1 USD in QR registration transaction fees. Each product triggers at most one verification transaction at 0.001 USD. For 100,000 products, this corresponds to approximately 100 USD in annual verification transaction costs (100,000 × 0.001 USD). These verification costs are fully borne by the system operator rather than individual producers. Core infrastructure expenses remain below 5 USD per month, or roughly 60 USD annually.

Assuming ten such producers participate, total annual verification costs amount to approximately 1,000 USD, while participation fees generate about 5,000 USD. Even after accounting for infrastructure expenses, the system maintains a positive margin, ensuring financial sustainability while preserving transparency, auditability, and large-scale deployability in agricultural supply chains.

7.4 Evaluation against requirements

This subsection evaluates the extent to which the proposed artifact satisfies the design requirements defined in Section 3.5. The evaluation combines analytical reasoning derived from the protocol and architectural design with empirical observations obtained from the implemented prototype.

7.4.1 Security-oriented requirements (DR1–DR4)

The evaluation indicates that the proposed artifact satisfies the four security-oriented requirements (DR1–DR4) through the combined use of dual-QR identifiers and blockchain-backed verification.

7.4.2 DR1 (unforgeability)

Each product is associated with a private identifier s i d i, whose hash h i = H ( s i d i ) is recorded on-chain. Since the smart contract derives hash values internally using a preimage-resistant function H, forging a valid identifier that passes verification is computationally infeasible.

7.4.3 DR2 (non-replayability)

The contract enforces an atomic state transition from unredeemed to redeemed upon the first successful verification of a product. Subsequent attempts are deterministically rejected, ensuring that each identifier can be verified at most once.

7.4.4 DR3 (non-repudiation)

Each successful verification produces an immutable, timestamped ProductRedeemed event on-chain. This event constitutes a publicly auditable record that can be independently verified using the associated transaction hash.

7.4.5 DR4 (trust independence)

Verification correctness is enforced by the on-chain registry, where all validation logic and state transitions are executed within the smart contract. Each verification event is recorded as a blockchain transaction, whose data, timestamps, and emitted events can be independently audited. As a result, no centralized administrator or intermediary can fabricate, modify, or remove verification records.

However, the intermediary I remains involved in request forwarding and transaction submission, and may attempt to delay or censor verification requests. This limitation does not compromise correctness but affects liveness. To mitigate this risk, the verification interface is deployed as a decentralized application (dApp) on IPFS, ensuring that the application code is content-addressed and cannot be altered without detection. Consequently, all verification steps, transaction statuses, and returned results are transparently observable by users. Any inconsistency, delay, or failure to submit a transaction can be immediately detected, making misbehavior by the intermediary evident and accountable.

7.4.6 DR5 – cost-effectiveness and deployability

The system achieves low deployment cost by relying solely on printed QR codes and standard smartphones, without requiring specialized hardware or modifications to existing workflows. Infrastructure costs remain below 5 USD per month, and on-chain transaction fees are minimized through batched registration (Section 7.3). A remaining practical concern is the operational overhead associated with generating, printing, and securely handling private QR codes during packaging, which is not quantified in this evaluation.

7.4.7 DR6 – performance and scalability

Batch registration of 1,000 private identifiers completes in approximately 5 s. This operation is performed offline by producers and is not on the critical path of packaging or distribution processes. In practice, identifier generation and registration can be completed in advance and reused during printing, ensuring that the registration step does not introduce any production bottleneck. Public and private QR scans exhibit latencies of approximately 5 s and 30 s, respectively. These response times are acceptable for typical point-of-sale and post-purchase verification scenarios.

From a system perspective, verification imposes minimal load on backend services. Public scans rely on read-only queries to the blockchain or IPFS, while private scans require the backend only to sign and forward a transaction. Most computation and state management are offloaded to the blockchain network, where validation is distributed across multiple nodes. As a result, the workload introduced by the verification process remains negligible relative to the capacity of modern public networks.

The primary limitation concerns user experience rather than system capacity. Private-code verification requires waiting for blockchain confirmation, and a latency of approximately 30 s may be unsuitable in scenarios requiring rapid or repeated verification.

7.4.8 DR7 – user-oriented accessibility

Consumer interaction is limited to scanning a QR code using a standard mobile device. The scan opens an IPFS-hosted web application without requiring installation or configuration. The interface retrieves relevant on-chain data and presents verification results without requiring user knowledge of blockchain systems. A usability limitation is that private-code verification occurs only after purchase, which may be unintuitive in markets where consumers expect pre-purchase validation.

Overall, the proposed method satisfies the defined requirements by combining formal security guarantees (DR1–DR4) with practical deployability, scalability, and usability. The design is inherently suited to post-sale verification, where concealed identifiers enable strong non-replay guarantees at the cost of pre-sale authentication. Table 4 summarizes the level of satisfaction for each requirement and the associated limitations.

TABLE 4. Summary of security guarantees and requirement satisfaction.

8 Discussion

8.1 Principal findings

This study demonstrates that a dual-QR authentication mechanism anchored to a public blockchain can provide verifiable, non-replayable product identity while maintaining low operational cost and deployment complexity. By binding product redemption states to immutable on-chain records, the system achieves cryptographic trust minimization without requiring specialized hardware, relying solely on printed QR codes and standard consumer smartphones.

Performance evaluation shows that batch identifier registration completes within seconds, ensuring compatibility with industrial packaging workflows. Public QR verification supports near real-time authenticity checks prior to purchase, while private-code redemption–although subject to blockchain confirmation latency–remains operationally acceptable for post-purchase validation. These results indicate that decentralized state enforcement can be practically integrated into consumer-facing anti-counterfeiting systems at industrial scale.

8.2 Relation to prior work

Anti-counterfeiting approaches can be broadly categorized into three directions: (i) QR-based systems with centralized backends, (ii) hardware-assisted authentication using RFID/NFC, and (iii) blockchain-based traceability frameworks. While each direction addresses specific aspects of the problem, none simultaneously achieves low-cost deployment, unit-level authenticity, and trust-independent verification in a broadly deployable manner. Table 5 summarizes this landscape by comparing representative approaches with respect to the defined design requirements (DR1–DR7).

TABLE 5. Comparative analysis of anti-counterfeiting approaches.

QR-based authentication systems: Renushe et al. (2025).

RFID/NFC-based authentication systems: Khalil et al. (2020); Li et al. (2024); Uwiragiye and Sumbiri (2025); Subramaniam et al. (2025).

Public blockchain-based authentication and traceability systems: Anthony et al. (2023); Patel et al. (2025); Vakil et al. (2025); Aziz et al. (2025).

Permissioned blockchain-based traceability frameworks: Zhang et al. (2023); Sharma et al. (2025).

Provides provenance traceability but does not prevent identifier duplication or replay.

Supports provenance lookup only without unit-level authenticity enforcement.

QR-based systems represent the most cost-efficient and accessible class of solutions. They incur near-zero per-unit cost and achieve sub-second verification latency, making them highly suitable for large-scale deployment (DR5–DR7). However, these advantages come at the expense of weak security guarantees. Because identifiers are publicly visible and reusable, QR-based systems do not provide unforgeability (DR1) or non-replayability (DR2): a copied identifier can be reused indefinitely while producing identical verification outcomes. Furthermore, reliance on centralized databases introduces a trust dependency on backend infrastructure, violating trust independence (DR4) and enabling potential database tampering or administrative collusion. While basic logging mechanisms may provide limited auditability, they do not achieve the immutable and publicly verifiable records required for non-repudiation (DR3). Consequently, QR-based systems occupy an extreme point in the design space: they maximize cost-efficiency and accessibility, but fail to provide meaningful protection against identifier duplication.

Hardware-assisted approaches, such as RFID and NFC, strengthen the binding between physical products and digital identifiers. By embedding unique identifiers within tags, these systems provide stronger resistance to cloning than printed codes and enable pre-sale authentication, partially addressing unforgeability (DR1). However, this improvement comes at a practical cost: RFID/NFC solutions introduce non-negligible per-unit cost and require dedicated readers and supporting infrastructure, limiting scalability in cost-sensitive environments (DR5, DR7). Moreover, while hardware identifiers are harder to replicate, they remain reusable and do not enforce non-replayability (DR2), as the system cannot distinguish between first use and subsequent reuse. Similar to QR-based systems, most deployments rely on centralized backends, thereby inheriting trust dependencies and lacking strong guarantees of trust independence (DR4). As a result, RFID/NFC approaches improve physical authenticity and enable early-stage verification, but still fall short of providing system-level protection against identifier reuse.

Blockchain-based approaches address trust and auditability by recording product provenance and ownership on immutable ledgers. Public blockchain systems Anthony et al. (2023) enable decentralized verification and transparent traceability. Subsequent blockchain-based authentication and traceability frameworks have extended this direction to luxury goods, agricultural supply chains, pharmaceutical systems, and NFC-enabled applications Patel et al. (2025); Vakil et al. (2025); Aziz et al. (2025); Subramaniam et al. (2025). In parallel, permissioned frameworks Zhang et al. (2023), including recent private-Ethereum agri-food architectures Sharma et al. (2025), support structured data sharing within a consortium of trusted participants. These designs provide strong guarantees of non-repudiation (DR3) and trust independence (DR4) through tamper-resistant, distributed records. However, their functionality remains centered on provenance tracking, where verification consists of querying a publicly accessible identifier and retrieving its associated history. Because the identifier can be read and reused without restriction, duplicating it does not change the verification outcome: both genuine and counterfeit products return identical provenance records. Thus, while blockchain ensures the integrity of recorded data, it does not enforce authenticity at the unit level. Unforgeability (DR1) and non-replayability (DR2) are therefore not achieved unless additional mechanisms are introduced.

From a practical perspective, public blockchain platforms introduce non-negligible verification latency and transaction costs due to consensus mechanisms, whereas permissioned frameworks reduce latency but require consortium setup and coordination. This trade-off highlights that blockchain improves trust and auditability, but does not by itself resolve the tension between security, cost, and deployability.

8.2.1 Key limitation

Across all three directions, a common limitation emerges: authentication relies on identifiers that are either publicly visible or reusable. This design prevents the system from distinguishing between legitimate first use and subsequent malicious reuse, making large-scale duplication fundamentally difficult to detect.

8.2.2 Position of this work

The proposed system addresses this limitation by separating public traceability from private authentication. A concealed, single-use identifier is assigned to each product unit and can be redeemed exactly once through an on-chain state transition. Unlike prior approaches that permit unlimited queries against the same identifier, this design enforces one-time verification, enabling explicit detection of duplication while preserving the low-cost and accessibility advantages of QR-based systems. This approach achieves full coverage of the defined security requirements (DR1–DR4) without requiring specialized hardware or consortium trust assumptions, at the cost of higher verification latency and the inability to support pre-sale unit-level authentication.

To further position the proposed artifact against recent blockchain-based anti-counterfeiting systems, we compare it with representative 2024–2025 frameworks spanning Ethereum–IPFS agri-food traceability Sharma et al. (2025), RFID-enabled agricultural provenance tracking Li et al. (2024), NFC-integrated authentication platforms Subramaniam et al. (2025), and pharmaceutical anti-counterfeiting infrastructures Aziz et al. (2025). The first two systems primarily rely on publicly accessible or reusable identifiers, leaving duplication and replay attacks insufficiently addressed at the unit level. The NFC-integrated framework improves physical–digital binding through hardware-assisted authentication but incurs higher per-unit deployment cost and remains dependent on reusable tags. The pharmaceutical-oriented framework tolerates higher verification overhead due to the high-margin nature of the domain, limiting its applicability to large-scale agricultural products.

In contrast, the proposed dual-QR authentication artifact separates public traceability from concealed single-use authentication, enabling one-time verification semantics on low-cost printed identifiers without specialized hardware. Consequently, the design simultaneously achieves anti-replay protection (DR2) and trust independence (DR4) while preserving practical deployability for low-margin agricultural environments. This comparison highlights that the contribution lies not in the isolated adoption of blockchain or IPFS, which are already common in recent traceability frameworks Sharma et al. (2025); Vakil et al. (2025), but in the artifact-level integration of concealed unit-level authentication with blockchain-backed state transitions for replay-resistant verification.

8.3 Industrial relevance and scalability

From an industrial standpoint, the proposed architecture enables large-scale product authentication without specialized hardware or significant modification to existing production lines. QR codes remain inexpensive to generate and print, and verification requires only standard smartphones, supporting practical deployability.

Scalability is primarily constrained by blockchain confirmation latency rather than backend server throughput. Because redemption states are enforced on-chain, centralized performance bottlenecks are minimized. As public blockchain infrastructures continue to improve in throughput, finality, and fee stability, verification latency may decrease without architectural redesign, supporting long-term scalability. Recent reviews of digital traceability systems in agri-food supply chains Huang et al. (2025); Vasileiou et al. (2025) likewise report increasing maturity of blockchain infrastructures and supporting ecosystems, suggesting continued improvements in suitability for high-volume verification workloads.

8.4 Limitations

Despite its advantages, the proposed method has several limitations that merit discussion.

8.4.1 Design limitations

The system enforces strong non-replay guarantees through single-use redemption semantics; however, these guarantees are only activated once the private QR code is revealed. Consequently, the framework does not support pre-sale unit-level authentication and cannot prevent scenarios in which the concealed identifier is exposed prior to purchase. This trade-off arises directly from the design choice of separating public traceability from private authentication.

8.4.2 System-level constraints

Private verification latency depends on blockchain confirmation time and prevailing network conditions, including congestion and fee variability. As a result, response time is inherently less predictable than in centralized systems and may vary across deployments. While this variability does not affect the correctness of verification, it introduces uncertainty in user experience that cannot be fully mitigated at the application layer.

8.4.3 Deployment considerations

Practical deployment requires secure handling of concealed identifiers throughout the production pipeline, including printing, packaging, and distribution. These processes introduce operational assumptions—such as protection against insider leakage and physical tampering—that are not explicitly modeled or evaluated in this work, but may influence real-world robustness.

8.4.4 Evaluation limitations

The experimental results reported in this study are based on a limited number of trials under typical network conditions. The evaluation does not include statistical confidence intervals, stress testing under high concurrency, or systematic adversarial experimentation. Although the security properties (DR1–DR4) are enforced at the protocol level, the absence of large-scale empirical validation limits the generalizability of the reported performance metrics.

8.5 Design rationale and architectural trade-offs

8.5.1 Post-purchase authentication model

The proposed framework deliberately adopts a post-purchase authentication model in which strong anti-counterfeiting protection becomes available only after the concealed private QR code is revealed. Consequently, the system does not provide pre-sale authentication and cannot fully prevent counterfeit products from entering circulation before consumer purchase. This limitation results from the architectural separation of public traceability and private authentication, which prioritizes secure one-time verification over pre-sale counterfeit prevention.

This design choice reflects a practical design trade-off rather than a purely technical constraint. By deferring private authentication until package opening, the framework achieves low deployment cost, compatibility with existing agricultural packaging workflows, and scalability for large-volume, low-margin supply chains, while avoiding reliance on specialized hardware such as RFID or NFC. These properties are particularly important in agricultural contexts, where affordability and operational simplicity are often key drivers of real-world adoption, outweighing the benefits of stronger but more resource-intensive security mechanisms.

The system does not function solely as a passive post-purchase verification mechanism. Although counterfeit products may still enter circulation before purchase, the framework provides meaningful value by enabling immediate detection of fraud at the point of product opening. This occurs when the concealed private QR code is either absent from the on-chain registry or has already been marked as redeemed in a prior verification event. This mechanism enables end-to-end traceability of counterfeit incidents, allowing producers to identify compromised supply routes, regulatory authorities to investigate fraudulent distribution networks, and sellers to be held accountable based on verifiable evidence, while also supporting consumer complaint mechanisms grounded in auditable records. Consequently, post-purchase verification extends beyond individual consumer protection and contributes to broader supply-chain transparency, accountability, and enforcement.

8.5.2 Hybrid trust architecture

The framework intentionally adopts a hybrid trust architecture that combines decentralized security enforcement with centralized operational support. The centralized coordination layer primarily serves as an intermediary that connects verification applications to the blockchain, handling transaction submission and blockchain data retrieval on behalf of users. This design removes the need for end users to directly manage blockchain wallets, sign transactions, or interact with smart contracts, thereby substantially improving usability, accessibility, and practical deployability. By abstracting blockchain complexity while preserving blockchain-enforced verification integrity, the system reduces technical barriers and improves adoption feasibility in large-scale agricultural supply chains.

However, this intermediary does not control core authentication processes. Product records, verification outcomes, and state transitions are enforced directly by blockchain smart contracts, preventing unauthorized alteration or falsification. Consequently, product authenticity and verification results remain secured by blockchain execution rather than intermediary trust.

Decentralization is further reinforced at the application layer through IPFS deployment of the verification dApp. By hosting QR scanning and verification applications on content-addressable decentralized storage, the system preserves application integrity, reduces reliance on centralized hosting infrastructure, and increases resistance to censorship or unauthorized interface modification. This deployment model improves transparency for end users while minimizing intermediary influence over verification interfaces.

In addition, blockchain transaction hashes and smart contract event logs provide immutable, independently verifiable records for every authentication event. These records strengthen accountability by enabling consumers to confirm verification outcomes, producers to trace misuse, and regulatory authorities to audit product histories and investigate fraudulent activity. Accordingly, although the system does not achieve full trustlessness, it operates as a trust-minimized hybrid architecture in which blockchain and decentralized storage preserve core security guarantees, while centralized components primarily enhance operational efficiency and accessibility.

Overall, these design decisions reflect an intentional balance between security, practicality, and economic feasibility. Although they introduce limitations in pre-sale counterfeit interception and full decentralization, they substantially improve scalability, affordability, and real-world adoption potential. In agricultural supply chains, such trade-offs enhance implementation feasibility while preserving robust counterfeit detection, misuse traceability, and regulatory accountability.

8.6 Future research directions

Future research can extend the proposed framework by addressing the limitations identified in this work along technical, empirical, and system-integration dimensions.

8.6.1 Latency and verification efficiency

Given the dependence of private verification on blockchain confirmation, an important direction is the design of latency-aware verification mechanisms. Approaches such as hybrid confirmation schemes, optimistic redemption models, or integration with layer-2 infrastructures could reduce perceived waiting time while preserving security guarantees. A key research challenge is to quantify the trade-off between responsiveness and the risk of premature acceptance under delayed finality.

8.6.2 Scalability and empirical validation

The current evaluation is limited to small-scale experiments under typical network conditions. Future work should conduct large-scale and statistically rigorous studies, including high-concurrency stress testing and repeated measurements with confidence intervals. Such evaluations would enable a more precise characterization of throughput, latency variability, and cost under realistic workloads.

8.6.3 Adversarial and implementation-level assurance

Although the protocol enforces security properties by design, formal verification of the smart contract implementation and systematic adversarial testing remain essential. Techniques such as symbolic execution, model checking, or fuzz testing could be applied to validate correctness under edge cases and adversarial inputs.

8.6.4 Secure deployment and operational robustness

The framework assumes secure handling of concealed identifiers during production and distribution. Future research should investigate mechanisms to mitigate insider threats and physical leakage, such as tamper-evident packaging, secure printing pipelines, or audit mechanisms for identifier lifecycle management.

8.6.5 System integration and interoperability

Finally, extending the framework toward integration with existing supply-chain systems and exploring interoperability across platforms may improve practical adoption. This includes studying how authentication data can be linked with enterprise resource planning systems or shared across multiple stakeholders without introducing new trust dependencies.

9 Conclusion

This study presented a dual-QR authentication artifact for low-cost anti-counterfeiting in agricultural supply chains, combining a concealed unit-level identifier with a public project-level code, supported by an on-chain registry and lightweight off-chain metadata storage. The proposed design addresses fundamental weaknesses of traditional QR-based anti-counterfeiting systems by preventing identifier reuse, minimizing reliance on centralized trust, and avoiding the cost overhead of hardware-dependent solutions. The resulting artifact provides a practical design blueprint for blockchain-enabled unit-level authentication in large-scale, low-margin deployment environments.

Evaluation of the implemented prototype demonstrates that the proposed artifact achieves low-latency code generation, practical verification times, and negligible operational cost. The dual-QR design enables robust post-sale authentication while maintaining scalability across large product volumes and compatibility with low-cost packaging and standard mobile devices, making it suitable for real-world agricultural deployment.

Despite these advantages, the concealed-code design inherently prevents pre-purchase unit-level verification and introduces additional operational overhead in safeguarding private identifiers during packaging. Future work will investigate strategies to mitigate these limitations, including integration with tamper-evident packaging, comprehensive field testing in real supply-chain environments, and extension of the mechanism to broader consumer-goods sectors.

Generative AI statement

The author(s) declared that generative AI was used in the creation of this manuscript. Generative AI was used to assist with language editing and structural refinement of the manuscript. The authors take full responsibility for the content of the manuscript and have verified its accuracy and originality.

Any alternative text (alt text) provided alongside figures in this article has been generated by Frontiers with the support of artificial intelligence and reasonable efforts have been made to ensure accuracy, including review by the authors wherever possible. If you identify any issues, please contact us.

Publisher’s note

All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.

Footnotes

Edited by: Akm Bahalul Haque, Åbo Akademi University, Finland

Reviewed by: Muhammad Shoaib Farooq, University of Engineering and Technology, Pakistan

Maruf Farhan, University of Sussex, United Kingdom

Footnotes

https://polygon.technology/

https://aws.amazon.com/ec2/instance-types/t2

https://www.mongodb.com/pricing

https://polygon.technology/