Intelligent control method and system based on web3 supply chain finance

Abstract

The application discloses an intelligent control method and system based on Web3 supply chain finance, and belongs to the technical field of distributed data control of supply chain finance. The method performs source authentication, time alignment and consensus confirmation on transaction events, fund events, logistics events and credit events in a Web3 supply chain finance network to form a risk state vector; the action set of a reinforcement learning policy network is constrained by a risk score and a current contract state to output a risk control action; the risk control action is bound with a ledger state identifier, a state transition is performed by an intelligent contract state machine, and a contract execution receipt is generated; the contract execution receipt, subsequent performance events and the next consensus confirmation state are associated to form a reward value and a state transition sample, and after updating and verifying the policy version, the next control cycle is entered. The application can reduce the error control and repeated execution caused by inconsistent events, and improve the distributed state consistency and the receipt traceability.

Description

Technical Field

[0001] This invention belongs to the field of distributed data control technology in supply chain finance, specifically relating to intelligent control methods and systems based on Web3 supply chain finance. Background Technology

[0002] Supply chain finance systems need to receive heterogeneous events from procurement systems, order systems, warehousing systems, transportation equipment, payment interfaces, and credit data interfaces. Different events may use different time bases, business object identifiers, and transmission protocols. Network jitter, node offline, duplicate reporting, or interface retries may cause sequential conflicts, duplicate records, and unconfirmed records for the same business object. If the risk model directly reads events that have not been uniformly confirmed, it may generate financing approval, credit limit adjustment, risk warning, or fund freeze actions based on the old status.

[0003] Permissioned distributed ledgers can store events jointly confirmed by multiple participants and record the order of event submissions. However, writing business data to the ledger does not automatically guarantee that the model input is in a usable state. Ledger submissions have a time process, and when off-chain risk models read events, they also need to identify the event source, time integrity, submission status, and corresponding smart contract status. If the risk model does not store the correspondence between the input state and the ledger state, it is difficult to determine what state the control action is based on, and it is also difficult to distinguish between model errors, data delays, and contract rejections.

[0004] Existing supply chain finance platforms typically treat risk scoring and contract rules as two adjacent modules. When the risk score exceeds a threshold, the rules module triggers an alert or fund control; when the risk score is below the threshold, the rules module allows financing. Fixed thresholds make it difficult to adjust subsequent controls based on the results of delivery, repayment, settlement, and payment after execution. Even with the introduction of machine learning models, if the model only outputs a score without processing the current state of the contract, it may still output actions that do not conform to the state transition order.

[0005] Reinforcement learning can adjust policies based on state, actions, and rewards, but supply chain finance outcomes are delayed. A smart contract completing a call only indicates a successful computer state transition; it does not equate to a correct assessment of financing risks. Whether delivery is complete, payments are made on schedule, settlements are rolled back, and cross-chain payments are finally confirmed are typically determined after the contract call. If only successful contract calls are rewarded, the policy network may favor actions that are easy to execute while ignoring subsequent risky outcomes.

[0006] Smart contracts in multi-node networks also face concurrent and retry calls. The same risky action may be sent multiple times due to interface retries, and actions generated by older policy versions may arrive at the execution node after the ledger state has changed. When ledger state identifiers, policy version identifiers, and idempotency identifiers are missing, execution nodes have difficulty confirming whether actions are still applicable to the current state. Duplicate or out-of-order state transitions increase ledger conflicts and manual repair work.

[0007] Some systems utilize user feedback to modify risk rules. While this feedback may reflect false alarms, it does not directly equate to consensus-confirmed execution results. Supply chain finance involves multiple entities, and model updates require linking contract execution receipts, subsequent performance events, and the next ledger status to the same business object, while retaining auditable association keys. Without this association process, training samples are prone to being contaminated with data from different financing cycles.

[0008] In the permissioned distributed ledger environment of Web3 supply chain finance networks, the problem that needs to be solved is how to organize the consensus confirmation state formed by multi-source events, risk scoring, reinforcement learning actions, smart contract state transitions and post-execution performance results into a traceable data closed loop, so as to reduce the error control caused by unconfirmed events, old state actions and repeated calls, and make policy updates correspond to specific execution results. Summary of the Invention

[0009] The purpose of this invention is to provide an intelligent control method and system based on Web3 supply chain finance, which solves the technical problems of incorrect control caused by unsubmitted events, old state actions and repeated calls in Web3 supply chain finance networks, as well as insufficient distributed state consistency and acknowledgment traceability.

[0010] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: Intelligent control methods based on Web3 supply chain finance include: Collect supply chain transaction events, funding events, logistics events, and credit events from the Web3 supply chain finance network, perform source authentication, time alignment, and consensus confirmation on the events, and generate risk state vectors with credibility labels; The risk state vector is input into the risk scoring algorithm and the reinforcement learning strategy network. The risk score is used to constrain the set of optional actions of the reinforcement learning strategy network, and the risk control actions such as financing approval, quota adjustment, risk warning or fund freezing are output. The risk control action is bound to the ledger state identifier contained in the risk state vector to form a contract call request. The smart contract state machine verifies the contract call request and the current contract state, performs the allowed state transition, and generates a contract execution receipt. Based on the contract execution receipt, subsequent performance events and the next consensus confirmation state, a reward value and a state transition sample are generated. The state transition sample is used to update the reinforcement learning policy network and write the new policy version. After the consensus confirmation is completed in the contract execution receipt, the next control cycle begins; when a new strategy version is generated, the new strategy version is activated after it has been verified by multiple nodes, until the strategy stability condition or the update limit is reached.

[0011] As a preferred embodiment of the present invention, the source authentication includes verifying the digital signature and authorization credentials of the event sending node; the time alignment includes associating transaction events, fund events, logistics events and credit events according to the business object identifier and the event time window; the consensus confirmation includes reading the commit status of the permissioned distributed ledger and isolating uncommitted events outside the risk status vector.

[0012] As a preferred technical solution of the present invention, the risk state vector with credibility marker includes event characteristics, event source reliability, time integrity, ledger confirmation, contract current status and the status of the most recent contract execution receipt, wherein the event source reliability, time integrity and ledger confirmation together form the event credibility.

[0013] As a preferred embodiment of the present invention, the risk scoring algorithm maps the risk score to a set of actions allowed within the risk score range. The smart contract state machine outputs a set of state transition actions allowed for the current contract state. The action constraint module intersects the set of actions allowed within the risk score range with the set of state transition actions to form a set of optional actions. The reinforcement learning policy network selects risk control actions only from the set of optional actions.

[0014] As a preferred embodiment of the present invention, the contract call request carries a business object identifier, a ledger status identifier, a strategy version identifier, and an idempotent identifier. The smart contract state machine performs a state transition when the ledger status identifier carried in the contract call request is consistent with the ledger status identifier corresponding to the current contract state and the idempotent identifier has not been processed; and generates a rejection receipt when the two are inconsistent or the idempotent identifier is duplicated.

[0015] As a preferred technical solution of the present invention, the contract execution receipt includes risk control actions, contract status before execution, contract status after execution, execution result, ledger transaction identifier, and execution time; the subsequent performance events include delivery status, repayment status, settlement status, or payment status; the contract execution receipt and the subsequent performance events are associated through business object identifier and ledger status identifier.

[0016] As a preferred technical solution of the present invention, the reward value includes a successful contract state transition component, a false alarm penalty component, a default loss penalty component, and a processing delay penalty component; the state transition sample includes a risk state vector, a risk control action, a reward value, and the next consensus confirmation state, and is written into the experience replay buffer.

[0017] As a preferred embodiment of the present invention, the reinforcement learning policy network employs an online network and a target network. The online network is updated according to the state transition samples extracted from the experience replay buffer, and the target network is synchronized according to a preset update cycle. The policy stability conditions include that the change in validation set loss and the rate of change in control actions do not exceed their respective stability thresholds within the continuous update cycle.

[0018] As a preferred technical solution of the present invention, the multi-node verification includes a parameter digest of the candidate policy version, a fixed verification set output and control action boundaries. The verification node signs the verification result, activates the candidate policy version when the number of passes meets the preset consensus condition, and maintains the previous policy version when the preset consensus condition is not met.

[0019] As a preferred embodiment of the present invention, the sensitive fields in the credit event are retained in the authorized data node, the authorized data node generates zero-knowledge proofs for the risk access conditions, the permissioned distributed ledger verifies the zero-knowledge proofs, and writes the proof verification result and proof summary into the risk state vector; when the proof verification fails, the financing disbursement action is removed from the set of optional actions.

[0020] As a preferred technical solution of the present invention, the smart contract state machine sends financing, liquidation or payment requests through a cross-chain communication interface. The cross-chain communication interface returns a cross-chain execution receipt or a timeout rollback receipt, which is included in the state transition sample as a component of the contract execution receipt.

