Supply chain financial intelligent contract management system based on block chain

Abstract

The invention discloses a supply chain financial intelligent contract management system based on a block chain, and relates to the technical field of supply chain financial risk management, and the system comprises an event-driven multi-layer intelligent contract dynamic cooperation engine; the multi-layer intelligent contract dynamic cooperation engine is composed of a risk event quantification-rule engine layer, a contract relation graph-cooperation scheduling layer and a security execution-feedback optimization layer which are in communication connection in sequence. According to the supply chain financial intelligent contract management system based on the block chain, through an event-driven multi-layer intelligent contract dynamic cooperation engine, the problems of staticization and isolation of a multi-level financing contract are solved. Based on a risk conduction routing protocol of a supply chain tree-shaped topological graph, data driving strategy generation of a dual-path verification rule base is combined, and it is ensured that when the credit risk of a core enterprise dynamically changes, the system automatically triggers differential parameter adjustment associated with a multi-level contract.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of supply chain financial risk management, in particular to a supply chain financial smart contract management system based on block chain. BACKGROUND

[0002] In the field of supply chain finance, the credit status of core enterprises is the key basis for their multi-level upstream suppliers to obtain financing. The traditional supply chain finance system is information fragmented, cumbersome process, and low transparency. The combination of blockchain technology and smart contracts has brought revolution to this field. Through distributed ledger, data credibility and transaction transparency are improved. Using programmable contracts, automatic execution of transaction conditions is realized, such as automatic financing and repayment based on receivables or orders, which significantly improves business efficiency.

[0003] However, the existing supply chain financial smart contract management system based on block chain has a significant defect: the operation logic of its smart contract generally presents static and isolated characteristics. Once these contracts are deployed, their core terms such as financing interest rate, limit, and loan conditions are usually fixed or need complex manual intervention to modify. More importantly, there is a lack of efficient automatic linkage mechanism between financing contracts for different levels of suppliers around the same core enterprise. When a major credit risk event occurs to the core enterprise, the existing system is difficult to perceive this change in real time and automatically, and it is also unable to automatically trigger timely and differentiated dynamic adjustments to the terms of all levels of suppliers' financing contracts associated with the core enterprise according to preset rules. The lack of such linkage mechanism leads to a serious lag in risk response, forcing financial institutions to rely on inefficient manual operations to assess risks and manually modify contracts at each level, which not only significantly increases operational risks and costs, but also amplifies credit risks along the supply chain, deteriorates the financing environment for suppliers, reduces capital efficiency, and the overall risk management effectiveness of the system is far from expected. Therefore, the problem to be solved at present is: how to realize the automatic and real-time linkage adjustment of associated multi-level financing smart contracts when the credit risk of the core enterprise dynamically changes. SUMMARY

[0004] To achieve the above purpose, the present application is implemented by the following technical scheme: a supply chain financial smart contract management system based on block chain, comprising: an event-driven multi-layer smart contract dynamic coordination engine;

[0005] The multi-layer smart contract dynamic coordination engine is composed of a risk event quantification-rule engine layer, a contract relationship graph-synergistic scheduling layer, and a safe execution-feedback optimization layer connected in communication;

[0006] The risk event quantification-rule engine layer receives external input credit risk event data and outputs adjustment strategies to the synergistic scheduling layer;

[0007] The cooperative scheduling layer builds a multi-level contract relationship network and pre-verifies the adjustment strategy, and sends the instructions that pass the verification to the execution layer;

[0008] The execution layer implements contract parameter modification and feeds back execution effect data to the rule engine layer.

[0009] Preferably, the risk event quantification-rule engine layer includes a dynamic credit risk factor matrix generation module and a double-path verification rule library;

[0010] The dynamic credit risk factor matrix generation module converts risk events into calculable indicators containing hierarchical transmission intensity coefficients and financing type sensitive thresholds;

[0011] The double-path verification rule library generates adjustment strategies by the following methods:

[0012] (a) calling the pre-defined credit event response rules of financial institutions;

[0013] (b) generating dynamic compensation rules based on on-chain historical default data training;

[0014] (c) merging the output results of the two paths to generate the final strategy.

[0015] Preferably, the generation process of the dynamic compensation rules includes:

[0016] Extracting the correlation characteristics of supplier levels and funding losses in historical events;

[0017] Generating calibration parameters covering preset risk levels through a machine learning model;

[0018] When the deviation of the preset rules and the calibration parameters exceeds the set threshold, the calibration parameters are used preferentially.

[0019] Preferably, the contract relationship graph-synergistic scheduling layer performs the following operations:

[0020] Parsing the core enterprise digital signature and supplier affiliation field in the financing contract;

[0021] Generating a multi-level supply chain tree topology graph with the core enterprise as the root node;

[0022] Determining the priority order of contract adjustment according to the preset risk transmission routing protocol.

[0023] Preferably, the cooperative scheduling layer further includes a sandboxed linkage simulator, which simulates the following before executing the adjustment:

[0024] Loading the state data of all related contracts;

[0025] Simulating the funding flow paths under different adjustment strategies;

[0026] A dual convergence check mechanism is initiated, including:

[0027] (i) verifying whether the overall system risk exposure is reduced to the target range;

[0028] (ii) scanning all supplier nodes for cash flow disruption risk markers.

[0029] Preferably, the dual convergence check mechanism sets two levels of blocking conditions:

[0030] When the risk exposure does not meet the standard, the rule engine layer is returned to regenerate the strategy;

[0031] When the disruption risk of any supplier node exceeds the safety threshold, the adjustment process is terminated.

[0032] Preferably, the safe execution-feedback optimization layer includes:

[0033] A dual-channel atomization execution module, the main channel of which modifies parameters in batches through cross-contract calls, and the standby channel activates a risk isolation fuse solution when it detects an execution failure;

[0034] A dynamic rule evolution module that compares the deviation amplitude of actual fund loss data and simulated prediction values;

[0035] When the deviation exceeds a set threshold, the rule base is triggered for retraining.

[0036] Preferably, the risk isolation fuse solution includes:

[0037] Immediately freezing the new financing operations of the current level contract;

[0038] Sending a risk state code to the adjacent level contract;

[0039] Triggering a secondary fuse according to the risk transmission routing protocol.

[0040] Preferably, the blockchain-based supply chain financial smart contract management system further includes:

[0041] A trusted oracle component that inputs risk events to the rule engine layer through digital signature verification;

[0042] A hierarchical permission controller that limits the contract modification permissions of participants at different levels.

[0043] Preferably, the dynamic rule evolution module inputs the retrained rule base into a sandboxed linkage simulator, and only updates to the dual-path verification rule base after passing the dual convergence check.

[0044] The present application provides a blockchain-based supply chain financial smart contract management system.

[0045] The blockchain-based supply chain financial smart contract management system solves the problems of staticization and isolation of multi-level financing contracts through an event-driven multi-layer smart contract dynamic collaboration engine. It realizes precise control of risk transmission, and generates data-driven strategy based on the risk transmission routing protocol of the supply chain tree topology map and the double-path verification rule library, ensuring that when the credit risk of core enterprises changes dynamically, the system automatically triggers the differentiated parameter adjustment of associated multi-level contracts.

[0046] The blockchain-based supply chain financial smart contract management system forms a security line with a sandboxed linkage simulator and a double convergence verification mechanism to predict changes in global risk exposure and node cash flow disruption risk before parameter modification, fundamentally avoiding the spread of credit risk caused by manual intervention lag. The rule self-evolution mechanism continuously optimizes and adjusts the strategy to form a closed-loop risk control system of perception-decision-execution-optimization. BRIEF DESCRIPTION OF DRAWINGS

[0047] Figure 1 The figure is a schematic diagram of the overall framework of the application. DETAILED DESCRIPTION

[0048] The technical solutions in the embodiments of the application will be described in detail below with reference to the drawings in the embodiments of the application. Obviously, the described embodiments are only a part of the embodiments of the application, not all embodiments. Based on the embodiments in the application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the application.

[0049] Please refer to Figure 1 The application provides a technical solution: a blockchain-based supply chain financial smart contract management system, comprising: an event-driven multi-layer smart contract dynamic collaboration engine;

[0050] The multi-layer smart contract dynamic collaboration engine is composed of a risk event quantification-rule engine layer, a contract relationship map-collaboration scheduling layer and a safe execution-feedback optimization layer connected in sequence.

[0051] The risk event quantification-rule engine layer receives external input credit risk event data and outputs adjustment strategies to the collaboration scheduling layer.

[0052] The collaboration scheduling layer constructs a multi-level contract relationship network and pre-verifies the adjustment strategies, and sends the verified instructions to the execution layer.

[0053] The execution layer implements contract parameter modification and feeds back execution effect data to the rule engine layer.

[0054] It needs to be further explained that in the specific implementation process, when the system detects the core enterprise credit risk event through the trusted oracle component, the event-driven multi-layer intelligent contract dynamic collaboration engine starts the response process. The risk event quantification-rule engine layer first receives the risk event raw data, and the dynamic credit risk factor matrix generation module converts it into calculable indicators, including: automatically assigning decay transmission intensity coefficients to different levels of suppliers, and matching differentiated risk sensitivity thresholds according to financing types.

[0055] The double-path verification rule library operates synchronously, the first path calls the pre-defined rule library of the financial institution to generate basic adjustment parameters, and the second path activates the historical risk event-fund loss correlation model to generate dynamic compensation parameters covering preset risk levels by analyzing the distribution characteristics of historical default data on the chain; when the deviation of the output parameters of the two paths exceeds the set tolerance threshold, the compensation parameters generated by the data-driven are preferred, and the final adjustment strategy is output after weighted fusion.

