WO2025072780A1 - Payment network system tokenized asset platforms - Google Patents

Abstract

There has been a rising interest in the tokenization of flat currencies among the public and private sectors. The latest trend is the interest of commercial banks in the tokenization of their fractional reserves on shared ledgers (e.g., blockchains) with the primary goal of achieving real-time interbank transfers. A payment network system can provide a comprehensive sandbox solution for commercial banks to tokenize its deposits on a blockchain of their choice while adhering to global standards to facilitate interbank transfers via their network. This technique can provide opportunities to employ advanced cryptographic techniques such as zero-knowledge proofs and atomic swaps for building an environment that would allow the payment network system to not only connect banks for real-time transfers but also provide value-added services such as fraud detection and credentials for bank deposits.

Description

TITLE

PAYMENT NETWORK SYSTEM TOKENIZED ASSET PLATFORMS

RELATED APPLICATIONS

[0001] This application claims priority to Greek Patent Application No. 20230100785, titled PAYMENT NETWORK SYSTEM TOKENIZED ASSET PLATFORMS, filed September 29, 2023, the disclosure of which is incorporated by reference in its entirety.

TECHNICAL FIELD

[0002] The following disclosure relates generally to a deposit tokenization technique (DTT) that can allow for a bank to tokenize its deposits on a blockchain while adhering to global standards developed by a Payment Network System (PNS), such as the one developed by Visa, for example, to facilitate interbank transfers. In various aspects, the disclosure describes payment network system tokenized asset platforms (TAP) and techniques.

BACKGROUND

[0003] The evolution of digital currencies has prompted a demand for tokenizing fiat currencies that run on blockchains. Four distinct types that have emerged are cryptocurrencies, stablecoins, central bank digital currencies (CBDCs), and tokenized bank deposits. Although, any form of digital cash that is controlled by a private cryptographic key is considered to be a digital currency. Despite the clear demand for tokenizing fiat currencies, there are still numerous questions on how it will play out. Furthermore, it is believed that the tokenization of fiat currencies is not possible if every bank, or country, pursues their own version of a tokenized deposit product. Rather, a global technique and standards for interoperability between bank tokens across the world is necessary for banks to lead the way on digitizing fiat currencies.

SUMMARY

[0004] In one aspect, the present disclosure provides a method for use by a payment network system to transfer a plurality of deposit tokens. The method can comprise utilizing an interoperable, two-phase commit protocol and a relay node to settle inter-chain transfers with privacy guarantees between a first token contract on a first blockchain and a second token contract on a second blockchain. The protocol can comprise receiving, via the relay node, from a first bank belonging to a first blockchain, information regarding a transaction comprising an amount to be transferred, a sending party identifier, a sending party’s bank identifier, a receiving party identifier, and a receiving party’s bank identifier, and a sending party’s signature; providing, via the relay node, to a second bank belonging to a second blockchain, information regarding the transaction comprising the amount to be transferred, the sending party identifier, the sending party’s bank identifier, the receiving party identifier, and the receiving party’s bank identifier; and receiving, via the relay node, from the second bank belonging to the second blockchain, a receiving party’s signature.

[0005] In numerous aspects, the protocol further comprises invoking a prepare burn function and verifying the sending party’s signature.

[0006] In several aspects, the protocol further comprises invoking a prepare mint function and verifying the receiving party’s signature.

[0007] In various aspects, the protocol further comprises invoking a commit burn function, wherein the commit burn function finalizes a burn that was invoked in the prepare burn function.

[0008] In many aspects, the protocol further comprises invoking a commit mint function, wherein the commit mint function finalizes a mint that was invoked in the prepare mint function.

[0009] In numerous aspects, the protocol further comprises sending a confirmation message to the first bank and the second bank, wherein the confirmation message confirms that a transfer has been completed.

[0010] In some aspects, the protocol further comprises an auditor optionally performing an audit to verify an honest behavior of the first bank, the second bank, and the payment network system.

[0011] In one aspect, the present 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 comprising receiving a user input comprising input transaction information; based on at least the input transaction information, generating a digital transaction info message, wherein the digital transaction info message comprises at least one of a transfer amount, an identifier of a sender, an identifier of a receiver, an identifier of a sender bank, an identifier of a receiver bank, or a randomness variable; generating another digital message comprising at least one of the identifier of the sender, the transfer amount, or combinations thereof; digitally signing the other digital message to generate a digital signed message; and sending a first data package comprising least one of the digital transaction info message or the digital signed message to a relay node to facilitate a transaction with a second bank server (SB server).

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

[0013] In many aspects the method further comprises displaying an actionable notification on the client device, wherein the actionable notification comprises an interactive option of at least one of an option to retry the transaction upon failure of the transaction, an option to initiate a new transaction, or an option to repeat the transaction.

[0014] In one aspect, the present disclosure provides a system for facilitating blockchain transactions. The system can comprise a payment network server hub (PNS hub), a plurality of bank servers connected to the PNS hub, and an auditor server connected to the PNS hub. The PNS hub can comprise a deposit tokenization sandbox to connect to the plurality of bank servers; receive a data package from a first bank server (FB server) of the plurality of bank servers, wherein the FB server is of a first bank, and associated with a first blockchain, the data package comprising transaction information and a digital signed message; encrypt at least one portion of the transaction information with an encryption key of the FB server; generate a first new digital message based on the data package; verify a digital signature of a first bank digital signed message; and based on the verification, transmit at least a portion of the transaction information to a second bank server (SB server) of the plurality of bank servers, wherein the SB server is of a second bank and associated with a second blockchain.

[0015] In several aspects, the system comprises the FB server of the plurality of bank servers to generate a digital transaction message, by the FB server of a first bank, wherein the FB server is associated with a first bank, a first client account of a first user, and a first blockchain, wherein the digital transaction message comprises 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 randomness variable; digitally sign another message comprising at least the identifier and the transfer amount to generate a first bank digital signed message; and send a first data package comprising least one of the digital transaction message or the first bank digital signed message to the PNS hub. [0016] In numerous aspects, the system comprises the SB server of the plurality of bank servers to receive, by the SB server, the at least portion of the transaction information, wherein the SB server is associated to the second bank; verify, by the SB server, compliance of the at least one portion of the transaction information; sign a second bank message, the second bank message comprising at least one of an identifier of a second client account, an identifier of the SB server, or a transfer amount to generate a digital signed second bank message; and send the digital signed second bank message to the PNS hub.

[0017] In various aspects, the PNS hub comprises a deposit tokenization sandbox to receive a second bank digital signed message from an SB server; generate a second new digital message based on at least one of the transaction information from the data package or the second bank digital signed message; invoke a prepare burn function based on first inputs comprising at least one of the first new digital message or the first bank digital signed message; upon receiving a confirmation, invoke a prepare mint function based on second inputs comprising at least one of the second new digital message or the second bank digital signed message; upon receiving another confirmation from the SB server; undertake a token burn function; upon receiving a successful token burn confirmation from the token burn function; undertake a token mint function; and upon receiving a successful token mint confirmation from the token mint function, send a confirmation message to at least one of the FB server or the SB server.

[0018] In many aspects, the system further comprises an auditor server to determine that a proof of burn from at least one of the first bank or the second bank matches an encrypted balance sheet.

[0019] In various aspects, the prepare burn function comprises instructions to verify a signature of the first bank digital signed message against the first inputs; based on the verifying, subtract the transaction amount from a first account with the first bank; register an addition of the transaction amount in a first pending digital token balance associated with the first bank; and set an expiry time, set to reverse a token transfer if a confirmation is not received by the PNS hub within the expiry time.

[0020] In some aspects, the prepare mint function comprises instructions to verify a signature of the second bank against the second inputs, and based on the verifying, register an addition of the transaction amount a second pending digital token balance associated with the second bank. [0021] In many aspects, the token burn function comprises instructions to determine that a current time stamp is less than an expiry time; based on the determination, subtract the transaction amount from the first pending digital token balance; and generate a confirmation indicating a successful token burn, the confirmation receivable by the PNS hub.

[0022] In several aspects, the token burn function comprises instructions to determine that a current time stamp is not less than an expiry time; based on the determining, transfer the transaction amount from the first pending digital token balance to a first client account; and generate a failed token burn confirmation receivable by the PNS hub.

[0023] In various aspects, the token mint function comprises instructions to determine that a current time stamp is less than an expiry time; based on the determination, transfer the transaction amount from the second pending digital token balance to a second client account of a second user of a second bank; and generate a confirmation indicating a successful token mint, the confirmation receivable by the PNS hub.

[0024] In numerous aspects, the token mint function comprises instructions to determine that a current time stamp is not less than an expiry time; based on the determining, subtract the transaction amount from the second pending digital token balance; and generate a confirmation indicating a failed token mint, the token mint receivable by the PNS hub.

BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0027] The systems disclosed herein have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the various aspects of the present disclosure so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein. [0028] FIG. 1 illustrates a deposit tokenization technique sandbox hosted by a Payment Network System, according to at least one aspect of the present disclosure.

[0029] FIG. 2 is an example bubble diagram of the deposit tokenization technique as disclosed by the Payment Network System, which displays the various connections between a hub and other digital currencies and deposit tokenization techniques, according to at least one aspect of the present disclosure.

[0030] FIG. 3 is a commercial bank balance sheet, which displays the deposit tokens representing a bank’s assets and liabilities, according to at least one aspect of the present disclosure.

[0031] FIG. 4 illustrates a deposit tokenization technique bridge protocol as hosted by the Payment Network System, according to at least one aspect of the present disclosure.

[0032] FIG. 5 illustrates an alternate aspect of the deposit tokenization technique bridge protocol as hosted by the Payment Network System, according to at least one aspect of the present disclosure.

[0033] FIG. 6 illustrates yet another deposit tokenization technique bridge protocol as hosted by the Payment Network System, according to at least one aspect of the present disclosure.

[0034] FIG. 7 illustrates a sandbox proposal disclosing a process in which banks and an auditor communicate through different bridges and functionalities, according to at least one aspect of the present disclosure.

[0035] FIG. 8 illustrates a sandbox proposal disclosing an alternate process in which banks and an auditor communicate through different bridges and functionalities, according to at least one aspect of the present disclosure.

[0036] FIG. 9 is a block diagram of a computer apparatus with data processing subsystems or components, according to at least one aspect of the present disclosure.

[0037] FIG. 10 is a diagrammatic representation of an example system that includes a host machine within which a set of instructions to perform any one or more of the methodologies discussed herein may be executed, according to at least one aspect of the present disclosure. [0038] FIG. 11 illustrates a flow diagram of a method to transfer a plurality of tokens, according to at least one aspect of the present disclosure.

[0039] FIG. 12 illustrates a flow diagram of a method for initiating and undertaking a token transfer transaction via a client device, according to at least one aspect of the present disclosure.

[0040] FIG. 13 illustrates one possible aspect of the architecture of systems and methods for deposit tokenization technique bridge protocol as hosted by the Payment Network System connected to multiple bank systems, according to at least one aspect of the present disclosure.

[0041] FIG. 14 illustrates an alternative aspect of the architecture of systems and methods for deposit tokenization technique bridge protocol as hosted by the Payment Network System connected to multiple bank systems, according to at least one aspect of the present disclosure.

[0042] FIG. 15 illustrates another alternative aspect of the architecture of systems and methods for deposit tokenization technique bridge protocol as hosted by the Payment Network System connected to multiple bank systems, according to at least one aspect of the present disclosure.

DESCRIPTION

[0043] The following disclosure may provide exemplary systems, devices, and methods for conducting a financial transaction and related activities. Although reference may be made to such financial transactions in the examples provided below, aspects are not so limited. That is, the systems, methods, and apparatuses may be utilized for any suitable purpose.

[0044] As part of an overall deposit tokenization technique, there can exist a need to transfer tokens across blockchains in an atomic way. Various aspects of the present disclosure are directed to techniques that enable commercial banks to perform inter-bank, inter-chain (e.g., inter-blockchain) transfers using a relay node managed by a Payment Network System while hiding the bank’s balance sheet data from other banks and the payment relay.

