An automated settlement and reconciliation method and system for rwa asset return allocation

Abstract

The application provides a kind of RWA asset income distribution automation settlement and reconciliation method, comprising: (1) multidimensional data acquisition;(2) data cross-validation and trusted packaging;(3) trusted data on-chain and contract call;(4) income right ratio calculation correction and batch transfer;(5) allocation evidence pair construction and verification preprocessing;(6) multi-chain income collaborative management and Gas fee optimization;(7) investor reconciliation inquiry and multi-party interest balance verification.The application aims at the systematic deficiencies of existing RWA income distribution technology in efficiency, cost, transparency and compatibility, solves the core problems of artificial dependence, high intermediary cost, verification difficulty and cross-chain fragmentation by building off-chain and on-chain trusted collaborative system, and lays a technical foundation for large-scale commercial application of RWA asset tokenization.

Description

Technical Field

[0001] This invention relates to the field of blockchain and financial technology intersection, and in particular to an automated settlement and reconciliation method and system for RWA asset income distribution. Background Technology

[0002] Real-world asset (RWA) tokenization is the process of converting the rights and value of offline physical assets into on-chain digital tokens using blockchain technology. This field is developing rapidly, but the post-distribution operation and management of revenue distribution has become a key obstacle restricting its large-scale application. Existing technologies have significant shortcomings: First, revenue distribution heavily relies on manual operation, resulting in long processes and susceptibility to human error. Even with smart contracts in some projects, manual import of offline data is still required, failing to achieve full automation. Second, the revenue distribution path involves multiple intermediaries, leading to high fees and operating costs, impacting the profitability of the business model. Third, off-chain asset revenue data and on-chain distribution records are isolated, lacking immutable correlation, making it difficult for investors to verify the authenticity and accuracy of the distribution, resulting in complex audits and high trust costs. Fourth, multi-chain deployed RWA assets lack effective cross-chain collaborative management mechanisms, leading to fragmented asset revenue collection, calculation, and distribution, resulting in a poor user experience. Summary of the Invention

[0003] This invention provides an automated settlement and reconciliation method and system for RWA asset revenue distribution. Addressing the systemic shortcomings of existing RWA revenue distribution technologies in terms of efficiency, cost, transparency, and compatibility, this invention solves core problems such as reliance on manual labor, high intermediary costs, verification difficulties, and cross-chain fragmentation by constructing a trusted off-chain and on-chain collaborative system. This lays the technical foundation for the large-scale commercial application of RWA asset tokenization.

[0004] To achieve the above objectives, the present invention adopts the following technical solution: An automated settlement and reconciliation method for RWA asset income distribution includes: (1) Real-time collection of raw RWA asset return data from off-chain data sources; (2) Send the original RWA asset revenue data to a verification committee composed of multiple independent nodes. The committee members use threshold signature technology to cross-verify the authenticity and consistency of the original RWA asset revenue data. Generate a joint signature for the verified original RWA asset revenue data to form a trusted data packet carrying multiple signatures. (3) Upload the trusted data packet carrying multi-signatures to the blockchain network and call the revenue distribution main contract pre-deployed on the blockchain network; (4) The main contract for revenue distribution queries the pre-deployed asset distribution relationship map. The asset distribution relationship map is a dataset associated with the main contract for revenue distribution and records the proportion of revenue rights corresponding to each RWA token address in the form of key-value pairs. The main contract for revenue distribution calculates the current total revenue based on the original RWA asset revenue data, and calculates the amount of revenue due for each RWA token address by combining the proportion of revenue rights in the asset distribution relationship map, and automatically initiates batch transfers. (5) Each batch transfer corresponds to an allocation transaction that generates a globally unique settlement certificate hash on the chain. The settlement certificate hash is anchored to the off-chain original certificate hash corresponding to the original RWA asset revenue data to form a verifiable allocation evidence pair. (6) If RWA assets are deployed on multiple blockchain networks, the revenue of each blockchain network will be managed in a unified manner through a pre-set cross-chain settlement engine; (7) Investors query the batch transfer details and allocation evidence pairs, input any hash in the allocation evidence pair, and trace back the data flow and fund flow from step (1) to step (4) to complete the reconciliation verification.

[0005] In this specification, the threshold signature technology described in step (2) adopts the (t,n) mode, that is, at least t nodes among the n independent nodes of the verification committee complete the signature confirmation, and the original data of RWA asset income can be verified and generate a joint signature, where n and t are preset positive integers and t < n.

[0006] In this specification, the asset distribution relationship map described in step (4) adopts an event-driven update mechanism. When an RWA token transfer, issuance or destruction event occurs, the revenue distribution main contract triggers the map to be updated in real time, ensuring that the revenue rights ratio corresponding to each RWA token address is always accurate.

[0007] In this specification, the cross-chain settlement engine described in step (6) achieves multi-chain collaborative management through the cross-chain message protocol, specifically including two methods: First, the RWA asset income on multiple blockchain networks is uniformly collected into a preset main chain, and the income distribution main contract centrally calculates and distributes the income; Second, the distribution instructions are distributed to the sub-contracts of each blockchain network according to the asset distribution relationship map, so as to achieve one-time calculation and multi-chain synchronous distribution.

[0008] In this specification, step (1) involves collecting raw data of RWA asset returns through a trusted data oracle. The collection methods include receiving webhook notifications from the payment gateway, obtaining periodic reports from the enterprise ERP system, and receiving encrypted data streams from IoT sensors. The off-chain data sources include the payment gateway, the enterprise ERP system, and IoT sensors.

[0009] In this specification, the independent nodes of the verification committee mentioned in step (2) are operated by at least two types of entities, namely operators, regulatory agencies, and third-party notaries, to ensure the independence of each node and the impartiality of the verification results.

[0010] In this specification, the profit rights ratio mentioned in step (4) is calculated by a dynamic profit rights allocation algorithm. This algorithm comprehensively considers the amount of staking, historical staking duration, recent active time, RWA asset risk assessment data, governance participation records and holding continuity of each RWA token address. After basic weight calculation, risk adjustment and behavioral incentive factor weighting, the final profit rights ratio is obtained.

[0011] In this specification, the cross-chain settlement engine in step (6) adopts a dynamic gas fee optimization decision model based on reinforcement learning. This model obtains the current gas price, the total amount of revenue to be distributed, the number of transactions to be merged, the historical average waiting time and network congestion indicators in real time, and dynamically selects the transaction strategy of immediate execution or continued waiting, so as to control gas costs while ensuring the timely arrival of revenue.

[0012] In this manual, the reconciliation verification in step (7) adopts a dual-mode architecture: Mode 1 is public verification, which generates a hash of the allocation certificate that can be directly queried on the chain through the Merkle tree for investors to verify publicly; Mode 2 is privacy verification, which generates zero-knowledge proof through the zk-SNARKs proof circuit, so that investors can complete the verification of the integrity and correctness of the profit distribution without obtaining the specific distribution details.

[0013] An automated settlement and reconciliation system for RWA asset return distribution, applying the automated settlement and reconciliation method for RWA asset return distribution described above, comprises: a data acquisition and verification module, a smart contract module, an asset graph management module, a cross-chain settlement engine module, and a user interaction module. The data acquisition and verification module includes a trusted data oracle and verification committee nodes, used to collect, cross-validate, and jointly sign raw RWA asset return data. The smart contract module is deployed on a blockchain network, including a main return distribution contract and sub-contracts, used to calculate the total return amount, calculate the due return amount, initiate batch transfers, and generate settlement voucher hashes. The asset graph management module maintains an asset distribution graph, supporting event-driven updates and return right ratio queries. The cross-chain settlement engine enables collaborative management of returns across multiple blockchain networks and gas fee optimization. The user interaction module is a DApp interface used to display batch transfer details and distribution evidence pairs to investors, supporting hash queries and data flow and fund flow traceability verification.

[0014] In summary, the present invention has at least the following beneficial effects: Significantly improve the efficiency and accuracy of profit distribution by replacing manual operations with automated processes, avoiding human error and shortening the distribution cycle; Significantly reduce operating and transaction costs related to revenue distribution, reduce reliance on intermediaries, and make small-amount, high-frequency revenue distribution economically feasible. Enhance the transparency and credibility of profit distribution, build a verifiable chain of evidence across the entire chain, and allow investors to independently verify the source and distribution details of profits without permission; This enables collaborative management of multi-chain RWA assets, breaks down the fragmented management of cross-chain asset returns, lays the foundation for building complex multi-chain RWA financial products, and enhances system scalability and interoperability. Attached Figure Description

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

[0016] Figure 1 This is a flowchart illustrating the automated settlement and reconciliation method for RWA asset income distribution involved in this invention. Detailed Implementation

[0017] 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.