[0021] As a preferred technical solution of the present invention, the supply chain finance scenarios applied by the Web3 supply chain finance network are accounts receivable financing, order financing, inventory pledge financing or cross-border payment; the risk status vector selects the corresponding transaction event, logistics event and performance event fields according to the scenario, and the risk control actions are executed through a compliant and authorized financial operation interface.

[0022] This invention also discloses an intelligent control system for Web3-based supply chain finance, including an event acquisition interface, a permissioned distributed ledger node, a risk control server, a smart contract execution node, and a financial operation interface; The event acquisition interface is used to receive transaction events, fund events, logistics events and credit events generated by the supply chain business system and IoT nodes, and to send events that have been source-authenticated and time-aligned to the permissioned distributed ledger node; The permissioned distributed ledger node is used to complete event consensus confirmation and send the confirmed event, ledger status identifier and contract current status to the risk control server. The risk control server includes a trusted state construction module, a risk scoring module, a reinforcement learning strategy module, an action constraint module, and a feedback update module. The trusted state construction module is used to generate a risk state vector. The risk scoring module and the current state of the contract together limit the set of optional actions of the reinforcement learning strategy module. The action constraint module binds the selected risk control action with the ledger state identifier and sends it to the smart contract execution node. The smart contract execution node is used to verify contract call requests, execute allowed state transitions, transmit financing or fund control requests through the financial operation interface, and send contract execution receipts to the permissioned distributed ledger node and feedback update module. The feedback update module is used to associate contract execution receipts, subsequent performance events, and the next consensus confirmation status to form state transition samples and update the reinforcement learning strategy module.

[0023] As a preferred embodiment of the present invention, the action constraint module embeds a mixed-integer linear programming solver. After forming the set of optional actions, the action constraint module inputs the set of optional actions, the current funding exposure corresponding to the ledger status identifier, the global liquidity parameters recorded by the permissioned distributed ledger node, and the upstream and downstream node relationships into the mixed-integer linear programming solver to construct a set of constraint equations containing discrete action variables and continuous credit limit variables. The mixed-integer linear programming solver aims to maximize the difference between the overall expected revenue of the supply chain network and the residual default risk loss and credit limit change, calculates feasible optimal action combinations under hard funding constraints, and outputs the feasible optimal action combinations. The discrete action boundary and continuous quota boundary defined by the combination are used as the fourth allowed set; the intersection of the fourth allowed set and the optional action set forms the final execution action set, and the reinforcement learning policy network selects the risk control action only within the final execution action set; when the risk control action is financing approval or quota adjustment, the execution quota of the risk control action is determined by the value of the corresponding continuous quota variable in the feasible optimization action combination; when the mixed integer linear programming solver does not obtain a feasible solution within the preset solution time window, or when the ledger status identifier corresponding to the solution input is inconsistent with the current ledger status identifier, the final execution action set only retains the action of maintaining the current state and the manual review action.

[0024] As a preferred embodiment of the present invention, the objective function is expressed as: ; in, The value is the objective function value, expressed in yuan. This represents the total number of financing nodes involved in the business transaction. For the first The expected rate of return for each financing node is a dimensionless quantity. To be assigned to the The continuous amount variable for each financing node, in yuan; The total number of risk nodes; For the first The expected default loss at each risk point when financing exposure is activated, in yuan; For the first The financing exposure corresponding to each risk node is used as a variable, with a value of 0 or 1. This indicates that financing nodes affected by this risk node are allowed to retain a non-zero quota. This indicates that financing nodes affected by this risk node are prohibited from retaining non-zero quotas or obtaining new quotas; This represents the total number of all financing nodes. For the first The penalty coefficient for changes in the amount of each node is a dimensionless penalty weight, representing the penalty cost corresponding to each unit change in the amount. For the first The absolute change in the current allocation quota of each node relative to the allocation quota of the previous control period, expressed in yuan; auxiliary variables Establishment is performed for each financing node individually. When the amount of a financing node has not changed relative to the previous control period, the solver obtains the solution. The set of constraint equations includes at least: ; For any Established; , , ; in, The global liquidity cap, confirmed by consensus, is expressed in yuan. This represents the total amount of funds currently frozen, expressed in yuan. This represents the total amount of pending funds in the processing state within cross-chain communication interfaces or financial operation interfaces, expressed in yuan. For the first The credit limit for each financing node, in yuan; For the first The set of downstream financing nodes directly affected by each risk node; For the first The allocation amount for each node in the previous control cycle, in yuan; composed of two items regarding... The inequality makes Not less than and The absolute value of the difference is used to represent the change in the quota with a linear constraint.

[0025] Compared with the prior art, the present invention has the following beneficial effects: This invention performs unified source authentication, time alignment, and consensus confirmation on supply chain transaction events, funding events, logistics events, and credit events within a Web3 supply chain finance network. It generates risk state vectors carrying ledger status identifiers, enabling the reinforcement learning strategy network to generate risk control actions only based on trusted states that have completed consensus confirmation. This reduces the probability of unconfirmed events and time-series conflicting events entering the control cycle, minimizing erroneous control due to data inconsistency. The risk scoring algorithm and the smart contract state machine jointly limit the set of selectable actions, allowing the reinforcement learning strategy network to choose risk control actions such as financing approval, credit limit adjustment, risk warning, or fund freezing within the limits allowed by the contract state transition rules and risk scoring range, avoiding out-of-order calls that do not conform to the state transition sequence. Risk control actions are further bound to ledger status identifiers, strategy version identifiers, and idempotency identifiers. The smart contract state machine completes state verification and state transition, reducing duplicate execution and concurrent state conflicts, and improving distributed state consistency.

[0026] This invention associates contract execution receipts, subsequent performance events, and the next consensus confirmation state to form reward values ​​and state transition samples, ensuring that strategy updates correspond to actual performance results. This distinguishes between successful computer execution and correct risk control results, reducing false alarm rates and strategy drift. Further, a mixed-integer linear programming solver transforms the global liquidity cap, frozen funds, outstanding funds, and upstream / downstream node relationships into capital conservation constraints and risk transmission constraints. This provides a secondary constraint on the set of optional actions formed by the action constraint module, ensuring that the risk control actions output by the reinforcement learning strategy network satisfy the capital boundary, thus preventing global liquidity defaults and the accumulation of risk exposure. Overall, this solution improves the traceability and execution reliability of distributed control in supply chain finance. Attached Figure Description

[0027] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained from these drawings without creative effort.

[0028] Figure 1 This is the main flowchart of the method of the present invention.

[0029] Figure 2 This is a flowchart defining the sub-processes for the optional action set of this invention.

[0030] Figure 3 This is a flowchart of the strategy version update and verification sub-process of the present invention.

[0031] Figure 4 This is a flowchart of the sub-process of the limited action set for the mixed integer linear programming solver of the present invention. Detailed Implementation

[0032] In the following description, only certain exemplary embodiments are briefly described. As those skilled in the art will recognize, the described embodiments can be modified in various ways without departing from the spirit or scope of the embodiments of the invention. Therefore, the drawings and description are considered to be exemplary in nature and not restrictive.

[0033] The following is in conjunction with the appendix Figures 1-4 The embodiments of the present invention will be described in detail below.

[0034] In this invention, the Web3 supply chain finance network includes permissioned distributed ledger nodes, smart contract execution nodes, financial operation interfaces, node identity authentication interfaces, and cross-chain communication interfaces. The event collection interface consists of an application programming interface gateway, a message queue access terminal, and an IoT gateway. The permissioned distributed ledger nodes are deployed on servers or cloud computing nodes of core enterprises, financial institutions, logistics companies, and suppliers, while the risk control servers are deployed on independent servers, container clusters, or edge computing nodes.

[0035] The risk control process is jointly implemented by a trusted state construction algorithm, a constrained reinforcement learning strategy algorithm, and a smart contract state machine algorithm. The trusted state construction algorithm outputs a risk state vector and a ledger state identifier; the constrained reinforcement learning strategy algorithm takes the risk state vector as input, and the risk score and contract state as action constraints, outputting a risk control action; the smart contract state machine takes the risk control action as state transition input and outputs a contract execution receipt; the contract execution receipt and subsequent performance events are returned to the trusted state construction algorithm and the reinforcement learning strategy algorithm to form the next state and reward.

[0036] The online control loop and the offline training loop are separated. The online control loop uses the activated policy version to generate risk control actions and does not change the model parameters during a single contract execution. The offline training loop extracts training batches from the state transition samples that have completed consensus confirmation, generates candidate policy versions, and replaces the online policy version after multi-node verification. Through this separation, the intermediate training parameters are prevented from directly affecting the state of the executing contract.

