Liquidity caches utilized within an asset exchange system

Abstract

The present invention provides for collections of assets utilized for exchanging digital assets called Liquidity Caches. The ownership of the assets in a Liquidity Cache can be tracked on a blockchain, whether a specific token is held in an LC or subsequently transferred to an individual or entity.

Description

Liquidity Caches Utilized Within an Asset Exchange System

[0001] Technical Field

[0002] The present invention is in the field of methods and systems accommodating the exchange of digital assets.

[0003] Background

[0004] Liquidity is the cornerstone of efficient financial markets, enabling seamless trading and price stability across exchanges. However, many exchanges face significant challenges in maintaining consistent liquidity across many types of assets. As digital assets and the tokenization of real-world assets become more common, this problem will only increase. Insufficient liquidity leads to higher bid-ask spreads, increased price slippage, and reduced trading efficiency, ultimately discouraging user participation. Furthermore, fragmented liquidity across multiple exchanges creates inefficiencies, as traders must navigate multiple platforms to find the best execution, increasing costs and reducing market transparency.

[0005] Current solutions, such as liquidity pools and market makers, address some of these challenges but introduce their own limitations. Automated market makers (AMMs), commonly used in decentralized finance (DeFi), suffer from impermanent loss and inefficient capital allocation.Centralized exchanges rely on high-frequency trading firms and designated market makers, which can result in monopolistic behaviors or withdrawal of liquidity during volatile conditions. These systemic issues underscore the need for an innovative approach to liquidity provisioning — one that enhances market depth, reduces inefficiencies, allows for liquidity to be applied across exchanges, and fosters a more resilient trading environment across all types of exchanges and all types of assets.

[0006] In parallel with liquidity concerns for exchanging assets on an exchange, there are other situations where an efficient solution providing for the exchange of assets can be valuable. The development of efficient payment solutions using digital assets, where various digital assets can be used for payments, is an example of another opportunity but demonstrates additional challenges as well. One major hurdle is the volatility of digital currencies, which complicates their use as a reliable medium of exchange. Unlike fiat currencies, which benefit from relative price stability, cryptocurrencies experience frequent and unpredictable fluctuations that can affect purchasing power and settlement values. This volatility necessitates complex hedging strategies or the use of stablecoins, which introduce their own set of risks, including regulatory scrutiny and dependency on centralized issuers.

[0007] Another critical challenge is transaction speed and cost, particularly for blockchain-based payments. While traditional payment networks process transactions within seconds, many blockchain-based solutions suffer from scalability issues, leading to network congestion, high fees, and slower confirmation times. Layer-2 solutions and cross-chain interoperability protocols aim to mitigate these issues, but adoption remains inconsistent across different platforms and jurisdictions. Additionally, regulatory uncertainty surrounding digital asset payments further complicates mainstream acceptance, creating barriers to integration with existing financial infrastructure and limiting the potential for widespread adoption. Further, there is a challenge when customers want topay in one type of digital asset, but sellers want to receive a different type of digital asset as payment.

[0008] Given these challenges, there is a pressing need for a system that can quickly and efficiently exchange and transfer digital assets. The present invention provides a system that integrates a dynamic liquidity mechanism with an adaptive digital asset payment framework. The present invention not only enhances liquidity distribution across exchanges but also establishes a more stable and efficient digital payment infrastructure, paving the way for broader adoption of digital assets in financial transactions.

[0009] Description of Invention

[0010] Liquidity Caches

[0011] The present invention provides for collections of assets utilized for exchanging digital assets called Liquidity Caches. A Liquidity Cache (LC) can be comprised of a single asset type when the asset is used for market making but not payments, but is typically comprised of two asset types in which the assets can be used for both market making and payments, or any other type of utility where the exchange of assets is desired. Multiple LCs working together can define a broader system where a collection of LCs provides for liquidity across many different types of assets and also allows for the conversion between many different types of assets. Typically a collection of LCs has a Shared Digital Asset (SDA) where one of two assets in each LC is the SDA. The other asset in an LC pair is the Primary Digital Asset (PDA) for that LC. For example, as shown in FIG. 1 , a first LC, LC1 , can contain an amount of a token BTC and an amount of a token called DEWE (a trademark of Devvio Inc.). A second LC, LC2, can contain an amount of a token ETH and an amount of DEWE. These two LCs can operate in conjunction with each other to provide for liquidity for BTC, ETH and DEWE, and allow for instant trades between BTC, ETH and DEWE. Further, other collections of LCs can have a different SDA, and work together to provide for liquidity between any of the assets. For example, two more LCs, LC3 and LC4, can respectively contain tokens called SAND and FIAS and AXS and FIAS, where FIAS is the SDA for LC3 and LC4. Another LC, LC5, can contain two SDAs from other groups, DEWE and FIAS to facilitate exchanges between the DEWE SDA collection and the FIAS SDA collection. In the situation where thousands of different types of assets are contained in thousands of different LCs, the SDAs can be thought of as an intermediary between them all. In that sense, particularly when many LC assets represent other types of cryptocurrencies or stablecoins that are thought of as a representation of money, the SDAs can be considered the money of money or the currency of currency, as intuitive descriptions.

[0012] The ownership of the assets in an LC can be tracked on a blockchain, whether a specific token is held in an LC or subsequently transferred to an individual or entity. A number of example implementations are as follows. LCs therefore can have their own public-private keypair or wallet, and transfers of assets can be made into or out of an LC. LCs can be managed by entities that hold the private keys for the LCs or manage accounts that have access to the wallets. The movements of assets to or from an LC can be automated through procedures or rules, such as by smart contracts or by off-chain automation. The credit for contributions of an LC can be determined through analysisof the blockchain, or can be implemented through off-chain records that are matched with the blockchain records.

[0013] Collections of LCs can further operate in conjunction with a traditional exchange, E1. For example, an exchange that allows trades with BTC, ETH, SAND, AXS, FIAS, and DEWE can work with LC1-LC5 to provide for additional liquidity. For example, in a situation where additional BTC liquidity is desired, BTC can be transferred out of LC1 into the exchange as part of a trade, where the BTC is transferred to a trader who is trading another asset for BTC. Multiple exchanges, such as E1 , can interact with the Liquidity Cache System, and multiple Payment Systems or other types of systems that need immediate exchanges of assets, such as P1 , can interact with the Liquidity Cache system, referred in FIG. 1 as a Liquidity Mesh.

[0014] FIG. 1 is an illustration of an example of an asset exchange system using liquidity caches in coordination with an exchange and payment system.

[0015] The assets in an LC can be provided by issuers of the assets, by an exchange, through investments, or through any owner of the assets, as examples. For example, Special Purpose Vehicles, or SPVs, can be used as investment vehicles for investors to invest in an asset.Investments into SPVs can then be used to purchase the asset, which can be put into an LC.

[0016] Many different types of tokens, cryptocurrencies, digital assets, NFTs (Non-Fungible Tokens) or fractional NFTS, or other representations of value can be used in the overall framework described in this patent. For example, one type of asset can be cryptocurrencies. Another asset class can be stablecoins or Central Bank Digital Currencies (CBDCs). Another asset class can be tokenized versions of traditional assets such as stocks, bonds, derivatives, ETFs, lending mechanisms, contractual agreements, environmental or energy assets, tokenized Real World Assets (RWAs), fractional ownership of physical or traditional assets, digital representations of physical or traditional assets, or any other representation of financial assets or instruments or value. Assets can be tracked and managed through fungible tokens, non-fungible tokens, or fractionalized non-fungible tokens, as examples. Other representations of value such as derivatives, futures, options, perpetuals can be tracked on the blockchain and utilized with the exchange. The blockchain can also track leveraged positions and manage requirements under leveraged trading. Similarly, given that derivatives are, by definition, derivative of underlying assets, they can be tracked in a traditional methodology while spot trading can be tracked on-chain, in a particular embodiment of the present invention.

