Blockchain based asset management and exchange trading

Abstract

Embodiments of the present invention provide novel methods and systems to instantly settle transactions, remove middlemen, reduce and remove settlement risk, and dramatically reduce time and costs in the operations of a financial exchange across asset categories.

Description

Blockchain Based Asset Management and Exchange Trading

[0001] Field Of The Invention

[0002] The subject invention is related to management and exchange of assets implemented on a distributed ledger such as a blockchain.

[0003] Background Of The Invention

[0004] Despite a long history of transacting, a number of challenges still exist with financial exchange technology. One of the largest challenges comes from how assets are settled after an exchange transaction is made. A common traditional finance exchange approach matches buy orders against sell orders. A matchmaking engine matches orders with other orders that fit their respective criteria, and then matches are made. After a match is made, the system indicates matches and therefore exchanges of assets, and then assets are expected to be transferred to buyers and sellers correlating with the matched trades. This settlement process typically takes time and money, uses middlemen, and creates risk.

[0005] In financial exchanges, settlement time and settlement risk are critical factors that impact the efficiency, reliability, and safety of trading operations. Traditional settlement processes can be slow, often requiring multiple business days to finalize transactions, which exposes counterparties to settlement risk due to potential price fluctuations, counterparty default, and operational delays. Current crypto Centralized Exchanges (CEXs) often act more like a brokerage than a traditional finance (TradFi) exchange, and they directly maintain control of users’ deposits. This control innately can lead to fraud and theft, such as the fraud that the FTX exchange committed. Even crypto Decentralized Exchanges (DEXs) have settlement and liquidity challenges, and typically have poor user experiences, are expensive, and are not regulatory compliant. Across exchange technologies and approaches there are many challenges, many of which relate to settlement. The time lag between when a trade is executed and when it is settled can lead to price discrepancies, especially in volatile markets. Sudden price swings can result in a mismatch between the trade price and settlement price, which can create financial losses for either the exchange or the user. Exchanges must have enough liquidity to complete settlements immediately after a trade. In times of high trading volume or market volatility, liquidity can be stretched thin, making it difficult to settle trades in real-time. Having delays in settlement can also exacerbate liquidity challenges. During periods of high activity, such as when a popular asset is experiencing significant movement, exchanges can experience backlogs, which can further delay settlement, and potentially lead to failed settlements. Exchanges often have mechanisms to manage risks, such as insurance funds or backstop liquidity, to cover defaults and maintain market integrity. In traditional finance, clearinghouses often mitigate counterparty risk. Exchanges must find ways to manage this risk directly, which can add operational complexity and cost. Settlement processes can also be targets for fraud, including attempts at double-spending (in crypto exchanges), spoofing, front-running, or other types of trade manipulation.

[0006] Summary Of The Invention

[0007] Embodiments of the present invention provide novel methods and systems to instantly settle transactions, remove middlemen, reduce and remove settlement risk, and dramatically reduce time and costs in the operations of a financial exchange across asset categories.

[0008] Blockchain technology can be transformative for exchanges by offering a secure, transparent, and efficient infrastructure for trading, settlement, and record-keeping. Every transaction on a blockchain is recorded immutably, creating a verifiable and permanent record. This makes it easier for exchanges to track trades, manage compliance, and conduct audits. Blockchains are highly secure due to their distributed nature. Transactions on a blockchain are often validated through consensus mechanisms, making it difficult for malicious actors to create fraudulent transactions or alter records.

[0009] The critical process of settlement in finalizing the transfer of assets between entities can be massively improved with benefits for the timing, transparency, resilience, and cost of these operations. The atomic settlement procedure described herein illustrates a platform to standardize and streamline settlements between multiple entities in a single ’straight through processing’ step that provides fast and immutable distribution of the ownership state transitions. This makes the process both transparent for trading entities as well as easy for governments to audit. Overall, this settlement procedure has the potential to improve timing and reduce costs for all entities involved.

[0010] Brief Description of the Drawings

[0011] FIG. 1 is a pseudocode illustration of a method of an example embodiment.

[0012] Description of the Invention

[0013] Embodiments of the present invention provide novel methods and systems to instantly settle transactions, remove middlemen, reduce and remove settlement risk, and dramatically reduce time and costs in the operations of a financial exchange across asset categories..

[0014] Blockchain technology can be transformative for exchanges by offering a secure, transparent, and efficient infrastructure for trading, settlement, and record-keeping. Every transaction on a blockchain is recorded immutably, creating a verifiable and permanent record. This makes it easier for exchanges to track trades, manage compliance, and conduct audits. Blockchains are highly secure due to their distributed nature. Transactions on a blockchain are often validated through consensus mechanisms, making it difficult for malicious actors to create fraudulent transactions or alter records.