[0018] The following disclosure provides many different implementations or examples for carrying out different structures of the embodiments of the present invention. To simplify the disclosure of the embodiments of the present invention, specific examples of components and arrangements are described below. Of course, these are merely examples and are not intended to limit the embodiments of the present invention. Furthermore, reference numerals and / or reference letters may be repeated in different examples of the embodiments of the present invention; such repetition is for simplification and clarity and does not in itself indicate a relationship between the various implementations and / or arrangements discussed.

[0019] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0020] like Figure 1 As shown, this embodiment provides an automated settlement and reconciliation method for RWA asset income distribution, including: (1) Multi-dimensional data collection: Real-time collection of raw RWA asset return data from off-chain data sources; (2) Data cross-validation and trusted packaging: The original data of RWA asset revenue is sent to a verification committee composed of multiple independent nodes. The committee members use threshold signature technology to cross-validate the authenticity and consistency of the original data of RWA asset revenue. The verified original data of RWA asset revenue generates a joint signature to form a trusted data packet carrying multiple signatures. (3) Trusted data on-chain and contract invocation: Upload a trusted data packet carrying multi-signature to the blockchain network and invoke the revenue distribution main contract pre-deployed on the blockchain network; (4) Calculation and correction of the profit right ratio and batch transfer: The profit distribution main contract queries the pre-deployed asset distribution relationship map. The asset distribution relationship map is a dataset associated with the profit distribution main contract and records the profit right ratio of each RWA token address in the form of key-value pairs. The profit distribution main contract calculates the current total profit based on the original RWA asset profit data, and calculates the profit amount due for each RWA token address by combining the profit right ratio in the asset distribution relationship map, and automatically initiates batch transfer. (5) Construction and verification of allocation evidence pairs: Each batch transfer corresponding to the allocation transaction generates a globally unique settlement certificate hash on the chain. The settlement certificate hash is anchored to the off-chain original certificate hash corresponding to the original RWA asset revenue data to form a verifiable allocation evidence pair. (6) Multi-chain revenue collaborative management and gas fee optimization: If RWA assets are deployed on multiple blockchain networks, the revenue of each blockchain network is managed in a unified manner through a preset cross-chain settlement engine. (7) Investor reconciliation and verification of the balance of interests among multiple parties: Investors query the batch transfer details and allocation evidence pairs, input any hash in the allocation evidence pair, and trace back the data flow and fund flow from step (1) to step (4) to complete the reconciliation verification.

[0021] In some embodiments, the threshold signature technology in step (2) adopts the (t,n) mode, that is, at least t nodes among the n independent nodes of the verification committee complete the signature confirmation, and the original data of RWA asset income can be verified and generate a joint signature, where n and t are preset positive integers and t < n.

[0022] In some embodiments, the asset distribution relationship map described in step (4) adopts an event-driven update mechanism. When an RWA token transfer, issuance or destruction event occurs, the revenue distribution main contract triggers the map to be updated in real time, ensuring that the revenue rights ratio corresponding to each RWA token address is always accurate.

[0023] In some embodiments, the cross-chain settlement engine in step (6) achieves multi-chain collaborative management through a cross-chain message protocol, specifically in two ways: first, the RWA asset income on multiple blockchain networks is uniformly collected into a preset main chain, and the income distribution main contract centrally calculates and distributes the income; second, the distribution instructions are distributed to the sub-contracts of each blockchain network according to the asset distribution relationship map, so as to achieve one-time calculation and multi-chain synchronous distribution.

[0024] In some embodiments, step (1) involves collecting raw data of RWA asset returns through a trusted data oracle. The collection methods include receiving webhook notifications from a payment gateway, obtaining periodic reports from an enterprise ERP system, and receiving encrypted data streams from IoT sensors. The off-chain data sources include payment gateways, enterprise ERP systems, and IoT sensors.

[0025] In some embodiments, the independent nodes of the verification committee in step (2) are operated by at least two types of entities, namely operators, regulatory agencies, and third-party notaries, to ensure the independence of each node and the impartiality of the verification results.

[0026] In some embodiments, the profit rights ratio mentioned in step (4) is calculated by a dynamic profit rights allocation algorithm. This algorithm comprehensively considers the amount of staking, historical staking duration, recent active time, RWA asset risk assessment data, governance participation records and holding continuity of each RWA token address. After basic weight calculation, risk adjustment and behavioral incentive factor weighting, the final profit rights ratio is obtained.

[0027] In some embodiments, the cross-chain settlement engine in step (6) adopts a dynamic gas fee optimization decision model based on reinforcement learning. This model obtains the current gas price, the total amount of revenue to be distributed, the number of transactions to be merged, the historical average waiting time and network congestion indicators in real time, and dynamically selects the transaction strategy of immediate execution or continued waiting, so as to control gas costs while ensuring the timely arrival of revenue.

[0028] In some embodiments, the reconciliation verification in step (7) adopts a dual-mode architecture: Mode 1 is public verification, which generates an on-chain queried allocation certificate hash through a Merkle tree for investors to publicly verify; Mode 2 is privacy verification, which generates zero-knowledge proofs through zk-SNARKs proof circuits, allowing investors to complete the verification of the integrity and correctness of the profit distribution without obtaining specific allocation details.

[0029] An automated settlement and reconciliation system for RWA asset return distribution, applying the automated settlement and reconciliation method for RWA asset return distribution described above, comprises: a data acquisition and verification module, a smart contract module, an asset graph management module, a cross-chain settlement engine module, and a user interaction module. The data acquisition and verification module includes a trusted data oracle and verification committee nodes, used to collect, cross-validate, and jointly sign raw RWA asset return data. The smart contract module is deployed on a blockchain network, including a main return distribution contract and sub-contracts, used to calculate the total return amount, calculate the due return amount, initiate batch transfers, and generate settlement voucher hashes. The asset graph management module maintains an asset distribution graph, supporting event-driven updates and return right ratio queries. The cross-chain settlement engine enables collaborative management of returns across multiple blockchain networks and gas fee optimization. The user interaction module is a DApp interface used to display batch transfer details and distribution evidence pairs to investors, supporting hash queries and data flow and fund flow traceability verification.

[0030] The technical concept of this invention is as follows: This solution constructs a trusted closed loop connecting the off-chain real world and the on-chain digital world. Its core achieves end-to-end automation and transparency through five modules and three collaborative algorithms: First, it establishes an off-chain data uplink based on a trusted data oracle, triggering smart contracts after completing revenue data collection and multi-node threshold signature verification. Second, the smart contract cluster drives automated settlement and reconciliation, accurately calculating revenue distribution ratios and initiating batch transfers through an asset distribution graph, while simultaneously generating hash credentials anchored to both on-chain and off-chain data. Third, it achieves unified collection and accounting or synchronous distribution of multi-chain asset revenues through a cross-chain settlement engine. Fourth, it provides a DApp user interface to support investor inquiries and verification. Fifth, through dynamic revenue rights allocation, gas fee optimization, and dual-mode hash verification algorithms, it respectively ensures distribution fairness, reduces transaction costs, and balances verification efficiency and privacy protection, ultimately achieving end-to-end automation from revenue data collection, verification, distribution to auditing.

[0031] The specific technical solution of this system is as follows: System Hardware and Network Architecture: The system is deployed on a cloud server cluster. Core components include a data acquisition and verification module, a smart contract module, an asset graph management module, a cross-chain settlement engine module, and a user interaction module. These modules interact with each other through pre-defined communication protocols. The system connects to off-chain data sources (such as bank payment systems and IoT platforms) via API interfaces and communicates with the target blockchain network through node clients.

[0032] Oracle-based trusted data uplink: Data Acquisition: A trusted data oracle monitors and collects revenue information from off-chain data sources in real time. This data can come from webhook notifications from payment gateways, scheduled reports from enterprise ERP systems, or encrypted data streams directly from IoT sensors.

[0033] Multi-node verification and signing: The collected raw data is sent to a verification committee composed of multiple independent nodes (which can be run by operators, regulatory agencies, or third-party notaries). Committee members use threshold signature technology to cross-verify the authenticity and consistency of the data, and jointly sign the verified data packets to ensure that the data has reached a consensus and is tamper-proof before being uploaded to the blockchain.

[0034] Triggering the smart contract: A trusted data packet carrying multi-signatures is uploaded to the blockchain network by the oracle and invokes the pre-deployed main contract for revenue distribution.

[0035] Smart contract-driven automated settlement and reconciliation engine: Automatic Settlement: Once the main revenue distribution contract is triggered, it automatically executes predefined distribution rules. The contract first queries the asset distribution graph, which records the revenue right ratio corresponding to each RWA token address in key-value pairs. Subsequently, the contract calculates the amount due to each address proportionally based on the current total revenue and automatically initiates batch transfer transactions.

[0036] Real-time reconciliation: Every allocation transaction is recorded on-chain, generating a globally unique settlement voucher hash. This hash is anchored to the original voucher hash of the off-chain data source, together forming a verifiable allocation evidence pair. Investors and auditors can input any hash through the DApp interface to trace and verify the entire data and fund flow in reverse, achieving reconciliation within seconds.