[0017] In an example embodiment of the present invention, funds can be raised for LCs through Special Purpose Vehicles (SPVs). A wide range of methods and mechanics for investing can be used, but the end result can be that SPV investors invest into digital assets that are held in an LC. Investors can invest fiat equivalents, or other value equivalents, that can be used to purchase the LC digital assets, or they can simply transfer their owned digital assets into LCs through mechanisms that give them credit. For example, a system can be utilized where tokens representing the transfers of assets into LCs can be delivered to a sender therefore recording credit into the LC. Alternatively, a ledger on the blockchain or off-chain can be used to simply record contributions to an LC. Similarly, other mechanisms can be used to credit a transfer, and other methods can be used to implement the tokens actually used in the LCs. For example, funds can be locked in a user’s wallet at theconsensus or monad (as described herein) level, where validators directly receive transactions indicating the state of those funds, and those funds, or alternatively a representation of those funds, can then be used within the LC itself. In this example situation, a user can lock funds in their own wallet, and a transfer of equivalent funds from a larger collection of the asset can be moved into LCs on the user’s behalf. This type of approach can avoid tax ramifications that would otherwise be triggered by an actual transfer. Fees such as those from payments systems or exchange transactions or market making revenue can be shared with those that contribute to an LC. Market making revenue or other types of revenue created through the activities of LCs can be shared with LC contributors. Contributors to an LC can contribute a PDA while others can contribute an SDA. PDA contributors can share in different types of revenue than those who contribute to an SDA for example.

[0018] Liquidity Caches can include one asset. For example, an LC can be comprised of an SDA which is utilized for matchmaking activities, but where that LC is not used for immediate exchanges. LCs can include more than two assets. For example, an LC that includes X assets, where X>2, can work as a traditional liquidity pool but where the returned assets from the transfer of one of the assets is comprised of all of the other assets on a pro rata basis. Other mathematical functions or algorithms can determine how an LC with X>2 operates with respect to immediate exchanges.Similarly, irrespective of the number of assets in an LC, a variety of mathematical functions or algorithms are possible for determining how the assets correlate upon transactions. For example, in a traditional liquidity pool the product of the quantities of the two tokens is set to a constant product. In an LC, any arbitrary function f(X), can be used, where the value or amount of a first token A is equal to f(X) and the value or amount of a second token is X. Various functions that determine how adjustments of the amount or value of one token affect the amount or value of another token can give better behavior for more volatility in the token values, as an example.

[0019] Users in the Asset Exchange System (AES, as described herein), can contribute tokens into the AES, such as into LCs or into Liquidity Seas (as described herein), or can invest in which a manager then purchases tokens and contributes the assets into the AES. The contributions can be managed at the Monad level, and can be defined by rules and recorded through NFTs, as examples.

[0020] In this present invention, the methods that users can maintain their assets and control the use of their assets can be referred to as a wallet, a public private keypair, a public address, an account, or other descriptions commonly use in relation to blockchain technology. Any descriptions of methodologies for ownership representations and control of assets is not intended to be limiting, and various descriptions of the mechanics of ownership can be used interchangeably.

[0021] Automated Market Making System

[0022] An Automated Market Making System (AMMS) can be used to create liquidity for an exchange in coordination with LCs. The AMMS can make money in a similar way to how traditional market makers make money. The spread refers to the difference between the price at which a seller is willing to sell an asset (ask price) and the price a buyer is willing to pay for it (bid price); it is the gap between the buying and selling price of an asset on an exchange, representing the cost to execute a trade. Traditional market makers primarily make money by profiting from the spread.Essentially, they buy at a lower price and sell at a slightly higher price on each trade, typically generating a small profit on every transaction that is irrespective of overall market price movements.

[0023] Traditional exchanges often use order books to match buy orders and sell orders. FIG. 2 shows a simple example order book consisting of buy orders (bids), and sell orders (asks). In FIG. 2, one of the users is labeled as BTC LC, referring to the DevvE / BTC LC. The exchange, coordinating with the AMMS, can put bids and asks into the order book associated with LCs. An algorithm can determine which orders are placed at various prices and amounts in an order book alongside traditional orders from traders and market makers. An example algorithm can have ordering defined by rules rather than order times, when the orders come from an LC. An example algorithm can have a parameter that affects how many orders are placed in the order book based on a percentage of volume. For example, an algorithm can have a concept of AMMS Liquidity Provision Pct (ALPP) where the ALPP indicates a percentage of trades that would typically come from LCs. In this example, if the ALPP were set to 50%, then the AMMS can match all of the limit order trades by other traders and market makers. Additional orders can be entered at varying times and price points into an order book. For example, in FIG. 2, when the $100, 106 bid from the BTC LC is fully filled, then a new order for .1 BTC at a price of $100,096 can be entered into the order book. An example algorithm can implement traditional market making approaches by adjusting pricing within the spread in order to be more or less aggressive in lowering the spread. Typically, assets that have a higher volatility have a higher spread. The AMMS can determine its own pricing, or leverage other orders in the order book to determine its pricing, or leverage other markets and exchanges to determine its orders. The AMMS’s activities can complement other traditional market maker activities leading to lower spreads and less overall volatility on assets. The algorithm used by an AMMS in coordination with the exchange can place orders before or after other market maker orders and give different prioritization.

[0024] An AMMS algorithm can be automated by implementing an AMMS trading system, which can be managed on-chain through smart contracts, or off-chain through traditional programming methodologies, where the AMMS trading system has access to managed private keys. The AMMS trading system can operate within the rules of when orders are placed determined by an algorithm, and can sign transactions sent to the blockchain. These transactions can be traditional transactions simply sending assets to another public address, or can be contingently signed where the transaction goes through if and only if all criteria required are met by grouping the transaction with other transactions as part of a Contingent Transaction Set (CTS). For example, a contingently signed transaction in FIG. 2 can be that the BTC LC agrees to transfer $11 ,612.19 (comprised of $11 ,512.19 for payment for the asset plus $100 in exchange fees) of a USD stablecoin if and only if at the same time it receives 0.115 BTC through a different transaction. A contingent transaction or a standard transaction can be signed with an ECDSA signature for example. In the case of a standard transaction, the assets can be managed by a middleman or intermediary implementing the exchange transaction. In the case of a contingently signed transaction there is no middleman or intermediary. The transactions in a CTS occur at the same exact moment, as they officially occur when the blockin a blockchain containing the CTS is added to the blockchain. Therefore Contingent Transactions have Mathematically Instantaneous Settlement (MIS).

[0025] Multiple exchanges can be implemented using the same LCs. For example, exchanges that are created as different legal entities in different legal jurisdictions can target different customers and operate according to the legal jurisdiction for the entity. For example, different exchanges can operate in different countries, targeting the citizens of those countries and following the laws of those countries. Some exchanges can target citizens of other countries. Some exchanges can utilize derivatives while others only implement spot trades, while others can do both. Different exchanges owned by different legal entities can develop partnerships and business relationships to strengthen their businesses. In these types of situations, a classic challenge is the separation of liquidity. A company running a successful exchange in one country can struggle when opening a new exchange in another country, as liquidity for the original exchange is tied to the operations of that exchange, and not easily moved to the new exchange. LCs and the related Liquidity Mesh provide for a solution to this problem. LCs can operate in coordination with multiple exchanges where orders can be sent to multiple exchanges, giving shared liquidity across exchanges. Smart contracts or simply operational definitions can adjust how one LC operates with respect to multiple exchanges if there are ever conflicts in regulatory requirements. An ALPP can vary for LCs, can vary for the use of LCs in different exchanges and can vary over time. An ALPP can grow from a small percentage to a large percentage, or even 100%, as the assets contained by LCs grow.

