CN114270385A - Method, apparatus and computer readable medium for transaction management across multiple heterogeneous computing networks - Google Patents

Abstract

A method and apparatus for providing communication between disparate computing networks, such as a distributed ledger network. Ledger-agnostic overlay networks and computing architectures span a range of digital communication networks, including transaction-only DLT networks, such as bitcoin DLT, smart contract-based DLT, such as etherhouses, and traditional centralized systems. The transfer of transaction information across heterogeneous jurisdictional boundaries, payment networks, banking systems, public and private distributed ledgers, internal corporate accounting systems, and exchanges is achieved.

Description

Method, apparatus and computer readable medium for transaction management across multiple heterogeneous computing networks

Data of related applications

This application claims priority to U.S. provisional application No. 62/839,971, filed on 29.4.2019, the entire disclosure of which is incorporated herein by reference.

Technical Field

The invention relates to transaction management of value transfer across multiple heterogeneous computing networks.

Copyright notice

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the patent and trademark office patent file or records, but otherwise reserves all copyright rights whatsoever.

Background

Most financial transactions involve value transfers and require coordination between multiple proprietary system ledgers, such as ledgers of two different financial institutions. Global financial institutions may send and receive information regarding financial transactions over SWIFT (financial telecommunications institute over global banking) networks in standardized message formats, such as MT103 or ISO 20022. The SWIFT messages allow for the transfer of payment instructions between financial institutions. SWIFT does not facilitate the transfer of funds. The payment instructions must be settled through the agency accounts of the institutions in the traditional banking system. Each financial institution must be a bank or affiliated with a bank. Settlement is a complex process that compares ledgers between different systems of each bank involved in a transaction. This process is reliable, but relatively slow and inefficient.

Even simple transactions such as payments and exchanges often involve more than one proprietary system. More complex transactions (purchases, loans, etc.) almost always involve more than one ledger. Examples of common transactions involving multiple ledgers and/or accounting balances include:

escrow (deposit/withdrawal), value is transferred to an agent or network to ensure security and/or convenience.

Remittance (cross-border payment), transferring value between payment networks.

Cross-provider transactions (e.g., PayPal to AliPay), banks and payment providers store the value of depositors on internal ledgers.

Cross-distributed ledger transactions (e.g., bitcoin to etherhouse) in which units of value are transferred or traded by wallet owners of different DLT vendors.

Corporate finance (internal accounting < - > external financial finance), where government and cross-country companies typically have dispersed accounting systems, transact multiple currencies, and have complex governance structures.

Cross Exchange Operations, where a trader typically owns multiple accounts at different exchanges for maximum liquidity. Transfers between exchange accounts can be expensive and time consuming and involve cross ledger transactions.

Asset transition, i.e. the transition of an asset from one type to another, which may involve binding/unbinding of rights (e.g. separating the voting right from the actual ownership).

Distributed Ledger Technology (DLT), such as blockchains, has been used to transfer value through decentralized networks, with alternative and irreplaceable assets represented by digital tokens and packaged therein. DLT network providers, the parties that develop and maintain the distributed ledger protocol, continue to proliferate and innovate, resulting in a wide range of DLT products, each with its own advantages and disadvantages. For each DLT product, the transaction is recorded on the ledger based on confirmation of completion by the consensus mechanism. DLT has the potential to decommission traditional banking systems and allow either party to transfer value directly to the other. While the purpose of DLTs is to eliminate the intermediary party, one constraint on the utility of DLT networks is that digital tokens are typically native and lock onto the underlying DLT that created them. Each DLT network may be designed to achieve specific goals and therefore may have its own tokens, protocols, consensus mechanisms and ontologies. Thus, transactions between DLT systems, i.e., "cross ledger" transactions, need to be reconciled in a manner that is not materially different from the coordination required between traditional data systems. This constraint, if not mitigated, limits the headroom of DLTs because it limits participants to a walled garden, limiting scalability and extensibility.

In addition, most business and financial services are built on traditional centralized ledger (relational or NOSQL database) technology. These traditional diversion providers are responsible for the vast majority of transactions today. In order to conduct meaningful business in the foreseeable future without forcing participants to choose either a fully "on chain" (DLT only) or fully traditional trading approach, the trading system must effectively span both traditional centralized and distributed ledger systems. The framework for providing seamless transfer of value within and between centralized and distributed vendors provides a significant effect for ever-growing blockchain products.

In 2014, two leading distributed ledger companies, Ripple and Stellar, introduced a cross-border value delivery approach that reflects the known "Nostro Vostro" technology. These techniques provide an effective value transfer model, but these methods do not support an integration framework that is independent of the respective Ripple and/or Stellar networks. Thus, all transactions, even between traditional or third party vendors, rely on traversing these networks. Furthermore, these approaches do not include an integrated model for pricing transactions from third party centralized or distributed exchanges, which is a significant limitation when liquidity on their network is limited.

In 2019, Accenture and JP Morgan published a paper entitled "realizing cross-border high-value transfer by using distributed ledger technology", and a result of a method for promoting cross-ledger value transfer is introduced in detail. At the heart of this approach is the bridging between ledgers using Hash Time Locking Contracts (HTLCs). While this approach breaks the dependency on any single ledger, it has several limitations. First, the use of HTLCs requires direct communication and coordination between the sender and receiver (exchange of the hash key). Second, the HTLC mechanism requires a ledger that supports smart contracts and therefore cannot be used in DLTs that do not support smart contracts, such as Bittercoin, Ripple, permanent Star (Stellar), or traditional centralized systems. These limitations make this approach unsuitable for facilitating many types of value transfer approaches.

In addition to not being able to efficiently support transactions across multiple ledgers or other communication networks, known systems are also unable to efficiently support the following transactions: converting currency, tokens, or assets; including multiple jurisdictions (jurisdictions) or policies; the need to change the object form (split/recombine assets); across multiple banking networks, payment providers, or transfer service providers (transfer service providers).

Disclosure of Invention

The disclosed support embodiments overcome all of the limitations described above with respect to transferring across networks. For simplicity, the terms "transfer" or "network transfer" as used herein include any type of transaction or conversion. While Distributed Ledger Technology (DLT) simplifies value transfer within a network, most transactions involve more than one ledger — an extensible, repeatable framework is required to record transactions that affect more than one ledger. The disclosed embodiments coordinate cross ledger transactions, simplify the mortgage and transfer of value, track assets and obligations across heterogeneous systems, simplify oversight, and maintain necessary liquidity in the underlying ecosystem.

The disclosed embodiments include ledger-independent overlay networks intended to span the scope of digital transfer networks, including transaction-only DLT networks like bitcoin DLT, smart contract-based DLT like etherhouses, and traditional centralized computing systems so that value transfers can be made between and within them, spanning heterogeneous jurisdictional boundaries, payment networks, banking systems, public and private distributed ledgers, intra-enterprise accounting systems, exchanges, and the like.

The disclosed embodiments include financial Ontology (financial Ontology), a grammatical independent model of financial transactions, a catalog including value transfers, transfer information terms, and related items, and a translation schema that converts heterogeneous embodiments into applicants' grammatical independent model.

The disclosed embodiments also include a transaction service bus module that breaks down the details of independent value transfer systems (e.g., DLTs, payment networks, banking systems) by providing a global interface for value movement (and other financial transactions).