[0015] The present invention utilizes the benefits of distributed ledger technology to implement exchange mechanisms that are fast, secure, inexpensive, and which require no middleman. An important aspect of the present invention is the concept of an Atomic Transaction Set (ATSet). An ATSet groups transactions so that any transactions in the set are validated as a transaction on the blockchain if and only if all of the transactions in the setare validated. For example, if a User 1 wants to exchange X of Token A for Y of Token B, and User 2 wants to exchange Y of Token B for X of Token A, or in other words they agree to trade their assets, then a historically typical method of implementing a trade is to use a middleman that both User 1 and User 2 trust. User 1 can give the middleman X units of Token A and User 2 can give the middleman Y units of Token B, and when the middleman sees that both parties have correctly transferred the agreed upon amounts for the exchange, then the middleman can give the respective trades out. The middleman would therefore give User 2 X units of Token A and give User 1 Y units of Token B. Typically the middleman would also get paid a fee for managing the transaction.

[0016] Atomic Transaction Sets give a more efficient method for implementing this type of transaction. Using ATSets, User 1 would create and digitally sign a transaction, Transaction 1 A, that is defined such that they are willing to transfer X units of Token A If and Only If (IFF) they in turn receive Y units of Token B. Transaction 1A is therefore defined so that it can only be validated as part of an ATSet. Similarly, User 2 would create and digitally sign a transaction, Transaction 1B, that is defined such that they are willing to transfer Y units of Token B IFF they in turn receive X units of Token A. Transaction 1A cannot be validated by validators in the blockchain network, despite the fact that it is correctly signed, if it is not grouped with a matching transaction that fits its requirements. Transaction 1 B also cannot be validated by validators in the blockchain network, despite the fact that it is also correctly signed, unless it is part of an ATSet. Because Transaction 1 A and Transaction 1 B are defined to require they be part of an ATSet to be validated, they are grouped as an ATSet, and the entire group, in this case 2 transactions, is validated and necessarily added to the same block on the blockchain. Because the Transaction 1A and 1B are included on the same block on the blockchain, they occur at the exact same time, and therefore the assets are exchanged at the exact same time. Using ATSets, no middlemen are needed or used to implement the mechanics of the exchange of assets.

[0017] There are various ways that a transaction can be defined to be included in an ATSet. One way, for example, is to define requirements for the transaction to go through, and the inclusion of requirements can make the transaction an ATSet transaction. Another approach is to have a flag in the definition of the transaction that indicates that the transaction is an ATSet transaction. Another approach is to present all transactions that are part of an ATSet to the validators in a group that represents the ATSet itself, and in doing so validators understand that the transactions are ATSet transactions. Those skilled in the art can develop various methods or combinations of methods to define an ATSet transaction. It is important that the software creating and signing transactions matches with the software validators use, so that validators correctly understand when transactions must be grouped as an ATSet, so that they are approved by validators when they should be approved and are not approvedwhen they should not be approved. Similarly, there are various ways that ATSet transactions can be validated in any given consensus mechanism. For example, validators can group transactions that are logically able to be grouped, or a process can exist where ATSets are presented to validators already in defined groups. These details depend on the mechanics of consensus for a given consensus mechanism, and those skilled in the art can implement varying methods for defining and approving ATSets at a consensus level.

[0018] There are also various requirements that can be used with an ATSet transaction. An ATSet transaction can require that an asset is matched in an exchange with another asset, an amount of an asset is matched against an amount of another asset, where traditional trade mechanism such as market versus limit orders are defined and required, where a transaction happens at a particular time or on a particular blockchain or shard, where a transaction happens within a set of matching public addresses or with a transaction from a specific public address, or where the transaction has other types of requirements such as privacy related requirements or fraud protection requirements, as examples. Those skilled in the art can create definitions of ATSet transactions to limit them in any way that a user might want to create requirements on how a transaction is allowed or not.

[0019] Because ATSet transactions can be implemented in a way that the recipient of an asset transfer is not known, an ATSet transaction can be signed such that the requirements for its approval do not include the recipient address. For example, in a situation where a seller on an exchange is willing to sell 100 units of Token A at a minimum price of $1.00 per token, the seller can sign a transaction that states those requirements. The $1 used in the transfer can be a stablecoin for example. Then if a buyer is willing to buy 100 units of Token A at $1.00 per token, then the buyer can create a transaction approving that purchase. Those two transactions can be grouped in an ATSet, where the grouping defines the recipient. There are other ways to define recipients, when the recipient is not known at the time of the user signing. For example, in another embodiment of the present invention, an intermediate wallet address can be used as part of an ATSet. If a seller is willing to sell 100 of Token A for $100, and a buyer is willing to buy 100 of token A for $100, then the buyer and seller can each sign an ATSet transaction defining their respective side of the exchange. The definition of the seller’s transaction can allow for the transfer of the 100 of Token A to be transferred into an intermediate wallet, while still defining that the transaction only goes through IFF $100 is received in the ATSet. The definition of the buyer’s transaction can allow for the transfer of the $100 to be transferred into the intermediate wallet, while still defining that the transaction only goes through IFF 100 of Token A is received in the ATSet. The exchange can then utilize the intermediate wallet in this transaction by creating and signing two transactions, one where $100 is transferred to the seller and one where 100 of Token A is transferred to the buyer. Then, the entire ATSet includes all 4 transactions that then arevalidated and included on the same block on a blockchain. It should be noted in this case that even through an intermediary wallet was used, this does not represent a middleman. It is simply a mechanism to implement the exchange. Because the transactions go through IFF the users receive their side of the exchanged assets, and the ATSet logically included the intermediate address as a function where the exchange was implemented at the exact moment the block was added to the blockchain, there is no trust involved with the intermediate address. The owner of the intermediate address, in this case the exchange, by definition has no ability to do anything with the assets, and no time to do anything with the assets, other than use the intermediate address as a simple mechanism to implement the defined trade.