[0026] An AMMS can use hedging strategies, as is common for market makers. An AMMS can coordinate with a partner exchange’s operations to implement hedging strategies, or it can use mechanisms outside of the overall system. For example, the AMMS can hedge using perpetuals or other derivatives if a position in an LC asset grows too large or too small.

[0027] Fig. 2 is an illustration of an example order book.

[0028] Immediate Exchanges

[0029] In addition to the use of LCs, and the assets within the LCs, for the purposes of increasing liquidity for an exchange and for market making, LCs can also be utilized for immediate exchanges of assets. In the case of an AMMS utilizing an LC, the assets within the LC can be used within an order book as shown in FIG. 2. In that use case, the PDA asset within an LC pair is used for liquidity for that asset. Additionally, however, the combination of both assets in the LC pair can be used to allow for an exchange between those two assets. For example, LC1 can be used to immediately exchange BTC for DEVVE or DEWE for BTC.

[0030] A Liquidity Cache can be implemented to allow for immediate exchanges in a similar way to how Decentralized Exchanges (DEXs) use Liquidity Pools (LPs) and Automated Market Makers (AMM). A DEX typically allows for the deposits of two assets into an LP. A common type of DEX is a Constant Product Pool, in which the product of the quantities of the two tokens is set to a value K. An LC can be operated with a similar K value when immediate exchanges are required. When one of the two assets in an LC asset pair is sent to the LC, an amount of the other asset in the asset pair is returned such that the K value is maintained and fees for the transaction are paid. This mechanism adjusts the relative pricing of the two assets. Other mechanisms and other mathematical functionscan be used in an LP or LC, but the end result is that the mathematical function adjusts the relative prices of the two assets to create a function that allows for natural supply and demand curves.Typically, larger amounts of assets in an LP or LC creates less price volatility per trade (when comparing equal trade amounts), while smaller amounts of the assets creates larger volatility per trade. Typically larger trades create larger price differences as well.

[0031] When LCs are used for immediate transactions, the SDA in a collection of LCs can be used to exchange value between any non-SDA assets in the collection. For example, immediate exchanges of assets are often needed for payments. A buyer may want to pay with one type of digital asset (such as Bitcoin), where the seller may want to receive a different type of digital asset (such as a stablecoin like USDC). The seller often wants payment immediately, such as a merchant selling a cup of coffee. LCs can be utilized effectively in this situation to make the payment while allowing for the requirements of both parties. In the example of a customer buying a cup of coffee, the customer can scan a QR code with a mobile phone at a point of sale system at checkout and then verify on the mobile phone that the purchase is allowed. A Payment Controller System (PCS) can then indicate three transactions to complete the purchase. In this example, the first transaction is a transfer of Bitcoin from the User’s wallet to the BTC / DEVVE LC. This results in an equivalent value return of DEWE, less potential fees. The second transaction is a transfer of that DEWE to a USDC / DEWE LC, which results in the equivalent value of USDC, less potential fees. The third transaction is the transfer of the USDC to the merchant thus completing the payment. In this example, fees for the overall transaction to the PCS can be paid per use of the LCs or paid separately in a separate transaction. For example, the fees can be designed such that they are paid in an SDA asset as a separate transaction from the actual transaction implementing the payment itself. In the case of an LC controlled by a constant product K value, the current state of the two assets in each of the LCs involved adjust the overall pricing and fees. Other fees can be manually calculated per use of the LC or as a flat fee, for examples. The amounts in the three transactions can be determined by the PCS at the time of the payment such that all fees are accounted for, and such that the correct amounts of BTC are transferred from the customer and the correct amount of USDC is transferred to the merchant to cover the cost of the purchased item. The point of sale system can verify that the USDC was received. For example, the PCS can send a verification ID of the payment transaction to the point of sale system, and the point of sale system can utilize an API command linked to a block explorer in order to approve the transaction and verify payment was received. Assets can be wrapped tokens, where an underlying asset is held by a bailment partner. For example, a bank can hold BTC on the Bitcoin blockchain underlying wrapped bitcoin on the blockchain processing the payments, where a representation of the underlying BTC (the wrapped token) is used for the payment. With a high speed blockchain like the DevvX blockchain, the transactions can complete in a fraction of a second, making merchant payments possible.

[0032] If the three transactions in the above payment example are implemented as contingent transactions, and then all three transactions are approved as a contingent transaction set on the blockchain, then the PCS can predefine the three contingent transactions, thus removing any counterparty risk or settlement risk for any of the transactions. A contingent transaction set allows fora situation where each of the three transactions are validated on the blockchain if and only if all three transactions are validated, making sure that the entirety of the payment transaction occurs as designed.

[0033] Two LC collections with different SDAs can similarly be utilized together through additional transactions by using a separate LC with a pair that has one each of the two SDAs. In this way, any number of LC collections can be used to convert or exchange any asset to any other asset in them. For example, an immediate exchange of BTC to AXS can be implemented with a transaction with the BTC / DEVVE LC, followed by a transaction with the DEW / FIAS LC, followed by a transaction with the FIAS / AXS LC. Contingent transaction sets can be used with any number of transactions combined in a group to give a desired overall outcome (in this example, the exchange of BTC for AXS), including transfers to recipients such as in payments, therefore eliminating settlement risk on any individual transaction within the overall payment defined by the contingent transaction set. With these mechanisms, any asset can be designed to be able to be exchanged for any other asset immediately and without settlement risk.

[0034] Immediate exchanges can also be used for creating liquidity on an exchange separate from the use of LC assets in market making activities. For example, in a situation where liquidity is low for a particular asset and there are few or no orders in an order book, a user listing a market order could be matched against an immediate transaction in the same way that a payment is processed. If the market order in this example is a bid for token A in exchange for token B, then the system can instruct the PCS to make asset A available in exchange for asset B through one or more LCs.

[0035] Digital Asset Exchange

[0036] A Digital Asset Exchange (DAE) can be used in conjunction with the LCs. Operations for the DAE can be coordinated with the AMMS and PCS in order to coordinate orders from traders and market makers with LCs, to allow balancing of the systems, and to allow for additional complementary use as described herein, as examples. Given CTS, custody is not required for the DAE, and therefore the DAE can operate more like a traditional finance exchange in terms of regulation rather than current Centralized Exchanges (CEXs) which operate more like brokerages as users transfer their assets into the exchanges’ custody to implement trading. CTS settlement can be used to implement settlement that is different from traditional exchanges as orders can be placed such that they are guaranteed to settle if they are grouped in a valid CTS, and settlement after the matchmaking process can occur in less than a second with no settlement risk. A DAE can receive orders through a User Interface (Ul) or through API integrations.

[0037] Asset Exchange System

[0038] An overall Asset Exchange System (AES) can be implemented with liquidity transactions managed by an AMMS combined with immediate exchange transactions managed by a PCS. In combination, these two systems can operate in conjunction with an exchange, such as a DAE, and implement a broadly applicable asset exchanging mechanism across different requirements for timing, speed, and utility. Liquidity caches can be used broadly as an intermediary swapping exchange and contractual agreements can be implemented through smart contracts or Monad programming, and can be automated. Transactions that need to be handled immediately irrespectiveof any other parties being involved, can be implemented quickly, while traditional exchange transactions matching buyers and sellers can also happen quickly with immediate settlement after matches are made.

