Digital Asset Platform

Abstract

A Digital Asset Platform (DAP) uses distributed ledger technology and smart contract programming. A DAP can include a distributed and decentralized communication network system and application system that collectively handles the end-to-end tokenization, management, and lifecycle processing of digital assets. Assets can be digitally native securities (e.g., bonds, stocks, funds, etc.) and non-securities (e.g., digital cash, loans, derivatives), tokenizations of real-world assets (securities and non-securities), or any other form of tokenized assets.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 63 / 380,573, filed October 23, 2022, and U.S. Provisional Patent Application No. 63 / 381,125, filed October 26, 2022, both of which are incorporated by reference.

[0002] The present disclosure relates generally to the field of distributed ledger technology (DLT), and in particular to a digital asset platform capable of providing end-to-end registration, storage, issuance, trading, settlement, and servicing of digital assets and tokenized assets. [Background technology]

[0003] Distributed ledger technology (e.g., blockchain) was developed as a means for parties to engage in transactions, such as financial transactions, without the need for a single centralized authority or intermediary. In such DLT-based systems, each transaction is recorded separately by multiple nodes. In some embodiments, no single entity controls all of the nodes, making it extremely difficult for a malicious actor to alter a transaction after it has been recorded by the nodes. Even in embodiments where a single entity controls all of the nodes, it is still extremely difficult to alter data recorded on enough nodes to change the consensus expressed by all of the nodes without leaving an indication that the data has been tampered with.

[0004] There are many possible scenarios in which parties may desire to exchange digital assets for other digital assets, cash, or non-digital assets. Market participants desire a wide range of functionality for digital assets to reflect the wide variety of financial products possible using traditional, non-digital methods. However, traditional digital asset systems offer a patchwork of functionality that only partially meets financial market participants' needs. Furthermore, because regulatory requirements vary across jurisdictions, a system developed to serve market participants in one region may not be a viable solution elsewhere where regulatory requirements differ. Therefore, there is a need for a new DLT-based financial market infrastructure (FMI) that addresses the fragmentation and inefficiencies within and across jurisdictions in existing digital asset systems and provides, for example, end-to-end registration, custody, issuance, trading, settlement, and servicing of digital assets and tokenized assets (including securities and non-securities). Summary of the Invention

[0005] These and other problems may be solved by a digital asset platform ("DAP" or "platform") that uses distributed ledger technology (DLT) and smart contract programming. A DAP may include a distributed and decentralized communication network system and application system that collectively handles end-to-end tokenization, management, and lifecycle processing of digital assets. The assets may be digitally native securities (e.g., bonds, stocks, funds, etc.) and non-securities (e.g., digital cash, loans, derivatives), tokenizations of real-world assets (securities and non-securities), or any other form of tokenized assets (collectively, "digital assets").

[0006] To comply with securities and non-securities regulatory requirements in many jurisdictions, the platform may use a permissioned DLT network (e.g., a permissioned private or consortium blockchain) with nodes hosted and operated by recognized legal entities (e.g., regulated financial institutions). In various embodiments, the platform uses smart contracts to provide one or more of the following: role and service management engine, primary issuance of digital assets, secondary trading of digital assets, securities and non-securities registration and custody, digital asset transaction settlement (e.g., cross-tier atomic settlement), account and portfolio management, and asset services (e.g., coupon creation and processing, redemption processing, securities splitting and combining, etc.). [Brief explanation of the drawings]

[0007] The disclosed embodiments have advantages and features that will become more readily apparent from the detailed description, the appended claims, and the accompanying figures (or drawings), the following of which is a brief introduction.

[0008] [Figure 1] FIG. 1 is a block diagram illustrating a networked computing environment suitable for providing end-to-end registration, storage, issuance, trading, settlement, and servicing of digital and tokenized assets, according to one embodiment. [Figure 2] FIG. 2 is a block diagram of the digital asset platform of FIG. 1 according to one embodiment. [Figure 3] 1 is a flowchart of a method for assigning roles to entities in a platform, according to one embodiment. [Figure 4] 1 is a flowchart of a method for creating an account on a platform, according to one embodiment. [Figure 5] 1 is a flowchart of a method for primary publishing, according to one embodiment. [Figure 6]1 is a flowchart of a method of asset origination, according to one embodiment. [Figure 7] 1 is a flowchart of a method for asset issuance, according to one embodiment. [Figure 8] 1 is a flowchart of a method for processing a transaction, according to one embodiment. [Figure 9] FIG. 1 is a block diagram of a set of accounts that use hierarchical claim tokens to provide second- and third-order interests in digital assets, according to one embodiment. [Figure 10] 1 is a flowchart of a method for waterfalling coupon payments through account hierarchies, according to one embodiment. [Figure 11] 1 is a flowchart of a method for integrating an off-chain system with a platform for transaction validation, according to one embodiment. [Figure 12] 2 is a block diagram of an example computer suitable for use in the networked computing environment of FIG. 1, according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0009] The figures and the following description illustrate some embodiments by way of example only. Those skilled in the art will readily appreciate from the following description that alternative embodiments of the structures and methods may be used without departing from the principles described. Wherever practical, similar or like reference numerals have been used in the figures to indicate similar or like functionality. When elements share a common numeral followed by a different letter, this indicates that the elements are similar or identical. Numeric-only reference numerals generally refer to any one or any combination of such elements unless otherwise noted.

[0010] overview 1 illustrates one embodiment of a networked computing environment 100 suitable for providing end-to-end registration, custody, issuance, trading, settlement, and servicing of digital and tokenized assets. In the illustrated embodiment, networked computing environment 100 includes a digital asset platform 120, one or more distributed ledgers 110, and one or more client devices 140, all connected via a network 190. In other embodiments, networked computing environment 100 includes fewer, different, or additional elements. Additionally, functionality may be distributed among elements in a manner different from that described.

[0011] Digital asset platform 120 includes one or more computing devices that collectively provide functionality for digital assets and tokenized assets, including end-to-end registration, custody, issuance, trading, settlement, and servicing of those assets. These computing devices include nodes on one or more distributed ledgers (e.g., distributed ledger 110A or 110B). Digital asset platform 120 provides information to drive user interfaces (e.g., on client devices 140) through which market participants conduct transactions involving digital assets. Digital asset platform 120 creates and manages smart contracts on one or more distributed ledgers 110 (e.g., blockchains) to provide the aforementioned functionality. Various embodiments of digital asset platform 120 are described in more detail below with reference to FIG. 2.

[0012] The distributed ledger 110 provides an immutable record of current and historical ownership of digital assets and tokenized assets. The distributed ledger also encompasses smart contracts that provide functionality related to digital assets and tokenized assets. FIG. 1 shows two distributed ledgers 110A and 110B for illustrative purposes. In practice, the networked computing environment 100 may include any number of distributed ledgers. For example, in one embodiment, a single permissioned distributed ledger is used to store all digital assets and smart contracts, while in another embodiment, the platform may support multiple types of digital assets, each stored in its own distributed ledger. Furthermore, in some embodiments, the platform may use a distributed ledger for storing smart contracts that is separate from the one used to store digital assets or tokenized assets.

[0013] 1, a first distributed ledger 110A is shown as including three distributed nodes 112: a first distributed node 112A, a second distributed node 112B, and an Nth distributed node 112N. Similarly, a second distributed ledger 110B is shown as including a first distributed node 114A, a second distributed node 114B, and an Nth distributed node 114N. In practice, each distributed ledger 110 can (and could) include many more nodes.

[0014] The distributed nodes 112, 114 are computing devices. The distributed nodes may manage and provide a blockchain or other type of distributed ledger. The distributed nodes may also store and enforce rules established by smart contracts. Thus, when a trigger condition of a smart contract is met, one or more actions may be automatically performed by the distributed nodes 112, 114. When an event or data related to a smart contract is generated, the associated information may be added to a block in the blockchain. The blockchain and smart contracts may codify and automatically enforce the rules governing ownership and investment of digital assets.

[0015] When a distributed node 112 or 114 receives a request to execute a transaction, it verifies or denies whether the transaction's associated data matches its records. If a threshold amount of distributed nodes meet that the transaction matches its records, the transaction is considered successfully verified. For example, Byzantine fault tolerance techniques may be used to verify a transaction by determining whether enough nodes confirm the transaction's validity. Similarly, an action defined in the rules of a smart contract may be triggered if a threshold amount of distributed nodes meet that the trigger condition for that action is met.

[0016] A distributed ledger 110 generally takes one of the following forms: - A single global ledger maintained by all nodes in a blockchain network, or - A global ledger made up of multiple local ledgers maintained by individual nodes in the network.

[0017] In DLT embodiments that use a single global ledger, when a change is made to the blockchain (e.g., when a new transaction or block is created), nodes reach agreement on how the change should be integrated into the network of decentralized nodes. Once agreed upon, the agreed-upon change is considered confirmed such that each node maintains a copy that should match copies stored by other nodes. Changes, if any, that do not achieve consensus can be ignored. Thus, unlike traditional centralized ledgers, a single party cannot unilaterally change the blockchain.

[0018] In DLT embodiments that use a global ledger made up of multiple local ledgers, when a transaction is submitted to the network, the relevant nodes check the validity of the transaction and confirm its validity. Once agreed upon, the agreed upon changes are considered confirmed and will be used to update the contract state in the relevant nodes' local ledgers. Unlike embodiments that use a single global ledger, each node maintains its own private ledger state that collectively form the global ledger.

