A cross-chain digital currency collaborative pricing system for a distributed network

Abstract

This invention discloses a cross-chain digital currency collaborative pricing system for distributed networks, belonging to the field of distributed computing technology. The system includes: a state awareness module, which collects and processes heterogeneous data reflecting the market and reserve status of the associated digital currencies of the current node in real time, forming node state data; a distributed collaborative decision-making module, which generates collaborative control instructions based on the node state data through collaborative training and distributed decision-making among intelligent agents; a cross-chain execution module, which converts the collaborative control instructions into multilateral asset transfer operations executed atomically through smart contracts to update the digital currency reserve status; and a pricing calculation module, which, while protecting the data privacy of each participating node, collaboratively generates a multilateral real-time exchange rate based on the updated digital currency reserve status of each participating node and by integrating external benchmark exchange rate data. This application achieves efficient, stable, and secure collaborative pricing and settlement between cross-border digital currencies.

Description

Technical Field

[0001] This invention relates to the field of distributed computing technology, and in particular to a cross-chain digital currency collaborative pricing system for distributed networks. Background Technology

[0002] Building a multilateral central bank digital currency (CBDC) cross-border settlement infrastructure presents significant technical challenges in achieving efficient and stable real-time pricing of multilateral exchange rates. Traditional delayed net settlement models suffer from inherent drawbacks such as long cycles and exchange rate lags, making them unsuitable for real-time requirements. While existing instant exchange schemes based on liquidity pools improve efficiency, their mechanisms primarily target bilateral or simple scenarios, lacking dynamic liquidity coordination capabilities across multilateral systems. This leads to insufficient liquidity allocation during peak trading periods, potentially causing exchange rates to deviate significantly from their reasonable range and resulting in pricing distortions. Furthermore, classic automated market maker (ACM) algorithms lack corresponding collaborative designs in multilateral environments, making them unsuitable for multilateral CBDC settlement scenarios that demand higher system stability and coordination. In addition, existing solutions fail to adequately address the inherent contradiction between the identity and transaction verification requirements necessary for cross-border transactions and the protection of the privacy of participants' business information, further limiting their applicability in compliant cross-border scenarios. Summary of the Invention

[0003] The purpose of this invention is to provide a cross-chain digital currency collaborative pricing system for distributed networks, in order to solve the problems of poor real-time exchange rate pricing, rigid liquidity management, compliance and privacy conflicts, and inefficient cross-institutional data collaboration in existing multilateral central bank digital currency cross-border settlements.

[0004] To achieve the above objectives, this application adopts the following technical solution:

[0005] This application discloses a cross-chain digital currency collaborative pricing system for a distributed network. The system is deployed in a decentralized network composed of multiple participating nodes, each node maintaining the reserve status of its associated digital currency. The system includes:

[0006] The status awareness module is deployed on each participating node to collect and process heterogeneous data that reflects the status of the associated digital currency market and reserve status of the node in real time, forming node status data.

[0007] The distributed collaborative decision-making module is connected to each of the state perception modules and is built based on a multi-agent reinforcement learning framework. It is used to generate collaborative control instructions for dynamically adjusting the digital currency reserves of each participating node based on the state data of each participating node through collaborative training and distributed decision-making among agents.

[0008] The cross-chain execution module, connected to the distributed collaborative decision-making module, is used to convert the collaborative control instructions into multilateral asset transfer operations executed atomically through smart contracts, so as to coordinate the synchronous update of the digital currency reserve status of each participating node.

[0009] The pricing calculation module connects to each participating node and is built on a federated learning framework. It is used to collaboratively generate and output a multilateral real-time exchange rate for settlement, based on the updated digital currency reserve status of each participating node and by integrating external benchmark exchange rate data, while protecting the data privacy of each participating node.

[0010] Preferably, the digital currency reserves maintained by each participating node constitute a multilateral digital currency liquidity pool. The initial liquidity of the liquidity pool consists of the digital currency reserves deposited by the issuers corresponding to each participating node and the flexible market-making funds provided by market makers.

[0011] Preferably, the collaborative control command is a dynamic adjustment command for the reserve ratio of each currency in the liquidity pool;

[0012] The heterogeneous data collected by the state awareness module includes the real-time reserve amount of each currency in the liquidity pool and the cross-border trading activity data of each currency.

[0013] Preferably, the distributed collaborative decision-making module adopts a centralized training and distributed execution architecture, including:

[0014] The intelligent agents deployed on each participating node act as executors to generate candidate actions based on local node state data.

[0015] A centralized trainer is used to jointly optimize the policy network of the multi-agent reinforcement learning framework using a reinforcement learning algorithm based on the global state and training-related data obtained from each agent, wherein the optimization objective includes at least minimizing the overall funding gap rate of the liquidity pool.

[0016] The collaborative control commands are output in a distributed manner by each agent according to the optimized policy network.

[0017] Preferably, the reinforcement learning algorithm is a monotonic value function decomposition method, which uses a hybrid network to nonlinearly aggregate the local action value functions of each agent to ensure the monotonicity of the joint action value function during the training phase and to achieve decentralized decision-making for each agent during the execution phase.

[0018] Preferably, the pricing calculation module includes:

[0019] The local pricing unit, deployed at each participating node, is used to calculate the local base exchange rate based on the updated digital currency reserve status of the node through an automated market maker model.

[0020] The federated learning aggregation unit is used to perform secure aggregation computation on the model parameter update amount uploaded by each local pricing unit based on a secure multi-party computation protocol, so as to update the global hybrid pricing model and distribute the updated model parameters to each local pricing unit.

[0021] The hybrid pricing model is used to dynamically weight and integrate the local base exchange rate with the external benchmark exchange rate data.

[0022] Preferably, the external benchmark exchange rate data is obtained through a decentralized oracle network;

[0023] The oracle network connects to multiple authoritative data sources and performs cross-validation and trusted aggregation of the obtained official exchange rate guidance based on the Byzantine fault-tolerant consensus mechanism.

[0024] Preferably, the system further includes a compliance audit module, which interacts with the pricing calculation module and / or the cross-chain execution module to generate verifiable compliance proofs for the transaction process based on zero-knowledge proof technology.

[0025] Preferably, the state sensing module collects the heterogeneous data at dynamically configurable multi-level frequencies;

[0026] Among them, cross-border transaction popularity data and reserve status data are collected at the highest frequency, external benchmark exchange rate data is collected at the second medium frequency, and compliance rule data is collected at the third low frequency.

[0027] Preferably, the cross-chain execution module is deployed in a trusted execution environment;

[0028] The decentralized network adopts a delegated proof-of-stake consensus mechanism based on multi-dimensional reputation rating, in which consensus nodes are dynamically elected based on their computing performance, network stability, and security history.

[0029] The present invention has the following beneficial effects:

[0030] 1. By using a distributed architecture and atomic execution of smart contracts, the overall system response latency for cross-border settlement is reduced from more than 24 hours in traditional systems to the second level.