[0056] After the adjustment strategy is transmitted to the contract relationship graph-synergistic scheduling layer, the system parses the core enterprise digital signature and supplier affiliation field in the financing contract, and constructs a multi-level supply chain tree topology graph with the core enterprise as the root node. According to the preset risk transmission routing protocol, the adjustment priority order from the directly associated first-level supplier contract to the last-level supplier contract is determined.

[0057] The sandboxed linkage simulator loads all the current associated contract state data, simulates the fund flow path under the adjustment strategy, including: if the simulation result shows that the overall risk exposure of the system has not decreased to the target safety range, send a strategy reconstruction instruction to the rule engine layer; if the cash flow disruption risk flag of any supplier node is triggered, immediately terminate the process and start the fuse protocol.

[0058] The verified instructions enter the safe execution-feedback optimization layer, and the double-channel atomization execution module initiates cross-contract batch modification through the main channel, including: if the parameter modification of a certain level contract fails, the standby channel immediately freezes the newly added financing of that branch and sends an encrypted risk state code to the adjacent level, triggering the secondary fuse.

[0059] After execution is completed, the dynamic rule evolution module captures the actual fund loss data and performs deviation analysis with the simulation prediction value, including: when the deviation amplitude continuously exceeds the dynamic learning threshold, automatically start rule library retraining, and new rules need to be double-checked by the sandbox simulator before deployment. The hierarchical permission controller monitors the operation permission throughout the process to ensure that only authorized nodes can modify the corresponding level contract parameters.

[0060] The risk event quantification-rule engine layer includes a dynamic credit risk factor matrix generation module and a double-path verification rule library;

[0061] The dynamic credit risk factor matrix generation module converts the risk event into a calculable indicator containing the hierarchical transmission intensity coefficient and the financing type sensitive threshold;

[0062] The dual-path verification rule base generates the adjustment strategy in the following ways:

[0063] (a) calling the pre-defined credit event response rules of the financial institution;

[0064] (b) generating dynamic compensation rules based on on-chain historical default data training;

[0065] (c) merging the output results of the two paths to generate the final strategy.

[0066] It needs to be further explained that in the specific implementation process, when the risk event quantification-rule engine layer is started, the dynamic credit risk factor matrix generation module first processes the external input core enterprise credit risk event, including: after identifying the event type, automatically assigning the transmission intensity coefficient to the suppliers at different levels, which decays exponentially with the level of the suppliers away from the core enterprise; At the same time, according to the type of financing product, match the corresponding risk sensitive threshold, the receivables financing and the order financing adopt different threshold standards.

[0067] The dual-path verification rule base activates the two processing paths simultaneously, that is: the first path accesses the pre-defined rule database of the financial institution, extracts the response rule template matched with the current risk event type, and generates the basic adjustment parameter; The second path calls the on-chain historical default database, analyzes the characteristics of three dimensions through the association model, including: the supplier level distribution in the historical similar events, the actual fund loss ratio, and the risk transmission time delay, and trains to generate dynamic compensation parameters.

[0068] When the key parameters output by the two paths deviate more than the set tolerance threshold, the compensation parameters generated by the second path are preferred; If the deviation is within the tolerance range, then the results of the two paths are fused according to the preset weight, wherein the key parameters include the interest rate floating value and the margin adjustment amount.

[0069] The final output adjustment strategy contains two mandatory constraints, including: the total amount of financing of the core enterprise after adjustment cannot exceed its dynamic credit limit, and the financing cost increase of the last level supplier must be lower than the transmission decay coefficient.

[0070] The generation process of the dynamic compensation rule includes:

[0071] Extract the association characteristics of the supplier level and the fund loss in the historical events;

[0072] Generate calibration parameters covering the preset risk level through a machine learning model;

[0073] The calibration parameter is adopted in priority when the deviation of the preset rule from the calibration parameter exceeds a set threshold.

[0074] It should be further explained that in the specific implementation process, when the dual-path verification rule library activates the second path, the system first extracts three types of core features from the on-chain historical database, including: the credit rating interval of the core enterprise at the time of the risk event, the hierarchical position of the affected supplier, and the actual financial loss ratio within a specific time window after the event.

[0075] Through the correlation model of supplier hierarchy and financial loss, the attenuation curve characteristics of hierarchy depth and loss rate are identified, that is: when the supplier hierarchy increases by one level, the loss rate attenuation speed presents a nonlinear slowing down trend.

[0076] The machine learning engine generates dynamic compensation parameters based on the characteristics, including: for directly associated first-level suppliers, generating full compensation parameters covering high-risk levels; for second-level and subsequent suppliers, generating stepwise decreasing compensation parameters according to the loss rate proportion corresponding to their hierarchical positions on the attenuation curve.

[0077] If the deviation of the compensation parameters generated by the training from the preset rules of the financial institution exceeds the set tolerance threshold, the system automatically starts the parameter replacement protocol, and adopts the compensation value generated by the data-driven in priority; if the preset rules do not define the current risk event type, the compensation parameter is directly used as the final output.

