Security and privacy for Binance-based integrated blockchain for blood supply chain management systems

Introduction

Blood is one of the main fluids in the human body. It helps to support the organs with the necessary and useful things needed for survival. As the demand for blood is exceeding all the medical requirements, the governments educate their citizens about blood donation by organizing awareness programs. The number of donors in the years 2018–2019 was estimated to be 136,908 donors, contributing to a total of 216,639 donations (Mandal et al., 2023; Hawashin et al., 2021). In general, every 56 days, mostly healthy individuals give blood donations. The World Health Organization estimates that the annual amount of blood donations collected is 112.5 million units, which is approximately 50 million liters, per year (Kim, Kim & Kim, 2020). However, the lack of blood donors has increased with the emergence of new diseases. The requirement to enable reliable and efficient blood donation management has been raised. Blood management for patients is a huge and complex task (Musamih et al., 2021). The current system of blood management contains various restrictions and gaps that limit the supply chain to perform efficiently. Hannon (Kumar et al., 2024) reported that the blood component wastage rates usually run from 1% to 5% and that the amount of disposal is not shared or visible to clarify the reason behind it. Therefore, any development or improvement in this regard is an important consideration in providing efficient health care globally.

Maintaining secure communications for sensitive healthcare information is paramount for both patients and providers. However, the widespread adoption of cloud-based solutions introduces significant concerns regarding data security, especially with the inclusion of third-party services (Nazir et al., 2023). Fundamental to managing data security is the Confidentiality, Integrity, and Availability (CIA) triad, which emphasizes confidentiality, integrity, and availability. Blockchain technology offers a promising solution to enhance the performance, management, and security of information systems, primarily due to its inherent non-repudiation feature (Ekanayake & Halgamuge, 2021). The Binance Smart Chain (BSC) has emerged as an ideal candidate for managing blood resources, thanks to its compatibility with the Ethereum Virtual Machine (EVM) and optimized transaction performance (Gia et al., 2023).

AdaBoost is vital in optimizing the prediction of available blood units concerning geographical location and blood type. AdaBoost combines many “weak classifiers” to get one strong predictive model. Similarly, calculations of geodesic distance are necessary to find nearby blood banks relative to the location of a user (Ramakrishna et al., 2023). These calculations show, among other things, the shortest distance between two points on the Earth’s surface, enabling the accurate filtering of blood banks within a specified radius from the user.

Related work

Hawashin et al. (2022) proposes a blockchain-based system for the management of the blood donation supply chain, ensuring transparency, security, and auditability. It uses a private Ethereum blockchain integrated with InterPlanetary File System (IPFS), used for storing large data files. It employs smart contracts for the core functionalities and dApp at the frontend interface, while software devices can be hooked with the former through Application Programming Interfaces (APIs). It is one of the permissioned Ethereum blockchain-based solutions providing all privacy and authorization controls. It has not been tested or deployed on the real network, it lacks analysis on performance and scalability, and very limited security analysis and details on what roles exist and the sort of access controls that would be required.

Fiore et al. (2023) proposes the current state of blockchain utilization in healthcare supply chains, pointing out that private/consortium blockchains have largely been implemented due to control, confidentiality, lower energy use, and cost benefits; Ethereum is a widely implemented platform; smart contracting is to support automation; and main blockchain principles regarding accountability, security, transparency, confidentiality, and reliability are covered. These proposed solutions are still not technologically mature and require many studies on scalability and real-world applications. Only one real-world application shows the potential of blockchain to reduce costs and enhance efficiency.

Imamoglu, Topcu & Aydin (2023) proposed an intense analysis of 265 articles in the Web of Science database, making use of bibliometric and network analyses to dissect the literature on the blood supply chain. Data visualization and statistical analysis tools help provide insights into deeper research trends and gaps within the blood supply chain research. The methodology used includes a mixed review methodology, which integrates technology-driven approaches toward providing a comprehensive understanding of the literature on the blood supply chain, the identification of gaps within the research, and the future directions. The limitations of this study are that it is dependent on English-language publications, hence potentially excluding relevant research from linguistic diversity.

Roozkhosh, Pooya & Agarwal (2023) aimed at supply chain resilience improvement by predicting the blockchain acceptance rate in blood donation and supply chains. Herein, it makes a case for the hybrid combination of Hyperledger Fabric and Caliper with system dynamics in simulating the long-term behavior of blockchain acceptance rate (BAR) and machine learning techniques like Multilayer Perceptron (MLP) and Support Vector Regression (SVR) for its prediction. Ensuring that the issues of implementation challenges and data privacy and security, scalability, and performance limitations have been fully addressed, the study concludes by asserting that resilient supply chains are significantly influenced by inflationary control, R&D, exchange rates, and political risks, thereby underlining the need for effective analysis in these respects and eliciting proper policy making.

Emmanuel et al. (2023) proposed the use of machine learning in drug supply management chains in the case of outbreaks of infectious diseases, with a view of predictive parameters for spread of diseases like COVID-19, influenza, dengue, malaria, and Ebola. Some shared methods applied are neural networks, Bayesian networks, and reinforcement learning. Predictive parameters include demographic data, environmental factors, mobility data, and social media data; among them, demographic data is most used. The study would really increase the need for more efficacious research into the topic, especially in developing countries. It does not mention any blockchain technology or application, but only a systematic literature review on machine learning in drug supply chain management.

Le et al. (2022) propose BloodChain, a blockchain-based system using Hyperledger Fabric to manage blood information and improve the blood supply chain. It provides detailed information about blood consumption and its disposal to recipients. The implementation performance will be benchmarked through the transaction-per-second (TPS) metric by means of Hyperledger Caliper. BloodChain deploys a permissioned blockchain with an inbuilt governance model that assures trust among defined participants, doing away with the requirement of expensive mining. This might include governance and participant policy management, data privacy and security, and scalability and performance challenges, as indirectly reflected in latency results.

