Automatic payment method based on smart contract

Abstract

The invention discloses an automatic payment method based on a smart contract, and relates to the technical field of electronic transactions. The method comprises the steps of firstly obtaining and analyzing a payment protocol, performing separation processing on a payment amount, a payment condition and an external data source identifier, transmitting the payment amount to a payment smart contract for locking, digitizing the payment condition into an executable code, deploying the executable code to an arbitration management smart contract, and sending the data source identifier to a decentralized oracle network, then, the oracle machine network monitors the under-chain state data, judges whether the payment condition is met or not through a consensus mechanism, submits a verification certificate to the arbitration governance intelligent contract, sends an execution instruction to the payment intelligent contract after the verification certificate of the arbitration governance intelligent contract is valid, and finally automatically completes fund transfer through the payment intelligent contract. Therefore, through combination of the intelligent contract and the oracle machine technology, trustworthy payment with intermediary removal, condition triggering and real-time automation is realized, and the settlement efficiency, transparency and flexibility are remarkably improved.

Description

Technical Field

[0001] This invention belongs to the field of electronic transaction technology, and specifically relates to an automated payment method based on smart contracts. Background Technology

[0002] Current mainstream payment systems, especially those involving cross-border or complex transactions, heavily rely on a series of centralized intermediaries. In international trade, payment instructions typically need to be transmitted, reconciled, and cleared among multiple correspondent banks via the SWIFT (Society for Worldwide Interbank Financial Telecommunications) network. Domestic or platform transactions rely on banks and third-party payment platforms (such as PayPal or credit card organizations) as trusted guarantors and settlement centers. The essence of this architecture is entrusting trust to centralized institutions responsible for verifying the identities of both parties, confirming the authenticity of the transaction, and ultimately completing the transfer of funds. In the blockchain field, although the concept of decentralized payments has emerged, many early smart contract platforms are limited by scalability and still face problems such as high transaction fees and slow confirmation speeds, making it difficult to support high-frequency and real-time payment demands. In essence, they have not completely broken free from their dependence on centralized sorting mechanisms or high-fee environments.

[0003] The aforementioned intermediary-centric payment model reveals the following technological shortcomings when dealing with the modern economy, especially the automated agency economy and trade under complex conditions: (1) The settlement efficiency is low and the cycle is long. Due to the reliance on manual or batch processing operations of multiple intermediaries, the settlement cycle of traditional cross-border payments is usually as long as 3 to 5 working days (i.e., T+3 to T+5 days). Even within the same country, corporate payments involving complex audits take a long time. This delay leads to serious capital occupation and low capital utilization efficiency, which cannot meet the commercial needs of real-time or near real-time settlement, especially in high-speed digital transaction scenarios. (2) High transaction costs, namely, the service fees charged by intermediaries significantly increase transaction costs; in cross-border payments, the average handling fee can reach 1% to 3% of the transaction amount. For small and high-frequency payment scenarios (such as micro-payments between AI intelligent agents and IoT device transactions), such fixed or proportional fees are completely unfeasible from an economic perspective, killing off a large number of potential business models. (3) The business process is not transparent and it is difficult to verify the credibility. That is, the payment status and the flow of funds are a "black box" for both parties to the transaction. The payer has difficulty confirming the progress of the payment in real time and with credibility, and the payee cannot predict the arrival time. When it comes to conditional payment (such as cash on delivery or payment after acceptance), the determination of whether the "conditions are met" depends on mutual trust between the two parties or manual verification by a third party. The process is cumbersome and prone to disputes, and there is a lack of objective and automated verification mechanism. (4) Insufficient flexibility and programmability, that is, the rules of traditional payment systems are rigid and difficult to support complex and custom payment logic; for example, it is not possible to automatically trigger payment based on multiple external conditions (such as logistics receipt information and API data feedback), or to automatically split a sum of money into multiple payees; this lack of programmability makes it unable to adapt to the needs of advanced business models such as supply chain finance, automated accounting and smart entity economy.

[0004] Therefore, the industry urgently needs an innovative payment method that can establish a reliable trust and execution mechanism without relying on traditional intermediaries. Specifically, this method needs to address the following key technical challenges: (A) How to ensure the credible verification and automatic execution of payment terms through technical means (rather than institutional guarantees); (B) How to design a fair and efficient dispute resolution mechanism to address potential anomalies during automated execution; and (C) How to efficiently and accurately translate non-standardized commercial terms (payment conditions) into executable computer code. This invention is proposed against this backdrop, aiming to fundamentally overcome the shortcomings of existing technologies by integrating smart contracts and decentralized oracles to build a complete, autonomous, and reliable automated payment solution. Summary of the Invention

[0005] The purpose of this invention is to provide an automated payment method based on smart contracts to solve the problems of low settlement efficiency, long cycle, high transaction cost, opaque business process and / or insufficient flexibility and programmability in existing payment schemes.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: This invention provides an automated payment method based on smart contracts, comprising: Obtain the payment agreement reached between the payer and the payee; The payment agreement extracts the payment amount, payment conditions, and at least one external data source identifier for verifying the payment conditions. The payment amount is then transmitted to the payment smart contract, and the payment conditions are digitized into executable code and deployed to the arbitration governance smart contract. The external data source identifier is also transmitted to a decentralized oracle network. The payment smart contract is used to lock the payer's funds based on the payment amount and automatically execute the payment upon fulfillment of triggering conditions. The arbitration governance smart contract is used to manage the verification logic of the payment conditions based on the executable code, and it is also used to execute the dispute resolution process. The oracle network continuously monitors off-chain state data associated with the external data source identifier; The oracle network determines whether the payment conditions are met based on a predefined consensus mechanism and the off-chain state data. If the conditions are met, a verification certificate indicating that the conditions are met is submitted to the arbitration governance smart contract. After verifying the validity of the verification proof, the arbitration governance smart contract generates an execution instruction and sends it to the payment smart contract; In response to the execution instruction, the payment smart contract automatically transfers the locked funds to the address specified by the payee to complete the payment.