[0020] Fraud protections can be used as part of the definition of an ATSet trade. For example, an exchange can be implemented on the DevvX blockchain, which includes fraud, theft, and loss protections. An ATSet implemented on DevvX can include in its requirements that fraud protections be part of the exchange. Depending on the exact definition of the fraud protections, the result would be that the assets could be required to be held in the recipient’s wallet for a period of time before being transferred out of that wallet, or the assets could be held in an escrow wallet and be automatically transferred by a smart contract after a defined period of time. Users can define any conditions around fraud, theft, or loss as needed, and therefore users are protected, because they only sign ATSet transactions they are comfortable with. For example, a user could sign a transaction that requires there are no fraud protections in a trade, and another user could sign a transaction that requires there are fraud protections in a trade. Even if all of the other criteria in the two trade definitions matched, those two transactions would not be validated together in an ATSet because one user required fraud protections in their transaction and one user required no fraud protections in their transaction.

[0021] An example embodiment of the present invention can be implemented on a blockchain that has parallel running shards in a methodology such as the DevvX (trademark of Devvio Inc.) blockchain. In this example embodiment, various DevvX shards can be implemented in different regulatory environments. A single exchange can run on one or more shards, different exchanges can run where each utilizes its own shard, or different exchanges can use multiple shards. Exchanges and shards can be customized for asset types, regulatory requirements, or other business needs. For example, an exchange running on a DevvX shard can be implemented in the UK for UK citizen exchanges and a different exchange running on a different shard can be implemented in the US for US citizen exchanges. The DevvX cross-shard mechanism can allow for users of different shards to trade assets when the exchange legally allows for that type of asset exchange, and not allow for cross shard trades when citizens are implementing cross-jurisdictional trades that are notallowed. ATSets can be required to incorporate regulatory requirements as part of the requirements for the ATSet. For example, a government might require that all trades use Know-Your-Customer requirements, in which case the exchange can be designed to only allow for ATSet exchange trades where a trader has provably gone through a KYC process. On DevvX, for example, that KYC process can be associated with a public address, so the ATSet trade definitions can require that only users whose KYC definitions fit specific requirements are allowed to trade in that jurisdiction or on a given shard. Differing levels of requirements for KYC for individuals, business entities, or government entities can allow for different types of trades. For example, users who go through a higher level and more rigorous type of KYC can be allowed to use higher monetary values for individual trades or for trades within a given timeframe.

[0022] Buyers and sellers can create trade definitions that are defined to be part of an ATSet such that the trade definition in the ATSet implements typical types of trading strategies. An ATSet trade can define, without limitation, market orders, limit orders, stop orders, stop-limit orders, fill-or-ki II orders, immediate-or-cancel orders, good-til-canceled orders, good-for-day orders, all-or-none orders, iceberg orders, margin trades, leveraged trades, short sales, arbitrage trades, swing trades, scalping trades, pairs trades, options trades, futures and derivatives trades, algorithmic trades, high frequency trades, otc trades, and conditional orders, as examples. For example, if a user wants to implement a limit order to buy an asset, the ATSet transaction definition would require a purchase of an asset at a specified price or lower in order to find a matching sell order that would meet the requirements for the buy order so that the two transactions can be grouped in the ATSet. As another example, a trader who is implementing an arbitrage strategy might create multiple trades that each have requirements where those trades must be included in a single ATSet in order to be validated, where the trades, by definition, appropriately implement the arbitrage strategy. ATSet transactions implementing trades can be automated with smart contracts on-chain, or can be implemented with bots off-chain. Users can maintain private keys in self custody or managed custody. For example, one trader on one exchange might prefer the exchange manage the transactions and private keys for that user’s assets. In that example, the exchange can allow for traditional finance security implementations such as two factor authentication to get access to the trading front end. Alternatively, in another example a user or business can insist that their trades be implemented in a way that they maintain their own private keys and direct control of their assets. For example, an exchange can be implemented such that it allow for trades using assets held on a hard wallet such as a Ledger Nano. In this example, the user can plug in the Ledger Nano into a computer, enter the password into the Ledger Nano, and then access the trading interface. The user can define a specified order, and the software running the trading interface can access theLedger Nano, indicate to it that a trade definition should be created using a private key held on the Ledger Nano, and the resulting signed ATSet transaction can be delivered to validators.

