Digital asset platform

Abstract

A digital asset platform (DAP) uses distributed ledger technology and smart contract programming. The DAP may include distributed and decentralized communication networks and application systems that collectively provide end-to-end tagging, management, and lifecycle handling of digital assets. The assets may be digital native securities (e.g., bonds, stocks, funds, etc.) and non-securities (e.g., digital cash, loan, derivatives), tagged real-world assets (securities and non-securities), or any other form of tagged assets.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 380,573, filed on October 23, 2022, and U.S. Provisional Patent Application No. 63 / 381,125, filed on October 26, 2022, both of which are incorporated herein by reference. Technical Field

[0003] The present invention generally relates to the field of distributed ledger technology (DLT), and more particularly to a digital asset platform capable of providing end-to-end registration, custody, issuance, trade, settlement and services for digital assets and tokenized assets. Background Art

[0004] Distributed ledger technologies (e.g., blockchain) were developed as a means for parties to engage in transactions (e.g., financial transactions) without the need for a single, centralized authority or intermediary. In such DLT-based systems, each transaction is independently recorded by multiple nodes. In some implementations, no single entity controls all nodes, making it difficult for malicious parties to alter a transaction once it has been recorded. Even in implementations where a single entity controls all nodes, it remains difficult to alter data recorded on enough nodes to change the consensus indicated by all nodes without leaving any indication that the data has been tampered with.

[0005] In many cases, parties desire to exchange digital assets, or other digital assets, cash, or non-digital assets. Market participants expect digital assets to have a broad range of functionalities that mirror the rich financial products possible with traditional, non-digital methods. However, traditional digital asset systems offer only a patchwork of functionalities that address only a subset of the needs of financial market participants. Furthermore, custody requirements vary across jurisdictions, meaning that a system developed to serve market participants in one region may not be a viable solution in another where custody requirements differ. Therefore, new DLT-based financial market infrastructures (FMIs) are needed that address the intra- and inter-jurisdictional fragmentation and inefficiencies in existing digital asset systems, for example, by providing end-to-end registration, custody, issuance, trading, settlement, and servicing of digital and tokenized assets (both securities and non-securities). Summary of the Invention

[0006] These and other issues can be addressed by digital asset platforms ("DAPs" or "Platforms") that utilize distributed ledger technology (DLT) and smart contract programming. DAPs can include distributed and decentralized communication networks and application systems that together provide 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), tokenized versions of real-world assets (both securities and non-securities), or any other form of tokenized assets (collectively, "digital assets").

[0007] To comply with custody requirements for securities and non-securities in many jurisdictions, the platform may use a permissioned DLT network (e.g., a permissioned private or partnership blockchain) with nodes hosted and operated by recognized and legal institutions (e.g., custodial financial institutions). In various embodiments, the platform uses smart contracts to provide one or more of the following: a role and service management engine, primary issuance of digital assets, secondary trading of digital assets, registration and custody of securities and non-securities, settlement of digital asset transactions (e.g., cross-layer atomic settlement), account and portfolio management, and asset services (e.g., coupon generation and processing, redemption processing, splitting and consolidation of securities, etc.). BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The disclosed embodiments have advantages and features that will be more readily understood from the detailed description, the appended claims, and the accompanying drawings (or figures).

[0009] Figure 1 is a block diagram illustrating a networked computing environment suitable for providing end-to-end registration, custody, issuance, trade, settlement, and services for digital assets and tokenized assets, according to one embodiment.

[0010] Figure 2 According to one embodiment Figure 1 Block diagram of the digital asset platform.

[0011] Figure 3 is a flow chart of a method for assigning roles to entities within a platform, according to one embodiment.

[0012] Figure 4 is a flow chart of a method for creating an account on a platform according to one embodiment.

[0013] Figure 5 is a flow chart of a method for primary distribution according to one embodiment.

[0014] Figure 6 is a flow chart of a method for asset origination according to one embodiment.

[0015] Figure 7is a flow chart of a method for asset issuance according to one embodiment.

[0016] Figure 8 is a flow chart of a method for processing a transaction according to one embodiment.

[0017] Figure 9 is a block diagram of a set of accounts that use tiered claim tokenization to provide secondary and tertiary interests in digital assets, according to one embodiment.

[0018] Figure 10 is a flow chart of a method for waterfalling coupon payments through an account hierarchy, according to one embodiment.

[0019] Figure 11 is a flow chart of a method for integrating an off-chain system with a platform to provide transaction verification, according to one embodiment.

[0020] Figure 12 According to one embodiment, Figure 1 A block diagram of an example of a computer for use in a networked computing environment. DETAILED DESCRIPTION

[0021] The accompanying drawings and the following description describe certain embodiments by way of illustration only. Those skilled in the art will readily appreciate from the following description that alternative embodiments of the structures and methods may be employed without departing from the principles described. Where feasible, similar or like reference numerals are used in the drawings to indicate similar or like functionality. If elements share a common number followed by a different letter, this indicates that the elements are similar or identical. Unless the context indicates otherwise, references to numbers alone generally refer to any one or any combination of such elements.

[0022] Overview

[0023] Figure 1 One embodiment of a networked computing environment 100 suitable for providing end-to-end registration, custody, issuance, trade, settlement, and services for digital assets and tokenized assets is shown. In the illustrated embodiment, the 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, the networked computing environment 100 includes fewer, different, or additional elements. Furthermore, functionality may be distributed among the elements in a manner different from that described.

[0024] The digital asset platform 120 includes one or more computing devices that collectively provide functionality for digital and tokenized assets, including end-to-end registration, custody, issuance, trade, settlement, and servicing of these assets. These computing devices include nodes of one or more distributed ledgers (e.g., distributed ledgers 110A or 110B). The digital asset platform 120 provides information to market participants to drive user interfaces (e.g., at client devices 140) for conducting transactions involving digital assets. The digital asset platform 120 creates and manages smart contracts on one or more distributed ledgers 110 (e.g., blockchains) to provide the above functionality. Figure 2 Various embodiments of the digital asset platform 120 are described in more detail.

[0025] The distributed ledger 110 provides an immutable record that indicates the current and historical ownership of digital and tokenized assets. The distributed ledger also contains smart contracts that provide functionality related to digital and tokenized assets. Figure 1 Two distributed ledgers 110A and 110B are shown 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 on its own distributed ledger. Furthermore, in some embodiments, the platform may use a separate distributed ledger for storing smart contracts, other than those used to store digital or tokenized assets.

[0026] exist Figure 1 , a first distributed ledger 110A is shown as including three distributed nodes 112, namely 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 likely will) include several more nodes.

[0027] Distributed nodes 112 and 114 are computing devices. Distributed nodes can manage and provide blockchains or other types of distributed ledgers. Distributed nodes can also store and execute rules set by smart contracts. Therefore, when the trigger conditions of a smart contract are met, distributed nodes 112 and 114 can automatically execute one or more actions. When events or data related to a smart contract are generated, the relevant information can be added to a block on the blockchain. Blockchains and smart contracts can codify and automatically enforce the rules governing ownership and investment in digital assets.

[0028] When a distributed node 112 or 114 receives a request to conduct a transaction, it confirms or rejects whether the relevant data of the transaction is consistent with its records. If a threshold number of distributed nodes agree that the transaction is consistent with their records, the transaction is considered successfully verified. For example, Byzantine fault tolerance methods can be used to determine whether enough nodes confirm the validity of a transaction to verify it. Similarly, if a threshold number of distributed nodes agree that the triggering conditions for the action have been met, the action defined in the rules of the smart contract can be triggered.

[0029] The distributed ledger 110 typically takes one of the following forms:

[0030] - a single global ledger maintained by all nodes within the blockchain network; or

[0031] -A global ledger composed of multiple local ledgers maintained by each node in the network.

[0032] 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 a consensus on how to integrate the change into the distributed network of nodes. Under consensus, agreed-upon changes are considered confirmed, so that each node maintains a copy that should match the copies stored by other nodes. Any changes that fail to reach consensus are ignored. Therefore, unlike traditional centralized ledgers, a single party cannot unilaterally alter the blockchain.

[0033] In DLT embodiments that utilize a global ledger comprised of multiple local ledgers, when a transaction is submitted to the network, the involved nodes verify and provide confirmation of the transaction's validity. After reaching consensus, the agreed-upon changes are considered confirmed and are used to update the contract state within the local ledgers of the involved nodes. Unlike embodiments that utilize a single global ledger, each node maintains its own private ledger state, which collectively form the global ledger.

[0034] The blockchain may also include smart contracts, which are sets of executable instructions stored along with one or more trigger conditions. If the trigger conditions are met, the smart contract is triggered to execute the corresponding instructions. Each distributed node 112, 114 can receive the definition of the smart contract, but only validate any results generated by the execution of the code within the smart contract when there is consensus among the nodes on the state of the smart contract (e.g., a sufficient number of nodes agree that the trigger conditions have been met and the execution of the instructions resulted in a specific result). In other embodiments, other types of distributed ledgers may be used.

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