[0037] Cross-chain asset collaboration: For RWA assets deployed on multiple chains, the system achieves collaboration through a cross-chain settlement engine. This engine utilizes a cross-chain messaging protocol to unify the revenue from different chains into a single "main chain" for accounting, or distributes instructions to sub-contracts on each chain based on the asset distribution graph, achieving "one-time accounting, multi-chain synchronous distribution" and providing investors with a unified view of revenue.

[0038] The present invention has the following significant advantages: 1. Ultimate Efficiency and Precision: By replacing manual operations with smart contracts, the profit distribution cycle is shortened from days to minutes or even seconds, achieving near real-time T+0 settlement. Automated execution eliminates human calculation errors, ensuring 100% accuracy of the distribution results.

[0039] 2. Significantly Reduced Costs: By drastically reducing intermediary steps, high fees paid to multiple intermediaries are avoided. The automated execution of smart contracts minimizes operational manpower costs, making the allocation of small, high-frequency returns economically feasible and significantly improving the ROI of RWA projects.

[0040] Unprecedented transparency and credibility: Through on-chain and off-chain data anchoring technology, a fully verifiable chain of evidence is created from the asset side to the investor's wallet. Any investor can verify the source and distribution details of every return at any time without permission, building "trust" on publicly verifiable code and cryptographic proofs, greatly enhancing market confidence.

[0041] 3. Strong scalability and interoperability: The built-in cross-chain settlement engine enables it to seamlessly manage RWA assets deployed on different blockchain networks, laying the foundation for building complex, multi-chain RWA financial products in the future and avoiding ecosystem fragmentation.

[0042] Method steps of the present invention (process perspective): The implementation of the method includes the following key steps: Establishment of a trusted data uplink: Data Acquisition: Real-time monitoring and collection of revenue information from off-chain data sources via trusted data oracles.

[0043] Multi-node verification and threshold signature: The collected raw data is sent to a verification committee composed of multiple independent nodes. Committee members use threshold signature technology to cross-verify the authenticity and consistency of the data. The threshold value setting logic can adopt an (t,n) pattern, for example, at least 3 signatures out of 5 nodes are required to pass, ensuring fault tolerance and security.

[0044] Triggering the smart contract: A trusted data packet carrying a valid multi-signature is uploaded to the blockchain by the oracle, and the main contract for profit distribution is invoked.

[0045] Automated settlement and reconciliation driven by smart contracts: Automatic settlement: The contract queries the asset distribution graph, calculates the amount due to each address proportionally based on the current total revenue, and automatically initiates batch transfers. The graph update mechanism is event-driven; when token transfers, issuances, or destructions occur, the graph is updated in real time via contract events.

[0046] Real-time reconciliation: Each allocation transaction generates a globally unique settlement voucher hash on the chain, which is anchored to the original off-chain voucher hash to form a verifiable evidence pair.

[0047] Cross-chain asset collaboration: Achieve unified management of multi-chain asset returns through a cross-chain settlement engine. Cross-chain communication protocols can utilize technologies such as relay chains, sidechains, or light nodes; the specific choice requires a trade-off between security, efficiency, and development complexity.

[0048] Investor Inquiry and Verification: Investors can check their earnings details through the DApp interface and use the settlement voucher hash to trace the entire data flow and fund flow in reverse, achieving reconciliation in seconds.

[0049] System modules of this invention (architectural perspective): The hardware and network architecture of this system is deployed on a cloud server cluster, and the core functional modules are as follows: Data Acquisition and Verification Module: Responsible for data acquisition and multi-node verification and threshold signature steps, including oracle client and signature verification service.

[0050] Smart contract module: Responsible for automatic settlement and real-time reconciliation, it is the core logic processing unit of the system and is deployed on the blockchain.

[0051] Cross-chain settlement engine module: responsible for cross-chain asset collaboration steps, and is the key to achieving multi-chain collaboration.

[0052] Asset Mapping Management Module: Maintains asset distribution maps and provides quick access to ownership and proportion queries.

[0053] User interaction module: Provides the DApp front-end, responsible for user interaction during investor inquiry and verification processes.

[0054] The invention will now be explained in detail with an application example and three core algorithms.

[0055] Application Example: Daily Revenue Distribution of Distributed Charging Piles Scenario: A charging pile operating company owns 1,000 charging piles and has issued 100 million revenue-sharing tokens.

[0056] 1. System initialization: Contract Deployment: Write and deploy the contract to the corresponding blockchain using Solidity. Initialization Parameters: Allocation period is 24 hours, operator address, and initial profit share calculated using Algorithm 1.

[0057] Oracle and Verification Committee: Configure the Chainlink oracle and form a 5-node verification committee consisting of operators, regulatory agencies, and third-party auditors, setting the threshold value to 3.

[0058] 2. One allocation cycle: Data Acquisition: The oracle periodically retrieves data from the platform API, such as "Date: 2025-11-19, Total Profit: 10,000 USDC".

[0059] Verification and Execution: Once the data is verified and signed by the committee, the contract is triggered. The contract calculates the investor's net return as 9,000 USDC and distributes it automatically.

[0060] Results: In the traditional method, this allocation would require 2 person-days and is prone to errors; this system achieves fully automatic allocation within minutes with 100% accuracy.

[0061] The core advantage of this system lies in its three collaborative algorithms.

[0062] Algorithm 1: Dynamic Revenue Rights Allocation Algorithm Based on Risk Adjustment and Behavioral Incentives This algorithm is used to accurately calculate the dynamic weight of each token address in the distribution of RWA (Real-World Asset) revenue. By comprehensively considering multiple factors such as the address's risk-taking, loyalty contribution, and governance participation, it achieves a fairer and incentive-compatible revenue distribution mechanism.

[0063]

[0064] Algorithm 1 processing logic: 1. Calculation of Basic Income Rights Weights Basic yield right weight calculation: Basic quantity weight = staked quantity / total token supply; 2. Risk Adjustment Factor Module: Base Risk Coefficient (BRC) = Risk level of RWA assets obtained from external oracles (range 0.8-1.5, low risk 0.8, high risk 1.5). Risk-adjusted quantity weight = base quantity weight × BRC; 3. Behavioral Motivation Factor Module: Loyalty factor: calculated non-linearly based on continuous holding time (e.g., 1 year = 1.0, 2 years = 1.1, 3 years = 1.25). Governance participation factor: A bonus is awarded based on the number and proportion of participation in on-chain governance voting (e.g., a coefficient of 1.2 for participation rate > 80%). Comprehensive behavioral factor = Loyalty factor × 0.7 + Governance participation factor × 0.3; 4. Final dynamic weight: Final return right weight = risk-adjusted quantity weight × comprehensive behavioral factor.

[0065] Algorithm 2: Dynamic Gas Fee Optimization Decision Model Based on Reinforcement Learning When revenue needs to be distributed across chains, the algorithm uses reinforcement learning to intelligently merge transactions to significantly reduce gas fee consumption while balancing timely settlement.

