Token-based asset platform of payment network system

Abstract

The interests of public and private departments on legal currency token coinage are increasingly increased. The latest trend is that commercial banks are interested in tokenization of their partial reserve fund on shared ledgers (e.g., blockchains), with the main objective of achieving real-time inter-bank transfer. The payment network system can provide a comprehensive sandbox solution for commercial banks, so that the commercial banks carry out tokenization on their deposits on their own selected block chains while complying with global standards to promote banks to transfer accounts through their networks. This technique may offer opportunities to employ advanced cryptographic techniques such as zero-knowledge proof and atomic exchange to build an environment that allows payment network systems to both connect banks for real-time transfer and provide value-added services such as fraud detection and bank deposit credentials.

Description

[0001] Related applications This application claims priority to Greek patent application No. 20230100785, filed on September 29, 2023, entitled “Payment Network System Tokenized Asset Platforms”, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0002] The following disclosure broadly relates to a deposit tokenization technology (DTT) that allows banks to tokenize their deposits on a blockchain while adhering to global standards developed by Payment Network Systems (PNS), such as those developed by Visa, to facilitate interbank transfers. In various respects, this disclosure describes the Payment Network Systems Tokenized Asset Platform (TAP) and its technology. Background Technology

[0003] The evolution of digital currencies has spurred the need to tokenize fiat currencies to operate on blockchains. Four different types have emerged: cryptocurrencies, stablecoins, central bank digital currencies (CBDCs), and tokenized bank deposits. Nevertheless, any form of digital cash controlled by private cryptographic keys is considered digital currency. While the need to tokenize fiat currencies is clear, many questions remain about how it will function. Furthermore, it is believed that the tokenization of fiat currencies is impossible if each bank or country pursues its own version of tokenized deposit products. Instead, banks need a global technology and standard to enable interoperability between bank tokens worldwide to lead the digitization of fiat currencies. Summary of the Invention

[0004] In one aspect, this disclosure provides a method for a payment network system to transfer multiple deposit tokens. The method may include: settling inter-chain transfers between a first token contract on a first blockchain and a second token contract on a second blockchain while preserving privacy, using an interoperable two-phase commit protocol and a relay node. The protocol may include: receiving, via the relay node, information about the transaction, including the amount to be transferred, a sender identifier, a sender's bank identifier, a receiver identifier, and the receiver's bank identifier, as well as the sender's signature, from a first bank belonging to the first blockchain; providing, via the relay node, information about the transaction, including the amount to be transferred, the sender identifier, the sender's bank identifier, the receiver identifier, and the receiver's bank identifier, to a second bank belonging to the second blockchain; and receiving, via the relay node, the receiver's signature from the second bank belonging to the second blockchain.

[0005] In many respects, the protocol also includes invoking a prepare-to-destroy function and verifying the sender's signature.

[0006] In several aspects, the protocol also includes invoking a pre-casting function and verifying the recipient's signature.

[0007] In various aspects, the protocol also includes invoking a commit-destroy function, wherein the commit-destroy function ultimately determines the destruction invoked in the prepare-destroy function.

[0008] In many respects, the protocol also includes invoking a submit casting function, wherein the submit casting function ultimately determines the casting to be invoked in the prepare casting function.

[0009] In many respects, the protocol also includes sending confirmation messages to the first bank and the second bank, wherein the confirmation messages confirm that the transfer has been completed.

[0010] In some respects, the agreement also includes an auditor who may optionally perform an audit to verify the integrity of the first bank, the second bank, and the payment network system.

[0011] In one aspect, this disclosure provides a non-transitory computer-readable medium storing instructions that, when executed, perform a method on a client device initiating a token transfer transaction. The method includes: receiving user input including input transaction information; generating a digital transaction information message based at least on the input transaction information, wherein the digital transaction information message includes at least one of a transfer amount, a sender's identifier, a receiver's identifier, a sender's bank identifier, a receiver's bank identifier, or a random variable; generating another digital message including at least one of the sender's identifier, the transfer amount, or a combination thereof; digitally signing the other digital message to generate a digital signature message; and sending a first data packet including at least one of the digital transaction information message or the digital signature message to a relay node to facilitate a transaction with a second bank server (SB server).

[0012] In several aspects, the method further includes receiving confirmation of transaction completion from the relay node.

[0013] In many respects, the method also includes displaying an executable notification on the client device, wherein the executable notification includes at least one of the following interactive options: an option to retry the transaction if the transaction fails, an option to initiate a new transaction, or an option to repeat the transaction.

[0014] In one aspect, this disclosure provides a system for facilitating blockchain transactions. The system may include a Payment Network Server Hub (PNS Hub), multiple bank servers connected to the PNS Hub, and an audit server connected to the PNS Hub. The PNS Hub may include a deposit tokenization sandbox for: connecting to the multiple bank servers; receiving data packets from a first bank server (FB server) among the multiple bank servers, wherein the FB server belongs to a first bank and is associated with a first blockchain, the data packets including transaction information and a digital signature message; encrypting at least a portion of the transaction information using the FB server's encryption key; generating a first new digital message based on the data packets; verifying the digital signature of the first bank's digital signature message; and based on the verification, sending at least a portion of the transaction information to a second bank server (SB server) among the multiple bank servers, wherein the SB server belongs to a second bank and is associated with a second blockchain.

[0015] In several aspects, the system includes the FB server among the plurality of bank servers, configured to: generate a digital transaction message by the FB server of a first bank, wherein the FB server is associated with the first bank, a first client account of a first user, and a first blockchain, wherein the digital transaction message includes at least one of a transaction amount, an identifier of the first client account, an identifier of a second client account of a second user of a second bank, an identifier of the first bank, an identifier of the second bank, or a random variable; digitally sign another message including at least the identifier and the transfer amount to generate a first bank digital signature message; and send a first data packet including at least one of the digital transaction message or the first bank digital signature message to the PNS hub.

[0016] In many respects, the system includes an SB server among the plurality of bank servers, configured to: receive at least a portion of the transaction information by the SB server, wherein the SB server is associated with the second bank; verify the compliance of the at least a portion of the transaction information by the SB server; sign the second bank message to generate a digitally signed second bank message, the second bank message including at least one of an identifier of a second client account, an identifier of the SB server, or a transfer amount; and send the digitally signed second bank message to the PNS hub.

[0017] In various aspects, the PNS hub includes a deposit tokenization sandbox for: receiving a second bank digital signature message from an SB server; generating a second new digital message based on at least one of the transaction information from the data packet or the second bank digital signature message; invoking a prepare-to-destroy function based on a first input including at least one of the first new digital message or the first bank digital signature message; invoking a prepare-to-mint function based on a second input including at least one of the second new digital message or the second bank digital signature message upon receiving confirmation; performing a token destruction function upon receiving another confirmation from the SB server; performing a token minting function upon receiving a successful token destruction confirmation from the token destruction function; and sending a confirmation message to at least one of the FB server or the SB server upon receiving a successful token minting confirmation from the token minting function.

[0018] In many respects, the system also includes an audit server for determining whether a destruction certificate from at least one of the first or second banks matches an encrypted balance sheet.

[0019] In various aspects, the prepared destruction function includes instructions for: verifying the signature of the first bank's digital signature message against the first input; deducting the transaction amount from the first bank's first account based on the verification; registering the addition of the transaction amount to a first pending digital token balance associated with the first bank; and setting an expiration time, which is set to rescind the token transfer if no confirmation is received by the PNS hub within the expiration time.

[0020] In some aspects, the prepared minting function includes instructions for: verifying the signature of the second bank against the second input; and, based on the verification, registering the addition of the transaction amount in a second pending digital token balance associated with the second bank.

[0021] In many respects, the token destruction function includes instructions for: determining that the current timestamp is less than the expiration time; deducting the transaction amount from the first pending digital token balance based on the determination; and generating a confirmation indicating successful token destruction, the confirmation being received by the PNS hub.

[0022] In several aspects, the token destruction function includes instructions for: determining that the current timestamp is not less than the expiration time; based on the determination, transferring the transaction amount from the first pending digital token balance to a first client account; and generating a failed token destruction confirmation, which can be received by the PNS hub.

[0023] In each respect, the token minting function includes instructions for: determining that the current timestamp is less than the expiration time; based on the determination, transferring the transaction amount from the second pending digital token balance to the second client account of the second user of the second bank; and generating a confirmation indicating successful token minting, the confirmation being receivable by the PNS hub.

[0024] In many respects, the token minting function includes instructions for: determining that the current timestamp is not less than the expiration time; deducting the transaction amount from the second pending digital token balance based on the determination; and generating an indication of failed token minting, which may be received by the PNS hub. Attached Figure Description

[0025] In this description, specific details, such as particular aspects, procedures, techniques, etc., are set forth for purposes of explanation and not limitation in order to provide a thorough understanding of the invention. However, it will be apparent to those skilled in the art that the invention may be practiced in other aspects besides these specific details.

[0026] The accompanying drawings, together with the detailed description below, are incorporated in and form part of this specification, and serve to further illustrate aspects of the concepts including the claimed disclosure and to explain the various principles and advantages of those aspects.

[0027] The systems disclosed herein have been represented by conventional symbols in the accompanying drawings where appropriate, showing only those specific details relevant to understanding various aspects of this disclosure, so as not to obscure this disclosure with details obvious to those skilled in the art who benefit from the description herein.

[0028] Figure 1 A sandbox of deposit tokenization technology hosted by a payment network system is shown, according to at least one aspect of this disclosure.

[0029] Figure 2 This is an example bubble diagram of deposit tokenization technology disclosed through a payment network system according to at least one aspect of this disclosure, showing the various connections between the hub and other digital currencies and deposit tokenization technologies.

[0030] Figure 3 It is a commercial bank balance sheet showing deposit tokens representing bank assets and liabilities, as shown in at least one aspect of this disclosure.

[0031] Figure 4 A deposit tokenization technology bridging protocol custodied by a payment network system is illustrated, according to at least one aspect of this disclosure.

[0032] Figure 5An alternative aspect of a deposit tokenization technology bridging protocol hosted by a payment network system, according to at least one aspect of this disclosure, is shown.

[0033] Figure 6 This disclosure illustrates yet another deposit tokenization technology bridging protocol hosted by a payment network system, according to at least one aspect of this disclosure.

[0034] Figure 7 A sandbox proposal illustrates a process by which public banks and auditors communicate through different bridges and functions, according to at least one aspect of this disclosure.

[0035] Figure 8 A sandbox proposal illustrates an alternative process for communication between public banks and auditors through different bridges and functions, according to at least one aspect of this disclosure.

[0036] Figure 9 It is a block diagram of a computer device having a data processing subsystem or component according to at least one aspect of the present disclosure.

[0037] Figure 10 It is a graphical representation of an example system including a host according to at least one aspect of this disclosure, within which a set of instructions for performing any or more methods discussed herein can be executed.

[0038] Figure 11 A flowchart of a method for transferring multiple tokens according to at least one aspect of this disclosure is shown.

[0039] Figure 12 A flowchart is shown of a method for initiating and conducting token transfer transactions via a client device, according to at least one aspect of this disclosure.

[0040] Figure 13 This disclosure illustrates one possible aspect of the architecture for a system and method for a deposit tokenization technology bridging protocol hosted by a payment network system connected to multiple banking systems, according to at least one aspect of this disclosure.

[0041] Figure 14 Alternative aspects of the architecture of a system and method for a deposit tokenization technology bridging protocol hosted by a payment network system connected to multiple banking systems, according to at least one aspect of this disclosure, are shown.

[0042] Figure 15 This disclosure illustrates another alternative aspect of the architecture of a system and method for a deposit tokenization technology bridging protocol hosted by a payment network system connected to multiple banking systems, based on at least one aspect of this disclosure. Detailed Implementation

[0043] The following disclosure provides exemplary systems, apparatuses, and methods for conducting financial transactions and related activities. While reference may be made to such financial transactions in the examples provided below, the aspects are not limited thereto. That is, the systems, methods, and apparatuses described can be used for any suitable purpose.

[0044] As part of the overall deposit tokenization technology, it may be necessary to transfer tokens atomically across blockchains. Various aspects of this disclosure relate to technologies that enable commercial banks to perform interbank, inter-chain (e.g., inter-blockchain) transfers using relay nodes managed by a payment network system, while hiding the banks' balance sheet data from other banks and the payment relays.