[0031] 2. By using multi-agent reinforcement learning to dynamically allocate liquidity pools, the funding gap ratio can be stably controlled below 0.5%, and the exchange rate fluctuation range can be limited to ±1.5%, significantly improving pricing stability.

[0032] 3. Zero-knowledge proof technology enables the generation of verifiable compliance credentials without disclosing details of the original transaction data. This mechanism ensures necessary transaction verification is completed while protecting the privacy of participants' business information, thus achieving effective synergy between compliance verification and privacy protection in terms of technology.

[0033] 4. By using the federated learning framework, while ensuring the local storage of data by all participating parties, the bottleneck of the inability to directly share data among multiple countries and the difficulty of joint modeling caused by data sovereignty restrictions is overcome. This enables privacy-preserving collaborative training of model parameters and improves the accuracy and adaptability of the multilateral exchange rate pricing model.

[0034] 5. It provides a technical architecture that can adapt to the compliance and regulatory requirements of central bank digital currencies. By integrating official benchmark exchange rates, providing standardized audit interfaces, and executing in a trusted environment, it builds a multilateral settlement infrastructure that is both efficient and compliant with financial regulation and sovereign credit requirements, making up for the lack of regulatory interfaces and compliance design in classic decentralized finance models. Attached Figure Description

[0035] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0036] Figure 1 This is an operation flowchart of a cross-chain digital currency collaborative pricing system for a distributed network provided in an embodiment of this application;

[0037] Figure 2 This is a schematic diagram of the structure of a cross-chain digital currency collaborative pricing system for a distributed network provided in an embodiment of this application;

[0038] Figure 3 This is a schematic diagram of the structure of the distributed collaborative decision-making module provided in the embodiments of this application;

[0039] Figure 4 This is a flowchart of the liquidity pool allocation adjustment provided in the embodiments of this application;

[0040] Figure 5 This is a schematic diagram of the pricing calculation module provided in the embodiments of this application. Detailed Implementation

[0041] To make the technical solution of this application clearer, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. The terms "first," "second," etc., in the claims and specification of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate. This is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of units is not necessarily limited to those units, but may include other units not explicitly listed or inherent to these processes, methods, products, or apparatuses.

[0042] This disclosure provides an embodiment of a cross-chain digital currency collaborative pricing system for distributed networks. For example... Figure 1 As shown, Figure 1 The system's operational flow is provided. The system is deployed in a decentralized network comprised of multiple participants, each node maintaining the reserve status of its associated digital currency.

[0043] In some embodiments, the system can be deployed in a network built on a private cloud. The participating nodes in this network may include nodes operated by different central banks or currency issuers, for example, nodes maintaining digital currency reserves in country A and country B respectively. The core modules of the system adopt a distributed microservice architecture and are deployed on edge computing nodes local to each participating party. Nodes are interconnected via high-bandwidth, low-latency communication technologies such as dedicated lines or 5G network slicing to ensure stable and reliable transmission of control signaling and business data. Node location can be combined with the main transaction scenarios of cross-border payments (such as cross-border trade nodes between country A and country B, or between country B and country C), deploying the core liquidity pool service on private cloud edge computing nodes (such as edge data centers in countries A, B, and C) geographically close to both parties to the transaction, to reduce the physical distance and latency of data transmission across regions.

[0044] Furthermore, the digital currency reserves maintained by each participating node collectively constitute a multilateral digital currency liquidity pool. This liquidity pool adopts a dual-supply architecture of "central bank reserves + market makers," and its initial liquidity consists of two parts: 1) Central base reserves, which are injected into the liquidity pool as basic liquidity funds by the central banks of participating countries according to a preset ratio or bilateral / multilateral agreements; 2) Market elasticity market-making funds, which are provided by one or more certified market makers based on transaction commission incentive mechanisms to enhance the pool's liquidity's ability to cope with short-term fluctuations.

[0045] This dual-supply architecture enables the total size of the liquidity pool to expand dynamically: in normal trading scenarios, it mainly relies on central bank reserves to maintain a basic balance; in abnormal scenarios such as peak trading periods, large payments, or sharp exchange rate fluctuations, it automatically activates the market maker's flexible funding channel, and can also trigger the central bank's emergency reserve replenishment mechanism when necessary, thereby achieving a multi-layered liquidity guarantee of "basic stability + flexible response".

[0046] This design not only improves the robustness and responsiveness of the cross-border payment system, but also introduces external liquidity resources through market-based incentive mechanisms, reducing reliance on a single central bank fund and effectively supporting real-time settlement needs in high-concurrency and high-volatility environments.

[0047] like Figure 2 As shown, the system specifically includes a state awareness module 10, a distributed collaborative decision-making module 20, a cross-chain execution module 30, and a pricing calculation module 40.

[0048] The state awareness module 10 is deployed on each participating node to collect and process heterogeneous data that reflects the state of the digital currency market and reserve status of the node in real time, thereby forming node state data.

[0049] In one specific embodiment, the state awareness module 10 collects heterogeneous data at dynamically configurable multi-level frequencies. The dynamic configuration of these multi-level frequencies is determined comprehensively based on multiple dimensions, including data timeliness requirements, system resource consumption, and the impact weight of business scenarios. Specifically:

[0050] For data that directly impacts liquidity allocation and changes rapidly, such as cross-border transaction activity data and reserve status data (including but not limited to the trading volume, frequency, and single transaction amount of each CBDC; the real-time reserve amount of each currency in the liquidity pool and the funding gap ratio of each currency), a high-frequency (e.g., 1 second / time) collection method is adopted. Given the small size of this type of data (≤1KB), even with a high collection frequency, the resource consumption on private cloud edge nodes is relatively low (<5%), and it will not affect the system's response speed. The funding gap ratio refers to the amount that needs to be added / reduced in the liquidity pool for each currency based on the target proportion and current reserves (e.g., country A's digital currency needs to be added by 2 million, and country B's digital currency needs to be reduced by 1.5 million).

[0051] For data that requires a certain time window to demonstrate its value, such as external benchmark exchange rate data (e.g., central bank guidance prices and exchange rate volatility captured through oracles) and market maker funding availability, a second intermediate frequency (e.g., once every minute) collection strategy is adopted. Considering that these data typically have periodic characteristics—for example, central bank guidance prices are generally updated every minute, while exchange rate volatility requires the accumulation of multiple pricing data points to have statistical significance—a collection frequency of once per minute ensures both timeliness and effective utilization of system resources.

[0052] For data that changes slowly and involves cross-organizational synchronization, such as compliance rule data and business scenario identification data (e.g., the switch between e-commerce promotional and non-promotional periods), the third low-frequency (e.g., once per hour) collection mode is selected. Because this type of data is updated infrequently and requires cross-border information exchange, excessively high collection frequencies not only increase communication costs but may also raise compliance risks. Therefore, a collection frequency of once per hour is sufficient to meet the needs of model adaptation while minimizing unnecessary resource overhead.