[0023] In the present invention, the mechanisms for grouping transactions can vary. For example, in one example embodiment of the present invention, trades can be defined such that they can be grouped in multiple ATSets. As a more specific example, if a buyer created a transaction to buy 100 units of Token A, and ten different sellers were each willing to sell 10 units of Token A in acceptable terms, then those ten seller transactions can be grouped with the buyer transaction. However, a situation can occur where the seller transactions come in over time. If the buyer transaction is defined such that it can be grouped with different transactions that do not need to happen all at once, then the buyer transaction can, for example, be grouped in one ATSet with 5 seller transactions, and then be grouped in another ATSet with 5 different seller transactions.

[0024] In another example embodiment of the present invention, a desired trade can be split into multiple transactions. For example, if a user wants to buy 1 unit of Token A, then that buy transaction can be split into 100 transactions, each for 0.01 units of Token A. The smaller sized transactions allow for more optimized matchmaking across trades that do not match up exactly.

[0025] In the present invention, a matchmaking system can be interrelated with the settlement system or the two systems can be separated. For example, if the matchmaking system is separate from the settlement system, then a client-side user interface for a trading system can allow for a user to define trades that are then signed by the client. Those trades can be sent to an off-chain matchmaking service that groups trades into ATSets, therefore matching them. These matched trades can then be sent in the defined ATSet groups to validators on the blockchain, at which point the ATSets are validated, and the settlement of the trades is implemented. Settlement would be guaranteed to occur so long as the validators received the ATSet. Although there is some risk on transmissions not effectively making it to validators, redundancies can be implemented so that any ATSets not shown as being approved can be retransmitted to assure their approval. Overall this type of system can reduce risk on settlement to a negligible amount. One advantage of this type of approach is that matchmaking can occur with a smaller time to finality than the blockchain finality. For example, matches can be made within 5 ms timeframes even if settlement occurs on a larger timeframe such as 100 ms timeframes.

[0026] As an alternative approach for an example embodiment of the present invention, the matchmaking service can happen on-chain. Transactions that define trades can be grouped by validators themselves, and then be proposed to other validators. Depending on the consensus mechanism the validators are using the trades can be proposed in a non-deterministic system such that other validators simply verify that a proposer is giving a valid grouping, or alternatively trades in a deterministic system can be grouped algorithmically such that all validators agree on the order of trades. A deterministic system like this, such as what would be implemented on the DevvX blockchain, can prevent front-running attacks.

[0027] A variety of different types of assets can be maintained and exchanged in the present invention. Fungible tokens can be used to represent fungible assets and non-fungible tokens (NFTs) can be used to represent non-fungible assets or fractional ownership of both fungible and non-fungible assets. Assets categories can include, without limitation, cryptocurrencies, wrapped tokens, stablecoins, game or metaverse assets, stocks, bonds, commodities, real estate, mutual funds, options, futures, currencies, precious metals, collectibles, intellectual property rights, mineral rights, water rights, ESG assets, derivatives, participation rights, and measures of human work or endeavor, as examples. A fungible token or an NFT representing fractional ownership can have an overall cap on the number of units that can be minted (for example, a token’s maximum mintable supply) and it can be divisible to a defined smallest unit size, as examples. If a fungible token represents fungible real-world assets (RWAs) then the token can be defined in how it relates to that RWA. For example, tokens that represent US Dollars (such as a stablecoin) can be defined such that each token equals 1 US Dollar, and each hundredth of a token equals a penny. Fungible tokens and fractional portions of NFTs can have a circulating supply, and cryptographic methods can be used to prove ownership of those assets for holding, transferring, converting, or exchanging the assets. NFTs can include data that shows details of the asset that it represents. For example, an NFT can be defined to represent a share of a company, or an NFT can be defined to represent the entire company and include a portion of its definition that allows for fractional ownership, where each fraction that is owned represents a share of the company. Similarly, fungible tokens can represent shares of a company. An NFT can include a large amount of data related to an asset as well. For example, an NFT that represents one or more carbon credits can also include a large amount of reference data that shows the provenance of the asset or the process underlying the asset.