[0007] Based on the above-mentioned invention, an automated payment solution based on smart contract integration and decentralized oracles is provided. This solution first acquires and parses the payment protocol, separating the payment amount, payment conditions, and external data source identifier. The payment amount is then transferred to the payment smart contract for locking, the payment conditions are digitized into executable code and deployed to the arbitration governance smart contract, and the data source identifier is sent to a decentralized oracle network. The oracle network then monitors off-chain state data and determines whether the payment conditions are met through a consensus mechanism. It then submits a verification certificate to the arbitration governance smart contract, which verifies the certificate's validity and issues an execution command to the payment smart contract. Finally, the payment smart contract automatically completes the fund transfer. This combination of smart contracts and oracle technology achieves disintermediation, condition-triggered, real-time automated, and reliable payments, significantly improving settlement efficiency, transparency, and flexibility, and facilitating practical application and promotion.

[0008] In one possible design, the dispute resolution process employs the following progressive dispute resolution mechanism: Upon receiving the verification proof, the arbitration governance smart contract initiates a preset challenge waiting period. During the challenge waiting period, if the payer or the payee raises an objection to the condition being met and pays a challenge deposit to the arbitration governance smart contract, the on-chain arbitration process is triggered. In the on-chain arbitration process, the arbitration governance smart contract submits the objections and related evidence to a decentralized arbitration tribunal composed of token holders for on-chain voting and adjudication. Based on the feedback of the adjudication, the payment smart contract's function is directly invoked to execute the final allocation of funds.

[0009] In one possible design, the members of the decentralized arbitration tribunal consist of token holders who voluntarily stake system tokens to the arbitration governance smart contract; The arbitration actions of the members are linked to the economic incentives of their pledged assets: if the member's vote is consistent with the final ruling of the arbitration tribunal, the member will receive a reward; if the member's vote is inconsistent with the final ruling of the arbitration tribunal or the member fails to participate in the voting according to the preset rules, a portion of the system tokens pledged by the member will be forfeited.

[0010] In one possible design, the oracle network includes multiple independent oracle nodes; Determining whether the payment conditions are met based on a predefined consensus mechanism and the off-chain state data includes: The off-chain state data is monitored, acquired, and submitted by each of the plurality of oracle nodes. When the off-chain state data submitted by the oracle nodes exceeding a preset threshold are consistent, the oracle network uses threshold signature technology to generate a verification proof based on the consistent off-chain state data to determine that the payment conditions are met.

[0011] In one possible design, the payment terms are digitized into executable code and deployed to an arbitration governance smart contract, including: The payment conditions are parsed using a natural language processing model to understand their semantic logic and extract key verification elements containing event types and logical constraint parameters; these key verification elements are then transformed into query vectors. The semantic similarity is calculated between the query vector and the descriptive metadata vector of each standardized condition verification module in the pre-set standardized condition verification module library. Based on the semantic similarity calculation result, at least one standardized condition verification module that is most similar is selected from the standardized condition verification module library. Different standardized condition verification modules encapsulate executable code for implementing different off-chain condition verification logic and all follow the preset smart contract interface specification. The smart contract interface address of the at least one standardized condition verification module is registered to the arbitration governance smart contract, wherein the arbitration governance smart contract is configured to call the standardized condition verification module corresponding to the registered smart contract interface address when the payment conditions need to be verified, so as to manage the verification logic of the payment conditions.

[0012] In one possible design, the payment terms are digitized into executable code and deployed to an arbitration governance smart contract, including: Based on the payment conditions, a large language model is invoked to generate condition verification logic source code that conforms to a preset interface specification; the condition verification logic source code is then subjected to interface compliance verification and security vulnerability scanning; after passing the interface compliance verification and security vulnerability scanning, the condition verification logic source code is deployed to the blockchain network to form a standardized condition verification module, and the smart contract interface address of the standardized condition verification module is obtained; the smart contract interface address is registered to the arbitration governance smart contract, wherein the arbitration governance smart contract is configured to invoke the standardized condition verification module corresponding to the registered smart contract interface address when the payment conditions need to be verified, so as to manage the verification logic of the payment conditions.

[0013] In one possible design, the payment smart contract has a pre-configured payment routing logic, wherein the payment routing logic is used to define multiple receiving addresses and the fund allocation share of each of the multiple receiving addresses, the multiple receiving addresses including the address specified by the receiving party; Automatically transferring locked funds to the address designated by the recipient to complete the payment includes: Based on the payment routing logic and the funds locked in a single transaction, the amount due for each receiving address is calculated. Based on the amount due at each of the receiving addresses, the locked funds are split and routed to the multiple receiving addresses to complete the payment.

