Hash-anchored quality-control evidence for food-production digital twins: a Solana-based LIMS-compatible framework

Digital twins in food production increasingly support quality monitoring, traceability, and operational decision-making. However, a digital twin can only be as reliable as the quality-control evidence used to update its state. In many food-production settings, laboratory quality information is stored in laboratory information management systems (LIMS), supplier certificates, or external laboratory reports, while blockchain-based food studies mainly focus on supply-chain traceability rather than verified laboratory event integration. This paper proposes a minimal Solana-based hash-anchoring framework that allows food-production digital twins to verify whether LIMS-compatible quality-control evidence is original, modified, or missing before accepting it as batch quality-state evidence. Laboratory data remain off-chain, while Solana stores only event identifiers, cryptographic hashes, and minimal metadata. The framework is evaluated using an anonymized bakery flour quality-control case based on two flour certificates and generated LIMS-like events derived from the same field structure. Experiments evaluate tamper detection, anchoring and verification latency, benchmark repeatability, and digital twin state classification. In the primary 1,000-event local-validator benchmark, Solana per-event anchoring detected 100% of post-validation modifications under a local-store compromise threat model, with mean anchoring latency of 474.7862 ms per event and mean verification latency of 1.5945 ms. A repeat 1,000-event run produced the same order of overhead, with mean anchoring latency of 472.2501 ms and mean verification latency of 1.2591 ms. Local hash and append-only log baselines were faster, but failed to provide external tamper-evident evidence under local reference compromise. Under the evaluated conditions, Solana hash anchoring provides an external integrity layer for verified quality-state updates in food-production digital twins, rather than a performance optimization.

Food production relies on repeated quality-control (QC) decisions: raw materials are accepted, rejected, retested, or routed to production based on laboratory evidence. In bakery production, flour QC values are not only descriptive records. Moisture affects storage stability and water adjustment during dough preparation; gluten quantity and IDK quality describe dough strength and handling behavior; falling number reflects amylase activity; and ash content and whiteness support flour grade and quality classification. These measurements can therefore change the production decision for a batch. They may be stored in a LIMS, entered from external laboratory certificates, or exchanged as supplier documentation. As food-production digital twins become more widely used for process monitoring and quality-state representation, the reliability of the twin increasingly depends on whether the QC evidence behind a batch state still matches the validated laboratory record.

Existing digital twin studies in food production focus on modeling, monitoring, process optimization, shelf-life estimation, quality loss, shelf-life control, and supply-chain representation (Niu et al., 2025; Udugama et al., 2023; Guo et al., 2025; Moreno-Razo et al., 2026; Maheshwari et al., 2023; Sing et al., 2023; Monteiro and Barata, 2025a; Zou et al., 2025; Zhang et al., 2026; Inanlar and Altay, 2026; Kannapinn et al., 2026; Monteiro and Barata, 2025b; Xuan et al., 2026). Blockchain studies in food systems often focus on transparency, traceability, provenance, anti-fraud, or supply-chain integrity (Boller et al., 2024; Duan et al., 2024; Vilas-Boas et al., 2023; Kandasamy et al., 2025; Puthenveettil et al., 2026; Pittaras et al., 2024). LIMS and LIS literature addresses laboratory workflows, sample management, audit trails, instrument integration, and reporting (He et al., 2023; Sun et al., 2021; Edayan et al., 2024; Radovet et al., 2025; Benitez et al., 2025; Kharbach et al., 2026; Charoo et al., 2023). However, these areas are usually treated separately. A methodological gap remains: the digital twin needs a minimal verification mechanism to decide whether a QC event used to update a material or batch state is verified, modified after validation, or missing.

This paper addresses that gap with a minimal framework that links LIMS-like QC evidence to a digital twin through Solana-based hash anchoring. The framework does not replace a LIMS and does not store laboratory measurements on-chain. Instead, it normalizes each QC event, computes a SHA-256 hash, anchors the hash on Solana, and later verifies the current QC payload against the anchored value. The digital twin then updates the batch quality state only after the verification service returns one of three states: verified, modified, or missing.