[0078] A double-layer verification mechanism is set during the training process, including: the compensation parameter must make the financial loss coverage rate in the historical sample reach the preset target value, and the compensation amount of the last-level supplier must not exceed its financing limit, and the model is retrained when any condition is not met.

[0079] The contract relationship graph-synergistic scheduling layer performs the following operations:

[0080] Analyzing the core enterprise digital signature and supplier affiliation field in the financing contract;

[0081] Generating a multi-level supply chain tree topology graph with the core enterprise as the root node;

[0082] Determining the priority order of contract adjustment according to the preset risk transmission routing protocol.

[0083] It should be further explained that in the specific implementation process, when the synergistic scheduling layer is started, the system scans the metadata fields of all associated financing contracts on the blockchain, and identifies the directly associated parties by decrypting the affiliation code in the core enterprise digital signature. For first-level supplier contracts, extract the downstream supplier list declared in the contract terms, and recursively build a multi-level affiliation chain.

[0084] The topological map generation module takes the core enterprise as the root node, the first-level supplier as the second-level node, and the subsequent levels as child nodes according to the declaration relationship, forming a tree structure and labeling the financing quota weight of each node. The risk transmission routing protocol sets the adjustment priority according to three dimensions, including: first, processing contracts with direct debt and equity relationships with the core enterprise; second, ordering from near to far according to the supplier level; and finally, arranging the same level contracts in ascending order according to the financing expiration date.

[0085] When detecting that a supplier appears in multiple supply chains at the same time, automatically merging duplicate nodes and taking the highest risk transmission coefficient. During the construction of the map, a conflict resolution mechanism is set, including: if the level declaration of the same supplier by different contracts is contradictory, the supply chain traceability database is called to verify the true relationship; if it cannot be verified, the node associated path is temporarily frozen.

[0086] The collaborative scheduling layer also includes a sandboxed linkage simulator, which:

[0087] loads the state data of all associated contracts;

[0088] simulates the fund flow path under different adjustment strategies;

[0089] starts a double convergence verification mechanism, including:

[0090] (i) verifying whether the overall risk exposure of the system has decreased to the target range;

[0091] (ii) scanning all supplier nodes for cash flow disruption risk markers.

[0092] It needs to be further explained that in the specific implementation process, when the collaborative scheduling layer receives the adjustment strategy from the rule engine layer, the sandboxed linkage simulator first creates a parallel test environment isolated from the main chain and loads the real-time state snapshot of all associated contracts. The simulator reconstructs the fund flow path according to the node connection relationship of the supply chain tree topological map, including: starting from the core enterprise node, injecting a risk event shock wave, and calculating the parameter adjustment influence of each supplier node layer by layer. During the simulation execution, the system tracks three key indicators, namely: global risk exposure change value, single node cash flow gap marker number, and cross-level risk transmission delay time.

[0093] The dual convergence verification mechanism is synchronously started, including: the first level verification monitors whether the overall risk exposure of the system is reduced to the boundary of the target safety zone, if the exposure value is still higher than the upper threshold after three consecutive simulation iterations, a strategy reconstruction request is sent to the rule engine layer; the second level verification scans all supplier nodes, when any node is detected to have a cash flow disruption risk marker, that is, the simulation account balance is lower than a certain proportion of the debt to be paid, the simulation process is immediately terminated and a fuse instruction is generated. The simulation results are output through a dynamic visual board, and high-risk nodes and transmission paths that need human intervention are highlighted.

[0094] The dual convergence verification mechanism sets two levels of blocking conditions:

[0095] When the risk exposure is not up to standard, the rule engine layer is returned to regenerate the strategy;

[0096] When the disruption risk of any supplier node exceeds the safety threshold, the adjustment process is terminated.

[0097] It needs to be further explained that during the specific implementation process, when the dual convergence verification mechanism is running, the system first judges the current verification type, including: if it is risk exposure verification, a three-level progressive processing flow is started, that is: when the global risk exposure is first detected to be higher than the target upper threshold, the risk shock wave transmission strength is automatically reduced to re-simulate; if the second detection is still over-standard, the adjustment parameter variation interval is compressed to the historical safety range; when the exposure value continues to exceed the boundary after the third simulation, a strategy reconstruction instruction is sent to the rule engine layer and the current adjustment batch is frozen. If it is cash flow disruption verification, the system scans the payment ability indicators of all supplier nodes in real time, when the simulation account balance of a certain node is detected to be lower than a certain proportion of the debt to be paid, the whole link simulation process is immediately interrupted, and a fuse instruction containing the coordinates of the disrupted node is generated.

[0098] There are execution priority differences between the two verification modes, including: when the cash flow disruption verification is triggered, the exposure verification process is immediately covered to ensure immediate risk priority disposal. For special industry supply chains, such as cyclical fluctuation industries, the system automatically retrieves the industry feature library to match the flexible verification threshold, avoiding misjudgment caused by rigid blocking.