[0036] The network 190 provides a communication channel through which other elements of the networked computing environment 100 communicate. The network 190 may include any combination of local area networks or wide area networks using either wired or wireless communication systems. In one embodiment, the network 190 uses standard communication technologies or protocols. For example, the network 190 may 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 networking protocols for communicating via the network 190 include Multi-Protocol 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 through the network 190 may be represented using any appropriate format such as Hypertext Markup Language (HTML) or Extensible Markup Language (XML). In some embodiments, all or some communication links of the network 190 may be encrypted using any appropriate technology.

[0037] Sample Digital Asset Platform

[0038] Figure 2One embodiment of a digital asset platform 120 is shown. In the illustrated embodiment, the 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 trade module 240, an auxiliary trade module 245, a settlement engine 250, a registry and escrow module 255, a reconciliation module 260, an asset model module 265, a verification module 270, a coupon payment module 275, a redemption module 280, a delegation module 285, and an integration module 290. In other embodiments, the platform 120 includes different or additional elements. Furthermore, functionality may be distributed among the components of the platform 120 differently than described. For example, a single module may handle both origination and issuance.

[0039] The role assignment module 205 manages the roles that different entities serve on the platform 120. The following are example roles that an entity may have:

[0040] - Operator: Responsible for maintaining the DAP on the DLT, including administrative functions. The operator can control role assignment (i.e., granting different entities platform roles, which enable specific functions depending on the corresponding services assigned).

[0041] - Issuer: The trigger for the initiation and issuance of digital assets on the DLT / chain. The issuer may also delegate the initiation and issuance process to the registrar.

[0042] -Registrar: Approves the asset issuance process and maintains the integrity of issued assets. The registrar may also provide oversight and management of escrow accounts.

[0043] - Distributors: Distributors can provide lead banking services, managing the primary issuance, book generation, and allocation. Distributors can also provide syndication banking services, participating in the primary issuance workflow, onboarding investors, and submitting orders.

[0044] -Payment Agent: Identifies the coupon rate for a specific payment date, receives the net par amount from the issuer, and distributes the eligible par amount to the investor.

[0045] - Settlement Agent: Generates settlement instructions and executes atomic settlement.

[0046] - Cash Token Manager: Provides digital cash origination and issuance for digital cash tokens represented on-chain.

[0047] -Distributor / Syndicate Bank: Responsible for participating in the main issuance workflow, investor onboarding and order submission.

[0048] - Custodian: Responsible for approving on-chain settlement instructions on behalf of investors. Custodians protect and manage assets on behalf of investors.

[0049] Investors: Enables clients to submit primary or secondary market orders, indications of interest (IOIs), requests for quotes (RFQs), and requests for tenders (RFTs), as well as approve settlement instructions. Investors can also access portfolio / account management services to review their on-chain digital asset holdings. In some embodiments, investors can also delegate their account and settlement obligations and functions to a custodian.

[0050] -Oracles: Provide the platform with links to off-chain reference data feeds, such as calendars, benchmarks, and legal entity data.

[0051] - Secondary traders: Create / delete IOIs, orders or RFQ / RFTs to provide liquidity facilities for investors and the market.

[0052] Role allocation can be centralized or decentralized. Figure 3 An example method 300 for assigning roles to entities using a centralized approach is shown according to one embodiment. In the illustrated embodiment, the method 300 begins with the role assignment module 205 identifying 310 an entity and an intended role for the entity. The entity can be identified 310 by a user providing a legal entity identifier (LEI) or other identifier for the entity, while the role can be identified by a text string representing the name of the role or another unique identifier for the role.

[0053] The role assignment module 205 sends 320 a role offer to an entity by creating a smart contract on a distributed ledger for the entity and the role. The entity can be notified of the creation of the offer smart contract by a message sent to a client device 140 associated with the entity, such as by sending an email, instant message, or other type of message to an account of the entity 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 role is assigned 340 to the entity. The role can be assigned by creating a role smart contract that identifies the entity (e.g., by its LEI) and the role (e.g., the role name) and archiving the offer smart contract. The role assignment module 205 can also create a service smart contract that includes code for the entity to perform actions associated with the assigned role. Alternatively, other data structures can be used to identify the roles assigned to the entity and define the permissible actions.

[0054] The role assignment module 205 can also assign roles to specific releases. In one embodiment, the identifiers of entities and the one or more roles they serve with respect to an release are stored in a smart contract or other data object associated with the release. When an entity attempts to perform an action related to an release, the role assignment module 205 can check whether the entity has both the relevant role assigned to it (globally) and the role assigned for a specific release.

[0055] In a decentralized embodiment, a similar approach can be taken, where instead of a single entity assigning roles, any entity can assume a new role as a product administrator. This new role allows the entity to determine what roles different parties will play in the context of a primary offering (e.g., an entity can be the lead banker in a primary offering and an investor in another primary offering, with its functions and limitations always derived within the context of the offering it operates). Entities still accept or approve the functional roles of their offerings, but can do so without storing a specific role smart contract on-chain to capture those approvals. Instead, the role an entity plays for an offering can be stored in association with an identifier for that offering.

[0056] In a decentralized configuration, the platform 120 provides three types of protection against malicious or unintended use. First, a model for confirming that entities are authorized to act on a specific offering is provided at the API layer, through which entities interact with the platform. Second, while any entity can be a product administrator and assign roles to an offering, legally binding asset transfers only occur when all parties sign the transaction. Third, if malicious or unintended functionality is executed, node operators retain emergency permissions to block user access and delete any contracts determined to be invalid for any reason.

[0057] Return Reference Figure 2 The account creation module 210 creates accounts for entities using the platform. In one embodiment, account creation involves two parties: the account provider and the account owner. The account provider is the entity with a custodial role, while the account owner can be any entity on the platform 120. Accounts are represented on-chain by smart contracts that include identifiers for the account, the provider, and the owner, as well as the account's KYC status. Typically, the account provider is responsible for maintaining / updating the account's KYC status.

[0058] Figure 4An example method 400 for creating an account on the platform 120 according to one embodiment is shown. In the illustrated embodiment, the method 400 begins with the account creation module 210 receiving 420 an escrow request from one of the parties (e.g., the account owner or the custodian). The escrow request may be represented by a smart contract stored on-chain. The account creation module 210 may receive 430 approval of the escrow request from the other party. The other party may provide approval by signing the smart contract. When the other party signs, the escrow relationship may be established on-chain by creating 440 an escrow service smart contract. The escrow request smart contract may be archived at this time. Similarly, if an escrow request is received from the custodian and identifies the account owner, then when the account owner signs the escrow request smart contract, the account creation module 210 creates 440 an escrow service smart contract (and may archive the escrow request smart contract). The escrow service smart contract includes code for providing escrow service functionality. The account creation module 210 also receives 450 an account creation request from the account owner, who created the account request smart contract. Upon receiving 460 approval of the account creation request from the custodian that signed the account request smart contract, the account creation module 210 creates 470 the account (which is a smart contract) and may archive the account request smart contract. The account smart contract includes information about the account as described above.

[0059] Return Reference Figure 2 , the account management module 215 provides a user interface (e.g., via the client device 140) that an account owner can use to manage how their account is used. In one embodiment, an entity can hold multiple accounts from different account providers on the platform and use the interface provided by the account management module 215 to specify a default account to be used for settlement in various situations. For example, an account holder can specify: a default securities account, a default cash account, a default comprehensive securities account (if the account holder is a securities custodian), a default comprehensive cash account (if the account holder is a cash custodian), and any other default account for specified types of assets, depending on the specific use case. The account holder's default account selection can be stored on a distributed ledger in a smart contract. At settlement time, the settlement agent can use the smart contract to find out what account should be used and generate settlement instructions accordingly.

[0060] The KYC module 220 provides an interface for the account provider (e.g., via the client device 140) to update the KYC status of the account. The account provider can operate its usual KYC procedures off-chain, and in the event that the KYC status of the account holder changes, the account provider can use the interface provided by the KYC module 220 to add a new smart contract to the distributed ledger indicating the updated KYC status (which replaces any previous smart contract for the account). Alternatively, the account's smart contract can indicate an off-chain location where the account's KYC status is stored, and the account provider can update the KYC status stored at that location, thereby automatically making the updated KYC status available on-chain.

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