The article is motivated by a flour quality-control case from bakery production. Two anonymized flour quality documents are used as case evidence: a handwritten laboratory form dated 2026–04–23 and a printed quality certificate dated 2025–08–25. The documents include moisture, gluten, gluten quality, whiteness, falling number, and ash content where available. Larger generated QC event sets are derived from the same field structure to evaluate operational overhead.

The study makes three contributions. First, it defines a minimal LIMS-compatible framework that converts laboratory quality-control evidence into verifiable digital twin events without storing sensitive laboratory data on-chain. Second, it implements per-event hash anchoring and direct event verification using Solana Anchor, with event identifiers and event hashes as the core verification fields. Third, it evaluates tamper detection, anchoring and verification latency, and digital twin state classification using a bakery flour quality-control case.

Related work

Digital twins in food production

Digital twins in food production are commonly used to represent production processes, quality behavior, freshness, shelf-life, supply-chain state, or processing conditions (Niu et al., 2025; Udugama et al., 2023; Guo et al., 2025; Moreno-Razo et al., 2026; Maheshwari et al., 2023; Sing et al., 2023; Monteiro and Barata, 2025a; Zou et al., 2025; Zhang et al., 2026; Inanlar and Altay, 2026; Kannapinn et al., 2026; Monteiro and Barata, 2025b; Xuan et al., 2026). Bakery-specific work has also connected spectroscopy and machine learning with future digital twin integration for breadmaking and quality monitoring (Niu et al., 2025). Related agri-food data-system research has further emphasized optimization, privacy, and distributed learning as important requirements for digital food supply systems (Monteiro and Barata, 2025b; Xuan et al., 2026). More general digital twin studies emphasize data integration, security, scalability, standardization, complex system modeling, and open-source compositional digital twin frameworks as adoption challenges and implementation directions (Zhang et al., 2026; Amirkhanov et al., 2025; Amirkhanova et al., 2025; Amirkhanov et al., 2026; Robles et al., 2023). These studies are important because they show how digital representations can support operational decisions in food systems. However, the quality of a digital twin depends on the trustworthiness of the data used to update it. When laboratory quality records are modified, replaced, or missing, the digital twin may update its state from evidence that no longer corresponds to the validated laboratory result.

Blockchain for food traceability

Blockchain-based food studies usually emphasize provenance, anti-counterfeiting, transparency, traceability, and supply-chain integrity (Boller et al., 2024; Duan et al., 2024; Vilas-Boas et al., 2023; Kandasamy et al., 2025; Puthenveettil et al., 2026; Pittaras et al., 2024). Studies on distributed ledger technologies for food fraud and blockchain-IoT food safety systems show the relevance of tamper-resistant records in food systems, but their primary emphasis is supply-chain transparency rather than LIMS-to-digital-twin state verification (Boller et al., 2024; Duan et al., 2024; Kandasamy et al., 2025; Puthenveettil et al., 2026). Work on DLT convergence with digital twins and IoT in fresh-food logistics is closer to the proposed direction, but still mainly addresses logistics-level integration rather than laboratory QC event acceptance by a digital twin (Vilas-Boas et al., 2023). Broader blockchain literature also highlights the trade-off between decentralized integrity and database-like performance, storage, and query requirements (Kalajdjieski et al., 2023). Secure smart-contract digital twin work supports the general link between blockchain and tamper-evident twin data, but does not address food-production LIMS records as the evidence source (Pittaras et al., 2024). These approaches can make events in a supply chain more auditable, but they often do not focus on validated laboratory records as first-class lifecycle events for digital twins. In addition, storing detailed laboratory data on-chain is undesirable because QC documents can contain supplier, production, laboratory, or commercial information. Prior work on privacy-aware digital twin interaction also reinforces the need to control exposure of sensitive twin-related data (Amirkhanova et al., 2025). A hash-only design is therefore more appropriate for a privacy-preserving integrity layer.