[0053] This multi-level frequency acquisition mechanism can achieve a balance between the system's real-time requirements and resource utilization efficiency, ensuring that while meeting business needs, it minimizes the consumption of system resources and reduces operating costs.

[0054] The distributed collaborative decision-making module 20 is connected to each state perception module 10 and is built based on the multi-agent reinforcement learning (MARL) framework. It is used to generate collaborative control instructions for dynamically adjusting the digital currency reserves of each participating node based on the state data of each participating node through collaborative training and distributed decision-making among agents.

[0055] In one specific embodiment, the distributed collaborative decision-making module 20 is configured to dynamically adjust the target proportion of CBDC in the liquidity pool in real time based on the cross-border transaction activity collected by each state-aware module 10 over the past hour, using a multi-agent reinforcement learning (MARL) model to ensure that the funding gap ratio is below a set threshold (e.g., below 0.5%). If the funding gap ratio is too high (e.g., >2%), it will cause the reserves of each currency in the liquidity pool to deviate significantly from the actual market demand, thereby causing the exchange rate generated by the Automated Market Maker (AMM) algorithm to deviate significantly from the reasonable range, resulting in exchange rate risks in cross-border payments (e.g., excessively high costs for the payer and reduced actual amount received by the payee).

[0056] To balance system response efficiency and global collaboration capabilities, the distributed collaborative decision-making module 20 adopts a centralized training and distributed execution architecture. For example... Figure 3 As shown, the architecture includes:

[0057] Agents deployed on each participating node act as executors, each generating candidate actions based on its local node state data.

[0058] A central trainer is used to jointly optimize the policy network of a multi-agent reinforcement learning framework using reinforcement learning algorithms, based on the global state and training-related data obtained from each agent.

[0059] The optimized policy network is deployed back to each agent, and during the execution phase, it can output cooperative control commands by relying only on local observations, thereby achieving low-latency, highly scalable distributed decision-making.