[0062] During the issuance process, the lead party updates the issuance with different statuses to represent different stages of the issuance (e.g., announced, open book, closed book, launched, allocated, priced, canceled). For each issuance, allocation and price discovery can be set to manual with the help of the underwriter or through auction crowdsourcing. The ledger construction process can be completed on-chain, or can be performed off-chain and then fed into the platform 120 and recorded on the ledger via direct use of the platform UI or API to manage and execute the on-chain ledger construction, or integrated with a traditional ledger construction system, which feeds the resulting trade, order, and allocation information into the platform 120 for recording on the distributed ledger.

[0063] Figure 5 A method 500 for primary issuance according to one embodiment is shown. The method is described from the perspective of the primary issuance module 225 executing the method 500, but it should be understood that, unless otherwise specified, the steps are performed at the direction of the lead bank for the transaction (e.g., in response to instructions provided via a user interface at the lead bank's client device 140).

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

[0065] Once the price of the offering is set, 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 involve two parties: the issuer and the registrar. In one embodiment, issuance and instrumentation services are established between the issuer and the registrar before asset origination and issuance begin. Assuming the required services are in place, the issuance and origination of digital assets are considered two distinct processes. Origination creates a smart contract that includes a description of the digital asset (or an instrument that defines the digital asset), but does not represent the legal creation or ownership of the digital asset. In contrast, issuance creates tokens representing instances of the digital asset and assigns ownership of those tokens on-chain. Individual tokens do not include a description of the digital asset, but instead refer back to the smart contract created during origination. As a result, only one instance of the digital asset description is stored on-chain, which improves efficiency and eliminates the risk of inconsistent definitions between instances.

[0066] Figure 6 An example method 600 for originating a digital asset, according to one embodiment, is shown. In the illustrated embodiment, the method 600 begins with the asset origination module 230 receiving 610 an origination request from the issuer of the digital asset. The asset origination module 230 retrieves 620 information about the asset from the 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, which enables verification that the origination is consistent with the information about the issuance in the registry. Approval can be requested by creating an approval smart contract on a 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 an asset description. The description is a dataset that details the characteristics of the digital asset. The dataset can be stored on-chain in a smart contract.

[0067] Figure 7An example method 700 for issuing digital assets according to one embodiment is shown. In the illustrated embodiment, method 700 begins with the asset issuance module 235 receiving 710 an issuance request from the 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 the registrar for approval. Assuming the registrar does not identify any issues with the issuance request, the registrar sends an approval of the issuance request, which is received 740 by the asset issuance module 235. The asset issuance module 235 then creates 750 an asset deposit and an issuance. An issuance is one or more instances of an asset described by the dataset created for that asset by the asset issuance module 230. An asset deposit is an instance of a digital asset credited to the issuer's account, representing a pending issuance, while an issuance is a record of the number of digital assets issued. The combination of the asset deposit account and issuance provides a check to ensure that the number of digital assets intended to be issued by the issuer matches the number of digital assets actually issued (i.e., held by entities in the platform).

[0068] Reference again Figure 2 , the primary trade module 240 manages primary trades of digital assets. In one embodiment, the primary trade module 240 supports a variety of trades that can be composed of various hierarchical structures (including flat issuance schemes without a hierarchical structure). Example types of trades supported include: (1) reduction trades (trades between the issuer and the lead bank to reduce the entire issuance); (2) investor trades (trades between investors and banks to purchase digital assets); (3) residual trades (sharing of residual unallocated assets between syndicate banks in the event of undersubscription); (4) broker trades (trades between the lead bank and the syndicate banks that allow the syndicate banks to settle directly with their own investors); and (5) direct allocation trades (trades between the issuer and investors). The lead bank can register these primary trades in the platform 120 based on the size of the issuance and investor orders submitted during the account establishment phase.

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

[0070] The secondary trade module 245 enables the trading of ownership and beneficial interests in digital assets in the secondary market. In one embodiment, the secondary trade module 245 provides a bulletin 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 discuss and, assuming they can agree on terms, agree to a trade. Once both parties reach an agreement, either party can begin creating a trade summary. Once one party creates a trade summary request using the user interface, the other party can confirm the submission. Assuming confirmation is provided, the settlement agent initiates settlement from the creation of the trade. From there, settlement proceeds in the same manner as a primary issuance or any other trading environment.

[0071] In one embodiment, the secondary trade module 245 provides efficient trade summary matching. In traditional trade matching systems that do not involve a distributed ledger, the system can query a database of trade information for all trades that meet a specified set of criteria. However, when using a distributed ledger, retrieving trade information is limited to keyed lookups, which makes identity matching more difficult.

[0072] To address this issue, when the platform 120 receives counterparty trade summaries, it stores them on-chain in a custom queue. The queue is rebalanced to always return the earliest matching (or latest matching, depending on the specific needs of the implementation) counterparty trade summary. A self-ordering 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 the ordering and is self-contained. In one embodiment, the queue is a virtually balanced queue, meaning that it does not require any further data storage and does not use any other data structures besides creating a smart contract for the unilateral trade. In other traditional implementations of queues, additional data structures are often used with properties so that elements in the queue are removed in the order they were added to the queue. However, virtual queues are implemented through existing smart contracts that are controlled with iteration keys.

[0073] To enable efficient lookups from the queue, each side of a trade is keyed using the trade economics and iteration keying. Iteration keying allows for searching within an iterative algorithm while also ensuring uniqueness. When the platform ingests one side of a trade, the platform 120 performs an iterative keyed lookup on other trades with the same economics but opposite sides. If a match is found, both sides of the trade are matched. The queue is rebalanced so that if multiple potential matches exist, either the earliest or latest potential match is returned, depending on the specific implementation of the queue. Conversely, if no match is found, the trade is stored in a virtual balanced queue.

[0074] Figure 8An example method 800 for creating a trade summary and processing a transaction, according to one embodiment, is shown. In the illustrated embodiment, method 800 begins with secondary trade module 245 receiving 810 a request for a trade summary. As previously described, either party to a trade can send a request for a trade summary (e.g., using a user interface provided at client device 140). Secondary trade module 245 captures 820 the details of the trade (e.g., the assets being transferred and the identities of the parties) and creates a trade summary request smart contract. Later, secondary trade module 245 also receives 830 a trade summary request from a counterparty. The two trade summary requests are matched 840. Settlement generates 850 settlement instructions to implement the trade defined by the matched trade summary requests 840. The settlement instructions are provided to the custodians of the parties to the trade, and assuming the custodians approve the settlement instructions, the custodians provide their signatures to secondary trade module 245. Upon receiving 860 the custodian's signature, secondary trade module 245 causes a settlement agent to process 870 the settlement instructions to credit the appropriate digital assets to the counterparties.

[0075] If relevant custody requirements permit, the platform 120 may provide electronic trading capabilities to provide better liquidity management after the issuance of digital assets. For example, the platform 120 may provide 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 the platform 120 or by integrating with an existing trading engine (e.g., via an API).

[0076] Reference again Figure 2 The settlement engine 250 is responsible for the settlement process after generating a trade. In one embodiment, the generated settlement instruction is signed by both the sender and the receiver, and the trade is settled by the settlement agent. The settlement agent settles the trade atomically, meaning that either all assets involved in the trade are transferred or no assets are transferred. In some embodiments, the settlement instruction can be used for settlement even when one of the assets is in a different blockchain. Further details on how hashed time-locked contracts (HTLCs) can be found in U.S. patent application No. 18 / 205,861, filed on June 5, 2023, which is incorporated by reference.

[0077] The settlement type can be determined based on the presence of a delivery and payment asset and the asset type. This enables the platform 120 to atomically implement the following types of settlements: (1) delivery-to-payment; (2) no payment and no delivery; and (3) delivery-to-delivery and payment-to-payment. Because the platform 120 allows for cross-chain representation of assets, the settlement process can also support atomic settlement of trades across two or more chains.

[0078] In various embodiments, the settlement engine 250 uses a settlement agent bot (which can be a bot that is always running) to automate the DvP and FoP settlement processes. The settlement engine 250 can use some or all of the following processes to provide automated or near-automated atomic settlement:

[0079] -Adding a settlement agent to a trade watcher: The lead bank or operator periodically retrieves all open, visible trades and checks to see if there are any trades that do not have a settlement agent in the watcher list. If such a trade is found, the settlement agent is added to the watcher list.

[0080] - Create Settlement Instructions: The Settlement Agent periodically obtains all visible trades in an open state (both primary issuance trades and secondary trades) and generates settlement instructions as needed.

[0081] - Register Settlement Readiness: The Settlement Agent periodically retrieves all visible delivery / settlement template attempts to mark them as fully signed by all required parties. This will throw an error if not all trade counterparties have signed, meaning the instructions will not actually execute prematurely due to the need for off-chain checks. This process checks whether all settlement instructions for the trade have been signed by both parties. If all those signatures are in place, the trade is considered ready for settlement. If all signatures are in place, a boolean value is set on any HTLC-locked settlement instructions to indicate that all signatures are in place. This lets the buy-side HTLC connector bot (which doesn't inherently have the ability to check whether all parties have provided the required signatures) know that everything is ready for execution.

[0082] Settlement Trades: The settlement agent periodically retrieves all visible delivery / settlement templates and attempts to execute its selected settlement instructions. These instructions will throw an error if not all counterparties have signed, so the settlement agent can call these instructions so that those that are ready to execute are executed, while those that are not ready to execute remain unexecuted, without the need for off-chain checks.

[0083] - Asset servicing automation: The settlement agent regularly settles any outstanding coupon payments.

[0084] - Cancellation of settlements of canceled trades: The settlement agent periodically obtains all settlements and attempts to cancel them. A settlement is only canceled if the related trade is canceled.

[0085] - Send trade cancellation / notification SWIFT: The settlement agent periodically checks whether there is a cancelled trade or a trade that requires a notification message and, if so, sends a SWIFT message if the message was not sent previously.

[0086] - Cancel invalid trade: Settlement Agent can cancel any trade that can no longer be settled.

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

[0088] The asset registration and custody module 255 provides DLT-based on-chain registration and custody of digital assets. The wallet / account structure supporting asset registration and custody can flexibly support: (1) self-custody or custody management; (2) multi-level settings supporting custody and sub-custody relationships; (3) accounts for each investor / beneficiary owner or a comprehensive account for multiple investors / beneficiary owners; and (4) different wallet / account settings for different jurisdictions to comply with local regulations.

[0089] Utilizing a multi-tiered approach, registrants only need to custodian the accounts they are directly responsible for, rather than every account on the platform. This further allows custodians to manage the bookkeeping of the accounts they are responsible for. Figure 9 An embodiment of a hierarchical account structure is shown, with a custodian holding securities in Tier 1 accounts and providing claim tokens for digital assets in Tier 2 accounts. In the illustrated embodiment, the account structure is arranged as a three-tiered hierarchy. However, in principle, any number of tiers can exist within the hierarchy. Each additional tier enables the provider holding tokens in the preceding tier to further segment the ownership or beneficial interest represented by those tokens into several components, represented by other tokens in lower tiers. These tiers can all be stored on a single blockchain, with permissions controlling the information each participating entity can view. Alternatively, an entity with custody of assets in Tier 1 can operate a separate blockchain to record beneficial interests in the assets it holds.

[0090] Layer 1 910 of the hierarchical account structure handles the digital custody of the assets themselves. Custody of digital assets is generally limited to a small number of qualified institutional investors, depending on jurisdictional requirements (for example, some jurisdictions do not allow institutional investors to engage in self-custody). The controls implemented only allow the account owner to transfer / move assets within the account and view the assets held. Layer 1 accounts can provide ownership or beneficial interest in their custody assets to other users, hold assets as self-custodians for their own benefit, or both. Figure 9In the illustrated embodiment, Layer 1 910 includes a securities issuance account 911 (which contains the asset when it is first initiated on the ledger), one or more Layer 1 investor risk accounts 912, a first Layer 1 provider risk account 914, a Layer 1 provider omnibus client account 215, a second Layer 1 provider risk account 916, and one or more Layer 1 segregated accounts 917. As previously mentioned, each account can be a blockchain address or wallet, or an account defined within the ledger, depending on the DLT technology used. In other embodiments, Layer 1 910 can include different or additional elements. For example, any number of providers can have risk and omnibus client / segregated accounts within Layer 1 ledger 910.

[0091] The Securities Issuance Account (or Securities Issuance Record) 911 is an account that records the initial issuance of a set of assets. Therefore, information about the assets and the amount of issued assets is stored using a smart contract, which can be used to verify Layer 1 asset holdings. The Securities Issuance Account 911 is different from the trading account (used for storing securities). The Securities Issuance Account 911 neither holds custody of the assets nor indicates legal ownership of the assets, but rather serves as a registry of the assets.

[0092] Layer 1 Investor Risk Account 912 is used to authorize accounts (e.g., institutional investors) to trade in Layer 1 ledger 910. These accounts wish to self-custody their assets (i.e., directly through a registered holding account). Layer 1 Investor Risk Account 912 holds investor principal positions.

[0093] In the example shown, 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 of which stores tokens for a single entity). Depending on local regulatory requirements and client preferences, the tier structure may use only Tier 1 omnibus client accounts 915, only one set of Tier 1 segregated accounts 917, or a combination of both (e.g., local laws and regulations permit omnibus accounts, but one or more clients choose to use segregated accounts). Furthermore, while a specific number of accounts of each type is shown, Tier 1 may include accounts of each type with any number of providers for investing in digital assets available to Tier 2 users.

[0094] In some embodiments, the provider may have a risk account and a holding account. The purpose of the custodian holding a risk account and an omnibus account is to isolate the client's custody assets (held in the client's omnibus account) from its proprietary assets (held in the risk account). However, in a typical configuration, the custodian does not hold proprietary assets and therefore does not need (and therefore may not have) a risk account. That is, for the sake of completeness, Figure 9A first Tier 1 provider risk account 914 is shown, which may hold digital assets held by the custodian in its corporate capacity, as well as a Tier 1 provider omnibus client account 915 that holds custody of digital assets that the provider makes available for ownership or beneficial interest to Tier 2 users, as well as digital assets for which other Tier 1 participants have custody rights. Similarly, a second Tier 1 provider risk account 916 holds custody of digital assets held by the second provider for principal investment. However, the second provider has a Tier 1 segregated account 917, in which the second provider holds digital assets that provide beneficial interest to Tier 2 users, which are segregated from the digital assets for which other Tier 1 participants act as custodians.