LIMS and laboratory QC workflows

LIMS and LIS platforms manage samples, analysis requests, results, validation workflows, reporting, and laboratory audit trails (He et al., 2023; Sun et al., 2021; Edayan et al., 2024; Radovet et al., 2025; Benitez et al., 2025; Charoo et al., 2023). Open-source electronic laboratory information systems demonstrate the feasibility of large-scale laboratory digitalization, while LIS integration studies highlight the importance of interoperability and systematic validation of laboratory workflows (He et al., 2023; Edayan et al., 2024; Radovet et al., 2025; Benitez et al., 2025). In food quality control, recent work has also identified technological and managerial barriers to digitalizing QC systems (Radovet et al., 2025). Food analysis and quality-control literature further shows that laboratory evidence can be technically complex, multi-instrument, and method-dependent, which reinforces the need to keep detailed results off-chain while anchoring verifiable commitments (Kharbach et al., 2026). Data-integrity studies in regulated laboratory and pharmaceutical contexts also show that auditability and protection against retrospective data manipulation are practical concerns in validated quality workflows (Charoo et al., 2023). An open-source LIMS platform can serve as a reference source for structured laboratory events. However, even when a LIMS records QC data internally, a digital twin still needs a mechanism to verify whether the QC event presented to it later matches the validated version. Local audit trails and append-only logs can help, but they remain within the same administrative boundary.

Research gap

The missing link is a minimal mechanism that connects validated LIMS-like QC evidence to digital twin state updates through external tamper-evident verification. Existing food digital twin and food blockchain studies cover important pieces of this problem, including quality modeling, logistics traceability, food fraud mitigation, and blockchain-enabled auditability (Niu et al., 2025; Udugama et al., 2023; Guo et al., 2025; Moreno-Razo et al., 2026; Maheshwari et al., 2023; Sing et al., 2023; Monteiro and Barata, 2025a; Zou et al., 2025; Zhang et al., 2026; Inanlar and Altay, 2026; Kannapinn et al., 2026; Monteiro and Barata, 2025b; Xuan et al., 2026; Boller et al., 2024; Duan et al., 2024; Vilas-Boas et al., 2023; Kandasamy et al., 2025; Puthenveettil et al., 2026; Pittaras et al., 2024). LIMS studies cover laboratory workflow and data management (He et al., 2023; Sun et al., 2021; Edayan et al., 2024; Radovet et al., 2025; Benitez et al., 2025). What remains underdeveloped is the direct verification step between a laboratory QC event and the state accepted by a digital twin. This work does not claim that blockchain proves the physical truth of a laboratory measurement. Instead, it addresses a narrower and more defensible integrity problem: whether the QC event currently presented to the digital twin matches the version that was previously validated and anchored.

Problem formulation

Let a QC event be a normalized record: e = {

event_id,

batch_id,

product,

quality_results,

decision,

validated_at,

source_document_hash

}

The framework computes: h = SHA-256(normalize(e))

and stores an external anchor: A(event_id) = h

The digital twin later receives a current version of the event, e′, recomputes h′, and queries the anchor by event_id. The verification service returns: verified if A(event_id) exists and h′ = A(event_id)

modified if A(event_id) exists and h′ != A(event_id)

missing if A(event_id) does not exist

The core research question is:

Can Solana-based hash anchoring provide tamper-evident verification of QC events for a digital twin while keeping operational overhead acceptable for a food-production setting?

The threat model covers retrospective modification of validated QC results, replacement of exported QC files or certificates, mismatch between a LIMS record and the event used by the digital twin, and missing QC evidence for a material or batch state. It also includes practical risks that arise around the anchoring process itself: a user may enter a false result before validation, an authority key may be compromised, or an unvalidated record may be anchored by mistake. Hash anchoring makes later changes to an anchored payload visible, but it does not prove that the original laboratory measurement was physically correct. That part remains the responsibility of the LIMS workflow, laboratory controls, access management, and approval process.

