Next Article in Journal
A Multi-Domain Enhanced Network for Underwater Image Enhancement
Previous Article in Journal
The Role of Public Health Informatics in the Coordination of Consistent Messaging from Local Health Departments and Public Health Partners During COVID-19
 
 
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:
Background:
Article

Fujairah Honey Chain (FHC): A Blockchain Framework for Monitoring Honey Production

1
Faculty of Computer Information Science, Higher Colleges of Technology, Fujairah P.O. Box 1626, United Arab Emirates
2
Fujairah Research Centre, Fujairah, United Arab Emirates
3
Finswiss Research, Sydney, NSW 2100, Australia
*
Author to whom correspondence should be addressed.
Information 2025, 16(8), 626; https://doi.org/10.3390/info16080626
Submission received: 6 March 2025 / Revised: 4 June 2025 / Accepted: 12 June 2025 / Published: 23 July 2025

Abstract

Honey is globally recognized for its substantial nutritional and therapeutic properties. However, its high market value makes it susceptible to counterfeiting, negatively impacting consumers and beekeepers. This paper presents a blockchain-based framework to monitor the honey trade supply chain, ensuring authenticity. The framework employs an oracle component to verify honey quality and origin using IoT data. Additionally, it integrates fungible and non-fungible tokens to track honey batches. The study evaluates the economic feasibility of this approach, demonstrating that the cost of performing a trade is less than USD 1, with the oracle component achieving an average accuracy rate of 90% in detecting falsified sensor data.

1. Introduction

Honey, a natural sweetener produced by honeybees, is globally cherished for its diverse benefits and unique properties. Its composition, rich in glucose, fructose, vitamins, minerals, proteins, and enzymes, varies significantly based on the floral source, geographical origin, and bee species [1]. This natural variation underscores honey’s appeal not only as a sweetener but also as a complex nutritional substance with potential therapeutic applications. The health benefits of honey are well documented, including antibacterial, anti-inflammatory, and antioxidant properties, making it valuable for various therapeutic uses. Moreover, honey’s effectiveness in wound healing has been extensively studied, owing to its ability to promote tissue regeneration and reduce infection risk [2]. Research continues to explore honey’s therapeutic potential, reinforcing its integral role in both traditional medicine and modern healthcare practices.
Global honey production has remained substantial and fairly steady in recent years, totaling roughly 1.8–1.9 million tonnes annually. After peaking at about 1.88 million tonnes in 2017, output dipped slightly and then resumed modest growth (approximately 1.4% average annual increase from 2019 to 2022). This places current production near record levels, with China by far the leading producer. China alone contributes around one-quarter of the world’s honey (about 460–500 thousand tonnes per year), vastly outpacing other top producers, for example, Turkey (≈115 thousand tonnes,  6% of global output) and Iran/Ethiopia (each in the order of 70–80 thousand tonnes) [3,4].
By comparison, the United Arab Emirates (UAE) UAE represents a growing honey market and remains largely dependent on imports to meet domestic demand. The UAE, specifically Fujairah, stands out due to its production of unique honeydew honey, derived from the excretions of plant-sucking insects. This specialty honey is distinguished by its distinct taste profile and composition, contributing significantly to local demand and economic activity [5].
This global context underscores that, while honey production is concentrated in a few countries, the interest in honey is worldwide, including in the UAE, thereby linking even small producers and consumers to the trends and challenges of the international honey trade.
One of the foremost challenges in the honey industry today is ensuring the authenticity and purity of honey along the supply chain. The high market value of natural honey has unfortunately made it a common target for fraud and adulteration [6]. Adulteration typically involves diluting or substituting authentic honey with cheaper sweeteners (e.g., sugar syrups derived from rice, corn, or beet) or blending inferior honey and mislabeling its botanical or geographical origin. Such practices allow unscrupulous sellers to increase volume and profit, but at the cost of product integrity.
Studies identify honey as one of the most frequently adulterated food products. It was recently ranked sixth in Europe for incidence of food fraud [5]. This pervasive honey fraud is a serious concern because it deceives consumers and undermines their trust; it also harms legitimate beekeepers, who cannot easily compete with the influx of cheap, fake honey [7].
Recent investigations have spotlighted the extent of the problem: for example, an EU-wide screening in 2022 found that 46% of sampled honey imports were “suspicious” for containing added syrups, failing to meet authenticity standards. Such findings confirm that honey adulteration is not a rare occurrence but a widespread issue spanning multiple countries. Indeed, the problem has become so severe that even international honey quality contests have been impacted; notably, organizers of the World Beekeeping Awards halted the honey competition category in 2025 due to difficulties in verifying unadulterated entries.
Overall, the integrity of global honey supply chains is being undermined, with estimates suggesting that up to 10% of honey traded internationally is fraudulent. In regions such as China and India, adulteration rates in tested samples can exceed 30% [8].
These industry reports and actions illustrate why honey authenticity and traceability have emerged as critical priorities. In essence, if the origin and purity of honey cannot be ensured, both consumer confidence and fair market practices are at stake on a global scale.
Against this global backdrop, the UAE’s role and concerns regarding honey authenticity have also come to the forefront. The UAE traditionally has only modest domestic honey production (owing to its arid climate and limited forage), but it is a significant consumer of honey and thus relies heavily on imports. As a result, the UAE faces the same authenticity challenges that dominate the international honey market.
National food authorities in the UAE have implemented standards and testing protocols to verify honey quality, and their surveys reinforce global concerns: in one recent study of honey imports via UAE ports (2017–2021), about 20.8% of samples were found to be non-compliant with quality benchmarks, indicating likely adulteration or improper handling in a substantial fraction of imported honey.
This finding aligns with global trends and highlights why ensuring honey authenticity is a priority for the UAE. To protect consumers and honest producers, it is crucial to be able to trace honey from “hive to table,” verifying that each batch is genuine and untainted [9,10].
Regulatory efforts are striving to keep pace with evolving adulteration methods, necessitating robust traceability and detection measures to safeguard purity and consumer confidence in honey products. In the production of honey supply chains, monitoring honey quality involves tracking various metrics such as hive health, nectar sources, and production timelines. These metrics are crucial for ensuring the quality of the honey obtained and for detecting counterfeit honey products. However, monitoring all stages of the honey supply chain and ensuring the authenticity of all data related to honey quality presents a significant challenge. This challenge emphasizes the need for a secure information-sharing mechanism to guarantee the authenticity of all recorded data in the honey supply chain.
To address such a challenge, blockchain technology has emerged as a promising solution. Blockchain is a distributed ledger technology (DLT), where several network nodes maintain identical copies of cryptographically linked ledgers or databases. These blocks are interconnected using their hash values. When a new block is inserted into the blockchain, it also includes the hash value of the previous block. Due to this linking process, any attempt to alter a transaction in a block disrupts the chain, as the new hash value will not match the one stored in the subsequent block. The decentralized nature of blockchain eliminates the need for a centralized authority, and the use of smart contracts highlights the potential for process automation. A smart contract is a program (code) that executes based on a predefined set of events, which are integral to the smart contract’s implementation.
Blockchain technologies have inherited security-related features and business automation capabilities that have expanded the domain of decentralized applications (DApp). Accordingly, several proposals have investigated the use of blockchain technology to automate business processes in several application domains, such as e-commerce [11,12,13,14,15,16] and e-government services [17,18,19]. Decentralized blockchain-based application storage and computational requirements are not free of charge. Therefore, a major design requirement is to provide lightweight, computationally inexpensive blockchain solutions.
This work proposes a geographically aware, blockchain-based, lightweight framework for monitoring honey production. With this framework, customers can accurately trace the origin of the honey they purchase. It also facilitates the monitoring of various quality-related factors, such as hive health and nectar sources, by distinguishing between internal and external constraints. Internal constraints are typically implemented by beekeeping businesses to track hive health and other internal metrics, while external constraints focus on monitoring the movement of honey products across supply chain entities. By using these two types of constraints, the framework increases the range of production-related variables that can be monitored. Both beekeeping businesses and government auditing entities are expected to track more production-related variables than end customers.
To enhance the detection of counterfeit products, the proposed framework leverages both non-fungible and fungible tokens. For each batch of honey, a unique non-fungible token is generated to record the origin and ingredient details. This non-fungible token is linked to a set of fungible tokens, with the number of fungible tokens matching the number of honey jars produced from the batch. The purpose of using both types of tokens is to enable tracking throughout the supply chain: the non-fungible token provides access to the honey’s original information, while the fungible tokens facilitate the detection of counterfeit products. If a fungible token cannot be traced to the corresponding origin point, the associated honey product is flagged as counterfeit.
Gathering honey production-related information is supported by an IoT unit that assists in uploading data and images to the framework. To ensure the authenticity of the uploaded images and information before storing them on the blockchain, an oracle component is incorporated into the framework. This component utilizes a machine learning model and an authentication mechanism to verify the accuracy of information and images received from the IoT component. If the oracle confirms the authenticity of the received information, the data will be transferred to the blockchain; if not, the unverified information will be discarded. For example, if a specific type of nectar image is received, the oracle component will verify whether such a nectar type can grow in the specified hive area. Upon confirmation, the blockchain will process the uploaded image; otherwise, the framework will reject it.
By combining trade, oracle, and monitoring components, the proposed framework aims to provide an end-to-end blockchain honey trading solution that supports beekeeping businesses and customers. To achieve this goal, this paper addresses the following research questions (RQs):
  • RQ1: Is the proposed honey production monitoring framework economically feasible?
  • RQ2: Are there any computational and operational issues that challenge implementing the proposed blockchain framework?