[0037] Step S1: Collect events and construct a credible risk status; the event collection interface receives supply chain event data from the supply chain business system and IoT nodes. Transaction events may include order creation, order modification, invoice confirmation, and accounts receivable transfer; financial events may include credit occupancy, loan requests, repayment confirmation, and settlement results; logistics events may include warehousing, outbound, transportation location, temperature and humidity status, and receipt; credit events may include credit status or verification results output by authorized institutions.

[0038] Each event employs a unified event encapsulation. This unified event encapsulation includes at least a business object identifier, event type, event time, sending node identifier, event sequence number, event payload summary, previous associated event identifier, and digital signature. The business object identifier is used to associate the same financing application or digital debt certificate; the event sequence number and previous associated event identifier are used to detect out-of-order delivery and broken links; and the event payload summary is used to verify content integrity.

[0039] The source authentication unit reads the node's public key and authorization credentials based on the sending node identifier, and verifies the digital signature and event type authorization. Events that fail verification are written to an isolation queue and do not enter the current control cycle; events that succeed in verification enter the time alignment unit. The time alignment unit groups events by business object identifier and sorts them according to event time and event sequence number within the control time window. When a break in event sequence number is detected, the time alignment unit sends a supplementary acquisition request to the event acquisition interface and marks the business object status as incomplete.

[0040] The consensus confirmation unit submits authenticated and aligned events to the permissioned distributed ledger nodes, and reads the event transaction identifier, block identifier, and commit status. The commit status can include pending, sorted, committed, and invalid. Only committed events enter the risk state vector; invalid events enter the isolation queue; pending or sorted events are reserved for reading in the next control time window.

[0041] Event credibility is used to express whether an event can be used as a basis for current control. In one implementation, event credibility is obtained by multiplying source reliability, time integrity, and ledger confirmation: ; in, To control the cycle The Middle The credibility of each event; To control the cycle The Middle The reliability of the source of the event; To control the cycle The Middle The temporal completeness of each event; To control the cycle The Middle The ledger confirmation rate of each event; For controlling the periodic index; This serves as an event index. The event credibility, source reliability, time integrity, and ledger confirmation are all normalized dimensionless quantities, with consistent dimensions on both sides of the formula.

[0042] The trusted state construction module multiplies standardized event features by their corresponding trustworthiness and then concatenates them with the ledger state identifier, the current contract state, the status of the most recent contract execution receipt, and a data integrity marker to form a risk state vector. The ledger state identifier can consist of a channel identifier, block height, and state version. This risk state vector is simultaneously input into both the risk scoring module and the reinforcement learning strategy module.

[0043] For example, a financing transaction might have characteristics such as order amount changes, shipping delays, repayment history, and credit verification results within the control period. After source authentication and consensus confirmation, the trusted state construction module converts these four types of characteristics into a unified dimension and assigns a trust level to each. If a logistics event has not yet been submitted, the trust level of the logistics characteristic is set to zero, and the data integrity flag is set to incomplete. The action constraint module can then remove the financing disbursement action accordingly.

[0044] Step S2: Generate constrained risk control actions; the risk scoring module receives the risk state vector and outputs the risk score and the contribution of each risk item. The risk score does not directly trigger the smart contract; the risk scoring module maps the risk score to an allowed risk level, which serves as one of the action constraints. The risk scoring module can use linear scoring, a decision tree model, or a neural network; the model type does not change the relationship between the risk score as an action constraint and not as the final execution command.

[0045] The reinforcement learning strategy module receives the same risk state vector and uses an online deep Q-network to calculate the value of candidate actions. Candidate actions can include maintaining the financing status, allowing financing, reducing the financing amount, increasing the level of manual review, issuing a risk warning, sending a fund freeze request, and sending a restriction release request. Action types are defined by the compliance authorization interface and the smart contract state machine. The reinforcement learning strategy network cannot generate messages outside the action dictionary. The action dictionary is an enumerated set of executable actions obtained by parsing the state transition table.

[0046] The action constraint module reads the risk score range, the current contract state, the data integrity flag, the permission verification result, and the availability status of the financial operation interface. Based on the contract state transition table, the action constraint module generates a first allowed set; based on the risk score range, it generates a second allowed set; and based on the permissions and data integrity flag, it generates a third allowed set. The intersection of these three sets forms the set of optional actions.

[0047] In the implementation of the mixed-integer linear programming solver, the action constraint module denotes the set of actions allowed by the contract state as the first allowed set, the set of actions allowed by the risk scoring interval as the second allowed set, and the set of actions allowed by permissions and data integrity as the third allowed set; the intersection of the first three allowed sets is the optional action set. The solver takes the fund snapshot corresponding to the ledger state identifier as input and outputs discrete action boundaries and the upper and lower bounds of the continuous amount for each financing node, forming the fourth allowed set. The intersection of the optional action set and the fourth allowed set is the final set of actions to be executed. The solution result, along with the input ledger state identifier, solver version, parameter summary, solution state, feasible solution objective value, and optimality gap, is written into the decision package.

[0048] For example, if the current contract status is "Financing application submitted," the status transition table allows for manual review, approval of financing, or rejection of financing. When the risk score is in the high-risk range, the second permission set excludes approved financing; when credit verification fails, the third permission set excludes approved financing and increases the limit. The strategy network can only select the risk control action with the highest action value from the remaining actions.

[0049] The reinforcement learning policy network employs an online network and a target network. The online network is a deep Q-network used to calculate candidate action values, and the target network is used to calculate the target value. The online network includes an input layer, a first hidden layer, a second hidden layer, and an output layer. The number of nodes in the input layer is consistent with the dimension of the risk state vector. The first hidden layer has 128 nodes, the second hidden layer has 64 nodes, and the activation function is ReLU. The number of nodes in the output layer equals the number of actions in the set of available actions. The online network and the target network use the same network structure. The initial learning rate of the online network is 0.0005, the training batch size is 64, the target network synchronization period is every 200 training steps, and the experience replay buffer capacity is 50,000 state transition samples. In one implementation, the target value of the control period is obtained by adding the current reward value to the discounted action value of the next control period. The discounted action value of the next control period is equal to the discount factor multiplied by the maximum action value output by the target network in the set of available actions in the next consensus confirmation state. The target value, reward value, and action value are all normalized dimensionless quantities, and the discount factor is also dimensionless.

[0050] Online network parameters are updated by minimizing the difference between the value of online network actions and the target value, while target network parameters are synchronized from the online network according to the update cycle. The experience replay buffer stores state transition samples according to the business object identifier and control cycle. Stratified sampling can be used for training batches to allow samples of default, false alarms, contract rejection, and normal performance to be included in the training.

[0051] The risk scoring algorithm and the reinforcement learning policy algorithm interact directly. The risk score output is not executed concurrently with the reinforcement learning output; instead, it alters the set of optional actions for the reinforcement learning. The feedback and performance results after the reinforcement learning actions are executed further change the subsequent risk state and reward. Through this interaction, conflicting control commands from the fixed threshold and the reinforcement learning policy network are avoided.

[0052] Step S3: Bind the state and execute the smart contract state transition; the action constraint module selects a risk control action and generates a contract call request. The contract call request includes at least the business object identifier, risk control action, ledger state identifier, strategy version identifier, idempotency identifier, request time, and request signature. The idempotency identifier can generate a summary based on the business object identifier, control period, action type, and strategy version.

[0053] After receiving a contract call request, the smart contract execution node verifies the request signature and call permissions, and reads the current contract state stored in the permissioned distributed ledger. When the ledger state identifier is inconsistent with the current state version, the smart contract state machine rejects the request and returns the old state action receipt; when the idempotency identifier already exists, the smart contract state machine does not repeat the execution, but returns the original execution receipt or the duplicate request receipt.

[0054] When the ledger state identifiers are consistent and the idempotency identifier has not been processed, the smart contract state machine queries the state transition table. The state transition table records the actions allowed for each contract state and the target state after each action. For example, the "financing application submitted" state can receive actions such as entering manual review, approving financing, or rejecting financing; the "financing approved" state can receive actions such as adjusting the amount, issuing a risk warning, or sending a fund freeze request; the "settled" state no longer receives fund freeze requests.

[0055] When state transition is permitted, the smart contract state machine first writes the idempotency flag and the pending execution state into the ledger transaction, and then sends a control message to the financial operation interface. The financial operation interface can connect to a bank's core system, a supply chain financing platform, a digital debt instrument platform, or a compliant cross-border payment gateway. The financial operation interface returns an accept, reject, processing, or timeout status, and the smart contract state machine completes the target state writing or execution rollback based on the interface status.