The proposed framework consists of a LIMS or LIMS-like QC source, a QC event exporter, a hash service, a Solana Anchor program, and a verification service connected to the digital twin. The present implementation is a LIMS-compatible prototype: it defines the event path that a LIMS connector would follow and also supports external certificates normalized into the same structure. A validated laboratory record or certificate is exported as a stable JSON event. Field order, numeric formats, document identifiers, and dates are normalized before the event identifier, event hash, and hashed LIMS record identifier are calculated with SHA-256.

The Solana Anchor program stores one immutable anchor per QC event, with the on-chain account containing the event identifier, event hash, event type, hashed LIMS record identifier, authority, and timestamp metadata. The laboratory values themselves remain in the LIMS or off-chain evidence store. When the digital twin later receives a QC event for a batch state update, the verification service recomputes the current event hash, reads the stored Solana anchor, and returns verified, modified, or missing. Only a verified result is treated as ordinary QC evidence for the digital twin. The transformation from a laboratory quality certificate into a verifiable digital twin event is summarized in Figure 1.

The overall architecture of the proposed framework is shown in Figure 2. The architecture separates the laboratory evidence layer, the deterministic hashing layer, the Solana anchoring layer, and the digital twin state-update layer (Figure 2).

Data model

The normalized QC event includes fields such as: document_id

document_date

organization

product

grade

standard

production_date

volume_tons

moisture_percent

gluten_percent

gluten_quality_idk

ash_percent_dry_basis

whiteness

falling_number_sec

decision

source_document_hash

The on-chain anchor stores: event_id

event_hash

event_type

lims_record_id_hash

authority

anchored_at

The digital twin quality state stores: batch_id

qc_status: verified | modified | missing

quality_decision: accepted | rejected | retest

last_verified_at

Verification outcomes

The framework distinguishes three outcomes. In the verified scenario, the current QC event hash matches the anchored hash. In the modified scenario, a QC field has changed after anchoring, so the recomputed hash no longer matches. In the missing scenario, no anchor exists for the event identifier. These three verification outcomes are illustrated in Figure 3. This distinction is important because the digital twin should not treat modified and missing evidence as ordinary accepted QC input (Figure 3).

Implementation

The prototype was implemented as a Solana Anchor project. The Solana program implements two instructions. anchor_event(event_id, event_hash, event_type, lims_record_id_hash)

verify_event(event_id, expected_event_hash)

The anchor_event instruction creates a program-derived account for the QC event and rejects duplicate event identifiers. The verify_event logic compares the expected hash with the stored account hash. In the benchmark client, verification is measured as account read plus local hash comparison, since a digital twin does not need to submit a transaction each time it verifies a QC state.

The digital twin layer is modeled as compatible with open-source compositional digital twin frameworks such as OpenTwins, where individual entities and subsystems can be orchestrated into higher-level digital twin representations (Robles et al., 2023). In this manuscript, that layer is used as the consumer of verified QC states; the main contribution remains the integrity verification step between laboratory evidence and digital twin state update.

The implementation includes normalized JSON examples based on the anonymized flour certificate structure, TypeScript utilities for deterministic JSON normalization and SHA-256 hashing, generated QC event data for 100, 1,000, and 10,000 event volumes, local baseline benchmarks for no-chain hash verification and append-only local logs, Solana local-validator benchmarks for per-event anchoring and verification, and a digital twin state-classification evaluation.

Experimental evaluation

Case data

The case study uses two anonymized flour quality-control documents from a bakery-production context. The first is a handwritten laboratory form dated 2026–04–23 for first-grade wheat flour, including gluten quantity 30.6%, gluten quality group I with 76 IDK units, moisture 14.8%, whiteness 51.0, and falling number 271. The second is a printed quality certificate dated 2025–08–25 for first-grade wheat bakery flour according to GOST 26574-2017, including ash content 0.70%, whiteness 52.5, gluten 30.0%, gluten quality 77 IDK units, falling number 301 s, and moisture 14.3%.