[0099] The safe execution-feedback optimization layer includes:

[0100] The dual-channel atomization execution module, the main channel of which modifies the parameters in batches through cross-contract calls, and the standby channel activates the risk isolation fuse solution when execution failure is detected;

[0101] The dynamic rule evolution module compares the deviation amplitude between the actual fund loss data and the simulation prediction value;

[0102] When the deviation exceeds the set threshold, the rule library is triggered for retraining.

[0103] It's important to note that during implementation, once the sandbox simulation passes verification, the dual-channel atomic execution module initiates primary channel operations, including batch initiating cross-contract calls based on topology priority and modifying key parameters like interest rates and margins. The primary channel employs a two-step confirmation mechanism: each node returns a digitally signed receipt upon successful contract modification. If a receipt at a specific level isn't received within a specified timeframe, the system automatically retries a limited number of times before switching to the backup channel.

[0104] The backup channel activates the risk isolation circuit breaker solution, including: freezing all new financing functions of the current problem node, injecting encrypted risk status codes into the adjacent layer contracts, including event type, risk level, and transmission path identifier, to trigger the secondary node to initiate a local circuit breaker. During the execution process, the actual capital flow data is captured in real time, and the dynamic rule evolution module conducts a three-stage deviation analysis between it and the simulated forecast value, including: marking the strategy as an observation sample when the short-term deviation exceeds the limit; triggering local retraining of the rule library for three consecutive deviations; and initiating global model reconstruction when there is a systematic deviation. Recent high-confidence event samples are given priority during retraining. New rules must be injected into the sandbox environment and pass double verification before they can be deployed to the production environment. For cross-border multi-currency scenarios, the exchange rate fluctuation buffer model is automatically called to correct the capital loss calculation benchmark.

[0105] Risk isolation and circuit breaking solutions include:

[0106] Immediately freeze new financing operations for the current level of contracts;

[0107] Send risk status codes to adjacent level contracts;

[0108] Trigger secondary circuit breakers based on risk transmission routing protocols.

[0109] It's important to further clarify that, during implementation, when the risk isolation circuit breaker scheme is activated on the backup channel, the system first locates the problematic node, immediately freezes all new financing transaction authorizations for that node, and generates a 128-bit risk status code. This code comprises a three-dimensional feature vector, including an event type identifier, a risk intensity index, and a topological transmission path fingerprint. After verification by the blockchain consensus node, the code is propagated to adjacent tiers according to a pre-set routing protocol. Specifically, for directly connected upstream nodes, a first-level circuit breaker instruction is issued, requiring a simultaneous freeze on capital outflows. For downstream nodes, a second-level warning signal is injected, triggering conservative parameter adjustments.

[0110] The secondary fusing adopts dynamic range control, including: if the problem node is a first-level supplier, the fusing radius covers its directly associated third-level subnets; if it is a terminal node, only the current branch is isolated. For cross-border multi-chain scenarios, the protocol converter is automatically called to compile the fusing instructions into a risk event standard format recognizable by the target chain smart contract, ensuring the collaborative blocking between heterogeneous systems. During the fusing state duration, the system scans the node solvency every minute, and when the account balance rises to the safety threshold and remains stable for a certain period, the fusing release proposal is automatically initiated, which needs two-thirds of the associated nodes to pass the consensus before it can be released.

[0111] The blockchain-based supply chain financial smart contract management system further comprises:

[0112] A trusted oracle component inputs risk events to the rule engine layer through digital signature verification;

[0113] A hierarchical permission controller limits the contract modification permissions of participants at different levels.

[0114] It should be further explained that in the specific implementation process, when an external credit risk event occurs, the trusted oracle component starts a three-way verification channel, including: first, obtaining official risk rating change data through the financial institution supervision sandbox interface, second, grabbing key word matching events from the authoritative judicial agency announcement platform, and finally, calling real-time operating indicators of the core enterprise supply chain collaboration system. After the three-way data flow is compared for consistency by the consensus node, a dynamic weight algorithm is used to generate a final risk event report, i.e.: the supervision data has the highest weight, the judicial announcement follows, and the enterprise self-certification data needs to be verified in reverse before being accepted.

[0115] The event report is attached with a timestamp and quantum signature and input to the rule engine layer, which triggers the risk control upgrade protocol of the hierarchical permission controller, including: the first-level risk event automatically grants the financial institution global parameter modification permission, the second-level event is limited to hierarchical adjustment permission, and the terminal warning only opens read-only monitoring permission. For cross-border multi-subject scenarios, the system automatically identifies the regulatory attribution of the participants' registered place, dynamically divides the permission domain, including: the EU subject applies the GDPR query permission template, and the Asia-Pacific subject enables cross-border data desensitization access channel. The permission change record is written in real time into an unalterable log for regulatory audit traceability.