[0019] Blockchains may also include smart contracts, which are sets of executable instructions stored in combination with one or more trigger conditions. When a trigger condition is met, the smart contract is triggered and the corresponding instructions are executed. Each distributed node 112, 114 may receive a smart contract definition, but any results from the execution of the code in the smart contract are only verified if there is consensus among the nodes regarding the state of the smart contract (e.g., enough nodes agree that the trigger condition is met and that the execution of the instructions will lead to a particular outcome). Other types of distributed ledgers may be used in other embodiments.

[0020] Client device 140 is a computing device through which a user interacts with digital asset platform 120 or a distributed ledger, such as distributed ledger 110A or distributed ledger 110B. Although three client devices are shown (first client device 140A, second client device 140B, and Nth client device 140N), in practice, networked computing environment 100 may include any number of such devices. In one embodiment, client device 140 provides a user interface (e.g., in a browser or via a dedicated application) that enables market participants to provide transaction details, apply their digital signatures to transactions, view their previous activity on the platform, and access other functionality of the platform (such as any of the functionality described below).

[0021] Network 190 provides a communication channel through which other elements of networked computing environment 100 communicate. Network 190 can include any combination of local area networks or wide area networks using both wired and wireless communication systems. In one embodiment, network 190 uses standard communication technologies or protocols. For example, network 190 can include communication links using technologies such as Ethernet, 802.11, Worldwide Interoperability for Microwave Access (WiMAX), 3G, 4G, 5G, Code Division Multiple Access (CDMA), Digital Subscriber Line (DSL), etc. Examples of network protocols used to communicate over network 190 include Multiprotocol Label Switching (MPLS), gRPC Remote Procedure Call (GRPC), Transmission Control Protocol / Internet Protocol (TCP / IP), Hypertext Transfer Protocol (HTTP), Simple Mail Transfer Protocol (SMTP), and File Transfer Protocol (FTP). Data exchanged over network 190 can be represented using any suitable format, such as Hypertext Markup Language (HTML) or Extensible Markup Language (XML). In some embodiments, all or part of the communication links of network 190 may be encrypted using any suitable technique.

[0022] Exemplary Digital Asset Platform 2 illustrates one embodiment of a digital asset platform 120. In the illustrated embodiment, platform 120 includes a role assignment module 205, an account creation module 210, an account management module 215, a KYC module 220, a primary issuance module 225, an asset origination module 230, an asset issuance module 235, a primary trading module 240, a secondary trading module 245, a settlement engine 250, a registration and custody module 255, a reconciliation module 260, an asset model module 265, an inspection module 270, a coupon payment module 275, a redemption module 280, a delegation module 285, and an integration module 290. In other embodiments, platform 120 includes different or additional elements. Furthermore, functionality may be distributed among the components of platform 120 differently than described. For example, a single module may handle origination and issuance.

[0023] The role assignment module 205 manages which roles different entities serve on the platform 120. The following are example roles that an entity may have: - Operator: Responsible for maintaining the on-DLT DAP, including administrative functions. The Operator controls role assignment (i.e., granting platform roles to different entities, which enable specific functions according to the respective assigned services). - Issuer: Triggers the on-DLT / on-chain digital asset origination and issuance process. The issuer may also delegate the origination and issuance process to a registrar. - Registrar: Approves the asset origination and issuance process and maintains the integrity of the issued assets. The registrar may also oversee and manage the custodial account. Distributor: A distributor may provide lead banking services to manage the primary issue, bookbuilding, and allocation. A distributor may also provide syndicate banking services to participate in the primary issue workflow, onboard investors, and submit orders. - Payment Agent: Identifies the coupon rate for the special payment date, receives the net coupon amount from the issuer, and distributes the entitled coupon amount to investors. - Settlement Agent: Generates settlement instructions and executes atomic settlements. - Cash Token Administrator: Responsible for digital cash origination and issuance of digital cash tokens represented on-chain. - Distributor / Syndicate Bank: Participates in the primary issuance workflow, onboards investors, and submits orders. - Custodian: Responsible for reviewing and approving on-chain settlement instructions on behalf of investors. Custodians safeguard and manage assets on behalf of investors. - Investors: Enable clients to submit primary or secondary market orders, Expressions of Interest (IOIs), Requests for Quotes (RFQs), and Requests for Tenders (RFTs), as well as approve settlement instructions. Investors may also access portfolio / account management services to view their digital asset holdings on-chain. In some embodiments, investors may also delegate their account and settlement obligations and functions to a custodian. - Oracles: Provide the platform with links to off-chain reference data feeds (e.g., calendars, benchmarks, and legal entity data). - Secondary Trader: Creates / deletes IOIs, orders, or RFQs / RFTs, providing liquidity facilitation to investors and the market.

[0024] Role assignment can be centralized or decentralized. Figure 3 shows an exemplary method 300 for assigning roles to entities using a centralized approach, according to one embodiment. In the illustrated embodiment, method 300 begins with the role assignment module 205 identifying 310 an entity and an intended role for that entity. The entity may be identified 310 by a user providing a Legal Entity Identifier (LEI) or other identifier for the entity, and the role may be identified by a string representing the role's name or another unique identifier for the role.

[0025] The role assignment module 205 sends the role offer to the entity by creating a smart contract on the distributed ledger for the entity and the role (320). The entity may be notified of the creation of the offer smart contract with a message sent to the client device 140 associated with the entity, such as by sending an email, instant message, or other type of message to the entity's account accessible at the client device 140 (e.g., by providing the entity's credentials). Assuming the entity agrees to accept the role by signing the offer smart contract, the entity is assigned the role (340). A role may be assigned by creating a role smart contract that identifies the entity (e.g., by its LEI) and the role (e.g., by role name) and archiving the offer smart contract. The role assignment module 205 may also create a service smart contract that contains code for the entity to perform actions associated with the assigned role. Alternatively, other data structures may be used to identify the role assigned to the entity and define the allowable actions.

[0026] The role assignment module 205 may also assign roles to a particular issuance. In one embodiment, identifiers of entities and the roles they service with respect to an issuance are stored in a smart contract or other data object associated with the issuance. When an entity attempts to perform an action related to an issuance, the role assignment module 205 may verify whether the entity has both the relevant role assigned to it (globally) and that the role for the particular issuance has been assigned to it.

[0027] In decentralized embodiments, a similar approach may be adopted, where rather than a single entity assigning roles, any entity may assume a new role of product administrator that enables that entity to decide what roles different parties will play in the context of an issuance (e.g., an entity may be the lead bank in one issuance and the investor in another, with their capabilities and limitations always derived within the context of the issuance they are acting on). Entities may still accept or approve their functional roles for an issuance, but may do so without having specific role smart contracts stored on-chain to capture their approval. Rather, the roles played by an entity for an issuance may be stored in association with an identifier for that issuance.

[0028] In a decentralized configuration, the platform 120 provides three safeguards against malicious or unintended use. First, a model is provided at the API layer through which entities interact with the platform to verify whether they have the authority to act on a particular issuance. Second, any entity can become a product administrator and assign roles for issuance, but legally binding asset transfers occur only when all parties sign the transaction. Third, in the event of malicious or accidental functioning, node operators retain emergency powers to block access to users and to delete any contracts that are determined to be invalid for any reason.

[0029] Referring back to FIG. 2, the account creation module 210 module creates accounts for entities using the platform. In one embodiment, account creation involves two parties: an account provider and an account owner. The account provider is an entity with a custodian role, and the account owner can be any entity on the platform 120. The account is represented on-chain by a smart contract that includes an account identifier, a provider identifier, and an owner identifier, as well as the account's KYC status. Generally, it is the account provider's responsibility to maintain / update the account's KYC status. FIG. 4 illustrates an exemplary method 400 for creating an account on platform 120, according to one embodiment. In the illustrated embodiment, method 400 begins with account creation module 210 receiving 420 a custody request from one of the parties (e.g., an account owner or a custodian). The custody request may be represented by a smart contract stored on-chain. Account creation module 210 receives 430 an approval of the custody request from the other party. The approval may occur by the other party signing the smart contract. Once the other party has signed, the custody relationship may be created on-chain by creating 440 a custody service smart contract. The custody request smart contract may be archived at this point. Similarly, if a custody request is received from a custodian and identifies the account owner, account creation module 210 creates 440 a custody service smart contract (and may archive the custody request smart contract) once the account owner signs the custody request smart contract. The custodial service smart contract includes code for providing custodial service functionality. The account creation module 210 also receives (450) an account creation request from an account holder and creates an account request smart contract. Upon receiving (460) approval of the account creation request by a custodian who signs the account request smart contract, the account creation module 210 may create (470) the account (which is a smart contract) and archive the account request smart contract. The account smart contract includes information about the account.

[0030] Referring back to FIG. 2 , the account management module 215 provides a user interface (e.g., via the client device 140) to allow account holders to manage how their accounts are used. In one embodiment, an entity may maintain multiple accounts on the platform from different account providers and use the interface provided by the account management module 215 to designate default accounts to be used for settlement in various circumstances. For example, an account holder may designate: a default securities account, a default cash account, a default omnibus securities account (if the account holder is a securities custodian), a default omnibus cash account (if the account holder is a cash custodian), and any other default accounts for particular types of assets, depending on the particular use case. The account holder's default account selection may be stored in a distributed ledger in a smart contract. At settlement time, the settlement agent may use the smart contract to determine which account should be used and generate settlement instructions accordingly.

[0031] The KYC module 220 provides an interface for the account provider to update the KYC status of an account (e.g., via the client device 140). The account provider can operate its normal KYC procedures off-chain, and if there is a change in the account holder's KYC status, the account provider may use the interface provided by the KYC module 220 to add a new smart contract to the distributed ledger indicating the updated KYC status (this smart contract replaces any previous smart contract for the account). Alternatively, the smart contract for the account may indicate an off-chain location where the account's KYC status is stored, and the account provider may update the KYC status stored there and make the updated KYC status automatically available on-chain.