[0045] In one aspect, this disclosure provides a two-phase commit protocol between two token contracts deployed on different blockchains, and relay nodes (operated by the payment network system) for settling inter-chain transfers. As part of the payment network system's deposit tokenization technology, aspects of this disclosure enable atomic transfers of tokens across blockchains. This allows commercial banks to use payment network system relay nodes to perform interbank, inter-chain transfers. In another aspect, this disclosure provides an interoperability protocol between two blockchains that provides the privacy guarantees required by the payment network system's deposit tokenization technology.

[0046] In a general sense, the following disclosures relate to the development of systems or technologies that can meet the following needs: tokenization that allows banks’ assets and liabilities to be held in the form of deposit tokens; interoperability that allows tokens to circulate in real time across many different banks and financial institutions; on-demand audits by third parties of the reserve requirements and solvency of the token supply; and programmability to enforce policies regarding the circulation of deposit tokens, privacy protection, and so on.

[0047] As disclosed in this paper, one aspect of the proposed method is based on, for example, Visa. TM The payment network system has developed deposit tokenization technology that allows banks to tokenize their deposits on a blockchain while adhering to global standards developed by the payment network system, such as those by Visa. TM Develop global standards to facilitate interbank transfers. These standards may include one or more of the following: blockchain-agnostic design, universal token contracts, universal bridges, real-time interbank transfers, and on-chain / off-chain programmability.

[0048] The systems and technologies disclosed in one aspect of this disclosure typically involve three types of participants: banks, relay services, and auditors. Bank-type entities are responsible for minting and burning tokens, conducting internal transfers, and authorizing incoming and outgoing transactions. Banks can only see their own balance sheets and incoming transaction data from other banks. Relay services, or payment network systems, relay cross-chain transfers and provide value-added services (fraud checks, custody, directory services, etc.). Relay services can only see transfer information such as amount, sender, receiver, time, source bank, and destination bank. Finally, auditors verify zero-knowledge (ZK) proofs from the relay service and obtain real data from the chain. Auditors can only see certain transfer information, for example, transfers > $10,000.00.

[0049] This paper and the preceding descriptive paragraphs disclose several types of zero-knowledge proofs. Solvency Proof (PoS) is a range proof where x > 0 and Enc(bal) > x > 0. Destruction Proof (PoB) is a proof that the destruction of TX is recorded on the sender's chain. Minting Proof (PoM) is a proof that the minting of TX is recorded on the sender's chain. Equivalence Proof (PoE) is a proof that the destruction of TX and the minting of TX are of the same amount. Inclusion Proof (PoI) is a proof that destruction and minting have been committed and confirmed.

[0050] To include all the necessary information for understanding the disclosed descriptions and diagrams, the following provides various entity, notation, and smart contract definitions and functions.

[0051] Entities: “Distributed Ledger Technology” (DLT) is a permissioned blockchain, accessible only to a consortium, and maintained by a set of validator nodes approved by the consortium to run a Byzantine Fault Tolerance (BFT) consensus. Various DLTs may allow only one bank or financial entity, while others allow many banks. A “token contract” can be a smart contract deployed on a DLT for each bank or financial institution to maintain tokenized deposits for its customers (the term “bank as used herein” can refer to any or all of the following: these banks, institutions, and any servers, data centers, or computing systems belonging to or associated with them). A “party” is any entity in the system that can be identified by an identity identifier (e.g., a public key). These can include the following: (a) a “bank” is a bank that owns the token contract; (b) a “minter” is a bank-authorized entity capable of minting new tokens; (c) a “customer” is a customer of the bank (e.g., an individual or company with a deposit account, where the deposit account is also referred to as a bank liability); and (d) a “payment network system,” such as Visa. TM(a) The “auditor” is a semi-trusted entity that acts as an intermediary between banks and smart contracts deployed by banks and maintains a full read-only node for each DLT; (e) The “auditor” is a trusted entity that has read-only access to the blockchain by maintaining a full node or customer list, wherein the auditor performs sporadic random audits by requesting proofs from banks and payment network systems in order to ensure the honest behavior of all system entities in an optimistic manner.

[0052] Notation: "[value]" bank "[value]" is the value encrypted using probabilistic additive homomorphic encryption with a bank key. "r" is used to construct "[value]". bank The randomness of "σ". "C" is the smart contract address. party "(m)" is the digital signature of the participant for the message "m". For the ZK proof "π", the Camenisch-Stadler notation is used as π = {(w): R(x,w) = 1}(x), where "w" is a private witness of the public instance "x" and the NP relation "R" such that R(x,w) = 1.

[0053] Smart contract definition: In various implementations, smart or token contracts can be defined by the following contract field: "[totalLiabilities]" bank "It is the sum of all customer balances encrypted under the bank's key." [totalSupply] bank "balances" refers to the number of tokens in circulation encrypted under a bank key. "balances" can be of the form {party:([balances ... party ] bank , [Outbal party ] bank , [Inbal party ] bank The dictionary of} maintains the token balance of each participant, where party represents the participant's identity, "bal party "Outbalance" indicates the balance available for spending, and "Outbalance" party "and "Inbal party"This represents the pending expenditure and income balances that are locked. "minters" is the set of allowed minters. "expiry" is a hard-coded value representing the maximum time (or number of blocks) before the amount in the pending state is rolled back without confirmation from the payment network system. "account" can be a record with the following attributes: "isInitialized" and balance. "lockKey" can be used when locking an account for concurrency control. "pendingPayment" can be a record with the following attributes: "BURN", "INTERNALTRANSFER", "EXTERNALBURN", and "EXTERNALMINT". "client" can be an account associated with the pending payment type. "amt" can be the payment amount. "expiry" can represent the time (or number of blocks) to wait for a relay to confirm an operation in the pending state. Such operations may not be able to be revoked if not confirmed within this period. "[totalSupply]" bank "Can be the number of tokens in circulation encrypted under a bank key. "name" can be the name of the token. "symbol" can be the symbol of the token (e.g., a shorter version of the name). "currencyType" can be the currency type of the token. "bank" can be the address of a bank. "relayer" can be the address of a relayer. "decimals" can be the number of decimal places used to obtain its user representation. For example, if the number of decimal places is equal to 2, the balance of 505 tokens should be displayed as 5.05 (505 / (10 * 2)). "prepareDuration" can represent the maximum time period (or maximum number of blocks) for waiting for the relayer to confirm an operation in a pending state. Such operations can be subsequently revoked if they are not confirmed within this period. "lockDuration" can represent the maximum time period (or maximum number of blocks) before the lock on an account expires automatically. "accounts" can be a list of account records, which is essentially a bank customer's balance sheet. "pendingPayments" can be a list of pending payments in storage. "isSeenBefore" can be a list of txids that have already been used in a transaction.

[0054] Contract function overview: "prepareBurn(client, [amt])" bank , σ bank This will reduce the customer's balance by [amt]. bank This will increase the customer's spending balance by the same amount. "prepareMint(client, [amt])"bank ,σ bank This will increase the customer's income balance by "[amt]". bank ". "commitBurn(client, [amt] bank This will reduce the customer's spending balance. bank ". "commitMint(client, [amt] bank This will increase the customer's balance by "[amt]". bank "and reduce the customer's income balance by the same amount." "checkExpiry()" is an accounting function that cancels prepareBurn and prepareMint if they are not confirmed by the corresponding function within the due date. "transferInternal(sender, receiver, [amt])" bank This transfers tokens within the same contract. "totalSupply(bank)" returns [totalSupply]. bank "balanceOf(party)" returns [balance] party ] bank .

[0055] Core smart contract functionalities: "mint(txid, client, [amt]bank)" homomorphically adds "amt" to the client's encrypted balance. "burn(txid, client, [amt]bank), σ, lockKey" homomorphically deducts "amt" from the client's encrypted balance. "transferInternal(txid, sender, receiver, [amt]bank), σ, lockKey" transfers "amt" from the sender to the receiver within the same contract. "prepareBurn(txid, client, [amt]bank, σ, lockKey)" reduces the client's balance by [amt]bank and adds [amt]bank to the pending payment list. "commitBurn(txid)" finalizes the operation from prepareBurn() based on the expiration status and removes the operation from txlist. "revertBurn(txid)" reverts the operation from prepareBurn() based on the expiration status and removes the operation from txlist. The `prepareMint(m, σ)` function adds transaction events to the `txlist`. The `commitMint(txid)` function finalizes the operation from `prepareMint()` based on the expiration status and removes the operation from the `txlist`. The `revertMint(txid)` function reverts the operation from `prepareMint()` based on the expiration status and removes the operation from the `txlist`.

[0056] Smart contract function: "prepareMint(receiver, [amt])" bank ", σ)" can (a) require the caller to be the payment network system; and (b) include [amt] bank Add to [Inbal] party ] bank_receiver . "commitMint(receiver,[amt] bank ", σ)" can (a) require the caller to be the payment network system; (b) from [Inbal party ] bank_receiver [amt] is deducted from the middle. bank (c) [amt] bank Add to balanceOf(receiver); and (d) add [amt] bank Add to [totalSupply] bank “burn(sender, [amt]”bank The expression "balanceOf(sender)" can (a) require the caller to equal the bank; and (b) verify π to ensure that balanceOf(sender) ≥ [amt]. bank (c) Deduct [amt] from balanceOf(sender) bank ; and (d) from [totalSupply] bank [amt] is deducted from the middle. bank . "transferInternal(sender, receiver, [amt] bank The expression "(π1, π2)" can (a) require the caller to be a bank; and (b) verify π1 and π2 to ensure [amt] bank >0 and balanceOf(sender) ≥ [amt] bank (c) Deduct [amt] from balanceOf(receiver) bank ; and (d) will [amt] bank Add to balanceOf(receiver). "addMinter(party)" can (a) require the caller to be a bank; and (b) add a participant to the minting party. "removeMinter(party)" can (a) require the caller to be a bank; and (b) remove a participant from the minting party. "sendCrossChain(Req, σ)" can (a) require the caller to be a bank; and (b) resolve Req to (sender, receiver, bank). to , [amt] bank_to (c) Call burn(sender, [amt]); bank , π); and (d) send to the payment network system. “receiveCrossChain(t, tx) cross , [amt] bank_receiver , π inc, "π2)" can (a) require the caller to be a bank; and (b) obtain the block header (bh, LCS). C bridge .GetHeader(t); (c) Using π inc Verify tx cross Is it included in tx? cross In the middle; and (d) calling mint(receiver, [amt]); bank_receiver , π2).

[0057] The off-chain function "CreateMintTx(receiver, amt)" can (a) encrypt amt into [amt]. bank (b) Generate proof [amt] bank NIZK proof of π > 0; and (c) calling Cmint(client, [amt]). bank , π). “CreateBurnTx(sender, amt)” can (a) encrypt amt to [amt] bank (b) Generate proof balanceOf(sender) - [amt] bank NIZK proof of π > 0; and (c) calling C.mint(client, [amt]). bank , π). “CreateInternalTx(sender, receiver, amt)” can (a) encrypt the sender and receiver respectively as [amt]. bank_sender and [amt] bank_receiver (b) Generate separate proofs for balanceOf(sender) - [amt] bank >0 and [amt] bank NIZK proofs for π1 and π2 > 0; and (c) calling C.transferInternal(sender, receiver, [amt]). bank , π1, π2). “sendCrossChainTXinit(sender, receiver, bank to "amt, chainID" can be invoked by the bank by sending an outbound request to the payment network system, and may include (a) encrypting amt as [amt]. bank ; and (b) sending Req = (sender, receiver, bank) to the payment network system to [amt] bank_to chainID) and σ bank_from (Req). “sendCrossChainTXinitfwd(Req, σ)” can be executed by the payment network system upon receiving data from the sending bank. from The transaction request is invoked and may include (a) verifying σ; and (b) sending a request to the bank. to Send (Req, bank) from ,σ). “rcvCrossChainTXinit(Req, bank from , σ)” can be obtained from bank toInvoked upon receiving a request for a transaction from the payment network system, and may include (a) resolving Req as (sender, receiver, bank) to , [amt] bank_to (a) chainID); (b) [amt] bank_to Decrypt to amt; and (c) if σ verifies or [amt] bank If decryption fails, or if the recipient is on a blacklist, send ((Req, NACK), σ) to the payment network system. bank_to ((Req, NACK))) otherwise send (ACK, σ) to the payment network system bank_to , ((Req,ACK))). “sendCrossChainTX(Req, σ)” can include (a) generating NIZK for amt ∈ Req. π1 ; and (b) calling tx cross = C. Additionally, “SendCrossChain(Req, π, σ)” can include σ, where σ represents the digital signature and / or encryption of the data.