Trong et al. (2022) proposed a blockchain-based system for the management of the supply chain of blood using Hyperledger Fabric. The system provides a blockchain architecture for decentralized data storage, smart contracts for data control, and proof-of-concept implementation with evaluations that prove its benefits and feasibility. The current implementation, however, only covers a subset of processes, lacking an authorization mechanism across stakeholders. It potentially brings out the use of Hyper-ledge Fabric in enhancing transparency, security, and data integrity of the blood supply chain management but needs further work in bringing it fully to end-to-end.

Ben Elmir, Hemmak & Senouci (2023) aimed at proposing a smart platform for the enhancement of the blood supply chain. This will be achieved through the development of an information system that spans from the receipt of blood donation to the utilization stage. The model enhances coordination via a centralized database. The paper proposes the reduction in uncertainty related to blood demand through machine learning and time series forecasting models such as Autoregressive Moving Average (ARMA) and Autoregressive Integrated Moving Average (ARIMA). It also develops a blood donor classifier using artificial neural networks (ANN), Logistic Regression, Support Vector Machine (SVM), Decision Trees, K-Nearest Neighbors (KNN), and Naive Bayes. Limitations of the work include that there is a need for clear-cut statistical procedures considering resiliency and effectiveness, simplicity of the solution, and specialist expertise in some techniques.

Khalid et al. (2023) proposed blockchain-based decentralized storage systems, their benefits, solutions of challenges, and deployment strategies. It gives an analysis of applications such as Sia, Filecoin, and Storj against cloud storage, discussing various advantages and disadvantages. Security issues are addressed in the survey, some solutions are shown, and future research is suggested. However, it does not provide an in-depth analysis on the implementation challenges, detailed performance comparison, scalability issues, cost-effectiveness, and truly regulatory and legal implications. In a nutshell, the limitations include not discussing the regulatory and legal implications of using blockchain for decentralized data storage, which can turn out to be a big hindrance to its wide adoption.

Abdullah et al. (2022) proposed a decentralized blood donation system on the Ethereum blockchain to attain transparency, traceability, and safety in blood transfusion procedures. On this platform, peer-to-peer interactions can be facilitated because of token incentives to the donors through smart contracts. Since there are no hierarchical procedures, the turnaround time is reduced with full traceability through the blockchain. Along with that, some benefits include transparency and traceability of blood donations. The scalability challenges and the need for a wide adoption of the system among stakeholders might not permit the implementation of such a system’s traceability.

Methodology

The proposed system architecture for the blood supply chain management system (B-SCM) is depicted in Fig. 1. B-SCM comprises different entities that include Admin i.e., National AIDS Control Organization (NACO), Collection Point (CP), Medical Centre (MC), Transporter (TS), and Donor (DR). The system contains four phases—Registration phase, Login and authentication phase, Logistics Management, and User request (Eghtesadifard & Jozan, 2022). The model runs on a system equipped with an 11^th Generation Intel Core^TM i7-11390H processor, 16 GB RAM, a 64-bit Windows 10 operating system, and a 1 TB hard drive. The AdaBoost model was implemented using Python 3.9 with the scikit-learn library.

Registration phase

Entity registration phase

Figure 2 depicts the entity Registration phase which explains the process of each entity registration. B-SCM has three entities $\mathbb{E}$ as in Eq. (1) that are solely registered by the central authority NACO. Each entity has a wallet address that is technically analogous to the public key of the entity symbolically $P{K}_E$ as represented in Eqs. (2) and (3).

(1) $$\mathbb{E}=⟨CP,MC,TS⟩$$

(2) $$⟨⟨\mathrm{W}\mathrm{a}\mathrm{l}\mathrm{l}\mathrm{e}\mathrm{t}\mathrm{A}\mathrm{d}\mathrm{d}\mathrm{r}\mathrm{e}\mathrm{s}\mathrm{s}\equiv \mathrm{P}\mathrm{u}\mathrm{b}\mathrm{l}\mathrm{i}\mathrm{c}\mathrm{k}\mathrm{e}\mathrm{y};{\mathrm{P}\mathrm{K}}_E⟩⟩$$

(3) $$⟨⟨\mathrm{P}\mathrm{a}\mathrm{s}\mathrm{s}\mathrm{w}\mathrm{o}\mathrm{r}\mathrm{d}\equiv \mathrm{P}\mathrm{r}\mathrm{i}\mathrm{v}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{K}\mathrm{e}\mathrm{y};P{R}_E⟩⟩.$$

Step 1: NACO $⟺⟨P{K}_{Owner}\parallel P{R}_{Owner}⟩$; NACO $\to ⟨P{K}_E⟩$; NACO can access the dApp using $⟨P{K}_{Owner},P{R}_{Owner}⟩$. Once NACO registers into B-SCM, it is liable for registering $\mathbb{E}$ in B-SCM with $⟨P{K}_E⟩$.

Step 2: $\mathbb{E}$ $\to ⟨⟨P{K}_E\parallel P{R}_E\parallel \mathrm{N}\mathrm{a}\mathrm{m}\mathrm{e}\parallel \mathrm{L}\mathrm{O}\mathrm{C}⟩⟩$

$\mathbb{E}$ registers into the system with $P{K}_E$, Name, and Location. NACO validates the entity by considering the standards of the entity: (available (AV), accessible (AC), affordable (AF), safe (SF), and of standard quality (SQ)), i.e., $\mathbb{E}$ should possess the standards of NACO, and then it is considered to be valid as in Eq. (4).