[0032] The primary issuance module 225 manages the primary issuance of one or more issuances (e.g., tranches) of digital assets as part of a transaction. In one embodiment, the primary issuance process begins with a lead manager (e.g., a lead bank for a syndicated issuance) creating a transaction. The transaction is defined as a collection of one or more issuances grouped under the same issuer and lead bank syndicate. Each issuance represents an issuance lifecycle (e.g., a syndicated issuance, a private placement, a municipal bond issuance, etc.) involving a separate set of participants and digital assets. The primary issuance and bookbuilding workflow are decoupled from the digital asset securities to achieve maximum flexibility. Within each issuance, a designated lead manager is responsible for managing the issuance workflow. The workflow can also be configured to include different visibility levels, bookbuilding stages, permitted participants, and actions.

[0033] Throughout the issuance process, the lead manager updates the issuance with separate states to represent the various stages of the issuance (e.g., announcement, open book, close book, launch, allocation, pricing, cancellation). For each issuance, allocation and price discovery can be set manually with the help of underwriters or crowdsourced through an auction. The bookbuilding process can be completed on-chain or performed off-chain and then input into platform 120 and recorded on the ledger using the platform UI or API directly to manage and execute bookbuilding on-chain or manage and execute integration with traditional bookbuilding systems that input the resulting trades, orders, and allocation information into platform 120 to be recorded on the distributed ledger.