[0058] The foregoing definitions and functions apply to the deposit tokenization technology discussed in this article, but will be found most helpful in explaining bridge protocols, such as... Figure 1-15 The aspects described herein. Furthermore, the specific details presented below will aid in understanding the disclosed figures and aspects.

[0059] Figure 1 A Deposit Tokenization Technology (DTT) sandbox hosted by a payment network system is illustrated according to at least one aspect of this disclosure. The DTT sandbox 101 communicates with a bank 102, such as a commercial bank or other financial institution (when referred to herein as "bank," this disclosure includes, in its sense, any computing system; local, cloud, or enterprise network; server; mainframe; or other nodes used, owned, or associated with the bank where appropriate), which invokes an application programming interface (API) via a username and password and invokes DTT interoperability services. The DTT sandbox 101 includes a set of DTT APIs 103, and tokenization services such as a tokenization provider 104, a smart contract library 105, proof-of-reserve 106, and a multi-chain manager 107. Furthermore, the DTT sandbox 101 includes a blockchain comprising a custodial master wallet for the bank and additional custodial wallets for the bank and business-to-business (B2B) customers. Key services being developed by the payment network system are the tokenization service and the DTT interoperability service, both of which are provided by… Figure 1 The box in the text is covered.

[0060] Figure 2This is a simplified diagram of Deposit Tokenization Technology (DTT) 200 disclosed through a payment network system according to at least one aspect of this disclosure, showing various connections between hub 201 and other digital currencies and DTT 202. For example, Figure 2 The Payment Network System (PNS) hub connects to various central bank digital currencies (CBDCs), stablecoins, and DTTs203, some of which have been developed by the Payment Network System. It should be noted that the deposit tokenization technology disclosed herein is not limited to… Figure 2 The connections described herein. In a general sense, the deposit tokenization technology disclosed herein enables banks to tokenize their deposits on a blockchain, thereby complying with global standards to facilitate interbank transfers. In various aspects, the deposit tokenization technology can provide chain-agnostic design, universal token contracts, universal bridges, real-time interbank transfers, and / or on-chain and off-chain programmability.

[0061] Figure 3 This is a commercial bank balance sheet 300 showing deposit tokens representing bank assets 301 and liabilities 302, according to at least one aspect of this disclosure. Regarding assets 301, loans 303 occupy the majority of space in balance sheet 300, followed by current assets 304, then cash 305 and commercial bank reserves 306 in equal proportions. Regarding liabilities 302, deposits 307 occupy the majority of space in balance sheet 300, followed by debt (or borrowed capital) 308 and equity 309 in equal proportions.

[0062] Figure 4 A bridging protocol 400 hosted by a Payment Network System (PNS) according to at least one aspect of this disclosure is illustrated. In the disclosed aspect, bank 1 401 sends 411 TX information and Sig to PNS 410 via wallet provider 1 403 and user 1 404. Bank1 Then, PNS 410 provides 412 of at least some of the information received from bank 1 401 to bank 2 402. In response, bank 2 402 sends 413 Sig to PNS 410. Bank2 The "Prepare for Destruction" process 419 and the "Prepare for Casting" process 415 follow immediately afterward, followed by the destruction process 416 and the casting process 417, which are then confirmed with both Bank 1 and Bank 2. Finally, PNS 410 communicates with the auditor 420, who can conduct an audit at any future point in time.

[0063] In some respects, PNS completes advanced transaction flows between two banks (or entities) that belong to, are associated with, or utilize two different blockchains, according to the following steps.

[0064] First, Bank 1 401 (e.g., the bank that initiated the transfer after a request from one of its customers) begins to perform the following tasks: (a) creating a message txInfo = {r, amt, (sender, banksender), (receiver, bankreceiver)}, the message including transaction information, where r is a randomness sampled by the sending bank, amt is the amount to be transferred, the sender is the sending customer belonging to the bank sender, and the receiver is the receiving customer belonging to the bank receiver; (b) for m1 Sign (sender, [amt]bank_sender) to obtain σ1 σbank_sender(m1), i.e., signed, authenticated, and / or encrypted (m1), where [amt]bank_sender is the amount to be transferred encrypted with randomness r; and (c) send 411 (txInfo, σ1) to PNS 410.

[0065] Upon receiving the tuple (txInfo, σ1), the PNS 410 performs the following tasks: (a) using the sender's bank encryption key [amt] bank_sender Enc((txInfo.amt, txInfo.r), bank sender (a) Encrypt the transferred amount; (b) Construct message m1 and / or verify σ1, the message being based on and including information from txInfo; (c) Perform compliance / fraud checks on txInfo and / or σ1, such as for anti-money laundering checks; and (d) Send 412 (txInfo) to bank 2 402 (e.g., the bank receiving the payment). In each respect, if PNS 410 successfully verifies... σ1 If the compliance / fraud check is successful and without issues, then txInfo is either transmitted or sent to bank 2402 via 412. In some embodiments, m1 is constructed by PNS 410 based on σ1 and includes (sender, [amt]). bank_senderIn other embodiments, m1 may include any information or combination of information derived from txInfo and / or σ1. In several aspects, the message m1 can be constructed / reconstructed using information from txInfo as follows: txInfo = {r, amt, (sender, banksender), (receiver, bankreceiver)} m1 = (sender, [amt]bank_sender). Specifically, the payment network can use the randomness r from txInfo to reconstruct the ciphertext [amt]bank_sender.