[0116] The dynamic rule evolution module inputs the retrained rule base into the sandboxed linkage simulator, and only updates to the double-path verification rule base after passing the double convergence check. It needs to be further explained that, in the specific implementation process, when the dynamic rule evolution module detects that the deviation between the actual fund loss data and the simulation prediction value exceeds the dynamic learning threshold, the system automatically starts the rule base retraining process. First, isolate the storage of recent high-confidence risk event sample sets, extract three layers of features through the historical event-loss correlation model, including: risk transmission speed indicators, cross-level loss decay curves, and industry sensitivity coefficients. The training process uses a double-channel verification architecture, i.e.: the main channel performs regular parameter optimization, and the backup channel injects adversarial samples to test the robustness of the rules.

[0117] The newly generated rule base is immediately imported into the sandboxed linkage simulator and forced to pass the double convergence check, including: risk exposure verification requires that the simulation results be stable within the target safety zone for three consecutive times, and cash flow disruption verification requires that all nodes be scanned for zero alarm triggers. If the verification fails, the system automatically reverts to the last stable version and marks the problem feature dimension; if the verification passes, the system starts the gray release mechanism, including: first selecting a specific industry supply chain branch for trial operation, and monitoring the actual effect after three business cycles to meet the requirements before deploying it globally. For regulatory compliance conflicts that occur during the training process, the legal clause knowledge graph is called in real time to filter the rules, and parameter combinations that violate local regulatory policies are automatically excluded.

[0118] When a core enterprise credit risk event occurs, the system obtains external information through a trusted data source component, which simultaneously connects financial regulatory agency data interfaces, judicial announcement platforms, and enterprise supply chain collaboration systems. After consistency comparison and verification, multiple data streams generate a final risk report, which is attached with an unforgeable time stamp and encrypted signature and input into the rule processing layer.

[0119] The rule processing layer starts the dynamic factor conversion module, which automatically assigns risk transmission coefficients based on the correlation level between suppliers and core enterprises, and the coefficient value decreases with the increase of the level, while distinguishing between accounts receivable financing and order financing types to match different sensitivity thresholds. The double-path rule verification mechanism is activated simultaneously, the first path accesses the financial institution's preset rule base to extract basic adjustment parameters, and the second path retrieves historical default records stored on the blockchain, and generates compensation parameters by analyzing the correlation between the supplier level distribution and the actual fund loss in historical events.

[0120] When the difference between the output results of the two paths exceeds the set tolerance limit, the data-driven compensation parameters are preferred, and the difference within the limit is processed by a fixed proportion. The final generated adjustment strategy contains two mandatory constraints, including: the total financing amount after adjustment does not exceed the dynamic credit limit of the core enterprise, and the financing cost increase of the last-level supplier is lower than the level decay coefficient extreme value.

[0121] After the adjustment strategy is transmitted to the contract coordination layer, the system scans the financing contract metadata on the blockchain to parse the supplier affiliation code in the core enterprise digital signature. By recursively extracting the downstream associated parties declared by the first-level contract, a multi-level tree topology structure with the core enterprise as the root node is constructed, and the connection lines between nodes are marked with the financing quota weight. According to the preset conduction rules, the contract processing priority is determined, including: the contract holding the core enterprise's direct endorsement is processed first, the same level is arranged in ascending order according to the financing expiration time, and the cross-border supply chain branch is automatically converted to the time zone benchmark.

[0122] The sandboxed simulation environment loads the topology structure and real-time state of the contract, injects a risk shock wave to simulate the conduction effect, including: starting from the core enterprise node, calculating the parameter adjustment influence layer by layer, tracking the global risk exposure change value and single-node solvency index. The simulation process starts double security check, when the risk exposure is detected for the first time to exceed the target range, the impact strength is reduced to recalculate, the second time exceeds the standard, the adjustment amplitude is compressed to the historical safe interval, the third time exceeds the standard directly terminates the process and requests rule reconstruction. When the balance of any node simulation account is lower than the warning proportion of the debt to be paid, the whole link simulation is interrupted immediately, and a high-risk node positioning report is generated.

[0123] The instructions verified by simulation enter the execution layer, the main channel initiates batch contract parameter modification according to priority, and each modification needs to obtain a digital signature reply confirmation. Nodes that have not received a reply trigger the backup channel fuse mechanism, including: freezing the node's new financing function, sending encrypted instructions containing risk type identification, intensity level, and conduction path fingerprint to adjacent nodes.

[0124] During the execution process, real-time capture of actual fund flow data is performed, and deviation analysis is performed with the simulation prediction value, including: short-term deviation is marked as an observation sample, continuous deviation triggers local training of the rule library, and systematic deviation starts global reconstruction. The new rule library must be injected into the sandbox environment to pass the double check again, and after the effect is verified in the specific industry supply chain for three business cycles, it is deployed in the whole system. The training process is connected to the legal clause knowledge base in real time, automatically filtering parameter combinations that violate local regulatory policies, such as shielding rules related to personal data in the European Union.