[0014] In one possible design, the payment smart contract and the arbitration governance smart contract are deployed on a first blockchain network, while the payment conditions are verified by an auxiliary contract or oracle deployed on a second blockchain network. When the payment conditions are met, a trigger signal is sent to the arbitration governance smart contract of the first blockchain network via a cross-chain messaging protocol to trigger the execution of the payment smart contract.

[0015] In one possible design, the method further includes: When verifying the payment conditions requires sensitive data, the condition prover generates a zero-knowledge proof and submits the zero-knowledge proof as the off-chain state data to the oracle network. The oracle network verifies the validity of the zero-knowledge proof, and determines that the payment conditions are met after the verification is successful.

[0016] In one possible design, before responding to the execution instruction, the payment smart contract is also used to: check whether the payee has made a final confirmation of the payment to be executed via digital signature within a preset time; if so, the payment is executed immediately; otherwise, the payee waits for the execution instruction to arrive.

[0017] The beneficial effects of the above scheme are: (1) This invention provides an automated payment solution based on the integration of smart contracts and decentralized oracles. First, the payment protocol is acquired and parsed, and the payment amount, payment conditions and external data source identifier are separated and processed. The payment amount is then sent to the payment smart contract for locking, the payment conditions are digitized into executable code and deployed to the arbitration governance smart contract, and the data source identifier is sent to the decentralized oracle network. Then, the oracle network monitors the off-chain state data and determines whether the payment conditions are met through a consensus mechanism. Then, it submits a verification certificate to the arbitration governance smart contract. After the arbitration governance smart contract verifies the validity of the certificate, it issues an execution instruction to the payment smart contract. Finally, the payment smart contract automatically completes the fund transfer. Thus, through the combination of smart contract and oracle technology, a trustworthy payment solution with no intermediaries, condition triggering and real-time automation is achieved, which significantly improves settlement efficiency, transparency and flexibility. (2) It can realize the complete automation and efficiency revolution of the payment process. That is, through the automatic execution of smart contracts and the real-time verification of oracles, the manual processing and settlement cycle of several days in traditional payment can be shortened to the deterministic settlement that is completed instantly upon condition triggering, which greatly improves capital efficiency. At the same time, it also realizes the automatic conversion and deployment from natural language contracts to executable code, covering the complete closed loop from condition definition, verification to execution, eliminating the bottleneck of manual coding and intervention. (3) Decentralized trust can be built, significantly reducing costs and risks. On the one hand, payment contracts are used as automatic custodians, and arbitration governance contracts and decentralized arbitration tribunals replace traditional judicial / arbitration institutions, building a trust and enforcement system that does not rely on any single center. On the other hand, automation greatly reduces manual operation and intermediary service fees, and modularization and AI generation reduce development and adaptation costs. Furthermore, cross-chain design allows the computing load to be distributed to low-cost chains, further optimizing the fee structure. (4) It can ensure the deep transparency of business logic and the credibility of the process. That is, all payment terms, verification logic, fund status and arbitration records are publicly available and tamper-proof on the chain, providing a level of transparency that traditional "black box" payments cannot match. The oracle network based on multi-node consensus and threshold signature and the arbitration mechanism based on staking incentives jointly ensure the fraud resistance and objectivity and fairness of the process of putting off-chain data on the chain and resolving disputes. (5) It can provide unprecedented flexibility and scalability. Through two paths, namely pluggable standardized module library and AI dynamic code generation, the system can adapt to any complex and non-standard real-world payment conditions at extremely low cost. At the same time, it supports advanced functions such as automatic account routing and cross-chain verification execution, and can handle privacy-sensitive scenarios through zero-knowledge proofs to meet diverse business needs from simple to extremely complex. (6) It can enhance the robustness of the system and the user experience. That is, through the progressive dispute resolution mechanism, it can provide a formal channel for human supervision and error correction for the automated process, and the final confirmation option adds security redundancy. Security vulnerability scanning ensures basic security at the code level. In addition, while pursuing full automation, the system properly handles the edge cases of automation through dispute arbitration and final confirmation, making the technical solution more inclusive and practical for the real business environment. (7) Through systematic architectural innovation, this solution has achieved a leapfrog comprehensive improvement in multiple dimensions such as efficiency, cost, trust, flexibility and security. It can provide a complete and feasible technical blueprint for building the next generation of trusted automated payment infrastructure, which is convenient for practical application and promotion. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention 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 the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating an automated payment method based on smart contracts provided in an embodiment of the present invention. Detailed Implementation

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the present invention will be briefly introduced below in conjunction with the accompanying drawings and descriptions of the embodiments or the prior art. Obviously, the following description of the structure of the accompanying drawings is only some embodiments of the present invention. For those skilled in the art, other embodiments can be obtained based on these embodiments without creative effort. It should be noted that the description of these embodiments is for the purpose of helping to understand the present invention, but does not constitute a limitation of the present invention.

[0021] It should be understood that although the terms "first" and "second", etc., may be used herein to describe various objects, these objects should not be limited by these terms. These terms are only used to distinguish one object from another. For example, the first object may be referred to as the second object, and similarly, the second object may be referred to as the first object, without departing from the scope of the exemplary embodiments of the invention.