[0045] In one aspect, the present disclosure provides a two-phase commit protocol between two token contracts deployed on different blockchains, as well as a relay node (operated by the Payment Network System) to settle inter-chain transfers. As part of the Payment Network System deposit tokenization technique, aspects of the present disclosure enable the ability to transfer tokens across blockchains in an atomic way. This can provide the ability for commercial banks to perform inter-bank, inter-chain transfers using the Payment Network System relay node. In one aspect, the present disclosure provides an interoperability protocol between two blockchains with privacy guarantees as needed by the Payment Network System deposit tokenization technique requirements.

[0046] In one general aspect, the following disclosure relates to developing a system or technique that can fill the need for tokenization that allows a bank’s assets and liabilities to be held in the form of a deposit token, interoperability that allows the tokens to move in real time across many different banks and financial institutions, on-demand auditing through a third party that audits token supply for reserve requirements and solvency, and programmability that enforces policies on the movements, privacy, and more of deposit tokens.

[0047] As disclosed herein, one aspect of the proposed approach is the development of a deposit tokenization technique by the Payment Network System, such as Visa™, for example, that allows a bank to tokenize its deposits on a blockchain while adhering to global standards developed by the Payment Network System, such as the global standards developed by Visa™, for example, to facilitate interbank transfers. These standards can include one or more of the following: a blockchain agnostic design, a universal token contract, a universal bridge, real-time interbank transfers, and on-chain/off-chain programmability.

[0048] The system and techniques disclosed in one aspect of the present disclosure can generally involve three types of parties: a bank, a relay service, and an auditor, among others. The bank type entities are responsible for minting and burning tokens, making internal transfers, and authorizing incoming and outgoing transfers. The bank(s) can only see their balance sheet and the incoming transfer data from another bank. The relay service, or the Payment Network System, relays cross-chain transfers and offers value-added services (fraud checks, custody, directory service, etc.). The relay service can only see the transfer information, such as the amount, sender, receiver, time, source bank, and destination bank. Finally, the auditor verifies zero-knowledge (ZK) proofs coming from the relay service and obtains ground-truth data from the chains. The auditor can only see certain transfer information, such as, for example, that a transfer was > $10,000.00 US.

[0049] There are several types of zero-knowledge proofs that are disclosed herein and in the proceeding description paragraphs. Proof of Solvency (PoS) is a range proof that x > 0 and Enc(bal) > x > 0. Proof of Burn (PoB) is a proof that Burn TX was recorded on the sender chain. Proof of Mint (PoM) is a proof that the Mint TX was recorded on the sender chain. Proof of Equality (PoE) is a proof that the Burn and Mint TX have the same amount. Proof of Inclusion (Pol) is a proof that the Burn and Mint have been committed and confirmed.

[0050] As to include all necessary information for understanding the disclosed descriptions and figures, various entities, notation, and smart contract definitions and functionalities are provided below.

[0051] Entities. “Distributed Ledger Technology” (DLT) is a permissioned blockchain accessible only by a consortium and maintained by a consortium-approved set of validator nodes running Byzantine fault tolerance (BFT) consensus. Various DLTs may allow only one bank or financial entity, while other DLTs allow many banks. A “TokenContract” can be a smart contract deployed on DLT for each bank or financial institution (the term “bank as used herein” can denote any or all of these banks, institutions, and any servers, data centers, or computing systems belonging to or associated with them) to maintain tokenized deposits of its clients. A “party” is any entity of the system identifiable with an identity (e.g., a public key). These can include the following: (a) a “Bank” is the bank owning TokenContract; (b) a “Minter” is a bank-authorized entity with the ability to mint new tokens; (c) a “Client” is a client of the bank (e.g., an individual or a company with a deposit account, wherein a deposit account is also referred to as the liability of the Bank); (d) a “Payment Network System”, such as Visa™, for example, is a semi-trusted entity that acts as an intermediary between Banks and the Banks’ deployed smart contracts, and maintains a full read-only node for each DLT; (e) an “Auditor” is a trusted entity that has read-only access to the blockchains by maintaining either a full node or a list of clients, wherein it performs sporadic random audits by requesting proofs from banks and the Payment Network System in order to ensure honest behavior by all system entities in an optimistic approach.

[0052] Notation. A “[value]bank” is the encrypted value under the Bank’s key using a probabilistic, additively homomorphic encryption technique. An “r” is the randomness used to construct “[value]_bank.” A “C” is a smart contract address. “o_part_y(m)” is a party’s digital signature on a message, “m.” For a ZK proof “TT,” the Camenisch-Stadler notation is used as TT = {(w): R(x,w) = 1}(x), where “w” is some private witness for a public instance “x” and an NP-relation “R” such that R(x,w) = 1.

[0053] Smart contract definitions. In various embodiments, Smart or token contracts may be defined by the following contract fields. “[totalLiabilities]bank” is the sum of all client balances encrypted under the Bank’s key. “[totalSupply]bank” is the number of tokens in circulation encrypted under the Bank’s key. “Balances” can be is a dictionary in the form {party: ([bal_party]bank, [Outbal_party]bank, [I nbal_party]bank)} maintaining the token balance of each party, where party denotes the identity of the party, “bal_party” denotes its balance available for spending, and “Outbal_party” and “lnbal_party” denote the pending outgoing and incoming balances, respectively, which are in a locked state. “Minters” is the set of allowed minters. “Expiry” is a hard-coded value which denotes the maximum time (or number of blocks) after which the amounts in pending states are reverted if not confirmed by the Payment Network System. “Account” can be a record with the following attributes: “isl nitialized” and balance. A “lockKey” can be used when locking an account for concurrency. A “pendingPayment” can be a record with the following attributes: “BURN,” “INTERNALTRANSFER,” “EXTERNALBURN,” and “EXTERNALMINT.” A “client” can be an account associated with the pending payment type. An “amt” can be the payment amount. An “expiry” can denote the time (or the block number) to wait for confirmation by Relay of operations in a pending state. Such operations may not be subsequently reverted if not confirmed within this period. The “[totalSupply]bank” can be a number of tokens in circulation encrypted under the Bank’s key. A “name” can be the name of the token. A “symbol” can be the symbol of the token (e.g., a shorter version of the name). A “currencyType” can be the currency type of the token. A “bank” can be the address of the bank. A “relayer” can be the address of the relayer.

“Decimals” can be the number of decimals used to get its user representation. For example, if decimals equal 2, a balance of 505 tokens should be displayed to a user as 5.05 (505 / (10 *2)). A “prepareDuration” can denote the maximum time period (or the maximum number of blocks) to wait for confirmation by Relay of operations in a pending state. Such operations may be subsequently reverted if not confirmed within this period. A “lockDuration” can denote the maximum time period (or the maximum number of blocks) before a lock automatically expires on an account. “Accounts” can be list of Account records, effectively the balance sheet of the Bank’s clients. “pendingPayments” can be a list of pendingPayments in memory. An “isSeenBefore” can be list of txid that have already been used in a transaction.

[0054] Summary of Contract Functions. A “prepareBurn(client, [amt]bank, Obank)” decreases the client’s balance by “[amt]_bank” and increases client’s outgoing balance by the same amount. A “prepareMint(client, [amt]_bank, Obank)” increases the client’s incoming balance by “[amt]bank.” A “commitBurn(client, [amt]bank)” decreases the client’s outgoing balance by “[amt]bank.” A “commitMint(client, [amt]bank)” increases the client’s balance by “[amt]bank” and decreases clients incoming balance by the same amount. A “checkExpiryO” is a bookkeeping function, which reverts the above actions of prepareBurn and prepareMint if not confirmed by the respective functions within expiry. A “transferlnternal(sender, receiver, [amt]bank)” transfers tokens within the same contract. A “totalSupply(bank)” returns [totalSupply]bank. A “balanceOf(party)” returns [bal_party]bank.

[0055] Core Smart Contract Functionalities. A “mint(txid, client, [amt]bank)” can homomorphically add the “amt” to the encrypted balance of client. A “burn(txid, client, [amt]bank), o, lockKey” can homomorphically subtract the “amt” to the encrypted balance of client. A “transferlnternal(txid, sender, receiver, [amt]bank), o, lockKey” can transfer the “amt” from sender to receiver within the same contract. A “prepareBurn(txid, client, [amt]bank, o, lockKey)” can decrease a client’s balance by [amt]bank and add it to the list of pendingPayments. A “commitBurn(txid)” can finalize operation from prepareBurn(), depending on expiry status, and remove it from txlist. A “revertBurn(txid)” can revert operation from prepareBurn(), depending on expiry status, and remove it from txlist. A “prepareMint(m, o)” can add a transaction event in txlist. A “commitMint(txid)” can finalize operation from prepareMint(), depending on expiry status, and remove it from txlist. A “revertMint(txid)” can revert operation from prepareMint(), depending on expiry status, and remove it from txlist.

[0056] Smart Contract Functionalities. A “prepareMint(receiver, [amt]bank, o)” can (a) require caller = Payment Network System; and (b) add [amt]bank to [lnbal_Party]bank_receiver. A “commitMint(receiver, [amt]bank, o)” can (a) require caller = Payment Network System; (b) subtract [amt]bank from [lnbal_part_y]bank_receiver; (c) add [amt]bank to balanceOf( receiver); and (d) add [amt]bank to [totalSupply]bank. A “burn(sender, [amt]bank, IT)” can (a) require caller = bank; (b) verify TT to ensure that balanceOf(sender) > [amt]bank; (c) subtract [amt]b_ank from balanceOf(sender); and (d) subtract [amt]bank from [totalSupply]bank. A “transferlnternal(sender, receiver, [amt]bank, TTI , TT2)” can (a) require caller = bank; (b) verify TTI , TT2 to ensure that [amt]bank > 0 and balanceOf(sender) > [amt]bank; (c) subtract [amt]bank from balanceOf( receiver); and (d) Add [amt]_bank to balanceOf( receiver). An “addMinter(party)” can (a) require caller to be bank; and (b) add party to minters. A “removeMinter(party)” can (a) require caller to be bank; and (b) remove party from minters. A “sendCrossChain(Req, o)” can (a) require the caller be bank; (b) parse Req into (sender, receiver, bank_t0, [amt]_bank_to, chainlD); (c) invoke burn(sender, [amt]b_ank, TT); and (d) send to Payment Network System. A “receiveCrossChain(t, tx_crOss, [amt]bank_receiver, TTinc, TT2)” can (a) require the caller to be bank; (b) obtain a block header (bh, LCS) <- Cbnd_ge.GetHeader(t); (c) use TT_inc to verify if tx_Cross is included in tx_cross; and (d) Invoke mint( receiver, [amt]bank_receiver, TT2).

[0057] Off-Chain Functionalities. A “CreateMintTx(receiver, amt)” can (a) encrypt amt into [amt]bank; (b) generate a NIZK proof TT proving that [amt]bank > 0; and (c) invoke Cmint(client, [amt]bank, TT). A “CreateBurnTx(sender, amt)” can (a) encrypt amt into [amt]bank; (b) generate a NIZK proof TT that proves that balanceOf(sender) - [amt]bank > 0; and (c) invoke C.mint(client, [amt]bank, TT). A “CreatelnternalTx(sender, receiver, amt)” can (a) encrypt sender and receiver into [amt]bank_sender and [amt]bank_receiver, respectively; (b) generate NIZK proofs, TTI, TT2 that prove that balanceOf(sender) - [amt]bank > 0 and [amt]bank > 0 respectively; and (c) invoke C. transferlnternal(sender, receiver, [amt]bank, TTI , TT2). A “sendCrossChainTXinit(sender, receiver, bank_t0, amt, chainlD)” can be invoked by Bank by sending an outbound request to the Payment Network System, and it can include (a) encrypt amt into [amt]_bank; and (b) send Req = (sender, receiver, bank_t0, [amt]bank_to, chainlD) and Obankjrom(Req) to the Payment Network System. A “sendCrossChainTXinitfwd(Req, o)” can be invoked by the Payment Network System on receipt of transaction request from sending Bank bank_from, and it can include (a) verify o; and (b) send (Req, bankf_rom, o) to bank_t0. A “rcvCrossChainTXinit(Req, bank_from, o)” can be invoked by bank_t0 on receipt of transaction request from the Payment Network System, and it can include (a) parse Req into (sender, receiver, bank_t0, [amt]bank_to, chainlD); (b) decrypt [amt]bank_to to amt; and (c) if o verification or [amt]bank decryption fails or if receiver belongs to a blacklist, send ((Req, NACK), Obank_to((Req, NACK))) to the Payment Network System, else send (ACK, Obankjo, ((Req, ACK))) to the Payment Network System. A “sendCrossChainTX(Req, o)” can include (a) generate NIZK TTI for amt e Req; and (b) invoke tx_cross = C. Additionally, “SendCrossChain(Req, TT, O)” can include o, where o signifies a digital signature and/or encryption of data.

