{"paper_id":"0f8a969a-58b1-4ad2-84b9-a23ecafbb2e5","body_text":"Performance Evaluation of a Hyperledger Fabric–Based Permissioned Blockchain Network for Cross-Border Regulatory Applications | Research Square window.SnipcartSettings = { analytics: { enabled: false } }; (function() { var accessVector = localStorage.getItem('access_vector') || ''; window.dataLayer = window.dataLayer || []; if (accessVector) { window.dataLayer.push({ user: { profile: { profileInfo: { snid: accessVector } } } }); } })(); (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src='https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);})(window,document,'script','dataLayer','GTM-K279D39R'); Browse Preprints In Review Journals COVID-19 Preprints AJE Video Bytes Research Tools Research Promotion AJE Professional Editing AJE Rubriq About Preprint Platform In Review Editorial Policies Our Team Advisory Board Help Center Sign In Submit a Preprint Cite Share Download PDF Research Article Performance Evaluation of a Hyperledger Fabric–Based Permissioned Blockchain Network for Cross-Border Regulatory Applications Ayele Legesse, Birhanu Beshah, Ermias Tesfaye, Yalew Kidane Tolcha This is a preprint; it has not been peer reviewed by a journal. https://doi.org/ 10.21203/rs.3.rs-8611135/v1 This work is licensed under a CC BY 4.0 License Status: Under Review Version 1 posted 5 You are reading this latest preprint version Abstract Permissioned blockchain platforms operate as peer-to-peer distributed systems whose performance, scalability, and resource behavior are critical for deployment in cross-border regulatory applications. Effective regulatory coordination within Free Trade Areas (FTAs) is nevertheless hindered by fragmented National Quality Infrastructure (NQI) systems, limited interoperability, and weak institutional trust mechanisms. This study addresses these challenges by designing and experimentally evaluating a permissioned blockchain network based on Hyperledger Fabric to support interoperable, transparent, and auditable NQI processes. Using the African Continental Free Trade Area (AfCFTA) as an illustrative regulatory environment, the proposed system models core regulatory transactions—such as standards submission and endorsement, accreditation recording, and certificate verification—through smart contracts executed across multiple peer organizations. The design distinguishes between write-intensive submission transactions, which require multi-peer endorsement and ordering, and read-only verification and audit transactions executed locally at peer nodes. The framework is implemented in Go using the Fabric Contract API and evaluated on Hyperledger Fabric v2.5 using Hyperledger Caliper v0.6.0. Experimental results under varying concurrency and load conditions demonstrate low-latency read performance (sub-15 ms) and a write-throughput ceiling of approximately 400 TPS, attributable to endorsement and ordering overheads in the consensus pipeline. These results provide empirical insights into performance trade-offs in permissioned peer-to-peer blockchain networks and confirm the suitability of Hyperledger Fabric for compliance-driven, multi-institutional regulatory environments. Peer-to-Peer Blockchain Networks Permissioned Blockchain Hyperledger Fabric Blockchain Performance Evaluation Throughput and Latency Analysis Distributed Ledger Systems Figures Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 Figure 7 Figure 8 1. Introduction The accelerating digital transformation of governance and regulatory systems has positioned permissioned blockchain platforms as peer-to-peer distributed systems capable of supporting institutional transparency, accountability, and cross-border interoperability [1, 2]. Its distributed and tamper-resistant architecture enables organizations to exchange trusted information without dependence on centralized intermediaries [3]. This property is particularly valuable in regulatory ecosystems, where multiple autonomous entities must coordinate to uphold product quality, safety, and compliance across jurisdictions [1, 4]. Across many regional free trade agreements (FTAs), including Africa’s AfCFTA, regulatory harmonization remains a persistent challenge. Disparities in institutional capacity, fragmented conformity-assessment systems, and inconsistent regulatory infrastructures hinder effective cooperation and mutual recognition of standards [5–7]. Because National Quality Infrastructure (NQI) systems—encompassing metrology, accreditation, standards, and conformity assessment—constitute the backbone of cross-border regulatory assurance, [8–10], a secure and interoperable digital infrastructure is essential for improving coordination among participating authorities. From a systems perspective, these coordination challenges translate into requirements for distributed data consistency, secure peer communication, and scalable transaction processing across autonomous institutions. Distributed ledger technology offers a promising foundation for such integration by enabling peer-to-peer data replication, decentralized trust establishment, and consensus-driven state synchronization across independent organizations [1, 4]. Yet, the application of blockchain to policy-regulated and compliance-intensive domains raises specific challenges. Public blockchains such as Bitcoin or Ethereum deliver high decentralization but lack the privacy, governance flexibility, and performance predictability demanded by regulatory authorities [11, 12]. By contrast, permissioned frameworks such as Hyperledger Fabric (HLF) provide authenticated participation, fine-grained access control, and modular consensus protocols [13, 14]. These features make HLF well-suited for institutional ecosystems that require transparency and accountability without sacrificing confidentiality or performance. Despite this alignment, empirical research on how permissioned blockchain networks such as Hyperledger Fabric perform under realistic, multi-organization regulatory workloads remains limited. Existing studies have primarily focused on blockchain’s conceptual benefits—traceability, auditability, and transparency in governance—rather than its operational viability within resource-constrained or heterogeneous institutional environments [1]. In particular, limited attention has been paid to how endorsement policies, ordering services, and peer concurrency jointly affect throughput, latency, and scalability in permissioned peer-to-peer blockchain networks. Benchmarking efforts such as those by Thakkar et al. [15] and Dreyer et al. [16] provided useful insights into throughput and latency behavior but were detached from policy or regulatory contexts. Furthermore, few studies have examined the interplay between consensus mechanisms, data-sharing requirements, and institutional governance structures in cross-border cooperation settings [17, 18]. This gap is especially evident in the governance landscape of emerging FTAs—such as the AfCFTA—where harmonized regulatory oversight across multiple national NQI agencies requires digital systems that support both verifiability and jurisdictional autonomy. While blockchain promises distributed assurance, the absence of empirical evaluations linking its architectural features to NQI processes limits informed adoption and policy formulation [19]. These constraints make AfCFTA an analytically useful setting for evaluating the scalability and performance limits of permissioned blockchain networks under cross-border, multi-institutional conditions. Addressing these gaps requires examining blockchain not merely as a technical innovation but as a socio-technical infrastructure—a hybrid system in which institutional trust mechanisms are embedded within computational logic. This view is supported by the cyber-institutional perspective, which argues that governance functions—such as verification, compliance, and accountability—can be operationalized through technical primitives like consensus algorithms and smart contracts [1, 20–22]. Within this paradigm, blockchain serves as both a technological enabler and a governance mediator, translating institutional protocols into programmable, auditable workflows. From a networking perspective, this implies that governance logic is increasingly coupled with transaction flow, message ordering, and consensus latency. Hyperledger Fabric offers distinct advantages for such applications. Its execution-ordering-validation architecture, which explicitly separates peer execution, ordering, and validation stages, supported by the consensus mechanism and Membership Service Provider (MSP) framework, provides a configurable foundation for secure multi-organizational collaboration [23]. This makes Fabric well-suited for automating NQI processes, including standards approval, conformity assessment, and certification data management, in cross-border regulatory ecosystems. Accordingly, this study addresses three core research questions: RQ1: How can a Hyperledger Fabric–based blockchain network and smart contracts be designed to support, automate, and harmonize key NQI regulatory functions within regional FTAs (illustrated using AfCFTA)? RQ2: How does the proposed Hyperledger Fabric peer-to-peer network perform under varying transaction workloads—evaluated through throughput, latency, efficiency, and resource utilization—using standardized benchmarking tools? RQ3: What insights do empirical results provide for optimizing scalability, consensus efficiency, and broader adoption of blockchain-enabled regulatory systems in cross-border trade environments? By framing these guiding questions, this study situates itself at the intersection of blockchain engineering and institutional governance. It contributes conceptually by advancing the understanding of how decentralized architectures can underpin trust-centric regulatory systems, and empirically by demonstrating how permissioned blockchain infrastructures can be evaluated for their suitability in complex, multi-jurisdictional environments. In summary, this research examines how a Hyperledger Fabric–based smart contract framework can operationalize trust, transparency, and interoperability for NQI processes under regional FTAs, using AfCFTA as an illustrative context. The study draws insights from information systems, production governance, and digital policy to propose a structured foundation for blockchain-enabled regulatory cooperation. The remainder of this paper is organized as follows. Section 2 delves in to the analysis of relevant literature and the gaps. Section 3 develops the conceptual framework connecting blockchain governance with NQI and AfCFTA objectives. Section 4 describes the system design and research methodology. Section 5 presents and analyzes experimental results on performance, and discusses the institutional implications of the findings, and Section 6 concludes with key insights, limitations and future research directions. 2. Literature Review 2.1 Blockchain for Institutional and Regulatory Systems Blockchain technology has emerged as a transformative peer-to-peer distributed system enabling institutional transparency, regulatory efficiency, and cross-border interoperability. Studies such as Patil & Sangeetha [14] highlighted its ability to enhance institutional trust through secure, auditable, and decentralized infrastructures, especially in cross-border fund transfers. Similarly, Naseem & Yong [17] has shown how blockchain reduces compliance and data risks in global supply chains, enabling proactive regulatory assurance. A broader synthesis in Casino et al. [24] identified transparency, security, immutability, and auditability as core drivers of institutional reform. Within NQI environments, blockchain reinforces metrology, conformity assessment, and certification functions by enabling secure verification of digital records and traceability data [25–29]. The Sea-Trace-Pricing (STP) framework proposed by Rani et al. [28] enhances dynamic pricing and traceability in the seafood supply chain through blockchain, demonstrating its capacity to address pricing volatility and fraud. Practical deployments, including UNIDO’s pilot in Ghana’s cocoa value chain, demonstrated how blockchain reduces process costs while increasing trust through real-time traceability [29], through real-time traceability enabled by decentralized data replication across participating nodes. In legal metrology, blockchain and smart contracts automate workflows and preserve measurement integrity, strengthening confidence in compliance processes [30, 31]. Sector-specific researches further reinforced blockchain’s regulatory significance. Kumar et al. [32] demonstrate its capacity to improve transparency and auditability across diverse supply chain governance contexts, while G. Liu et al. [33] has shown that blockchain preserves compliance and traceability even in highly competitive environments. Benchis et al. [34] identified substantial sectoral variation in adoption trajectories, underscoring the need for domain-sensitive deployment strategies. Taken together, this body of work illustrates that blockchain’s institutional value extends beyond technical functionality, residing in its ability to institutionalize transparency, accountability, and interoperability through distributed, peer-to-peer system architectures. 2.2. Hyperledger Fabric as a Permissioned Blockchain Platform Hyperledger Fabric has emerged as a leading permissioned peer-to-peer blockchain platform for enterprise and regulatory applications due to its modularity, scalability, and granular governance features. The conceptual model in Uyar et al. [35] demonstrated Fabric’s adaptability for compliance-oriented traceability systems, integrating IoT sensors and smart contracts to enforce automated regulatory validation. Foundational work of Androulaki et al. [36] detail Fabric’s architectural innovation—its execute–order–validate logic, configurable consensus mechanisms, and MSP-based identity management— which collectively support authenticated multi-organizational collaboration and high performance in peer-to-peer transaction propagation and validation, as illustrated in Fig. 1. These characteristics make Fabric particularly suitable for NQI implementations, where role-based access control, decentralized audit trails, and secure certificate verification are essential [26]. Research in metrology suggests Fabric can support inter-NMI (National Metrology Institutions) blockchain networks that enhance data exchange, regulatory coordination, and mutual recognition arrangements [27]. Extending these capabilities, (Jagadeesh Sai et al. [37] demonstrated Fabric’s utility in permissioned identity and access management. Additionally, Kaushal et al. [38] introduced a Hyperledger Fabric-based remote patient monitoring system, showcasing its effectiveness in secure health data management. Together, these studies confirm Fabric’s versatility and operational suitability for regulated ecosystems requiring high trust, traceability, and institutional accountability. 2.3 Blockchain Benchmarking and Performance Evaluation Research on blockchain benchmarking has evolved through progressively deeper analytical and empirical contributions aimed at understanding the performance of peer-to-peer distributed ledger networks. Foundational studies such as Thakkar et al. [15] identified system parameters—endorsement policies, block size, and batch timeout—as primary drivers of throughput and latency, demonstrating that targeted tuning can substantially improve Hyperledger Fabric’s performance. Shortly after, Sukhwani et al. [40] advanced the analytical dimension by applying stochastic reward nets to predict throughput and queuing behavior, highlighting endorsement and validation delays as critical bottlenecks. Building on these early insights, Khan et al. [41] conducted empirical benchmarking using Hyperledger Caliper to examine Fabric’s scalability limits within SME-oriented environments, revealing practical trade-offs between network size and latency. Further extending analytical rigor, Melo et al. [42] introduced a stochastic Petri net model that quantifies how endorsement strategies, transaction flow, and ordering services affect system responsiveness, providing a validated framework for predictive performance assessment. More expansive work by Lau et al. [43] benchmarked public blockchain platforms, including Algorand, whose latency and throughput patterns reaffirm the broader importance of systematic performance evaluation across different blockchain architectures. Additionally, Ayub Khan et al. [44] proposed a framework that integrates Hyperledger Fabric with federated learning for Anti-Money Laundering systems, highlighting the need for operational efficiency and performance optimization in blockchain applications. Taken together, these studies establish performance benchmarking—combining model-driven analysis with empirical validation—as a cornerstone for improving scalability, predictability, and real-world applicability in peer-to-peer blockchain-based systems. Table 1 Summary of the literature on blockchain performance investigations Study Detailed content [45] This paper benchmarks Hyperledger Fabric's performance across architecture, setup, workloads, networks, and robustness using an enhanced DLPS framework, revealing scalability limits, throughput peaks, and latency sensitivities for enterprise blockchain applications like supply chains. [46] This paper presents a blockchain-based framework using smart contracts for supply chain collaboration, focusing on performance metrics such as throughput and latency to enhance resource sharing and operational efficiency among supply chain partners. [47] The paper reviews latency-related performance challenges in Hyperledger Fabric, examining factors affecting transaction delays, modeling techniques, and architectural bottlenecks. It highlights the need for accurate latency evaluation to support scalable and reliable IoT-blockchain deployments. [48] This paper analyzes the integration of blockchain technology in trade finance, highlighting its potential to optimize processes and reduce fraud. It proposes a hybrid solution combining blockchain with existing infrastructure for enhanced performance metrics. [14] This paper analyzes the performance of Hyperledger Fabric for cross-border fund transfers using benchmarking tools. It evaluates latency, scalability, and efficiency, providing insights into the platform's application in financial services. [49] This study benchmarks Hyperledger Fabric v2.4.9 performance under varying workloads, transaction rates (up to 350 TPS), chaincode languages (Go/Node.js), ordering services (Solo/Raft), and organizations, analyzing throughput, latency, success rates, and resource use to identify scalability bottlenecks. [43] The paper develops a blockchain-based messaging system using Algorand and evaluates its performance through benchmarking tests on latency, throughput, confirmation time, and efficiency. It provides practical performance insights for scalable, secure, and reliable blockchain communication in air-cargo supply chains. [39] This study benchmarks Hyperledger Fabric on heterogeneous hardware using Caliper, evaluating throughput (up to 1148 TPS), latency, CPU/memory usage for read/tokenize/transfer chaincodes in IoT networks. [50] This paper proposes lightweight Hyperledger Fabric/IoT authentication for SCM, benchmarked at 10ms execution, 80ms latency, 12 TPS using Composer—addresses cyber-attack resilience via hash functions. 2.4 Smart Contracts and Regulatory Automation Smart contracts represent a pivotal innovation in blockchain systems, enabling the automation of compliance, verification, and enforcement processes across institutional and regulatory environments. They enhance transparency, trust, and efficiency by embedding regulatory requirements directly into executable code, ensuring that transactions are validated and enforced without manual intervention, while facilitating real-time monitoring through distributed execution across peer nodes [46, 48]. This automation significantly reduces administrative delays, human error, and fraud, while facilitating real-time monitoring [48, 51]. Recent researches position smart contracts as the technological backbone of regulatory automation, transforming policy enforcement into self-executing logic. Studies such as Adeyinka Ogunbajo et al. [20] demonstrated how blockchain-integrated smart contracts can embed governance and compliance rules directly within transactional code, while Agrawal et al. [46] has shown how automated rule enforcement in supply chains mirrors the operation of regulatory oversight. The Model-Driven Architecture (MDA) approach proposed by Jurgelaitis et al. [51] further strengthened reliability by generating smart contracts from formal models, enhancing accuracy and reducing implementation errors—critical for trustworthy regulatory systems. In financial and trade contexts, smart contracts facilitate on-chain governance and automated compliance verification, bridging traditional trade processes with digital auditability [48, 52]. Within permissioned blockchains such as Hyperledger Fabric, these capabilities are realized through chaincode—modular, containerized smart contracts executed under defined endorsement policies. Fabric’s architecture allows authenticated institutions to collaborate securely while maintaining confidentiality and accountability, making it particularly suited for regulated ecosystems. Yet, despite growing evidence of their potential, empirical validation of smart contracts in multi-jurisdictional regulatory environments—particularly with respect to transaction throughput, latency, and scalability—remains scarce. This study addresses that gap by developing and evaluating Fabric-based smart contract (chaincode) designed to automate NQI functions under AfCFTA, demonstrating their effectiveness in achieving trusted, harmonized, and transparent regulatory cooperation. Table 2 provides a summary of blockchain applications, highlighting various studies' focus on regulatory automation, institutional integration, and smart contracts. Table 2 Literature Summary blockchain applications Study Area of Application Regulatory Automation Institutional Integration Focus on Smart Contracts Throughput Analysis Latency Analysis Efficiency Resource Utilization Evaluation of Scalability [45] cross-organizational processes ✖ ✓ ✓ ✓ ✓ ✓ a ✓ a ✓ [46] Supply chain/supply network collaboration ✓ ✓ ✓ ✖ ✖ ✓ ✓ ✖ [47] Internet of Things (IoT) environments ✖ ✖ ✓ a ✓ b ✖ ✖ ✖ ✓ a [48] Trade finance ✓ ✓ ✓ ✖ ✖ ✓ ✖ ✓ [14] Cross-Border Fund Transfers ✖ ✓ ✓ ✓ ✓ ✓ ✖ ✓ [49] B2B/B2C transactions ✖ ✓ ✓ ✓ ✓ ✓ ✓ ✓ [43] Air cargo supply chains ✖ ✓ ✓ ✓ ✓ ✓ ✖ ✓ [39] IoT ecosystems ✖ ✖ ✓ ✓ ✓ ✓ ✓ ✓ a This study Cross-border trade under FTAs ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ a The authors considered it conceptual, not in-depth b The authors considered it conceptually, no experimental benchmarking done 2.5 Research Gaps and Synthesis Despite growing interest in blockchain-enabled governance, key research gaps persist in evaluating the performance and scalability of peer-to-peer blockchain systems applied to policy-driven, cross-border frameworks such as AfCFTA. Current blockchain–NQI studies typically focus on isolated elements—such as conformity assessment or metrological traceability—without examining how blockchain could support an integrated NQI system capable of operating across diverse regulatory environments among AfCFTA member states [26, 27, 30, 31]. This systemic gap is especially significant given the need for harmonized standards and efficient regulatory assurance in regional trade. Similarly, while Hyperledger Fabric is frequently cited for its potential, limited research investigates the practical design, customization, and performance evaluation of Fabric-based smart contracts tailored to NQI regulatory functions under African jurisdictional conditions. This research addresses these gaps by developing a reproducible evaluation of Fabric in an AfCFTA-aligned configuration, linking performance analysis with regulatory design. Ultimately, sustainable blockchain integration in regulatory infrastructures requires aligning peer-to-peer system architectures, consensus mechanisms, and performance characteristics with institutional objectives, particularly within African trade integration. 3. Conceptual Framework for Peer-to-Peer Blockchain–Enabled NQI Governance The conceptual framework of this study integrates blockchain technology as a permissioned peer-to-peer distributed system, NQI systems, and AfCFTA regulatory objectives into a unified model for digital trust, interoperability, and performance-driven governance. It establishes the theoretical and operational foundation for designing and evaluating a permissioned blockchain system based on Hyperledger Fabric (HLF), aimed at automating compliance, ensuring traceability, and enhancing transparency across interconnected regulatory institutions. While AfCFTA is used as the illustrative regulatory environment, the framework is generalizable to other regional free trade agreements that rely on NQI coordination. 3.1. Framework Overview The framework (as depicted in Fig. 2) conceptualizes the interaction between AfCFTA’s regional regulatory ecosystem, as an illustrative case, and blockchain-based digital infrastructure through three interdependent layers: the Institutional Governance & Trust Layer, the Permissioned Blockchain & P2P Infrastructure Layer, and the Blockchain Performance & Scalability Evaluation Layer. These layers collectively form a closed feedback loop that connects governance objectives, peer-to-peer system design, and empirical performance validation. Policy-driven requirements such as standard harmonization, traceability, and data integrity inform blockchain design choices, while empirical performance outcomes provide feedback for refining both institutional and technical processes. This cyclical interaction ensures that digital systems evolve in alignment with regulatory and operational realities. From a networking perspective, this loop captures how institutional requirements shape peer interactions, consensus participation, and transaction propagation, while measured performance feeds back into architectural and policy refinement. 3.2. Institutional Governance & Trust Layer: AfCFTA–NQI Integration At the macro level, the AfCFTA framework seeks to eliminate trade barriers and promote regional economic integration by harmonizing technical regulations and conformity standards across member states. NQI systems—comprising metrology, standards, accreditation, and conformity assessment—constitute the operational backbone of these regulatory processes [53–55]. Yet, fragmentation among national systems in Africa, inconsistent certification procedures, and limited data interoperability remain significant challenges to the mutual recognition of conformity certificates and to cross-border trade efficiency[56–58]. Within the conceptual framework, the Permissioned Blockchain & P2P Infrastructure Layer defines the institutional logic and trust boundaries that the peer-to-peer blockchain system must accommodate. It outlines key regulatory principles such as the traceability of conformity assessments, immutability of certification data, and automatic validation of compliance conditions. These principles are then operationalized in the digital infrastructure layer through smart contracts and consensus mechanisms. By embedding governance logic into system architecture, the institutional layer ensures that the peer-to-peer blockchain infrastructure not only digitizes but also enforces regulatory integrity and accountability across distributed participants. 3.3. Permissioned Blockchain & P2P Infrastructure Layer: Blockchain and Smart Contracts The second layer translates institutional and policy requirements into a permissioned blockchain environment that supports secure, auditable, and efficient data exchange among regulatory agencies. Built conceptually on the Hyperledger Fabric architecture, this layer models a permissioned peer-to-peer network of organizations—each representing an NQI institution—interacting through deterministic message exchange, endorsement protocols, and a consensus mechanism such as Raft. Table 3 Mapping of AfCFTA-aligned NQI regulatory functions to blockchain transactions and smart contracts AfCFTA–NQI Function Business Transaction Smart Contract Ledger Operation Standards harmonization Submission of new technical standards Regulatory Submission and Endorsement Contract (Propose) Write Standards harmonization Multi-institutional endorsement of standards Regulatory Submission and Endorsement Contract (Propose) Write Accreditation Recording accreditation decisions Regulatory Submission and Endorsement Contract (Propose) Write Conformity assessment Submission of inspection or testing results Regulatory Submission and Endorsement Contract (Propose) Write Mutual recognition Validation of approved conformity certificates Regulatory Verification and Audit Contract (Query) Read Trade facilitation Certificate verification by regulators or border authorities Regulatory Verification and Audit Contract (Query) Read Compliance monitoring Regulatory audit and inspection queries Regulatory Verification and Audit Contract (Query) Read Institutional transparency Retrieval of immutable regulatory records Regulatory Verification and Audit Contract (Query) Read Table 3 summarizes how AfCFTA-aligned NQI regulatory functions are operationalized as blockchain transactions through functionally distinct smart contracts, forming the basis for the system design evaluated in subsequent sections. Two classes of smart contracts underpin this layer. The Propose Contract represents write-intensive operations that submit and endorse new records (e.g., standards proposals and indorsements, or accreditation results), requiring multi-organizational agreement to achieve consensus. The Query Contract represents read-only operations that retrieve certified data from the ledger, enabling real-time information access for regulators, auditors, and stakeholders. These two transaction types model the dual functionality of the blockchain—state-changing and read-only operations—and enable performance differentiation based on consensus involvement. From a networking perspective, this distinction separates consensus-bound transaction flows that traverse endorsement and ordering peers from local execution paths that operate entirely at individual peer nodes. The modular structure of Hyperledger Fabric supports this design by separating transaction execution, ordering, and validation [26, 27, 59, 60]. This separation enhances scalability and fault isolation while maintaining deterministic transaction flow across a distributed peer-to-peer execution and ordering pipeline. In addition, channel isolation provides privacy-preserving interactions between participating agencies, and the Membership Service Provider (MSP) framework ensures cryptographically verified digital identities. Together, these mechanisms operationalize a trust architecture that embodies institutional accountability and data sovereignty across FTAs. 3.4. System Design Specification for Blockchain-Enabled NQI Transactions Building on the transaction mappings summarized in Table 3, this subsection formalizes the regulatory workflows as system-level business transactions. While the preceding sections establish the conceptual and architectural foundations of a blockchain-enabled NQI framework, this subsection specifies the concrete system design that operationalizes these concepts. The purpose of this section is to explicitly define the distributed system structure, the AfCFTA-relevant business transactions, and the smart contract abstractions that are later implemented and evaluated experimentally in Section 4. 3.4.1. Design Scope and Assumptions The system design targets a permissioned distributed ledger environment in which multiple NQI institutions interact under a shared regulatory framework. AfCFTA is used as an illustrative regulatory context; however, the design is intentionally generic and applicable to other FTAs that depend on mutual recognition of standards, certifications, and conformity assessments. The design assumes: Consortium-based governance among regulatory institutions; Institutional trust boundaries enforced through cryptographic identities; Deterministic transaction processing suitable for regulatory use cases; Infrastructure constraints representative of developing-region deployments. Peer-to-peer communication and ledger replication across organizational boundaries. 3.4.2. Participating Organizations and Network Roles Each participating organization in the system represents an NQI institution (e.g., standards bodies, accreditation agencies, conformity assessment bodies, or regulatory authorities). Within the distributed ledger network: Each organization operates at least one peer node; All peers maintain a synchronized ledger state; Endorsement policies enforce multi-institutional agreement on regulatory actions; A logically centralized but physically distributed ordering service ensures transaction finality within the peer-to-peer network. This organizational abstraction directly informs the symmetric three-peer topology used in the experimental setup described in Section 4.2. 3.4.3. AfCFTA-Oriented Business Transactions The system design models regulatory business transactions rather than generic blockchain operations. These transactions reflect the core functions of NQI coordination under FTAs: Standards Proposal and Endorsement: Submission and multi-party validation of new or revised technical standards. Accreditation and Conformity Record Submission: Recording certification outcomes, inspection results, or accreditation decisions that require immutability and auditability. Certificate and Standard Verification: Retrieval of validated regulatory records by customs authorities, auditors, or trade stakeholders. Compliance and Audit Queries: Read-only access to historical regulatory data for monitoring and enforcement purposes. These transactions represent distinct regulatory workflows with different performance and consensus requirements. 3.4.4. Smart Contract Abstraction and Classification Based on the above transactions, the system defines two functional classes of smart contracts, aligned with Hyperledger Fabric’s execution model: Propose Contracts (Write-Intensive): Implement state-changing regulatory actions such as standards proposals or certification submissions. These transactions require endorsement by multiple organizations and inclusion in an ordered block before commitment. Query Contracts (Read-Only): Support certificate verification, compliance checks, and audit queries. These transactions are executed locally on peer nodes and do not invoke consensus mechanisms. This abstraction reflects the operational reality of NQI systems, where regulatory decisions require collective validation, while compliance verification demands low-latency access. 3.4.5. Design–Evaluation Alignment The explicit system design directly motivates the experimental methodology presented in Section 4. By selecting one representative Propose smart contract and one Query smart contract, the evaluation isolates the performance impact of consensus-driven versus local execution paths under constrained infrastructure conditions. Thus, the performance metrics reported later are grounded in realistic regulatory transaction flows, ensuring that evaluation results are interpretable within the context of AfCFTA-oriented NQI operations rather than abstract blockchain benchmarks. 3.5. Blockchain Performance & Scalability Evaluation Layer: Benchmarking and Feedback Mechanism The third layer of the conceptual model establishes a performance and evaluation framework that quantifies peer-to-peer system efficiency, scalability, and reliability. Moreover, this layer is conceived abstractly as a data-driven feedback mechanism that connects blockchain performance metrics with system and policy optimization. It encompasses the processes of workload generation, performance observation, and data interpretation—focusing on key indicators such as throughput, latency, efficiency, and resource utilization. These indicators serve as the quantitative foundation for assessing how the blockchain system performs under different network loads and organizational configurations [41, 43, 59]. The results inform iterative adjustments to blockchain parameters (e.g., block size, endorsement policies, consensus settings) and provide evidence for institutional decisions on acceptable response times and operational efficiency in regulatory environments [15, 41, 43, 59]. Thus, this layer transforms performance assessment into a strategic governance instrument, bridging peer-to-peer network behavior, system-level performance outcomes, and policy formulation. By treating system evaluation as part of the conceptual logic, rather than as a mere implementation detail, the framework integrates measurement and control into the design of the regulatory infrastructure itself. 3.6. Interactions and Feedback Dynamics The model establishes bidirectional linkages among the three layers, ensuring that institutional objectives guide system design while empirical results continuously refine policy and technology. The top-down integration process ensures that AfCFTA and NQI policy goals directly influence blockchain parameters—such as consensus rules, endorsement mechanisms, and data-sharing policies—while the bottom-up feedback loop channels performance insights into adaptive policy reform and technical reconfiguration. This dynamic interaction constitutes a cyber–institutional feedback loop in which peer-to-peer system behavior and governance mechanisms co-evolve. It reflects the principle that digital transformation in regulatory systems should not be static but responsive, enabling iterative improvements in efficiency, transparency, and interoperability. By aligning technical performance with policy outcomes, the model embodies the socio-technical synergy necessary for digital trust and sustainable trade integration [3]. 4. Methodology This study adopted an experimental research design to evaluate the performance and scalability of a Hyperledger Fabric (HLF) 2.5–based permissioned peer-to-peer blockchain framework for regulating and interlinking NQI services under the AfCFTA framework. The methodology integrated system design, workload modeling, benchmarking, and monitoring under reproducible conditions to ensure empirical rigor and transparency, consistent with established blockchain performance research practices [14, 41, 43, 59, 61]. 4.1. Research Design and Objectives A quantitative, experiment-driven research design was employed to evaluate the operational behavior of the proposed AfCFTA–NQI distributed ledger system under representative regulatory transaction workloads. Performance was assessed using four standard indicators: Throughput (transactions per second, TPS), Latency, Efficiency, and Resource utilization (CPU, memory, and network I/O). These metrics jointly assess the peer-to-peer network’s scalability, responsiveness, and execution behavior in supporting institutional operations [41, 43, 61]. The workloads defined below directly instantiate the AfCFTA-oriented business transactions specified in Section 3.4. To reflect real AfCFTA regulatory processes, workloads were defined based on business transaction semantics rather than abstract read/write labels: Regulatory Submission and Endorsement Workload: This workload models AfCFTA–NQI transactions that create or update regulatory state, such as accreditation approvals, conformity assessment results, or standards proposals. These transactions require endorsement from multiple NQI institutions and trigger block creation and ledger updates. Regulatory Verification and Audit Workload: This workload represents AfCFTA trade-facilitation activities such as certificate verification, compliance inspection, and audit queries. These transactions retrieve validated records from the ledger without modifying state and are executed locally at peer nodes. This distinction enables isolation of consensus-bound peer-to-peer transaction flows from local peer execution paths, a key concern in distributed ledger networking research. This dual workload structure mirrors NQI’s operational logic—where new regulatory records demand immutability, and audits require rapid data access [43, 62–64]. The experimental design pursued four main objectives: Evaluate throughput and latency trends under varying transaction rates and concurrency; Measure system efficiency under progressively increasing loads; Analyze relationships between performance metrics and infrastructure resource consumption; and Identify the sources of performance bottlenecks within the system, determining whether they arise from Fabric’s architectural processes (endorsement and ordering) or from underlying resource constraints. 4.2. System Design and Implementation 4.2.1. Network Architecture The test network was implemented as a containerized experimental testbed designed for reproducibility and controlled parameter tuning. The topology comprised one Raft-based ordering service and three peer organization (NQI_Org1, NQI_Org2, and NQI_Org3), each hosting a single peer node forming a permissioned peer-to-peer network with replicated ledger state and deterministic consensus. This configuration provides a minimal but representative regulatory consortium structure, balancing decentralization and manageability [36, 65, 66]. To preserve methodological neutrality, the organizations were labeled generically rather than assigned to specific AfCFTA member states. Each organization symbolized an NQI institution with identical peer roles, endorsement policies, and network configurations. This symmetrical setup isolates Fabric’s architectural effects from country-specific factors such as infrastructural heterogeneity or policy maturity. All network components were containerized using Docker and orchestrated with Docker Compose to ensure modular deployment and service isolation. Transport Layer Security (TLS) secured all peer-to-peer communications among peers and orderers, ensuring authenticated message exchange and secure ledger replication, and the Membership Service Provider (MSP) managed digital identities and certificate hierarchies among consortium members [36, 66, 67]. The ordering service employed a 2-second batch timeout, a maximum message count of 10, and a block size of 512 KB, parameters chosen to balance throughput and latency. A single application channel hosted the deployed smart contracts, providing a shared ledger view and consistent data synchronization , enabling consistent state propagation across peers via ordered block dissemination. 4.2.2. Organizational and Cryptographic Configuration Each organization’s cryptographic identity was established via the Fabric Certificate Authority (CA). The configurations (defined in crypto-config.yaml and configtx.yaml) specified MSP IDs, domain names, administrative certificates, and channel governance policies. The MAJORITY Admins policy regulated administrative decisions, while ImplicitMeta rules governed chaincode access. Fabric v2.5–specific features—private-data collections and enhanced endorsement semantics—were enabled to improve confidentiality and deterministic transaction validation. [62, 68] 4.2.3. Smart Contract and Workload Design Two chaincodes were implemented to operationalize the AfCFTA–NQI transaction model: The Regulatory Submission and Endorsement Contract implements business logic for proposing and recording regulatory artifacts, including standards and conformity outcomes. Each transaction enforces endorsement policies that reflect institutional consensus requirements before ledger commitment. The Regulatory Verification and Audit Contract enables efficient retrieval of validated regulatory data to support trade facilitation, border inspection, and compliance monitoring without consensus overhead. From a networking standpoint, these query transactions avoid inter-peer coordination and ordering traffic, allowing direct state access at individual peers. Both contracts were developed in Go and deployed using the Hyperledger Fabric v2.5 chaincode lifecycle. This design ensures deterministic execution, modular extensibility, and consistent performance measurement across transaction classes [36, 69, 70]. Listing 1 1 illustrates representative functions—ProposeStandard and QueryStandard—which model AfCFTA-aligned regulatory submission and verification workflows within the distributed ledger. Listing 1 Simplified chaincode logic for proposal and query transactions 1 // Listing 1. Simplified Chaincode Logic for Propose and Query Transactions 2 package main 3 import ( 4 \"encoding/json\" 5 \"fmt\" 6 \"github.com/hyperledger/fabric-contract-api-go/contractapi\" 7 ) 8 // Standard defines the structure for a regulatory standard 9 type Standard struct { 10 StandardID string `json:\"standardID\"` 11 Details string `json:\"details\"` 12 ProposingMember string `json:\"proposingMember\"` 13 Votes map[string]bool `json:\"votes\"` 14 Status string `json:\"status\"` 15 } 16 // ProposeStandard allows a member organization to submit a new standard 17 func (s *SmartContract) ProposeStandard(ctx contractapi.TransactionContextInterface, 18 standardID, details, proposingMember string) error { 19 exists, err := s.StandardExists(ctx, standardID) 20 if err != nil { 21 return err 22 } 23 if exists { 24 return fmt.Errorf(\"the standard %s already exists\", standardID) 25 } 26 27 std := Standard{ 28 StandardID: standardID, 29 Details: details, 30 ProposingMember: proposingMember, 31 Votes: make(map[string]bool), 32 Status: \"Proposed\", 33 } 34 stdJSON, _ := json.Marshal(std) 35 return ctx.GetStub().PutState(standardID, stdJSON) 36 } 37 // QueryStandard retrieves the details of a standard from the ledger 38 func (s *SmartContract) QueryStandard(ctx contractapi.TransactionContextInterface, 39 standardID string) (*Standard, error) { 40 stdJSON, err := ctx.GetStub().GetState(standardID) 41 if err != nil { 42 return nil, fmt.Errorf(\"failed to read from world state: %v\", err) 43 } 44 if stdJSON == nil { 45 return nil, fmt.Errorf(\"the standard %s does not exist\", standardID) 46 } 47 var std Standard 48 _ = json.Unmarshal(stdJSON, &std) 49 return &std, nil 50 } 4.3. Benchmarking and Monitoring Environment Performance evaluation utilized Hyperledger Caliper v0.6.0, a standardized benchmarking framework for permissioned blockchains [14, 41, 63]. Fig. 3, illustrates the experimental setup followed. Caliper was configured to execute the Propose and Query workloads under varying transaction rates (100–800 TPS) and concurrency levels (1–12 workers). Each test was run for 60 seconds per round, with results exported in JSON and HTML formats. The total number of experimental runs was determined as follows: 7 worker concurrencies × 5 transaction load levels × 3 repeated batches = 105 total runs. This design enabled the computation of representative averages and minimized the influence of transient system fluctuations, thereby ensuring the reliability and validity of the reported Hyperledger Fabric performance metrics. This experimental design enables observation of peer-to-peer throughput saturation, ordering delays, and execution locality effects under controlled network conditions. A Grafana–Prometheus monitoring stack was integrated to collect real-time system-level metrics. Prometheus captured container-specific CPU, memory, and network I/O data, while Grafana visualized performance trends. The dual instrumentation allowed cross-validation between blockchain metrics (from Caliper) and system resource behavior, ensuring reliability and interpretability [71, 72]. 4.4. Data Collection and Preprocessing Each experimental configuration was executed three times to mitigate stochastic variability. To preserve statistical validity, warm-up and cool-down intervals were excluded from analysis to eliminate transient startup effects. Outlier runs—caused by temporary I/O or scheduling delays—were filtered out. 4.5. Experimental Control The experimental setup was deployed on a high-performance workstation equipped with an Intel Xeon Gold 6230R processor (52 cores, 46 GB RAM, 5.9 TB SSD) running Ubuntu 22.04 LTS under Windows Subsystem for Linux 2 (WSL2). The software environment comprised Docker 28.3.3, Node.js 20.19.5, and npm 10.8.2. This configuration was selected to minimize hardware-related effects and ensure that observed behaviors reflected protocol-level performance. All benchmarking components—Hyperledger Fabric v2.5, Caliper v0.6.0, Prometheus v2.54, and Grafana v11.1—were containerized, version-controlled, and verified for configuration consistency. Before testing, extensive validation confirmed network integrity, including: • Certificate Authority (CA) enrollment and TLS handshake verification; • Successful chaincode deployment and endorsement testing; and • Inspection of peer and orderer container logs to ensure stable operation and error-free startup. 4.6. Analytical Framework The benchmarking data exported by Caliper were processed and visualized using MATLAB to derive descriptive statistics and performance correlations. Analytical plots were constructed to explore relationships between: Throughput and target TPS; Latency and concurrency; Efficiency and load; and Resource utilization and transaction rate. These analyses follow established methodologies in blockchain benchmarking and distributed systems performance modeling [14, 41, 59, 61]. Queueing theory, consensus mechanics, and peer-to-peer execution principles provided the interpretive foundation for assessing throughput–latency trade-offs and identifying saturation points, though detailed results are discussed later in Section 5. 4.7. Ethical, Methodological, and Contextual Considerations While the experimental model abstracted organizational entities (NQI_Org1–NQI_Org3) rather than assigning real countries, this abstraction preserved neutrality and reproducibility. It ensured that performance outcomes reflected system-level properties rather than infrastructural disparities among AfCFTA member states. The use of synthetic workloads and de-identified institutional analogs avoided collection of any sensitive or proprietary data. All configurations adhered to open-source licensing conditions of the Hyperledger ecosystem, ensuring compliance with ethical standards for digital experimentation and software reproducibility [73]. 5. Results and Discussion 5.1. Throughput and Scalability Analysis The experimental benchmarking results reveal clear distinctions in the performance behavior of write-intensive (Propose) and read-intensive (Query) workloads (Fig. 4), reflecting the modular peer-to-peer execution architecture of Hyperledger Fabric 2.5. This dichotomy underscores the influence of Fabric’s consensus-driven transaction pipeline on overall system scalability, particularly when comparing endorsement-heavy write transactions against lightweight read queries [15, 36, 45, 74]. For the Propose workload (Fig. 4(a)), throughput exhibited a progressive increase with concurrency up to approximately four workers, where it peaked at around 400 transactions per second (TPS). Beyond this point, throughput plateaued, with marginal gains observed even as concurrency was increased to twelve workers. This saturation behavior reveals an upper throughput boundary dictated primarily by the Raft-based ordering service, whose batching policy, endorsement latency, and block formation intervals collectively constrain transaction finalization rates [15, 75, 76]. The results are consistent with previous evaluations of Fabric’s ordering service, which identified similar throughput ceilings in consensus-bound workloads, confirming the deterministic limitations imposed by sequential block generation [45, 62]. In contrast, as shown in Fig. 4(b), the Query workload demonstrated nearly linear scalability across all concurrency and throughput levels tested, sustaining up to 800 TPS under maximum load without significant degradation. This behavior aligns with Fabric’s design philosophy for query operations, which bypass the ordering and endorsement processes and are executed locally at peer nodes through efficient state database lookups [45, 75, 76]. The lack of dependency on consensus mechanisms allows these operations to leverage parallel processing and local caching, resulting in near-ideal scaling efficiency even as workload intensity increases [36, 39, 75]. The observed divergence in scalability between the two workloads highlights a fundamental trade-off between immutability and speed in Hyperledger Fabric’s operational model. Write transactions, constrained by endorsement and ordering dependencies, exhibit throughput ceilings once consensus pipelines become saturated (Fig. 4(c)), whereas read transactions benefit from the system’s ability to perform parallel, consensus-free executions (Fig. 4(d)). This behavior confirms the architectural efficiency of Fabric for read-dominant use cases, such as regulatory audits, compliance monitoring, and data transparency dashboards, where rapid data retrieval is prioritized over transaction immutability. From a scalability perspective, these findings suggest that optimizing performance for write-heavy applications requires consensus-layer tuning and architectural adjustments rather than hardware augmentation. Strategies such as multi-orderer clusters, channel partitioning, or dynamic block parameter adjustment can mitigate queuing delays and improve throughput consistency [62, 77]. Conversely, for data-centric applications dominated by queries, the system’s performance scales effectively with concurrency, confirming its suitability for analytics-oriented workloads within NQI systems under AfCFTA. Overall, the throughput trends observed reaffirm Fabric’s design trade-offs: while the platform guarantees transactional integrity and traceability for write operations, it does so at the expense of scalability under high load (Fig. 4(a)). Meanwhile, read operations demonstrate Fabric’s capability for horizontal scaling and low-latency data retrieval (Fig. 4(d)), making it particularly well-suited for hybrid institutional ecosystems that demand both accountability and performance. 5.2. Transaction Efficiency and Latency Behavior Efficiency and latency analyses provide deeper insights into the stability and responsiveness of Hyperledger Fabric under varying transaction loads. Together, these metrics expose how consensus and endorsement processes affect overall system responsiveness and resource utilization, revealing Fabric’s intrinsic operational bottlenecks and performance asymmetries [40, 47, 76]. To complement throughput analysis, efficiency captures transaction success under load, while latency characterizes temporal responsiveness once saturation is approached. For the Propose workload (Fig. 5(a)), efficiency decreased progressively as the target transaction rate increased—from approximately 97% at 100 TPS to about 50% at 800 TPS. This decline reflects the growing mismatch between transaction arrival rates and the service rate of the ordering layer, leading to queuing and eventual transaction rejection or timeout. Similarly, efficiency declined beyond four to six concurrent workers (Fig. 5(c)), stabilizing near 65%, for the case of 600 TPS, a behavior consistent with predictions from queuing theory for bounded service systems operating near saturation [14, 76]. The drop in efficiency at higher concurrencies indicates that, beyond a certain point, additional workload parallelism fails to produce proportional performance gains, as the ordering service becomes the dominant limiting factor. In contrast, the Query workload (Fig. 5(b)) maintained near-perfect efficiency (~100%) across all concurrency and transaction rates, except for the worker concurrencies of one and two. This stability confirms that Fabric’s read operations—executed without the overhead of consensus—are not subject to queuing or block batching constraints. Consequently, read-heavy applications can achieve deterministic reliability even under extreme transactional stress, highlighting Fabric’s potential for high-frequency analytics and continuous data validation environments [15, 16, 75]. Latency analysis further accentuates these distinctions. For Propose transactions (Fig. 6(a)), average latency remained low (≤0.1 s) at modest loads (≤200 TPS) but escalated sharply beyond 400 TPS, reaching approximately 27.5 seconds at 800 TPS. The corresponding maximum latency increased from 3.9 seconds at 400 TPS to nearly 48 seconds at 800 TPS (Fig. 6(c)), illustrating rapidly increasing queuing delays in the ordering and endorsement stages once throughput saturation was reached. Such behavior typifies consensus-bound blockchain systems, where deterministic transaction ordering introduces serialization overhead that limits real-time responsiveness [40, 42, 76]. Conversely, for Query transactions (Fig. 6(b) and Fig. 6(d)) both average and maximum latency remained remarkably stable—ranging between 0.008 and 0.015 seconds across all concurrency levels and target TPS rates. This low and consistent latency validates Fabric’s architecture for read operations, where transactions are processed directly at peer nodes without requiring endorsement or block inclusion. These results confirm that Fabric’s query performance scales predictably and remains unaffected by network congestion or block size parameters, provided the underlying database (CouchDB) is efficiently indexed and cached [45, 47] The latency divergence between write and read workloads emphasizes the cost of consensus in permissioned blockchains. While ordering ensures non-repudiation and regulatory trustworthiness, it introduces significant propagation delay under high concurrency, making it unsuitable for latency-sensitive, write-heavy environments. On the other hand, the predictably low query latency supports real-time applications such as regulatory dashboards, compliance verification systems, and audit portals, where sub-second response times are essential for usability and transparency. Collectively, the efficiency and latency results (Fig. 5–6) align with prior studies demonstrating that Fabric’s performance bottlenecks originate primarily from the ordering and endorsement layers, rather than computational or networking constraints [40, 45, 78]. Even under peak concurrency, CPU and network utilization remained below critical thresholds, confirming that throughput and latency degradation stem from software-level serialization effects rather than hardware limitations. Thus, the results provide empirical validation of Fabric’s scalability boundaries and reinforce the need for architectural enhancements—such as parallel consensus mechanisms and multi-channel isolation—to improve write scalability in institutional blockchain deployments. 5.3. System Resource Utilization and Monitoring Resource utilization analysis provides a holistic understanding of how Hyperledger Fabric manages computational and communication resources under varying workloads. The results demonstrate that system performance limitations observed in throughput and latency stem primarily from consensus-layer constraints rather than hardware exhaustion, reaffirming the architectural efficiency of Fabric’s modular design [40, 76, 79]. CPU utilization exhibited a near-linear scaling pattern with respect to both workload concurrency and transaction rate (Fig. 7(a) and Fig. 7(b)). Utilization increased from approximately 6% with a single worker to between 30% and 55% with twelve workers at the highest workload intensity (800 TPS). This predictable growth suggests that the Fabric execution model effectively distributes computational load across available cores. The narrow variance in CPU usage confirms that endorsement, validation, and block verification processes are efficiently parallelized across threads, minimizing idle cycles and synchronization overhead [39, 75]. Query workloads, by contrast, imposed considerably lighter computational demands, maintaining consistently low CPU usage across all concurrency levels (Fig. 7). This behavior reflects the architectural simplicity of read operations, which bypass consensus and endorsement pipelines, thereby reducing cryptographic and state validation overhead [45, 62]. Such efficiency highlights Fabric’s suitability for high-frequency query-based applications, where low computational latency is essential for near–real-time analytics and dashboard services. Memory utilization remained modest and stable throughout all experimental conditions (Fig. 8(a) and 8(b)). Consumption increased gradually from approximately 8% with one worker to about 12% at twelve workers, demonstrating that Fabric’s in-memory caching and ledger state management remain bounded and predictable even under increased transactional load. The low dispersion of memory metrics and the absence of outliers suggest that Fabric’s memory footprint is determined primarily by ledger caching and database indexing rather than by concurrency or network complexity. These findings align with prior studies confirming that Fabric’s memory management is optimized for containerized and cloud-native environments, where modular resource allocation is critical for scalability [62, 74, 80]. Outgoing traffic increased proportionally with workload intensity, reaching several Gbps under peak load Network utilization metrics obtained through Grafana monitoring revealed stable and deterministic communication patterns across workloads. Outgoing traffic (Tx) increased proportionally with workload intensity, reaching several Gbps under peak load, indicating consistent broadcast behavior from peers and orderers during block propagation. Conversely, incoming traffic (Rx) remained nearly constant at approximately 192 Mbps across all configurations, reflecting the fixed size of inbound messages per peer within Fabric’s communication protocol [81]. This pattern confirms the network’s role as a predictable and non-saturating component of the overall system, ensuring that communication latency does not significantly affect performance outcomes. The combined observations from Caliper results and Grafana dashboards as shown in the Grafana dashboard snapshots exhibited tightly clustered CPU, memory, and network usage distributions, with minimal variance across runs. This uniformity reinforces the conclusion that hardware and network subsystems operated far below saturation levels, and that the observed throughput plateau at approximately 400 TPS for write transactions was not a consequence of infrastructural limitations. Rather, it originated from software-level synchronization delays within the consensus mechanism. The empirical evidence, supported by prior benchmarking research [39, 45, 63, 74, 75], demonstrates that the system remained within safe operational thresholds throughout the experiments, with adequate capacity for scaling under optimized consensus configurations. Collectively, these findings confirm that Hyperledger Fabric’s resource efficiency is well aligned with the demands of institutional blockchain deployments. The platform’s stable CPU and memory profiles, combined with predictable network behavior, make it highly compatible with distributed, container-based environments where elasticity, resource predictability, and system observability are critical operational requirements. 5.4. Integrated Insights and Performance Bottlenecks An integrated assessment of peer-to-peer throughput, latency, efficiency, and resource utilization demonstrates the dual scalability characteristics inherent in Hyperledger Fabric’s architecture (Table 4). Read operations ( Query ) scaled linearly with near-constant latency and efficiency across all workloads, confirming high stability in non-consensus transactions. Write operations ( Propose ), however, exhibited an early growth phase followed by a clear saturation point near 400 TPS, beyond which throughput plateaued and latency rose sharply. This divergence is a structural consequence of Fabric’s modular execution and ordering model [45, 80]. System-level monitoring corroborated that these constraints stem from Fabric’s internal protocols rather than hardware limitations. CPU usage never exceeded 60%, memory consumption remained below 12%, and network throughput scaled linearly—evidence that the infrastructure had ample computational capacity. The bottleneck originated in the Raft ordering service, whose sequential batching introduced queueing delays when write requests exceeded its processing rate. Similar consensus-layer congestion has been documented in previous analyses of Fabric [82, 83]. These results confirm that Fabric’s throughput ceiling and latency escalation are intrinsic to its endorsement and ordering workflow rather than resource constraints. Overcoming these limits therefore requires architectural refinements—not hardware expansion. Promising strategies include deploying multi-orderer clusters to parallelize consensus, running parallel Raft instances to distribute block formation tasks, and applying channel partitioning to isolate high-traffic transaction domains. Prior work shows that these interventions enhance throughput and responsiveness by reducing serialization overhead [42, 75]. The integrated Caliper–Grafana instrumentation validated that Fabric’s performance boundaries are software-architectural in nature. Despite its throughput limits, the system exhibited consistent resource scaling, deterministic transaction ordering, and reproducible performance—properties essential for institutional blockchain applications demanding transparency, traceability, and auditability. These findings demonstrate Fabric’s suitability for regulatory infrastructures such as AfCFTA’s NQI network, provided that scalability is addressed through consensus parallelization and dynamic block-parameter tuning. Table 4 Summary of Integrated Insights and Performance Bottlenecks Dimension Metric / Aspect Observed Behavior Underlying Cause Optimization / Design Implication Supporting Literature Throughput & Scalability Transaction Throughput Write (Propose) saturates at ~400 TPS; Read (Query) scales linearly up to 800 TPS Raft ordering and endorsement pipeline create serialization bottleneck Introduce multi-orderer clusters, channel partitioning, or dynamic block-size tuning to parallelize consensus [15, 36, 45, 76, 77] Latency Behavior Average Latency Write latency low (<0.1 s) under 200 TPS but rises sharply to >27 s at 800 TPS; Read latency stable at 0.008–0.015 s Queuing and block formation delays in Raft ordering layer; Read bypasses consensus Optimize batch timeout and block size; deploy adaptive consensus tuning for high-load conditions [42, 76, 84–86] Transaction Efficiency Success Ratio Write efficiency drops from 97% (100 TPS) to ~50% (800 TPS); Read efficiency stable at ~100% Saturation of consensus queue; endorsement contention under high concurrency Workload segregation—handle write and read workloads on separate channels [40, 49, 76, 87] Resource Utilization CPU & Memory CPU < 60%; Memory < 12%, even under peak loads Hardware not saturated; bottleneck purely architectural Focus on software-level optimization rather than hardware scaling [39, 39, 75, 79, 80] Network Utilization Tx/Rx Traffic Outgoing traffic scales linearly (~6 Gbps); inbound steady (~192 Mbps) Stable peer communication; non-congested network Confirms network non-limiting for throughput; supports containerized, distributed deployments [74, 81, 88] Integrated Insight Overall System Behavior Dual scalability: bounded write vs. linear read performance; stable resource footprint Consensus serialization, not hardware limits Hyperledger Fabric suitable for regulatory systems; requires architectural tuning for large-scale deployments [45, 63, 76, 89] 5.5. Design, Scalability, and Strategic Implications The experimental results provide theoretical and practical insights into Fabric 2.5’s scalability, highlighting its ability to balance data immutability with operational performance. Performance was found to be predominantly influenced by consensus latency once incoming transactions surpassed the ordering service’s capacity. The observed saturation near 400 TPS for write-intensive workloads aligns with theoretical queuing-model predictions and prior empirical benchmarks of permissioned blockchains [14, 45, 76, 87]. Conversely, read-intensive transactions maintained consistently low latency and near-perfect efficiency, validating the platform’s decoupled transaction model in which read and write paths operate independently [39, 47]. 5.5.1. Experimental Abstraction and Generalizability The network modeled three generic organizations—NQI_Org1, NQI_Org2, and NQI_Org3—representing distinct NQI authorities rather than specific countries. This abstraction enhanced analytical rigor by eliminating contextual disparities while preserving the inter-organizational dynamics of AfCFTA’s regulatory ecosystem. Although AfCFTA provides the contextual backdrop for the evaluation, the underlying framework is equally applicable to other regional free trade agreements that depend on coordinated NQI functions. The architecture is also scalable by design: additional peers or orderers can be incorporated linearly to simulate continent-wide participation, ensuring that the derived insights generalize to larger AfCFTA deployments. 5.5.2. Theoretical and Analytical Perspectives From a theoretical standpoint, the results reinforce the principle of modularity in blockchain systems: performance ceilings arise not from computational or network limits but from the serialization inherent in consensus and block formation. The strong correlation between the observed throughput plateau and modeled queuing thresholds provides empirical confirmation of Fabric’s bounded throughput property [45, 76]. This dual behavior—bounded write scalability versus linear read scalability—substantiates that Fabric’s pipeline consists of semi-independent execution paths, enabling deterministic and predictable system behavior under diverse loads. 5.5.3. Practical Implications for Institutional Deployment For institutions implementing permissioned blockchains in regulatory or quality-infrastructure domains, three principal implications emerge: Workload Segregation as a Design Principle. Separating Propose (write) transactions—requiring endorsement and ordering—from Query (read) operations—executed at peer level—minimizes contention between transaction finality and data accessibility. This division mirrors operational roles within NQI systems and aligns with prior recommendations for task-specific blockchain partitioning to improve responsiveness [39, 49, 77]. Parameter Tuning over Hardware Scaling. Because system resources remained below saturation, meaningful throughput improvements can be achieved through tuning rather than hardware upgrades. Adjusting parameters such as batch timeout, block size, and endorsement policies can optimize throughput–latency trade-offs, a strategy supported by empirical studies showing up to 40% performance gains in Fabric-based deployments [40, 75, 77, 89]. Cloud-Native Suitability and Resource Efficiency. Fabric’s modest resource footprint—memory usage below 12% and low CPU intensity—demonstrates its compatibility with containerized and cloud-native infrastructures. Its modular architecture supports elastic scaling, allowing institutions to expand or contract resources dynamically in line with transaction volumes, a crucial feature for distributed regulatory systems operating across multiple jurisdictions [79, 90]. 5.5.4. Strategic Scalability Roadmap The experimental findings outline a roadmap for achieving balanced hybrid scalability in Fabric-based ecosystems. Read-oriented applications—such as certification registries, auditing dashboards, and compliance portals—can scale horizontally with minimal modification, leveraging peer-level state caching and query parallelism. This read-scalability supports not only AfCFTA-aligned operations but can also extend to other regional free trade agreements that depend on coordinated NQI processes, enabling broader institutional stakeholders—such as the AU, WTO, WCO, research institutions, and sectoral regulatory bodies—to access or analyze non-sensitive quality-infrastructure data without imposing additional load on the core network. Write-intensive processes, including accreditation or regulatory submissions, require architectural reconfiguration to mitigate ordering bottlenecks. Multi-orderer clusters and multi-channel partitioning can parallelize consensus operations and isolate high-frequency domains, while dynamic Raft-parameter tuning (e.g., block size and timeout) enables adaptive optimization under variable loads [62, 76, 77]. Collectively, these strategies allow institutions to harmonize throughput, latency, and reliability without compromising Fabric’s guarantees of data integrity and auditability. By integrating architectural tuning with modular deployment, Hyperledger Fabric can evolve from an enterprise blockchain platform into a foundational digital infrastructure supporting governance, standardization, and regulatory cooperation within the AfCFTA and its broader ecosystem partners[89]. 5.5.5. Institutional and Policy Significance Beyond technical implications, the findings offer strategic value for AfCFTA’s digital transformation agenda. The demonstrated performance characteristics establish a replicable foundation for deploying cross-border quality-infrastructure systems that demand both transparency and scalability. Fabric’s predictable performance and strong governance control make it a viable substrate for digital conformity assessment, standards harmonization, and accreditation tracking across member states. Moreover, the architectural insights contribute to the broader discourse on blockchain-enabled regulatory interoperability, showing how digital infrastructures can operationalize institutional trust without central intermediaries. As such, the study bridges the gap between performance benchmarking and policy design, offering empirical guidance for scaling decentralized regulatory frameworks in emerging continental trade systems. 6. Conclusions This study presented the design and empirical evaluation of a peer-to-peer, permissioned distributed ledger architecture based on Hyperledger Fabric to support National Quality Infrastructure (NQI) coordination in cross-border trade under regional Free Trade Agreements (FTAs). Using the African Continental Free Trade Area (AfCFTA) as an illustrative regulatory context, the paper demonstrated how AfCFTA-aligned regulatory workflows—such as standards submission and endorsement, accreditation recording, and certificate verification—can be explicitly modeled as peer-to-peer, consensus-governed business transactions and operationalized through smart contracts. The proposed system design defined a consortium-based network in which NQI institutions interact through well-specified write-intensive and read-only smart contract classes, reflecting the institutional logic of regulatory decision-making and compliance verification. This design rationale directly informed the experimental methodology. A controlled testbed comprising three peer organizations and a single Raft-based ordering service was implemented to emulate a minimal but representative regulatory consortium. Performance evaluation was conducted using Hyperledger Caliper and system-level monitoring via Grafana–Prometheus under varying transaction loads and concurrency levels. This design–evaluation alignment enabled a direct examination of how peer-to-peer execution paths, endorsement dependencies, and ordering constraints shape system-level performance under institutional workloads. The evaluation revealed distinct performance characteristics aligned with the system design. Write-intensive regulatory submission transactions saturated at approximately 400 TPS, reflecting bounded throughput in consensus-serialized peer-to-peer workflows inherent to Fabric’s execution–ordering–validation model. In contrast, read-only verification and audit transactions exhibited near-linear scalability with sub-15 ms latency, benefiting from Fabric’s consensus-free query execution at peer nodes. Resource utilization remained modest across all experiments, indicating that observed performance limits were intrinsic to the peer-to-peer ordering and endorsement architecture rather than hardware constraints. Together, these results validate the proposed design choices and confirm Hyperledger Fabric’s suitability for compliance-driven, multi-institutional regulatory systems that require deterministic trust, traceability, and auditability. Although AfCFTA served as the illustrative use case, the architectural principles and transaction abstractions developed in this study are transferable to other FTAs that rely on interoperable NQI coordination. The framework therefore provides a foundational reference model for digitally enabled regulatory cooperation across diverse cross-border trade environments. As such, the proposed architecture and findings contribute not only to blockchain-enabled trade facilitation but also to the broader study of scalable peer-to-peer systems for regulated multi-organizational environments. 6.1.1. Limitations and Future Research Directions Despite its contributions, this study has several limitations that frame opportunities for future research. First, the three-organization network topology was selected to ensure experimental clarity and reproducibility; however, it does not fully reflect the institutional diversity and infrastructural heterogeneity of large-scale regional trade ecosystems. While the observed performance trends are expected to scale qualitatively, peer-to-peer coordination overheads and consensus dynamics may evolve nonlinearly as network size and heterogeneity increase. Second, the experimental environment did not model adverse network conditions, dynamic membership changes, or fault scenarios that may affect consensus behavior in real-world regulatory settings. From a design perspective, the implemented smart contracts captured core NQI transaction patterns but did not encode the full procedural complexity of regulatory workflows, such as hierarchical approvals, document lifecycle management, or sector-specific compliance rules. In addition, several architectural optimization strategies—such as multi-orderer clustering, multi-channel partitioning, and adaptive consensus tuning—were identified but not empirically evaluated within the scope of this study. Evaluating how richer regulatory semantics interact with endorsement policies and ordering latency therefore remains an open systems-level research challenge. Future research should expand both the system design and evaluation dimensions. Larger and more heterogeneous network topologies should be tested to assess scalability under realistic cross-border conditions, including multi-orderer and multi-channel configurations. Comparative evaluations with other permissioned distributed ledger platforms could further clarify architectural trade-offs among peer-to-peer consensus models. Finally, domain-enriched smart contracts that formalize NQI-specific semantics—such as mutual recognition rules, certificate validity constraints, and audit traceability—would advance the development of resilient, policy-aligned digital infrastructures for AfCFTA and similar regional trade frameworks. Collectively, these extensions would advance the design of peer-to-peer regulatory infrastructures that combine deterministic governance, scalable performance, and institutional trust across regional and global trade systems. Declarations Author Contributions • Ayele Legesse: Study conception and design, Data collection, Analysis and interpretation of results, Draft manuscript preparation. • Birhanu Beshah: Study conception, analysis and interpretation of results, verification of results, final editing and approval of the manuscript and work supervision. • Ermias Tefaye: Study conception, analysis and interpretation of results, verification of results, and work supervision. • Yalew Kidane: Study conception, analysis and interpretation of results, verification of results. Funding No funding was received for conducting this research Data Availability The data that support the findings of this study are available from the corresponding author upon reasonable request. Research Involving Human Participants and/or Animals Not applicable Ethics approval Not applicable. Consent to publish Not applicable. Competing Interests The authors declare no competing interests. References Alotaibi EM, Issa H, Codesso M (2025) Blockchain-based conceptual model for enhanced transparency in government records: a design science research approach. International Journal of Information Management Data Insights 5:100304. https://doi.org/10.1016/j.jjimei.2024.100304 Saari A, Sinclair S, Leshinsky R, Junnila S (2025) Best practices for blockchain-driven digital transformation in cross-industry settings. Digital Business 5:100127. https://doi.org/10.1016/j.digbus.2025.100127 Brusset X, Kinra A, Naseraldin H, Alkhudary R (2024) Increasing willingness to pay in the food supply chain: a blockchain-oriented trust approach. International Journal of Production Research 62:8858–8879. https://doi.org/10.1080/00207543.2024.2352763 Huubse M (2010) Blockchain Strategies to Enhance Transparency, Efficiency, and Governance for Public-Private Partnership Leaders AU (2025) The African Continental Free Trade Area. African Union EAC (2025). East African Community tralac (2025) Continental Free Trade Area Mlambo VH, Thusi X, Zubane SP, Mlambo DN (2022) The African Continental Free Trade Area: Challenges and Possible Successes Racine, Jean-Louis, Tippmann, Christina (2013) The national quality infrastructure : tool for competitiveness, trade, and social well-being (English). World Bank Group, Washington, DC UNCTAD Support to the African Continental Free Trade Area. United Nations Trade and Development Allena M (2021) Blockchain Technology and Regulatory Compliance: Towards a Cooperative Supervisory Model Zafar A (2025) Reconciling blockchain technology and data protection laws: regulatory challenges, technical solutions, and practical pathways. Journal of Cybersecurity 11:tyaf002. https://doi.org/10.1093/cybsec/tyaf002 Li K, Lee J-Y, Gharehgozli A (2023) Blockchain in food supply chains: a literature review and synthesis analysis of platforms, benefits and challenges. International Journal of Production Research 61:3527–3546. https://doi.org/10.1080/00207543.2021.1970849 Patil PB, Sangeetha M (2024) A Comprehensive Performance Analysis of a Hyperledger Fabric-powered Blockchain Network for Cross-Border Fund Transfers. Procedia Computer Science 233:723–732. https://doi.org/10.1016/j.procs.2024.03.261 Thakkar P, Nathan S, Viswanathan B (2018) Performance Benchmarking and Optimizing Hyperledger Fabric Blockchain Platform. In: 2018 IEEE 26th International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems (MASCOTS). IEEE, Milwaukee, WI, pp 264–276 Dreyer J, Fischer M, Tönjes R (2020) Performance analysis of hyperledger fabric 2.0 blockchain platform. In: Proceedings of the Workshop on Cloud Continuum Services for Smart IoT Systems. ACM, Virtual Event Japan, pp 32–38 Naseem S, Yong T (2025) Blockchain-Based Risk Management in Cross-Border Data Supply Chains: A Comparative Analysis of Alibaba and Infosys. Sustainability 17:7704. https://doi.org/10.3390/su17177704 Xiao S, Qin X, Tian Y, Dang Z (2025) Blockchain-Based Framework for Secure Sharing of Cross-Border Trade Data. CMC 83:2351–2373. https://doi.org/10.32604/cmc.2025.062324 Legesse A, Beshah B, Berhan E, Tesfaye E (2024) Exploring the influencing factors of blockchain technology adoption in national quality infrastructure: a Dual-Stage structural equation model and artificial neural network approach using TAM-TOE framework. Cogent Engineering 11:2369220. https://doi.org/10.1080/23311916.2024.2369220 Adeyinka Ogunbajo, Adefemi Quddus Abidola, Itunu Taiwo, et al (2025) How blockchain-enabled smart contracts and artificial intelligence are reshaping corporate governance frameworks in fintech and logistics industries. World J Adv Res Rev 25:050–059. https://doi.org/10.30574/wjarr.2025.25.2.0333 Amen S (2024) Assessment of Consensus Algorithms for Blockchain Technology to Enhance Decentralized Applications. J Basrah Res (Sci) 50:267–280. https://doi.org/10.56714/bjrs.50.2.23 Singh HP, Alshammari TS (2020) An Institutional Theory Perspective on Developing a Cyber Security Legal Framework: A Case of Saudi Arabia. BLR 11:637–650. https://doi.org/10.4236/blr.2020.113039 Al Salih A, Wang Y (2024) Pluggable Consensus in Hyperledger Fabric. In: Proceedings of the 2024 6th Blockchain and Internet of Things Conference. ACM, Fukuoka Japan, pp 92–100 Casino F, Dasaklis TK, Patsakis C (2019) A systematic literature review of blockchain-based applications: Current status, classification and open issues. Telematics and Informatics 36:55–81. https://doi.org/10.1016/j.tele.2018.11.006 Gu Y, Chen D, Long Y (2026) BesCo: Blockchain-enabled secure collaboration framework for multi-inspection agency integration. Peer-to-Peer Netw Appl 19:14. https://doi.org/10.1007/s12083-025-02160-z Machado EG, Gomes RTR, Martins EVA, et al (2023) Blockchain network to conformity assessment bodies Moni M, Melo W, Peters D, Machado R (2021) When Measurements Meet Blockchain: On Behalf of an Inter-NMI Network. Sensors 21:1564. https://doi.org/10.3390/s21051564 Rani P, Sharma P, Gupta I, Gaba P (2025) STP: a permissioned blockchain solution for dynamic pricing and traceability in food supply chain. Peer-to-Peer Netw Appl 18:224. https://doi.org/10.1007/s12083-025-02060-2 UNIDO Advancing Conformity Assessment for the New Digital Age. United Nations Industrial Development Organization De Souza Melo Junior W (2021) Blockchains and legal metrology: applications and possibilities. https://doi.org/10.13140/RG.2.2.16861.95208 Melo WS, Bessani A, Neves N, et al (2019) Using Blockchains to Implement Distributed Measuring Systems. IEEE Trans Instrum Meas 68:1503–1514. https://doi.org/10.1109/TIM.2019.2898013 Kumar N, Kumar K, Aeron A, Verre F (2025) Blockchain technology in supply chain management: Innovations, applications, and challenges. Telematics and Informatics Reports 18:100204. https://doi.org/10.1016/j.teler.2025.100204 Liu G, Zhao Y, Zhou S, Shao X (2025) Blockchain development in a supply chain with rival entry. International Journal of Production Research 63:5122–5141. https://doi.org/10.1080/00207543.2024.2374835 Benchis MP, Shahzad K, Dan S (2025) Comparative analysis of blockchain adoption in the public and private sectors. A technology-organization-environment (TOE) framework approach. Journal of Innovation & Knowledge 10:100746. https://doi.org/10.1016/j.jik.2025.100746 Uyar H, Papanikolaou A, Kapassa E, et al (2025) Blockchain-enabled traceability and certification for frozen food supply chains: A conceptual design. Smart Agricultural Technology 12:101085. https://doi.org/10.1016/j.atech.2025.101085 Androulaki E, Barger A, Bortnikov V, et al (2018) Hyperledger fabric: a distributed operating system for permissioned blockchains. In: Proceedings of the Thirteenth EuroSys Conference. ACM, Porto Portugal, pp 1–15 Jagadeesh Sai, Shivanand Patil, Karthikesh (2025) Permissioned Blockchain Identity and Access Management System using Hyperledger Fabric. https://doi.org/10.13140/RG.2.2.14607.91044 Kaushal RK, Kumar N, Kukreja V, Boonchieng E (2025) Hyperledger fabric based remote patient monitoring solution and performance evaluation. Peer-to-Peer Netw Appl 18:105. https://doi.org/10.1007/s12083-025-01921-0 Zulkarnain MM, Ramli N, Nordin AN (2025) Performance Benchmarking of Hyperledger Fabric on Heterogeneous Hardware for IoT Applications. IIUMEJ 26:156–170. https://doi.org/10.31436/iiumej.v26i3.3610 Sukhwani H, Wang N, Trivedi KS, Rindos A (2018) Performance Modeling of Hyperledger Fabric (Permissioned Blockchain Network). In: 2018 IEEE 17th International Symposium on Network Computing and Applications (NCA). IEEE, Cambridge, MA, pp 1–8 Khan D, Jung LT, Hashmani MA, Cheong MK (2022) Empirical Performance Analysis of Hyperledger LTS for Small and Medium Enterprises. Sensors 22:915. https://doi.org/10.3390/s22030915 Melo C, Gonçalves G, Silva FA, Soares A (2024) Performance Modeling and Evaluation of Hyperledger Fabric: An Analysis Based on Transaction Flow and Endorsement Policies. In: 2024 IEEE Symposium on Computers and Communications (ISCC). pp 1–6 Lau CW, Liu J, Ma X, Talluri S (2025) Performance analysis of a blockchain-based messaging system implementation for air cargo supply chains. International Journal of Production Research 63:5428–5451. https://doi.org/10.1080/00207543.2024.2407903 Khan AA, Alsufyani A, Alsufyani N, Mohamed MA (2025) BAML: a decentralized approach to secure, privacy-preserving financial compliance for enhancing anti-money laundering with blockchain hyperledger and federated learning. Peer-to-Peer Netw Appl 18:270. https://doi.org/10.1007/s12083-025-02086-6 Guggenberger T, Sedlmeir J, Fridgen G, Luckow A (2022) An in-depth investigation of the performance characteristics of Hyperledger Fabric. Computers & Industrial Engineering 173:108716. https://doi.org/10.1016/j.cie.2022.108716 Agrawal TK, Angelis J, Khilji WA, et al (2023) Demonstration of a blockchain-based framework using smart contracts for supply chain collaboration. International Journal of Production Research 61:1497–1516. https://doi.org/10.1080/00207543.2022.2039413 Enare Abang J, Takruri H, Al-Zaidi R, Al-Khalidi M (2024) Latency performance modelling in hyperledger fabric blockchain: Challenges and directions with an IoT perspective. Internet of Things 26:101217. https://doi.org/10.1016/j.iot.2024.101217 Kellaf T (2024) Blockchain in trade finance: The Good, the Bad and the Verdict. MF 2:136–160. https://doi.org/10.61351/mf.v2i2.206 Thakur A, Ranga V, Agarwal R (2024) Workload dynamics implications in permissioned blockchain scalability and performance. Cluster Comput 27:11569–11593. https://doi.org/10.1007/s10586-024-04550-z Palit SK, Chakraborty M, Chakraborty S (2025) Design, formal verification, and security analysis of SCMChain: A lightweight blockchain-based authentication protocol for IoT-enabled supply chain management. Peer-to-Peer Netw Appl 18:298. https://doi.org/10.1007/s12083-025-02141-2 Jurgelaitis M, Čeponienė L, Butkus K, et al (2022) MDA-Based Approach for Blockchain Smart Contract Development. Applied Sciences 13:487. https://doi.org/10.3390/app13010487 Duke A What Does the CISG Have to Say About Smart Contracts? A Legal Analysis Tippmann C (2013) The National Quality Infrastructure. World Bank Vereinte Nationen (2023) The basics of quality infrastructure for trade. United Nations, Geneva World Bank, UNIDO (2014) Conformity Assessment Builds Trust by Mixing Benefits and Minimizing Barriers. The Naional Quality Infrastructure Project for Nigeria APRI (2023) The Road to Africa’s Single Market: Progress so far and challenges for the future. Africa Policy Research Institute, Berlin, Germany Budoo B (2023) Towards free, fair and safe trade in Africa: Setting up an African continental technical regulatory framework (ACTReF) – Concept paper Karangizi S (2023) Ad Hoc Expert Group Meeting on: “Accelerating the implementation of the AfCFTA in Southern Africa building on the acquis of the RECs FTA.” United Nations Economic Commission for Africa, Gaborone, Botswana Al-Sumaidaee G, Alkhudary R, Zilic Z, Swidan A (2023) Performance analysis of a private blockchain network built on Hyperledger Fabric for healthcare. Information Processing & Management 60:103160. https://doi.org/10.1016/j.ipm.2022.103160 Fan C, Ghaemi S, Khazaei H, Musilek P (2020) Performance Evaluation of Blockchain Systems: A Systematic Survey. IEEE Access 8:126927–126950. https://doi.org/10.1109/ACCESS.2020.3006078 Nasir Q, Qasse IA, Abu Talib M, Nassif AB (2018) Performance Analysis of Hyperledger Fabric Platforms. Security and Communication Networks 2018:1–14. https://doi.org/10.1155/2018/3976093 Hyperledger Fabric Documentation (2025) Read and write operations Kaushal RK, Kumar N (2024) Exploring Hyperledger Caliper Benchmarking Tool to Measure the Performance of Blockchain Based Solutions. In: 2024 11th International Conference on Reliability, Infocom Technologies and Optimization (Trends and Future Directions) (ICRITO). IEEE, Noida, India, pp 1–6 Olivieri L, Negrini L, Arceri V, et al (2025) Detection of Read-Write Issues in Hyperledger Fabric Smart Contracts. In: Proceedings of the 40th ACM/SIGAPP Symposium on Applied Computing. ACM, Catania International Airport Catania Italy, pp 329–337 Battisti JHF, Batista VE, Koslovski GP, et al (2023) Performance analysis of the Raft consensus algorithm on Hyperledger Fabric and Ethereum on cloud. In: 2023 IEEE International Conference on Cloud Computing Technology and Science (CloudCom). IEEE, Naples, Italy, pp 155–160 Iftekhar A, Cui X, Tao Q, Zheng C (2021) Hyperledger Fabric Access Control System for Internet of Things Layer in Blockchain-Based Applications. Entropy 23:1054. https://doi.org/10.3390/e23081054 Ma C, Kong X, Lan Q, Zhou Z (2019) The privacy protection mechanism of Hyperledger Fabric and its application in supply chain finance. Cybersecur 2:5. https://doi.org/10.1186/s42400-019-0022-2 Keo R, Firdaus M, Rhee K (2024) A Secure Rubber Supply Chain Management System Based on Hyperledger Fabric Blockchain: A Use Case in Cambodia Dharani J, Sundarakantham K, Kunwar Singh, Mercy Shalinie S (2022) A Privacy-Preserving Framework for Endorsement Process in Hyperledger Fabric. Computers & Security. https://doi.org/10.1016/j.cose.2022.102637 Zappoli R (2022) Go Language Support in Hyperledger Fabric Private Chaincode Coding Bootcamps (2023) How to monitor Hyperledger Fabric application Jagtap C (2022) Monitoring Fabric network using Grafana and Prometheus Linux Foundation (2021) Case study: Hyperledger Foundation LF Decentralized Trust (2023) Benchmarking Hyperledger Fabric 2.5 performance Baliga A, Solanki N, Verekar S, et al (2018) Performance Characterization of Hyperledger Fabric. In: 2018 Crypto Valley Conference on Blockchain Technology (CVCBT). IEEE, Zug, pp 65–74 Das SR, Jhanjhi N, Asirvatham D, et al Empirical Performance Analysis of Hyperledger Fabric Blockchain Network for Healthcare Javaid H, Hu C, Brebner G (2019) Optimizing Validation Phase of Hyperledger Fabric. In: 2019 IEEE 27th International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems (MASCOTS). IEEE, Rennes, FR, pp 269–275 Wang C, Chu X (2020) Performance Characterization and Bottleneck Analysis of Hyperledger Fabric. In: 2020 IEEE 40th International Conference on Distributed Computing Systems (ICDCS). pp 1281–1286 Melo C, Gonçalves G, Silva FA, et al (2024) Optimal Resource Utilization in Hyperledger Fabric: A Comprehensive SPN-Based Performance Evaluation Paradigm. In: NOMS 2024-2024 IEEE Network Operations and Management Symposium. IEEE, Seoul, Korea, Republic of, pp 1–7 Gorenflo C, Lee S, Golab L, Keshav S (2019) FastFabric: Scaling Hyperledger Fabric to 20,000 Transactions per Second. In: 2019 IEEE International Conference on Blockchain and Cryptocurrency (ICBC). IEEE, Seoul, Korea (South), pp 455–463 Grafana Labs HLF SmartBFT dashboard Jangid DP, Badhe DNB, Giri DN, et al (2025) COMPARATIVE ANALYSIS OF HYPERLEDGER FABRIC PERFORMANCE ACROSS VARIOUS ORDERING SERVICES. International Journal of Applied Mathematics 38: Melo C, Gonçalves G, Silva FA, Soares A (2024) A comprehensive hyperledger fabric performance evaluation based on resources capacity planning. Cluster Comput 27:12395–12410. https://doi.org/10.1007/s10586-024-04591-4 Gutierrez R, Villegas-Ch W, Govea J (2025) Adaptive consensus optimization in blockchain using reinforcement learning and validation in adversarial environments. Front Artif Intell 8:1672273. https://doi.org/10.3389/frai.2025.1672273 Rizal S, Kim D-S (2025) Enhancing Blockchain Consensus Mechanisms: A Comprehensive Survey on Machine Learning Applications and Optimizations. Blockchain: Research and Applications 100302. https://doi.org/10.1016/j.bcra.2025.100302 Zidi I, Zaghdoud R, El Khediri S (2026) Optimizing block size and cloud storage in blockchain technology using an NSGA-III and SVM hybrid approach. Peer-to-Peer Netw Appl 19:5. https://doi.org/10.1007/s12083-025-02145-y Xu X, Sun G, Luo L, et al (2021) Latency performance modeling and analysis for Hyperledger Fabric blockchain network. Information Processing & Management 58:. https://doi.org/10.1016/j.ipm.2020.102436 Kraus T (2024) Deployment of containerized simulations in an API-driven distributed infrastructure Li M, Wang Y, Ma S, et al (2023) Auto-Tuning with Reinforcement Learning for Permissioned Blockchain Systems. Proc VLDB Endow 16:1000–1012. https://doi.org/10.14778/3579075.3579076 Kaushal R, Kumar N (2024) Exploring Hyperledger Caliper benchmarking tool to measure the performance of blockchain based solutions. In: Proceedings of the 11th International Conference on Reliability, Infocom Technologies and Optimization (ICRITO 2024). IEEE, pp 1–6 Additional Declarations No competing interests reported. Cite Share Download PDF Status: Under Review Version 1 posted Reviewers agreed at journal 28 Apr, 2026 Reviewers invited by journal 02 Mar, 2026 Editor assigned by journal 31 Jan, 2026 Submission checks completed at journal 22 Jan, 2026 First submitted to journal 15 Jan, 2026 You are reading this latest preprint version Research Square lets you share your work early, gain feedback from the community, and start making changes to your manuscript prior to peer review in a journal. As a division of Research Square Company, we’re committed to making research communication faster, fairer, and more useful. We do this by developing innovative software and high quality services for the global research community. Our growing team is made up of researchers and industry professionals working together to solve the most critical problems facing scientific publishing. Also discoverable on Platform About Our Team In Review Editorial Policies Advisory Board Help Center Resources Author Services Accessibility API Access RSS feed Manage Cookie Preferences © Research Square 2026 | ISSN 2693-5015 (online) Privacy Policy Terms of Service Do Not Sell My Personal Information {\"props\":{\"pageProps\":{\"initialData\":{\"identity\":\"rs-8611135\",\"acceptedTermsAndConditions\":true,\"allowDirectSubmit\":false,\"archivedVersions\":[],\"articleType\":\"Research Article\",\"associatedPublications\":[],\"authors\":[{\"id\":599448208,\"identity\":\"202f9c71-1860-4bce-ad42-edec12892ace\",\"order_by\":0,\"name\":\"Ayele Legesse\",\"email\":\"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAZAAAAAyAQMAAABI0h/eAAAABlBMVEX///8AAABVwtN+AAAACXBIWXMAAA7EAAAOxAGVKw4bAAAA5ElEQVRIiWNgGAWjYBACCWYGBsYGMJP5AIxFnBYJBga2BCK1MMC18BgQp0Wyncfw44yKO3X8/Ge+SfzcYSPHwH746AZ8WqSZeYwlN5x5JiE5I3ebZO+ZNGMGnrS0G/i0yDHzGEg+bDssYXCDd5sEb9vhxAYJHjNCWox/grTYnz/zTPIvMVqADjOT3AiyhSGHTZooWySb2cosZ5w5LDnjRpqxtWxbmjEbIb9InD+8+WZPxWF+/v7DD2++bbOR42c/fAyvFgYGDgMYiwUUSQxs+JWDAPsDGIv5A2HVo2AUjIJRMBIBALuASMuuP0GiAAAAAElFTkSuQmCC\",\"orcid\":\"\",\"institution\":\"Addis Ababa University\",\"correspondingAuthor\":true,\"prefix\":\"\",\"firstName\":\"Ayele\",\"middleName\":\"\",\"lastName\":\"Legesse\",\"suffix\":\"\"},{\"id\":599448209,\"identity\":\"919a0314-ef1f-407b-93d8-a749fb8865c9\",\"order_by\":1,\"name\":\"Birhanu Beshah\",\"email\":\"\",\"orcid\":\"\",\"institution\":\"Addis Ababa University\",\"correspondingAuthor\":false,\"prefix\":\"\",\"firstName\":\"Birhanu\",\"middleName\":\"\",\"lastName\":\"Beshah\",\"suffix\":\"\"},{\"id\":599448210,\"identity\":\"8283519a-0d67-4909-8375-8c5dd0652eb3\",\"order_by\":2,\"name\":\"Ermias Tesfaye\",\"email\":\"\",\"orcid\":\"\",\"institution\":\"Addis Ababa University\",\"correspondingAuthor\":false,\"prefix\":\"\",\"firstName\":\"Ermias\",\"middleName\":\"\",\"lastName\":\"Tesfaye\",\"suffix\":\"\"},{\"id\":599448211,\"identity\":\"15186f3d-6935-47cf-b9c4-69a284f40889\",\"order_by\":3,\"name\":\"Yalew Kidane Tolcha\",\"email\":\"\",\"orcid\":\"\",\"institution\":\"Korea Advanced Institute of Science and Technology\",\"correspondingAuthor\":false,\"prefix\":\"\",\"firstName\":\"Yalew\",\"middleName\":\"Kidane\",\"lastName\":\"Tolcha\",\"suffix\":\"\"}],\"badges\":[],\"createdAt\":\"2026-01-15 13:53:53\",\"currentVersionCode\":1,\"declarations\":\"\",\"doi\":\"10.21203/rs.3.rs-8611135/v1\",\"doiUrl\":\"https://doi.org/10.21203/rs.3.rs-8611135/v1\",\"draftVersion\":[],\"editorialEvents\":[],\"editorialNote\":\"\",\"failedWorkflow\":false,\"files\":[{\"id\":103971826,\"identity\":\"16ce78ec-3c14-41a3-99fc-441ddf72b65c\",\"added_by\":\"auto\",\"created_at\":\"2026-03-05 07:47:13\",\"extension\":\"png\",\"order_by\":1,\"title\":\"Figure 1\",\"display\":\"\",\"copyAsset\":false,\"role\":\"figure\",\"size\":120848,\"visible\":true,\"origin\":\"\",\"legend\":\"\\u003cp\\u003eThe timing diagram showing the flow of chaincode endorsement and block distribution across different types of nodes in Hyperledger Fabric [Source: Adapted from[39]]\\u003c/p\\u003e\",\"description\":\"\",\"filename\":\"1.png\",\"url\":\"https://assets-eu.researchsquare.com/files/rs-8611135/v1/ac355f4777b50b4e5617e42e.png\"},{\"id\":103971827,\"identity\":\"2aac1e6b-5854-4bab-b08f-25c04c3b9775\",\"added_by\":\"auto\",\"created_at\":\"2026-03-05 07:47:13\",\"extension\":\"png\",\"order_by\":2,\"title\":\"Figure 2\",\"display\":\"\",\"copyAsset\":false,\"role\":\"figure\",\"size\":88143,\"visible\":true,\"origin\":\"\",\"legend\":\"\\u003cp\\u003eConceptual Framework for a Permissioned Blockchain–Based NQI System under Regional FTAs [Source: Authors’ conceptualization]\\u003c/p\\u003e\",\"description\":\"\",\"filename\":\"2.png\",\"url\":\"https://assets-eu.researchsquare.com/files/rs-8611135/v1/40bb73df34490d38ec0b1a41.png\"},{\"id\":104402183,\"identity\":\"17f74b10-848e-43f7-909f-6340010e9c44\",\"added_by\":\"auto\",\"created_at\":\"2026-03-11 12:14:35\",\"extension\":\"png\",\"order_by\":3,\"title\":\"Figure 3\",\"display\":\"\",\"copyAsset\":false,\"role\":\"figure\",\"size\":167034,\"visible\":true,\"origin\":\"\",\"legend\":\"\\u003cp\\u003eExperimental setup for the benchmarking\\u003c/p\\u003e\",\"description\":\"\",\"filename\":\"3.png\",\"url\":\"https://assets-eu.researchsquare.com/files/rs-8611135/v1/07c55398374645f8450811b5.png\"},{\"id\":103971831,\"identity\":\"e03d4267-3d21-41f9-9b2a-628ecfd32679\",\"added_by\":\"auto\",\"created_at\":\"2026-03-05 07:47:13\",\"extension\":\"png\",\"order_by\":4,\"title\":\"Figure 4\",\"display\":\"\",\"copyAsset\":false,\"role\":\"figure\",\"size\":539061,\"visible\":true,\"origin\":\"\",\"legend\":\"\\u003cp\\u003ePerformance of propose and query workloads: (a,b) throughput vs. Target TPS, (c,d) throughput vs. Worker Concurrency\\u003c/p\\u003e\",\"description\":\"\",\"filename\":\"4.png\",\"url\":\"https://assets-eu.researchsquare.com/files/rs-8611135/v1/f2feb6945feef1873498f58d.png\"},{\"id\":103971832,\"identity\":\"80a7e1c1-5da4-4816-a777-7ba16e0d1416\",\"added_by\":\"auto\",\"created_at\":\"2026-03-05 07:47:13\",\"extension\":\"png\",\"order_by\":5,\"title\":\"Figure 5\",\"display\":\"\",\"copyAsset\":false,\"role\":\"figure\",\"size\":357433,\"visible\":true,\"origin\":\"\",\"legend\":\"\\u003cp\\u003eTransaction efficiency for (a) Propose and (b) Query workloads vs. target TPS, and (c) Propose workload vs. worker concurrency\\u003c/p\\u003e\",\"description\":\"\",\"filename\":\"5.png\",\"url\":\"https://assets-eu.researchsquare.com/files/rs-8611135/v1/8eb1fa0d7b874af67a4c508b.png\"},{\"id\":103971830,\"identity\":\"a6b8c27b-b0f2-49a3-ad76-164c7ea4ef92\",\"added_by\":\"auto\",\"created_at\":\"2026-03-05 07:47:13\",\"extension\":\"png\",\"order_by\":6,\"title\":\"Figure 6\",\"display\":\"\",\"copyAsset\":false,\"role\":\"figure\",\"size\":482176,\"visible\":true,\"origin\":\"\",\"legend\":\"\\u003cp\\u003eTransaction latency vs. target TPS for (a) average and (b) maximum latency in Propose workload, and (c) average and (d) maximum latency in Query workload\\u003c/p\\u003e\",\"description\":\"\",\"filename\":\"6.png\",\"url\":\"https://assets-eu.researchsquare.com/files/rs-8611135/v1/a2c0b33c654021a49700d005.png\"},{\"id\":103971829,\"identity\":\"44830e7c-2b4e-484b-82aa-b0299a75bee4\",\"added_by\":\"auto\",\"created_at\":\"2026-03-05 07:47:13\",\"extension\":\"png\",\"order_by\":7,\"title\":\"Figure 7\",\"display\":\"\",\"copyAsset\":false,\"role\":\"figure\",\"size\":157228,\"visible\":true,\"origin\":\"\",\"legend\":\"\\u003cp\\u003eCPU utilization behavior under varying workloads: (a) CPU usage distribution (box plot) and (b) CPU utilization versus worker concurrency (scatter plot)\\u003c/p\\u003e\",\"description\":\"\",\"filename\":\"7.png\",\"url\":\"https://assets-eu.researchsquare.com/files/rs-8611135/v1/8f41bf039ac9c69be80aab1e.png\"},{\"id\":103971833,\"identity\":\"ac9a4fef-fdd6-44ad-bdc1-129f06e98a35\",\"added_by\":\"auto\",\"created_at\":\"2026-03-05 07:47:14\",\"extension\":\"png\",\"order_by\":8,\"title\":\"Figure 8\",\"display\":\"\",\"copyAsset\":false,\"role\":\"figure\",\"size\":138914,\"visible\":true,\"origin\":\"\",\"legend\":\"\\u003cp\\u003eMemory utilization under varying workloads: (a) Memory consumption distribution (box plot) and (b) Memory utilization versus worker concurrency (scatter plot)\\u003c/p\\u003e\",\"description\":\"\",\"filename\":\"8.png\",\"url\":\"https://assets-eu.researchsquare.com/files/rs-8611135/v1/ed500e5a868d171bc13f7783.png\"},{\"id\":104408338,\"identity\":\"b45074d5-2584-4efc-b2f3-882f52a08ed8\",\"added_by\":\"auto\",\"created_at\":\"2026-03-11 12:42:09\",\"extension\":\"pdf\",\"order_by\":0,\"title\":\"\",\"display\":\"\",\"copyAsset\":false,\"role\":\"manuscript-pdf\",\"size\":3373983,\"visible\":true,\"origin\":\"\",\"legend\":\"\",\"description\":\"\",\"filename\":\"manuscript.pdf\",\"url\":\"https://assets-eu.researchsquare.com/files/rs-8611135/v1/4d75b4d8-c93a-4a37-ae4a-3720a29e3c59.pdf\"}],\"financialInterests\":\"No competing interests reported.\",\"formattedTitle\":\"Performance Evaluation of a Hyperledger Fabric–Based Permissioned Blockchain Network for Cross-Border Regulatory Applications\",\"fulltext\":[{\"header\":\"1. Introduction\",\"content\":\"\\u003cp\\u003eThe accelerating digital transformation of governance and regulatory systems has positioned permissioned blockchain platforms as peer-to-peer distributed systems capable of supporting institutional transparency, accountability, and cross-border interoperability [1, 2].\\u0026nbsp;Its distributed and tamper-resistant architecture enables organizations to exchange trusted information without dependence on centralized intermediaries\\u0026nbsp;[3].\\u0026nbsp;This property is particularly valuable in regulatory ecosystems, where multiple autonomous entities must coordinate to uphold product quality, safety, and compliance across jurisdictions\\u0026nbsp;[1, 4].\\u003c/p\\u003e\\n\\u003cp\\u003eAcross many regional free trade agreements (FTAs), including Africa’s AfCFTA, regulatory harmonization remains a persistent challenge. Disparities in institutional capacity, fragmented conformity-assessment systems, and inconsistent regulatory infrastructures hinder effective cooperation and mutual recognition of standards [5–7]. Because National Quality Infrastructure (NQI) systems—encompassing metrology, accreditation, standards, and conformity assessment—constitute the backbone of cross-border regulatory assurance, [8–10], \\u0026nbsp;a secure and interoperable digital infrastructure is essential for improving coordination among participating authorities.\\u0026nbsp;From a systems perspective, these coordination challenges translate into requirements for distributed data consistency, secure peer communication, and scalable transaction processing across autonomous institutions.\\u003c/p\\u003e\\n\\u003cp\\u003eDistributed ledger technology offers a promising foundation for such integration by enabling peer-to-peer data replication, decentralized trust establishment, and consensus-driven state synchronization across independent organizations [1, 4].\\u0026nbsp;Yet, the application of blockchain to policy-regulated and compliance-intensive domains raises specific challenges. Public blockchains such as Bitcoin or Ethereum deliver high decentralization but lack the privacy, governance flexibility, and performance predictability demanded by regulatory authorities\\u0026nbsp;[11, 12].\\u0026nbsp;By contrast, permissioned frameworks such as Hyperledger Fabric (HLF) provide authenticated participation, fine-grained access control, and modular consensus protocols\\u0026nbsp;[13, 14].\\u0026nbsp;These features make HLF well-suited for institutional ecosystems that require transparency and accountability without sacrificing confidentiality or performance.\\u003c/p\\u003e\\n\\u003cp\\u003eDespite this alignment, empirical research on how permissioned blockchain networks such as Hyperledger Fabric perform under realistic, multi-organization regulatory workloads remains limited. Existing studies have primarily focused on blockchain’s conceptual benefits—traceability, auditability, and transparency in governance—rather than its operational viability within resource-constrained or heterogeneous institutional environments [1]. In particular, limited attention has been paid to how endorsement policies, ordering services, and peer concurrency jointly affect throughput, latency, and scalability in permissioned peer-to-peer blockchain networks. Benchmarking efforts such as those by\\u0026nbsp;Thakkar et al.\\u0026nbsp;[15]\\u0026nbsp;and Dreyer et al.\\u0026nbsp;[16]\\u0026nbsp;provided useful insights into throughput and latency behavior but were detached from policy or regulatory contexts. Furthermore, few studies have examined the interplay between consensus mechanisms, data-sharing requirements, and institutional governance structures in cross-border cooperation settings\\u0026nbsp;[17, 18].\\u003c/p\\u003e\\n\\u003cp\\u003eThis gap is especially evident in the governance landscape of emerging FTAs—such as the AfCFTA—where harmonized regulatory oversight across multiple national NQI agencies requires digital systems that support both verifiability and jurisdictional autonomy. While blockchain promises distributed assurance, the absence of empirical evaluations linking its architectural features to NQI processes limits informed adoption and policy formulation [19].\\u0026nbsp;These constraints make AfCFTA an analytically useful setting for evaluating the scalability and performance limits of permissioned blockchain networks under cross-border, multi-institutional conditions.\\u003c/p\\u003e\\n\\u003cp\\u003eAddressing these gaps requires examining blockchain not merely as a technical innovation but as a socio-technical infrastructure—a hybrid system in which institutional trust mechanisms are embedded within computational logic. This view is supported by the cyber-institutional perspective, which argues that governance functions—such as verification, compliance, and accountability—can be operationalized through technical primitives like consensus algorithms and smart contracts [1, 20–22].\\u0026nbsp;Within this paradigm, blockchain serves as both a technological enabler and a governance mediator, translating institutional protocols into programmable, auditable workflows. From a networking perspective, this implies that governance logic is increasingly coupled with transaction flow, message ordering, and consensus latency.\\u003c/p\\u003e\\n\\u003cp\\u003eHyperledger Fabric offers distinct advantages for such applications. Its execution-ordering-validation architecture, which explicitly separates peer execution, ordering, and validation stages, supported by the consensus mechanism and Membership Service Provider (MSP) framework, provides a configurable foundation for secure multi-organizational collaboration [23].\\u0026nbsp;This makes Fabric well-suited for automating NQI processes, including standards approval, conformity assessment, and certification data management, in cross-border regulatory ecosystems.\\u003c/p\\u003e\\n\\u003cp\\u003eAccordingly, this study addresses three core research questions:\\u003c/p\\u003e\\n\\u003cp\\u003e\\u003cstrong\\u003eRQ1:\\u003c/strong\\u003e How can a Hyperledger Fabric–based blockchain network and smart contracts be designed to support, automate, and harmonize key NQI regulatory functions within regional FTAs (illustrated using AfCFTA)?\\u003c/p\\u003e\\n\\u003cp\\u003e\\u003cstrong\\u003eRQ2:\\u003c/strong\\u003e How does the proposed Hyperledger Fabric peer-to-peer network perform under varying transaction workloads—evaluated through throughput, latency, efficiency, and resource utilization—using standardized benchmarking tools?\\u003c/p\\u003e\\n\\u003cp\\u003e\\u003cstrong\\u003eRQ3:\\u003c/strong\\u003e What insights do empirical results provide for optimizing scalability, consensus efficiency, and broader adoption of blockchain-enabled regulatory systems in cross-border trade environments?\\u003c/p\\u003e\\n\\u003cp\\u003eBy framing these guiding questions, this study situates itself at the intersection of blockchain engineering and institutional governance. It contributes conceptually by advancing the understanding of how decentralized architectures can underpin trust-centric regulatory systems, and empirically by demonstrating how permissioned blockchain infrastructures can be evaluated for their suitability in complex, multi-jurisdictional environments.\\u003c/p\\u003e\\n\\u003cp\\u003eIn summary, this research examines how a Hyperledger Fabric–based smart contract framework can operationalize trust, transparency, and interoperability for NQI processes under regional FTAs, using AfCFTA as an illustrative context. The study draws insights from information systems, production governance, and digital policy to propose a structured foundation for blockchain-enabled regulatory cooperation.\\u003c/p\\u003e\\n\\u003cp\\u003eThe remainder of this paper is organized as follows. Section 2 delves in to the analysis of relevant literature and the gaps. Section 3 develops the conceptual framework connecting blockchain governance with NQI and AfCFTA objectives. Section 4 describes the system design and research methodology. Section 5 presents and analyzes experimental results on performance, and discusses the institutional implications of the findings, and Section 6 concludes with key insights, limitations and future research directions.\\u003c/p\\u003e\"},{\"header\":\"2.\\tLiterature Review\",\"content\":\"\\u003ch2 id=\\\"_Toc214266814\\\"\\u003e\\u003cstrong\\u003e2.1 Blockchain for Institutional and Regulatory Systems\\u003c/strong\\u003e\\u003c/h2\\u003e\\n\\u003cp\\u003eBlockchain technology has emerged as a transformative peer-to-peer distributed system enabling institutional transparency, regulatory efficiency, and cross-border interoperability. Studies such as\\u0026nbsp;Patil \\u0026amp; Sangeetha [14] highlighted its ability to enhance institutional trust through secure, auditable, and decentralized infrastructures, especially in cross-border fund transfers. Similarly,\\u0026nbsp;Naseem \\u0026amp; Yong\\u0026nbsp;[17]\\u0026nbsp;has shown how blockchain reduces compliance and data risks in global supply chains, enabling proactive regulatory assurance. A broader synthesis in Casino et al.\\u0026nbsp;[24]\\u0026nbsp;identified transparency, security, immutability, and auditability as core drivers of institutional reform.\\u003c/p\\u003e\\n\\u003cp\\u003eWithin NQI environments, blockchain reinforces metrology, conformity assessment, and certification functions by enabling secure verification of digital records and traceability data [25\\u0026ndash;29]. The Sea-Trace-Pricing (STP) framework proposed by Rani et al. [28] enhances dynamic pricing and traceability in the seafood supply chain through blockchain, demonstrating its capacity to address pricing volatility and fraud. Practical deployments, including UNIDO\\u0026rsquo;s pilot in Ghana\\u0026rsquo;s cocoa value chain, demonstrated how blockchain reduces process costs while increasing trust through real-time traceability [29], through real-time traceability enabled by decentralized data replication across participating nodes. In legal metrology, blockchain and smart contracts automate workflows and preserve measurement integrity, strengthening confidence in compliance processes [30, 31].\\u003c/p\\u003e\\n\\u003cp\\u003eSector-specific researches further reinforced blockchain\\u0026rsquo;s regulatory significance.\\u0026nbsp;Kumar et al. [32] demonstrate its capacity to improve transparency and auditability across diverse supply chain governance contexts, while G. Liu et al. [33] has shown that blockchain preserves compliance and traceability even in highly competitive environments.\\u0026nbsp;Benchis et al.\\u0026nbsp;[34]\\u0026nbsp;identified substantial sectoral variation in adoption trajectories, underscoring the need for domain-sensitive deployment strategies. Taken together, this body of work illustrates that blockchain\\u0026rsquo;s institutional value extends beyond technical functionality, residing in its ability to institutionalize transparency, accountability, and interoperability through distributed, peer-to-peer system architectures.\\u003c/p\\u003e\\n\\u003ch2 id=\\\"_Toc214266815\\\"\\u003e\\u003cstrong\\u003e2.2. Hyperledger Fabric as a Permissioned Blockchain Platform\\u003c/strong\\u003e\\u003c/h2\\u003e\\n\\u003cp\\u003eHyperledger Fabric has emerged as a leading permissioned peer-to-peer blockchain platform for enterprise and regulatory applications due to its modularity, scalability, and granular governance features. The conceptual model in Uyar et al. [35] demonstrated Fabric\\u0026rsquo;s adaptability for compliance-oriented traceability systems, integrating IoT sensors and smart contracts to enforce automated regulatory validation. Foundational work of Androulaki et al. [36] \\u0026nbsp;detail Fabric\\u0026rsquo;s architectural innovation\\u0026mdash;its execute\\u0026ndash;order\\u0026ndash;validate logic, configurable consensus mechanisms, and MSP-based identity management\\u0026mdash; which collectively support authenticated multi-organizational collaboration and high performance in peer-to-peer transaction propagation and validation, as illustrated in Fig. 1.\\u003c/p\\u003e\\n\\u003cp\\u003eThese characteristics make Fabric particularly suitable for NQI implementations, where role-based access control, decentralized audit trails, and secure certificate verification are essential [26]. Research in metrology suggests Fabric can support inter-NMI (National Metrology Institutions) blockchain networks that enhance data exchange, regulatory coordination, and mutual recognition arrangements [27]. Extending these capabilities, (Jagadeesh Sai et al. [37] demonstrated Fabric\\u0026rsquo;s utility in permissioned identity and access management. Additionally, Kaushal et al. [38] introduced a Hyperledger Fabric-based remote patient monitoring system, showcasing its effectiveness in secure health data management.\\u0026nbsp;\\u003c/p\\u003e\\n\\u003cp\\u003eTogether, these studies confirm Fabric\\u0026rsquo;s versatility and operational suitability for regulated ecosystems requiring high trust, traceability, and institutional accountability.\\u003c/p\\u003e\\n\\u003cp\\u003e\\u003cstrong\\u003e\\u0026nbsp;2.3\\u0026nbsp;\\u003c/strong\\u003e\\u003cstrong\\u003eBlockchain Benchmarking and Performance Evaluation\\u003c/strong\\u003e\\u003c/p\\u003e\\n\\u003cp\\u003eResearch on blockchain benchmarking has evolved through progressively deeper analytical and empirical contributions aimed at understanding the performance of peer-to-peer distributed ledger networks. Foundational studies such as Thakkar et al. [15] identified system parameters\\u0026mdash;endorsement policies, block size, and batch timeout\\u0026mdash;as primary drivers of throughput and latency, demonstrating that targeted tuning can substantially improve Hyperledger Fabric\\u0026rsquo;s performance. Shortly after, Sukhwani et al. [40] \\u0026nbsp;advanced the analytical dimension by applying stochastic reward nets to predict throughput and queuing behavior, highlighting endorsement and validation delays as critical bottlenecks.\\u003c/p\\u003e\\n\\u003cp\\u003eBuilding on these early insights, Khan et al. [41] conducted empirical benchmarking using Hyperledger Caliper to examine Fabric\\u0026rsquo;s scalability limits within SME-oriented environments, revealing practical trade-offs between network size and latency. Further extending analytical rigor, Melo et al. [42] introduced a stochastic Petri net model that quantifies how endorsement strategies, transaction flow, and ordering services affect system responsiveness, providing a validated framework for predictive performance assessment. More expansive work by Lau et al. [43] benchmarked public blockchain platforms, including Algorand, whose latency and throughput patterns reaffirm the broader importance of systematic performance evaluation across different blockchain architectures. Additionally, Ayub Khan et al. [44] proposed a framework that integrates Hyperledger Fabric with federated learning for Anti-Money Laundering systems, highlighting the need for operational efficiency and performance optimization in blockchain applications. Taken together, these studies establish performance benchmarking\\u0026mdash;combining model-driven analysis with empirical validation\\u0026mdash;as a cornerstone for improving scalability, predictability, and real-world applicability in peer-to-peer blockchain-based systems.\\u003c/p\\u003e\\n\\u003cp\\u003e\\u003cstrong\\u003eTable\\u0026nbsp;\\u003c/strong\\u003e\\u003cstrong\\u003e1\\u003c/strong\\u003e\\u003cstrong\\u003e\\u0026nbsp;\\u003c/strong\\u003eSummary of the literature on blockchain performance investigations\\u003c/p\\u003e\\n\\u003ctable border=\\\"0\\\" width=\\\"638\\\" cellspacing=\\\"0\\\" cellpadding=\\\"0\\\"\\u003e\\n\\u003ctbody\\u003e\\n\\u003ctr\\u003e\\n\\u003ctd style=\\\"width: 96px;\\\" valign=\\\"bottom\\\"\\u003e\\n\\u003cp\\u003eStudy\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 542px;\\\" valign=\\\"bottom\\\"\\u003e\\n\\u003cp\\u003eDetailed content\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003c/tr\\u003e\\n\\u003ctr\\u003e\\n\\u003ctd style=\\\"width: 96px;\\\"\\u003e\\n\\u003cp\\u003e[45]\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 542px;\\\"\\u003e\\n\\u003cp\\u003eThis paper benchmarks Hyperledger Fabric's performance across architecture, setup, workloads, networks, and robustness using an enhanced DLPS framework, revealing scalability limits, throughput peaks, and latency sensitivities for enterprise blockchain applications like supply chains.\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003c/tr\\u003e\\n\\u003ctr\\u003e\\n\\u003ctd style=\\\"width: 96px;\\\"\\u003e\\n\\u003cp\\u003e[46]\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 542px;\\\"\\u003e\\n\\u003cp\\u003eThis paper presents a blockchain-based framework using smart contracts for supply chain collaboration, focusing on performance metrics such as throughput and latency to enhance resource sharing and operational efficiency among supply chain partners.\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003c/tr\\u003e\\n\\u003ctr\\u003e\\n\\u003ctd style=\\\"width: 96px;\\\"\\u003e\\n\\u003cp\\u003e[47]\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 542px;\\\"\\u003e\\n\\u003cp\\u003eThe paper reviews latency-related performance challenges in Hyperledger Fabric, examining factors affecting transaction delays, modeling techniques, and architectural bottlenecks. It highlights the need for accurate latency evaluation to support scalable and reliable IoT-blockchain deployments.\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003c/tr\\u003e\\n\\u003ctr\\u003e\\n\\u003ctd style=\\\"width: 96px;\\\"\\u003e\\n\\u003cp\\u003e[48]\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 542px;\\\"\\u003e\\n\\u003cp\\u003eThis paper analyzes the integration of blockchain technology in trade finance, highlighting its potential to optimize processes and reduce fraud. It proposes a hybrid solution combining blockchain with existing infrastructure for enhanced performance metrics.\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003c/tr\\u003e\\n\\u003ctr\\u003e\\n\\u003ctd style=\\\"width: 96px;\\\"\\u003e\\n\\u003cp\\u003e[14]\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 542px;\\\"\\u003e\\n\\u003cp\\u003eThis paper analyzes the performance of Hyperledger Fabric for cross-border fund transfers using benchmarking tools. It evaluates latency, scalability, and efficiency, providing insights into the platform's application in financial services.\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003c/tr\\u003e\\n\\u003ctr\\u003e\\n\\u003ctd style=\\\"width: 96px;\\\"\\u003e\\n\\u003cp\\u003e[49]\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 542px;\\\"\\u003e\\n\\u003cp\\u003eThis study benchmarks Hyperledger Fabric v2.4.9 performance under varying workloads, transaction rates (up to 350 TPS), chaincode languages (Go/Node.js), ordering services (Solo/Raft), and organizations, analyzing throughput, latency, success rates, and resource use to identify scalability bottlenecks.\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003c/tr\\u003e\\n\\u003ctr\\u003e\\n\\u003ctd style=\\\"width: 96px;\\\"\\u003e\\n\\u003cp\\u003e[43]\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 542px;\\\"\\u003e\\n\\u003cp\\u003eThe paper develops a blockchain-based messaging system using Algorand and evaluates its performance through benchmarking tests on latency, throughput, confirmation time, and efficiency. It provides practical performance insights for scalable, secure, and reliable blockchain communication in air-cargo supply chains.\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003c/tr\\u003e\\n\\u003ctr\\u003e\\n\\u003ctd style=\\\"width: 96px;\\\"\\u003e\\n\\u003cp\\u003e[39]\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 542px;\\\"\\u003e\\n\\u003cp\\u003eThis study benchmarks Hyperledger Fabric on heterogeneous hardware using Caliper, evaluating throughput (up to 1148 TPS), latency, CPU/memory usage for read/tokenize/transfer chaincodes in IoT networks.\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003c/tr\\u003e\\n\\u003ctr\\u003e\\n\\u003ctd style=\\\"width: 96px;\\\"\\u003e\\n\\u003cp\\u003e[50]\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 542px;\\\"\\u003e\\n\\u003cp\\u003eThis paper proposes lightweight Hyperledger Fabric/IoT authentication for SCM, benchmarked at 10ms execution, 80ms latency, 12 TPS using Composer\\u0026mdash;addresses cyber-attack resilience via hash functions.\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003c/tr\\u003e\\n\\u003c/tbody\\u003e\\n\\u003c/table\\u003e\\n\\u003cp\\u003e\\u0026nbsp;\\u003cstrong\\u003e2.4\\u0026nbsp;\\u003c/strong\\u003e\\u003cstrong\\u003eSmart Contracts and Regulatory Automation\\u003c/strong\\u003e\\u003c/p\\u003e\\n\\u003cp\\u003eSmart contracts represent a pivotal innovation in blockchain systems, enabling the automation of compliance, verification, and enforcement processes across institutional and regulatory environments. They enhance transparency, trust, and efficiency by embedding regulatory requirements directly into executable code, ensuring that transactions are validated and enforced without manual intervention, while facilitating real-time monitoring through distributed execution across peer nodes [46, 48]. This automation significantly reduces administrative delays, human error, and fraud, while facilitating real-time monitoring [48, 51].\\u003c/p\\u003e\\n\\u003cp\\u003eRecent researches position smart contracts as the technological backbone of regulatory automation, transforming policy enforcement into self-executing logic. Studies such as Adeyinka Ogunbajo et al. [20] demonstrated how blockchain-integrated smart contracts can embed governance and compliance rules directly within transactional code, while Agrawal et al. [46] has shown how automated rule enforcement in supply chains mirrors the operation of regulatory oversight. The Model-Driven Architecture (MDA) approach proposed by Jurgelaitis et al. [51] further strengthened reliability by generating smart contracts from formal models, enhancing accuracy and reducing implementation errors\\u0026mdash;critical for trustworthy regulatory systems. In financial and trade contexts, smart contracts facilitate on-chain governance and automated compliance verification, bridging traditional trade processes with digital auditability [48, 52].\\u003c/p\\u003e\\n\\u003cp\\u003eWithin permissioned blockchains such as Hyperledger Fabric, these capabilities are realized through chaincode\\u0026mdash;modular, containerized smart contracts executed under defined endorsement policies. Fabric\\u0026rsquo;s architecture allows authenticated institutions to collaborate securely while maintaining confidentiality and accountability, making it particularly suited for regulated ecosystems. Yet, despite growing evidence of their potential, empirical validation of smart contracts in multi-jurisdictional regulatory environments\\u0026mdash;particularly with respect to transaction throughput, latency, and scalability\\u0026mdash;remains scarce. This study addresses that gap by developing and evaluating Fabric-based smart contract (chaincode) designed to automate NQI functions under AfCFTA, demonstrating their effectiveness in achieving trusted, harmonized, and transparent regulatory cooperation.\\u0026nbsp;Table 2 provides a summary of blockchain applications, highlighting various studies' focus on regulatory automation, institutional integration, and smart contracts.\\u003c/p\\u003e\\n\\u003cp\\u003e\\u003cstrong\\u003eTable\\u0026nbsp;\\u003c/strong\\u003e\\u003cstrong\\u003e2\\u003c/strong\\u003e Literature Summary blockchain applications\\u003c/p\\u003e\\n\\u003ctable border=\\\"0\\\" width=\\\"636\\\" cellspacing=\\\"0\\\" cellpadding=\\\"0\\\"\\u003e\\n\\u003ctbody\\u003e\\n\\u003ctr\\u003e\\n\\u003ctd style=\\\"width: 126px;\\\" valign=\\\"bottom\\\"\\u003e\\n\\u003cp\\u003eStudy\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 162px;\\\" valign=\\\"bottom\\\"\\u003e\\n\\u003cp\\u003eArea of Application\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\" valign=\\\"bottom\\\"\\u003e\\n\\u003cp\\u003eRegulatory Automation\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\" valign=\\\"bottom\\\"\\u003e\\n\\u003cp\\u003eInstitutional Integration\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 54px;\\\" valign=\\\"bottom\\\"\\u003e\\n\\u003cp\\u003eFocus on Smart Contracts\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003eThroughput Analysis\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003eLatency Analysis\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 36px;\\\"\\u003e\\n\\u003cp\\u003eEfficiency\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003eResource Utilization\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 48px;\\\"\\u003e\\n\\u003cp\\u003eEvaluation of Scalability\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003c/tr\\u003e\\n\\u003ctr\\u003e\\n\\u003ctd style=\\\"width: 126px;\\\"\\u003e\\n\\u003cp\\u003e[45]\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 162px;\\\"\\u003e\\n\\u003cp\\u003ecross-organizational processes\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✖\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 54px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 36px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003csup\\u003ea\\u003c/sup\\u003e\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003csup\\u003ea\\u003c/sup\\u003e\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 48px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003c/tr\\u003e\\n\\u003ctr\\u003e\\n\\u003ctd style=\\\"width: 126px;\\\"\\u003e\\n\\u003cp\\u003e[46]\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 162px;\\\"\\u003e\\n\\u003cp\\u003eSupply chain/supply network collaboration\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 54px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✖\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✖\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 36px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 48px;\\\"\\u003e\\n\\u003cp\\u003e✖\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003c/tr\\u003e\\n\\u003ctr\\u003e\\n\\u003ctd style=\\\"width: 126px;\\\"\\u003e\\n\\u003cp\\u003e[47]\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 162px;\\\"\\u003e\\n\\u003cp\\u003eInternet of Things (IoT) environments\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✖\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✖\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 54px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003csup\\u003ea\\u003c/sup\\u003e\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003csup\\u003eb\\u003c/sup\\u003e\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✖\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 36px;\\\"\\u003e\\n\\u003cp\\u003e✖\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✖\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 48px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003csup\\u003ea\\u003c/sup\\u003e\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003c/tr\\u003e\\n\\u003ctr\\u003e\\n\\u003ctd style=\\\"width: 126px;\\\"\\u003e\\n\\u003cp\\u003e[48]\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 162px;\\\"\\u003e\\n\\u003cp\\u003eTrade finance\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 54px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✖\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✖\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 36px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✖\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 48px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003c/tr\\u003e\\n\\u003ctr\\u003e\\n\\u003ctd style=\\\"width: 126px;\\\"\\u003e\\n\\u003cp\\u003e[14]\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 162px;\\\"\\u003e\\n\\u003cp\\u003eCross-Border Fund Transfers\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✖\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 54px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 36px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✖\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 48px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003c/tr\\u003e\\n\\u003ctr\\u003e\\n\\u003ctd style=\\\"width: 126px;\\\"\\u003e\\n\\u003cp\\u003e[49]\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 162px;\\\"\\u003e\\n\\u003cp\\u003eB2B/B2C transactions\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✖\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 54px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 36px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 48px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003c/tr\\u003e\\n\\u003ctr\\u003e\\n\\u003ctd style=\\\"width: 126px;\\\"\\u003e\\n\\u003cp\\u003e[43]\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 162px;\\\"\\u003e\\n\\u003cp\\u003eAir cargo supply chains\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✖\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 54px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 36px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✖\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 48px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003c/tr\\u003e\\n\\u003ctr\\u003e\\n\\u003ctd style=\\\"width: 126px;\\\"\\u003e\\n\\u003cp\\u003e[39]\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 162px;\\\"\\u003e\\n\\u003cp\\u003eIoT ecosystems\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✖\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✖\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 54px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 36px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 48px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003csup\\u003ea\\u003c/sup\\u003e\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003c/tr\\u003e\\n\\u003ctr\\u003e\\n\\u003ctd style=\\\"width: 126px;\\\"\\u003e\\n\\u003cp\\u003eThis study\\u0026nbsp;\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 162px;\\\"\\u003e\\n\\u003cp\\u003eCross-border trade under FTAs\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 54px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 36px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 42px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003ctd style=\\\"width: 48px;\\\"\\u003e\\n\\u003cp\\u003e✓\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003c/tr\\u003e\\n\\u003ctr\\u003e\\n\\u003ctd style=\\\"width: 636px;\\\" colspan=\\\"10\\\" valign=\\\"bottom\\\"\\u003e\\n\\u003cp\\u003e\\u003csup\\u003ea\\u003c/sup\\u003eThe authors considered it conceptual, not in-depth\\u003c/p\\u003e\\n\\u003cp\\u003e\\u003csup\\u003eb\\u003c/sup\\u003eThe authors considered it conceptually, no experimental benchmarking done\\u003c/p\\u003e\\n\\u003c/td\\u003e\\n\\u003c/tr\\u003e\\n\\u003c/tbody\\u003e\\n\\u003c/table\\u003e\\n\\u003cp\\u003e\\u003cstrong\\u003e2.5 Research Gaps and Synthesis\\u003c/strong\\u003e\\u003c/p\\u003e\\n\\u003cp\\u003eDespite growing interest in blockchain-enabled governance, key research gaps persist in evaluating the performance and scalability of peer-to-peer blockchain systems applied to policy-driven, cross-border frameworks such as AfCFTA. Current blockchain\\u0026ndash;NQI studies typically focus on isolated elements\\u0026mdash;such as conformity assessment or metrological traceability\\u0026mdash;without examining how blockchain could support an integrated NQI system capable of operating across diverse regulatory environments among AfCFTA member states [26, 27, 30, 31]. This systemic gap is especially significant given the need for harmonized standards and efficient regulatory assurance in regional trade.\\u003c/p\\u003e\\n\\u003cp\\u003eSimilarly, while Hyperledger Fabric is frequently cited for its potential, limited research investigates the practical design, customization, and performance evaluation of Fabric-based smart contracts tailored to NQI regulatory functions under African jurisdictional conditions. This research addresses these gaps by developing a reproducible evaluation of Fabric in an AfCFTA-aligned configuration, linking performance analysis with regulatory design. Ultimately, sustainable blockchain integration in regulatory infrastructures requires aligning peer-to-peer system architectures, consensus mechanisms, and performance characteristics with institutional objectives, particularly within African trade integration.\\u003c/p\\u003e\"},{\"header\":\"3.\\tConceptual Framework for Peer-to-Peer Blockchain–Enabled NQI Governance\",\"content\":\"\\u003cp\\u003eThe conceptual framework of this study integrates blockchain technology as a permissioned peer-to-peer distributed system, NQI systems, and AfCFTA regulatory objectives into a unified model for digital trust, interoperability, and performance-driven governance. It establishes the theoretical and operational foundation for designing and evaluating a permissioned blockchain system based on Hyperledger Fabric (HLF), aimed at automating compliance, ensuring traceability, and enhancing transparency across interconnected regulatory institutions.\\u0026nbsp;While AfCFTA is used as the illustrative regulatory environment, the framework is generalizable to other regional free trade agreements that rely on NQI coordination.\\u003c/p\\u003e\\n\\u003ch2 id=\\\"_Toc214266820\\\"\\u003e\\u003cstrong\\u003e3.1. Framework Overview\\u003c/strong\\u003e\\u003c/h2\\u003e\\n\\u003cp\\u003eThe framework (as depicted in Fig. 2) conceptualizes the interaction between AfCFTA\\u0026rsquo;s regional regulatory ecosystem, as an illustrative case, and blockchain-based digital infrastructure through three interdependent layers: the Institutional Governance \\u0026amp; Trust Layer, the Permissioned Blockchain \\u0026amp; P2P Infrastructure Layer, and the Blockchain Performance \\u0026amp; Scalability Evaluation Layer. These layers collectively form a closed feedback loop that connects governance objectives, peer-to-peer system design, and empirical performance validation. Policy-driven requirements such as standard harmonization, traceability, and data integrity inform blockchain design choices, while empirical performance outcomes provide feedback for refining both institutional and technical processes. This cyclical interaction ensures that digital systems evolve in alignment with regulatory and operational realities.\\u0026nbsp;From a networking perspective, this loop captures how institutional requirements shape peer interactions, consensus participation, and transaction propagation, while measured performance feeds back into architectural and policy refinement.\\u003c/p\\u003e\\n\\u003ch2\\u003e\\u003cstrong\\u003e3.2. Institutional Governance \\u0026amp; Trust Layer: AfCFTA\\u0026ndash;NQI Integration\\u003c/strong\\u003e\\u003c/h2\\u003e\\n\\u003cp\\u003eAt the macro level, the AfCFTA framework seeks to eliminate trade barriers and promote regional economic integration by harmonizing technical regulations and conformity standards across member states. NQI systems\\u0026mdash;comprising metrology, standards, accreditation, and conformity assessment\\u0026mdash;constitute the operational backbone of these regulatory processes [53\\u0026ndash;55]. Yet, fragmentation among national systems in Africa, inconsistent certification procedures, and limited data interoperability remain significant challenges to the mutual recognition of conformity certificates and to cross-border trade efficiency[56\\u0026ndash;58].\\u003c/p\\u003e\\n\\u003cp\\u003eWithin the conceptual framework, the Permissioned Blockchain \\u0026amp; P2P Infrastructure Layer defines the institutional logic and trust boundaries that the peer-to-peer blockchain system must accommodate. It outlines key regulatory principles such as the traceability of conformity assessments, immutability of certification data, and automatic validation of compliance conditions. These principles are then operationalized in the digital infrastructure layer through smart contracts and consensus mechanisms. By embedding governance logic into system architecture, the institutional layer ensures that the peer-to-peer blockchain infrastructure not only digitizes but also enforces regulatory integrity and accountability across distributed participants.\\u003c/p\\u003e\\n\\u003ch2 id=\\\"_Toc214266822\\\"\\u003e\\u003cstrong\\u003e3.3. Permissioned Blockchain \\u0026amp; P2P Infrastructure Layer: Blockchain and Smart Contracts\\u003c/strong\\u003e\\u003c/h2\\u003e\\n\\u003cp\\u003eThe second layer translates institutional and policy requirements into a permissioned blockchain environment that supports secure, auditable, and efficient data exchange among regulatory agencies. Built conceptually on the Hyperledger Fabric architecture, this layer models a permissioned peer-to-peer network of organizations\\u0026mdash;each representing an NQI institution\\u0026mdash;interacting through deterministic message exchange, endorsement protocols, and a consensus mechanism such as Raft.\\u003c/p\\u003e\\n\\u003cp\\u003e\\u003cstrong\\u003eTable 3\\u003c/strong\\u003e Mapping of AfCFTA-aligned NQI regulatory functions to blockchain transactions and smart contracts\\u003c/p\\u003e\\n\\u003ctable border=\\\"0\\\" cellspacing=\\\"0\\\" cellpadding=\\\"0\\\" width=\\\"660\\\"\\u003e\\n \\u003ctbody\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd valign=\\\"bottom\\\" style=\\\"width: 175px;\\\"\\u003e\\n \\u003cp\\u003e\\u003cstrong\\u003eAfCFTA\\u0026ndash;NQI Function\\u003c/strong\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"bottom\\\" style=\\\"width: 203px;\\\"\\u003e\\n \\u003cp\\u003e\\u003cstrong\\u003eBusiness Transaction\\u003c/strong\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"bottom\\\" style=\\\"width: 198px;\\\"\\u003e\\n \\u003cp\\u003e\\u003cstrong\\u003eSmart Contract\\u003c/strong\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"bottom\\\" style=\\\"width: 84px;\\\"\\u003e\\n \\u003cp\\u003e\\u003cstrong\\u003eLedger Operation\\u003c/strong\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 175px;\\\"\\u003e\\n \\u003cp\\u003eStandards harmonization\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 203px;\\\"\\u003e\\n \\u003cp\\u003eSubmission of new technical standards\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 198px;\\\"\\u003e\\n \\u003cp\\u003eRegulatory Submission and Endorsement Contract (Propose)\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 84px;\\\"\\u003e\\n \\u003cp\\u003eWrite\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 175px;\\\"\\u003e\\n \\u003cp\\u003eStandards harmonization\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 203px;\\\"\\u003e\\n \\u003cp\\u003eMulti-institutional endorsement of standards\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 198px;\\\"\\u003e\\n \\u003cp\\u003eRegulatory Submission and Endorsement Contract (Propose)\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 84px;\\\"\\u003e\\n \\u003cp\\u003eWrite\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 175px;\\\"\\u003e\\n \\u003cp\\u003eAccreditation\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 203px;\\\"\\u003e\\n \\u003cp\\u003eRecording accreditation decisions\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 198px;\\\"\\u003e\\n \\u003cp\\u003eRegulatory Submission and Endorsement Contract (Propose)\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 84px;\\\"\\u003e\\n \\u003cp\\u003eWrite\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 175px;\\\"\\u003e\\n \\u003cp\\u003eConformity assessment\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 203px;\\\"\\u003e\\n \\u003cp\\u003eSubmission of inspection or testing results\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 198px;\\\"\\u003e\\n \\u003cp\\u003eRegulatory Submission and Endorsement Contract (Propose)\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 84px;\\\"\\u003e\\n \\u003cp\\u003eWrite\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 175px;\\\"\\u003e\\n \\u003cp\\u003eMutual recognition\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 203px;\\\"\\u003e\\n \\u003cp\\u003eValidation of approved conformity certificates\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 198px;\\\"\\u003e\\n \\u003cp\\u003eRegulatory Verification and Audit Contract (Query)\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 84px;\\\"\\u003e\\n \\u003cp\\u003eRead\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 175px;\\\"\\u003e\\n \\u003cp\\u003eTrade facilitation\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 203px;\\\"\\u003e\\n \\u003cp\\u003eCertificate verification by regulators or border authorities\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 198px;\\\"\\u003e\\n \\u003cp\\u003eRegulatory Verification and Audit Contract (Query)\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 84px;\\\"\\u003e\\n \\u003cp\\u003eRead\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 175px;\\\"\\u003e\\n \\u003cp\\u003eCompliance monitoring\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 203px;\\\"\\u003e\\n \\u003cp\\u003eRegulatory audit and inspection queries\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 198px;\\\"\\u003e\\n \\u003cp\\u003eRegulatory Verification and Audit Contract (Query)\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 84px;\\\"\\u003e\\n \\u003cp\\u003eRead\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 175px;\\\"\\u003e\\n \\u003cp\\u003eInstitutional transparency\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 203px;\\\"\\u003e\\n \\u003cp\\u003eRetrieval of immutable regulatory records\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 198px;\\\"\\u003e\\n \\u003cp\\u003eRegulatory Verification and Audit Contract (Query)\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 84px;\\\"\\u003e\\n \\u003cp\\u003eRead\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003c/tbody\\u003e\\n\\u003c/table\\u003e\\n\\u003cp\\u003eTable 3 summarizes how AfCFTA-aligned NQI regulatory functions are operationalized as blockchain transactions through functionally distinct smart contracts, forming the basis for the system design evaluated in subsequent sections.\\u003c/p\\u003e\\n\\u003cp\\u003eTwo classes of smart contracts underpin this layer. The Propose Contract represents write-intensive operations that submit and endorse new records (e.g., standards proposals and indorsements, or accreditation results), requiring multi-organizational agreement to achieve consensus. The Query Contract represents read-only operations that retrieve certified data from the ledger, enabling real-time information access for regulators, auditors, and stakeholders. These two transaction types model the dual functionality of the blockchain\\u0026mdash;state-changing and read-only operations\\u0026mdash;and enable performance differentiation based on consensus involvement. From a networking perspective, this distinction separates consensus-bound transaction flows that traverse endorsement and ordering peers from local execution paths that operate entirely at individual peer nodes.\\u003c/p\\u003e\\n\\u003cp\\u003eThe modular structure of Hyperledger Fabric supports this design by separating transaction execution, ordering, and validation [26, 27, 59, 60]. This separation enhances scalability and fault isolation while maintaining deterministic transaction flow across a distributed peer-to-peer execution and ordering pipeline. In addition, channel isolation provides privacy-preserving interactions between participating agencies, and the Membership Service Provider (MSP) framework ensures cryptographically verified digital identities. Together, these mechanisms operationalize a trust architecture that embodies institutional accountability and data sovereignty across FTAs.\\u003c/p\\u003e\\n\\u003ch2\\u003e\\u003cstrong\\u003e3.4. System Design Specification for Blockchain-Enabled NQI Transactions\\u003c/strong\\u003e\\u003c/h2\\u003e\\n\\u003cp\\u003eBuilding on the transaction mappings summarized in Table 3, this subsection formalizes the regulatory workflows as system-level business transactions. While the preceding sections establish the conceptual and architectural foundations of a blockchain-enabled NQI framework, this subsection specifies the concrete system design that operationalizes these concepts. The purpose of this section is to explicitly define the distributed system structure, the AfCFTA-relevant business transactions, and the smart contract abstractions that are later implemented and evaluated experimentally in Section 4.\\u003c/p\\u003e\\n\\u003ch3\\u003e\\u003cstrong\\u003e3.4.1. Design Scope and Assumptions\\u003c/strong\\u003e\\u003c/h3\\u003e\\n\\u003cp\\u003eThe system design targets a permissioned distributed ledger environment in which multiple NQI institutions interact under a shared regulatory framework. AfCFTA is used as an illustrative regulatory context; however, the design is intentionally generic and applicable to other FTAs that depend on mutual recognition of standards, certifications, and conformity assessments.\\u003c/p\\u003e\\n\\u003cp\\u003eThe design assumes:\\u003c/p\\u003e\\n\\u003col class=\\\"decimal_type\\\"\\u003e\\n \\u003cli\\u003eConsortium-based governance among regulatory institutions;\\u003c/li\\u003e\\n \\u003cli\\u003eInstitutional trust boundaries enforced through cryptographic identities;\\u003c/li\\u003e\\n \\u003cli\\u003eDeterministic transaction processing suitable for regulatory use cases;\\u003c/li\\u003e\\n \\u003cli\\u003eInfrastructure constraints representative of developing-region deployments.\\u003c/li\\u003e\\n \\u003cli\\u003ePeer-to-peer communication and ledger replication across organizational boundaries.\\u003c/li\\u003e\\n\\u003c/ol\\u003e\\n\\u003ch3\\u003e\\u003cstrong\\u003e3.4.2. Participating Organizations and Network Roles\\u003c/strong\\u003e\\u003c/h3\\u003e\\n\\u003cp\\u003eEach participating organization in the system represents an NQI institution (e.g., standards bodies, accreditation agencies, conformity assessment bodies, or regulatory authorities). Within the distributed ledger network:\\u003c/p\\u003e\\n\\u003cul class=\\\"decimal_type\\\"\\u003e\\n \\u003cli\\u003eEach organization operates at least one peer node;\\u003c/li\\u003e\\n \\u003cli\\u003eAll peers maintain a synchronized ledger state;\\u003c/li\\u003e\\n \\u003cli\\u003eEndorsement policies enforce multi-institutional agreement on regulatory actions;\\u003c/li\\u003e\\n \\u003cli\\u003eA logically centralized but physically distributed ordering service ensures transaction finality within the peer-to-peer network.\\u003c/li\\u003e\\n\\u003c/ul\\u003e\\n\\u003cp\\u003eThis organizational abstraction directly informs the symmetric three-peer topology used in the experimental setup described in Section 4.2.\\u003c/p\\u003e\\n\\u003ch3\\u003e\\u003cstrong\\u003e3.4.3. AfCFTA-Oriented Business Transactions\\u003c/strong\\u003e\\u003c/h3\\u003e\\n\\u003cp\\u003eThe system design models regulatory business transactions rather than generic blockchain operations. These transactions reflect the core functions of NQI coordination under FTAs:\\u003c/p\\u003e\\n\\u003col\\u003e\\n \\u003cli\\u003eStandards Proposal and Endorsement: Submission and multi-party validation of new or revised technical standards.\\u003c/li\\u003e\\n \\u003cli\\u003eAccreditation and Conformity Record Submission: Recording certification outcomes, inspection results, or accreditation decisions that require immutability and auditability.\\u003c/li\\u003e\\n \\u003cli\\u003eCertificate and Standard Verification: Retrieval of validated regulatory records by customs authorities, auditors, or trade stakeholders.\\u003c/li\\u003e\\n \\u003cli\\u003eCompliance and Audit Queries: Read-only access to historical regulatory data for monitoring and enforcement purposes.\\u003c/li\\u003e\\n\\u003c/ol\\u003e\\n\\u003cp\\u003eThese transactions represent distinct regulatory workflows with different performance and consensus requirements.\\u003c/p\\u003e\\n\\u003ch3\\u003e\\u003cstrong\\u003e3.4.4. Smart Contract Abstraction and Classification\\u003c/strong\\u003e\\u003c/h3\\u003e\\n\\u003cp\\u003eBased on the above transactions, the system defines two functional classes of smart contracts, aligned with Hyperledger Fabric\\u0026rsquo;s execution model:\\u003c/p\\u003e\\n\\u003cul\\u003e\\n \\u003cli\\u003ePropose Contracts (Write-Intensive): Implement state-changing regulatory actions such as standards proposals or certification submissions. These transactions require endorsement by multiple organizations and inclusion in an ordered block before commitment.\\u003c/li\\u003e\\n \\u003cli\\u003eQuery Contracts (Read-Only): Support certificate verification, compliance checks, and audit queries. These transactions are executed locally on peer nodes and do not invoke consensus mechanisms.\\u003c/li\\u003e\\n\\u003c/ul\\u003e\\n\\u003cp\\u003eThis abstraction reflects the operational reality of NQI systems, where regulatory decisions require collective validation, while compliance verification demands low-latency access.\\u003c/p\\u003e\\n\\u003ch3\\u003e\\u003cstrong\\u003e3.4.5. Design\\u0026ndash;Evaluation Alignment\\u003c/strong\\u003e\\u003c/h3\\u003e\\n\\u003cp\\u003eThe explicit system design directly motivates the experimental methodology presented in Section 4. By selecting one representative Propose smart contract and one Query smart contract, the evaluation isolates the performance impact of consensus-driven versus local execution paths under constrained infrastructure conditions.\\u003c/p\\u003e\\n\\u003cp\\u003eThus, the performance metrics reported later are grounded in realistic regulatory transaction flows, ensuring that evaluation results are interpretable within the context of AfCFTA-oriented NQI operations rather than abstract blockchain benchmarks.\\u003c/p\\u003e\\n\\u003ch2 id=\\\"_Toc214266823\\\"\\u003e\\u003cstrong\\u003e3.5. Blockchain Performance \\u0026amp; Scalability Evaluation Layer: Benchmarking and Feedback Mechanism\\u003c/strong\\u003e\\u003c/h2\\u003e\\n\\u003cp\\u003eThe third layer of the conceptual model establishes a performance and evaluation framework that quantifies peer-to-peer system efficiency, scalability, and reliability. Moreover, this layer is conceived abstractly as a data-driven feedback mechanism that connects blockchain performance metrics with system and policy optimization.\\u003c/p\\u003e\\n\\u003cp\\u003eIt encompasses the processes of workload generation, performance observation, and data interpretation\\u0026mdash;focusing on key indicators such as throughput, latency, efficiency, and resource utilization. These indicators serve as the quantitative foundation for assessing how the blockchain system performs under different network loads and organizational configurations [41, 43, 59]. The results inform iterative adjustments to blockchain parameters (e.g., block size, endorsement policies, consensus settings) and provide evidence for institutional decisions on acceptable response times and operational efficiency in regulatory environments [15, 41, 43, 59].\\u003c/p\\u003e\\n\\u003cp\\u003eThus, this layer transforms performance assessment into a strategic governance instrument, bridging peer-to-peer network behavior, system-level performance outcomes, and policy formulation. By treating system evaluation as part of the conceptual logic, rather than as a mere implementation detail, the framework integrates measurement and control into the design of the regulatory infrastructure itself.\\u003c/p\\u003e\\n\\u003ch2 id=\\\"_Toc214266824\\\"\\u003e\\u003cstrong\\u003e3.6. Interactions and Feedback Dynamics\\u003c/strong\\u003e\\u003c/h2\\u003e\\n\\u003cp\\u003eThe model establishes bidirectional linkages among the three layers, ensuring that institutional objectives guide system design while empirical results continuously refine policy and technology. The top-down integration process ensures that AfCFTA and NQI policy goals directly influence blockchain parameters\\u0026mdash;such as consensus rules, endorsement mechanisms, and data-sharing policies\\u0026mdash;while the bottom-up feedback loop channels performance insights into adaptive policy reform and technical reconfiguration.\\u003c/p\\u003e\\n\\u003cp\\u003eThis dynamic interaction constitutes a cyber\\u0026ndash;institutional feedback loop in which peer-to-peer system behavior and governance mechanisms co-evolve. It reflects the principle that digital transformation in regulatory systems should not be static but responsive, enabling iterative improvements in efficiency, transparency, and interoperability. By aligning technical performance with policy outcomes, the model embodies the socio-technical synergy necessary for digital trust and sustainable trade integration [3].\\u003c/p\\u003e\"},{\"header\":\"4.\\tMethodology\",\"content\":\"\\u003cp\\u003eThis study adopted an experimental research design to evaluate the performance and scalability of a Hyperledger Fabric (HLF) 2.5\\u0026ndash;based permissioned peer-to-peer blockchain framework for regulating and interlinking NQI services under the AfCFTA framework. The methodology integrated system design, workload modeling, benchmarking, and monitoring under reproducible conditions to ensure empirical rigor and transparency, consistent with established blockchain performance research practices [14, 41, 43, 59, 61].\\u003c/p\\u003e\\n\\u003ch2 id=\\\"_Toc214266826\\\"\\u003e\\u003cstrong\\u003e4.1. Research Design and Objectives\\u003c/strong\\u003e\\u003c/h2\\u003e\\n\\u003cp\\u003eA quantitative, experiment-driven research design was employed to evaluate the operational behavior of the proposed AfCFTA\\u0026ndash;NQI distributed ledger system under representative regulatory transaction workloads. Performance was assessed using four standard indicators:\\u003c/p\\u003e\\n\\u003col start=\\\"1\\\" type=\\\"1\\\"\\u003e\\n \\u003cli\\u003eThroughput (transactions per second, TPS),\\u003c/li\\u003e\\n \\u003cli\\u003eLatency,\\u003c/li\\u003e\\n \\u003cli\\u003eEfficiency, and\\u003c/li\\u003e\\n \\u003cli\\u003eResource utilization (CPU, memory, and network I/O).\\u003c/li\\u003e\\n\\u003c/ol\\u003e\\n\\u003cp\\u003eThese metrics jointly assess the peer-to-peer network\\u0026rsquo;s scalability, responsiveness, and execution behavior in supporting institutional operations [41, 43, 61].\\u003c/p\\u003e\\n\\u003cp\\u003eThe workloads defined below directly instantiate the AfCFTA-oriented business transactions specified in Section 3.4. To reflect real AfCFTA regulatory processes, workloads were defined based on business transaction semantics rather than abstract read/write labels:\\u003c/p\\u003e\\n\\u003cul\\u003e\\n \\u003cli\\u003e\\u003cem\\u003eRegulatory Submission and Endorsement Workload:\\u003c/em\\u003e This workload models AfCFTA\\u0026ndash;NQI transactions that create or update regulatory state, such as accreditation approvals, conformity assessment results, or standards proposals. These transactions require endorsement from multiple NQI institutions and trigger block creation and ledger updates.\\u003c/li\\u003e\\n \\u003cli\\u003e\\u003cem\\u003eRegulatory Verification and Audit Workload:\\u003c/em\\u003e This workload represents AfCFTA trade-facilitation activities such as certificate verification, compliance inspection, and audit queries. These transactions retrieve validated records from the ledger without modifying state and are executed locally at peer nodes. This distinction enables isolation of consensus-bound peer-to-peer transaction flows from local peer execution paths, a key concern in distributed ledger networking research.\\u003c/li\\u003e\\n\\u003c/ul\\u003e\\n\\u003cp\\u003eThis dual workload structure mirrors NQI\\u0026rsquo;s operational logic\\u0026mdash;where new regulatory records demand immutability, and audits require rapid data access [43, 62\\u0026ndash;64].\\u003c/p\\u003e\\n\\u003cp\\u003eThe experimental design pursued four main objectives:\\u003c/p\\u003e\\n\\u003col class=\\\"decimal_type\\\"\\u003e\\n \\u003cli\\u003eEvaluate throughput and latency trends under varying transaction rates and concurrency;\\u003c/li\\u003e\\n \\u003cli\\u003eMeasure system efficiency under progressively increasing loads;\\u003c/li\\u003e\\n \\u003cli\\u003eAnalyze relationships between performance metrics and infrastructure resource consumption; and\\u003c/li\\u003e\\n \\u003cli\\u003eIdentify the sources of performance bottlenecks within the system, determining whether they arise from Fabric\\u0026rsquo;s architectural processes (endorsement and ordering) or from underlying resource constraints.\\u003c/li\\u003e\\n\\u003c/ol\\u003e\\n\\u003ch2 id=\\\"_Toc214266827\\\"\\u003e\\u003cstrong\\u003e4.2. System Design and Implementation\\u003c/strong\\u003e\\u003c/h2\\u003e\\n\\u003ch3 id=\\\"_Toc214266828\\\"\\u003e\\u003cstrong\\u003e4.2.1. Network Architecture\\u003c/strong\\u003e\\u003c/h3\\u003e\\n\\u003cp\\u003eThe test network was implemented as a containerized experimental testbed designed for reproducibility and controlled parameter tuning. The topology comprised one Raft-based ordering service and three peer organization (NQI_Org1, NQI_Org2, and NQI_Org3), each hosting a single peer node\\u0026nbsp;forming a permissioned peer-to-peer network with replicated ledger state and deterministic consensus. This configuration provides a minimal but representative regulatory consortium structure, balancing decentralization and manageability [36, 65, 66].\\u003c/p\\u003e\\n\\u003cp\\u003eTo preserve methodological neutrality, the organizations were labeled generically rather than assigned to specific AfCFTA member states. Each organization symbolized an NQI institution with identical peer roles, endorsement policies, and network configurations. This symmetrical setup isolates Fabric\\u0026rsquo;s architectural effects from country-specific factors such as infrastructural heterogeneity or policy maturity.\\u003c/p\\u003e\\n\\u003cp\\u003eAll network components were containerized using Docker and orchestrated with Docker Compose to ensure modular deployment and service isolation. Transport Layer Security (TLS) secured all peer-to-peer communications among peers and orderers, ensuring authenticated message exchange and secure ledger replication, and the Membership Service Provider (MSP) managed digital identities and certificate hierarchies among consortium members [36, 66, 67].\\u003c/p\\u003e\\n\\u003cp\\u003eThe ordering service employed a 2-second batch timeout, a maximum message count of 10, and a block size of 512 KB, parameters chosen to balance throughput and latency. A single application channel hosted the deployed smart contracts, providing a shared ledger view and consistent data synchronization\\u0026nbsp;, enabling consistent state propagation across peers via ordered block dissemination.\\u003c/p\\u003e\\n\\u003ch3 id=\\\"_Toc214266829\\\"\\u003e\\u003cstrong\\u003e4.2.2. Organizational and Cryptographic Configuration\\u003c/strong\\u003e\\u003c/h3\\u003e\\n\\u003cp\\u003eEach organization\\u0026rsquo;s cryptographic identity was established via the Fabric Certificate Authority (CA). The configurations (defined in\\u0026nbsp;crypto-config.yaml\\u0026nbsp;and\\u0026nbsp;configtx.yaml) specified MSP IDs, domain names, administrative certificates, and channel governance policies. The MAJORITY Admins policy regulated administrative decisions, while ImplicitMeta rules governed chaincode access.\\u003c/p\\u003e\\n\\u003cp\\u003eFabric v2.5\\u0026ndash;specific features\\u0026mdash;private-data collections and enhanced endorsement semantics\\u0026mdash;were enabled to improve confidentiality and deterministic transaction validation. [62, 68]\\u003c/p\\u003e\\n\\u003ch3 id=\\\"_Toc214266830\\\"\\u003e\\u003cstrong\\u003e4.2.3. \\u0026nbsp;Smart Contract and Workload Design\\u003c/strong\\u003e\\u003c/h3\\u003e\\n\\u003cp\\u003eTwo chaincodes were implemented to operationalize the AfCFTA\\u0026ndash;NQI transaction model:\\u003c/p\\u003e\\n\\u003cul class=\\\"decimal_type\\\"\\u003e\\n \\u003cli\\u003eThe Regulatory Submission and Endorsement Contract implements business logic for proposing and recording regulatory artifacts, including standards and conformity outcomes. Each transaction enforces endorsement policies that reflect institutional consensus requirements before ledger commitment.\\u003c/li\\u003e\\n \\u003cli\\u003eThe Regulatory Verification and Audit Contract enables efficient retrieval of validated regulatory data to support trade facilitation, border inspection, and compliance monitoring without consensus overhead.\\u0026nbsp;From a networking standpoint, these query transactions avoid inter-peer coordination and ordering traffic, allowing direct state access at individual peers.\\u003c/li\\u003e\\n\\u003c/ul\\u003e\\n\\u003cp\\u003eBoth contracts were developed in Go and deployed using the Hyperledger Fabric v2.5 chaincode lifecycle. This design ensures deterministic execution, modular extensibility, and consistent performance measurement across transaction classes [36, 69, 70]. Listing 1 1 illustrates representative functions\\u0026mdash;ProposeStandard and QueryStandard\\u0026mdash;which model AfCFTA-aligned regulatory submission and verification workflows within the distributed ledger.\\u003c/p\\u003e\\n\\u003cp\\u003e\\u003cstrong\\u003eListing 1\\u003c/strong\\u003e Simplified chaincode logic for proposal and query transactions\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026nbsp;\\u003c/p\\u003e\\n\\u003ctable style=\\\"width:6.5in;border-collapse:collapse;border:none;\\\"\\u003e\\n \\u003ctbody\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e1\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: 1pt solid windowtext;border-left: none;border-bottom: none;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e// Listing 1. Simplified Chaincode Logic for Propose and Query Transactions\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e2\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003epackage main\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e3\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003eimport (\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e4\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp;\\u0026quot;encoding/json\\u0026quot;\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e5\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp;\\u0026quot;fmt\\u0026quot;\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e6\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp;\\u0026quot;github.com/hyperledger/fabric-contract-api-go/contractapi\\u0026quot;\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e7\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e)\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e8\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e// Standard defines the structure for a regulatory standard\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e9\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003etype Standard struct {\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e10\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp;StandardID \\u0026nbsp; \\u0026nbsp; \\u0026nbsp;string \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp;`json:\\u0026quot;standardID\\u0026quot;`\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e11\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; Details \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; string \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp;`json:\\u0026quot;details\\u0026quot;`\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e12\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp;ProposingMember string \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; `json:\\u0026quot;proposingMember\\u0026quot;`\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e13\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; Votes \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; map[string]bool `json:\\u0026quot;votes\\u0026quot;`\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e14\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; Status \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp;string \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp;`json:\\u0026quot;status\\u0026quot;`\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e15\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e}\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e16\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e// ProposeStandard allows a member organization to submit a new standard\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e17\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003efunc (s *SmartContract) ProposeStandard(ctx contractapi.TransactionContextInterface,\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e18\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp;standardID, details, proposingMember string) error {\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e19\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; exists, err := s.StandardExists(ctx, standardID)\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e20\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; if err != nil {\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e21\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; return err\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e22\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; }\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e23\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; if exists {\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e24\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; return fmt.Errorf(\\u0026quot;the standard %s already exists\\u0026quot;, standardID)\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e25\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; }\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e26\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp;\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e27\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; std := Standard{\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e28\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp;StandardID: \\u0026nbsp; \\u0026nbsp; \\u0026nbsp;standardID,\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e29\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp;Details: \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; details,\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e30\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp;ProposingMember: proposingMember,\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e31\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp;Votes: \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp;make(map[string]bool),\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e32\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp;Status: \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026quot;Proposed\\u0026quot;,\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e33\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; }\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e34\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; stdJSON, _ := json.Marshal(std)\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e35\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; return ctx.GetStub().PutState(standardID, stdJSON)\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e36\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e}\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e37\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e// QueryStandard retrieves the details of a standard from the ledger\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e38\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003efunc (s *SmartContract) QueryStandard(ctx contractapi.TransactionContextInterface,\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e39\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp;standardID string) (*Standard, error) {\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e40\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; stdJSON, err := ctx.GetStub().GetState(standardID)\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e41\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; if err != nil {\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e42\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; return nil, fmt.Errorf(\\u0026quot;failed to read from world state: %v\\u0026quot;, err)\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e43\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; }\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e44\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; if stdJSON == nil {\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e45\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; \\u0026nbsp; \\u0026nbsp; return nil, fmt.Errorf(\\u0026quot;the standard %s does not exist\\u0026quot;, standardID)\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e46\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; }\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e47\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; var std Standard\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e48\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; _ = json.Unmarshal(stdJSON, \\u0026amp;std)\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e49\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e\\u0026nbsp; \\u0026nbsp; return \\u0026amp;std, nil\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 22.5pt;border-top: none;border-bottom: none;border-left: none;border-image: initial;border-right: 1pt solid windowtext;padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:right;line-height:normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e50\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 445.5pt;border-top: none;border-left: none;border-bottom: 1pt solid windowtext;border-right: 1pt solid windowtext;background: rgb(242, 242, 242);padding: 0in 5.4pt;vertical-align: top;\\\"\\u003e\\n \\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height: normal;'\\u003e\\u003cspan style=\\\"font-size:12px;font-family:Consolas;color:black;\\\"\\u003e}\\u003c/span\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003c/tbody\\u003e\\n\\u003c/table\\u003e\\n\\u003cp style='margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:0in;font-size:11.0pt;font-family:\\\"Calibri\\\",sans-serif;text-align:justify;line-height:normal;'\\u003e\\u003cspan style='font-size:13px;font-family:\\\"Times New Roman\\\",serif;color:black;'\\u003e\\u0026nbsp;\\u003c/span\\u003e\\u003c/p\\u003e\\n\\u003ch2\\u003e\\u003cstrong\\u003e4.3. Benchmarking and Monitoring Environment\\u003c/strong\\u003e\\u003c/h2\\u003e\\n\\u003cp\\u003ePerformance evaluation utilized Hyperledger Caliper v0.6.0, a standardized benchmarking framework for permissioned blockchains [14, 41, 63]. Fig. 3, illustrates the experimental setup followed. Caliper was configured to execute the \\u003cem\\u003ePropose\\u003c/em\\u003e and \\u003cem\\u003eQuery\\u003c/em\\u003e workloads under varying transaction rates (100\\u0026ndash;800 TPS) and concurrency levels (1\\u0026ndash;12 workers). Each test was run for 60 seconds per round, with results exported in JSON and HTML formats. The total number of experimental runs was determined as follows:\\u003c/p\\u003e\\n\\u003cp\\u003e\\u003cstrong\\u003e7 worker concurrencies \\u0026times; 5 transaction load levels \\u0026times; 3 repeated batches = 105 total runs.\\u003c/strong\\u003e\\u003c/p\\u003e\\n\\u003cp\\u003eThis design enabled the computation of representative averages and minimized the influence of transient system fluctuations, thereby ensuring the reliability and validity of the reported Hyperledger Fabric performance metrics. This experimental design enables observation of peer-to-peer throughput saturation, ordering delays, and execution locality effects under controlled network conditions.\\u003c/p\\u003e\\n\\u003cp\\u003eA Grafana\\u0026ndash;Prometheus monitoring stack was integrated to collect real-time system-level metrics. Prometheus captured container-specific CPU, memory, and network I/O data, while Grafana visualized performance trends. The dual instrumentation allowed cross-validation between blockchain metrics (from Caliper) and system resource behavior, ensuring reliability and interpretability [71, 72].\\u003c/p\\u003e\\n\\u003ch2 id=\\\"_Toc214266832\\\"\\u003e\\u003cstrong\\u003e4.4. Data Collection and Preprocessing\\u003c/strong\\u003e\\u003c/h2\\u003e\\n\\u003cp\\u003eEach experimental configuration was executed three times to mitigate stochastic variability. To preserve statistical validity, warm-up and cool-down intervals were excluded from analysis to eliminate transient startup effects. Outlier runs\\u0026mdash;caused by temporary I/O or scheduling delays\\u0026mdash;were filtered out.\\u003c/p\\u003e\\n\\u003ch2 id=\\\"_Toc214266833\\\"\\u003e\\u003cstrong\\u003e4.5. Experimental Control\\u003c/strong\\u003e\\u003c/h2\\u003e\\n\\u003cp\\u003eThe experimental setup was deployed on a high-performance workstation equipped with an Intel Xeon Gold 6230R processor (52 cores, 46 GB RAM, 5.9 TB SSD) running Ubuntu 22.04 LTS under Windows Subsystem for Linux 2 (WSL2). The software environment comprised Docker 28.3.3, Node.js 20.19.5, and npm 10.8.2. This configuration was selected to minimize hardware-related effects and ensure that observed behaviors reflected protocol-level performance.\\u003c/p\\u003e\\n\\u003cp\\u003eAll benchmarking components\\u0026mdash;Hyperledger Fabric v2.5, Caliper v0.6.0, Prometheus v2.54, and Grafana v11.1\\u0026mdash;were containerized, version-controlled, and verified for configuration consistency. Before testing, extensive validation confirmed network integrity, including:\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; Certificate Authority (CA) enrollment and TLS handshake verification;\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; Successful chaincode deployment and endorsement testing; and\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; Inspection of peer and orderer container logs to ensure stable operation and error-free startup.\\u003c/p\\u003e\\n\\u003ch2 id=\\\"_Toc214266834\\\"\\u003e\\u003cstrong\\u003e4.6. Analytical Framework\\u003c/strong\\u003e\\u003c/h2\\u003e\\n\\u003cp\\u003eThe benchmarking data exported by Caliper were processed and visualized using MATLAB to derive descriptive statistics and performance correlations. Analytical plots were constructed to explore relationships between:\\u003c/p\\u003e\\n\\u003cul type=\\\"disc\\\"\\u003e\\n \\u003cli\\u003eThroughput and target TPS;\\u003c/li\\u003e\\n \\u003cli\\u003eLatency and concurrency;\\u003c/li\\u003e\\n \\u003cli\\u003eEfficiency and load; and\\u003c/li\\u003e\\n \\u003cli\\u003eResource utilization and transaction rate.\\u003c/li\\u003e\\n\\u003c/ul\\u003e\\n\\u003cp\\u003eThese analyses follow established methodologies in blockchain benchmarking and distributed systems performance modeling [14, 41, 59, 61]. Queueing theory, consensus mechanics, and peer-to-peer execution principles provided the interpretive foundation for assessing throughput\\u0026ndash;latency trade-offs and identifying saturation points, though detailed results are discussed later in Section 5.\\u003c/p\\u003e\\n\\u003ch2 id=\\\"_Toc214266835\\\"\\u003e\\u003cstrong\\u003e4.7. Ethical, Methodological, and Contextual Considerations\\u003c/strong\\u003e\\u003c/h2\\u003e\\n\\u003cp\\u003eWhile the experimental model abstracted organizational entities (NQI_Org1\\u0026ndash;NQI_Org3) rather than assigning real countries, this abstraction preserved neutrality and reproducibility. It ensured that performance outcomes reflected system-level properties rather than infrastructural disparities among AfCFTA member states. The use of synthetic workloads and de-identified institutional analogs avoided collection of any sensitive or proprietary data.\\u003c/p\\u003e\\n\\u003cp\\u003eAll configurations adhered to open-source licensing conditions of the Hyperledger ecosystem, ensuring compliance with ethical standards for digital experimentation and software reproducibility [73].\\u003c/p\\u003e\"},{\"header\":\"5.\\tResults and Discussion\",\"content\":\"\\u003ch2 id=\\\"_Toc214266837\\\"\\u003e\\u003cstrong\\u003e5.1. Throughput and Scalability Analysis\\u003c/strong\\u003e\\u003c/h2\\u003e\\n\\u003cp\\u003eThe experimental benchmarking results reveal clear distinctions in the performance behavior of write-intensive (Propose) and read-intensive (Query) workloads (Fig. 4), reflecting the modular peer-to-peer execution architecture of Hyperledger Fabric 2.5. This dichotomy underscores the influence of Fabric\\u0026rsquo;s consensus-driven transaction pipeline on overall system scalability, particularly when comparing endorsement-heavy write transactions against lightweight read queries [15, 36, 45, 74].\\u003c/p\\u003e\\n\\u003cp\\u003eFor the Propose workload (Fig. 4(a)), throughput exhibited a progressive increase with concurrency up to approximately four workers, where it peaked at around 400 transactions per second (TPS). Beyond this point, throughput plateaued, with marginal gains observed even as concurrency was increased to twelve workers. This saturation behavior reveals an upper throughput boundary dictated primarily by the Raft-based ordering service, whose batching policy, endorsement latency, and block formation intervals collectively constrain transaction finalization rates [15, 75, 76]. The results are consistent with previous evaluations of Fabric\\u0026rsquo;s ordering service, which identified similar throughput ceilings in consensus-bound workloads, confirming the deterministic limitations imposed by sequential block generation [45, 62].\\u003c/p\\u003e\\n\\u003cp\\u003eIn contrast, as shown in Fig. 4(b), the Query workload demonstrated nearly linear scalability across all concurrency and throughput levels tested, sustaining up to 800 TPS under maximum load without significant degradation. This behavior aligns with Fabric\\u0026rsquo;s design philosophy for query operations, which bypass the ordering and endorsement processes and are executed locally at peer nodes through efficient state database lookups [45, 75, 76]. The lack of dependency on consensus mechanisms allows these operations to leverage parallel processing and local caching, resulting in near-ideal scaling efficiency even as workload intensity increases [36, 39, 75].\\u003c/p\\u003e\\n\\u003cp\\u003eThe observed divergence in scalability between the two workloads highlights a fundamental trade-off between immutability and speed in Hyperledger Fabric\\u0026rsquo;s operational model. Write transactions, constrained by endorsement and ordering dependencies, exhibit throughput ceilings once consensus pipelines become saturated (Fig. 4(c)), whereas read transactions benefit from the system\\u0026rsquo;s ability to perform parallel, consensus-free executions (Fig. 4(d)). This behavior confirms the architectural efficiency of Fabric for read-dominant use cases, such as regulatory audits, compliance monitoring, and data transparency dashboards, where rapid data retrieval is prioritized over transaction immutability.\\u003c/p\\u003e\\n\\u003cp\\u003eFrom a scalability perspective, these findings suggest that optimizing performance for write-heavy applications requires consensus-layer tuning and architectural adjustments rather than hardware augmentation. Strategies such as multi-orderer clusters, channel partitioning, or dynamic block parameter adjustment can mitigate queuing delays and improve throughput consistency [62, 77]. Conversely, for data-centric applications dominated by queries, the system\\u0026rsquo;s performance scales effectively with concurrency, confirming its suitability for analytics-oriented workloads within NQI systems under AfCFTA.\\u003c/p\\u003e\\n\\u003cp\\u003eOverall, the throughput trends observed reaffirm Fabric\\u0026rsquo;s design trade-offs: while the platform guarantees transactional integrity and traceability for write operations, it does so at the expense of scalability under high load (Fig. 4(a)). Meanwhile, read operations demonstrate Fabric\\u0026rsquo;s capability for horizontal scaling and low-latency data retrieval (Fig. 4(d)), making it particularly well-suited for hybrid institutional ecosystems that demand both accountability and performance.\\u003c/p\\u003e\\n\\u003ch2 id=\\\"_Toc214266838\\\"\\u003e\\u003cstrong\\u003e5.2. Transaction Efficiency and Latency Behavior\\u003c/strong\\u003e\\u003c/h2\\u003e\\n\\u003cp\\u003eEfficiency and latency analyses provide deeper insights into the stability and responsiveness of Hyperledger Fabric under varying transaction loads. Together, these metrics expose how consensus and endorsement processes affect overall system responsiveness and resource utilization, revealing Fabric\\u0026rsquo;s intrinsic operational bottlenecks and performance asymmetries [40, 47, 76].\\u0026nbsp;To complement throughput analysis, efficiency captures transaction success under load, while latency characterizes temporal responsiveness once saturation is approached.\\u003c/p\\u003e\\n\\u003cp\\u003eFor the Propose workload (Fig. 5(a)), efficiency decreased progressively as the target transaction rate increased\\u0026mdash;from approximately 97% at 100 TPS to about 50% at 800 TPS. This decline reflects the growing mismatch between transaction arrival rates and the service rate of the ordering layer, leading to queuing and eventual transaction rejection or timeout. Similarly, efficiency declined beyond four to six concurrent workers (Fig. 5(c)), stabilizing near 65%, for the case of 600 TPS, a behavior consistent with predictions from queuing theory for bounded service systems operating near saturation [14, 76]. The drop in efficiency at higher concurrencies indicates that, beyond a certain point, additional workload parallelism fails to produce proportional performance gains, as the ordering service becomes the dominant limiting factor.\\u003c/p\\u003e\\n\\u003cp\\u003eIn contrast, the Query workload (Fig. 5(b)) maintained near-perfect efficiency (~100%) across all concurrency and transaction rates, except for the worker concurrencies of one and two. This stability confirms that Fabric\\u0026rsquo;s read operations\\u0026mdash;executed without the overhead of consensus\\u0026mdash;are not subject to queuing or block batching constraints. Consequently, read-heavy applications can achieve deterministic reliability even under extreme transactional stress, highlighting Fabric\\u0026rsquo;s potential for high-frequency analytics and continuous data validation environments [15, 16, 75].\\u003c/p\\u003e\\n\\u003cp\\u003eLatency analysis further accentuates these distinctions. For Propose transactions (Fig. 6(a)), average latency remained low (\\u0026le;0.1 s) at modest loads (\\u0026le;200 TPS) but escalated sharply beyond 400 TPS, reaching approximately 27.5 seconds at 800 TPS. The corresponding maximum latency increased from 3.9 seconds at 400 TPS to nearly 48 seconds at 800 TPS (Fig. 6(c)), illustrating rapidly increasing queuing delays in the ordering and endorsement stages once throughput saturation was reached. Such behavior typifies consensus-bound blockchain systems, where deterministic transaction ordering introduces serialization overhead that limits real-time responsiveness [40, 42, 76].\\u003c/p\\u003e\\n\\u003cp\\u003eConversely, for Query transactions (Fig. 6(b) and Fig. 6(d)) both average and maximum latency remained remarkably stable\\u0026mdash;ranging between 0.008 and 0.015 seconds across all concurrency levels and target TPS rates. This low and consistent latency validates Fabric\\u0026rsquo;s architecture for read operations, where transactions are processed directly at peer nodes without requiring endorsement or block inclusion. These results confirm that Fabric\\u0026rsquo;s query performance scales predictably and remains unaffected by network congestion or block size parameters, provided the underlying database (CouchDB) is efficiently indexed and cached [45, 47]\\u003c/p\\u003e\\n\\u003cp\\u003eThe latency divergence between write and read workloads emphasizes the cost of consensus in permissioned blockchains. While ordering ensures non-repudiation and regulatory trustworthiness, it introduces significant propagation delay under high concurrency, making it unsuitable for latency-sensitive, write-heavy environments. On the other hand, the predictably low query latency supports real-time applications such as regulatory dashboards, compliance verification systems, and audit portals, where sub-second response times are essential for usability and transparency.\\u003c/p\\u003e\\n\\u003cp\\u003eCollectively, the efficiency and latency results (Fig. 5\\u0026ndash;6)\\u003cstrong\\u003e\\u0026nbsp;\\u003c/strong\\u003ealign with prior studies demonstrating that Fabric\\u0026rsquo;s performance bottlenecks originate primarily from the ordering and endorsement layers, rather than computational or networking constraints [40, 45, 78]. Even under peak concurrency, CPU and network utilization remained below critical thresholds, confirming that throughput and latency degradation stem from software-level serialization effects rather than hardware limitations. Thus, the results provide empirical validation of Fabric\\u0026rsquo;s scalability boundaries and reinforce the need for architectural enhancements\\u0026mdash;such as parallel consensus mechanisms and multi-channel isolation\\u0026mdash;to improve write scalability in institutional blockchain deployments.\\u003c/p\\u003e\\n\\u003ch2 id=\\\"_Toc214266839\\\"\\u003e\\u003cstrong\\u003e\\u003cstrong\\u003e5.3.\\u0026nbsp;\\u003c/strong\\u003eSystem Resource Utilization and Monitoring\\u003c/strong\\u003e\\u003c/h2\\u003e\\n\\u003cp\\u003eResource utilization analysis provides a holistic understanding of how Hyperledger Fabric manages computational and communication resources under varying workloads. The results demonstrate that system performance limitations observed in throughput and latency stem primarily from consensus-layer constraints rather than hardware exhaustion, reaffirming the architectural efficiency of Fabric\\u0026rsquo;s modular design [40, 76, 79].\\u003c/p\\u003e\\n\\u003cp\\u003eCPU utilization exhibited a near-linear scaling pattern with respect to both workload concurrency and transaction rate (Fig. 7(a) and Fig. 7(b)). Utilization increased from approximately 6% with a single worker to between 30% and 55% with twelve workers at the highest workload intensity (800 TPS). This predictable growth suggests that the Fabric execution model effectively distributes computational load across available cores. The narrow variance in CPU usage confirms that endorsement, validation, and block verification processes are efficiently parallelized across threads, minimizing idle cycles and synchronization overhead [39, 75].\\u003c/p\\u003e\\n\\u003cp\\u003eQuery workloads, by contrast, imposed considerably lighter computational demands, maintaining consistently low CPU usage across all concurrency levels (Fig. 7). This behavior reflects the architectural simplicity of read operations, which bypass consensus and endorsement pipelines, thereby reducing cryptographic and state validation overhead [45, 62]. Such efficiency highlights Fabric\\u0026rsquo;s suitability for high-frequency query-based applications, where low computational latency is essential for near\\u0026ndash;real-time analytics and dashboard services.\\u003c/p\\u003e\\n\\u003cp\\u003eMemory utilization remained modest and stable throughout all experimental conditions (Fig. 8(a) and 8(b)). Consumption increased gradually from approximately 8% with one worker to about 12% at twelve workers, demonstrating that Fabric\\u0026rsquo;s in-memory caching and ledger state management remain bounded and predictable even under increased transactional load. The low dispersion of memory metrics and the absence of outliers suggest that Fabric\\u0026rsquo;s memory footprint is determined primarily by ledger caching and database indexing rather than by concurrency or network complexity. These findings align with prior studies confirming that Fabric\\u0026rsquo;s memory management is optimized for containerized and cloud-native environments, where modular resource allocation is critical for scalability [62, 74, 80].\\u003c/p\\u003e\\n\\u003cp\\u003eOutgoing traffic increased proportionally with workload intensity, reaching several Gbps under peak load\\u003c/p\\u003e\\n\\u003cp\\u003eNetwork utilization metrics obtained through Grafana monitoring revealed stable and deterministic communication patterns across workloads. Outgoing traffic (Tx) increased proportionally with workload intensity, reaching several Gbps under peak load, indicating consistent broadcast behavior from peers and orderers during block propagation. Conversely, incoming traffic (Rx) remained nearly constant at approximately 192 Mbps across all configurations, reflecting the fixed size of inbound messages per peer within Fabric\\u0026rsquo;s communication protocol [81]. This pattern confirms the network\\u0026rsquo;s role as a predictable and non-saturating component of the overall system, ensuring that communication latency does not significantly affect performance outcomes.\\u003c/p\\u003e\\n\\u003cp\\u003eThe combined observations from Caliper results and Grafana dashboards as shown in the Grafana dashboard snapshots exhibited tightly clustered CPU, memory, and network usage distributions, with minimal variance across runs. This uniformity reinforces the conclusion that hardware and network subsystems operated far below saturation levels, and that the observed throughput plateau at approximately 400 TPS for write transactions was not a consequence of infrastructural limitations. Rather, it originated from software-level synchronization delays within the consensus mechanism. The empirical evidence, supported by prior benchmarking research [39, 45, 63, 74, 75], demonstrates that the system remained within safe operational thresholds throughout the experiments, with adequate capacity for scaling under optimized consensus configurations.\\u003c/p\\u003e\\n\\u003cp\\u003eCollectively, these findings confirm that Hyperledger Fabric\\u0026rsquo;s resource efficiency is well aligned with the demands of institutional blockchain deployments. The platform\\u0026rsquo;s stable CPU and memory profiles, combined with predictable network behavior, make it highly compatible with distributed, container-based environments where elasticity, resource predictability, and system observability are critical operational requirements.\\u003c/p\\u003e\\n\\u003ch2 id=\\\"_Toc214266840\\\"\\u003e\\u003cstrong\\u003e\\u003cstrong\\u003e5.4.\\u0026nbsp;\\u003c/strong\\u003eIntegrated Insights and Performance Bottlenecks\\u003c/strong\\u003e\\u003c/h2\\u003e\\n\\u003cp\\u003eAn integrated assessment of peer-to-peer throughput, latency, efficiency, and resource utilization demonstrates the dual scalability characteristics inherent in Hyperledger Fabric\\u0026rsquo;s architecture (Table 4). Read operations (\\u003cem\\u003eQuery\\u003c/em\\u003e) scaled linearly with near-constant latency and efficiency across all workloads, confirming high stability in non-consensus transactions. Write operations (\\u003cem\\u003ePropose\\u003c/em\\u003e), however, exhibited an early growth phase followed by a clear saturation point near 400 TPS, beyond which throughput plateaued and latency rose sharply. This divergence is a structural consequence of Fabric\\u0026rsquo;s modular execution and ordering model [45, 80].\\u003c/p\\u003e\\n\\u003cp\\u003eSystem-level monitoring corroborated that these constraints stem from Fabric\\u0026rsquo;s internal protocols rather than hardware limitations. CPU usage never exceeded 60%, memory consumption remained below 12%, and network throughput scaled linearly\\u0026mdash;evidence that the infrastructure had ample computational capacity. The bottleneck originated in the Raft ordering service, whose sequential batching introduced queueing delays when write requests exceeded its processing rate. Similar consensus-layer congestion has been documented in previous analyses of Fabric [82, 83].\\u003c/p\\u003e\\n\\u003cp\\u003eThese results confirm that Fabric\\u0026rsquo;s throughput ceiling and latency escalation are intrinsic to its endorsement and ordering workflow rather than resource constraints. Overcoming these limits therefore requires architectural refinements\\u0026mdash;not hardware expansion. Promising strategies include deploying multi-orderer clusters to parallelize consensus, running parallel Raft instances to distribute block formation tasks, and applying channel partitioning to isolate high-traffic transaction domains. Prior work shows that these interventions enhance throughput and responsiveness by reducing serialization overhead [42, 75].\\u003c/p\\u003e\\n\\u003cp\\u003eThe integrated Caliper\\u0026ndash;Grafana instrumentation validated that Fabric\\u0026rsquo;s performance boundaries are software-architectural in nature. Despite its throughput limits, the system exhibited consistent resource scaling, deterministic transaction ordering, and reproducible performance\\u0026mdash;properties essential for institutional blockchain applications demanding transparency, traceability, and auditability. These findings demonstrate Fabric\\u0026rsquo;s suitability for regulatory infrastructures such as AfCFTA\\u0026rsquo;s NQI network, provided that scalability is addressed through consensus parallelization and dynamic block-parameter tuning.\\u003c/p\\u003e\\n\\u003cp\\u003e\\u003cbr\\u003e\\u003c/p\\u003e\\n\\u003cp\\u003e\\u003cstrong\\u003eTable 4\\u003c/strong\\u003e Summary of Integrated Insights and Performance Bottlenecks\\u003c/p\\u003e\\n\\u003ctable border=\\\"0\\\" cellspacing=\\\"3\\\" cellpadding=\\\"0\\\" width=\\\"905\\\"\\u003e\\n \\u003cthead\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 81px;\\\"\\u003e\\n \\u003cp\\u003e\\u003cstrong\\u003eDimension\\u003c/strong\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 64px;\\\"\\u003e\\n \\u003cp\\u003e\\u003cstrong\\u003eMetric / Aspect\\u003c/strong\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 220px;\\\"\\u003e\\n \\u003cp\\u003e\\u003cstrong\\u003eObserved Behavior\\u003c/strong\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 170px;\\\"\\u003e\\n \\u003cp\\u003e\\u003cstrong\\u003eUnderlying Cause\\u003c/strong\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 183px;\\\"\\u003e\\n \\u003cp\\u003e\\u003cstrong\\u003eOptimization / Design Implication\\u003c/strong\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 174px;\\\"\\u003e\\n \\u003cp\\u003e\\u003cstrong\\u003eSupporting Literature\\u003c/strong\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003c/thead\\u003e\\n \\u003ctbody\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 81px;\\\"\\u003e\\n \\u003cp\\u003eThroughput \\u0026amp; Scalability\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 64px;\\\"\\u003e\\n \\u003cp\\u003eTransaction Throughput\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 220px;\\\"\\u003e\\n \\u003cp\\u003eWrite (Propose) saturates at ~400 TPS; Read (Query) scales linearly up to 800 TPS\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 170px;\\\"\\u003e\\n \\u003cp\\u003eRaft ordering and endorsement pipeline create serialization bottleneck\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 183px;\\\"\\u003e\\n \\u003cp\\u003eIntroduce multi-orderer clusters, channel partitioning, or dynamic block-size tuning to parallelize consensus\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 174px;\\\"\\u003e\\n \\u003cp\\u003e[15, 36, 45, 76, 77]\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 81px;\\\"\\u003e\\n \\u003cp\\u003eLatency Behavior\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 64px;\\\"\\u003e\\n \\u003cp\\u003eAverage Latency\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 220px;\\\"\\u003e\\n \\u003cp\\u003eWrite latency low (\\u0026lt;0.1 s) under 200 TPS but rises sharply to \\u0026gt;27 s at 800 TPS; Read latency stable at 0.008\\u0026ndash;0.015 s\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 170px;\\\"\\u003e\\n \\u003cp\\u003eQueuing and block formation delays in Raft ordering layer; Read bypasses consensus\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 183px;\\\"\\u003e\\n \\u003cp\\u003eOptimize batch timeout and block size; deploy adaptive consensus tuning for high-load conditions\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 174px;\\\"\\u003e\\n \\u003cp\\u003e[42, 76, 84\\u0026ndash;86]\\u0026nbsp;\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 81px;\\\"\\u003e\\n \\u003cp\\u003eTransaction Efficiency\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 64px;\\\"\\u003e\\n \\u003cp\\u003eSuccess Ratio\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 220px;\\\"\\u003e\\n \\u003cp\\u003eWrite efficiency drops from 97% (100 TPS) to ~50% (800 TPS); Read efficiency stable at ~100%\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 170px;\\\"\\u003e\\n \\u003cp\\u003eSaturation of consensus queue; endorsement contention under high concurrency\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 183px;\\\"\\u003e\\n \\u003cp\\u003eWorkload segregation\\u0026mdash;handle write and read workloads on separate channels\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 174px;\\\"\\u003e\\n \\u003cp\\u003e[40, 49, 76, 87]\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 81px;\\\"\\u003e\\n \\u003cp\\u003eResource Utilization\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 64px;\\\"\\u003e\\n \\u003cp\\u003eCPU \\u0026amp; Memory\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 220px;\\\"\\u003e\\n \\u003cp\\u003eCPU \\u0026lt; 60%; Memory \\u0026lt; 12%, even under peak loads\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 170px;\\\"\\u003e\\n \\u003cp\\u003eHardware not saturated; bottleneck purely architectural\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 183px;\\\"\\u003e\\n \\u003cp\\u003eFocus on software-level optimization rather than hardware scaling\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 174px;\\\"\\u003e\\n \\u003cp\\u003e[39, 39, 75, 79, 80]\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 81px;\\\"\\u003e\\n \\u003cp\\u003eNetwork Utilization\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 64px;\\\"\\u003e\\n \\u003cp\\u003eTx/Rx Traffic\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 220px;\\\"\\u003e\\n \\u003cp\\u003eOutgoing traffic scales linearly (~6 Gbps); inbound steady (~192 Mbps)\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 170px;\\\"\\u003e\\n \\u003cp\\u003eStable peer communication; non-congested network\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 183px;\\\"\\u003e\\n \\u003cp\\u003eConfirms network non-limiting for throughput; supports containerized, distributed deployments\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 174px;\\\"\\u003e\\n \\u003cp\\u003e[74, 81, 88]\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd style=\\\"width: 81px;\\\"\\u003e\\n \\u003cp\\u003eIntegrated Insight\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 64px;\\\"\\u003e\\n \\u003cp\\u003eOverall System Behavior\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 220px;\\\"\\u003e\\n \\u003cp\\u003eDual scalability: bounded write vs. linear read performance; stable resource footprint\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 170px;\\\"\\u003e\\n \\u003cp\\u003eConsensus serialization, not hardware limits\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd style=\\\"width: 183px;\\\"\\u003e\\n \\u003cp\\u003eHyperledger Fabric suitable for regulatory systems; requires architectural tuning for large-scale deployments\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" style=\\\"width: 174px;\\\"\\u003e\\n \\u003cp\\u003e[45, 63, 76, 89]\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003c/tbody\\u003e\\n\\u003c/table\\u003e\\n\\u003ch2\\u003e\\u003cstrong\\u003e5.5.\\u0026nbsp;\\u003c/strong\\u003e\\u003cstrong\\u003eDesign, Scalability, and Strategic Implications\\u003c/strong\\u003e\\u003c/h2\\u003e\\n\\u003cp\\u003eThe experimental results provide theoretical and practical insights into Fabric 2.5\\u0026rsquo;s scalability, highlighting its ability to balance data immutability with operational performance. Performance was found to be predominantly influenced by consensus latency once incoming transactions surpassed the ordering service\\u0026rsquo;s capacity. The observed saturation near 400 TPS for write-intensive workloads aligns with theoretical queuing-model predictions and prior empirical benchmarks of permissioned blockchains [14, 45, 76, 87]. Conversely, read-intensive transactions maintained consistently low latency and near-perfect efficiency, validating the platform\\u0026rsquo;s decoupled transaction model in which read and write paths operate independently [39, 47].\\u003c/p\\u003e\\n\\u003ch3\\u003e\\u003cstrong\\u003e5.5.1. Experimental Abstraction and Generalizability\\u003c/strong\\u003e\\u003c/h3\\u003e\\n\\u003cp\\u003eThe network modeled three generic organizations\\u0026mdash;NQI_Org1, NQI_Org2, and NQI_Org3\\u0026mdash;representing distinct NQI authorities rather than specific countries. This abstraction enhanced analytical rigor by eliminating contextual disparities while preserving the inter-organizational dynamics of AfCFTA\\u0026rsquo;s regulatory ecosystem. Although AfCFTA provides the contextual backdrop for the evaluation, the underlying framework is equally applicable to other regional free trade agreements that depend on coordinated NQI functions. The architecture is also scalable by design: additional peers or orderers can be incorporated linearly to simulate continent-wide participation, ensuring that the derived insights generalize to larger AfCFTA deployments.\\u003c/p\\u003e\\n\\u003ch3\\u003e\\u003cstrong\\u003e\\u003cstrong\\u003e5.5.2.\\u003c/strong\\u003eTheoretical and Analytical Perspectives\\u003c/strong\\u003e\\u003c/h3\\u003e\\n\\u003cp\\u003eFrom a theoretical standpoint, the results reinforce the principle of modularity in blockchain systems: performance ceilings arise not from computational or network limits but from the serialization inherent in consensus and block formation. The strong correlation between the observed throughput plateau and modeled queuing thresholds provides empirical confirmation of Fabric\\u0026rsquo;s bounded throughput property [45, 76]. This dual behavior\\u0026mdash;bounded write scalability versus linear read scalability\\u0026mdash;substantiates that Fabric\\u0026rsquo;s pipeline consists of semi-independent execution paths, enabling deterministic and predictable system behavior under diverse loads.\\u003c/p\\u003e\\n\\u003ch3\\u003e\\u003cstrong\\u003e\\u003cstrong\\u003e5.5.3.\\u0026nbsp;\\u003c/strong\\u003ePractical Implications for Institutional Deployment\\u0026nbsp;\\u003c/strong\\u003e\\u003c/h3\\u003e\\n\\u003cp\\u003eFor institutions implementing permissioned blockchains in regulatory or quality-infrastructure domains, three principal implications emerge:\\u003c/p\\u003e\\n\\u003col start=\\\"1\\\" type=\\\"1\\\"\\u003e\\n \\u003cli\\u003eWorkload Segregation as a Design Principle. Separating Propose (write) transactions\\u0026mdash;requiring endorsement and ordering\\u0026mdash;from Query (read) operations\\u0026mdash;executed at peer level\\u0026mdash;minimizes contention between transaction finality and data accessibility. This division mirrors operational roles within NQI systems and aligns with prior recommendations for task-specific blockchain partitioning to improve responsiveness [39, 49, 77].\\u003c/li\\u003e\\n \\u003cli\\u003eParameter Tuning over Hardware Scaling. Because system resources remained below saturation, meaningful throughput improvements can be achieved through tuning rather than hardware upgrades. Adjusting parameters such as batch timeout, block size, and endorsement policies can optimize throughput\\u0026ndash;latency trade-offs, a strategy supported by empirical studies showing up to 40% performance gains in Fabric-based deployments [40, 75, 77, 89].\\u003c/li\\u003e\\n \\u003cli\\u003eCloud-Native Suitability and Resource Efficiency. Fabric\\u0026rsquo;s modest resource footprint\\u0026mdash;memory usage below 12% and low CPU intensity\\u0026mdash;demonstrates its compatibility with containerized and cloud-native infrastructures. Its modular architecture supports elastic scaling, allowing institutions to expand or contract resources dynamically in line with transaction volumes, a crucial feature for distributed regulatory systems operating across multiple jurisdictions [79, 90].\\u003c/li\\u003e\\n\\u003c/ol\\u003e\\n\\u003ch3\\u003e\\u003cstrong\\u003e\\u003cstrong\\u003e5.5.4.\\u003c/strong\\u003eStrategic Scalability Roadmap\\u003c/strong\\u003e\\u003c/h3\\u003e\\n\\u003cp\\u003eThe experimental findings outline a roadmap for achieving balanced hybrid scalability in Fabric-based ecosystems. Read-oriented applications\\u0026mdash;such as certification registries, auditing dashboards, and compliance portals\\u0026mdash;can scale horizontally with minimal modification, leveraging peer-level state caching and query parallelism. This read-scalability supports not only AfCFTA-aligned operations but can also extend to other regional free trade agreements that depend on coordinated NQI processes, enabling broader institutional stakeholders\\u0026mdash;such as the AU, WTO, WCO, research institutions, and sectoral regulatory bodies\\u0026mdash;to access or analyze non-sensitive quality-infrastructure data without imposing additional load on the core network.\\u003c/p\\u003e\\n\\u003cp\\u003eWrite-intensive processes, including accreditation or regulatory submissions, require architectural reconfiguration to mitigate ordering bottlenecks. Multi-orderer clusters and multi-channel partitioning can parallelize consensus operations and isolate high-frequency domains, while dynamic Raft-parameter tuning (e.g., block size and timeout) enables adaptive optimization under variable loads [62, 76, 77].\\u003c/p\\u003e\\n\\u003cp\\u003eCollectively, these strategies allow institutions to harmonize throughput, latency, and reliability without compromising Fabric\\u0026rsquo;s guarantees of data integrity and auditability. By integrating architectural tuning with modular deployment, Hyperledger Fabric can evolve from an enterprise blockchain platform into a foundational digital infrastructure supporting governance, standardization, and regulatory cooperation within the AfCFTA and its broader ecosystem partners[89].\\u0026nbsp;\\u003c/p\\u003e\\n\\u003ch3\\u003e\\u003cstrong\\u003e\\u003cstrong\\u003e5.5.5.\\u0026nbsp;\\u003c/strong\\u003eInstitutional and Policy Significance\\u003c/strong\\u003e\\u003c/h3\\u003e\\n\\u003cp\\u003eBeyond technical implications, the findings offer strategic value for AfCFTA\\u0026rsquo;s digital transformation agenda. The demonstrated performance characteristics establish a replicable foundation for deploying cross-border quality-infrastructure systems that demand both transparency and scalability. Fabric\\u0026rsquo;s predictable performance and strong governance control make it a viable substrate for digital conformity assessment, standards harmonization, and accreditation tracking across member states.\\u003c/p\\u003e\\n\\u003cp\\u003eMoreover, the architectural insights contribute to the broader discourse on blockchain-enabled regulatory interoperability, showing how digital infrastructures can operationalize institutional trust without central intermediaries. As such, the study bridges the gap between performance benchmarking and policy design, offering empirical guidance for scaling decentralized regulatory frameworks in emerging continental trade systems.\\u0026nbsp;\\u003c/p\\u003e\"},{\"header\":\"6.\\tConclusions \",\"content\":\"\\u003cp\\u003eThis study presented the design and empirical evaluation of a peer-to-peer, permissioned distributed ledger architecture based on Hyperledger Fabric to support National Quality Infrastructure (NQI) coordination in cross-border trade under regional Free Trade Agreements (FTAs). Using the African Continental Free Trade Area (AfCFTA) as an illustrative regulatory context, the paper demonstrated how AfCFTA-aligned regulatory workflows\\u0026mdash;such as standards submission and endorsement, accreditation recording, and certificate verification\\u0026mdash;can be explicitly modeled as peer-to-peer, consensus-governed business transactions and operationalized through smart contracts.\\u003c/p\\u003e\\n\\u003cp\\u003eThe proposed system design defined a consortium-based network in which NQI institutions interact through well-specified write-intensive and read-only smart contract classes, reflecting the institutional logic of regulatory decision-making and compliance verification. This design rationale directly informed the experimental methodology. A controlled testbed comprising three peer organizations and a single Raft-based ordering service was implemented to emulate a minimal but representative regulatory consortium. Performance evaluation was conducted using Hyperledger Caliper and system-level monitoring via Grafana\\u0026ndash;Prometheus under varying transaction loads and concurrency levels. This design\\u0026ndash;evaluation alignment enabled a direct examination of how peer-to-peer execution paths, endorsement dependencies, and ordering constraints shape system-level performance under institutional workloads.\\u003c/p\\u003e\\n\\u003cp\\u003eThe evaluation revealed distinct performance characteristics aligned with the system design. Write-intensive regulatory submission transactions saturated at approximately 400 TPS, reflecting bounded throughput in consensus-serialized peer-to-peer workflows inherent to Fabric\\u0026rsquo;s execution\\u0026ndash;ordering\\u0026ndash;validation model. In contrast, read-only verification and audit transactions exhibited near-linear scalability with sub-15 ms latency, benefiting from Fabric\\u0026rsquo;s consensus-free query execution at peer nodes. Resource utilization remained modest across all experiments, indicating that observed performance limits were intrinsic to the peer-to-peer ordering and endorsement architecture rather than hardware constraints. Together, these results validate the proposed design choices and confirm Hyperledger Fabric\\u0026rsquo;s suitability for compliance-driven, multi-institutional regulatory systems that require deterministic trust, traceability, and auditability.\\u003c/p\\u003e\\n\\u003cp\\u003eAlthough AfCFTA served as the illustrative use case, the architectural principles and transaction abstractions developed in this study are transferable to other FTAs that rely on interoperable NQI coordination. The framework therefore provides a foundational reference model for digitally enabled regulatory cooperation across diverse cross-border trade environments. As such, the proposed architecture and findings contribute not only to blockchain-enabled trade facilitation but also to the broader study of scalable peer-to-peer systems for regulated multi-organizational environments.\\u003c/p\\u003e\\n\\u003ch3 id=\\\"_Toc214266843\\\"\\u003e\\u003cstrong\\u003e6.1.1. Limitations\\u003c/strong\\u003e\\u003cstrong\\u003e\\u0026nbsp;and Future Research Directions\\u003c/strong\\u003e\\u003c/h3\\u003e\\n\\u003cp\\u003eDespite its contributions, this study has several limitations that frame opportunities for future research. First, the three-organization network topology was selected to ensure experimental clarity and reproducibility; however, it does not fully reflect the institutional diversity and infrastructural heterogeneity of large-scale regional trade ecosystems. While the observed performance trends are expected to scale qualitatively, peer-to-peer coordination overheads and consensus dynamics may evolve nonlinearly as network size and heterogeneity increase. Second, the experimental environment did not model adverse network conditions, dynamic membership changes, or fault scenarios that may affect consensus behavior in real-world regulatory settings.\\u003c/p\\u003e\\n\\u003cp\\u003eFrom a design perspective, the implemented smart contracts captured core NQI transaction patterns but did not encode the full procedural complexity of regulatory workflows, such as hierarchical approvals, document lifecycle management, or sector-specific compliance rules. In addition, several architectural optimization strategies\\u0026mdash;such as multi-orderer clustering, multi-channel partitioning, and adaptive consensus tuning\\u0026mdash;were identified but not empirically evaluated within the scope of this study. Evaluating how richer regulatory semantics interact with endorsement policies and ordering latency therefore remains an open systems-level research challenge.\\u003c/p\\u003e\\n\\u003cp\\u003eFuture research should expand both the system design and evaluation dimensions. Larger and more heterogeneous network topologies should be tested to assess scalability under realistic cross-border conditions, including multi-orderer and multi-channel configurations. Comparative evaluations with other permissioned distributed ledger platforms could further clarify architectural trade-offs among peer-to-peer consensus models. Finally, domain-enriched smart contracts that formalize NQI-specific semantics\\u0026mdash;such as mutual recognition rules, certificate validity constraints, and audit traceability\\u0026mdash;would advance the development of resilient, policy-aligned digital infrastructures for AfCFTA and similar regional trade frameworks. Collectively, these extensions would advance the design of peer-to-peer regulatory infrastructures that combine deterministic governance, scalable performance, and institutional trust across regional and global trade systems.\\u003c/p\\u003e\"},{\"header\":\"Declarations\",\"content\":\"\\u003cp\\u003e\\u003cstrong\\u003eAuthor Contributions\\u003c/strong\\u003e \\u003cem\\u003e•\\u0026nbsp;\\u003c/em\\u003eAyele Legesse: Study conception and design, Data collection, Analysis and interpretation of results, Draft manuscript preparation. \\u003cem\\u003e•\\u0026nbsp;\\u003c/em\\u003eBirhanu Beshah: Study conception, analysis and interpretation of results, verification of results, final editing and approval of the manuscript and work supervision. \\u003cem\\u003e•\\u0026nbsp;\\u003c/em\\u003eErmias Tefaye: Study conception, analysis and interpretation of results, verification of results, and work supervision. \\u003cem\\u003e•\\u0026nbsp;\\u003c/em\\u003eYalew Kidane: Study conception, analysis and interpretation of results, verification of results.\\u003c/p\\u003e\\n\\u003cp\\u003e\\u003cstrong\\u003eFunding\\u0026nbsp;\\u003c/strong\\u003eNo funding was received for conducting this research\\u003c/p\\u003e\\n\\u003cp\\u003e\\u003cstrong\\u003eData Availability\\u0026nbsp;\\u003c/strong\\u003eThe data that support the findings of this study are available from the corresponding author upon reasonable request.\\u003c/p\\u003e\\n\\u003cp\\u003e\\u003cstrong\\u003eResearch Involving Human Participants and/or Animals\\u0026nbsp;\\u003c/strong\\u003eNot applicable\\u003c/p\\u003e\\n\\u003cp\\u003e\\u003cstrong\\u003eEthics approval\\u003c/strong\\u003e Not applicable.\\u003c/p\\u003e\\n\\u003cp\\u003e\\u003cstrong\\u003eConsent to publish\\u003c/strong\\u003e Not applicable.\\u003c/p\\u003e\\n\\u003cp\\u003e\\u003cstrong\\u003eCompeting Interests\\u003c/strong\\u003e The authors declare no competing interests.\\u003c/p\\u003e\"},{\"header\":\"References\",\"content\":\"\\u003col\\u003e\\n\\u003cli\\u003eAlotaibi EM, Issa H, Codesso M (2025) Blockchain-based conceptual model for enhanced transparency in government records: a design science research approach. International Journal of Information Management Data Insights 5:100304. https://doi.org/10.1016/j.jjimei.2024.100304\\u003c/li\\u003e\\n\\u003cli\\u003eSaari A, Sinclair S, Leshinsky R, Junnila S (2025) Best practices for blockchain-driven digital transformation in cross-industry settings. Digital Business 5:100127. https://doi.org/10.1016/j.digbus.2025.100127\\u003c/li\\u003e\\n\\u003cli\\u003eBrusset X, Kinra A, Naseraldin H, Alkhudary R (2024) Increasing willingness to pay in the food supply chain: a blockchain-oriented trust approach. International Journal of Production Research 62:8858\\u0026ndash;8879. https://doi.org/10.1080/00207543.2024.2352763\\u003c/li\\u003e\\n\\u003cli\\u003eHuubse M (2010) Blockchain Strategies to Enhance Transparency, Efficiency, and Governance for Public-Private Partnership Leaders\\u003c/li\\u003e\\n\\u003cli\\u003eAU (2025) The African Continental Free Trade Area. African Union\\u003c/li\\u003e\\n\\u003cli\\u003eEAC (2025). East African Community\\u003c/li\\u003e\\n\\u003cli\\u003etralac (2025) Continental Free Trade Area\\u003c/li\\u003e\\n\\u003cli\\u003eMlambo VH, Thusi X, Zubane SP, Mlambo DN (2022) The African Continental Free Trade Area: Challenges and Possible Successes\\u003c/li\\u003e\\n\\u003cli\\u003eRacine, Jean-Louis, Tippmann, Christina (2013) The national quality infrastructure : tool for competitiveness, trade, and social well-being (English). World Bank Group, Washington, DC\\u003c/li\\u003e\\n\\u003cli\\u003eUNCTAD Support to the African Continental Free Trade Area. United Nations Trade and Development\\u003c/li\\u003e\\n\\u003cli\\u003eAllena M (2021) Blockchain Technology and Regulatory Compliance: Towards a Cooperative Supervisory Model\\u003c/li\\u003e\\n\\u003cli\\u003eZafar A (2025) Reconciling blockchain technology and data protection laws: regulatory challenges, technical solutions, and practical pathways. Journal of Cybersecurity 11:tyaf002. https://doi.org/10.1093/cybsec/tyaf002\\u003c/li\\u003e\\n\\u003cli\\u003eLi K, Lee J-Y, Gharehgozli A (2023) Blockchain in food supply chains: a literature review and synthesis analysis of platforms, benefits and challenges. International Journal of Production Research 61:3527\\u0026ndash;3546. https://doi.org/10.1080/00207543.2021.1970849\\u003c/li\\u003e\\n\\u003cli\\u003ePatil PB, Sangeetha M (2024) A Comprehensive Performance Analysis of a Hyperledger Fabric-powered Blockchain Network for Cross-Border Fund Transfers. Procedia Computer Science 233:723\\u0026ndash;732. https://doi.org/10.1016/j.procs.2024.03.261\\u003c/li\\u003e\\n\\u003cli\\u003eThakkar P, Nathan S, Viswanathan B (2018) Performance Benchmarking and Optimizing Hyperledger Fabric Blockchain Platform. In: 2018 IEEE 26th International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems (MASCOTS). IEEE, Milwaukee, WI, pp 264\\u0026ndash;276\\u003c/li\\u003e\\n\\u003cli\\u003eDreyer J, Fischer M, T\\u0026ouml;njes R (2020) Performance analysis of hyperledger fabric 2.0 blockchain platform. In: Proceedings of the Workshop on Cloud Continuum Services for Smart IoT Systems. ACM, Virtual Event Japan, pp 32\\u0026ndash;38\\u003c/li\\u003e\\n\\u003cli\\u003eNaseem S, Yong T (2025) Blockchain-Based Risk Management in Cross-Border Data Supply Chains: A Comparative Analysis of Alibaba and Infosys. Sustainability 17:7704. https://doi.org/10.3390/su17177704\\u003c/li\\u003e\\n\\u003cli\\u003eXiao S, Qin X, Tian Y, Dang Z (2025) Blockchain-Based Framework for Secure Sharing of Cross-Border Trade Data. CMC 83:2351\\u0026ndash;2373. https://doi.org/10.32604/cmc.2025.062324\\u003c/li\\u003e\\n\\u003cli\\u003eLegesse A, Beshah B, Berhan E, Tesfaye E (2024) Exploring the influencing factors of blockchain technology adoption in national quality infrastructure: a Dual-Stage structural equation model and artificial neural network approach using TAM-TOE framework. Cogent Engineering 11:2369220. https://doi.org/10.1080/23311916.2024.2369220\\u003c/li\\u003e\\n\\u003cli\\u003eAdeyinka Ogunbajo, Adefemi Quddus Abidola, Itunu Taiwo, et al (2025) How blockchain-enabled smart contracts and artificial intelligence are reshaping corporate governance frameworks in fintech and logistics industries. World J Adv Res Rev 25:050\\u0026ndash;059. https://doi.org/10.30574/wjarr.2025.25.2.0333\\u003c/li\\u003e\\n\\u003cli\\u003eAmen S (2024) Assessment of Consensus Algorithms for Blockchain Technology to Enhance Decentralized Applications. J Basrah Res (Sci) 50:267\\u0026ndash;280. https://doi.org/10.56714/bjrs.50.2.23\\u003c/li\\u003e\\n\\u003cli\\u003eSingh HP, Alshammari TS (2020) An Institutional Theory Perspective on Developing a Cyber Security Legal Framework: A Case of Saudi Arabia. BLR 11:637\\u0026ndash;650. https://doi.org/10.4236/blr.2020.113039\\u003c/li\\u003e\\n\\u003cli\\u003eAl Salih A, Wang Y (2024) Pluggable Consensus in Hyperledger Fabric. In: Proceedings of the 2024 6th Blockchain and Internet of Things Conference. ACM, Fukuoka Japan, pp 92\\u0026ndash;100\\u003c/li\\u003e\\n\\u003cli\\u003eCasino F, Dasaklis TK, Patsakis C (2019) A systematic literature review of blockchain-based applications: Current status, classification and open issues. Telematics and Informatics 36:55\\u0026ndash;81. https://doi.org/10.1016/j.tele.2018.11.006\\u003c/li\\u003e\\n\\u003cli\\u003eGu Y, Chen D, Long Y (2026) BesCo: Blockchain-enabled secure collaboration framework for multi-inspection agency integration. Peer-to-Peer Netw Appl 19:14. https://doi.org/10.1007/s12083-025-02160-z\\u003c/li\\u003e\\n\\u003cli\\u003eMachado EG, Gomes RTR, Martins EVA, et al (2023) Blockchain network to conformity assessment bodies\\u003c/li\\u003e\\n\\u003cli\\u003eMoni M, Melo W, Peters D, Machado R (2021) When Measurements Meet Blockchain: On Behalf of an Inter-NMI Network. Sensors 21:1564. https://doi.org/10.3390/s21051564\\u003c/li\\u003e\\n\\u003cli\\u003eRani P, Sharma P, Gupta I, Gaba P (2025) STP: a permissioned blockchain solution for dynamic pricing and traceability in food supply chain. Peer-to-Peer Netw Appl 18:224. https://doi.org/10.1007/s12083-025-02060-2\\u003c/li\\u003e\\n\\u003cli\\u003eUNIDO Advancing Conformity Assessment for the New Digital Age. United Nations Industrial Development Organization\\u003c/li\\u003e\\n\\u003cli\\u003eDe Souza Melo Junior W (2021) Blockchains and legal metrology: applications and possibilities. https://doi.org/10.13140/RG.2.2.16861.95208\\u003c/li\\u003e\\n\\u003cli\\u003eMelo WS, Bessani A, Neves N, et al (2019) Using Blockchains to Implement Distributed Measuring Systems. IEEE Trans Instrum Meas 68:1503\\u0026ndash;1514. https://doi.org/10.1109/TIM.2019.2898013\\u003c/li\\u003e\\n\\u003cli\\u003eKumar N, Kumar K, Aeron A, Verre F (2025) Blockchain technology in supply chain management: Innovations, applications, and challenges. Telematics and Informatics Reports 18:100204. https://doi.org/10.1016/j.teler.2025.100204\\u003c/li\\u003e\\n\\u003cli\\u003eLiu G, Zhao Y, Zhou S, Shao X (2025) Blockchain development in a supply chain with rival entry. International Journal of Production Research 63:5122\\u0026ndash;5141. https://doi.org/10.1080/00207543.2024.2374835\\u003c/li\\u003e\\n\\u003cli\\u003eBenchis MP, Shahzad K, Dan S (2025) Comparative analysis of blockchain adoption in the public and private sectors. A technology-organization-environment (TOE) framework approach. Journal of Innovation \\u0026amp; Knowledge 10:100746. https://doi.org/10.1016/j.jik.2025.100746\\u003c/li\\u003e\\n\\u003cli\\u003eUyar H, Papanikolaou A, Kapassa E, et al (2025) Blockchain-enabled traceability and certification for frozen food supply chains: A conceptual design. Smart Agricultural Technology 12:101085. https://doi.org/10.1016/j.atech.2025.101085\\u003c/li\\u003e\\n\\u003cli\\u003eAndroulaki E, Barger A, Bortnikov V, et al (2018) Hyperledger fabric: a distributed operating system for permissioned blockchains. In: Proceedings of the Thirteenth EuroSys Conference. ACM, Porto Portugal, pp 1\\u0026ndash;15\\u003c/li\\u003e\\n\\u003cli\\u003eJagadeesh Sai, Shivanand Patil, Karthikesh (2025) Permissioned Blockchain Identity and Access Management System using Hyperledger Fabric. https://doi.org/10.13140/RG.2.2.14607.91044\\u003c/li\\u003e\\n\\u003cli\\u003eKaushal RK, Kumar N, Kukreja V, Boonchieng E (2025) Hyperledger fabric based remote patient monitoring solution and performance evaluation. Peer-to-Peer Netw Appl 18:105. https://doi.org/10.1007/s12083-025-01921-0\\u003c/li\\u003e\\n\\u003cli\\u003eZulkarnain MM, Ramli N, Nordin AN (2025) Performance Benchmarking of Hyperledger Fabric on Heterogeneous Hardware for IoT Applications. IIUMEJ 26:156\\u0026ndash;170. https://doi.org/10.31436/iiumej.v26i3.3610\\u003c/li\\u003e\\n\\u003cli\\u003eSukhwani H, Wang N, Trivedi KS, Rindos A (2018) Performance Modeling of Hyperledger Fabric (Permissioned Blockchain Network). In: 2018 IEEE 17th International Symposium on Network Computing and Applications (NCA). IEEE, Cambridge, MA, pp 1\\u0026ndash;8\\u003c/li\\u003e\\n\\u003cli\\u003eKhan D, Jung LT, Hashmani MA, Cheong MK (2022) Empirical Performance Analysis of Hyperledger LTS for Small and Medium Enterprises. Sensors 22:915. https://doi.org/10.3390/s22030915\\u003c/li\\u003e\\n\\u003cli\\u003eMelo C, Gon\\u0026ccedil;alves G, Silva FA, Soares A (2024) Performance Modeling and Evaluation of Hyperledger Fabric: An Analysis Based on Transaction Flow and Endorsement Policies. In: 2024 IEEE Symposium on Computers and Communications (ISCC). pp 1\\u0026ndash;6\\u003c/li\\u003e\\n\\u003cli\\u003eLau CW, Liu J, Ma X, Talluri S (2025) Performance analysis of a blockchain-based messaging system implementation for air cargo supply chains. International Journal of Production Research 63:5428\\u0026ndash;5451. https://doi.org/10.1080/00207543.2024.2407903\\u003c/li\\u003e\\n\\u003cli\\u003eKhan AA, Alsufyani A, Alsufyani N, Mohamed MA (2025) BAML: a decentralized approach to secure, privacy-preserving financial compliance for enhancing anti-money laundering with blockchain hyperledger and federated learning. Peer-to-Peer Netw Appl 18:270. https://doi.org/10.1007/s12083-025-02086-6\\u003c/li\\u003e\\n\\u003cli\\u003eGuggenberger T, Sedlmeir J, Fridgen G, Luckow A (2022) An in-depth investigation of the performance characteristics of Hyperledger Fabric. Computers \\u0026amp; Industrial Engineering 173:108716. https://doi.org/10.1016/j.cie.2022.108716\\u003c/li\\u003e\\n\\u003cli\\u003eAgrawal TK, Angelis J, Khilji WA, et al (2023) Demonstration of a blockchain-based framework using smart contracts for supply chain collaboration. International Journal of Production Research 61:1497\\u0026ndash;1516. https://doi.org/10.1080/00207543.2022.2039413\\u003c/li\\u003e\\n\\u003cli\\u003eEnare Abang J, Takruri H, Al-Zaidi R, Al-Khalidi M (2024) Latency performance modelling in hyperledger fabric blockchain: Challenges and directions with an IoT perspective. Internet of Things 26:101217. https://doi.org/10.1016/j.iot.2024.101217\\u003c/li\\u003e\\n\\u003cli\\u003eKellaf T (2024) Blockchain in trade finance: The Good, the Bad and the Verdict. MF 2:136\\u0026ndash;160. https://doi.org/10.61351/mf.v2i2.206\\u003c/li\\u003e\\n\\u003cli\\u003eThakur A, Ranga V, Agarwal R (2024) Workload dynamics implications in permissioned blockchain scalability and performance. Cluster Comput 27:11569\\u0026ndash;11593. https://doi.org/10.1007/s10586-024-04550-z\\u003c/li\\u003e\\n\\u003cli\\u003ePalit SK, Chakraborty M, Chakraborty S (2025) Design, formal verification, and security analysis of SCMChain: A lightweight blockchain-based authentication protocol for IoT-enabled supply chain management. Peer-to-Peer Netw Appl 18:298. https://doi.org/10.1007/s12083-025-02141-2\\u003c/li\\u003e\\n\\u003cli\\u003eJurgelaitis M, Čeponienė L, Butkus K, et al (2022) MDA-Based Approach for Blockchain Smart Contract Development. Applied Sciences 13:487. https://doi.org/10.3390/app13010487\\u003c/li\\u003e\\n\\u003cli\\u003eDuke A What Does the CISG Have to Say About Smart Contracts? A Legal Analysis\\u003c/li\\u003e\\n\\u003cli\\u003eTippmann C (2013) The National Quality Infrastructure. World Bank\\u003c/li\\u003e\\n\\u003cli\\u003eVereinte Nationen (2023) The basics of quality infrastructure for trade. United Nations, Geneva\\u003c/li\\u003e\\n\\u003cli\\u003eWorld Bank, UNIDO (2014) Conformity Assessment Builds Trust by Mixing Benefits and Minimizing Barriers. The Naional Quality Infrastructure Project for Nigeria\\u003c/li\\u003e\\n\\u003cli\\u003eAPRI (2023) The Road to Africa\\u0026rsquo;s Single Market: Progress so far and challenges for the future. Africa Policy Research Institute, Berlin, Germany\\u003c/li\\u003e\\n\\u003cli\\u003eBudoo B (2023) Towards free, fair and safe trade in Africa: Setting up an African continental technical regulatory framework (ACTReF) \\u0026ndash; Concept paper\\u003c/li\\u003e\\n\\u003cli\\u003eKarangizi S (2023) Ad Hoc Expert Group Meeting on: \\u0026ldquo;Accelerating the implementation of the AfCFTA in Southern Africa building on the acquis of the RECs FTA.\\u0026rdquo; United Nations Economic Commission for Africa, Gaborone, Botswana\\u003c/li\\u003e\\n\\u003cli\\u003eAl-Sumaidaee G, Alkhudary R, Zilic Z, Swidan A (2023) Performance analysis of a private blockchain network built on Hyperledger Fabric for healthcare. Information Processing \\u0026amp; Management 60:103160. https://doi.org/10.1016/j.ipm.2022.103160\\u003c/li\\u003e\\n\\u003cli\\u003eFan C, Ghaemi S, Khazaei H, Musilek P (2020) Performance Evaluation of Blockchain Systems: A Systematic Survey. IEEE Access 8:126927\\u0026ndash;126950. https://doi.org/10.1109/ACCESS.2020.3006078\\u003c/li\\u003e\\n\\u003cli\\u003eNasir Q, Qasse IA, Abu Talib M, Nassif AB (2018) Performance Analysis of Hyperledger Fabric Platforms. Security and Communication Networks 2018:1\\u0026ndash;14. https://doi.org/10.1155/2018/3976093\\u003c/li\\u003e\\n\\u003cli\\u003eHyperledger Fabric Documentation (2025) Read and write operations\\u003c/li\\u003e\\n\\u003cli\\u003eKaushal RK, Kumar N (2024) Exploring Hyperledger Caliper Benchmarking Tool to Measure the Performance of Blockchain Based Solutions. In: 2024 11th International Conference on Reliability, Infocom Technologies and Optimization (Trends and Future Directions) (ICRITO). IEEE, Noida, India, pp 1\\u0026ndash;6\\u003c/li\\u003e\\n\\u003cli\\u003eOlivieri L, Negrini L, Arceri V, et al (2025) Detection of Read-Write Issues in Hyperledger Fabric Smart Contracts. In: Proceedings of the 40th ACM/SIGAPP Symposium on Applied Computing. ACM, Catania International Airport Catania Italy, pp 329\\u0026ndash;337\\u003c/li\\u003e\\n\\u003cli\\u003eBattisti JHF, Batista VE, Koslovski GP, et al (2023) Performance analysis of the Raft consensus algorithm on Hyperledger Fabric and Ethereum on cloud. In: 2023 IEEE International Conference on Cloud Computing Technology and Science (CloudCom). IEEE, Naples, Italy, pp 155\\u0026ndash;160\\u003c/li\\u003e\\n\\u003cli\\u003eIftekhar A, Cui X, Tao Q, Zheng C (2021) Hyperledger Fabric Access Control System for Internet of Things Layer in Blockchain-Based Applications. Entropy 23:1054. https://doi.org/10.3390/e23081054\\u003c/li\\u003e\\n\\u003cli\\u003eMa C, Kong X, Lan Q, Zhou Z (2019) The privacy protection mechanism of Hyperledger Fabric and its application in supply chain finance. Cybersecur 2:5. https://doi.org/10.1186/s42400-019-0022-2\\u003c/li\\u003e\\n\\u003cli\\u003eKeo R, Firdaus M, Rhee K (2024) A Secure Rubber Supply Chain Management System Based on Hyperledger Fabric Blockchain: A Use Case in Cambodia\\u003c/li\\u003e\\n\\u003cli\\u003eDharani J, Sundarakantham K, Kunwar Singh, Mercy Shalinie S (2022) A Privacy-Preserving Framework for Endorsement Process in Hyperledger Fabric. Computers \\u0026amp; Security. https://doi.org/10.1016/j.cose.2022.102637\\u003c/li\\u003e\\n\\u003cli\\u003eZappoli R (2022) Go Language Support in Hyperledger Fabric Private Chaincode\\u003c/li\\u003e\\n\\u003cli\\u003eCoding Bootcamps (2023) How to monitor Hyperledger Fabric application\\u003c/li\\u003e\\n\\u003cli\\u003eJagtap C (2022) Monitoring Fabric network using Grafana and Prometheus\\u003c/li\\u003e\\n\\u003cli\\u003eLinux Foundation (2021) Case study: Hyperledger Foundation\\u003c/li\\u003e\\n\\u003cli\\u003eLF Decentralized Trust (2023) Benchmarking Hyperledger Fabric 2.5 performance\\u003c/li\\u003e\\n\\u003cli\\u003eBaliga A, Solanki N, Verekar S, et al (2018) Performance Characterization of Hyperledger Fabric. In: 2018 Crypto Valley Conference on Blockchain Technology (CVCBT). IEEE, Zug, pp 65\\u0026ndash;74\\u003c/li\\u003e\\n\\u003cli\\u003eDas SR, Jhanjhi N, Asirvatham D, et al Empirical Performance Analysis of Hyperledger Fabric Blockchain Network for Healthcare\\u003c/li\\u003e\\n\\u003cli\\u003eJavaid H, Hu C, Brebner G (2019) Optimizing Validation Phase of Hyperledger Fabric. In: 2019 IEEE 27th International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems (MASCOTS). IEEE, Rennes, FR, pp 269\\u0026ndash;275\\u003c/li\\u003e\\n\\u003cli\\u003eWang C, Chu X (2020) Performance Characterization and Bottleneck Analysis of Hyperledger Fabric. In: 2020 IEEE 40th International Conference on Distributed Computing Systems (ICDCS). pp 1281\\u0026ndash;1286\\u003c/li\\u003e\\n\\u003cli\\u003eMelo C, Gon\\u0026ccedil;alves G, Silva FA, et al (2024) Optimal Resource Utilization in Hyperledger Fabric: A Comprehensive SPN-Based Performance Evaluation Paradigm. In: NOMS 2024-2024 IEEE Network Operations and Management Symposium. IEEE, Seoul, Korea, Republic of, pp 1\\u0026ndash;7\\u003c/li\\u003e\\n\\u003cli\\u003eGorenflo C, Lee S, Golab L, Keshav S (2019) FastFabric: Scaling Hyperledger Fabric to 20,000 Transactions per Second. In: 2019 IEEE International Conference on Blockchain and Cryptocurrency (ICBC). IEEE, Seoul, Korea (South), pp 455\\u0026ndash;463\\u003c/li\\u003e\\n\\u003cli\\u003eGrafana Labs HLF SmartBFT dashboard\\u003c/li\\u003e\\n\\u003cli\\u003eJangid DP, Badhe DNB, Giri DN, et al (2025) COMPARATIVE ANALYSIS OF HYPERLEDGER FABRIC PERFORMANCE ACROSS VARIOUS ORDERING SERVICES. International Journal of Applied Mathematics 38:\\u003c/li\\u003e\\n\\u003cli\\u003eMelo C, Gon\\u0026ccedil;alves G, Silva FA, Soares A (2024) A comprehensive hyperledger fabric performance evaluation based on resources capacity planning. Cluster Comput 27:12395\\u0026ndash;12410. https://doi.org/10.1007/s10586-024-04591-4\\u003c/li\\u003e\\n\\u003cli\\u003eGutierrez R, Villegas-Ch W, Govea J (2025) Adaptive consensus optimization in blockchain using reinforcement learning and validation in adversarial environments. Front Artif Intell 8:1672273. https://doi.org/10.3389/frai.2025.1672273\\u003c/li\\u003e\\n\\u003cli\\u003eRizal S, Kim D-S (2025) Enhancing Blockchain Consensus Mechanisms: A Comprehensive Survey on Machine Learning Applications and Optimizations. Blockchain: Research and Applications 100302. https://doi.org/10.1016/j.bcra.2025.100302\\u003c/li\\u003e\\n\\u003cli\\u003eZidi I, Zaghdoud R, El Khediri S (2026) Optimizing block size and cloud storage in blockchain technology using an NSGA-III and SVM hybrid approach. Peer-to-Peer Netw Appl 19:5. https://doi.org/10.1007/s12083-025-02145-y\\u003c/li\\u003e\\n\\u003cli\\u003eXu X, Sun G, Luo L, et al (2021) Latency performance modeling and analysis for Hyperledger Fabric blockchain network. Information Processing \\u0026amp; Management 58:. https://doi.org/10.1016/j.ipm.2020.102436\\u003c/li\\u003e\\n\\u003cli\\u003eKraus T (2024) Deployment of containerized simulations in an API-driven distributed infrastructure\\u003c/li\\u003e\\n\\u003cli\\u003eLi M, Wang Y, Ma S, et al (2023) Auto-Tuning with Reinforcement Learning for Permissioned Blockchain Systems. Proc VLDB Endow 16:1000\\u0026ndash;1012. https://doi.org/10.14778/3579075.3579076\\u003c/li\\u003e\\n\\u003cli\\u003eKaushal R, Kumar N (2024) Exploring Hyperledger Caliper benchmarking tool to measure the performance of blockchain based solutions. In: Proceedings of the 11th International Conference on Reliability, Infocom Technologies and Optimization (ICRITO 2024). IEEE, pp 1\\u0026ndash;6\\u003c/li\\u003e\\n\\u003c/ol\\u003e\\n\\u003cp\\u003e\\u0026nbsp;\\u003c/p\\u003e\"}],\"fulltextSource\":\"\",\"fullText\":\"\",\"funders\":[],\"hasAdminPriorityOnWorkflow\":false,\"hasManuscriptDocX\":true,\"hasOptedInToPreprint\":true,\"hasPassedJournalQc\":\"\",\"hasAnyPriority\":false,\"hideJournal\":false,\"highlight\":\"\",\"institution\":\"\",\"isAcceptedByJournal\":false,\"isAuthorSuppliedPdf\":false,\"isDeskRejected\":\"\",\"isHiddenFromSearch\":false,\"isInQc\":false,\"isInWorkflow\":false,\"isPdf\":false,\"isPdfUpToDate\":true,\"isWithdrawnOrRetracted\":false,\"journal\":{\"display\":true,\"email\":\"info@researchsquare.com\",\"identity\":\"peer-to-peer-networking-and-applications\",\"isNatureJournal\":false,\"hasQc\":true,\"allowDirectSubmit\":false,\"externalIdentity\":\"ppna\",\"sideBox\":\"Learn more about [Peer-to-Peer Networking and Applications](http://link.springer.com/journal/12083)\",\"snPcode\":\"12083\",\"submissionUrl\":\"https://submission.nature.com/new-submission/12083/3\",\"title\":\"Peer-to-Peer Networking and Applications\",\"twitterHandle\":\"\",\"acdcEnabled\":true,\"dfaEnabled\":true,\"editorialSystem\":\"em\",\"reportingPortfolio\":\"Springer Hybrid\",\"inReviewEnabled\":true,\"inReviewRevisionsEnabled\":false},\"keywords\":\"Peer-to-Peer Blockchain Networks, Permissioned Blockchain, Hyperledger Fabric, Blockchain Performance Evaluation, Throughput and Latency Analysis, Distributed Ledger Systems\",\"lastPublishedDoi\":\"10.21203/rs.3.rs-8611135/v1\",\"lastPublishedDoiUrl\":\"https://doi.org/10.21203/rs.3.rs-8611135/v1\",\"license\":{\"name\":\"CC BY 4.0\",\"url\":\"https://creativecommons.org/licenses/by/4.0/\"},\"manuscriptAbstract\":\"Permissioned blockchain platforms operate as peer-to-peer distributed systems whose performance, scalability, and resource behavior are critical for deployment in cross-border regulatory applications. Effective regulatory coordination within Free Trade Areas (FTAs) is nevertheless hindered by fragmented National Quality Infrastructure (NQI) systems, limited interoperability, and weak institutional trust mechanisms. This study addresses these challenges by designing and experimentally evaluating a permissioned blockchain network based on Hyperledger Fabric to support interoperable, transparent, and auditable NQI processes. Using the African Continental Free Trade Area (AfCFTA) as an illustrative regulatory environment, the proposed system models core regulatory transactions—such as standards submission and endorsement, accreditation recording, and certificate verification—through smart contracts executed across multiple peer organizations. The design distinguishes between write-intensive submission transactions, which require multi-peer endorsement and ordering, and read-only verification and audit transactions executed locally at peer nodes. The framework is implemented in Go using the Fabric Contract API and evaluated on Hyperledger Fabric v2.5 using Hyperledger Caliper v0.6.0. Experimental results under varying concurrency and load conditions demonstrate low-latency read performance (sub-15 ms) and a write-throughput ceiling of approximately 400 TPS, attributable to endorsement and ordering overheads in the consensus pipeline. These results provide empirical insights into performance trade-offs in permissioned peer-to-peer blockchain networks and confirm the suitability of Hyperledger Fabric for compliance-driven, multi-institutional regulatory environments.\",\"manuscriptTitle\":\"Performance Evaluation of a Hyperledger Fabric–Based Permissioned Blockchain Network for Cross-Border Regulatory Applications\",\"msid\":\"\",\"msnumber\":\"\",\"nonDraftVersions\":[{\"code\":1,\"date\":\"2026-03-05 07:47:08\",\"doi\":\"10.21203/rs.3.rs-8611135/v1\",\"editorialEvents\":[{\"type\":\"communityComments\",\"content\":0},{\"type\":\"reviewerAgreed\",\"content\":\"109392533738067544929238692981098067601\",\"date\":\"2026-04-28T11:18:32+00:00\",\"index\":\"hide\",\"fulltext\":\"\"},{\"type\":\"reviewersInvited\",\"content\":\"\",\"date\":\"2026-03-02T12:13:03+00:00\",\"index\":\"\",\"fulltext\":\"\"},{\"type\":\"editorAssigned\",\"content\":\"\",\"date\":\"2026-01-31T10:23:53+00:00\",\"index\":\"\",\"fulltext\":\"\"},{\"type\":\"checksComplete\",\"content\":\"\",\"date\":\"2026-01-22T13:00:48+00:00\",\"index\":\"\",\"fulltext\":\"\"},{\"type\":\"submitted\",\"content\":\"Peer-to-Peer Networking and Applications\",\"date\":\"2026-01-15T13:44:20+00:00\",\"index\":\"\",\"fulltext\":\"\"}],\"status\":\"published\",\"journal\":{\"display\":true,\"email\":\"info@researchsquare.com\",\"identity\":\"peer-to-peer-networking-and-applications\",\"isNatureJournal\":false,\"hasQc\":true,\"allowDirectSubmit\":false,\"externalIdentity\":\"ppna\",\"sideBox\":\"Learn more about [Peer-to-Peer Networking and Applications](http://link.springer.com/journal/12083)\",\"snPcode\":\"12083\",\"submissionUrl\":\"https://submission.nature.com/new-submission/12083/3\",\"title\":\"Peer-to-Peer Networking and Applications\",\"twitterHandle\":\"\",\"acdcEnabled\":true,\"dfaEnabled\":true,\"editorialSystem\":\"em\",\"reportingPortfolio\":\"Springer Hybrid\",\"inReviewEnabled\":true,\"inReviewRevisionsEnabled\":false}}],\"origin\":\"\",\"ownerIdentity\":\"3d15580c-9935-4012-bc40-1d666b74d67a\",\"owner\":[],\"postedDate\":\"March 5th, 2026\",\"published\":true,\"recentEditorialEvents\":[],\"rejectedJournal\":[],\"revision\":\"\",\"amendment\":\"\",\"status\":\"under-review\",\"subjectAreas\":[],\"tags\":[],\"updatedAt\":\"2026-03-05T07:47:09+00:00\",\"versionOfRecord\":[],\"versionCreatedAt\":\"2026-03-05 07:47:08\",\"video\":\"\",\"vorDoi\":\"\",\"vorDoiUrl\":\"\",\"workflowStages\":[]},\"version\":\"v1\",\"identity\":\"rs-8611135\",\"journalConfig\":\"researchsquare\"},\"__N_SSP\":true},\"page\":\"/article/[identity]/[[...version]]\",\"query\":{\"redirect\":\"/article/rs-8611135\",\"identity\":\"rs-8611135\",\"version\":[\"v1\"]},\"buildId\":\"XKTyCvWXoU3ODBz1xrDgd\",\"isFallback\":false,\"isExperimentalCompile\":false,\"dynamicIds\":[84888],\"gssp\":true,\"scriptLoader\":[]}","source_license":"CC-BY-4.0","license_restricted":false}