When a cross-network transaction is proposed, the transaction service bus module examines the proposed transaction and lets the path planning service find a potential transfer path of value from the source to the ultimate recipient using a series of chained sub-transactions between transfer providers. The sender (or a representative of the sender, which may be an artificial intelligence engine) may then select a preferred route based on preferences for speed, cost, or reliability.

The sender then authorizes the preferences and engages a Chained Transfer Handler module in connection with the Transfer system of any package to manage value Transfer across different networks. Alternatively, the transaction may be initiated by an external source that sends a value and delivery indication to the inbound source wallet. The route planning service module is executed to determine an optimized transfer path comprising a chain of sub-transactions, and the chain transfer handler executes the transactions in a controlled manner.

One aspect of the invention is a method for connecting a heterogeneous computing network and a transfer provider to complete a conversion transaction. The phrase "conversion transaction" as used herein refers to a transaction that includes value across a ledger or across a network, requires currency/asset conversion, includes multiple jurisdictions, or requires object decomposition and/or reorganization. The method comprises the following steps: receiving information transferred across networks, i.e., transactions that must span at least two networks, providers, ledgers, asset classes or forms, or value types; traversing a graph structure to find feasible paths between a source and a target, the graph structure formed by a multi-agent system that crawls the network and neighboring bridges to create and maintain a network topology, stored as a graph structure of nodes, wherein each node in the graph structure has an associated set of attribute variables that specify bridge characteristics and a logical network interface with at least one node in another network; generating transaction routing information according to the graph structure to implement the transaction; determining a transfer path from the transaction routing information, the transfer path including a set of sub-transactions to ensure correct execution of the cross ledger transaction, the determining including checking a transfer information term directory and a translation schema to convert an implementation of the heterogeneous network provider into an optimized transfer path through a syntax independent model and modeling the sub-transactions according to the syntax independent model; initiating a complex transfer through a cross-network delivery model; through the complicated transfer of the independent ledger records, the independent ledger uses zero-knowledge proof to realize invariance and privacy; and, performing the sub-transactions by applying the logical interface to transfer value within and between the at least two networks, thereby effecting the cross-network transaction.

Node pairs and corresponding sets of attribute variables in the graph structure may define a bridge data structure that provides programmatic connections between node pairs, where at least some of the node pairs correspond to accounts in different networks.

The bridge data structure may specify at least one source wallet, at least one target wallet, supported units of value, and a transaction pricing model for transaction communications flowing between nodes in the node pair. The bridge data structure may specify conversion logic attached to the logical interface.

The generating of the transaction routing information may include traversing the graph structure and resolving the attribute variables according to a node traversal algorithm. Associated with each sub-transaction

Transfer details of the global chained transfer of links may be published on a distributed ledger, which may be separate from the transfer network being traversed.

Brief description of the drawings

Fig. 1 is a flow diagram of a method of providing communication between different networks in accordance with the disclosed embodiments.

FIG. 2 is a schematic diagram of a computer architecture for providing communications between different networks, according to the disclosed embodiments.

FIG. 3A is a schematic diagram of a node map in accordance with the disclosed embodiments.

Fig. 3B is a schematic diagram of a bridge metadata schema.

FIG. 4 is a schematic diagram of an example of a sub-transaction chain for completing cross-ledger changes, according to disclosed embodiments.

FIG. 5 is a schematic diagram of an example of simple value transfer, according to disclosed embodiments.

FIG. 6 is a schematic diagram of an example of a chained transaction in accordance with the disclosed embodiments.

Fig. 7 is a schematic diagram of an example of a transaction chain establishment process, according to disclosed embodiments.

Fig. 8 is a schematic illustration of chain transfer according to a disclosed embodiment.

Fig. 9A and B, in combination, illustrate an example of a state diagram for chain transfer in accordance with the disclosed embodiments.

Fig. 10 schematically illustrates an example of operations for a bridge to complete a mortgage transfer, in accordance with the disclosed embodiments.

Fig. 11 schematically illustrates an example of a bridge completing a settlement transfer operation, according to the disclosed embodiments.

Detailed Description

FIG. 1 illustrates a method of interfacing a heterogeneous DLT system for performing conversion transactions, according to disclosed embodiments. At 1002, information is received for the desired/required cross-ledger transaction that spans at least two different networks, such as two different DLT networks. At 1004, the multi-network graph structure is read. The graph structure may be created by crawling nodes corresponding to spanning bridges. Each node in the graph structure may have a set of associated attribute variables as node metadata. Attribute variables may include native value units (tokens) of the corresponding network, identification of smart contracts that implement the tokens, wallets or accounts for bridging, sources of value available to users, and APIs and network interfaces with other networks. At 1006, transaction routing information is generated to effectuate the transaction by traversing the graph structure according to a node traversal algorithm and detecting bridge nodes that facilitate the desired transaction. At 1008, a transfer path is selected by the source based on the preference to use the transaction routing information and the transfer is initiated. The required transfer path may include a set of chained sub-transactions to ensure proper execution of the requested cross ledger transaction. At 1010, the sub-transactions are performed using the designated interface to implement the cross-network transaction. The sub-transactions are executed over the heterogeneous network using an ontology mapping that translates the grammar-independent execution instructions into specific instructions identified by the underlying transfer network. The overall transaction and all of the sub-transactions may be recorded on a ledger, which may be different from the ledgers that participate in the sub-transactions. The independent ledger can provide invariance with zero knowledge proof while maintaining transaction privacy. Note that the sub-transaction chain may include transactions in the source network, the target network, and other networks as connections between the source network and the target network.

FIG. 2 schematically illustrates a computer architecture for implementing the method of FIG. 1 and other transition transitions, in accordance with disclosed embodiments. The architecture 2000 is comprised of a transaction service bus module 2002, a chained transfer processing module 2004, a planning service module 2006, a bridge service module 2008, a pricing and liquidity module 2010, an independent transaction ledger module 2012, and an out-of-band transfer/recycling module 2014. Each module of the architecture 2000 may communicate with other modules as needed through a network computing environment.

The modules described herein may be implemented as computer executable code within a single computer processing unit or multiple computer processing units. One or more modules may be implemented remotely from the other modules in a distributed architecture. The following description of the functionality provided by the different modules is for illustrative purposes and is not meant to be limiting, as any module may provide more or less functionality than is described. For example, one or more modules may be eliminated, and some or all of its functionality may be provided by other modules.

As described above, automatic execution of a converted transaction (e.g., an inter-network (cross-ledger) transaction) is accomplished upon receipt of a transaction data structure specifying details of a proposed cross-ledger transaction (e.g., a value transfer). The data structure may include transaction details (e.g., source, destination, amount, currency) and may be created by a party authorized to initiate the transfer. For example, the Transaction data structure may be (Transaction Type, Transaction current, Ether, Source 1address, Destination 2 address).