(4) $$\mathrm{i}\mathrm{s}\mathrm{V}\mathrm{a}\mathrm{l}\mathrm{i}\mathrm{d}\left(\mathbb{E}\right)\to ⟨\begin{array}{cc}AV\to \mathrm{T}\mathrm{r}\mathrm{u}\mathrm{e};& AC\to \mathrm{T}\mathrm{r}\mathrm{u}\mathrm{e};\\ AF\to \mathrm{T}\mathrm{r}\mathrm{u}\mathrm{e};& SF\to \mathrm{T}\mathrm{r}\mathrm{u}\mathrm{e};\\ SQ\to \mathrm{T}\mathrm{r}\mathrm{u}\mathrm{e}& \end{array}⟩.$$

Step 3: MM $\to P{K}_{Owner}$;

The Metamask connected to $P{K}_{Owner}$ will be initiated, and the transaction of registering $\mathbb{E}$ will be enforced.

Step 4: If $⟨P{K}_{Owner},P{R}_{Owner}⟩$ is valid, the transaction will proceed further by processing $\mathbb{E}$ to MM and subsequently adding $\mathbb{E}$ into B-SCM. Otherwise, the access of $\mathbb{E}$ is denied, as illustrated in Eqs. (5), (6), (7).

(5) $$\mathrm{a}\mathrm{d}\mathrm{d}\mathrm{E}\mathrm{n}\mathrm{t}\mathrm{i}\mathrm{t}\mathrm{y}\left(\mathbb{E}\right)\to \left(\mathbb{E}⟼MM\right)\cup (\mathbb{E}\bowtie B-SCM)$$

(6) $$\mathrm{d}\mathrm{e}\mathrm{n}\mathrm{y}\mathrm{E}\mathrm{n}\mathrm{t}\mathrm{i}\mathrm{t}\mathrm{y}\left(\mathbb{E}\right)\to \left(\mathbb{E}\nRightarrow \mathrm{B}-\mathrm{S}\mathrm{C}\mathrm{M}\right)$$

(7) $$\left(P{K}_{Owner}\parallel P{R}_{Owner}==\mathrm{E}\mathrm{q}.(4)\right):\mathrm{E}\mathrm{q}.(5)?\{\mathrm{E}\mathrm{q}.(6)\}.$$

Donor registration phase

CP registers DR in B-SCM, validating the DR as depicted in Fig. 3 and adhering to the regulatory standards of NACO (Rekha & Siddappa, 2023) as follows:

Step 1: CP $\to$DR;

DR $\to \sum \left(\mathrm{n}\mathrm{a}\mathrm{m}\mathrm{e},A,G,\mathrm{W}\mathrm{t},\mathrm{H}\mathrm{t},\mathrm{L}\mathrm{o}\mathrm{c},\mathrm{P}\mathrm{h}\mathrm{n}\right)$; CP collects the details of DR, which include name, age, gender, weight, height, location, and phone number.

(8) $$\mathrm{i}\mathrm{s}\mathrm{E}\mathrm{l}\mathrm{i}\mathrm{g}\mathrm{i}\mathrm{b}\mathrm{l}\mathrm{e}\left(\mathrm{D}\mathrm{R}\right)\to ⟨\begin{array}{c}\mathrm{W}\mathrm{t}\ge 50\mathrm{k}\mathrm{g}\cup \mathrm{A}\ge 18\hfill \\ \mathrm{a}\mathrm{n}\mathrm{d}\mathrm{A}\le 75\hfill \end{array}⟩.$$

Step 2: After verifying whether the respective DR is eligible, as illustrated in Eq. (8), for donating blood by the details collected in Step 1, $⟨P{K}_{DR}⟩$ is shared with CP and registered on B-SCM.

Step 3: DR $\to$ B-SCM: DR can access B-SCM with $⟨P{K}_{DR},P{R}_{DR}⟩$ and then confirm their details. This ensures two-step authentication of DR details to ensure safe and secure blood maintenance (Ghadge et al., 2022).

Login and authentication phase

Each entity upon registration goes through the login and authentication phase as shown in Fig. 4 by following the steps below:

Step 1: $⟨⟨MM\to A{D}_E;A{D}_E\equiv P{K}_E;P{W}_E\equiv P{R}_E⟩⟩$; $\mathbb{E}$ enters $⟨A{D}_E,P{W}_E⟩$ to log into B-SCM. It enables Metamask (MM) and performs a three-step mutual authentication. This includes verifying the existence of the address of $\mathbb{E}$ in MM and cross-checking the authenticity of $\mathbb{E}$.

Step 2: $⟨⟨MM\to A{D}_{CP};A{D}_{CP}\equiv P{K}_{CP};P{W}_{CP}\equiv P{R}_{CP}⟩⟩$; each $\mathbb{E}$ has its functions to perform in dApp. CP has $⟨A{D}_{CP},P{W}_{CP}⟩$ that are verified by MM for mutual authentication.

Step 3: $⟨⟨MM\to A{D}_{MC};A{D}_{MC}\equiv P{K}_{MC};P{W}_{MC}\equiv P{R}_{MC}⟩⟩$; CP can receive blood from donors and supply it to MC as requested, whereas MC has $⟨A{D}_{MC},P{W}_{MC}⟩$ that are verified by MM for mutual authentication.

Step 4: $⟨⟨MM\to A{D}_{TS};A{D}_{TS}\equiv P{K}_{TS};P{W}_{TS}\equiv P{R}_{TS}⟩⟩$; TS supplies the blood from CP to MC, whereas TS has $⟨A{D}_{TS},P{W}_{TS}⟩$ that are verified by MM for mutual authentication.

Logistics management

The blood inventory management ranges from the NACO to the user (Kumaran & Mohan, 2023), and all these logistics can be implemented by the entities in B-SCM as depicted in Fig. 5. The following steps outline the process:

Step 1: $MC\to CP;CP\to ⟨I{D}_{CP}\parallel I{D}_{MC}\parallel N\parallel BG⟩$; the supply chain process begins when a patient requires blood at a MC. The MC contacts the CP with the CP’s identification number, the MC’s own identification number for verification purposes, the number of blood units needed, and the required blood group (Subramanian, 2024).