[0058] The foregoing definitions and functionalities are applicable to the deposit tokenization technique discussed herein, though will be found most helpful for interpreting the bridge protocols as laid out in the aspects of FIGS. 1-15. Further, the specific details set forth below will help in the understanding of the disclosed figures and aspects.

[0059] FIG. 1 illustrates a deposit tokenization technique (DTT) sandbox hosted by a Payment Network System, according to at least one aspect of the present disclosure. The DTT sandbox 101 is in communication with a bank 102, e.g., a commercial bank or other financial institution (when referring to a “bank” herein, the disclosure includes in its meaning any computing systems; local, cloud, or enterprise networks; servers; mainframes; or other nodes used, owned by, or associated to the bank, where appropriate), which invokes application programming interfaces (APIs) via a username and password, and DTT interoperability services. The DTT sandbox 101 includes a set of DTT APIs 103, as well as tokenization services such as a tokenization provider 104, smart contact library 105, proof- of-reserve 106, and multi-chain manager 107. Furthermore, the DTT sandbox 101 includes a blockchain that includes a custodial master wallet for a bank and additional custodial wallets for a bank and business-to-business (B2B) clients. The key services that are under development by the Payment Network system are tokenization services and the DTT interoperability services, both which are encompassed by boxes in FIG. 1.

[0060] FIG. 2 is a simplified graphic of a deposit tokenization technique (DTT) 200 as disclosed by a Payment Network System, which displays the various connections between a hub 201 and other digital currencies and DTTs 202, according to at least one aspect of the present disclosure. For example, the Payment Network System (PNS) hub in FIG. 2 is in connection 203 with various central bank digital currencies, stablecoins, and DTTs, some which have been developed by the Payment Network System. It should be noted that the deposit tokenization techniques disclosed herein are not limited to the connections set forth in FIG. 2. In one general aspect, the deposit tokenization techniques disclosed herein can enable banks to tokenize their deposits on a blockchain, adhering to global standards to facilitate interbank transfers. In various aspects, the deposit tokenization techniques can provide chain agnostic design, universal token contracts, universal bridges, real-time interbank transfers, and/or on-chain and off-chain programmability.

[0061] FIG. 3 is a commercial bank balance sheet 300 that displays the deposit tokens representing a bank’s assets 301 and liabilities 302, according to at least one aspect of the present disclosure. In terms of the assets 301 , loans 303 take a majority of the space in the balance sheet 300, followed by liquid assets 304, which is then followed by cash 305 and commercial bank reserves 306 in equal parts. In terms of the liabilities 302, deposits 307 take a majority of the space in the balance sheet 300, followed by debt (or borrowed capital) 308 and equities 309 in equal parts.

[0062] FIG. 4 illustrates a bridge protocol 400 as hosted by a Payment Network System (PNS), according to at least one aspect of the present disclosure. In the disclosed aspect, Bank 1 401 , via Wallet Provider 1 403 and User 1 404, sends 411 TX Information and SigBanki to the PNS 410. The PNS 410 then provides 412 at least some of the received information from Bank 1 401 to Bank 2 402. In return, Bank 2 402 sends 413 SigBank2 to the PNS 410. A “prepare to burn” process 419 and a “prepare to mint” process 415 follows soon after and then the burn 416 and mint 417 processes are completed, followed by a confirmation with both Bank 1 and Bank 2. Finally, the PNS 410 is in communication with an auditor 420 that can make an audit at any point in the future.

[0063] In some aspects, the PNS completes a high-level transaction flow between two banks (or entities), which belong to, are associated with, or utilize two different blockchains, according to the following steps. [0064] First, Bank 1 401 (e.g., the bank initiating the transfer after a request from one of its clients) begins by completing the following tasks: (a) create the message txlnfo = {r, amt, (sender, banksender), (receiver, bankreceiver)}, which comprises transaction information, where r is randomness sampled by the sending bank, amt is the amount to be transferred, sender is the sending client who belongs to banksender, and receiver is the receiving client who belongs to bankreceiver; (b) sign the message ml <- (sender, [amt]bank_sender) to get o1 <- obank_sender(m1), i.e., signed, certified, and/or encrypted (ml), where [amt]bank_sender is the encrypted amount to be transferred using randomness r; and (c) send 411 (txlnfo, o1) to the PNS 410.

[0065] On receiving the tuple (txlnfo, Oi), the PNS 410 completes the following tasks: (a) encrypt the transfer amount with the sender bank encryption key, [amt]bank_sender <- Enc((txlnfo.amt, txlnfo. r), bank_sender); (b) construct a message r based on and comprising information from txlnfo, and/or verify Oi; (c) perform compliance/fraud checks for example for anti-money laundering, on txlnfo and/or Oi; and (d) send 412 (txlnfo) to Bank 2 402 (e.g., the bank that is receiving the payment). In various aspects, txlnfo is only transmitted or sent 412 to Bank 2 402 if the PNS 410 successfully verifies Oi and/or the results of compliance/fraud checks are successful and unproblematic. In some embodiments rm is constructed by the PNS 410 based on Oi and comprises (sender, [amt]bank_sender) while in other embodiments rm can comprise any information or combination of information derived from txlnfo and I or Oi. In several aspects, the message ml can be constructed/reconstructed using the information from txinfo as follows: txlnfo = {r, amt, (sender, banksender), (receiver, bankreceiver)} ml = (sender, [amt]bank_sender). Specifically, the payment network can reconstruct the ciphertext [amt]bank_sender using the randomness r from txlnfo.

[0066] On receiving (txlnfo) from the PNS 410, the receiver bank 402 completes the following tasks: (a) check the received transaction message for compliance (e.g., check against a client blacklist); (b) sign the message m₂ <- (receiver, [txlnfo. amt]bank_receiver) to get o₂ <- Obank_ receiver (m₂), where [amt]bank_ receiver denotes the encrypted amount to be received; and (c) send 413 (o₂) to the PNS 410.

[0067] On receiving the pair (o₂), from the receiver bank 402, the PNS 410 completes the following tasks: (a) [amt]_bank_receiver <- Enc((txlnfo.amt, txlnfo. r), bank receiver) ; (b) construct m₂ based on information from txlnfo and I or o₂, and/or verifies o₂; and (c) invoke 414 tXprepareBum <- Csender. prepareBurn(mi , Oi), where prepareBurn function 414 checks the bank’s 401 signature against the inputs, [amt]bank_sender is subtracted from balanceOf(sender) and notes it as pending burn, and an expiry time, burnExpiry, is set to reverse the burn if a confirmation is not received. [0068] On receiving confirmation on tXprepareBum, the PNS 410 invokes 415 tx_Pre_PareMint <- Creceiver.prepareMint(m2, 02), where prepareMint function 415 checks the bank’s 402 signature against the inputs and [amt]bank_receiver is added to a pending incoming balance 435.

[0069] On receiving confirmation on tx_prepareMint, the PNS 410 invokes 414 txcommitBum <- Csender.commitBurnO, where commitBurn function 414 finalizes a burn that was invoked in tXprepareBum, ensures that the current time stamp is less than expiry, and if the time stamp is satisfied, subtract [amt]bank_sender from pending burn. Otherwise, subtract [amt]bank_sender from pending burn and add it back to balanceOf(sender).

[0070] On receiving confirmation on tx_commitBum, the PNS 410 invokes tx_COmmitMint <- Creceiver.commitMintO, where commitMint function 415 finalizes a mint that was invoked in tXcommitMint, ensures that the current time stamp is less than expiry, and if the time stamp is satisfied, subtract [amt]bank_receiver from pending incoming balance and add it to balanceOf( receiver). Otherwise, subtract [amt]bank_sender from pending incoming balance.

[0071] On receiving confirmation on tx_commitMint, the PNS 410 sends 419 a confirmation message on completing the transfer to both banks 401 , 402.

[0072] After the transaction is finalized and its respective elements recorded on the blockchains, the auditor 420 at any point in the future can optionally make the following audits 419 for some time stamp/block in a reactive fashion to verify the honest behavior of banks and the PNS 410: (a) PoB (from banks): TTb = {(r, amt): amt > 0 A bal_sender s amt}([amt]bank, [bal_sender]bank, bank), where balsender is the sending client’s balance in the bank reflected in the balance sheet in encrypted format as [bal_sender]bank (this proves that the amount burned in non-negative and that the leftover amount in the sender’s balance is not negative); and (b) PoE (from the PNS): TT₆ = {(r, amt)}([amt]_bank__sender, [amt]bank_receiver, banksender, bankreceiver), which proves that the same amount was encrypted in both burn and mint operations.

[0073] FIG. 5 illustrates a deposit tokenization technique (DTT) bridge protocol 500 as hosted by a Payment Network System (PNS) 510, according to at least one aspect of the present disclosure. In the disclosed aspect, Bank 1 501 , via Wallet Provider 1 503 and User 1 504, sends 511 TX Information, SigBanki, and PoB to the PNS 510. The PNS 510 then provides 512 at least some of the received information from Bank 1 501 to Bank 2 502. In return, Bank 2 502 sends 513 SigBank2 to the PNS 510. A prepare to burn 514 and prepare to mint 515 process follows soon after, which also includes setting an expiry, and then the burn 516 and mint 517 processes are completed. Confirmation with both Bank 1 501 and Bank 2 502 occurs soon after. Finally, the PNS 510 is in communication with an auditor 520 that can make an audit at any point in the future, most namely zero-knowledge (ZK) proofs 519 Proof of Equality (PoE), Proof of Burn (PoB), and Proof of Inclusion (Pol) of burn and mint.

[0074] The following can apply to the DTT described in FIG. 5:

[0075] Optimistic Zether: All ZK verifications originally done by the contract are now done off-chain by the auditor sporadically;

[0076] PoB: A ZK range proof that x > 0 and Enc bal)> x>0;