[0125] The permission control system runs through the whole process, including: the first-level risk event grants the financial institution the right to modify the global parameters, the second-level event limits the hierarchical adjustment permission, and the last-level early warning only opens the monitoring function. Cross-border scenarios automatically segment the permission domain, the European Union main body uses the data desensitization access channel, and the Asia-Pacific main body matches the regional regulatory template. All operations generate an unalterable audit trail, recording the operation party's identity ciphertext, target contract identifier, and parameter value before and after change.

[0126] During the risk fuse period, the system continuously monitors the node's ability to pay, and when the account balance remains stable beyond the safety threshold and meets the minimum observation period, it initiates a fuse removal proposal. The proposal requires direct association with the consistent agreement of the node and indirect majority voting of the node, and at the same time, it meets the cross-border jurisdiction requirement to take effect. For seasonal industry fluctuation scenarios, the system automatically retrieves the industry feature library to temporarily relax the judgment standard, avoiding false triggering of the fuse mechanism.

[0127] A blockchain-based supply chain financial smart contract management system, comprising the following steps:

[0128] Step S1: Obtain core enterprise credit risk events through a three-source trusted data channel. The financial regulatory interface, judicial announcement platform, and enterprise supply chain system data flow through the consensus node to compare consistency, generate a risk report with a timestamp and encrypted signature. Dynamically generate event type identification code and risk intensity index, trigger permission control system to upgrade risk control level.

[0129] Step S2: The rule processing layer starts hierarchical transmission coefficient distribution, including: the first-tier supplier adopts the benchmark coefficient, and the coefficient decreases by one level contract relationship according to the historical loss decay curve. Synchronously activate double-path verification, including: path one: call the financial institution preset rule library to extract basic parameters; path two: analyze on-chain historical default data, extract three-layer features to generate compensation parameters; when the path difference exceeds the tolerance limit, prefer to use data-driven results, and new events directly enable compensation parameters. The output strategy is forced to meet the final supplier cost increase below the hierarchical decay extreme value, wherein the three-layer features include transmission speed, loss decay slope, and industry sensitivity.

[0130] Step S3: Analyze the 128-bit membership code in the digital signature of the financing contract, recursively extract the downstream associated party declaration. Build a tree structure with the core enterprise as the root node, and label the financing amount weight between nodes. Sort by three priority levels, including: 1) contracts with direct endorsement of the core enterprise, 2) suppliers from near to far, 3) financing expiration date in ascending order, automatically convert time zone reference for cross-border branches, and conflict nodes call off-chain traceability data verification.

[0131] Step S4: Load the topology structure and real-time contract state in the isolated environment, inject risk shock wave simulation transmission, including: calculating parameter adjustment impact from the core enterprise node layer by layer; track global risk exposure changes and single-node solvency indicators; start gradual blocking, including exposure verification and cash flow disruption verification, wherein exposure verification includes: first over-standard decay shock intensity → second over-standard compression adjustment amplitude → third over-standard termination process; cash flow disruption verification includes: any node balance below the solvency warning line triggers chain link fuse; disruption signal takes precedence over exposure over-standard processing, and the industry fluctuation scenario automatically relaxes the judgment standard.

[0132] Step S5: The main channel modifies the contract parameters in batches according to the topology priority, and needs to obtain a digital signature reply confirmation. Unconfirmed nodes trigger the backup channel fuse, including: freezing the problem node's new financing function, injecting encrypted instructions containing risk fingerprints into adjacent nodes, and compiling instructions for cross-border scenarios into a standard event format recognizable by the target chain.

[0133] Step S6: Real-time capture of fund flow data and comparison with simulation values, including: short-term deviation marked as observation samples, continuous deviation triggering local training of rule library, systematic deviation starting global reconstruction, training process injecting adversarial sample testing robustness, legal compliance filter real-time removing illegal parameters.

[0134] Step S7: New rule library forced to pass through three rounds of sandbox environment verification, including: risk exposure continuously stable in the safety zone, full node scanning zero fracture alarm, trial operation in specific industry branches for three business cycles, monitoring actual effect up to standard for global deployment.

[0135] Step S8: Continuous monitoring of node solvency, when the balance continuously exceeds the safety threshold and meets the minimum observation period, including: generating a proposal for removal that needs to be directly associated with node full vote, indirect nodes voting by majority weighted by financing amount, synchronously meeting cross-border jurisdiction requirements, and restoring the process to an immutable audit trail.

[0136] Through the event-driven multi-layer intelligent contract dynamic collaboration engine, the problems of static and isolation of multi-level financing contracts are solved. The precise control of risk transmission is realized, and the risk transmission routing protocol based on the supply chain tree topology graph is combined with the data-driven strategy generation of the double-path verification rule library to ensure that when the credit risk of core enterprises changes dynamically, the system automatically triggers differentiated parameter adjustment of associated multi-level contracts.

[0137] The sandboxed linkage simulator and double convergence verification mechanism form a safety line to predict global risk exposure changes and node cash flow disruption risks before parameter modification, fundamentally avoiding the spread of credit risk caused by manual intervention lag. The rule self-evolution mechanism continuously optimizes and adjusts strategies, forming a closed-loop risk control system of perception-decision-execution-optimization.