[0060] The candidate actions generated by each agent refer to optional adjustment instructions regarding the proportion of the corresponding CBDC currency in the liquidity pool, belonging to the preset action space. In this embodiment, candidate actions include, but are not limited to, the proportion adjustment amount (e.g., "increase the current proportion by 3%)", the rebalancing direction indicator (e.g., "replenish liquidity" or "maintain the status quo"), the funding source indication (e.g., "activate central bank reserves"), and the execution timeliness level (e.g., "execute immediately"). After the candidate actions are generated, they are all uploaded to the centralized trainer for joint strategy evaluation.

[0061] Training-related data refers to the necessary information collected and uploaded by each agent during execution to the centralized trainer for model training and parameter updates. It does not contain sensitive business privacy information, only retaining the state-action-reward structure required for reinforcement learning, ensuring compliance and communication efficiency. This includes, but is not limited to, local observations. (Such as the trading activity of this CBDC in the past hour, its current proportion in the liquidity pool, the available funds balance of local market makers, local compliance status, etc.), the actions actually performed by the agent at that time, the selected actions, timestamps and sequence identifiers (used to construct the time-series trajectory in experience replay), and a summary of environmental interaction results (such as the change in this CBDC reserves after rebalancing, the change in local exchange rate deviation, rebalancing time and cost estimation). This data is packaged and generated by each agent in each decision cycle (such as per second or per minute) and uploaded to the centralized trainer through an encrypted channel. The trainer combines the global state (such as the total reserves of the entire pool, the overall funding gap rate, and the cross-currency exchange rate matrix) to construct a complete tuple for simulation training.

[0062] Furthermore, this embodiment employs the Monotonic Value Function Decomposition (QMIX) method as the core algorithm of the MARL model. The QMIX algorithm uses a Mixing Network to decompose the local action value functions of each agent. Nonlinear aggregation into a joint action value function And ensure that the aggregation process satisfies the monotonicity constraint: that is, the local monotonicity of any agent. When the value increases, the joint The value does not decrease. This characteristic ensures that the selected combination of actions can still approximate the global optimum during the distributed execution phase.

[0063] The symbols are defined as follows:

[0064] S: The overall state of the environment, including the trading activity of all CBDCs, the total reserves of liquidity pools, the funding gap ratio, etc.

[0065] Intelligent agent Local observations, such as the trading volume of its corresponding CBDC and its current proportion in the pool;

[0066] Intelligent agent The action indicates an instruction to adjust its CBDC percentage (such as "+3%", "..."). (2% or "remain unchanged")

[0067] The joint action of all intelligent agents. Indicates the total number of intelligent agents;

[0068] R: Global reward signal, calculated from a preset reward function.

[0069] joint value Determined by the following formula:

[0070]

[0071] Where f(·) is a hybrid network (such as a multilayer perceptron), whose parameters are modulated by the global state s and are forced to satisfy the monotonicity condition; This represents all individuals of N intelligent agents. Add the values ​​together.

[0072] Module 20 calculates the global reward based on a preset reward function:

[0073] r=α1*(1 (funding gap ratio) + β1 * (1 |Exchange Rate Volatility|) + λ1 * Rebalancing Cost Savings

[0074] Among them, α1, β1 and λ1 are all configurable weighting coefficients, which reflect the degree of importance attached to liquidity stability, exchange rate stability and operational economy, respectively.

[0075] During the training phase, module 20 updates the QMIX model parameters using the Temporal Difference (TD) error method:

[0076]

[0077] in, ∈(0,1) is the discount factor, which represents the discount ratio of future rewards. The smaller the value, the more the agent values ​​immediate benefits. This represents the global state at the next moment. Indicate the next state The maximum value that can be generated from all possible joint actions is predicted. Indicate the next state Below, one of all possible actions to take.

[0078] By minimizing the TD error, the model gradually strengthens action combinations that bring high long-term cumulative rewards (such as "prioritizing the replenishment of corresponding currencies when trading activity increases"), while suppressing inefficient or redundant actions (such as "frequent portfolio rebalancing when there are no significant changes in demand").

[0079] The cyclical evaluation rate can be dynamically adjusted according to the business scenario load: under normal scenarios, the parameter is updated once after every 5 percentage adjustments are completed; during peak transaction periods (such as cross-border e-commerce promotions), the update is increased to once every 2 adjustments to enhance the responsiveness of module 20.

[0080] It's important to note that model parameters can be automatically updated via a feedback mechanism. Furthermore, several key hyperparameters also support dynamic configuration based on business scenarios, avoiding rigidity. Specifically, the discount factor... Adjustments are made based on trading stability, therefore, during peak trading periods (when exchange rate volatility risk is high), the following settings are applied: 0.95, emphasizing long-term stability; set to [value] during off-peak periods. 0.85, emphasizing short-term efficiency. Reward weights α1, β1, and λ1 are adjusted based on core objective priorities. For example, during periods of strict compliance review, α1 is set to 0.5, β1 to 0.4, and λ1 to 0.1, prioritizing liquidity; during cost-sensitive periods, λ1 is increased to 0.3, emphasizing the economics of portfolio rebalancing. The range of action is adjusted based on the funding gap ratio; when the gap ratio is ≤0.5%, minor adjustments are allowed (e.g., {...}). 2%, 0, +2%}); when the gap rate is greater than 1%, it expands to a significant adjustment (such as { 5%, The trigger threshold is adjusted based on the magnitude of changes in transaction activity data. When the fluctuation in transaction activity exceeds 20% (e.g., a sudden large transaction), the percentage is immediately readjusted; when the fluctuation is less than 5%, a routine assessment is performed every 5 minutes.

[0081] Module 20 has adaptive adjustment logic to prevent systemic risks in response to abnormal events in cross-border payments, specifically including:

[0082] Impact of large transactions (single transaction amount greater than 5 million RMB of Country A digital currency): Temporarily expand the action range to ±8%, prioritize the use of the central bank reserve channel, and reduce the rebalancing cost weight λ1 to 0.05 to prioritize the smooth completion of transactions.

[0083] Market maker funding response delay (>3 seconds): Automatically freeze the market maker channel, switch to a backup market maker or central bank reserves, and introduce a penalty term in the reward function to suppress strategies that "over-rely on a single funding source".

[0084] If exchange rate fluctuations exceed the limit (volatility > ±1.5%): Suspend the weighting adjustment operation and activate the hedging mechanism (such as executing pre-set option contracts) to smooth market fluctuations; after the volatility falls back to within ±1%, resume the weighting adjustment and increase the weight of λ1 to prioritize maintaining exchange rate stability.

[0085] During the execution phase, each CBDC agent (such as the digital currency agent of country A and the digital currency agent of country B) makes independent decisions based solely on its own local observations (e.g., the digital currency agent of country A adjusts its proportion based on its own transaction volume), without waiting for global information synchronization. Although the centralized hybrid network is used during the training phase, it does not participate in real-time inference during the execution phase, thus ensuring the low latency and strong robustness of module 20. Ultimately, module 20 chooses to use... The largest joint action is to adjust the target proportion strategy (for example, adjusting the proportion of digital currency in country A from 40% to 42% and the proportion of digital currency in country B from 50% to 48%), and drive the liquidity pool to complete the rebalancing through the issuance of instructions.

[0086] In addition, this embodiment defines a multi-level priority mechanism for fund allocation: priority is given to using the market makers' elastic funds to fill gaps or receive redundant funds; if the market maker's funds are unavailable or the response is delayed (>3 seconds), the system will automatically switch to the central bank's reserve channel as an emergency supplementary source.

[0087] This embodiment integrates multi-agent reinforcement learning, dynamic hyperparameter scheduling, and abnormal event response mechanisms to construct an efficient, robust, and scalable CBDC liquidity collaborative control module, which can continuously maintain the supply and demand balance of the liquidity pool and the rationality of exchange rates in a complex and ever-changing cross-border payment environment.

[0088] The cross-chain execution module 30 is connected to the distributed collaborative decision-making module 20. Its core function is to convert two types of instructions into multilateral operations that are atomically executed through smart contracts: firstly, to dynamically adjust the currency reserves of the liquidity pool; and secondly, to complete the final settlement of cross-border payments. This module 30 ensures that both operations are atomic, auditable, and highly timely.

[0089] The smart contract execution for dynamic adjustment of the liquidity pool aims to respond in real time to the collaborative control instructions (i.e., percentage adjustment instructions) issued by the distributed collaborative decision-making module 20, and to rebalance the reserves of each currency in the liquidity pool.

[0090] When the distributed collaborative decision-making module 20 generates an adjustment instruction (e.g., "Increase the target proportion of country A's digital currency in the liquidity pool by 2%, decrease the proportion of country B's digital currency by 2%, and replenish country A's digital currency by X amount and reduce country B's digital currency by Y amount"), this instruction serves as a dedicated liquidity adjustment contract triggered by an on-chain event.

[0091] Once triggered, the smart contract first verifies the transaction initiation authority and preset conditions (such as the current state of the liquidity pool meeting requirements), and then sends asset locking requests to the relevant CBDC chains via a cross-chain communication protocol (such as Hash Time Locking (HTLC)). The condition is considered met only when the corresponding assets on all chains are successfully locked within a specified time. Once all preconditions are verified, the smart contract issues the final execution instruction. Subordinate smart contracts or verification nodes on each chain synchronously execute the asset transfer operation. This process is protected by cryptographic commitments and timeout mechanisms to ensure that no party can unilaterally remove assets without completing all operations. Finally, the operation results (transaction hash, success status) on all chains are collected and submitted back to the smart contract of the cross-chain coordination layer for final confirmation, forming an immutable execution certificate.

[0092] After the multilateral asset transfer is successfully executed atomically, the cross-chain execution module 30 generates a reserve status update notification based on the on-chain confirmed execution result and broadcasts it to all relevant participating nodes. Upon receiving the notification, each participating node atomically updates its maintained cryptocurrency reserve status in its local ledger or state database, ensuring consistency from the "global liquidity pool" to each node's "local sub-liquidity pool" view. After the status update is complete, the cross-chain execution module 30 sends a success feedback signal to the distributed collaborative decision-making module 20 and the pricing calculation module 40, thus forming a complete "decision-execution-status update" closed loop. Figure 4 As shown, Figure 4 It provides a complete process for adjusting liquidity pool allocation.

[0093] Simultaneously, the contract generates an adjustment execution certificate, recording the reserve status before and after the adjustment, the execution timestamp, and the associated decision instruction hash. This certificate is automatically submitted to the compliance audit module for archiving, ensuring the traceability and auditability of each liquidity rebalancing.

[0094] Through the above mechanism, the cross-chain execution module 30 ensures that even in a distributed, multi-chain heterogeneous environment, complex multilateral fund allocation can have atomicity, consistency, isolation and durability like a single database transaction, laying the foundation for reliable collaboration of the entire system.

[0095] After the proportion adjustment is completed, the smart contract automatic clearing of cross-border payment settlement processes specific cross-border payment transactions, realizing "exchange rate confirmation - fund transfer - voucher generation".

[0096] The system is pre-configured as a three-stage, event-driven smart contract chain, including an exchange rate confirmation contract, a fund transfer contract, and a certificate generation contract, which are linked together through an on-chain event subscription mechanism.

[0097] When the pricing calculation module 40 publishes the final real-time exchange rate event, the exchange rate confirmation contract is triggered, and the consensus-confirmed exchange rate parameters (such as 1 Country A digital currency = 1.238 Country B digital currency) are written into its state in an immutable manner.

[0098] The exchange rate lock event automatically triggers a fund transfer contract. This contract reads the locked exchange rate and transaction request details (such as payer, payee, and amount), calculates the receivables, and atomically calls the liquidity pool interface to simultaneously complete the deduction from the payer's account and the crediting to the payee's account. It relies on the underlying distributed transaction to ensure strong consistency and eliminate partial execution risks.

[0099] A successful fund transfer triggers a certificate generation contract. This contract automatically calls the zero-knowledge proof interface of the compliance audit module 50 to generate verifiable compliance audit certificates based on transaction hashes, exchange rates, timestamps, etc., and distributes them across the system's private nodes and the regulatory chain to ensure that the transaction is tamper-proof and traceable.

[0100] In this embodiment, to support seamless value transfer between multilateral CBDC systems (such as digital currencies of country A, country B, and country C), module 30 includes dedicated cross-chain routing nodes. These nodes are deployed in an edge computing environment. By optimizing node location (geographically close to the transaction initiator and receiver), employing lightweight cross-chain communication protocols, and pre-configuring interoperability interfaces with mainstream CBDC chains, the end-to-end latency of cross-chain communication is ensured to be stable within ≤50 milliseconds (ms), thus meeting the real-time requirements of high-frequency cross-border payments.

[0101] This embodiment ensures that the entire time from instruction triggering (whether it is a percentage adjustment or exchange rate confirmation) to the final completion of the operation is strictly controlled within 10 seconds by deploying smart contracts on edge nodes, utilizing the low-latency network in the private cloud (end-to-end latency ≤1ms), and optimizing the contract execution process, without the need for manual intervention.

[0102] The cross-chain execution module 30 ensures that liquidity pools can be rebalanced in real time, automatically, and reliably according to market conditions, while providing efficient, secure, and compliant automated settlement services for cross-border payments.

[0103] The pricing calculation module 40 is connected to each participating node and is built based on the federated learning framework. It is used to collaboratively generate and output the multilateral real-time exchange rate for settlement based on the updated digital currency reserve status of each participating node and the integration of external benchmark exchange rate data, while protecting the data privacy of each participating node.

[0104] In one specific embodiment, such as Figure 5 As shown, the pricing calculation module 40 includes a local pricing unit 42 deployed on each participating node and a centrally deployed federated learning aggregation unit 44. The two work together to realize a hybrid exchange rate pricing mechanism of "local calculation, global optimization, and privacy protection".

[0105] Specifically, each participating node deploys a local pricing unit 42. This unit calculates the local base exchange rate of its currency against other currencies by running an adapted and optimized Automated Market Maker (AMM) model based on the updated digital currency reserve status of the node (including the real-time reserve amount of this CBDC in the liquidity pool, the target proportion, and the funding gap rate, etc.).

[0106] For cross-border scenarios of multilateral central bank digital currencies (CBDCs), this embodiment makes three optimizations to the AMM constant product formula x*y=k, where x and y represent the reserves of two assets (such as digital currencies of country A and country B) in the liquidity pool, respectively, and k is a constant.

[0107] 1) Multi-currency adaptation optimization: The formula is extended to accommodate multiple assets. ,in This represents the reserve amount of the i-th CBDC in the pool, where n is the total number of currencies in the pool. This extension ensures overall liquidity balance in a multi-currency environment.

[0108] 2) Enhanced stability: A dynamic fee mechanism is introduced. When the reserves of a certain currency fall below a preset threshold (e.g., 5%), the exchange fee for that currency is automatically increased to suppress price slippage under extreme market conditions and improve exchange rate stability.