[0077] PoE: A ZK proof that 3x,r_1,r_2 s.t., E_1=Enc_1 (x,r_1), E_2= Enc_2 (x,r_2 ,

[0078] Prepare Burn: Checks solvency; and

[0079] Prepare Mint: Check supply/liability requirements to receive liability.

[0080] FIG. 6 illustrates a deposit tokenization technique (DTT) bridge protocol 600 as hosted by a PNS 610, according to at least one aspect of the present disclosure. In the disclosed aspect, Bank 1 601 , via Wallet Provider 1 603 and User 1 604, sends 611 TX Information, SigBanki, an expiry, and Proof of Burn (PoB) to the PNS 610. The PNS 610 then provides 612 at least some of the received information from Bank 1 601 to Bank 2 602. In return, Bank 2 602 sends 613 SigBank2 to the PNS 610. A prepare to burn and prepare to mint process follows soon after, which also includes the expiry, and then the burn 614 and mint 615 processes are completed. The PNS 610 is then in communication with an auditor 620 that can make an audit at any point in the future, most namely zero-knowledge (ZK) proofs Proof of Equality (PoE), Proof of Burn (PoB), and Proof of Inclusion (Pol). Although, unlike the disclosures set forth in FIG. 4 and FIG. 5, the auditor also receives information from the token contract 625 of Bank 1 601 as well as from the PNS 610.

[0081] The following can apply to the DTT described in FIG. 6:

[0082] Optimistic Zether: All ZK verifications originally done by the contract are now done off-chain by the auditor sporadically;

[0083] PoB: A ZK range proof that x > 0 and Enc(baZ)> x>0; and

[0084] PoE: A ZK proof that 3x,r_1 ,r_2 s.t. E_'\=Enc_'\ (x,r_1 ), E_2= Enc_2 (x,r_2 ).

[0085] FIG. 7 illustrates a sandbox proposal disclosing the process 700 in which a bank 701 and an auditor 720 communicate through different bridges and functionalities, according to at least one aspect of the present disclosure. The bank 701 is responsible for deploying the TokenContract 725 and sending a zero-knowledge Proof of Reserve (PoR) 703. The auditor 720 is responsible for verifying fiat reserves and signing the PoR. Moving forward, the TokenContract 725 verifies 726 the cross-DLT reserve before the UPC Contract 730 (cross-consortium bridge) and eventually the Reservecontract 735. There is also an on- chain bridge (atomic swap) 727. The central bank 740 is responsible for deploying the ReserveContract 735, which maintains and mints/burns central bank digital currencies. Any of these contracts 725, 730, 740 can have ledger and/or escrow functionalities and can serve as token or digital currency balance sheets.

[0086] The following can apply to the sandbox proposal described in FIG. 7: multiple banks in the same island, universal TokenContract or an ERC-20-like interface, and an interface that standardizes what is needed for cross-island transactions.

[0087] FIG. 8 illustrates a sandbox proposal disclosing an alternate process 800 in which banks 801, 840 and an auditor 820 communicate through different bridges and functionalities, according to at least one aspect of the present disclosure. In this aspect, the bank 801 is responsible for deploying the TokenContract 825 and sending a zero-knowledge Proof of Reserve (PoR) 803, while the central bank 840 is responsible for deploying the ReserveContract 839. The auditor 820 is responsible for verifying fiat reserves and signing 821 the PoR 803. Moving forward, the TokenContract 825 verifies 826 the central bank digital currency reserve before meeting the ReserveContract 839, which maintains and mints/burns central bank digital currencies. In this aspect, the UPC Contract 830 (crossconsortium bridge) is bypassed. In one aspect, the TokenContract 825 maintains a supply and balance sheet, mints/burns tokens, and verifies PoR. In one aspect, the ReserveContract 839 maintains CBDC reserves and mints/burns CBDC. In one aspect, permissioned blockchains avoids Sybil attacks and individual members still not trusted for integrity and privacy.

[0088] In various aspects, the s described herein in connection with FIGS. 1-8 and FIGS. 11-13 may be implemented on computer systems and distributed networks. In various aspects, the deposit tokenization techniques described herein in connection with FIGS. 1-8 and FIGS. 11-13 may be implemented in some aspects on a computer apparatus 3000, as shown in FIG. 9, and the example system 4000, as shown in FIG. 10.

[0089] FIG. 9 is a block diagram of a computer apparatus 3000 with data processing subsystems or components, according to at least one aspect of the present disclosure. The subsystems shown in FIG. 9 are interconnected via a system bus 3010. Additional subsystems such as a printer 3018, keyboard 3026, fixed disk 3028 (or other memory comprising computer-readable media), monitor 3022 (which is coupled to a display adapter 3020), and others are shown. Peripherals and input/output (I/O) devices, which couple to an I/O controller 3012 (which can be a processor or other suitable controller), can be connected to the computer system by any number of means known in the art, such as a serial port 3024. For example, the serial port 3024 or external interface 3030 can be used to connect the computer apparatus 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 the central processor 3016 to communicate with each subsystem and to control the execution of instructions from system memory 3014 or the fixed disk 3028, as well as the exchange of information between subsystems. The system memory 3014 and/or the fixed disk 3028 may embody a computer-readable medium.

[0090] FIG. 10 is a diagrammatic representation of an example system 4000 that includes a host machine 4002 within which a set of instructions to perform any one or more of the methodologies discussed herein may be executed, according to at least one aspect of the present disclosure. In various aspects, the host machine 4002 operates as a stand-alone device or may be connected (e.g., networked) to other machines. In a networked deployment, the host machine 4002 may operate in the capacity of a server or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The host machine 4002 may 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 telephone; a portable music player (e.g., a portable hard drive audio device such as an Moving Picture Experts Group Audio Layer 3 (MP3) player); a web appliance; a network router, switch, or bridge; or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

[0091] The example system 4000 includes the host machine 4002, running a host operating system (OS) 4004 on a processor or multiple processor(s)/processor core(s) 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 hypervisor 4010, which is able to control the functions and/or communicate with a virtual machine (VM) 4012 running on machine-readable media. The VM 4012 also may include a virtual CPU or vCPU 4014. The memory nodes 4008 may be linked or pinned to virtual memory nodes or vNodes 4016. When the memory node 4008 is linked or pinned to a corresponding vNode 4016, then data may be mapped directly from the memory nodes 4008 to their corresponding vNodes 4016.

[0092] All the various components shown in host machine 4002 may be connected with and to each other or communicate to each other via a bus (not shown) or via other coupling or communication channels or mechanisms. The host machine 4002 may further include a video display, audio device, or other peripherals 4018 (e.g., a liquid crystal display (LCD), alpha-numeric input device(s) including, e.g., a keyboard, a cursor control device, e.g., a mouse, a voice recognition or biometric verification unit, an external drive, a signal generation device, e.g., a speaker), a persistent storage device 4020 (also referred to as disk drive unit), and a network interface device 4022. The host machine 4002 may further include a data encryption module (not shown) to encrypt data. The components provided in the host machine 4002 are those typically found in computer systems that may be suitable for use with aspects of the present disclosure and are intended to represent a broad category of such computer components that are known in the art. Thus, the example system 4000 can be a server, minicomputer, mainframe computer, or any other computer system. The computer may also include different bus configurations, networked platforms, multiprocessor platforms, and the like. Various operating systems may be used, including UNIX, LINUX, WINDOWS, QNX ANDROID, IOS, CHROME, TIZEN, and other suitable operating systems.

[0093] The disk drive unit 4024 also may be a Solid-state Drive (SSD), a hard disk drive (HDD) or other that includes a computer- or machine-readable medium on which is stored one or more sets of instructions and data structures (e.g., data/instructions 4026) embodying or utilizing any one or more of the methodologies or functions described herein. The data/instructions 4026 also may reside, completely or at least partially, within the main memory node 4008 and/or within the processor(s)/processor core(s) 4006 during execution thereof by the host machine 4002. The data/instructions 4026 may further be transmitted or received over a network 4028 via the network interface device 4022 utilizing any one of several well-known transfer protocols (e.g., Hyper Text Transfer Protocol (HTTP)).

[0094] The processor(s)/processor core(s) 4006 and memory nodes 4008 also may comprise machine-readable media. The term “computer-readable medium” or “machine- readable medium” should be taken to include a single medium or multiple medium (e.g., a centralized or distributed database and/or associated caches and servers) that store the one or more sets of instructions. The term “computer-readable medium” shall also be taken to include any medium that is capable of storing, encoding, or carrying a set of instructions for execution by the host machine 4002 and that causes the host machine 4002 to perform any one or more of the methodologies of the present application, or that is capable of storing, encoding, or carrying data structures utilized by or associated with such a set of instructions. The term “computer-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals. Such media may also include, without limitation, hard disks, floppy disks, flash memory cards, digital video discs (DVD), random-access memory (RAM), read-only memory (ROM), and the like. The example aspects described herein may be implemented in an operating environment comprising software installed on a computer, in hardware, or in a combination of software and hardware.

[0095] FIG. 11 illustrates a flow diagram of a method 1100 to transfer a plurality of tokens from one account to another. Method 1100 may be used for inter-blockchain transfers between accounts belonging to different banks. In one embodiment, method 1100 may comprise receiving 1105, via a relay node, from a first bank belonging to a first blockchain, information regarding a transaction, such as a token transfer. This information can, in various embodiments, comprise any (or any combination of) of the following: an amount to be transferred (transaction amount), a sending party identifier, a sending party’s bank identifier, a receiving party identifier (including clients or client devices associated with the aforementioned users), a receiving party’s bank identifier, and a sending party’s signature. In many embodiments, method 1100 utilizes an interoperable, two-phase commit protocol and the relay node to settle inter-chain transfers with privacy guarantees between a first token contract on a first blockchain and a second token contract on a second blockchain. The protocol can comprise the processes outlined in method 1100.

[0096] Method 1100 can also include providing 1110, via the relay node, such as a payment network system as described above, to a second bank belonging to a second blockchain, information regarding the transaction, including, but not limited to, any of the following: the amount to be transferred, the sending party identifier, the sending party’s bank identifier, the receiving party identifier, and the receiving party’s bank identifier. Other information such as client identifiers (clients including applications, for example) or client device identifiers running a client, as well as bank account, credit card, application account, or other account information or identifiers, such as emails, usernames, IP addresses, and the like, could all be part of the transaction information in various embodiments of the rest of this disclosure, as well as in method 1100.

[0097] The method 1100 can also include receiving 1115, via the relay node, from the second bank belonging to the second blockchain, a receiving party’s signature. In various embodiments, the protocol of method 1100 can also comprise invoking a prepare burn function and verifying the sending party’s signature and invoking a prepare mint function and verifying the receiving party’s signature. In several aspects, any one of the prepare burn and mint functions depend on successful verifying of one or all the signatures. In several aspects, method 1100 can invoke a commit burn function.

[0098] The commit burn function finalizes a burn that was invoked in the prepare burn function and is generally based on a successful verification of the signatures. In any aspects, the method 1100 invokes a commit mint function, wherein the commit mint function finalizes a mint that was invoked in the prepare mint function. In various aspects, a burn refers to taking funds, tokens, or digital currency out of an account and/or out of circulation, while a mint refers to the creation of new coins, tokens, or digital currency and adding them to an account and/or to circulation. The tokens, digital coins, or currency burned or minted can be different or the same, and belong to the same or different blockchains, depending on the aspect.

[0099] A confirmation message can be sent upon either a successful or a failed transaction comprising sending a confirmation message to the first bank and the second bank, wherein the confirmation message confirms that a transfer has been completed, partially completed, or failed. Method 1100 can also include an auditor, auditor service, or server optionally performing an audit to verify an honest behavior of the first bank, the second bank, and the payment network system.

[0100] FIG. 12 illustrates a flow diagram of a method 1200 for initiating and undertaking a token transfer transaction via a client device. A token transfer transaction can be undertaken on a client application (also “client”) executed on a client or user device, for example, a mobile phone, computing device, or tablet. The client device may execute the 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 comprising receiving 1205 a user input that includes input transaction information, where the user input can include, but is not limited to, a username, email, phone number, transfer amounts, number of transactions, identity of recipients, a type of fund (for example, the type of token or digital currency/instrument), as well as IP information, blockchain information, sender account information for withdrawing funds, speed of transfer options or selections, and the like.

[0101] The method 1200 can also, in various aspects, comprise sending the received user input, a portion of the user input, or data associated to the user input (collectively referred to herein as “input transaction information”) to a bank server. The client itself may be running on the first bank server that directly or via the client receives the input transaction information derived from the user input. The client can then generate 1210 a digital transaction information message comprising at least one of the sender identifier (such as its name or a user name for an application), the sender client identifier (which could include a serial or unique identifying number, for example), the transfer amount (‘transfer amount’ as referred to herein can comprise the type of fund, for example, the specific currency or digital token to be transferred or utilized, as well as a quantity of the fund), or combinations thereof. Another message comprising a portion of the input transaction information can also be generated 1215.

[0102] Once a digital message is generated, the client application, via the bank server, can digitally sign 1220 the digital transaction information message to generate a digital signed message. The method 1200 can then continue to send 1225 a data package, such as a first data package comprising least one of the digital transaction message or the digital signed message to a relay node, for example, a payment network server to facilitate the transaction with a second bank server. In several aspects, the client can receive a notification of a confirmation of a successful or a failed token transaction from the relay node and/or the payment network server. In several aspects, based on the confirmation, the client can display an actionable notification on a user interface or display of the client device, the actionable notification comprising an interactive option of at least one of an option to retry the transaction upon failure of the transaction, an option to initiate a new transaction, or an option to repeat the transaction.

[0103] FIG. 13 illustrates one possible aspect of the architecture of a system for deposit tokenization technique (DTT) bridge protocol as hosted by the Payment Network System connected to multiple bank systems, according to at least one aspect of the present disclosure. Now referring primarily to FIG. 13 in conjunction with FIG. 2, in various embodiments, the system 1300 includes components for facilitating blockchain transactions and/or token transfer transactions, e.g., of digital assets and currencies, these components include, but are not limited to, a payment network server hub or relay node 1310 (referred to as “PNS hub”), which can be comprised of one or more servers of a payment network system, a relay node, and/or a hub 201, for example, as disclosed by FIG. 2. The PNS hub 1310 can be connected to a plurality of bank servers, systems, networks, digital currencies, and/or payment techniques, for example, the systems and currencies 202, as disclosed by FIG. 2.

[0104] With primary reference to FIG. 13 in combination with FIG. 1, in numerous aspects, connections between the PNS hub 1310 with various bank systems can be facilitated by APIs, API tools, software development kits, or other runtime and querying languages, or combinations thereof, e.g., API testing tools, as disclosed by FIG. 1. In several aspects, an auditor server or system 1304 (which can be an independent service or one associated with PNS hub 1310) is also connected to, or in communication with, the PNS hub 1310. In several aspects, the PNS hub 1310 comprises a deposit tokenization sandbox or container to execute methods for facilitating token and/or blockchain transactions.

[0105] In several aspects, the PNS hub 1310 is coupled with or connected to a first bank I first bank server 1301 (FB server) of the plurality of bank servers or systems, and/or to a second bank I second bank server 1302 (SB server) of the plurality of bank servers or systems, where the FB server 1301 and SB server 1302 are of a first bank and second bank, respectively. The FB server 1301 and SB server 1302 can be associated with or be part of a first bank system or network 1321 (referred to herein as “FB network 1321”) or a second bank system or network 1322 (referred to herein as “SB network 1322”), respectively.

[0106] These networks 1321 , 1322 can comprise enterprise systems, databases, data centers, and/or large server systems, mainframes, and the like and could be hosted locally, in a cloud environment, and/or as distributed systems. In several aspects, the FB server 1301 and/or associated FB network 1321 can belong to or be associated with a first blockchain, while the SB server 1302 and/or associated SB network 1322 can belong to or be associated with a second blockchain.

[0107] In numerous aspects, FB server 1301 responds to a client or client application, for example, wallet provider or application 1306 on a user or client device of a first sender user 1311 of the first bank who wants to transfer funds to a second recipient user 1312 that belongs to a second bank. In various aspects, a first user 1311 uses a client such as the wallet provider or application 1306 to send funds comprising financial instruments or assets that include, but are not limited to, currency, tokens, digital coin, or digital currency, which can be received by a second user 1312 in the same form or in a different form, digital instrument, or asset, for example, the same or a different digital coin or digital currency.

[0108] In one aspect, once FB server 1301 receives a first user transaction request, e.g., from a client, application, or wallet provider, an authorization flow is triggered encompassing processes up to 1315 of the system 1300. The FB server undertakes the following: generate a digital transaction message, a transaction information data packet, or transaction information, wherein the transaction message (or transaction data/info) comprises at least one of a transfer amount, an identifier of a first client or client device, an identifier of 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 randomness variable, or any combination thereof.

[0109] Once FB server 1301 has generated a digital transaction message or transaction information, it then digitally signs another message, which in several aspects comprises at least the sender identifier and the transfer amount, to generate a first bank digital signed message. In various aspects, other combinations of other information derived from input transaction information or from other transaction information, i.e., the transaction data/info listed above as well as that discussed in relation to other figures in this disclosure, can be used for the digital signed message. FB server 1301 then may send 1313 a first data package comprising least one of the digital transaction message and/or the first bank digital signed message to the PNS hub 1310 to facilitate the transaction requested by the first user 1311.

[0110] Upon receipt of the data package, PNS hub 1310 can then facilitate the transfer of financial assets from one bank to another, in several aspects, by receiving the first data package sent 1313 from the FB server 1301 of the plurality of bank servers, the first data package comprising transaction information, a digital signed message, or both. The PNS hub 1310 then may encrypt at least one portion of the transaction information with an encryption key of the FB server 1301. In several aspects, this portion of the transaction information includes encrypting the transfer amount.

[0111] The PNS hub 1310 may then generate a first new digital message based on the data package. In many aspects, the constructing of the first new digital message is based on the transaction message or at least a portion of information in the transaction message, for example, any combination of any of the following that was included in the digital transaction data package sent 1313 by FB server 1301: a transfer amount, 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 randomness variable, other input transaction information, or any combination thereof. The PNS hub 1310 can also verify a digital signature of the FB server 1301 associated with or in the digital signed message that was sent 1313, and based on the verification being successful, for example, the signature being non-problematic or non-fraudulent and/or being verified as belonging to the FB server 1301, the PNS hub 1310 can transmit 1314 at least a portion of the transaction message to the SB server 1302 of the plurality of bank servers. [0112] The SB server 1302 can receive the at least a portion of the transaction message that was sent 1314 and then can verify compliance of the at least a portion of the transaction message, for example, compliance against pre-set rules, regulations, or laws against a client blacklist. After successful verification, the SB server 1302 then signs a second bank message, the second bank message comprising at least one of a receiver client identifier (for example, wallet provider or digital wallet 1307 and/or associated user 1312), an identifier of the SB server 1302 and/or second bank network 1322, and/or the transfer amount to generate a digital signed second bank message, and it sends 1315 the digital signed second bank message to the PNS hub 1310. This is where the authorization flow of the system 1300 ends and where the settlement flow begins.

[0113] The settlement flow of system 1300 comprises the PNS hub 1310 receiving the second bank digital signed message sent 1315 by the SB server 1302. The PNS hub 1310 then generates a second new digital message based on at least one of: the information from the data package or the second bank digital signed message, and it executes, runs, or invokes 1316, a “prepare burn” or “prepare token burn” function 1316 based on first inputs comprising at least one of the first new digital message or the first bank digital signed message. Invocation 1316 of the function with the aforementioned inputs can be undertaken on, with, or via a digital token pending balance or contract 1325 (“token contract 1325”) on the FB network 1321, where the token contract 1325 can comprise various functions, including, but not limited to, escrow and/or ledger functionalities.

[0114] The prepare burn/burn token function 1316 can comprise verifying a signature of the first bank digital signed message against the first inputs by the PNS hub 1310, FB network 1321 , or both, and then, based on a successful verification, subtract the transaction amount from an account associated with a first user (e.g., the sending user), e.g., from a first user digital wallet provider 1306 associated with the FB server 1301 and registering the addition of the transaction amount to the token contract 1325 that is associated with the FB server 1301 , or the first bank network 1321, in preparation for the amount added to be burned. The function 1316 can also include setting an expiry time, set to reverse a blockchain token transfer if a confirmation is not received by the PNS hub 1310 within the expiry time. If the verification is not successful, then the transaction may be canceled by the PNS hub 1310 or PNS hub 1310 may attempt to automatically repeat the transaction. In some aspects, upon incidents of a failure of the function 1316, for example, if the verification is not successful, then based on this failed verification, the PNS hub 1310 may ask the first user 1311, second user 1312, the client or wallet providers/clients 1306, 1307, and/or FB server 1301 or SB server 1302 for additional information or inputs necessary to complete the transaction, or the PNS hub 1310 may cancel the transaction.

[0115] Upon a successful prepare burn function 1316, the settlement flow for the transaction continues, where upon receiving by the PNS hub 1310 a confirmation from the prepare burn function 1316 of its success, the PNS hub 1310 executes, runs, or invokes a “prepare mint function” 1317 based on second inputs comprising at least one of the second new digital message or the second bank digital signed message, or both, and invoking, executing, or running this prepare mint function 1317 in various aspects on a digital token pending contract 1335 that is on, or associated with, the SB network 1322, where the token pending contract 1335 can comprise various functions, including, but not limited to, escrow and/or ledger functionalities.

[0116] The prepare mint function 1317 can, in various aspects, comprise verifying by one of the PNS hub 1310, the SB server 1302, and/or SB network 1322 a signature of the SB server 1302 against the second inputs, and based on the verifying, where the verifying is successful, register the addition of, or adding the transaction amount to, a second pending digital token balance 1335 associated with the SB server 1302, or the SB network 1322, in preparation for the amount added to be minted. In some aspects, upon incidents of a failure of the function 1317, for example, if the verification is not successful, then based on this failed verification, the PNS hub 1310 may ask the first user 1311, second user 1312, the client or wallet providers/clients 1306, 1307, and/or FB server 1301 or SB server 1302 for additional information or inputs necessary to complete the transaction, or the PNS hub 1310 may cancel the transaction.

[0117] Upon receiving, by PNS hub 1310, another confirmation from the prepare mint function 1317 from the SB server 1302, and/or from the SB network 1322, the PNC Hub 1310 invokes, executes, or initiates a token burn process/function 1318 on the token contract 1325 that commits/completes the process undertaken in the prepare burn function 1316.

[0118] The token burn function 1318 can comprise determining that a current time stamp is less than the expiry time, and based on the determination, it can subtract the transaction amount from the first pending digital token balance 1325, essentially “burning” or deleting the tokens from storage or circulation, and then generate a confirmation indicating a successful token burn receivable by the PNS hub 1310. However, in an unsuccessful burn scenario, the token burn function 1318 can comprise determining that a current time stamp is not less than the expiry time, and based on this determination, it can transfer the transaction amount from the first pending digital token balance 1325 to the first client account; this could be done by first deleting the transfer amount in the first pending digital token balance 1325, then adding the transaction amount into the first client account, and then generating a confirmation indicating a failed token burn, which is receivable by the PNS hub 1310. Upon receiving a successful token burn confirmation from the token burn function 1318, the PNS hub 1310 can then continue the transaction by invoking, executing, or initiating a token mint function 1319, and upon receiving a successful token mint confirmation from the token mint function 1319, it can send via the PNC hub 1310 a confirmation message to at least one of the FB server or the SB server.

[0119] In several aspects, the token mint function 1319 comprises determining that a current time stamp is less than the expiry time, and based on the determination, transfer 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 into the second client account, and then generating a confirmation indicating a successful token mint, with the confirmation being receivable by the PNS hub 1310. In unsuccessful scenarios, the token mint function 1319 comprises determining that a current time stamp is not less than the expiry time, and based on the determining, subtracting the transaction amount from the second pending digital token balance, essentially deleting or burning the tokens that were going to be created before they are generated, and then generating a confirmation indicating a failed token mint, which is receivable by the PNS hub 1310.

[0120] In several aspects, the PNS hub 1310 can also receive at least one of a failed token burn confirmation or a failed token mint confirmation from functions 1318 and 1319, respectively. In numerous aspects, the PNS hub 1310 sends 1320 a notification of a successful or failed token transfer transaction to at least a first client or device 1306 or the second client/or device 1307.

[0121] One skilled in the art will recognize that Internet service may be configured to provide Internet access to one or more computing devices that are coupled to the Internet service, and that the computing devices may include one or more processors, buses, memory devices, display devices, I/O devices, and the like. Furthermore, those skilled in the art may appreciate that the Internet service may be coupled to one or more databases, repositories, servers, and the like, which may be utilized to implement any of the various aspects of the disclosure as described herein. [0122] The computer program instructions also may be loaded onto a computer, a server, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other devices to produce a computer-implemented process such that the instructions that execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

[0123] Suitable networks may include or interface with any one or more of, for instance, a local intranet; a p PAN (Personal Area Network), a LAN (Local Area Network), a WAN (Wide Area Network), a MAN (Metropolitan Area Network), a virtual private network (VPN), a storage area network (SAN), a frame relay connection, an Advanced Intelligent Network (AIN) connection, a synchronous optical network (SONET) connection, a digital T1 , T3, E1 or E3 line, Digital Data Service (DDS) connection, DSL (Digital Subscriber Line) connection, an Ethernet connection, an ISDN (Integrated Services Digital Network) line, a dial-up port such as a V.90, V.34 or V.34bis analog modem connection, a cable modem, an ATM (Asynchronous Transfer Mode) connection, or an FDDI (Fiber Distributed Data Interface) or CDDI (Copper Distributed Data Interface) connection. Furthermore, communications may also 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 Communication), CDMA (Code Division Multiple Access) or TDMA (Time Division Multiple Access), cellular phone networks, GPS (Global Positioning System), CDPD (cellular digital packet data), RIM (Research in Motion, Limited) duplex paging network, Bluetooth radio, or an Institute of Electrical and Electronics Engineers (IEEE) 802.11-based radio frequency (RF) network. The server 4030 can further include or interface with any one or more of an RS-232 serial connection, an I EEE- 1394 (Firewire) connection, a Fibre Channel connection, an Infrared Data Association port, a SCSI (Small Computer Systems Interface) connection, a USB (Universal Serial Bus) connection, or other wired or wireless, digital or analog interface or connection, mesh, or Digi® networking.