[0056] The contract execution receipt records the contract status before execution, the request action, the contract status after execution, the interface result, the reason for rejection, the ledger transaction identifier, and the execution time. The contract execution receipt is written to the permissioned distributed ledger and sent to the feedback update module. The risk status monitoring interface can read the contract execution receipt for display; input on the interface does not reverse the risk control actions.

[0057] For cross-chain financing, clearing, or payment requests, the smart contract state machine writes the source chain state identifier, the target chain request identifier, and the timeout condition into the contract call request. The cross-chain communication interface returns a cross-chain execution receipt or a timeout rollback receipt. Both types of receipts are entered into the feedback update module to avoid only recording successful cross-chain transactions while ignoring timeout failures.

[0058] Step S4: Feedback samples are formed from execution receipts and performance events; the feedback update module receives contract execution receipts and subsequent performance events, using the business object identifier and ledger status identifier as the primary association keys. The subsequent performance events enter the same source authentication, time alignment, and consensus confirmation process through the event collection interface. Only delivery status, repayment status, settlement status, or payment status that has completed consensus confirmation is used to correct rewards.

[0059] Execution receipts generate immediate result components. A success component is generated when a state transition is successful and the interface accepts it; penalty components are generated for actions in the old state, duplicate requests, insufficient permissions, or interface rejection. Subsequent fulfillment events generate delayed result components; fulfillment on schedule generates a positive component, while overdue, default, liquidation rollback, or payment rollback generates a penalty component. False alarms generate false alarm penalty components after confirmation by authorized review events.

[0060] In one implementation, the reward value consists of a successful execution component, a malfunction component, and a processing latency component: ; in, To control the cycle The reward value; Weighting of execution and fulfillment success factors; The penalty weight for erroneous actions; Penalty weights for handling delay components; To control the cycle The weight of successful execution and performance; To control the cycle The weight of false warnings, defaults, or illegal actions; To control the cycle Normalization processing latency; To control the periodic index, all components and weights are dimensionless, the reward value is dimensionless, and the dimensions on both sides of the formula are consistent.

[0061] The reward weights are constrained by technical metrics on a fixed validation set, and do not directly aim at maximizing profits as the sole objective. Validation metrics may include the proportion of error control actions, false alarm rate, illegal state transition request rate, repeated execution rate, and processing latency. After adjusting the reward weights, the fixed validation set needs to be rerun, and the multi-node validation module needs to confirm that the action boundaries have not been violated.

[0062] The feedback update module reads the next consensus confirmation state after contract execution and encapsulates the previous risk state vector, actual execution action, reward value, and next consensus confirmation state into a state transition sample. If a subsequent performance event has not yet occurred, the state transition sample can first save the immediate receipt component and mark it as pending correction; after the performance event occurs, the reward value is updated through the association key to prevent execution success from being regarded as final performance success.

[0063] State transition samples are entered into the experience replay buffer. The experience replay buffer retains the sample version, associated ledger transaction identifier, and reward correction record. The training module only reads samples whose rewards have stabilized or reached a preset observation window, which is determined by the performance period of the financing product and configured accordingly.

[0064] Step S5: Update and verify the strategy version; the training module extracts samples from the experience replay buffer according to the update plan. Training data is deduplicated according to ledger transaction identifiers and divided into training and fixed validation sets in chronological order to prevent information leakage caused by adjacent periods of the same business object entering both sets simultaneously. After the online network update is complete, candidate strategy parameters and parameter summaries are generated.

[0065] The multi-node verification module sends candidate policy parameters or security computation shards to the verification nodes. Each verification node uses the same fixed verification set to calculate the error control action ratio, false alarm rate, illegal state transition request rate, repeated execution rate, and processing latency, and checks whether the candidate policy output is always within the set of optional actions given by the action constraint module.

[0066] Verification nodes sign the parameter digest, indicator digest, and boundary check results, and the permissioned distributed ledger records the verification results. When the verification results meet the consensus conditions, the policy version management unit marks the candidate policy version as activated and sends the policy version identifier to the action constraint module; when the verification results do not meet the consensus conditions, the candidate policy version is marked as rejected, and online control continues to use the previous policy version.

[0067] The policy stability condition uses both the change in validation set loss and the rate of change of actions. For example, if the change in validation set loss does not exceed a preset stability threshold within 5 consecutive update cycles, and the rate of change of actions on the fixed validation set does not exceed another stability threshold, the current round of training can be terminated; training also terminates when the maximum number of updates is reached.

[0068] After activation, the new online control cycle reads the activated policy version, the latest ledger status identifier, and the current contract status. Requests generated with the old policy version but not yet executed undergo policy version and ledger status identifier verification at the smart contract execution node. Requests that fail verification return a rejection receipt, which serves as a negative sample in the feedback loop.

[0069] Furthermore, the unified event encapsulation adopts a versioned data structure. The event structure version, event type version, and payload digest algorithm version are recorded separately, and the event acquisition interface verifies the structure version before parsing. Unrecognizable structure versions enter a compatibility queue, where a version converter transforms them according to the registered mappings; events without registered mappings enter an isolation queue. Version transformation retains the original event digest, the transformed digest, and the transformation rule version, enabling the risk state vector to be traced back to the original event and preventing the loss of origin due to interface upgrades.

[0070] The business object identifier is jointly determined by the supply chain financing object and the financing cycle. Order changes, debt transfers, repeated financing applications, or renewal financing cannot rely solely on enterprise identifiers to avoid events from different financing cycles entering the same state. The event correlator establishes a mapping between business object identifiers, upstream document identifiers, ledger transaction identifiers, and contract instance identifiers. After the mapping is written into the permissioned distributed ledger, the feedback update module searches for execution receipts and fulfillment events according to the mapping.

[0071] The time alignment unit simultaneously stores the event time and the ledger reception time. The event time is used to restore the order of supply chain transactions, while the ledger reception time is used to determine network latency and retransmissions. Records with the same event time but different event numbers are sorted according to their event numbers; records with the same event number but different payload digests are marked as conflict events. Conflict events do not enter the current state; the conflict digest and the sending node identifier are written to the exception record for the node permission module to adjust the source reliability.

[0072] The risk state vector uses a fixed field dictionary and a missing field flag. The field dictionary records the field name, data type, standardization method, allowed range, source event type, and effective version. When a field has not been confirmed through consensus, the trusted state construction module does not replace the true value with zero; instead, it writes a missing field flag and sets the corresponding event's trustworthiness to zero. The action constraint module reads the missing field flag and removes actions that depend on the missing field based on the set of fields required for the action.

[0073] The risk scoring range is not used as an independent execution threshold. The risk scoring module maps continuous scores to low risk, medium risk, high risk, and insufficient data states, and the mapping rules have versioning. The action constraint module sequentially intersects the actions allowed by the risk range, the actions allowed by the contract state, the actions allowed by data integrity, and the actions allowed by permissions. When any allowed set is empty, the system outputs a manual review action or maintains the current state action, without sending a fund change request to the financial operation interface.

[0074] The contract state transition table consists of state, input action, preconditions, target state, failure state, and receipt type. The preconditions include ledger state version, access permissions, idempotent state, and availability of the financial operation interface. The state transition table version is written to the contract instance, and the reinforcement learning policy network only reads the action dictionary consistent with the contract instance version. During contract upgrades, the old contract instance continues to use the old action dictionary until the migration is complete, preventing the policy version from taking effect before the contract version.

[0075] The contract execution receipt uses an immutable receipt header and an appendable result segment. The receipt header records the business object identifier, contract call request summary, pre-execution state, initial execution result, and ledger transaction identifier; the appendable result segment records asynchronous confirmation, cross-chain confirmation, or timeout rollback of the financial operation interface, with each append reference to the previous result segment summary. The feedback update module reads the complete receipt chain and only marks the execution result component as stable when the final result segment reaches the completion, rejection, or rollback state.

[0076] Performance event association employs three conditions: business object identification, financing cycle, and responsibility stage. Delivery events only correct state transition samples associated with the delivery stage, repayment events only correct samples associated with the repayment stage, and settlement receipts only correct samples associated with the settlement action. When no unique associated sample can be found, the performance event enters the pending association queue, and is not automatically matched according to the nearest time principle to avoid contamination of delayed results from different financing objects.

[0077] Reward correction records do not overwrite original rewards. The feedback update module saves immediate rewards, each delay correction, correction event identifier, and stable rewards. The training module selects stable rewards according to the sample reading time; samples that are not yet stable can enter the observation buffer but not the formal training batch. In some preferred embodiments, the performance observation window is configured according to the term of the financing product; configuration changes only affect new samples and do not retroactively change the training data used by the already activated strategy version.