The transaction service bus module 2002 parses the transaction data structure and determines one or more feasible paths (including expected pricing, fees, and transaction time) from the graph to execute the specified transaction across multiple networks. The path determination is based on a network model determined by the routing planning service module 2006 (in a manner described in detail below), including a transaction chain composed of a plurality of sub-transactions, each having a source and a destination. If asset transitions are required on the path, the pricing and liquidity module 2010 specifies the ratio between source and target assets required for bridge traversal based on bridge metadata (described below). The chain transfer processing module 2004 executes the sub-transactions (with zero knowledge proof to protect privacy) as a sequence of network transfers, confirmations, and bridge traversals (specified by the bridge service module 2008, described below) to ultimately affect the value transfer of the specified converted transaction. Out-of-band transfer module 2014 may be used to include non-network (manual or non-instrumented) transfers. The out-of-band transfer module 2014 is used for rebalancing account resources as needed according to the consumption of the liquidated funds in the sub-transactions. Transaction records may be recorded by the independent transaction ledger module 2012. The disclosed embodiments may utilize the compliance framework described in U.S. published patent application No. US20190164151a1 to secure cross ledger transactions and perform compliance verification on different networks.

The above-mentioned network model is created by the route planning service module 2006 using a multi-agent system that crawls various networks (that may be expected to participate in cross-ledger transactions) and bridge nodes to determine feasible paths for value transfers between sources and targets. The topology between networks may be stored as a graph structure of nodes. Node attribute variables, which will be described in detail below, may include a description of the value units (tokens) that are native in a particular network, traversal methods, accounts for bridging, cost and pricing methods, and associated APIs and network interfaces for communicating with external sources.

Fig. 3A is a schematic diagram of a simple graph structure 3000 of an inter-network topology traversed by the route planning service module 2006, according to an embodiment. For example, network 3002 may be a Bitcoin (bitcoil) blockchain, network 3004 may be an etherhouse (Ethereum) protocol blockchain, and network 3006 may be a Stellar protocol blockchain. In fig. 3A, three different networks (3002, 3004, and 3006) are shown, however, any number or type of different networks may be included in an embodiment. In fig. 3A, each network has bridge nodes illustrated, each node representing an edge of a bridge providing inter-network communication. Node B is a bridge node of the DLT network 3002, node M is a bridge node of the DLT network 3006, and node Y is a bridge node of the DLT network 3004. Each bridge node corresponds to an account/wallet in the respective DLT network. A pair of bridge nodes. For example, nodes B and M define a bridge between DLT network 3002 and DLT network 3006. Each bridge node has a corresponding metadata record indicating the set of attribute variables described above. Further, the bridge characteristic data is stored as bridge metadata. Each pair of bridge nodes connected by wires in fig. 3A, and the associated metadata (node metadata and bridge characteristic metadata), define a bridge. Of course, there may be any number of nodes and bridge nodes in the graph (typically thousands), and fig. 3 is a simple graph for purposes of illustration.

As an example, metadata record 3010 is stored in association with node B, metadata record 3012 is stored in association with node M, and bridge feature metadata record 3014 is stored to define a connection between node B and node M. Thus, the bridge is defined by metadata records 3010, 3012, and 3014 (collectively bridge metadata) of the graph structure 3000. A more detailed schema 3100 of bridge metadata according to an embodiment is shown in fig. 3B. Mode 3100 includes wallet attributes 3102 (which may be stored as node metadata in the graph), token attributes 3104 (which may be stored as node metadata in the graph), data type attributes 3106 (which may be stored as bridge feature metadata in the graph), and interface 3108 (which includes pricing models and other logic, which may be stored as bridge feature metadata in the graph). Although the metadata records 3010, 3012, and 3014 of fig. 3A are shown as three distinct records, the data therein may be combined into a single bridge metadata record or divided into additional records according to the architecture of fig. 3000. The disclosed embodiments use standard schema to specify metadata. Bridges act as connection paths between different networks. This figure allows the transaction path to locate and use bridges across the ledger transaction chain (or in some cases within the ledger transaction, as described below). The metadata records 3010, 3012, and 3014 are discussed in more detail below in connection with the bridge function. The data in diagram 3000 is stored by the bridge services module 2008 and traversed by the route planning services module 2006. The transaction service bus module 2002 provides optimized transaction routing information, including the sub-transactions required to implement the converted transaction. When the route is displayed, the source account may initiate a chained transaction based on the graphics and user preferences, such as one or more of transaction time, conversion rate, and cost load. The chained transfer processing module 2004 manages transactional execution including proposed sub-transactions to ensure proper transfer execution (or rollback) through final delivery. Route planning and path optimization are described in more detail below.

The transaction service bus module 2002 implements the financial ontology as a grammatical independent model of value transfer, a directory of transfer information terms and related items, and a translation schema that converts heterogeneous implementations of various networks into grammatical independent models. The chain transfer processing module 2004, executes the sub-transactions on the heterogeneous network through the transaction service bus module 2002, the transaction service bus module 2002 translates the proposed sub-transactions from the syntax independent instructions to the network implementation.

Financial ontologies are abstraction layers that provide a common language for financial transactions. The ontology defines the interfaces of services, functions, and objects encountered in the financial system. The ontology provides an interoperability layer that isolates differences between various service provider implementations, providing a flexible modular system in which various components are loosely coupled. Ontologies make it possible to combine individual financial services into complex financial systems, even if the individual services are not designed to work in concert. Since the payment chain is designed to connect any transfer network to any other transfer network, the generic service definition reduces the complexity of the interconnected N systems from N factorial (N |) to N. Thus, the body is designed to make large scale integration easy to handle. The standard functions and interfaces of this technique will be discussed below.

However, developing a common abstraction for each underlying vendor for ease of processing may reduce the expressiveness of a single vendor (i.e., the specific functionality that may be exposed by a particular vendor). The disclosed framework has two mechanisms to ensure that expressiveness is not lost for ease of handling. First, a "wrapper" may disclose functionality that is specific to a particular provider/network or subclass of providers/networks. In this case, the relying client can directly interface with the implementation-specific wrapper to take advantage of these unique functionalities. However, this establishes a direct dependency between the client and the service implementation, tightly linking the client with the service implementation, limiting modularity and scalability. The implementer may decide whether it is worth increasing the dependency on a particular vendor/network in order to obtain a unique functional tradeoff. Furthermore, the ontology comprises a data structure that allows to carry additional data with locally defined specifications in the generic interface. The core data structure includes other data (OtherData) fields with a specification that includes type and data information, enabling a parser to examine the data and parse if a format is identified. Such an architecture may enable point-to-point communication between systems, which may require additional data to be carried in the architecture used by all parts of the system. Thus, a coordination function, such as the one exhibited in the chained transfer handler, can execute functions on a global scale without sacrificing the unique functionality of a particular transfer vendor.

As described above, the bridge server module 2008 provides logical interfaces, bridges between the various DLT networks and transfers transactions and value between them. The network bridge may accommodate token types representing different assets and value units. The bridge server module 2008 implements bridging to create logical cross ledger connections based on model and node metadata. In essence, a bridge is a data structure that defines the behavior of a transition. The bridge server module 2008 reads the metadata records 3010, 3012, and 3014 (fig. 3) and determines the bridge type, assigns one or more Vostro wallets(s), assigns nosstro wallets, identifies the cost, determines the pricing model, assigns out-of-band restocking when necessary, and identifies and appends the conversion logic in the manner described below. The bridge operator, i.e., the entity or system process with the appropriate authority to operate over the two networks spanned by the bridge, may be represented in the metadata record 3014. A bridge account is created or assigned to connect the source network and the target network. The source account in the bridge is typically a hosted account, for which the bidirectional bridge support should be active, the target should be active, and the linked sender may be required to make some type of transfer.