[0039] A Liquidity Cache’s size, or amount of contained assets, determines its capabilities on both market making transactions and immediate transactions. If the number of assets in the LC are too small, then there can be too much volatility in the relative prices of an LC asset pair when implementing payments, for example. However, if the LC is too big, then the pricing might not react to changes fast enough. Larger LCs can implement more liquidity, but too large an LC can leave owners with too small a share in revenue from the LC’s use. LCs can be broken into multiple LCs with the same trading pairs which are optimally sized for their usage. The SDA can be adjusted relative to the PDA to adjust the relative changes between the two assets as desired in a given use case. The AES can affect or define algorithms that adjust the amounts of any given asset in an LC. Some LCs can be sized and used to emphasize immediate payments while others can be sized and used to emphasize market making activities, but in this type of example situation, both can be used for both purposes as needed.

[0040] LC asset amounts can also be adjusted over time, either algorithmically or through a management process, based on overall price movements of assets as well. If a PDA increases in price, additional SDA can be increase in amount in the LC to maintain desired characteristics for immediate payments. Similarly, as another example, if a PDA increases in price, an LC can be split into two other LCs where the amounts of the PDA in the new LCs better fit a market making strategy. Alternatively, the amount of the PDA can simply be adjusted, by returning assets to owners or allowing participants to contribute more, or by changing amounts from other pools or through trading and transactions that balance the system. Similarly, the SDA can be adjusted in similar philosophies. Adjustments to LC sizes have additional flexibility with Liquidity Oceans and Liquidity Seas described herein.

[0041] One of the benefits of the architecture of an AES is its ability to operate within regulatory compliance. Given CTS, there are no middlemen in trades, and therefore the exchange itself does not need to maintain custody of assets in an omnibus wallet therefore creating additional risk to users. An example of this is demonstrated by the Bybit exchange theft. In an AES, different entities can manage the DAE and the LCs to prevent conflicts of interest that are prevalent with current CEXs and DEXs. The DAE can maintain an order book where market makers and the AMMS follow rules set out by regulations such as the NBBO. Identity information on all users and entities operating in the system can be maintained in order to be compliant with Anti-Money Laundering (AML) and Know-Your-Customer (KYC) requirements.

[0042] Another benefit for an AES is its ability to prevent manipulation and illegal activity. Given KYC requirements and the innate immutability of a blockchain many types of manipulation can be prevented or discouraged. Wash trades and spoofing can be tracked and evaluated by regulators. Large purchases or sales designed to artificially move the price of an asset and benefit from shorting or derivatives purchases such as perpetuals (perps) can likewise be tracked and evaluated by regulators. Concepts like front running are eliminated given CTS and MIS. LCs help to prevent otherentities from cornering the market, and over time large percentages of marketing making can come from the AMMS algorithms, which can be designed to be regulatory compliant.

[0043] Another example of preventing illegal activity comes from abuse of short selling. AES can implement specific methodologies for short selling. For example, terms and conditions for the use of the DAE and for the asset ownership on the blockchain can require that all short selling be implemented through a smart contract system. The smart contract system can be defined by on-chain and auditable NFTs. The mechanics of short selling can be implemented through automated processes where payments are automatically credited appropriately based on tracked movements of assets on a blockchain. The short selling smart contract system can utilize auditable requirements on asset ownership to prevent naked short selling, where a seller sells shares they do not actually own. Short selling can be restricted on assets where manipulation can be easily implemented such as with assets that have a low volume of trading. Where traditional finance approaches typically look to prevent naked short selling through attempts to create transparency, an AES can mechanically enforce short selling requirements therefore reducing much of the difficulty in catching those who abuse the system.

[0044] Another benefit of an AES comes from efficiencies and the removal of middlemen and intermediaries. Given CTS, users can trade directly from their own wallets removing the need for brokers. MIS removes the need for intermediaries that manage settlement. All of the middlemen in a traditional finance exchange, CEXs themselves acting as middlemen, inefficiencies and manipulation in DEXs, exorbitant fees in payments, fees associated with transfers of assets such as remittance fees or any type of generic transfer fee, on-ramp and off-ramp fees, all create expense and inefficiencies that remove value from the system and users of a system. Removing these costs and inefficiencies allows for an AES to be more efficient and for AES users to maintain more control of the value within the system as a whole. Further, by sharing in revenue from fees, market making, or other forms of revenue related to the use of LCs, fundamentally the AES represents a system where its revenue, including revenue from different parties involved in the system as a whole, is shared with those that help provide liquidity for the system. The creates a system that incentivizes liquidity provisioning. Additional liquidity creates opportunity for additional revenue generation by the system, which further creates more incentives for adding more liquidity, and so on.

[0045] Another benefit of an AES comes from the benefits of its unique operations for traditional financial entities that must work within traditional regulatory frameworks. For example, middle sized banks cannot simply transfer their customers’ deposits into a CEX. Given CTS, banks and their customers, or any financial institution and their customers, can maintain control of their assets at all times, making an AES an applicable way to take part in digital assets for the first time in many cases. In the case that a DAE is run on the DevvX blockchain, the DevvX blockchain features can give additional capabilities that traditional financial institutions need, such as fraud protection, theft protection, loss protection, integration through a RESTful API, and regulatory compliant privacy that traditional financial institutions require in order to enter the space.

[0046] Another benefit of an AES comes from its ability for automation. This can be implemented through on-chain smart contracts, through Monad programming, or through off-chain algorithms tiedin with the blockchain operations of the AES. As examples, a number of activities can be automated such as the balancing of LCs, placing AMMS orders, collection of collateral in a loan in the case of a default on payments, movements of assets to and from Liquidity Oceans and Liquidity Seas, the coordination of Contingent Transactions as part of an overall payment or exchange, reporting to auditors and regulators, payments for fees for exchanges on the DAE, payments for fees for immediate exchanges through the PCS, verification of asset transfers, prevention of multiple spoofing trades, tracking a history of manipulate activity, verification of real world events through IOT connections or through oracles which integrate external data events with a blockchain, automating trades for users or the AMMS based on the success, failure, or status of other trades, subscription payments, arbitrage activities, tracking of trader and market maker manipulations of the AMMS, oversight and operations typically implemented through Full Time Employees FTEs where those efforts can be automated and verified by blockchain records, payments based on events, point of sale systems, remittance systems, tax payments, gamification for participating in revenue sharing, events for sharing in revenue from the AES, and methodologies for accounting for revenue share in the AES, as examples.

[0047] An example embodiment of the present invention includes different types of automation, as examples. Events can be used to trigger automation. Events can be time-based, transaction based, blockchain status based, asset ownership state based, or based on events that occur externally to the blockchain, which are related to the blockchain through a trusted source such as an oracle. One category of automation is automation on trades. A user can implement a standard limit order trade that might or might not be fulfilled, depending on the movement of prices of the asset and the particular state of an order book. A user might want to have a second trade that occurs if the first trade goes through. The second trade, for example, might require the assets acquired in the first trade. In this case the user can indicate that the second trade be created in an automated manner once the first trade goes through. This can be implemented with an off-chain solution in which a system monitors the states of trades, and creates new trades based on those states. If CTS is used, the user can sign the second transaction, but not release it to the system until the first transaction is completed. Similarly, contingent trades can be implemented with CTS directly. The contingency on one contingent transaction can be the completion of a separate transaction. In this way, the user can implement both contingent transactions at the same time, but the second will not go through until a contingent transaction set including the first trade is completed and validated on-chain. Another category of automation is escrow systems that are implemented upon events. Transfers can be implemented into an escrow system, or to any other recipient, such that the transfer goes through after an event occurs. As with other automations, this can be implemented with off-chain transactions where private keys are managed, or through contingent transactions where the contingencies are defined and understood by validators using Monads. Another example of automation includes contractual and legal obligations and implementations. For example, a will can be defined in an NFT, where assets are distributed upon one’s death. The event of one’s death can be verified by a trusted authority through a mechanism such as a signature that is allowed to define the use of this mechanism per the NFT definition, for example. A will NFT can define which assetsare sent to which wallets upon a death event. This can be implemented through a managed key or through contingent transactions.