[0034] 5 illustrates a method 500 of primary issuance, according to one embodiment. The method is described in terms of the primary issuance module 225 performing the method 500, although it should be understood that unless otherwise noted, the steps are performed at the direction of the lead bank for the transaction (e.g., in response to instructions given via a user interface of the lead bank's client device 140).

[0035] In the illustrated embodiment, method 500 begins with the primary issuance module 225 creating a trade (510) and then creating an issue for the trade (520). A book is opened (530), and the primary issuance module 225 receives orders from syndicate banks and / or other investors (540). The orders may be stored on-chain. Once one or more conditions are met (e.g., at a specified time), the primary issuance module 225 closes the book (550) and updates the issue size and spread based on the orders (560). The primary issuance module 225 allocates the orders (570) and determines a price based on the allocated orders (580).

[0036] After the issuance is priced, the asset origination module 230 and the asset issuance module 235 work together to issue the digital asset. Asset origination and issuance on platform 120 involves two parties: the issuer and the registrar. In one embodiment, issuance and securities services are established between the issuer and the registrar before asset origination and issuance begins. Assuming the required services are in place, digital asset issuance and origination are handled as two separate processes. Origination involves creating a smart contract that contains a description of the digital asset (or a security that defines the digital asset), but does not represent the legal creation or ownership of the digital asset. In contrast, issuance involves creating a token that represents an instance of the digital asset and assigning ownership of that token on-chain. Each token does not contain a description of the digital asset, but rather references back to the smart contract created during origination. Thus, only one instance of the digital asset description is stored on-chain, which improves efficiency and eliminates the risk of inconsistent definitions between instances.

[0037] FIG. 6 illustrates an exemplary method 600 for originating a digital asset, according to one embodiment. In the illustrated embodiment, method 600 begins with the asset origination module 230 receiving (610) an origination request from an issuer of the digital asset. The asset origination module 230 retrieves (620) information about the asset from an issuance defined by the primary issuance module 225. The asset origination module 230 requests (630) approval of the origination from the registrar. The approval request may include information about the asset provided to the registrar's client device 140 that enables verification that the origination matches information about the issuance in the registry. The approval request may be made by creating an approval smart contract on the distributed ledger. Assuming the registrar finds no issues with the request, the asset origination module 230 receives (640) approval from the registrar (e.g., by the registrar signing the approval smart contract) and creates (650) a description of the asset. This description is a dataset detailing the properties of a digital asset, which can be stored on-chain as a smart contract.

[0038] FIG. 7 illustrates an exemplary method 700 of issuing a digital asset, according to one embodiment. In the illustrated embodiment, method 700 begins with the asset issuance module 235 receiving (710) an issuance request from an issuer of a digital asset. The asset issuance module 235 retrieves (720) information about the asset issuance from the issuance request and provides (730) the issuance request to a registrar for approval. If the registrar identifies no issues with the issuance request, the registrar sends (740) an approval of the issuance request, which is received by the asset issuance module 235. The asset issuance module 235 then creates (750) an asset deposit and issuance. An issuance is one or more instances of an asset described by a dataset created for that asset by the asset issuance module 230. The asset deposit is an instance of a digital asset credited to the issuer's account, representing a pending issuance, and the issuance is a record of the number of digital assets issued. The combination of asset depository and issuance verifies that the quantity of digital assets that an issuer intended to issue matches the quantity of digital assets that was actually issued (i.e., held by entities within the platform).

[0039] Referring again to FIG. 2 , primary trading module 240 manages primary transactions for digital assets. In one embodiment, primary trading module 240 supports a wide variety of transactions, which may be structured in various hierarchies (including a flat issuance structure with no hierarchy). Exemplary types of transactions supported include: (1) takedown transactions (transactions between an issuer and a lead bank to take down the entire issuance); (2) investor transactions (transactions between investors and banks to purchase digital assets); (3) residual transactions (distributing remaining unallocated assets among syndicate banks in the event of an underissuance); (4) broker transactions (transactions between a lead bank and a syndicate bank to allow the syndicate bank to settle directly with its own investors); and (5) direct allocation transactions (transactions between the issuer and investors). The lead bank can book these primary transactions on platform 120 based on the issue size and investor orders submitted during the bookbuilding phase.

[0040] Once a trade is booked, a settlement agent can generate settlement instructions for the trade. In one embodiment, the settlement instructions are generated by traversing a custodial hierarchy tree using an algorithm that ensures a valid path exists between the buyer and seller. The generation of the settlement instructions can be triggered manually or automated based on one or more criteria being met. The settlement instructions are generated based on information retrieved from the trade and the settlement information of each counterparty. The settlement instructions are then signed by the relevant parties (e.g., buyer, seller, custodian) and proceed to asset settlement transfer (e.g., DvP / FoP).

[0041] The secondary trading module 245 enables trading of ownership and beneficial interests in digital assets in a secondary market. In one embodiment, the secondary trading module 245 provides a message board (e.g., accessible via client device 140) where secondary traders can post IOIs for digital assets. If another secondary trader is interested in the IOI, the secondary traders can negotiate and, if they can agree on terms, enter into a trade. Once the two parties reach an agreement, either party can initiate the creation of a trade recap. Once a party creates a request for a trade recap using a user interface, the other party can confirm the submission. If confirmation is received, the settlement agent initiates settlement, beginning with the creation of the trade. From there, settlement proceeds similarly to a primary issuance or any other trading context.

[0042] In one embodiment, the secondary transaction module 245 performs efficient transaction aggregate matching. In traditional transaction matching systems that do not involve a distributed ledger, the system can query a database of transaction information for all transactions that meet a specified set of criteria. However, using a distributed ledger, searching for transaction information is limited to index matching, making it more difficult to identify matches.

[0043] To address this, as platform 120 receives counterparty trade summaries, it stores them on a chain of custom queues. The queue rebalances to always return the earliest (or latest, depending on the specific requirements of the implementation) matching opposite-side trade summaries. The self-order queue can be implemented as an immutable contract object in DAML (or any other suitable form of smart contract). The queue does not use any additional objects to store orders and is self-contained. In one embodiment, the queue is a virtual balancing queue, meaning it does not require any additional data storage or use any other data structures beyond creating a smart contract for one side of the transaction. Other conventional implementations of queues often use additional data structures, with the property that elements in the queue are removed in the order they were added. However, the virtual queue is implemented through an existing smart contract that is populated with a recursive key.

[0044] To enable efficient matching from the queue, each side of the transaction is entered with the transaction economics and an iteration key. The iteration key ensures uniqueness while allowing it to be used in an iterative algorithm for searching. When the platform ingests one side of a transaction, it performs an iteratively keyed query for the other transaction with the same economics but on the other side. If it finds a match, the two sides of the transaction are matched. The queue rebalances so that if there are multiple potential matches, either the earliest or latest potential match is returned, depending on the particular implementation of the queue. Conversely, if no match is found, the transaction is stored in a virtual balancing queue.

[0045] FIG. 8 illustrates an exemplary method 800 for creating a trade summary and processing a transaction, according to one embodiment. In the illustrated embodiment, method 800 begins with the secondary trading module 245 receiving (810) a request for a trade summary. As previously indicated, either party to a trade may submit the request from the trade summary (e.g., using a user interface provided on the client device 140). The secondary trading module 245 captures (820) the details of the trade (e.g., the assets to be transferred and the identities of the parties) and creates a trade summary request smart contract. Subsequently, the secondary trading module 245 also receives (830) a trade summary request from the other party to the trade. The two trade summary requests are matched (840). Settlement generates (850) settlement instructions to implement the trade defined by the matched (840) trade summary requests. The settlement instructions are provided to the custodians of the parties to the transaction, and if the custodians approve the settlement instructions, the custodians provide their signatures to the secondary transaction module 245. Upon receiving the custodian's signatures 860, the secondary transaction module 245 has a settlement agent process the settlement instructions 870 and credit the appropriate digital assets to the corresponding parties.

[0046] Where permitted by relevant regulatory requirements, platform 120 may offer electronic trading capabilities to provide better liquidity management after the issuance of digital assets. For example, platform 120 may offer one or more of the following: multilateral continuous order matching, multilateral auction matching, or bilateral or multilateral RFQ and RFT interactions. This may be achieved using an electronic trading engine within platform 120 or using integration (e.g., via an API) with an existing trading engine.

[0047] Referring again to FIG. 2, the settlement engine 250 is responsible for the settlement process after a transaction is generated. In one embodiment, the generated settlement instruction is signed by both the sender and receiver, and the transaction is settled by a settlement agent. The settlement agent settles the transaction atomically, meaning that either all assets included in the transaction are transferred or none are transferred. In some embodiments, the settlement instruction can be used to settle even when one of the assets is on another blockchain. More information on how hash timelock contracts (HTLCs) can be used to settle cross-chain transactions can be found in U.S. Patent Application No. 18 / 205,861, filed June 5, 2023, which is incorporated by reference.

[0048] The settlement type may be determined based on the existence of delivery and payment assets and the type of assets. This allows platform 120 to atomically achieve the following types of settlements: (1) delivery vs. payment; (2) no payment and no delivery; and (3) delivery vs. delivery and payment vs. payment. Because platform 120 allows for cross-chain representation of assets, the settlement process can also support atomically settling transactions between two or more chains.

[0049] In various embodiments, the settlement engine 250 uses settlement agent robots (which may be constantly running) to automate the DvP and FoP settlement processes. The settlement engine 250 may use some or all of the following processes to provide automated or near-automated atomic settlements: - Adding a settlement agent to the transaction observer: The lead bank or operator periodically fetches all open visible transactions and checks whether there are any that do not have a settlement agent in the observer list. If such a transaction is found, the settlement agent is added to the observer list. - Generate Settlement Instructions: The settlement agent periodically fetches all open visible transactions (both primary and secondary) and generates settlement instructions accordingly. - Registerability for Settlements: The settlement agent periodically fetches all visible delivery / settlement templates and attempts to mark those as fully signed by all required parties. This will throw an error if not all counterparties have signed, meaning the orders will not actually be executed prematurely due to the need for off-chain checks. This process checks whether all settlement orders for a transaction have been signed by both parties. If all those signatures are present, it means the transaction is ready for settlement. If all signatures are present, it sets a Boolean value on any HTLC-locked settlement orders to indicate that all signatures are present. This signals to the buyer HTLC connector robot, which does not have the ability to check by itself that all parties have provided the required signatures, that everything is ready to execute. - Settlement Transactions: The settlement agent periodically fetches all visible delivery / settlement templates and attempts to execute their settling instructions. These will throw an error if not all counterparties have signed, so the settlement agent will call these instructions and those that are ready to execute will be executed, and those that are not ready can remain pending without the need for off-chain checks. - Automated asset servicing: The settlement agent periodically settles pending coupon payments, if any. - Reverse settlement of cancelled transactions: The settlement agent periodically fetches all settlements and attempts to reverse them. A settlement is reversed only if the associated transaction is reversed. - Send transaction cancellation / advice SWIFT: The settlement agent periodically checks whether there are any cancelled transactions or transactions for which an advisory message is required, and if so, sends a quick message if a message has not been sent previously. - Cancel invalid transactions: The settlement agent may cancel transactions, if any, that are no longer capable of being settled.

[0050] In some embodiments, the settlement engine 250 may batch multiple financial / settlement transactions into a single set of settlement instructions that are executed in a single atomic settlement. This can improve the efficiency of the settlement agent 250 and may be desirable in some scenarios where it is desirable to execute multiple transactions simultaneously.

[0051] Asset registration and storage module 255 provides DLT-based on-chain registration and storage of digital assets. The wallet / account structure supporting asset registration and storage can be adaptable to support: (1) self-custody or custodian management; (2) multi-tier setup to support custodian and sub-custodian relationships; (3) per-investor / beneficiary-owner account or omnibus account for multiple investors / beneficiary-owners; and (4) separate wallet / account setup by jurisdiction to comply with local regulations.

[0052] With a multi-tiered approach, registrars only need to maintain custody of the accounts they directly support, rather than all accounts on the platform. It also allows custodians to self-manage the bookkeeping for the accounts they support. Figure 9 illustrates one embodiment of a layered, hierarchical account structure with custodians holding securities in layer 1 accounts and providing digital asset claim tokens in layer 2 accounts. In the illustrated embodiment, the account structure is organized in a hierarchy containing three layers. However, there can in principle be any number of layers within a hierarchy. Each additional layer allows providers holding tokens in higher layers to further divide the ownership or beneficial interests represented by those tokens into portions represented by different tokens in lower layers. The layers can all be stored on a single blockchain, with permissions used to control what information each participating entity can see. Alternatively, entities holding custody of assets in layer 1 can operate a separate blockchain to record beneficial interests in the assets they hold.

[0053] Tier 1 910 of the tiered account structure handles the digital custody of the assets themselves. Custody of digital assets is typically limited to a small number of qualified institutional investors, depending on jurisdictional requirements (e.g., some jurisdictions do not allow institutional investors to self-custody). Controls are implemented to only allow account owners to transfer / move assets within the account and view ownership rights. Tier 1 accounts may offer ownership or beneficial interest in the assets they custody to other users, may hold assets as self-custodians for their own benefit, or both. In the embodiment shown in FIG. 9 , Tier 1 910 includes a securities issuing account 911 (to house assets when they are first created on the ledger), one or more Tier 1 investor risk accounts 912, a first Tier 1 provider risk account 914, a Tier 1 provider omnibus client account 215, a second Tier 1 provider risk account 916, and one or more Tier 1 segregated accounts 917. As mentioned above, each account may be a blockchain address or wallet or account defined within the ledger, depending on the DLT technology used. In other embodiments, Tier 1 910 may include different or additional elements. For example, any number of providers may have risk and omnibus client / segregated accounts in Tier 1 ledger 910.

[0054] The Securities Issuance Account (or Securities Issuance Register) 911 is where the initial issuance of a set of assets is recorded. Thus, information about the assets and number of assets issued can be stored using smart contracts and used to reconcile with Layer 1 asset ownership. The Securities Issuance Account 911 is distinct from transaction accounts (used to store securities). The Securities Issuance Account 911 does not store assets or represent legal ownership of assets; rather, it serves as a registry of assets.

[0055] Tier 1 investor risk accounts 912 are for accounts (e.g., institutional investors) that wish to self-custody their assets (i.e., hold their accounts directly with a registrar) and are authorized to transact on the first tier ledger 910. Tier 1 investor risk accounts 912 hold investor principal positions.

[0056] In the illustrated example, there is both a tier 1 omnibus client account 915 (which stores tokens for multiple entities in a single account) and one or more tier 1 segregated accounts 917 (each segregated account stores tokens for a single entity). Depending on local regulatory requirements and client preferences, a tier may use only the tier 1 omnibus client account 915, only a set of tier 1 segregated accounts 917, or a combination of both (e.g., if local laws and regulations allow omnibus accounts, but one or more clients choose to use segregated accounts). Additionally, while a specific number of different types of accounts are shown, a first tier may include accounts of each type for any number of providers that make investments in digital assets available to second tier users.

[0057] In some embodiments, a provider may have a risk account and a holding account. The purpose of a custodian maintaining a risk account and an omnibus account is to separate a client's custodial assets (held in the client omnibus account) from their proprietary assets (held in the risk account). However, in a typical configuration, a custodian does not hold proprietary assets and therefore does not need (and may not have) a risk account. That said, for completeness, Figure 9 shows a first Tier 1 provider risk account 914 that may hold digital assets held by the custodian in its defined capacity, and a Tier 1 provider omnibus client account 915 that stores digital assets for which the provider makes ownership or beneficial interest available to Tier 2 users, as well as digital assets in custody held by other Tier 1 participants. Similarly, a second Tier 1 provider risk account 916 stores digital assets held by a second provider for principal investment. However, the second provider has a tier 1 segregated account 917 in which it stores digital assets in which it offers beneficial interests to tier 2 users, separate from the digital assets for which other tier 1 participants are custodians.

[0058] Accounts in the second tier hold tokens that represent ownership or beneficial interests in digital assets held in custodian-managed accounts in layer 1 910. The layer 2 accounts do not store digital assets themselves; instead, they hold claims issued by their respective securities custodians. This may be achieved through ownership or beneficial interest smart contracts that are signed by the custodian accounts. In the embodiment shown in FIG. 9 , the second tier includes a first portion 920 and a second portion 930. Each layer 2 portion corresponds to a different custodian in layer 1. In one embodiment, the accounts in layer 2 portions 920 and 930 are part of the same ledger that includes the layer 1 accounts. Alternatively, some or all of the layer 2 accounts may be stored in separate ledgers. Although a first tier 2 portion 920 is shown branching off of a tier 1 omnibus client account 915 and a second tier 2 portion 930 is shown branching off of a tier 1 segregated account 917, it should be noted that the tier 2 portions may branch off of a tier 1 omnibus client account, a segregated account, or any combination of both.

[0059] The first tier 2 portion 920 is for a first tier 1 provider. In this case, the first tier 1 provider / custodian protects securities for its tier 2 clients by holding the securities in an omnibus account and representing ownership or beneficial interest in the digital assets in a tier 2 account using custodian-issued claim tokens held in the tier 2 account, but none of these secondary users further divide ownership or beneficial interest in a tier 3 account. Thus, accounts in the first tier 2 portion 920 hold digital assets for tier 2 investors. Digital asset ownership in the custodian omnibus account reconciles against claim tokens in the tier 2 investor account provided by the custodian. When a tier 2 user invests in digital assets for which the first tier 1 provider is the custodian, tokens representing ownership or beneficial interest in the digital assets (or portions of the digital assets) are added to the tier 2 user's account 922.

[0060] The second tier 2 portion 930 similarly includes a second tier 2 investor account 932 that may store claim tokens (issued by a custodian) representing ownership or beneficial interests in digital assets (or portions of digital assets) for which the second tier 1 provider is custodian. The second tier 2 portion 930 may include an omnibus client account 936 that further subdivides the ownership or beneficial interests it holds and makes portions of the subdivided ownership or beneficial interests available to third-tier investors, tier 2 segregated accounts that store tokens representing beneficial interests held by individual tier 2 participants, or a combination of both. Tier 2 omnibus client accounts 936 function similarly to tier 1 omnibus client accounts (e.g., tier 1 omnibus client account 915), except that tier 2 omnibus client accounts 936 are not custodians of digital assets, and tier 2 omnibus client accounts 936 hold ownership or beneficial interests in the assets of multiple tier 2 participants, and some or all of the participants may make ownership or beneficial interests in those interests available to tier 3 investors. Tier 2 segregated accounts 938 are similar to tier 1 segregated accounts 917, except that they store ownership or beneficial interests in individual tier 2 participants, and some or all of the participants may make ownership or beneficial interests in those interests available to tier 3 investors.

[0061] Layer 3 940 includes accounts 942 for layer 3 users who acquire ownership or beneficial interests from layer 2 providers. Note that layer 3 ledger 940 may also include one or more provider accounts that make ownership or beneficial interests in digital assets available to layer 4 users, and so on, up to any number of layers. An advantage of using the layer structure shown in FIG. 9 is that it provides privacy controls, only allowing account providers to know client holdings, and enabling reconciliation between the assets they custody and the number of claim tokens issued to custodial clients. For example, a second layer 1 provider may only need to know which ownership or beneficial interests it has granted to layer 2 users. It may not need to know whether the layer 2 users are holding these rights for their own benefit or further passing them on to layer 3 users. Furthermore, because the layer 1 users remain custodians of the digital assets, layer 1 910 can remain unchanged when ownership or beneficial interests are traded at layers 2 920 and 930. Similarly, when beneficial interests are exchanged or traded, such as in tier 3 940, tiers 2 920 and 930 may remain unchanged.

[0062] Another advantage of the tiered structure is that different tier 2 (or lower) portions may be used to trade ownership or beneficial interests in different jurisdictions. Each tier 2 portion 920, 930 may be configured to comply with local regulatory requirements for trading in securities. Thus, tier 1 910 may be universal and include custody of the underlying digital asset, while tier 2 may also trade securities for the underlying asset to other markets with different regulatory requirements.

[0063] Referring again to FIG. 2, reconciliation module 260 monitors the different tiers of the hierarchy managed by registry and custody module 255 for discrepancies. Depending on the specific nature of the assets and the configuration of platform 120, there are generally two types of reconciliation checks: (1) comparing records at different levels of the hierarchy for consistency (e.g., that for an investor with an account at a particular custodian, all rights to a type of token recorded at tier 2 match the number of that token held by that custodian at tier 1); and (2) comparing ownership interests indicated on-chain with off-chain records.

[0064] In one embodiment, the on-chain per-check is performed by a reconciliation robot that can be used by registrars and custodians. When used by a registrar, the robot reconciles the registrar's issuing account (the nominal account that holds records of outstanding securities) with the holdings in the tier 1 account that the registrar provides on platform 120. When used by a custodian, the robot reconciles the custodian's tier 2 custody client claims with the custodian's holdings in its tier 1 account provided by the registrar.

[0065] When comparing on-chain to off-chain records, the reconciliation module 260 may use an API or other similar functionality to compare token ownership and beneficial interests stored on-chain with the off-chain system of record.

[0066] In either case, if a discrepancy is identified, the reconciliation module 260 may invoke emergency powers (e.g., via a smart contract) that the registrar can use to make the appropriate corrections (e.g., by issuing a revised claims token). In one embodiment, the reconciliation module 260 provides two types of emergency error correction capabilities. In general, these powers are not intended or expected to be exercised routinely except in exceptional circumstances where a system bug invalidates the consistency of the registers provided by the platform 120.

[0067] The first emergency power allows the registrar to create new assets in its securities account and, as custodian, transfer the newly created assets into its tier 1 securities account. The second emergency power allows the custodian to transfer asset claims in and out of the tier 2 securities account it manages. Because smart contracts running on platform 120 define which parties can create or modify them, this functionality requires the affected party to make the modification using its own identity. For example, if a custodian other than the operator of platform 120 needs to move assets, the identity (i.e., digital signature and authentication) of that party is required.

[0068] The asset model module 265 defines how various assets are represented within the platform. For example, the asset model module 265 can use one or more token models to define tokens corresponding to assets. In general, tokenization can be achieved in two ways: digitally native or tokenized. A digitally native asset is one where an asset is digitized and represented on-chain as a smart contract token. In contrast, a tokenized asset is one where a token is created off-chain in another way and a token is created to represent the asset on-chain. Regardless of the type of asset, it is stored on-chain as a smart contract that contains the definition of the asset.

[0069] In one embodiment, the platform supports three broad types of assets for use in transactions: external assets, tokenized digital assets, and wrapped tokens. External assets can be anything created off-chain, such as fiat cash or assets stored on another chain. Such assets are provided by the platform operator and cannot be minted or burned because they are not natively stored on the chain used by platform 120. Tokenized digital assets are digital assets native to platform 120; therefore, tokens corresponding to these assets are fully mintable and burnable by the platform and can be provided by any entity with an issuer role. Finally, wrapped tokens are created on-chain by a bridge operator or similar operator using a wormhole and are backed by off-chain assets (possibly on another chain) controlled by a third party that may not exist on platform 120 but are themselves tokens stored on-chain. Thus, wrapped tokens are mintable and burnable, although minting and burning such tokens may require coordination with a third party that controls the underlying off-chain assets.

[0070] These asset models can be used to support various settlement and payment models in platform 120, including one or more of the following: (1) asset transfer-to-payment, payment-to-payment, and transfer-to-transfer on the same chain (e.g., for mintable / burnable cash tokens and security tokens); (2) transfer-to-payment, payment-to-payment, and transfer-to-transfer between chains via HTLC settlement (e.g., for mintable / burnable security tokens and non-mintable cash tokens that represent cash on another chain) or via sequential settlement (e.g., for mintable / burnable security tokens and wrapped cash tokens that represent cash tokens on another chain); (3) no payment (e.g., for mintable / burnable security tokens and non-mintable fiat cash tokens); or (4) transfer of payment assets, transfer assets, etc. (e.g., for any mintable tokens such as coupon payments).

[0071] The inspection module 270 manages the verification of the authenticity of smart contracts deployed on the platform 120. In one embodiment, the inspection module 270 collaborates with trusted inspectors to inspect smart contracts. In a centralized configuration, any valid contracts must have an operator signature as part of them. In a more decentralized setup, the operator role can be shared and distributed among multiple parties, but valid contracts must still be signed by an operator. In a single-operator, centralized embodiment, any contract not signed by the operator is considered invalid, and transactions containing such contracts will not be settled. In a multiple-operator configuration, an operator role may be assigned per transaction, and smart contracts involved in a transaction may be required to be signed by an entity with the operator role for that transaction. Additionally or alternatively, a semi-decentralized configuration may allow for a per-transaction operator to be assigned who can sign smart contracts for the corresponding transaction, although there may also be a global operator who can sign any smart contract in that capacity as an operator.

[0072] Coupon payment module 275 manages coupon payments for digital debt issuances. Coupon payments are one example of various asset servicing functions that may be provided by platform 120. Coupon payments may be settled on-chain or off-chain, depending on the particular configuration. Depending on the particular account structure used, typical parties involved in coupon payments are (1) a paying agent, (2) a settlement agent, (3) a registrar, and (4) one or more custodians (and the obligors / investors they serve).

[0073] On the coupon payment date, the robot (in its capacity as a paying agent) initiates the coupon payment flow by interacting with the ledger and identifying whether a payment is due to the investor. The corresponding coupon rate may be stored in an intermediary smart contract that is referenced by other participants in the workflow. The registrar then initiates the process of notifying custodians in the account hierarchy of the impending coupon payment so they can identify their investor positions and may pull their own investor custodian positions directly with the registrar.

[0074] Once initiated, coupon payments waterfall down through the hierarchy. For example, an issuer issues the entire net coupon payment to a paying agent, which passes the payment to a registrar. The registrar divides the coupon payment among one or more custodians, who each divide their portion of the payment among one or more investors according to the coupon amount.

[0075] 10 shows an exemplary method 1000 for making coupon payments, according to one embodiment. In the illustrated embodiment, method 1000 begins with the coupon payment module 275 identifying 1010 a coupon and a corresponding payment date. On or shortly before the payment date, the coupon payment module 275 identifies 1020 custodians with coupon positions. On the payment date, the coupon payment module 275 distributes 1030 coupon payments to custodians according to their positions and coupon amounts.

[0076] Additionally, on or shortly before the payment date, the coupon payment module 275 notifies the custodian of the pending payment. In response to receiving this notification, the custodian identifies investors with coupon positions for which they are acting as custodians (1040). Upon receiving the coupon payment, each custodian divides the payment among the investors according to their positions and the amount received by the custodian (1050). While this is described as a two-tiered waterfall payment from the registrar to the custodian and from the custodian to the investors, it should be understood that payments may flow through any number of hierarchical levels. For example, one or more of a custodian's investors may act as sub-custodians and further divide the payments they receive among additional investors.

[0077] Referring again to FIG. 2 , redemption module 280 provides another example of an asset service that may be provided by platform 120. Similar to coupon payment module 275, redemption module 280 can generate redemption settlement instructions for digital asset issuances, which can be settled on-chain or off-chain. Depending on the tiered account structure, the parties involved are (1) a paying agent, (2) a settlement agent, (3) a registrar, and (4) one or more custodians. On the maturity date, the registrar notifies the custodian holding the securities account at tier 1 that there has been a maturity / redemption. The custodian then communicates the notification to the end investor.

[0078] Thus, cash payments and token burning can be accomplished in a waterfall fashion through the hierarchy. Specifically, in one embodiment, the paying agent pays the registrar and the securities issuance account is zeroed. The asset description is updated to indicate that the digital asset no longer exists. The registrar pays the custodian, and the digital asset that the custodian has stored with the registrar is burned by the registrar. The custodians then distribute payments to their clients and burn the digital assets based on their arrangements with those clients (typically for payment distribution). This process can be extended to any arbitrarily complex tiered storage structure.

[0079] The delegation module 285 allows a party to delegate the right to make selections on the platform 120 on its behalf to another party. In one embodiment, delegation is used to subdivide a party's entitlement down to the department level. For example, the authority to sign settlement instructions for one transaction may be delegated to a first department, and the authority to sign settlement instructions for another transaction may be delegated to a second department. In one embodiment, the delegation module 285 provides two types of delegation: party-level delegation and service-level delegation.

[0080] Party-level delegation allows a single user to act as multiple parties. DAML has two built-in concepts known as DAML parties and DAML users. A DAML party represents an identity that can interact with the ledger by submitting DAML commands that result in DAML transactions and DAML contracts being created on the ledger. A DAML user, on the other hand, is local to a given participant node and is associated with a primary party and a dynamic set of actAs and readAs parties. Those associated with multiple DAML parties can act as and submit DAML commands in the capacities of these parties.

[0081] For example, an issuer may wish to delegate its on-chain party responsibilities to another organization (e.g., Bank A and Custodian B). Under this scenario, Custodian B user rights are defined to act as both a Bank A DAML Party and a Custodian B DAML Party. These entitlement rights allow the Custodian B user to use the Bank A DAML Party identity to submit DAML commands (in the capacity of Bank A) that result in the creation of DAML transactions and DAML contracts (with the Bank A party signing).

[0082] Service level delegation is the use of the on-chain delegation pattern to grant a delegated party the right to exercise options (within the scope of a service contract) on behalf of another party. As mentioned above, in some embodiments, each party is assigned to one or more roles. Each assigned role is accompanied by its own service DAML contract, which defines a list of permitted actions that this role can perform. Under this setup, an on-chain delegation DAML contract can be created between the principal and the representative party that defines options to allow the delegated party to exercise some service contract options using the issuer identity.

[0083] The integration module 290 enables platform 120 to integrate with off-chain systems. In one embodiment, the integration module 290 allows an entity that does not operate a node on platform 120 to participate on the platform through a node managed by another entity, while still providing the entity with confidence that its intentions are being faithfully executed. Specifically, the integration module 290 interacts with the entity's off-chain system to allow the entity to examine API payloads submitted to nodes operated on its behalf. The entity can attach a signature using its off-chain system, and the integration module 290 retrieves this signature via a webhook. The integration module 290 adds the retrieved signature, along with transaction details, to the blockchain in a smart contract. In this way, the entity can always verify that on-chain information matches what it originally signed using the off-chain system.

[0084] FIG. 11 illustrates an example method 1100 for processing a transaction in which one of the parties does not maintain its own node but instead signs the transaction using an off-chain system, according to one embodiment. In the illustrated embodiment, method 1100 begins with integration module 290 receiving a settlement instruction for the transaction (1110) and pushing information about the transaction to the off-chain system (1120). Assuming the off-chain system approves the settlement instruction, integration module 290 receives the parties' signatures (1130) from the off-chain system (e.g., via webhooks, as described above). Integration module 290 stores the signatures and transaction information on-chain (1140) and executes the transaction according to the settlement instruction (1150). The parties can then use the on-chain transaction information to verify (1160) that the executed transaction is consistent with their intent. Any discrepancies between the on-chain transaction information and what the parties signed using the off-chain system will be apparent because the signature will not be valid unless the on-chain information matches what was signed off-chain.

[0085] Based on the foregoing, it will be apparent to those skilled in the art that the disclosed platform 120 includes several technical improvements and advantages over existing digital asset transaction systems. Moreover, the design of platform 120 lends itself to easy upgrades and modifications to suit particular needs.

[0086] In one embodiment, platform 120 uses abstracted method contracts. Abstracted method contracts are smart contracts that include selection enforcement functionality that operates independently of the contract's state (potentially aside from the data of the abstracted method contract's signers). For example, an application might provide functionality for making payments, and part of that functionality is a complex check that the payment amount is within a set of rules (which might specify maximum, minimum, or nominal values, or rules for obtaining these values, etc.). Instead of writing a single DAML contract that encompasses the entire enforcement logic, the enforcement can be split into two contracts: (1) a main DAML contract that implements most of the enforcement logic, and (2) another DAML contract (in a separate DAML contract) that implements the payment amount checking portion. The main contract can synchronously call the check contract to assert validity, or it can wait for the check contract to send a proof of validity (note that "wait" is not necessarily asynchronous in nature).