The bridge server module 2008 may create and store various classes of bridges with a range of options in terms of price discovery (hook, float, exchange), accounting (translation, contract), and migration (in-band, out-of-band). These classes provide a common interconnection pattern that facilitates repeatable processes to execute and record value movement across networks. The included bridge classes consist of options in areas of price discovery, accounting, and migration (e.g., a combination of in-band and out-of-band), as specified by the metadata model. The different networks are connected together using bridges, so that the bridges facilitate value transfer between the networks and can extract charges for services as specified by the metadata. Bridges establish connections between networks or value units, receiving and relaying value transfers for different transfer networks by controlling:

transfer mode: mortgage (by reference), settlement (by value), linkage or trade-conversion (changing, splitting assets)

Pricing: exchange, algorithm and hook

Synchronization: synchronous or asynchronous (with hedging and risk management).

Cost, capital supply flow, and mobility management

Each bridge includes an inbound account and an outbound account (e.g., associated with nodes B and M in FIG. 3, respectively.) these accounts may be owned by a bridge operator with "System" privileges, operating as part of a transaction chain. when a bridge is created, these accounts are provided as configuration parameters in bridge metadata. the units of value supported by the inbound and outbound accounts define bridge-supported connections. supporting connections is necessary to transfer routes. Using the example in FIG. 3, where transactions originate from a bitcoin ledger (DLT Network 3002) and span into the star Network Stellar Network (DLT Network 3006), the inbound (Vostro) account for a bridge (e.g., B in FIG. 3) becomes the target account for initial sub-payments in the transaction chain And sending value. The Nostro account should be active, meaning that the processing thread should be entitled to initiate a transaction from the account. For Dark Pool transactions (Dark Pool transactions), i.e., transactions with a preset value, there must be sufficient value in the inbound bridge account before a chain transaction is initiated. The bridge may be loaded from the bridge server module 2008 into the list of chained transfer processing modules for route planning and payment execution usage. The class used to execute the bridge is configuration dependent.

For inbound and outbound wallets that are available for use by a bridge, the list of possible routes from one wallet type to another (given the desired target value units) can be determined by evaluating the supporting tokens indicated in the bridge metadata. The route planning service module 2006 uses this list in mapping paths from sources to destinations. For example, diagram 3000 of fig. 3 shows two possible routes between DLT network 3002 and DLT network 3006. The first route is represented by 2 and the second route by the combination of 1 and 3.

In addition to the bridge's configuration details, the operational attributes of the bridge class are determined by injection-dependent details and may be stored as bridge metadata. In the disclosed implementation, the operational changes of the bridge can be divided into 6 attributes defined in the metadata: transfer mode, pricing mode, restocking mode (reload Model), order, direction and cost. The transfer mode defines how ledgers are connected together by a bridging wallet. Five types of transfer models can be implemented: mortgage (deposit), settlement (withdrawal), and transfer (NostroVostro), transformation (Transmute) (ledger change), and transformation (Transform). The model to be used may be determined by the required transfer mode, the ability of the bridge operator to perform the publish/burn operation, the availability of the escrow wallet, and other business requirements.

The pricing model defines a proportion of the number of target ledger tokens sent per source token received by the bridge. Implementations of the pricing model include: link (1:1), index point (Peg) (fixed scale), algorithm (relying on injection plug-in), or external (from a third party source, such as an exchange). The replenishment model defines a mechanism for refilling the outbound wallet when excessive unbalanced flow occurs and resources must be relocated. The realization of the replenishment model comprises the following steps: none, manual, transfer and swap. Bridges have a sequence (serial/parallel) and direction (unidirectional/bidirectional) indicating how they can perform.

In the case of multi-ledger issuance, a bridge may implement cross-ledger translation. This can be used when the official record of ownership is on a separate ledger, rather than on a ledger for transfer, or when the official record is the sum of ownership records on affected ledgers. The conversion allows tokens to be issued on multiple ledgers and/or provides a way for tokens issued on one ledger to "flow" to another ledger. When a token is transferred from one ledger to another, the total number of tokens in circulation remains the same, while ownership records are transferred from one ledger to another.

For example, funds exiting the ledger are sent to the source ledger base wallet. This transfer may also be a kind of hosted transaction, holding tokens without moving them. An equal amount of token circulation is issued on the target ledger from the issuer (Wallet, account or smart contract) or Cold Wallet (Cold Wallet) to vendor B's outbound Wallet for delivery to the target. After a successful delivery, the iissuer. withdrawal function is called on the source ledger, removing tokens from circulation.

An example of completing a sub-chain of transactions across ledger conversions, i.e., creation of one value unit corresponds to destruction of another value unit, is shown in the flow chart of FIG. 4. An example of a conversion transaction is the movement of shares representing actual ownership from one ledger to another ledger. At 4002, value is sent from a Source Wallet (Source Wallet) to a base Wallet (base (escrow) Wallet) using vendor a (provider a), which is a bridge inbound Wallet. At 4004, tokens are issued from vendor B's Issuer Wallet (issue Wallet) and sent to vendor B (provider B)'s base Wallet (bridge outbound Wallet based on bridge attributes). At 4006, vendor B's Base Wallet (Base Wallet) sends value to vendor B's target Wallet (Destination Wallet). At 4008, after the transaction is completed, an equivalent amount of tokens are destroyed from the vendor a base wallet. It should be noted that this process assumes that the chain transfer processing module 2004 has a mechanism to detect and attribute transactions on the source and target ledgers, as well as a mechanism to create tokens on vendor B and burn (destroy) tokens from the base wallet on vendor a. Access to these rights may be indicated by bridge metadata. Additionally, steps 4004 and 4008 can also be skipped by directly issuing and burning tokens through the distributor wallet.

In some cases, it may be desirable to convert the rights represented by a token from one form to another. For example, it may be desirable to convert the loan rights represented in the convertible ticket to equity. In this case, a fixed-scale conversion may be performed using an earlier conversion function (e.g., 1-share or 10-share 1-share). However, it may be useful to divide the rights of a common share into different tokens, the functions of which differ, one representing the voting right and the other representing the actual ownership of the income or equity return. In this case, a customized transaction translation bridge is required. For each type of token delivered to the inbound wallet, more than 1 share may be generated and delivered to the target. The basic sequence of converted transactions (Transform transactions) is the same as converted transactions (Transmute transactions), but the bridge must execute instructions, issue 2 or more types of instruments in the outbound transaction, and must deliver each instrument to the desired target wallet. Conducting a revocation transaction may merge rights into a new composite right (e.g., merge voting rights and actual ownership into a common stock). The translation bridge may be an intra-ledger bridge, i.e., not necessarily spanning multiple networks.

An exchange bridge is a special bridge in which price discovery or money flow involves in-band or out-of-band (OOB) of the exchange. In this case, the amount of funds required for the source transaction depends on the current total price (integer of order book) for the exchange's peer transaction. The funds are then replenished in bulk, either in-band or out-of-band. In some cases, the inbound transfer may be an in-band transaction to an exchange account. In this case, the Nostro account will also reside in the exchange. The Nostro account may use the same vendor as the Vostro account if the exchange cannot be made over the vendor network, but supports a different currency. Other types of bridges are discussed below in conjunction with fig. 10 and 11.