[0066] Upon receiving (txInfo) from PNS 410, the receiving bank 402 performs the following tasks: (a) checks the compliance of the received transaction message (e.g., checks against a customer blacklist); (b) examines message m2. (receiver,[txInfo.amt) bank_receiver Sign to obtain σ2 σ bank_receiver (m2), where [amt] bank_receiver (c) Indicate the encrypted amount to be received; and (d) send 413 (σ2) to PNS 410.

[0067] Upon receiving the pair (σ2) from receiving bank 402, PNS 410 performs the following tasks: (a) [amt] bank_receiver Enc((txInfo.amt, txInfo.r), bank receiver (b) Construct m2 based on information from txInfo and / or σ2, and / or verify σ2; and (c) Invoke 414 tx prepareBurn C sender .prepareBurn(m1,σ1), where the prepareBurn function 414 checks the signature of bank 401 against the input, [amt] bank_sender It is deducted from balanceOf(sender) and recorded as pending destruction, and if no confirmation is received, the expiration time burnExpiry is set to cancel the destruction.

[0068] Upon receiving tx prepareBurn Upon confirmation, PNS 410 calls 415 tx prepareMint C receiver.prepareMint(m2, σ2), where the prepareMint function 415 checks the signature of bank 402 against the input, and [amt] bank_receiver Added to pending income balance 435.

[0069] Upon receiving tx prepareMint Upon confirmation, PNS 410 calls 414 tx commitBurn C sender .commitBurn(), where the commitBurn function 414 is ultimately determined in tx prepareBurn The destruction process called within the `<process>` block ensures that the current timestamp is less than the expiration time, and if the timestamp is satisfied, deducts `[amt]` from the pending destruction count. bank_sender Otherwise, deduct [amt] from the pending destruction list. bank_sender And add it back to balanceOf(sender).

[0070] Upon receiving tx commitBurn Upon confirmation, PNS 410 calls tx commitMint C receiver .commitMint(), where the commitMint function 415 is ultimately determined in tx commitMint The casting process calls a function that ensures the current timestamp is less than the due date, and if the timestamp is met, deducts [amt] from the pending revenue balance. bank_receiver Then add it to balanceOf(receiver). Otherwise, deduct [amt] from the pending revenue balance. bank_sender .

[0071] Upon receiving tx commitMint Upon confirmation, PNS 410 sends a confirmation message to 419 regarding the completion of the transfers to the two banks 401 and 402.

[0072] After the transaction is finalized and its corresponding elements are recorded on the blockchain, the auditor 420 may, at any future point in time, optionally and passively perform the following audits 419 on some timestamps / blocks to verify the integrity of the bank and PNS 410: (a) PoB (from the bank): π b = {(r, amt): amt ≥ 0 ∧ bal sender ≥ amt}([amt] bank , [bal sender ] bank , bank), where bal senderIt sends the customer's bank balance, which is reflected in the balance sheet in encrypted format as [balance]. sender ] bank (This proves that the amount destroyed is non-negative and the remaining amount in the sender's balance is not negative); and (b) PoE (from PNS): π e = {(r, amt)}([amt) bank_sender [amt] bank_receiver bank sender bank receiver This proves that the same amount is encrypted in both the destruction and casting operations.

[0073] Figure 5 This disclosure illustrates a deposit tokenization technology (DTT) bridging protocol 500 hosted by a Payment Network System (PNS) 510, according to at least one aspect of this disclosure. In the disclosed aspect, bank 1 501 sends 511 TX information and Sig... to PNS 510 via wallet provider 1 503 and user 1 504. Bank1 And PoB. Then, PNS 510 will provide 512 to bank 2 502 at least some of the information received from bank 1 501. In response, bank 2 502 will send 513 Sig to PNS 510. Bank2 The preparation for destruction process 514 and the preparation for casting process 515 follow immediately, which also includes setting the expiration date, and then the destruction process 516 and the casting process 517 are completed. Shortly thereafter, confirmation occurs with both Bank 1 501 and Bank 2 502. Finally, PNS 510 communicates with the auditor 520, who can conduct an audit at any future point in time, specifically regarding zero-knowledge (ZK) proofs 519, namely proof of equivalence (PoE), proof of destruction (PoB), and proof of inclusion of destruction and casting (PoI).

[0074] The following items are applicable Figure 5 DTT as described in the text: Optimistic Zether: All ZK verifications, initially completed by contracts, are now being done piecemeal off-chain by auditors; PoB: Proof of the ZK range x>0 and ()>>0; PoE: ZK Proof ,_1,_2 .., _1=_1 (,_1), _2= _2 (,_2); Preparation for destruction: checking solvency; and Preparing for casting: Checking supply / liability requirements to assume liabilities.

[0075] Figure 6A deposit tokenization technology (DTT) bridging protocol 600, custodied by PNS 610, is illustrated according to at least one aspect of this disclosure. In the disclosed aspect, bank 1 601 sends 611 TX information, Sig, and Sig messages to PNS 610 via wallet provider 1 603 and user 1 604. Bank1 The expiration date and proof of destruction (PoB) are then determined. PNS 610 then provides 612 to bank 2 602 at least some of the information received from bank 1 601. In response, bank 2 602 sends 613 Sig to PNS 610. Bank2 The preparation for destruction and the preparation for casting follow immediately, including the expiration date, and then the destruction process 614 and the casting process 615 are completed. Then, PNS 610 communicates with the auditor 620, who can conduct an audit at any future point in time, specifically regarding zero-knowledge (ZK) proofs, i.e., proof of equivalence (PoE), proof of destruction (PoB), and proof of inclusion (PoI). However, unlike... Figure 4 and Figure 5 In addition to the publicly disclosed information described in the report, the auditors also received information from Bank 1 601's token contract 625 and from PNS 610.

[0076] The following items are applicable Figure 6 DTT as described in the text: Optimistic Zether: All ZK verifications, initially completed by contracts, are now being done piecemeal off-chain by auditors; PoB: Proof of the ZK range x>0 and ()>>0; and PoE: ZK Proof ,_1,_2 .. _1=_1 (,_1 ), _2= _2 (,_2 ).

[0077] Figure 7 A sandbox proposal illustrates a process 700 in which a public bank 701 and an auditor 720 communicate through various bridges and functions according to at least one aspect of this disclosure. Bank 701 is responsible for deploying the token contract 725 and sending a zero-knowledge proof-of-reserve (PoR) 703. Auditor 720 is responsible for verifying the fiat reserves and signing the PoR. Next, the token contract 725 verifies the cross-DLT reserves 726 before the UPC contract 730 (cross-consortium bridge) and ultimately before the reserve contract 735. An on-chain bridge (atomic swap) 727 is also present. Central bank 740 is responsible for deploying the reserve contract 735, which maintains and creates / destroys central bank digital currency. Any of these contracts 725, 730, and 740 may have ledger and / or custody functions and may act as a balance sheet for the token or digital currency.

[0078] The following items are applicable Figure 7 The sandbox proposal described in the document includes: multiple banks on the same island, a universal token contract or an ERC-20-like interface, and an interface for standardizing the content required for cross-island transactions.

[0079] Figure 8 A sandbox proposal is shown for an alternative process 800 in which public banks 801, 840, and auditor 820 communicate through different bridges and functions according to at least one aspect of this disclosure. In this aspect, bank 801 is responsible for deploying token contract 825 and sending zero-knowledge proof of reserves (PoR) 803, while central bank 840 is responsible for deploying reserve contract 839. Auditor 820 is responsible for verifying fiat reserves and signing PoR 803 821. Next, token contract 825 verifies 826 central bank digital currency reserves before satisfying reserve contract 839, which maintains and mints / destroys central bank digital currency. In this aspect, UPC contract 830 (cross-faction bridge) is bypassed. In one aspect, token contract 825 maintains the supply and balance sheet, mints / destroys tokens, and verifies PoR. In another aspect, reserve contract 839 maintains CBDC reserves and mints / destroys CBDC. In one aspect, permissioned blockchains avoid Sybil attacks, but individual members remain untrusted in terms of integrity and privacy.

[0080] In all aspects, this article combines Figure 1-8 and Figure 11-13 The described s can be implemented in computer systems and distributed networks. In various aspects, this paper combines... Figure 1-8 and Figure 11-13 The described deposit tokenization technology can be applied in several ways, such as Figure 9 The computer device 3000 shown and such Figure 10 The example system shown is implemented on a 4000.

[0081] Figure 9 It is a block diagram of a computer device 3000 having a data processing subsystem or component according to at least one aspect of this disclosure. Figure 9The subsystems shown are interconnected via system bus 3010. Additional subsystems are shown, such as printer 3018, keyboard 3026, fixed disk 3028 (or other memory including computer-readable media), monitor 3022 (coupled to display adapter 3020), etc. Peripheral devices and input / output (I / O) devices coupled to I / O controller 3012 (which may be a processor or other suitable controller) can be connected to the computer system via any number of means known in the art, such as serial port 3024. For example, serial port 3024 or external interface 3030 can be used to connect computer device 3000 to a wide area network (WAN), such as the Internet, a mouse input device, or a scanner. The interconnection via system bus 3010 allows central processing unit 3016 to communicate with each subsystem and control the execution of instructions from system memory 3014 or fixed disk 3028, as well as the exchange of information between subsystems. System memory 3014 and / or fixed disk 3028 may be embodied in computer-readable media.

[0082] Figure 10 This is a graphical representation of an example system 4000 including a host 4002, according to at least one aspect of this disclosure, within which a set of instructions can be executed to perform any or more of the methods discussed herein. In various aspects, the host 4002 operates as a standalone device or can be connected (e.g., networked) to other machines. In a network deployment, the host 4002 can operate as a server or client machine in a server-client network environment, or as a peer-to-peer (or distributed) network environment. The host 4002 can be a computer or computing device, a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular phone, a portable music player (e.g., a portable hard disk audio device, such as a Moving Picture Experts Group Audio Layer 3 (MP3) player), a network appliance, a network router, a switch, or a bridge, or any machine capable of executing a set of instructions (sequentially or otherwise) specifying the actions to be taken by said machine. Furthermore, although only a single machine is shown, the term "machine" should also be understood to include any set of machines that individually or collectively execute one or more sets of instructions to perform any one or more methods of the methods discussed herein.

[0083] Example system 4000 includes a host 4002, on which a host operating system (OS) 4004 runs on one or more processors / processor cores 4006 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both) and various memory nodes 4008. The host OS 4004 may include a super manager 4010 capable of control functions and / or communicating with virtual machines (VMs) 4012 running on machine-readable media. VM 4012 may also include a virtual CPU or vCPU 4014. Memory nodes 4008 may be linked or pinned to virtual memory nodes or vNodes 4016. When a memory node 4008 is linked or pinned to a corresponding vNode 4016, data can subsequently be directly mapped from the memory node 4008 to its corresponding vNode 4016.

[0084] All the various components shown in host 4002 can be connected to and linked to each other, or communicate with each other via a bus (not shown) or via other coupling or communication channels or mechanisms. Host 4002 may also include a video display, audio device or other peripheral device 4018 (e.g., liquid crystal display (LCD), alphanumeric input device (including, for example, a keyboard), cursor control device (e.g., mouse), voice recognition or biometric authentication unit, external driver, signal generation device (e.g., speaker)), persistent storage device 4020 (also referred to as a disk drive unit), and network interface device 4022. Host 4002 may also include a data encryption module (not shown) for encrypting data. The components disposed in host 4002 are components commonly found in computer systems suitable for use with aspects of this disclosure, and are intended to represent a broad category of such computer components known in the art. Thus, exemplary system 4000 may be a server, minicomputer, host computer, or any other computer system. Computers may also include different bus configurations, networking platforms, multiprocessor platforms, etc. It can use various operating systems, including UNIX, LINUX, WINDOWS, QNX ANDROID, IOS, CHROME, TIZEN and other suitable operating systems.

[0085] Disk drive unit 4024 may also be a solid-state drive (SSD), hard disk drive (HDD), or other drive including computer-readable or machine-readable media on which one or more sets of instructions and data structures (e.g., data / instructions 4026) embodying or utilizing any one or more of the methods or functions described herein are stored. Data / instructions 4026 may also reside wholly or at least partially within main memory node 4008 and / or processor / processor core 4006 during execution by host 4002. Data / instructions 4026 may be further sent or received via network 4028 via network interface device 4022 utilizing any of several well-known transport protocols (e.g., Hypertext Transfer Protocol (HTTP)).

[0086] Processor 4006 / processor core and memory node 4008 may also include machine-readable media. The term "computer-readable media" or "machine-readable media" should be considered as including a single or multiple media (e.g., a centralized or distributed database and / or associated caches and servers) storing one or more instruction sets. The term "computer-readable media" should also be considered as including any medium capable of storing, encoding, or carrying an instruction set for execution by host 4002 and causing host 4002 to perform any or more methods of this application, or any medium capable of storing, encoding, or carrying data structures utilized by or associated with such instruction set. Therefore, the term "computer-readable media" should be understood to include, but is not limited to, solid-state memory, optical and magnetic media, and carrier signals. Such media may also include, but is not limited to, hard disks, floppy disks, flash memory cards, digital video optical discs (DVDs), random access memory (RAM), read-only memory (ROM), etc. The exemplary aspects described herein may be implemented in an operating environment including software installed on a computer, in hardware, or in a combination of software and hardware.

[0087] Figure 11A flowchart of method 1100 for transferring multiple tokens from one account to another is shown. Method 1100 can be used for inter-blockchain transfers between accounts belonging to different banks. In one embodiment, method 1100 may include receiving 1105 information about a transaction (e.g., a token transfer) from a first bank belonging to a first blockchain via a relay node. In various embodiments, this information may include any one (or any combination of) the following: the amount to be transferred (transaction amount), the sender's identifier, the sender's bank identifier, the recipient's identifier (including a client or client device associated with the aforementioned user), the recipient's bank identifier, and the sender's signature. In many embodiments, method 1100 utilizes an interoperable two-phase commit protocol and a relay node to settle inter-chain transfers between a first token contract on a first blockchain and a second token contract on a second blockchain while preserving privacy. The protocol may include the procedures outlined in method 1100.

[0088] Method 1100 may further include providing 1110 information about the transaction to a second bank belonging to the second blockchain via a relay node, such as the payment network system described above. This information includes, but is not limited to, any one of the following: the amount to be transferred, the sender's identifier, the sender's bank identifier, the recipient's identifier, and the recipient's bank identifier. Other information, such as a client identifier (e.g., including the client of an application) or the identifier of the client device running the client, as well as bank accounts, credit cards, application accounts, or other account information or identifiers, such as email addresses, usernames, IP addresses, etc., may be part of the transaction information in various embodiments of the remainder of this disclosure and in method 1100.

[0089] Method 1100 may further include receiving the signature of recipient 1115 from a second bank belonging to the second blockchain via a relay node. In various embodiments, the protocol of method 1100 may also include invoking a prepare-to-destroy function and verifying the sender's signature, and invoking a prepare-to-mint function and verifying the recipient's signature. In several aspects, either the prepare-to-destroy function or the prepare-to-mint function depends on the successful verification of one or all signatures. In several aspects, method 1100 may invoke a commit-to-destroy function.

[0090] The commit burn function ultimately determines the burn that is invoked in the prepare burn function, and is typically based on successful signature verification. In any respect, method 1100 invokes the commit mint function, where the commit mint function ultimately determines the mint that is invoked in the prepare mint function. In each respect, burn refers to removing funds, tokens, or digital currencies from an account and / or withdrawing them from circulation, while mint refers to creating new coins, tokens, or digital currencies and adding them to an account and / or into circulation. Depending on the specifics, the tokens, digital currencies, or currencies burned or minted can be different or the same, and belong to the same or different blockchains.

[0091] Confirmation messages can be sent upon successful or failed transactions, including sending confirmation messages to the first bank and the second bank, wherein the confirmation message confirms that the transfer has been completed, partially completed, or failed. Method 1100 may also include an auditor, auditing service, or server that optionally performs an audit to verify the integrity of the first bank, the second bank, and the payment network system.

[0092] Figure 12 A flowchart is shown for a method 1200 for initiating and conducting token transfer transactions via a client device. The token transfer transaction can be conducted on a client application (also referred to as a "client") running on a client device or user device, such as a mobile phone, computing device, or tablet. The client device can execute a client application. The client can be a wallet, wallet provider, payment, or any other type of application or program, such as a browser. The client initiates a token transfer transaction, which includes receiving 1205 user input including input transaction information, wherein the user input may include, but is not limited to, username, email address, phone number, transfer amount, number of transactions, recipient's identity, type of funds (e.g., type of token or digital currency / instrument), and IP information, blockchain information, sender account information for withdrawing funds, transfer options or selected speed, etc.

[0093] In various aspects, method 1200 may also include sending the received user input, a portion of the user input, or data associated with the user input (collectively referred to herein as "input transaction information") to a bank server. The client itself may run on a first bank server, which receives the input transaction information derived from the user input directly or via the client. The client may then generate a 1210 digital transaction information message, which includes at least one of the following: a sender identifier (e.g., its name or the username of an application), a sender client identifier (e.g., which may include a serial or unique identifier), a transfer amount (as referred to herein, 'transfer amount' may include the type of funds, such as a specific currency or digital token to be transferred or utilized, and the amount of funds), or a combination thereof. Another message 1215, including a portion of the input transaction information, may also be generated.

[0094] Once a digital message is generated, the client application can digitally sign the digital transaction information message 1220 via the bank server to generate a digitally signed message. Then, method 1200 can continue to send 1225 data packets, such as a first data packet including at least one of the digital transaction message or the digitally signed message, to a relay node, such as a payment network server, to facilitate the transaction with the second bank server. In several aspects, the client can receive notifications confirming successful or failed token transactions from the relay node and / or the payment network server. In several aspects, based on the confirmation, the client can display an executable notification on the user interface or display of the client device, the executable notification including at least one of the following interactive options: an option to retry the transaction if it fails, an option to initiate a new transaction, or an option to repeat the transaction.

[0095] Figure 13 This illustration shows one possible aspect of the architecture of a system for a Deposit Tokenization Technology (DTT) bridging protocol hosted by a payment network system connected to multiple banking systems, according to at least one aspect of this disclosure. Reference is now made primarily to... Figure 13 Combination Figure 2 In various embodiments, system 1300 includes components for facilitating blockchain transactions and / or token transfers (e.g., digital assets and currencies). These components include, but are not limited to, payment network server hubs or relay nodes 1310 (referred to as “PNS hubs”), which may include one or more servers, relay nodes, and / or hubs 201 of a payment network system, such as... Figure 2 As disclosed in the document. The PNS hub 1310 can connect to multiple bank servers, systems, networks, digital currencies, and / or payment technologies, such as systems and currencies 202, etc. Figure 2 As disclosed in the document.

[0096] Main reference Figure 13 Combination Figure 1 In many ways, PNS Hub 1310 can facilitate connections with various banking systems through APIs, API tools, software development kits, or other runtime and query languages ​​or combinations thereof, such as API testing tools. Figure 1 As disclosed herein. In several aspects, the audit server or system 1304 (which may be a standalone service or a service associated with the PNS hub 1310) is also connected to or communicates with the PNS hub 1310. In several aspects, the PNS hub 1310 includes a deposit tokenization sandbox or container for executing methods to facilitate token and / or blockchain transactions.

[0097] In several respects, the PNS hub 1310 is coupled or connected to a first bank / first bank server 1301 (FB server) of multiple bank servers or systems, and / or coupled or connected to a second bank / second bank server 1302 (SB server) of multiple bank servers or systems, wherein FB server 1301 and SB server 1302 belong to the first bank and the second bank, respectively. FB server 1301 and SB server 1302 may be associated with or be part of the first bank system or network 1321 (referred to herein as "FB network 1321") or the second bank system or network 1322 (referred to herein as "SB network 1322"), respectively.

[0098] These networks 1321 and 1322 may include enterprise systems, databases, data centers, and / or large server systems, mainframes, etc., and may be hosted locally, in a cloud environment, and / or as a distributed system. In several respects, FB server 1301 and / or associated FB network 1321 may belong to or be associated with a first blockchain, while SB server 1302 and / or associated SB network 1322 may belong to or be associated with a second blockchain.

[0099] In many respects, FB server 1301 responds to clients or client applications, such as wallet providers or applications 1306 on the user device or client device of a first sender user 1311 of a first bank, who wishes to transfer funds to a second recipient user 1312 belonging to a second bank. In various respects, the first user 1311 sends funds, including but not limited to financial instruments or assets, using a client such as wallet provider or application 1306, and the second user 1312 receives these funds in the same or different forms, using digital instruments or assets (e.g., the same or different digital currencies).

[0100] In one aspect, once FB server 1301 receives a first user transaction request, for example from a client, application, or wallet provider, it triggers an authorization process that includes the procedures of system 1300 prior to 1315. FB server performs the following: generates a digital transaction message, transaction information data packet, or transaction information, wherein the transaction message (or transaction data / information) includes at least one of the following: the amount transferred, an identifier of a first client or client device, an identifier of a second client or client device, an identifier of a first bank, an identifier of a second bank, an identifier of a first bank system or server, an identifier of a second bank system or server, a random variable, or any combination thereof.

[0101] Once the FB server 1301 has generated a digital transaction message or transaction information, the FB server then digitally signs another message to generate a first bank digital signature message, which in several respects includes at least a sender identifier and a transfer amount. In various respects, other combinations of information derived from input transaction information or other transaction information, i.e., the transaction data / information listed above and the transaction data / information discussed in other diagrams within this disclosure, can be used to digitally sign the message. The FB server 1301 can then send a first data packet 1313 to the PNS hub 1310, including at least one of the digital transaction message and / or the first bank digital signature message, to facilitate the transaction requested by the first user 1311.

[0102] Upon receiving a data packet, the PNS hub 1310 can then facilitate the transfer of financial assets from one bank to another in several ways by receiving a first data packet 1313 sent by the FB server 1301 from multiple bank servers. The first data packet includes transaction information, a digital signature message, or both. The PNS hub 1310 can then encrypt at least a portion of the transaction information using the encryption key of the FB server 1301. In several ways, this portion of the transaction information includes encrypting the amount transferred.

[0103] Then, PNS hub 1310 can generate a first new digital message based on the data packet. In many respects, the construction of the first new digital message is based on at least a portion of the information in the transaction message or the transaction message, such as any combination of any of the following included in the digital transaction data packet 1313 sent by FB server 1301: the transfer amount, the identifier of a first client or client device, the identifier of a second client or client device, the identifier of a first bank, the identifier of a second bank, the identifier of a first bank system or server, the identifier of a second bank system or server, a random variable, other input transaction information, or any combination thereof. PNS hub 1310 can also verify the digital signature associated with or in the digital signature message 1313 sent by FB server 1301, and based on successful verification, for example, if the signature is problem-free or non-fraudulent and / or verified as belonging to FB server 1301, PNS hub 1310 can send at least a portion of transaction message 1314 to SB server 1302 among multiple bank servers.

[0104] SB server 1302 can receive at least a portion of the transaction message sent 1314, and can then verify the compliance of at least a portion of the transaction message, for example, compliance with pre-set rules, regulations, or laws, or compliance with customer blacklists. After successful verification, SB server 1302 then signs the second bank message to generate a digitally signed second bank message, and sends the digitally signed second bank message 1315 to PNS hub 1310. The second bank message includes at least one of the following: recipient client identifier (e.g., wallet provider or digital wallet 1307 and / or associated user 1312), identifier of SB server 1302 and / or second bank network 1322, and / or transfer amount. This is where the authorization process of system 1300 ends and the settlement process begins.

[0105] The settlement process of system 1300 includes PNS hub 1310 receiving a second bank digital signature message 1315 sent by SB server 1302. Then, PNS hub 1310 generates a second new digital message based on at least one of the following: information from a data packet or the second bank digital signature message, and executes, runs, or calls function 1316 "Prepare to Destroy" or "Prepare to Destroy Tokens" based on a first input including at least one of the first new digital message or the first bank digital signature message. The call to function 1316 with the aforementioned input can be made on, using, or via a digital token pending balance or contract 1325 ("Token Contract 1325") on FB network 1321, whereby Token Contract 1325 may include various functions, including but not limited to custody and / or ledger functions.

[0106] The function 1316 for preparing to destroy / destroy tokens may include verifying the signature of a first bank digital signature message against a first input by PNS hub 1310, FB network 1321, or both. Based on successful verification, it then deducts the transaction amount from the account associated with the first user (e.g., the sending user), for example, from the first user's digital wallet provider 1306 associated with FB server 1301, and registers the transaction amount added to a token contract 1325 associated with said FB server 1301 or first bank network 1321, preparing for the destruction of the added amount. Function 1316 may also include setting an expiration time, which is set to rescind the blockchain token transfer if PNS hub 1310 does not receive confirmation within the expiration time. If verification fails, the transaction may be cancelled by PNS hub 1310, or PNS hub 1310 may attempt to automatically repeat the transaction. In some respects, when function 1316 fails, for example, if verification fails, based on this failed verification, PNS hub 1310 may request additional information or input required to complete the transaction from first user 1311, second user 1312, client or wallet provider / client 1306, 1307 and / or FB server 1301 or SB server 1302, or PNS hub 1310 may cancel the transaction.

[0107] After the successful completion of the burn function 1316, the transaction settlement process continues, wherein when the PNS hub 1310 receives a successful confirmation from the burn function 1316, the PNS hub 1310 executes, runs, or calls the "preparation to mint function" 1317 based on a second input including at least one of a second new digital message or a second bank digital signature message or both, and calls, executes, or runs this preparation to mint function 1317 in various aspects of the digital token pending contract 1335 on or associated with the SB network 1322, wherein the token pending contract 1335 may include various functions, including but not limited to custody and / or ledger functions.

[0108] In various aspects, the minting preparation function 1317 may include verifying the signature of SB server 1302 against a second input by one of PNS hub 1310, SB server 1302, and / or SB network 1322, and based on the verification, if the verification is successful, registering the addition of a second pending digital token balance 1335 associated with SB server 1302 or SB network 1322, or registering the addition of a transaction amount to the second pending digital token balance, in preparation for minting the added amount. In some aspects, in the event of a failure of function 1317, for example, if the verification fails, based on this failed verification, PNS hub 1310 may query the first user 1311, the second user 1312, the client or wallet provider / client 1306, 1307, and / or FB server 1301 or SB server 1302 for additional information or input required to complete the transaction, or PNS hub 1310 may cancel the transaction.

[0109] After receiving another confirmation from the prepare minting function 1317 from the SB server 1302 and / or from the SB network 1322, the PNS hub 1310 calls, executes, or initiates the token burn process / function 1318 on the token contract 1325, which submits / completes the process performed in the prepare burn function 1316.

[0110] The token destruction function 1318 may include determining that the current timestamp is less than the expiration time, and based on this determination, the token destruction function may deduct the transaction amount from the first pending digital token balance 1325, essentially "destroying" or deleting the token from storage or circulation, and then generating a confirmation indicating successful token destruction, which may be received by the PNS hub 1310. However, in an unsuccessful destruction scenario, the token destruction function 1318 may include determining that the current timestamp is not less than the expiration time, and based on this determination, the token destruction function may transfer the transaction amount from the first pending digital token balance 1325 to a first client account; this can be accomplished by first deleting the transfer amount from the first pending digital token balance 1325, then adding the transaction amount to the first client account, and then generating a confirmation indicating failed token destruction, which may be received by the PNS hub 1310. Upon receiving a successful token destruction confirmation from the token destruction function 1318, the PNS hub 1310 can then continue the transaction by calling, executing, or initiating the token minting function 1319, and upon receiving a successful token minting confirmation from the token minting function 1319, can send a confirmation message to at least one of the FB server or SB server via the PNC hub 1310.

[0111] In several aspects, the token minting function 1319 includes determining that the current timestamp is less than the expiration time, and based on said determination, transferring the transaction amount from the second pending token balance to the second client account, for example by deleting the transaction amount from the second pending digital token balance 1335, then adding the transaction amount to the second client account, and then generating a confirmation indicating successful token minting, wherein the confirmation may be received by the PNS hub 1310. In an unsuccessful scenario, the token minting function 1319 includes determining that the current timestamp is not less than the expiration time, and based on said determination, deducting the transaction amount from the second pending digital token balance, essentially deleting or destroying the token to be created before it is generated, and then generating a confirmation indicating failed token minting, which may be received by the PNS hub 1310.

[0112] In several respects, PNS hub 1310 may also receive at least one of a failed token burning confirmation or a failed token minting confirmation from functions 1318 and 1319, respectively. In many respects, PNS hub 1310 sends a notification of a successful or failed token transfer transaction (1320) to at least a first client or device 1306 or a second client / / device 1307.

[0113] Those skilled in the art will recognize that an Internet service can be configured to provide Internet access to one or more computing devices coupled to the Internet service, and the computing devices may include one or more processors, buses, memory devices, display devices, I / O devices, etc. Furthermore, those skilled in the art will understand that the Internet service can be coupled to one or more databases, repositories, servers, etc., which can be used to implement any of the various aspects of this disclosure as described herein.

[0114] Computer program instructions may also be loaded onto a computer, server, other programmable data processing apparatus or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide for implementing the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0115] For example, a suitable network may include or interface with any one or more of the following: local intranet, PAN (Personal Area Network), LAN (Local Area Network), WAN (Wide Area Network), MAN (Metropolitan Area Network), Virtual Private Network (VPN), Storage Area Network (SAN), Frame Relay connection, Advanced Intelligent Network (AIN) connection, Synchronous Fiber Network (SONET) connection, digital T1, T3, E1 or E3 line, Digital Data Service (DDS) connection, DSL (Digital Subscriber Line) connection, Ethernet connection, ISDN (Integrated Services Digital Network) line, dial-up port (e.g., V.90, V.34 or V.34bis), dual analog modem connection, cable modem, ATM (Asynchronous Transfer Mode) connection, or FDDI (Fiber Distributed Data Interface) or CDDI (Copper Distributed Data Interface) connection. In addition, communications may include links to any of a variety of wireless networks, including WAP (Wireless Application Protocol), GPRS (General Packet Radio Service), GSM (Global System for Mobile Communications), CDMA (Code Division Multiple Access) or TDMA (Time Division Multiple Access), cellular telephone networks, GPS (Global Positioning System), CDPD (Cellular Digital Packet Data), RIM (Dynamic Research Ltd.) full-duplex paging networks, Bluetooth radio, or IEEE 802.11-based radio frequency (RF) networks. Server 4030 may also include or interface with any one or more of the following: RS-232 serial connection, IEEE-1394 (FireWire) connection, Fibre Channel connection, Infrared Data Association port, SCSI (Small Computer System Interface) connection, USB (Universal Serial Bus) connection or other wired or wireless, digital or analog interfaces or connections, mesh or Digi® networking.