[0028] An example embodiment of the present invention includes NFT pairs with a particular type of definition, where the NFT has an immutable portion (referred to here as an NFT-17) and mutable portion (referred to here as an NFT-18), together referred to herein as an NFT- 17 / 18. Both NFT components, the NFT-17 and NFT-18, of this type of NFT together represent an asset. For clarity, the description of mutability or immutability of the NFT-17 / 18 does not refer to the overall immutability of the record of transactions held on the blockchain. It only refers to whether each component can be changed over time, as they are represented on the blockchain. For further clarity, for example, if the NFT-18 portion of an NFT-17 / 18 is modified, the blockchain will still maintain an immutable record of all changes to the NFT-18over time. In this example, the NFT-17 and the NFT-18 both include in their definition the ability to incorporate any type of JSON definition. For example, a simplified ESG asset defined with an NFT-17 / 18, for the purposes of demonstration, is given with JSON nameobject pairs as follows:

[0029] NFT-17 definition, including a JSON definition as follows:Asset Type: Carbon CreditAsset ID: [an ID reference for the asset]Asset Reference: [a reference to a third-party registry definition which includes the given asset ID]Asset Units: 100Asset pair reference: [a reference to the NFT-18 half of the overall asset definition]

[0030] NFT-18 definition, including a JSON definition as follows:Asset Price: $100Asset Unit Ownership: [Json definition of all owners of Units]

[0031] In this example, the price can change over time, and the owner of the asset can update fields in the NFT-18. If the asset is sold, then the NFT-17 / 18 would be transferred to the new owner, and the new owner would then have the ability, and rights, to update the NFT-18 portion of the asset.

[0032] An NFT-17 / 18 can be used as one method of representing fractional ownership. Continuing with the example above, an entity that maintains records of ownership for ESG assets, such as a traditional registry, can use an NFT-17 / 18 to keep track and update who owns all of the carbon credits in a project. The owner of the NFT-17 in this case would effectively be maintaining the right to define ownership of the included assets, and the asset itself would not be transferred. Alternatively, using the same system, the registry could implement 100 NFT-17 / 18 assets (without including the Asset Units field in the NFT-17 and the Asset Unity Ownership field in the NFT-18), and the NFT-17 / 18’s themselves would represent ownership.

[0033] An example embodiment of the present invention includes one or more marketplaces in addition to one or more exchanges that coordinate. Marketplaces can allow for sales of assets where a limited number of payment mechanisms are allowed. A marketplace can include tokens as a payment mechanism, which would make some of its operations similar in nature to an exchange since one type of token is being traded for another type of token, but a marketplace can also allow for traditional payment mechanisms such as credit card purchases, wire transfers, or ACH transfers, as examples. Marketplaces and exchanges can interact with the same types of assets. A user can decide to sell a number of ESG assets on a marketplace, or exchange them on an exchange.

[0034] An example embodiment of the present invention includes bridging technology.Often, an asset is desired to be sold on a different platform than it is currently held, for example, in order to get more access to different types of buyers or liquidity. Exchange capabilities in the present invention can be implemented such that tokens on another blockchain platform are bridged to the blockchain on which the exchange is operating. For example, ERC-20 tokens can be sent to an Ethereum Smart Contract address used for bridging where the receipt of the tokens in that address on the Ethereum Blockchain are matched against tokens that are defined to be able to be transferred in the bridge, at which point new tokens are minted on the DevvX blockchain, where the exchange is operating from.

[0035] Example Embodiment.

[0036] Context. Despite major advances in information technology, the settlement process to finalize the trade or exchange of assets remains complex and inefficient. The process involves multiple communications between agencies with varying rules depending on jurisdiction. The intermediary steps are not transparent to end users and often occur in a series of independent events, rather than an atomic state transition. It is not unusual for the settlement process to take multiple days. All this time creates a significant cost not just in direct expenses but also in terms of the holding costs of any collateral, which generally cannot be otherwise utilized until settlement finalizes. Furthermore, in the event of a disaster the timing and disposition of these assets becomes ambiguous and finality can be delayed even more

[0037] Definitions:

[0038] Atomic - the operation occurs as a single indivisible unit where either every transfer occurs simultaneously or not at all.

[0039] Atomic Transaction Set (ATS) - a special data structure that binds multiple transactions together atomically so they all must succeed or fail together with no possible intermediate outcome. This structure can support both delivery-versusdelivery and delivery- versus-payment operations.

[0040] Asynchronous - entities do not need to coordinate their timing, clock signals are irrelevant, and transfers finalize or get rejected immediately.

[0041] Blockchain - a series of cryptographically linked blocks, records of transactions, that use a hash function to verify the integrity of the prior block.

[0042] Composable - lists, chains, or state transitions are composable if they can merge while preserving their relative order without invaliding any sequence of transitions.

[0043] Distributed - the operation occurs on multiple independent computing systems with no single point of failure.

[0044] Immutable - once a transfer finalizes it cannot be retroactively altered. If a legal or government decision requires a change in the ownership this must be appended later on; the record of the original transfer is permanent.

[0045] KYC / AML - know your customer / anti-money laundering

[0046] Monad - a pure computational function that combines fragmented inputs, arguments, or functions and wraps their return values in a type with additional computation.

[0047] NFT - non-fungible token, a globally unique token distinguishable from all others