[0078] The experience replay buffer is partitioned according to policy version and data version. Each sample carries the version of the state field dictionary, contract state transition table, reward rule, and policy. Training batches do not mix incompatible data versions. When cross-version training is required, the version converter first converts the old samples to the target field dictionary and generates a conversion record; samples that cannot be converted remain archived. Version partitioning ensures that when the policy reverts to an older version, the corresponding training and validation basis can be found.

[0079] Multi-node validation not only compares model losses but also performs action boundary replay. Each validation node simultaneously inputs each risk state vector from the fixed validation set into the risk scoring module, action constraint module, and candidate policy network to check whether the action selected by the candidate policy belongs to the set of available actions. If action boundary replay fails, the candidate policy version cannot be activated even if the validation loss decreases. The validation results save the failure sample identifiers, and the training module can increase the sampling weight of the corresponding state transition samples in the next round.

[0080] Policy version rollback is triggered by the ledger status. The online monitoring module calculates the error control action ratio, contract rejection rate, duplicate request rate, and interface timeout rate; these metrics characterize the technology's operational status. When any metric exceeds a preset rollback threshold, the policy version management unit generates a rollback proposal. After the verification node confirms the rollback proposal, it activates the previous policy version and writes the rollback receipt as a model version event to the permissioned distributed ledger.

[0081] A signed message channel is used between the risk control server and the smart contract execution node. This message channel stores the request sending time, receiving time, number of retries, and channel status. In the event of a network interruption, the risk control server does not generate a new idempotency flag; instead, it resends the request using the original idempotency flag. The smart contract state machine returns the original response based on the idempotency record, preventing network layer retries from triggering new fund control actions.

[0082] When a temporary divergence occurs among nodes in a permissioned distributed ledger, the risk control server reads the commit state that meets the consortium's confirmation conditions, without using the local pre-commit state of a single node. If the confirmation conditions are not met within the control time window, the trusted state construction module retains the previous confirmed state and writes a state stale flag. The action constraint module, based on the state stale flag, only retains the actions of maintaining the current state and manual review, and resumes automatic control after the new state is confirmed.

[0083] System logs are categorized into security audit logs, model decision logs, and business receipt logs. Security audit logs record authentication, permission changes, and signature failures; model decision logs record state summaries, policy versions, action values, and sets of optional actions; and business receipt logs record contract state transitions and financial operation interface results. These three types of logs are linked through business object identifiers and ledger state identifiers, allowing the audit process to replay individual control cycles without reading sensitive vendor plaintext.

[0084] The risk status monitoring interface retrieves model version, ledger confirmation status, set of optional actions, contract execution receipt status, and number of exception queues from a read-only query interface. This interface does not provide a write path for directly modifying strategy parameters or contract status. When manual review is required, the review terminal generates a review event with an identity signature. This review event still needs to undergo event collection, source authentication, and consensus confirmation, and cannot bypass the core data closed loop.

[0085] When event quality degrades, the event acquisition interface can send a re-acquisition request to a specific acquisition node. The re-acquisition request includes the business object identifier, the missing event type, the missing time period, and the original event sequence number range. Re-acquiring events do not overwrite existing events; instead, they are written with new event sequence numbers and reference the supplemented event range. The time alignment unit recalculates the time integrity, and after the consensus confirmation unit completes its submission, the trusted state construction module updates the risk state vector in the next control cycle.

[0086] The risk scoring module stores the scoring model version and feature dictionary version. In addition to the risk range, the scoring model output includes a data insufficiency flag and the scoring time. When the scoring model version is incompatible with the risk state vector feature dictionary version, the action constraint module does not expand the automatic action range using the risk range, but only retains the actions of maintaining the current state and manual review. The version compatibility table is maintained by the policy version management unit and written into the configuration summary.

[0087] When only one action remains after the risk score range and the allowed set of contract states intersect, the policy network still records the action value of this unique action but does not change the action through random exploration. When multiple allowed actions exist, the policy network can select an exploration action according to the training mode; in the online control mode, it uses the activated policy to determine the action. The exploration actions generated in the training mode are only executed in the test environment or authorized sandbox contract and do not directly enter the production financial operation interface.

[0088] The smart contract state machine sets the "processing" state for asynchronous financial operations. When the financial operation interface accepts a request but has not yet completed it, the contract state changes from "pending execution" to "processing," and repeated requests return a "processing" receipt. After the interface returns a completion message, the contract transitions to the "completed" state; after the interface returns a rejection message, it transitions to the "failed" state; if the timeout condition is exceeded, the contract enters the rollback processing state, and after the compensation action is completed, it transitions to the "rollback completed" state. Each state transition generates a corresponding receipt segment.

[0089] The messages returned by the financial operation interface include an interface request identifier, processing status, result summary, and message signature. The smart contract execution node verifies the message signature and checks the interface request identifier to prevent asynchronous messages from other business objects from altering the current contract. The result summary corresponds to the original result stored by the financial operation interface. The permissioned distributed ledger only stores the fields and summaries required by the business logic; sensitive plaintext is stored in the authorization system according to permissions.

[0090] The replay tool reads the unified event, risk status summary, optional action set, selected action, contract call request, and replay chain in the order of ledger transactions. The replay tool uses the field dictionary, state transition table, and policy version for the corresponding control period, and does not replace historical configurations with the latest current configuration. The replay result is used to verify whether a risk control action was generated based on a state that was visible and confirmed at the time.

[0091] State transition sample deletion or correction is recorded appendedly. When an event source is found to be revoked, the receipt association is incorrect, or the fulfillment label is incorrect, the authorized node submits a sample correction event. The feedback update module verifies the correction permission and the original sample identifier, generates a new sample version, and marks the old version as not participating in training. Policy versions already generated using old samples retain the training data summary, and the policy version management unit decides whether to re-verify or roll back based on the scope of impact.

[0092] The fixed validation set is stratified according to business status and exception type, including normal fulfillment, delayed fulfillment, missing event, stale status, duplicate requests, permission failure, interface timeout, and rollback samples. The validation set is only replaced during authorized version updates, and a summary of the old validation set is saved. Candidate policy versions must satisfy the action boundaries on each stratified sample, and the overall metric is not allowed to mask out-of-bounds actions of a certain exception type.

[0093] The zero-knowledge proof verification result includes a verification pass flag, a proof digest, a verification condition version, and a valid time window. The risk state vector does not contain the sensitive primitives corresponding to the proof. After the verification condition version changes, the old proof cannot automatically extend its validity period; the event collection interface requests authorized data nodes to generate a new proof. The action constraint module maintains a data insufficiency state until the new proof is confirmed through consensus, preventing the use of expired proofs to relax the action set.

[0094] The cross-chain communication interface establishes a source-side locking state, a target-side confirmation state, and a timeout state for each cross-chain request. The source-side state only transitions to completion after the target-side confirmation message completes signature verification and is written to the permissioned distributed ledger. If the target-side fails to confirm within the timeout period, the source-side executes a rollback and generates a timeout rollback receipt. The feedback update module calculates latency and failure components using the complete cross-chain receipt chain to prevent a single intermediate success message from being mistaken for final payment completion.

[0095] When node permissions change, the permission management node submits a permission change event. This event includes the node identifier, allowed event types, allowed action scope, effective ledger status, and permission version. The source authentication unit reads the permission version according to the ledger status corresponding to the event, without using the current permission to trace and determine historical events. The action constraint module updates the set of allowed actions after the permission change is confirmed through consensus; contract call requests that have been generated but not yet executed need to undergo permission verification again.

[0096] The system clock is jointly verified by the node's local clock and the ledger sorting time. When the local clock deviation exceeds the allowable range, events can still be received, but time integrity is reduced, triggering a node clock correction notification. The ledger sorting time is used to determine the order in which events enter the control cycle and does not directly cover the time when the service occurs. Dual time recording allows for separate analysis of network latency and service latency and reduces out-of-order states caused by clock drift.

[0097] Both model and contract configurations use incremental version identifiers. Deleting a configuration writes it to a disabled state, and the already disabled version identifier is not reused. State transition samples, execution receipts, and audit logs always save the corresponding version, enabling subsequent verification nodes to load the same configuration and reproduce action boundaries. If configuration storage is corrupted or a version is missing, online control enters a secure hold mode, allowing only the current state to be maintained and manual review actions to be performed. State changes and recovery processes generated in secure hold mode are all written to a permissioned distributed ledger.

[0098] Business event revocation does not delete the original event. Authorized business nodes submit revocation events, which reference the original event identifier, revocation reason, authorization credentials, and effective status. After consensus confirmation of the revocation event, the trusted state construction module reduces or removes the original event's contribution to subsequent states, while retaining both the pre- and post-revocation state versions. Contract call requests generated based on the pre-revocation state but not yet executed will be rejected due to inconsistencies in the ledger state identifiers; rejection receipts enter the feedback loop.