[0138] In the supply chain finance business scenario, the risk management efficiency and fund use efficiency of financial institutions are improved. On the one hand, the automatic linkage adjustment mechanism eliminates the delay of cross-contract manual operation, reduces operational risk and compliance cost; on the other hand, the fuse protocol and permission hierarchical control ensure the safety and transparency of the adjustment process, preventing risk amplification along the supply chain.

[0139] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a..." does not exclude the presence of additional identical elements in the process, method, article, or device comprising the element.

[0140] While embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions, and variations may be made to these embodiments without departing from the principles and spirit of the invention, and that the scope of the invention is defined by the appended claims and their equivalents.

Claims

1. A supply chain finance smart contract management system based on blockchain, characterized by: include: Event-driven multi-layer smart contract dynamic collaboration engine; The multi-layer smart contract dynamic collaboration engine is composed of a risk event quantification-rule engine layer, a contract relationship map-collaborative scheduling layer, and a security execution-feedback optimization layer that are connected in sequence. The risk event quantification-rule engine layer receives external credit risk event data and outputs adjustment strategies to the collaborative scheduling layer; The collaborative scheduling layer constructs a multi-level contract relationship network and pre-verifies the adjustment strategy, and sends the verified instructions to the execution layer; The execution layer implements contract parameter modifications and feeds back execution effect data to the rule engine layer.

2. The blockchain-based supply chain finance smart contract management system according to claim 1, characterized in that: The risk event quantification-rule engine layer includes a dynamic credit risk factor matrix generation module and a dual-path verification rule library; The dynamic credit risk factor matrix generation module converts risk events into computable indicators including hierarchical transmission intensity coefficients and financing type sensitivity thresholds; The dual-path verification rule base generates adjustment strategies in the following ways: (a) Invoking credit event response rules predefined by financial institutions; (b) Generate dynamic compensation rules based on historical default data on the chain; (c) The output results of the two paths are integrated to generate the final strategy.

3. The blockchain-based supply chain finance smart contract management system according to claim 2, characterized in that: The generation process of the dynamic compensation rule includes: Extract the correlation characteristics between supplier level and financial loss in historical events; Generate calibration parameters covering pre-set risk levels through machine learning models; When the deviation between the preset rule and the calibration parameter exceeds the set threshold, the calibration parameter is preferentially adopted.

4. The blockchain-based supply chain finance smart contract management system according to claim 1, characterized in that: The contract relationship graph-coordinated scheduling layer performs the following operations: Parse the core enterprise digital signature and supplier affiliation fields in financing contracts; Generate a multi-level supply chain tree topology map with the core enterprise as the root node; Determine the priority order of contract adjustments based on the preset risk transmission routing protocol.

5. The blockchain-based supply chain finance smart contract management system according to claim 4, characterized in that: The collaborative scheduling layer also includes a sandboxed linkage simulator, which, before performing adjustments: Load the status data of all currently associated contracts; Simulate the capital flow path under different adjustment strategies; Enable the dual convergence verification mechanism, including: (i) Verify whether the overall risk exposure of the system has been reduced to the target range; (ii) Scan the cash flow disruption risk markers of all supplier nodes.

6. The blockchain-based supply chain finance smart contract management system according to claim 5, characterized in that: The dual convergence verification mechanism sets two levels of blocking conditions: When the risk exposure does not meet the requirements, it returns to the rule engine layer to regenerate the strategy; The adjustment process is terminated when it is detected that the fracture risk of any supplier node exceeds the safety threshold.

7. The blockchain-based supply chain finance smart contract management system according to claim 1, characterized in that: The security execution-feedback optimization layer includes: A dual-channel atomic execution module, where the main channel batch modifies parameters through cross-contract calls, and the backup channel activates a risk isolation circuit breaker solution when an execution failure is detected; Dynamic rule evolution module, comparing the deviation between actual capital loss data and simulated prediction values; When the deviation exceeds the set threshold, the rule base is retrained.

8. The blockchain-based supply chain finance smart contract management system according to claim 7, characterized in that: The risk isolation and fusing solution includes: Immediately freeze new financing operations for the current level of contracts; Send risk status codes to adjacent level contracts; Trigger secondary circuit breakers based on risk transmission routing protocols.

9. The blockchain-based supply chain finance smart contract management system according to claim 1, characterized in that: The blockchain-based supply chain finance smart contract management system also includes: The trusted oracle component inputs risk events into the rule engine layer through digital signature verification; A hierarchical permission controller limits the contract modification permissions of participants at different levels.

10. The blockchain-based supply chain finance smart contract management system according to claim 7, characterized in that: The dynamic rule evolution module inputs the retrained rule base into the sandboxed linkage simulator and updates it to the dual-path verification rule base only after passing the dual convergence check.

Images