[0022] It should be understood that the term "and / or" that may appear in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, B exists alone, or A and B exist simultaneously. Another example is A, B and / or C, which can mean that any one of A, B, and C or any combination thereof exists. The term " / and" that may appear in this document describes another relationship between related objects, indicating that two relationships can exist. For example, A / and B can mean: A exists alone or A and B exist simultaneously. In addition, the character " / " that may appear in this document generally indicates that the related objects before and after it are in an "or" relationship.

[0023] Example like Figure 1 As shown, the automated payment method based on smart contracts provided in this embodiment includes, but is not limited to, the following steps S1 to S6.

[0024] S1. Obtain the payment agreement reached between the payer and the payee.

[0025] In step S1, the payer and the payee are the two parties to the transaction. Specifically, they can be Party A and Party B in international trade, or buyer and seller in domestic or platform transactions, and so on. The payment agreement is the core digital contract that initiates the entire on-chain process. It is not a simple paper document, but a structured and machine-readable data object. Its content and acquisition method together constitute the technical bridge connecting the real business world and the on-chain smart contract. Specifically, the payment protocol is exemplified by a structured data object (typically defined in JSON or a specific schema) containing, but not limited to, the following key fields: a unique protocol identifier (i.e., the on-chain contract address or global ID, used for indexing), the addresses of the payer and payee (i.e., the blockchain public key addresses, representing the transaction entities), the payment amount and asset type (i.e., the quantity and type of assets locked in the payment contract, such as USDT), payment conditions (i.e., a core field, specifically describing the event triggering the payment in natural or structured language, such as "when the logistics company DHL's official website shows that waybill number 123456789 is 'signed'"), an external data source identifier (i.e., a core field, specifying one or more off-chain state data application programming interface (API) fields required to verify the conditions), dispute resolution parameters (i.e., the duration of the challenge waiting period and the number of arbitrators, inherited from the arbitration governance contract), and a digital signature (i.e., the payer and payee signing the protocol hash value using their private keys to ensure non-repudiation). Furthermore, the payment protocol can be routinely generated and uploaded through a standardized human-machine collaborative process involving multiple parties.

[0026] S2. Extract the payment amount, payment conditions, and at least one external data source identifier for verifying the payment conditions from the payment protocol, and transmit the payment amount to the payment smart contract, and digitize the payment conditions into executable code and deploy it to the arbitration governance smart contract, and also transmit the external data source identifier to a decentralized oracle network, wherein the payment smart contract is used to lock the payer's funds according to the payment amount and automatically execute the payment after the triggering conditions are met, the arbitration governance smart contract is used to manage the verification logic of the payment conditions according to the executable code, and the arbitration governance smart contract is also used to execute the dispute adjudication process.

[0027] In step S2, since the payment protocol is a structured data object containing many key fields, the payment amount, payment conditions, and external data source identifier can be routinely parsed and extracted. A smart contract is not a traditional legal contract, but rather a piece of computer program code deployed on a blockchain that can be automatically executed. Its core lies in transforming contract terms into precise "if-then" logical rules; once the preset conditions are triggered and verified to be true, the contract will automatically execute the corresponding operation (such as transferring assets or registering ownership) without the intervention of any intermediary; all nodes in the blockchain network jointly verify and execute the contract, ensuring the determinism, immutability, and decentralized trust of the process. Therefore, the payment smart contract and the arbitration governance smart contract can be routinely created and deployed based on existing smart contract concepts. The specific digitization process of the payment conditions and the executable code can be implemented based on a pre-built standardized condition verification module. Specifically, the payment conditions are digitized into executable code and deployed to the arbitration governance smart contract, including but not limited to the following steps S211 to S214.

[0028] S211. Apply a natural language processing model to parse the payment conditions in order to understand the semantic logic of the payment conditions and extract key verification elements, including but not limited to event types and logical constraint parameters.

[0029] In step S211, the Natural Language Processing (NLP) model is a type of artificial intelligence model whose core goal is to enable computers to understand, interpret, and manipulate human natural language. In this embodiment, the model is not a general chat tool, but a specialized technical module that has been specifically trained for deep parsing of payment condition text. Therefore, it can routinely extract key verification elements such as the event type and the logical constraint parameters based on the semantic logic understanding results.

[0030] S212. Convert the key verification elements into query vectors.

[0031] In step S212, the key verification element is structured text information, which needs to be converted into a form that computers can efficiently compare mathematically—that is, a vector (or embedding vector). Specifically, this can be achieved by relying on a pre-trained text embedding model (such as Sentence-BERT or Universal Sentence Encoder).

[0032] S213. Perform semantic similarity calculation on the query vector and the descriptive metadata vector of each standardized condition verification module in the pre-set standardized condition verification module library, and select at least one standardized condition verification module that is most similar from the standardized condition verification module library based on the semantic similarity calculation result. The different standardized condition verification modules encapsulate executable code for implementing different off-chain condition verification logic and all follow the preset smart contract interface specification.

[0033] In step S213, the standardized condition verification module is obtained based on the standardized programming of preset payment conditions and has a corresponding descriptive metadata vector pre-converted. This vector is a digital summary of its functional semantics, such as "verify DHL logistics receipt" or "verify CSI 300 index price". Therefore, the cosine similarity and other metrics between the query vector and all metadata vectors in the database can be calculated to obtain the semantic similarity calculation result. Furthermore, the specific method for selecting at least one of the most similar standardized condition verification modules can be accomplished according to a preset strategy (such as setting a similarity threshold or selecting the highest score), which will not be elaborated here.