[0099] Before entering the risk status vector, the status of funds and claims undergoes a conservation check. This check compares the credit limit, disbursed amount, repaid amount, frozen amount, and available credit for the same business entity, and also compares the status of claim generation, transfer, pledge, release, and settlement. If the checks are inconsistent, a status conflict flag is written, and the action constraint module removes the release, credit limit increase, and restriction removal actions, retaining only the status maintenance, risk warning, and manual review actions to prevent the model from using inconsistent balances to generate control requests.

[0100] In practical implementation, the system generates a decision package for each control cycle. The decision package includes a set of input event identifiers, a field dictionary version, a risk state summary, a scoring model version, a strategy version, a set of optional actions, the selected action, a contract state transition table version, a contract call request summary, and an execution receipt identifier. When a mixed-integer linear programming solver is enabled, the decision package also includes a solution input ledger state identifier, a solver version, a parameter summary, a solution state, a feasible solution objective value, and an optimality gap. The decision package summary is written to a permissioned distributed ledger, allowing authorized audit nodes to retrieve the corresponding data and replay the processing procedure based on the summary.

[0101] To facilitate a better understanding of the present invention by those skilled in the art, the present invention will be further illustrated below with reference to specific implementation examples.

[0102] Example 1: In this example, the system receives order events, invoice confirmation events, logistics receipt events, credit occupancy events, and credit verification events for a specific accounts receivable financing business object. The event collection interface verifies the signatures and groups them according to the business object identifier. The permissioned distributed ledger node completes the event submission, and the trusted state construction module reads the submitted events and forms a risk state vector.

[0103] The risk scoring module outputs a risk score range, while the reinforcement learning strategy module outputs the value of five candidate actions: maintain, release, reduce, warn, and freeze requests. The action constraint module reads the current contract status. A submitted financing application status allows for release, manual review, or rejection, but not freeze requests; an approved financing status allows for reduction, warning, or freeze requests. The risk score range and the status transition table together form the set of selectable actions.

[0104] When the reinforcement learning strategy module selects a reduction action, the action constraint module binds the reduction action to the business object identifier, ledger status identifier, strategy version identifier, and idempotency identifier. The smart contract execution node verifies that the current status is that the financing has been approved and the idempotency identifier has not been processed, sends a limit adjustment message to the financial operation interface, and writes the interface acceptance result into the contract execution receipt.

[0105] After subsequent repayment events are confirmed through consensus in the permissioned distributed ledger, the feedback update module associates the repayment event with the contract execution receipt. When repayment is made on time, the execution success component is positive; if manual review determines the original warning was a false alarm, a false alarm penalty component is added. The feedback update module generates state transition samples and writes them into the experience replay buffer.

[0106] For example, the trusted state construction module obtains four normalized event features: source reliability of 1 for all four, time integrity of 1, 1, 0.8, and 1 respectively, and ledger confirmation of 1, 1, 1, and 1 respectively. According to the event trustworthiness formula, the four trustworthinesses are 1, 1, 0.8, and 1 respectively. The third feature has its weight reduced due to the event sequence number gap, and the action constraint module retains the manual review action.

[0107] The training module updates the online network using state transition samples to generate candidate policy versions. Three verification nodes confirm the candidate policy parameter summary, fixed validation set output, and action boundary signatures; once consensus conditions are met, the candidate policy version is activated. In some preferred embodiments, the number of verification nodes is determined based on the number of consortium members and the security policy.

[0108] Example 2: This example shares the same core state, action, execution, and feedback chain as Example 1, but adds edge event aggregation, zero-knowledge proof pre-gating, and multi-node policy verification. IoT nodes send logistics events to edge computing nodes, which perform format validation, event digest deduplication, and timestamp correction before sending the events to the event acquisition interface.

[0109] Supplier financial fields are stored in the authorized data nodes, which generate zero-knowledge proofs for the accounts receivable range, credit status, and transaction authenticity conditions. Permissioned distributed ledger nodes verify these zero-knowledge proofs and write only the verification result, proof summary, and verification time to the credit event. The trusted state construction module incorporates the proof verification result as part of the risk state vector.

[0110] If the proof verification fails or the proof exceeds the valid time window, the action constraint module removes the financing release action from the set of optional actions. The smart contract execution node can still accept requests for supplementary materials or enter the manual review action. The proof verification result affects both the model state and the contract action boundary.

[0111] When candidate policy versions are verified through multi-party secure computation, each verification node holds a parameter shard or a verification result shard. The verification result summary, signature, and policy version identifier are written to the permissioned distributed ledger. The online control node only loads policy versions that are already activated.

[0112] If an edge computing node detects a broken event sequence number, it issues a re-collection request and sets the data integrity flag to incomplete. The risk state vector retains the data integrity flag, and the action constraint module prohibits the release of actions. After the event re-collection is completed and confirmed by consensus, the set of allowed actions is restored in the next control cycle.

[0113] Example 3: This example shares the same core closed loop as Example 1, but differs in that the supply chain finance scenario involves accounts receivable financing and payment for cross-border electronic product supply chains. Transaction events include purchase orders, electronic invoices, and receivables confirmation status; logistics events include outbound shipment, cross-border transportation milestones, and receipt; and funding events include loan disbursement, cross-border payment requests, and settlement confirmation.

[0114] The risk control server constructs a risk state vector based on the events confirmed through consensus. The risk scoring module outputs a risk range, and the reinforcement learning strategy module outputs actions such as maintaining, reducing, issuing warnings, or suspending payments. The action constraint module reads the current state of the cross-border payment smart contract and the channel availability status returned by the compliance interface, and removes currently unexecutable actions.

[0115] Cross-border payment requests carry the source chain status identifier, the target channel request identifier, and timeout conditions. The cross-chain communication interface returns a success receipt, a processing receipt, or a timeout rollback receipt. Both success receipts and timeout rollback receipts are written to the permissioned distributed ledger and enter the feedback update module.

[0116] For example, a payment request first returns a "processing" receipt. The feedback update module only generates an immediate state sample and marks it as pending correction. After the target channel completes settlement, it returns a success receipt. The event acquisition interface submits the success receipt as a funding event to the ledger, and the feedback update module updates the reward and generates a stable state transition sample. If the timeout condition is exceeded, the timeout rollback receipt generates a latency penalty and an execution failure component.

[0117] Comparative Example 1: Using the same event input, source authentication, time alignment, ledger confirmation, risk scoring, reinforcement learning policy network, smart contract, and feedback observation window as Example 1, only the constraint of the current contract state on the set of selectable actions is removed. The policy network can select actions from the entire action dictionary, and the smart contract state machine rejects actions that do not conform to the current state at the execution end.

[0118] When using the same set of four normalized event features and the same policy parameters, the policy network selects the freeze request action when the financing application has been submitted. In Example 1, the action constraint module removes the freeze request action before policy selection and selects manual review; in Comparative Example 1, the freeze request is sent to the smart contract execution node, the smart contract state machine rejects the request and generates a retry.

[0119] Within 10 consecutive control cycles, Comparative Example 1 generated 2 illegal state transition requests and 1 repeated retry, while Example 1 generated no illegal state transition requests, reducing the illegal state transition request rate from 20% to 0. Except for contract state action constraints, input and processing remained consistent; the degradation stemmed from deleting action constraints.

[0120] Comparative Example 1 shows that rejecting illegal actions only at the smart contract execution end increases the amount of invalid requests and receipt processing. Risk scoring and contract state jointly constrain the action set before strategy selection, which can directly reduce out-of-order calls.

[0121] Comparative Example 2: Using the same event input, trusted state construction, risk scoring, action constraints, smart contract state transitions, and training cycle as Example 1, the only change is that contract execution receipts and subsequent performance events are not included in the reinforcement learning state transition samples, and the policy network only uses changes in risk scores to constitute rewards.

[0122] When using the same input, a risk warning was confirmed as a false alarm after manual authorization and review. Example 1 associates the false alarm review event with the contract execution receipt and generates a false alarm penalty; Comparative Example 2 does not receive a review event, but still treats the successful generation of the warning record by the contract as a positive result.

[0123] In 20 state transition samples, Comparative Example 2 issued 6 warning actions for similar states, of which 3 were subsequently identified as false warnings; Example 1 issued 3 warning actions for similar states after reward correction, of which 1 was subsequently identified as a false warning. Except for acknowledgments and fulfillment feedback, the input, model structure, and training batches remained consistent.

[0124] Comparative Example 2 demonstrates that successful contract execution cannot replace effective risk control. By combining execution receipts, subsequent performance events, and the next confirmation status into a sample for rewards and state transitions, the model can distinguish between successful technical execution and subsequent performance outcomes.