[0087] The advantage of this pattern is that multiple instances of an application contract can share a single instance of the extracted method contract, so that an upgrade can be performed with contract replacement of only a few (of the extracted method contracts), which is less than replacing all of the application contracts. Therefore, the minimum number of extracted method contract instances is one, and the minimum number of extracted method contracts required to do this without additional data disclosure is equal to the number of nodes in platform 120.

[0088] Another design feature used in some embodiments to provide upgradability is a retroactive upgrade interface implemented using DAML templates. These retroactive upgrade interfaces can perform complete upgrades without requiring any action from anyone other than the node operator. Furthermore, this approach allows for very flexible upgrades with respect to how code is written, and places few, if any, requirements on the structure and content of the code.

[0089] For templates that are upgraded without schema changes, a single retroactive interface with an "upgrade" option, with the controller as the single party, can be written and implemented retroactively for all of those templates. For templates with schema changes, a separate retroactive interface contract can be written for each such schema-changing template with a single "upgrade" option, with appropriate parameters required for the schema transformation logic or additional data, and also with only a single party as the controller.

[0090] Once a DAR filled with the upgrader retroactive interface is created, published, and uploaded to a node, the DAML contract upgrade process proceeds automatically. Because the upgrader option has only a single controller, it eliminates the need to reconcile and accumulate signatures from parties across different nodes using traditional "upgrade proposal" contracts. Instead, each upgrade contract uses a single method call with a single party's authority. Therefore, the number of operations required is equal to the number of contract instances across all templates across all DARs being updated. This is significantly fewer operations than would typically be required using traditional upgrade techniques.