[0048] PH - personally identifiable information

[0049] Regular - in the sense of occurring at consistent intervals or having equally sized partitions in time or size

[0050] Shard - an independent distributed blockchain supported by multiple independent validators where each validator has a complete record of the blockchain.

[0051] Sound - the property of a transaction being syntactically correct itself with a verified signature

[0052] Transparent - all involved entities and regulators can have the same view of the operation for analysis, taxation, forensics, or other purposes.

[0053] Valid - the property of being correct with respect to the current state or context including other simultaneous transactions (’joint validity’)

[0054] Validator - one node that coordinates with other ’peer’ validators to confirm or reject new blocks in a shard and maintains one copy of that blockchain.

[0055] Exchange Settlement Algorithm

[0056] Terminology Note. The embodiments are described as structuring trades in delivery- versus-delivery (DVD) terms where every end user signs ’sell’ orders. In delivery-versus- payment (DVP) terms, a ’buy’ order consists of an end user selling a currency or payment asset for another type of asset and a ’sell’ order offers some asset type in exchange for another asset or payment.

[0057] Building upon the platform described in Rapid Byzantine Fault Tolerance with Proof of Validation, the Exchange Settlement Algorithm (see FIG. 1 illustration of Algorithm 1 ) provides a method to atomically transfer ownership representations between entities immediately without requiring the system to take custody of any asset for any time. A notional ’exchange’ wallet enables this procedure giving every entity a hook or platform to jointly exchange their assets and payments in one atomic multi-party transaction without requiring any a priori knowledge of their counterparty. Each party sets up their trade by creating and signing a transaction that authorizes their sale of the asset(s) they are giving up and includes the terms under which they are willing to part with this asset. The target of this transaction is not any specific counterparty rather the notional ’exchange’ wallet itself. An exchange platform (either within the same shard or external) receives all of these orders andgroups them into circuits of corresponding orders where every sale has matching buyer(s) based on the terms of that sale. This group of transactions constitutes an Atomic Transaction Set (ATS) that is communicated to one or more Exchange monads along with other metadata including the determined price or quantitative ratio between each pair of asset types. This monad then constructs corresponding outgoing transactions from the notional ’exchange’ wallet back to each entity and signs as that wallet adding these transactions to the ATS. If every such corresponding ’buy’ transaction cannot be constructed, the monad rejects the entire ATS since this would indicate an error in the transaction grouping. Otherwise, the ATS extended with the corresponding transactions is passed to one or more live validator nodes in the shard that supports this particular exchange platform. The validators distribute the ATS to their peers and verify: (1) the soundness of each transaction, its data structure, and that the signature correctly corresponds to the signer; (2) the validity of each transaction, whether that party currently possesses the assets they are selling; and (3) the joint validity of all of the transactions in the entire set, which includes de-duplicating any extra copies of any transaction and insuring that all of the signing parties still possess the assets they are selling given the effects of all of the other transactions. Once the validators sign and distribute the new block, each party ends up possessing the assets they bought and no longer possesses the ones they sold. There is a useful invariant to check that all of the orders cleared: the notional ’exchange’ wallet that signs the corresponding ’buy’ transactions for every party should always be empty since all of the assets flow straight through to their intended recipient in one operation.

[0058] Intuitive Analogy. Imagine a group of people come together with the goal to exchange or barter some items. Each person has something to give and something they want in exchange, but none of them really trust each other. To make a beneficial deal, they agree to meet at an empty table and upon an agreed upon signal they all put something on the table with one hand while simultaneously taking what they want off the table with the other hand. The table itself remains empty both before and after this multi-party transaction. The table itself is a notional space to coordinate the trade whether it is a logical hook or a physical location.

[0059] The Exchange Wallet

[0060] The Exchange Wallet is considered notional in the sense that it is merely a rally point or hook for transactions to know where to finalize their matches. This wallet is always empty and serves as a target for sellers to sign transactions against with the intention of exchanging assets with a trading peer. The actual wallet key is arbitrary and can be rotated as frequently as needed. It is unclear if possession of such a key would even pose much risk to the system, since the exchange wallet cannot initiate any transaction so long as its state remains empty. The peer validators would reject any transition that left any asset in theexchange wallet.

[0061] Registration and Bridging Assets

[0062] Some setup is required before an entity can trade: (1) They must be registered with a designated wallet in the Devvio system and (2) assets, representations, or references must be loaded into the system to be traded with other entities.

[0063] Registration directly or indirectly identifies the owner of a wallet by creating an account. An account could store PH directly in order to comply with KYC / AML rules or store an identifer that refers to another system for any specifically identifying information required for the jurisdiction(s) in question. This information can be updated independently of the order and settlement process.