[0034] S214. Register the smart contract interface address of the at least one standardized condition verification module to the arbitration governance smart contract, wherein the arbitration governance smart contract is configured to call the standardized condition verification module corresponding to the registered smart contract interface address when the payment conditions need to be verified, so as to manage the verification logic of the payment conditions.

[0035] In step S2, considering that each standardized condition verification module in the standardized condition verification module library is a static module, it may not be 100% compatible with the support conditions that have dynamic changes. Therefore, in order to achieve the purpose of accurate digitization, it is preferable to digitize the payment conditions into executable code and deploy it to the arbitration governance smart contract, including but not limited to the following steps S221 to S224.

[0036] S221. Based on the payment conditions, call the large language model to generate the source code of the condition verification logic that conforms to the preset interface specification.

[0037] In step S221, the Large Language Model (LLM) is an artificial intelligence model trained on massive amounts of data that can deeply understand and generate human language and computer code. In this embodiment, the dedicated LLM is fine-tuned with financial and contract corpora. Its core function is to intelligently convert payment conditions described in natural language (such as "payment after goods are signed for") into condition verification logic source code that conforms to the preset interface specifications of blockchain smart contracts (such as fixed function names, parameters and return values).

[0038] S222. Perform interface compliance verification and security vulnerability scanning on the source code of the condition verification logic.

[0039] In step S222, the interface compliance verification aims to ensure that the smart contract source code generated by the large language model can be correctly and reliably called by the arbitration governance smart contract. The core of the interface compliance verification is to verify whether the generated code strictly follows the preset smart contract interface specifications, which typically includes: checking whether standard functions are clearly defined (such as "verifyCondition(bytes memory proof) returns (bool)"), whether the function visibility is correct (such as external or public), and whether the parameter and return value types match, etc. This can be achieved through static code analysis to ensure seamless technical integration. The security vulnerability scanning aims to identify and eliminate program defects and risk patterns in the source code that may endanger the security of locked funds. Based on a known smart contract security vulnerability database, it automatically detects whether there are common security threats such as reentrancy attacks, integer overflow / underflow, access control defects, and logical errors in the code through static analysis or formal verification tools. This is a core technical safeguard to prevent malicious use and ensure the financial security of the payment system.

[0040] S223. After passing the interface compliance verification and security vulnerability scan, the source code of the condition verification logic is deployed to the blockchain network to form a standardized condition verification module, and the smart contract interface address of the standardized condition verification module is obtained.

[0041] S224. Register the smart contract interface address to the arbitration governance smart contract, wherein the arbitration governance smart contract is configured to call the standardized condition verification module corresponding to the registered smart contract interface address when the payment conditions need to be verified, so as to manage the verification logic of the payment conditions.

[0042] S3. Continuously monitor off-chain state data associated with the external data source identifier through the oracle network.

[0043] In step S3, the oracle network serves as a secure data bridge connecting the blockchain to the external world. It is a decentralized service network composed of multiple independent nodes (i.e., the oracle network includes multiple independent oracle nodes). Its core responsibility is to acquire and verify off-chain state data from designated external data sources (such as logistics APIs or stock exchanges) on demand, and write it into the blockchain in a tamper-proof manner. The off-chain state data specifically refers to information states existing outside the blockchain system and stored in the traditional internet or physical world. In this embodiment, it directly corresponds to real-world event evidence upon which payment conditions depend, such as the package receipt status of a logistics company, real-time stock price data from a stock exchange, or temperature readings from an IoT sensor, etc. These data themselves do not possess the immutability of the blockchain; therefore, they must be reliably captured and verified through the oracle network before they can become a reliable basis for triggering automatic payments via smart contracts, serving as the core input for automating conditional payments.

[0044] S4. The oracle network determines whether the payment conditions are met based on a predefined consensus mechanism and the off-chain state data. If the conditions are met, a verification certificate indicating that the conditions are met is submitted to the arbitration governance smart contract.

[0045] In step S4, the consensus mechanism (such as threshold signature) is used to ensure the credibility of the data. That is, only when a sufficient number of nodes reach a consensus on the data will a unique cryptographic proof be generated and submitted to the arbitration contract, thereby solving the key technical bottleneck that smart contracts cannot actively obtain external credible data. Specifically, the payment conditions are determined based on the predefined consensus mechanism and the off-chain state data, including but not limited to the following steps S41 to S42.

[0046] S41. The off-chain state data is monitored, acquired, and submitted by each of the plurality of oracle nodes.

[0047] S42. When the off-chain state data submitted by the oracle nodes exceeding a preset threshold are consistent, the oracle network uses threshold signature technology to generate a verification proof based on the consistent off-chain state data to determine that the payment conditions are met.

[0048] In step S42, the preset threshold can be, for example but not limited to, a 5:7 preset threshold. That is, in a network composed of 7 independent oracle nodes, when any 5 (or more) nodes submit off-chain state data (such as "waybill signed for") that are completely consistent, the network determines that the data is valid. (This design allows the network to operate reliably even when at most 2 nodes fail or are unresponsive, achieving a balance between security and availability, reflecting the Byzantine fault-tolerant design philosophy.) The threshold signature technology is an advanced cryptographic scheme that shards a private key among multiple participants (such as oracle nodes). In this embodiment, when nodes that have reached the preset threshold reach a consensus on the data, the nodes do not need to exchange private key shards; they can collaboratively generate a single, standard, and verifiable aggregate signature as verification proof. This technology is not only highly secure but also generates a very small amount of proof data, greatly reducing the verification cost and complexity of on-chain contracts, and is key to achieving efficient decentralized consensus.