[0091] In one embodiment, orchestrating the upgrade process involves each node uploading a DAR for the new version of the package and a DAR for the upgrader retroactive interface. Each node operator naturally knows which template upgrades they are responsible for, because the upgrader retroactive interface defines rules for each contract that identify the specific party expected to perform the upgrade, and the node operator knows whether that party is hosted on their node. Each node operator can grant itself an "Act As" token to any party hosted on its node. On an agreed-upon schedule, which can be a rolling or A / B approach, the node operator upgrades the contract instance. The node operator grants itself an "ActAs" token as the party responsible for upgrading that contract, invokes the "upgrade" method, and provides the necessary parameters if the "upgrade" method involves handling schema changes that require parameters.

[0092] Computing System Architecture FIG. 12 illustrates an exemplary computer 1200 suitable for use as part of the digital asset platform 120, client device 140, or distributed node 112 or 114, according to one embodiment. The exemplary computer 1200 includes at least one processor 1202 coupled to a chipset 1204. For convenience, various operations may be described as being performed by “processor 1202.” This should be understood to mean that the operations described are performed by one or more processors acting individually or in concert. The chipset 1204 includes a memory controller hub 1220 and an input / output (I / O) controller hub 1222. The memory 1206 and the graphics adapter 1212 are coupled to the memory controller hub 1220, and the display 1218 is coupled to the graphics adapter 1212. The storage device 1208, the keyboard 1210, the pointing device 1214, and the network adapter 1216 are coupled to the I / O controller hub 1222. Other embodiments of the computer 1200 have different architectures.

[0093] In the embodiment shown in FIG. 12 , storage device 1208 is a non-transitory computer-readable storage medium, such as a hard drive, a compact disc read-only memory (CD-ROM), a DVD, or a solid-state memory device. Memory 1206 contains instructions for implementing the methods described above and data used by processor 1202. Pointing device 1214 may be a mouse, a trackball, a touchscreen, or any other type of pointing device and may be used in combination with keyboard 1210 (which may be an on-screen keyboard) to input data into computer system 1200. Graphics adapter 1212 enables images and other information to be displayed on display 1218. Network adapter 1216 couples computer system 1200 to one or more computer networks (e.g., network 190). The types of computers used by the entities in FIG. 1 can vary depending on the embodiment and the processing power required by the entities. Additionally, a computer may lack some of the above components, such as keyboard 1210, graphics adapter 1212, and display 1218.

[0094] Additional Considerations Some portions of the above description describe embodiments in terms of algorithmic processes or operations. These algorithmic descriptions and representations are typically used by those skilled in the computing arts to effectively convey the substance of their work to others skilled in the art. These operations, while described functionally, computationally, or logically, will be understood to be implemented by computer programs comprising instructions for execution by a processor or equivalent electrical circuits, microcode, or the like. Further, it has proven convenient at times, without loss of generality, to refer to units of these functional operations as modules.