[0064] Bridging. The details of how ownership of an asset is represented in the system depends on the class of the asset and the rules of relevant jurisdiction(s). Digital assets could be fully noncustodial in a variety of ways such as recording a copy of the entire asset state, using a wrapper to locally reference the asset, or using the NFT-17 standard structure defined in the Devvio system. If a digital asset remains on another system, it could be tracked by reference so long as the reference is universally specific and not ambiguous and that the external system guarantees delivery to a buyer post-trade. This system does not require any internal custody, but a custodian may often be required elsewhere in a bank, brokerage, fund, or other institution to oversee any external steps involved in the handover of an asset. At the opposite end of the spectrum from digital assets, in the case of real property a digital copy or reference to a deed might bridge into the system and post-trade a custodian other than the seller or buyer may be heavily involved in final delivery or handover.

[0065] Pre-trade (order booking) modes

[0066] Sharding allows for very different instances of settlement systems based on asset class, jurisdiction, and trade frequency or volume. The example modes listed here are not intended to be exhaustive, but rather to illustrate a dimension of flexibility the system has in terms of tracking unmatched orders.

[0067] Single-Pass Settlement. This is one of the simplest modes where trading entities are registered with wallets and their assets are bridged. Especially when running downstream from an external matching system, there does not need to be any order book representation in this system. Matched orders could be sent for immediate finalization or rejection without any further setup. This avoids locking assets at this layer and handles all trades for immediate execution. In a single-pass configuration, many details about the order itself such as allowable price ranges are not utilized.

[0068] Soft Order Book. In this configuration, the system does have an on chain order book, but it allows traders to make orders that exceed their ability to fulfill given other preexisting orders. This means orders can be potentially invalid at settlement. This configuration may beuseful for situations where assets are highly fungible and entities exist that can extend credit to fulfill invalid transactions at the longer term expense of the over-committed seller.

[0069] Firm Order Book. In this case, orders are explicitly booked on chain and rejected if the seller does not possess enough of the asset given their other pending orders. In order to place the new order, the seller may need to cancel a previous order and remove it from the book. The core system is designed to handle race conditions such as the case where an order is canceled and matching at close to the same time. One request will always unambiguously succeed and the other will fail depending on the actual sequence in which they arrive.

[0070] Order Parameters and Metadata

[0071] The details of an order can vary widely from one shard to another depending on the asset classes, jurisdiction, and purpose of a system. Some common details are: (1 ) whether an order is a market order or has a specified limit price, (2) whether partial orders are allowed or not, and (3) additional details for an option or derivative order.

[0072] Matching and Batching

[0073] Request and Integration Patterns. The core validation system is asynchronous and will halt if there are no pending orders available. The web layer provides a synchronous request-response interface where a set of matched orders can be provided and the system will block until it has a final response, which typically occurs in well under one second not accounting for potential network latency. It is possible to integrate with the system on multiple levels with different communication patterns. For example, one implementation could have front-end traders create orders asynchronously where the order is booked and they must wait an undetermined amount of time before it matches and settles. In parallel, the matching system could provide sets of orders for settlement synchronously where that service immediately knows in the response if the settlement succeeded.

[0074] Batching is a very important dimension for tuning such a system. Matches can be given as minimal pairs of buy and sell transactions or as large N-circuits with many parties involved in complex inter-related settlements. In order to be valid, the matches must perfectly clear with every seller receiving an exchange that is acceptable to them and no assets left in the exchange wallet. The system will likely tend to operate with the highest throughput when batch sizes are relatively uniform. A sudden burst in the size of a batch such as many 2-party transactions followed by a 200-party transaction may temporarily slow the response time.

[0075] Regularity and Optimization

[0076] By default the system waits when there are no pending matched orders to process, which can lead to an irregular interval in outputs if for example the system gets bursts of settlement requests even if they are the same complexity. If it is important to have veryregular validated reports of the system’s newest state it may be helpful to output blocks at a regular interval and size by filling unused transactional space with empty transactions that do not cause any real state transition. Highly uniform transaction rates and sizes may lead to optimal throughput especially at high frequency.

[0077] Tuning and Shard Topology

[0078] Scaling Nodes. The core validation system generates redundant copies of the records of the state being tracked. At a high level, there is a trade-off between latency / proximity of nodes and their ability to recover from disaster. If two nodes are destroyed by the same event, then the redundancy between them did not provide any benefit, so it is important that nodes be somewhat separate both physically and in terms of network topology and security to usefully distribute the data. At minimum, a shard must have 3 independent nodes - each of which can replace its running process with backups or replacements to locally recover. As one adds more nodes or separates them physically or logically, this necessarily increases the latency between them.

[0079] Scaling Shards. A fully developed system can utilize vertical integration of shards to separate big, critical, global settlements on differently tuned shards from localized or isolated settlements. Shards can also scale horizontally by adding more partitions for settlement within one exchange context. The best performance will likely result from partioning shards based on asset types or trading pairs, so assets with the same bridging processes or custodial rules will likely be grouped together. Differences in jurisdiction may also be easier to manage by utilizing separate shards, especially if they are geographically distinct.However, one shard can also handle settlements for many jurisdictions at once since those distinctions will usually only have an impact post-trade and not on the settlement process itself.