[0095] The accounts in the second layer hold tokens representing ownership or beneficial interests in digital assets, which are held in the custody management accounts in layer one 910. The layer two accounts themselves do not have custody of the digital assets, but rather hold claims issued by the corresponding securities custodians. This can be achieved through ownership or beneficial interest smart contracts signed by the custody accounts. Figure 9 In the illustrated embodiment, the second layer 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 on different ledgers. Note that while the first layer 2 portion 920 is shown as branching from the layer 1 consolidated client account 915 and the second layer 2 portion 930 is shown as branching from the layer 1 segregated account 917, the layer 2 portions may branch from layer 1 consolidated client accounts, segregated accounts, or any combination of the two.

[0096] The first Layer 2 section 920 is for the first Layer 1 provider. In this case, the first Layer 1 provider / custodian protects the securities of Layer 2 clients by holding the securities in an omnibus account and using a custodian-issued claim token held in the Layer 2 account to indicate ownership or beneficial interest in the digital assets to the Layer 2 account, but none of those second-tier users further divide ownership or beneficial interest in the Layer 3 account. Thus, the accounts in the first Layer 2 section 920 hold digital assets for Layer 2 investors. The digital assets held in the custodial omnibus account are reconciled with the claim tokens located in the Layer 2 investor accounts provided by the custodian. When a Layer 2 user invests in a digital asset for which the first Layer 1 provider is the custodian, a token representing ownership or beneficial interest in the digital asset (or portion of the digital asset) is added to the first-tier user's account 922.

[0097] The second Layer 2 portion 930 similarly includes a second Layer 2 investor account 932, which may store debt tokens (issued by the custodian) representing ownership or beneficial interests in digital assets (or portions of digital assets) held by the second Layer 1 provider. The second Layer 2 portion 930 may include an omnibus client account 936 that further subdivides its ownership or beneficial interests and makes portions of the subdivided ownership or beneficial interests available to third-layer investors, a Layer 2 segregated account that stores tokens representing beneficial interests held by individual Layer 2 participants, or a combination of both. The Layer 2 omnibus client account 936 functions similarly to a Layer 1 omnibus client account (e.g., Layer 1 omnibus client account 915), except that instead of being the custodian of the digital assets, the Layer 2 omnibus client account 936 holds ownership or beneficial interests in the assets of multiple Layer 2 participants, some or all of whom may make their ownership or beneficial interests in those interests available to third-layer investors. Tier 2 segregated accounts 938 are similar to Tier 1 segregated accounts 917, except that they store the ownership or beneficial interests of individual Tier 2 participants, some or all of whom may make their ownership or beneficial interests in those interests available to Tier 3 investors.

[0098] Layer 3 940 includes accounts 942 of layer 3 users that obtain ownership or beneficial interests from layer 2 providers. It should be noted 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). Figure 9 The advantage of the illustrated layered structure is that it provides privacy controls, allowing only account providers to know the clients held and providing reconciliation between the assets they custody and the amount of debt tokens issued to the custody clients. For example, a second layer provider may only need to know the ownership or beneficial interest it has granted to layer 2 users. It may not need to know whether the layer 2 user holds these interests for its own benefit or whether they have further passed these interests to layer 3 users. Furthermore, because the layer 1 user remains the custodian of the digital assets, layer 1 910 can remain unchanged when ownership or beneficial interests are traded on layers 2 920 and 930. Similarly, if beneficial interests are exchanged or traded in layers 3 940, etc., layers 2 920 and 930 can remain unchanged.