To address the proposed questions, this paper’s contributions can be summarized as follows:
  • We develop a blockchain-based honey trading monitoring framework.
  • We design a tracking mechanism to monitor the flow of honey products in the trade supply chain.
  • We design an oracle component that ensures the authenticity and accuracy of the uploaded information and images to the blockchain.
  • We implement the proposed framework in Solidity (0.8.17), where Hardhat is used as the development environment. Any Ethereum-compatible blockchain can be used as the targeted network.
Solidity v0.8.17 was selected as the smart contract language for our Ethereum-based framework due to its enhanced security features and strong ecosystem support. Notably, the Solidity 0.8.× series introduced built-in protections against arithmetic overflow and underflow, which pre-empt a common class of smart contract vulnerabilities [20]. Additionally, Ethereum’s widespread adoption means Solidity benefits from extensive developer resources and tooling, making it well-suited for implementing complex supply chain applications [21]. An oracle module is incorporated to bridge the blockchain with external inputs, since on-chain contracts cannot directly access off-chain data (e.g., temperature, inspection results, location) needed for monitoring conditions [22]. The oracle securely fetches and verifies such real-world data for use by smart contracts, enabling our honey supply chain system to make informed, autonomous decisions while preserving the transparency and trust guarantees of the blockchain.
Several experiments were conducted to evaluate the operational costs of the proposed framework. The results indicate that the cost of executing a trade involving five transition states is less than USD 1. In this context, a transition refers to the movement of honey products between two logistics personnel. Additionally, the findings show that increasing the number of transitions in the supply chain results in a linear increase in cost. This behavior is acceptable, as the number of transitions in this type of supply chain is typically limited. Given the cost of honey, these results demonstrate that implementing the proposed framework is economically viable. Furthermore, the oracle component was able to detect falsified sensor data with an average accuracy of 90%.

Key Contributions

This research presents a pioneering traceability framework that advances both the technical and contextual landscape of blockchain applications in agriculture. Unlike prior efforts that rely solely on static blockchain records or centralized quality checks, our work introduces a dynamic, machine-learning-powered oracle capable of validating real-time environmental and sensor data before committing it to the blockchain. This ensures a higher level of data integrity and resistance to tampering in decentralized systems. We also introduce a dual-token mechanism combining fungible and non-fungible digital assets, allowing for granular, batch-specific honey product tracking and traceable trade execution. The framework is tailored to the unique environmental and regulatory landscape of the United Arab Emirates, marking the first documented initiative of its kind specifically deployed and validated within the Fujairah region. From a practical standpoint, the system is economically viable for producers, achieving transaction costs below USD 1 through deployment on the Avalanche blockchain. Collectively, these contributions bridge critical gaps in food authenticity, environmental validation, and blockchain adaptability in arid-region agri-supply chains.
The rest of this paper is organized as follows. In Section 2, we discuss the most related proposals from the literature. Section 3 presents the proposed honey trade framework, and Section 4 presents and discusses the results of the performed analyses. The paper is concluded in Section 5.

2. Related Work

The use of blockchain technology to monitor and enhance trade supply chain processes has been extensively studied in the literature [11,18,23,24,25,26,27]. For instance, in the e-auction domain, Almiani et al. [11] presented a blockchain-based framework for monitoring customer service quality. Using the proposed framework, any service violation is automatically detected via the framework’s smart contracts, where the violating entities are penalized by utilizing cryptocurrency. Several other proposals [12,13,14,15,16] have also explored the benefits of employing blockchain solutions to optimize and secure the e-auction processes.
To detect counterfeit goods, Juma et al. [18] discussed the importance of using blockchain technology in the international trade supply chain from a customs administration perspective. Accordingly, the authors highlighted the advantages of using this technology to detect counterfeit products and protect the local market. Additionally, Azevedo et al. [28] discussed the requirements to ensure traceability in the supply chain using blockchain solutions.
In the context of the food supply chain, several proposals [24,25,26,27] have investigated the importance of using blockchain technology to ensure food safety and to authenticate the information provided by supply chain parties. In [26], the authors proposed a blockchain-based framework for agricultural food supply chains. With the help of an IoT component, the proposed framework aims to capture farming environment conditions, such as soil moisture and weather sensor readings, on the blockchain. Along these lines, Shahidi et al. [27] proposed a blockchain-based framework for agricultural food supply chains. The proposed framework has a reputation-based mechanism, ensuring the participating entities’ credibility.
Regarding the honey supply chain, Rünzel et al. [29] proposed an image-based traceability system supported by blockchain technology. In the proposed system, several off-chain image-centric components monitor the quality of the honey and detect any risk-related factors. Sellers are expected to submit the sell log to the blockchain. Additionally, the system relies heavily on analyzing the captured images to perform a pollen signature check to authenticate the honey’s origin. As highlighted by the authors, the image analysis component requires significant training to ensure its reliability. Furthermore, the implementation details of the proposed system were not described. Several other proposals [30,31,32] have discussed the advantages of using blockchain technology in the honey trade supply chain.
In [33], the authors propose a blockchain-based system that utilizes smart contracts to support and secure honey trades. Using the proposed system, trade and honey-harvesting information are recorded on the blockchain for traceability. To avoid counterfeiting, a “white” list of trusted honey producers is maintained, where any honey producer not included in the list is not permitted to interact with the system. The white list limits the business space, and using such a mechanism requires defining a process for how a honey producer can join the list.
Lukovac et al. [34] proposed a blockchain-based system to track organic honey production. Using this system, customers can retrieve stored product information via a product QR code. Sensor readings are collected from hive environments and periodically uploaded to the system for analysis and verification. However, relying solely on a QR code to ensure the authenticity of honey is not sufficient. QR codes could be regenerated in an attempt to sell fake honey. Additionally, the sensors deployed in hive environments are subject to manipulation, a risk that was not addressed in the proposed system.
Unlike the previous proposals [29,30,31,32,33,34], in addition to tracking sales records, each honey batch is associated with a set of fungible tokens that help track the sales volume. Accordingly, once honey is sold to the customer, its associated QR code and fungible token can no longer be used in future sales. Furthermore, the proposed framework introduces an oracle component that aims to detect any attempt to manipulate the collected information during the harvesting season.

3. The Proposed Framework