[0048] An example embodiment of the present invention includes fraud, theft, and loss protections with an AES. Users can define systems that protect their assets against fraudulent transactions, against theft of one’s assets, and against loss of a private key.

[0049] Monads can be used for implementing various types of protections with a focus on user control where the common crypto refrain of “not your keys, not your crypto” is established. Each of fraud, theft, and loss protections have their own logical flow to give protections on the blockchain at the validator level. May people in the crypto space have felt the trepidation of sending assets, the fear of theft and scams, and the risk of losing access to a wallet. The crypto space has many experiences fraught with risk, and many cryptocurrency owners have experienced loss or theft of some sort. These protections are optional, so a user does not have to set them up to be implemented.

[0050] An example embodiment of the present invention includes loss protection mechanisms in which a user can define an NFT that is added into a wallet that provides rules in which there is an ability to recover assets if the user loses the private key associated with that wallet. For example, a user can set up a service to contact and have assets moved to a new wallet if a private key is lost. A loss protection NFT therefore can define rights on how the loss protection event can be triggered, such as from another wallet signature or an M of N set of signatures from other wallets. This is an important mechanism if a user loses a private key or if someone dies and their heirs do not know where a private key is kept. This recovery mechanism is implemented so that it cannot be abused as well. The movement of assets in a recovery operation can be implemented so that the assets are locked for a time period, for example 30 days, and during that time the original private key can reverse the recovery transaction that moved the assets. Therefore, overall, there is recourse if one loses a private key but no actual trust required because the owner can undo the loss recovery transaction if they did not actually lose their private key.

[0051] An example embodiment of the present invention includes theft protection. Thieves stealing private keys or otherwise draining a victim’s wallet is a significant problem in the crypto space. With a theft protection mechanism, a user can create multiple wallets, i.e. multiple public-private keypairs, that maintain timeframes in which the assets can be released. A user can therefore, for example, put 5% of their assets into a hot wallet that is at risk of theft, but put 95% of their assets into a wallet that has a 30 day locking period. After a transfer is initiated, and during the locking period, the user can prevent the transfer from completing, such as by signing a transaction stopping the transfer. Lending programs can give access to locked funds, with no risk to the lender, if funds are ever needed early.

[0052] An example embodiment of the present invention includes another type of protection, fraud protection, can be used to provide the protections typically used in traditional finance when buying items. In contrast to loss protection and theft protection, fraud protection can be implemented per transaction, such that both the sender and receiver are presented with rules defining the transaction. This is useful, for example, if someone buys something online, and there is risk that the purchased item might not be delivered. With fraud protection mechanisms there is recourse in this situation.Transactions that are protected with fraud protection put any transaction assets into a state where they are not delivered, such as an escrow wallet, or an asset that is in the process of being delivered, as examples, for a time period in a way that is transparent to a buyer and a seller. If there is a dispute, then a dispute resolution system is implemented, similar to the dispute resolution system implemented by companies like Visa. If a dispute is initiated, then the transaction can be held up for a longer time period while the dispute is resolved. The definition of the fraud protection can include an entity that has rights with respect to the blockchain transaction to manage the dispute, but allowing or denying the transaction to go through, extend the timeframe that the transaction is held up, or otherwise provide for a fair resolution. Fraud protection is optional, and senders or receivers can disagree with its use.

[0053] An example embodiment of the present invention includes management of the AES to account for latency in global transactions. The DevvX blockchain can be used to implement the AES. The DevvX blockchain includes what it calls shards, where each shard has its own validators and blockchain. Each shard can be customized in its operations for a given use case, for given legal requirements, or for given technical needs, as examples. DevvX has a cross-shard mechanism where transactions and assets can be moved from one shard to another. LCs can be held and managed on different shards, where the validators on a given shard are located in a particular geographic area, therefore removing challenges with latency in that area. Multiple LCs with the same pair of SDA and PDA can be managed on different shards, where preference for a need for liquidity or payments, for example, can be made to the shard with lower latency. LCs in shards with larger latency, though, can still be used, so the liquidity is not lessened through this type of implementation. Rather, latency is addressed and minimized given the use and separation by shards. Similarly, different shards can be customized for other needs. For example, if a high frequency trading capability is needed for institutional traders, a shard can be customized for their use, using LCs on that shard optimized for their needs. LCs on shards can be balanced globally as needed given DevvX cross shard functionality.

[0054] Balancing

[0055] The algorithms used by the AMMS and the PCS can adjust the asset balances in the LCs so that in steady state operations, the balances remain withing statistical or desired ranges. For example, BTC used to create liquidity for BTC exchanges can be comprised of both bids and asks such that the average of all the bids and asks keeps the BTC amount at an average amount over time. This can be important, as the BTC in an LC can represent an investment by investors in that asset, where the investors are relying on the BTC amount not changing substantially over time. Similarly the PCS can manage payments such that relative balances of CTS assets remain within a statistical range. If some users want to spend BTC and some users want to receive BTC, then the amount of BTC in an LC can average to a set amount over time.

[0056] However, any exchange experiences times of higher volatility. Macro market dynamics, outside of the exchange’s operations, can drive supply and demand fluctuations of assets held in the LCs. Also, even during standard operations, patterns can drive imbalance. For example, many merchants might want to receive stablecoins for payment for their products to remove volatility withinthe payments themselves. Some merchants, for example, do not want to receive cryptocurrencies that are volatile. They simply want to focus on their business operated with cash and cash equivalents. This can create more demand for stablecoins in LCs, thus negatively affecting the price of the matching SDA in the stablecoin LCs.

[0057] In situations where an asset amount or value in an LC becomes too high or too low for desired operations or desired purposes or other desired criteria, then balancing is needed in that LC. Balancing can be based on value or amount, and descriptions herein describing balancing by value can also be implemented by amount and balancing by amount can also be implemented by value. A combination of algorithms and automation run by the AES directly, by the DAE, by the AMMS, by the PCS can implement balancing. Any given algorithm can have an ability to create priority or adjust specific mechanics of trades. Balancing transactions can be used with CTS.

[0058] LCs can be balanced through trades on the DAE. For example, a BTC / DEWE LC that has too much BTC can put an ask for BTC into the exchange. This can happen by the AMMS with permissions allowed to enter into the order book, or it can be a request by the AMMS into the exchange, or it can simply be an order placed like any other trader. Balancing trades can be limit orders, market orders, or other types of orders. The DAE can give both permissions and order book visibility to the AMMS so that the AMMS can get priority in setting trades. Trades that are flagged for rebalancing can be implemented without fees.

[0059] LCs can be balanced through immediate exchanges. For example, if an LC needs more of a specific type of token, then an immediate transfer from another LC with that token can fulfill that need. If multiple LCs need to be adjusted where the tokens in each of them can create a better balance, balancing can occur across all of them. For example if an LC needs more of token T 1 and less of token T2, another LC needs more of T1 and less of token T3, another LC need less of T1 and more of T3, and another LC needs less of T1 and more of T2, then all four LCs can implement immediate exchanges to collectively be in better positions on their assets.

