NFT-based product authenticity verification system

A physical product with a "blockchain-verified" QR code is marketing, not security. The real problem is that NFT stores a link to something, but not the thing itself. Forging a physical item and pasting the QR code from the original onto a copy is trivial if the system does not solve the cryptographic binding of the physical object to the digital token. We develop such systems turnkey — with NFC chips, on-chain registry, and gasless verification. We have 5+ years of experience in blockchain development and over 20 projects in NFT verification. NFC chips with ECC are 1000 times more reliable than simple QR codes without cryptography.

How to ensure cryptographic binding of a physical object to an NFT?

NFC chips with cryptography

The most reliable approach for physical goods is NFC chips with ECC signature support (NTAG 424 DNA from NXP or similar Kong Halo). The chip contains a private key that cannot be physically extracted from the device. When scanned, the chip signs a challenge-response with the private key.

Verification scheme:

1. During production, the chip generates a keypair. The public key is written into the NFT metadata and into the verification contract.
2. For verification, the user scans NFC → chip signs keccak256(randomChallenge || timestamp) → signature is sent to the backend or directly to the contract.
3. The contract verifies the signature via ecrecover — if recovered_address == chip_public_key and chip_public_key is registered as belonging to a specific tokenId — the product is genuine.

function verifyChip( uint256 tokenId, bytes32 challenge, bytes memory signature ) external view returns (bool) { address chipAddress = _chipAddresses[tokenId]; require(chipAddress != address(0), "Token not registered"); bytes32 messageHash = keccak256( abi.encodePacked("\x19Ethereum Signed Message:\n32", challenge) ); address recovered = ECDSA.recover(messageHash, signature); return recovered == chipAddress; } 

The Kong protocol (ERC-7015 / Kong Halo) standardizes this exact scheme. For luxury goods, watches, sneakers — this is a production-ready solution.

QR code without physical cryptography

If NFC is not suitable (paper documents, packaging), a different scheme is used. The manufacturer creates a pair (publicId, secretKey) — publicId is embedded in the QR code and stored in the NFT, secretKey is printed inside the packaging under a protective layer. During verification, the user opens the packaging, enters the secretKey — the backend checks that keccak256(secretKey) == storedHash.

This is a one-time scheme: after the first verification, the secret is exposed. For repeated verifications, another mechanism is needed. Suitable for collectibles, alcohol, pharmaceuticals.

Why is an on-chain authenticity registry important?

Contract structure

The registry stores a mapping tokenId → AuthRecord:

struct AuthRecord { address chipAddress; // public key of the NFC chip or zero address bytes32 secretHash; // keccak256 of the secret for QR scheme uint256 mintedAt; // timestamp of creation uint256 verificationCount; // how many times verified bool activated; // whether activated (for one-time) string productSku; // manufacturer SKU } mapping(uint256 => AuthRecord) private _authRecords; 

verificationCount — useful analytics. A product verified 500 times is either very popular or someone is trying to brute force. Threshold alert on the backend for anomalous verification counts.

Lifecycle statuses

For more complex scenarios, a status is added:

Transfer history is transparent via standard ERC-721 Transfer events — no separate storage needed.

How to implement gasless verification for the user?

Verification should not require gas from the user — that's a barrier to adoption. Two approaches:

Off-chain with on-chain proof. The backend makes an eth_call to the verification contract (free), returns the result to the user. The source of truth is the blockchain, but no gas is paid.

Gasless verification via signature. The user signs a verification request (EIP-712), the backend checks the chip signature and the user signature, records the verification event in an off-chain log (with cryptographic proof). For critical verifications (insurance, legal) — periodic on-chain recording of a Merkle root from batch verifications.

Integration with marketplaces and access roles

Standard ERC-721 + additional metadata. In tokenURI JSON, add fields:

{ "name": "Product #12345", "attributes": [ {"trait_type": "Authenticity", "value": "Verified"}, {"trait_type": "Manufacturer", "value": "Brand XYZ"}, {"trait_type": "SKU", "value": "PROD-001"}, {"trait_type": "Chip Type", "value": "NXP NTAG 424 DNA"} ], "verification_contract": "0x...", "chip_public_key": "0x..." } 

OpenSea and other marketplaces display these attributes. A buyer on the secondary market can verify the product before purchase.

The contract uses OpenZeppelin AccessControl:

• MANUFACTURER_ROLE — right to mint new tokens and register chips
• VERIFIER_ROLE — right to record verification results on-chain (for enterprise clients)
• FLAGGING_ROLE — right to mark tokens as disputed (brand anti-counterfeit service)
• DEFAULT_ADMIN_ROLE — role management

The manufacturer can delegate to authorized distributors the right to register products in their segment.

What is included in the work

Estimated timelines and cost

System with QR codes and on-chain registry without NFC — from 1 week. With NFC chip support (Kong/NTAG 424 DNA), role model, mobile SDK for scanning, and analytics dashboard — from 2 to 3 weeks. The cost is calculated individually based on the scope of work.

Contact us to discuss your project. Order development of a verification system — get a consultation on architecture and timelines.