The disclosed embodiment includes a transaction service bus module 2002, also referred to as "InfiniXchange^TM", which is an interface architecture that includes a library of mapping and service interfaces and data structures for DLT and traditional value transfer networks (e.g., etherhouse (Ethereum), PayPal, SWIFT) and value transfer models. As described above, the interfaces required by the bridge may be specified in the bridge metadata. These interfaces disclose the functions required to execute the programs for converting transactions. The InfinXchange wrapper implements a hub and spoke model for integration by which services dependent, such as the chained transfer processing module 2004, need only integrate once with the required interfaces to coordinate transactions in the wrapped transfer network.

The transaction services bus module 2002 may be implemented as an abstraction layer that provides a generic interface for in-book transactions. To participate in a cross-ledger transaction as a source or target ledger, a transaction provider may be wrapped in an InfinXchange wrapper. A wrapper is an executable file that is integrated with the underlying transfer provider to perform transactions and react to activities in the network. The wrapper discloses a generic interface defined in the financial ontology. These interfaces separate the business and transaction logic associated with chained transactions from the transaction provider's specific implementation details and allow for extensive reuse of transaction patterns.

Transaction providers/networks vary greatly in implementation and integration patterns. For example, blockchain networks require a client to interact with the nodes, and many payment networks expose APIs. The API is implemented using REST, SOAP, RPC, and other schemas. An enterprise accounting system typically runs on a relational database without a specific integration schema. A library of transaction service bus modules may be developed to integrate with a transaction provider implemented in any of these ways, thereby providing a universal model of interaction with the underlying services.

The library of transactional service bus modules connected to each vendor can be injected into the chained transfer process modules 2004 using an abstract factory schema. An abstract factory schema is a known mechanism for packaging a set of individual factories with a common theme without specifying their concrete classes. For example, client software may create a concrete implementation of an abstract plant and then use the general purpose interface of the plant to create concrete objects that are part of the subject. The factory schema separates the implementation details of a set of objects from their general purpose.

Also, interfaces defining connections can be found in the financial ontology. When the vendor is initialized, it issues its support for service interfaces and functions to the calling service. This enables the calling service to identify the services and methods supported by the transaction provider. Using this information, the calling service may determine the eligibility of the provider to support the transaction type. Any vendor participating in a chain transaction should support IPaymentService abstraction. A short list of services that are often used in a financial ontology is described below.

IPaymentService: all value transfers are performed. The functions include: estimating the cost of the transaction, executing the payment, verifying its completion and obtaining a list of payments from a source

Iwallelterservice: identify account balance (amount of value available for a particular wallet address) and use it to obtain wallet details (e.g., supported currency, date of creation)

IWalletValidatorService: it is determined whether the wallet is eligible for transactions, including ownership of the entity claiming to own the wallet.

The IPayment service and IIssuer service may cover any payment system and transfer money through the vendor. Examples of pseudo code and associated data structures for the interface can be found immediately below.

public interface IIssuerService

{

///<summary>

///Issues an amount of new tokens to a designated wallet.

///</summary>

Task<ITransaction>IssueAsync(IWalletIssuerActive wallet,IAmount amount)；

///<summary>

///Destroys an amount of new tokens from a designated wallet.

///</summary>

Task<ITransaction>DestroyAsync(IWalletIssuerActive wallet,IAmount amount)；

///<summary>

///Freezes a token.

///</summary>

Task<ITransaction>FreezeAsync(IWalletIssuerActive wallet,IToken token)；

///<summary>

///Retrieves token details.

///</summary>

Task<ITokenDetail>GetTokenDetails(IWalletActive wallet,IToken token)；

}

public interface IPaymentService

{

///<summary>

///Calculates available routes to deliver amount to designated wallet.

///</summary>

Task<List<IPaymentOption>>PrepareAsync(IWalletActive wallet,IWallet destinationWallet,IAmount amount,IFilter filter＝null)；

///<summary>

///Executes payment using IPaymentOption path using authority of active wallet

///</summary>

Task<ITransaction>SubmitAsync(IWalletActive wallet,IPaymentOption payment)；

///<summary>

///Cancels ongoing payment transaction using authority of active wallet

///</summary>

///<remarks>

///Not all providers will support this action

///</remarks>

Task<ITransaction>CancelAsync(IWalletActive wallet,string uuid)；

Event Complete(ITransaction trans)；

}