[0124] FIG. 14 illustrates an alternative aspect of the architecture of Tokenized Asset Platform (TA) systems and methods for deposit tokenization technique (DDT) bridge protocol as hosted by the Payment Network System (PNS) connected to multiple bank systems, according to at least one aspect of the present disclosure. The architecture shown in FIG. 14 is, in many aspects, identical or very similar to the architecture shown in FIG. 13; however, FIG. 14 additionally illustrates that each bank can be connected to a ledger associated with it that may or may not be hosted on the respective bank’s network. For example, bank 1 can be connected to a bank 1 ledge and bank 2 can be connected to a bank 2 ledger. The bank 1 ledger and the bank 2 ledger can host the digital contracts 1425, 1435, respectively, that correspond to digital contracts 1325, 1335 and can allow similar functionalities. The systems, methods, and processes of FIG. 13 can be applied to FIG. 14 but are not repeated for brevity.

[0125] FIG. 15 illustrates another alternative aspect of the architecture of Tokenized Asset Platform (TAP) systems and methods for deposit tokenization technique (DTT) bridge protocol as hosted by the Payment Network System (PNS) hub 1510 connected to multiple bank systems, according to at least one aspect of the present disclosure. The model of TAP is shown in FIG. 1. This model considers Banks who have tokenized the deposits of their clients on a smart contract (which can be within the same or across different ledgers). The amounts reflected on the smart contracts are in encrypted format under the respective Bank’s key to preserve the clients’ privacy.