[0116] Figure 14 Alternative aspects of the architecture of a tokenized asset platform (TA) system and method for a deposit tokenization technology (DDT) bridging protocol hosted by a payment network system (PNS) connected to multiple banking systems are shown, based on at least one aspect of this disclosure. Figure 14 The architecture shown is in many ways similar to Figure 13 The architectures shown are the same or very similar; however, Figure 14It is also shown that each bank can connect to its associated ledger, which may or may not be hosted on the respective bank's network. For example, Bank 1 can connect to the Bank 1 ledger, and Bank 2 can connect to the Bank 2 ledger. The Bank 1 ledger and the Bank 2 ledger can respectively host digital contracts 1425 and 1435 corresponding to digital contracts 1325 and 1335, and similar functionality can be allowed. Figure 13 Systems, methods, and processes can be applied to Figure 14 However, for the sake of brevity, it will not be repeated.

[0117] Figure 15 This disclosure illustrates another alternative aspect of the architecture for a tokenized asset platform (TAP) system and method based on at least one aspect of the present disclosure, using a deposit tokenization technology (DTT) bridging protocol hosted by a Payment Network System (PNS) hub 1510 connected to multiple banking systems. The TAP model is... Figure 1 The model is illustrated below. This model considers banks that have already tokenized customer deposits on smart contracts (which can be within the same ledger or across different ledgers). The amounts reflected on the smart contracts are in a format encrypted under the corresponding bank's key to protect customer privacy.