[0095] As used herein, any reference to "one embodiment" or "an embodiment" means that a particular element, feature, structure, material, or characteristic described with respect to that embodiment is included in at least one embodiment. The appearances of the phrase "in one embodiment" in various places throughout this specification do not necessarily all refer to the same embodiment. Similarly, the use of "a" or "an" before an element or component is merely for convenience. This description should be understood to mean that one or more of the element or component are present, unless a different intention is clear.

[0096] Where values ​​are described as "approximately" or "substantially" (or derivatives thereof), such values ​​should be construed to have an accuracy of ±10%, unless otherwise clear from the context. From the example, "approximately 10" should be understood to mean "in the range of 9 to 11."

[0097] As used herein, the terms "comprises," "comprising," "includes," "including," "has," "having," or any other variations thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus that includes a list of elements is not necessarily limited to only those elements and may include other elements not expressly listed or inherent in such process, method, article, or apparatus. Furthermore, unless expressly stated to the contrary, "or" refers to an inclusive "or" rather than an exclusive "or." For example, condition A or B can be satisfied by any one of the following: A is true (or present) and B is false (or absent); A is false (or absent) and B is true (or present); and both A and B are true (or present).

[0098] After reading this disclosure, those skilled in the art will recognize additional alternative structural and functional designs for systems and processes that provide end-to-end registration, storage, issuance, trading, settlement, and servicing of digital and tokenized assets. Accordingly, while particular embodiments and applications have been illustrated and described, it should be understood that the described subject matter is not limited to the precise structure and components disclosed. The scope of protection should be limited only by the scope of any patent claims that may ultimately be issued.

Claims

1. 1. A computer-implemented method comprising: receiving an origination request identifying a digital asset; obtaining asset origination information describing the digital asset; storing a description of the digital asset derived from the asset origination information in an origination smart contract on a distributed ledger; receiving an asset issuance request; retrieving the description of the digital asset in response to the asset issuance request; creating one or more instances of the digital asset on the distributed ledger; A computer-implemented method comprising:

2. receiving a definition of the digital asset; and creating the origination smart contract using the definition; storing the description of the digital asset includes committing the asset origination smart contract to the distributed ledger; 10. The computer-implemented method of claim 1.

3. retrieving the description of the digital asset, receiving an identifier of the origination smart contract; querying the distributed ledger using the identifier of the origination smart contract to identify the description of the digital asset; Including, 10. The computer-implemented method of claim 1.

4. creating the one or more instances of the digital asset on the distributed ledger; creating an asset deposit smart contract in the issuer's account; Creating an issuance smart contract in the securities issuing account Including, 10. The computer-implemented method of claim 1.

5. verifying that the quantity of instances of the digital asset represented in the issuer's account matches the quantity of instances of the digital asset represented in the securities issuing account; 10. The computer-implemented method of claim 1.

6. requesting approval of said origination request from a registrar; receiving an approval of said origination request by said registrar; further comprising the description of the digital asset is stored in response to receiving the approval of the origination request.

10. The computer-implemented method of claim 1.

7. wherein the step of requesting approval of the origination request includes creating an approval smart contract; receiving approval of the origination smart contract includes receiving an indication that the registrar has signed the approval smart contract; 7. The computer-implemented method of claim 6.

8. requesting approval of said asset issuance request from a registrar; receiving approval of the asset issuance request by the registrar; further comprising the one or more instances of the digital asset are created in response to receiving the approval of the asset issuance request.

10. The computer-implemented method of claim 1.

9. the step of requesting approval of the asset issuance request includes creating an approval smart contract; receiving approval of the asset issuance smart contract includes receiving an indication that the registrar has signed the approval smart contract; 9. The computer-implemented method of claim 8.

10. The distributed ledger includes a blockchain.

10. The computer-implemented method of claim 1.

11. the asset origination smart contract is a DAML smart contract; 10. The computer-implemented method of claim 1.

12. A non-transitory computer-readable medium containing instructions stored thereon, the instructions, when executed, causing a computing system to: receiving an origination request identifying a digital asset; obtaining asset origination information describing the digital asset; storing a description of the digital asset derived from the asset origination information in an origination smart contract on a distributed ledger; receiving an asset issuance request; retrieving the description of the digital asset in response to the asset issuance request; creating one or more instances of the digital asset on the distributed ledger; A non-transitory computer-readable medium for performing operations including:

13. The operation is receiving a definition of the digital asset; and creating the origination smart contract using the definition; storing the description of the digital asset includes committing the asset origination smart contract to the distributed ledger; The non-transitory computer-readable medium of claim 12.

14. Retrieving the description of the digital asset includes: receiving an identifier of the origination smart contract; querying the distributed ledger using the identifier of the origination smart contract to identify the description of the digital asset; Including, The non-transitory computer-readable medium of claim 12.

15. Creating the one or more instances of the digital asset on the distributed ledger includes: creating an asset deposit smart contract in the issuer's account; Creating an issuance smart contract in the securities issuing account Including, The non-transitory computer-readable medium of claim 12.

16. the operations further include verifying that the quantity of instances of the digital asset represented in the issuer's account matches the quantity of instances of the digital asset represented in the securities issuing account; The non-transitory computer-readable medium of claim 12.

17. The operation is requesting approval of said origination request from a registrar; receiving an acknowledgement of the origination request by the registrar; the description of the digital asset is stored in response to receiving the approval of the origination request. The non-transitory computer-readable medium of claim 12.

18. requesting approval of the origination request includes creating an approval smart contract; receiving approval of the origination smart contract includes receiving an indication that the registrar has signed the approval smart contract; 20. The non-transitory computer-readable medium of claim 17.

19. The operation is requesting approval of said asset issuance request from a registrar; receiving approval of said asset issuance request by said registrar; further comprising the one or more instances of the digital asset are created in response to receiving the approval of the asset issuance request. The non-transitory computer-readable medium of claim 12.

20. requesting approval of the asset issuance request includes creating an approval smart contract; receiving approval of the asset issuance smart contract includes receiving an indication that the registrar has signed the approval smart contract; 20. The non-transitory computer-readable medium of claim 19.

21. 1. A computer-implemented method comprising: identifying entitlements and corresponding entitlement expiration dates; identifying the entitlement rights held by a custodian in a first tier of a hierarchy of entitlement rights, the hierarchy being stored in a distributed ledger; distributing a portion of the entitlement to the custodians according to their entitlements on the entitlement expiration date; Including, A computer-implemented method in which at least some of the custodians identify investors in a second tier of the hierarchy who have rights to the entitlements and allocate those portions of the entitlements to the investors according to their rights in the entitlements.

22. identifying, by at least a portion of the investors, additional investors entitled to the entitlement in a third tier of the hierarchy; distributing, by said at least some of said investors, corresponding portions of said entitlements to said additional investors according to their rights in said entitlements; further comprising:

22. The computer-implemented method of claim 21.

23. the entitlement is a coupon payment; 22. The computer-implemented method of claim 21.

24. the rights in the entitlement are represented by claim tokens on the distributed ledger; 22. The computer-implemented method of claim 21.

25. The distributed ledger includes a blockchain.

22. The computer-implemented method of claim 21.

26. The blockchain is a permissioned blockchain and smart contracts are used to express the rights in the entitlement so that participants can only see the rights to which they are entitled or responsible.

26. The computer-implemented method of claim 25.

27. the distributed ledger further includes a second blockchain; The rights in the first tier of the hierarchy are stored on the blockchain; rights at the second tier of the hierarchy are stored on the second blockchain; 26. The computer-implemented method of claim 25.

28. providing notice to at least one of the custodians that the entitlement will be paid prior to payment of the entitlement; the at least one custodian, in response to the notice, identifies the investor entitled to the entitlement prior to payment of the entitlement; 22. The computer-implemented method of claim 21.

29. A non-transitory computer-readable medium containing instructions stored thereon, the instructions, when executed by a computing system, causing the computing system to: Identifying the entitlements and corresponding entitlement expiration dates; identifying the entitlement rights held by a custodian in a first tier of a hierarchy of entitlement rights, the hierarchy being stored in a distributed ledger; distributing a portion of said entitlement to said custodians according to their entitlements on said entitlement expiration date; and performing an operation including A non-transitory computer-readable medium, wherein at least some of the custodians identify investors in a second tier of the hierarchy who are entitled to the entitlements and allocate those portions of the entitlements to the investors according to their entitlements in the entitlements.

30. The above operation is identifying, by at least a portion of the investors, additional investors entitled to the entitlement in a third tier of the hierarchy; distributing by said at least some of said investors a corresponding portion of said entitlement to said additional investors in accordance with their rights in said entitlement; further comprising:

30. The non-transitory computer-readable medium of claim 29.

31. the entitlement is a coupon payment; 30. The non-transitory computer-readable medium of claim 29.

32. the rights in the entitlement are represented by claim tokens on the distributed ledger; 30. The non-transitory computer-readable medium of claim 29.

33. The distributed ledger includes a blockchain.

30. The non-transitory computer-readable medium of claim 29.

34. The blockchain is a permissioned blockchain and smart contracts are used to express the rights in the entitlement so that participants can only see the rights to which they are entitled or responsible.

34. The non-transitory computer-readable medium of claim 33.

35. the distributed ledger further includes a second blockchain; The rights in the first tier of the hierarchy are stored on the blockchain; The rights at the second tier of the hierarchy are stored on the second blockchain.

34. The non-transitory computer-readable medium of claim 33.

36. providing notice to at least one of the custodians that the entitlement will be paid prior to payment of the entitlement; the at least one custodian, in response to the notice, identifies the investor entitled to the entitlement prior to payment of the entitlement; 30. The non-transitory computer-readable medium of claim 29.