[0126] In a basic aspect, architecture shown in FIG. 15 includes a sending user 1511 who has an account under Bank 1 1501, requests to send a specified amount to a receiving user 1512 who has an account under Bank 2 1502. This transfer is facilitated by a relay (or Relay), e.g., relay 1510, which also has access privileges to smart contracts, including, but not limited to, token contracts 1525, 1535 of the owning banks 1501, 1502, respectively. During the transfer, the relay 1510 will learn the amount transacted between the banks 1501, 1502, but it still may not be able to learn the encrypted balance sheet information.

[0127] Finally, the deployed TAP model is optimistic (sometimes also referred to as “trust and verify”). This implies that the Banks’ 1501 , 1502 and relay’s 1510 behavior is assumed to be honest, and these aforementioned entities are expected to follow the protocol. However, an auditor 1504 at any point can request proofs from those entities that they indeed follow a TAP protocol. These proofs are created in the Zero- Knowledge (ZK) paradigm, such that the auditor 1504 does not learn any information, such as client balances or transaction amounts.

[0128] Both of the architectures illustrated by FIGS. 14-15 can comprise any of the described protocols in FIG. 13 and can also comprise alternate processes as further described herein. For example, any of the architectures can comprise a sending user 1411, 1511 initiating the transaction by sampling a random transaction identifier txidl, hashes the transaction as h = H(“EXTERNALBURN”, txidl, [amt]banksender), and sending 1540 the signed hash o_sender(/7) to bank 1, 1401, 1501 respectively. [0129] With continued reference to FIGS. 14-15, Bank 1 1401 , 1501 can then perform the following protocol: (a) verify o_sender(/7); (b) sample encryption randomness ri; (c) construct ciphertext [amt]bank_sender using randomness r , (d) create the transaction information message txlnfoi = {txidi, sender, [amt]banksender, o_Sender(/7i), lockKey}; (e) invoke a function lockAccount(sender, lockKey) 1541 that locks the user or client account from any changes such as transactions outside of the pending current transaction, to avoid changes to the account while the protocol is being undertaken; and (f) Invokes prepareBurn(txlnfoi) 1541. Where, in several aspects, the smart contract on invoking prepareBurn does one or more of the following: (a) verify that the sender account is locked; (b) verify that txidi is not in “isSeenBefore”; (c) verify o_sender(/7i); (d) add txidi to “isSeenBefore”; (e) add {“EXTERNALBURN”, sender, [amt]banksender, expiry} to pendingPayments[txid1], where expiry = now + prepareDuration; (f) homomorphically subtract amt from the client’s balance and the global totalSupply; (g) set the client account’s lockExpiry to 0 (which unlocks the account); and (h) emit a prepareBurn event as eventi = {txidi, sender, [amt]banksender}.

[0130] Bank 1 (sender bank) 1401 , 1501 can then send 1542 (txlnfoi, amt, fi, bank_receiver, receiver) and the transaction hash of eventi to Relay 1410, 1510 (also referred to as “relay node”).

[0131] Relay node 1410, 1510 can then perform the following actions: (a) reconstruct ciphertext [amt]banksender using randomness and verify that this equals the ciphertext in eventi; (b) verify Oi; (c) performs compliance/fraud checks as needed; and (d) send 1543 {receiver, amt} to Bank 2, 1402, 1502 (e.g., the bank with address bankreceiver, which corresponds to the Bank receiving the payment).

[0132] On receiving {receiver, amt} from Relay 1410, 1510, the receiver bank 1402, 1502: (a) checks that receiver exists in the contract balance sheet and that the transaction is compliant (e.g., that the client is not in a transaction blacklist); (b) samples encryption randomness r₂ and a unique transaction identifier txid₂; (c) constructs ciphertext [amt]bankreceiver using randomness r₂; (d) signs the message /?₂ <— /-/(“EXTERNALMINT”, txid₂, receiver, [amt]_bankreceiver) to get o₂ «- Obankreceiver(/k); and (e) sends 1544 (txid₂, r₂, a₂) to Relay 1410, 1510.

[0133] On receiving (txid₂, r₂, a₂) from the receiving bank 1401 , 1501 , Relay 1410, 1510: (a) reconstructs ciphertext [amt]bankreceiver using randomness r₂ and verifies that this equals with the ciphertext in h₂, (b) verifies o₂, (c) samples random values r₂, r^, (to be used later for randomizing the auditorinfo hashes); (d) saves txlnfo = {sender, receiver, bank_sender, bankreceiver, txidi , txid₂, amt, fi, r₂, r₂, r₄} to its database (to be used in case of a future audit); (e) computes auditorlnfoi = /7(bank_sender, txidi , r₃), where auditorinfo information is to be used at a later auditing stage; and (f) invokes prepareMint(txid2, receiver, [amt]bankreceiver, 02, auditorlnfoi) 1545 in the receiving Bank’s 1502 smart contract 1535 (also referred to herein as “token contract” or “digital token contract”). The smart contract 1535 on invoking prepareMint does the following: (a) verifies 02 (b) adds {“EXTERNALMINT”, receiver, [amt]bankreceiver, expiry} to pendingPayments[txid2], where expiry = now + prepareDuration; and (c) emits a prepareMint event as event2 = {txid₂, receiver, [amt]bankreceiver, auditorlnfoi}.

[0134] Relay 1410, 1510 computes auditor! nfo₂ = /7(bank_receiver, txid₂, r4) and invokes commitBurn(txidi, auditorlnfoi) in the sending Bank’s 1401 , 1501 smart contract 1425, 1525. On invoking commitBurn, the smart contract does the following: (a) deletes pendingPayments[txidi]; and (b) emits a commitBurn event 1546 as events = txidi. This commitBurn event could be undertaken via the token contract 1435, 1535, FIG. 14, FIG. 15 that could be hosted on a digital ledger 1437, FIG. 14 and/or a bank network 1537, FIG. 15 of bank 2 1502.

[0135] Relay 1410, 1510 invokes commitMint(txid2) 1547 in the receiving Bank’s 1402, 1502 smart contract. On invoking commitMint 1547, the smart contract does the following:

(a) homomorphically adds amt to the receiving client’s balance and the global totalSupply;

(b) deletes pendingPayments[txid2]; and (c) emits a commitMint event as event4 = txid2.This commitMint event could be undertaken via the token contract 1435, 1535, FIG. 14, FIG. 15, which could be hosted on a digital ledger 1437, FIG. 14 and/or a bank network 1537, FIG. 15 of bank 2 1502.

[0136] In various aspects of the systems, methods, processes, and protocols disclosed in FIGS. 1-15, after the transaction is finalized and its respective elements recorded on the blockchains, the auditor at any point in the future can optionally make the following audits for some time stamp/block in a reactive fashion to verify the honest behavior of banks and Relay.

[0137] Proof of burn Tib from banks on observation of a commitBurn smart contract operation. This proves that the amount burned is non-negative and that the leftover amount in the sender’s balance is not negative. The proof is provided in ZK as follows: Tib = {(r, amt): amt > 0 A balsender amt}([amt]bank, [bal_sender]bank, bank), where bal_sender is the sending client’s balance in the Bank reflected in the balance sheet in encrypted format as [balsender] bank. [0138] Proof of equality from Relay on observation of a commitBurn or commitMint event. This proves that there exists a matching commitMint or commitBurn operation, respectively, and that the encrypted amounts are equal. The proof is provided in ZK as follows. First, the auditor asks Relay to prove equality on 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 opens auditor! nfoi and auditor! nfc>2 to the auditor, who learns txidi, txid2, r₃, f4, sender, receiver, bank_sender and bankreceiver of a single TAP transaction. Then, for the corresponding encryptions, Relay provides Tie = {(r1 , r2, amt)}([amt]bank_sender, [amt] bankreceiver, banksender, bankreceiver).

[0139] In various aspects of the systems, methods, processes, and protocols disclosed in FIGS. 1-15, the TAP protocol may utilize an additively homomorphic encryption scheme. The TAP protocol can be instantiated with “the additive version of EIGamal encryption” as one example, which consists of the following algorithms: pp <— Setup(1A): On input of security parameter A, outputs public parameters pp = (G, g, p), where g is generator of cyclic group G of prime order p. These parameters are considered as a default input to all following algorithms and are omitted for simplicity, (pk, sk) <— Gen(): Outputs a secret-public key pair as sk <— Zp, pk = g^sk.

[0140] (ci , C2) Enc(pk, x): Samples r <— Zp, computes Ci = g^r, C2 = g^x pk^r and outputs ciphertext C = (ci, C2). x <— Dec(sk, (ci , C2)): Compute g^x = c2/c^sk. While x cannot be directly computed from g^x, it can be recovered as explained herein. The scheme is additively homomorphic because it holds that EncA(pk, xi) Encs(pk, X2) = (CIA ■ CIB, C2A ■ C2B) = Enc(pk, xi + X2). The message space is in Z_p, and thus 0 is not included. There are various methods to support encryption of 0, for instance, by mapping the message space {0, ..., p - 2} to {1 , .... p - 1}.

[0141] As discussed above, in additive EIGamal, Dec(sk, (ci , C2)) does not directly output x but g^x. Recovering the actual value x can be done by iterating through all possible x in a brute-force fashion or using a pre-computed lookup table. Both of these methods require 0(1) space and O(n) computation or O(n) space and 0(1) computation, respectively, and are only practical when assuming that the message space is relatively small (up to some billion values).