Figure 1 illustrates the conceptual workflow of the proposed framework’s functionalities. The framework consists of three main components: trade, monitoring, and oracle.
The trade component contains all trade-related functionalities, including pre-trade activities such as registration and token generation. Businesses must register with the framework via the trade component to access its functionalities. A regulatory entity is responsible for verifying business licenses, certifications, and other required documents to validate the business registration. This regulatory role can be assigned to one or multiple government entities. Additionally, businesses must register all IoT devices (e.g., phones, sensors) that will be used throughout the various stages of the trade supply chain (e.g., transfer, lab tests).
The monitoring component contains all functionalities related to initiating and fulfilling monitoring requests. During honey production, two types of tokens are generated (minted). A non-fungible token identifies each honey batch. For each non-fungible token, a set of fungible tokens is minted, corresponding to the number of honey bottles (containers) produced from that batch. The minting process for both fungible and non-fungible tokens is triggered for each honey batch. The non-fungible token contains details about the batch ingredients and all collected information regarding its production, while the fungible tokens trace the ownership of the honey bottles through the trade supply chain.
The oracle component authenticates information related to the quality and origin of the honey before storing it on the blockchain. If the oracle verifies the authenticity of the uploaded information, it is stored on the blockchain; otherwise, it is disregarded.
Finally, when the honey product reaches the customer (either a business or individual), they can verify the product’s authenticity using the trade component functionalities. This allows customers to access detailed information about the product, including its origin.

3.1. Trade Component

This component registers businesses and IoT devices and initiates the honey batch harvesting service.

3.1.1. Registration