Step 2: $CP\to MC$; CP evidences the MC and checks for availability of the intended blood group (BG) and required number of blood units as shown in Eq. (9).

(9) $${\mathrm{B}\mathrm{G}}_{availability}\to ⟨N_{available}>N⟩\to \mathrm{T}\mathrm{r}\mathrm{u}\mathrm{e}.$$

Step 3: $CP\to MC$; $MC\to ⟨I{D}_{DR}\parallel I{D}_{MC}\parallel N\parallel D{R}_{Info}⟩$; later, CP sends $⟨\mathrm{I}{\mathrm{D}}_{DR}\parallel \mathrm{I}{\mathrm{D}}_{MC}\parallel N\parallel \mathrm{D}{\mathrm{R}}_{Info}⟩$ to MC, which ensures the safety, security, and quality of blood inventory management.

Step 4: $DR\to MC$; $D{R}_{Info}=\int ⟨BG\parallel HIV\parallel LIV\parallel HB\parallel BP⟩$; with the $\mathrm{I}{\mathrm{D}}_{DR}$, MC confirms the blood quality as illustrated in Eqs. (10) and (11) by verifying the $\mathrm{D}{\mathrm{R}}_{\mathrm{I}\mathrm{n}\mathrm{f}\mathrm{o}}$ that comprises information about health standards according to NACO.

(10) $${\mathrm{D}\mathrm{R}}_{\mathrm{S}\mathrm{t}\mathrm{a}\mathrm{n}\mathrm{d}\mathrm{a}\mathrm{r}\mathrm{d}\mathrm{s}}\to ⟨\mathrm{\neg }\mathrm{H}\mathrm{I}\mathrm{V}\parallel \mathrm{\neg }\mathrm{L}\mathrm{I}\mathrm{V}\parallel \mathrm{\neg }\mathrm{B}\mathrm{P}\parallel \mathrm{H}\mathrm{B}>12⟩$$

(11) $$\mathrm{B}\mathrm{l}\mathrm{o}\mathrm{o}\mathrm{d}\mathrm{Q}\mathrm{u}\mathrm{a}\mathrm{l}\mathrm{i}\mathrm{t}\mathrm{y}(\mathrm{B}\mathrm{U})\to ({\mathrm{D}\mathrm{R}}_{\mathrm{I}\mathrm{n}\mathrm{f}\mathrm{o}}\approx {\mathrm{D}\mathrm{R}}_{\mathrm{S}\mathrm{t}\mathrm{a}\mathrm{n}\mathrm{d}\mathrm{a}\mathrm{r}\mathrm{d}\mathrm{s}}):\mathrm{T}\mathrm{r}\mathrm{u}\mathrm{e}?\mathrm{F}\mathrm{a}\mathrm{l}\mathrm{s}\mathrm{e}.$$

Step 5: On confirming the blood quality, MC assigns an ACCEPTED/REJECTED tag to the blood unit (BU) received as illustrated in Eq. (12).

(12) $$\mathrm{B}\mathrm{U}\to \left(\mathrm{E}\mathrm{q}.(11)==\mathrm{T}\mathrm{r}\mathrm{u}\mathrm{e}\right):\mathrm{A}\mathrm{C}\mathrm{C}\mathrm{E}\mathrm{P}\mathrm{T}\mathrm{E}\mathrm{D}?\mathrm{R}\mathrm{E}\mathrm{J}\mathrm{E}\mathrm{C}\mathrm{T}\mathrm{E}\mathrm{D}.$$

Step 6: $TS\to User$; $RCInfo\Rightarrow ⟨A{D}_{RC},Name,Phone,B{G}_{RC}⟩$; TS will send the ACCEPTED blood units to the end user. TS collects recipient information $\{\mathrm{R}{\mathrm{C}}_{\mathrm{I}\mathrm{n}\mathrm{f}\mathrm{o}}\}$ for safe and secure logistics management.

User request

The blood bank dataset utilized for this study was sourced from the central government’s official website, eRaktKosh (Ministry of Health and Family Welfare, Government of India, 2016). The data was systematically organized into a structured format of rows and columns, enabling efficient preprocessing and model training. Specifically, the dataset comprises 106 entries across eight distinct attributes, providing a robust foundation for analysis and model development (Ministry of Health and Family Welfare, Government of India, 2025). This study employed a purposive sample of 106 participants, chosen for accessible direct engagement with the hospital system under evaluation. While the sample may seem limited, it aligns with similar exploratory research in health informatics. Future work will expand this to multiple institutions across different regions to improve generalizability. The user can request the intended BG and search for the nearest blood banks (BB) as follows:

Step 1: $User\to Location$; $Location\Rightarrow ⟨LA{T}_{User},LO{N}_{User}⟩$; the user enables location services by logging into the dApp, which retrieves the user’s latitude and longitude.

Step 2: $User\to ⟨BG,N⟩$; the user enters the required blood group and the number of necessary blood units into B-SCM. The $⟨\mathrm{L}\mathrm{A}{\mathrm{T}}_{\mathrm{B}\mathrm{B}},\mathrm{L}\mathrm{O}{\mathrm{N}}_{\mathrm{B}\mathrm{B}}⟩$ of the blood banks are fetched, and the geodesic distance is calculated as shown in the following equations:

(13) $$\alpha ={\sin }^2\left(\frac{\mathrm{\Delta }\psi }{2}\right)+\cos \left({\mathrm{L}\mathrm{A}\mathrm{T}}_{\mathrm{U}\mathrm{s}\mathrm{e}\mathrm{r}}\right)\times \cos \left({\mathrm{L}\mathrm{A}\mathrm{T}}_{\mathrm{B}\mathrm{B}}\right)\times {\sin }^2\left(\frac{\mathrm{\Delta }\phi }{2}\right)$$