[0142] However, for example, “Shanks algorithm” enables a space-time tradeoff for the naive solutions above. It defines a “baby-step,” which stores (x, g^x) for all x e [1, 2^a] in a lookup table M, and up to 2^P “giant-steps”, with a + /3 = n. To recover the discrete log of c = g^x, it computes the giant step as g^2a, initializes counter i — > 0, and checks if c/g^i2a exists in M. If the lookup is successful: return x+i ■ 2^a, else increment i and repeat lookup. This algorithm has O(2^a) storage and requires 2p multiplications (elliptic curve point additions) in the worst case, which can be amortized as needed. In various exemplary aspects in TAP, it can be considered that n = 37, i.e. , a space up to 2³⁷ values, which are needed to support a range of up to 100 billion with 2 decimal digits. When a bank needs to decrypt an encrypted “EIGamal” or other “ciphertext” from the smart contract, in several aspects it needs to map x to g^x as described herein.

[0143] In general, a cloud-based computing environment is a resource that typically combines the computational power of a large grouping of processors (such as within web servers) and/or that combines the storage capacity of a large grouping of computer memories or storage devices. Systems that provide cloud-based resources may be utilized exclusively by their owners, or such systems may be accessible to outside users who deploy applications within the computing infrastructure to obtain the benefit of large computational or storage resources.

[0144] The cloud is formed, for example, by a network of web servers that comprise a plurality of computing devices, such as the host machine 4002, with each server 4030 (or at least a plurality thereof) providing processor and/or storage resources. These servers manage workloads provided by multiple users (e.g., cloud resource customers or other users). Typically, each user places workload demands upon the cloud that vary in real time, sometimes dramatically. The nature and extent of these variations typically depend on the type of business associated with the user.

[0145] It is noteworthy that any hardware platform suitable for performing the processing described herein is suitable for use with the technology. The terms “computer-readable storage medium” and “computer-readable storage media” as used herein refer to any medium or media that participate in providing instructions to a 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 or magnetic disks, such as a fixed disk. Volatile media include dynamic memory, such as system RAM. Transmission media include coaxial cables, copper wire, and fiber optics, among others, including the wires that comprise one aspect of a bus. Transmission media can also take the form of acoustic or light waves, such as those generated during RF and infrared data communications. Common forms of computer-readable media include, for example, a flexible disk, a hard disk, magnetic tape, any other magnetic medium, a CD-ROM disk, DVD, any other optical medium, any other physical medium with patterns of marks or holes, a RAM, a PROM, an EPROM, an EEPROM, a FLASH EPROM, any other memory chip or data exchange adapter, a carrier wave, or any other medium from which a computer can read.

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

[0147] Computer program code for carrying out operations for aspects of the present technology may be written in any combination of one or more programming languages, including an object-oriented programming language, such as Java, Smalltalk, C++, or the like, and conventional procedural programming languages, such as the “C” programming language, Go, Python, or other programming languages, including assembly languages. The program code may execute entirely on the user’s computer, partly on the user’s computer, as a stand-alone software package, partly on the user’s computer and partly on a remote computer, or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user’s computer through any type of network, including a LAN or a WAN, or the connection may be made to an external computer (for example, through the Internet using an Internet service provider).

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

[0149] Clause 1. In one aspect, the present disclosure provides a method for use by a payment network system to transfer a plurality of deposit tokens, the method comprising utilizing an interoperable, two-phase commit protocol and a relay node to settle inter-chain transfers with privacy guarantees between a first token contract on a first blockchain and a second token contract on a second blockchain, the protocol comprising receiving, via the relay node, from a first bank belonging to a first blockchain, information regarding a transaction comprising an amount to be transferred, a sending party identifier, a sending party’s bank identifier, a receiving party identifier, and a receiving party’s bank identifier, and a sending party’s signature; providing, via the relay node, to a second bank belonging to a second blockchain, information regarding the transaction comprising the amount to be transferred, the sending party identifier, the sending party’s bank identifier, the receiving party identifier, and the receiving party’s bank identifier; and receiving, via the relay node, from the second bank belonging to the second blockchain, a receiving party’s signature.

[0150] Clause 2. The method of Clause 1 wherein the protocol further comprises invoking a prepare burn function and verifying the sending party’s signature.

[0151] Clause 3. The method of any of Clauses 1-2 wherein in several aspects, the protocol further comprises invoking a prepare mint function and verifying the receiving party’s signature.

[0152] Clause 4. The method of any of Clauses 1-3 wherein the protocol further comprises invoking a commit burn function, wherein the commit burn function finalizes a burn that was invoked in the prepare burn function.

[0153] Clause 5. The method of any of Clauses 1-4 wherein in many aspects the protocol further comprises invoking a commit mint function, wherein the commit mint function finalizes a mint that was invoked in the prepare mint function.

[0154] Clause 6. The method of any of Clauses 1-5 wherein in numerous aspects the protocol further comprises sending a confirmation message to the first bank and the second bank, wherein the confirmation message confirms that a transfer has been completed.

[0155] Clause 7. The method of any of Clauses 1-6 wherein the protocol further comprises an auditor optionally performing an audit to verify an honest behavior of the first bank, the second bank, and the payment network system.

[0156] 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 a user input comprising input transaction information; based on at least the input transaction information, generating a digital transaction info message, wherein the digital transaction info message comprises at least one of a transfer amount, an identifier of a sender, an identifier of a receiver, an identifier of a sender bank, an identifier of a receiver bank, or a randomness variable; generating another digital message comprising at least one of the identifier of the sender, the transfer amount, or combinations thereof; digitally signing the other digital message to generate a digital signed message; and sending a first data package comprising least one of the digital transaction info message or the digital signed message to a relay node to facilitate a transaction with a second bank server. [0157] Clause 9. The non-transitory computer-readable medium of Clause 8, wherein the method further comprises receiving a confirmation, from the relay node, of completion of the transaction.

[0158] Clause 10. The non-transitory computer-readable medium of Clauses 8-9, wherein the method further comprises displaying an actionable notification on the client device, wherein the actionable notification comprises an interactive option of at least one of an option to retry the transaction upon failure of the transaction, an option to initiate a new transaction, or an option to repeat the transaction.

[0159] 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; an auditor server connected to the PNS hub; wherein the PNS hub comprises a deposit tokenization sandbox to connect to the plurality of bank servers; receive a data package from a first bank server (FB server) of the plurality of bank servers, wherein the FB server is of a first bank, and associated with a first blockchain, the data package comprising transaction information and a digital signed message; encrypt at least one portion of the transaction information with an encryption key of the first bank server; generate a first new digital message based on the data package; verify a digital signature of a first bank digital signed message; and based on the verification, transmit at least a portion of the transaction information to a second bank server of the plurality of bank servers, wherein the second bank server is of a second bank and associated with a second blockchain.

[0160] Clause 12. The system of Clause 11, wherein the system comprises the first bank server (FB server) of the plurality of bank servers to generate a digital transaction message, by the FB server of a first bank, wherein the FB server is associated with a first bank, a first client account of a first user, and a first blockchain, wherein the digital transaction message comprises 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 randomness variable; digitally sign another message comprising at least the identifier and the transfer amount to generate a first bank digital signed message; and send a first data package comprising least one of the digital transaction message or the first bank digital signed message to the PNS hub.

[0161] Clause 13. The system of Clauses 10-12, wherein the system comprises a second bank server of the plurality of bank servers to receive, by the second bank server (SB server), the at least portion of the transaction information wherein the SB server is associated to the second bank; verify, by the SB server, compliance of the at least one portion of the transaction information; sign a second bank message, the second bank message comprising at least one of an identifier of a second client account, an identifier of the SB server, or a transfer amount to generate a digital signed second bank message; and send the digital signed second bank message to the PNS hub.

[0162] Clause 14. The system of Clauses 10-13, wherein the PNS hub comprises a deposit tokenization sandbox to receive a second bank digital signed message from an SB server; generate a second new digital message based on at least one of the transaction information from the data package or the second bank digital signed message; invoking a prepare burn function based on first inputs comprising at least one of the first new digital message or the first bank digital signed message; upon receiving a confirmation, invoking a prepare mint function based on second inputs comprising at least one of the second new digital message or the second bank digital signed message; upon receiving another confirmation from the SB server; undertake a token burn function; upon receiving a successful token burn confirmation from the token burn function; undertake a token mint function; and upon receiving a successful token mint confirmation from the token mint function; send a confirmation message to at least one of the FB server, or the SB server.

[0163] Clause 15. The system of Clauses 10-14, further comprising an auditor server to determine that a proof of burn from at least one of the first bank or the second bank matches an encrypted balance sheet.

[0164] Clause 16. In various aspects the system of Clauses 10-15, wherein the prepare burn function comprises instructions to verify a signature of the first bank digital signed message against the first inputs; based on the verifying, subtracting the transaction amount from a first account with the first bank; registering an addition of the transaction amount in a first pending digital token balance associated with the first bank; and setting an expiry time, set to reverse a token transfer if a confirmation is not received by the PNS hub within the expiry time.

[0165] Clause 17. In various aspects the system of Clauses 10-16 wherein the prepare mint function comprises instructions to verify a signature of the second bank against the second inputs; and based on the verifying, registering an addition of the transaction amount a second pending digital token balance associated with the second bank.

[0166] Clause 18. In various aspects the system of Clauses 10-17, wherein the token burn function comprises instructions to determine that a current time stamp is less than an expiry time; based on the determination, subtract the transaction amount from the first pending digital token balance; and generate a confirmation indicating a successful token burn, the confirmation receivable by the PNS hub.

[0167] Clause 19. In various aspects the system of Clauses 10-18, wherein the token burn function comprises instructions to determining that a current time stamp is not less than an expiry time; based on the determining, transfer the transaction amount from the first pending digital token balance to a first client account; and generate a failed token burn confirmation receivable by the PNS hub.

[0168] Clause 20. In various aspects the system of Clauses 10-19, wherein the token mint function comprises instructions to determine that a current time stamp is less than an expiry time; based on the determination, transfer the transaction amount from the second pending digital token balance to a second client account of a second user of a second bank; and generate a confirmation indicating a successful token mint, the confirmation receivable by the PNS hub.

[0169] Clause 21. In various aspects the system of Clauses 10-20, wherein the token mint function comprises instructions to determine that a current time stamp is not less than an expiry time; based on the determining, subtract the transaction amount from the second pending digital token balance; and generate a confirmation indicating a failed token mint, the token mint receivable by the PNS hub.

[0170] The foregoing detailed description has set forth various forms of the systems and/or processes via the use of block diagrams, flowcharts, and/or examples. Insofar as such block diagrams, flowcharts, and/or examples contain one or more functions and/or operations, it will be understood by those within the art 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. Those skilled in the art will recognize that some aspects of the forms disclosed herein, in whole or in part, can be equivalently implemented in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing the circuitry and/or writing the code for the software and or firmware would be well within the skill of one of skill in the art in light of this disclosure. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein are capable of being distributed as one or more program products in a variety of forms, and that an illustrative form of the subject matter described herein applies regardless of the particular type of signal bearing medium used to actually carry out the distribution.

[0171] Instructions used to program logic to perform various disclosed aspects can be stored within a memory in the system, such as dynamic random access memory (DRAM), cache, flash memory, or other storage. Furthermore, the instructions can be distributed via a network or by way of other computer-readable media. Thus a machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer), but is not limited to, floppy diskettes, optical disks, compact disc, read-only memory (CD-ROMs), and magneto-optical disks, read-only memory (ROMs), random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic or optical cards, flash memory, or a tangible, machine-readable storage used in the transmission of information over the Internet via electrical, optical, acoustical or other forms of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.). Accordingly, the non- transitory computer-readable medium includes any type of tangible machine-readable medium suitable for storing or transmitting electronic instructions or information in a form readable by a machine (e.g., a computer).

[0172] Any of the software components or functions described in this application, may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Python, Java, C++ or Perl using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions, or commands on a computer-readable medium, such as RAM, ROM, a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD- ROM. Any such computer-readable medium may reside on or within a single computational apparatus and may be present on or within different computational apparatuses within a system or network.