[0049] In step S4, considering that directly uploading plaintext data is not feasible when the conditions involve trade secrets or sensitive personal data (such as transaction amounts or medical records), the method preferably further includes the following steps to resolve the conflict between payment condition verification and data privacy protection: when verifying the payment conditions requires sensitive data, the condition prover generates a zero-knowledge proof and submits this zero-knowledge proof as the off-chain state data to the oracle network; the oracle network verifies the validity of the zero-knowledge proof and determines that the payment conditions are met upon successful verification. By introducing zero-knowledge proofs, the prover can prove to the oracle network that "the conditions have been met" without disclosing any sensitive information, thereby ensuring payment automation while meeting strict privacy and compliance requirements, and greatly expanding the applicability of the solution in highly sensitive scenarios.

[0050] S5. After verifying the validity of the verification certificate, the arbitration governance smart contract generates an execution instruction and sends it to the payment smart contract.

[0051] In step S5, the arbitration governance smart contract specifically verifies the validity of the verification proof by calling the standardized condition verification module corresponding to the registered smart contract interface address. Furthermore, the dispute resolution process is used to address and resolve objections initiated periodically by the payer or payee. Specifically, the dispute resolution process adopts the following progressive dispute resolution mechanism: after receiving the verification proof, the arbitration governance smart contract initiates a preset challenge waiting period; during the challenge waiting period, if the payer or payee raises an objection to the condition fulfillment status and pays a challenge deposit to the arbitration governance smart contract, an on-chain arbitration process is triggered; in the on-chain arbitration process, the arbitration governance smart contract submits the objection and related evidence to a decentralized arbitration tribunal composed of token holders for on-chain voting and, based on the feedback ruling, directly calls the function of the payment smart contract to execute the final allocation of funds. In detail, the members of the decentralized arbitration tribunal are token holders who voluntarily stake system tokens to the arbitration governance smart contract; the members' arbitration actions are linked to the economic incentives of their staked assets: if the member's vote is consistent with the final ruling of the arbitration tribunal, the member will receive a reward; if the member's vote is inconsistent with the final ruling of the arbitration tribunal or the member fails to participate in the voting according to the preset rules, a portion of the member's staked system tokens will be forfeited.

[0052] The aforementioned progressive dispute resolution mechanism is the core security network and trust enhancement layer of the entire automated payment system. Its core function is to introduce necessary human judgment and final adjudication power into the system while ensuring the efficiency of automated execution, thereby constructing a reliable payment environment that combines code determinism with real-world flexibility. Specifically, its role is reflected in three aspects: (A) Balancing automation and fault tolerance, that is, through the design of a "challenge waiting period," a cooling-off period and error correction window are set before automatic execution. This respects the efficiency of the automated process and provides a program exit for handling rare edge cases caused by oracle data anomalies, ambiguities in condition understanding, etc., preventing the rigidity risks that may be brought about by "complete code is law"; ( (B) Establish decentralized governance and game-theoretic constraints, which means that it transfers the right to adjudicate disputes from centralized institutions to a community of staked token holders constrained by economic incentives. Arbitrators ensure the seriousness and fairness of their voting by staking assets (rewarding correct votes / penalizing incorrect ones), making the dispute resolution process itself decentralized, trustworthy and resistant to manipulation; (C) Complete the legal and technological closed loop, which means that the mechanism transforms commercial disputes that may occur in the real world into an executable and verifiable on-chain governance process. The final ruling is automatically executed by the arbitration contract, so that dispute resolution is no longer an external event detached from the system, but is internalized and structured into the entire technological closed loop, ensuring the final certainty and legality of the payment result.

[0053] In step S5, to address the challenges of blockchain ecosystem fragmentation and performance differences, it is necessary to deploy computationally intensive condition verification on a high-performance, low-cost blockchain (such as Layer 2), while placing core asset custody and final payment execution on a more secure blockchain (such as the main chain). This achieves a cross-chain architecture of "verification and execution separation." Preferably, the payment smart contract and the arbitration governance smart contract are deployed on the first blockchain network, while the payment conditions are verified by an auxiliary contract or oracle deployed on the second blockchain network. When the payment conditions are met, a trigger signal is sent to the arbitration governance smart contract on the first blockchain network via a cross-chain messaging protocol to trigger the execution of the payment smart contract. This leverages the advantages of each chain and ensures reliable transmission of the trigger signal through the cross-chain messaging protocol, thereby significantly improving system scalability and reducing overall costs while ensuring security.

[0054] S6. In response to the execution instruction, the payment smart contract automatically transfers the locked funds to the address specified by the payee to complete the payment.

[0055] In step S6, considering that in traditional and simple blockchain payments, a transaction can only pay a single address, while in real-world business scenarios (such as supply chains, platform profit sharing, or tax withholding), a single payment often needs to be automatically and atomically split to multiple recipients. Therefore, in order to enable the payment smart contract to automatically complete complex splitting within a single transaction after being triggered, thereby extending automated payments from "peer-to-peer" to "peer-to-multipoint," greatly expanding its commercial applicability and flexibility, preferably, the payment smart contract has a preset configurable payment routing logic. This payment routing logic is used to define multiple receiving addresses and the fund allocation share for each of these multiple receiving addresses, including addresses specified by the recipient. It automatically transfers locked funds to the addresses specified by the recipient to complete the payment, including but not limited to: first calculating the amount due for each receiving address based on the payment routing logic and the locked funds in a single transaction; then splitting and routing the locked funds to the multiple receiving addresses based on the amount due for each receiving address to complete the payment. Furthermore, considering edge cases such as oracle data anomalies, condition misjudgments, or temporary changes in the payee's needs, it is necessary to grant the payee an active final confirmation right (this does not weaken automation, but rather, through a hybrid mechanism of "optimistic automatic execution supplemented by rapid manual confirmation," significantly improves the system's fault tolerance, flexibility, and user-friendliness while maintaining the overall efficiency framework, ensuring the robustness of automated payments in complex business environments). Preferably, before responding to the execution instruction, the payment smart contract also checks whether the payee has made a final confirmation of the upcoming payment via digital signature within a preset time. If so, the payment is executed immediately; otherwise, it waits for the execution instruction. This introduces crucial human confirmation and security redundancy into a highly automated payment system.