[0109] 3) Adaptation to the characteristics of central bank digital currency: Embed the central bank reserve ratio factor into the AMM pricing logic to enforce that the reserve of each currency is not lower than the regulatory requirements (e.g., not lower than 60% of the total size of the liquidity pool) to ensure compliance.

[0110] After completing the calculation of the local base exchange rate, the local pricing unit 42 does not directly publish the exchange rate to the outside world, but uses it as an input feature to train the local hybrid pricing sub-model.

[0111] Each local pricing unit 42 trains a hybrid pricing sub-model locally, incorporating purchasing power parity (PPP) factors, interest rate parity (IRP) factors, and external benchmark exchange rate weights. During training, the original data (such as CPI, interest rates, reserves, etc.) remains on the local node and does not leave the domain; only the encrypted model parameter updates (such as gradients or weight differences) are uploaded to the federated learning aggregation unit 44.

[0112] Federated learning aggregation unit 44, based on a secure multi-party computation protocol, performs secure aggregation computation on the parameter updates received from each local pricing unit 42, avoiding any unilateral inference of other parties' data. The aggregation structure is used to update the global hybrid pricing model, which is as follows:

[0113] Final exchange rate = AMM base exchange rate × α2 + central bank guidance price × β2 + PPP factor × λ2 + IRP factor × δ.

[0114] Wherein, α2, β2, λ2 and δ are weight coefficients (satisfying α2+β2+λ2+δ=1), and the initial values ​​can be set to α2=0.4, β2=0.3, λ2=0.2 and δ=0.1, and continuously dynamically optimized through federated learning.

[0115] The PPP factor is calculated from the Consumer Price Index (CPI) of each country, using the formula: PPP factor = . , These represent the CPI of both the trading parties' countries.

[0116] The IRP factor is calculated from the benchmark interest rates of various countries, using the formula: IRP factor = . These are the benchmark interest rates for the two countries involved in the transaction.

[0117] The updated global model parameters (i.e., the optimized weights α2, β2, λ2, and δ) are encrypted and distributed by the federated learning aggregation unit 44 to each local pricing unit 42 for the next round of local inference and training, forming a closed-loop optimization.

[0118] To ensure the authority and timeliness of the central bank's guidance price, local pricing unit 42 obtains external benchmark exchange rate data in real time through oracle technology. The specific steps are as follows:

[0119] 1) Multi-source data access: Oracle nodes connect to the official public APIs of central banks in various countries (such as the digital currency research institute of country A and the exchange rate release interface of country B), as well as authoritative financial data platforms, to ensure the authority and redundancy of data sources.

[0120] 2) Data Validation and Aggregation: A multi-node consensus mechanism (such as the Byzantine Fault Tolerance algorithm) is adopted to cross-validate exchange rate data from different sources. Only when more than 2 / 3 of the nodes confirm that the data is consistent is the exchange rate data marked as "valid", preventing data tampering or anomalies by a single node.

[0121] 3) Real-time updates and on-chain: The verified official exchange rate data is encrypted and uploaded to the blockchain or a trusted execution environment of a private cloud at an update frequency of 1 minute, so that the local pricing unit 42 can call it in real time and ensure the timeliness of the basic exchange rate calibration.

[0122] Through the collaborative operation of the local pricing unit 42 and the federated learning aggregation unit 44, this embodiment achieves high-precision, high-stability, and high-compliance collaborative pricing of multilateral CBDC exchange rates without sharing original sensitive data, effectively balancing the three core requirements of privacy protection, model performance, and regulatory compliance.

[0123] In one specific embodiment, the system further includes a compliance audit module 50, which interacts with the pricing calculation module 40 and / or the cross-chain execution module 30 to generate verifiable compliance proofs for the transaction process based on zero-knowledge proof technology.