[0099] Another advantage of the tiered structure is that different Tier 2 (or lower) components can be used to provide trading of ownership or beneficial interests in different jurisdictions. Each Tier 2 component 920, 930 can be configured to comply with local regulatory requirements for securities trading. Thus, Tier 1 910 can be general and include custody of the underlying digital asset, while Tier 2 can provide securities trading of the same underlying asset to different markets with different regulatory requirements.

[0100] Reference again Figure 2 , the reconciliation module 260 monitors whether there are discrepancies between the different layers of the hierarchy managed by the registry and custodian module 255. There are generally two types of reconciliation checks, depending on the specific nature of the asset and the configuration of the platform 120: (1) comparing records at different levels of the hierarchy to ensure consistency (e.g., for an investor with an account at a given custodian, all interests in a certain type of token in the layer 2 records match the number of that token held by that custodian at layer 1); and (2) comparing ownership as indicated on the o-chain with off-chain records.

[0101] In one embodiment, on-chain to on-chain verification is performed by a reconciliation bot that can be used by both the registrant and the custodian. When used by the registrant, the bot reconciles the registrant's issuer account (the nominal account that keeps a record of unredeemed securities) with the holdings in the registrant's Tier 1 account provided on the platform 120. When used by the custodian, the bot reconciles the custodian's Tier 2 custodial client claims with the custodian's holdings in its Tier 1 account (or accounts), which is provided by the registrant.

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

[0103] In either case, if a discrepancy is identified, the reconciliation module 260 can activate (e.g., via a smart contract) emergency rights available to the registrant to make appropriate corrections (e.g., by issuing a revised claim token). In one embodiment, the reconciliation module 260 provides two types of emergency error correction capabilities. Generally speaking, these powers are not intended or expected to be invoked on a regular basis, but rather are invoked in special circumstances where a system vulnerability invalidates the consistency of the registrant provided by the platform 120.

[0104] The first emergency power allows a registered party to create new assets in its securities account and, acting as custodian, transfer these newly created assets to its Tier 1 securities account. The second emergency power enables the custodian to transfer asset claims into or out of its managed Tier 2 securities account. Because the smart contracts running on platform 120 define which parties can create or modify these assets, this functionality requires the affected party to use their own identity to make corrections. For example, if a custodian other than the operator of platform 120 needs to move assets, that party's identity (i.e., digital signature and authorization) is required.

[0105] The asset model module 265 defines how various assets are represented within the platform. For example, the asset model module 265 can define tokens corresponding to assets using one or more tokenization models. Tokenization can generally be achieved in two ways: digitally native or tokenized. Digitally native assets are assets that are digitized and represented as smart contract tokens on-chain. In contrast, tokenized assets are assets that are tokenized externally, using another method to represent the asset on-chain. Regardless of the asset type, it is stored on-chain as a smart contract that includes the asset definition.

[0106] In one embodiment, the platform supports three broad types of assets used in trade: external assets, tokenized digital assets, and wrapped tokens. External assets can be any transaction generated outside of the chain, such as fiat cash or assets stored on a different chain. Such assets are provided by the platform's operators and cannot be minted or burned because they are not primarily stored on the chain used by platform 120. Tokenized digital assets are digital assets native to platform 120, and therefore, the tokens corresponding to these assets are fully mintable and burnable by the platform and can be provided by any entity with the issuer role. Finally, bridge operators use Wormhole or similar operators to create wrapped tokens on-chain, backed by off-chain assets (possibly on a different chain) managed by a third party that may not exist on platform 120 but is itself a token stored on-chain. Therefore, wrapped tokens are mintable and burnable, but minting and burning such tokens may require coordination with the third party that manages the underlying off-chain asset.

[0107] These asset models can be used to support various settlement and payment models in platform 120, including one or more of the following: (1) delivery-to-payment, payment-to-payment, and delivery-to-delivery for assets on the same chain (e.g., for mintable / burnable cash and security tokens and non-mintable cash tokens); (2) delivery-to-payment, payment-to-payment, and cross-chain delivery-to-delivery via HTLC settlement (e.g., for mintable / burnable security tokens and non-mintable cash tokens representing cash on different chains) or continuous settlement (e.g., for mintable / burnable security tokens and wrapped cash tokens representing cash tokens on different chains); (3) payment-free (e.g., for mintable / burnable security tokens and non-mintable fiat cash tokens); or (4) transfers, such as for payment assets or delivery assets (e.g., for any mintable token, such as coupon payments).

[0108] Verification module 270 manages the verification of the authenticity of smart contracts deployed to platform 120. In one embodiment, verification module 270 coordinates with a trusted verifier to verify smart contracts. In a centralized configuration, any valid contract must have an operator signature as part of its existence. For a more decentralized setup, the operator role can be shared and distributed among multiple parties, but valid contracts must still be signed by the operator. In a centralized embodiment with a single operator, any contract not signed by the operator is considered invalid, and transactions involving such contracts will not settle. In a multi-operator configuration, the operator role can be assigned per transaction, and smart contracts involved in a transaction may require entities with the operator role for that transaction to sign. Additionally or alternatively, a semi-decentralized configuration may allow for the assignment of a per-transaction operator who can sign the smart contract for that transaction, but it is also possible for a global operator to act as the operator and sign any smart contract under its identity.

[0109] The 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 the platform 120. Coupon payments may be settled on-chain or off-chain, depending on the specific configuration. Depending on the specific account structure used, typical parties involved in coupon payments are: (1) a payment agent; (2) a settlement agent; (3) a registrar; and (4) one or more custodians (and the debt holders / investors they are servicing).

[0110] On coupon payment day, the bot (acting as a payment agent) initiates the coupon payment flow by interacting with the ledger and identifying whether there are any payments due to investors. The corresponding coupon rate can be stored in an intermediate smart contract, which is referenced by other participants in the workflow. The registrant then begins the process of notifying custodians in the account hierarchy of the impending coupon payment so they can identify their investor positions and obtain their own investor custodian positions directly from the registrant.

[0111] Once initiated, coupon payments cascade down the hierarchy. For example, the issuer may issue the entire net coupon payment to a disbursement agent, which then passes the payment on to the registrar. The registrar may then split the coupon payment among one or more custodians, each of which then divides its portion of the payment among one or more investors based on the coupon amount.

[0112] Figure 10An example method 1000 for making coupon payments according to one embodiment is shown. In the illustrated embodiment, the 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 that have a position in the coupon. On the payment date, the coupon payment module 275 distributes 1030 the coupon payment to the custodians based on their positions and the number of coupons.

[0113] 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 1040 the investors that have positions in the coupon for which it serves as custodian. Upon receiving the coupon payment, each custodian splits 1050 its payment based on the investor's position and the amount received by the custodian. While this is described as a two-tiered waterfall of payments from the registrar to the custodian and from the custodian to the investors, it should be understood that payments can flow through any number of levels of the hierarchy. For example, one or more of the custodian's investors can serve as sub-custodians and further divide the payments they receive among additional investors.

[0114] Reference again Figure 2 , the redemption module 280 provides another example of an asset service that can be provided by the platform 120. Similar to the coupon payment module 275, the redemption module 280 can generate redemption settlement instructions for digital asset issuance, which can be settled on-chain or off-chain. Depending on the tiered account structure, the participating parties are: (1) a payment 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 Tier 1 securities account of the maturity / redemption. The custodian then passes the notification to the end investor.

[0115] Thus, cash payments and token burns can be implemented in a waterfall fashion through a hierarchical structure. Specifically, in one embodiment, the payment agent pays the registrant, and the securities issuance account is zeroed. The asset description is updated to indicate that the digital asset no longer exists. The registrant pays the custodian, and the digital assets held by the custodian for the registrant are burned by the registrant. The custodian then distributes payments to its clients and, based on arrangements with those clients (typically based on the distribution of payments), burns the digital assets. This process can be extended to any given arbitrarily complex hierarchical custody structure.

[0116] Delegation module 285 enables one party to delegate the exercise of options on its behalf within platform 120 to another party. In one embodiment, delegation is used to decentralize a party's rights down to the department level. For example, authority to sign settlement instructions for one transaction can be delegated to a first department, while authority to sign settlement instructions for another transaction can be delegated to a second department. In one embodiment, delegation module 285 provides two types of delegation: party-level delegation and service-level delegation.