[0060] In the operations of an LC, there can be limits on maximum and minimum amounts of a token, or the availability of a token in an LC can be controlled by a mathematical algorithm where the availability is a function that is asymptotic to limits. As an LC’s balances approach limits, balancing can be prioritized, including by paying for additional fees if needed.

[0061] Another form of balancing is adjusting the amounts of an asset directly through transfer transactions, rather than through exchange transactions or immediate exchanges. For example, the SDA balance can be adjusted in an algorithm across all LCs to maintain balance across a desired balancing goal. In this example, examples of a balancing goal includes maintaining consistent amounts of value for the SDA across LCs, maintaining consistent amounts of value across both pairs of tokens in the LCs, adjusting the immediate payment conversion mechanisms to drive price goals for PDAs such as in the case of stablecoins.

[0062] In the case that an LC is balanced to create a constant value for a PDA token referenced off an external asset such as a fiat currency, the SDA amount can, for example, be adjusted by transfers to and from a Liquidity Sea. The relative values of the PDA and SDA can be controlled by a K value, for example. If an asset the PDA is tracking, such as the US Dollar (USD), changes invalue, then the SDA amount can be adjusted so that the relative value of the PDA to the SDA is equal to the value of the USD. The use of LCs for maintaining a relative value of a PDA can be used to limit volatility for the PDA similar to the use of stablecoins.

[0063] Another example of a balancing goal is adjusting asset amounts in a collection of LCs where the collection of LCs represents a collection of other assets. The assets in the collection of LCs can be adjusted in value in a similar mechanism to how ETFs track indices or other asset groups, for example, referred to herein as an LC ETF. The concept can be used to track collections of cryptocurrencies, or any other collection of assets, in a similar way to how traditional ETFs work. Tokens can be issued that represent the ownership of the underlying assets in these LC ETF collections. As ownership tokens are added or removed, which can be accomplished by minting or burning them based on supply and demand for the ownership tokens, the underlying assets in one or more LCs can be adjusted to reflect the value of the reflected collection. For example, an LC ETF can be implemented such that multiple LCs hold tokenized stocks representing the Nasdaq-100 index, which is made up of the 100 largest non-financial companies on the Nasdaq. 100 LCs can be created where each LC holds one of the Nasdaq 100 index stocks. As users desire to purchase the LC ETF ownership tokens, for each ownership token purchased, the ownership token can be minted and transferred to the new owner at the same time that additional PDA assets in each LC are purchased and added to the LCs, such that the value of the LC ETF ownership tokens have a value equal to the Nasdaq-100 index value. If a user desires to sell an ownership token, it can be burned and the underlying assets in the LC ETF can be removed from the LCs and sold or exchanged. Other LCs not associated with the LC ETF can hold the LC ETF ownership tokens as its PDA.

[0064] An example embodiment of the present invention includes LCs that are utilized for both market making activities and immediate exchanges for payments. When the LC is used for immediate exchanges, such as for payments, the relative prices of the two assets is adjusted by the K value of the LC. When the PDA in LCs are used for market making activities the SDA, and a PDA amount is removed, the SDA amount can be adjusted using a Liquidity Sea so that the relative prices remain the same and so that the marketing making activities do not adjust the relative prices. Similarly, mathematical functions can drive adjustments in the SDA along any function curve so that market making activities affect the relative prices as much as desired when creating balance.

[0065] Container Types

[0066] Assets can be held in amounts that are reserved for use as needed, that can be coordinated with LCs. For example, two types of asset containers beyond LCs are called Liquidity Oceans and Liquidity Seas. A Liquidity Sea can be used to transfer assets to and from LCs for balancing purposes or for operations of the LCs. A Liquidity Ocean can be used to transfer assets to and from Liquidity Seas as needed, if the Liquidity Sea gets too big or too small, or when other mechanisms are needed in order to manage business requirements related to the Liquidity Sea such as distributions of shared fees. Liquidity Oceans and Liquidity Seas can hold one or more tokens and can coordinate with different collections of LCs or each other.

[0067] Liquidity Seas and Liquidity Oceans can represent different types of ownership and different types of revenue sharing. As one example, fees associated with a payment system can be sharedpro-rata with all LC SDA contributors and SDA Liquidity Sea contributors. The SDA Liquidity Sea can be used to assure that enough of the SDA needs are met and can allow a larger number of contributors to take part in the system by moving their tokens into the Liquidity Sea. A Liquidity Ocean, for example, can include tokens owned by a token issuer, and transfers to and from the Liquidity Ocean and Liquidity Sea can be used to keep a Liquidity Sea at a set amount while allowing for priority in Liquidity Sea participation to go to AES users. Tokens placed in LCs, Liquidity Seas, and Liquidity Oceans can be subject to lockups and other usage rules. Any type of rule, such as contribution rules, lockup rules, extraction rules, use rules, or other rules can be different between LCs, Liquidity Seas, and Liquidity Oceans. All of these rules can vary by token or can vary based on whether the token is an SDA or PDA.

[0068] As an example use of Liquidity Oceans, a user can indicate that they want to contribute a token to a Liquidity Sea. Tokens can then be locked in a user’s wallet, and tokens from a Liquidity Ocean can be transferred to the Liquidity Sea on the user’s behalf. The user can share in fees associated with the Liquidity Sea’s use. When the user wants to withdraw the use of the locked tokens from the Liquidity Sea, they can unlock the tokens at which point their tokens in the Liquidity Sea can be transferred back to the Liquidity Ocean. The unlocking of tokens in a wallet can be limited over a time function, for example.

[0069] Tokens in LCs, Liquidity Seas, and Liquidity Oceans can be considered to be Unowned Tokens (UTs) if the LC, Liquidity Sea, or Liquidity Ocean is designated to have UTs. With UTs there is no owner of the tokens, meaning that the tokens are used mechanically as part of the LC algorithms. An Unowned Token Pool is any collection of UTs such as in UT LCs, UT Liquidity Seas, and UT Liquidity Oceans. If, for example, a UT is transferred to a user as part of a DAE exchange, the UT then becomes an owned token, owned by the new owner. Users can receive bailment tokens for tokens that are contributed to a UTP. The bailment tokens can then be used to retrieve the UTs. Alternatively, when a user wants to contribute tokens to a LC or Liquidity Sea, assets can be flagged in a user’s wallet, and locked by low level consensus mechanisms until an unlock event is initiated. Retrieving or unlocking UTs can be implemented with rules such as lockups and amount transfers limited over time by other related amounts such as trading volumes or the size of the LC. UTs provide for a way of more accurately accounting for the circulating supply of a token or for accounting for tokens that represent true ownership, where a user can sell them, in contrast to tokens that are simply used for mechanical movements and balancing in the AES. For example, tokens that are locked up in an LC as UTs do not represent an ability for the bailment token owner to sell them, while they are locked up. While they are locked up, they are used only in the LC mechanisms. Rules can affect how UTs are utilized and how they can be transferred to users.Depending on any rules UTs operate under, UTs can be included or excluded when reporting the market cap or circulating supply for a token.

[0070] Revenue Sharing

[0071] There are several types of revenue generated by the AES. There is revenue from fees for exchanges on the DAE. There is revenue generated by the AMMS through market making activities. There are fees associated with immediate payments by the PCS. There are opportunities for otherfees associated with LCs, such as subscriptions, interest, investment of LC assets, lending fees, or any other traditional method of generating revenue from assets. There is an ability to generate revenue through arbitrage, including discrepancies in prices between an exchange and a payment system, an exchange and external prices of assets like other exchanges, or between the payment system and external prices of assets like other exchanges.