[0066] Reinforcement learning framework: State ): Real-time Gas price, total revenue to be distributed, number of transactions to be merged, historical average waiting time, network congestion indicators; Action ): {"Execute immediately", "Continue to wait"}; Reward function ): =-(Total Gas Fee for this Transaction / Total Transfer Amount) × -(Average waiting time)× (in and (As weighted, reflecting preferences for cost and time). Multi-objective optimization: The algorithm dynamically learns the optimal strategy, seeking Pareto optimality between gas cost and waiting time. Simulations show that this model can reduce gas costs for high-frequency, small-amount transfers by 60%-80%, while keeping the average waiting time within an acceptable range for users.

[0067] Algorithm 3: Multi-chain revenue reconciliation hash verification algorithm (including zero-knowledge proof option) This algorithm generates a lightweight global verification hash and introduces a zero-knowledge proof option to achieve instant verification with privacy protection.

[0068] Dual-mode verification architecture: Mode A (Public Verification): Using the Merkle tree scheme, generate on-chain verifiable allocation credential hashes.

[0069] Mode B (Privacy Verification): Introduces zk-SNARKs proof circuitry to generate zero-knowledge proofs for each round of allocation. Verifiers can verify the integrity and correctness of the entire batch of allocations within milliseconds using a very small proof file (a few hundred bytes), without exposing specific allocation details.

[0070] Processing flow: 1. In the chain After the allocation is completed, calculate the Merkle root hash of all allocation transactions on the chain. .

[0071] 2. It is submitted along with timestamps, chain IDs, etc., to the blockchain that serves as the "anchor".

[0072] 3. Investors can choose either Mode A or Mode B for verification. Mode B is particularly suitable for scenarios that require the protection of sensitive business information.

[0073] Algorithm Collaboration Workflow: The dynamic profit rights ratio calculated by Algorithm 1 serves as a key input for Algorithm 2's transaction merging judgment; the merged transaction records of Algorithm 2, in turn, serve as the basis for Algorithm 1 to update user activity characteristics; the verification result of Algorithm 3 triggers Algorithm 2's resend mechanism when a transaction fails; the outputs of Algorithms 1 and 2 together constitute the verification basis of Algorithm 3. The three form a closed loop, ensuring that the system is efficient, transparent, and scalable.

[0074] Through the innovation of the above-mentioned system and method, this invention effectively solves the key technical bottlenecks in RWA revenue distribution, laying a solid foundation for large-scale commercial application.

[0075] In some embodiments, the base risk coefficient (BRC) of the dynamic revenue distribution algorithm in step (4) ranges from 0.8 to 1.5, where low-risk RWA assets (such as rental income from mature commercial real estate) correspond to BRC=0.8-1.0, medium-risk assets (such as revenue from new energy infrastructure) correspond to BRC=1.1-1.3, and high-risk assets (such as accounts receivable from early-stage projects) correspond to BRC=1.4-1.5. This risk level is updated quarterly by an external oracle and synchronized to the revenue distribution master contract.

[0076] In some embodiments, the loyalty factor of the dynamic benefit distribution algorithm in step (4) is calculated nonlinearly according to the following rules: the coefficient is 1.0 for continuous holding for 1 year or less, 1.1 for 1-2 years (inclusive), 1.25 for 2-3 years (inclusive), and 1.4 for more than 3 years; the governance participation factor is determined according to the proportion of participation in on-chain governance voting, with a participation rate ≤50% having a coefficient of 1.0, 50%-80% (inclusive) having a coefficient of 1.1, and >80% having a coefficient of 1.2.

[0077] In some embodiments, in the reinforcement learning-based dynamic gas fee optimization decision model described in step (8), the weights of the reward function... The value ranges from 0.6 to 0.8. The value ranges from 0.2 to 0.4, and can be dynamically adjusted based on the RWA project type (such as in scenarios involving small, high-frequency allocations). =0.8、 =0.2, in scenarios involving large-amount, low-frequency allocations =0.6、 =0.4); the decision threshold of the model is set as follows: when the real-time gas price is lower than 60% of the historical 7-day average price, the "immediate execution" strategy is executed first; when the gas price is higher than 150% of the historical 7-day average price, the "continue to wait" strategy is triggered.

[0078] In some embodiments, in the dual-mode verification architecture described in step (9), the Merkle tree in mode one uses the SHA-256 algorithm to generate hash values. The leaf nodes are the combination data of "token address + amount due + timestamp" for a single allocation transaction, and the non-leaf nodes are the result of splicing the hash values ​​of the two nodes at the next level. The number of constraints in the zk-SNARKs proof circuit in mode two is set to 8-12, including core constraints such as consistency of total allocation, compliance of the proportion of benefit rights, and validity of hash anchoring. The size of the proof file is controlled within 512 bytes.

[0079] In some embodiments, the number of n in the verification committee in step (2) is 3-7, and the number of t is ceil(n×2 / 3) (rounded up). A typical configuration is n=5 and t=3. The hardware configuration requirements for independent nodes are CPU≥8 cores and memory≥16GB. Nodes transmit verification data through encrypted communication protocols (such as TLS 1.3) to prevent data tampering or leakage.

[0080] In some embodiments, the cross-chain settlement engine in step (6) uses the Polkadot relay chain protocol or the target blockchain network sidechain protocol as the cross-chain message protocol. When the "main chain aggregation" method is used, the sub-chain revenue is aggregated to the main chain once per hour through the cross-chain bridge. The aggregation process uses zero-knowledge proof encryption transmission. When the "multi-chain synchronous distribution" method is used, the communication delay between the main contract and the sub-contract is controlled within 30 seconds, and the execution result of the sub-contract needs to return a confirmation receipt to the main contract.

[0081] In some embodiments, in the event-driven update mechanism of the asset distribution relationship map described in step (4), the threshold for triggering the update of token transfer is that the amount of a single transfer is ≥ 0.1% of the total issuance of RWA tokens. Transfer transactions below this threshold are accumulated and updated uniformly at 24:00 on the same day. When updating the map, the principle of "update first and then allocate" is adopted to ensure that the proportion of income rights has been synchronized with the latest status before allocation. When the update fails, the contract retry mechanism is triggered, and the number of retries does not exceed 3 times, with an interval of 5 seconds between each retries.

[0082] In some embodiments, the trusted data oracle in step (1) adapts the format of heterogeneous data sources as follows: the webhook notification of the payment gateway, the timed report of the ERP system, and the encrypted data stream of the IoT sensor are uniformly converted into the JSON format of “asset ID + revenue amount + transaction time + data source identifier”, wherein the numerical data retains 2 decimal places, the timestamp is uniformly in UTC format, and the data source identifier is standardized and encoded according to “payment gateway = PG, ERP system = ERP, IoT sensor = IOT”.

[0083] In some embodiments, the encrypted transmission scheme for data acquisition in step (1) is as follows: the oracle and the off-chain data source use HTTPS protocol + SHA-256 encryption algorithm to transmit data. Before data transmission, a random salt value (salt value length is 16 bytes) is added, and the integrity of the transmitted data is verified (the verification code is generated using CRC32 algorithm). If the verification fails, the data is retransmitted, and the number of retransmissions does not exceed 5 times.

[0084] In some embodiments, the off-chain original certificate hash in step (5) is generated using the SHA-256 algorithm, and the generation rule is a combination hash of "original data string + random salt value". The salt value and the corresponding settlement certificate hash are stored on the chain together. The reverse tracing function of the DApp interface in step (7) adopts a joint indexing mechanism of "block height + hash value". After inputting the hash, the corresponding data stream (original data, verification record, allocation calculation process) and fund flow (transfer transaction record, block confirmation status) details are returned within 1 second.

[0085] In some embodiments, when the trusted data oracle in step (1) collects the original data of RWA asset returns, a dual reinforcement mechanism of hardware security module (HSM) and blockchain timestamp is introduced: the oracle has an HSM built into it that conforms to the FIPS 140-3 standard, performs hardware-level encrypted storage of the collected original data, and uploads the data collection timestamp to the blockchain as the "anchor" for anchoring, generating a four-dimensional trusted identifier of "data content + collection time + HSM encrypted signature + mainnet timestamp". This identifier is sent to the verification committee along with the original data to further eliminate the risk of data tampering and time forgery.

[0086] In some embodiments, based on the aforementioned four-dimensional trusted identifier mechanism, the dynamic benefit right allocation algorithm in step (4) introduces an edge computing preprocessing stage: while performing cross-validation, each verification committee node performs localized preliminary calculations on the token address characteristics (staking amount, historical staking duration, etc.) within the coverage area of ​​its own node through the edge computing node, generates a local benefit right weight intermediate value, and then reports the intermediate value and the four-dimensional trusted identifier to the master node. The master node aggregates all local intermediate values ​​through the Byzantine Fault Tolerance (BFT) algorithm to obtain the final benefit right ratio. This reduces the on-chain computing pressure by more than 40% and avoids allocation delays caused by insufficient computing power of a single node.

[0087] In some embodiments, based on edge computing preprocessing and four-dimensional trusted identifiers, the cross-chain settlement engine in step (6) adopts a hybrid architecture of "DLT relay + zero-knowledge proof": the cross-chain message protocol introduces distributed ledger technology (DLT) as a cross-chain data cache layer on the basis of the Polkadot relay chain. The cache layer only stores the hash of the total revenue of each chain and the digest of the four-dimensional trusted identifier, and does not store the original allocation data. When multi-chain synchronous allocation is performed, the sub-contract verifies the consistency between the hash digest of the cache layer and the main contract instruction through zero-knowledge proof. There is no need to directly transmit the complete data, the cross-chain data transmission volume is reduced by 70%, and the cache layer adopts a sharded storage mechanism. Each shard is hosted by a different entity, which further improves the cross-chain data security.

[0088] In some embodiments, based on the aforementioned hybrid cross-chain architecture, the reconciliation verification in step (7) is enhanced with a federated learning anomaly detection module: the operator, regulatory agency, and investor representatives each deploy federated learning nodes, and jointly train an anomaly transaction detection model based on the locally stored allocation evidence pairs data (the model adopts a lightweight CNN architecture, and the input features are "hash matching degree + transfer amount fluctuation + allocation cycle deviation"). During the model training process, only gradient parameters are transmitted, and the original data is not leaked. When investors trace and verify through the DApp, the system automatically calls the trained model to perform real-time detection of the current data flow and fund flow. If the anomaly probability is higher than 0.05, a secondary verification mechanism is triggered, and the data is re-verified by more than 3 nodes of the verification committee to achieve the dual functions of "verification + anomaly warning".