[0117] Party-level delegation allows a single user to act as multiple parties. There are two built-in concepts in DAML, called DAML parties and DAML users. A DAML party represents an identity that can interact with the ledger by submitting DAML commands, thereby creating DAML transactions and DAML contracts on the ledger. A DAML user, on the other hand, is local to a given party node and is associated with a master party and a dynamic set of one or more actAs and readAs parties. An A associated with multiple DAML parties is able to act as those parties and submit DAML commands on their behalf.

[0118] For example, an issuer may wish to delegate responsibility for its on-chain participants to another organization (e.g., Bank A and Custodian B). In this scenario, Custodian B user rights are defined to act as both a Bank A DAML party and a Custodian B DAML party. With these rights, the Custodian B user can use the Bank A DAML party identity to submit DAML commands (as Bank A), which results in the creation of DAML transactions and DAML contracts (signed with Bank A).

[0119] Service-level delegation uses an on-chain delegation model to allow a delegate to exercise options (within a service contract) on behalf of another party. As previously mentioned, in some embodiments, each party is assigned to one or more roles. Each of the assigned roles has its own service DAML contract that defines a list of allowed actions that role can perform. In this setup, an on-chain delegation DAML contract can be created between the principle and the delegating party, which defines the options that allow the delegating party to use the issuer identity to execute certain service contract options.

[0120] The integration module 290 enables the integration of the platform 120 with off-chain systems. In one embodiment, the integration module 290 enables an entity that does not operate a node in the platform 120 to participate in the platform via a node managed by another entity in a manner that still provides 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 enable the entity to inspect the API payload that will be submitted to the node operating on its behalf. The entity can attach its signature using its off-chain system, and the integration module 290 retrieves the signature via a webhook. The integration module 290 adds the retrieved signature to the blockchain in the smart contract along with the transaction details. Therefore, the entity can verify at any time whether the on-chain information matches what was originally signed using the off-chain system.

[0121] Figure 11 An example method 1100 for processing a transaction is shown, according to one embodiment, in which a party does not maintain its own node and instead uses an off-chain system to sign the transaction. In the illustrated embodiment, method 1100 begins with integration module 290 receiving 1110 settlement instructions for a transaction and pushing 1120 information about the transaction to the off-chain system. Assuming the off-chain system approves the settlement instructions, integration module 290 receives 1130 the party's signature from the off-chain system (e.g., via a webhook as described above). Integration module 290 stores 1140 the signature and transaction information on-chain and implements 1150 the transaction according to the settlement instructions. Later, the party can use the on-chain transaction information to verify 1160 that the implemented transaction matches its intention. Any changes between the on-chain transaction information and the information signed by the party using its off-chain system are apparent because the signature is invalid unless the on-chain information matches the off-chain signed information.

[0122] Based on the above, it is clear to those skilled in the art that the disclosed platform 120 includes several technical improvements and advantages over existing digital asset trading systems. In addition, the design of the platform 120 facilitates easy upgrading and modification to meet specific needs.

[0123] In one embodiment, the platform 120 utilizes extracted method contracts. Extracted method contracts are smart contracts that have optional implementation functionality that behaves independently of the contract state (which may not include obtaining data about the signatories of the method contract). For example, an application may deliver functionality that performs a payment, and part of that functionality is complex validation that the payment amount is within a rule set (which may specify maximum / minimum / denomination values, or rules for retrieving those values, etc.). Rather than writing a single DAML contract that contains the complete implementation logic, the implementation can be split into two contracts: (1) a main DAML contract that implements most of the implementation logic; and (2) a separate DAML contract (in a separate DAR) that implements the payment amount validation portion. The main contract can call the validation contract to assert validity synchronously, or can wait for the validation contract to send a proof of validity (note that "waiting" is not necessarily asynchronous in practice).

[0124] The advantage of this pattern is that upgrades require only a few contract replacements (of the extracted method contracts), which is fewer than replacing each application contract because multiple instances of the application contract can share a single instance of the extracted method contract. Therefore, the minimum number of extracted method contract instances is one, and the minimum number of extracted method contracts required to perform this operation without exposing additional data is equal to the number of nodes in platform 120.

[0125] Another design feature used in some embodiments to provide upgradeability is a retroactive upgrade interface implemented using DAML templates. These retroactive upgrade interfaces can perform a complete upgrade without requiring any action from anyone other than the node operator. Furthermore, this approach supports upgrades with a high degree of flexibility in writing code, with few (if any) requirements on the structure and content of the code.

[0126] For templates that upgrade without changing the schema, a single traceability interface with the option "upgrade" can be written and retroactively implemented on all those templates, with a single party acting as the controller. For templates that change schemas, a separate traceability interface contract can be written for each such schema-changing template, with a single option "upgrade" and the appropriate parameters for the schema conversion logic and additional data, again with a single party acting as the controller.

[0127] Once a DAR (containing the updater traceability interface) is created, issued, and uploaded to a node, the DAML contract upgrade process proceeds automatically. Upgrade selection is handled by a single controller, eliminating the need for traditional "upgrade proposal" contracts to coordinate and accumulate signatures from various parties on different nodes. Instead, each upgrade contract uses a single method call with single-party authority. Therefore, the number of operations required is equal to the number of contract instances for all templates in all DARs being updated. This is significantly fewer operations than would typically be required using traditional upgrade methods.

[0128] In one embodiment, the coordination of the upgrade process includes each node uploading a DAR of the new version of the package and the DAR of the Upgrader Traceback Interface. Each node operator naturally knows which templates they are responsible for upgrading because the Upgrader Traceback Interface defines rules that identify the specific party that is expected to perform the upgrade for each contract, and the node operator knows whether the party is hosted on its node. Each node operator can grant itself an "ActAs" mark for any party hosted on its node. On an agreed schedule (which can be a rolling or A / B approach), the node operator upgrades the contract instance. The node operator gives itself an "ActAs" mark as the party responsible for upgrading the contract, calls the "Upgrade" method, and provides the required parameters if the "Upgrade" method includes handling a scenario change that requires parameters.

[0129] Computing system architecture

[0130] Figure 12 An example computer 1200 suitable for use as part of a digital asset platform 120, client device 140, or distributed node 112 or 114, according to one embodiment, is shown. The example 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." It should be understood that this means that the stated operations are performed by one or more processors working individually or in conjunction. The chipset 1204 includes a memory controller hub 1220 and an input / output (I / O) controller hub 1222. Memory 1206 and a graphics adapter 1212 are coupled to the memory controller hub 1220, and a display 1218 is coupled to the graphics adapter 1212. Storage device 1208, keyboard 1210, pointing device 1214, and network adapter 1216 are coupled to the I / O controller hub 1222. Other embodiments of the computer 1200 have different architectures.

[0131] exist Figure 12 In the illustrated embodiment, the 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. The memory 1206 stores, for example, instructions for executing the methods described above, and data used by the processor 1202. The pointing device 1214 may be a mouse, a trackball, a touch screen, or any other type of pointing device, and may be used in combination with the keyboard 1210 (which may be an on-screen keyboard) to enter data into the computer system 1200. The graphics adapter 1212 causes images and other information to be displayed on the display 1218. The network adapter 1216 couples the computer system 1200 to one or more computer networks (e.g., the network 190). Figure 1 The type of computer used by the entity may vary depending on the embodiment and the processing power required by the entity. In addition, the computer may lack some of the components mentioned above, such as keyboard 1210, graphics adapter 1212 and display 1218.

[0132] Additional Notes

[0133] Some portions of the foregoing description describe embodiments of algorithmic processes or operations. These algorithmic descriptions and representations are commonly used by those skilled in the computing arts to effectively convey the essence of their work to others skilled in the art. Although these operations are described functionally, computationally, or logically, they are understood to be implemented by computer programs comprising instructions executed by a processor or equivalent circuitry, microcode, or the like. Furthermore, it is sometimes convenient to refer to arrangements of these functional operations as modules, without loss of generality.

[0134] As used herein, any reference to "one embodiment" or "an embodiment" means that a particular element, feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearance of the phrase "in one embodiment" in various places in the specification does not necessarily refer to the same embodiment. Similarly, the use of "one" or "an" before an element or component is merely for convenience. The description should be understood to mean that there are one or more of the elements or components unless it is obvious that it does not.

[0135] If a value is described as "approximately" or "substantially" (or derivatives thereof), such value should be interpreted as being accurate to + / - 10%, unless the context clearly indicates otherwise. For example, "approximately ten" should be understood to mean "within the range of nine to eleven."

[0136] As used herein, the terms "comprises," "includes," "comprising," "consists of," "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 but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Furthermore, unless expressly stated to the contrary, "or" refers to an inclusive or, and not an exclusive or. For example, a condition A or B is satisfied by any of the following: A is true (or exists) and B is false (or does not exist), A is false (or does not exist) and B is true (or exists), and both A and B are true (or exists).