[0072] Revenue sharing can be based on NFT ownership where NFTs are rewarded for other activities. For example, users that join the system early, bring in many other users, help spread the word about the AES, or in other ways contribute to the growth or success of the system, can receive NFTs and those NFTs can give benefits such as reduced fees as a user, increased revenue sharing as a user, or access to particular revenue streams.

[0073] Users can pay fees directly through transactions, can have fees debited from their ownership of an asset such as an SDA like DEWE, or can pay fees as part of a transaction, as examples.

[0074] Revenue generated by the AES can be shared with users, investors, or LC asset contributors. Different types of revenue can be shared with different types of users and activities. For example, in one example embodiment of the present invention, revenue generated from market making can be shared with owners of PDA assets in LCs where revenue generated from a payment system can be shared with owners of SDA assets.

[0075] There can be different mechanisms for determining how revenue is shared. Different categories of fees can be shared with different categories of users. Revenue sharing can be allocated based on a pro-rata rate of participation in contributing to LC assets, based on token ownership or contribution records, based on gamification strategies associated with activities that grow the AES, or any other type of algorithm. For example, revenue that is shared with SDA owners can be shared with everyone who contributes SDA assets or investments used to purchase SDA assets, and the pro-rata rate of sharing in revenue generation can include ownership directly in LCs as well as Liquidity Seas.

[0076] Agamified system can be implemented for determining sharing of revenue. This system can be implemented for a specific collection related to an SDA for example, or it can be implemented across the entire AES. As an example of how a system can be used to adjust revenue sharing, guilds can be created where competitions between guilds determine relative increases or decreases in revenue sharing. Competitions can be reset over a time period, or aspects of competition can be tracked longer term or even be tracked perpetually. Guilds can compete through their member activities, and members can play games, take part in activities, perform tasks, help grow the overall ecosystem surrounding the AES, take part in activities within the AES such as trading, onboard partners, develop technological integrations, refer others, take part in a multi-level marketing system, and perform work in gig economies, as examples. Guild owners can be responsible for the contributions to LCs or Liquidity Seas, and for recruiting members. Guilds can be set up so that guild owners define how much revenue, if any, is shared with members. Guilds that perform better on tasks, have more member contributions to activities, or are more active in growing the system, or perform better in other types of measures, can receive higher amounts of revenues. This can be implemented through analyzing assets collected in activities, whether fungible or non-fungible, orcan be tracked off-chain. A base revenue sharing level can be determined, and guilds that perform well can get an increased percentage while guilds that do not perform well can get a decreased percentage. The base revenue sharing can be determined based on a guild’s asset contributions, such as an SDA asset contribution into a Liquidity Sea, for example.

[0077] Fees can vary based on the particular use of LCs. Fees can be less or even zero, for example, for transactions that are used for balancing. Revenue generation can be higher during times of volatility or when a token is thinly traded and does not have much liquidity. An LC that manages an immediate payment can incur a higher fee from a user because of the need for immediacy and the convenience of having that immediacy. Fees for immediate exchanges can vary based on the state of the system. An LC that uses a K value can charge larger fees with respect to one token versus the other if one of the tokens has a larger amount than started and that LC has not yet been balanced back to a desired state. Those fees can be innate in the K value calculation, or they can be separate fees based on some measure of desired balance in the LC. There can also be slippage when combining different transactions.

[0078] Revenue can be shared with organizations that manage different aspects of the AES, such as the owners of the LCs, the owners of SPVs that invest in LC assets, the owners of the company that manages SPVs, the owners of the DAE, owners of the PCS, owners of the AMMS, or participants in any of these organizations or systems, as examples.

[0079] Lending

[0080] In the AES, lending functionality is envisioned. In traditional lending, a lender loans money and a borrower pays the loan back plus interest. There is often collateral that the borrower uses to obtain the loan and if the borrower defaults on the loan the lender has rights to the collateral.

[0081] Digital assets provide for similar mechanisms, but with the benefits of utilizing digital representations of the assets. The mechanics of lending can be automated through smart contracts, or can be implemented through off-chain systems that tie in to the blockchain through transactions. On the DevvX blockchain, low level processing and low level primitive representations of assets and activities allow validator level approval of core concepts. The DevvX blockchain uses a concept called Monads to implement these low level approaches. Monads are programmed capabilities for validators on the blockchain. Monads are used in contrast to Turing complete on-chain smart contract systems such as the implementation of smart contracts on the Ethereum blockchain.Monads do not innately need gas and the programming for the Monad activities is implemented directly with the Validators rather than interpreted by the Validators by code written in a separate smart contract. Because Monads are operated directly by Validators, they are limited in their functionality by users compared to a Turing complete smart contract system, as the functionality has to be directly programmed into the Validator’s actions outside of user control or definition, but Monads allow for lower level processing of specific types of functionalities that the blockchain uses. Monads can be used, for example, for loss protection on a blockchain where a user loses a private key, for theft protections with lockups on assets, for lending systems, for on-chain wills, or other blockchain based applications including those primarily used for automation and protection. Smart contract systems like Ethereum’s cannot be used in this way. Monads can utilize NFTs forimplementing systems, and those NFTs can be made to have special characteristics, such as their inability to be deleted or moved from a wallet.

[0082] Lending can be implemented with Monads to automate important aspects of the lending process and algorithms. For example, an NFT definition of a loan can be created when a lender approves the loan. Approval of loans itself can be automated based on rules. When a lender has approved a loan and a user has accepted the terms on a loan, an NFT can define the rules around which the loan is implemented and managed. The NFT can include the loan terms such as interest rate, collateral definition, payment frequency, grace periods, penalties, and event of default, as examples. Loans can be implemented by lenders allowed to operate on the system. Loans can be made on any type of digital asset. After a loan definition is created, the loan amount can be transferred to the borrower in the form of a digital asset, such as a stablecoin. The borrower can make payments on the loan through accepted transfers of assets, such as with stablecoins. Loan payments can include fees and interest. A Loan Management System (LMS) can verify that payments on the loan are made on time. The loan NFT definition can include flexibility on late payments, such as the timeframes and total numbers of late payments that are allowable, if any, for example. In the event that a loan payment is late and the loan is therefore in default, the collateral can be transferred automatically by the LMS. The LMS can be granted this capability by interactions with Monads that are verified by the blockchain’s validators, where the validators interpret the rules of the loan based on the loan NFT. Loans can be defined offchain as well through oracles rather than through NFTs or through other on-chain mechanisms in which data is stored on-chain. Collateral on a loan can also be stored in an escrow account, controlled by the lender or controlled by the LMS, depending on the business relationship and business requirements between the lender and the borrower. If a borrower sends an asset to an escrow account, depending on the legal jurisdiction in which this activity is done, that transfer can create a tax event. The use of locking up collateral assets in a user’s account, and having the LMS transfer the assets only in the case of a default can be used to avoid unwanted tax ramifications. Transfers upon default, can be initiated by an automated system or by the lender attempting to collect collateral once those rights are obtained, as examples.