To understand the application of the transaction service bus module 2002 in complex cross ledger transfers, it is helpful to first discuss how a simple payment system works in the transaction service bus module 2002. Fig. 5 schematically shows an example 5000 of a simple transfer. User x (user x), the sender, wants to send value to user y (user y), the receiver, on the same ledger (e.g., PayPal transfers). First, the sender will propose a transfer by specifying the function (ipaymentservice. prepare) the recipient (by address) and the currency/amount to send (usually expressed in the amount the recipient expects to receive). The system will check the validity of the proposed payment (assessing cost/gas, policy, valid recipient, sufficient funds) and provide one or more options (in many systems, only one option is available) for the amount that must be sent to effect the intended delivery. If the transfer terms for an option are acceptable, the sender will initiate the transfer by signing the transaction (login, privacy, etc.) (step 1, paymentservice. The system validates the transfer (step 2, event ipaymentservice. initiated) and moves the value by adjusting the account balance (decreasing the source balance and increasing the destination balance) while extracting the transfer cost (step 3). After the transaction is completed, a notification (issued IPAymentservice. completed) will be sent. The new balance is reflected in the source and target wallets.

In accordance with the disclosed embodiments, these same functions may be used in conjunction with the novel elements of the disclosed embodiments to initiate a chained transaction. FIG. 6 schematically illustrates an example 6000 of a chained transaction (including multiple sub-transactions completed in a particular order) according to disclosed embodiments. The example in fig. 6 may use the architecture (architecture)2000 of fig. 2 to complete the transaction. The single ledger transfer in the chained transaction uses a method consistent with simple payments, with the coordination activities managed by the chained transfer processing module 2004 of fig. 2.

As shown in fig. 6, the sender uses the InfinXchang interface for transfer (ipaymentservice. In this example, user X wishes to transfer value from vendor A (e.g., a first DLT network) and an account on vendor A to user Y's account on vendor B (e.g., a second DLT network). In step 1, the fig. 2 route planning service module 2006 looks for available paths by traversing a node map (e.g., node map 3000 of fig. 3A) to identify bridges that can provide feasible paths between source and target networks from bridge metadata and obtain a cost for each branch of the migration. There may be 0 to many paths available to facilitate the transfer. Various techniques, including artificial intelligence, may be used to narrow the list of available options or prioritize the possible paths. These paths may include all necessary InfinXchange interfaces and business logic derived from bridge metadata.

The sender or an automated algorithm may select the desired path and initiate the desired transfer (ipaymentservice. The chained transfer processing module 2004 writes the transactions into the ledger of the system transaction ledger 2013 (fig. 2) to ensure auditability and recoverability in the event of a system failure. The record may be obfuscated using zero-knowledge proof techniques to provide invariance without compromising transaction privacy. The chained transfer processing module 2004 also issues an event (IPAymentservice. initiated) to indicate the transfer. The chained transfer process module 2004 passes the user's signature authority through the ipaymentservice. sub-mit function (step 2) to perform sub-transfers on the source ledger using the intended routes, which includes traversing through different networks through one or more bridges. At the time of the child transfer, an event (ipaymentservice. initiated) will be raised because the transfer is linked to the parent transaction in the external transaction ledger. Upon completion of the transfer to the source bridge account (ipaymentservice. completed), an event will be raised to mark the completion of the transfer, informing the handler to initiate the next part of the transaction. The transfer is initiated through a bridge (ibridservice. sub). After bridge transfer (ibridge service. completed) is complete, chain transfer handler module 2004 initiates a transfer on the outbound ledger using ipaymentservice. submit (step 4) to deliver value to the target account or another branch in the chain depending on the path. Initiation of the transaction (ipaymentservice. initiated) causes an event. The transaction is connected to a parent transaction in the external transaction ledger of the independent transaction ledger module 2012. Value is transferred to the target account and an event (ipaymentservice. completed) is raised at step 5. As the last step in the chain sequence and triggers an event, marking the completion of all transactions. All sub-transactions are recorded in the ledger of the system transaction ledger 2012.

Alternatively, the chain transfer may be initiated from an external system, skipping steps 1 and 2 of fig. 6, by passing the value to the bridge source account with the pass-to target instruction. Upon receipt, the bridge account may issue an ipaymentservice.completed transfer. Chained transfer processing module 2004 reads the event and determines if there is a legitimate payment route. If there is a route available, the chain is initiated with funds held in the bridge source account. If the transfer is successful, the funds are released. If the transfer fails, the funds may be returned to the source. If the source ledger supports intelligent contracts, initiating a transaction may utilize an on-chain escrow method to ensure atomicity of the transaction.

FIG. 7 is a schematic diagram of an example transaction chain construction process, according to disclosed embodiments. The illustrated process may be implemented by the architecture of fig. 2. Route planning service Module 2006 and Infmxchange^TMThe wrappers combine to identify the best transition path across the network nodes, given the transactions specified in the transaction data structure. In this example, the specified transaction is "transfer ABC tokens from user A node on Stellar DLT system to user B node on Ripple DLT system". The transaction data structure may specify a set of all available options, such as price and expected delivery time. At step 1, the route planning service module 2006 evaluates all possible routes and available bridges to perform the migration by traversing a graph of all nodes and bridges. The possible transaction paths are analyzed by reading the bridge metadata of the associated network and a bridge graph is built representing all connections between the supplier and tokens of the source ledger (Steller in this example) and the target ledger (Ripple in this example). The bridge graph may include all relevant bridge metadata identifying the connected bridges.

The route planning service module 2006 may apply a Breadth First Search (BFS) algorithm, a known graph traversal algorithm that traverses a graph layer by layer starting from a selected Node, to find all paths and return a list of Bridge Node Chains (Bridge Node Chains), i.e., a list of possible paths to complete a transaction. In this example, two possible paths (TransactionChain 1 and TransactionChain 2) are determined. In step 2, the route planning service module 2006 constructs a final transaction path based on the list and transaction requirements and conditions. For example, in the case where the transaction chain must deliver 1ABC token to the target wallet and the sum of the associated transfer fees equals 0.1 ABC tokens, then the source must transfer 1.1 ABC tokens. The construction of the final transaction path may take into account various preferences and attributes such as transaction fees, transaction confirmation time, and the like.

Fig. 3A may be used to better illustrate the selection of paths and transaction chains. Recall that in fig. 3A, fig. 3000 has three DLT networks, each having at least one node. Transactions may occur within a network (e.g., A- > B, Y- > Z). However, in order to cross between networks, for example to transact between nodes of different DLT networks, a bridge must be used. Without a bridge, there is no transition path between nodes a and Z, for example. To connect to the network, bridge accounts B, M and Y are created. A bridge is then established to connect these accounts. With bridge 1, for example, there is a route (A- > B1-Y- > Z) between A and Z. The second route exists through the connection of a third party network (A- > B-2-M-3-Y- > Z). The route planner of the route planning service module 2006 traverses the network graph and generates these routes as potential routes. The user (or automated service) may determine the best diversion path from the identified options based on preferences and other attributes.

Returning to FIG. 7, the ability to transfer value from one network or ledger to another may involve many potential paths and mechanisms, or no feasible path at all. When a user requests a payment delivery, a set of all available options, their prices and expected delivery times must be generated in substantially real time. In step 2 of fig. 7, the route planning service module 2004 collects all possible routes by evaluating all available bridges that can provide a path from the source node to the target node. Transaction service bus

After all the abstract paths have been computed, the routing plan service module 2006 builds one or more transaction chains according to the abstract paths. There are at least two ways to establish a chain, starting from either the target (default) or the source. The route planning service module 2006 starts with the target condition as a fixed point when starting from the target to the source. When starting with the source node as a fixed parameter, the route planning service module 2006 determines the value that the target node will receive if the transfer starts with 1 ABC. The route planning service module 2006 establishes a transaction connection from the source and accumulates all charges and transactions over the path. For example, if the total cost equals 0.1 ABC tokens, the recipient will eventually get 0.9 ABC tokens. The routing plan service module 2006 then builds an abstract path to the actual chain according to, for example, the following rules.

The route planning service module 2006 then selects all of the path chains and merges them into a single final transaction chain by removing duplicate links. As shown in fig. 7, the transaction chain includes transaction link 1 (transactionilink 1), transaction link 2 (transactionilink 2), transaction link 3 (transactionilink 3), transaction link 4 (transactionilink 4), and transaction link 5 (transactionilink 5). At step 3 of fig. 7, the transaction verification service (transactionivaliationservice) verifies whether the transaction path can be executed, for example, by checking whether each linked source wallet in the path has sufficient balance to submit the transaction and/or checking a self-referencing chain (self-referencing chains), i.e., the same node appears more than once in the chain. (the policy engine may verify regulatory compliance at each transfer node, for example, the systems and methods described in U.S. published patent application number US20190164151a1 may be used to verify regulatory compliance.) each viable transaction chain may involve fees and exchanges, and will have an estimated lead time. Before the user approves the transfer operation, the price and delivery time of the proposed transfer may be calculated for presentation to the user.

During the transfer of a chain of sub-transactions, or canceling the transfer before completion (if allowed), a network failure may occur. In this case, a rollback is required. In the case of charging an intermediate fee or conducting a transaction, it may not be possible to revoke the transaction without loss of value. In this case, the user may choose to restart the transfer chain to continue completion, roll back the transfer, or abort the transaction by declaring value in the current state. 8002 in FIG. 8 shows the success chain of the four sub-transactions (to complete the desired transfer transaction). All four sub-transactions (8002a, 8002b, 8002c, and 8002d) are successful.

However, depending on the configuration of the bridge, after a transaction failure, the system may automatically restart to pass on the value, or may stop and wait for user input. 8004 of FIG. 8 shows a chain transaction with sub-transaction 8004d failing. According to a configuration, a chained transaction may automatically initiate a rollback transaction upon failure. Roll-back transactions are only possible if each bridge used in the routing is a bidirectional bridge capable of supporting bidirectional transactions. 8006 of fig. 8 shows a rollback transaction. At 8006, sub-transaction 8006d has failed, at which time all sub-transactions 8006a, 8006b, and 8006c are "undone" by completing undoing the sub-transactions for each of these sub-transactions. Further, the transaction may be cancelled en route, as shown at 8008 and 8010. In transaction 8008, sub-transaction 8008b has been cancelled prior to execution, and thus sub-transaction 8008a has been cancelled. Alternatively, at 8010, sub-transaction 8010b is cancelled after execution, and both sub-transactions 9010a and 8010b are undone. Additionally, if the transaction initiator has a means to receive value through the intermediate ledger, value can be solicited directly from the stopped transaction, as shown at 8012. All sub-transactions, including reimbursement transactions, are recorded on the system transaction ledger module 2012. Fig. 9A and B show an example of a state diagram 9000 of a chain transfer in combination.

Each feasible route may involve a fee and a transaction and will have an estimated delivery time. The price of the proposed transfer must be calculated for submission to the user to support the transfer operation. The chain transfer processor 2004 is intended to provide a manageable alternative to atomicity (A) and to provide consistency (C), isolation (I), and persistence (D) consistent with ACID (see https:// en. wikipedia. org/wiki/ACID _ (computer _ science) patent delivery). The chained transfer process module 2004 coordinates cross-ledger payments by providing the following functions: ledger interoperability, routing planning, price and cost discovery, transaction management, transaction status and logs. The chained transfer processing module 2004 ensures high reliability end-to-end transfer across the network by:

post the proposed end-to-end transaction and all sub-transactions to a ledger (e.g., system transaction ledger 2012), with zero knowledge proofs at execution time to achieve traceability and reliability;

ranking the transfers using an interoperability framework, leveraging the transfer capabilities of the transactions across each network; and

ensure that each transaction is executed (or rolled back) successfully to deliver the value successfully.

Isolation (I) is provided by a generic IPaymentService plug-in that isolates each individual ledger transaction as a component in a larger flow. This plug-in framework provides a common model for processing transactions between different ledgers. Transaction management: transaction management provides persistence of chained payments (D). The CTH manages each step of the complex payment sequence to ensure that it can be executed even in the face of downtime or failure of the payment network. This component handles parallel or serial transactions, performing payment and bridge transactions.

Atomicity (a) cannot be guaranteed due to the irreversibility of some transactions (due to fees), long lead times and frequently changing market conditions, which are all characteristic of some chain payments. To account for the slip point (change in exchange rate or fee from the start of the transaction to the completion of the transaction), the CTH may freeze the transaction when a significant change occurs to allow the user to gauge whether he is willing to continue the transaction. In this regard, the transaction may be rolled back (at the expense of the fee), the value may be solicited in its existing form, or the transaction may be restarted to continue to completion (the user accepting the changed terms).

Since a chained transaction may involve more than one ledger, no single ledger involved will contain end-to-end traceability of the transaction. To ensure consistency (C), the independent transaction ledger module 2012 maintains an overall ledger to track the entire transaction and the connections to each sub-transaction. Chain transfers may be in series or in parallel, depending on the configuration of the bridge. Parallel payments are the fastest, but may require rollback locks and hedging because inbound delivery time delays are risky. Tandem delivery may require extensive use of point-of-slip management, requiring locking out of funds to support delays in inbound transactions.

When operating in tandem, bridges wait for verification of the completion of the initiated transaction (inbound) (ipayment. complete event) before initiating the chained transaction (outbound). When operating in parallel, outbound transactions may be initiated immediately upon verification of initiation of an inbound transaction (ipayment. initiated event). For parallel operation, the bridge operator bears the risk of delivery if the inbound (and all intermediate) transactions are cancelled or rolled back. Typically, a bridge operator will allow parallel operation only if the inbound network does not allow cancellation or rollback. Additionally, the bridge operator may require collateral or charge a large fee to compensate for the delivery risk. For tandem operations, the initiator may encounter a skid point risk, i.e., a change in delivery price from the initial terms set forth at the initiation of the transaction. For example, the fee or exchange rate of the downstream network may have changed since the start of the transaction. Bridge operators may offer price guarantees (no points of slipping) but typically add some cost to compensate for market changes or hedging strategies.

As noted above, in addition to providing a path for transactions across different networks, bridges may have various logic functions. Deposits are a special example of a bridge function. It involves hooking the deposited funds with an equivalent token (mortgage asset or debit) that is delivered to the user's internal account. Loans (IOUs) may be transferred to other users or traded for assets through centralized or decentralized exchanges. These tokens can redeem (settle) the value in the contract partner (counter) account by using the reverse flow, i.e., withdrawal.

The account balance in the contract counterpart pool should match exactly the total number of circulating internal tokens. Both balances should be published to the user. Some networks support the creation and destruction of tokens, while others require circulation in and out through cold purses.

Fig. 10 schematically illustrates an example of the operation of a network bridge to complete a collateral transfer. At step 1, value is sent from the source wallet to the hosting wallet (bridge inbound) using an external vendor (e.g., OOB, Cascade, PayPal, etherhouse (Ethereum)). At step 2, an equal amount of debit (a digital version of the deposit amount) is issued and sent from the issuer wallet to the base wallet. In step 3, the base wallet (bridge outbound) executes ipayment. transfer, sending value to the target wallet of the internal vendor. This mode requires the chain transfer handler module 2004 to have a method of detecting and determining transaction attributes on the source ledger and to execute transactions from the issuer wallet and the base wallet. Access rights to this rights may be granted at the time of bridge setup. Note that step 2 can be skipped, sent directly from the issuer wallet to the target wallet.

Settlement is the reverse of mortgage transfer. When a user wishes to remove value from the ledger and restore the value to its original form, a transfer process across the settlement bridge is initiated. Fig. 11 schematically illustrates an example of the operation of a bridge to complete a settlement transfer. In step 1, value is sent from the source wallet to the base account (bridge inbound) using an external vendor (e.g., OOB, Cascade, PayPal). At step 2, the escrow wallet (bridge outbound) performs an IGateway payment to send the value to the target wallet. In step 3, in response to the completion of the previous step, an equivalent amount of debit (digital version of the settlement amount) is recorded (i.e., destroyed) from the base (escrow) wallet. This mode requires the chain transfer processing module 2004 to have a method of detecting and determining transaction attributes on the source ledger and to execute transactions from the escrow wallet, as well as to burn tokens from the base wallet. Access rights to this rights may be granted as part of the bridge settings. Additionally, if there is a right to revoke the burn upon failure of the transaction, step 3 can be skipped and the issuer wallet received directly from the source wallet.

Cross-taxonomy translation can be used for multi-ledger issuance. For example, it may be used when the official record of ownership is separate from the ledger for transfer, or when the official record is the sum of ownership records on affected ledgers. By presence in a particular fractionInfinixchange on class account^TMA summation mechanism that allows tokens to be issued on multiple ledgers and/or provides a means by which tokens issued on one ledger can "flow" to another ledger. When a token is moved from one ledger to another, the total number of tokens in circulation remains the same, while the ownership record is moved from one ledger to another. This type of bridge combines both withdrawal and deposit functions. By removing tokens from one ledger while introducing tokens to another ledger, the total number of tokens remains unchanged. Funds exiting the ledger are sent to the source ledger base wallet. Such a transfer may also be a escrow transaction, holding the token without moving the token. An equal amount of token circulation is issued on the target ledger from the issuer (wallet, account or smart contract) or cold wallet to the outbound wallet on vendor B for delivery to the target. After successful delivery, iissuer. withdrawal function is called on the source ledger, removing tokens from circulation.

The out-of-band transfer module 2104 provides out-of-band (OOB) processing in the event that the value transfer path leg cannot be fully automated within the system. An interface is provided to enable a third party to signal and provide data to applicants' system to facilitate the performance of the process. For example, where a bridge may only support unidirectional flow of funds between networks, a fund imbalance may accumulate, possibly requiring OOB transactions to restore balance. Managing the time lag of OOB and the proper pre-allocation of funds in the outbound account is a logistical problem with a robust control mathematical model. Price discovery is facilitated by the operation of pricing and liquidity module 2010 (FIG. 2). The module may adjust the price through a market function to maintain a balance between inbound and outbound account levels. External markets may be utilized to supplement liquidity. The dark pool owner (the person who contributes assets to the dark pool) receives revenue from the costs associated with the use of the dark pool. The pricing and liquidity module 2010 is intended to manage liquidity between ecosystems, currencies, and asset exchanges. Pricing and liquidity module 2010 applies market maker algorithms to manage liquidity. The pricing and liquidity module 2010 may manage the cost of the transfer based on a resource balance of both dark pool parties. It drives up the cost of capital flow for persistent mismatches. A constant imbalance in resource flow between a and B will result in a price increase from a- > B and a price decrease from B- > a. The larger the mismatch, the greater the revenue of the model. The user can "invest in" the mismatch, bringing fluidity when needed.

The liquidity pool can also be used to facilitate transfer between or within ecosystems when dealing with currency exchanges. The chain flow may be repeated among many suppliers, including available currency exchanges, providing a path for any flow of value, and using external liquidity. Monetary transactions may occur through the pricing and liquidity module 2010. The process may be repeated and the trading contract may be used to maximize liquidity against the trading account.

Other alternative structural and functional designs may be implemented to perform cross ledger transfers. Thus, while embodiments and examples have been illustrated and described, it is to be understood that the invention is not limited to the precise construction and components disclosed herein. Various modifications, changes and variations may be made in the arrangement, operation and details of the methods and apparatus disclosed herein without departing from the spirit and scope of the invention as defined in the appended claims.

Claims (20)

1. A method of connecting heterogeneous computing networks to complete a cross-network transaction in a system comprised of a plurality of networks, the method comprising:

receiving information proposing a transaction, the transaction spanning at least two networks and having a source node and a destination node;

traversing a graph structure including transaction nodes within a transition network and bridges across the network and established by a plurality of agent systems that crawl the network through the nodes and bridges to identify paths between the source node and the target node, wherein each node in the graph structure resides on the network, each node having an associated set of attribute variables specifying tokens to support, and bridges defined by two nodes across two logical networks, the bridges having attribute variables representing transition characteristics;

generating transaction routing information specifying a set of sub-transactions for performing the transaction according to the graph structure, the information including an expected cost and time of the transaction if the routing is used; and

controlling execution of the sub-transaction groups using a manager that executes and controls the order of execution of the sub-transactions across the heterogeneous network, ensures and logs successful execution of the entire chain, and performs a rollback if the transaction fails.

2. The method of claim 1, wherein the generating comprises determining a transition path from the transaction routing information, the transition path including the sub-transaction group, the determining comprising examining a transition information term directory and a translation schema to convert a heterogeneous ontology of the DLT networks in the optimized transition path into a syntax-independent model and modeling the sub-transactions according to the syntax-independent model, and applying an interface between the DLT networks in the optimized transition path.

3. The method of claim 1, wherein node pairs in the graph structure and corresponding property variable groups define a bridge data structure providing connections between the nodes in the node pairs.

4. The method of claim 3, wherein at least some of the node pairs correspond to accounts in different networks.

5. The method of claim 3, wherein the bridge data structure specifies at least one source network wallet, at least one target network wallet, and a transaction pricing model for flowing value between nodes of the node pair.

6. The method of claim 3, wherein the bridge data structure specifies translation logic to be attached to a logical interface.

7. The method of claim 1, wherein the generating comprises traversing the graph structure in accordance with a node traversal algorithm and parsing the attribute variables to identify acceptable routes.

8. The method of claim 1, wherein each node is wrapped with a generic transaction interface that translates syntax independent instructions into a specific network syntax to cause transactions to be performed on different networks.

9. The method of claim 1, further comprising posting the transaction and the connection with each sub-transaction to a separate ledger.

10. The method of claim 9, wherein the published transaction provides invariance using zero knowledge proof while maintaining transaction privacy.

11. A computer architecture for connecting heterogeneous computing networks to complete cross-network transactions in a system comprised of a plurality of networks, the architecture comprising:

at least one computer processor; and

at least one memory storing computer-readable instructions that, when executed by at least one computer processor, cause the at least one computer processor to: capable of receiving information proposing a transaction, the transaction spanning at least two networks and having a source node and a destination node;

traversing a graph structure including transaction nodes within a transition network and bridges across the network and established by a plurality of agent systems that crawl the network through the nodes and bridges to identify paths between the source node and the target node, wherein each node in the graph structure resides on the network, each node having an associated set of attribute variables specifying tokens to support, and bridges defined by two nodes across two logical networks, the bridges having attribute variables representing transition characteristics;

generating transaction routing information specifying a set of sub-transactions for performing the transaction according to the graph structure, the information including an expected cost and time of the transaction if the routing is used; and

the execution of the sub-transaction group is controlled using a manager that executes and controls the order of execution of the sub-transactions across the heterogeneous network, ensures and logs successful execution of the entire chain, and performs a rollback if a transaction fails.

12. The architecture of claim 11 wherein the generating comprises determining a transition path from the transaction routing information, the transition path including the sub-transaction group, the determining comprising examining a transition information term directory and a translation schema to convert a heterogeneous ontology of DLT networks in the optimized transition path to a syntax-independent model and modeling the sub-transactions according to the syntax-independent model, and applying an interface between the DLT networks in the optimized transition path.

13. The architecture of claim 11, wherein node pairs in the graph structure and corresponding property variable groups define a bridge data structure providing connections between the nodes in the node pairs.

14. The architecture of claim 13 wherein at least some of the node pairs correspond to accounts in different networks.

15. The architecture of claim 13 wherein the bridge data structure specifies at least one source network wallet, at least one target network wallet, and a transaction pricing model for flowing value between nodes in the node pair.

16. The architecture of claim 13 wherein the bridge data structure specifies translation logic to be attached to a logical interface.

17. The architecture of claim 11 wherein the generating comprises traversing the graph structure in accordance with a node traversal algorithm and parsing the attribute variables to identify acceptable routes.

18. The architecture of claim 11 wherein each node is wrapped with a generic transaction interface that translates syntax independent instructions into a specific network syntax to cause transactions to be performed on different networks.

19. The architecture of claim 11, wherein the instructions, when executed by the at least one processor, further cause the at least one processor to include issuing the transaction and the connection with each sub-transaction to a separate ledger.

20. The method of claim 19, wherein the published transaction provides invariance using zero knowledge proof while maintaining transaction privacy.

Images