(14) $$\beta =2\times \arctan 2\left(\sqrt{\alpha },\sqrt{1\text{-}\alpha }\right)$$

(15) $$\gamma =\mathbb{R}\times \beta$$

(16) $$\mathrm{\Delta }\psi =({\mathrm{L}\mathrm{A}\mathrm{T}}_{\mathrm{U}\mathrm{s}\mathrm{e}\mathrm{r}}-{\mathrm{L}\mathrm{A}\mathrm{T}}_{\mathrm{B}\mathrm{B}})\times \frac{\pi }{180}$$

(17) $$\mathrm{\Delta }\phi =({\mathrm{L}\mathrm{O}\mathrm{N}}_{\mathrm{U}\mathrm{s}\mathrm{e}\mathrm{r}}-{\mathrm{L}\mathrm{O}\mathrm{N}}_{\mathrm{B}\mathrm{B}})\times \frac{\pi }{180}.$$

Step 3: The AdaBoost model identifies the nearest blood banks to the user based on $⟨\mathrm{L}\mathrm{A}{\mathrm{T}}_{\mathrm{B}\mathrm{B}},\mathrm{L}\mathrm{O}{\mathrm{N}}_{\mathrm{B}\mathrm{B}}⟩$ and filters the blood banks by checking blood availability $⟨\mathrm{B}\mathrm{G},\mathrm{N}⟩$.

Step 4: The model filters blood banks based on the BG availability that matches with the user request along with the location that is nearest to the user’s location.

Figure 6 illustrates the AdaBoost model training pipeline, which comprises several stages: data pre-processing, feature engineering, data splitting, model training, and displaying the final list of selected blood banks and donors. During data pre-processing, the dataset was first screened for missing values, duplicates, and outliers. Missing values in critical fields (e.g., blood group, geographic coordinates, or availability status) were either imputed using domain-informed defaults or removed if imputation risked introducing bias. Duplicate entries were eliminated using record linkage based on blood bank names and GPS coordinates. Outliers in numerical attributes (e.g., extreme or incorrect latitude/longitude values) were detected using interquartile range (IQR) and Mahalanobis distance methods. Furthermore, categorical attributes were standardized to maintain consistency in labels (e.g., “B+” and “B Positive” unified).

The cleaned dataset ensured higher model reliability and minimized noise during training. Feature engineering followed, involving one-hot encoding for blood groups and normalization of geospatial coordinates. Independent variables included user-provided latitude and longitude, the requested blood group (BG), and required units (N), while dependent variables were blood availability and system-generated selection of suitable blood banks. The model applied the Haversine formula for precise geodesic distance calculations, enabling spatial filtering of blood banks. The curated dataset was then partitioned into training and validation sets, and used to train the AdaBoost classifier—selected for its high accuracy in imbalanced datasets. The final output lists eligible blood banks based on both proximity and stock availability.

The AdaBoost algorithm was selected for its high classification accuracy and ability to handle imbalanced datasets, which are common in donor availability and blood stock prediction scenarios. Its ensemble learning approach, combining weak learners to form a strong predictor, makes it well-suited for our use case involving multiple features such as donor location, blood group, availability history, and urgency level. The AdaBoost model is implemented off-chain within the decision-support layer of the system. Performing such computations on-chain is not feasible due to gas cost constraints and the computational limitations of blockchain environments.

As shown in Table 2, blood should only be collected by a licensed blood bank, considering certain factors. Blood should be drawn from the donor by a qualified physician or under their supervision by trained assistants. The blood is then stored over a blockchain using the proposed distributed application (dApp).

Table 2:

Considered factors in the index of blood donor profile.

Factors	Characteristics	Scoring mechanisms
Donor recruitment	Voluntary
	Non-remunerated, Low risk, Safe and healthy donors
Name & Address		Govt. authorized Documents
Donor selection	Age	18 and 65 years
	Hemoglobin or packed Cell Volume (Hematocrit)	Hemoglobin more than 12.0 gm/dl or Hematocrit less than 36%
	Weight	45–55 Kg–350 ml collection
		55 Kg–450 ml collection
	Blood pressure	Systolic blood pressure: 100 and 160 mm
		Diastolic pressure: 60–90 mm
	Temperature	37.5 C/99.5 F
	Pulse	60 to 100 beats per minute
Blood group	Temp & Expiry date	Use before 12 weeks
Medical history	Not suffering from any serious illness	Ex: malignant disease, epilepsy, bronchial asthma, diabetes, excessive menstrual bleeding, cardio-vascular conditions, renal disease, allergic diseases, abnormal bleeding tendency.
		Deferred permanently
	HIV, HBsAg/HCV	Deferred permanently
	Swollen glands, Persistent cough,
	Unexplained weight loss,
	Night sweats/fever, Skin rashes and skin infections, diarrhea
	Alcohol, Any drug abuse	Not accepted if not providing reliable answers to the standard questionnaire

DOI: 10.7717/peerj-cs.3123/table-2

The implemented system incorporates predefined rules within Access Control Lists (ACLs), outlined in Table 3, to safeguard the security and privacy of sensitive user, donor, and blood bank information. These rules ensure that digitalization processes are securely managed under authorized control, thereby protecting highly confidential details throughout the system. This comprehensive approach to access control ensures that only authorized entities can interact with specific functionalities, maintaining data integrity and regulatory compliance in the B-SCM system.

Table 3:

Rules defined in access control lists.