37. 1. A computing system comprising: one or more processors; and a memory storing instructions that, when executed by the one or more processors, cause the computing system to: Identifying the entitlements and corresponding entitlement expiration dates; identifying the entitlement rights held by a custodian in a first tier of a hierarchy of entitlement rights, the hierarchy being stored on a distributed ledger; and distributing a portion of said entitlement to said custodians according to their entitlements on said entitlement expiration date; and performing an operation including A computing system in which at least some of the custodians identify investors in a second tier of the hierarchy who have rights to the entitlements and allocate those portions of the entitlements to the investors according to their rights in the entitlements.

38. The above operation is identifying, by at least a portion of the investors, additional investors entitled to the entitlement in a third tier of the hierarchy; distributing by said at least some of said investors a corresponding portion of said entitlement to said additional investors in accordance with their rights in said entitlement; further comprising:

38. The computing system of claim 37.

39. The distributed ledger is a permissioned blockchain and smart contracts are used to express the rights in the entitlements so that participants can see only the rights to which they are entitled or responsible.

38. The computing system of claim 37.

40. the distributed ledger includes a first blockchain and a second blockchain; The rights at the first tier of the hierarchy are stored on the first blockchain; The rights at the second tier of the hierarchy are stored on the second blockchain.

38. The computing system of claim 37.

41. 1. A computer-implemented method comprising: receiving a first transaction summary request for the transaction from a first party; capturing details of the transaction in a smart contract stored on a distributed ledger; receiving a second transaction summary request for the transaction from a second party; matching the first transaction summary request with the second transaction summary request; generating settlement instructions to effectuate the transaction in response to said match; receiving signatures of custodians of the first and second parties; processing the settlement instruction; A computer-implemented method comprising:

42. the step of matching the first transaction summary request with the second transaction summary request is performed using a balancing queue.

42. The computer-implemented method of claim 41.

43. The balancing queue is implemented using immutable smart contracts.

43. The computer-implemented method of claim 42.

44. the balancing queue is a virtual balancing queue implemented without any additional object to preserve the order of the transaction summary requests; 43. The computer-implemented method of claim 42.

45. the first and second transaction aggregate requests are keyed into the balancing queue using transaction economics and a repeat key; 43. The computer-implemented method of claim 42.

46. the step of matching the first transaction summary request with the second transaction summary request includes, in response to receiving the second transaction summary request, performing recursive keyed queries for other transactions with matching economics until the first transaction summary request is identified.

46. ​​The computer-implemented method of claim 45.

47. the balancing queue is rebalanced so that the first trade aggregate request becomes the earliest or latest matching trade aggregate request of a plurality of possible matching trade aggregate requests for the second trade aggregate request.

47. The computer-implemented method of claim 46.

48. in response to receiving the first trade summary request, querying a virtual balancing queue for a matching trade summary request; adding the first trade summary request to the virtual balancing queue in response to not finding a matching trade summary request; further comprising:

42. The computer-implemented method of claim 41.

49. receiving the signatures of the custodians includes the custodians signing a smart contract with their digital signatures; 42. The computer-implemented method of claim 41.

50. A non-transitory computer-readable medium containing instructions stored thereon, the instructions, when executed, causing a computing system to: receiving a first transaction summary request for the transaction from a first party; capturing details of said transaction in a smart contract stored on a distributed ledger; receiving a second transaction summary request for the transaction from a second party; Matching the first transaction summary request with the second transaction summary request; generating settlement instructions to effectuate the transaction in response to said matching; receiving signatures of custodians of the first party and the second party; processing said settlement instruction; A non-transitory computer-readable medium for performing operations including:

51. Matching the first transaction summary request with the second transaction summary request is performed using a balancing queue.

51. The non-transitory computer-readable medium of claim 50.

52. The balancing queue is implemented using immutable smart contracts.

52. The non-transitory computer-readable medium of claim 51.

53. the balancing queue is a virtual balancing queue implemented without any additional object to preserve the order of the transaction summary requests; 52. The non-transitory computer-readable medium of claim 51.

54. the first and second transaction aggregate requests are keyed into the balancing queue using transaction economics and a repeat key; 52. The non-transitory computer-readable medium of claim 51.

55. Matching the first transaction summary request with the second transaction summary request includes, in response to receiving the second transaction summary request, performing recursive keyed queries for other transactions with matching economics until the first transaction summary request is identified.

55. The non-transitory computer-readable medium of claim 54.

56. the balancing queue is rebalanced so that the first trade aggregate request becomes the earliest or latest matching trade aggregate request of a plurality of possible matching trade aggregate requests for the second trade aggregate request.

56. The non-transitory computer-readable medium of claim 55.

57. The operation is responsive to receiving the first trade summary request, querying a virtual balancing queue for a matching trade summary request; adding the first trade aggregate request to the virtual balancing queue in response to not finding a matching trade aggregate request; further comprising:

51. The non-transitory computer-readable medium of claim 50.

58. receiving the signatures of the custodians includes the custodians signing a smart contract with their digital signatures; 51. The non-transitory computer-readable medium of claim 50.

59. 1. A system comprising: one or more processors; and a memory storing instructions that, when executed by the one or more processors, cause the computing system to: receiving a first transaction summary request for the transaction from a first party; capturing details of the transaction in a smart contract stored on a distributed ledger; receiving a second transaction summary request for the transaction from a second party; Matching the first transaction summary request with the second transaction summary request; generating settlement instructions to effectuate the transaction in response to said matching; receiving signatures of custodians of the first party and the second party; processing said settlement instruction; A system that performs an operation including:

60. matching the first transaction summary request with the second transaction summary request is performed using a balancing queue; the first and second transaction aggregate requests are keyed into the balancing queue using transaction economics and a repeat key; Matching the first transaction summary request with the second transaction summary request includes, in response to receiving the second transaction summary request, performing recursive keyed queries for other transactions with matching economics until the first transaction summary request is identified; the balancing queue is rebalanced so that the first trade aggregate request becomes the earliest or latest matching trade aggregate request of a plurality of possible matching trade aggregate requests for the second trade aggregate request; 60. The system of claim 59.

61. 1. A computer-implemented method comprising: receiving a settlement instruction for a transaction involving the parties; pushing information about the transaction to an off-ledger system associated with the parties; receiving a digital signature of the party from the off-ledger system; responsive to receiving the digital signature of the party, conducting the transaction using the settlement instruction; A computer-implemented method comprising:

62. The distributed ledger is the blockchain, 62. The computer-implemented method of claim 61.

63. storing the digital signature and the information about the transaction in a smart contract in a distributed ledger.

62. The computer-implemented method of claim 61.

64. and further comprising: verifying the execution of the transaction using the information about the transaction stored in the smart contract on the distributed ledger.

64. The computer-implemented method of claim 63.

65. and verifying the execution of the transaction includes comparing the information about the transaction pushed to the off-ledger system with the information about the transaction stored in the smart contract on the distributed ledger.

65. The computer-implemented method of claim 64.

66. The party does not operate a node of the distributed ledger, and a second party operates a node of the distributed ledger on behalf of the party; 62. The computer-implemented method of claim 61.

67. receiving the digital signature of the party includes retrieving the digital signature using a webhook of the off-ledger system; 62. The computer-implemented method of claim 61.

68. A non-transitory computer-readable medium that, when executed, causes a computing system to: receiving settlement orders for transactions involving the parties; pushing information about the transaction to an off-ledger system associated with the party; and receiving a digital signature of the party from the off-ledger system; responsive to receiving the digital signature of the party, conducting the transaction using the settlement instruction; A non-transitory computer-readable medium having stored thereon instructions for causing the execution of operations including:

69. The distributed ledger is the blockchain, 69. The non-transitory computer-readable medium of claim 68.

70. the operations further include storing the digital signature and the information about the transaction in a distributed ledger.

69. The non-transitory computer-readable medium of claim 68.

71. the operations further include verifying the execution of the transaction using the information about the transaction stored in the smart contract on the distributed ledger.

71. The non-transitory computer-readable medium of claim 70.

72. and verifying the execution of the transaction includes comparing the information about the transaction pushed to the off-ledger system with the information about the transaction stored in the smart contract on the distributed ledger.

72. The non-transitory computer-readable medium of claim 71.

73. The party does not operate a node of the distributed ledger, and a second party operates a node of the distributed ledger on behalf of the party; 69. The non-transitory computer-readable medium of claim 68.

74. receiving the digital signature of the party includes retrieving the digital signature using a webhook of the off-ledger system; 69. The non-transitory computer-readable medium of claim 68.

75. 1. A system comprising: one or more processors; and a memory storing instructions that, when executed by the one or more processors, cause the computing system to: receiving settlement orders for transactions involving the parties; pushing information about the transaction to an off-ledger system associated with the party; and receiving a digital signature of the party from the off-ledger system; responsive to receiving the digital signature of the party, conducting the transaction using the settlement instruction; A system that performs an operation including:

76. the operations further include storing the digital signature and the information about the transaction in a distributed ledger.

76. The system of claim 75.

77. the operations further include verifying the execution of the transaction using the information about the transaction stored in the smart contract on the distributed ledger.

77. The system of claim 76.

78. and verifying the execution of the transaction includes comparing the information about the transaction pushed to the off-ledger system with the information about the transaction stored in the smart contract on the distributed ledger.

78. The system of claim 77.

79. The party does not operate a node of the distributed ledger, and a second party operates a node of the distributed ledger on behalf of the party; 76. The system of claim 75.

80. receiving the digital signature of the party includes retrieving the digital signature using a webhook of the off-ledger system; 76. The system of claim 75.

Images