[0080] Potential Error Modes

[0081] Generally with correct matching logic that has no remainders and a firm deterministic sequencing of orders, a match will always settle without error. However, logical bugs or data corruption could always cause an unexpected error. This section discusses some error modes that should be considered.

[0082] Invalid Orders. If the provided transaction set contains at least one invalid order, then the entire set of orders will be rejected as invalid. The system can emit which invalid order it is specifically rejecting, but in the case of multiple invalid orders it will not necessarily note every invalid order. The matching system may be able to immediately replay the settlement successfully by removing all the invalid orders and replacing them with corresponding valid orders.

[0083] Unsound Orders. If any provided transaction is structurally unsound or its signature does not validate, this may indicate some type of data corruption. If all of the orders appearto be sound to the matching system, it can try to replay the entire set and it may succeed since another corruption is highly unlikely. If the rejection repeats, then there may be some serious problem with the interface between the two systems.

[0084] Duplicate Orders. The system internally de-duplicates orders based on their timestamps and signatures. If an entire transaction set is resent after settling successfully it will be rejected as duplicate. If an individual transfer from one party is duplicated, this is the same as an invalid order and the entire set it was grouped with will be rejected.

[0085] Reversal Orders. If post-trade a legal or governmental order is made to reverse a transaction, this may not always be directly possible without the action of the entity who now has custody of the asset. If the trade is final, it would need to be reversed by constructing a corresponding trade from the buyer back to the seller. In certain scenarios, it may make sense to delay finality for a well-defined window if such a reversal order is common. The DevvProtect system provides a method for settlements to finalize at some specified future time, so buyers will not have access to the asset for that time and the inverse order can be automatically generated without any action on behalf of the buyer. They will receive a ’refund’ of the assets or payment they provided initially and the seller can also have their side of the deal returned. If the window closes without any such order, the transaction will automatically finalize without any further action and both parties will be able to use, trade, or move the assets or payment they received.

[0086] Auditing and Analysis

[0087] The result of the settlement process is one or multiple blockchains that provide composable ordered lists of settlement transactions. This data structure can be the input for other systems to analyze or audit for predictive or governance purposes. The blockchains themselves are sequences of events that may need to be normalized into a model suitable for certain types of analysis across time. It is important to note that transfers within one block are not in a specifically ordered in terms of time. They all occur simultaneously in parallel and are structurally ordered in a deterministic canonical order that is more lexical or a matter of protocol than a temporal series. In the context of the larger chain however, the transactions in one block are all strictly ordered as before or after all of the ones in other prior or posterior blocks respectively.

[0088] This settlement platform can realize many time and cost efficiencies over current systems while providing the flexibility necessary to function in transitional ecosystems that combines rapidly finalizing procedures like this one with more traditional serialized or timebound processes. Many systems involving multi-party trust and settlement can be improved using the designs described herein.

[0089] The present invention has been described in connection with various example embodiments. It will be understood that the above description is merely illustrative of theapplications of the principles of the present invention, the scope of which is to be determined by the claims viewed in light of the specification. Other variants and modifications of the invention will be apparent to those skilled in the art.

Claims

ClaimsWhat is claimed is:1 . A method for exchanging assets using a distributed ledger, comprising submitting one or more transactions identifying an atomic transaction set, and recording an exchange on the distributed ledger if the conditions for all the required transactions in the atomic transaction set are satisfied.

2. A system for exchanging assets using a distributed ledger, comprising a computer- implemented blockchain, and one or more block building systems that accept transactions identifying an atomic transaction set, and that record an exchange on the distributed ledger if the conditions for all the required transactions in the atomic transaction set are satisfied.

3. A method for maintaining assets using a ledger containing transactions with cryptographic signatures, in which the transactions have contingencies and where the transactions are only recorded on the ledger if the contingencies are satisfied.

4. The method of any of claims 1-3, wherein the ledger is a hashed ledger or a hashed data store.

5. The method of any of claims 1-3, wherein the ledger is a blockchain.

6. The method of any of claims 1 -3, wherein groupings of two or more of the transactions into a set satisfy the contingencies.

7. The method of any of claims 1-3, wherein the contingencies represent the exchange of assets between two parties.

8. The method of claim 7, wherein the exchange of assets comprises orders on an exchange.

9. The method of claim 7, wherein the exchange of assets comprises orders typical of an exchange, including one or more of market order, limit order, stop order.

10. The method of any of claims 1-3, wherein the transactions represent one or more of modification to a process or procedure defined by an NFT, modification of a definition of an NFT, a rule implementing a traditional financial transaction including one or more of dispute resolution, lending, derivative, ETF valuation.11 . The method of any of claims 1-3, wherein the cryptographic signatures comprise elliptic curve digital signatures.