[0118] In terms of fundamentals, Figure 15 The architecture shown includes: a sending user 1511 with an account at bank 1 1501 requests to send a specified amount to a receiving user 1512 with an account at bank 2 1502. This transfer is facilitated by a relay (or relay party), such as relay party 1510, which also has access to smart contracts, including but not limited to token contracts 1525 and 1535 that respectively own banks 1501 and 1502. During the transfer, relay party 1510 will be aware of the amount transacted between banks 1501 and 1502, but may still not be aware of the encrypted balance sheet information.

[0119] Finally, the deployed TAP model is optimistic (sometimes referred to as "trust and verification"). This means that the actions of banks 1501, 1502, and relayers 1510 are considered honest, and these aforementioned entities are expected to comply with the protocol. However, auditor 1504 can, at any point in time, request proof from those entities that they have indeed complied with the TAP protocol. These proofs are created in a zero-knowledge (ZK) paradigm, ensuring that auditor 1504 has no access to information such as customer balances or transaction amounts.

[0120] Figure 14-15 Both of the architectures shown can include Figure 13Any protocol described herein, and may also include alternative processes as further described herein. For example, any of the architectures may include: sending users 1411 and 1511 to initiate a transaction by sampling a random transaction identifier txid1, hashing the transaction as... h = H(“EXTERNALBURN”,txid1, [amt]banksender), and send the hash σ with a signature of 1540 to banks 1, 1401, and 1501 respectively. sender ( h ).

[0121] Continue to refer to Figure 14-15 Then, banks 11401 and 1501 can execute the following protocol: (a) verify σ sender ( h (b) Regarding the randomness of encryption r 1. Sampling; (c) Using randomness r 1. Construct the ciphertext [amt]bank sender (d) Create transaction information message txInfo1 = {txid1, sender, [amt]} banksender , σ sender ( h 1), lockKey}; (e) calling the function lockAccount(sender, lockKey) 1541, which locks the user account or client account to prevent any changes, such as pending transactions other than the current transaction, to avoid changes to the account during protocol execution; and (f) calling prepareBurn(txInfo1) 1541. In several aspects, upon calling prepareBurn, the smart contract performs one or more of the following: (a) verifying that the sender account has been locked; (b) verifying that txid1 is not in "isSeenBefore"; (c) verifying σ sender ( h 1); (d) Add txid1 to "isSeenBefore"; (e) Add {"EXTERNALBURN", sender, [amt]} banksender (f) Homomorphically deduct amt from the customer balance and global totalSupply; (g) Set lockExpiry of the client account to 0 (unlock the account); and (h) Issue a prepareBurn event as event1 = {txid1, sender, [amt]}banksender}

[0122] Then, banks 1 (sender banks) 1401 and 1501 can send 1542 (txInfo1, amt, ...) to relays 1410 and 1510 (also known as "relay nodes"). r 1. bank receiver The transaction hashes of receiver and event1.

[0123] Then, relay nodes 1410 and 1510 can perform the following actions: (a) using randomness r 1. Reconstruct the ciphertext [amt] banksender (a) Verify that the ciphertext is equal to the ciphertext in event1; (b) Verify σ 1; (c) Perform compliance / fraud checks as needed; and (d) Contact banks 2, 1402, 1502 (e.g., banks with addresses) receiver The bank (corresponding to the bank receiving the payment) sends 1543 {receiver, amt}.

[0124] Upon receiving {receiver, amt} from relays 1410 and 1510, receiving banks 1402 and 1502: (a) check if the receiving bank exists on the contract's balance sheet and if the transaction is compliant (e.g., the customer is not on a transaction blacklist); (b) check the encryption randomness. r 2. Sampling with the unique transaction identifier txid2; (c) Using randomness r 2. Construct the ciphertext [amt] bankreceiver (d) For messages h 2← H ("EXTERNALMINT", txid2, receiver, [amt] bankreceiver Sign to obtain σ 2← σ bankreceiver ( h 2); and (e) send 1544 (txid2, to relays 1410 and 1510. r 2, σ 2).

[0125] Upon receiving (txid2, r 2, σ 2) When relays 1410 and 1510: (a) using randomness r 2. Reconstruct the ciphertext [amt] bankreceiver And verify that the ciphertext equals h (b) Verification of the ciphertext in 2; σ 2; (c) For random values r 3. r 4. Perform sampling; (later used to randomize the auditorInfo hash); (d) convert txInfo = {sender, receiver, bank} sender bank receiver , txid1, txid2, amt, r 1, r 2, r 3, r 4) Save to its database (for future auditing); (e) Calculate auditorInfo1= H (bank sender (f) in smart contract 1535 of receiving bank 1502 (also referred to herein as the “token contract” or “digital token contract”) call prepareMint(txid2, receiver, [amt], txid1, r3), where the auditorInfo information will be used in the later audit phase; and (f) in smart contract 1535 of receiving bank 1502 (also referred to herein as the “token contract” or “digital token contract”) call prepareMint(txid2, receiver, [amt]). bankreceiver , σ 2,auditorInfo1) 1545. Smart contract 1535 performs the following when calling prepareMint: (a) Verification σ 2; (b) {"EXTERNALMINT", receiver, [amt] bankreceiver Add `expiry` to `pendingPayments[txid2]`, where `expiry = now + prepareDuration`; and (c) emit the `prepareMint` event as `event2 = {txid2, receiver, [amt]`. bankreceiver , auditorInfo1}.

[0126] Relays 1410 and 1510 calculate audioInfo2= H (bank receiver The smart contract calls `commitBurn(txid1, auditorInfo2)` in smart contracts 1425 and 1525, which send data to banks 1401 and 1501 respectively. Upon calling `commitBurn`, the smart contract performs the following actions: (a) deletes `pendingPayments[txid1]`; and (b) emits `commitBurn` event 1546 as `event3 = txid1`. This `commitBurn` event can be accessed via... Figure 14 , Figure 15 The token contracts 1435 and 1535 are executed, and the token contracts can be held in custody by bank 21502. Figure 14 Digital ledger 1437 and / or Figure 15 On the banking network 1537.

[0127] Relays 1410 and 1510 call `commitMint(txid2)1547` within the smart contracts of receiving banks 1402 and 1502. Upon calling `commitMint 1547`, the smart contract performs the following actions: (a) homomorphically adds the amount to the receiving customer's balance and the global `totalSupply`; (b) deletes `pendingPayments[txid2]`; and (c) emits a `commitMint` event as `event4 = txid2`. This `commitMint` event can be accessed via... Figure 14 , Figure 15 The token contracts 1435 and 1535 are executed, and the token contracts can be held in custody by bank 21502. Figure 14 Digital ledger 1437 and / or Figure 15 On the banking network 1537.

[0128] exist Figure 1-15 The various aspects of the publicly disclosed systems, methods, processes, and protocols, after a transaction is finalized and its corresponding elements are recorded on the blockchain, allow the auditor to optionally, passively, audit certain timestamps / blocks at any future point in time to verify the integrity of the bank and the relayer.

[0129] Observing the commitBurn smart contract operation, the destruction proof πb from the bank proves that the destroyed amount is non-negative and that the remaining amount in the sender's balance is not negative. This proof is provided in ZK as follows: πb = {(r, amt): amt ≥ 0 ∧ bal sender ≥ amt}([amt]bank, [bal sender ]bank, bank), where bal sender It sends the customer's bank balance, which is reflected in the balance sheet in encrypted format as [balance]. sender ]bank.

[0130] When observing commitBurn or commitMint events, an equivalence proof from the relay node is provided: this proves the existence of matching commitMint or commitBurn operations, respectively, and that the encrypted amounts are equal. This proof is provided in ZK as follows: First, the auditor requests the relay node to prove the equivalence of a specific event (without loss of generality, we assume the queried event corresponds to a commitBurn operation). Then, the relay node retrieves the corresponding transaction data from its database that matches the txid in the queried event and provides the auditor with auditorInfo1 and auditorInfo2, which reveal the txid1, txid2, and txid2 of a single TAP transaction. r 3. r 4. Sender, Receiver, Bank sender and bank receiver Then, for the corresponding encryption, the relay provides πe = {(r1, r2, amt)}([amt]bank sender , [amt]bank receiver bank sender ,bank receiver ).

[0131] exist Figure 1-15 The TAP protocol, which discloses various aspects of the systems, methods, processes, and protocols, can utilize additive homomorphic encryption schemes. The TAP protocol can be instantiated as an example using an "additive version of ElGamal encryption," which consists of the following algorithm: pp ← Setup(1λ): Outputs common parameters pp = (G, g, p) with input security parameters λ, where g is a generator of the cyclic group G of prime order p. These parameters are considered the default inputs for all subsequent algorithms and are omitted for simplicity. (pk, sk) ← Gen(): Outputs the secret public key pair sk ← Zp, pk = g sk .