Businesses must register with the proposed framework to use it. As part of the registration process, a new wallet address will be created for the company that must submit identification documents, which will be linked to the newly generated address. All identification documents will be stored off-chain on the InterPlanetary File System network (IPFS (https://ipfs.tech/), accessed on 6 December 2023). Furthermore, a registered business must register its logistics personnel and IoT devices to interact with the framework.

3.1.2. Honey Trade Service Request

At the beginning of each harvesting season, each registered beekeeping business is expected to submit a honey trade service request. Figure 2 illustrates the process of submitting the request. The submitted request highlights the quantity and type of harvested honey (Sider or Samr). Additionally, the request includes the honey quality certificate obtained from the regulatory entity. The certificate is stored off-chain through IPFS, and its hash code is stored on the blockchain for linking purposes.
Along with the request, the business has to submit images that capture the details of the hives’ surrounding environment. These images are utilized to monitor the hives’ health and identify the types of nectar sources from which the bees are foraging. Additional information, such as temperature and the quality of water, can also be submitted along with the request. Uploading such information and data is expected to be performed via registered IoT devices that are also programmed to capture the GPS location at the time of collecting the images and/or sensor readings. A registered beekeeping business can register several IoT devices to be used during the collection and distribution of honey. Before storing the uploaded images and data, the oracle component is called to confirm the authenticity of the uploaded information. Once the authenticity of the images and/or sensor reading is confirmed, they will be stored on the blockchain. However, uploaded images will be stored in the IPFS, where their hash code will be recorded on the blockchain.
Upon registration of the new service request, tokens will be generated to capture the movement of the harvested honey throughout all stages of the honey production supply chain.

3.1.3. Token Generation and Verification

Figure 3 illustrates the token-generating process. For each honey trade service request, two types of tokens are generated (minted): a non-fungible token and a set of fungible tokens. The non-fungible token is used to capture all of the information and images submitted in a trade service request. This token works as the honey batch certificate. The set of minted fungible tokens is equal to the number of bottles (containers) used to store the harvested honey. The generated fungible tokens are mainly used to identify and track the generated honey bottles. Each set of minted fungible tokens is associated with a single non-fungible token. The ownership of a non-fungible token is reserved for the regulatory entity. The non-fungible token QR codes are printed on sealed honey bottles (containers) and used by customers (businesses or individuals) to access all production-related information. The fungible tokens are used to track the distribution of the honey bottles and detect counterfeit products.
Accordingly, at any stage of the trade supply chain, the entity (individual or business) that physically has honey bottles must own a number of fungible tokens equal to the number of honey bottles—transferring n bottles of honey from entity A to entity B results in transferring n fungible tokens from entity A to entity B. Using the proposed framework, the authenticity of a honey bottle can be verified using the non-fungible token printed on the bottle and the associated fungible tokens maintained by the framework. The non-fungible token shows the honey details (history), and the fungible tokens are used to determine whether the seller is expected to own the traded honey bottles.
A customer can check the authenticity of the honey bottle(s) by submitting the non-fungible token QR code, the seller name (or ID), and the number of honey bottles to the framework. If the verification process can trace the ownership of bottles (fungible tokens) to the owner, the authenticity of the honey bottles will be confirmed. Otherwise, the traded bottles will be considered fake.
Once a honey bottle reaches its final customer, the ownership of the fungible token associated with the sale is returned to the framework. The fungible token will be returned to the framework and gain points that will entitle the customer to future discounts.

3.1.4. Sell Order

Once the trade service request and the token generation process are completed, a business can submit a sell order request to the framework with the assistance of the monitoring and oracle components. Along with the seller’s details (beekeeping business), the seller must also submit the buyer’s information and the order details to the framework.

3.2. The Monitoring Component

As with any other business trade, customers (individuals or businesses) and sellers (beekeeping) may agree on a set of constraints that represents the Quality of Service (QoS) requirements, which must be satisfied through the trade supply chain. Accordingly, the monitoring component is designed to facilitate the process of capturing such constraints on-chain. The functionalities of the monitoring component mainly consist of the QoS agreement definition and service monitoring.

3.2.1. QoS Agreement Definition

Using the proposed framework, the sellers (beekeeping businesses) can define two types of QoS agreements: internal and external. Internal agreements are used by beekeeping businesses to monitor the performance of internal processes and logistics personnel. For instance, a beekeeping business may introduce constraints to ensure that the distance between any two hives is at least one meter. The external agreement represents the QoS constraints the beekeeping business has promised the customer.
The structure of the agreements could vary significantly. Thus, the process adopted to capture the agreement should be flexible to support various constraints. Algorithm 1 illustrates the process of agreement definition. An agreement can be composed of a set of constraints, and the types of constraints are shown in Table 1. The types of constraints are distinguished by the source type ( s t ) and event type ( e t ). This table works as a lookup table and aims to simplify the process of registering and executing an agreement-related task. The regulatory entity maintains the list of available types, where a business can submit a request to introduce a new type using the proposed framework. In this context, the regulatory entity has to approve the submitted request before it is added to the table.
Algorithm 1: defineAgreement
Information 16 00626 i001
Each constraint (internal or external) consists of four fields. Besides s t and e t , a constraint will have an event script ( e s ) and event location ( l e ). e s represents the query (instruction) the source is expected to answer, where l e is a unique identification number that is used to identify the set of IoT devices that can act as sources. Each IoT device is associated with a l e value that captures its logical location. This location represents the locality of the IoT device; for instance, an l e value could be used to identify that the IoT device (sensor) is located in room A. In situations where multiple IoT devices share the same l e value, one device will be selected randomly to answer the query. The selected source answers the received constraint in a publish–subscribe event fashion.
A single agreement can be represented as a direct graph, where the vertices of this graph represent the agreement constraints, and the edges represent the dependence between the constraints. For instance, if constraint A must be fulfilled before constraint B, the arrow connecting the constraints (vertices) will be directed toward constraint B vertically. When there is no dependency between the constraints, the agreement will be captured as a complete graph (Figure 4). Consequently, an agreement is fulfilled once all vertices in its associated graph have been visited (traversed).

3.2.2. Agreement Traversing

Any trade-related input must be received from registered IoT devices, such as sensors, PDAs, or mobile phones. These devices function as transaction feeders to the framework. Once an input is received, the agreement traversing function processes it and updates the associated agreement traversing graph. Algorithm 2 highlights the steps of the agreement traversing process.
Algorithm 2: traverse
Information 16 00626 i002
A vertex is labeled as “traversed” if the execution of its constraint query returns a true value (line 3). When such an execution returns a false value, the vertex is labeled “failed” (line 5). When all vertices are labeled as traversed, the agreement is considered fulfilled (line 8). However, the agreement is considered unfulfilled if any vertex is labeled as failed. Labeling an agreement with external constraints as unfulfilled could allow the customer to cancel the entire trade due to violating the QoS constraints. In such a situation, the customer can receive partial reimbursement based on the importance of the failed constraints. The beekeeping business and customer may collaboratively agree on the reimbursement amount and strategy before the initiation of the trade. Consequently, the agreed strategy and amount can be integrated as part of the proposed framework to ensure the ease of business flow.
A threat assessment and evaluation model is expected to be conducted for IoT-based applications to assess potential threats and propose countermeasures. However, in this work, we assume that the IoT devices used are trustworthy; therefore, conducting such an assessment is outside the scope of this paper.

3.3. Oracle Component

This component receives several images and environment-related data at different stages in the honey trade supply chain for authentication. The received data and/or images are generally tagged by the location of the source (beekeeping business). The aim of the oracle component is to confirm whether the reported information accurately reflects the environment surrounding the apiary. Due to its computational complexity, this component is implemented off-chain. The process performed by this component depends on the nature of the received data images or sensor readings.

3.3.1. Images

During the trade supply chain, two types of images are expected to be received by the oracle component: general images and constraints-related images. General images represent those used to showcase the beekeeping business environment. These images support the trading process by allowing the customer to inspect the honey hives’ surroundings visually. They are uploaded during the initiation of the honey trade service request. The uploading of such images is expected to be performed via registered IoT devices that record GPS coordinates during the image-capturing process.
For these images, the only required authentication is matching the GPS coordinates with the known location of the beekeeping business. This authentication process can be conducted by comparing the recorded coordinates with those stored in the framework. The two sets of coordinates are not expected to be exactly the same. Thus, a distance interval can be added to the stored beekeeping business coordinates to allow for a slight difference of a few meters between the two.
Constraints-related images are mainly used to capture the type of nectar the bees are expected to use for forging. Authenticating this type of image is performed through two steps (Figure 5). In the first step, the captured images’ GPS coordinates are authenticated using a strategy similar to that for the general image. Then, in the last step, the type of nectar is authenticated using a machine learning-based model using YOLOv8 [35] (You Only Look Once). YOLOv8 is a high-end object detection model with high accuracy and speed in image processing. Fujairah Research Center (FRC) is developing a comprehensive dataset of plant images, including thousands of photos of key honey nectar plants cultivated in the apiaries of the Fujairah region. The primary nectar sources for honey production include Acacia tortilis, Ziziphus spina-christi, Prosopis cineraria, and various other supporting plants, such as, Boerhavia elegans, Citrus medica, and Fagonia indica. These plants form a significant portion of the nectar used in honey production. The honey is produced in a supervised honey park, where the plants are known and monitored. To enhance traceability and security, beekeepers will photograph the nectar plants that bees visit each season and upload these images to the framework. This ensures that the dataset, which captures the seasonal variations and growth trends of nectar plants, remains up-to-date. Furthermore, this dynamic dataset will be used to train models capable of accurately identifying and categorizing a wide range of honey nectar plants.
By examining the visual characteristics of the plants stored on the framework, reliable authentication of the nectar source can be achieved. In addition to this, pollen analysis from honey batches will be conducted in laboratories to determine whether the honey is Sidr, Samar, or a poly-floral blend. This information will be linked to a certification that is easily accessible via QR codes on the honey bottles, providing consumers with a verifiable record of the honey’s origin and composition.
For general images, if the oracle component confirms the GPS coordinates for the uploaded image, the uploaded images will be stored using an IPFS service, where their hash code will be stored on-chain for linking purposes. For constraints-related images, besides confirming the images’ GPS coordinates, the machine learning model has to recognize and confirm the type of nectar displayed in these images. Once the GPS coordinates and the type of nectar are confirmed, the constraints-related images will be stored using an IPFS service and linked to the blockchain using their hash code. When the oracle component fails to authenticate an uploaded image, the honey trade request will be canceled, and the beekeeping business will be notified. In such a case, the beekeeping business will be allowed to dispute the decision. Resolving the dispute is the responsibility of the regulatory entity, which can confirm the authenticity of the images or the cancellation status. The responsibility of resolving the dispute can be assigned to any government authority that handles goods regulation.

3.3.2. Sensor Readings

As part of internal and external constraints processing, sensor readings are expected to be uploaded to the framework. Consequently, once a sensor reading is received, it is passed to the oracle component for authentication. Sensor readings are uploaded via a registered IoT device during the agreement traversing process. A sensor reading (data) is processed based on the associated event type, where the objective of this processing is to determine whether the reported data can be classified as normal or abnormal. To this end, each piece of event type (temperature, light, etc.) data is represented as a graph, where an outlier detection algorithm is used to compare newly received data against the available historical data of a similar type. Each piece of sensor data (value) is associated with two values: time and date. These two values aim to increase the accuracy of the employed outlier detection algorithm because the reported sensor values (e.g., temperature and humidity) are influenced by the recording time and date (season).
Algorithm 3 highlights the sensor data authentication process, which employs the well-known Local Outlier Factor (LOF) [36], which is typically used to determine whether newly received data (point) can be classified as an outlier or not. Accordingly, if the LOF for a piece of data is ≤1, the oracle component labels the received data as normal. However, if the LOF is above one, the data is labeled as abnormal (outlier). When the oracle component labels the data as normal, the traversing process is notified to continue processing. However, if the data is labeled as an outlier, the regulatory entity is notified to analyze the received data further. A sensor might report an accurate value due to malfunctioning; in such cases, the sensor must be replaced. Each piece of sensor data is represented as a point in a 3-dimensional space, where the x-axis captures the sensor data and the y-axis represents the time. The z-axis captures the seasons and is determined based on the date value. This axis consists of four values (for seasons) that cover the entire year (Figure 6)—the time window for each sensor is an input parameter.
If the LOF is around one, normal data might be labeled as abnormal due to the lack of distinct features. Therefore, the employed authentication mechanism introduces a safety gap variable ( s g ) to reduce the probability of false positives. Accordingly, newly processed data is considered abnormal if it is 1 + s g . When sensor data is labeled as abnormal, the associated constraint is considered unfilled. This component can employ other types of outlier detection algorithms. However, the LOF algorithm is selected in this paper, since the proposed framework targets a limited area and the reported sensor readings are expected to be homogeneous.
Algorithm 3: sensorAuthentication
Information 16 00626 i003

3.4. Security and Decentralization Aspects

This section discusses several operational factors related to the proposed framework.

3.4.1. Decentralization and the Regulatory Entity

Decentralization is crucial for ensuring the proposed framework’s applicability. In addition to contract deployment, the regulatory entity is involved during the seller identification process, resolves disputes, and oversees the honey packaging process. Managing the identification process of sellers can be delegated to beekeeping (Apiarist) associations or independent verification companies that establish the necessary standards. For resolving disputes, the regulatory entity is expected to review the outcome of the oracle component and either confirm or reject its decision. In this context, the reviewed outcome typically involves constraints-related images and/or sensor readings. To ensure transparency in resolving disputes, customers are made aware of any decisions made by this entity through the capability to retrieve the entire history of honey products. With the help of a multi-signature scheme, oversight of the packaging process can be delegated to one or multiple entities. Overall, the presence of the regulatory entity does not limit the decentralization aspects of the proposed framework since it lacks the authority to alter the business flow.
Honey production would not be regulated in most Western countries, and DAOs, although an option, are a bridge too far. There are beekeeping (Apiarist) associations and independent verification companies that could provide standards and human resources.

3.4.2. Accounts and Wallet Addresses

Interaction with the framework, once it is deployed on a public blockchain, is not free of charge. The charges incurred by a function call are typically paid by the wallet address of the function invoker. These charges depend on the called function’s computational and/or storage requirements. The only set of functions that are not chargeable are those that only return the value of stored variables (view functions). Accordingly, the proposed framework is designed to ensure that seller-related functions are the only chargeable functions. Customers are only expected to invoke two functions: retrieving honey product information and returning the fungible token. Retrieving the product information is not associated with computational requirements and does not change the status of any variable stored on-chain, making it free of charge. To transfer the fungible tokens back to the framework for a future discount, the customer is not required to pay any charges, since this function is funded by the regulatory entity account.

3.4.3. Counterfeit Goods and Auditing

To ensure the traceability of honey products, the proposed framework records all transactions, from harvesting requests onward, on the blockchain. This includes capturing the movement of products. Accordingly, the entire history of a honey product is traceable via the QR code on the product-sealed package. Using this mechanism, counterfeit products can be easily detected, as the QR codes correspond exactly to the number of fungible tokens, all of which are fully traceable within the framework. However, to ensure the efficiency of the adopted product traceability mechanism, the fungible tokens must be returned to the framework once a product is sold to the final customer. This is required to avoid any possibility of reusing the serial numbers on counterfeit products.
To address this requirement, the framework includes the functionality of returning the tokens to the framework for a future discount. Securing the tokens can be further ensured by applying additional measures, such as introducing an auditing process. This could limit customers (businesses) from making new purchases until they have returned the tokens from previous sales to the framework. Furthermore, an expiration date could be introduced to determine the lifetime of serial numbers.

3.4.4. Oracle Implementation

In this work, we assumed that the oracle component has to be implemented off-chain to reduce operational costs. This is particularly true for the machine learning (ML) model due to its computational requirements. However, determining the authenticity of received sensor readings could be implemented on-chain, especially when the number of expected readings (data points) is typically small. To enhance decentralization, multiple nodes can host oracle components, each utilizing different ML models and outlier detection mechanisms. Using such settings, the employed oracles can use a voting mechanism to determine the authenticity of the received images and/or data.

3.4.5. Targeted Deployment Blockchain

With minor modifications, the proposed framework can also be implemented on a private blockchain. However, in this work, we designed the framework to operate on an Ethereum-compatible public blockchain. This approach aims to support the decentralized aspects of the framework and leverage the ERC token standards. Additionally, deploying the framework on an Ethereum-compatible blockchain provides the advantage of interoperability, making it operational on various blockchains.
Regarding Ethereum’s block settlement time and the frequency of trades, a different type of blockchain should be considered if the trade frequency is expected to be relatively high. On average, it takes around 13 s (https://etherscan.io/chart/blocktime, accessed on 15 January 2024) to confirm and include a transaction in an Ethereum block. This block settlement time can be considered slow for high-frequency trading applications.

4. Results and Discussion

This section describes the experiment settings, followed by a detailed discussion about the reported results.

4.1. Experiment Settings

The proposed framework was developed using the experimental methodology shown in Figure 7. Accordingly, the initial design and configurations of the framework were conducted during the design phase. Then, in the implementation phase, the implementation of the created design was performed using the Solidity (0.8.17) language (the source code can be obtained by contacting the corresponding author), whereas HardHat (https://hardhat.org/, accessed on 10 March 2024) was used as the development environment. During the experimental phase, the design and implementation of the proposed framework were revisited to improve the overall performance. The Ethereum network was used as the deployment environment in the experimental and validation phases (however, any Ethereum-compatible blockchain can be utilized for deployment), whereas, in the validation phase, several test scenarios were performed to validate the performance of the proposed framework.
The proposed framework functionalities were divided into four smart contracts: the trade contract, the decentralized identification (DID) contract, the MintingManagement (MM) smart contracts, and the oracle contract. Dividing the functionalities into multiple contracts aims to reduce the cost of re-deployment and simplify the process of adding more functionalities in the future. Table 2 summarizes the smart contracts’ functionalities. The trade contract handles trade-related tasks such as agreement traversing and QoS agreement definition. The DID contract is responsible for the (de-)registration of beekeeping businesses and their IoT devices. The MM smart contract mainly has token generation and verification functions. The oracle smart contract communicates with the off-chain component to ensure the authenticity of the received images and sensor readings. All computations resulting from invoking the oracle contract functionalities are performed off-chain. Therefore, the cost of interacting with this contract can be neglected. However, its functionalities are listed in Table 2 for completeness.
Regarding the trade service request and the generations of the tokens, Figure 8 illustrates the interaction between contract functionalities to handle such a request to generate the associated tokens. Besides the quality-related information and images, the beekeeping business must submit the number of honey containers (bottles) that will be harvested and the batch identification number. The submission process is initiated by the DID contract, with the regulatory entity having to approve the request. Then, token generating (minting) is performed using the MM contract, which is implemented using an ERC1155 token standard that supports the use of multiple tokens. Once the non-fungible and fungible tokens are generated, the ownership of the non-fungible token will be maintained by the regulatory entity, whereas the minted fungible tokens will be transferred to the beekeeping business account.
The interactions between the smart contract functionalities during the processing of a customer order can be described as follows: This process starts by defining the QoS agreement using the trade contract, which records the details of the agreement and the trade. Then, during each stage of the trade supply chain, the trade contract transfers the fungible tokens between the supply chain entities with the help of the MM and DID contracts. For instance, if 20 honey containers are moved from logistic personnel A to B, the associated 20 non-fungible tokens will be transferred from logistic personnel A’s wallet address to the wallet of logistic personnel B. Moreover, any trade-related input is processed by the trade-traversing function, which tracks the fulfillment of the trade agreement and determines the final status as either fulfilled or violated.
Besides analyzing the operational cost of the proposed framework, the experiments presented in this section investigate the accuracy of the oracle component authentication mechanisms.

4.2. Cost Analysis

The objective of the experiments presented in this section is to evaluate the economic feasibility of the proposed framework. Therefore, the presented experiments focus mainly on the cost (gas consumption) of executing the framework functionalities. Table 3 summarizes the cost associated with each function call. When a function with computational and/or storage requirements is called, the caller address will be charged based on the gas needed to execute the function. The gas price depends on the targeted network; in the Ethereum network, the gas price is 7 Gwei (https://www.coinbase.com/, accessed on 1 Octobar 2023), and ETH 1 is equal to 109 Gwei.
The table shows the highest cost of deploying the smart contracts, which is an initial cost incurred at deployment. This cost is only charged if all contracts are redeployed. If only some contracts need to be redeployed, the cost will be lower, demonstrating the benefit of dividing the framework’s functions. The cost of registering beekeeping businesses is a one-time charge per business. The cost of minting non-fungible and fungible tokens is incurred once during the harvesting season (mintTokens), as the minting process is triggered once for each batch.
For each trade (sell order), the trade initiation and agreement definition functions are executed once, while the traversing function depends on the number of transitions (stops) in the trade supply chain. Additionally, the number of times the token transfer function is called depends on the number of involved logistics personnel. The token burning function has the lowest cost of ETH 0.00021 and is used to track goods in the trade supply chain accurately.
To understand the importance of the reported results, consider a situation where beekeeping business A agrees to sell 100 bottles of honey to customer B. In this example, assume that A, its logistics personnel, and its IoT devices are already registered in the framework. The cost incurred for performing the sell order includes the QoS agreement definition, traversing, and sell order registration costs. The cost of calling these functions is 1,576,351 (ETH 0.011). Assuming the trade supply chain consists of one transition (stop), the traverse and token transfer functions are executed once.
The cost of using the proposed framework in USD depends on the deployment network. While the cost of 0.011 is USD 41.67, using other Ethereum-compatible networks, such as the well-known Avalanche (https://www.avax.network/, accessed on 1 January 2023) network, can significantly reduce the cost. The cost of AVAX 0.011 is USD 0.4, where AVAX is Avalanche’s native currency. Considering that the market price of some premium honey types can reach more than USD 300, the economic feasibility of the proposed framework is emphasized (RQ1).
Next, to investigate the impact of the total number of transitions (stops) on the cost, we ran experiments while varying the length of the trade supply chain (number of transitions). Figure 9 shows the results of this investigation, assuming that a sale order has been confirmed between business A and customer B. The figure illustrates that increasing the number of transitions results in a semi-linear increase in gas consumption. This is because increasing the number of transitions leads to more frequent calls to the traversing and token transfer functions. However, the combined cost of calling these two functions is significantly smaller compared to the cost of calling the agreement definition and sell order functions. The highest cost occurs when the number of transitions is five (1,873,175 gas units), which is approximately equivalent to AVAX 0.013 (USD 0.47). This result further underscores the economic feasibility of the proposed framework.
To investigate the relationship between agreement size (number of vertices) and gas consumption, we ran experiments while varying the number of vertices. The experiments were configured to ensure that the traverse function was called n times, where n equals the number of vertices in the agreement graph. Figure 10 shows the results of the evaluations. Increasing the number of vertices increases the cost of invoking the QoS agreement definition and executing the traverse functions. The results indicate that increasing the number of vertices leads to a linear increase in cost. This is primarily because a larger number of vertices increases the amount of information that must be recorded, thus raising the cost of defining the QoS agreement. Regarding the traverse function cost, the size of the agreement has no significant impact on the cost of executing the function, because any received input is tagged by the source type (vertex label). The observed results highlight the practicality of the proposed framework (RQ2).

4.3. Senor Readings

This section evaluates the accuracy of the authentication method employed for sensor readings. The experiments used 10,961 temperature readings recorded over six months. The temperature sensor (source) is located near one of the hives at the Fujairah Research Center. The input data was divided into two sets: falsified and authentic. The authentic set comprised 80% of the input data and was used to construct the graph employed during authentication. The falsified set, representing the remaining 20%, was treated as newly received sensor data. Each sensor reading in the falsified set was manipulated with a probability p, with any manipulated reading differing from the original by at most e%. The safety gap ( s g ) was set to 1%.
To investigate the impact of the e parameter on the accuracy of the authentication mechanism, we conducted experiments while varying the e value. Figure 11 shows the results, where the value of the p parameter was set to 50%. The results indicate that increasing the e value increases the accuracy of the proposed method. A higher e value increases the gap between the original and manipulated values, thereby increasing the probability that manipulated data will be detected by the authentication method. Additionally, the results show that when the e value is relatively small (7%), the accuracy of the proposed method drops significantly. At a lower e value, the probability of obtaining a false positive is relatively high, since there is a good chance that an abnormal value (sensor reading) will have an outlier factor close to one. This behavior highlights the importance of the safety gap ( s g ), since it underlines the need to examine readings that do not have clear, distinct outlier features further. However, the value of this gap should be event-type-related, as event values are expected to follow different distributions.

4.4. Image Classification

The YOLOv8 model was applied for the classification and detection of honey nectar plants, based on images collected across seasons. The model was trained to classify these plant species by processing the dataset through its convolutional layers, which extracted critical features such as leaf shape, flower structure, and plant growth patterns. YOLOv8’s architecture enabled real-time object detection and classification, making it suitable for identifying multiple plant species within a single image. As a one-stage detector, it localized and classified the plants simultaneously, providing both the bounding boxes and the associated class labels.
Following the initial training, classification accuracy was evaluated based on precision, recall, and F1 score, with a focus on the correct identification of each plant species under varying environmental conditions. Misclassifications were analyzed to fine-tune the model, and additional images were incorporated to improve its robustness, as illustrated in Figure 12. Seasonal variations in plant growth were accounted for by retraining the model with new image data in each season, ensuring that the classification remained accurate. The model was utilized for automated classification during each season, and the detected plant species were compared against manually annotated data to validate the results. The classified images were also used to continuously improve the model’s accuracy and adaptability to future environmental changes, supporting both real-time classification and long-term model refinement. In this study, image authentication could not be implemented, as it requires a prototype and mobile application to function. Consequently, the results pertaining to this component will be compiled and published as a separate study at a later stage.
Overall, this proposed framework contributes to the blockchain-based agri-food traceability domain by introducing a lightweight, geographically aware system tailored for monitoring honey production in regions with authenticity challenges. Unlike prior work that primarily focuses on static traceability records or centralized data verification, this study integrates a machine learning-enhanced oracle that dynamically authenticates images and sensor data before blockchain entry, improving reliability across the supply chain. Images and sensor data are the key components in honey supply-chain authenticity. A key novelty lies in the combination of fungible and non-fungible token association with honey batches, enabling both traceability and trade flexibility in a single environment. The application of YOLOv8 for nectar source verification underlines the system’s ability to adapt to environmental variability, a feature not commonly addressed in existing traceability frameworks. To the best of our knowledge, this is the first initiative of its kind in the UAE, particularly in the Fujairah region, to integrate machine learning, blockchain, and IoT technologies for end-to-end honey traceability. The theoretical implications include demonstrating how decentralized applications can incorporate external validation layers, such as oracles, while maintaining blockchain integrity. Practically, it proves economically feasible, with costs remaining under USD 1 per transaction, and scalable, as shown by the performance on the Avalanche network. The framework offers actionable insights for food regulators, policy makers, producers, and blockchain developers seeking to implement transparent, tamper-resistant agri-food supply chains, especially in arid and high-risk regions like Fujairah.

4.5. Discussion and Limitations

This section discusses the proposed framework’s operational costs, aspects of decentralization, and scalability. The nature of blockchain technology supports the proposed framework’s scalability requirements. Business-related processes, mainly the trade and monitoring component functionalities, are executed on-chain. The number of involved beekeeping businesses and customers has no impact on the scalability of the proposed framework because there is no dependency between the trading processes and the volume of trade. Regarding a single trade instance, increasing the number of involved logistics personnel has no impact on scalability since, based on the characteristics of the application domain, this number is expected to be bounded. These facts are supported by the reported cost results, which demonstrate the linear impact of increasing the number of logistics personnel on the operational cost of the proposed framework (RQ2 and RQ1). The oracle component functionalities are implemented off-chain, where increasing the volume of trade is expected to improve the accuracy of its functionalities (RQ2).
The presence of the regulatory entity does not limit the proposed framework’s decentralization aspects. Besides validating the submitted documents, this entity works as a treasury during the tokenization process. Accordingly, this entity does not have the authority to alter the business flow and, therefore, has no impact on the proposed framework’s decentralization aspects. Moreover, parts of this entity’s responsibilities can be automated based on the adopted business case. For instance, advanced honey processing machines could be able to automatically generate a digital report that includes details related to the harvested honey weight. In this context, the generated report can be submitted directly to the framework in order to automate the token generation process further (RQ2).

5. Conclusions

The proposed framework has emerged as a promising platform to increase trust between beekeeping businesses and customers by allowing customers to verify the honey’s origin and quality. The results and discussion highlight the economic feasibility of the proposed framework and its ability to detect counterfeit products. Additionally, combining fungible and non-fungible tokens simplifies the process of tracking honey products in the trade supply chain.
Regarding the operational cost of using the proposed framework, the linear relationship between the cost and the number of transitions in the trade supply chain supports its scalability. This scalability is emphasized because the number of transitions in such an applied domain is typically limited. The actual cost of using the proposed framework is influenced by the chosen blockchain network. However, our discussion shows that this cost can be less than USD 1 when the Avalanche network is selected as the deployment environment.
As part of our future work, we plan to investigate the oracle component further to enhance the security and management of biodiversity- and nature-related data. The employed oracle component is currently designed for deployment in Fujairah, where the reported nature-related information and images follow a deterministic behavior. Expanding the management of biodiversity- and nature-related data will increase the coverage area of the proposed oracle component.

Author Contributions

Methodology, K.A., C.Z. and K.M.A.; Software, K.A.; Validation, S.B.M. and K.M.A.; Formal analysis, K.A. and C.Z.; Resources, K.M.A.; Data curation, K.M.A.; Writing – original draft, K.A., S.B.M. and C.Z.; Writing – review & editing, K.A., S.B.M. and C.Z.; Supervision, F.L. All authors have read and agreed to the published version of the manuscript.

Funding

This research received no external funding.

Data Availability Statement

The data presented in this study are available on request from the corresponding author.

Acknowledgments

The authors wish to express their sincere gratitude to James Arruda Salome from Fujairah Research Centre and Adrian Galben from Crown Frams, Fujairah, for their exceptional support with this research project.

Conflicts of Interest

The authors declare no conflicts of interest.

References

  1. Painkra, K.; Painkra, G.; Shaw, S.; Dubey, V.; PK, B. Studies on identification of monofloral/multifloral honey by pollen morphology. Int. J. Adv. Biochem. Res. 2024, 8, 709–716. [Google Scholar]
  2. Hameed, O.M.; Shaker, O.M.; Ben Slima, A.; Makni, M. Biochemical Profiling and Physicochemical and Biological Valorization of Iraqi Honey: A Comprehensive Analysis. Molecules 2024, 29, 671. [Google Scholar] [CrossRef] [PubMed]
  3. Kachinde, J.L.; Fweja, L.W.; Mihale, M.J. Evaluation of the Effect of Handling, Processing, and Storage Practices on the Quality of Honey Products from Selected Honey-producing Villages in Central Tanzania. Asian J. Food Res. Nutr. 2023, 2, 64–72. [Google Scholar]
  4. Popescu, A.; Dinu, T.; Stoian, E.; Serban, V. Beehives and Honey Production—A Brief Statistics in the World and European Union 2000–2022 and Honey Bees Between Interlinked Crisis of Biodiversity, Pollution and Climate Change. Sci. Pap. Ser. Manag. Econ. Eng. Agric. Rural. Dev. 2024, 24, 655–676. [Google Scholar]
  5. Salomea, J.A.; Mirzac, S.B.; Ridouanec, F.L.; Al Taiba Farms, F. Comparison Analysis of Honeydew Honey Production and Quality in Fujairah, UAE and Other Regions of the World: A Review. Int. J. Innov. Sci. Res. Technol. 2022, 7, 55–63. [Google Scholar]
  6. Osaili, T.M.; Bani Odeh, W.A.M.; Al Sallagi, M.S.; Al Ali, A.A.S.A.; Obaid, R.S.; Garimella, V.; Bakhit, F.S.B.; Hasan, H.; Holley, R.; El Darra, N. Quality of Honey Imported into the United Arab Emirates. Foods 2023, 12, 729. [Google Scholar] [CrossRef]
  7. Fakhlaei, R.; Selamat, J.; Khatib, A.; Razis, A.F.A.; Sukor, R.; Ahmad, S.; Babadi, A.A. The toxic impact of honey adulteration: A review. Foods 2020, 9, 1538. [Google Scholar] [CrossRef]
  8. Polakova, K.; Bobková, A.; Demianová, A.; Bobko, M.; Jurčaga, L.; Mesárošová, A.; Čapla, J.; Timoracká, I.; Lidiková, J.; Čeryová, N. Adulteration in Food Industry in 2023-Overview. J. Microbiol. Biotechnol. Food Sci. 2024, 13, e11048. [Google Scholar] [CrossRef]
  9. Brar, D.; Pant, K.; Krishnan, R.; Kaur, S.; Rasane, P.; Nanda, V.; Saxena, S.; Gautam, S. A Comprehensive Review on Unethical Honey: Validation by Emerging Techniques. Food Control 2023, 145, 109482. [Google Scholar] [CrossRef]
  10. Ždiniaková, T.; Lörchner, C.; De Rudder, O.; Dimitrova, T.; Kaklamanos, G.; Breidbach, A.; Respaldiza, A.; Vaz Silva, I.; Paiano, V.; Ulberth, F.; et al. EU Coordinated Action to Deter Certain Fraudulent Practices in the Honey Sector; Technical Report; Publications Office of the European Union: Luxembourg, 2023. [Google Scholar]
  11. Almiani, K.; Alrub, M.A.; Lee, Y.C.; Rashidi, T.H.; Pasdar, A. A Blockchain-Based Auction Framework for Location-Aware Services. Algorithms 2023, 16, 340. [Google Scholar] [CrossRef]
  12. Chen, E.; Qin, B.; Zhu, Y.; Song, W.; Wang, S.; Chu, C.C.W.; Yau, S.S. SPESC-Translator: Towards Automatically Smart Legal Contract Conversion for Blockchain-Based Auction Services. IEEE Trans. Serv. Comput. 2022, 15, 3061–3076. [Google Scholar] [CrossRef]
  13. Wu, S.; Chen, Y.; Wang, Q.; Li, M.; Wang, C.; Luo, X. CReam: A Smart Contract Enabled Collusion-Resistant e-Auction. IEEE Trans. Inf. Forensics Secur. 2019, 14, 1687–1701. [Google Scholar] [CrossRef]
  14. Lee, J.S.; Chew, C.J.; Chen, Y.C.; Wei, K.J. Preserving Liberty and Fairness in Combinatorial Double Auction Games Based on Blockchain. IEEE Syst. J. 2021, 15, 3517–3527. [Google Scholar] [CrossRef]
  15. Liu, L.; Du, M.; Ma, X. Blockchain-Based Fair and Secure Electronic Double Auction Protocol. IEEE Intell. Syst. 2020, 35, 31–40. [Google Scholar] [CrossRef]
  16. Blass, E.O.; Kerschbaum, F. Strain: A Secure Auction for Blockchains. In European Symposium on Research in Computer Security; Lopez, J., Zhou, J., Soriano, M., Eds.; Springer: Cham, Switzerland, 2018; pp. 87–110. [Google Scholar]
  17. AlSuwaidi, M.; Almarri, M.H.; Almi’Ani, K.; Lee, Y.C.; Pasdar, A.; Hameed, Z. Blockchain-based Framework for Housing Establishments Support Services. In Proceedings of the ACSW ’24, 2024 Australasian Computer Science Week, New York, NY, USA, 29 January–2 February 2024; pp. 14–19. [Google Scholar] [CrossRef]
  18. Juma, H.; Shaalan, K.; Kamel, I. A Survey on Using Blockchain in Trade Supply Chain Solutions. IEEE Access 2019, 7, 184115–184132. [Google Scholar] [CrossRef]
  19. Liu, L.; Piao, C.; Jiang, X.; Zheng, L. Research on Governmental Data Sharing Based on Local Differential Privacy Approach. In Proceedings of the 2018 IEEE 15th International Conference on e-Business Engineering (ICEBE), Xi’an, China, 12–14 October 2018; pp. 39–45. [Google Scholar] [CrossRef]
  20. Karaduman, Ö.; Gülhas, G. Blockchain-Enabled Supply Chain Management: A Review of Security, Traceability, and Data Integrity Amid the Evolving Systemic Demand. Appl. Sci. 2025, 15, 5168. [Google Scholar] [CrossRef]
  21. Yigit, E.; Dag, T. Improving Supply Chain Management Processes Using Smart Contracts in the Ethereum Network Written in Solidity. Appl. Sci. 2024, 14, 4738. [Google Scholar] [CrossRef]
  22. Gigli, L.; Zyrianoff, I.; Montori, F.; Aguzzi, C.; Roffia, L.; Di Felice, M. A Decentralized Oracle Architecture for a Blockchain-Based IoT Global Market. IEEE Commun. Mag. 2023, 61, 86–92. [Google Scholar] [CrossRef]
  23. Alrawashdeh, T.; Almi’ani, K.; Choon Lee, Y.; Rashidi, T.H.; Hameed Mir, Z. Provisioning Deterministic Finite Automata for QoS Monitoring in Blockchain Decentralized Applications. IEEE Access 2024, 12, 77379–77392. [Google Scholar] [CrossRef]
  24. Vu, N.; Ghadge, A.; Bourlakis, M. Blockchain adoption in food supply chains: A review and implementation framework. Prod. Plan. Control 2023, 34, 506–523. [Google Scholar] [CrossRef]
  25. Risso, L.A.; Ganga, G.M.D.; Godinho Filho, M.; de Santa-Eulalia, L.A.; Chikhi, T.; Mosconi, E. Present and future perspectives of blockchain in supply chain management: A review of reviews and research agenda. Comput. Ind. Eng. 2023, 179, 109195. [Google Scholar] [CrossRef]
  26. Raza, Z.; Haq, I.U.; Muneeb, M. Agri-4-all: A framework for blockchain based agricultural food supply chains in the era of fourth industrial revolution. IEEE Access 2023, 11, 29851–29867. [Google Scholar] [CrossRef]
  27. Shahid, A.; Almogren, A.; Javaid, N.; Al-Zahrani, F.A.; Zuair, M.; Alam, M. Blockchain-Based Agri-Food Supply Chain: A Complete Solution. IEEE Access 2020, 8, 69230–69243. [Google Scholar] [CrossRef]
  28. Azevedo, P.; Gomes, J.; Romão, M. Supply chain traceability using blockchain. Oper. Manag. Res. 2023, 16, 1359–1381. [Google Scholar] [CrossRef]
  29. Rünzel, M.A.S.; Hassler, E.E.; Rogers, R.E.L.; Formato, G.; Cazier, J.A. Designing a Smart Honey Supply Chain for Sustainable Development. IEEE Consum. Electron. Mag. 2021, 10, 69–78. [Google Scholar] [CrossRef]
  30. Paunović, M.; Alizadeh, Z. Conceptual Blockchain Model for Honey Supply Chain System. In Proceedings of the 5th International Scientific Conference Village and Agriculture, Bijeljina, Republika Srpska, Bosnia and Herzegovina, 30 September 2022; Bijeljina University: Bijeljina, Republic of Srpska, Bosnia and Herzegovina, 2022. [Google Scholar]
  31. Marchesi, L.; Mannaro, K.; Marchesi, M.; Tonelli, R. Automatic Generation of Ethereum-Based Smart Contracts for Agri-Food Traceability System. IEEE Access 2022, 10, 50363–50383. [Google Scholar] [CrossRef]
  32. Dobbins, A.; Sprinkle, A.; Hadley, B.; Cazier, J.; Wilkes, J. Blocks for bees: Solving bee business problems with blockchain technology. In Proceedings of the Appalachian Research in Business Symposium, East Tennessee State University, Johnson City, TN, USA, 22–23 March 2018; Volume 1. [Google Scholar]
  33. Madhwal, Y.; Pieber, E.; Yanovich, Y.; Yakushkina, T. Smart Contract Based Honey Production Supply Chain. In Proceedings of the ICBTA ’22—2022 5th International Conference on Blockchain Technology and Applications, New York, NY, USA, 12–14 July 2023; pp. 70–76. [Google Scholar] [CrossRef]
  34. Lukovac, P.; Miletić, A.; Radenković, B. A System for Tracking Organic Honey Production Using Blockchain Technologies. In International Symposium SymOrg; Springer: Cham, Switzerland, 2022; pp. 239–254. [Google Scholar]
  35. Redmon, J.; Divvala, S.; Girshick, R.; Farhadi, A. You only look once: Unified, real-time object detection. In Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition, Las Vegas, NV, USA, 27–30 June 2016; pp. 779–788. [Google Scholar]
  36. Breunig, M.M.; Kriegel, H.P.; Ng, R.T.; Sander, J. LOF: Identifying Density-Based Local Outliers. In Proceedings of the SIGMOD ’00—2000 ACM SIGMOD International Conference on Management of Data, New York, NY, USA, 16–18 May 2000; pp. 93–104. [Google Scholar] [CrossRef]
Figure 1. The proposed framework’s conceptual workflow.
Figure 1. The proposed framework’s conceptual workflow.
Information 16 00626 g001
Figure 2. The steps of submitting a honey trade service.
Figure 2. The steps of submitting a honey trade service.
Information 16 00626 g002
Figure 3. The token generating process.
Figure 3. The token generating process.
Information 16 00626 g003
Figure 4. An agreement representation using a complete graph.
Figure 4. An agreement representation using a complete graph.
Information 16 00626 g004
Figure 5. The steps of processing a constraints-related image.
Figure 5. The steps of processing a constraints-related image.
Information 16 00626 g005
Figure 6. Temperature recordings over the four seasons.
Figure 6. Temperature recordings over the four seasons.
Information 16 00626 g006
Figure 7. The steps of the adopted experimental methodology.
Figure 7. The steps of the adopted experimental methodology.
Information 16 00626 g007
Figure 8. A sequence diagram showing the steps of token minting.
Figure 8. A sequence diagram showing the steps of token minting.
Information 16 00626 g008
Figure 9. The impact of the number of transitions on gas consumption.
Figure 9. The impact of the number of transitions on gas consumption.
Information 16 00626 g009
Figure 10. The impact of the number of constraints on gas consumption.
Figure 10. The impact of the number of constraints on gas consumption.
Information 16 00626 g010
Figure 11. The impact of the e value on accuracy.
Figure 11. The impact of the e value on accuracy.
Information 16 00626 g011
Figure 12. Image processing and YOLOv8 training scheme.
Figure 12. Image processing and YOLOv8 training scheme.
Information 16 00626 g012
Table 1. Event types.
Table 1. Event types.
Event Type ( e t )Source Type ( s t )Description
Temperature (t)SensorTemperature reading
Location (l)GPS (IoT)Location coordinates
Light (l)SensorLight level
Humidity (h)SensorHumidity level
Note: Event location ( l e ) is used to identify the location of the source.
Table 2. Smart contracts’ main functionalities.
Table 2. Smart contracts’ main functionalities.
ContractFunctionDescription
TradetraverseProcess a new trade-related transaction received from logistic personnel or an IoT device.
defineQoSAgreementDefine trade-related QoS constraints.
initiateTradeHandle and record the details related to honey trade service.
createSellOrderCreate and store the new sell order.
DIDregisterIoTCalled by the beekeeping business to register an IoT device.
registerPersonnelCalled by the beekeeping business to register logistics personnel.
registerBeekeepingCalled to register a new beekeeping business.
de-registerBeekeepingCalled to unregister a beekeeping business.
de-registerIoTUsed to unregister an IoT device.
de-registerPersonnelUsed to unregister logistics personnel.
MMmintTokensMint a new single non-fungible token and its associated fungible tokens.
burnTokensUsed to burn tokens.
transferFungibleTokensUsed to transfer fungible tokens between addresses.
OracleprocessImageCheck the authenticity of the received image.
processReadingCheck the authenticity of the received sensor reading.
Table 3. Cost of transactions.
Table 3. Cost of transactions.
Transaction TypeGas UsedCost (ETH)
traverse428,5710.003
defineQoSAgreement1,085,7140.0076
initiateTrade642,8570.0045
createSellOrder31,1090.000217
registerBeekeeping71,1340.00049
de-registerBeekeeping30,1720.00021
mintTokens172,8960.0012
burnTokens37,1720.00026
transferFungibleTokens30,9570.00021
contracts deployment6,560,9810.04592
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Share and Cite

MDPI and ACS Style

Almiani, K.; Mirza, S.B.; Zufferey, C.; Alyammahi, K.M.; Lamghari, F. Fujairah Honey Chain (FHC): A Blockchain Framework for Monitoring Honey Production. Information 2025, 16, 626. https://doi.org/10.3390/info16080626

AMA Style

Almiani K, Mirza SB, Zufferey C, Alyammahi KM, Lamghari F. Fujairah Honey Chain (FHC): A Blockchain Framework for Monitoring Honey Production. Information. 2025; 16(8):626. https://doi.org/10.3390/info16080626

Chicago/Turabian Style

Almiani, Khaled, Shaher Bano Mirza, Camille Zufferey, Khawla M. Alyammahi, and Fouad Lamghari. 2025. "Fujairah Honey Chain (FHC): A Blockchain Framework for Monitoring Honey Production" Information 16, no. 8: 626. https://doi.org/10.3390/info16080626

APA Style

Almiani, K., Mirza, S. B., Zufferey, C., Alyammahi, K. M., & Lamghari, F. (2025). Fujairah Honey Chain (FHC): A Blockchain Framework for Monitoring Honey Production. Information, 16(8), 626. https://doi.org/10.3390/info16080626

Note that from the first issue of 2016, this journal uses article numbers instead of page numbers. See further details here.

Article Metrics

Back to TopTop