Rule	Entity	Access control	Justification
R1	NACO	Register entities	NACO is authorized to register the central entities (CP, MC, TS) into B-SCM. This ensures that only authorized entities, validated by NACO, are included in the system, maintaining data integrity and regulatory compliance.
R2	CP	Register donors	CP can register donors into B-SCM after collecting and validating donor information. This rule ensures that only validated donors meeting regulatory standards can participate in the blood supply chain.
R3	E (CP, MC, TS)	Access B-SCM	Entities (CP, MC, TS) can access their respective operations within B-SCM using their public-private key pairs. This rule implements mutual authentication to ensure secure access and operation within the dApp.
R4	CP	Manage logistics	CP manages logistics such as blood inventory from collection points to medical centers. This rule allows CP to maintain efficient supply chain operations, verifying blood availability and quality before distribution.
R5	MC	Receive blood units	MC receives blood units from CP after verification of donor and blood quality. This rule ensures that only blood meeting specified health standards and donor eligibility criteria is accepted by MC.
R6	User	Request blood units	Users can request blood units based on blood group and location. This rule facilitates user access to critical blood supply information, ensuring efficient matching with available donors and blood banks.

DOI: 10.7717/peerj-cs.3123/table-3

Results and discussions

The Home page of blood block supply chain management system (BB-SCM) shown in Fig. 7 depicts the entities involved in BB-SCM where each entity has been provided with Login and Register options. The smart contracts written ensure that only the owner i.e., NACO can register all the entities. Figure 8 depicts all entities registered in BB-SCM by the Admin which details the public address, name, and contact number of each entity E. An entity is registered as a transaction initiated by the Admin that ensures authorization. As soon as the contract has been confirmed in Metamask, the dApp pops up a message showing the registration has been completed. CP can register donors since blood is collected by CP which can be seen in Fig. 9 As per NACO standards, the details to be collected from the donor by CP are name, age, weight, gender, and mobile number. The public wallet address is collected in addition, to ensure donor authorization. Figure 10 depicts the process of distributing blood from the CP to the MC as requested by the MC to the CP. For initiating the transportation, CP requires the name of the intended MC, public address for authenticity, and volumes of blood required.

After the blood is transported to the MC, the second step of verification is presided over blood units by the MC. According to NACO standards, the following parameters of the DR are substantiated: $⟨BG,HIV,LIV,BP,HB⟩$; if the DR meets all requirements specified by NACO, the blood unit is accepted. When the end user is in need of blood, the TS will receive the details of the RC and supply the blood unit from NACO to the end user. Later, the details of the RC are to be collected at the time of blood transportation. The end user can track the status of intended blood units to be received by logging in with their respective wallet address, as shown in Fig. 11.

Figure 12 describes a user interface where the user is prompted to enter their blood type and location by providing the latitude and longitude. When the user clicks the “Search Blood Banks” button, the system calculates the nearest blood banks using the geodesic distance method. Based on this data, it lists the blood banks closest to the user, ensuring that the user can quickly find available blood supplies.

Security analysis

Formal analysis

Theorem: The security and privacy of the data are provided in the B-SCM by implementing a Byzantine Fault Tolerance (BFT) system for the nodes in the system (Al-Farsi, Rathore & Bakiras, 2021). The nodes in the system, namely NACO, DR, CP, TS, and MC, are interconnected in the network as shown in Fig. 13.

Proof: Let $N=5$ be the total number of nodes in the network. For a Byzantine Fault Tolerance system to function correctly, it must tolerate up to $f$ faulty nodes where $N>3f$. The BFT consensus algorithm used is Practical Byzantine Fault Tolerance (PBFT), which ensures consensus if at least $\frac{2N}{3}$ nodes agree on the validity of a transaction. Given $N=5$, the maximum number of tolerated Byzantine nodes is $f$, which satisfies (Eq. (18)). Therefore, we get the $f$ value as evaluated in Eq. (19):

(18) $$N>3f$$

(19) $$f<\frac{N}{3}=\frac{5}{3}\approx \mathrm{1.67.}$$

To analyze the relationship between correct nodes and faulty nodes, consider the following inequality derived from Eq. (18):

(20) $$N-f>3f-f.$$

Simplifying Eq. (20), we get:

(21) $$N-f>2f.$$

Therefore, from Eqs. (19) and (21), we get:

(22) $$N-f>\frac{2N}{3}.$$

To validate the number of correct nodes required for consensus, we calculate:

(23) $$\frac{2N}{3}=\frac{2\times 5}{3}=\frac{10}{3}\approx 3.33\approx 4.$$

Hence, the system can tolerate up to 1 faulty node ( $f=1$). For a transaction T (e.g., blood donation, transport, or utilization) to be validated, each node $i$ (where $i\in \{1,2,\dots ,5\}$) independently validates T. The transaction T is considered valid if at least the number of nodes as computed in Eq. (23) vote in favor of it. This ensures that even if up to 1 node is malicious or faulty, the system remains secure. Therefore, from Eqs. (22) and (23), if four nodes agree, T is added to the blockchain. Additionally, in the case where TS submits conflicting transport data, the other nodes (NACO, DR, CP, and MC) identify the inconsistency and reject TS’s transaction. Continuous misbehavior by TS leads to its removal from the consensus process by a majority vote, ensuring system integrity.

Lemma 1: In a PBFT system, consensus is reached.

Proof: In a PBFT system, $f$ is the maximum number of faulty nodes the system can tolerate. Since $N>3f$, there are always at least $N\text{-}f$ correct nodes. The consensus requires $\frac{2N}{3}$ votes, thereby from Eq. (22) ensuring that a majority of correct nodes can reach consensus even if up to $f$ nodes are faulty.

Lemma 2: The system ensures data integrity and privacy.

Proof: The data is stored and transmitted using blockchain technology, which leverages cryptographic techniques inherent in blockchain systems to ensure that data cannot be altered once it is committed to the ledger. Each transaction is digitally signed by the submitting node, and the integrity of the data is verified by all participating nodes. The immutable audit trail on the blockchain ensures that all transactions are verifiable and traceable, further ensuring data integrity and privacy. This system implements this framework by maintaining a ledger that records every crypto transaction.