[0132] (c1, c2) ← Enc(pk, x): Perform a region r ← Zp and calculate c1 = g. r c2= g x pk r Output the ciphertext C = (c1, c2). x ← Dec(sk, (c1, c2)): Calculate g x = c2 / c sk Although it cannot be directly derived from g x x is calculated, but it can be recovered as explained in this article. The scheme is additively homomorphic because it assumes Enc A (pk, x1) EncB (pk, x2)= (c 1A · c 1B , c 2A · c 2B = Enc(pk, x1+ x2). The message space is in Z. p In this context, 0 is not included. For example, various methods exist to support encryption of 0 by mapping the message space {0, ..., p - 2} to {1, ..., p - 1}.

[0133] As discussed above, in the addition ElGamal, Dec(sk, (c1, c2)) does not directly output x, but instead outputs g. x Recovering the actual value x can be done either by brute-force iterating through all possible x values ​​or by using a pre-computed lookup table. These two methods respectively require... O (1) Space and O (n) calculation or O (n) space and O (1) The calculation is only feasible if the message space is relatively small (at most a few billion values).

[0134] However, for example, the "Shanks algorithm" implements a time-space tradeoff for the above naive solution. It defines a "baby-step" approach, which applies to all x ∈ [1, 2...]. α ] of (x, g x Stored in a lookup table M In the middle; and at most 2 β A “giant step”, in which α + β = n In order to restore c = g x The discrete logarithm, which will be calculated in large steps as g 2α Initialize counter i → 0, and check M Does c / g exist in it? i2α If the search is successful: return x + i ・ 2 α Otherwise, increment i and repeat the search. This algorithm has... O (2 α Storage, and in the worst case, it requires 2 β Multiple multiplications (elliptic curve point additions) can be amortized as needed. In various exemplary aspects of TAP, n = 37 can be considered, that is, at most 2^n * n* is needed to support a range of up to 100 billion with 2 decimal places. 37A space of values. When a bank needs to decrypt encrypted "ElGamal" or other "ciphertext" from a smart contract, in several ways, the bank needs to map x to g as described in this article. x .

[0135] Broadly speaking, a cloud-based computing environment is a resource that typically combines large groups of processors (e.g., within a web server) with computing power and / or large groups of computer memory or storage devices with storage capacity. Systems providing cloud-based resources may be available only to their owners, or such systems may be accessible to external users who deploy applications within the computing infrastructure to benefit from large computing or storage resources.

[0136] For example, a cloud consists of a network of web servers comprising multiple computing devices (such as host 4002), where each server 4030 (or at least several) provides processor and / or storage resources. These servers manage workloads provided by multiple users (e.g., cloud resource customers or other users). Typically, each user's workload requirements for the cloud change in real time, sometimes dramatically. The nature and extent of these changes usually depend on the type of business associated with the user.

[0137] It is worth noting that any hardware platform suitable for performing the processes described herein is suitable for use with the technology. As used herein, the terms "computer-readable storage medium" and "computer-readable storage media" refer to any one or more media that participate in providing instructions to the CPU for execution. Such media can take many forms, including but not limited to non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical discs or magnetic disks, such as fixed disks. Volatile media include dynamic memory, such as system RAM. Transmission media include coaxial cables, copper wires, and optical fibers, which include conductors including one side of a bus. Transmission media can also take the form of acoustic or optical waves, such as acoustic or optical waves generated during RF and infrared data communications. Common forms of computer-readable media include, for example, floppy disks, hard disks, magnetic tapes, any other magnetic media, CD-ROMs, DVDs, any other optical media, any other physical media with markings or perforation patterns, RAM, PROMs, EPROMs, EEPROMs, FLASH EPROMs, any other memory chips or data exchange adapters, carrier waves, or any other media from which a computer can read them.

[0138] Various forms of computer-readable media can participate in loading one or more sequences of one or more instructions to the CPU for execution. A bus carries data to system RAM, from which the CPU fetches and executes instructions. Instructions received from system RAM may optionally be stored on a fixed disk before or after execution by the CPU.

[0139] Computer program code used to perform operations on various aspects of this technology can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" programming language, Go, Python, or other programming languages, including assembly language. The program code can execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer via any type of network, including LANs or WANs, or can connect to an external computer (e.g., via the Internet using an Internet service provider).

[0140] Examples of methods according to various aspects of this disclosure are provided in the following numbered clauses. An aspect of the method may include any one or more of the numbered clauses described below, and any combination thereof.

[0141] Clause 1. In one aspect, this disclosure provides a method for a payment network system to transfer multiple deposit tokens, the method comprising: settling inter-chain transfers between a first token contract on a first blockchain and a second token contract on a second blockchain while preserving privacy, using an interoperable two-phase commit protocol and a relay node, the protocol comprising: receiving, via the relay node, information about the transaction including the amount to be transferred, a sender identifier, a sender's bank identifier, a receiver identifier, and the receiver's bank identifier, and a sender's signature, from a first bank belonging to the first blockchain; providing, via the relay node, information about the transaction including the amount to be transferred, the sender identifier, the sender's bank identifier, the receiver identifier, and the receiver's bank identifier, to a second bank belonging to the second blockchain; and receiving, via the relay node, the receiver's signature from the second bank belonging to the second blockchain.

[0142] Clause 2. The method according to Clause 1, wherein the protocol further includes invoking a prepare-to-destroy function and verifying the sender's signature.

[0143] Clause 3. The method according to any one of Clauses 1 to 2, wherein in several aspects, the protocol further includes invoking a pre-casting function and verifying the signature of the recipient.

[0144] Clause 4. The method according to any one of Clauses 1 to 3, wherein the protocol further includes invoking a commit destruction function, wherein the commit destruction function ultimately determines the destruction invoked in the prepare destruction function.

[0145] Clause 5. The method according to any one of Clauses 1 to 4, wherein in many respects the protocol further includes invoking a submit casting function, wherein the submit casting function ultimately determines the casting invoked in the prepare casting function.

[0146] Clause 6. The method according to any one of Clauses 1 to 5, wherein in many respects the agreement further includes sending confirmation messages to the first bank and the second bank, wherein the confirmation messages confirm that the transfer has been completed.

[0147] Clause 7. The method according to any one of Clauses 1 to 6, wherein the agreement further includes an auditor who optionally performs an audit to verify the integrity of the first bank, the second bank, and the payment network system.

[0148] Clause 8. A non-transitory computer-readable medium storing instructions that, when executed, perform a method on a client device initiating a token transfer transaction, the method comprising: receiving user input including input transaction information; generating a digital transaction information message based at least on the input transaction information, wherein the digital transaction information message includes at least one of a transfer amount, a sender's identifier, a receiver's identifier, a sender's bank's identifier, a receiver's bank's identifier, or a random variable; generating another digital message including at least one of the sender's identifier, the transfer amount, or a combination thereof; digitally signing the other digital message to generate a digital signature message; and sending a first data packet including at least one of the digital transaction information message or the digital signature message to a relay node to facilitate a transaction with a second bank server.

[0149] Clause 9. The non-transient computer-readable medium as described in Clause 8, wherein the method further includes receiving confirmation of transaction completion from the relay node.

[0150] Clause 10. The non-transient computer-readable medium according to Clauses 8 to 9, wherein the method further comprises displaying an executable notification on the client device, wherein the executable notification includes at least one of the following interactive options: an option to retry the transaction if the transaction fails, an option to initiate a new transaction, or an option to repeat the transaction.

[0151] Clause 11. A system for facilitating blockchain transactions, comprising: a Payment Network Server Hub (PNS Hub); a plurality of bank servers connected to the PNS Hub; and an audit server connected to the PNS Hub; wherein the PNS Hub includes a deposit tokenization sandbox for: connecting to the plurality of bank servers; receiving a data packet from a first bank server (FB server) among the plurality of bank servers, wherein the FB server belongs to a first bank and is associated with a first blockchain, the data packet including transaction information and a digital signature message; encrypting at least a portion of the transaction information using an encryption key of the first bank server; generating a first new digital message based on the data packet; verifying a digital signature of the first bank digital signature message; and, based on the verification, sending at least a portion of the transaction information to a second bank server among the plurality of bank servers, wherein the second bank server belongs to a second bank and is associated with a second blockchain.

[0152] Clause 12. The system according to Clause 11, wherein the system includes a first bank server (FB server) of the plurality of bank servers, configured to: generate a digital transaction message by the FB server of the first bank, wherein the FB server is associated with the first bank, a first client account of a first user, and a first blockchain, wherein the digital transaction message includes at least one of a transaction amount, an identifier of the first client account, an identifier of a second client account of a second user of a second bank, an identifier of the first bank, an identifier of the second bank, or a random variable; digitally sign another message including at least the identifier and the transfer amount to generate a first bank digital signature message; and send a first data packet including at least one of the digital transaction message or the first bank digital signature message to the PNS hub.

[0153] Clause 13. The system according to Clauses 10 to 12, wherein the system includes a second bank server among the plurality of bank servers, configured to: receive at least a portion of the transaction information by the second bank server (SB server), wherein the SB server is associated with the second bank; verify the compliance of the at least a portion of the transaction information by the SB server; sign the second bank message to generate a digitally signed second bank message, the second bank message including at least one of an identifier of a second client account, an identifier of the SB server, or a transfer amount; and send the digitally signed second bank message to the PNS hub.

[0154] Clause 14. The system according to Clauses 10 to 13, wherein the PNS hub includes a deposit tokenization sandbox for: receiving a second bank digital signature message from an SB server; generating a second new digital message based on at least one of the transaction information from the data packet or the second bank digital signature message; invoking a prepare-to-destroy function based on a first input including at least one of the first new digital message or the first bank digital signature message; invoking a prepare-to-mint function based on a second input including at least one of the second new digital message or the second bank digital signature message upon receiving confirmation; performing a token destruction function upon receiving another confirmation from the SB server; performing a token minting function upon receiving a successful token destruction confirmation from the token destruction function; and sending a confirmation message to at least one of the FB server or the SB server upon receiving a successful token minting confirmation from the token minting function.

[0155] Clause 15. The system described in Clauses 10 to 14 further includes an audit server for determining whether a destruction certificate from at least one of the first bank or the second bank matches the encrypted balance sheet.

[0156] Clause 16. In all respects, the system according to Clauses 10 to 15, wherein the prepared destruction function includes instructions for: verifying the signature of the first bank's digital signature message against the first input; deducting the transaction amount from the first bank's first account based on the verification; registering the addition of the transaction amount to a first pending digital token balance associated with the first bank; and setting an expiration time, the expiration time being set to rescind the token transfer if no confirmation is received by the PNS hub within the expiration time.

[0157] Clause 17. In all respects, the system according to Clauses 10 to 16, wherein the prepared minting function includes instructions for: verifying the signature of the second bank against the second input; and, based on the verification, registering the addition of the transaction amount to a second pending digital token balance associated with the second bank.

[0158] Clause 18. In all respects, the system according to Clauses 10 to 17, wherein the token destruction function includes instructions for: determining that the current timestamp is less than the expiration time; deducting the transaction amount from the first pending digital token balance based on the determination; and generating a confirmation indicating successful token destruction, the confirmation being receivable by the PNS hub.

[0159] Clause 19. In all respects, the system according to Clauses 10 to 18, wherein the token destruction function includes instructions for: determining that the current timestamp is not less than the expiry time; based on the determination, transferring the transaction amount from the first pending digital token balance to a first client account; and generating a failed token destruction confirmation, the failed token destruction confirmation being received by the PNS hub.

[0160] Clause 20. In all respects, the system according to Clauses 10 to 19, wherein the token minting function includes instructions for: determining that the current timestamp is less than the expiry time; based on the determination, transferring the transaction amount from the second pending digital token balance to the second client account of the second user of the second bank; and generating a confirmation indicating successful token minting, the confirmation being receivable by the PNS hub.

[0161] Clause 21. In all respects, the system according to Clauses 10 to 20, wherein the token minting function includes instructions for: determining that the current timestamp is not less than the expiry time; deducting the transaction amount from the second pending digital token balance based on the determination; and generating an indication of failed token minting, which may be received by the PNS hub.

[0162] The foregoing detailed description has illustrated various forms of systems and / or processes using block diagrams, flowcharts, and / or examples. Those skilled in the art will understand that each function and / or operation within such block diagrams, flowcharts, and / or examples can be implemented individually and / or collectively by a wide range of hardware, software, firmware, or virtually any combination thereof, provided that such block diagrams, flowcharts, and / or examples contain one or more functions and / or operations. Those skilled in the art will recognize that some aspects of the forms disclosed herein can be implemented, in whole or in part, equivalently in an integrated circuit as one or more computer programs (e.g., one or more programs running on one or more computer systems), one or more programs running on one or more processors (e.g., one or more programs running on one or more microprocessors), firmware, or virtually any combination thereof, and that designing circuit systems and / or writing code for software and / or firmware according to this disclosure will be entirely within the skill of those skilled in the art. Furthermore, those skilled in the art will understand that the mechanisms of the subject matter described herein are capable of being distributed as one or more program products in various forms, and will understand that the illustrative form of the subject matter described herein applies regardless of the specific type of signal-bearing medium used to actually perform the distribution.

[0163] Instructions for programming logic to execute various disclosed aspects may be stored in the system's memory, such as dynamic random access memory (DRAM), cache, flash memory, or other memory. Furthermore, instructions may be distributed via a network or by means of other computer-readable media. Therefore, machine-readable media may include any means for storing or transmitting information in a machine-readable (e.g., computer-readable) form, but are not limited to floppy disks, optical disks, compressed optical disks, read-only memory (CD-ROM) and magneto-optical disks, read-only memory (ROM), random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic cards or optical cards, flash memory, or tangible machine-readable storage devices for transmitting information via the Internet via electrical, optical, acoustic, or other forms of propagation signals (e.g., carrier waves, infrared signals, digital signals, etc.). Therefore, non-transient computer-readable media include any type of tangible machine-readable medium suitable for storing or transmitting electronic instructions or information in a machine-readable (e.g., computer-readable) form.

[0164] Any software component or function described in this application may be implemented as processor-executable software code using, for example, conventional or object-oriented techniques, in any suitable computer language (e.g., Python, Java, C++, or Perl). The software code may be stored as a series of instructions or commands on a computer-readable medium, such as RAM, ROM, magnetic media (e.g., hard disk or floppy disk), or optical media (e.g., CD-ROM). Any such computer-readable medium may reside on or within a single computing device, and may exist on different computing devices or within a system or network.

[0165] As used in any aspect of this document, the term "logic" may refer to an application, software, firmware, and / or circuit system configured to perform any of the foregoing operations. Software may be embodied as a software package, code, instructions, instruction sets, and / or data recorded on a non-transitory computer-readable storage medium. Firmware may be embodied as hard-coded (e.g., non-volatile) code, instructions, or instruction sets and / or data in a memory device.

[0166] As used in any aspect of this document, the terms “component,” “system,” “module,” etc., can refer to computer-related entities, namely hardware, a combination of hardware and software, software, or software in execution.

[0167] As used in any aspect of this document, "algorithm" refers to a self-consistent sequence of steps that produce a desired result, where "step" refers to the manipulation of physical quantities and / or logical states, which may (though not necessarily) take the form of electrical or magnetic signals capable of being stored, transmitted, combined, compared, and otherwise manipulated. These signals are typically referred to as bits, values, elements, symbols, characters, items, numbers, etc. These and similar terms may be associated with appropriate physical quantities and are merely convenient labels applied to these quantities and / or states.

[0168] The network may include a packet-switched network. Communication devices may be able to communicate with each other using selected packet-switched network communication protocols. An example communication protocol may include an Ethernet communication protocol that may allow communication using Transmission Control Protocol / Internet Protocol (TCP / IP). The Ethernet protocol may conform to or be compatible with the Ethernet standard entitled "IEEE 802.3 Standard" and / or subsequent versions of this standard, published by the Institute of Electrical and Electronics Engineers (IEEE) in December 2008. Alternatively or additionally, communication devices may be able to communicate with each other using the X.25 communication protocol. The X.25 communication protocol may conform to or be compatible with standards issued by the International Telecommunication Union-Telecommunication Standardization Sector (ITU-T). Alternatively or additionally, communication devices may be able to communicate with each other using the Frame Relay communication protocol. Frame Relay communication protocols may conform to or be compatible with standards issued by the Consultative Committee for International Telegraph and Telephone (CCITT) and / or the American National Standards Institute (ANSI). Alternatively or additionally, transceivers may communicate with each other using Asynchronous Transfer Mode (ATM) communication protocols. ATM communication protocols may conform to or be compatible with the ATM standard entitled "ATM-MPLS Network Interworking 2.0" published by the ATM Forum in August 2001 and / or subsequent versions of this standard. Of course, this document also considers different and / or back-end connectivity network communication protocols.

[0169] Unless explicitly stated in the foregoing disclosure, it should be understood that throughout this disclosure, the use of terms such as “processing,” “computing,” “operation,” “determining,” “displaying,” etc., refers to the actions and processes of a computer system or similar electronic computing device that manipulate data represented as physical (electronic) quantities in computer system registers and memories and transform them into other data similarly represented as physical quantities in computer system memories or registers or other such information storage, transmission, or display devices.

[0170] One or more components may be referred to herein as “configured to,” “configurable to,” “operable as,” “suitable for,” “capable of,” “compliant to,” etc. Those skilled in the art will recognize that, unless the context otherwise requires, “configured to” can generally encompass active state components and / or inactive state components and / or standby state components.

[0171] Those skilled in the art will recognize that, in general, the terms used herein, and especially in the appended claims (e.g., the body of the appended claims), are typically intended as “open-ended” terms (e.g., the term “including” should be interpreted as “including but not limited to”, the term “having” should be interpreted as “having at least”, the term “includes” should be interpreted as “includes but is not limited to”, etc.). Those skilled in the art will further understand that if a particular number of the introduced claim statements are intended, then such intent will be expressly stated in the claims, and where no such statements are present, such intent does not exist. For example, to aid understanding, the appended claims may contain the use of the introductory phrases “at least one” and “one or more” to introduce the claim statements. However, the use of such phrases should not be construed as meaning that introducing a claim statement with the indefinite article "a(a)" or "an" limits any particular claim containing this introduced claim statement to containing only one of these statements, even when the same claim includes the introductory phrase "one or more" or "at least one" and an indefinite article such as "a(a)" or "an" (e.g., "a(a)" and / or "an" should generally be interpreted as meaning "at least one" or "one or more"); the same applies to the use of definite articles for introducing a claim statement.

[0172] Furthermore, even when a specific number is explicitly stated in the introduced claims, those skilled in the art will recognize that such a statement should generally be interpreted as meaning at least the stated number (e.g., the simple statement "two statements" without other modifiers generally means at least two statements, or two or more statements). Moreover, in these cases where conventions such as "at least one of A, B, and C" are used, generally, those skilled in the art will understand the meaning of the convention and anticipate such a construction (e.g., "a system having at least one of A, B, and C" will include, but is not limited to, systems having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). In these cases where conventions such as "at least one of A, B, or C" are used, generally, such a construction is intended to be carried out in the meaning of the convention that those skilled in the art will understand (e.g., "a system having at least one of A, B, or C" will include, but is not limited to, systems having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). Those skilled in the art will further understand that, generally, unless the context otherwise indicates, separate words and / or phrases presenting two or more alternative terms, whether in the specification, claims, or drawings, should be understood to include the possibility of including one term, either term, or both terms. For example, the phrase "A or B" will generally be understood to include the possibility of including "A" or "B" or "A and B".

[0173] Regarding the appended claims, those skilled in the art will understand that the operations described herein can generally be performed in any order. Furthermore, although the various operation flowcharts are presented in a sequence(s), it should be understood that the various operations can be performed in any order other than those shown, or can be performed simultaneously. Examples of such alternative orderings may include overlapping, interleaving, interrupted, reordered, ascending, preparatory, supplementary, simultaneous, inverted, or other varied orderings, unless the context otherwise specifies. Unless the context otherwise specifies, terms such as “in response to,” “related to,” or other past tense adjectives are generally not intended to exclude such variations.

[0174] It is worth noting that any reference to "an aspect," "one aspect," "an example," "an example," etc., means that a particular feature, structure, or characteristic described in connection with said aspect is included in at least one aspect. Therefore, the phrases "in an aspect," "in one aspect," "in an example," and "in an example" appearing throughout the specification do not necessarily all refer to the same aspect. Furthermore, a particular feature, structure, or characteristic may be combined in one or more aspects in any suitable manner.

[0175] As used herein, unless the context clearly indicates otherwise, the singular forms “a”, “an”, and “the” include plural referents.

[0176] Any patent application, patent, non-patent publication, or other disclosure cited in this specification and / or listed in any application data sheet is incorporated herein by reference so that the incorporated material is not inconsistent with it. Therefore, and to the extent necessary, any conflicting material incorporated by reference as expressly set forth herein supersedes any conflicting material. It is claimed that any material or portion thereof incorporated herein by reference that conflicts with existing definitions, statements, or other disclosures set forth herein will be incorporated only to the extent that the incorporated material does not conflict with existing disclosures. This is not an admission that they are prior art.

[0177] In summary, the numerous benefits arising from adopting the concepts described herein have been described. One or more forms of the foregoing description have been presented for illustrative and descriptive purposes. They are not intended to be exhaustive or limited to the precise forms disclosed. Modifications or variations are possible in light of the foregoing teachings. The aforementioned forms have been chosen and described to illustrate principles and practical applications, thereby enabling those skilled in the art to utilize the various forms and make various modifications suitable for the particular application contemplated. The claims filed herein are intended to define the overall scope.

Claims

1. A method for a payment network system to transfer multiple deposit tokens, the method comprising: Using an interoperable two-phase commit protocol and relay nodes, inter-chain transfers are settled between a first token contract on a first blockchain and a second token contract on a second blockchain while ensuring privacy. The protocol includes: The relay node receives information about the transaction, including the amount to be transferred, sender identifier, sender's bank identifier, receiver identifier, and receiver's bank identifier, as well as the sender's signature, from the first bank belonging to the first blockchain. The relay node provides a second bank belonging to the second blockchain with information about the transaction, including the amount to be transferred, the sender's identifier, the sender's bank identifier, the receiver's identifier, and the receiver's bank identifier; and The recipient's signature is received from the second bank, which belongs to the second blockchain, via the relay node.

2. The method of claim 1, wherein the protocol further includes invoking a prepare-to-destroy function and verifying the sender's signature.

3. The method of claim 2, wherein the protocol further includes invoking a prepare casting function and verifying the recipient's signature.

4. The method of claim 3, wherein the protocol further includes calling a commit destruction function, wherein the commit destruction function ultimately determines the destruction called in the prepare destruction function.

5. The method of claim 4, wherein the protocol further comprises invoking a submit casting function, wherein the submit casting function ultimately determines the casting invoked in the prepare casting function.

6. The method of claim 5, wherein the protocol further includes sending a confirmation message to the first bank and the second bank, wherein the confirmation message confirms that the transfer has been completed.

7. The method of claim 6, wherein the agreement further comprises an auditor, who optionally performs an audit to verify the integrity of the first bank, the second bank, and the payment network system.

8. A non-transitory computer-readable medium storing instructions, which, when executed, perform a method on a client device initiating a token transfer transaction, the method comprising: Receive user input, including transaction information; Based at least on the input transaction information, a digital transaction information message is generated, wherein the digital transaction information message includes at least one of the following: transfer amount, sender identifier, receiver identifier, sender bank identifier, receiver bank identifier, or random variable. Generate another digital message, the other digital message including at least one of the sender's identifier, the transfer amount, or a combination thereof; Digitally sign the other digital message to generate a digitally signed message; as well as Send a first data packet to the relay node, including at least one of the digital transaction information message or the digital signature message, to facilitate a transaction with the second bank server.

9. The non-transient computer-readable medium of claim 8, wherein the method further comprises: Receive confirmation of transaction completion from the relay node.

10. The non-transient computer-readable medium of claim 9, wherein the method further comprises: An executable notification is displayed on the client device, wherein the executable notification includes at least one of the following interactive options: an option to retry the transaction if the transaction fails, an option to initiate a new transaction, or an option to repeat the transaction.

11. A system for facilitating blockchain transactions, comprising: Payment Network Server Hub (PNS Hub); Multiple bank servers connected to the PNS hub; An audit server connected to the PNS hub; The PNS hub mentioned above includes a deposit tokenization sandbox for: Connect to the multiple bank servers; Data packets are received from a first bank server (FB server) among the plurality of bank servers, wherein the FB server belongs to the first bank and is associated with the first blockchain, and the data packets include transaction information and digital signature messages; At least a portion of the transaction information is encrypted using the encryption key of the first bank server; A first new digital message is generated based on the data packet; Verify the digital signature of the First Bank's digital signature message; as well as Based on the verification, at least a portion of the transaction information is sent to a second bank server among the plurality of bank servers, wherein the second bank server belongs to a second bank and is associated with a second blockchain.

12. The system according to claim 11, comprising the first bank server (FB server) among the plurality of bank servers, for: A digital transaction message is generated by the FB server of the first bank, wherein the FB server is associated with the first bank, the first client account of the first user, and the first blockchain, wherein the digital transaction message includes at least one of the following: transfer amount, identifier of the first client account, identifier of the second client account of the second user of the second bank, identifier of the first bank, identifier of the second bank, or random variable. Digitally sign another message that includes at least the identifier and the transfer amount to generate a first bank digital signature message; and Send a first data packet to the PNS hub, including at least one of the digital transaction message or the first bank digital signature message.

13. The system according to claim 11, comprising a second bank server among the plurality of bank servers, for: The transaction information is received by the second bank server (SB server), wherein the SB server is associated with the second bank; The SB server verifies the compliance of at least a portion of the transaction information; A second bank message is signed to generate a digitally signed second bank message, the second bank message including at least one of the identifier of the second client account, the identifier of the SB server, or the transfer amount; as well as Send the digitally signed second bank message to the PNS hub.

14. The system of claim 11, wherein the PNS hub includes a deposit tokenization sandbox for: Receive the second bank's digital signature message from the SB server; A second new digital message is generated based on at least one of the transaction information from the data packet or the second bank digital signature message; The prepare-to-destroy function is invoked based on a first input including at least one of the first new digital message or the first bank digital signature message; Upon receiving confirmation, the prepare-to-cast function is invoked based on a second input including at least one of the second new digital message or the second bank digital signature message; Upon receiving another confirmation from the SB server, the token destruction function is executed; Upon receiving a successful token destruction confirmation from the token destruction function, the token minting function is executed. as well as Upon receiving a successful token minting confirmation from the token minting function, a confirmation message is sent to at least one of the FB server or the SB server.

15. The system of claim 14, further comprising an audit server, configured to: Determine that the destruction certificate from at least one of the first bank or the second bank matches the encrypted balance sheet.

16. The system of claim 14, wherein the prepare-to-destroy function includes instructions for: Verify the signature of the first bank's digital signature message against the first input; Based on the verification, the transaction amount is deducted from the first account of the first bank; Register the addition of the transaction amount in the first pending digital token balance associated with the first bank; and An expiration time is set, which is set to cancel the token transfer if no confirmation is received in the PNS hub within the expiration time.

17. The system of claim 14, wherein the preparation casting function includes instructions for: Verify the signature of the second bank against the second input; and Based on the verification, the addition of the transaction amount is registered in the second pending digital token balance associated with the second bank.

18. The system of claim 16, wherein the token destruction function includes instructions for: It is determined that the current timestamp is less than the expiration time; Based on the determination, the transaction amount is deducted from the first pending digital token balance; and Generate a confirmation indicating successful token destruction, which can be received by the PNS hub.

19. The system of claim 16, wherein the token destruction function includes instructions for: Ensure the current timestamp is not less than the expiration time; Based on the determination, the transaction amount will be transferred from the first pending digital token balance to the first client account; as well as A failure token destruction confirmation is generated, which can be received by the PNS hub.

20. The system of claim 16, wherein the token minting function includes instructions for: It is determined that the current timestamp is less than the expiration time; Based on the determination, the transaction amount is transferred from the second pending digital token balance to the second client account of the second user of the second bank; as well as Generate a confirmation indicating successful token minting, which can be received by the PNS hub.

21. The system of claim 16, wherein the token minting function includes instructions for: Ensure the current timestamp is not less than the expiration time; Based on the determination, the transaction amount is deducted from the second pending digital token balance; and Generate a confirmation indicating a failed token minting, which can be received by the PNS hub.

Images