[0089] In some embodiments, based on the federated learning anomaly detection module, the batch transfer in step (4) adds a dynamic priority scheduling mechanism: the main contract for revenue distribution obtains the asset liquidity rating (rated range L1-L5, L1 is the highest liquidity and L5 is the lowest) of each RWA token address in advance through an external oracle, and combines the anomaly probability output by the federated learning model to determine the transfer order using the "liquidity priority + anomaly probability correction" algorithm - the priority coefficient for addresses with liquidity ratings L4-L5 is 1.5, the priority coefficient for addresses with L1-L3 is 1.0, and the priority coefficient for addresses with anomaly probability higher than 0.03 is reduced by 0.3. The scheduling mechanism is automatically executed by the smart contract to ensure that the returns of assets with poor liquidity are credited first, while avoiding high-risk addresses occupying settlement resources.

[0090] In some embodiments, based on dynamic priority scheduling, the verification committee in step (2) introduces a "dynamic node rotation + reputation points" mechanism: the reputation points of the verification nodes are linked to the data verification accuracy, response speed, and compliance (1 point is added for verification accuracy ≥ 99.5%, 0.5 points are deducted for response delay exceeding 5 seconds, and 5 points are deducted for each violation verification), and the points are updated monthly; every quarter, the bottom 20% of nodes are eliminated based on the reputation points ranking, and new nodes are added from qualified third-party institutions. During the rotation process, node permissions are redistributed through threshold signature technology to ensure that the verification committee always maintains high credibility and avoids the risk of collision caused by long-term fixed nodes (the reputation points calculation rules are published on the blockchain through smart contracts and cannot be tampered with).

[0091] In some embodiments, based on dynamic node rotation and reputation points, the hash anchoring in step (5) adopts a "dual anchor point + cross-chain mutual verification" mechanism: the settlement certificate hash and the off-chain original certificate hash are not only mutually anchored, but also uploaded to the blockchain and Cosmos Hub as "anchor points" for dual anchoring, generating two independent anchoring records; when investors reconcile accounts through the DApp, they can choose any anchoring record to initiate verification, and the system automatically calls the anchoring record of another chain for cross-verification. If the hash matching degree of the two records is ≥99.99%, the verification is deemed to be successful. This mechanism improves the anti-attack capability of the reconciliation results to 3 times that of the original scheme, and is especially suitable for the compliance audit scenario of cross-border RWA assets.

[0092] In some embodiments, based on Algorithms 1-3, Algorithm 4 is added: a cross-dimensional collaborative filtering profit distribution correction algorithm based on multi-party interest balance. Multi-party interest balance aims to reconcile the conflicting interests of investors, operators, and regulatory agencies, while cross-dimensional collaborative correction breaks through the limitations of traditional "single-user feature modeling" and achieves calibration of the cross-influence of user features and asset features. Algorithm 4 innovatively integrates the ideas of "multi-objective collaborative filtering" and "game theory Nash equilibrium," forming a two-way interactive closed-loop linkage with Algorithms 1-3, significantly improving the fairness, stability, and anti-interference capability of the system.

[0093] The updated method steps after applying Algorithm 4 are as follows: (1) Collect raw RWA asset yield data from off-chain data sources in real time through a trusted data oracle, and simultaneously collect user characteristic data and corresponding RWA asset asset asset characteristic data for each RWA token address. The off-chain data sources include payment gateways, enterprise ERP systems, and IoT sensors. User characteristic data includes staking quantity, historical staking duration, recent active time, governance participation record, and holding continuity. Asset characteristic data includes asset risk level, yield stability, verification pass rate, and cross-chain deployment quantity. (2) Send the original data of RWA asset revenue, user characteristic data and asset characteristic data together to the verification committee composed of multiple independent nodes. The committee members use threshold signature technology to cross-verify the authenticity and consistency of the data, and jointly sign the data packets that pass the verification to form a trusted data packet carrying multiple signatures. (3) Upload the trusted data packet carrying multiple signatures to the blockchain network, call the revenue distribution main contract pre-deployed on the blockchain network, and the main contract triggers the initialization of the cross-dimensional collaborative filtering revenue distribution correction algorithm (algorithm 4) based on the balance of interests of multiple parties. (4) The main contract first uses the dynamic profit distribution algorithm (algorithm 1) to combine the parameters such as the amount of pledged and the historical staking duration in the user characteristic data, and calculates the initial profit right ratio through basic weight calculation, risk adjustment and behavioral incentive factor weighting; then it constructs a user-asset cross-dimensional collaborative filtering matrix through algorithm 4, calculates the matching degree between users and corresponding assets and the collaborative filtering correction factor, and dynamically corrects the initial profit right ratio by combining the multi-party interest balance correction coefficient solved by algorithm 4 to obtain the final profit right ratio; the main contract queries the pre-deployed asset distribution relationship map (the map records the profit right ratio corresponding to each RWA token address in the form of key-value pairs, and is updated in real time with the corrected final profit right ratio), calculates the current total profit based on the original RWA asset profit data, calculates the profit amount due for each RWA token address in combination with the final profit right ratio, and automatically initiates batch transfers; (5) Each batch transfer corresponds to an allocation transaction that generates a globally unique settlement certificate hash on the chain. The settlement certificate hash is anchored to the off-chain original certificate hash corresponding to the original RWA asset revenue data to form a verifiable allocation evidence pair. At the same time, the multi-chain revenue reconciliation hash verification algorithm (algorithm 3) selects the verification mode according to the collaborative filtering correction factor output by algorithm 4. If the correction factor is ≥1.0, a publicly verifiable allocation certificate hash is generated using a Merkle tree. If the correction factor is <1.0, a zero-knowledge proof is generated through a zk-SNARKs proof circuit to complete the verification preprocessing of the allocation evidence pair. (6) If RWA assets are deployed on multiple blockchain networks, the revenue of each blockchain network is managed in a unified manner through the preset cross-chain settlement engine. The cross-chain settlement engine calls the dynamic gas fee optimization decision model (algorithm 2) based on reinforcement learning, and uses the final revenue right ratio after Algorithm 4 as the transaction priority parameter. It dynamically selects the transaction strategy of "execute immediately" or "continue to wait" in combination with indicators such as real-time gas price and total amount of revenue to be distributed. At the same time, the reward function weight of Algorithm 2 is adjusted through the multi-party interest balance correction coefficient of Algorithm 4 to balance gas cost and timely arrival of funds. (7) Investors query batch transfer details and allocation evidence pairs through the DApp interface, input any hash in the allocation evidence pair, and trace back the data flow and capital flow from step (1) to step (4) based on the dual-mode verification architecture of Algorithm 3. During the tracing process, the multi-party interest balance correction coefficient of Algorithm 4 synchronously verifies the balance of interests among the three parties. If the abnormal probability is higher than the preset threshold, the verification committee will trigger a second cross-verification to complete the reconciliation verification.

[0094] The specific details of Algorithm 4 are as follows: I. Model Building Process 1. Define the core objectives: Correct the bias in the benefit weight of Algorithm 1 through cross-dimensional collaborative filtering to avoid unfair distribution caused by single user characteristics; Constrain Algorithm 2's Gas fee optimization strategy and Algorithm 3's verification threshold through multi-party interest game equilibrium to ultimately achieve the unity of the three objectives of "benefit fairness + cost optimization + verification security", filling the gap in the existing technology of "single-objective optimization ignoring multi-party interest conflicts".

[0095] 2. Define multiple stakeholders and interest functions: First, identify three core stakeholders: Investors' core demand is to maximize returns and ensure fair distribution, which is directly related to the rationality of dynamic weights in Algorithm 1; operators' core demand is to minimize operating costs and maximize distribution efficiency, which corresponds to the Gas fee optimization effect of Algorithm 2; and regulatory agencies' core demand is to ensure data authenticity and compliance, which is directly linked to the verification confidence level of Algorithm 3.

[0096] To quantify the interests of all parties, a benefit function standardized to the [0,1] interval is constructed (all parameters in the function are explicitly defined when they first appear): Investor interest function: ;in It is the investor's preference coefficient for return weight, with a value range of [0.6, 0.8], used to adjust the weight of return ratio and verification security. It is the final dynamic weight of user i output by Algorithm 1; It is the confidence score of the k-th verification in Algorithm 3. In Mode A, it is the Merkle hash matching score, and in Mode B, it is the validity score of the zk-SNARKs proof.

[0097] Operator profit function: ;in This is the operator's cost preference coefficient, with a value range of [0.5, 0.7]. It is the reward function value at time t in Algorithm 2; It is the collaborative filtering correction factor for user i and asset j output by Algorithm 4, used to reflect the impact of the matching degree between users and assets on operational efficiency.

[0098] Regulatory interest function: ;in This is the regulatory agency's preference coefficient for verification security, with a value range of [0.7, 0.9]. It is the multi-party interest balance correction coefficient output by Algorithm 4, used to calibrate the degree of balance of interests among the three parties.