[0124] The compliance audit module 50 is implemented by a compliance rule engine that incorporates multiple sets of international and regional compliance rules. This engine supports automatic matching of corresponding rules based on the countries of the transaction participants, ensuring the global compliance of cross-border payments. Simultaneously, through zero-knowledge proof technology, it achieves the goal of "compliance audit visible, privacy data invisible," meaning that only verifiable audit credentials are disclosed to regulatory agencies, without exposing sensitive information such as transaction amounts and user identities.

[0125] In one example, to address the real-time and high-concurrency requirements of cross-border payments, the compliance audit module 50 employs a concise non-interactive knowledge proof (zk-SNARKs) protocol. This protocol typically has proofs only a few hundred bytes in size and offers fast verification speeds (milliseconds), adapting to the low-latency requirements of cross-border payments. Furthermore, it supports "one-time setup" (trusted initialization), making it suitable for compliance scenarios involving multiple institutions.

[0126] When a cross-border transaction occurs (such as e-commerce platform A paying supplier B 1 million units of digital currency from country A), the payment system first encrypts sensitive data (such as transaction amount, user identity, and account information): firstly, it uses homomorphic encryption to encrypt numerical data such as transaction amount to ensure that subsequent calculations can be performed in ciphertext; then, it hashes user identity information (such as company name and unified social credit code) to generate an irreversible identity digest.

[0127] Subsequently, the payment system, acting as the prover, generates a zero-knowledge proof based on the preprocessed encrypted data. The specific steps are as follows:

[0128] First, the "transaction compliance rules" are transformed into arithmetic circuits. For example, for the rule that "a single transaction amount ≤ 5 million A country digital currency", a circuit is designed to verify whether the transaction amount in encrypted form meets this condition. Then, the "trusted setting" of zk-SNARKs is used to generate a proof key, which is combined with the encrypted transaction data to generate a zero-knowledge proof. This proof contains a mathematical proof that "the transaction satisfies all compliance rules", but does not contain any original sensitive data.

[0129] The regulatory agency, acting as a verifier, first verifies the legality of the publicly available parameters of the "trusted settings" upon which the proof relies, ensuring that the proof has not been tampered with. Then, the zero-knowledge proof is input into the verification circuit to quickly verify whether the transaction meets all preset compliance rules. During the verification process, the regulatory agency cannot obtain any original transaction data; it can only obtain a "compliant / non-compliant" conclusion.

[0130] Once the verification is successful, the system generates a verifiable audit credential, which includes a unique identifier for the credential (such as a hash value), a verification timestamp, and a list of compliance rules that are met (such as "no large transaction warnings were triggered" and "data is stored on domestic nodes").

[0131] The credentials are stored in plaintext in the regulatory agency's system, while an encrypted backup is maintained on a private cloud distributed node to ensure audit traceability and prevent the leakage of private data.

[0132] Leveraging the data isolation capabilities of private clouds, transaction data from different countries is stored on edge nodes in their respective countries. Cross-border transmissions involve only encrypted model parameters, not the original transaction data, thus complying with data sovereignty requirements and maximizing the protection of user privacy.

[0133] In one specific embodiment, the decentralized network adopts a delegated proof-of-stake consensus mechanism based on multi-dimensional reputation rating. This mechanism, through deep adaptation and optimization of the traditional delegated proof-of-stake (DPoS) engine, can support high-concurrency, low-latency cross-border payment and liquidity management scenarios.

[0134] In this embodiment, the election of consensus nodes is not fixed but dynamically based on their real-time performance and historical performance in the private cloud environment. The election is conducted according to a multi-dimensional reputation rating system, which comprehensively evaluates a node's computing performance (e.g., CPU / GPU computing power), network stability (e.g., bandwidth, latency, and packet loss rate), and security history (e.g., the accuracy and stability of past consensus participation). The system automatically runs an election algorithm every election cycle (e.g., every hour) to select a few nodes with the highest overall rating from all candidate nodes (e.g., the number is controlled to within 21, far fewer than the hundreds of nodes in a public blockchain) to serve as the "super nodes" for the current cycle. This mechanism ensures that the consensus cluster is always composed of the most reliable and high-performance private cloud nodes in the current network.

[0135] Furthermore, to improve transaction processing efficiency, this embodiment also includes targeted optimizations to key aspects of the consensus process. Specifically, these include:

[0136] 1) Block generation optimization: The elected super nodes adopt a parallel transaction packaging strategy. Specifically, the nodes classify the received transactions by currency type (e.g., cryptocurrency transactions from country A and cryptocurrency transactions from country B) or business channel, and verify and package them in parallel, thereby significantly compressing the generation time of a single block from the second level (e.g., 10 seconds) common in public chains to the millisecond level (e.g., 500 milliseconds).

[0137] 2) Consensus Verification Optimization: Leveraging the hardware acceleration capabilities of private cloud infrastructure (e.g., deploying GPUs or FPGA accelerator cards) to parallelize computationally intensive tasks such as block signature verification. This improves the verification speed by an order of magnitude (e.g., 10 times) compared to software implementation, further shortening the consensus confirmation time.

[0138] Furthermore, to cope with fluctuations in transaction load, the system also implements elastic scheduling of computing resources. Specifically:

[0139] When the system detects a peak in transactions (such as during a major cross-border e-commerce promotion), the private cloud management platform's elastic resource scheduling algorithm will proactively and dynamically allocate additional CPU and memory resources to the supernodes undertaking consensus tasks, ensuring that the system can continuously maintain high-performance transaction processing capabilities. For example, when a peak in cross-border transactions arrives, the system automatically expands the computing resources of the liquidity pool by 20% to ensure that transaction processing is not interrupted.

[0140] Meanwhile, a layered architecture of "edge node local priority processing + super node final global confirmation" is adopted. Geographically distributed edge nodes prioritize processing and confirming localized transactions within their jurisdiction (for example, node B prioritizes processing transactions involving digital currencies from country B), submitting only transactions requiring cross-regional global consensus to the super node layer for final confirmation. This effectively distributes consensus pressure, reduces network communication overhead, and thus improves overall system throughput and response speed.

[0141] Through the collaborative design of node election, process optimization and resource scheduling, the consensus mechanism implemented in this embodiment can provide high-throughput, low-latency and secure and reliable underlying transaction confirmation and state synchronization services for cross-chain digital currency collaborative pricing systems in a private cloud environment.

[0142] In one specific embodiment, to ensure the high availability and durability of core system data (such as liquidity pool fund status and transaction records), this system also adopts a distributed storage multi-replica backup mechanism based on a private cloud.

[0143] The system utilizes private cloud distributed storage technology to logically shard critical data objects. For example, a cross-border transaction record can be split into multiple logical data blocks, such as a "transaction amount block," a "participant account identifier block," and a "timestamp block." Each independent data block is further divided into multiple redundant copies (e.g., three copies by default). These copies are not centrally stored but are distributed across geographically located edge storage nodes according to a specific placement strategy. For example, three copies of the same data block can be stored on private cloud edge nodes in countries A, B, and C, respectively, thereby achieving off-site disaster recovery and improving resilience against regional failures.