[0056] In summary, the automated payment method provided in this embodiment has the following technical effects: (1) This embodiment provides an automated payment solution based on smart contract integration and decentralized oracle. First, the payment protocol is acquired and parsed, the payment amount, payment conditions and external data source identifier are separated and processed, and the payment amount is transmitted to the payment smart contract for locking. The payment conditions are digitized into executable code and deployed to the arbitration governance smart contract. The data source identifier is sent to the decentralized oracle network. Then, the oracle network monitors the off-chain state data and judges whether the payment conditions are met through the consensus mechanism. Then, it submits a verification certificate to the arbitration governance smart contract. After the arbitration governance smart contract verifies the validity of the certificate, it issues an execution instruction to the payment smart contract. Finally, the payment smart contract automatically completes the fund transfer. Thus, through the combination of smart contract and oracle technology, trusted payment with no intermediaries, condition triggering and real-time automation is realized, which significantly improves settlement efficiency, transparency and flexibility. (2) It can realize the complete automation and efficiency revolution of the payment process. That is, through the automatic execution of smart contracts and the real-time verification of oracles, the manual processing and settlement cycle of several days in traditional payment can be shortened to the deterministic settlement that is completed instantly upon condition triggering, which greatly improves capital efficiency. At the same time, it also realizes the automatic conversion and deployment from natural language contracts to executable code, covering the complete closed loop from condition definition, verification to execution, eliminating the bottleneck of manual coding and intervention. (3) Decentralized trust can be built, significantly reducing costs and risks. On the one hand, payment contracts are used as automatic custodians, and arbitration governance contracts and decentralized arbitration tribunals replace traditional judicial / arbitration institutions, building a trust and enforcement system that does not rely on any single center. On the other hand, automation greatly reduces manual operation and intermediary service fees, and modularization and AI generation reduce development and adaptation costs. Furthermore, cross-chain design allows the computing load to be distributed to low-cost chains, further optimizing the fee structure. (4) It can ensure the deep transparency of business logic and the credibility of the process. That is, all payment terms, verification logic, fund status and arbitration records are publicly available and tamper-proof on the chain, providing a level of transparency that traditional "black box" payments cannot match. The oracle network based on multi-node consensus and threshold signature and the arbitration mechanism based on staking incentives jointly ensure the fraud resistance and objectivity and fairness of the process of putting off-chain data on the chain and resolving disputes. (5) It can provide unprecedented flexibility and scalability. Through two paths, namely pluggable standardized module library and AI dynamic code generation, the system can adapt to any complex and non-standard real-world payment conditions at extremely low cost. At the same time, it supports advanced functions such as automatic account routing and cross-chain verification execution, and can handle privacy-sensitive scenarios through zero-knowledge proofs to meet diverse business needs from simple to extremely complex. (6) It can enhance the robustness of the system and the user experience. That is, through the progressive dispute resolution mechanism, it can provide a formal channel for human supervision and error correction for the automated process, and the final confirmation option adds security redundancy. Security vulnerability scanning ensures basic security at the code level. In addition, while pursuing full automation, the system properly handles the edge cases of automation through dispute arbitration and final confirmation, making the technical solution more inclusive and practical for the real business environment. (7) Through systematic architectural innovation, this solution has achieved a leapfrog comprehensive improvement in multiple dimensions such as efficiency, cost, trust, flexibility and security. It can provide a complete and feasible technical blueprint for building the next generation of trusted automated payment infrastructure, which is convenient for practical application and promotion.

[0057] Finally, it should be noted that the above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. An automated payment method based on smart contracts, characterized in that, Including: Obtain the payment agreement reached between the payer and the payee; The payment agreement extracts the payment amount, payment conditions, and at least one external data source identifier for verifying the payment conditions. The payment amount is then transmitted to the payment smart contract, and the payment conditions are digitized into executable code and deployed to the arbitration governance smart contract. The external data source identifier is also transmitted to a decentralized oracle network. The payment smart contract is used to lock the payer's funds based on the payment amount and automatically execute the payment upon fulfillment of triggering conditions. The arbitration governance smart contract is used to manage the verification logic of the payment conditions based on the executable code, and it is also used to execute the dispute resolution process. The oracle network continuously monitors off-chain state data associated with the external data source identifier; The oracle network determines whether the payment conditions are met based on a predefined consensus mechanism and the off-chain state data. If the conditions are met, a verification certificate indicating that the conditions are met is submitted to the arbitration governance smart contract. After verifying the validity of the verification proof, the arbitration governance smart contract generates an execution instruction and sends it to the payment smart contract; In response to the execution instruction, the payment smart contract automatically transfers the locked funds to the address specified by the payee to complete the payment.