[0099] 3. Construct a cross-dimensional collaborative filtering matrix (1) Definition of feature dimensions: The user feature vector contains six dimensions, which fully reuse the input parameters of Algorithm 1: pledge quantity, historical pledge duration, recent active time, RWA asset risk assessment data, governance participation record, and holding continuity. The data of each dimension are standardized to the [0,1] interval to ensure the consistency of calculation.

[0100] The asset feature vector contains four dimensions, which integrate the asset-related parameters of Algorithms 1 and 3: asset risk level (i.e., the basic risk coefficient in Algorithm 1), asset return stability (represented by the reciprocal of the historical 30-day return volatility, the lower the volatility, the higher the stability), asset verification pass rate (the average of historical verification confidence in Algorithm 3), and number of cross-chain deployments of assets (multi-chain identifier in Algorithm 2, the more deployment chains, the higher the value), which are also standardized to the [0,1] range.

[0101] (2) Construction of collaborative filtering matrix Construct a user-asset interaction matrix, where each element in the matrix is... This indicates that the cross-dimensional matching degree between user i and asset j is calculated using the cosine similarity formula: ; in the formula It is the feature vector of user i. It is the feature vector of asset j. This represents the dot product operation of two vectors. It is the magnitude of the user feature vector. This is the magnitude of the asset feature vector. In the specific calculation, the first four dimensions of the user feature vector are respectively correlated with the four dimensions of the asset feature vector to calculate a dot product. The fifth and sixth dimensions of the user feature vector are both correlated with the fourth dimension of the asset feature vector, thus achieving a comprehensive cross-match between user features and asset features. The value ranges from [0, 1.5], with higher values ​​indicating a higher degree of matching between the user and the asset.

[0102] 4. Establish a game equilibrium constraint and correction coefficient model (1) Nash equilibrium condition: The core condition for the equilibrium of the interests of multiple parties is that no party can improve its own interests by changing its strategy alone. Mathematically, this is expressed as the partial derivatives of the interest functions of each party being 0. That is, the partial derivatives of the investor's interest function with respect to the dynamic weight of Algorithm 1, the partial derivatives of the operator's interest function with respect to the reward function value of Algorithm 2, and the partial derivatives of the regulatory agency's interest function with respect to the verification confidence of Algorithm 3 are all equal to 0. At this time, the interests of the three parties reach the optimal balance state.

[0103] (2) Double correction coefficient model Algorithm 4 outputs two core correction coefficients, which are linked to Algorithms 1-3 respectively to achieve bidirectional linkage: Collaborative Filtering Correction Factor User-asset matching degree The formula for correcting the individual weight bias in Algorithm 1 is as follows: ; in It is the average matching degree between user i and all assets, which is obtained by summing the matching degrees between user i and each asset and then dividing by the total number of assets; It is the maximum match between user i and all assets. It is the minimum value. The value range is [0.8, 1.4]. When the user's match with the target asset is higher than their average level, A value greater than 1 corresponds to an increase in the user's benefit rights weight; conversely, a value less than 1 corresponds to an appropriate decrease in weight, achieving cross-dimensional matching calibration.

[0104] Multi-party interest balance correction coefficient The equilibrium solution is obtained based on the three-party interest function, and the calculation formula is as follows: ; Where I, O, and R represent the interest function values ​​of investors, operators, and regulatory agencies, respectively. The solution is obtained using an iterative method. This ensures that the value of the function is stabilized in the range of [0.8, 1.2], and that the ratio of the product of the three parties' interest function values ​​to the mean is close to 1. At this point, the interests of the three parties are in equilibrium, neither favoring one party's demands nor hindering the achievement of the overall system goal.

[0105] II. Model Training Process 1. Training Data Preparation: The training data includes full RWA allocation data for the past 12 months: dynamic weights for each user output by Algorithm 1, reward function values ​​at each time step by Algorithm 2, and confidence levels for each verification by Algorithm 3; full user characteristic data, including the amount of each user's staked assets, historical staking duration, recent active time, RWA asset risk assessment data, governance participation records, and holding continuity; full asset characteristic data, including the risk level, return stability, verification pass rate, and number of cross-chain deployments for each asset; and feedback data on the interests of all three parties, including investor complaint records (more complaints indicate poorer fairness in returns), operator cost reports (higher cost percentage indicates lower operational efficiency), and regulatory compliance scores (lower scores indicate poorer compliance).

[0106] In the data preprocessing stage, all numerical data are standardized in the range [0,1] to eliminate the influence of units; Boolean data (such as holding continuity) are converted into numerical forms of 0 or 1; missing data are filled using the nearest neighbor interpolation method based on user-asset matching degree, that is, the mean of the corresponding features of the three users with the highest matching degree with the target user is selected as the missing feature value of the target user to ensure data integrity.

[0107] 2. Collaborative Filtering Matrix Training: The training objective is to minimize the prediction error of the user-asset matching degree. The prediction error is calculated as the sum of the squares of the actual matching degree and the model's predicted matching degree. Alternating least squares is used for training. The user-asset interaction matrix is ​​decomposed into a user feature latent vector matrix and an asset feature latent vector matrix, with the latent vector dimension set to 5. The prediction error is reduced by iteratively updating the two latent vector matrices.

[0108] The iterative update process is as follows: First, fix the asset feature latent vector matrix and solve for the optimal solution of the user feature latent vector matrix; then, fix the user feature latent vector matrix and solve for the optimal solution of the asset feature latent vector matrix; repeat the above process, introducing a regularization coefficient (with a value of 0.01) in each iteration to prevent model overfitting. The training termination condition is when the number of iterations reaches 50, or the prediction error is less than 0.001, at which point the model converges and can accurately predict the cross-dimensional matching degree between users and assets.

[0109] 3. Optimization of the Interest Balance Objective: The optimization objective is to minimize the variance of the interest function value among the three parties. The smaller the variance, the more balanced the interests of the three parties. A stochastic gradient descent algorithm is used for optimization, with a learning rate set to 0.005. By iteratively updating the preference coefficients of investors, operators, and regulatory agencies, the variance of the interests among the three parties is gradually reduced.

[0110] The iterative update process is as follows: calculate the variance of the three-party interests under the current preference coefficients, solve the partial derivative of the variance with respect to each preference coefficient, and adjust the preference coefficients according to the direction of the partial derivatives and the learning rate to iterate in the direction of decreasing variance. The training terminates when the variance of the three-party interests is less than 0.01, or when the number of iterations reaches 30, at which point the preference coefficients stabilize and the three-party interests reach an equilibrium state.

[0111] 4. Model Validation: The validation dataset consists of three months of reserved real-world allocation data, covering 2000 users, 1000 charging pile assets, and three deployment chains, consistent with the application instance scenario. Validation metrics include three core dimensions: benefit balance (requiring the variance of the interests of all three parties to be ≤0.01), correction accuracy (requiring the corrected allocation complaint rate to be ≤0.5%), and cross-chain collaboration efficiency (requiring that gas fees be further reduced by 15%-20% based on the optimization of Algorithm 2).

[0112] The verification results show that after model training, the variance of the three parties' interests stabilized at 0.008, the allocation complaint rate dropped to 0.3%, and the cross-chain gas fee decreased by an average of 18%. All indicators met the preset requirements, the model converged stably, and it has practical application feasibility.

[0113] III. Model Application Process The collaborative application process of Algorithm 4 and Algorithms 1-3 fully embodies pairwise bidirectional interaction, as detailed below: 1. Algorithm 1 Execution Phase: Algorithm 1 calculates initial dynamic weights based on user characteristics. ,Will The feature data of all assets are input into Algorithm 4 to provide the basis for Algorithm 4's calculations.

[0114] 2. Algorithm 4 First Interaction Calculation: Based on the input user and asset features, Algorithm 4 constructs a cross-dimensional collaborative filtering matrix and calculates the matching degree between each user and the corresponding asset using the cosine similarity formula. Then substitute the values ​​into the collaborative filtering correction factor formula to solve. .Will Feedback is sent back to Algorithm 1 to adjust the initial dynamic weights of Algorithm 1. Make adjustments to obtain the adjusted weight of the benefit rights. This enables bidirectional interaction between Algorithm 1 and Algorithm 4.

[0115] 3. Algorithm 2 execution phase: Algorithm 2 will process the output of Algorithm 4. As a criterion for determining transaction priority, the higher the match between the user and the asset, The higher the value, the higher the transaction priority. Algorithm 2 calculates the reward function value by combining parameters such as real-time gas prices and the total amount of revenue to be allocated. and will Input Algorithm 4 to provide data support for the benefit balance calculation of Algorithm 4.

[0116] 4. Second interactive calculation of Algorithm 4: Algorithm 4 receives Algorithm 2's... Then, combined with the modified version of Algorithm 1 The initial verification confidence level of Algorithm 3 (0.95 as the initial base confidence level) is substituted into the tripartite interest function to calculate the I, O, and R values, and then solved using the interest balance correction coefficient formula. This enables bidirectional interaction between Algorithm 2 and Algorithm 4.