[0137] After reading this disclosure, those skilled in the art will appreciate additional alternative structural and functional designs for systems and processes for providing end-to-end registration, custody, issuance, trade, settlement, and services for digital assets and tokenized assets. Thus, while specific embodiments and applications have been illustrated and described, it should be understood that the described subject matter is not limited to the precise configurations and components disclosed. The scope of protection should be limited only to any claims that may ultimately be asserted.

Claims

1. A computer-implemented method comprising: Receiving an initiation request for identifying a digital asset; Retrieve asset origination information describing the digital asset; Storing a description of the digital asset derived from the asset initiation information in an initiating smart contract on a distributed ledger; Receive asset issuance request; Retrieving the description of the digital asset in response to the asset issuance request; as well as One or more instances of the digital asset are created on the distributed ledger.

2. The computer-implemented method of claim 1 , further comprising: receiving a definition of the digital asset; as well as Creating the initiating smart contract using the definition, wherein storing the description of the digital asset comprises submitting the asset initiating smart contract to the distributed ledger.

3. The computer-implemented method of claim 1 , wherein retrieving the description of the digital asset comprises: Receiving an identifier of the initiating smart contract; as well as The distributed ledger is queried using the identifier of the initiating smart contract to identify the description of the digital asset.

4. The computer-implemented method of claim 1 , wherein creating the one or more instances of the digital asset on the distributed ledger comprises: Creating an asset deposit smart contract in the issuer’s account; as well as Create an issuance smart contract in the securities issuance account.

5. The computer-implemented method of claim 1 , further comprising: Verifying that the number of instances of the digital asset indicated in the account of the issuer matches the number of instances of the digital asset indicated in the securities issuance account.

6. The computer-implemented method of claim 1 , further comprising: Requesting approval of the initiation request from the registration party; as well as Approval of the origination request by the registrant is received, wherein the description of the digital asset is stored in response to receiving the approval of the origination request.

7. The computer-implemented method of claim 6 , wherein requesting the approval of the initiation request comprises: An approval smart contract is created, and receiving approval of the initiation smart contract includes receiving an indication that the registrant has signed the approval smart contract.

8. The computer-implemented method of claim 1 , further comprising: Requesting approval from the Registrant for the asset issuance request; as well as An approval of the asset issuance request by the registrar is received, wherein the one or more instances of the digital asset are created in response to receiving the approval of the asset issuance request.

9. The computer-implemented method of claim 8, wherein requesting the approval of the asset issuance request comprises: An approval smart contract is created, and receiving approval of the asset issuance smart contract includes receiving an indication that the registered party has signed the approval smart contract.

10. The computer-implemented method of claim 1, wherein the distributed ledger comprises a blockchain.

11. The computer-implemented method of claim 1 , wherein the asset initiation smart contract is a DAML smart contract.

12. A non-transitory computer-readable medium comprising stored instructions that, when executed, cause a computing system to perform operations comprising: Receiving an initiation request for identifying a digital asset; Retrieve asset origination information describing the digital asset; Storing a description of the digital asset derived from the asset initiation information in an initiating smart contract on a distributed ledger; Receive asset issuance request; Retrieving the description of the digital asset in response to the asset issuance request; as well as One or more instances of the digital asset are created on the distributed ledger.

13. The non-transitory computer-readable medium of claim 12, wherein the operations further comprise: receiving a definition of the digital asset; as well as Creating the initiating smart contract using the definition, wherein storing the description of the digital asset comprises submitting the asset initiating smart contract to the distributed ledger.

14. The non-transitory computer-readable medium of claim 12, wherein retrieving the description of the digital asset comprises: Receiving an identifier of the initiating smart contract; as well as The distributed ledger is queried using the identifier of the initiating smart contract to identify the description of the digital asset.

15. The non-transitory computer-readable medium of claim 12, wherein creating the one or more instances of the digital asset on the distributed ledger comprises: Creating an asset deposit smart contract in the issuer’s account; as well as Create an issuance smart contract in the securities issuance account.

16. The non-transitory computer-readable medium of claim 12, wherein the operations further comprise: Verifying that the number of instances of the digital asset indicated in the account of the issuer matches the number of instances of the digital asset indicated in the securities issuance account.

17. The non-transitory computer-readable medium of claim 12, wherein the operations further comprise: Requesting approval of the initiation request from the registration party; as well as Approval of the origination request by the registrant is received, wherein the description of the digital asset is stored in response to receiving the approval of the origination request.

18. The non-transitory computer-readable medium of claim 17, wherein requesting the approval for the initiation request comprises: An approval smart contract is created, and receiving approval of the initiation smart contract includes receiving an indication that the registrant has signed the approval smart contract.

19. The non-transitory computer-readable medium of claim 12, wherein the operations comprise: Requesting approval from the Registrant for the asset issuance request; as well as An approval of the asset issuance request by the registrar is received, wherein the one or more instances of the digital asset are created in response to receiving the approval of the asset issuance request.

20. The non-transitory computer-readable medium of claim 19, wherein requesting the approval of the asset issuance request comprises: An approval smart contract is created, and receiving approval of the asset issuance smart contract includes receiving an indication that the registered party has signed the approval smart contract.

21. A computer-implemented method comprising: Identify the rights and the corresponding dates on which said rights expire; identifying an interest in the right held by a custodian in a first layer of a hierarchy of interests in the right, the hierarchy being stored in a distributed ledger; as well as On the date when the right expires, portions of the right are allocated to the custodians based on their interests in the right, wherein at least some of the custodians identify investors in the second layer of the hierarchy that have interests in the right, and portions of the investors in the right are allocated to the investors based on their interests in the right.

22. The computer-implemented method of claim 21 , further comprising: identifying, by at least some of the investors, additional investors having an interest in the rights in a third level of the hierarchy; as well as A corresponding portion of the right is allocated by at least some of the investors to the additional investors based on their interests in the right.

23. The computer-implemented method of claim 21, wherein the right is a coupon payment.

24. The computer-implemented method of claim 21 , wherein the interest in the right is represented by a claim token on the distributed ledger.

25. The computer-implemented method of claim 21 , wherein the distributed ledger comprises a blockchain.

26. The computer-implemented method of claim 25, wherein the blockchain is a permissioned blockchain and smart contracts are used to represent the interests in the rights such that parties can only view the interests to which they are entitled or for which they are responsible.

27. The computer-implemented method of claim 25, wherein the distributed ledger further comprises a second blockchain, wherein the stake in the first layer of the hierarchy is stored on the blockchain, and the stake in the second layer of the hierarchy is stored on the second blockchain.

28. The computer-implemented method of claim 21 , further comprising: Providing a notification to at least one of the custodians prior to payment of the right that the right will be paid, wherein the at least one of the custodians, in response to the notification, identifies the investor having an interest in the right prior to payment of the right.

29. A non-transitory computer-readable medium comprising stored instructions that, when executed by a computing system, cause the computing system to perform operations comprising: Identify the rights and the corresponding dates on which said rights expire; identifying an interest in the right held by a custodian in a first layer of a hierarchy of interests in the right, the hierarchy being stored in a distributed ledger; as well as On the date when the right expires, portions of the right are allocated to the custodians based on their interests in the right, wherein at least some of the custodians identify investors in the second layer of the hierarchy that have interests in the right, and portions of the investors in the right are allocated to the investors based on their interests in the right.

30. The non-transitory computer readable medium of claim 29, wherein the operations further comprise: identifying, by at least some of the investors, additional investors having an interest in the rights in a third level of the hierarchy; as well as A corresponding portion of the right is allocated by at least some of the investors to the additional investors based on their interests in the right.

31. The non-transitory computer readable medium of claim 29, wherein the right is a coupon payment.

32. The non-transitory computer-readable medium of claim 29, wherein the interest in the right is represented by a claim token on the distributed ledger.

33. The non-transitory computer-readable medium of claim 29, wherein the distributed ledger comprises a blockchain.

34. The non-transitory computer-readable medium of claim 33, wherein the blockchain is a permissioned blockchain and smart contracts are used to represent the interests in the rights such that parties can only view the interests to which they are entitled or for which they are responsible.

35. The non-transitory computer-readable medium of claim 33, wherein the distributed ledger further comprises a second blockchain, wherein the interests in the first layer of the hierarchy are stored on the blockchain, and the interests in the second layer of the hierarchy are stored on the second blockchain.

36. The non-transitory computer readable medium of claim 29, wherein the operations further comprise: Providing a notification to at least one of the custodians prior to payment of the right that the right will be paid, wherein the at least one of the custodians, in response to the notification, identifies the investor having an interest in the right prior to payment of the right.