[0173] As used in any aspect herein, the term “logic” may refer to an app, software, firmware and/or circuitry configured to perform any of the aforementioned operations. Software may be embodied as a software package, code, instructions, instruction sets and/or data recorded on non-transitory computer-readable storage medium. Firmware may be embodied as code, instructions or instruction sets and/or data that are hard-coded (e.g., nonvolatile) in memory devices. [0174] As used in any aspect herein, the terms “component,” “system,” “module” and the like can refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution.

[0175] As used in any aspect herein, an “algorithm” refers to a self-consistent sequence of steps leading to a desired result, where a “step” refers to a manipulation of physical quantities and/or logic states which may, though need not necessarily, take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It is common usage to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. These and similar terms may be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities and/or states.

[0176] A network may include a packet switched network. The communication devices may be capable of communicating with each other using a selected packet switched network communications protocol. One example communications protocol may include an Ethernet communications protocol which may be capable of permitting communication using a Transmission Control Protocol/lnternet Protocol (TCP/IP). The Ethernet protocol may comply or be compatible with the Ethernet standard published by the Institute of Electrical and Electronics Engineers (IEEE) titled “IEEE 802.3 Standard”, published in December, 2008 and/or later versions of this standard. Alternatively, or additionally, the communication devices may be capable of communicating with each other using an X.25 communications protocol. The X.25 communications protocol may comply or be compatible with a standard promulgated by the International Telecommunication Union-Telecommunication Standardization Sector (ITU-T). Alternatively, or additionally, the communication devices may be capable of communicating with each other using a frame relay communications protocol. The frame relay communications protocol may comply or be compatible with a standard promulgated by Consultative Committee for International Telegraph and Telephone (CCITT) and/or the American National Standards Institute (ANSI). Alternatively, or additionally, the transceivers may be capable of communicating with each other using an Asynchronous Transfer Mode (ATM) communications protocol. The ATM communications protocol may comply or be compatible with an ATM standard published by the ATM Forum titled “ATM-MPLS Network Interworking 2.0” published August 2001 , and/or later versions of this standard. Of course, different and/or after-developed connection-oriented network communication protocols are equally contemplated herein.

[0177] Unless specifically stated otherwise as apparent from the foregoing disclosure, it is appreciated that, throughout the present disclosure, discussions using terms such as “processing,” “computing,” “calculating,” “determining,” “displaying,” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system’s registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

[0178] One or more components may be referred to herein as “configured to,” “configurable to,” “operable/operative to,” “adapted/adaptable,” “able to,” “conformable/conformed to,” etc. Those skilled in the art will recognize that “configured to” can generally encompass active-state components and/or inactive-state components and/or standby-state components, unless context requires otherwise.

[0179] Those skilled in the art will recognize that, in general, terms used herein, and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as “open” 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.). It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, as an aid to understanding, the following appended claims may contain usage of the introductory phrases “at least one” and “one or more” to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim recitation to claims containing only one such recitation, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an” (e.g., “a” and/or “an” should typically be interpreted to mean “at least one” or “one or more”); the same holds true for the use of definite articles used to introduce claim recitations.

[0180] In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should typically be interpreted to mean at least the recited number (e.g., the bare recitation of “two recitations,” without other modifiers, typically means at least two recitations, or two or more recitations). Furthermore, in those instances where a convention analogous to “at least one of A, B, and C, etc.” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., “a system having at least one of A, B, and C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, and C together, etc.). In those instances where a convention analogous to “at least one of A, B, or C, etc.” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., “a system having at least one of A, B, or C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, and C together, etc.). It will be further understood by those within the art that typically a disjunctive word and/or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms unless context dictates otherwise. For example, the phrase “A or B” will be typically understood to include the possibilities of “A” or “B” or “A and B.”

[0181] With respect to the appended claims, those skilled in the art will appreciate that recited operations therein may generally be performed in any order. Also, although various operational flow diagrams are presented in a sequence(s), it should be understood that the various operations may be performed in other orders than those which are illustrated or may be performed concurrently. Examples of such alternate orderings may include overlapping, interleaved, interrupted, reordered, incremental, preparatory, supplemental, simultaneous, reverse, or other variant orderings, unless context dictates otherwise. Furthermore, terms like “responsive to,” “related to,” or other past-tense adjectives are generally not intended to exclude such variants, unless context dictates otherwise.

[0182] It is worthy to note that any reference to “one aspect,” “an aspect,” “an exemplification,” “one exemplification,” and the like means that a particular feature, structure, or characteristic described in connection with the aspect is included in at least one aspect. Thus, appearances of the phrases “in one aspect,” “in an aspect,” “in an exemplification,” and “in one exemplification” in various places throughout the specification are not necessarily all referring to the same aspect. Furthermore, the particular features, structures or characteristics may be combined in any suitable manner in one or more aspects.

[0183] As used herein, the singular form of “a”, “an”, and “the” include the plural references unless the context clearly dictates otherwise.

[0184] Any patent application, patent, non-patent publication, or other disclosure material referred to in this specification and/or listed in any Application Data Sheet is incorporated by reference herein, to the extent that the incorporated materials is not inconsistent herewith. As such, and to the extent necessary, the disclosure as explicitly set forth herein supersedes any conflicting material incorporated herein by reference. Any material, or portion thereof, that is said to be incorporated by reference herein, but which conflicts with existing definitions, statements, or other disclosure material set forth herein will only be incorporated to the extent that no conflict arises between that incorporated material and the existing disclosure material. None is admitted to be prior art.

[0185] In summary, numerous benefits have been described which result from employing the concepts described herein. The foregoing description of the one or more forms has been presented for purposes of illustration and description. It is not intended to be exhaustive or limiting to the precise form disclosed. Modifications or variations are possible in light of the above teachings. The one or more forms were chosen and described in order to illustrate principles and practical application to thereby enable one of ordinary skill in the art to utilize the various forms and with various modifications as are suited to the particular use contemplated. It is intended that the claims submitted herewith define the overall scope.

Claims

CLAIMS What is claimed is:

1 . A method for use by a payment network system to transfer a plurality of deposit tokens, the method comprising: utilizing an interoperable, two-phase commit protocol and a relay node to settle interchain transfers with privacy guarantees between a first token contract on a first blockchain and a second token contract on a second blockchain, the protocol comprising: receiving, via the relay node, from a first bank belonging to a first blockchain, information regarding a transaction comprising an amount to be transferred, a sending party identifier, a sending party’s bank identifier, a receiving party identifier, and a receiving party’s bank identifier, and a sending party’s signature; providing, via the relay node, to a second bank belonging to a second blockchain, information regarding the transaction comprising the amount to be transferred, the sending party identifier, the sending party’s bank identifier, the receiving party identifier, and the receiving party’s bank identifier; and receiving, via the relay node, from the second bank belonging to the second blockchain, a receiving party’s signature.

2. The method of Claim 1 , wherein the protocol further comprises invoking a prepare burn function and verifying the sending party’s signature.

3. The method of Claim 2, wherein the protocol further comprises invoking a prepare mint function and verifying the receiving party’s signature.

4. The method of Claim 3, wherein the protocol further comprises invoking a commit burn function, wherein the commit burn function finalizes a burn that was invoked in the prepare burn function.

5. The method of Claim 4, wherein the protocol further comprises invoking a commit mint function, wherein the commit mint function finalizes a mint that was invoked in the prepare mint function.

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

7. The method of Claim 6, wherein the protocol further comprises an auditor optionally performing an audit to verify an honest behavior of the first bank, the second bank, and the payment network system.

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 a user input comprising input transaction information; based on at least the input transaction information, generating a digital transaction info message, wherein the digital transaction info message comprises at least one of a transfer amount, an identifier of a sender, an identifier of a receiver, an identifier of a sender bank, an identifier of a receiver bank, or a randomness variable; generating another digital message comprising at least one of the identifier of the sender, the transfer amount, or combinations thereof; digitally signing the other digital message to generate a digital signed message; and sending a first data package comprising least one of the digital transaction info message or the digital signed message to a relay node to facilitate a transaction with a second bank server.

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

10. The non-transitory computer readable medium of claim 9, wherein the method further comprises: displaying an actionable notification on the client device, wherein the actionable notification comprises an interactive option of at least one of an option to retry the transaction upon failure of the transaction, an option to initiate a new transaction, or an option to repeat the transaction.

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; an auditor server connected to the PNS hub; wherein the PNS hub comprises a deposit tokenization sandbox to: connect to the plurality of bank servers; receive a data package from a first bank server (FB server) of the plurality of bank servers, wherein the FB server is of a first bank, and associated with a first blockchain, the data package comprising transaction information and a digital signed message; encrypt at least one portion of the transaction information with an encryption key of the first bank server; generate a first new digital message based on the data package; verify a digital signature of a first bank digital signed message; and based on the verification, transmit at least a portion of the transaction information to a second bank server of the plurality of bank servers, wherein the second bank server is of a second bank and associated with a second blockchain.

12. The system of claim 11 comprising the first bank server (FB server) of the plurality of bank servers to: generate a digital transaction message, by the FB server of a first bank, wherein the FB server is associated with a first bank, a first client account of a first user, and a first blockchain, wherein the digital transaction message comprises at least one of a transfer 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 randomness variable; digitally sign another message comprising at least the identifier and the transfer amount to generate a first bank digital signed message; and send a first data package comprising least one of the digital transaction message or the first bank digital signed message to the PNS hub.

13. The system of claim 11 comprising a second bank server of the plurality of bank servers to: receive, by the second bank server (SB server), the at least portion of the transaction information wherein the SB server is associated to the second bank; verify, by the SB server, compliance of the at least one portion of the transaction information; sign a second bank message, the second bank message comprising at least one of an identifier of a second client account, an identifier of the SB server, or a transfer amount to generate a digital signed second bank message; and send the digital signed second bank message to the PNS hub.

14. The system of claim 11 wherein the PNS hub comprises a deposit tokenization sandbox to: receive a second bank digital signed message from an SB server; generate a second new digital message based on at least one of the transaction information from the data package or the second bank digital signed message; invoking a prepare burn function based on first inputs comprising at least one of the first new digital message or the first bank digital signed message; upon receiving a confirmation, invoking a prepare mint function based on second inputs comprising at least one of the second new digital message or the second bank digital signed message; upon receiving another confirmation from the SB server; undertake a token burn function; upon receiving a successful token burn confirmation from the token burn function; undertake a token mint function; and upon receiving a successful token mint confirmation from the token mint function; send a confirmation message to at least one of the FB server, or the SB server.

15. The system of claim 14, further comprising an auditor server to: determine that a proof of burn from at least one of the first bank or the second bank matches an encrypted balance sheet.

16. The system of claim 14, wherein the prepare burn function comprises instructions to: verify a signature of the first bank digital signed message against the first inputs; based on the verifying, subtracting the transaction amount from a first account with the first bank; registering an addition of the transaction amount in a first pending digital token balance associated with the first bank; and setting an expiry time, set to reverse a token transfer if a confirmation is not received by the PNS hub within the expiry time.

17. The system of claim 14, wherein the prepare mint function comprises instructions to: verify a signature of the second bank against the second inputs; and based on the verifying, registering an addition of the transaction amount a second pending digital token balance associated with the second bank.

18. The system of claim 16, wherein the token burn function comprises instructions to: determine that a current time stamp is less than an expiry time; based on the determination, subtract the transaction amount from the first pending digital token balance; and generate a confirmation indicating a successful token burn, the confirmation receivable by the PNS hub.

19. The system of claim 16, wherein the token burn function comprises instructions to: determining that a current time stamp is not less than an expiry time; based on the determining, transfer the transaction amount from the first pending digital token balance to a first client account; and generate a failed token burn confirmation receivable by the PNS hub.

20. The system of claim 16, wherein the token mint function comprises instructions to: determine that a current time stamp is less than an expiry time; based on the determination, transfer the transaction amount from the second pending digital token balance to a second client account of a second user of a second bank; and generate a confirmation indicating a successful token mint, the confirmation receivable by the PNS hub.

21. The system of claim 16, wherein the token mint function comprises instructions to: determine that a current time stamp is not less than an expiry time; based on the determining, subtract the transaction amount from the second pending digital token balance; and generate a confirmation indicating a failed token mint, the token mint receivable by the PNS hub.