[0117] 5. Algorithm 3 execution phase: Algorithm 3 will process the output of Algorithm 4. As an adjustment coefficient for the verification confidence threshold, when When the balance of interests among the three parties is relatively good, the verification threshold can be lowered by 10% to improve verification efficiency; when When =1, it indicates that the interests of the three parties have reached an optimal balance, keeping the basic threshold unchanged and balancing verification security and efficiency; when This indicates a risk of imbalance in the interests of the three parties, prompting an increase in the verification threshold by 10% to enhance security. Algorithm 3 performs hash verification to obtain the actual verification confidence level. and will Feedback is sent to Algorithm 4.

[0118] 6. Algorithm 4 closed-loop correction stage: Algorithm 4 receives the data from Algorithm 3. Then, the tripartite interest function value was recalculated and ,like If the optimal equilibrium interval [0.95, 1.05] is not met, then the behavioral incentive factor of Algorithm 1 is adjusted in reverse. Increase the weight of the loyalty factor when it is too low. When the value is too high, increase the weight of the governance participation factor and the weight of the reward function in Algorithm 2. Increase when it is too low Weight, Increase when it is too high (Weights), enabling bidirectional interaction between Algorithm 3 and Algorithm 4.

[0119] 7. Iterative Convergence Phase: Repeat steps 3 to 6 above, dynamically adjusting the algorithm parameters in each iteration until convergence. The value stabilizes within the range of [0.95, 1.05], at which point the interests of the three parties reach optimal equilibrium, and the final output is obtained. (Final benefit weight of Algorithm 1) (Final reward function value of Algorithm 2) (Algorithm 3 final verification confidence) completes the entire process collaboration.

[0120] IV. Pairwise interactions between algorithms 1. Algorithm 4 and Algorithm 1: Bidirectional interaction in weight adjustment Forward data transmission: Algorithm 1 sets the initial dynamic weights of user i. The parameter is passed to Algorithm 4 and serves as the core parameter for calculating the investor interest function. It is the user benefit weight obtained by Algorithm 1 through basic weight calculation, risk adjustment, and weighting by behavioral incentive factors.

[0121] Reverse correction propagation: Algorithm 4 uses collaborative filtering correction factors Correcting Algorithm 1 The corrected formula is: ;in It is the final profit right weight of user i and asset j after Algorithm 4 correction. It is a collaborative filtering correction factor. It is a correction coefficient for balancing the interests of all parties. Meanwhile, Algorithm 4 is based on... The numerical dynamic adjustment algorithm 1's behavioral incentive factor, when At that time, the weight of the loyalty factor was adjusted from 0.7 to 0.75, and the weight of the governance participation factor was adjusted from 0.3 to 0.25; when At that time, the weight of the loyalty factor was adjusted from 0.7 to 0.65, and the weight of the governance participation factor was adjusted from 0.3 to 0.35, so as to achieve dynamic optimization of the parameters of Algorithm 1.

[0122] 2. Algorithm 4 and Algorithm 2: Bidirectional interaction for Gas Fee Optimization Forward data transfer: Algorithm 2 will pass the reward function value at time t. Passed to Algorithm 4, The calculation follows the original logic of Algorithm 2, that is... =-(Gas fee / Total transfer amount) X -Average waiting time X ,in and These are the original weight parameters of Algorithm 2.

[0123] Reverse correction propagation: Algorithm 4 passes Adjusting Algorithm 2 and The formula is adjusted as follows: ; ;in and These are the weight parameters of Algorithm 2 after Algorithm 4 is modified. At the same time, Algorithm 4 will... As the transaction priority parameter for Algorithm 2, the transaction priority calculation formula is as follows: Algorithm 2 processes transfer requests with higher transaction priority, thus linking gas fee optimization with revenue right weight.

[0124] 3. Algorithm 4 and Algorithm 3: Two-way interaction of verification confidence Forward data transmission: Algorithm 3 will use the confidence level of the kth verification. Passed to Algorithm 4, under Mode A The Merkle hash matching degree (i.e., the probability of matching the on-chain settlement document hash with the off-chain original document hash) is given under Mode B. Prove the validity of zk-SNARKs (i.e., the probability that the proof document passes verification).

[0125] Reverse correction propagation: Algorithm 4 passes Adjust the verification threshold of Algorithm 3 using the following formula: ;in This is the verification threshold of Algorithm 3 after Algorithm 4 is modified; the base threshold is set to 0.95 by default. Simultaneously, Algorithm 4 adjusts the threshold based on the collaborative filtering correction factor. Dynamically select the verification mode of Algorithm 3: when When the user and asset match is high, choose Mode A (public verification) to improve verification efficiency; when At that time, the user-asset matching degree was low, which posed a potential risk. Mode B (privacy verification) was selected to enhance data security and achieve linkage between verification mode and cross-dimensional matching degree.

[0126] 4. Three-way feedback mechanism (closed-loop linkage of Algorithms 1-4) The core of cyclic feedback is through The iterative updates achieve dynamic optimization of all algorithms, and the iterative formula is: ; ; ; ; Where t is the number of iterations. This is the benefit balance correction coefficient for the t-th iteration. , , Let be the value of the tripartite interest function in the t-th iteration. The corrected weight of the benefit right in the (t+1)th iteration. Let be the reward function value for the (t+1)th iteration. This represents the verification confidence level for the (t+1)th iteration. The iteration termination condition is the confidence level between two consecutive iterations. When the difference is less than 0.001, the closed-loop linkage reaches a stable state.

[0127] V. Specific Application Examples Case Basic Parameters User 1001 and asset 501 (the 501st charging pile) are selected as the specific application objects: the initial dynamic weight of user 1001 output by Algorithm 1. Algorithm 2 Initial Weight Parameters , Algorithm 3's basic verification threshold = 0.95; Algorithm 4's preference coefficient , , .

[0128] User 1001's characteristic data: staking quantity 1000 tokens (0.1 after standardization), historical staking duration 2 years (0.5 after standardization), most recent active time 3 days ago (0.9 after standardization), RWA asset risk assessment is medium risk (corresponding to basic risk coefficient 1.2, 0.5 after standardization), governance participation rate 75% (0.75 after standardization), holding continuity is yes (converted to 1.0).

[0129] The characteristics of Asset 501 are as follows: risk level 1.2 (0.5 after standardization), return stability 0.9 (inverse of historical 30-day return volatility, 0.9 after standardization), verification pass rate 0.98 (mean of historical verification confidence of Algorithm 3, 0.98 after standardization), and number of cross-chain deployments 2 chains (0.67 after standardization).

[0130] Detailed calculation process: 1. Collaborative filtering matching degree calculation: The dot product of the user feature vector and the asset feature vector is (0.1×0.5)+(0.5×0.9)+(0.9×0.98)+(0.5×0.67)+(0.75×0.67)+(1.0×0.67)=0.05+0.45+0.882+0.335+0.5025+0.67=2.8895; the magnitude of the user feature vector is √( + + + + + ) = √(0.01 + 0.25 + 0.81 + 0.25 + 0.5625 + 1.0) = √2.8825 ≈ 1.70; the magnitude of the asset feature vector is √(0.5 2 +0.9 2 +0.98 2 +0.67 2 ) = √(0.25 + 0.81 + 0.9604 + 0.4489) = √2.4693 ≈ 1.57; therefore, the collaborative filtering matching degree between user 1001 and asset 501 is... .

[0131] 2. Collaborative Filtering Correction Factor Calculation: Average Match Rate Between User 1001 and All Assets Maximum matching degree minimum value ;therefore .

[0132] 3. Calculation of Initial Interest Equilibrium Correction Coefficient: Initial Corrected weight of income rights The initial reward function value of Algorithm 2 Standardized operator benefit function value (Outside the [0,1] interval, standardized to 1.0); Algorithm 3 initial verification confidence level Investor interest function value The value of the regulatory agency's interest function ;therefore It is not in the range [0.8, 1.2] and needs to be iteratively corrected.

[0133] 4. First Iteration Correction: Adjust the behavioral incentive factors of Algorithm 1, increasing the weight of the loyalty factor from 0.7 to 0.75 and decreasing the weight of the governance participation factor from 0.3 to 0.25; recalculate the dynamic weights of Algorithm 1. Adjust the weight parameters of Algorithm 2 , Recalculate the reward function value of Algorithm 2. After standardization (Standardized version 1.0); Algorithm 3 adjusts the verification threshold (If the value is outside the [0,1] range, take 1.0), then re-verify. Recalculate the tripartite interest function value , ; .

[0134] 5. Convergence after multiple iterations: Repeat the above correction process. After 12 iterations, The weight stabilizes at 0.98, at which point the corrected weights from Algorithm 1 are... The corrected weights of Algorithm 2 , reward function value After standardization (Standardized version 1.0); Corrected threshold of Algorithm 3 Verification confidence level Investor interest function value The value of the regulatory agency's interest function The variance of the interests of the three parties is 0.007, which meets the equilibrium requirement, and the iteration terminates.