Performance analysis

The model’s performance was assessed using a confusion matrix, as shown in Fig. 14. In Eqs. (24), (25), (26) and (27) blood availability (BA) is analogous to True Positives, indicating the number of correct predictions of blood supply availability when it was indeed available. Blood unavailability (BU) corresponds to True Negatives, representing correct predictions of unavailability when the blood supply was unavailable (Younis et al., 2021). False blood availability (FBA) represents False Positives, where the model incorrectly predicted availability when the blood supply was unavailable. Similarly, false blood unavailability (FBU) corresponds to False Negatives, indicating incorrect predictions of unavailability when the blood supply was available. This evaluation provides a comprehensive breakdown of the model’s accuracy in predicting blood supply availability within the given context (Rupa et al., 2025).

The model achieved an accuracy of 96%, demonstrating its effectiveness in predicting the availability of blood from nearby blood banks and donors. The study possesses a precision of 97.95%, highlighting the model’s ability to accurately identify true positive blood availability predictions. The recall was also 97.95%, indicating the model’s effectiveness in detecting actual blood availability. Similarly, the F1-score was 97.95%, reflecting the balance between precision and recall and confirming the model’s overall high performance in predicting blood supply availability.

(24) $$\mathrm{A}\mathrm{c}\mathrm{c}\mathrm{u}\mathrm{r}\mathrm{a}\mathrm{c}\mathrm{y}=\frac{BA+BU}{BA+BU+FBA+FBU}$$

(25) $$\mathrm{P}\mathrm{r}\mathrm{e}\mathrm{c}\mathrm{i}\mathrm{s}\mathrm{i}\mathrm{o}\mathrm{n}=\frac{BA}{BA+FBA}$$

(26) $$\mathrm{F}1\text{-}\mathrm{s}\mathrm{c}\mathrm{o}\mathrm{r}\mathrm{e}=\frac{2\times BA}{2\times BA+FBA+FBU}$$

(27) $$\mathrm{R}\mathrm{e}\mathrm{c}\mathrm{a}\mathrm{l}\mathrm{l}=\frac{BA}{BA+FBU}$$where:

• BA = True Positives (Blood Available)

• BU = True Negatives (Blood Unavailable)

• FBA = False Positives (False Blood Available)

• FBU = False Negatives (False Blood Unavailable)

B-SCM includes entities such as NACO, CP, MC, TS, and DR, as shown in Fig. 15. These entities interact and access data according to specific rules defined by Access Control Lists (ACLs), as illustrated in Table 2. To represent and enforce these rules, we use two matrices: a Binary Connection Matrix A and a Weighted Connection Matrix W.

The Binary Connection Matrix A in Eq. (28) indicates whether there is access (1) or no access (0) between entities. The rows and columns represent the entities, and each element $a_{ij}$ shows if entity $i$ has access to the resources of entity $j$.

(28) $$A=\left[\begin{array}{ccccc}1& 1& 1& 1& 0\\ 1& 1& 1& 1& 0\\ 1& 1& 1& 1& 0\\ 1& 1& 1& 1& 1\\ 1& 1& 0& 0& 1\end{array}\right]$$where in Eq. (28):

• rows and columns represent the entities in the order: NACO, CP, MC, TS, DR.

• Each element $a_{ij}$ indicates whether entity $i$ has access to the resources of entity $j$.

The Weighted Connection Matrix W assigns weights to the access permissions, representing the priority or level of access. These weights could be based on transactional data, security levels, and access frequency.

(29) $$W=\left[\begin{array}{cccc}0& W_{12}& W_{13}& W_{14}\hfill \\ W_{21}& W_{22}& W_{23}& W_{24}\hfill \\ W_{31}& W_{32}& W_{33}& W_{34}\hfill \\ W_{41}& W_{42}& W_{43}& 0\hfill \\ 0& 0& 0& 0\hfill \end{array}\right].$$

This study has successfully implemented Access Control Lists (ACLs) and priority scores were assigned for the entities for secure communication. The performance analysis of ACLs, priorities of entity operations, alongside the security and privacy requirements are clearly stated as follows:

