Blockchain Product Origin Certification System Development

Development of Blockchain-Based Product Origin Certification System

Classic problem in supply chain: origin certificates are forged, supply chain data is stored in scattered ERP systems of different participants and not verifiable by third parties, and consumer has no way to check that "organic product" is actually organic. Blockchain itself doesn't solve this—data in smart contract is entered by human, and if human enters wrong data, blockchain only guarantees its immutability, not truthfulness. Correct architecture is understanding where blockchain actually helps and where it doesn't.

Architectural Solutions

Network Choice

For supply chain systems with corporate participants two classes fit:

Public networks (Polygon, Avalanche, Base) provide transparency for end consumer. Anyone can verify data via block explorer. Minus—all data is public, which may be unacceptable for B2B data about counterparties and prices.

Permissioned networks (Hyperledger Besu, Quorum, Fabric) provide participant privacy, high performance, fixed validator set. Good for consortium participants. Minus—lose trustless guarantee characteristic of public networks.

Hybrid approach: private network for operational data + anchoring hashes to public blockchain for auditability. Optimal for most enterprise cases.

Product Identifiers

Standard is GS1 EPCIS 2.0 for supply chain events. Each physical object gets unique identifier (EPC—Electronic Product Code), tied to on-chain record:

contract ProductRegistry {
    struct ProductBatch {
        bytes32 batchId;          // hash of GS1 GTIN + lot number + expiry
        address certifiedBy;       // certifying body account
        bytes32 documentHash;      // IPFS CID of documents in bytes32
        uint256 certifiedAt;
        CertificationLevel level;
        bool revoked;
    }
    
    enum CertificationLevel { 
        ORIGIN_DECLARED,    // seller declared origin
        AUDITOR_VERIFIED,   // independent auditor verified
        LAB_TESTED,         // lab analysis confirmed
        CERTIFIED           // full certification passed
    }
    
    mapping(bytes32 => ProductBatch) public batches;
    mapping(bytes32 => bytes32[]) public batchEvents; // chain of events
    
    // only accredited certifiers
    mapping(address => bool) public certifiers;
    
    modifier onlyCertifier() {
        require(certifiers[msg.sender], "Not authorized certifier");
        _;
    }
    
    function certifyBatch(
        bytes32 batchId,
        bytes32 documentHash,
        CertificationLevel level
    ) external onlyCertifier {
        batches[batchId] = ProductBatch({
            batchId: batchId,
            certifiedBy: msg.sender,
            documentHash: documentHash,
            certifiedAt: block.timestamp,
            level: level,
            revoked: false
        });
        emit BatchCertified(batchId, msg.sender, level);
    }
    
    function revokeCertification(bytes32 batchId, string calldata reason) 
        external onlyCertifier 
    {
        require(batches[batchId].certifiedBy == msg.sender, "Not your cert");
        batches[batchId].revoked = true;
        emit CertificationRevoked(batchId, reason);
    }
}

NFT vs. SFT vs. Fungible Token

For certifying batches:

• ERC-721 (NFT) each batch is unique. Good for high-value goods (wine, luxury), where each batch has unique characteristics
• ERC-1155 (Semi-fungible) optimal for most cases: units within batch identical, between batches—no. Allows transferring part of batch
• ERC-20 for bulk/liquid goods without fixed batches (grain, oil)

Chain of Events (Custody Transfer)

Each product movement in supply chain is recorded as event. Events form auditable trail:

contract SupplyChainEvents {
    struct CustodyEvent {
        bytes32 batchId;
        address from;       // previous owner / producer
        address to;         // next owner / distributor
        bytes32 locationHash; // hash of GPS or warehouse address
        bytes32 conditionsHash; // hash of IoT data (temperature, humidity)
        uint256 timestamp;
        EventType eventType;
    }
    
    enum EventType {
        PRODUCED,
        QUALITY_CHECKED,
        PACKAGED,
        SHIPPED,
        CUSTOMS_CLEARED,
        RECEIVED,
        RETAIL_LISTED,
        SOLD
    }
    
    event CustodyTransferred(
        bytes32 indexed batchId,
        address indexed from,
        address indexed to,
        EventType eventType
    );
}

Store raw location and condition data on-chain is expensive. Correct scheme: data → IPFS/Arweave → hash on-chain. Verifier downloads data from IPFS and checks hash matches on-chain record.

IoT Integration

Physical sensors (temperature during transport, humidity in warehouse) are important for food & pharma. Problem: IoT device cannot independently sign Ethereum transactions in resource-constrained conditions.

Architectural solution—oracle pattern:

IoT Device → Edge Gateway → Oracle Service → Smart Contract

Edge Gateway collects device data, aggregates, transmits via secure channel to oracle service (Chainlink, API3, or custom). Oracle records data on-chain with trusted operator signature.

For higher IoT data trust: TEE (Trusted Execution Environment) on edge gateway—Intel SGX or ARM TrustZone. Data signed inside isolated environment, and TEE execution proof can be verified on-chain.

Consumer Verification

QR code on product encodes batchId. Consumer scans QR and sees:

• Certification status (level, body, date)
• Full custody chain from producer to shelf
• Documents (certificates, lab analyses) on IPFS
• Whether certificate was revoked

This is implemented as static site or mobile app reading data directly from blockchain via JSON-RPC or The Graph (for complex queries).

Access Control and Accreditation

Critical component—managing who gets to record certification. Variations:

For regulated industries (organic food, pharma) optimal model is national accreditation bodies managing on-chain list of authorized certifiers. Creates bridge between traditional regulatory system and blockchain.

Economic Incentives

For stakeholder participation:

• Consumers trust on-chain verifiable data
• Producers earn premium for verifiable origin
• Certifiers earn fees for certification services
• Platforms take percentage of producer premium

DAO tokens can govern policy updates—adding new acceptable certifiers, changing standards, etc.

Timeline and Effort

Total: 19–27 weeks. Main unknowns: time to convince industry participants to adopt, regulatory approvals if needed.

Key success factor: achieving critical mass of participants. System only valuable if major certifiers and producers use it.