2. The automated payment method as described in claim 1, characterized in that, The dispute adjudication process adopts the following progressive dispute resolution mechanism: Upon receiving the verification proof, the arbitration governance smart contract initiates a preset challenge waiting period. During the challenge waiting period, if the payer or the payee raises an objection to the condition being met and pays a challenge deposit to the arbitration governance smart contract, the on-chain arbitration process is triggered. In the on-chain arbitration process, the arbitration governance smart contract submits the objections and related evidence to a decentralized arbitration tribunal composed of token holders for on-chain voting and adjudication. Based on the feedback of the adjudication, the payment smart contract's function is directly invoked to execute the final allocation of funds.

3. The automated payment method as described in claim 2, characterized in that, The members of the decentralized arbitration tribunal consist of token holders who voluntarily stake system tokens to the arbitration governance smart contract; The arbitration actions of the members are linked to the economic incentives of their pledged assets: if the member's vote is consistent with the final ruling of the arbitration tribunal, the member will receive a reward; if the member's vote is inconsistent with the final ruling of the arbitration tribunal or the member fails to participate in the voting according to the preset rules, a portion of the system tokens pledged by the member will be forfeited.

4. The automated payment method as described in claim 1, characterized in that, The oracle network comprises multiple independent oracle nodes; Determining whether the payment conditions are met based on a predefined consensus mechanism and the off-chain state data includes: The off-chain state data is monitored, acquired, and submitted by each of the plurality of oracle nodes. When the off-chain state data submitted by the oracle nodes exceeding a preset threshold are consistent, the oracle network uses threshold signature technology to generate a verification proof based on the consistent off-chain state data to determine that the payment conditions are met.

5. The automated payment method as described in claim 1, characterized in that, The payment terms are digitized into executable code and deployed to the arbitration governance smart contract, including: The payment conditions are parsed using a natural language processing model to understand their semantic logic and extract key verification elements containing event types and logical constraint parameters; these key verification elements are then transformed into query vectors. The semantic similarity is calculated between the query vector and the descriptive metadata vector of each standardized condition verification module in the pre-set standardized condition verification module library. Based on the semantic similarity calculation result, at least one standardized condition verification module that is most similar is selected from the standardized condition verification module library. Different standardized condition verification modules encapsulate executable code for implementing different off-chain condition verification logic and all follow the preset smart contract interface specification. The smart contract interface address of the at least one standardized condition verification module is registered to the arbitration governance smart contract, wherein the arbitration governance smart contract is configured to call the standardized condition verification module corresponding to the registered smart contract interface address when the payment conditions need to be verified, so as to manage the verification logic of the payment conditions.

6. The automated payment method as described in claim 1, characterized in that, The payment terms are digitized into executable code and deployed to the arbitration governance smart contract, including: Based on the payment conditions, a large language model is invoked to generate condition verification logic source code that conforms to a preset interface specification; the condition verification logic source code is then subjected to interface compliance verification and security vulnerability scanning; after passing the interface compliance verification and security vulnerability scanning, the condition verification logic source code is deployed to the blockchain network to form a standardized condition verification module, and the smart contract interface address of the standardized condition verification module is obtained; the smart contract interface address is registered to the arbitration governance smart contract, wherein the arbitration governance smart contract is configured to invoke the standardized condition verification module corresponding to the registered smart contract interface address when the payment conditions need to be verified, so as to manage the verification logic of the payment conditions.

7. The automated payment method as described in claim 1, characterized in that, The payment smart contract has a pre-configurable payment routing logic, which is used to define multiple receiving addresses and the fund allocation share of each receiving address among the multiple receiving addresses, including the address specified by the receiving party. Automatically transferring locked funds to the address designated by the recipient to complete the payment includes: Based on the payment routing logic and the funds locked in a single transaction, the amount due for each receiving address is calculated. Based on the amount due at each of the receiving addresses, the locked funds are split and routed to the multiple receiving addresses to complete the payment.

8. The automated payment method as described in claim 1, characterized in that, The payment smart contract and the arbitration governance smart contract are deployed on the first blockchain network, while the payment conditions are verified by an auxiliary contract or oracle deployed on the second blockchain network. When the payment conditions are met, a trigger signal is sent to the arbitration governance smart contract of the first blockchain network via a cross-chain messaging protocol to trigger the execution of the payment smart contract.

9. The automated payment method as described in claim 1, characterized in that, The method further includes: When verifying the payment conditions requires sensitive data, the condition prover generates a zero-knowledge proof and submits the zero-knowledge proof as the off-chain state data to the oracle network. The oracle network verifies the validity of the zero-knowledge proof, and determines that the payment conditions are met after the verification is successful.

10. The automated payment method as described in claim 1, characterized in that, Before responding to the execution instruction, the payment smart contract is also used to: check whether the payee has made a final confirmation of the payment to be executed through digital signature within a preset time; if so, execute the payment immediately; otherwise, wait for the execution instruction to arrive.

Images