[0144] To maintain data consistency among multiple replicas in distributed storage, the system implements real-time synchronization between replicas based on mature distributed consistency protocols (such as Raft or Paxos). When any data block is updated, the protocol ensures that all replicas reach the same state in a strongly consistent or eventually consistent manner, preventing data divergence. This provides a unified and reliable data view for upper-layer applications.

[0145] This mechanism features automatic fault detection and failover capabilities. When a storage node fails or becomes isolated due to network isolation, the system can detect this in real time and automatically route data read / write requests to other healthy replica nodes of the data block. This process is transparent to upper-layer business operations, ensuring uninterrupted data services and no data loss even when some nodes fail, continuously supporting the stable operation of core businesses such as transaction processing.

[0146] This embodiment provides a cross-chain digital currency collaborative pricing system for distributed networks. A state-aware module collects heterogeneous market data in real time, while a distributed collaborative decision-making module dynamically optimizes the currency reserve ratio of the liquidity pool based on multi-agent reinforcement learning. Combined with a cross-chain execution module, it achieves atomic and automated fund adjustments and payment settlement. A pricing calculation module uses federated learning to generate real-time exchange rates by integrating multi-source data while protecting privacy. This, coupled with an optimized private cloud consensus mechanism and distributed storage, enables efficient, stable, and secure collaborative pricing and settlement between cross-border digital currencies. This effectively reduces exchange rate volatility risks and funding gaps, and improves system throughput, response speed, and overall reliability.

[0147] Example 2

[0148] This embodiment is a specific application of the cross-chain digital currency collaborative pricing system for distributed networks provided in Embodiment 1, involving the collaborative operations of the central bank of Country A, the financial regulatory authority of Country B, market makers, cross-border e-commerce companies, and regulatory agencies. The following describes the entire system operation process through a specific scenario.

[0149] The participants include the central bank of Country A, which provides reserves of 50 million for Country A's digital currency; the financial authority of Country B, which provides reserves of 60 million for Country B's digital currency; market maker H, which provides supplementary flexible funds (10 million for Country A's digital currency and 12 million for Country B's digital currency); cross-border e-commerce platform F, which acts as the payer; supplier G, which acts as the payee in Country B; and the cross-border transaction supervision system of Country A, which acts as the regulator.

[0150] The initial state of the liquidity pool is:

[0151] Central bank reserves: 50 million in digital currency of country A and 60 million in digital currency of country B (exchange rate pegged to 1 digital currency of country A ≈ 1.08 digital currency of country B).

[0152] Market maker H replenishes funds: 10 million in digital currency from country A and 12 million in digital currency from country B;

[0153] Total liquidity pool: 60 million digital currencies from Country A and 72 million digital currencies from Country B (initial ratio of 1:1.2, in line with recent trading activity).

[0154] The full-link implementation steps are as follows:

[0155] Step 1: Transaction initiation and dynamic allocation of liquidity pool.

[0156] Transaction request triggered: E-commerce platform F initiates a payment request through its private cloud edge node. The transaction type is "Digital Currency of Country A → Digital Currency of Country B", and the amount is 1 million. After the system detects the transaction request, it triggers the status awareness module 10 to monitor the liquidity pool in real time.

[0157] Transaction activity analysis: The status awareness module 10 collects data from the past hour (including the transaction ratio of "Cryptocurrency A → Cryptocurrency B") and feeds the data back to the distributed collaborative decision-making module 20 in real time. Based on the input data (the transaction ratio of "Cryptocurrency A → Cryptocurrency B" increases from 30% to 45%), the distributed collaborative decision-making module 20 determines that it is necessary to increase the liquidity reserve of Cryptocurrency B, and then outputs a rebalancing strategy to the cross-chain execution module 30.

[0158] Currency allocation calculation: The distributed collaborative decision-making module 20, based on a reinforcement learning model (QMIX algorithm), takes the following input parameters: trading activity (45%), real-time reserves (60 million A-country digital currency, 72 million B-country digital currency), central bank guidance price (1 A-country digital currency = 1.23 B-country digital currency), and market maker resources (3 million B-country digital currency flexible funds)}. By maximizing the global reward function, it outputs the optimal allocation ratio of A-country digital currency: B-country digital currency = 1:1.25, and calculates the target B-country digital currency reserve as 60 million × 1.25 = 75 million, requiring an additional 75 million - 72 million = 3 million B-country digital currency.

[0159] Funding replenishment execution: The cross-chain execution module 30 prioritizes calling the elastic funds of country B digital currency from market maker H (replenishing 3 million), updating the liquidity pool to 60 million of country A digital currency and 75 million of country B digital currency, with a funding gap rate of 0.3% (≤0.5% threshold), to meet the trading demand.

[0160] The formula for calculating the funding gap ratio is as follows:

[0161] ×100%.

[0162] Wherein, LDR represents the funding gap ratio, TLS represents the target total liquidity, and RL represents the actual total liquidity.

[0163] In this example, the target total liquidity (TLS) (calculated based on trading activity and risk factor) is 1 billion yuan. The actual total liquidity (RL) before replenishment was 997 million yuan, and after replenishment it is 1 billion yuan. Therefore, the funding gap ratio is... (Threshold).

[0164] Global reward function implementation (executed by distributed collaborative decision-making module 20):