(30) $${\mathrm{A}\mathrm{C}\mathrm{L}}_{i,j}=\{\begin{array}{cc}1\hfill & \mathrm{i}\mathrm{f}{a}_{ij}=1\hfill \\ 0\hfill & \mathrm{i}\mathrm{f}{a}_{ij}=0\hfill \end{array}$$

(31) $$P_{i,j}=\{\begin{array}{cc}{W}_{ij}\hfill & \mathrm{i}\mathrm{f}{a}_{ij}=1\hfill \\ 0\hfill & \mathrm{i}\mathrm{f}{a}_{ij}=0\hfill \end{array}.$$

To ensure ACLs are maintained, we sum the priority scores for all granted accesses as depicted in Eqs. (32) and (33). To illustrate the enforcement of ACLs, we use the priority scores of each entity along with the access level assigned to each entity.

For $AC{L}_{i,j}=1$

(32) $$\sum _{i\in E_j}\sum _{j\in E}{\mathrm{A}\mathrm{C}\mathrm{L}}_{i,j}\cdot P_{i,j}=\sum _{i\in E_j}\sum _{j\in E}{P}_{i,j}.$$

For $AC{L}_{i,j}=0$

(33) $$\sum _{i\in E_j}\sum _{j\in E}{\mathrm{A}\mathrm{C}\mathrm{L}}_{i,j}\cdot P_{i,j}=\sum _{i\in E_j}\sum _{j\in E}0\cdot P_{i,j}=0.$$

To strengthen the rationale for selecting Binance Smart Chain (BSC) over other platforms such as Ethereum and Hyperledger Fabric, a quantitative comparison is presented in Table 4. The comparison evaluates core parameters including transaction fees, throughput, confirmation time, development complexity, and use case suitability. BSC offers significantly lower transaction costs (approximately $0.10) compared to Ethereum’s $5–$10 range, making it highly cost-effective for frequent interactions in decentralized applications. While Hyperledger Fabric provides higher throughput, it is a permissioned network, making it less suitable for publicly accessible systems like ours. Additionally, BSC achieves a good balance between scalability, development simplicity (due to EVM compatibility), and public accessibility. These factors make BSC a more practical and efficient choice for the implementation of a decentralized blood supply chain management system.

Table 5 describes the comparison between the proposed system with the existing studies. The proposed system, utilizing AdaBoost, demonstrates superior performance across all metrics, achieving an accuracy of 99.5%, which is the highest among the compared models. In terms of precision, recall, and F1-score, the proposed system consistently scores 0.99, 0.96, and 0.98, respectively, surpassing the performance of models like SVM, KNN, and MLP. These results indicate that the proposed AdaBoost system is not only more accurate but also more reliable in correctly identifying positive instances and capturing all relevant instances, making it the best-performing model in this comparison. This comprehensive improvement across all evaluation criteria underscores the robustness and effectiveness of our proposed approach. The superior performance of the proposed system can be demonstrated graphically in Fig. 16.

The comparative analysis demonstrates the AdaBoost model’s superiority over alternative approaches, achieving 99.5% accuracy compared to 96.5% for SVM and MLP models. Beyond prediction performance, BSC provides distinct advantages over other blockchain platforms: its $0.10 average transaction cost is 50–100× lower than Ethereum’s $5–$10 range, while maintaining 3-s confirmation times vs Ethereum’s 13–15 s. Although Hyperledger Fabric offers higher throughput (1000+ TPS vs. BSC’s 100 TPS), its permissioned nature limits suitability for public health applications. This balance of low cost, developer-friendly EVM compatibility, and public accessibility makes BSC ideal for decentralized blood supply chains.

This study aimed to develop an intelligent and secure blood supply chain management system by integrating the AdaBoost machine learning algorithm with a blockchain-based infrastructure. The rationale behind this integration is to overcome key limitations of traditional systems, such as low accuracy in predicting donor and blood bank availability, and the absence of secure, transparent data handling. Existing centralized systems are often prone to data tampering and lack the intelligence needed for real-time decision-making. The proposed system addresses these gaps by using the AdaBoost algorithm off-chain to provide high-accuracy predictions for locating the nearest eligible donors and available blood banks, outperforming conventional models like SVM, KNN, and MLP in terms of both accuracy and speed. Simultaneously, the blockchain layer is deployed on the Binance Smart Chain, ensuring immutable and verifiable records of all supply chain events, from donor registration to blood unit tracking, using smart contracts. By combining predictive intelligence with decentralized trust, the proposed framework offers superior performance, enhanced transparency, and greater reliability compared to existing centralized or siloed approaches, thereby meeting the core research objectives effectively.

Conclusion and future work

The blockchain system configured for blood supply chain management integrates nodes with different levels of access, thereby enhancing authorization mechanisms and ensuring secure handling of sensitive information. By configuring the Binance Coin (BNB) gas price through the Hardhat environment, the system avoids high transaction costs, as demonstrated in the experiments. The integration of the AdaBoost algorithm achieves a 99.5% prediction accuracy, significantly enhancing user experience by efficiently identifying suitable donors and blood banks. The use of BscScan validates the reliability of public blockchain operations, while essential security features such as immutability via access control, confidentiality, integrity of records, and non-repudiation through distributed ledgers strengthen the trustworthiness of the system.

In contrast to traditional centralized systems that are often prone to data tampering, single-point failures, and limited transparency, our system offers decentralized trust, traceability, and predictive intelligence. The comparative analysis demonstrates significant advantages: AdaBoost outperforms alternative models (SVM, KNN, MLP) by 3–8.5% in accuracy, while Binance Smart Chain reduces transaction costs 50–100x compared to Ethereum. However, limitations including potential integration challenges with existing healthcare infrastructure (particularly regarding HL7/FHIR interoperability and HIPAA/GDPR compliance), dependency on public blockchain gas fees during network congestion, and limited deployment across diverse geographic regions need to be addressed in future iterations.

From a practical perspective, deploying such a system in real-world healthcare environments presents several benefits, including increased transparency, improved traceability, and faster, data-driven decisions. However, challenges may arise, such as integrating with legacy hospital systems, complying with healthcare data privacy regulations, managing blockchain scalability, and ensuring affordability of gas fees under high-volume transactions. Although the current system is built on a public blockchain, future adaptations may consider private or consortium blockchains for enhanced data safety and interoperability. Specific infrastructure compatibility solutions will include developing standardized API gateways and hybrid architectures that maintain backward compatibility with existing hospital systems.

In addition, scalability studies using more advanced machine learning models will be undertaken to optimize performance further. Future work will specifically address current limitations through: (1) multi-institutional trials across diverse healthcare ecosystems, (2) implementation of Layer-2 scaling solutions for gas optimization, (3) expansion of training datasets via partnerships with national blood networks, and (4) smart contract modularization for regulatory adaptation across jurisdictions. This work lays the foundation for a scalable, secure, and intelligent blood supply chain management system, with promising implications for broader healthcare applications, including secure e-blood donation platforms and digital payment integration.

Abbreviations

The following Table 6 lists the abbreviations used in this manuscript:

Data Source

The dataset was compiled using information sourced from the official e-RaktKosh platform of the Ministry of Health and FamilyWelfare, Government of India: https://eraktkosh.mohfw.gov.in/BLDAHIMS/bloodbank/transactions/bbpublicindex.html. The dataset has been curated and published with an assigned DOI via the Zenodo repository: https://doi.org/10.5281/zenodo.15667720.

Supplemental Information