These documents ground the event structure in real bakery QC evidence, but they do not constitute a full industrial deployment dataset. The larger evaluation datasets are generated from the same fields to test anchoring overhead, verification behavior, and state classification at controlled volumes. For the bakery use case, the assumed operating scale is approximately 5–20 QC tests per batch and 10–50 batches per day, or about 100–1,000 QC events per day. A 10,000-event dataset represents a stress-scale workload for the evaluation setting rather than a claim of observed daily production volume.

To document that the case data were derived from production quality-control evidence rather than an abstract example, Figure 4 shows anonymized excerpts from the two source documents. The organization names, applicant information, and other identifying details are not disclosed in the manuscript. Permission was granted to use anonymized excerpts for research reporting (Figure 4).

Baselines

The three evaluated approaches are summarized in Table 1.

Local baselines are expected to be faster. Their limitation is not hash computation, but the lack of an independent external reference under local-store compromise.

Experiment 1: tamper detection

The tamper-detection threat scenarios are defined in Table 2.

The second scenario is the main threat model for this paper. If an insider or compromised local system can alter both the QC event and the local hash or log, local verification can be made to pass. In contrast, the Solana anchor remains outside the local administrative boundary, so a modified payload produces a mismatch.

Experiment 2: anchoring and verification latency

The latency experiment measures anchoring latency and verification latency separately. Anchoring is the time required to store the reference hash. Verification is the time required to retrieve the reference and compare it with the current event hash. The benchmark uses Solana local validator to keep the measurement environment reproducible and to avoid external network variability. The 1,000-event local-validator protocol was run twice: the original run reported in the main results and an independent repeat run using the same generated event structure and benchmark scripts. The repeat run is used to check whether the measured overhead remains in the same range, not to claim production-network performance.

Experiment 3: digital twin state classification

The digital twin state experiment creates a mixed set of events: verified events, modified events, and missing events. The verification service assigns one of three states: verified

modified

missing

The evaluation checks whether each approach provides the correct state classification for the digital twin.

Tamper detection

Under the local-store compromise threat model, both local baselines failed to detect post-validation modification because the local reference could be updated with the modified payload. Solana anchoring detected 100% of modified events because the externally anchored hash remained unchanged.

The tamper-detection results for the 1,000-event evaluation are reported in Table 3.

Anchoring and verification latency

The anchoring and verification latency results are summarized in Table 4.

The measured anchoring latency was lowest for the local baselines and highest for Solana anchoring. Verification latency remained lower than anchoring latency for the Solana-based approach because verification in the benchmark consisted of an account read and local hash comparison rather than a new transaction. In the repeat 1,000-event local-validator run, Solana anchoring produced a mean of 472.2501 ms/event with SD 29.7694, p50 469.2, p95 483.42, and mean verification latency of 1.2591 ms/event. Across the two 1,000-event Solana runs, the run-level mean anchoring latency was 473.5181 ms/event and the run-level SD was 1.7933 ms. The performance trade-off is visualized in Figure 5. The figure emphasizes that Solana anchoring introduces substantial anchoring overhead compared with local baselines, while verification remains comparatively lightweight because it is implemented as an account read and local hash comparison.

Digital twin state classification

The digital twin state evaluation uses a mixed set of verified, modified, and missing events. Verified events are expected to update the batch quality state, modified events are expected to trigger an integrity alert, and missing events are expected to keep the state pending until supporting evidence is available.

The evaluation setup generated a 300-event state-classification dataset linked to the 1,000-event benchmark run. The Solana-based approach classified the evaluated events according to the expected verified, modified, and missing states under the defined threat model. Local baselines can classify missing events, but under local-store compromise they classify modified events as verified. The resulting digital twin state-update logic is summarized in Figure 6. In this logic, only verified evidence is allowed to update the batch quality state, while modified and missing evidence trigger alert or pending states (Figure 6).