[0125] For example, an accounts receivable financing transaction generates four standardized event characteristics during control period 1, with values ​​of 0.6, 0.8, 0.5, and 0.7 respectively. The reliability of all four sources is 1, the time completeness is 1, 1, 0.8, and 1 respectively, and the ledger confirmation is 1 for all four. According to the event credibility formula, the four credibility levels are 1, 1, 0.8, and 1 respectively; the weighted average of the four characteristics is 0.6, 0.8, 0.4, and 0.7 respectively.

[0126] The trusted state construction module concatenates four weighted features with the ledger state identifier, the submitted financing application status, and the most recent receipt status to form a risk state vector. The risk scoring module outputs the risk range from the risk state vector. The contract state transition table allows for manual review, financing approval, and financing rejection. The risk scoring range removes the direct financing approval action, leaving only manual review and financing rejection in the optional action set.

[0127] The online deep Q network outputs an action value of 0.4 for the manual review action and 0.1 for the financing rejection action. The strategy module selects the manual review action. The action constraint module generates a contract call request and attaches the current ledger status identifier, strategy version identifier, and idempotency identifier. After the smart contract state machine verifies the status and idempotency identifier, it transfers the contract status from "financing application submitted" to "manual review".

[0128] The contract execution node generates a success receipt, which is then manually reviewed and confirmed to be consistent with the order and logistics events. The financing status for the next control cycle is then changed to allow release. Let the successful execution and fulfillment component be 1, the erroneous action component be 0, and the normalized processing latency be 0.2; the three reward weights are 0.6, 0.3, and 0.1 respectively. According to the reward formula, the reward value is 0.58.

[0129] Let the maximum target network action value among the possible actions in the next state be 0.5, with a discount factor of 0.95. Following the aforementioned target value calculation rules, the target value is 1.055. The training module uses 1.055 as the update target for the online network's action value for this time, thus obtaining the candidate policy parameters.

[0130] The feedback update module encapsulates the risk state vector of control cycle 1, the manual review action, the 0.58 reward value, and the next consensus confirmation state into a state transition sample. This state transition sample is written into the experience replay buffer, and the associated ledger transaction identifier and contract execution receipt identifier are also saved.

[0131] Candidate policy versions pass action boundary checks on a fixed validation set and are activated after being signed by validation nodes that meet the consensus conditions. Control cycle 2 reads the new policy version and the latest ledger state. If the same idempotent flag arrives again, the smart contract state machine returns a repeat request receipt without repeating the state transition. The closed loop enters the subsequent control cycle after the receipt completes consensus confirmation.

[0132] Example 4: This example further discloses an action constraint module with an embedded mixed-integer linear programming solver and its operating mechanism. When processing concurrent financing requests from multiple suppliers, supply chain finance networks relying solely on reinforcement learning strategies may, due to exploration mechanisms or local strategy biases, generate quota combinations exceeding the global liquidity limit or accumulate risk exposure. This example introduces a mixed-integer linear programming solver in the action constraint stage to establish funding boundaries and risk transmission boundaries for the reinforcement learning strategy network.

[0133] The system deploys a mixed-integer linear programming solver employing linear relaxation, branch and bound, and feasible solution search processes in the action constraint module of the risk control server. The risk scoring module outputs a risk score interval, and the smart contract state machine outputs the set of state transition actions allowed for the current contract state. The action constraint module intersects the set of actions allowed for the risk score interval, the set of state transition actions, and the set of actions allowed for permissions and data integrity to initially form a set of optional actions. This set of optional actions does not yet include the concurrent capital occupation and topological transmission relationships between risk nodes across the entire supply chain. The action constraint module reads the current capital exposure, the related transaction network matrix of upstream and downstream enterprises, the global liquidity limit, the total amount of frozen funds, and the total amount of outstanding funds corresponding to the current ledger state identifier from the permissioned distributed ledger node via a remote procedure call interface.

[0134] The mixed-integer linear programming solver receives the above input parameters and constructs a system of constraint equations in memory. For the... At each risk node, the solver sets up a variable to enable financing exposure. , This indicates that financing nodes affected by this risk node are allowed to retain a non-zero quota. This indicates that financing nodes affected by this risk node are prohibited from retaining non-zero quotas or obtaining new quotas. For the [missing information]... Each financing node, the solver is set with continuous quota variables. ,in This represents the credit limit for the financing node as confirmed by the permissioned distributed ledger. Risk warnings and manual review actions do not directly increase the fund balance; they remain within the set of optional actions and are selected by the reinforcement learning policy network from the final set of actions to be executed.

[0135] The objective function set by the system is used to balance capital turnover efficiency, residual default risk loss, and cross-cycle quota changes, and is expressed as: ; in, The value is the objective function value, expressed in yuan. This represents the total number of financing nodes. For the first The expected rate of return for each financing node is calculated based on historical performance events that have been confirmed through consensus, and is a dimensionless quantity. To be assigned to the The continuous amount variable for each financing node, in yuan; The total number of risk nodes; For the first The expected default loss at each risk point when financing exposure is activated, in yuan; For the first Variables are activated for the financing exposure corresponding to each risk node; This represents the total number of all financing nodes. For the first The penalty coefficient for changes in the amount of each node is a dimensionless penalty weight, representing the penalty cost corresponding to each unit change in the amount. For the first The absolute change in the current allocated quota of each node relative to the allocated quota of the previous control period, expressed in yuan. Auxiliary variable. Establishment is performed for each financing node individually. When the amount of a financing node has not changed relative to the previous control period, the solver obtains the solution. The first item represents the expected return, the second item represents the expected default loss corresponding to the activation of financing exposure, and the third item represents the penalty for changes in the amount. All three items are in yuan.

[0136] The constraint equations are based on the conservation of capital flows. The liquidity conservation constraint limits the total funds allocated within a single consensus confirmation period: ; in, This is the global liquidity cap confirmed through consensus. This represents the total amount of funds currently frozen in the smart contract state machine. This refers to the total amount of outstanding funds currently being processed in the cross-chain communication interface or financial operation interface; the above parameters and The unit for all values ​​is yuan.

[0137] Risk transmission constraints link the financing exposure activation variable with the continuous credit limit variable: For any Established; in, Indicates the subject of the first A risk node directly affects the set of downstream financing nodes. When At that time, the continuous credit limit variable of downstream financing nodes directly affected by this risk node. Limited to 0; when hour, Still subject to credit limits It is constrained by both the liquidity conservation constraint and other factors.

[0138] To represent the absolute change in the quota with linear constraints, the solver introduces a non-negative auxiliary variable. And set: ; ; ; The above two difference constraints make Not less than and The absolute value of the difference; due to the objective function on A negative penalty is applied, and the solver selects the minimum value that satisfies the constraints, all other things being equal. This allows us to obtain the absolute change in the credit limit without introducing nonlinear absolute value calculations into the solver.

[0139] The mixed-integer linear programming solver iterates within a preset solution time window. When the solver finds a solution that satisfies the optimality tolerance within the time window, it outputs the feasible optimal solution and the optimality gap; if the optimality tolerance is not met but a feasible solution has been found, it outputs the current feasible solution and the corresponding optimality gap; if no feasible solution is found, it outputs a state that no feasible solution is found. The solver outputs... and A feasible optimized action combination is formed. The action constraint module converts this combination into a fourth allowable set, which records both the allowed discrete actions and the continuous limit of each financing node. For example, when the solution results limit the limit of a financing node to 30% of the original application amount, the fourth allowable set removes the full financing disbursement action for that node, and only retains partial limit adjustment actions, reduction actions, and allowable actions that do not change the fund balance, not exceeding the limit.

[0140] Fourth, the set of actions is intersected with the initially generated set of optional actions to generate the final set of actions to be executed. The reinforcement learning policy network reads the final set of actions to be executed and calculates the action value of each candidate action in the set. It selects a risk control action only within the action space that satisfies the constraints of capital conservation and risk transmission. When the selected risk control action is financing approval or quota adjustment, this risk control action carries the continuous quota variable values ​​output by the solver for the corresponding financing node. When the selected risk control action is risk warning, fund freeze, maintaining the current state, or manual review, this risk control action will not increase the corresponding financing node's limit. The selected risk control action also carries a business object identifier, ledger status identifier, strategy version identifier, and idempotency identifier, and the smart contract state machine completes the state verification and state transition. When the final set of executed actions is empty, the solver does not obtain a feasible solution, or the ledger status on which the solution is based has changed, the action constraint module only outputs the "maintain current state" action or the "manual review" action, and does not send a fund change request to the financial operation interface.

