Blockchain from farm to fork: can it strengthen halal traceability?

Blockchain is one way to maintain a shared history that is difficult to alter unnoticed. NIST describes its central qualities as tamper evidence and tamper resistance, not a guarantee that every recorded statement is true. That distinction matters especially when the record concerns something physical that the computer cannot inspect. NIST blockchain overview

Follow the batch, not the marketing story

Consider an illustrative batch of packaged chicken curry. This is a design example, not a description of a particular company or RUKN service. A useful record would need to connect the chicken, other ingredients, processing steps and final packs. “Made at this factory” is much less informative than a history identifying which ingredient lots entered which production batch.

The farm or initial supplier would record the relevant source identifiers. The processor would record receipt and processing. Ingredient suppliers would supply their own lot information. The manufacturer would connect those inputs to the finished batch; the packer would link packs to cases or pallets; distributors and retailers would record the movements relevant to their responsibilities. Each link in that history should describe an actual transaction involving the goods, rather than simply repeat a general account of their origin.

GS1 distinguishes identification of a product type, a batch and an individual item. A product identifier alone cannot distinguish two batches of the same curry. GS1’s traceability standard also requires the relationship between inputs and outputs to be recorded when products are transformed. This is the essential connection when chicken, sauce and spices become a new finished food. GS1 Global Traceability Standard, sections 2.2, 4.1.1 and 5.4

The practical question at each handover is therefore precise: which goods were received, from whom, when, and which later goods contain or correspond to them? A missing ingredient link cannot be repaired merely by recording the finished package on a more sophisticated ledger.

What a shared ledger adds

Once those batch links are defined, consider how the records will be maintained. In a blockchain network, participating computers maintain copies of a ledger, or shared record, and apply agreed rules to new entries. Cryptographic links make changes to earlier records detectable. A permissioned network requires authorisation to publish blocks. Its rules may also restrict who can submit transactions or read records; those permissions must be specified rather than assumed. NIST technology overview, section 2.2

For the curry example, a proposed system might let suppliers submit dispatches, manufacturers submit production events and a certifier authenticate its own certification statements. A retailer would not thereby acquire authority to issue a halal certificate. Nor should every supplier necessarily see competitors’ prices or commercially sensitive recipes. These decisions about responsibility and access form the system’s governance; they are not settled simply by choosing blockchain.

Alongside clear responsibilities, a common way to describe events helps these systems exchange information. GS1’s EPCIS standard supports event information about products, locations, movements and custody. Version 2.0 supports sensor information and certification details. EPCIS is a data-sharing standard, not a requirement to buy a particular blockchain platform. GS1 EPCIS standard, version 2.0

Before choosing the ledger, a food business should establish whether partners can consistently identify the same batch and describe the same event. Otherwise, several businesses may share a technically secure record while misunderstanding what its entries mean.

The difficult link between the package and its record

A barcode identifies what a label says. It does not independently establish that the contents were never substituted. A temperature sensor records conditions at its location; interpreting that reading still requires knowing where the sensor was, whether it worked correctly and which goods it accompanied. These examples show the difficulty of establishing that a digital record accurately describes the physical goods it accompanies.

NIST explicitly warns that a blockchain may receive human or sensor data without being able to determine whether it reflects real events. This is often discussed as the oracle problem: the ledger depends on information arriving from outside itself. NISTIR 8202, section 7.3, page 36

For a proposed halal traceability scheme, useful questions include who applies labels, how quantities are reconciled, what happens when containers are opened and how discrepancies are investigated. Inspections, supplier checks and appropriate testing remain separate sources of evidence. MUIS, for example, may require a laboratory analysis report under its Product / Whole Plant certification conditions, including at an initial audit, periodic inspection or renewal audit. A stored declaration is not a replacement when that report is required. MUIS conditions, version 4.2, clause 3.8

Three documented examples, with their limits

Walmart’s mango experiment

Walmart’s 2018 responsibility reporting described a comparison involving sliced mangoes. Its conventional trace took six days, eighteen hours and twenty-six minutes; a blockchain-supported trace returned an origin in 2.2 seconds. This is a company-reported pilot result, not an independently established reduction in illness, fraud or recall costs. It shows the potential of readily accessible digital traceability information, not that all of the improvement was uniquely attributable to blockchain. Walmart 2018 report summary, page 39

Walmart subsequently set supplier requirements for leafy-greens traceability using IBM Food Trust, with staged deadlines in 2019. That letter documents a procurement requirement and intended rollout. It should not be read as proof that every supplier completed every stage, or as evidence of today’s deployment status. Neither example is a halal-certification project. Walmart supplier letter, September 2018

The UK’s cattle-inspection pilot

The Food Standards Agency’s retrospective describes a cattle-inspection project using Hyperledger Fabric. Animal-condition information was associated with unique ear-tag numbers. Importantly, the project did not capture haulier or retail information. It was therefore not a demonstrated complete journey to a shopper’s basket. The report discusses benefits from standards and permissioned access, alongside unresolved challenges in organisation and interoperability, or the ability of systems to exchange and use information. FSA, insights and learnings, pages 10 and 13–15

This example is particularly useful because its limits are visible. Inspection findings can become easier to share without the system covering every movement of the meat. The project was not presented as halal certification, and its animal-health records cannot be repurposed as such.

WWF’s Fiji tuna pilot

WWF documents a 2018 pilot involving tuna caught in a Fijian longline fishery. Participants included WWF organisations, ConsenSys, TraSeable and fishing and processing company Sea Quest Fiji. The project concerned seafood traceability and included a report on implementation and lessons. It is evidence of a real pilot, not proof of a universal commercial service or a halal guarantee. WWF-New Zealand, Blockchain Tuna Project 2018

Together, these examples show several possible uses: retrieving origin records, sharing inspection information and following seafood. None allows the conclusion that putting food records on a blockchain establishes religious compliance.

Certification needs its own verification

A traceability page should identify the certifier, the covered product or premises and the relevant validity period. A genuine certificate for one establishment is not evidence for every product sharing its brand name. MUIS’s consumer guidance, for example, asks readers to check that an outlet’s certificate is current and matches its name and location. Its separate product directory supports a different verification task. MUIS outlet verification guidance, MUIS product directory

For a digital scheme, ask how a suspension, replacement or withdrawal becomes visible. Preserving an old certificate entry is useful historical evidence, but displaying it without current status can mislead. A sensible design preserves the audit trail while clearly distinguishing superseded information from an active claim. That is an evaluation recommendation, not a claim that every platform already does it.

If a package’s digital page leaves those basics unclear, use the certifier’s own verification route. Our guide to checking a halal certificate and logo explains that consumer task separately.

When is an ordinary database enough?

With the record-keeping and certification requirements clear, ask the supplier to compare the proposed blockchain with an authenticated database using access controls, audit history and shared standards. What problem does distributing the ledger solve? Who operates it? What happens when a participant leaves? Can records be exported and understood elsewhere? How are mistakes corrected and disputed claims resolved?

The FSA’s lessons emphasise governance, data definitions, permissions and interoperability rather than treating ledger technology as the whole solution. Its discussion of follow-on work explicitly accommodates both blockchains and conventional databases. FSA, insights and learnings, pages 14–17

For shoppers, the standard should be straightforward: a scan should reveal relevant, verifiable evidence about the actual product. Blockchain can strengthen the history of those records. The food, the people handling it and the authority certifying it still require their own checks.