Under the evaluated threat model, Solana-based hash anchoring gave the digital twin an external reference for LIMS-like QC evidence. The result is not a faster verification pipeline. Local hashes and append-only logs are much faster, but they remain inside the same administrative boundary as the QC payload. Solana anchoring moves the reference hash outside that boundary, so a later change to the local event or local reference cannot be made invisible to the verification service.

The bakery flour case makes this integrity problem concrete because the QC values are tied to ordinary production decisions. Moisture, gluten, IDK quality, falling number, ash content, and whiteness affect whether flour is accepted, retested, or routed into production under specific assumptions about storage and processing. If those values are changed after validation, the digital twin may represent a batch state that no longer corresponds to the laboratory evidence. The proposed framework addresses this narrow integrity step: whether the event presented to the digital twin still matches the validated version.

The hash-only design also limits on-chain exposure of laboratory data. The Solana account stores hashes and minimal metadata, while the detailed certificate or LIMS record remains off-chain. This matters in food-production settings because QC documents may contain supplier information, laboratory identifiers, production dates, volumes, or other commercially sensitive details. The trade-off is that the off-chain evidence store still has to be managed properly; blockchain anchoring does not replace data governance inside the producer or laboratory.

Several limitations remain. The evaluation uses two anonymized flour QC documents to ground the data model and generated event sets to scale the benchmark. It therefore supports feasibility and reproducibility, not a claim of completed factory deployment. The benchmark also uses Solana local validator. Devnet or mainnet operation would add confirmation variability, transaction failure handling, account-rent and fee considerations, network congestion, and chain availability risks. The measured anchoring cost of about 0.47 s per event is reasonable for batch-level QC evidence that can be anchored asynchronously after laboratory validation, but it is not suitable for high-frequency sensor streams without batching or event grouping. Any batching design would need explicit completeness checks so that a QC event cannot be omitted from a batch without detection.

The framework also depends on controls outside the smart contract. A compromised authority key could anchor the wrong event; a weak approval process could allow an unvalidated result to become the reference record; and fraudulent laboratory practice before anchoring would remain outside the scope of cryptographic verification. In a production deployment, hash anchoring would need to sit behind LIMS permissions, review-and-approval steps, audit trails, key rotation, retry queues, and monitoring for failed transactions. These controls define the work needed to move from a reproducible prototype to an industrial quality system.

This paper proposed a Solana-based framework for verifiable quality-control evidence in food-production digital twins. The framework keeps laboratory data off-chain, stores only cryptographic commitments on Solana, and allows the digital twin to classify QC evidence as verified, modified, or missing before updating batch quality state. An anonymized bakery flour quality-control case based on flour certificates was used to motivate the data model, and generated QC events were used for performance and validation experiments.

The results show a clear trade-off. Local hash and append-only log methods are much faster, but do not provide an external tamper-evident reference under local-store compromise. Solana anchoring adds sub-second per-event anchoring overhead in the local-validator benchmark, but detects post-validation modification and keeps verification lightweight. Under the evaluated conditions, these results support the feasibility of using Solana as an integrity layer for digital twin quality-state updates, rather than as a replacement for LIMS or as a general food traceability platform.

Future work should move from the current schema-grounded prototype to a live LIMS integration with larger factory datasets, multi-user approval workflows, production key management, transaction-failure recovery, and devnet or mainnet measurements. Integration with open-source LIMS and digital twin backends such as OpenTwins would also allow the verification service to be tested as part of a complete quality-state pipeline. Secure IIoT data pipelines and privacy-preserving digital twin interfaces provide useful adjacent directions for strengthening confidentiality and operator control around such deployments (Amirkhanova et al., 2025; Amirkhanova et al., 2026; Robles et al., 2023).