A Blockchain-based Traceability System for AI-Driven Engine Blade Inspection

BladeChain: A Blockchain-based Traceability System for AI-Driven Engine Blade Inspection Mahmoud Hafez* 1 Eman Ouda 1 M. A. Mohammed Eltoum 1 Khaled Salah 2 Yusra Abdulrahman 1 , 3 Khalifa University of Science & Technology Abstract— Aircraft engine blade maintenance relies on in- spection records shared across manufacturers, airlines, main- tenance organizations, and regulators. Yet current systems are fragmented, difficult to audit, and vulnerable to tam- pering. This paper presents BladeChain, a blockchain-based system providing immutable traceability for blade inspections throughout the component life cycle. BladeChain is the first system to integrate multi-stakeholder endorsement, automated inspection scheduling, AI model provenance, and cryptographic evidence binding, delivering auditable maintenance traceability for aerospace deployments. Built on a four-stakeholder Hy- perledger Fabric network (OEM, Airline, MRO, Regulator), BladeChain captures every life cycle event in a tamper-evident ledger. A chaincode-enforced state machine governs blade status transitions and automatically triggers inspections when config- urable flight hour, cycle, or calendar thresholds are exceeded, eliminating manual scheduling errors. Inspection artifacts are stored off-chain in IPFS and linked to on-chain records via SHA-256 hashes, with each inspection record capturing the AI model name and version used for defect detection. This enables regulators to audit both what defects were found and how they were found. The detection module is pluggable, allowing organizations to adopt or upgrade inspection models without modifying the ledger or workflows. We built a prototype and evaluated it on workloads of up to 100 blades, demonstrating 100% life cycle completion with consistent throughput of 26 operations per minute. A centralized SQL baseline quantifies the consensus overhead and highlights the security trade-off. Security validation confirms tamper detection within 17 ms through hash verification. Index Terms— Blockchain, Hyperledger Fabric, aircraft maintenance, inspection traceability, IPFS, defect detection I. INTRODUCTION In the aviation industry, engine blades are among the most safety-critical serialized components [1]. Their structural integrity governs engine efficiency, fuel burn, and, above all, flight safety [2]. Across a multi-year life cycle, each blade accumulates a chain of high-stakes events: manufacture and release, in-service operation, scheduled and unscheduled in- spections, repairs and approvals, and ultimately removal from service [3], [4]. Effective maintenance and inspection are *Corresponding author: mahmoud.hafez@ku.ac.ae 1 Aerospace Engineering Department, Khalifa University of Science & Technology 2 Computer and Information Engineering Department, Khalifa University of Science & Technology 3 Advanced Research and Innovation Center (ARIC), Khalifa University of Science & Technology therefore indispensable [5]. Yet in practice, much of the as- sociated evidence (images, annotations, findings, approvals) remains fragmented across paper forms, spreadsheets, and organization-specific databases, making it difficult to rec- oncile [6], [7], [8]. These traditional information systems are often characterized by centralized storage, information lag, and high error rates, which act as a bottleneck for revenue and safety improvements [9]. This fragmentation slows audits, weakens accountability, and increases the risk of incomplete or disputed maintenance histories [10], [11], [12]. The scale of this challenge is substantial: the global Main- tenance, Repair, and Overhaul (MRO) market is projected to exceed $125 billion by the early 2030s, with engine maintenance alone accounting for 46% of civil aviation MRO spending [13], [14]. The International Air Transport Association (IATA) emphasizes that quality traceability data throughout a part’s life cycle is essential for inventory accuracy, reduced maintenance error, and effective decision- making, which are requirements that fragmented systems struggle to meet [3], [4], [15]. Regulatory frameworks such as EASA Part-145 mandate Occurrence Reporting Systems (ORS), yet many implementations function as passive repos- itories rather than comprehensive systems capable of enforc- ing traceability across organizational boundaries [5]. Poorly documented parts have contributed to aviation incidents, underscoring the need for verifiable record systems that span Original Equipment Manufacturers (OEMs), airlines, MROs, and regulators [11], [12]. In parallel, AI/ML-based inspection for engine blades has advanced significantly, including borescope image analysis, crack detection, and surface-anomaly segmentation [16]. These approaches reduce manual burden and improve consis- tency relative to purely visual inspection. However, most de- ployments remain point solutions: findings are confined to lo- cal Quality Assurance (QA) tools without cross-organization provenance, model-version accountability, or cryptographic bindings to the artifacts reviewed [17]. Even when an AI model flags a defect, there is no verifiable proof linking that output to the specific image, model version, responsible organization, and subsequent approval decision. The result is an infrastructure gap: AI can detect defects, but current systems do not anchor those detections into a regulator-grade audit trail. arXiv:2603.08288v1 [cs.CR] 9 Mar 2026 Adopting Industry 4.0 standards, such as the use of IoT, Big Data, and Cloud Computing, is now seen as vital for improving supply chain integration and making more accu- rate operational decisions [18]. Specifically, the transition to blockchain-enabled quality inspection can help supply chain members identify component problems earlier and approach ”zero-defect” manufacturing [19].While recent work has explored blockchain for aviation traceability, notably Hy- perledger Fabric for spare parts inventory [4], permissioned ledgers for maintenance records [11], [12], and broader aerospace applications [20], [15], [21], these efforts focus on parts provenance rather than inspection-artifact binding, and none integrate AI-based defect detection with cryptographic commitments within a unified life cycle framework [22], [17]. A permissioned blockchain is well-suited to this prob- lem: multiple mutually distrusting organizations (OEMs, air- lines, MROs, regulators) must jointly maintain authoritative records, no single party should unilaterally alter inspection evidence, and all state transitions require cryptographic proof of organizational endorsement [23], [24]. Shared authority, tamper-evidence, and verifiable provenance are difficult to achieve with centralized databases or federated systems lacking consensus guarantees. To address these gaps, we present BladeChain, a blockchain-based framework for end-to-end traceability of aircraft engine blade inspections. BladeChain unifies a per- missioned Hyperledger Fabric ledger governing blade life cycle events across OEM, airline, MRO, and regulator organizations; a pluggable AI-assisted inspection pipeline with off-chain artifact storage and on-chain cryptographic bindings; and an operational oracle layer that emits machine- verifiable traceability proofs. Our key contributions can be summarized as: 1) We propose BladeChain, a blockchain-based trace- ability system specifically designed for AI-driven en- gine blade inspection, addressing the fragmented and non-auditable nature of current aviation maintenance records. 2) We present on-chain recording of AI model prove- nance, where each inspection record captures the AI model name and version used for defect detection, enabling regulators to audit not only what defects were found but how they were found. 3) We implement automated inspection scheduling via a chaincode-enforced state machine that triggers in- spections based on configurable flight-hour, cycle, and calendar thresholds, eliminating manual tracking errors common in current maintenance workflows. 4) We evaluate a working prototype on Hyperledger Fabric, demonstrating stable throughput and 100% life cycle completion under realistic workloads, with a centralized SQL baseline quantifying the security- performance trade-off. The remainder of this paper is structured as follows. Section I reviews related work on blockchain applica- tions for aircraft parts traceability, maintenance records, and MRO organizations, and positions the proposed BladeChain framework within existing research. Section I details the system design, including design requirements and decisions, system architecture, network topology, data model, and the associated security and threat model. Section IV describes the implementation aspects, covering the development stack, chaincode implementation, API gateway and off-chain ser- vices, as well as the integration of defect detection. Section V presents the experimental setup and evaluates the system through functional, performance, and security validations. Finally, Section VI concludes the paper by summarizing the key findings and outlining future research directions. I. RELATED WORK Blockchain technology has attracted considerable attention in aviation for its potential to address longstanding chal- lenges in parts traceability, maintenance record integrity, and multi-stakeholder coordination. This section reviews existing work on blockchain applications in aircraft maintenance and supply chain management, then positions BladeChain relative to these efforts. A. Blockchain for Aircraft Parts Traceability Several studies have explored blockchain for tracking aircraft components across supply chain stakeholders. Ho et al. [4] present a comprehensive Hyperledger Fabric im- plementation for aircraft spare parts management, achieving over 2,000 transactions per second with multi-organization channels connecting OEMs, MROs, airlines, and logistics providers. Their system supports private chaincode for inter- organizational data sharing, but focuses on inventory man- agement rather than inspection evidence. Their design does not bind inspection artifacts or evidentiary media (e.g., images or NDT outputs) to ledger entries. Joeaneke et al. [29] provide quantitative validation of blockchain’s impact on aerospace supply chains through structural equation modeling, demonstrating significant ef- fects on traceability (β = 0.40, p < 0.001) and transparency (β = 0.38, p < 0.001). Their analysis confirms blockchain’s value for part authentication and provenance tracking. Recent work has shifted toward NFT-based authentication. Hawashin et al. [26] introduce composable NFTs for UAV parts traceability, where parent NFTs represent assembled UAVs and child NFTs represent individual components. This hierarchical model enables digital twin integration with life cycle tracking, using IPFS for off-chain metadata storage. Kabashkin [27] proposes a broader NFT-based framework for aviation component life cycle management spanning eight application areas, including parts tracking, maintenance records, certification, and quality assurance, and also uti- lizes IPFS for decentralized storage. However, both works focus primarily on manufacturing-stage provenance, owner- ship transfer, and certification events rather than in-service inspection workflows with multi-organizational endorsement requirements. TABLE I: Comparison of blockchain systems for aviation maintenance and traceability. SystemYearMulti-OrgMulti-OrgMaintenanceParts LifeAIOff-ChainOff-Chain ActorsEndorsementRecord KeepingCycle MgmtIntegrationRecord StorageIntegrity Proofs Aleshi et al. [12]2019✓✗✓✗ Schyga et al. [25]2019✓✗ Ho et al. [4]2021✓✗ AirChain [11]2022✓✗✓✗ Hawashin et al. [26]2024✓✗✓✗✓✗ Kabashkin [27]2024✓✗✓✗✓✗ Alqaryuti et al. [28]2025✓✗✓✗✓✗ BladeChain (Ours)2026✓ B. Blockchain for Aircraft Maintenance Records AirChain [11] represents a mature maintenance record sys- tem, storing both Cabin Log Book (CLB) and Technical Log Book (TLB) data on Hyperledger Besu with smart contract- based data management. Developed with China Airlines, AirChain demonstrates practical viability but lacks multi- organization endorsement policies and off-chain storage for large artifacts such as images or inspection media. Aleshi et al. [12] propose the Secure Aircraft Mainte- nance Records (SAMR) system using Hyperledger Sawtooth, addressing homeland security implications of maintenance fraud by preventing forgery of FAA personnel signatures. However, the system remains at a conceptual stage without implementation validation. The most feature-complete recent work is the blockchain- driven framework for aircraft hydraulic systems by Alqaryuti et al. [28], combining Ethereum smart contracts, time oracles for automated maintenance scheduling, and IPFS for off- chain document storage. Their cost analysis shows $0.89 average transaction cost, demonstrating economic viabil- ity. However, the system addresses preventive maintenance scheduling rather than inspection evidence binding, and does not integrate AI-assisted defect detection. While mainte- nance documents are stored off-chain and cryptographically anchored on-chain, the system does not provide artifact- level integrity proofs or support AI-assisted inspection trace- ability.Future iterations could leverage AI-driven predictive analytics to identify key emissions or failure drivers, validat- ing these insights against immutable blockchain records to ensure auditable explanations for all variables [30]. Kusumastuti and Hartono [31] implement a Ganache- based prototype for aircraft reliability and maintenance records, while Kabashkin [32] proposes the “Iceberg Model” integrating AI, blockchain, and data analytics for aircraft health monitoring. It is one of the few works combining AI with blockchain, though it remains conceptual. C. Blockchain in MRO Organizations Efthymiou et al. [33] provide a qualitative analysis of bar- riers to blockchain adoption in MRO organizations through a case study of Dublin Aerospace, identifying information- sharing reluctance, regulatory complexity, and implementa- tion costs as key challenges. Their findings suggest that con- sortium blockchains are ideal for MRO due to permissioned participation requirements. Schyga et al. [25] developed a working Hyperledger Fabric prototype for MRO documentation with smart contracts for automated workflows, but it lacks integration with off-chain storage. Tapia et al. [34] report one of the most detailed experimental evaluations of Hyperledger Fabric combined with decentralized identity and verifiable credentials in an aeronautical manufacturing context, demonstrating low over- head under industrial constraints. However, the focus is on manufacturing data provenance rather than aircraft mainte- nance or inspection workflows. D. Positioning of BladeChain Table I highlights that existing blockchain-based sys- tems in aviation address parts traceability, maintenance record storage, or workflow automation largely in isolation. Prior work has focused either on supply chain provenance and ownership transfer, on maintenance scheduling and documentation, or on conceptual integrations of AI and blockchain, but none provide an integrated mechanism for binding inspection artifacts, inspection actors, and inspection outcomes across organizational boundaries. In particular, existing systems do not address AI model ac- countability in inspection workflows. While some approaches incorporate digital twins, analytics, or conceptual AI inte- gration, they do not record which model version produced a given defect detection, nor do they cryptographically bind inference outputs to the original and annotated inspection ar- tifacts reviewed by human inspectors. As a result, inspection outcomes cannot be independently re-validated or audited once evidence is stored off-chain. BladeChain addresses these limitations by treating AI- assisted inspection as a first-class, auditable process. For each inspection event, the system records on-chain the model name and version, detected defect classes (corrosion, nick, dent, scratch), defect counts, inspector and organizational identities, and timestamps, alongside cryptographic com- mitments to the original and annotated inspection images Fig. 1: BladeChain architecture. Client applications communicate with the API gateway via REST/SSE. The gateway orchestrates interactions with the Hyperledger Fabric network, IPFS storage, and the pluggable AI inspection engine. via their IPFS CIDs and SHA-256 hashes. This design enables explicit, auditor-verifiable off-chain integrity proofs, allowing regulators or third parties to independently retrieve inspection artifacts, recompute hashes, and validate their integrity and provenance against on-chain records. BladeChain is the first system to combine multi- organization endorsement, verifiable off-chain integrity proofs, and AI inspection accountability within a single blockchain-based framework for aviation inspection and maintenance. I. SYSTEM DESIGN This section presents the design of BladeChain, a blockchain-based framework for the traceability of aircraft engine blade inspections. We begin by establishing require- ments derived from stakeholder needs, then describe our design decisions, system architecture, network topology, data model, and security considerations. A. Design Requirements BladeChain must satisfy the requirements of four stake- holder classes (OEMs, airlines, MROs, and regulators), each with distinct concerns regarding blade lifecycle management. R1: Multi-Organization Traceability. All life cycle events shall be attributable to a specific organization and individual, with cryptographic non-repudiation. R2: Multi-Party Control. No single organization shall be able to unilaterally create, modify, or delete records. R3: Automated Inspection Scheduling. The system shall enforce inspection schedules based on configurable thresh- olds. When a blade exceeds any threshold, it shall automati- cally transition to an inspection-due state, preventing further flight operations until inspection is completed. R4: Evidence Binding. Inspection artifacts shall be cryp- tographically bound to on-chain records. This binding shall include: (i) tamper-evident commitments to artifact content, (i) the AI model name and version used for defect detec- tion, (i) the inspector identity and organization, and (iv) timestamps for all events. R5: Auditability. Regulators shall be able to retrieve complete blade histories, verify artifact integrity, and receive real-time event notifications. The system shall support proof generation bundling on-chain records with hash revalidation. R6: Practical Scalability. The system shall support main- tenance workloads typical of fleet operations. While high transaction throughput is not required, the system shall handle concurrent inspections across multiple blades without performance degradation. B. Design Decisions The requirements outlined above informed several archi- tectural decisions regarding the selection of a blockchain platform, artifact storage, AI integration, and transaction endorsement. We selected Hyperledger Fabric 2.5 as the underlying blockchain platform after evaluating alternatives, includ- ing public blockchains and other permissioned frameworks. Public blockchains were unsuitable for two reasons: their pseudonymous identity models conflict with regulatory re- quirements for accountable, auditable participants, and their consensus mechanisms introduce latency and cost (gas fees) unnecessary for maintenance workloads. Among permis- sioned alternatives, Fabric offered the most mature sup- port for our requirements. Its Membership Service Provider (MSP) architecture provides X.509 certificate-based identity management aligned with enterprise PKI practices [35]. En- dorsement policies enable fine-grained specification of which organizations must approve transactions, directly addressing the multi-organization traceability requirement. The execute– order–validate architecture decouples transaction execution from consensus, enabling parallel endorsement across orga- nizations, while Raft-based ordering provides deterministic finality without the overhead of Byzantine fault–tolerant consensus mechanisms [24]. For inspection artifacts, we adopted an off-chain storage strategy using IPFS instead of storing images directly on the ledger. Storing images on-chain would rapidly bloat the ledger, degrade network performance, and complicate peer synchronization. Instead, BladeChain stores artifacts in IPFS and records only the Content Identifier (CID) and SHA-256 hash on-chain. The CID enables content-addressed retrieval, while the hash provides an independent verification path: any auditor or stakeholder can independently retrieve the artifact and confirm integrity by recomputing the hash [36]. This approach mirrors patterns established in prior blockchain systems for document-heavy domains [28], [27]. The defect detection component is designed as a plug- gable module rather than a fixed system element, with all inference performed off-chain. While our prototype employs a YOLOv8-based detector, the architecture imposes no con- straints on model architecture or vendor. The chaincode records model name and version alongside detection outputs, enabling post-hoc audit of which model produced which findings. This design acknowledges that detection technology will evolve and that different operators may prefer different solutions. BladeChain provides the traceability infrastructure without mandating specific AI implementations. Finally, we configured Fabric’s endorsement policy to re- quire transaction signatures from at least three organizations configured as a logical Majority endorsement policy. This policy ensures that inspection records cannot be created through unilateral action; a majority of organizations must cryptographically endorse each transaction. The Regulator organization participates in the channel and may endorse transactions, but primarily serves an audit and oversight role. C. System Architecture BladeChain employs a four-layer architecture that sepa- rates client applications, the API gateway, the blockchain network, and off-chain services. Figure 1 illustrates the overall system structure. Layer 1: Client Applications. The presentation layer comprises web-based dashboards tailored to each stakeholder role. Operators view blade status and initiate flight data updates; MRO technicians upload inspection images and review AI-generated annotations; regulators access audit interfaces and event streams. All clients interact with the system through the API gateway rather than directly with the blockchain, simplifying integration and enabling consistent access control. Layer 2: API Gateway (Oracle). The API gateway serves as the bridge between external clients and the blockchain network. Implemented as a Node.js service, it exposes REST- ful endpoints for all lifecycle operations: blade manufac- turing, activation, flight data recording, inspection submis- sion, repair logging, and proof generation. The gateway also provides Server-Sent Events (SSE) for real-time event streaming, enabling clients to receive notifications when blade states change. Critically, the gateway orchestrates the inspection workflow: receiving uploaded images, invoking the AI detection engine, uploading artifacts to IPFS, com- puting SHA-256 hashes, and submitting transactions to the Fabric network. Layer 3: Hyperledger Fabric Network. The blockchain layer provides the immutable, multi-party ledger for blade life cycle records. The network comprises peers from each organization (with CouchDB state databases for rich queries), a Raft-based ordering service for transaction sequencing, and the bladelifecycle chaincode implementing the blade state machine and access control logic. All peer-to- peer communication uses gRPC over TLS. Layer 4: Off-Chain Services. Two off-chain components complement the blockchain. The AI inspection engine re- turns bounding boxes, defect labels produced by the model, and confidence scores. The IPFS daemon provides content- addressed storage for inspection artifacts, returning CIDs that are recorded on-chain. Both services are accessed by the API gateway during the inspection workflow. a) Inspection Data Flow: Figure 2 illustrates the se- quence of operations when an MRO technician submits a blade inspection. The workflow proceeds as follows: 1) The client uploads an inspection image to the API gateway via HTTP POST. 2) The gateway forwards the image to the AI engine, which returns detected defects with bounding boxes and confidence scores. 3) The gateway uploads the inspection artifact (annotated image when available) to IPFS, receiving a CID. Client API Gateway AI Engine IPFS Fabric Peers 1 POST /inspect (image) 2 Detect defects Defects, b-boxes, confidence 3 Upload image CID 4 Compute SHA-256(image) 5 AddInspection(sn, defects, CID, hash) 6 Execute Endorse Order Validate 7 TxID, commit confirmation 8 Result: TxID, defects, CID EOV RequestResponse EOV: Execute-Order-Validate Fig. 2: Sequence diagram for blade inspection operations. The API gateway orchestrates AI inference, IPFS storage, hash computation, and chaincode invocation before returning results to the client. 4) The gateway computes the SHA-256 hash of the image content. 5) The gateway invokes the AddInspection chaincode function with the blade serial number, defect list, model metadata, CID, and hash. 6) Endorsing peers independently execute the chaincode and return signed endorsements. 7) The gateway submits the endorsed transaction to the ordering service. 8) Orderers sequence the transaction into a block and distribute it to all peers. 9) Each peer validates the transaction against the endorse- ment policy and commits the state update to CouchDB. 10) The gateway returns the transaction ID and inspection results to the client. D. Network Topology The BladeChain network comprises four organizations re- flecting the aviation maintenance ecosystem. Figure 3 depicts the network structure. a) Organizations: Four organizations participate in the network: • OEM: Manufactures blades, performs release inspec- tions, provides technical authority. • Airline: Operates aircraft, records flight data, owns blades during service. • MRO: Performs inspections, executes repairs. • Regulator: Audits records, verifies compliance. b) Channel Configuration: All organizations share a single channel (bladelifecycle-channel) providing a unified view of blade records. The channel hosts the bladelifecycle chaincode, which implements the blade state machine and enforces access control based on caller identity. c) Ordering Service: Transaction ordering uses a three- node Raft cluster providing crash fault tolerance (tolerating Fig. 3: BladeChain network topology. Peers execute the chaincode and sign. Orderers sequence endorsed transactions into blocks. Peers validate and commit to state database. one node failure). Raft was selected over Byzantine fault- tolerant alternatives (e.g., BFT-SMaRt) because the per- missioned network assumes non-Byzantine behavior among known ordering nodes, and Raft offers lower latency and simpler operations. d) Peer Configuration: Each organization operates one peer node with an associated CouchDB instance for state storage. CouchDB enables rich queries against blade records (e.g., retrieving all blades in INSPECTION DUE state), supporting operational dashboards and audit interfaces. E. Data Model The BladeChain data model captures the complete life cycle of aircraft engine blades through two primary con- structs: a state machine governing blade status transitions, and structured records for inspections and defects. a) Blade life cycle State Machine: Each blade pro- gresses through six states that reflect its operational status. A blade begins in the MANUFACTURED state upon creation by the OEM and undergoes a quality assurance inspection before release. Upon release to an airline, the blade transi- tions to INSERVICE, where it accumulates flight hours and cycles during normal operations. When any of the three con- figurable thresholds is exceeded, the chaincode automatically transitions the blade to INSPECTION DUE, recording which threshold triggered the transition. When inspection results are submitted, the blade moves to UNDERINSPECTION. Based on the outcome, the blade may be approved to return to IN SERVICE, or sent to UNDERREPAIR if defects require remediation. Upon successful repair and approval, the blade returns to service. If damage is irreparable, the blade tran- sitions to FAILEDSCRAPPED and is permanently removed from service. Figure 4 illustrates these states and the triggers for the transitions. Fig. 4: Blade life cycle stages and permitted transitions. Transitions are enforced by chaincode; the transition to IN- SPECTIONDUE occurs automatically when usage thresholds are exceeded. The automatic transition to INSPECTIONDUE is central to regulatory compliance. When LogFlightOperation() is invoked with new flight hours and cycles, the chaincode evaluates three threshold conditions and transitions the blade state if any condition is met. This design ensures that no blade can continue operating beyond its inspection interval without explicit inspection and approval. b) On-Chain Records: The blade record maintains both static attributes established at manufacture and dynamic fields updated throughout the life cycle. Table I summarizes the key fields stored in CouchDB. TABLE I: Blade record fields stored on-chain. FieldDescription serialNumberUnique blade identifier (PK) currentStateCurrent life cycle state currentOwnerOperating airline (MSP ID) manufactureDateISO 8601 manufacture timestamp totalFlightHoursCumulative flight hours totalFlightCyclesCumulative flight cycles lastFlightDateMost recent flight operation date hoursSinceInspectionHours since last inspection cyclesSinceInspectionCycles since last inspection daysSinceInspectionDays since last inspection inspectionDueReasonThreshold that trigger inspection nextInspectionDueScheduled next inspection date lastInspectionDateMost recent inspection date totalInspectionsCount of completed inspections inspectionHistoryArray of inspection event IDs createdAtRecord creation timestamp updatedAtLast modification timestamp Each inspection generates an InspectionEvent record appended to the blade’s history. Table I describes the inspection event structure. TABLE I: Inspection event fields recorded on-chain. FieldDescription eventIDDeterministic identifier serialNumberAssociated blade serial number inspectionDateISO 8601 inspection timestamp inspectionTypeType aiModelNameAI model name aiModelVersionAI model version detectedDefectsArray of defect objects defectCountTotal defects detected overallResultOutcome (pass / fail / critical) inspectorInspector identity (from MSP) organizationInspecting organization (MSP ID) imageIPFSIPFS CID of inspection image imageHashSHA-256 hash of image content flightHoursAtInspectionFlight hours at inspection time flightCyclesAtInspectionFlight cycles at inspection time notesOptional inspector notes timestampEvent timestamp Each defect in the detectedDefects array con- tains: defectType (classification from the AI model), confidence (0.0–1.0), and bounding box coordinates (x1, y1, x2, y2) localizing the defect in the image. c) Manufacturing Inspection Normalization: Manufac- turing inspections (quality assurance at the OEM) follow a normalized format to ensure consistent record structure. The result defaults to PASS with an empty defect list, model name and version are set to “N/A” (no AI detection required for new blades), and the inspector and organization are recorded as “OEM QA” and “OEM” respectively. This normalization prevents null values in the data model while preserving the distinction between manufacturing and operational inspec- tions. F. Security and Threat Model BladeChain’s security model leverages Fabric-native mechanisms for authentication, authorization, and data in- tegrity, while the threat model defines the assumptions un- derlying these guarantees. a) Authentication and Authorization: All network par- ticipants authenticate via X.509 certificates issued by organization-specific Certificate Authorities within Fabric’s MSP framework. Transactions carry the submitter’s cer- tificate, enabling non-repudiable attribution of actions to specific identities. Inspector and organization fields in inspec- tion records are derived from the caller’s MSP certificate, ensuring that inspection provenance cannot be falsified by client applications. At the network level, the channel endorsement policy requires a majority of the four organizations to sign transactions.Atthechaincodelevel,authorization isenforcedthroughstatechecks.Forexample, LogFlightOperationverifiesthebladeisin INSERVICE state before accepting flight data. b) Data Integrity: Table IV summarizes the integrity mechanisms protecting on-chain and off-chain data. TABLE IV: Data integrity mechanisms. MechanismProtection Block hashingEach block contains the hash of the previous block; tampering invalidates subsequent chain Endorsement signatures Committed transactions carry signatures from the majority of organizations IPFS CIDContent-addressed storage; CID derived from content hash SHA-256 bindingOn-chain hash enables independent artifact ver- ification gRPC over TLSEncrypted peer-to-peer and client-to-peer com- munication c) Auditability:Thechaincodeprovidesa GetBladeCompleteHistoryfunctionreturning the current blade record and all associated inspection events. The API gateway exposes a proof generation endpoint that bundles this history with recomputed artifact hashes for independent verification. Selective chaincode events notify subscribers of key state changes: InspectionDueEventwhenthresholdstrigger inspectionrequirements, DefectDetectedEvent and OEMDefectAlert when defects are found, and BladeScrapedEvent when blades are removed from service. d) Threat Model: Table V summarizes adversary capa- bilities and corresponding mitigations. TABLE V: Threat model: adversary capabilities and mitiga- tions. ThreatMitigation Invalid transaction Rejected by majority endorsement policy Single compromised peer Cannot forge transactions without majority endorse- ment Forged inspector identity Inspector/org derived from MSP certificate, not client input Network eavesdropper TLS encryption on all channels IPFS substitutionCID and SHA-256 verification detects modification Raft node failureTolerates < N/2 crash faults (1 of 3 orderers) We assume an honest majority among endorsing organiza- tions and that each organization’s root CA issues certificates only to legitimate members. Out-of-scope threats include collusion among a majority of endorsers (requiring gover- nance controls), adversarial attacks against the AI model (orthogonal ML security research), and denial-of-service (an infrastructure concern). IV. IMPLEMENTATION This section describes the implementation of BladeChain, covering the development stack, chaincode logic, API layer, and defect detection integration. A. Development Stack Table VI summarizes the technologies and versions used in the BladeChain prototype. TABLE VI: Implementation technology stack. ComponentTechnologyVersion Blockchain frameworkHyperledger Fabric2.5.14 ConsensusRaft (etcdraft)3 orderers Smart contractGo1.21.13 State databaseApache CouchDB3.3.2 API gatewayNode.js + Express20.19.5 Fabric SDKfabric-network2.2.20 Decentralized storageIPFS (Kubo)0.24.0 Defect detectionYOLOv8Custom ContainerizationDocker28.4.0 The network deployment consists of thirteen Docker con- tainers: three orderers forming the Raft cluster, four peers (one per organization), four CouchDB instances for state storage, an IPFS daemon, and the API gateway. Crypto- graphic materials (X.509 certificates) are generated using Fabric’s cryptogen tool for all organizations, peers, or- derers, and user identities. B. Chaincode Implementation The bladelifecycle chaincode, implemented in Go, encodes the blade state machine and exposes functions for each life cycle operation. a) Automatic Inspection Triggering: A key safety fea- ture is the automatic transition to INSPECTION DUE when usage thresholds are exceeded. Algorithm 1 presents the logic implemented in LogFlightOperation. The algorithm first validates that the blade is in IN SERVICE state, then updates cumulative and since- inspection counters. If any threshold is exceeded, the state transitions to INSPECTION DUE and an Inspection- DueEvent is emitted for downstream notification. The triggering reason is recorded for audit purposes. The cur- rent implementation uses hardcoded thresholds of 500 flight hours, 500 flight cycles, and 180 calendar days; these values are configurable and can be adjusted to match operator- specific maintenance programs. b) Inspection Recording: Algorithm 2 presents the in- spection submission logic, which binds AI detection results to on-chain records with cryptographic integrity. Critically, the inspector identity and organization are de- rived from the transaction context via GetClientMSPID and GetClientID, ensuring non-repudiable attribution that cannot be falsified by client applications. The inspection Algorithm 1: LogFlightOperation Input: serialNumber, flightHours, flightCycles, flightDate Output: Updated blade record, potential state transition 1 blade ← GetBlade(serialNumber); 2 if blade.currentState ̸= IN SERVICE then 3return error: invalid state for flight logging; 4 end 5 blade.totalFlightHours ← blade.totalFlightHours + flightHours; 6 blade.totalFlightCycles ← blade.totalFlightCycles + flightCycles; 7 blade.hoursSinceInspection ← blade.hoursSinceInspection + flightHours; 8 blade.cyclesSinceInspection ← blade.cyclesSinceInspection + flightCycles; 9 blade.daysSinceInspection ← DaysSince(blade.lastInspectionDate); 10 if blade.hoursSinceInspection ≥ 500 then 11blade.inspectionDueReason ← “HOURSEXCEEDED”; 12 else if blade.cyclesSinceInspection ≥ 500 then 13blade.inspectionDueReason ← “CYCLES EXCEEDED”; 14 else if blade.daysSinceInspection ≥ 180 then 15blade.inspectionDueReason ← “DAYSEXCEEDED”; 16 end 17 if blade.inspectionDueReason ̸= “” then 18blade.currentState ← INSPECTIONDUE; 19EmitEvent(InspectionDueEvent, blade); 20 end 21 SaveBlade(blade); event stores the IPFS CID and SHA-256 hash of the in- spection image, enabling independent verification of artifact integrity. C. API Gateway and Off-Chain Services The API gateway, implemented in Node.js with Express, bridges client applications with the Fabric network and off- chain services. It maintains per-organization wallet directo- ries containing enrolled identities, selecting the appropriate wallet based on the X-Org header or endpoint-specific defaults. The gateway connects to the Fabric network using the fabric-network SDK with connection pooling and au- tomatic reconnection with exponential backoff. For IPFS integration, the gateway communicates with the local Kubo daemon via its HTTP API. The /api/ipfs/upload end- point accepts image uploads, stores them in IPFS, computes the SHA-256 hash, and returns both the CID and hash for inclusion in inspection submissions. Thetraceabilityproofendpoint (/api/blades/:sn/proof)aggregatestheblade Algorithm 2: SubmitInspectionResult Input: serialNumber, inspectionData, imageCID, imageHash Output: Inspection event recorded, state updated 1 blade ← GetBlade(serialNumber); 2 if blade.currentState ̸= INSPECTION DUE then 3return error: blade not due for inspection; 4 end 5 mspID ← GetClientMSPID(); 6 inspector ← GetClientID(); 7 event ← new InspectionEvent; 8 event.eventID ← serialNumber + “ ” + timestamp; 9 event.inspector ← inspector; 10 event.organization ← mspID; 11 event.aiModelName ← inspectionData.modelName; 12 event.aiModelVersion ← inspectionData.modelVersion; 13 event.detectedDefects ← inspectionData.defects; 14 event.defectCount ← Length(inspectionData.defects); 15 event.overallResult ← inspectionData.result; 16 event.imageIPFS ← imageCID; 17 event.imageHash ← imageHash; 18 event.flightHoursAtInspection ← blade.totalFlightHours; 19 event.flightCyclesAtInspection ← blade.totalFlightCycles; 20 blade.currentState ← UNDER INSPECTION; 21 blade.inspectionHistory.append(event.eventID); 22 blade.totalInspections ← blade.totalInspections + 1; 23 if event.defectCount > 0 then 24EmitEvent(DefectDetectedEvent, event); 25 end 26 SaveInspectionEvent(event); 27 SaveBlade(blade); record and all inspection events, recomputes SHA-256 hashes of the serialized data, and bundles IPFS retrieval URLs for each inspection image. This proof package can be independently verified by regulators without trusting the API gateway. Real-time event delivery uses Server-Sent Events (SSE) via the /api/events/stream endpoint, which re- publishes chaincode events (InspectionDueEvent, DefectDetectedEvent, OEMDefectAlert, Blade- ScrapedEvent) to subscribed clients. D. Defect Detection Integration BladeChain integrates AI-based defect detection as a pluggable, external module rather than embedding inference within the API gateway. This design enables model updates without modifying the core system and supports heteroge- neous detection approaches across organizations. The prototype uses a YOLOv8 model trained on the BladeSynth dataset [37], a synthetic dataset of turbine blade images with pixel-level defect annotations. BladeSynth pro- vides controlled generation of healthy and defective blade images, enabling systematic evaluation of detection perfor- mance across defect types. Figure 5 shows examples of healthy and defective blade images from the dataset. (a) Healthy blade(b) Defective blade(c) AI-detection Fig. 5: Blade images at different processing stages: (a) healthy blade generated using BladeSynth; (b) defective blade generated using BladeSynth; (c) AI inference result for the defective image in (b), showing detected defects annotated with bounding boxes. The detection module accepts a blade image and returns a structured payload containing the model name and version, detected defects with classifications and confidence scores, bounding box coordinates, and an overall result (PASS, FAIL, or CRITICAL based on defect severity). This payload is submitted to the API gateway, which records it on-chain along with the IPFS CID and SHA-256 hash of the original image. By recording the AI model name and version with each inspection, BladeChain enables auditors to assess detection results in context. If a model is later found to have systematic blind spots, historical inspections using that model can be identified and flagged for re-evaluation, which is a capability absent from systems that treat AI detection as a black box. E. Client Applications BladeChain includes a web-based dashboard that provides stakeholder-specific views over the consortium ledger. The application communicates with the API gateway via REST calls and subscribes to real-time events through SSE. Figure 7 highlights two core interfaces. The dashboard provides a high-level operational overview, including state distribution, inspection due counts, and storage/AI summary metrics. The blade registry supports search, filtering, and sorting across the entire fleet, allowing users to quickly locate blades by serial number, owner, or life cycle state. The inspection history view, in Figure 6 (cropped from a blade dossier page), focuses on AI-assisted inspection events with IPFS-hosted images and cryptographic hashes, while the full dossier page also exposes additional blade metrics such as flight hours, cycles, ownership, and life cycle status. Together, these views provide both system-wide situational awareness and drill-down traceability for individual assets. Fig. 6: AI inspection history view (cropped from blade dossier), showing IPFS-stored images and SHA-256 hashes. The full dossier view also includes blade metrics such as operating hours, cycles, ownership, and current state. V. EVALUATION We evaluate BladeChain through functional validation, performance benchmarking, and security analysis. Our exper- iments address three questions: (1) Does the system correctly enforce the blade life cycle state machine? (2) How does performance scale with workload size? (3) Does the tamper- evidence mechanism detect artifact manipulation? A. Experimental Setup Experiments were conducted on a machine with an Intel Core Ultra 7 165U processor (12 cores, 24 threads), 16 GB RAM, and NVMe SSD storage, running Ubuntu 24.04 LTS with Docker 28.4.0. The Fabric network consisted of four organizations (OEM, Airline, MRO, Regulator), each oper- ating one peer with CouchDB state storage, and a three- node Raft ordering cluster. The bladelifecycle chain- code was deployed on the blade-lifecycle-channel with a majority endorsement policy requiring three of four organizations. The workload simulator drives blades through complete life cycle scenarios: manufacturing, release to the airline, flight operations (15–35 flights per cycle, 2–8 hours per flight), inspection with AI detection, and repair when defects are found. Each blade completes two full inspection cycles, with inspection thresholds set at 500 flight hours, 500 cycles, or 180 days. These parameters reflect representative airline maintenance scheduling practices, where component inspec- tions are triggered by whichever limit is reached first among flight hours, flight cycles, or calendar time [38]. The selected (a) Dashboard overview (b) Blade registry with search and filters Fig. 7: BladeChain web application interfaces: (a) system dashboard summarizing life cycle and integrity metrics; (b) blade registry for search, filter, and state tracking. thresholds approximate typical A-check maintenance inter- vals for commercial aircraft [39]. We evaluated three work- load sizes: 10, 50, and 100 blades, generating approximately 430, 2,160, and 4,080 API operations, respectively. B. Functional Validation We validated that BladeChain correctly enforces the blade life cycle state machine across all workload sizes. Table VII summarizes the results. TABLE VII: Functional validation results. WorkloadCompletedOperations 10 blades× 2 cycles10/10 (100%)429 50 blades× 2 cycles50/50 (100%)2,157 100 blades× 2 cycles100/100 (100%)4,075 All blades successfully progressed through the complete life cycle: MANUFACTURED → IN SERVICE → INSPEC- TION DUE → UNDERINSPECTION → UNDERREPAIR (when defects detected)→ INSERVICE. The chaincode cor- rectly triggered automatic transitions to INSPECTION DUE when flight hour, cycle, or calendar thresholds were ex- ceeded. Inspection events were recorded with AI model metadata, IPFS CIDs, and SHA-256 hashes, confirming that evidence binding operates as designed. C. Performance Evaluation a) Throughput and Scalability: Table VIII presents throughput measurements across workload sizes. The system maintains a consistent throughput of 25.8–26.3 operations per minute regardless of workload size, demonstrating linear scalability. This throughput is appropriate for maintenance workloads where inspections occur every 500+ flight hours rather than in real-time. TABLE VIII: Scalability evaluation results. WorkloadDurationThroughputOps/Blade 10 blades979 sec26.28 ops/min42.9 50 blades4,933 sec26.24 ops/min43.1 100 blades9,476 sec25.80 ops/min40.8 b) Transaction Latency:Write operations (state- changing transactions requiring consensus) exhibit a median latency of 2,084 ms with P95 at 2,103 ms. Table IX breaks down latency by operation type for the 100-blade workload. The consistent latency across operation types reflects the uniform cost of Raft consensus and multi-organization en- dorsement. Read operations, which do not require consensus, complete in 17–22 ms. c) Baseline Comparison: To contextualize the perfor- mance overhead of blockchain-based traceability, we imple- mented an equivalent system using PostgreSQL 16.11 as a centralized database, deployed locally on the same hardware described in Section V-A. The baseline schema mirrors the TABLE IX: Transaction latency by operation type. OperationCountP50 (ms)P95 (ms)Max (ms) Manufacture1002,0922,1022,123 Flight log1,800+2,0852,1052,107 Inspection200+2,0792,0952,098 Repair100+2,0802,0872,100 Approval100+2,0742,0762,076 chaincode data structures (blades, inspections, flight oper- ations, repairs) with indexes on blade identifiers and state fields. PostgreSQL was configured with default settings, with synchronous commit=on and fsync=on to ensure durability semantics comparable to the blockchain’s persis- tence guarantees. Table X compares the two approaches. TABLE X: Performance comparison: BladeChain vs. Post- greSQL baseline. MetricPostgreSQLBladeChainRatio Duration (100 blades)92 sec9,476 sec103× Throughput3,617 ops/min25.8 ops/min140× Write latency (avg)0.72 ms2,087 ms2,899× Read latency (avg)0.88 ms20.9 ms24× BladeChain’s throughput is approximately 140× lower than the centralized baseline. This overhead reflects the cost of four-organization consensus, cryptographic endorse- ment signatures, and append-only ledger semantics. How- ever, these properties, which are impossible to achieve in a centralized database, are precisely what enable multi-party trust without a central authority. For aviation maintenance workloads, where a blade undergoes inspection every 500+ flight hours (months of operation), the two-second transac- tion latency poses no operational constraint. The tradeoff favors integrity and auditability over raw throughput. d) IPFSOverhead:Inspectionimagesaverage 2.06 MB each, while on-chain metadata (CID, hash, defect records) requires approximately 0.5 KB, which is a ratio of 0.024%. IPFS upload latency averages 40 ms and does not significantly impact end-to-end inspection recording time, which is dominated by Fabric consensus overhead. D. Security Validation We validated BladeChain’s tamper-evidence mechanisms through controlled experiments. a) IPFS Hash Integrity: Figure 8 illustrates the tam- per detection mechanism. At inspection time, the SHA- 256 hash of the image is computed and stored on-chain alongside the IPFS CID. To verify integrity, the image is retrieved from IPFS, and its hash is recomputed. If the hashes match, the artifact is authentic; any modification produces a different hash, resulting in a detectable mismatch. In our test runs, we uploaded an inspection image, recorded its hash (ac4f193f...), modified the image bytes, and recomputed the hash (b90c534b...); the system flagged the mismatch in all trials as expected. Hash recomputation averaged 17.95 ms (max 22.34 ms), showing that verification remains lightweight. Fig. 8: Tamper detection verification. The recomputed hash from the retrieved artifact differs from the on-chain hash, producing a detectable mismatch. b) Blockchain Immutability: We verified that the append-only ledger prevents historical modification by at- tempting to alter previously committed blade records. The Fabric ledger correctly rejected all modification attempts, and the complete history remained intact and verifiable through the GetBladeCompleteHistory query. Figure 9 provides the corresponding console evidence for the security validation results. Fig. 9: Console output excerpt from the tamper-evidence test, confirming the hash mismatch and verification timing. These results confirm that BladeChain provides the tamper-evidence guarantees required for regulatory com- pliance: inspection artifacts cannot be modified without detection, and historical records remain immutable once committed to the distributed ledger. VI. CONCLUSION This paper presented BladeChain, a blockchain-based framework for aircraft engine blade inspection traceability. By combining Hyperledger Fabric’s permissioned ledger with IPFS-based artifact storage and pluggable AI defect detection, BladeChain addresses critical gaps in existing aviation maintenance systems: the lack of multi-party trust, the absence of tamper-evident evidence binding, and the inability to audit AI-assisted inspection decisions. Our design enforces inspection schedules through chaincode-level state machine transitions, eliminating the manual tracking errors that plague current systems. The multi-organization endorsement policy ensures that no single party can unilaterally create or modify inspection records, while cryptographic binding of inspection images via SHA- 256 hashes and IPFS CIDs enables verification of artifact integrity. By recording the AI model name and version for each inspection, BladeChain provides the provenance infor- mation regulators need to assess detection results and identify blades inspected by models later found to be deficient. Evaluation of workloads up to 100 blades demonstrated 100% functional correctness across the complete life cycle state machine, with consistent throughput of approximately 26 operations per minute. While this represents a reduction compared to a centralized PostgreSQL baseline, the over- head reflects the cost of four-organization consensus and immutable ledger semantics, which are properties essential for multi-party trust and regulatory compliance. Security validation confirmed that artifact tampering is detected within 17 ms through hash verification, and the append-only ledger prevents unauthorized modification of historical records. BladeChain demonstrates that blockchain technology can provide the trust, transparency, and auditability required for safety-critical aviation maintenance workflows. As regula- tory frameworks increasingly mandate digital traceability, systems like BladeChain offer a path toward tamper-evident maintenance records that all stakeholders can independently verify and trust [40]. Future work will explore integration with legacy mainte- nance management systems such as AMOS and TRAX, posi- tioning BladeChain as an automated verification layer rather than a replacement for existing workflows. This approach would allow stakeholders to retain their current software investments while gaining the benefits of blockchain-based traceability, with BladeChain operating either as a standalone solution with its web dashboard or as a backend verification service integrated via standard APIs. VII. ACKNOWLEDGMENTS This research was funded by Khalifa University of Science and Technology through the Faculty Start-Up (FSU) Fund under Project ID: KU-INT-FSU-2024-8474000660. REFERENCES [1] H. Qi, Y. Lu, S. Song, and Q. Xu, “Fatigue reliability analysis system for key components of aero-engine,” International Journal of Aerospace Engineering, vol. 2022, p. 1–14, Oct. 2022. [Online]. Available: http://dx.doi.org/10.1155/2022/1143901 [2] A. O. Abu, S. Eshati, P. Laskaridis, and R. Singh, “Aero-engine turbine blade life assessment using the neu/sehitoglu damage model,” International Journal of Fatigue, vol. 61, p. 160–169, 2014. [Online]. Available: https://w.sciencedirect.com/science/article/pii/ S0142112313003307 [3] IATA, “Guidance material and best practices for life-limited parts traceability,” International Air Transport Association, Tech. Rep., 2020. [Online]. Available: https://w.iata.org/contentassets/ d1ca23709f94de6a30e8837952a57bf/llp-traceability-1st-ed-2020.pdf [4] G. Ho, Y. M. Tang, K. Y. Tsang, V. Tang, and K. Y. Chau, “A blockchain-based system to enhance aircraft parts traceability and trackability for inventory management,” Expert Systems with Applications, vol. 179, p. 115101, 2021. [Online]. Available: https: //w.sciencedirect.com/science/article/pii/S095741742100542X [5] J. P ́ erezgonz ́ alez, N. McDonald, and E. Smith, “A review of the occurrence reporting system proposed by easa part-145,” Safety Science, vol. 43, no. 8, p. 559–570, 2005. [Online]. Available: https: //w.sciencedirect.com/science/article/pii/S0925753505000640 [6] FederalAviationAdministration,“Technicaldocumentation challenges in aviation maintenance,” FAA Office of Aerospace Medicine,Tech.Rep.DOT/FAA/AM-12/16,2012.[On- line]. Available: https://w.faa.gov/sites/faa.gov/files/data research/ research/medhumanfacs/oamtechreports/201216.pdf [7] M. K. Paidisetty, S. Singh, V. Sanal Kumar, O. Prakash, and R. Saladi, “Evaluating the crucial influence of aircraft maintenance records and safety control on aviation safety – a comprehensive analysis,” in AIAA AVIATION FORUM AND ASCEND 2024.American Institute of Aeronautics and Astronautics, Jul. 2024. [Online]. Available: http://dx.doi.org/10.2514/6.2024-4319 [8] A. Shanmugam and T. Paul Robert, “Human factors engineering in aircraft maintenance: a review,” Journal of Quality in Maintenance Engineering, vol. 21, no. 4, p. 478–505, 10 2015. [Online]. Available: https://doi.org/10.1108/JQME-05-2013-0030 [9] C. Xu, G. Bi, and C. Wu, “The impact of retailer’s demand forecast information sharing on platform supply chain efficiency under blockchain technology,” Computers & Industrial Engineering, vol. 212, p. 111688, 2026. [Online]. Available: https://w.sciencedirect. com/science/article/pii/S0360835225008344 [10] N. Zimmermann and F. A. C. Mendonca, “The impact of human factors and maintenance documentation on aviation safety: An analysis of 15 years of accident data through the pear framework,” Collegiate Aviation Review International, vol. 39, no. 2, 2021. [Online]. Available: http://dx.doi.org/10.22488/okstate.22.100230 [11] W. Lang Jensen, S. Jessing, W.-Y. Chiu, and W. Meng, “Airchain - towards blockchain-based aircraft maintenance record system,” in 2022 IEEE International Conference on Blockchain and Cryptocurrency (ICBC), 2022, p. 1–3. [12] A. Aleshi, R. Seker, and R. F. Babiceanu, “Blockchain model for enhancing aircraft maintenance records security,” in 2019 IEEE Inter- national Symposium on Technologies for Homeland Security (HST), 2019, p. 1–7. [13] S. Nam, W.-K. Song, and H. Yoon, “An maintenance, repair, and overhaul (mro) safety oversight system analysis: A case in korea,” Journal of Air Transport Management, vol. 107, p. 102349, 2023, cites Oliver Wyman (2022): total MRO market size estimated to reach $126.6 billion by 2032. [Online]. Available: https: //w.sciencedirect.com/science/article/pii/S0969699722001685 [14] Y. Huang, G. Sun, T. Rabczuk, and X. Zhuang, “Propagation and evolution graph method embedded with physical constraints for multi-factor coupled deep fault diagnosis in aero-engines,” Energy, vol. 342, p. 139555, 2026. [Online]. Available: https: //w.sciencedirect.com/science/article/pii/S0360544225051977 [15] R. W. Ahmad, H. Hasan, I. Yaqoob, K. Salah, R. Jayaraman, and M. Omar, “Blockchain for aerospace and defense: Opportunities and open research challenges,” Computers & Industrial Engineering, vol. 151, p. 106982, 2021. [16] Y. Abdulrahman, M. A. M. Eltoum, A. Ayyad, B. Moyo, and Y. Zweiri, “Aero-engine blade defect detection: A systematic review of deep learning models,” IEEE Access, vol. 11, p. 53 048–53 061, 2023. [17] Y. Abdulrahman, E. Arnautovi ́ c, V. Parezanovi ́ c, and D. Svetinovic, “Ai and blockchain synergy in aerospace engineering: An impact survey on operational efficiency and technological challenges,” IEEE Access, vol. 11, p. 87 790–87 804, 2023. [18] D. Oliveira-Dias, J. M. Maqueira-Mar ́ ın, and J. Moyano-Fuentes, “The link between information and digital technologies of industry 4.0 and agile supply chain: Mapping current research and establishing new research avenues,” Computers & Industrial Engineering, vol. 167, p. 108000, 2022. [Online]. Available: https://w.sciencedirect. com/science/article/pii/S0360835222000705 [19] C. Zhang, X. Li, H. Xu, Z. Li, and X. Zhao, “Does blockchain- enabled quality inspection work better in hybrid retailing?” Computers & Industrial Engineering, vol. 204, p. 111092, 2025. [Online]. Available: https://w.sciencedirect.com/science/article/pii/ S0360835225002384 [20] R. W. Ahmad, K. Salah, R. Jayaraman, H. R. Hasan, I. Yaqoob, and M. Omar, “The role of blockchain technology in aviation industry,” IEEE Aerospace and Electronic Systems Magazine, vol. 36, no. 3, p. 4–15, 2021. [21] M. Efthymiou, K. McCarthy, C. Markou, and J. F. O’Connell, “An exploratory research on blockchain in aviation: The case of maintenance, repair and overhaul (mro) organizations,” Sustainability, vol. 14, no. 5, 2022. [Online]. Available: https://w.mdpi.com/ 2071-1050/14/5/2643 [22] Y. Abdulrahman, V. Parezanovic, and D. Svetinovic, “Ai-blockchain systems in aerospace engineering and management: Review and chal- lenges,” in 2022 30th Telecommunications Forum (TELFOR), 2022, p. 1–4. [23] K. W ̈ ust and A. Gervais, “Do you need a blockchain?” in 2018 Crypto Valley Conference on Blockchain Technology (CVCBT), 2018, p. 45– 54. [24] E. Androulaki, A. Barger, V. Bortnikov, C. Cachin, K. Christidis, A. De Caro, D. Enyeart, C. Ferris, G. Laventman, Y. Manevich, S. Muralidharan, C. Murthy, B. Nguyen, M. Sethi, G. Singh, K. Smith, A. Sorniotti, C. Stathakopoulou, M. Vukoli ́ c, S. W. Cocco, and J. Yellick, “Hyperledger fabric: a distributed operating system for permissioned blockchains,” in Proceedings of the Thirteenth EuroSys Conference, ser. EuroSys ’18.New York, NY, USA: Association for Computing Machinery, 2018. [Online]. Available: https://doi.org/10.1145/3190508.3190538 [25] J. Schyga, J. Hinckeldeyn, and J. Kreutzfeldt, “Prototype for a permissioned blockchain in aircraft mro,” in Hamburg International Conference of Logistics (HICL) 2019. epubli GmbH, 2019, p. 469– 505. [26] D. Hawashin, M. Nemer, K. Salah, R. Jayaraman, D. Svetinovic, and E. Damiani, “Blockchain and nft-based traceability and certification for uav parts in manufacturing,” Journal of Industrial Information Integration, vol. 39, p. 100597, 2024. [Online]. Available: https: //w.sciencedirect.com/science/article/pii/S2452414X24000414 [27] I. Kabashkin, “Nft-based framework for digital twin management in aviation component lifecycle tracking,” Algorithms, vol. 17, no. 11, 2024. [Online]. Available: https://w.mdpi.com/1999-4893/17/11/ 494 [28] A.Alqaryuti,K.Moawad,K.Salah,A.Mayyas,and R.Jayaraman,“Blockchain-drivenframeworkforpreventive maintenance management of aircraft hydraulic systems,” Discover Internet of Things, vol. 5, no. 1, Apr. 2025. [Online]. Available: http://dx.doi.org/10.1007/s43926-025-00149-x [29] P. C. Joeaneke, T. M. Kolade, O. Obioha-Val, A. O. Olisa, S. A. Joseph, and O. O. Olaniyi, “Enhancing security and traceability in aerospace supply chains through block chain technology,” Journal of Engineering Research and Reports, vol. 26, no. 10, p. 114–135, Oct. 2024. [Online]. Available: http://dx.doi.org/10.9734/jerr/2024/v26i101294 [30] H. Fatorachian and H. Kazemi, “Secure digital frameworks for cold chain emissions tracking: leveraging ai and blockchain for robust data integrity,” Computers & Industrial Engineering, vol. 209, p. 111467, 2025. [Online]. Available: https://w.sciencedirect.com/ science/article/pii/S0360835225006138 [31] Inayatulloh, D. L. Kusumastuti, and I. K. Hartono, “Aircraft reliability and maintenance with blockchain technology to improve flight safety,” in 2024 International Conference on Smart Computing, IoT and Machine Learning (SIML), 2024, p. 156–160. [32] I. Kabashkin, “The iceberg model for integrated aircraft health monitoring based on ai, blockchain, and data analytics,” Electronics, vol. 13, no. 19, p. 3822, Sep. 2024. [Online]. Available: http://dx.doi.org/10.3390/electronics13193822 [33] M. Efthymiou, K. McCarthy, C. Markou, and J. F. O’Connell, “An exploratory research on blockchain in aviation: The case of main- tenance, repair and overhaul (MRO) organizations,” Sustainability, vol. 14, no. 5, p. 2643, 2022. [34] E. Tapia, L. Sastoque-Pinilla, B. Gamecho, and U. Lopez-Novoa, “Integration of blockchain-based digital identity management in an aeronautical manufacturing setting,” The International Journal of Advanced Manufacturing Technology, Aug. 2025. [Online]. Available: http://dx.doi.org/10.1007/s00170-025-16260-w [35] E. Androulaki, A. Barger, V. Bortnikov, C. Cachin, K. Christidis, A. De Caro, D. Enyeart, C. Ferris, G. Laventman, Y. Manevich, S. Muralidharan, C. Murthy, B. Nguyen, M. Sethi, G. Singh, K. Smith, A. Sorniotti, C. Stathakopoulou, M. Vukoli ́ c, S. W. Cocco, and J. Yellick, “Hyperledger fabric: a distributed operating system for permissioned blockchains,” in Proceedings of the Thirteenth EuroSys Conference, ser. EuroSys ’18.ACM, Apr. 2018, p. 1–15. [Online]. Available: http://dx.doi.org/10.1145/3190508.3190538 [36] J. Benet, “Ipfs - content addressed, versioned, p2p file system,” 2014. [Online]. Available: https://arxiv.org/abs/1407.3561 [37] M. A. Mohammed Eltoum, E. Iqbal, Y. Zweiri, B. Moyo, and Y. Abdulrahman, “Bladesynth: A high-quality rendering- based synthetic dataset for aero engine blade defect inspection,” Scientific Data, vol. 12, no. 1, Jul. 2025. [Online]. Available: http://dx.doi.org/10.1038/s41597-025-05563-y [38] R. Salto ̆ glu, N. Humaira, and G. ̇ Inalhan, “Aircraft scheduled airframe maintenance and downtime integrated cost model,” Advances in Operations Research, vol. 2016, p. 1–12, 2016. [Online]. Available: http://dx.doi.org/10.1155/2016/2576825 [39] Q. Deng, B. F. Santos, and R. Curran, “A practical dynamic programming based methodology for aircraft maintenance check scheduling optimization,” European Journal of Operational Research, vol. 281, no. 2, p. 256–273, 2020. [Online]. Available: https: //w.sciencedirect.com/science/article/pii/S0377221719306782 [40] L. A. Risso, G. M. D. Ganga, M. Godinho Filho, L. A. de Santa-Eulalia, T. Chikhi, and E. Mosconi, “Present and future perspectives of blockchain in supply chain management: a review of reviews and research agenda,” Computers & Industrial Engineering, vol. 179, p. 109195, 2023. [Online]. Available: https: //w.sciencedirect.com/science/article/pii/S036083522300219X