[0165] r=α1*(1 (funding gap ratio) + β1 * (1 |Exchange Rate Volatility|) + λ1 * Rebalancing Cost Savings

[0166] Parameter values: α1=0.5, β1=0.4, λ1=0.1, discount factor γ=0.9;

[0167] Data input: Funding gap rate 0.3% → (1 0.3% = 0.997, exchange rate volatility 0.1% → (1 0.1% = 0.999, the cost saving rate of rebalancing is 100% → 1;

[0168] Reward calculation: r = 0.5 × 0.997 + 0.4 × 0.999 + 0.1 × 1 = 0.9981.

[0169] The QMIX model parameters are updated using time-difference (TD) error to optimize subsequent portfolio rebalancing strategies.

[0170] Step 2: Real-time pricing of mixed exchange rates

[0171] Pricing calculation module 40 calls the improved AMM algorithm to calculate the base exchange rate based on the real-time liquidity pool reserves provided by state-aware module 10:

[0172] The base exchange rate (digital currency of country A → digital currency of country B) = total amount of digital currency of country B in the liquidity pool / total amount of digital currency of country A = 75 million / 60 million = 1.25 (i.e., 1 digital currency of country A = 1.25 digital currency of country B).

[0173] The oracle module captures the official guidance prices from the People's Bank of China and the Hong Kong Monetary Authority in real time (1 Country A digital currency = 1.23 Country B digital currency) and calibrates them with a 60% weight.

[0174] The final exchange rate = base exchange rate × 40% + central bank guidance price × 60% = 1.25 × 0.4 + 1.23 × 0.6 = 1.238 (i.e., 1 Country A digital currency = 1.238 Country B digital currency).

[0175] Volatility verification:

[0176] ERV= ×100%=| |×100%≈0.24%, take an approximate value of 0.2%<1.5% (threshold), where ERV represents the fluctuation range, CCER represents the exchange rate after this calibration, and RCER represents the exchange rate after the previous calibration.

[0177] After the verification is successful, the exchange rate is synchronized to the cross-chain execution module 30.

[0178] Step 3: Compliance Audit and Privacy Protection

[0179] Transaction data encryption: The cross-chain execution module 30 encrypts the transaction information (F's digital currency account in country A, G's digital currency account in country B, amount of 1 million) and transmits it to the compliance audit module 50.

[0180] The compliance audit module 50 performs compliance rule verification (no abnormal transactions in account F) and data localization verification (data F resides within country A, and data G resides on a node in country B). Upon successful verification, plaintext audit credentials are generated using zero-knowledge proofs and synchronized to country A's cross-border transaction supervision system.

[0181] Step 4: Cross-chain clearing and result feedback

[0182] The cross-chain execution module 30 calls the preset smart contract and calculates the receiving amount based on the final exchange rate (1.238) output by the pricing calculation module 40: 1 million A-country digital currency × 1.238 = 1.238 million B-country digital currency. Then, the fund transfer is executed, that is, 1 million A-country digital currency is deducted from F's account in the liquidity pool, and 1.238 million B-country digital currency is transferred to G's account. The liquidity pool is updated to 59 million A-country digital currency and 73.762 million B-country digital currency, and clearing certificates are returned to F and G. The entire process takes 8 seconds.

[0183] This embodiment achieves liquidity optimization, exchange rate pricing, compliance auditing, and efficient clearing for cross-border transactions through the coordinated operation of the state awareness module 10, the distributed collaborative decision-making module 20, the cross-chain execution module 30, the pricing calculation module 40, and the compliance audit module 50.

[0184] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention. Therefore, the scope of protection of this patent should be determined by the appended claims.

Claims

1. A cross-chain digital currency collaborative pricing system for distributed networks, characterized in that, The system is deployed in a decentralized network composed of multiple participating nodes, each node maintaining the reserve status of its associated digital currency. The system includes: The status awareness module is deployed on each participating node to collect and process heterogeneous data that reflects the status of the associated digital currency market and reserve status of the node in real time, forming node status data. The distributed collaborative decision-making module is connected to each of the state perception modules and is built based on a multi-agent reinforcement learning framework. It is used to generate collaborative control instructions for dynamically adjusting the digital currency reserves of each participating node based on the state data of each participating node through collaborative training and distributed decision-making among agents. The cross-chain execution module, connected to the distributed collaborative decision-making module, is used to convert the collaborative control instructions into multilateral asset transfer operations executed atomically through smart contracts, so as to coordinate the synchronous update of the digital currency reserve status of each participating node. The pricing calculation module connects to each participating node and is built on a federated learning framework. It is used to collaboratively generate and output a multilateral real-time exchange rate for settlement, based on the updated digital currency reserve status of each participating node and by integrating external benchmark exchange rate data, while protecting the data privacy of each participating node.

2. The cross-chain digital currency collaborative pricing system for distributed networks according to claim 1, characterized in that, The digital currency reserves maintained by each participating node together constitute a multilateral digital currency liquidity pool. The initial liquidity of the liquidity pool is composed of the digital currency reserves deposited by the issuers corresponding to each participating node and the elastic market-making funds provided by market makers.

3. A cross-chain digital currency collaborative pricing system for distributed networks according to claim 2, characterized in that, The collaborative control command is a dynamic adjustment command for the reserve ratio of each currency in the liquidity pool; The heterogeneous data collected by the state awareness module includes the real-time reserve amount of each currency in the liquidity pool and the cross-border trading activity data of each currency.

4. A cross-chain digital currency collaborative pricing system for distributed networks according to claim 2, characterized in that, The distributed collaborative decision-making module adopts a centralized training and distributed execution architecture, including: The intelligent agents deployed on each participating node act as executors to generate candidate actions based on local node state data. A centralized trainer is used to jointly optimize the policy network of the multi-agent reinforcement learning framework using a reinforcement learning algorithm based on the global state and training-related data obtained from each agent, wherein the optimization objective includes at least minimizing the overall funding gap rate of the liquidity pool. The collaborative control commands are output in a distributed manner by each agent according to the optimized policy network.

5. A cross-chain digital currency collaborative pricing system for distributed networks according to claim 4, characterized in that, The reinforcement learning algorithm is a monotonic value function decomposition method, which uses a hybrid network to nonlinearly aggregate the local action value functions of each agent to ensure the monotonicity of the joint action value function during the training phase and to achieve decentralized decision-making for each agent during the execution phase.

6. A cross-chain digital currency collaborative pricing system for distributed networks according to claim 1, characterized in that, The pricing calculation module includes: The local pricing unit, deployed at each participating node, is used to calculate the local base exchange rate based on the updated digital currency reserve status of the node through an automated market maker model. The federated learning aggregation unit is used to perform secure aggregation computation on the model parameter update amount uploaded by each local pricing unit based on a secure multi-party computation protocol, so as to update the global hybrid pricing model and distribute the updated model parameters to each local pricing unit. The hybrid pricing model is used to dynamically weight and integrate the local base exchange rate with the external benchmark exchange rate data.

7. A cross-chain digital currency collaborative pricing system for distributed networks according to claim 6, characterized in that, The external benchmark exchange rate data is obtained through a decentralized oracle network; The oracle network connects to multiple authoritative data sources and performs cross-validation and trusted aggregation of the obtained official exchange rate guidance based on the Byzantine fault-tolerant consensus mechanism.

8. A cross-chain digital currency collaborative pricing system for distributed networks according to claim 1, characterized in that, The system also includes a compliance audit module, which interacts with the pricing calculation module and / or the cross-chain execution module to generate verifiable compliance proofs for the transaction process based on zero-knowledge proof technology.

9. A cross-chain digital currency collaborative pricing system for a distributed network according to claim 1, 3, or 8, characterized in that, The state-aware module collects the heterogeneous data at dynamically configurable multi-level frequencies. Among them, cross-border transaction popularity data and reserve status data are collected at the highest frequency, external benchmark exchange rate data is collected at the second medium frequency, and compliance rule data is collected at the third low frequency.

10. A cross-chain digital currency collaborative pricing system for distributed networks according to claim 1, characterized in that, The cross-chain execution module is deployed in a trusted execution environment; The decentralized network adopts a delegated proof-of-stake consensus mechanism based on multi-dimensional reputation rating, in which consensus nodes are dynamically elected based on their computing performance, network stability, and security history.

Images