[0083] An example embodiment of the present invention includes theft protections where an NFT can be used to define lock up period for assets in a wallet. Transfers on those assets can be defined so that any transfers have a time delay before they are effective. For example, a user can create a 30 day hold on all of the assets in a wallet. Any transfer of those assets can then be forced to be implemented, at the Monad level, such that the delay in receipt allows for prevention of theft. If theft is detected, then the original send can prevent the completion of the transfer. Assets transfers can be implemented such that an asset doesn’t leave a user’s wallet until the time period elapses, an asset is in the process of being transferred until the time period elapses, an escrow system is used and the asset is held in an escrow wallet until the time period has elapsed, or assets are transferred but held in a recipient’s wallet until the time period elapses, as examples. Different approaches can have different benefits with respect to tax law, for example. An NFT can be defined such that the theft protections and time delays are required, where that NFT can be prevented from beingremoved from that wallet. One challenge with a theft protection implementation like this, however, is that a recipient does not actually receive assets until a lock up period has expired. Therefore, the owner does not have access to use the assets for payment until the lock up period has expired. There can be situations where a user desires to access assets, such as an urgent financial situation that comes up. In this situation a lender can lend against the protected assets, using the protected assets as collateral. An NFT can be implemented that defines the terms of the loan between the lender and borrower as described herein. In this situation, two separate NFTs create conditions and requirements on the use of assets. NFTs can be defined such that one NFT has priority over another in the case that there are conflicts, or they can be designed such that they work well together.Definitions of activities and rules can be held in other types of chain state than NFTs as well. In the case of a lending NFT and a loss protection NFT in the same wallet, the two definitions can be made to work together without conflicts. The loss protection NFT creates a delay in a transfer. The lending NFT creates rules about a loan and the use of the assets related to that loan. In the case of a default on the loan, the lender would receive the collateral, but that collateral would be delayed given the loss protection NFT. The lender would know that fact before providing the loan, and could increase an interest rate, for example, or simply be willing to lend against the protected assets anyhow given that the delay is not material to the lender in providing the loan.

[0084] When an asset is transferred to an LC or to a Liquidity Sea, those assets can be locked up depending on the terms of that allocation. Lending can be combined with AES asset contributions so that while the asset is locked up, the owner can still utilize the underlying value of the assets through loans. For example, if a user contributes an SDA into a Liquidity Sea, and in doing so locks the asset up for a time period, a loan can be implemented where the assets that were contributed are used as collateral in the loan. In the case of a default on loan payments by the user, the assets can be defined to be then owned by the lender even if they are locked in the Liquidity Sea. In that case, the lender can withdraw the assets itself directly from the Liquidity Sea when the lockup period is over. A similar implementation can utilize a bailment token representing the right to withdraw the contributed tokens after a lockup period has ended, and the bailment tokens themselves can be used as collateral for a loan. In that case, the system can be defined where the user cannot use the bailment token to withdraw the funds from the Liquidity Sea while the bailment token is still being used as collateral.

[0085] Another similar implementation of combining asset contributions to the AES with loans can be implemented using UTs, Monads, and a Liquidity Ocean. In this implementation a user can indicate that they want to contribute an SDA, for example, into a Liquidity Sea. In doing so, their SDA assets can be locked so that they cannot be transferred. This locking state is implemented through the Monad definition of a contribution action and is verified directly by validators using the contribution action definitions. The contribution action can be defined by an NFT, for example, stored in the user’s wallet. The contribution action can lock the SDA in the user's wallet rather than making a transfer. This can be valuable when operating within specific tax requirements in a legal jurisdiction. When the SDA assets are locked, an equal amount of UT SDA assets can be released by a Liquidity Ocean into a Liquidity Sea, where the assets are then used as part of an AES withinthe Liquidity Sea and within LCs as needed. Algorithms can determine transfers of the SDA into LCs from the Liquidity Sea. The contribution NFT can be used to determine shared revenue in the AES through the use of the SDA assets that were locked, or a separate token can be issued to the user when the SDA assets are locked and that separate token can be used to track revenue sharing or other needs in the implementation. Then, in this example implementation, a user can obtain a loan utilizing the locked SDA assets. A loan definition can be created, a lender can verify the loan manually or in an automated fashion and an NFT can be delivered that defines the loan properties. The lending system can be determined so that a contribution NFT and a lending NFT can be correlated and used together. The lending NFT can define payments the user needs to make. So long as the payments are made on time, the loan never goes into default, and the user can unlock the tokens once the loan is satisfied and the contribution requirements are satisfied. As another example of how the loan implementation and the contribution implementation can be correlated so that the SDA assets can be removed from the Liquidity Sea, in which case SDA assets are moved from the Liquidity Sea back into the Liquidity Ocean, but those assets remain locked an unable to be transferred given that the loan requirements are still in place. As another example of how the loan implementation and the contribution implementation can be correlated, if the user defaults on the loan, then the assets, which were collateral, can be transferred to the lender. This can be implemented in the NFT definitions or by an LMS transfer of bailment tokens if those were used. After a lender takes control of assets that were collateral, the lender can be required to comply with the contribution rules that were used at the time of contribution. The lender can be required to leave the assets until the contribution lockup has expired, for example. The lender will know the requirements for the contribution before providing a loan, and the lender can adjust terms, such as a higher interest rate, to accommodate the additional timing risk.

[0086] SDA Utility

[0087] Because SDA assets are shared across collections of LCs, they can hold specific utility in the AES. SDAs provide for immediate exchanges between PDAs and SDAs. Because they are included in multiple LCs the use of multiple transactions can be used to convert any PDA in an SDA collection with any other PDA. If a user’s activity or the PCS or other allowed interaction with the LCs, requires an exchange of Token 1 to Token 2, then three transactions can be used to implement that exchange. A transfer of Token 1 from the user into the Token 1 / SDA LC provides for value in the form of the SDA which can then be transferred to the Token 2 / SDAthus creating value in the form of Token 2, which can then be transferred to the recipient of the exchange. When combined with CTS these transactions allow for the exchange of any asset for any other asset with no settlement risk on any of the intermediary transactions. The SDA can be thought of as the money of money or the currency of currency among the other PDAs in a collection as it becomes the intermediary allowing for the exchanges between the PDAs.

[0088] Further, an SDA can be used to pay fees in the AES. For example, the system can require that users own an amount of the SDA greater than a given fee in order for a transaction to go through, and the fee can be automatically sent as part of the approval of a transaction. The SDA can be used for user fees in using the exchange, using immediate exchanges, using the AES forpayment functionality, using the AES for transfers including an exchange of different currencies as needed for remittance, as examples.

[0089] SDAs can be allowed to have specialized capabilities in the AES. For example, the contribution of SDAs can be associated with particular revenue streams in the AES, such as immediate exchange fees, DAE fees, and market making activities by the AMMS. SDAs can have abilities for lending that PDAs do not. For example, SDAs can be defined such that lending combined with contributions to LCs is only available for SDAs. SDAs can be defined such that they are the only tokens available to be used with Liquidity Seas or Liquidity Oceans. These categories of use for SDAs can drive additional value given the provided utility.

Claims

ClaimsWe claim:

1. An asset exchange system, comprising a plurality of Liquidity Caches, where each Liquidity Cache has at least one digital asset type in common with at least one other Liquidity Cache.

2. The asset exchange system of claim 1 , configured to provide a lending system, wherein a collateral asset is held in a borrower’s digital wallet but locked from transfer except to the asset exchange system, and where, upon occurrence of a predefined event the collateral asset is automatically transferred out of the borrower’s wallet into the asset exchange system, then converted using one or more Liquidity Caches in the asset exchange system to a converted asset having a digital asset form desired by a lender, then the converted asset transferred to the lender’s wallet.

3. The asset exchange system of claim 2, wherein the predefined event is an event of default on the loan.

4. The asset exchange system of claim 1 , wherein each Liquidity Cache has at least one digital asset type that is common to all the plurality of Liquidity Caches.

5. The asset exchange system of claim 1 , further comprising a means for transferring assets to and from traditional market making exchanges, wherein the plurality of Liquidity Pools are configured to automatically balance assets used in the traditional market making exchanges.

6. The asset exchange system of claim 1 , wherein exchanges within the Liquidity Pools comprise contingent transaction sets.

Images