[0135] Application Results: After the correction, the weight of user 1001's right to income was adjusted from 0.0001 to 0.000123, which not only reflects the high matching degree between the user and asset 501, but also avoids the loss of other parties' interests due to excessive weight through the balance of interests among multiple parties; the gas fee of Algorithm 2 was further reduced by 18% on the basis of the original optimization, and the operator's operating costs were significantly reduced; the verification threshold of Algorithm 3 was adjusted to 0.969, which improved the verification efficiency while ensuring compliance; the investor complaint rate dropped from the original 1.2% to 0.3%, and the interests of the three parties were optimally balanced.

[0136] VI. Core Contributions The innovativeness of interdisciplinary technology integration: It combines collaborative filtering technology in the field of recommendation systems with Nash equilibrium theory in game theory in the field of economics and applies it to the revenue distribution scenario of blockchain RWA, breaking through the traditional thinking of "single-technology dimension optimization" in the RWA field.

[0137] The uniqueness of bidirectional closed-loop linkage: Algorithm 4, together with Algorithms 1-3, forms "Algorithm 1 Algorithm 4 Algorithm 2 Algorithm 4 Algorithm 3 Algorithm 4 The fully closed-loop two-way interaction of "Algorithm 1" means that the core parameters of each algorithm are corrected by other algorithms in reverse. This linkage mode is extremely rare in RWA revenue distribution technology.

[0138] Deep parameter binding: Dynamic binding of all parameters is achieved by adjusting the coefficients, which reduces system complexity and ensures the integrity of the technical solution.

[0139] Addressing the pain points of conflicting interests among multiple parties: By using game theory Nash equilibrium constraints, the system achieves a unified goal of fair returns for investors, optimal costs for operators, and compliance and security for regulatory agencies. This effectively reduces the risk of disputes caused by imbalances in interests and fills the gap in existing technologies where "single-objective optimization ignores the interests of multiple parties."

[0140] Correcting cross-dimensional matching bias: By using collaborative filtering technology to achieve cross-calibration of user features and asset features, the "user-asset mismatch" allocation bias caused by Algorithm 1 calculating weights based solely on individual user features is resolved, thereby improving the accuracy and fairness of profit distribution.

[0141] Improve overall system performance: After Algorithm 4 is integrated with Algorithms 1-3, the system's Gas fee is further reduced by 15%-20% on the basis of the original optimization, the allocation complaint rate is reduced to below 0.5%, the verification pass rate is increased to over 99.5%, and the anti-interference capability is significantly enhanced. No single entity can profit by tampering with its own parameters because all parameters are subject to reverse constraints from other algorithms, ensuring system stability.

Claims

1. An automated settlement and reconciliation method for RWA asset income distribution, characterized in that, include: (1) Real-time collection of raw RWA asset return data from off-chain data sources; (2) Send the original RWA asset revenue data to a verification committee composed of multiple independent nodes. The committee members use threshold signature technology to cross-verify the authenticity and consistency of the original RWA asset revenue data. Generate a joint signature for the verified original RWA asset revenue data to form a trusted data packet carrying multiple signatures. (3) Upload the trusted data packet carrying multi-signatures to the blockchain network and call the revenue distribution main contract pre-deployed on the blockchain network; (4) The main contract for revenue distribution queries the pre-deployed asset distribution relationship map. The asset distribution relationship map is a dataset associated with the main contract for revenue distribution and records the proportion of revenue rights corresponding to each RWA token address in the form of key-value pairs. The main contract for revenue distribution calculates the current total revenue based on the original RWA asset revenue data, and calculates the amount of revenue due for each RWA token address by combining the proportion of revenue rights in the asset distribution relationship map, and automatically initiates batch transfers. (5) Each batch transfer corresponds to an allocation transaction that generates a globally unique settlement certificate hash on the chain. The settlement certificate hash is anchored to the off-chain original certificate hash corresponding to the original RWA asset revenue data to form a verifiable allocation evidence pair. (6) If RWA assets are deployed on multiple blockchain networks, the revenue of each blockchain network will be managed in a unified manner through a pre-set cross-chain settlement engine; (7) Investors query the batch transfer details and allocation evidence pairs, input any hash in the allocation evidence pair, and trace back the data flow and fund flow from step (1) to step (4) to complete the reconciliation verification.

2. The automated settlement and reconciliation method for RWA asset income distribution according to claim 1, characterized in that, The threshold signature technology described in step (2) adopts the (t,n) mode, that is, at least t nodes among the n independent nodes of the verification committee complete the signature confirmation, and the original data of RWA asset income can be verified and generate a joint signature, where n and t are preset positive integers and t < n.

3. The automated settlement and reconciliation method for RWA asset income distribution according to claim 1, characterized in that, The asset distribution relationship map described in step (4) adopts an event-driven update mechanism. When an RWA token transfer, issuance or destruction event occurs, the main contract for revenue distribution triggers the map to be updated in real time, ensuring that the revenue rights ratio corresponding to each RWA token address is always accurate.

4. The automated settlement and reconciliation method for RWA asset income distribution according to claim 1, characterized in that, The cross-chain settlement engine described in step (6) achieves multi-chain collaborative management through the cross-chain message protocol, specifically including two methods: First, the RWA asset income from multiple blockchain networks is uniformly collected into a preset main chain, and the income distribution main contract centrally calculates and distributes the income; Second, the distribution instructions are distributed to the sub-contracts of each blockchain network according to the asset distribution relationship map, so as to achieve one-time calculation and multi-chain synchronous distribution.

5. The automated settlement and reconciliation method for RWA asset income distribution according to claim 1, characterized in that, Step (1) Perform the collection operation of RWA asset revenue raw data through a trusted data oracle. The collection methods include receiving webhook notifications from the payment gateway, obtaining timed reports from the enterprise ERP system, and receiving encrypted data streams from IoT sensors. The off-chain data sources include the payment gateway, the enterprise ERP system, and IoT sensors.

6. The automated settlement and reconciliation method for RWA asset income distribution according to claim 1, characterized in that, The independent nodes of the verification committee mentioned in step (2) are operated by at least two types of entities, namely operators, regulatory agencies, and third-party notaries, to ensure the independence of each node and the impartiality of the verification results.

7. The automated settlement and reconciliation method for RWA asset income distribution according to claim 1, characterized in that, The profit rights ratio mentioned in step (4) is calculated by a dynamic profit rights allocation algorithm. This algorithm comprehensively considers the amount of staking, historical staking duration, recent active time, RWA asset risk assessment data, governance participation records and holding continuity of each RWA token address. After basic weight calculation, risk adjustment and behavioral incentive factor weighting, the final profit rights ratio is obtained.

8. The automated settlement and reconciliation method for RWA asset income distribution according to claim 1, characterized in that, In step (6), the cross-chain settlement engine adopts a dynamic gas fee optimization decision model based on reinforcement learning. This model obtains the current gas price, the total amount of revenue to be distributed, the number of transactions to be merged, the historical average waiting time, and network congestion indicators in real time, and dynamically selects the transaction strategy of immediate execution or continued waiting, so as to control gas costs while ensuring the timely arrival of revenue.

9. The automated settlement and reconciliation method for RWA asset income distribution according to claim 1, characterized in that, The reconciliation verification in step (7) adopts a dual-mode architecture: Mode 1 is public verification, which generates an on-chain queried allocation certificate hash through a Merkle tree for investors to verify publicly; Mode 2 is privacy verification, which generates zero-knowledge proofs through zk-SNARKs proof circuits, allowing investors to verify the integrity and correctness of the profit distribution without needing to obtain specific allocation details.

10. An automated settlement and reconciliation system for RWA asset income distribution, characterized in that, An automated settlement and reconciliation method for RWA asset revenue distribution according to any one of claims 1 to 9 is provided. The automated settlement and reconciliation system for RWA asset revenue distribution comprises: a data acquisition and verification module, a smart contract module, an asset graph management module, a cross-chain settlement engine module, and a user interaction module. The data acquisition and verification module includes a trusted data oracle and a verification committee node, used to collect, cross-validate, and jointly sign the original RWA asset revenue data. The smart contract module is deployed on a blockchain network and includes a revenue distribution main contract and sub-contracts, used to calculate the total revenue, calculate the amount of revenue due, initiate batch transfers, and generate settlement voucher hashes. The asset graph management module is used to maintain an asset distribution graph, supporting event-driven updates and revenue right ratio queries. The cross-chain settlement engine is used to achieve collaborative revenue management and gas fee optimization across multiple blockchain networks. The user interaction module is a DApp interface used to display batch transfer details and allocation evidence pairs to investors, supporting hash queries and data flow and fund flow traceability verification.

Images