37. A computing system comprising: one or more processors; as well as a memory storing instructions that, when executed by the one or more processors, cause the computing system to perform operations comprising: Identify the rights and the corresponding dates on which said rights expire; identifying an interest in the right held by a custodian in a first layer of a hierarchy of interests in the right, the hierarchy being stored in a distributed ledger; and On the date when the right expires, portions of the right are allocated to the custodians based on their interests in the right, wherein at least some of the custodians identify investors in the second layer of the hierarchy that have interests in the right, and portions of the investors in the right are allocated to the investors based on their interests in the right.

38. The computing system of claim 37, wherein the operations further comprise: identifying, by at least some of the investors, additional investors having an interest in the rights in a third level of the hierarchy; as well as A corresponding portion of the right is allocated by at least some of the investors to the additional investors based on their interests in the right.

39. The computing system of claim 37, wherein the distributed ledger is a permissioned blockchain and smart contracts are used to represent the interests in the rights so that parties can only view the interests to which they are entitled or for which they are responsible.

40. The computing system of claim 37, wherein the distributed ledger comprises a first blockchain and a second blockchain, wherein interests in the first layer of the hierarchy are stored on the first blockchain, and interests in the second layer of the hierarchy are stored on the second blockchain.

41. A computer-implemented method comprising: receiving a first trade summary request from a first party to a trade; capturing details of said trade in a smart contract stored on a distributed ledger; receiving a second trade summary request from a second party to the trade; matching the first trade summary request with the second trade summary request; In response to the matching, generating a settlement instruction to effectuate the trade; receiving signatures from the first party and the custodian of the second party; as well as Processing the settlement instruction.

42. The computer implemented method of claim 41, wherein matching the first trade summary request with the second trade summary request is implemented using a balancing queue.

43. The computer-implemented method of claim 42, wherein the balancing queue is implemented using an immutable smart contract.

44. The computer implemented method of claim 42, wherein the balancing queue is a virtual balancing queue implemented without requiring any additional objects to store the ordering of the trade summary requests.

45. The computer implemented method of claim 42, wherein the first and second trade summary requests are keyed into the balancing queue using trade economics and iterative keying.

46. ​​The computer-implemented method of claim 45, wherein matching the first trade summary request with the second trade summary request comprises: In response to receiving the second trade summary request, an iterative keyed lookup is performed for other trades having matching economics until the first trade summary request is identified.

47. The computer-implemented method of claim 46, wherein the balancing queue rebalances so that the first trade summary request is the earliest or latest matching trade summary request among a plurality of possible matching trade summary requests for the second trade summary request.

48. The computer-implemented method of claim 41 , further comprising: In response to receiving the first trade summary request, querying a virtual balancing queue for matching trade summary requests; In response to not finding a matching trade summary request, adding the first trade summary request to the virtual balancing queue.

49. The computer-implemented method of claim 41 , wherein receiving the signature of the escrow party comprises: The custodian signs the smart contract using their digital signature.

50. A non-transitory computer-readable medium comprising stored instructions that, when executed, cause a computing system to perform operations comprising: receiving a first trade summary request from a first party to a trade; capturing details of said trade in a smart contract stored on a distributed ledger; receiving a second trade summary request from a second party to the trade; matching the first trade summary request with the second trade summary request; In response to the matching, generating a settlement instruction to effectuate the trade; receiving signatures from the first party and the custodian of the second party; as well as Processing the settlement instruction.

51. The non-transitory computer readable medium of claim 50, wherein matching the first trade summary request with the second trade summary request is implemented using a balancing queue.

52. The non-transitory computer-readable medium of claim 51 , wherein the balancing queue is implemented using an immutable smart contract.

53. The non-transitory computer-readable medium of claim 51, wherein the balanced queue is a virtual balanced queue implemented without requiring any additional objects to store the ordering of the trade summary requests.

54. The non-transitory computer readable medium of claim 51, wherein the first trade summary request and the second trade summary request are keyed into the balancing queue using trade economics and iterative keying.

55. The non-transitory computer-readable medium of claim 54, wherein matching the first trade summary request with the second trade summary request comprises: In response to receiving the second trade summary request, an iterative keyed lookup is performed for other trades having matching economics until the first trade summary request is identified.

56. The non-transitory computer-readable medium of claim 55, wherein the balancing queue rebalances so that the first trade summary request is the earliest or latest matching trade summary request among a plurality of possible matching trade summary requests for the second trade summary request.

57. The non-transitory computer readable medium of claim 50, wherein the operations further comprise: In response to receiving the first trade summary request, querying a virtual balancing queue for matching trade summary requests; In response to not finding a matching trade summary request, adding the first trade summary request to a virtual balancing queue.

58. The non-transitory computer-readable medium of claim 50, wherein receiving the signature of the escrow party comprises: The custodian signs the smart contract using their digital signature.

59. A system comprising: one or more processors; as well as a memory storing instructions that, when executed by the one or more processors, cause the computing system to perform operations comprising: receiving a first trade summary request from a first party to a trade; capturing details of said trade in a smart contract stored on a distributed ledger; receiving a second trade summary request from a second party to the trade; matching the first trade summary request with the second trade summary request; In response to the matching, generating a settlement instruction to effectuate the trade; receiving signatures of the custodian of the first party and the second party; and Processing the settlement instruction.

60. The system of claim 59, wherein matching the first trade summary request with the second trade summary request is accomplished using a balancing queue, the first trade summary request and the second trade summary request being keyed into the balancing queue using trade economics and iterative keying, and wherein matching the first trade summary request with the second trade summary request comprises: In response to receiving the second trade summary request, an iterative keyed lookup is performed for other trades having matching economics until the first trade summary request is identified, and the balancing queue is rebalanced so that the first trade summary request is the earliest or latest matching trade summary request among a plurality of possible matching trade summary requests for the second trade summary request.

61. A computer-implemented method comprising: receiving settlement instructions for transactions involving parties; Pushing information about the transaction to an off-book system associated with the party; Receiving the digital signature of the participant from the off-book system; as well as In response to receiving the digital signature of the party, the transaction is implemented using the settlement instruction.

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

63. The computer-implemented method of claim 61 , further comprising: The digital signature and the information about the transaction in the smart contract are stored on a distributed ledger.

64. The computer-implemented method of claim 63, further comprising: The implementation of the transaction is verified using the information about the transaction stored in the smart contract on the distributed ledger.

65. The computer-implemented method of claim 64, wherein verifying the fulfillment of the transaction comprises: The information about the transaction pushed to the off-ledger system is compared with the information about the transaction stored in the smart contract on the distributed ledger.

66. The computer-implemented method of claim 61 , wherein 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.

67. The computer-implemented method of claim 61 , wherein receiving the digital signature of the party comprises: The digital signature is retrieved using a web hook of the off-book system.

68. A non-transitory computer-readable medium comprising stored instructions that, when executed, cause a computing system to perform operations comprising: receiving settlement instructions for transactions involving parties; Pushing information about the transaction to an off-book system associated with the party; Receiving the digital signature of the participant from the off-book system; as well as In response to receiving the digital signature of the party, the transaction is implemented using the settlement instruction.

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

70. The non-transitory computer readable medium of claim 68, wherein the operations further comprise: The digital signature and the information about the transaction in the smart contract are stored on a distributed ledger.

71. The non-transitory computer readable medium of claim 70, wherein the operations further comprise: The implementation of the transaction is verified using the information about the transaction stored in the smart contract on the distributed ledger.

72. The non-transitory computer-readable medium of claim 71 , wherein verifying the fulfillment of the transaction comprises: The information about the transaction pushed to the off-ledger system is compared with the information about the transaction stored in the smart contract on the distributed ledger.

73. The non-transitory computer-readable medium of claim 68, wherein 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.

74. The non-transitory computer-readable medium of claim 68, wherein receiving the digital signature of the party comprises retrieving the digital signature using a webhook of the off-book system.

75. A system comprising: one or more processors; as well as a memory storing instructions that, when executed by the one or more processors, cause the computing system to perform operations comprising: receiving settlement instructions for transactions involving parties; Pushing information about the transaction to an off-book system associated with the party; receiving the digital signature of the participant from the off-book system; and In response to receiving the digital signature of the party, the transaction is implemented using the settlement instruction.

76. The system of claim 75, wherein the operations further comprise: The digital signature and the information about the transaction in the smart contract are stored on a distributed ledger.

77. The system of claim 76, wherein the operations further comprise: The implementation of the transaction is verified using the information about the transaction stored in the smart contract on the distributed ledger.

78. The system of claim 77, wherein verifying the fulfillment of the transaction comprises: The information about the transaction pushed to the off-ledger system is compared with the information about the transaction stored in the smart contract on the distributed ledger.

79. The system of claim 75, wherein 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.

80. The system of claim 75, wherein receiving the digital signature of the party comprises: The digital signature is retrieved using a web hook of the off-book system.

Images