[0141] For example, suppose there are 3 financing nodes within a control period, and the expected rate of return is... , , The credit limits are 0.08, 0.06, and 0.05 respectively. , , The respective limits are 4 million yuan, 3 million yuan, and 2 million yuan; the overall liquidity cap confirmed by consensus. The amount is 7 million yuan, and the funds have been frozen. The outstanding amount is 1 million yuan. If the allocation is 500,000 yuan, then the total distributable funds for this period shall not exceed 5.5 million yuan. Let's assume the allocation limit from the previous control period... Ten thousand yuan, Ten thousand yuan, 10,000 yuan; penalty coefficient for changes in quota , , If the first risk node directly affects the second and third financing nodes, and the solver sets... ,but and All are limited to 0; if ,but and Not exceeding 3 million yuan and 2 million yuan respectively, and with Together, they satisfy the liquidity conservation constraint that the total amount does not exceed 5.5 million yuan. This example illustrates how the activation variable of financing exposure can change the continuous limit boundary through risk transmission constraints.

[0142] To verify the above mechanism, a comparative test was conducted on a set of 90 consecutive days of permissioned distributed ledger replay data, including 450,000 transaction events, 120,000 logistics events, and 50,000 smart contract state transition requests. The system ran in parallel a baseline model (i.e., a reinforcement learning control model without a solver) and an optimized model (i.e., the control method disclosed in this embodiment). Test metrics included the illegal state transition request rate, the proportion of erroneous control actions, the frequency of severe cross-cycle quota oscillations, the invalid exploration rate of reinforcement learning actions, the proportion of global liquidity default samples observed within the replay dataset, the average processing latency for a single action generation, and the number of retries triggered by contract rejection. Specific results are recorded in Table 1.

[0143] Table 1. Comparison of control effects between mixed-integer linear programming constrained reinforcement learning and reinforcement learning;

[0144] Note: The baseline model is a reinforcement learning control model without introducing a mixed-integer linear programming solver; the optimized model is the control method disclosed in the embodiments of this invention.

[0145] Under the replay conditions, the mixed-integer linear programming solver increases the average processing latency for a single action generation by 26.2 ms. This latency increment falls within the block generation time and control time window of the smart contract state machine set in this embodiment. Simultaneously, actions violating global liquidity constraints are removed during the action constraint phase, reducing illegal state transition requests and the number of retries triggered by contract rejection. Therefore, the state transition samples received by the feedback update module correspond to fund flow paths that satisfy the funding constraints, reducing the impact of exploratory actions lacking funding feasibility on the state of the permissioned distributed ledger.

[0146] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0147] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. It should be noted that any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A smart control method for Web3-based supply chain finance, characterized in that, include: Collect supply chain transaction events, funding events, logistics events, and credit events from the Web3 supply chain finance network, perform source authentication, time alignment, and consensus confirmation on the events, and generate risk state vectors with credibility labels; The risk state vector is input into the risk scoring algorithm and the reinforcement learning strategy network. The risk score is used to constrain the set of optional actions of the reinforcement learning strategy network, and the risk control actions such as financing approval, quota adjustment, risk warning or fund freezing are output. The risk control action is bound to the ledger state identifier contained in the risk state vector to form a contract call request. The smart contract state machine verifies the contract call request and the current contract state, performs the allowed state transition, and generates a contract execution receipt. Based on the contract execution receipt, subsequent performance events and the next consensus confirmation state, a reward value and a state transition sample are generated. The state transition sample is used to update the reinforcement learning policy network and write the new policy version. After the consensus confirmation is completed in the contract execution receipt, the next control cycle begins; when a new strategy version is generated, the new strategy version is activated after it has been verified by multiple nodes, until the strategy stability condition or the update limit is reached.

2. The intelligent control method for Web3-based supply chain finance according to claim 1, characterized in that, The source authentication includes verifying the digital signature and authorization credentials of the event sending node; the time alignment includes associating transaction events, fund events, logistics events, and credit events according to the business object identifier and event time window; the consensus confirmation includes reading the commit status of the permissioned distributed ledger and isolating uncommitted events outside the risk status vector.

3. The intelligent control method for Web3-based supply chain finance according to claim 2, characterized in that, The risk state vector with credibility markers includes event characteristics, event source reliability, time integrity, ledger confirmation, current contract status, and the status of the most recent contract execution receipt. The event source reliability, time integrity, and ledger confirmation together form the event credibility.

4. The intelligent control method for Web3-based supply chain finance according to claim 1, characterized in that, The risk scoring algorithm maps the risk score to a set of allowed actions within the risk score range. The smart contract state machine outputs a set of allowed state transition actions for the current contract state. The action constraint module intersects the set of allowed actions within the risk score range with the set of allowed state transition actions to form a set of optional actions. The reinforcement learning policy network selects risk control actions only from the set of optional actions.

5. The intelligent control method for Web3-based supply chain finance according to claim 4, characterized in that, The contract call request carries a business object identifier, a ledger status identifier, a strategy version identifier, and an idempotency identifier. The smart contract state machine performs a state transition when the ledger status identifier carried in the contract call request is consistent with the ledger status identifier corresponding to the current contract state and the idempotency identifier has not been processed; and generates a rejection receipt when the two are inconsistent or the idempotency identifier is duplicated.

6. The intelligent control method for Web3-based supply chain finance according to claim 5, characterized in that, The contract execution receipt includes risk control actions, contract status before execution, contract status after execution, execution result, ledger transaction identifier, and execution time; the subsequent performance events include delivery status, repayment status, settlement status, or payment status; the contract execution receipt and the subsequent performance events are associated through business object identifier and ledger status identifier.

7. The intelligent control method for Web3-based supply chain finance according to claim 6, characterized in that, The reward value includes a successful contract state transition component, a false alarm penalty component, a default loss penalty component, and a processing delay penalty component; the state transition sample includes a risk state vector, risk control actions, a reward value, and the next consensus confirmation state, and is written into the experience replay buffer.

8. The intelligent control method for Web3-based supply chain finance according to claim 7, characterized in that, The reinforcement learning policy network employs an online network and a target network. The online network is updated according to state transition samples extracted from the experience replay buffer, and the target network is synchronized according to a preset update cycle. The policy stability conditions include that the change in validation set loss and the rate of change in control actions do not exceed their respective stability thresholds within the continuous update cycle.

9. The intelligent control method for Web3-based supply chain finance according to claim 4, characterized in that, The action constraint module embeds a mixed-integer linear programming solver. After forming the set of optional actions, the action constraint module inputs the set of optional actions, the current funding exposure corresponding to the ledger status identifier, the global liquidity parameters recorded by the permissioned distributed ledger node, and the upstream and downstream node relationships into the mixed-integer linear programming solver to construct a set of constraint equations containing discrete action variables and continuous credit limit variables. The mixed-integer linear programming solver aims to maximize the difference between the overall expected return of the supply chain network and the residual default risk loss and credit limit change, calculates feasible optimal action combinations under hard funding constraints, and assigns the discrete action variables constrained by the feasible optimal action combinations to the solution. The boundary and continuous limit boundary are used as the fourth allowed set; the intersection of the fourth allowed set and the optional action set forms the final execution action set, and the reinforcement learning policy network selects the risk control action only within the final execution action set; when the risk control action is financing approval or limit adjustment, the execution limit of the risk control action is determined by the value of the corresponding continuous limit variable in the feasible optimization action combination; when the mixed integer linear programming solver does not obtain a feasible solution within the preset solution time window, or when the ledger status identifier corresponding to the solution input is inconsistent with the current ledger status identifier, the final execution action set only retains the action of maintaining the current state and the action of manual review.

10. An intelligent control system for Web3-based supply chain finance, used to execute the intelligent control method for Web3-based supply chain finance as described in any one of claims 1-9, characterized in that, This includes event collection interfaces, permissioned distributed ledger nodes, risk control servers, smart contract execution nodes, and financial operation interfaces; The event acquisition interface is used to receive transaction events, fund events, logistics events and credit events generated by the supply chain business system and IoT nodes, and to send events that have been source-authenticated and time-aligned to the permissioned distributed ledger node; The permissioned distributed ledger node is used to complete event consensus confirmation and send the confirmed event, ledger status identifier and contract current status to the risk control server. The risk control server includes a trusted state construction module, a risk scoring module, a reinforcement learning strategy module, an action constraint module, and a feedback update module. The trusted state construction module is used to generate a risk state vector. The risk scoring module and the current state of the contract together limit the set of optional actions of the reinforcement learning strategy module. The action constraint module binds the selected risk control action with the ledger state identifier and sends it to the smart contract execution node. The smart contract execution node is used to verify contract call requests, execute allowed state transitions, transmit financing or fund control requests through the financial operation interface, and send contract execution receipts to the permissioned distributed ledger node and feedback update module. The feedback update module is used to associate contract execution receipts, subsequent performance events, and the next consensus confirmation status to form state transition samples and update the reinforcement learning strategy module.

Images