Systems, methods, and program products for modifying the supply, depositing, holding and/or distributing collateral as a stable value token in the form of digital assets (2024)

This application is a continuation in part of U.S. patent application Ser. No. 16/421,975, filed on May 24, 2019 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR MODIFYING A SUPPLY OF STABLE VALUE DIGITAL ASSET TOKENS which in turn is a continuation of U.S. patent application Ser. No. 16/293,531, filed on Mar. 5, 2019 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR MODIFYING A SUPPLY OF STABLE VALUE DIGITAL ASSET TOKENS which claims the benefit of and priority to each of U.S. Provisional Application No. 62/638,679, filed on Mar. 5, 2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS; U.S. Provisional Application No. 62/647,353, filed on Mar. 23, 2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS; U.S. Provisional Application No. 62/660,655, filed on Apr. 20, 2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS; U.S. Provisional Application No. 62/683,412, filed on Jun. 11, 2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS; U.S. Provisional Application No. 62/689,563, filed on Jun. 25, 2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS; U.S. Provisional Application Ser. No. 62/764,977, filed on Aug. 17, 2018 and entitled SYSTEM, METHOD, AND PROGRAM PRODUCT FOR MODIFYING A SUPPLY OF STABLE VALUE DIGITAL ASSET TOKENS; U.S. Provisional Patent Application Ser. No. 62/721,983, filed on Aug. 23, 2018 and entitled SYSTEM, METHOD, AND PROGRAM PRODUCT FOR MODIFYING A SUPPLY OF STABLE VALUE DIGITAL ASSET TOKENS; and U.S. Provisional Patent Application Ser. No. 62/728,441, filed on Sep. 7, 2018 and entitled SYSTEM, METHOD, AND PROGRAM PRODUCT FOR MODIFYING A SUPPLY OF STABLE VALUE DIGITAL ASSET TOKENS, the entire content of each of which is hereby incorporated by reference herein.

This application is also a continuation in part of U.S. patent application Ser. No. 16/452,187, filed on Jun. 25, 2019 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR MAKING PAYMENTS USING FIAT BACKED DIGITAL ASSETS, which claims the benefit of and priority to each of U.S. Provisional Application No. 62/689,563, filed on Jun. 25, 2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS; U.S. Provisional Application Ser. No. 62/764,977, filed on Aug. 17, 2018 and entitled SYSTEM, METHOD, AND PROGRAM PRODUCT FOR MODIFYING A SUPPLY OF STABLE VALUE DIGITAL ASSET TOKENS; U.S. Provisional Patent Application Ser. No. 62/721,983, filed on Aug. 23, 2018 and entitled SYSTEM, METHOD, AND PROGRAM PRODUCT FOR MODIFYING A SUPPLY OF STABLE VALUE DIGITAL ASSET TOKENS; and U.S. Provisional Patent Application Ser. No. 62/728,441, filed on Sep. 7, 2018 and entitled SYSTEM, METHOD, AND PROGRAM PRODUCT FOR MODIFYING A SUPPLY OF STABLE VALUE DIGITAL ASSET TOKENS, the entire content of each of which is hereby incorporated by reference herein.

U.S. patent application Ser. No. 16/452,187 is a continuation-in-part of U.S. patent application Ser. No. 16/437,841, filed on Jun. 11, 2019 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS, which is a continuation in part of U.S. patent application Ser. No. 16/421,975, filed on May 24, 2019 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR MODIFYING A SUPPLY OF STABLE VALUE DIGITAL ASSET TOKENS, which is a continuation of U.S. patent application Ser. No. 16/293,531, filed on Mar. 5, 2019 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR MODIFYING A SUPPLY OF STABLE VALUE DIGITAL ASSET TOKENS which claims the benefit of and priority to each of U.S. Provisional Application No. 62/638,679, filed on Mar. 5, 2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS; U.S. Provisional Application No. 62/647,353, filed on Mar. 23, 2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS; U.S. Provisional Application No. 62/660,655, filed on Apr. 20, 2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS; U.S. Provisional Application No. 62/683,412, filed on Jun. 11, 2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS; U.S. Provisional Application No. 62/689,563, filed on Jun. 25, 2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS; U.S. Provisional Application Ser. No. 62/764,977, filed on Aug. 17, 2018 and entitled SYSTEM, METHOD, AND PROGRAM PRODUCT FOR MODIFYING A SUPPLY OF STABLE VALUE DIGITAL ASSET TOKENS; U.S. Provisional Patent Application Ser. No. 62/721,983, filed on Aug. 23, 2018 and entitled SYSTEM, METHOD, AND PROGRAM PRODUCT FOR MODIFYING A SUPPLY OF STABLE VALUE DIGITAL ASSET TOKENS; and U.S. Provisional Patent Application Ser. No. 62/728,441, filed on Sep. 7, 2018 and entitled SYSTEM, METHOD, AND PROGRAM PRODUCT FOR MODIFYING A SUPPLY OF STABLE VALUE DIGITAL ASSET TOKENS, the entire content of each of which is hereby incorporated by reference herein.

U.S. patent application Ser. No. 16/293,531, filed on Mar. 5, 2019 and entitled “SYSTEM, METHOD AND PROGRAM PRODUCT FOR MODIFYING A SUPPLY OF STABLE VALUE DIGITAL ASSET TOKENS” also claims priority as a continuation-in-part to U.S. patent application Ser. No. 16/036,469, filed on Jul. 16, 2018 and entitled “SYSTEM, METHOD, AND PROGRAM PRODUCT FOR DEPOSITING AND WITHDRAWING STABLE VALUE DIGITAL ASSETS IN EXCHANGE FOR FIAT”, which in turn is a continuation-in-part of U.S. patent application Ser. No. 16/020,534, filed on Jun. 27, 2018 and entitled “SYSTEM, METHOD, AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS”, which in turn is a continuation-in-part of U.S. patent application Ser. No. 15/960,040, filed on Apr. 23, 2018 and entitled “SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS,” which claims priority to and the benefit of each of U.S. Provisional Patent Application No. 62/660,655, filed on Apr. 20, 2018 and entitled “SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS,” U.S. Provisional Patent Application No. 62/647,353, filed on Mar. 23, 2018 and entitled “SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS,” and U.S. Provisional Patent Application No. 62/638,679, filed on Mar. 5, 2018 and entitled “SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS,” the entire content of each of which is hereby incorporated by reference herein.

U.S. patent application Ser. No. 16/036,469 also claims the benefit of and priority to each of U.S. Provisional Patent Application Ser. No. 62/689,563, filed on Jun. 25, 2018 and entitled “SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS” and U.S. Provisional Patent Application No. 62/683,412, filed Jun. 11, 2018 and entitled “SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS”, the entire content of each of which is hereby incorporated by reference herein.

U.S. patent application Ser. No. 16/293,531, filed on Mar. 5, 2019 and entitled “SYSTEM, METHOD AND PROGRAM PRODUCT FOR MODIFYING A SUPPLY OF STABLE VALUE DIGITAL ASSET TOKENS” also claims priority as a continuation-in-part to U.S. patent application Ser. No. 16/282,955, filed on Feb. 22, 2019 and entitled “SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR DEPOSITING, HOLDING, AND/OR DISTRIBUTING COLLATERAL AS A TOKEN IN THE FORM OF DIGITAL ASSETS ON AN UNDERLYING BLOCKCHAIN” which in turn is a continuation-in-part to U.S. Non-Provisional patent application Ser. No. 16/280,788, filed Feb. 20, 2019 and entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR LOANING DIGITAL ASSETS AND FOR DEPOSITING, HOLDING AND/OR DISTRIBUTING COLLATERAL AS A TOKEN IN THE FORM OF DIGITAL ASSETS ON AN UNDERLYING BLOCKCHAIN, which in turn claims priority to U.S. Provisional Application Ser. No. 62/684,023 filed on Jun. 12, 2018 and entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR LOANING DIGITAL ASSETS; U.S. Provisional Application No. 62/680,775, filed on Jun. 5, 2018 and entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR LOANING DIGITAL ASSETS; U.S. Provisional Application No. 62/702,265, filed on Jul. 23, 2018 and entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR LOANING DIGITAL ASSETS AND FOR DEPOSITING, HOLDING, AND/OR DISTRIBUTING COLLATERAL AS A TOKEN ON AN UNDERLYING BLOCKCHAIN; U.S. Provisional Patent Application Ser. No. 62/764,978, filed on Aug. 17, 2018 and entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR GENERATING USER DEFINED SMART CONTRACTS AND DEPOSITING, HOLDING AND/OR DISTRIBUTING COLLATERAL AS A TOKEN IN THE FORM OF DIGITAL ASSETS ON AN UNDERLYING BLOCKCHAIN; and U.S. Provisional Patent Application Ser. No. 62/732,347, filed on Sep. 17, 2018 and entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR GENERATING USER DEFINED SMART CONTRACTS AND DEPOSITING, HOLDING AND/OR DISTRIBUTING COLLATERAL AS A TOKEN IN THE FORM OF DIGITAL ASSETS ON AN UNDERLYING BLOCKCHAIN, the entire content of each of each of which is hereby incorporated by reference herein.

U.S. Non-Provisional patent application Ser. No. 16/280,788 also claims priority as a continuation-in-part to U.S. Non-Provisional patent application Ser. No. 15/973,140, filed on May 7, 2018 and entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR EXCHANGING DIGITAL ASSETS FOR FIAT AND/OR OTHER DIGITAL ASSETS, which in turn claims priority to U.S. Provisional Patent Application Ser. No. 62/660,655, filed on Apr. 20, 2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS, U.S. Provisional Patent Application Ser. No. 62/642,946, filed on Mar. 14, 2018 and entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR EXCHANGING DIGITAL ASSETS FOR FIAT AND/OR OTHER DIGITAL ASSETS, U.S. Provisional Patent Application Ser. No. 62/642,931, filed on Mar. 14, 2018 and entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR EXCHANGING DIGITAL ASSETS FOR FIAT AND/OR OTHER DIGITAL ASSETS, and U.S. Provisional Patent Application Ser. No. 62/629,417, filed on Feb. 12, 2018 and entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR VERIFYING DIGITAL ASSETS HELD IN A CUSTODIAL DIGITAL ASSET WALLET, the entire content of each of which is hereby incorporated by reference herein. U.S. Non-Provisional patent application Ser. No. 16/280,788 also claims priority as a continuation-in-part to U.S. Non-Provisional patent application Ser. No. 15/960,040, filed on Apr. 23, 2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS, which in turn claims priority to U.S. Provisional Patent Application Ser. No. 62/660,655, filed on Apr. 20, 2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS, and U.S. Provisional Patent Application Ser. No. 62/647,353, filed on Mar. 23, 2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS and U.S. Provisional Patent Application Ser. No. 62/638,679, filed on Mar. 5, 2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS, the entire content of each of which is hereby incorporated by reference herein. U.S. Non-Provisional patent application Ser. No. 16/280,788 also claims priority as a continuation-in-part to U.S. Non-Provisional patent application Ser. No. 15/973,175, filed on May 7, 2018 and entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR EXCHANGING DIGITAL ASSETS FOR FIAT AND/OR OTHER DIGITAL ASSETS, which in turn claims priority to U.S. Provisional Patent Application No. 62/642,946, filed on Mar. 14, 2018 and entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR EXCHANGING DIGITAL ASSETS FOR FIAT AND/OR OTHER DIGITAL ASSETS, and U.S. Provisional Patent Application No. 62/642,931 filed on Mar. 14, 2018 and entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR EXCHANGING DIGITAL ASSETS FOR FIAT AND/OR OTHER DIGITAL ASSETS, and U.S. Provisional Patent Application Ser. No. 62/629,417, filed Feb. 12, 2018 entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR VERIFYING DIGITAL ASSETS HELD IN A CUSTODIAL DIGITAL ASSET WALLET, and U.S. Provisional Patent Application Ser. No. 62/660,655 filed on Apr. 20, 2018 and entitled SYSTEMS, METHODS, and PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS, the entire content of each of which is hereby incorporated by reference herein. U.S. Non-Provisional patent application Ser. No. 16/280,788 also claims priority as a continuation-in-part to U.S. Non-Provisional patent application Ser. No. 15/920,042, filed on Mar. 13, 2018 and entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR VERIFYING DIGITAL ASSETS HELD IN A CUSTODIAL DIGITAL ASSET WALLET, which in turn claims priority to U.S. Provisional Patent Application No. 62/629,417 filed Feb. 12, 2018 entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR VERIFYING DIGITAL ASSETS HELD IN A CUSTODIAL DIGITAL ASSET WALLET, the entire content of each of which is hereby incorporated by reference herein.

This application claims the benefit of and priority to each of U.S. Provisional Application No. 62/867,091, filed on Jun. 26, 2019 and entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR DEPOSITING, HOLDING AND/OR DISTRIBUTING COLLATERAL AS A TOKEN IN THE FORM OF DIGITAL ASSETS ON AN UNDERLYING BLOCKCHAIN; U.S. Provisional Application No. 62/732,347, filed on Sep. 17, 2018 and entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR GENERATING USER DEFINED SMART CONTRACTS AND DEPOSITING, HOLDING AND/OR DISTRIBUTING COLLATERAL AS A TOKEN IN THE FORM OF DIGITAL ASSETS ON AN UNDERLYING BLOCKCHAIN; U.S. Provisional Application No. 62/728,441, filed on Sep. 7, 2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR MODIFYING A SUPPLY OF STABLE VALUE DIGITAL ASSET TOKENS; U.S. Provisional Patent Application No. 62/721,983, filed on Aug. 23, 2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR MODIFYING A SUPPLY OF STABLE VALUE DIGITAL ASSET TOKENS; U.S. Provisional Patent Application No. 62/764,978, filed on Aug. 17, 2018 and entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR GENERATING USER DEFINED SMART CONTRACTS AND DEPOSITING, HOLDING AND/OR DISTRIBUTING COLLATERAL AS A TOKEN IN THE FORM OF DIGITAL ASSETS ON AN UNDERLYING BLOCKCHAIN; U.S. Provisional Patent Application No. 62/764,977, filed on Aug. 17, 2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR MODIFYING A SUPPLY OF STABLE VALUE DIGITAL ASSET TOKENS; and U.S. Provisional Patent Application No. 62/702,265, filed on Jul. 23, 2018 and entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR LOANING DIGITAL ASSETS AND FOR DEPOSITING, HOLDING AND/OR DISTRIBUTING COLLATERAL AS A TOKEN IN THE FORM OF DIGITAL ASSETS ON AN UNDERLYING BLOCKCHAIN, the entire content of each of which is hereby incorporated by reference herein.

The present invention also relates to a method, system, and program product for generating user defined smart contracts and depositing, holding and/or distributing collateral in the form of a stable value token for a security token based on the user defined smart contracts, the tokens being on the same underlying blockchain.

There is no technological solution for generating user defined smart contracts and depositing, holding, and/or distributing collateral in the form of a stable value token for a security token based on the user defined smart contract, the tokens being on the same underlying blockchain.

Traditionally, capital markets work by channeling savings typically held in banks into investments in exchange for interest on the use of such capital over a defined period of time in exchange for a defined interest rates. With government backed currencies (or fiat) like the U.S. dollar, central authorities, like the Federal Reserve in the U.S. for U.S. Dollars, are involved in established bench mark rates at which banks may lend or borrow funds. These rates may vary on the length of time at which such funds are to be lent or borrowed.

With the advent of digital assets and crypto-currencies, traditional banks are no longer involved with storage of such digital assets. Thus, in the new paradigm, digital assets are stored by holders in digital wallets are tracked and maintained on a peer-to-peer blockchain, with no central authority or bank involved. As a result, once value is stored in a digital asset, that value is taken out of the economy and remains idle. In other words, it is no longer available to loan or invest, and/or earn interest, while it is being securely stored in a digital wallet.

Thus, digital assets and the new blockchain technology create a technological challenge of how to continue to take advantage of the security and independence offered by peer-to-peer blockchain technologies, but still allow stored value in digital asset wallets to be invested so as to earn interest and support investment through capital markets.

Another technical problem arises in that current blockchain technology does not provide for a mechanism to deposit, hold and/or distribute collateral in the form of stable value digital assets for a security token based on a user defined smart contract, on the same underlying blockchain.

An object of the present invention is to address technological challenges that currently exist in providing user defined smart contracts based on user provided contract parameters on underlying blockchains as well as depositing, holding and/or distributing collateral in the form of a stable value token for a security token based on the user defined smart contract, the tokens being on the same underlying blockchain.

This and other objects shall be addressed by embodiments of the present invention as set forth herein.

The present invention relates to methods, systems, and program products for providing user defined smart contract parameters on underlying blockchains.

Systems, methods, and program products for use with custodial electronics wallets for ETPs holding digital assets, including digital math-based assets, such as Bitcoin, Ethereum, Ripple, Cardano, Litecoin, NEO, Stellar, IOTA, NEM, Dash, Monero, Lisk, Qtum, Zcash, Nano, Steem, Bytecoin, Verge, Siacoin, Stratis, BitShares, Dogecoin, Waves, Decred, Ardor, Hshare, Komodo, Electroneum, Ark, DigiByte, E-coin, ZClassic, Byteball Bytes, PIVX, Cryptonex, GXShares, Syscoin, Bitcore, Factom, MonaCoin, ZCoin, SmartCash, Particl, Nxt, ReddCoin, Emercoin, Experience Points, Neblio, Nexus, Blocknet, GameCredits, DigitalNote, Vertcoin, BitcoinDark, Bitcoin Cash, Skycoin, ZenCash, NAV Coin, Achain, HTMLCOIN, Ubiq, BridgeCoin, Peercoin, PACcoin, XTRABYTES, Einsteinium, Asch, Counterparty, BitBay, Viacoin, Rise, Guiden, ION, Metaverse ETP, LBRY Credits, Crown, Electra, Burst, MinexCoin, Aeon, SaluS, DECENT, CloakCoin, Pura, ECC, DeepOnion, Groesticoin, Lykke, Steem Dollars, I/O Coin, Shift, HempCoin, Mooncoin, Dimecoin, Namecoin, Feathercoin, Diamond, Spectrecoin, Filecoin, Tezos, PPCoin, Tonal bitcoin, IxCoin, Devcoin, Freicoin, I0coin, Terracoin, Liquidcoin, BBQcoin, BitBars, Gas, Tether, Ether Classic and PhenixCoin to name a few, and other financial products or services based on the same, are disclosed.

In embodiments, prior to implementing the first trade instructions, the method further comprises: (k) sending, by the administrator system via the blockchain for the underlying digital asset, a second message comprising requests for the first smart contract to: (i) recalculate the second collateral amount based on the at least one collateral requirement and current benchmark information; (l) determining, by the first smart contract, a second additional collateral amount based on a difference between the recalculated second collateral amount and the second collateral amount; and (m) receiving, at the first smart contract address, the second additional collateral amount. In embodiments the second collateral amount is recalculated by the first user device. In embodiments, the administrator system sends the second message in response to receiving a request from the first user device. In embodiments, prior to implementing the first trade instructions, the method further comprises: (k) monitoring, by the administrator system, the second contract address on the blockchain associated with the underlying digital asset; (l) determining, by the administrator system, the second additional collateral amount is not received by the first smart contract address; (m) generating, by the administrator system, a notification indicating that the second additional collateral amount is not received by the first smart contract address; (n) sending, by the administrator system, the notification to the first user device, the second user device and the first smart contract address; (o) generating, by the administrator system, a third message including a request to transfer the first collateral amount, the second collateral amount, and the third collateral amount in accordance with the first trade instructions; and (p) sending, by the administrator system, the third message to the first smart contract address from the administrator public address via the blockchain, wherein, upon receipt of the third message, the first smart contract address transfers the first collateral amount, the second collateral amount, and the third collateral amount in accordance with the first trade instructions.

In embodiments, the first contract information further comprises at least one of the following: (H) derivative type information; (I) early termination rules; (J) a second benchmark; (K) asset identification information; (L) pricing model information; and (M) volatility information.

In embodiments, prior to step (a), the method further comprises: (k) generating, by the administrator system, machine readable instructions comprising graphical user interface information including a graphical user interface with at least one prompt for the first user to provide the contract proposal; (l) sending, by the administrator system to the first user device, the machine readable instructions such that, upon receipt of the machine readable instructions, the first user device displays the graphical user interface; and (m) receiving, from the first user device in response to the at least one prompt, the contract proposal.

In embodiments, the first smart contract is associated with a security token.

In embodiments, a third smart contract comprises the first smart contract and the stable value token smart contract.

In embodiments, a method comprises (a) receiving, from a first user device associated with a first user by an administrator system associated with an administrator of a digital asset database, a first contract proposal, wherein the first contract proposal includes: (i) first user information associated with the first user; and (ii) first contract information comprising at least the following contract parameters: (A) an inception date; (B) an inception value; (C) at least one benchmark; (D) a contract duration; (E) at least one collateral requirement; (F) a notional value of the smart contract; and (G) first side information comprising identification of a first leg of the first contract proposal, wherein the digital asset database is tied to a distributed public transaction ledger maintained by a plurality of geographically distributed computer systems in a peer-to-peer network; and wherein the administrator system is associated with an administrator public address associated with the peer-to-peer network; (b) receiving, by the administrator system from a second user device associated with a second user, at least one indication of interest, wherein the at least one indication of interest includes at least: (i) a first user response comprising: (1) second user information associated with the second user; and (2) second side information comprising a second leg of the contract proposal; (c) matching, by the administrator system, the first contract information and the second side information; (d) generating a first module on the peer-to-peer network associated with a fiat-backed digital asset, wherein the module comprises first contract instructions associated with a first module address associated with the peer-to-peer network, wherein the smart contract instructions are saved in the peer-to-peer network and include: (i) first authorization instructions regarding creating fiat-backed digital assets; (ii) second authorization instructions regarding transferring fiat-backed digital assets; (iii) third authorization instructions regarding destroying fiat-backed digital assets; (iv) fourth authorization instructions regarding functions associated with the fiat-backed digital asset; (v) first trade instructions including execution instructions to execute a first trade between the first user and the second user, wherein the first trade is based on at least the following: 1. the first contract proposal; and 2. the first user response (vi) fifth authorization instructions regarding transferring security tokens; (vii) sixth authorization instructions regarding destroying security tokens; (viii) seventh authorization instructions regarding transferring fiat-backed digital assets from the first smart contract address; (ix) calculating instructions regarding calculating excess collateral; and (x) dispute instructions regarding disputed benchmark information received by the first smart contract address from an oracle; (e) sending, by the administrator system from the administrator public address to the module address via the peer-to-peer network, the first module and associated first contract instructions; (f) receiving, by the first module address, a first amount of collateral, wherein the first amount of collateral is a first amount of fiat-backed digital assets associated with the first user as collateral, and wherein the first amount of fiat-backed digital assets associated with the first user is based on the at least one collateral requirement; (g) receiving, by the first module address, a second amount of collateral, wherein the second amount of collateral is a second amount of fiat-backed digital assets associated with the second user as collateral, wherein the second amount of fiat-backed digital assets associated with the second user is based on the at least one collateral requirement; (h) receiving, by the first module address from an oracle public address associated with the oracle, a third amount of collateral, wherein the third amount of collateral is a third amount of fiat-backed digital assets associated with the oracle as collateral, wherein the third amount of fiat-backed digital assets associated with the oracle is based on the at least one collateral requirement, wherein the oracle public address is associated with the peer-to-peer network; (i) implementing, by the first module, the first trade instructions via the peer-to-peer network by the plurality of geographically distributed computer systems in the peer-to-peer network, wherein implementing comprises the following steps: (i) receiving, by the first module address from the oracle, a first benchmark message including: (1) first current benchmark information associated with the first contract information; (2) a digital signature associated with the oracle; and (3) a first timestamp; (ii) monitoring, by the administrator system, the first module address for a predetermined amount of time; and (iii) after the predetermined amount of time has elapsed, collecting, by the administrator system from the module address, excess collateral from the first trade, wherein the collecting includes steps of: (1) sending, by the administrator system via the peer-to-peer network, a first message comprising requests for the first smart contract to: (A) determine first excess collateral for the first trade in accordance with the first module and the first trade instructions; (B) determine second excess collateral for the first trade in accordance with the first module and the first trade instructions; (C) determine third excess collateral for the first trade in accordance with the first module and first trade instructions; (D) distribute the first excess collateral to a first user public address associated with the first user and associated with the peer-to-peer network; (E) distribute the second excess collateral to a second user public address associated with the second user associated with the peer-to-peer network; and (F) distribute the third excess collateral to the oracle public address.

In embodiments, monitoring the first module address for the predetermined amount of time further comprises: (1) receiving, by the first module address, a first dispute message disputing the first current benchmark information, wherein the first dispute message comprises: (A) the first digitally signed benchmark message; and (B) a second digitally signed benchmark message, wherein the second digitally signed benchmark message is digitally signed by the oracle and comprises: i. second current benchmark information; and ii. a second timestamp; (2) comparing, by the first module, the first digitally signed benchmark message to the second digitally signed benchmark message to determine: i. a first difference between the first current benchmark information and the second current benchmark information; and ii. a second difference between the first timestamp and the second time stamp; (3) in the case where the first difference is above a first predetermined threshold and the second difference is below a second predetermined threshold, performing the steps of: (A) sending, by the administrator system via the peer-to-peer network, a second message comprising requests for the first module to: (i) recalculate, based on the dispute instructions, the first amount of collateral; (ii) recalculate, based on the dispute instructions, the second amount of collateral; (iii) recalculate, based on the dispute instructions, the third amount of collateral; (iv) determine first excess collateral for the first trade in accordance with the first module and the first trade instructions; (v) determine second excess collateral for the first trade in accordance with the first module and the first trade instructions; (vi) determine third excess collateral for the first trade in accordance with the first module and first trade instructions; (vii) distribute the first excess collateral for the first trade in accordance with the first module and the first trade instructions to the first user public address; (viii) distribute the second excess collateral for the first trade in accordance with the first module and the first trade instructions to the second user public address; and (ix) distribute the third excess collateral for the first trade in accordance with the first module and the first trades instructions to the oracle public address; (1) in the case where the first difference is above the first predetermined threshold and the second difference is above the second predetermined threshold, implementing, by the first module, the first trade instructions via the peer-to-peer network; and (2) in the case where the first difference is below the first predetermined threshold, implementing, by the first module, the first trade instructions via the peer-to-peer network. In embodiments, the first dispute message is received by the first module address from the first user public address. In embodiments, the first excess collateral comprises the third amount of collateral, and wherein the third excess collateral is zero. In embodiments, the first dispute message is received by the first module address from the second user public address. In embodiments, the second excess collateral comprises the third amount of collateral, and wherein the third excess collateral is zero. In embodiments, the first dispute message is received by the first module address from at least one of the following: (1) the first user public address; (2) the second user public address; and (3) the administrator public address. In embodiments, the first excess collateral comprises a first half of the third amount of collateral, wherein the second excess collateral comprises a second half of the third amount of collateral, and wherein the third excess collateral is zero. In embodiments, the first dispute message is verified by the administrator system. In embodiments, the first dispute message is verified by the first module.

In embodiments, receiving the first digitally signed benchmark message further comprises: (a) sending, from the first module address to the oracle public address, a digitally signed first transaction request; (b) receiving, from the oracle public address by the first module address, the first digitally signed benchmark message; and (c) storing, by the first module, the first digitally signed benchmark message.

In embodiments, the at least one collateral requirement comprises: (1) a user collateral requirement; and (2) an oracle collateral requirement.

In embodiments, the first contract information further comprises the following contract parameter: (H) a trusted oracle selection.

In embodiments, the first time stamp indicates the time at which the first current benchmark data was retrieved by the oracle.

In embodiments, prior to implementing the first trade instructions, the method further comprises: (k) sending, by the administrator system via the peer-to-peer network, a second message comprising requests for the first module to: (i) recalculate the first collateral amount based on the at least one collateral requirement and the first current benchmark information; and (ii) recalculate the second collateral amount based on the at least one collateral requirement and the first current benchmark information; (l) determining, by the first module, a first additional collateral amount based on a difference between the recalculated second collateral amount and the second collateral amount; (m) monitoring, by the administrator system, the first module address on the peer-to-peer network associated with the underlying digital asset; (n) determining, by the administrator system, the first additional collateral amount has not been received by the first contract address; (o) generating, by the administrator system, a default notification indicating that the first additional collateral amount was not received by the second contract address; (p) sending, by the administrator system, the default notification to the first user device, the second user device, and the first module address; (q) generating, by the administrator system, a third message including a request to transfer the first collateral amount and the second collateral amount in accordance with the first contract instructions; and (r) sending, by the administrator system from the administrator public address to the first module address, the third message, wherein, upon receipt of the third message, the first module implements the first trade instructions via the peer-to-peer network by computer systems among the plurality of distributed computer systems in the peer-to-peer network.

In embodiments, the first trade instructions are implemented as a result of a second message sent by the administrator system from the administrator public address to the first module address via the peer-to-peer network.

In embodiments, the first user information further comprises the first user public address, wherein the first user public address corresponds to a first user private key that is mathematically related to the first user public address, wherein the second user information further comprises the second user public address, and wherein the second user public address corresponds to a second user private key that is mathematically related to the second user public address. In embodiments, the step of receiving the first amount of collateral further comprises sending, by the first user device via the underlying peer-to-peer network from the first user public address, a digitally signed first transaction request including a request to transfer the first amount of collateral from the first user public address to the first module address, wherein the digitally signed first transaction request is digitally signed by the first user private key. In embodiments, the step of receiving the second amount of collateral further comprises sending, by the second user device via the underlying peer-to-peer network from the second user public address, a digitally signed first transaction request including a request to transfer the second amount of collateral from the second user public address to the first module address, wherein the digitally signed first transaction request is digitally signed by the second user private key.

In embodiments, the step of receiving the third amount of collateral further comprises sending, by an electronic device associated with the oracle via the underlying peer-to-peer network from the oracle public address, a digitally signed first transaction request including a request to transfer the third amount of collateral from the oracle public address to the first module address, wherein the oracle public address corresponds to an oracle private key that is mathematically related to the oracle public address, and wherein the digitally signed first transaction request is digitally signed by the oracle private key.

In embodiments, the excess collateral is calculated by at least one of the following: (i) the administrator system; (ii) the first module; (iii) the second smart contract; (iv) the first user device; and (v) the second user device.

In embodiments, prior to implementing the first trade instructions, the method further comprises: (k) sending, by the administrator system via the peer-to-peer network, a second message comprising requests for the first module to: (i) recalculate the second collateral amount based on the at least one collateral requirement and current benchmark information; (l) determining, by the first module, a second additional collateral amount based on a difference between the recalculated second collateral amount and the second collateral amount; and (m) receiving, at the first module address, the second additional collateral amount. In embodiments, the second collateral amount is recalculated by the first user device. In embodiments, the administrator system sends the second message in response to receiving a request from the first user device. In embodiments, prior to implementing the first trade instructions, the method further comprises: (k) monitoring, by the administrator system, the second contract address on the peer-to-peer network associated with the underlying digital asset; (l) determining, by the administrator system, the second additional collateral amount is not received by the first module address; (m) generating, by the administrator system, a notification indicating that the second additional collateral amount is not received by the first module address; (n) sending, by the administrator system, the notification to the first user device, the second user device and the first module address; (o) generating, by the administrator system, a third message including a request to transfer the first collateral amount, the second collateral amount, and the third collateral amount in accordance with the first trade instructions; and (p) sending, by the administrator system, the third message to the first module address from the administrator public address via the peer-to-peer network, wherein, upon receipt of the third message, the first module address transfers the first collateral amount, the second collateral amount, and the third collateral amount in accordance with the first trade instructions.

In embodiments, prior to step (a), the method further comprising: (k) generating, by the administrator system, machine readable instructions comprising graphical user interface information including a graphical user interface with at least one prompt for the first user to provide the contract proposal; (l) sending, by the administrator system to the first user device, the machine readable instructions such that, upon receipt of the machine readable instructions, the first user device displays the graphical user interface; and (m) receiving, from the first user device in response to the at least one prompt, the contract proposal.

In embodiments, the fiat-backed digital assets are pegged to a predetermined ratio associated with one or more types of fiat.

In embodiments, the fiat-backed digital assets are backed by a reserve of fiat maintained on behalf of an issuer of the fiat-backed digital assets.

In embodiments, a method comprises (a) receiving, from a first user device associated with a first user by an administrator system associated with an administrator of a digital asset database, a first contract proposal, wherein the first contract proposal includes: (i) first user information associated with the first user; and (ii) first contract information comprising at least the following contract parameters: (A) an inception date; (B) an inception value; (C) at least one benchmark; (D) a contract duration; (E) at least one collateral requirement; (F) a notional value of the smart contract; and (G) first side information comprising identification of a first leg of the first contract proposal, wherein the digital asset database is tied to a distributed public transaction ledger maintained by a plurality of geographically distributed computer systems in a peer-to-peer network; and wherein the administrator system is associated with an administrator public address associated with the peer-to-peer network; (b) receiving, by the administrator system from a second user device associated with a second user, at least one indication of interest, wherein the at least one indication of interest includes at least: (i) a first user response comprising: (1) second user information associated with the second user; and (2) second side information comprising a second leg of the contract proposal; (c) matching, by the administrator system, the first contract information and the second side information; (d) generating a first module on the peer-to-peer network associated with a fiat-backed digital asset, wherein the module comprises first contract instructions associated with a first module address associated with the peer-to-peer network, wherein the smart contract instructions are saved in the peer-to-peer network and include: (i) first authorization instructions regarding transferring fiat-backed digital assets; (ii) second authorization instructions regarding functions associated with the fiat-backed digital asset; (iii) first trade instructions including execution instructions to execute a first trade between the first user and the second user, wherein the first trade is based on at least the following: 1. the first contract proposal; and 2. the first user response (iv) third authorization instructions regarding transferring security tokens; (v) fourth authorization instructions regarding destroying security tokens; (vi) fifth authorization instructions regarding transferring fiat-backed digital assets from the first smart contract address; (vii) calculating instructions regarding calculating excess collateral; and (viii) dispute instructions regarding disputed benchmark information received by the first smart contract address from an oracle; (e) sending, by the administrator system from the administrator public address to the module address via the peer-to-peer network, the first module and associated first contract instructions; (f) receiving, by the first module address, a first amount of collateral, wherein the first amount of collateral is a first amount of fiat-backed digital assets associated with the first user as collateral, and wherein the first amount of fiat-backed digital assets associated with the first user is based on the at least one collateral requirement; (g) receiving, by the first module address, a second amount of collateral, wherein the second amount of collateral is a second amount of fiat-backed digital assets associated with the second user as collateral, wherein the second amount of fiat-backed digital assets associated with the second user is based on the at least one collateral requirement; (h) receiving, by the first module address from an oracle public address associated with the oracle, a third amount of collateral, wherein the third amount of collateral is a third amount of fiat-backed digital assets associated with the oracle as collateral, wherein the third amount of fiat-backed digital assets associated with the oracle is based on the at least one collateral requirement, wherein the oracle public address is associated with the peer-to-peer network; (i) implementing, by the first module, the first trade instructions via the peer-to-peer network by the plurality of geographically distributed computer systems in the peer-to-peer network, wherein implementing comprises the following steps: (i) receiving, by the first module address from the oracle, a first benchmark message including: (1) first current benchmark information associated with the first contract information; (2) a digital signature associated with the oracle; and (3) a first timestamp; (ii) monitoring, by the administrator system, the first module address for a predetermined amount of time; and (iii) after the predetermined amount of time has elapsed, collecting, by the administrator system from the module address, excess collateral from the first trade, wherein the collecting includes steps of: (1) sending, by the administrator system via the peer-to-peer network, a first message comprising requests for the first smart contract to: (A) determine first excess collateral for the first trade in accordance with the first module and the first trade instructions; (B) determine second excess collateral for the first trade in accordance with the first module and the first trade instructions; (C) determine third excess collateral for the first trade in accordance with the first module and first trade instructions; (D) distribute the first excess collateral to a first user public address associated with the first user and associated with the peer-to-peer network; (E) distribute the second excess collateral to a second user public address associated with the second user associated with the peer-to-peer network; and (F) distribute the third excess collateral to the oracle public address.

In embodiments, the at least one collateral requirement comprises: (1) a user collateral requirement; and (2) an oracle collateral requirement.

In embodiments, the first contract information further comprises the following contract parameter: (H) a trusted oracle selection.

In embodiments, the first time stamp indicates the time at which the first current benchmark data was retrieved by the oracle.

In embodiments, prior to implementing the first trade instructions, the method further comprises: (k) sending, by the administrator system via the peer-to-peer network, a second message comprising requests for the first module to: (i) recalculate the second collateral amount based on the at least one collateral requirement and current benchmark information; (l) determining, by the first module, a second additional collateral amount based on a difference between the recalculated second collateral amount and the second collateral amount; and (m) receiving, at the first module address, the second additional collateral amount. In embodiments, the second collateral amount is recalculated by the first user device. In embodiments, the administrator system sends the second message in response to receiving a request from the first user device. In embodiments, prior to implementing the first trade instructions, the method further comprises: (k) monitoring, by the administrator system, the second contract address on the peer-to-peer network associated with the underlying digital asset; (l) determining, by the administrator system, the second additional collateral amount is not received by the first module address; (m) generating, by the administrator system, a notification indicating that the second additional collateral amount is not received by the first module address; (n) sending, by the administrator system, the notification to the first user device, the second user device and the first module address; (o) generating, by the administrator system, a third message including a request to transfer the first collateral amount, the second collateral amount, and the third collateral amount in accordance with the first trade instructions; and (p) sending, by the administrator system, the third message to the first module address from the administrator public address via the peer-to-peer network, wherein, upon receipt of the third message, the first module address transfers the first collateral amount, the second collateral amount, and the third collateral amount in accordance with the first trade instructions.

In embodiments, the fiat-backed digital assets are pegged to a predetermined ratio associated with one or more types of fiat.

In embodiments, the fiat-backed digital assets are backed by a reserve of fiat maintained on behalf of an issuer of the fiat-backed digital assets.

Exemplary embodiments of the present invention will be described with references to the accompanying figures, wherein:

FIG. 1 is a schematic diagram of a digital asset network in accordance with exemplary embodiments of the present invention;

FIG. 2 is an exemplary screen shot of an excerpt of an exemplary bitcoin transaction log showing addresses in accordance with exemplary embodiments of the present invention;

FIG. 2A is an exemplary screen shot of a Security Token ledger in accordance with exemplary embodiments of the present invention;

FIG. 3 is an exemplary exchange agent interface in accordance with exemplary embodiments of the present invention;

FIGS. 4A-4D are exemplary block diagrams of components of security systems for an ETP holding digital math-based assets in accordance with various exemplary embodiments of the present invention;

FIGS. 5A and 5B are flow charts of exemplary processes for creating and securing digital wallets in accordance with exemplary embodiments of the present invention;

FIGS. 6A-6D are flow charts of exemplary processes for generating digital asset accounts and securely storing the keys corresponding to each account in accordance with exemplary embodiments of the present invention;

FIG. 7 is a flow chart of an exemplary process for retrieving securely stored keys associated with a digital asset account in accordance with exemplary embodiments of the present invention;

FIG. 8 is a flow chart of a method of performing a secure transaction in accordance with exemplary embodiments of the present invention;

FIGS. 9A-9D are schematic diagrams of cold storage vault systems in accordance with exemplary embodiments of the present invention;

FIGS. 10A and 10B are schematic diagrams of vault arrangements for a digital asset network in accordance with exemplary embodiments of the present invention;

FIGS. 11A-11B are flow charts of processes for generating key storage and insurance in accordance with exemplary embodiments of the present invention;

FIGS. 12A-12C are flow charts of processes for recovering key segments in accordance with exemplary embodiments of the present invention;

FIG. 13 is a schematic diagram of the participants in an ETP holding digital math-based assets in accordance with exemplary embodiments of the present invention;

FIG. 14 is a schematic diagram of an exemplary secondary market for shares in the trust in accordance with exemplary embodiments of the present invention;

FIGS. 15A and 15B are schematic diagrams of the accounts associated with a trust in accordance with exemplary embodiments of the present invention;

FIG. 16 is a block diagram of the data and modules in an exemplary embodiment of a trust computer system in accordance with the present invention;

FIGS. 17A and 17B are flow charts of processes for investing in the trust in accordance with exemplary embodiments of the present invention;

FIGS. 18A-18D are flow charts of various exemplary processes for assigning digital math-based assets, such as bitcoin, obtained during a creation and distributing them among digital wallets in accordance with embodiments of the present invention;

FIGS. 19A and 19B are flow charts of processes for redeeming shares in the trust in accordance with exemplary embodiments of the present invention;

FIG. 19C is a flow chart of an exemplary process for redemption of shares in an exchange traded product holding digital math-based assets in accordance with exemplary embodiments of the present invention;

FIG. 20A is a flow chart of processes for calculating the NAV value of shares in a trust holding digital assets in accordance with embodiments of the present invention;

FIG. 20B is a flow chart of processes for calculating the NAV value of shares in a trust holding bitcoin in accordance with embodiments of the present invention;

FIG. 21A is a flow chart of additional processes associated with evaluation day for calculating NAV value of shares in a trust holding digital assets in accordance with embodiments of the present invention;

FIG. 21B is a flow chart of additional processes associated with evaluation day for calculating NAV value of shares in a trust holding bitcoin in accordance with embodiments of the present invention;

FIG. 22 is a flow chart of a process for determining qualified exchanges in accordance with exemplary embodiments of the present invention;

FIGS. 23A-23H are flow charts showing methods for calculating a blended digital asset price in accordance with exemplary embodiments of the present invention;

FIG. 24 is a schematic diagram of participants in a system for providing a digital asset index and a digital asset exchange in accordance with exemplary embodiments of the present invention;

FIGS. 25A and 25B are flow charts of a method for creating an index of digital asset prices in accordance with exemplary embodiments of the present invention;

FIG. 26 is an exemplary exchange agent interface in accordance with exemplary embodiments of the present invention;

FIGS. 27A-B are schematic diagrams illustrating participants in a digital asset exchange in accordance with exemplary embodiments of the present invention;

FIGS. 28A-B are schematic diagrams of exemplary exchange computer systems in accordance with exemplary embodiments of the present invention;

FIG. 28C is an exemplary flow chart for a process for converting from, to or between digital assets in accordance with exemplary embodiments of the present invention;

FIG. 29 is an exemplary flow chart for processes for digital asset exchange account creation and account funding in accordance with exemplary embodiments of the present invention;

FIGS. 30A-B are an exemplary schematic diagram and corresponding flow chart of a process for digital asset exchange customer account fiat funding via an exchange-initiated request in accordance with exemplary embodiments of the present invention;

FIGS. 30C-E are an exemplary schematic diagram and corresponding flow chart of a process for digital asset exchange customer account fiat funding via a customer-initiated request in accordance with exemplary embodiments of the present invention;

FIGS. 31A-B are a schematic diagram and corresponding flow chart of a process for digital asset exchange account digital asset withdrawal in accordance with exemplary embodiments of the present invention;

FIG. 32 is an exemplary schematic diagram of a digital asset exchange transaction system in accordance with exemplary embodiments of the present invention;

FIG. 33 is an exemplary flow chart of operational transaction processes of a digital math-based asset electronic exchange in accordance with exemplary embodiments of the present invention;

FIGS. 35A-L are exemplary screen shots of user interfaces provided by an exchange computer system in accordance with exemplary embodiments of the present invention;

FIGS. 36A-D are exemplary block diagrams of components of security systems for an exchange holding digital math-based assets in accordance with various exemplary embodiments of the present invention;

FIG. 37 is a schematic diagram of participants in a system including a digital asset kiosk and a digital asset exchange in accordance with exemplary embodiments of the present invention;

FIGS. 38A-B are flow charts of processes for determining a money transmit business to process transactions in accordance with exemplary embodiments of the present invention;

FIG. 39 is a schematic diagram of a digital asset kiosk in accordance with exemplary embodiments of the present invention;

FIGS. 40A-Q are schematic diagrams of a digital asset kiosk display showing exemplary interfaces for various transactions and functions involving digital assets in accordance with exemplary embodiments of the present invention;

FIG. 41 is a flow chart of an exemplary process for performing an exchange transaction from an electronic kiosk in accordance with exemplary embodiments of the present invention;

FIGS. 42A-B are a schematic diagram and corresponding flow chart showing participants in and processes for digital asset notifications in accordance with exemplary embodiments of the present invention;

FIGS. 43A-B are exemplary screen shots associated with setting digital asset notification in accordance with exemplary embodiments of the present invention;

FIGS. 44A-C are exemplary screen shots of digital asset notifications in accordance with exemplary embodiments of the present invention;

FIGS. 45A-B are a schematic diagram and corresponding flow chart showing participants in and processes for automated digital asset transactions in accordance with exemplary embodiments of the present invention;

FIGS. 46A-B are a schematic diagram and corresponding flow chart showing participants in and processes for providing digital asset arbitrage opportunity notifications in accordance with exemplary embodiments of the present invention;

FIGS. 47A-B are a schematic diagram and corresponding flow chart showing participants in and processes for performing automated digital asset arbitrage transactions in accordance with exemplary embodiments of the present invention;

FIGS. 48A-C are schematic diagrams of foreign exchange systems in accordance with exemplary embodiments of the present invention;

FIGS. 49A-B are flow charts of exemplary processes for performing foreign exchange transactions in accordance with exemplary embodiments of the present invention;

FIGS. 50A-E are exemplary screen shots of user interfaces related to purchase transactions provided by an exchange computer system in accordance with exemplary embodiments of the present invention;

FIGS. 51A-E are exemplary screen shots of user interfaces related to sale transactions provided by an exchange computer system in accordance with exemplary embodiments of the present invention;

FIGS. 52A-C are flow charts of exemplary processes for generating graphical user interfaces representing an electronic order book in accordance with exemplary embodiments of the present invention;

FIG. 53 is an exemplary flow chart for a method of providing proof of control from a custodial digital asset account;

FIG. 54 is an exemplary flow chart illustrating the steps used to perform a transaction as part of the method to provide proof of control of the custodial account;

FIG. 55 illustrates an example of indicative auction results as may be published during an indicative auction window;

FIGS. 56 and 56A are exemplary flow charts for a block trade process in accordance with exemplary embodiments of the present invention;

FIG. 57 is an exemplary database structure for order book databases on a digital asset exchange in accordance with exemplary embodiments of the present invention;

FIG. 58 is a schematic diagram of exemplary structures of a digital asset exchange system for performing block trades in accordance with exemplary embodiments of the present invention;

FIGS. 59 and 59A are schematic flows of exemplary messages of various exemplary block trades in accordance with exemplary embodiments of the present invention;

FIG. 60 is an exemplary flow chart of the process of sending tokens from Alice to Bob on the Ethereum blockchain in accordance with exemplary embodiments of the present invention;

FIGS. 61A-B are exemplary flow charts illustrating an exemplary process for loaning digital assets on a digital asset computer system using a continuous book;

FIGS. 62A-C are exemplary flow charts illustrating an exemplary process for loaning digital assets on a digital asset computer system by conducting an electronic auction;

FIGS. 63A-C are exemplary flow charts illustrating an exemplary process for performing a return swap on a digital asset computer system in accordance with exemplary embodiments of the present invention;

FIGS. 64A-H illustrate exemplary embodiments of a token that utilizes smart contracts in accordance with an embodiment of the present invention;

FIGS. 65A-1-4 illustrate an exemplary embodiment of a dashboard fiat interface which allows registered users to deposit and/or withdraw fiat with the digital asset exchange in accordance with exemplary embodiments of the present invention;

FIGS. 65B-1-4 illustrate an exemplary dashboard digital asset interface which allows registered users to deposit and/or withdrawal digital assets with the digital asset exchange system in accordance with exemplary embodiments of the present invention;

FIGS. 65C-1-2 illustrate an exemplary dashboard SVCoin interface which allows registered users to purchase and/or redeem SVCoins for fiat or digital with the digital asset exchange system in accordance with exemplary embodiments of the present invention;

FIG. 65D illustrates an exemplary dashboard Security Token interface which allow Security Token issuers to provide instructions to transfer SVCoins to Security Token holders in accordance with exemplary embodiments of the present invention;

FIG. 66A is an exemplary flow chart of the process for purchasing SVCoin for fiat on a digital asset exchange in accordance with exemplary embodiments of the present invention;

FIG. 66B is an exemplary flow chart of the process for redeeming SVCoin for fiat on a digital asset exchange in accordance with exemplary embodiments of the present invention;

FIGS. 67A-B are flow charts of a process and a corresponding exemplary schematic diagram for implementing a Swap Token for a swap trade between two users;

FIG. 68 is a schematic drawing of an exemplary network for holding collateral in a smart contract on an underlying blockchain in accordance with exemplary embodiments of the present invention;

FIG. 69A is a schematic drawing of a contract parameters database of a smart contract in accordance with exemplary embodiments of the present invention;

FIG. 69B is a schematic drawing of data structures associated with an exemplary security token on an underlying blockchain including smart contract instruction modules in accordance with exemplary embodiments of the present invention;

FIG. 69C is a schematic drawing of data structures associated with an exemplary stable value token (SVCoin Token) including smart contract instruction modules in accordance with exemplary embodiments of the present invention;

FIG. 70A is a flow chart of a processes for holding collateral for a security token in the form of a stable value token in a smart contract on an underlying blockchain in accordance with exemplary embodiments of the present invention;

FIGS. 70B-C are flowcharts of an exemplary sub-process of setting up a trade between a first user and a second user in accordance with exemplary embodiments of the present invention;

FIG. 70D is a flowchart of another exemplary sub-process of setting up a trade between a first user and a second user in accordance with another exemplary embodiment of the present invention;

FIG. 70E is a flowchart of an exemplary sub-process of collecting excess collateral from a first user or a second user in a trade in accordance with exemplary embodiments;

FIG. 70F is a flowchart of another exemplary sub-process of collecting excess collateral from a first user and a second user in a trade in accordance with exemplary embodiments;

FIGS. 71A-B are exemplary graphical user interfaces (GUIs) showing exemplary published contracts in accordance with exemplary embodiments;

FIGS. 71C-D are exemplary GUIs showing exemplary first indications of interest from user Alice in accordance with exemplary embodiments;

FIGS. 71E-F are exemplary GUIs showing exemplary second indications of interest from user Bob in accordance with exemplary embodiments;

FIGS. 72A-72C illustrate an exemplary dashboard of a user interface which allows registered users of a digital asset exchange to deposit and/or withdraw SVCoins (referred to as Gemini Dollars) with the digital asset exchange system in accordance with exemplary embodiments of the present invention; and

FIG. 72D illustrates an exemplary dashboard Security Token interface which allows Security Token issuers to provide instructions to transfer SVCoins to Security Token holders in accordance with exemplary embodiments of the present invention;

FIG. 73 is a flow chart of a processes for generating a smart contract on an underlying blockchain in accordance with exemplary embodiments of the present invention;

FIG. 74 illustrate an exemplary dashboard of a user interface which allows registered users of a digital asset exchange to generate a smart contract on an underlying blockchain in accordance with exemplary embodiments of the present invention

FIG. 75 illustrates an exemplary flow reflecting an exemplary embodiment where a Security Token issuer initiates a transfer of SVCoins to Security Token holders in accordance with exemplary embodiments of the present invention;

FIGS. 76A-76G illustrate an exemplary process flow chart of a process reflecting an exemplary embodiment of a method of issuing a stable value digital asset token in accordance with exemplary embodiments of the present invention;

FIG. 77A is an exemplary flowchart of a process for withdrawing stable value digital asset tokens from a digital asset exchange computer system in accordance with exemplary embodiments in the present invention;

FIG. 77B is an exemplary flowchart of a process for authenticating an access request by a user device in accordance with exemplary embodiments in the present invention;

FIG. 77C is an exemplary flowchart of a process for obtaining a withdraw request in accordance with exemplary embodiments in the present invention;

FIGS. 77D-77E are exemplary flowcharts of a process for processing a withdraw request in accordance with exemplary embodiments in the present invention;

FIG. 78A is an exemplary flowchart of a process for depositing stable value digital asset tokens in accordance with exemplary embodiments in the present invention;

FIG. 78B is an exemplary flowchart of a process for authenticating an access request by a user device in accordance with exemplary embodiments in the present invention;

FIG. 78C is an exemplary flowchart of a process for obtaining a deposit request in accordance with exemplary embodiments in the present invention;

FIGS. 78D-78E are exemplary flowcharts of a process for processing a deposit request in accordance with exemplary embodiments in the present invention;

FIG. 79A is a schematic drawing of an exemplary collection of systems for increasing the total supply of digital asset tokens on an underlying blockchain in accordance with exemplary embodiments of the present invention;

FIG. 79B is a schematic drawing of an exemplary proxy smart contract in accordance with exemplary embodiments of the present invention;

FIG. 79C is a schematic drawing of an exemplary print limiter contract in accordance with exemplary embodiments of the present invention;

FIG. 79D is a schematic drawing of an exemplary custodian smart contract in accordance with exemplary embodiments of the present invention;

FIG. 79E is a schematic drawing of a store smart contract in accordance with exemplary embodiments of the present invention;

FIG. 79F is a schematic drawing of an impl smart contract in accordance with exemplary embodiments of the present invention;

FIG. 80A is a schematic drawing of an exemplary process for increasing the ceiling of a print limiter in accordance with exemplary embodiments of the present invention;

FIG. 80B is a schematic drawing of an exemplary process for increasing the ceiling of a print limiter in accordance with exemplary embodiments of the present invention;

FIG. 80C is a schematic drawing of an exemplary process of limiting the print limiter with respect to a public address in accordance with exemplary embodiments of the present invention;

FIG. 80D is a schematic drawing of an exemplary process of a transfer request in accordance with exemplary embodiments of the present invention;

FIG. 80E is a schematic drawing of an exemplary process of a burn request in accordance with exemplary embodiments of the present invention;

FIG. 81A is a flowchart of an exemplary process of increasing a supply of tokens of a digital asset token using off-line keys in accordance with exemplary embodiments of the present invention;

FIG. 81A-1 is a flowchart of an exemplary process of increasing the total supply of tokens of a digital asset token using off-line keys in accordance with exemplary embodiments of the present invention;

FIG. 81B is another flowchart of an exemplary process of increasing the total supply of tokens of a digital asset token in accordance with exemplary embodiments of the present invention;

FIG. 81C is another flowchart of an exemplary process of increasing the total supply of tokens of a digital asset token in accordance with exemplary embodiments of the present invention;

FIG. 82A is a flowchart of an exemplary process of increasing the total supply of tokens of a digital asset token in accordance with exemplary embodiments of the present invention;

FIG. 82B is a flowchart of an exemplary process of increasing the total supply of tokens of a digital asset token in accordance with exemplary embodiments of the present invention;

FIGS. 83A-83E are flow charts of processes for increasing a total supply of digital asset tokens in accordance with exemplary embodiments of the present invention;

FIGS. 84A-84C are flow charts of processes for withdrawing digital asset tokens in accordance with exemplary embodiments of the present invention;

FIG. 85 is a flow chart of a process for providing a plurality of designated key pairs in accordance with exemplary embodiments of the present invention;

FIG. 86 is a flow chart of a process for providing a plurality of smart contract instructions in accordance with exemplary embodiments of the present invention;

FIGS. 87A-87B are flow charts of processes for increasing a total supply of digital asset tokens in accordance with exemplary embodiments of the present invention;

FIG. 88 is a flow chart of a process for increasing a total supply of digital asset tokens in accordance with exemplary embodiments of the present invention;

FIG. 89 is a flow chart of a process for verifying a designated public address in accordance with exemplary embodiments of the present invention;

FIG. 90 is a flow chart of a process for issuing electronic payments using a fiat-backed digital asset on a digital asset security token in accordance with exemplary embodiments of the present invention;

FIG. 91 is a flow chart of a process for issuing electronic payments using a fiat-backed digital asset on a digital asset security token in accordance with exemplary embodiments of the present invention;

FIGS. 92A-92D are flow charts of a process for withdrawing fiat-backed digital asset on a digital asset security token in accordance with exemplary embodiments of the present invention;

FIGS. 93A-93C are flow charts of a process for depositing fiat-backed digital asset on a digital asset security token in accordance with exemplary embodiments of the present invention;

FIG. 94 is an exemplary flowchart of a process including a data breach or data incident in accordance with exemplary embodiments of the present invention;

FIG. 95B is a flow chart illustrating a process for implementing trade instructions on an underlying blockchain in accordance with exemplary embodiments of the present invention;

FIGS. 95C-95D are flow charts illustrating a process for disputing benchmark information supplied by an oracle in accordance with exemplary embodiments of the present invention;

FIG. 96A is an exemplary dispute message for disputing benchmark information supplied by an oracle in accordance with exemplary embodiments of the present invention; and

FIG. 96B-96C are exemplary digitally signed benchmark messages in accordance with exemplary embodiments of the present invention.

A digital math-based asset is a kind of digital asset based upon a computer generated mathematical and/or cryptographic protocol that may, among other things, be exchanged for value and/or be used to buy and sell goods or pay for services. A digital math-based asset may be a non-tangible asset that is not based upon a governmental rule, law, regulation, and/or backing. The Bitcoin system represents one form of digital math-based asset. The Ethereum system represents another form of digital math-based asset, which allows for smart contracts, as discussed below.

A bitcoin may be a unit of the Bitcoin digital math-based asset. An ether may be a unit of the Ethereum digital math-based asset. Other examples of digital math-based assets include Bitcoin, Ethereum, Ripple, Cardano, Litecoin, NEO, Stellar, IOTA, NEM, Dash, Monero, Lisk, Qtum, Zcash, Nano, Steem, Bytecoin, Verge, Siacoin, Stratis, BitShares, Dogecoin, Waves, Decred, Ardor, Hshare, Komodo, Electroneum, Ark, DigiByte, E-coin, ZClassic, Byteball Bytes, PIVX, Cryptonex, GXShares, Syscoin, Bitcore, Factom, MonaCoin, ZCoin, SmartCash, Particl, Nxt, ReddCoin, Emercoin, Experience Points, Neblio, Nexus, Blocknet, GameCredits, DigitalNote, Vertcoin, BitcoinDark, Bitcoin Cash, Skycoin, ZenCash, NAV Coin, Achain, HTMLCOIN, Ubiq, BridgeCoin, Peercoin, PACcoin, XTRABYTES, Einsteinium, Asch, Counterparty, BitBay, Viacoin, Rise, Guiden, ION, Metaverse ETP, LBRY Credits, Crown, Electra, Burst, MinexCoin, Aeon, SaluS, DECENT, CloakCoin, Pura, ECC, DeepOnion, Groesticoin, Lykke, Steem Dollars, I/O Coin, Shift, HempCoin, Mooncoin, Dimecoin, Namecoin, Feathercoin, Diamond, Spectrecoin, Filecoin, Tezos, PPCoin, Tonal bitcoin, IxCoin, Devcoin, Freicoin, I0coin, Terracoin, Liquidcoin, BBQcoin, BitBars, Gas, Tether, Ether Classic and PhenixCoin, to name a few. In embodiments, digital math-based assets, such as bitcoin, may be accepted in trade by merchants, other businesses, and/or individuals in many parts of the world.

Digital assets may also include “tokens,” which like other digital assets can represent anything from loyalty points to vouchers and IOUs to actual objects in the physical world. Tokens can also be tools, such as in-game items, for interacting with other smart contracts. A token is a “smart contract” running on top of a blockchain network (such as the Ethereum Blockchain, the Bitcoin Blockchain, to name a few). As such, it is a set of code with an associated database. In embodiments, the database may be maintained by an issuer. The code describes the behavior of the token, and the database is basically a table with rows and columns tracking who owns how many tokens.

In embodiments, a smart contract may be a computer protocol intended to digitally facilitate, verify, or enforce the negotiation or performance of credible transactions without third parties. In embodiments, smart contracts may also allow for the creation of tokens.

In embodiments, a digital math-based asset may be based on an open source mathematical and/or cryptographic protocol, which may exist on a digital asset network, such as a Bitcoin network or an Ethereum network. The network may be centralized, (e.g., run by one or more central servers) or decentralized (e.g., run through a peer-to-peer network). Digital math-based assets may be maintained, tracked, and/or administered by the network.

A digital math-based asset system may use a decentralized electronic ledger system, which may be maintained by a plurality of physically remote computer systems. Such a ledger may be a public transaction ledger, which may track asset ownership and/or transactions in a digital math-based asset system. The ledger may be a decentralized public transaction ledger, which can be distributed to users in the network (e.g., via a peer-to-peer sharing). Ledger updates may be broadcast to the users across the network. Each user may maintain an electronic copy of all or part of the ledger, as described herein. In embodiments, a digital asset system may employ a ledger that tracks transactions (e.g., transfers of assets from one address to another) without identifying the assets themselves.

In embodiments, a digital asset ledger, such as the Bitcoin blockchain or the Ethereum blockchain, can be used to achieve consensus and to solve double-spending problems where users attempt to spend the same digital assets in more than one transaction. In embodiments, before a transaction may be cleared, the transaction participants may need to wait for some period of time, e.g., a six-confirmation wait (typically one hour in the context of the Bitcoin network, 15 minutes in the context of the Litecoin network, to name a few), before feeling confident that the transaction is valid (e.g., not a double count). Each update to the decentralized electronic ledger (e.g., each addition of a block to the Bitcoin blockchain or the Ethereum blockchain) following execution of a transaction may provide a transaction confirmation. After a plurality of updates to the ledger (e.g., 6 updates), the transaction may be confirmed with certainty or high certainty.

In embodiments, a blockchain can be a public transaction ledger of the digital math-based asset that is maintained by a distributed network, such as the Bitcoin network or the Ethereum network. For example, one or more computer systems (e.g., miners) or pools of computer systems (e.g., mining pools) can solve algorithmic equations allowing them to add records of recent transactions (e.g., blocks), to a chain of transactions. In embodiments, such algorithmic equations may be using a cryptographic protocol like RSA, PKI, to name a few. In embodiments, miners or pools of miners may perform such services in exchange for some consideration such as an upfront fee (e.g., a set amount of digital math-based assets) and/or a payment of transaction fees (e.g., a fixed amount or set percentage of the transaction) from users whose transactions are recorded in the block being added. In embodiments, digital assets in the form of a digital asset token, such as Gas, may be used to pay such fees.

The digital asset network (e.g., Bitcoin network or Ethereum network) may timestamp transactions by including them in blocks that form an ongoing chain called a blockchain. In embodiments, the addition of a block may occur periodically, e.g., approximately every 15 seconds, every 2.5 minutes or every 10 minutes, to name a few. Such blocks cannot be changed without redoing the work that was required to create each block since the modified block. The longest blockchain may serve not only as proof of the sequence of events but also records that this sequence of events was verified by a majority of the digital asset network's computing power. The blockchain recognized by the nodes corresponding to the majority of computing power, or some other consensus mechanism will become the accepted blockchain for the network. In embodiments, confirmation of a transaction may be attained with a high degree of accuracy following the addition of a fixed number of blocks to the blockchain (e.g., six blocks) after a transaction was performed and first recorded on the blockchain. As long as a majority of computing power (or some other consensus mechanism) is controlled by nodes that are not cooperating to attack the network, they will generate the longest blockchain of records and outpace attackers.

There are a variety of consensus mechanisms (or protocols) that may be used to verify transactions recorded in a blockchain. A few non-limiting examples of these mechanisms are discussed below, however, other protocols may be used in accordance with exemplary embodiments of the present invention.

For example, the proof of control protocol is one example of a consensus mechanism and is used, for example, in the Bitcoin blockchain. A more detailed discussion of proof of control protocols can be found in co-pending U.S. patent application Ser. No. 15/920,042, filed Mar. 13, 2018 and entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR VERIFYING DIGITAL ASSETS HELD IN A CUSTODIAL DIGITAL ASSET WALLET, the entire content of which is hereby incorporated herein by reference.

The proof of stake protocol is another optional protocol that may be implemented by blockchains. In this type of protocol, the validator's stake is represented by the amount of digital assets held. Validators accept, reject or otherwise validate a block to be added to the blockchain based on the amount of digital assets held by the Validator on the blockchain. If the Validators are successful in validating and adding the block, such a protocol, in embodiments, will award successful Validators are a fee in proportion to their stake.

The delegated proof of stake protocol is another protocol that is available and is, for example, used by the EOS blockchain. In this protocol, blocks are produced in a fixed number in rounds (e.g., 21 for EOS). At the start of every such round, block producers are chosen. A number less than all of the producers (e.g., 20 in EOS) are automatically chosen while a corresponding number are chosen proportional to the number of their votes relative to other producers. In embodiments, the remaining producers may be shuffled using a pseudorandom number derived from the block time, for example. In embodiments, other forms of randomized selection may be used. To ensure that regular block production is maintained, in embodiments, block time is kept short (e.g., 3 seconds for EOS) and producers may be punished for not participating by being removed from consideration. In embodiments, a producer has to produce a minimal number of block, e.g., at least one block every 24 hours to be in consideration. All of the nodes will, by default, not switch to a fork which does not include any blocks not finalized by a sufficient majority (e.g., 15 of the 21 producers) regardless of chain length. Thus, in EOS, each block must gain 15 of 21 votes for approval to be considered a part of the chain.

In embodiments, a delegated byzantine fault tolerance protocol may be used as a consensus mechanism. For example, NEO uses this type of protocol. In this protocol, one of the bookkeeping nodes is randomly chosen as a “speaker.” The speaker then looks at all the demands of the “citizens,” (e.g., all of the holders of the digital asset), and creates a “law” (e.g., a rule governing the protocol). The speaker then calculates a “happiness factor” of these laws to see if the number is enough to satisfy the citizen's needs or not. The speaker then passes the happiness factor down to the delegates (e.g., the other bookkeeping nodes). The delegates may then individually check the speaker's calculations. If the speaker's number matches the delegate's number, then the delegates give their approval, and if not, then they give their disapproval. In embodiments, a sufficient majority (e.g., 66% in NEO) of the delegates need to give their approval for the law to pass, i.e. for the block to be added. If a sufficient majority is not obtained (e.g., less than 66% approval), then a new speaker is chosen and the process starts again.

Ripple uses an algorithm in which each server gathers all valid transactions that have not yet been applied and makes them public. Each server then amalgamates these transactions and votes on the veracity of each. Transactions that receive at least a minimum number of yes votes will move into another round of voting. A minimum of 80% approval is required before a transaction is applied.

These and other protocols may be used to generate a blockchain in accordance with exemplary embodiments of the present invention.

In embodiments, transaction messages can be broadcast on a best effort basis, and nodes can leave and rejoin the network at will. Upon reconnection, a node can download and verify new blocks from other nodes to complete its local copy of the blockchain.

In the exemplary Bitcoin system, a bitcoin is defined by a chain of digitally-signed transactions that began with its creation as a block reward through bitcoin mining. Each owner transfers bitcoin to the next by digitally signing them over to the next owner in a bitcoin transaction, which is published to and added onto a block on the blockchain. A payee can then verify each previous transaction, e.g., by analyzing the blockchain, to verify the chain of ownership.

Other examples of different types of blockchains noted above that are consistent with embodiments of present invention pose unique problems. Certain currencies present unique challenges in that transactions and/or wallets or digital asset addresses associated therewith may be shielded (e.g., not viewable by the public on the ledger). For example, Monero is based on the CryptoNight proof-of-work hash algorithm and possesses significant algorithmic differences relating to blockchain obfuscation. Monero provides a high level of privacy and is fungible such that every unit of the currency can be substituted by another unit. Monero is therefore different from public-ledger cryptocurrencies such as Bitcoin, where addresses with coins previously associated with undesired activity can be blacklisted and have their coins refused by others.

In embodiments, “proof of brain” may be a type of token reward algorithm used in social media blockchain systems that encourages people to create and curate content. In embodiments, proof of brain may enable token distribution by upvote and like-based algorithms, which may be integrated with websites to align incentives between application owners and community members to spur growth.

In particular, in Monero, ring signatures mix spender's address with a group of others, making it more difficult to establish a link between each subsequent transaction. In addition, Monero provides “stealth addresses” generated for each transaction which make it difficult, if not impossible to discover the actual destination address of a transaction by anyone else other than the sender and the receiver. Further, the “ring confidential transactions” protocol may hide the transferred amount as well. Monero is designed to be resistant to application-specific integrated circuit mining, which is commonly used to mine other cryptocurrencies such as Bitcoin, however, it can be mined somewhat efficiently on consumer grade hardware such as x86, x86-64, ARM and GPUs, to name a few.

Another example of a modified blockchain consistent with exemplary embodiments of the present invention discussed above is Darkcoin. Darkcoin adds an extra layer of privacy by automatically combining any transaction its users make with those of two other users—a feature it calls Darksend—so that it will be more difficult to analyze the blockchain to determine where a particular user's money ended up.

Yet another example of a modified blockchain consistent with embodiments of the present invention discussed above is Zcash. The Zcash network supports different types of transactions including: “transparent” transactions and “shielded” transactions. Transparent transactions use a transparent address (e.g., “t-address”). In embodiments, transactions between two t-addresses behave like Bitcoin transactions and the balance and amounts transferred are publicly visible on the Zcash blockchain. Unlike the Bitcoin Blockchain, the Zcash network may also support shielded transactions using a shield address (e.g., “z-address”). In embodiments, the “z-address” provides privacy via zero-knowledge succinct noninteractive arguments of knowledge (e.g., “zk-SNARKS” or “zero-knowledge proofs”). The balance of a z-address is not publicly visible on the Zcash blockchain—the amount transferred into and out of a z-address is private if between two z-addresses—but may be public if between a z-address and a t-address.

In embodiments, a digital asset based on a blockchain, may, in turn, include special programming, often referred to as “smart contracts”, which allow for the creation of “tokens”, which in turn are digital assets based on digital assets. In embodiments, tokens may be ERC-20 tokens, and used in conjunction with ERC-20 token standard as a programming language. In embodiments, other protocols may be used including but not limited to ERC-223 and ERC-721, to name a few. In embodiments, smart contracts may be written on other smart contracts to provide for increased functionality. One non-limiting example of this type of structure is the open source Cryptokittens game in which digital kittens are provided as ERC-721 tokens with a series of smart contracts provided to define how the kittens will interact with each other and with users. In embodiments, programming modules may be added to and/or transferred with programming modules associated with specific tokens. By way of illustration, a first token, e.g., a Cryptokitten Tiger, may purchase a second token, e.g., a digital “hat,” that will then become associated with the first token to be a Tiger with a hat, and remain with the first token when transferred. Thus, by way of illustration, in the context of example embodiments of the present invention, the first token could be, e.g., a security token, and the second token could be, e.g., an account holding tokens, or a right to request tokens from another account as discussed below. If the first token is transferred, the second token would transfer with the ownership of the first token.

For example, digital assets can include tokens, which like other digital assets that can represent anything from loyalty points to vouchers and IOUs to actual objects in the physical world. Tokens can also be tools, such as in-game items, for interacting with other smart contracts. A token is a smart contract running on top of a blockchain network (such as the Ethereum Blockchain, the Bitcoin Blockchain, to name a few). As such, it is a set of code with an associated database. In embodiments, the database may be maintained by an issuer. In embodiments, the database may be included as part of the blockchain. In embodiments, the ledger may be maintained in the first instance as a database in a sidechain by the issuer or agent of the issuer and subsequently published and stored as part of a blockchain. The code describes the behavior of the token, and the database may be a table with rows and columns tracking who owns how many tokens.

If a user or another smart contract within the blockchain network (such as the Ethereum Network) sends a message to that token's contract in the form of a “transaction,” the code updates its database.

In embodiments, an underlying blockchain, like the Bitcoin Block chain, may have limited or no smart contract capabilities.

In such embodiments, an overlying protocol, such as Omni Layer (https://www.omnilayer.org/) may also be used to create custom digital assets on such an underlying blockchain, like the Bitcoin blockchain, as described in https://github.com/OmniLayer/spec. In embodiments, a smart contract may be used for transactions involving Bitcoin through the use of a two way peg with side chain. The side chain can share miners with the Bitcoin blockchain and allows smart contracts to be run, such as contracts using the Ethereum virtual machine. When Bitcoin is to be used in the smart contract side chain, the Bitcoin is locked and an equal amount of side chain currency, an example of which is Super Bitcoin (SBTC), is assigned to the corresponding address. After the smart contract transaction is completed, the side chain currency is locked and the Bitcoin is unlocked. An example of such a side chain is Rootstock.

In embodiments, where the blockchain is the Bitcoin blockchain, and another protocol is used as a layer over the Bitcoin blockchain to provide for smart contract functionality. For example, the other protocol may be a two-way peg of stable value digital asset tokens to bitcoin and a sidechain that shares miners with the Bitcoin blockchain. In embodiments, the other protocol is an omni layer protocol.

So, for instance, as illustrated in FIG. 60, using a token based on the Ethereum Network for illustration purposes, when a wallet app sends a message to a token's contract address to transfer funds from Alice to Bob, the following process occurs.

In step S6001, at the token issuer computer system, Security Tokens are created. In embodiments, each Stable Value Token may have a “ERC-20 Contract Wallet Address” (“Contract Address”) which is an address on the blockchain at which the code for the smart contract is stored. In embodiments, the smart contract may include instructions to perform at least: (1) token creation, (2) token transfer, (3) token destruction; and (4) updating smart contract coding.

In embodiments of the present invention, the minimal specification for a Token, such as a Stable Value Token, may include instructions to perform at least: (1) a “total Supply” function, which when called, will respond with a count of the number of tokens in existence; (2) a “balanceOf” function, which when called with a specific account (address) as a parameter, responds with the count of the number of tokens owned by that account; and (3) a “transfer” function, which is an example of a state modifying function, that, when called, given one or more target accounts and corresponding transferred amounts as parameters, the transfer function will decrease the balance of the caller account by the corresponding transfer amounts, and increase the target accounts by the target amounts (or fail if the caller account has insufficient amounts or if there are other errors in the parameters).

In embodiments, a Stable Value Token may be created with a fixed supply of tokens at the time of its creation. For example, a Stable Value Token may be created with a supply of 21 million tokens and set Address 1 (mathematically associated with a private key 1) as the owner of all 21 million tokens. Thereafter, private key 1 will be required to generate a call to the transfer function in order to assign some portion of the 21 million tokens with a second Address 2 (mathematically associated with a private key 2) or any other Address (also mathematically associated with a corresponding private key).

In embodiments, a Stable Value Token may be created with a variable supply of tokens which can be set to increase or decrease after original creation. In such embodiments, the minimum functions required will also include: (4) a “print” function, which is another example of a state modifying function, that when called allows for the creation of additional Stable Value Tokens into the total Supply of Stable Value Tokens; and (5) a “burn” function, which is also another example of a state modifying function, that when called allows for the destruction of previously created Stable Value Token from the total Supply of the Stable Value Tokens. As discussed below in greater detail, in embodiments, the print and burn function may include limits on the Addresses that are allowed to call those functions.

Currently, due to the immutable nature of the Ethereum blockchain, once a smart contract is written to a specific Contract Address it cannot be changed. However, in embodiments, the various functions called for in the Contract Address may be associated with specific authorized key pairs of public keys (or “addresses”) and corresponding private keys (which are mathematically associated with public keys). In embodiments, one or more private keys may be stored off-line in, what is sometimes referred to as, a designated cold storage wallet associated with the token issuer. In such embodiments, keys may be generated, stored, and managed onboard hardware security modules (HSMs). For example, HSMs, e.g., each a “signer,” should have achieved a rating of FIPS PUB 140-2 Level 3 (or higher). In embodiments, one or more private keys may be stored on-line in, what is sometimes referred to as a designated hot storage wallet associated with the token issuer. In embodiments, the Contract Address may include instructions which are associated with authorizing one or more designated key pairs stored off-line in, e g., one or more cold storage wallets on one or more air-gapped computer systems associated with the token issuer, but may also give at least some permission to perform operations by one or more designated key pairs stored on-line, in, e.g., one or more hot wallets associated with the token issuer and/or a token administrator on behalf of the token issuer on one or more computer systems connected to the digital asset computer system. In embodiments, the on-line computer systems would be co-located with the digital asset computer systems. In embodiments, the Stable Value Tokens may be created in batches (for example, 100,000 SVCoins worth $100,000 U.S. dollars) by a designated key pair (such as an off-line designated key pair) authorized by smart contract and assigned by such a key pair to a designated address associated with on on-line public key for transactions as necessary.

In embodiments, a Stable Value Token database is maintained in a blockchain, such as the Ethereum blockchain, for example. In embodiments, the ledger may be maintained, in the first instance, as a database in a sidechain by the issuer or agent and subsequently published and stored as part of a blockchain.

In embodiments, a Stable Value Token database is maintained in a blockchain, such as the Ethereum blockchain, for example. In embodiments, the ledger may be maintained in the first instance as a database in a sidechain by the issuer or agent and subsequently published and stored as part of a blockchain.

In embodiments, Stable Value Tokens may be generated on the fly, however, in this case, the contract code, which is the executable code that is stored at the Contract Address location on the blockchain, may designate one or more public addresses corresponding to one or more on-line private keys held in, e.g., a hot wallet(s), or one or more public addresses corresponding on one or more off-line public keys held in, e.g., a cold wallet(s), or some combination thereof, as the authorized caller of some functionality. A more detailed discussion of hot wallets and cold wallets is presented in U.S. Pat. No. 9,892,460 issued Feb. 13, 2018 entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR OPERATING EXCHANGE TRADED PRODUCTS HOLDING DIGITAL MATH-BASED ASSETS, the entire content of which is incorporated herein by reference. In embodiments, Contract Wallets may be maintained by the token issuer and which would hold the private key associated with the token on an associated device. In embodiments, Contract Wallets may be provided on a user computer device and hold the private key associated with the token. In such embodiments, a user computer device may include a software application to provide secure access to the token issuer such that the user can engage in transactions.

By way of illustration, an ERC-20 Contract can include the following representative type of functions as shown in Table 1 in its programming of a Smart Contract associated with a particular token, such as a security token:

TABLE 1

1 // --------------------------------------------------------------------------
2 // ERC Token Standard #20 Interface
3 // https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20-token-
standard.md
4 // --------------------------------------------------------------------------
5 contract ERC20Interface {

6	function totalSupply( ) public constant returns (uint);
7	function balanceOf(address tokenOwner) public constant returns

(uint balance);

8	function allowance(address tokenOwner, address spender) public

constant returns (uint remaining);

9	function transfer(address to, uint tokens) public returns (bool success);
10	function approve(address spender, uint tokens) public returns (bool

success);

11	function transferFrom(address from, address to, uint tokens) public

returns (bool success);

12
13	event Transfer(address indexed from, address indexed to, uint tokens);
14	event Approval(address indexed tokenOwner, address indexed

spender, uint tokens);

Some of the tokens may include further information describing the token contract such as shown in Table 2:

TABLE 2

1	string public constant name = ″Token Name″;
2	string public constant symbol = ″SYM″
3	uint8 public constant decimals = 18; //18 is the most common
	number of decimal places

In embodiments, a more elaborate smart contract can be set up to allow token issuers to have hybrid control over which key pairs have authority to affect the token supply and distribution. In embodiments, a hybrid combination of on-line and off-line key pairs can be used to control the supply and distribution of tokens.

For example, in embodiments, a smart contract may include a state-changing function such as limitedPrint, where the authorized caller of such function would be authorized only to print (or issue) a specific limited amount of tokens. In embodiments, the limitedPrint function may be used with an on-line key pair (e.g., hot wallet), to allow for fast and efficient token creation, but limit risk of unauthorized takeover of the on-line key pair to the set limit.

In conjunction with a limitedPrint command, a separate state-changing function of raiseCeiling can be used to increase the authority for the on-line key pair using a different key pair, such as an off-line key pair (e.g., cold wallet), which is considered to be more secure.

In embodiments, using a limitedPrint function with a set limit that can be implemented by one or more designated on-line key pairs (e.g., hot wallets), and a raiseCeiling function which may change that limit under the authority of a different set of one or more designated off-line key pairs (e.g., cold wallets), the automated increases in the token supply through on-line control will only continue up until the ceiling is reached, at which point further intervention through off-line control is required.

One should consider the difference between the current token supply and the supply ceiling as part of the tokens at risk. If the current token supply has decreased through the use of burn, then the effective funds at risk could have increased without a corresponding decrease in the supply ceiling. The ceiling can be lowered by on-line control, through a function called lowerCeiling. This allows for relinquishing some portion of what has been granted through off-line control to limit the effective funds at risk through compromise of on-line key management systems. In embodiments, a limit on number of tokens that can be burned may also be included.

In embodiments, as illustrated in FIG. 64A, the token may be set up using at least three core smart contracts, e.g., ERC20Proxy 6410, ERC20Impl 6420, and ERC20Store 6430 that cooperatively implement an ERC20 compliant token.

In the context of a ERC20 compliant token on the Ethereum blockchain, there is one, and will only ever be one instance of ERC20Proxy 6410. This is the smart contract that users of the token treat as the token contract. Thus, ERC20Proxy 6410 can be considered the permanent face of interacting with the token on the Ethereum blockchain.

However, in embodiments, ERC20Proxy 6410 may have almost no code and does not keep any state information itself. Instead, in embodiments, ERC20Proxy 6410 has one or more implementations (e.g., ERC20 Impl 6420, ERC20 Impl (1) 6440, ERC20 Impl (2), to name a few) that executes the logic of the token. S6412 impl represents a delegation from ERC20 Proxy 6410 to ERC20Impl 6420. Thus, the instance of ERC20Impl 6420 executes the specific delegated functions. ERC20Impl 6420 may further limit the authority to implement to the specific delegated functions to only specified trusted callers (e.g., as shown in FIGS. 64C, 64G and 64H, one or more off-line key set 6462, one or more on-line key set 6464, to name a few). S6414 proxy illustrates the authorization of ERC20Impl 6420 executing logic on behalf of ERC20Proxy 6410, through call functions from one or more authorized addresses.

In embodiments, state information, such as token balances, may be maintained in a. separate instance, e.g., ERC20Store 6430, a “backing store.” In such embodiments, ERC20Store 6430 would own the delegated state of the token. S6422 store illustrates the delegation of state information from ERC20Impl 6420 to ERC20Store 6430. In embodiments, the instance of ERC20Store 6430 may execute updates to the state of the token, such as updates to token balances that occur during a token transfer to one or more designated key sets. S6424 impl represents the address that the ERC20Store 6430 will permit to invoke the update functions. In embodiments, that address is the “Contract Address” of the active version of ERC20Impl 6420.

This separation of duties—public face, logic, and storage, for ERC20Proxy 6410, ERC20Impl 6420, and ERC20Store 6430, respectively—provides the ability for token issuer to replace the logic of the system at a later date. In embodiments, the logic may be replaced by changing the impl arrows (e.g., S6412 impl and S6424 impl).

FIG. 64B illustrates an embodiment where a token has been upgraded, by creating a new instance of ERC20Impl (ERC20Impl (2) 6420A) with a second version of the code previously implemented through ERC20Impl 6420. The instance of ERC20Proxy 6410 now delegates its implementation in 56412A impl to ERC20Impl (2) 6420A (version 2 of the code) instead of the previous ERC20Impl 6420 (version 1), and the instance of ERC20Store 6430 will now only accept calls from ERC20Impl 6420A (version 2). The original ERC20Impl 6420 (version 1) remains, but has become inert as it is unlinked from the system.

Turning to FIGS. 64C-64F, custodianship will be discussed.

In embodiments, a fourth type of contract, Custodian 6450, may also be implemented. A Custodian 6450 is logic which designates which key pair (e.g., an Off-Line Keyset 6462), is authorized to control other contracts in the system (e.g., ERC20Proxy 6410). Contracts cooperate with Custodian 6450 by awaiting an approval from Custodian 6450 before executing certain actions. In turn, such approval will require a message from an authorized key pair (e.g., Off-Line Keyset 6462) authorizing the action (e.g., print tokens, limit tokens, transfer tokens, to name a few).

In embodiments, Custodian 6450 may include a range of control coding. In embodiments, control coding may include the requirement that at least two designated keysets authorize a specific action (e.g., print token). In embodiments, at the least two keysets may be a subset of a larger group of keysets (e.g., two of three designated keysets, or two of six designated keysets, or three of five designated keysets, to name a few). In embodiments, when a higher degree of security is desired, the keysets may be maintained off-line. In embodiments, when a high degree of automation or speed to access is required, the keysets may be maintained on-line, such as in a co-located, but separate computer system that is operatively connected to a customer facing digital asset system.

In embodiments, Custodian 6450 may also exercise control over various security operations of ERC20Proxy 6410 (e.g., time locking and revocation, to name a few).

In embodiments, Custodian 6450 may have custodianship of the proxy which grants exclusive power to replace the implementation for ERC20Proxy 6410 from its current implementation (e.g., ERC20Impl 6420 (version 1)) to a new implementation (e.g., ERC20Impl 6420A (version 2)), as illustrated in FIG. 64B, discussed above. As discussed, in embodiments, only authorized and designated key sets (e.g., off-line key set 6462) will have the authority in step S6454 signers to authorize the Custodian 6450 to modify an implementation of ERC20Proxy 6410.

In embodiments, Custodian contracts with their own respective authorized designated keysets can be set up for other contracts, such as ERC20Store 6430 as also shown in FIG. 64C. Thus, by way of example, ERC20Store 6430 may designate in S6432 Custodian 6450A as a custodian for certain operations of ERC20Store. Those operations will only be executed by ERC20Store 6430 when designated keyset (such as Off-Line keyset 6462A) sends a message through the blockchain to Custodian 6450A authorizing the Custodian 6450A to authorize the ERC20Store 6430 to perform the designated function. In embodiments, the off-line keyset 6462A may be the same as, overlap with, or be different from the Off-Line Key Set 6462A which may authorize Custodian 6450 with respect to ERC20Proxy 6410.

In embodiments, custodianship of the proxy and store also grants exclusive power to pass custodianship to a new instance of Custodian. Thus, one of the technical computer problems associated with the immutability of ERC20 smart contracts on the Ethereum blockchain has been solved, thus allowing for a self-upgrade of custodianship. In embodiments, since a set of signers for a given instance of a Custodian is fixed, a change to the off-line keyset may be implemented instead having a current Custodian authorize itself to be replaced by a new instance of Custodian with a new set of signers.

Referring now to FIGS. 64D-64F, the process of upgrading active implementation of the pointer relationship of ERCProxy 6410 from ERC20Impl 6420 (version 1) to ERC20Impl 6420A (version 2) will now be discussed.

FIG. 64D reflects the initial state in which ERC20Proxy 6410 has Custodian 6450 and in S6412A implemented ERC20 Impl 6420 (version 1) to act as a proxy in S6414A for certain functions of ERC20Proxy 6410.

To swap out the current ERC20Impl 6420 (version 1) with an updated ERC20Impl 6420 (version 2), as shown in FIG. 64E, the coding for ERC20 Impl 6420 (version 2) needs to be deployed on the blockchain and set its proxy point (S6414B proxy) to the same ERC20Proxy 6410.

Next, the implementation pointer from ERC20Proxy 6410 which is currently set at S6412 (impl) to point to ERC20Impl 6420 (Version 1), needs to be reset to be S6412B impl to point to ERC20Impl 6420A (version 2) instead. This change requires the authorization of Custodian 6450, which in turn requires two signatures from keys in its designated keyset (e.g., Off-Line Keyset 6462) sent to it on the blockchain.

Table 3 represents an exemplary embodiment of the steps used to implement this process:

TABLE 3

1.	lockID = proxy.requestImplChange(imp_2)
2.	request= custodian.requestUnlock(lockId,proxy.confirmImpl.Change)
3.	Off-line signing of request
4.	custodian.completeUnlock (request, signature_1, signature 2)
	a. proxy.confirmImplChange(lockID)

Referring to Table 3, in step 1, a request must be made to ERC20Proxy to change its instance of ERC20Impl. This request may come from any address, and when the request is made, the function returns a unique lockId that anyone can use to look up that request.

Next, in step 2, to confirm the pending request, the Custodian contract 6450 for ERC20 Proxy 6410 calls requestUnlock and passes as arguments the lockId generated for the change request, and the function in ERC20Proxy 6410 the Custodian 6450 needs to call to confirm the change request. This generates a request, which is a unique identifier for this unlock request.

In step 3, to complete the unlocking of Custodian and therefore propagate the change to ERC20Proxy 6410, the digital asset system operated by the token issuer uses its off-line key storage infrastructure to sign the request with the previously approved designated key sets. In this example, two signatures are required (signature 1 and signature 2), but other combinations of signatures may be used consistent with embodiments of the present invention.

In step 4, those signatures are passed into the Custodian's completeUnlock function along with the initial request. Once the request is validated against the signatures, completeUnlock parses the content of the request and issues the command. In this case, it calls ERC20Proxy's confirmImplChange using the lockId generated in the initial ERC20Impl change request.

As shown in FIG. 64F, ERC20Proxy 6410 now points with S6412B to the updated ERC20Impl 6420A (version 2) contract, thus delegating all future calls from ERC20Proxy 6410 to the updated contract ERC20 Impl (version 2) 6420A. This process can be repeated in the future to upgrade the ERC20 Impl (version 2) 6420A to new versions as authorized by the Custodian 6450.

In embodiments, a similar process may also be used to upgrade the active Custodian 6450. Instead of the pair of functions requestImplChange and confirmImplChange, the pair of functions requestCustodianChange and confirmCustodianChange are used instead.

Referring to FIGS. 64G and 64H, a PrinterLimiter 6460 contract may also be used as an upgradeable limit on the token supply available.

In the context of FIG. 64G, ERC20Impl 6420 allows printing an unbounded amount of tokens to any arbitrary address. This printing can only be done by PrintLimiter 6460 contract, which serves as ERC20Impl's custodian. However, PrintLimiter 6460 can only call this unbounded printing if it receives a call from its custodian, a separate contract named Custodian 6450, which is in turned controlled by signatures from designated keysets (e.g., Off-Line Key Set 6462).

Thus, to print an unbounded amount of tokens, signatures from keys in Off-Line Key Set 6462 need to be sent through the blockchain, to Custodian 6450, which, in turn, then calls through the blockchain, PrintLimiter 6460, which then, in turn, calls through the blockchain ERC20Impl 6420 to confirm the print request.

Referring to FIG. 64H, a limited printing option may also be implemented. Thus, in embodiments consistent with FIG. 64H, ERC20Impl 6420 allows either printing an unbounded amount (which originates from Off-Line Key Set 6462 as described earlier), or a limited amount which does not require the off-line key set to enact. Within PrintLimiter 6460 is a “total supply ceiling” variable: a maximum total supply of tokens that any “limited print” operation cannot exceed. This value is set by Off-Line Key Set 6462. PrintLimiter 6460 allows printing new tokens while remaining under that ceiling from a special hot wallet address. That hot wallet address can call PrintLimiter 6460 directly, which then calls ERC20Impl 6420 to confirm the “limited” print operation. In embodiments, limits may also be expressed in or related to time periods.

The total supply ceiling can only be raised by Off-Line Key Set 6462. In embodiments, it can be lowered, however, by that On-Line Key Set 6464 or Off-Line Key Set 6462.

Table 4 illustrates exemplary embodiments of code used in smart contracts on the Ethereum blockchain which implement a cooperative relationship with an external account or contract that exerts custodianship over the contract following the pattern.

A contract following the pattern is capable of carrying out some action—a portion of the desired operations; however, rather than executing the action directly, the action is first requested, with a unique ‘lock identifier’ returned as the result of the request. The pending action is stored in the contract state, storing the data necessary to execute the action in the future, and with the lock identifier as the lookup key to retrieve the pending action. If the contract is called by its custodian, receiving a lock identifier as an argument, then the associated pending action, if any, is retrieved and executed.

In embodiments, as illustrated in Table 4, the contracts may include multiple inheritances, so for the purposes of code reuse, a function for generating unique lock identifiers is implemented in the contract LockRequestable.

TABLE 4

	contract LockRequestable {
	uint256 public lockRequestCount;
	function LockRequestable( ) public {
	lockRequestCount = 0;
	}
	function generateLockId( ) internal returns (bytes32 lockId) {
	return keccak256(block.blockhash(block.number − 1),
	address(this), ++lockRequestCount);
	}
	}

In embodiments, the function generateLockId returns a 32-byte value to be used as a lock identifier, which is a hash of the following three components: (1) The blockhash of the Ethereum block prior to the block that included the Ethereum transaction that executed this function; (2) The deployed address of the instance of the contract that inherits from LockRequestable; and (3) The current value of the count of all invocations of generateLockId (within ‘this’ contract).

Component three plays the role of a nonce (in cryptography, a nonce is an arbitrary number that can be used just once) ensuring that a unique lock identifier is generating no matter how many invocations of generateLockId there are within a single Ethereum transaction or a single Ethereum block.

Component two ensures that the lock identifier is unique among the set of cooperating contracts that use this identifier generation scheme. A noncooperative contract authored by a third party may choose to generate identifiers that overlap, but that is expected not to impact operation.

Finally, component three uses the relative previous blockhash to make future lock identifiers unpredictable.

Table 5 illustrates embodiments of code which uses LockRequestable in a template consistent with embodiments of the present invention.

TABLE 5

contract C is ..., LockRequestable {
struct PendingAction {
t v;
...
}
address public custodian;
mapping (bytes32 => PendingAction) public pendingActionMap;
function C(address _custodian, ...) public {
custodian = _custodian;
...
}
modifier onlyCustodian {
require(msg.sender == custodian);
_;
}
function requestAction(t _v, ...) public returns (bytes32 lockId) {
require(_v != 0);
lockId = generateLockId( );
pendingActionMap[lockId] = PendingAction({
v: _v,
...
});
emit ActionLocked(lockId, _v, ...);
}
function confirmAction(bytes32 _lockId) public onlyCustodian {
PendingAction storage pendingAction = pendingActionMap[_lockId];
t v = pendingAction.v;
require(v != 0);
... // copy any other data from pendingAction
delete pendingActionMap[_lockId];
... // execute the action
emit ActionConfirmed(_lockId, v, ...);
}
event ActionLocked(bytes32 _lockId, t _v, ...);
event ActionConfirmed(bytes32 _lockId, t _v, ...);
}

The function requestAction generates a fresh lock identifier and captures the request parameters as a pending action, storing it in a mapping associated with the lock identifier.

The function confirmAction is callable only by the designated custodian. The given lock identifier is used to retrieve the associated pending action from the contract storage, if it exists, otherwise the function reverts. The pending action is deleted from storage, which ensures that the action will be executed at most once. Finally the logic of the action is executed.

In embodiments, there are two requirements to the confirmAction callback function: (1) The function does not have a return value; and (2) The function must only revert if there is no pending action associated with the lock identifier.

In these embodiments, the custodian receives a failure signal only when it called with an invalid lock identifier. Any failure cases that may occur in the execution of the action logic must be signaled by means other than return values or reversions (including abortive statements such as throw).

Programming consistent with Tables 4 and 5 may be used to implement a wide variety of functions in the context of a token including, by way of example:

- Contracts that inherit from the ERC20ImplUpgradeable contract (e.g., ERC20Proxy and ERC20Store) control updates to the address that references an instance of the ERC20Impl contract;
- The ERC20Impl contract to control increases to the token supply;
- The ERC20Holder contract to control ‘withdrawal’ transfers out of its balance;
- The PrintLimiter contract to control increases to its token supply ceiling state; and
- Contracts that inherit from the CustodianUpgradeable contract (e.g., ERC20Proxy, ERC20Impl, and ERC20Store) to control the passing of custodianship itself from the current custodian to a new custodian, to name a few.

In embodiments, other limits or controls may also be built into the smart contract functionality of the token. For example, in embodiments, it may be necessary for the token issuer to adjust the token ledger to account for regulatory activity. For example, there may be a court order seizure of funds, or a security issue that may require reversing transactions during a compromised period, to name a few

In embodiments, the administrator may send instructions to modify the token supply for one or more particular accounts. For example, the smart contract may include instructions to pause a transfer. The pause function may be a permanent pause, e.g., for a compromised account, a time limited pause, e.g., for 24 hours or 2 days, or a temporary pause which requires another instruction to reactivate the account, to name a few. Such a function could be included as an upgrade feature in a new Impl contract, or built into the smart contract to be activated when an authorized account, e.g., one or more off-line keys call upon the smart contract to implement the pause functionality, with appropriate parameters.

In embodiments, the administrator may send instructions to rebalance the token supply of one or more particular accounts. For example, the smart contract may include instructions to adjust a token balance in a designated account, e.g., by raising the balance in the designated account, lowering the balance in the designated account, or transferring some or all of the tokens in one designated account to one or more other designated accounts. Such a function could be included as an upgrade feature in a new Impl contract, or built into the smart contract to be activated when an authorized account, e.g., one or more off-line keys, call upon the smart contract to implement the pause functionality, with appropriate parameters.

In embodiments, the Stable Value Token may be embodied in the form of a token on the Ethereum Blockchain, referred to as a Gemini Dollar token, as illustrated in the exemplary dashboard of FIGS. 72A-72C.

FIG. 72A illustrates an exemplary GUI for an interface with the digital asset exchange in which a user can deposit/redeem Gemini Dollar tokens into an public address associated with the digital asset exchange, in exchange for an corresponding amount of fiat in the user's account at the digital asset exchange. In embodiments, after the registered user of the exchange deposits the stable value token into the exchange's public address, the exchange will transfer from the bank account or other account associated with the stable value token, a corresponding amount of fiat, to the bank account associated with the fiat holdings of the user. In embodiments, the deposited token will then be burnt from circulation. In embodiments, the deposited token may instead of being burnt be redistributed to another customer, but in such case, an appropriate amount of fiat will need to be redeposited into the bank account or other stable investment vehicle associated with the stable value token.

In embodiments, creation and redemption of the Gemini Dollar tokens may be made simple to promote usability and encourage adoption. In embodiments, Gemini Dollar tokens are redeemed or “destroyed” at the time of deposit into a digital asset exchange. Exchange customers may exchange Gemini Dollar tokens for U.S. dollars at a 1:1 exchange rate by depositing Gemini Dollar tokens into their exchange account. The U.S. dollar amount of Gemini Dollar tokens will be credited to the customer's exchange account balance at the time of deposit.

FIG. 72D illustrates an exemplary embodiment of a dashboard Security Token interface which allow Security Token issuers to provide instructions to transfer SVCoins to Security Token holders.

Referring back to FIG. 60, in Step S6002, Alice's wallet, or associated digital asset address, may send a request message to the database maintained by the blockchain including: (a) Alice's ethereum digital asset address, which is typically associated with a digital wallet (Source Address); (b) token identification information; (c) amount of token to be transferred; and (d) Bob's ethereum digital asset address (Destination Address). In embodiments, if a fee is charged for the transaction, fee payment information may also be required and provided. For example, on the Ethereum network, an amount of Gas tokens may be required from the sender to pay for processing of the transaction into a block on the blockchain. In embodiments, the message may include a proposed fee amount and/or fee proposal including a limit in e.g., Gas. The request message will also be digitally signed by Alice's private key.

In Step S6004, when miners on the blockchain network receive the transaction request directed to the contract wallet or associated digital asset address, with the request message, miners on the blockchain network will confirm the transaction, including verifying that the message was properly signed by Alice. In Step S1004-b, the miners may verify that Alice has a sufficient amount of tokens to perform the requested transaction, for example, by comparing Alice's balance against Alice's token balance as indicated on the blockchain. In Step S1004-c, the validity of Bob's digital asset address (the Destination Address) may also be confirmed by the miners. The miners may also compare the request with smart contract coding and instructions included in the Contract Address. The transaction fee discussed above is paid to the miners for confirming the transaction as noted above.

In Step S6006, if the request is verified the transaction is published in the Security Token database of the blockchain reflecting a debit against Alice's token holdings and a corresponding credit to Bob's token holdings (less any applicable fees).

In Step S6008, response messages to the digital asset addresses of both Alice and Bob may be sent to reflect that the transaction was successfully processed. In embodiments, such messages may include information including: (i) the source digital asset address; (ii) the destination digital asset address; (iii) the amount of tokens transferred; and/or (iv) the new balances for each digital asset address or associated digital wallet. In embodiments, the message may include a proposed fee amount and/or fee proposal including a limit in e.g., Gas. In embodiments, Alice, Bob, and/or third parties may view the balances and transaction information based on the information stored in the blockchain, by, e.g., viewing token balances at websites like etherscan.io, to name a few.

In contrast to tokens, a blockchain based digital asset (such as ether) is hard coded into the blockchain (e.g., the Ethereum Blockchain) itself. It is sold and traded as a cryptocurrency, and it also powers the network (e.g., the Ethereum Network) by allowing users to pay for smart contract transaction fees. (In some networks, transactions fees may be paid for in digital assets, such as tokens (e.g., Gas) or blockchain based digital assets (e.g., bitcoin). In the Ethereum Network, all computations typically have a cost based on other digital assets, such as Gas.

In embodiments, when tokens are sent to or from a Contract Address, for example, a fee may be charged for that transaction (in this case, a request to the token's contract to update its database) in, e.g., some form of digital asset, such as ether, bitcoin, Gas, to name a few. In embodiments, the message may include a proposed fee amount and/or fee proposal including a limit in digital asset, e.g., ether, bitcoin or Gas. This payment is then collected by a miner who confirms the transaction in a block, which then gets added to the blockchain.

FIG. 2 is an exemplary screen shot of an excerpt of a bitcoin transaction log or transaction ledger 115 showing digital asset account identifiers (e.g., addresses) corresponding to origin and destination accounts for each transaction and amount information for each transaction in accordance with exemplary embodiments of the present invention. The exemplary log 115 includes transaction identifiers, date and/or time information, fee information, digital asset account identifiers for the origin accounts, digital asset account identifiers for the destination accounts, and amounts transferred to and from each account. Such a ledger may also include description information (such as notes describing a transaction, e.g. “rent payment”) and/or balance information, to name a few. Other forms of transaction logs can be used consistent with exemplary embodiments of the present invention. In an exemplary embodiment the description information may be included as a message in a request for a transaction, as is discussed in detail with respect to FIGS. 53 and 54 and discussed below. The description information discussed above thus may also be used to confirm control of over a particular account.

As can be seen in FIG. 2, digital asset transfers may begin from a single origin and be sent to a single destination or multiple destinations. Similarly, digital assets may be transferred from multiple origins to one or more destinations.

FIG. 2A illustrates a screenshot showing an exemplary embodiment of a token ledger for a Gas token. This particular screenshot shows a specific example the token ledger for the Gas token provided by etherscan.io. As illustrated the ledger illustrates, in chronological order, a series of transactions identifying the source address 2201 and destination address 2203 along with the quantity of tokens 2205 transferred in each transaction. In embodiments, the Security Token ledger of the present application may appear in a similar manner to that illustrated in FIG. 2A. In embodiments, as illustrated in FIG. 2A, the Security Token ledger may also include the option to identify all Token holders 2207 as well as options to view token details 2209 and to view the contract details 2211. Similarly, in embodiments, a token ledger of the present application may be similar to that illustrated in FIG. 2A. Digital asset ledgers may be maintained in the form of a database. Such a database may be maintained on a blockchain or off a blockchain as a sidechain which may later be published to the blockchain.

An exemplary embodiment of a digital asset network is illustrated in FIG. 1. In embodiments, other digital math-based assets can be maintained and/or administered by other digital math-based asset networks. Without meaning to limit the invention, a digital math-based asset network will be discussed with reference to a Bitcoin network by example. Of course, other digital asset networks, such as the Ethereum network, can be used with embodiments of the present invention. A digital math-based asset network, such as a Bitcoin network, may be an on-line, end-user to end-user network hosting a public transaction ledger 115 and governed by source code 120 comprising cryptologic and/or algorithmic protocols. A digital asset network can comprise a plurality of end users, a . . . N, each of which may access the network using one or more corresponding user device 105a, 105b, . . . 105N. In embodiments, user devices 105a, 105b . . . 105N may be operatively connected to each other through a data network 125, such as the Internet, a wide area network, a local area network, a telephone network, dedicated access lines, a proprietary network, a satellite network, a wireless network, a mesh network, or through some other form of end-user to end-user interconnection, which may transmit data and/or other information. Any participants in a digital asset network may be connected directly or indirectly, as through the data network 125, through wired, wireless, or other connections.

In the exemplary embodiment, user devices 105a, 105b1 . . . 105N can each run a digital asset client 110, e.g., a Bitcoin client, which can comprise digital asset source code 120 and an electronic transaction ledger 115. The source code 120 can be stored in processor readable memory, which may be accessed by and/or run on one or more processors. The electronic transaction ledger 115 can be stored on the same and/or different processor readable memory, which may be accessible by the one or more processors when running the source code 120. In embodiments, the electronic transaction leger 115a (contained on a user device 105a) should correspond with the electronic transaction ledgers 115b . . . 115N (contained on user devices 105b . . . 105N), to the extent that the corresponding user device has accessed the Internet and been updated (e.g., downloaded the latest transactions). Accordingly, the electronic transaction ledger may be a public ledger. Exemplary embodiments of digital asset clients 110 for the Bitcoin network (Bitcoin clients) include Bitcoin-Qt and Bitcoin Wallet, to name a few. In embodiments, some of the transactions on the public ledger may be encrypted or otherwise shielded so that only authorized users may access ledger information about such transactions or wallets.

In addition, a digital asset network, such as a Bitcoin network, may include one or more digital asset exchange 130, such as Bitcoin exchanges (e.g., BitFinex, BTC-e). Digital asset exchanges may enable or otherwise facilitate the transfer of digital assets, such as bitcoin, and/or conversions involving digital assets, such as between different digital assets and/or between a digital asset and non-digital assets, currencies, to name a few. The digital asset network may also include one or more digital asset exchange agents 135, e.g., a Bitcoin exchange agent. Exchange agents 135 may facilitate and/or accelerate the services provided by the exchanges. Exchanges 130, transmitters 132, and/or exchange agents 135 may interface with financial institutions (e.g., banks) and/or digital asset users. Transmitters 132 can include, e.g., money service businesses, which could be licensed in appropriate geographic locations to handle financial transactions. In embodiments, transmitters 132 may be part of and/or associated with a digital asset exchange 130. Like the user devices 105, digital asset exchanges 130, transmitters 132, and exchange agents 135 may be connected to the data network 125 through wired, wireless, or other connections. They may be connected directly and/or indirectly to each other and/or to one or more user device 105 or other entity participating in the digital asset system.

Digital assets may be sub-divided into smaller units or bundled into blocks or baskets. For example, for bitcoin, subunits, such as a Satoshi, as discussed herein, or larger units, such as blocks of bitcoin, may be used in exemplary embodiments. Each digital asset, e.g., bitcoin, may be subdivided, such as down to eight decimal places, forming 100 million smaller units. For at least bitcoin, such a smaller unit may be called a Satoshi. Other forms of division can be made consistent with embodiments of the present invention.

In embodiments, the creation and transfer of digital math-based assets can be based on an open source mathematical and/or cryptographic protocol, which may not be managed by any central authority. Digital assets can be transferred between one or more users or between digital asset accounts and/or storage devices (e.g., digital wallets) associated with a single user, through a network, such as the Internet, via a computer, smartphone, or other electronic device without an intermediate financial institution. In embodiments, a single digital asset transaction can include amounts from multiple origin accounts transferred to multiple destination accounts. Accordingly, a transaction may comprise one or more input amounts from one or more origin digital asset accounts and one or more output amounts to one or more destination accounts. Origin and destination may be merely labels for identifying the role a digital asset account plays in a given transaction; origin and destination accounts may be the same type of digital asset account.

In embodiments, a digital math-based asset system may produce digital asset transaction change. Transaction change refers to leftover digital asset amounts from transactions in digital asset systems, such as Bitcoin, where the transactions are comprised of one or more digital inputs and outputs. A digital asset account can store and/or track unspent transaction outputs, which it can use as digital inputs for future transactions. In embodiments, a wallet, third-party system, and/or digital asset network may store an electronic log of digital outputs to track the outputs associated with the assets contained in each account. In digital asset systems such as Bitcoin, digital inputs and outputs cannot be subdivided. For example, if a first digital asset account is initially empty and receives a transaction output of 20 BTC (a bitcoin unit) from a second digital asset account, the first account then stores that 20 BTC output for future use as a transaction input. To send 15 BTC, the first account must use the entire 20 BTC as an input, 15 BTC of which will be a spent output that is sent to the desired destination and 5 BTC of which will be an unspent output, which is transaction change that returns to the first account. An account with digital assets stored as multiple digital outputs can select any combination of those outputs for use as digital inputs in a spending transaction. In embodiments, a digital wallet may programmatically select outputs to use as inputs for a given transaction to minimize transaction change, such as by combining outputs that produce an amount closest to the required transaction amount and at least equal to the transaction amount.

In embodiments, the present invention can be used to be compatable with the Libra Network and the Move Programming language as described in the following disclosures, each of which is hereby incorporated by reference herein: (1) Move: A Language With Programmable Resources (available at: https://developers.libra.org/docs/move-paper); (2) The Libra White Paper (available at: https://libra.org/en-US/white-paper/); (3) The Libra Reserve (available at: https://libra.org/en-US/about-currency-reserve/); (4) The Libra Association (available at: https://libra.org/en-US/association-council-principles/); (5) State Machine Replication in the Libra Blockchain (available at: https://developers.libra.org/docs/state-machine-replication-paper); (6) Moving Toward Permissionless Consensus (available at: https://libra.org/en-US/permissionless-blockchain/); and (7) The Libra Blockchain (available at: https://developers.libra.org/docs/the-libra-blockchain-paper).

Referring again to FIG. 1, a digital asset network may include digital asset miners 145. Digital asset miners 145 may perform operations associated with generating or minting new digital assets, and/or operations associated with confirming transactions, to name a few. Digital asset miners 145 may collaborate in one or more digital asset mining pools 150, which may aggregate power (e.g., computer processing power) so as to increase output, increase control, increase likelihood of minting new digital assets, increase likelihood of adding blocks to a blockchain, to name a few.

In embodiments, the processing of digital asset transactions, e.g., bitcoin transactions, can be performed by one or more computers over a distributed network, such as digital asset miners 145, e.g., bitcoin miners, and/or digital asset mining pools 150, e.g., bitcoin mining pools. In embodiments, mining pools 150 may comprise one or more miners 145, which miners 145 may work together toward a common goal. Miners 145 may have source code 120′, which may govern the activities of the miners 145. In embodiments, source code 120′ may be the same source code as found on user devices 105. These computers and/or servers can communicate over a network, such as an internet-based network, and can confirm transactions by adding them to a ledger 115, which can be updated and archived periodically using peer-to-peer file sharing technology. For example, a new ledger block could be distributed on a periodic basis, such as approximately every 10 minutes. In embodiments, the ledger may be a blockchain. Each successive block may record transactions that have occurred on the digital asset network. In embodiments, all digital asset transactions may be recorded as individual blocks in the blockchain. Each block may contain the details of some or all of the most recent transactions that are not memorialized in prior blocks. Blocks may also contain a record of the award of digital assets, e.g., bitcoin, to the miner 145 or mining pool 150 who added the new block, e.g., by solving calculations first.

A miner 145 may have a calculator 155, which may solve equations and/or add blocks to the blockchain. The calculator 155 may be one or more computing devices, software, or special-purpose device, to name a few. In embodiments, in order to add blocks to the blockchain, a miner 145 may be required to map an input data set (e.g., the blockchain, plus a block of the most recent transactions on the digital asset network, e.g., transactions on the Bitcoin network, and an arbitrary number, such as a nonce) to a desired output data set of predetermined length, such as a hash value. In embodiments, mapping may be required to use one or more particular cryptographic algorithms, such as the SHA-256 cryptographic hash algorithm or scrypt, to name a few. In embodiments, to solve or calculate a block, a miner 145 may be required to repeat this computation with a different nonce until the miner 145 generates a SHA-256 hash of a block's header that has a value less than or equal to a current target set by the digital asset network. In embodiments, each unique block may only be solved and added to the blockchain by one miner 145. In such an embodiment, all individual miners 145 and mining pools 150 on the digital asset network may be engaged in a competitive process and may seek to increase their computing power to improve their likelihood of solving for new blocks. In embodiments, successful digital asset miners 145 or mining pools 150 may receive an incentive, such as, e.g., a fixed number of digital assets (e.g., bitcoin) and/or a transaction fee for performing the calculation first and correctly and/or in a verifiable manner.

In embodiments, the cryptographic hash function that a miner 145 uses may be one-way only and thus may be, in effect, irreversible. In embodiments, hash values may be easy to generate from input data, such as valid recent network transaction(s), blockchain, and/or nonce, but neither a miner 145 nor other participant may be able to determine the original input data solely from the hash value. Other digital asset networks may use different proof of work algorithms, such as a sequential hard memory function, like scrypt, which may be used for Litecoin. As a result, generating a new valid block with a header less than the target prescribed by the digital asset network may be initially difficult for a miner 145, yet other miners 145 can easily confirm a proposed block by running the hash function at least once with a proposed nonce and other identified input data. In embodiments, a miner's proposed block may be added to the blockchain once a defined percentage or number of nodes (e.g., a majority of the nodes) on the digital asset network confirms the miner's work. A miner 145 may have a verifier 160, which may confirm other miners' work. A verifier 160 may be one or more computers, software, or specialized device, to name a few. A miner 145 that solved such a block may receive the reward of a fixed number of digital assets and/or any transaction fees paid by transferors whose transactions are recorded in the block. “Hashing” may be viewed as a mathematical lottery where miners that have devices with greater processing power (and thus the ability to make more hash calculations per second) are more likely to be successful miners 145. In embodiments, as more miners 145 join a digital asset network and as processing power increases, the digital asset network may adjust the complexity of the block-solving equation to ensure that one newly-created block is added to the blockchain approximately every ten minutes. Digital asset networks may use different processing times, e.g., approximately 2.5 minutes for Litecoin, approximately 10 minutes for Bitcoin, to name a few.

In addition to archiving transactions, a new addition to a ledger can create or reflect creation of one or more newly minted digital assets, such as bitcoin. In embodiments, new digital math-based assets may be created through a mining process, as described herein. In embodiments, the number of new digital assets created can be limited. For example, in embodiments, the number of digital assets (e.g., bitcoin) minted each year is halved every four years until a specified year, e.g., 2140, when this number will round down to zero. At that time no more digital assets will be added into circulation. In the exemplary embodiment of bitcoin, the total number of digital assets will have reached a maximum of 21 million assets in denomination of bitcoin. Other algorithms for limiting the total number of units of a digital math-based asset can be used consistent with exemplary embodiments of the present invention. For example, the Litecoin network is anticipated to produce 84 million Litecoin. In embodiments, the number of digital assets may not be capped and thus may be unlimited. In embodiments, a specified number of coins may be added into circulation each year, e.g., so as to create a 1% inflation rate.

In embodiments, the mining of digital assets may entail solving one or more mathematical calculations. In embodiments, the complexity of the mathematical calculations may increase over time and/or may increase as computer processing power increases. In embodiments, result of solving the calculations may be the addition of a block to a blockchain, which may be a transaction ledger, as described further below. Solving the calculations may verify a set of transactions that has taken place. Solving the calculations may entail a reward, e.g., a number of digital math-based assets and/or transaction fees from one or more of the verified transactions.

Different approaches are possible for confirming transactions and/or creating new assets. In embodiments, a digital asset network may employ a proof of work system. A proof of work system may require some type of work, such as the solving of calculations, from one or more participants (e.g., miners 145) on the network to verify transactions and/or create new assets. In embodiments, a miner 145 can verify as many transactions as computationally possible. A proof of work system may be computationally and/or energy intensive. In embodiments, the network may limit the transactions that a miner 145 may verify.

In embodiments, a digital asset network may employ a proof of stake system. In a proof of stake system, asset ownership may be tied to transaction verification and/or asset creation. Asset ownership can include an amount of assets owned and/or a duration of ownership. The duration of ownership may be measured linearly as time passes while a user owns an asset. In an exemplary embodiment, a user holding 4% of all digital assets in a proof of stake system can generate 4% of all blocks for the transaction ledger. A proof of stake system may not require the solution of complex calculations. A proof of stake system may be less energy intensive than a proof of work system. In embodiments, a hybrid of proof of work and proof of stake systems may be employed. For example, a proof of work system may be employed initially, but as the system becomes too energy intensive, it may transition to a proof of stake system.

Proof or work and proof of stake are both examples of consensus algorithms. Such consensus algorithms have as their goal providing a method of reaching consensus to improve the system whether it be on ways of improving transactions, upgrading the network, etc.

In embodiments, asset creation and/or transaction confirmation can be governed by a proof of stake velocity system. Proof of stake velocity may rely upon asset ownership where the function for measuring duration of ownership is not linear. For example, an exponential decay time function may ensure that assets more newly held correspond to greater power in the system. Such a system can incentivize active participation in the digital math-based asset system, as opposed to storing assets passively.

In embodiments, a proof of burn system may be employed. Proof of burn may require destroying assets or rendering assets unspendable, such as by sending them to an address from which they cannot be spent. Destroying or rendering assets unusable can be an expensive task within the digital math-based asset system, yet it may not have external costs such as the energy costs that can be associated with mining in a proof of work system.

Blockchains can include a consensus generating protocol through which the network determines whether a transaction is valid, included in the ledger and in what order each transaction should be included. Examples of such facilities, can include mining, proof of work, proof of stake protocols, to name a few.

In embodiments, a stable value digital asset token, or Stable Value Token (“SVCoin”) may operate on a blockchain based network, such as the Ethereum network, a decentralized virtual currency and blockchain network with a programming language that can automatically facilitate, verify, and enforce the terms of a digital contract entered into by human or computer counterparties. In embodiments, the SVCoin may conform with the ERC-223 token standard, making it available for a variety of uses within the Ethereum Network. In embodiments, the SVCoin may conform to the ERC-721 token standard. However, unlike other types of cryptocurrencies currently available on the Ethereum Network or the virtual currency ecosystem generally, the SVCoin will be strictly pegged to a fiat currency, such as the U.S. Dollar, and a custodian, such as a trusted entity like a digital asset exchange or bank, to name a few, will hold an equal value in fiat (e.g., one (1) SVCoin is pegged to be equal to one (1) USD or one hundred (199(SVCoin is pegged to equal one (1) USD, to name a few).

In embodiments, a digital asset exchange, such as a regulated digital asset exchange, like Gemini, may be the sole issuer of the SVCoin. In embodiments, especially in the context of a regulated digital asset exchange, in order to obtain freshly minted SVCoin, customers must first register with the digital asset exchange and create an exchange account to allow access to the digital asset exchange platform. Customers may deposit fiat (e.g., USD) with the digital asset exchange, via, e.g., Fedwire, ACH, Swift, to name a few, into the customers respective exchange account, or convert into fiat some or all of existing digital assets held at the digital asset exchange. SVCoin may be held in the customer's exchange account or may be transferred via the blockchain, such as via the Ethereum Network. In embodiments, the SVCoin issuer may be a digital asset exchange, a bank, a trust or some other trusted entity, to name a few.

In embodiments, regardless of whether the SVCoin is stored in the customer's exchange account or transferred via the blockchain such as the Ethereum Network, the digital exchange will continue to hold sufficient fiat to maintain the total value of SVCoin based on a notional pegged rate (e.g., one USD for every one SVCoin issued). In embodiments, the value of the SVCoin is pegged to the fiat in a fixed proportion, for example 1:1. In embodiments, fiat will be held in a segregated, omnibus bank account at one or more federally insured depository institution. In embodiments, the fiat may be held in other secure and non-volatile financial instruments, such as invested in treasury bills or other liquid, interest bearing financial instruments.

In embodiments, customers wishing to redeem their SVCoin for fiat may do so through the digital asset platform. Customers that have transferred their SVCoin to the blockchain will be able to transfer their SVCoin back to their exchange account, and subsequently redeem them for fiat through the digital exchange platform, such as via Fedwire, ACH or SWIFT to the customer's registered bank account, to name a few. For each fiat redeemed with the digital exchange, a corresponding SVCoin will be removed from circulation. As mentioned above, exemplary embodiments of such transactions are discussed below in connection with the descriptions of FIGS. 65A-1-4, 65B-1-4, and 65C-1-2.

In embodiments, the Stable Value Token may be implemented as a token on the Ethereum blockchain, following the open standard known as ERC20 adopted by the Ethereum community. In embodiments, the Stable Value Token may be a system of smart contracts. In embodiments, the Stable Value Token may be a triplet of smart contracts on the Ethereum blockchain, which may be referred to as ‘Proxy’, ‘Impl’, and ‘Store’.

In embodiments, the smart contract known as ‘Proxy’ is the permanent and public face of the Stable Value Token and provides the interface to interact with the token to allow token holders transfer their tokens and view token balances. In embodiments, however, this contract contains neither the code nor the data that comprises the behavior and state of the Stable Value Token.

In embodiments, the ‘Proxy’ contract delegates to the contract known as ‘Impl’ authority to execute the logic that governs token transfers, issuance, and other core features. In embodiments, ‘Impl’ does not directly own the data that is the ledger of the Stable Value Token, the mapping of token holders to their balances, but instead delegates this to the smart contract known as ‘Store’.

In embodiments, the arrangement of ‘Proxy’, ‘Impl’, and ‘Store’ provides for future change and flexibility. While ‘Proxy’ may be the permanent address of the Stable Value Token on the Ethereum blockchain, and ‘Store’ is the external storage of the token ledger, the ‘Impl’ contract is designed to be replaced, if need be. Utilizing this architecture to implement the Stable Value Token provides for the following advantages:

- 1. allows for responding to security incidents and resolving vulnerabilities;
- 2. allows for extending the system with new features;
- 3. allows for adding later optimizations to improve the operational efficiency of the token; and
- 4. In extreme cases and when compelled to do so, allows for pause, block, or reverse token transfers.

In embodiments, each of these three contracts has a custodian: an actor in the system that has the sole authority to authorize important actions. In embodiments, the custodianship role varies for each of ‘Proxy’, ‘Impl’, and ‘Store’. In embodiments, the custodian of ‘Proxy’ can redirect the delegation to the active token implementation, the specific ‘Impl’ contract. In embodiments, matching this arrangement, the ‘Store’ contract may only accept updates to its ledger from a single trusted source, the active token implementation, the specific ‘Impl’ contract. In embodiments, these two custodial actions on ‘Proxy’ and ‘Store’ provide the upgrade feature where a new ‘Impl’ displaces the prior version by the custodian of ‘Proxy’ redirecting the delegation in ‘Proxy’; and a new ‘Impl’ displaces the prior version by the custodian of ‘Store’ updating the trusted caller of ‘Store’. In embodiments, the custodians of ‘Proxy’ and ‘Store’ can also pass custodianship to new custodians.

In embodiments, the primary custodial action on the ‘Impl’ contract is different. In embodiments, an important aspect of the Stable Value Tokens is governing the increase to the token supply since at all times the system must ensure that there are at least as many U.S. Dollars as there are Stable Value Tokens in circulation. In embodiments, the ‘Impl’ contract contains the logic to increase the token supply, and the custodian of ‘Impl’ has the sole authority to invoke it. In embodiments, custodianship can also be passed.

In embodiments, an auxiliary contract is a contract to fulfil the custodian role, which we will refer to here as ‘Custodian’. In embodiments, this contract is designed around several security principles:

- 1. Dual Control: actions by the ‘Custodian’ contract are initially locked, and pending actions will only proceed once two out of a set of designated signers approve the action. (Approval is a digital signature linked to the action instructions, e.g. the amount and destination of new tokens.)
- 2. Offline Control: the ‘Custodian’ contract is designed with the expectation that the set of designated signers are keys managed by offline (“air gapped”) computer systems.
- 3. Time Locks: actions by the ‘Custodian’ contract are locked not only pending approval from two signers, but also require the passage of a minimum period of time before they can be executed. This enables the effective use of intrusion detection systems and a window of opportunity to respond to security breaches.
- 4. Revocation: pending actions can be revoked, thus erroneous or malicious actions can be nullified while they are still pending.

This provides strong security control on custodianship, which is appropriate for the critical and infrequent system actions of replacing the ‘Impl’ contract (“the upgrade feature”) and passing custodianship. In embodiments, however, for the action of increasing the token supply, an action expected to occur frequently, using ‘Custodian’ as the custodian of ‘Impl’ introduces an undue operational burden.

In embodiments, a second auxiliary contract, is referred to as ‘PrintLimiter’. In embodiments, the purpose of the ‘PrintLimiter’ smart contract is to govern the increases to the supply of Stable Value Tokens, specifically by a hybrid of online and offline control. While ‘Custodian’ is the custodian of the contracts ‘Proxy’ and ‘Store’, the ‘PrintLimiter’ contract is the custodian of ‘Impl’, and in turn, ‘Custodian’ is the custodian of ‘PrintLimiter’. In embodiments, this doubly-layered custodianship relationship still reserves ultimate control to ‘Custodian’, however, the ‘PrintLimiter’ contract grants limited permission to increase the token supply (“print” new tokens) to a key in online control (an automated, networked computer system), which we will refer to as ‘printer’. In embodiments, the ‘printer’ key can increase the token supply in response to user demand to withdraw U.S. dollars as Stable Value Tokens, but only up until a ceiling. In embodiments, further expansion of the supply is disallowed by ‘PrintLimiter’ once the ceiling is reached. In embodiments, increasing the ceiling is an action reserved for the custodian, and the custodian of ‘PrintLimiter’ is ‘Custodian.’ In embodiments, the ‘printer’ can reduce the ceiling thus reducing its own grant. In embodiments, offline control can increase the grant to online control; online control can decrease its own grant. In embodiments, the arrangement discussed herein achieves a hybrid of online and offline control over the supply of Stable Value Tokens. In embodiments, tokens can be issued in an efficient and timely manner, while the risk of inflation of the supply of Stable Value Tokens without backing U.S. Dollars is bounded.

In embodiments, as noted above, multiple signatures may be required for certain transactions such as those requiring intervention of the Custodian 1350. In embodiments, as noted above, changing the implementation pointer from ERC20Proxy 1310 which is currently set at S1312 (impl) to point to ERC20Impl 1320 (Version 1), requires resetting S1312B “impl” to point to ERC20Impl 1320A (version 2). In embodiments, a request is made to ERC20Proxy to change its instance of ERC20Impl. When the request is made, a unique lockId is generated. In embodiments, the Custodian contract 1350 for ERC20 Proxy 1310 calls requestUnlock and passes as arguments the lockId generated for the change request, and the function in ERC20Proxy 1310 the Custodian 1350 needs to call to confirm the change request. This generates a request, which is a unique identifier for this unlock request.

In embodiments, to complete the unlocking of Custodian and therefore propagate the change to ERC20Proxy 1310, the digital asset system operated by the token issuer uses its off-line key storage infrastructure to sign the request with the previously approved designated key sets. This may require the use of two or more key sets.

In embodiments, those signatures are passed into the Custodian's completeUnlock function along with the initial request. Once the request is validated against the signatures, completeUnlock parses the content of the request and issues the command. In this exemplary case, it calls ERC20Proxy's confirmImplChange using the lockId generated in the initial ERC20Impl change request.

In embodiments, the arrangement discussed herein achieves a hybrid of online and offline control over the supply of Stable Value Tokens. In embodiments, tokens can be issued in an efficient and timely manner, while the risk of inflation of the supply of Stable Value Tokens without backing U.S. Dollars is bounded. In embodiments, pending actions may be revoked, allowing for the nullification of erroneous or malicious actions before being executed.

In embodiments, a digital asset in the form of a token (“Security Token”) may be issued to represent inventory, equity interests in a venture, real estate, rights in intellectual property such music, videos, pictures, to name a few. When used as a security, appropriate filings with a regulatory authority may be necessary to comply with local law. In the case of a security, investors may exchange fiat or other digital assets (such as bitcoin or ether, to name a few) in exchange for Security Tokens. Typically, Security Tokens may issue using a smart contract written on another digital asset (such as ether or bitcoin, to name a few), and tracked in a separate database stored in a distributed peer to peer network in the form of a blockchain. In an example, the blockchain is the Ethereum Blockchain and includes all Security Tokens, the respective address associated therewith, wherein maintenance of the blockchain is controlled by contract instructions stored in the form of a smart contract at the Contract Address. In embodiments, the Secure Token database maintained on the blockchain may be viewed via etherscan.io. In embodiments, the Security Token ledger may be maintained as a sidechain in a separate database off chain and published periodically or aperiodically to the blockchain. Each Security Token may also be associated with a specific digital asset address on the network associated with the underlying digital asset (e.g., the Ethereum Network when ether is the underlying digital asset, or the Bitcoin Network, when bitcoin is the digital asset, to name a few). Generally, the same blockchain will be used for the SVCoin and the Security Token.

Digital assets may be associated with a digital asset account, which may be identified by a digital asset address. A digital asset account can comprise at least one public key and at least one private key, e.g., based on a cryptographic protocol associated with the particular digital asset system, as discussed herein. One or more digital asset accounts may be accessed and/or stored using a digital wallet, and the accounts may be accessed through the wallet using the keys corresponding to the account.

A digital asset account identifier and/or a digital wallet identifier may comprise a public key and/or a public address. Such a digital asset account identifier may be used to identify an account in transactions, e.g., by listing the digital asset account identifier on a decentralized electronic ledger (e.g., in association with one or more digital asset transactions), by specifying the digital asset account identifier as an origin account identifier, and/or by specifying the digital asset account identifier as a destination account identifier, to name a few. The systems and methods described herein involving public keys and/or public addresses are not intended to exclude one or the other and are instead intended generally to refer to digital asset account identifiers, as may be used for other digital math-based asset. A public key may be a key (e.g., a sequence, such as a binary sequence or an alphanumeric sequence) that can be publicly revealed while maintaining security, as the public key alone cannot decrypt or access a corresponding account. A public address may be a version of a public key. In embodiments, a public key may be generated from a private key, e.g., using a cryptographic protocol, such as the Elliptic Curve Digital Signature Algorithm (“ECDSA”).

In exemplary embodiments using bitcoin, a public key may be a 512-bit key, which may be converted to a 160-bit key using a hash, such as the SHA-256 and/or RIPEMD-160 hash algorithms. The 160-bit key may be encoded from binary to text, e.g., using Base58 encoding, to produce a public address comprising non-binary text (e.g., an alphanumeric sequence). Accordingly, in embodiments, a public address may comprise a version (e.g., a shortened yet not truncated version) of a public key, which may be derived from the public key via hashing or other encoding. In embodiments, a public address for a digital wallet may comprise human-readable strings of numbers and letters around 34 characters in length, beginning with the digit 1 or 3, as in the example of 175tWpb8K1S7NmH4Zx6rewF9WQrcZv245 W. The matching private key may be stored in a digital wallet or mobile device and protected by a password or other techniques and/or devices for providing authentication.

In embodiments, other cryptographic algorithms may be used such as:

- (1) The elliptic curve Diffie-Hellman (ECDH) key agreement scheme;
- (2) The Elliptic Curve Integrated Encryption Scheme (ECIES), also known as Elliptic Curve Augmented Encryption Scheme or simply the Elliptic Curve Encryption Scheme;
- (3) The Elliptic Curve Digital Signature Algorithm (ECDSA) which is based on the Digital Signature Algorithm;
- (4) The deformation scheme using Harrison's p-adic Manhattan metric;
- (5) The Edwards-curve Digital Signature Algorithm (EdDSA) which is based on Schnorr signature and uses twisted Edwards curves;
- (6) The ECMQV key agreement scheme which is based on the MQV key agreement scheme; and
- (7) The ECQV implicit certificate scheme.

In other digital asset networks, other nomenclature mechanisms may be used, such as a human-readable string of numbers and letters around 34 characters in length, beginning with the letter L for Litecoin or M or N for Namecoin or around 44 characters in length, beginning with the letter P for PPCoin, to name a few.

A private key in the context of a digital math-based asset, such as bitcoin, may be a sequence such as a number that allows the digital math-based asset, e.g., bitcoin, to be transferred or spent. In embodiments, a private key may be kept secret to help protect against unauthorized transactions. In a digital asset system, a private key may correspond to a digital asset account, which may also have a public key or other digital asset account identifier. While the public key may be derived from the private key, the reverse may not be true.

In embodiments related to the Bitcoin system, every Bitcoin public address has a matching private key, which can be saved in the digital wallet file of the account holder. The private key can be mathematically related to the Bitcoin public address and can be designed so that the Bitcoin public address can be calculated from the private key, but importantly, the same cannot be done in reverse. In the event that a transaction is sent to a Bitcoin public address and signed by a private key that does not match, such transaction will not be processed by the Bitcoin blockchain.

A digital asset account, such as a multi-signature account, may require a plurality of private keys to access it. In embodiments, any number of private keys may be required. An account creator may specify the number of required keys (e.g., 2, 3, 5, to name a few) when generating a new account. More keys may be generated than are required to access and/or use an account. For example, 5 keys may be generated, and any combination of 3 of the 5 keys may be sufficient to access a digital asset account. Such an account setup can allow for additional storage and security options, such as backup keys and multi-signature transaction approval, as described herein.

Because a private key provides authorization to transfer or spend digital assets such as bitcoin, security of the private key can be important. Private keys can be stored via electronic computer files, but they may also be short enough that they can be printed or otherwise written on paper or other media. An example of a utility that allows extraction of private keys from an electronic wallet file for printing purposes is Pywallet. Other extraction utilities may also be used consistent with the present invention.

In embodiments, a private key can be made available to a program or service that allows entry or importing of private keys in order to process a transaction from an account associated with the corresponding public key. Some wallets can allow the private key to be imported without generating any transactions while other wallets or services may require that the private key be swept. When a private key is swept, a transaction is automatically broadcast so that the entire balance held by the private key is sent or transferred to another address in the wallet and/or securely controlled by the service in question.

In embodiments, using Bitcoin clients, such as BlockChain.info's My Wallet service and Bitcoin-QT, a private key may be imported without creating a sweep transaction.

In embodiments, a private key, such as for a Bitcoin account, may be a 256-bit number, which can be represented in one or more ways. For example, a private key in a hexadecimal format may be shorter than in a decimal format. For example, 256 bits in hexadecimal is 32 bytes, or 64 characters in the range 0-9 or A-F. The following is an example of a hexadecimal private key:

- E9 87 3D 79 C6 D8 7D C0 FB 6A 57 78 63 33 89 F4 45 32 13 30 3D A6 1F 20 BD 67 FC 23 3A A3 32 62

In embodiments, nearly every 256-bit number is a valid private key. Specifically, any 256-bit number between 0x1 and 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141 is a valid private key. In embodiments, the range of valid private keys can be governed by the secp256k1 ECDSA standard used by Bitcoin. Other standards may also be used.

In embodiments, a shorter form of a private key may be used, such as a base 58 Wallet Import format, which may be derived from the private key using Base58 and/or Base58Check encoding. The Wallet Import format may be shorter than the original private key and can include built-in error checking codes so that typographical errors can be automatically detected and/or corrected. For private keys associated with uncompressed public keys, the private key may be 51 characters and may start with the number 5. For example, such a private key may be in the following format:

- 5Kb 8kLf9zgWQnogidDA76MzPL6TsZZY36hWXMssSzNydYXYB9KF

In embodiments, private keys associated with compressed public keys may be 52 characters and start with a capital L or K.

In embodiments when a private key is imported, each private key may always correspond to exactly one Bitcoin public address. In embodiments, a utility that performs the conversion can display the matching Bitcoin public address.

The Bitcoin public address corresponding to the sample above is:

- 1CC3X2gu58d6wXUWMffpuzN9JAfTUWu4Kj

In embodiments, a mini private key format can be used. Not every private key or Bitcoin public address has a corresponding mini private key; they have to be generated a certain way in order to ensure a mini private key exists for an address. The mini private key is used for applications where space is critical, such as in QR codes and in physical bitcoin. The above example has a mini key, which is:

- SzavMBLoXU6kDrqtUVmffv

In embodiments, any bitcoin sent to the designated address 1CC3X2gu58d6wXUWMffpuzN9JAfTUWu4Kj can be transferred or spent by anybody who knows the private key in any of the three formats (e.g., hexadecimal, base 58 wallet format, or mini private key). That includes bitcoin presently at the address, as well as any bitcoin that are ever sent to it in the future. The private key is only needed to transfer or spend the balance, not necessarily to see it. In embodiments, the bitcoin balance of the address can be determined by anybody with the public Block Explorer at http://www.blockexplorer.com/address/1CC3X2gu58d6wXUWMffpuzN9JAfTUWu4Kj—even if without access to the private key.

In embodiments, a private key may be divided into segments, encrypted, printed, and/or stored in other formats and/or other media, as discussed herein.

In embodiments, digital math-based assets can be stored and/or transferred using either a website or software, such as downloaded software. The website and/or downloadable software may comprise and/or provide access to a digital wallet. Each digital wallet can have one or more individual digital asset accounts (e.g., digital asset addresses) associated with it. Each user can have one or more digital wallets to store digital math-based assets, digital crypto-currency, assets and the like and/or perform transactions involving those currencies or assets. In embodiments, service providers can provide services that are tied to a user's individual account.

Digital wallets and/or the digital asset accounts associated with and/or stored by a digital wallet may be accessed using the private key (which may be used in conjunction with a public key or variant thereof). Accordingly, the generation, access, use, and storage of digital asset accounts is described herein with respect to generation, access, use, and storage of digital wallets. Such descriptions are intended to be representative of digital asset accounts and not exclusive thereof.

A digital wallet can be generated using a digital asset client 110 (e.g., a Bitcoin client). In embodiments, a digital wallet can be created using a key pair system, such as an asymmetric key pair like a public key and a private key. The public key can be shared with others to designate the address of a user's individual account and/or can be used by registries and/or others to track digital math-based asset transactions involving a digital asset account associated with the digital wallet. Such transactions may be listed or otherwise identified by the digital wallet. The public key may be used to designate a recipient of a digital asset transaction. A corresponding private key can be held by the account holder in secret to access the digital wallet and perform transactions. In embodiments, a private key may be a 256-bit number, which can be represented by a 64-character hexadecimal private key and/or a 51-character base-58 private key. As discussed herein, private keys of other lengths and/or based on other numbering systems can be used, depending upon the user's desire to maintain a certain level of security and convenience. Other forms of key pairs, or security measures can be used consistent with embodiments of the present invention.

In embodiments, a digital wallet may store one or more private keys or one or more key pairs which may correspond to one or more digital asset accounts.

In embodiments, a digital wallet may be a computer software wallet, which may be installed on a computer. The user of a computer software wallet may be responsible for performing backups of the wallet, e.g., to protect against loss or destruction, particularly of the private and/or public key. In embodiments, a digital wallet may be a mobile wallet, which may operate on a mobile device (e.g., mobile phone, smart phone, cell phone, iPod Touch, PDA, tablet, portable computer, to name a few). In embodiments, a digital wallet may be a website wallet or a web wallet. A user of a web wallet may not be required to perform backups, as the web wallet may be responsible for storage of digital assets. Different wallet clients may be provided, which may offer different performance and/or features in terms of, e.g., security, backup options, connectivity to banks or digital asset exchanges, user interface, and/or speed, to name a few.

In embodiments, a digital wallet may be a custodial digital wallet. Further, the custodial digital wallet may be a segregated custodial wallet or a commingled custodial wallet. Segregated custodial digital wallets hold digital assets for the benefit of a single customer or entity. Commingled custodial accounts hold digital assets for multiple users or customers of the custodian. Segregated custodial wallets are useful for institutional clients, mutual funds and hedge funds, for example.

While many digital asset holders may hold their digital assets in their own wallets, various custodial services, like Gemini custodial services exist. In embodiments, the present invention may be used with custodial wallets. In embodiments, custodial wallets may be commingled custodial wallets which commingle digital assets from more than one client. In embodiments, custodial wallets may be segregated custodial wallets, in which digital assets for a specific client is held using one or more unique digital asset addresses maintained by the custodial service. For segregated custodial wallets, the amount of digital assets held in such wallet(s) may be verified and audited on their respective blockchain. In embodiments, segregated custodial accounts may be used for digital asset holders such as hedge funds, mutual funds, exchange traded funds, to name a few. Proof of control as described herein may be implemented to verify the amount of assets held in custodial wallets, including both segregated custodial wallets and commingled custodial wallets.

A transaction may require, as a precondition to execution, a digital asset signature generated using a private key and associated public key for the digital asset account making the transfer. In embodiments, each transaction can be signed by a digital wallet or other storage mechanism of a user sending a transaction by utilizing a private key associated with such a digital wallet. The signature may provide authorization for the transaction to proceed, e.g., authorization to broadcast the transaction to a digital asset network and/or authorization for other users in a digital asset network to accept the transaction. A signature can be a number that proves that a signing operation took place. A signature can be mathematically generated from a hash of something to be signed, plus a private key. The signature itself can be two numbers such as r and s. With the public key, a mathematical algorithm can be used on the signature to determine that it was originally produced from the hash and the private key, without needing to know the private key. Signatures can be either 73, 72, or 71 bytes long, to name a few.

In embodiments, the ECDSA cryptographic algorithm may be used to ensure that digital asset transactions (e.g., bitcoin transactions) can only be initiated from the digital wallet holding the digital assets (e.g., bitcoin). Alternatively, or in addition, other algorithms may be employed.

In embodiments, a transaction from a multi-signature account may require digital asset signatures from a plurality of private keys, which may correspond to the same public key and/or public address identifying the multi-signature digital asset account. As described herein, a greater number of private keys may be created than is necessary to sign a transaction (e.g., 5 private keys created and only 3 required to sign a transaction). In embodiments, private keys for a multi-signature account may be distributed to a plurality of users who are required to authorize a transaction together. In embodiments, private keys for a multi-signature account may be stored as backups, e.g., in secure storage, which may be difficult to access, and may be used in the event that more readily obtainable keys are lost. As noted above, there are a variety of cryptographic algorithms that may be used.

A digital asset market place, such as a Bitcoin market place, can comprise various participants, including users, vendors, exchanges, exchange agents, and/or miners/mining pools. The market contains a number of digital asset exchanges, which facilitate trade of digital assets using other currencies, such as United States dollars. Exchanges may allow market participants to buy and sell digital assets, essentially converting between digital assets (e.g., bitcoin) and currency, legal tender, and/or traditional money (e.g., cash). In embodiments, a digital asset exchange market can include a global exchange market for the trading of digital assets, which may contain transactions on electronic exchange markets. In embodiments, a digital asset exchange market can also include regional exchange markets for the trading of digital assets, which may contain transactions on electronic exchange markets. In accordance with the present invention, exchanges and/or transmitters may also be used to facilitate other transactions involving digital assets, such as where digital assets are being transferred from differently denominated accounts or where the amount to transfer is specified in a different denomination than the digital asset being transferred, to name a few. Gemini Trust Company LLC (“Gemini”) at (www.gemini.com) is an example of a digital asset exchange 130. By example, registered users of Gemini may buy and sell digital assets such as Bitcoin and Ether in exchange for fiat such as U.S. dollars or other digital assets, such as Ether and Bitcoin, respectively. A Bitcoin exchange agent 135 can be a service that acts as an agent for exchanges, accelerating the buying and selling of bitcoin as well as the transfer of funds to be used in the buying and/or selling of bitcoin. Coinbase is an example of a company that performs the role of a Bitcoin exchange agent 135. Coinbase engages in the retail sale of bitcoin, which it obtains, at least in part, from one or more exchanges. FIG. 3 illustrates an exemplary Coinbase website interface for buying bitcoin. Other Coinbase options include “Sell Bitcoin,” “Send Money,” “Request Money,” and “Recurring Payments.” Other options could also be made available consistent with exemplary embodiments of the present invention.

In addition to the services that facilitate digital asset transactions and exchanges with cash, digital asset transactions can occur directly between two users. In exemplary uses, one user may provide payment of a certain number of digital assets to another user. Such a transfer may occur by using digital wallets and designating the public key of the wallet to which funds are being transferred. As a result of the capability, digital assets may form the basis of business and other transactions. Digital math-based asset transactions may occur on a global scale without the added costs, complexities, time and/or other limits associated with using one or more different currencies.

Vendors 140 may accept digital assets as payment. A vendor 140 may be a seller with a digital wallet that can hold the digital asset. In embodiments, a vendor may use a custodial wallet. In embodiments, a vendor 140 may be a larger institution with an infrastructure arranged to accept and/or transact in digital assets. Various vendors 140 can offer banknotes and coins denominated in bitcoin; what is sold is really a Bitcoin private key as part of the coin or banknote. Usually, a seal has to be broken to access the Bitcoin private key, while the receiving address remains visible on the outside so that the bitcoin balance can be verified. In embodiments, a debit card can be tied to a Bitcoin wallet to process transactions.

In embodiments, one form of trusted entity that may be an issuer of tokens or an agent of the issuer is a digital asset exchange or bank. In embodiments, the trusted entity may maintain a token database on a blockchain. In embodiments, the trusted entity may maintain the token database off chain as a sidechain which may be periodically or aperiodically published to a blockchain as discussed elsewhere.

In some embodiments, the trusted entity may be a digital asset exchange. A digital asset exchange, such as a digital math-based asset exchange, may allow users to sell digital assets in exchange for any other digital assets or fiat currency and/or may allow users to sell fiat currency in exchange for any digital assets. Accordingly, an exchange may allow users to buy digital assets in exchange for other digital assets or fiat currency and/or to buy fiat currency in exchange for digital assets. In embodiments, a digital asset exchange may integrate with a foreign exchange market or platform. A digital asset exchange may be configured as a centralized exchange or a decentralized exchange, as discussed herein.

In embodiments, the issuer of the SVCoin may be a digital asset exchange, a bank, a trust, or other trusted entity. In the context where a digital asset exchange may act as an issuer for token, or as an agent of the issuer, a digital asset exchange computer system may maintain a ledger as one or more databases associated with the token. Such a database may include an electronic log of all transactions, including the source wallet, the destination wallet, the timestamp of the transaction, the amount of the transaction (e.g., the number of tokens), and/or the balance in each wallet before and/or after the transaction. In embodiments, the database may include a list of wallet addresses and balances in each wallet of the token. In embodiments, the issuer may maintain the database by using a smart contract in association with a Contract Digital Address as part of a blockchain network, such as the Ethereum Network. In embodiments, the ledger may be maintained in a database as a sidechain which is periodically, or aperiodically, published to a blockchain such as the Ethereum blockchain. In embodiments, the ledger may be maintained directly on the blockchain.

FIG. 26 is a schematic diagram illustrating various potential participants in a digital asset exchange, in exemplary embodiments. The participants may be connected directly and/or indirectly, such as through a data network 15, as discussed herein. Users of a digital asset exchange may be customers of the exchange, such as digital asset buyers and/or digital asset sellers. Digital asset buyers may pay fiat (e.g., U.S. Dollars, Euros, Yen, to name a few) in exchange for digital assets (e.g., bitcoin, ether, litecoin, dogecoin, to name a few). Digital asset sellers may exchange digital assets (e.g., bitcoin, ether, litecoin, dogecoin, to name a few) for fiat (e.g., U.S. Dollars, Euro, Yen, to name a few). In embodiments, instead of fiat, other forms of digital assets may also be used.

In embodiments, users may connect to the exchange through one or more user electronic devices 3202 (e.g., 3202-1, 3202-2, . . . , 3202-N), such as computers, laptops, tablet computers, televisions, mobile phones, smartphones, and/or PDAs, to name a few. A user electronic device 3202 may access, connect to, and/or otherwise run one or more user digital wallets 3204. In embodiments, buyers and/or sellers may access the exchange using their own electronic devices and/or through a digital asset kiosk. A digital asset enabled kiosk can receive cash, including notes, coins or other legal tender, (of one or more fiat currencies) from a buyer to use in buying a quantity of digital assets. A digital asset kiosk may dispense cash (of one or more fiat currencies) to a seller of digital assets. In embodiments, a digital asset kiosk may receive funds from and/or dispense funds to a card, such as a prepaid or reloadable card, or digital asset address associated with a digital wallet, or electronic account. In embodiments, a digital wallet may be stored on a user electronic device, such as a mobile electronic device, or other computing device.

Users may also have user bank accounts 3208 (e.g., 3208-1, 3208-2, . . . , 3208-N) held at one or more banks 3206 (e.g., 3206-1, 3206-2, . . . , 3206-N). In embodiments, users may be able to access their bank accounts from a user electronic device 3202 and/or from a digital wallet 3204 or digital address associated therewith.

A digital asset exchange computer system 3210 can include software running on one or more processors, as discussed herein, as well as computer-readable memory comprising one or more database. A digital asset exchange can include one or more exchange digital wallets 3212, e.g., digital wallet 3212-A. Exchange digital wallets may be used to store digital assets in one or more denominations from one or more parties to a transaction. In embodiments, exchange digital wallets may store digital assets owned by the exchange, which may be used where an exchange is a counter-party to an exchange transaction, which can allow exchange transactions to occur even when a buyer and a seller are not otherwise both available and in agreement on transaction terms.

A digital asset exchange may have one or more bank accounts, e.g., bank account 3216-A, held at one or more banks 3214, such as exchange banks or exchange partner banks, which are banks associated with and/or in partnership with the exchange. In embodiments, exchanges may access other repositories for fiat currency. An exchange bank account may be a pass-through account that receives fiat currency deposits from a digital asset buyer and transfers the fiat currency to a digital asset seller. The exchange bank account may hold money in escrow while an exchange transaction is pending. For example, the exchange bank account may hold a digital asset buyer's fiat currency until a digital asset seller transfers digital assets to the buyer, to an exchange, or to an authorized third party. Upon receipt by the appropriate recipient of the requisite amount of digital assets, the exchange may authorize the release of the fiat currency to the digital asset seller. In embodiments, an exchange may hold, e.g., as custodian, fiat in bank accounts and digital assets in digital wallets at associated digital asset addresses. In embodiments, instead of using bank accounts, other stable investment instruments such as money market mutual funds, treasury bills, certificates of deposits, low risk bonds, to name a few, may be used.

FIG. 27A is another schematic diagram illustrating entities associated with a digital asset exchange in an exemplary embodiment of the present invention. Each entity may operate one or more computer systems. Computer systems may be connected directly or indirectly, such as through a data network. Entities associated with a digital asset exchange can include the exchange, an exchange computer system 3230, customer digital asset wallets at associated digital asset addresses 3222 (e.g., bitcoin wallets, ether wallets, to name a few), customer bank(s) 3224 having a customer fiat bank account(s) 3226, a digital asset network ledger 3228 (e.g., the Bitcoin blockchain, the Ethereum blockchain, to name a few), a digital asset network (e.g., the Bitcoin network), one or more exchange customers using one or more customer user devices 3232, an exchange digital asset electronic ledger 3234, one or more exchange digital asset vaults 3238, an exchange fiat electronic ledger 3236, and one or more exchange partner banks 3242, which can have exchange pooled customer fiat accounts 3244. The exchange digital asset vaults 3238 can store a plurality of digital asset wallets, which may be pooled exchange customer wallets 3240 with associated digital asset addresses. In embodiments, the exchange may have a single partner bank 3242 with a pooled exchange customer fiat account 3244. Such an account may be associated with insurance protection.

The exchange may employ an electronic ledger system to track customer digital assets and/or customer fiat holdings. Such a system may allow rapid electronic transactions among exchange customers and/or between exchange customers and the exchange itself using its own digital asset and fiat holdings or those of its sponsor or owner. In embodiments, the electronic ledger system may facilitate rapid computer-based automated trading, which may comprise use by one or more computer systems of a trading API provided by the exchange. The electronic ledger system may also be used in conjunction with cold storage digital asset security systems by the exchange. Fiat (e.g., USD) and digital assets (e.g., bitcoin or ether) can be electronically credited and/or electronically debited from respective (e.g., fiat and digital asset) electronic ledgers. Clearing of transactions may be recorded nearly instantaneously on the electronic ledgers. Deposits of fiat with the exchange and withdrawals from the exchange may be recorded on the electronic fiat ledger, while deposits and withdrawals of digital assets may be recorded on the electronic digital asset ledger. Electronic ledgers may be maintained using one or more computers operated by the exchange, its sponsor and/or agent, and stored on non-transitory computer-readable memory operatively connected to such one or more computers. In embodiments, electronic ledgers can be in the form of a database.

A digital asset exchange computer system can include one or more software modules programmed with computer-readable electronic instructions to perform one or more operations associated with the exchange. Each module can be stored on non-transitory computer-readable memory operatively connected to such one or more computers. An exchange may have a user on-boarding module to register users with the exchange and/or create accounts for new and/or existing exchange users. The exchange may employ systems and methods to ensure that the identity of exchange customers is verified and/or the destination of fiat currency and/or digital assets is known. Accordingly, the exchange may require new exchange customers to provide valid (e.g., complying with certain types, such as a driver's license or passport, or complying with certain characteristics) photo identification, a current address, a current bill, such as a utility bill, biometric information (e.g., a fingerprint or hand scan), and/or bank account information. A user on-boarding module can include back-end computer processes to verify and store user data as well as a front-end user interface by which a user can provide information to the exchange, select options, and/or receive information (e.g., through a display). The user on-boarding module can provide the front-end interface to one or more user devices and/or platforms, such as a computer, mobile phone (e.g., running an exchange-related mobile application), and/or digital asset kiosk, to name a few.

FIG. 27B shows another schematic diagram illustrating entities associated with a digital asset exchange in an exemplary embodiment of the present invention. In addition to the participants described with respect to FIG. 27A, a digital asset exchange may communicate with an authenticator computer system 3246 (to authenticate users, e.g., using multi-factor authentication and/or comparisons to databases of flagged users, to name a few), an index computer system 3248 (e.g., for generating and/or providing a digital asset index, which may be a price index), and/or a market maker computer system 3250. A market maker may be an exchange user that provides liquidity for the exchange, by purchasing or selling digital assets.

In embodiments, an exchange computer system may calculate different fees for a market maker. The fee calculation may vary with market conditions, such as price, digital asset supply (e.g., sell orders), and digital asset demand (e.g., buy orders). In embodiments, transaction fees charged by an exchange may be different for purchase and sale transactions. Fees may be based upon a user's identity, a user's transaction history, the quantity of digital assets and/or fiat currency associated with a user account, a rate schedule associated with a particular account or account type (e.g., there could be different rates for institutional or foreign users), time of day, and/or whether the user is operating as a market maker or a market taker for a given transaction, to name a few.

FIGS. 28A-B are schematic diagrams of exemplary exchange computer systems in accordance with exemplary embodiments of the present invention. FIG. 28A shows hardware, data, and software modules, which may run on one or more computers. FIG. 28B shows an exemplary distributed architecture for the exchange computer system.

As shown in FIG. 28A, an exchange computer system 3230 can include one or more processors 5102, a communication portal 5104 (e.g., for sending and/or receiving data), a display device 5106, and/or an input device 5108. The exchange computer system 3230 can also include non-transitory computer-readable memory with one or more database and data stored thereon. Data can include user identification data 5110 (e.g. know your customer data obtained during the user onboarding process), user account authentication data 5112 (e.g., login credentials, multi-factor authentication data, and/or anti-money laundering verifications), account activities logs 5114, electronic ledger data 5116, fiat account balance data 5118, and/or digital wallet balance data 5120. One or more software modules may be stored in the memory and running or configured to run on the one or more processors. Such modules can include a web server module 5122, authenticator module 5124, risk management module 5126, matching engine module 5128, electronic ledger module 5130, digital wallet module 5132, and/or fiat account module 5134. The processes performed by such modules, the data produced thereby and/or the data accessed thereby are described herein.

An account activities log 5114 may track all user requests received by the exchange computer system. The computer system may generate usage statistics and/or analyze user activity for patterns, e.g., to detect fraudulent behavior.

In embodiments, the risk management module 5126 may analyze user activity logs (e.g., access logs, transaction logs, user electronic requests, website navigation logs, mobile application usage logs, to name a few) to identify behavioral patterns, anomalies, and/or potential fraudulent activity (such as fraudulent electronic requests).

In embodiments, an exchange may conduct user or account verification procedures. In embodiments, these user or account verification procedures may comprise participating with third-party vendors in connection with certain Know Your Customer services. In embodiments, an exchange may implement alternative anti-money laundering (AML) measures. In embodiments, AML measures may include monitoring each transaction on the digital asset exchange for particular factors (e.g., amounts of transaction, location of transaction, volume of activity, to name a few). In the United States, the exchange may provide a user on-boarding mechanism that receives a user registration request, receives a user domicile (e.g., a state of domicile), and/or directs the user to an anti-money laundering user interface based upon the domicile. In embodiments, this interface may be generated at a user device using display data transmitted from the exchange computer system.

A matching engine 5128 may apply a continuous order book price time priority matching algorithm. In embodiments, matching engine 5128 may apply option points at low and/or high frequencies.

As shown in FIG. 28B an exchange computer system can include a web server 5152, an authenticator computer system 5154, a matching engine computer system 5156, an electronic ledger computer system 5158, a risk management computer system 5160, a digital wallet computer system 5162, a fiat account computer system 5164, and/or a SV Coin Computer System 5166. The exchange computer system 3230 may communicate with one or more external computer systems, such as bank computer systems, index computer systems, user computer system (e.g., institutional or individual users), and/or user electronic devices. Each computer system may comprise one or more computers and/or one or more processors, a communication portal, display devices, and/or input devices, to name a few.

A web server 5152 may provide display data to one or more user device 102, e.g., user device 102-1. Display data may comprise website content (e.g., HTML, JavaScript, and/or other data from which a user device can generate and/or render one or more webpages) and/or application content, such as mobile application content, to be used in generating or providing display content for one or more software application. In embodiments, the web server 5152 may authenticate a user account by verifying a received username and password combination.

An authenticator computer system 5154 may perform authentication of user login credentials, multi-factor authentication, and/or compare users against databases, such as government databases, for compliance with anti-money laundering laws and/or regulations.

A matching engine computer system 5156 may match buy (purchase) orders with sell orders, receive orders, and/or update an electronic order book, to name a few.

An electronic ledger computer system 5158 may track and/or store account balances, update account balances, compute account balances, report account balances, and/or place holds on account funds while transactions are in progress (e.g., set an account hold indicator), to name a few.

A risk management computer system 5160 may perform processes to detect fraudulent transactions and/or security breaches. Such a sub-system may monitor access data describing access of the exchange (e.g., IP addresses, accounts, times of access, to name a few), monitor trading data, analyze trading data, determine patterns, determine anomalies, and/or determine violations of pre-programmed security rules, to name a few.

A digital wallet computer system 5162 may generate digital wallets with associated digital asset addresses, generate instructions for digital wallet key storage and/or retrieval, allocate digital assets among digital wallets, track digital assets, store digital asset, and/or transfer digital assets, to name a few.

The digital wallets may include both hot wallets and cold wallets. In embodiments, sufficient digital assets will be stored in one or more hot wallets to allow for liquidity. The amount of digital assets stored in the one or more hot wallets may be determined based on historical averages of trading on the exchange. In embodiments, remaining digital assets will preferably be held in cold wallets. A more detailed discussion of hot wallets and cold wallets is presented in U.S. Pat. No. 9,892,460, issued Feb. 13, 2018 and entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR OPERATING EXCHANGE TRADED PRODUCTS HOLDING DIGITAL MATH-BASED ASSETS, the entire content of which is incorporated herein by reference.

A fiat account computer system 5164 may manage omnibus or pooled accounts for holding customer funds. The fiat account computer system may process receipts of funds, e.g., from a bank, via a wire transfer, via a credit card or ACH transfer, and/or via check, to name a few. Accordingly, the fiat account computer system may communicate with one or more external systems, such as a bank computer system. In embodiments, the fiat account computer system may process withdrawals. In embodiments, the omnibus or pooled accounts for holding fiat are maintained in a bank or other institution such that these accounts are eligible for insurance under the Federal Deposit Insurance Corporation (FDIC). In order to qualify for FDIC insurance, an account must typically be associated with specific user identification information, e.g., a user name, address and social security number, by way of example, to name a few. Accordingly, in embodiments, fiat accounts may be associated with individuals who are positively identified.

FIG. 29 is an exemplary flow chart for processes for digital asset exchange account creation and account funding in accordance with exemplary embodiments of the present invention. The processes may be performed by an exchange computer system, which may comprise one or more computers. In embodiments, any steps in the processes may be performed by third-party computer systems, which may be operatively connected to the exchange computer system, e.g., through the Internet. The processes may be performed in conjunction with a user interface, such as a website or mobile application on a smart phone, which can receive user inputs and/or display content to the user. In a step S4702, an exchange computer system may receive an electronic request for a new exchange account. Upon receiving such a request, the exchange computer system may perform account creation, identity verification, fiat account funding, and/or digital asset account funding processes.

Referring to the account creation process shown in FIG. 29, in a step S4704 the exchange computer system may receive account options and/or account information. Account options can include an account type (e.g., individual, business, investor, to name a few), which may correspond to different features, fees, limits, and/or services, such as the ability to transact once a day or multiple times a day, the ability to withdraw funds immediately or once a day, and/or access to a trading API, to name a few. Account information can include a username, password, contact information, actual name of user, location or domicile of user, to name a few. In a step S4706 the exchange computer system may configure customer authentication settings, which may involve setting up two-factor authentication for the user on one or more user devices.

Referring to the identity verification process shown in FIG. 29, in a step S4710 the exchange computer system may receive proof of identity information, which can include a scan of a government-issued identification document (e.g., a driver's license, a passport, a social security card), a copy of a utility bill, a photograph, biometric information (e.g., a fingerprint, palm scan, eye scan, to name a few), and/or identifying information such as a social security number or other government issued identification number, to name a few. In a step S4712 the exchange computer system may analyze the identity information, which may include verifying the information against one or more databases of identity information. Analyzing identity information may comprise verifying the accuracy of the information and/or determining eligibility for participation in the exchange (e.g., based on domicile and/or minimum age, to name a few). In a step S4714 the exchange computer system may provide to a user device a notification of approval, a notification of rejection, or a notification that additional information is required.

Referring to the fiat account funding process shown in FIG. 29, in a step S4720 the exchange computer system may receive fiat funding account information. Such information can include a bank account number (e.g., a routing number), a bank name, an account type, and/or an account holder's name, to name a few. In a step S4722, the exchange computer system may perform one or more validation transactions using the fiat funding account. Such transaction may comprise small deposits into the fiat funding account. In a step S4724, the exchange computer system may receive validation transaction information, which may include a transaction amount, date, and/or time. In a step S4726, the exchange computer system may electronically authorize use of the fiat funding account and/or request a funding transfer. Accordingly, the exchange computer system may provide an electronic notification, e.g., via email, via a website, and/or via a mobile phone application (e.g., via a push notification)—to name a few, that the fiat funding account is authorized for use with the exchange. A customer may electronically initiate a transaction, e.g., through an exchange-provided user interface or user electronic device operatively connected to the exchange, to transfer funds to the exchange. In a step S4728, the exchange computer system may receive an electronic notification indicating that funds were received, e.g., in an exchange bank account at a partner bank, from the customer fiat funding account. In a step S4730, the exchange computer system can update an exchange customer account with the received funds. Updating an exchange customer account can comprise electronically updating a fiat electronic ledger stored one or more computer readable media operatively connected to the exchange computer system to reflect the received funds and/or updating a display of the amount of funds in the account or a data ledger on a user computer device or on a printed and/or digitally transmitted receipt provided to the user and/or a user device.

Referring to the digital asset account funding process shown in FIG. 29, in a step S4734, the exchange computer system can receive an initial transfer of digital assets. In a step S4736, the exchange computer system can receive a confirmation of clearance of the digital asset transfer. In a step S4738, the exchange computer system can update an exchange customer account with the received digital assets. Updating an exchange customer account can include making an electronic entry in an exchange digital asset electronic ledger and/or providing a notification that the digital assets are received.

FIG. 30A is an exemplary schematic diagram of an exchange, and FIG. 30B is a corresponding flow chart of a process for digital asset exchange customer account fiat funding via an exchange-initiated request, such as ACH in accordance with exemplary embodiments of the present invention. An exchange computer system 4810 can interface with a customer digital asset wallet 4802, a bank 4804 with a customer fiat bank account 4806, an exchange partner bank 4822 with an exchange pooled customer fiat account 4824, a network digital asset ledger 4808, and/or a customer's user device 4812, to name a few. In addition to the exchange computer system 4810, the exchange can include an exchange digital asset electronic ledger 4814, an exchange fiat electronic ledger 4816, and an exchange digital asset vault 4818 with exchange pooled customer digital asset wallets 4820 with associated digital asset addresses. Any of these entities or components may communicate directly and/or indirectly, e.g., through a data network, such as the Internet. In embodiments, encryption and/or other security protocols may be used. These entities and components are further described with respect to FIG. 27A.

Referring to FIG. 30B, in a step S4802 the exchange computer system can receive user access credentials, e.g., from a user device. In a step S4804, the exchange computer system can authenticate the user, such as by verifying the received access credentials. In a step S4806, the exchange computer system may provide to a customer user device a fiat funding interface. In a step S4808, the exchange computer system may receive from the user device user selections for a funding source and/or funding method. The funding source may identify a bank account or other fiat account. The funding method may identify ACH transfer or wire transfer, to name a few. In a step S4810, the exchange computer system can receive from the user device a funding amount value to transfer to an exchange account associated with the user. In embodiments, step S4808 and step S4810 may be a single step or may occur substantially simultaneously. Accordingly, the exchange computer system may receive from a user electronic device a user electronic request comprising a funding amount and a funding method, wherein the funding method is an ACH transfer and the request further identifies a verified user bank account.

In a step S4812, the exchange computer system can transmit a fund transfer request to a bank where the customer has a fiat bank account. Accordingly, the exchange computer system may transmit to an exchange partner bank an electronic funding request comprising the funding amount and the user bank account identifier.

In a step S4814, the exchange computer system can update an exchange fiat electronic ledger with the funding transaction information. In a step S4816, the exchange computer system can receive an electronic indication that the funding amount was transferred from the customer's fiat bank account to an exchange fiat account, e.g., at a partner bank. In a step S4818, the exchange computer system can monitor the exchange fiat account to determine the availability of funds in an exchange account associated with the user. In embodiments, the exchange computer system may generate and/or provide an electronic notification to one or more user devices associated with a user account that funds are available for use on the exchange. In embodiments, the notification may indicate a current balance of a user account (e.g., in fiat currency and/or digital asset quantities).

FIG. 30C is an exemplary schematic diagram of an exchange, and FIG. 30D is a corresponding flow chart of a process for digital asset exchange customer account fiat funding via a customer-initiated request, such as a wire transfer, in accordance with exemplary embodiments of the present invention. The components and entities associated with an exchange that are shown in FIG. 30C are described with respect to FIG. 27A.

FIG. 30D is a flow chart showing an exemplary process for digital asset exchange customer account fiat funding. In a step S4852, an exchange computer system can receive user access credentials. In a step S4854, the exchange computer system can authenticate the user by verifying the received access credentials. Verifying the access credentials can comprise comparing the credentials to a secure credentials database. In a step S4856, the exchange computer system can provide to a customer user device a fiat funding interface. In a step S4858, the exchange computer system can receive from the customer user device, user selections for a funding source and/or funding method. The funding method may be a customer-initiated method, such as a wire transfer. In a step S4860, the exchange computer system can receive a funding amount value to transfer to an exchange account associated with the user. In a step S4862, the exchange computer system can provide to the customer user device fund transfer instruction, e.g., wire instructions. In a step S4864, the exchange computer system may receive an electronic indication of a customer-initiated fund transfer from a customer fiat bank account a customer bank to an exchange fiat account at an exchange partner bank according to the fund transfer instructions. In embodiments, step S4864 may be skipped. In a step S4866, the exchange computer system may receive an indication that the funding amount was transferred from the customer's fiat bank account to the exchange fiat account. In a step S4868, the exchange computer system can update an exchange fiat electronic ledger with the funding transaction information, which may include an amount value, customer account ID, transaction date and/or time, to name a few. In a step S4870, the exchange computer system can monitor the exchange fiat account to determine the availability of funds in an exchange account associated with the user. In a step S4872, the exchange computer system can provide an electronic notification to one or more customer user devices that funds are available for use on the exchange.

FIG. 30E is a flow chart showing another exemplary process for digital asset exchange customer account fiat funding. In a step S4852′, an exchange computer system can receive user access credentials. In a step S4854′, the exchange computer system can authenticate the user by verifying the received access credentials. Verifying the access credentials can comprise comparing the credentials to a secure credentials database. In a step S4856′, the exchange computer system can provide to a customer user device a fiat funding interface. In a step S4857, the exchange computer system can receive a user electronic request comprising a funding amount and a funding method (e.g., a wire transfer). In a step S4859, the exchange computer system can provide to the customer user device, an electronic message and/or display data comprising wire transfer instructions. In a step S4861, the exchange computer system can set a pending transfer indicator and/or initiate a funds receipt monitoring process. In a step S4863, the exchange computer system can receive an electronic indication that funds were received via wire transfer at an exchange fiat account at an exchange partner bank. In a step S4865, the exchange computer system can verify that the received funds were transferred from the authorized customer's fiat bank account to the exchange fiat account. In a step S4868′, the exchange computer system can update an exchange fiat electronic ledger with the funding transaction information, which may include an amount value, customer account ID, transaction date and/or time, to name a few. In a step S4870, the exchange computer system can monitor the exchange fiat account to determine the availability of funds in an exchange account associated with the user. In a step S4872′, the exchange computer system can provide an electronic notification to one or more customer user devices that funds are available for use on the exchange.

FIG. 31A is an exemplary schematic diagram of an exchange, and FIG. 31B is a corresponding flow chart of a process for digital asset exchange account digital asset withdrawal in accordance with exemplary embodiments of the present invention. The components and entities associated with an exchange that are shown in FIG. 31A are described herein with respect to FIG. 27A.

Referring to FIG. 31B, in a step S4902, an exchange computer system can receive user access credentials. User access credentials can include any of a username, password, fingerprints, access card scan (e.g., swipe of a card associated with the exchange and having a magnetic strip), and/or a pin (e.g., a number provided via SMS, other text message service, or email for multi-factor authentication), to name a few. In a step S4904, the exchange computer system can authenticate the user based upon the received user access credentials. In a step S4906, the exchange computer system may provide to a customer user device a withdrawal interface. In a step S4908, the exchange computer system may receive from the customer user device user inputs comprising at least a destination digital asset address, typically associated with a destination digital wallet and a requested digital asset withdrawal amount value. In a step S4910, the exchange computer system may verify that a digital asset account associated with the customer contains sufficient digital assets to cover the requested withdrawal amount. In embodiments, such verification can comprise reading a digital asset electronic ledger and/or determining a customer digital asset balance, e.g., based on summing transactions recorded on a digital asset electronic ledger. In a step S4912, the exchange computer system may update an exchange digital asset electronic ledger to reflect the pending withdrawal. In embodiments, recording an entry in the electronic ledger prior to the withdrawal may be performed to prevent double spending. In other embodiments, such a step may be skipped. In a step S4914, the exchange computer system may execute the withdrawal, e.g., by broadcasting the withdrawal to a digital asset network electronic ledger, e.g., the Bitcoin Blockchain, the Ethereum Blockchain, to name a few. In a step S4916, the destination wallet may receive an electronic notification of the receipt of digital assets from the exchange. In a step S4918, the exchange computer system may monitor the network digital asset ledger to determine whether and/or when the withdrawal transaction is confirmed. In a step S4920, the exchange computer system may update the digital asset electronic ledger, e.g., by debiting the withdrawal amount from the customer's exchange account, to reflect confirmation of the withdrawal transaction. In a step S4922, the exchange computer system may provide to one or more customer user devices an electronic notification of the withdrawal. Such a notification can include at least the customer's new digital asset balance.

A digital asset exchange can include additional systems, which may include software modules, for performing various functions of the exchange. For example, an exchange can include an account management system, which may comprise a user account registration system for new users and/or an existing user account management system. The exchange can include a trading system, which may comprise an interactive trading interface system, an automated trading interface system, a trade confirmation notification system, and/or a trade transaction fee processing system. A fund transfer system can include a fiat account funding and redemption system, a digital asset accounting funding and redemption system, and an account funding and redemption fee processing system. An exchange can also include a trade settlement system. A customer service system can include a trade dispute resolution interface system and a customer account management assistance system. A customer reporting system can include a gain an loss reporting system and a transaction history system. A fraud analysis system can monitor transactions to detect fraudulent and/or unauthorized transactions.

Deposited customer fiat may be held in a pooled fiat account maintained in a partner bank. Meanwhile, digital assets held by the exchange may be maintained in pooled digital addresses associated with pooled digital wallets, such as aggregated custodial wallets. The exchange may store digital assets using any of the security and/or storage systems and methods discussed herein. The exchange can employ any combination of varying levels of secure storage for its wallets. For example, portions of digital assets held by the exchange may be maintained in cold storage with neither the wallet's private nor public keys ever having been exposed to a digital asset network or other external network, such as the Internet. Other digital assets may be stored in air-gapped hot wallets, which may be wallets generated off-line with transactions generated off-line, e.g., on an isolated computer, and transferred to a networked computer via a temporary physical connection or manual transfer. Isolated computer systems are physically and operationally isolated from other computer systems. For example, an isolated computer system may be an air gapped computer system. Other digital assets may be maintained in hot wallets, e.g., to satisfy withdrawals from the exchange. The exchange may determine the amount of assets to hold in hot wallets, which may be based on historical exchange activity and/or anticipated need. A hot wallet liquidity module may analyze and predict the amount of assets per wallet and/or during a time period required to meet anticipated need and may also initiate transfers of assets to or from hot wallets to maintain desired levels. For example, a hot wallet liquidity module could determine that it is desirable to maintain digital assets in certain defined amounts (e.g., 0.5 bitcoin), and/or certain defined fiat amounts (e.g., $100 worth of bitcoin) and/or of certain defined quantities sufficient to cover transactions anticipated during a defined period (e.g., the day's transaction). In embodiments, initiating an electronic transfer may comprise electronically generating and providing an electronic notification to devices associated with one or more exchange administrators of a need to transfer assets and/or an amount of assets to transfer. The exchange may designate one or more wallets for receiving incoming digital assets only. For example, the exchange may employ a single digital wallet for each receipt of digital assets, e.g., from exchange users. The receiving wallet may be destroyed after the received assets are transferred to one or more other wallets.

The exchange may employ any of a number of different exchange digital wallet systems. As discussed herein, the exchange may operate a pooled or omnibus digital wallet system, e.g., as part of a centralized exchange system. The pooled system may use an electronic ledger to track digital asset ownership for each exchange customer. Customers may transfer digital assets from their own digital wallets to an exchange address in order to fund their digital asset account on the exchange. The ledger can track (e.g., record) such funding events, as well as withdrawal events. Transfers of digital assets among customers can also be accounted for using the ledger. With a pooled wallet system, internal transactions on the exchange (e.g., transactions that do not entail transferring funds to or from the exchange or exchange wallets but rather transactions between exchange wallets) can be settled without delay, since the transfer can be logged through electronic ledger updates and does not have to otherwise be processed by a digital asset network.

In another embodiment, the exchange digital wallet system may comprise exchange operated wallets for each exchange customer. These exchange operated wallets may be maintained in trust by the exchange for each customer as associated digital asset addresses. Transactions may be processed by the digital asset network, e.g., the Bitcoin network. The keys to each customer wallet may be held by the customer and/or by the exchange. Transactions may be settled via the digital asset network in real-time (with any corresponding confirmation period) as they occur, or transactions may be settled in a batch, which may entail broadcasting a plurality of transactions to the network at a particular time or periodically throughout a day.

In another embodiment of an exchange digital wallet system, the exchange customers may own and/or manage their own wallets, e.g., as part of a decentralized exchange system. The exchange would not hold any customer digital assets, and customers would hold the private keys to their wallets with associated digital asset addresses. The exchange may match customers, as described herein, so that a digital asset seller can transfer digital assets from the seller's digital wallet to a digital wallet corresponding to a digital asset buyer.

In embodiments, the digital wallet may be a custodial digital wallet. The custodial digital wallet may be segregated, that is, unique to a particular customer or commingled, including digital assets of multiple customers. In such an embodiment, the custodian holds digital assets in the custodial wallet for the benefit of its customers. The custodian would hold the private key to each custodial wallet whether it be segregated or commingled. Transactions may be made between different custodial wallets or between custodial wallets and exchange customer wallets in the manner described above.

In embodiments, the exchange may hold customer fiat currency and/or digital assets in centralized, pooled accounts or wallets. As discussed herein, the exchange may maintain an electronic ledger to record transactions among users of the exchange. Separate electronic fiat account ledgers and electronic digital asset ledgers may be maintained. Maintaining a ledger may involve electronically updating the ledger to reflect pending transactions and/or completed transactions, which may involve debiting assets from a user's account and/or crediting assets to a user's account. Broadcast to a digital asset network and confirmation from a digital asset network may not be performed for transactions within the exchange, e.g., transactions between a digital asset seller selling digital assets that are stored by the exchange and a buyer paying with fiat currency that is held in an exchange bank account, such as a pooled account.

In embodiments, for both a decentralized and a centralized exchange the exchange may provide the ability for customers to purchase digital assets from the exchange and/or sell digital assets to the exchange such that the exchange operator or owner is the counter-party to the transaction. Transaction amount limits may be place on such transactions and/or additional fees may be charged.

In embodiments, a digital asset exchange may require users to open designated accounts associated with the user in order to participate in the exchange. Each user may have a digital math-based asset account to record and maintain such user's digital math-based assets and a fiat account to record and maintain such user's fiat assets. In embodiments, the fiat assets recorded in the fiat account may be U.S. Dollars held in one or more omnibus bank accounts with one or more FDIC-insured depository institutions or banks. In embodiments, a digital math-based asset computer system of a digital asset exchange may record in an electronic ledger information associated with a user account, such as digital math-based asset purchase orders, digital math-based asset sell orders, digital math-based asset purchase offers, digital math-based asset sell offers. In embodiments, digital math-based asset purchase offers and digital math-based asset sell offers may be converted into digital math-based asset purchase orders and digital math-based asset sell orders, respectively, according to a user's instructions, if certain user-specified factors are met (e.g., digital math-based assets are within a given price, quantity, period of time, to name a few). In embodiments, when the digital math-based asset computer system matches an electronic digital math-based asset purchase order with an electronic digital math-based asset sell order, the digital math-based asset computer system may record the trade in an electronic ledger, effectively transferring ownership of the seller's traded digital math-based assets to the buyer, and ownership of the related purchase price in fiat currency from the buyer to the seller. In embodiments, the changes in a user's ownership of digital math-based assets and fiat currency recorded in the electronic ledger are reflected in a user's digital math-based asset account and fiat account.

In embodiments, a digital asset exchange may accept payment methods (e.g., credit card transactions; Automated Clearing House (ACH) debits, wire transfers, digital asset transactions, to name a few) for purchases of digital assets.

In embodiments, users may utilize sub-accounts subordinate to the master account. In embodiments, sub-accounts can be used as entities for traders, or can be used by machines associated with an owner, as discussed in U.S. patent application Ser. No. 15/071,902, filed Mar. 16, 2016 and entitled AUTONOMOUS DEVICES, which is expressly incorporated herein by reference.

In embodiments, a digital asset exchange may hold digital math-based assets and/or fiat currency in trust for users before, during and after a trade. Fiat currency may be maintained in accounts with a state or federally chartered bank and may be eligible for FDIC insurance, subject to compliance with applicable federal regulation. In embodiments, a digital asset exchange may also operate a digital math-based asset storage system, in which users may deposit digital math-based assets. In embodiments, fiat currency may be transmitted to a digital asset exchange's omnibus account. In embodiments, the exchange may transmit fiat currency back to a user upon receiving a request from a user.

In embodiments, a digital asset exchange may comply with relevant laws and regulations whereby the exchange may operate in a highly regulated banking environment and permit necessary supervision by relevant legal authorities.

In embodiments, when a user commences an electronic digital math-based asset purchase order to acquire digital math-based assets, the user may either have fiat currency in an associated user account or the buyer may send fiat currency to the digital asset exchange's omnibus account at the applicable bank. In embodiments, when a seller commences an electronic digital math-based asset sell order to sell digital math-based assets, the seller may either have digital math-based assets in an associated user account or may send digital math-based assets to a digital math-based asset account. In embodiments, the seller may send digital math-based assets to one or more of digital wallets held by the exchange. In embodiments, exchange transactions may only be completed after the digital math-based asset computer system verifies that the digital math-based asset accounts and fiat accounts associated with the users involved in the transaction at least equal the quantities required by the transaction.

In embodiments, the exchange may permit trading twenty-four hours a day, seven days a week. In embodiments, the exchange may shut down for scheduled maintenance periods. In embodiments, the exchange may prohibit users from transferring fiat currency outside of normal business hours, in order to comply with applicable laws and regulations. In embodiments, the exchange may allow users to deposit and withdraw digital math-based assets outside of normal business hours. In embodiments, the exchange may permit users to sell digital math-based assets for fiat currency or buy digital math-based assets with fiat currency if the user holds sufficient fiat currency in its associated account prior to initiating the transaction.

In embodiments, as discussed herein, exchange customers looking to buy digital assets may be matched to customers looking to sell digital assets, which matching may be performed by an exchange trading engine. Transaction volumes and prices may be based at least in part upon bids and asks that are received by the trading engine from the customers.

In embodiments, a digital asset exchange (such as a regulated exchange) can be used to exchange SVCoin for fiat and fiat for SVCoin. Since SVCoin is a stable value token, each token will be pegged to a stable value of fiat (e.g., 1 SVCoin=1 USD or 1 SVCoin=1 EUR, to name a few). An example of a SVCoin could be Gemini Dollar. In embodiments, when fiat is provided to a digital asset exchange to purchase SVCoin, a sufficient amount of fiat to cover the notional value of the SVCoin will be set aside and held until the SVCoin is redeemed. Similarly, when SVCoin is redeemed the corresponding amount of fiat associated with the notional value of the SVCoin will be taken from such reserves to cover the redemption.

In embodiments, each time SVCoins are purchased, redeemed and/or traded, transaction fees may be charged by the SVCoin issuer, and/or others involved in the transaction, such as miners on the digital asset network. Such transaction fees may be charged in fiat, SVCoin and/or other digital assets (e.g, Gas, bitcoin, ether, to name a few). For example, a purchaser may pay $1.01 USD for 1 SVcoin (that has a redemption value of $1.00 USD).

In embodiments, the SVCoin issuer may provide a discount to a purchaser of SVCoin, which may be reflected in fiat, SVCoin and/or other digital assets (e.g., Gas, bitcoin, ether, to name a few). For example, a purchaser may pay $0.99 USD for 1 SVCoin (that has a redemption value of $1.00 USD).

In embodiments, transaction fees and/or discounts can be incurred and/or paid at the time of transfer or at another time.

In embodiments, the SVCoin may be pegged to another stable value token. In embodiments, the SVCoin may be pegged to the value of another asset, other than fiat. In embodiments, the SVCoin may be pegged to the value of a security, for example, a certificate of stock in a particular company. In embodiments, a purchaser of the SVCoin may deposit or otherwise provide to the digital asset exchange, a share of stock and will receive an SVCoin token in return. In embodiments, the digital asset exchange will hold the share of stock, in a custodial account, for example, until it is redeemed. In embodiments, rather than deposit a share of stock, a purchaser of SVCoin may deposit a sum of fiat, or other assets, sufficient to purchase a share of stock. In embodiments, the digital asset exchange may acquire a share of stock on the market using the assets deposited by the purchaser and then hold the share of stock until the SVCoin is redeemed.

In embodiments, the SVCoin may be pegged to the value of a commodity. In embodiments, a purchaser of SVCoin may deposit a sum of fiat, or other assets, sufficient to purchase a quantity of a commodity. In embodiments, the digital asset exchange may hold an amount of the commodity, in a custodial account, for example, until the SVCoin is redeemed. In embodiments, the digital asset exchange may acquire the quantity of the commodity on the market using the assets deposited by the purchaser and then hold the commodity until the SVCoin is redeemed.

In embodiments, the SVCoin may be pegged to a derivative product of a stock, commodity and/or another digital asset to name a few.

In embodiments, when a user (such as a registered user of a regulated digital asset exchange) commences a purchase order to acquire SVCoin for fiat, the user may have fiat currency in an associated user account. Alternatively, the user may send fiat currency to the exchange's account, such as an omnibus account, at the applicable bank. In embodiments, when a seller sells SVCoin, the seller may have the SVCoin in an associated user account or may send SVCoin to a digital asset account. Specifically, the seller may send SVCoin to one or more of digital asset addressed, typically associated with digital wallets held by the exchange. In embodiments, exchange transactions may only be completed after the verification that the digital asset accounts and fiat accounts associated with the users involved in the transaction at least equal the quantities of each required by the transaction.

In embodiments, as shown in FIGS. 65A-1-4, 65B-1-4, 65C-1-2, and 65D. registered users of a digital asset exchange system, such as Gemini, may purchase and/or redeem SVCoins for fiat and/or other digital assets though one or more digital asset dashboard interfaces. In embodiments, the one or more digital asset dashboard interfaces may include: (i) a dashboard fiat interface which allows registered users to deposit and/or withdrawal fiat with the digital asset exchange; (ii) a dashboard digital asset interface which allows registered users to deposit and/or withdrawal digital assets with the digital asset exchange system; (iii) a dashboard SVCoin interface which allows registered users to purchase and/or redeem SVCoins with the digital asset exchange system; and (iv) a dashboard Security Token interface which allow Security Token issuers to provide instructions to transfer SVCoins to Security Token holders. Each of these dashboard interfaces will now be described in turn.

FIGS. 65A-1-4 illustrates an exemplary embodiment of a dashboard fiat interface which allows registered users to deposit and/or withdraw fiat with the digital asset exchange.

FIG. 65A-1 illustrates an exemplary embodiment of the dashboard fiat interface as used for deposit of fiat. As illustrated, the user has the option to make a transfer from a bank to the exchange by indicating an amount of fiat 6502 (e.g., US dollars) to be transferred from a funding source 6500 (e.g., a bank account).

FIG. 65A-2 illustrates an exemplary embodiment of the dashboard fiat interface providing an option of a wire transfer. As in FIG. 65A-1, the user indicates an amount of fiat 6502 to be transferred from a funding source 6500, such as a bank, to be wired to the exchange.

FIG. 65A-3 illustrates the dashboard fiat interface as used to withdraw fiat from the exchange and deposit it into a destination (e.g., a bank). In this case, the user provides a withdrawal amount of fiat 6504 and a destination 1106, such as a bank account, for the specific fiat.

Similarly, FIG. 65A-4 illustrates the dashboard fiat interface as used to withdraw fiat via a wire transfer where the user enters the withdrawal amount of fiat 6504 and a destination 1106, such as a bank account.

FIGS. 65B-1-4 illustrates an exemplary embodiment of a dashboard digital asset interface which allows registered users to deposit and/or withdrawal digital assets with the digital asset exchange system.

FIG. 65B-1 illustrates an exemplary embodiment of the dashboard fiat interface as used for deposit of digital assets, specifically bitcoin in this nonlimiting example. As illustrated, the user enters the current address 6512 of the digital asset (e.g., bitcoin, ether, etc.).

FIG. 65B-2 illustrates another exemplary embodiment of the dashboard fiat interface as used for deposit of digital assets, specifically ether this nonlimiting example. As illustrated, the user enters the current address 6512 of the digital asset (ether in this example.

FIG. 65B-3 illustrates an exemplary embodiment of the dashboard fiat interface as used for withdrawal of digital assets, specifically bitcoin in this nonlimiting example. As illustrated, the user enters the destination address 6514 for the digital asset (bitcoin) as well as amount of digital assets 6516 to be withdrawn.

FIG. 65B-4 illustrates an exemplary embodiment of the dashboard fiat interface as used for withdrawal of digital assets, specifically ether this example. As illustrated, the user enters the destination address 6514 of the digital asset (ether) as well as amount of digital assets 1116 to be withdrawn.

FIGS. 65C-1-2 illustrates an exemplary embodiment of a dashboard SVCoin interface which allows registered users to purchase and/or redeem SVCoins with the digital asset exchange system.

FIG. 65C-1 illustrates an exemplary embodiment of the dashboard fiat interface as used to purchase SVCoins using fiat. As illustrated, the user may enter an amount of fiat (U.S. dollars, in this example) 6522 to be provided from a source 6524 (e.g., a bank account) to purchase the SVCoins.

FIG. 65C-2 illustrates an exemplary embodiment of the dashboard fiat interface as used to purchase SVCoins using digital assets (bitcoin in this example). As illustrated, the user may enter the current address of the digital asset 6526.

In embodiments, a registered user may purchase SVCoins in exchange for fiat. Referring to FIG. 66A, in S6602, a registered user may log in to the dashboard SVCoin interface, such as illustrated in FIGS. 65C-1-2.

In S6604, the user selects the purchase SVCoin option, and specifies the amount of SVCoins the user seeks to obtain. In embodiments, the user may be requested to provide a digital asset address, typically associated with a digital wallet, such as a digital asset address associated with a blockchain digital asset, like ether. In embodiments, the amount of SVCoins to be purchased may be specified by number of SVCoins, or by an amount of fiat. Since the SVCoins are pegged to the fiat in a stable amount (e.g., 1 SVCoin=1 USD), the system can automatically convert and display the requested amount of SVCoin into fiat, or requested amount of fiat into SVCoin.

In S6606, the digital asset exchange system will analyze and verify that the request can be properly processed. In step S6606-a, the digital asset exchange system, as the SVCoin issuer, may verify that the user has sufficient fiat currency maintained at the digital asset exchange to cover the transaction, including a sufficient amount of fiat to cover the amount of SVCoin being acquired, as well as any transaction fees that may be charged. If the user does not have sufficient fiat in the system, the transaction may be terminated for insufficient funds. In embodiments, the user may be provided an opportunity to obtain sufficient funds, by, e.g., selling digital assets maintained by the user on the digital asset exchange or by making a deposit of additional fiat. In step S6606-b, the digital asset exchange system, may also verify that the digital asset address provided is a valid digital asset address. In step S6608-c, the digital asset exchange system, may also publish transactions to blockchain.

In S6608, after the digital asset exchange system has confirmed that the user has sufficient fiat to cover the transaction, the digital asset exchange system may initiate the process of generating the requested SVCoin. In embodiments, where SVCoins were previously generated, then S6608 may be replaced with an alternative process S9908′ as discussed below.

Returning to S6608, in S6608-a, the digital asset exchange system may debit the designated fiat funds from a fiat ledger associated with the user account, and credit a corresponding amount of fiat to the SVCoin fiat ledger to be held in trust by the Exchange.

In S6608-b, the digital asset exchange system shall generate the requested SVCoin tokens. As part of this step, or as an additional step, the digital asset exchange system will update the SVCoin ledger to reflect the creation of the newly generated SVCoins and to indicate the digital asset address associated with these newly generated SVCoins.

In S6608-c, the digital asset exchange system shall publish to the blockchain network (e.g., the Ethereum Network) the transaction to be recorded by the blockchain network. In embodiments, a transaction fee may be required by, e.g., a miner, to process and add the requested transaction on the blockchain.

As noted, when a reserve of SVCoin had been previously created but not yet distributed by the digital asset exchange system, S6608′ may be implemented instead of S6608. At step S6608-a′, digital asset exchange computer system may debit the designated fiat funds from a fiat ledger associated with the user account, and credit a corresponding amount of fiat to the SVCoin fiat ledger to be held in trust by the Exchange.

In step S6608-b′, the digital asset exchange computer system may determine an appropriate amount of SVCoin from the reserve to satisfy the request.

In step S6608-c′, the digital asset exchange computer system updates the SVCoin ledger to change the address associated with the portion of the reserve determined in step S6608b′ to the address associated with the user.

In S6610, the digital asset exchange computer system may send a message to the registered user, and/or the designated digital asset address to reflect that the transaction was successfully processed. In embodiments, such messages may include information including: (i) digital asset address; (ii) the amount of tokens generated; and/or (iii) the new balances for the digital asset address.

In embodiments, a registered user may redeem SVCoins in exchange for fiat. Referring to FIG. 66B, in S6652, a registered user may log in to the dashboard SVCoin interface, such as illustrated in FIG. 65C-1 and FIG. 65C-2.

In S6654, the user selects the redeem SVCoin option, and specifies the amount of SVCoins the user seeks to redeem. In embodiments, the user may be requested to provide a digital wallet address, such as a digital wallet address associated with a blockchain digital asset, like ether. In embodiments, the amount of SVCoins may be specified by number of SVCoins, or by an amount of fiat. Since the SVCoins are pegged to the fiat in a stable amount (e.g., 1 SVCoin=1 USD, or 100 SVCoin=1 USD, to name a few), the system can automatically convert the requested amount of SVCoin to fiat, or requested amount of fiat into SVCoin.

In S6656, the digital asset exchange system will analyze and verify that the request can be properly processed. In step S6656-a, the digital asset exchange system, as the SVCoin issuer, may verify that the user has sufficient SVCoin to cover the transaction as well as any transaction fees that may be charged. In embodiments, the digital asset exchange system may perform verification of the SVCoin balance by checking the token balance of the digital asset address against the SVCoin Token ledger as maintained by the digital asset blockchain. For example, a balance for a token issued based on the Ethereum Network may be checked at www.etherscan.io. If the user does not have sufficient SVCoin and/or an insufficient amount for transaction fees and/or provided an invalid digital asset address, to name a few, the transaction may be terminated.

In embodiments, SVCoin transactions may be published and recorded in a SVCoin token side ledger that is separate from an underlying blockchain (e.g., the Ethereum Blockchain). Such a side ledger may be provided using a sidechain, for example, a plasma chain, which is separate from the underlying digital asset blockchain that is maintained on the distributed network. In embodiments, this sidechain is used to record all transactions involving the SVCoin token and is maintained by the token issuer or another trusted entity on behalf of the token issuer. These transactions may then be subsequently published to the underlying digital asset blockchain periodically or aperiodically such that all transactions are publicly viewable and confirmable. In embodiments, with a blockchain supporting shielded transactions, the transactions in the SVCoin token may potentially be shielded and only viewable by authorized token holders. In embodiments, transactions on the sidechain may be consolidated prior to publication on the digital asset blockchain to increase speed of processing and reduce transaction costs.

The use of a sidechain in conjunction with a blockchain can provide certain technical advantages not otherwise available by either alone. For example, since all transactions on the sidechain are inevitably published to the digital asset blockchain, these transaction records enjoy the same benefit of immutability provided to all other transactions on the digital asset blockchain. However, use of a sidechain reduces both transaction costs and transaction times overall. Recording the transactions on the sidechain first can be accomplished more rapidly than transactions that are published directly to the digital asset blockchain, which must be confirmed prior to being added to the digital asset blockchain. In embodiments, the sidechain may simply be a database that records all transactions such that there is no need for miners to verify each transaction, and thus, no need to pay miners for this service. In this case, transaction costs are only incurred for the periodic or aperiodic publication of transfers from the sidechain to the underlying digital asset blockchain.

In embodiments, the database for the SVCoin tokens may be maintained as a separate side chain from the database for each Security token. In embodiments, one or more security tokens may be maintained in the same side chain as the SVCoin tokens, and/or by the same trusted entity system as used to maintain the SVCoin token database.

In S6658, after the digital asset exchange system may confirm that the user has sufficient SVCoin to cover the transaction, as well as any other designated criteria, the digital asset exchange system may initiate the process of redeeming the designated SVCoin.

In S6658-a, the digital asset exchange system redeems the designated SVCoin tokens, including updating the SVCoin token ledger database to reflect the debiting and cancelling of the designated tokens and debiting the corresponding digital wallet address associated with such redeemed SVCoin tokens. In embodiments, this process may be performed by generating a transaction on the digital asset exchange network from a contract digital wallet address or other authorized digital wallet address under the relevant SVCoin smart contract programming, to be sent in S6658-c, discussed below.

In S6658-b, the digital asset exchange system credits the designated fiat funds to a fiat ledger associated with the user account, and debit a corresponding amount of fiat from the SVCoin fiat ledger being held in trust by the exchange.

In S6658-c, the digital assert exchange system publishes to the blockchain network (e.g., the Ethereum Network) the transaction to be recorded by the blockchain network. In embodiments, a transaction fee (such as Gas) may be required by, e.g., a miner, to process and add the requested transaction on the blockchain. In embodiments, the transaction fee may be specified as an amount and/or an amount limit to facilitate the transaction being processed by a miner.

In S6660, the digital asset exchange computer system may send a message to the registered user, and/or the designated digital asset addresses to reflect that the transaction was successfully processed. In embodiments, such messages may include information including: (i) digital asset address; (ii) the amount of tokens redeemed; and/or (iii) the new balances for the digital asset address or digital wallet associated therewith.

FIG. 32 illustrates an exemplary embodiment of an exchange trading system in accordance with embodiments of the present invention. An interactive order entry system may provide one or more interfaces through which exchange customers may initiate exchange transactions. An automated order entry system may comprise one or more trading APIs that allow customer computer-initiated transactions. Orders may be electronically stored in an electronic pending order book. An exchange order matching engine, which can comprise a computer system, may match bids and asks or otherwise match buyers and sellers of pending transactions. A transaction ledger may track transactions. A settlement engine may process the transactions, which may include providing trade confirmations or otherwise carrying out the transactions.

In embodiments, a digital asset exchange may employ systems and methods to manage and/or reduce digital asset transaction change. Digital asset transaction change refers to leftover digital asset amounts from transactions in digital asset systems, such as Bitcoin, where the transactions are comprised of one or more digital inputs and outputs. A wallet stores unspent transaction outputs, which it can use as digital inputs for future transactions. In embodiments, a wallet or third-party system may store an electronic log of digital outputs to track the outputs associated with the assets contained in each wallet. In digital asset systems such as Bitcoin, digital inputs and outputs cannot be subdivided. For example, if a first wallet is initially empty and receives a transaction output of 20 BTC from a second wallet, the first wallet then stores that 20 BTC output for future use as a transaction input. To send 15 BTC, the first wallet must use the 20 BTC as an input, 15 BTC of which will be a spent output that is sent to the desired destination and 5 BTC of which will be an unspent output, which is transaction change that returns to the first wallet. A wallet with digital assets stored as multiple digital outputs can select any combination of those outputs for use as digital inputs in a spending transaction.

For transactions involving sending digital assets from exchange wallets to non-exchange wallets (e.g., when a user requests a withdrawal of digital assets from the user's exchange account), a digital asset exchange may employ systems and methods to reduce transaction change, e.g., to avoid a temporary decrease in liquidity due to the unavailability of funds during a transaction confirmation period, to which the change in systems such as Bitcoin is subject.

To manage and/or reduce transaction change, in embodiments, an exchange may maintain wallets containing varying sized digital outputs so that an output or combination of outputs can be selected as digital input for a transaction, where the total input amount can have a size either equal to or greater than but close to the transaction amount. Accordingly, the exchange may employ a wallet balancing module running one or more balancing algorithms on one or more processors to distribute digital assets to wallets in digital outputs of various sizes and various quantities of each size. These output sizes and quantities thereof may be pre-determined and programmed into the wallet balancing module and/or may be adjusted algorithmically to better reduce transaction change in light of actual current or historical exchange transaction activity. Wallet balancing operations may be performed continuously, periodically throughout a day, once a day (e.g., at midnight), once a week, at some other interval, as balancing is required for one or more transactions, and/or as the wallet balancing module determines a wallet imbalance that exceeds a threshold tolerable imbalance. In embodiments, an exchange wallet balancing module may perform balancing operations after receiving a digital asset withdrawal request from a user and before transferring the digital assets to the user.

An exchange may also reduce transaction change by programming multiple outputs for a single transaction. In embodiments, digital asset withdrawals may be processed only at specified times or periodically, e.g., in the morning and in the evening. Such a system may facilitate batch processing of withdrawals using multiple digital transaction outputs. In embodiments, digital asset storage or protection services, such as insurance or storage warranties, may be offered through a digital asset exchange. Transaction insurance or warranties may also be offered, e.g., to guarantee an exchange transaction for a particular volume at a particular price.

In embodiments of a digital asset exchange in accordance with the present invention, one or more types of order books may be used. For example, in embodiments, a digital asset exchange may feature central limit order books that follow a price-time priority model.

In embodiments, a continuous order book and/or auction order book may be used with any pair of digital assets and/or digital asset and fiat currency. For example, in embodiments the following trading pairs and order books may be available:


	Continuous Order Book	Auction Order Book

BTC/USD	Yes	Yes
ETH/USD	Yes	Yes
ZEC/USD	Yes	Yes
ETH/BTC	Yes	No
ZEC/BTC	Yes	No
ZEC/ETH	Yes	No

In the above example, BTC/USD is a pairing of Bitcoin with U.S. dollars, ETH/USD is a pairing of Ethers and U.S. Dollars and ETH/BTC is a pairing of Ethers and Bitcoin.

In embodiments, both a continuous order book and an auction order book may not be available, for example, an auction order book may not be available for an ETH/BTC pairing. In embodiments, however, an auction could be provided based on digital currency to digital currency pairings, such as ETH/BTC. In embodiments, other pairings may also be available such as other digital assets with other fiat currencies, or other digital asset pairs.

In embodiments, a digital asset exchange may operate during limited hours, or may operate 24 hours a day, seven days a week, except for brief maintenance periods.

In embodiments, clients may submit as many orders as desired with any of the execution options described below. Alternatively, in embodiments, the number of orders may be restricted.

In embodiments, a digital asset exchange may be a full reserve exchange in which all orders are fully funded. In full reserve exchange embodiments, a client's outstanding interest on orders books of the digital asset exchange cannot exceed their account balance at any time and all open orders reduce a client's available balance until such orders are fulfilled or canceled. In other embodiments, a digital set exchange may offer margin trading.

In embodiments, a digital asset exchange may support the following order types and execution options:


			Can	Can Rest
			Trade	on	Can
			Against	Continuous	Trade
		Specifies	Resting	Order	in
	Description	Price	Orders	Book	Auction

Market	Filled immediately against resting	No	Yes	No	No
	orders at the current best available
	price.
Limit	Filled at or better than a specified	Yes	Yes	Yes	Yes
	price. Any quantity that is not filled
	rests on the continuous order book
	until it is filled or canceled.
Limit:	Filled immediately at or better than	Yes	Yes	No	No
Immediate-	a specified price. Any quantity that
or-Cancel	is not filled immediately is canceled
(IOC)	and does not rest on the continuous
	order book.
Limit:	Rests on the continuous order book	Yes	No	Yes	Yes
Maker-or-	at a specified price. If any quantity
Cancel	can be filled immediately, the entire
(MOC)	order is canceled.
Limit:	Rests on the auction order book and	Yes	No	No	Yes
Auction-	is filled at or better than a specified
Only (AO)	price at the conclusion of an
Limit	auction. Any quantity that is not
	filled is canceled.

In embodiments, the digital asset exchange may also support an order type that initiates a block trading workflow to source liquidity for large block quantities.

It will be appreciated that in embodiments, different combinations of order types may be available and in embodiments, additional order types may be available and some order types may not be available. In embodiments, order types may differ for pairings of digital assets and/or fiat currencies.

In embodiments, a digital asset exchange may have a continuous book. The continuous book may support market orders and/or limit orders.

In embodiments, a continuous order book may be implemented, by way of example, in accordance with the following:

1. Alice places a limit order to buy 16.65 BTC at a price of 5885.65 USD.

2. Bob places a limit order to sell 21.84 BTC at a price of 5924.85 USD.

3. Both orders rest on continuous order book.

In embodiments, limit orders have a side, a limit price in fiat (e.g. USD) and a quantity in digital asset (e.g., Bitcoin or Ether). Example:

In embodiments, continuous book limit orders support the following execution options:

Option 1: Standard (Good until canceled)

The order may be filled in part or fully before being booked. The order will rest on the book until complete filled or cancelled.

Option 2: Immediate or Cancel

The order never rests on the book. The order is filled to the extent possible based on existing orders on the order book, and any remainder is cancelled.

Option 3: Market or Cancel

The order rests on the book to add liquidity. The order will be cancelled if any part of it would be filled immediately.

In embodiments, a continuous book may offer market buys. Market buys may be placed with a gross notional value in fiat (e.g., USD). A fee may be deducted from the gross amount. Market buys are filled against resting orders on the book. Any remainder to the order is cancelled when filled. As a circuit breaker, in embodiments, a threshold may be applied to a market buy, e.g., filling up a market buy up to a fixed percentage (e.g., 20%) or an aggregate amount (e.g., x digital assets or y fiat) against the market at time of order, with the remainder of the order being cancelled.

In embodiments, market buys in the continuous book may be implemented, by way of example, in accordance with the following:

1. Charlie wants to buy 5000 USD worth of bitcoin. He places a market buy order that is immediately filled against Bob's resting limit order to sell 21.849 BTC at a price of 5924.98 USD.

2. Charlie receives 0.84177499 BTC which his 4987.50 USD worth of BTC at the current market price of 5924.98 USD. 4968.50 USD is the net notional value of Charlie's market buy, which is the 5000 USD gross notional value of the market buy less his 12.50 USD fee.
3. Bob's limit sell continues to rest on the books with a remaining quantity of 21.007225 BTC.

In embodiments, a continuous book may offer market sells. Market sells are placed with a quantity in digital assets. As a circuit breaker, in embodiments, a threshold may be applied to a market sell, e.g., filing up a market sell up to a fixed percentage (e.g., 20%) or an aggregate amount (e.g., x digital assets or y fiat) against the market at time of order, with the remainder of the order being cancelled.

In embodiments, market sells in the continuous book may be implemented, by way of example, in accordance with the following:

1. David wants to sell 3 BTC at whatever the market price is. He places a market sell order that immediately crosses with Alice's resting limit order to buy 16.65 BTC at a price of 5885.65 USD.

2. David nets 17,612.81 USD form his market sell. 17,656.95 USD less his 44.14 USD fee.

3. Alice's limit buy continues to rest on the books with a remainder quantity of 13.65 BTC.

In embodiments, the priority of matching orders resting on the books may be filled in using price time priority.

In embodiments, priority of matching orders resting on the books filled in using price time priority may be implemented, by way of example, in accordance with the following:

At T1: Alice places a limit order to buy 2 BTC at 5788.52 USD.

At T2: Charlie places a limit order to buy 0.5 BTC at 5788.58 USD

At T3: Bob places a limit order to buy 3 BTC at 5788.52 USD

At T4: David places a limit order to sell 5.25 BTC at 5788.50 USD

David's order then completely fills, crossing first with Charlie then Alice and then partially filling Bob's order, which was placed last time at an acceptable price. Because of price improvement, David's order fills at a higher price than his limit price.

TABLE 1

PARTICIPANT	ORDER TIME	ORDER PRICE	FILLED QUANTITY	FILLED PRICE	RESTING QUANTITY

∨ David	X + 3	5788.50 USD	0.5 BTC	5788.55 USD	4.75 BTC
∧ Charlie	X + 1	5788.55 USD	0.5 BTC	5788.55 USD	0 BTC
∧ Alice	X	5788.52 USD	0 BTC	5788.52 USD	2 BTC
∧ Bob	X + 2	5788.52 USD	0 BTC	5788.52 USD	3 BTC

TABLE 2

PARTICIPANT	ORDER TIME	ORDER PRICE	FILLED QUANTITY	FILLED PRICE	RESTING QUANTITY

∨ David	X + 3	5788.50 USD	2 BTC	5788.52 USD	2.75 BTC
∧ Alice	X	5788.52 USD	2 BTC	5788.52 USD	0 BTC
∧ Bob	X + 2	5788.52 USD	0 BTC	5788.52 USD	3 BTC

TABLE 3

PARTICIPANT	ORDER TIME	ORDER PRICE	FILLED QUANTITY	FILLED PRICE	RESTING QUANTITY

∨ David	X + 3	5788.50 USD	2.75 BTC	5788.52 USD	0 BTC
∧ Bob	X + 2	5788.52 USD	2.75 BTC	5788.52 USD	0.25 BTC

TABLE 4

PARTICIPANT	ORDER TIME	ORDER PRICE	RESTING QUANTITY

∧ Bob	X +2	5788.52 USD	0.25 BTC

In embodiments, resting limit order could also be filled on a continuous book in price-time priority.

In embodiments, resting limit order filled on a continuous book in price-time priority may be implemented, by way of example, in accordance with the following:

1. At time X+1, Charlie's resting limit buy order for 0.5 BTC at $5,786.55 is filled.

2. At time X, Alice's resting limit buy order for 2 BTC at 5788.52 USD is completely filed.

3. At time X+2, Bob's resting limit buy order for 3 BTC at 5788.52 US is partially filed for 2.75 BTC, 0.25 BTC remains resting on the book.

In embodiments, a digital asset exchange may have an auction order book. In embodiments, the auction order book is blind but the public auction events contain information that allows market participants to understand when there is an imbalance of buy or sell interest. In embodiments, the auction order book supports auction-only (AO) market and limit orders. These orders rest until the auction runs, at which time the orders will be either filled or cancelled. In general, self-trading should not be not allowed. An incoming order that would cross with a resting order on the auction book from the same account is cancelled.

In embodiments, a digital asset exchange in accordance with the present invention may conduct auctions for certain trading pairs periodically (e.g., every day (including weekends and holidays)) and/or aperiodically (e.g., a specific announced times, which may be irregular). Such auctions offer a technical advantage of fostering moments of elevated liquidity and price discovery.

In embodiments, auctions may be implemented, by way of example, in accordance with the following representative schedules:


BTC/USD AUCTION SCHEDULE

New York	8 am	3:50 pm	3:51-	3:59 pm	3:59:15-	4 pm
			3:59 pm		3:59:45 pm
UTC	12:00	19:50	19:51-	19:59	19:59:15-	20:00
(EDT)			19:59		19:59:45
UTC	13:00	20:59	20:51-	20:59	20:51:15-	21:00
(EST)			20:50		20:59:45
SGT/HKT	11 am	6:50 pm	6:51-	6:59 pm	6:59:15-	7 pm
			6:59 pm		6:59:45 pm
JST	12:00	19:50	19:50-	19:59	19:50:15-	20:00
			19:59		19:59:45
UTC	03:00	10:50	10:51-	10:59	10:59:15-	11:00
			10:59		10:59:45
	Begin	First	The auction	Auction-	The auction	Auction
	accepting	auction	simulation	Only (AO)	simulation	runs.
	orders	simulation	is repeated	Limit	is repeated	Auction-Only
	for	runs.	and the	orders may	and the	(AO) Limit
	auction.	First	indicative	no longer	indicative	orders are
		indicative	price is	be canceled	price is	filled or
		price is	published	but may still	published	cancelled.
		published	every	be placed.	every 15	If successful,
		via	minute.		seconds.	auction
		API and				results are
		website				published as a
		UI.				bulk trade via
						API and
						website UI.


ETH/USD AUCTION SCHEDULE

New York	8 am	3:50 pm	3:51-	3:59 pm	3:59:15-	4 pm
			3:59 pm		3:59:45 pm
UTC	12:00	19:50	19:51-	19:59	19:59:15-	20:00
(EDT)			19:59		19:59:45
UTC	13:00	20:50	20:51-	20:59	20:51:15-	21:00
(EST)			20:50		20:59:45
	Begin	First	The auction	Auction-	The auction	Auction
	accepting	auction	simulation	Only (AO)	simulation	runs.
	orders	simulation	is repeated	Limit	is repeated	Auction-Only
	for	runs.	and the	orders may	and the	(AO) Limit
	auction.	First	indicative	no longer	indicative	orders are
		indicative	price is	be canceled	price is	filled or
		price is	published	but may still	published	cancelled.
		published	every	be placed.	every 15	If successful,
		via	minute.		seconds.	auction
		API and				results are
		website				published as a
		UI.				bulk trade via
						API and
						website UI.


ZEC/USD AUCTION SCHEDULE

New York	8 am	3:50 pm	3:51-	3:59 pm	3:59:15-	4 pm
			3:59 pm		3:59:45 pm
UTC	12:00	19:50	19:51-	19:59	19:59:15-	20:00
(EDT)			19:59		19:59:45
UTC	13:00	20:50	20:51-	20:59	20:51:15-	21:00
(EST)			20:50		20:59:45
	Begin	First	The auction	Auction-	The auction	Auction
	accepting	auction	simulation	Only (AO)	simulation	runs.
	orders	simulation	is repeated	Limit	is repeated	Auction-Only
	for	runs.	and the	orders may	and the	(AO) Limit
	auction.	First	indicative	no longer	indicative	orders are
		indicative	price is	be canceled	price is	filled or
		price is	published	but may still	published	cancelled.
		published	every	be placed.	every 15	If successful,
		via	minute.		seconds.	auction
		API and				results are
		website				published as a
		UI.				bulk trade via
						API and
						website UI.

In embodiments, the auction order book may have time constraints, so that auction order windows may only be placed within a specified time window. Thus, the auction order book for a given auction may open a set time period in advance of the auction (e.g., 8 hours before the auction begins), as the opening of the auction order window. For example, if an auction is set to begin at 4:00 p.m. Eastern Standard Time, the Auction could begin at 8:00 a.m. Eastern Standard Time, as illustrated above.

In embodiments, once an auction window opens, auction-only order may not be cancelled after the final indicated price has been published, e.g., one minute before the auction runs. In the above example, that would be 3:59 p.m.

In embodiments, auction-only orders may be accepted up until the auction runs.

In embodiments, auction only orders placed outside of the auction order window may be rejected.

In embodiments, at a set time period before the auction begins, e.g., 10 minutes, an indicative auction event window may be opened. An indicative auction event is a simulation of what would happen if the auction ran at that point in time. In embodiments, an indicative auction uses the same pricing algorithm as the final auction price determination. In embodiments, although the auction order book is blind, indicative auction events show when there is a buy/sell interest imbalance so participants may adjust their orders.

During an indicative auction window, indicative results may be published at set time intervals, such as once a minute, twice a minute, four times a minute, to name a few, and will continue to be published until the indicative auction window closes. In embodiments, the indicative auction window will not close until the auction is run.

In the example above, for an auction beginning at 4:00 p.m. Eastern Standard Time, an indicative auction window may be opened 10 minutes prior at 3:50 p.m. Eastern Standard Time. Indicate results are published once a minute starting at the opening of the indicative auction window at 3:50 p.m. Eastern Standard Time, 10 minutes before the 4:00 p.m. auction. Starting at one minute before the auction window, 3:59 p.m. Eastern Standard Time, the indicative price may be published every 15 seconds. An indicative auction window will close when the auction window opens at 4:00 p.m., with the last indicative price published at 3:59:45 p.m. Eastern Time. Of course, other time periods can be used to set the opening and closing of the indicative auction windows and one or more intervals of publication can be used in that windows.

FIG. 55 illustrates an example of indicative auction results as may be published during an indicative auction window.

In embodiments, the final auction run at a final auction run time, e.g., 4:00 p.m. Eastern Standard Time in the above examples. In embodiments, at the final auction run time, no more orders on the continuous or auction order books are accepted. In embodiments, the midpoint of the best bid and best ask from the auction price will be taken as the auction collar price. In embodiments, an index value may be taken as the auction collar price.

The final auction price for every auction is established as the price that executes the greatest aggregate quantity and minimizes the imbalance between buy and sell orders across both the auction and continuous order books. The imbalance is defined as the absolute value of the difference between total buy orders and total sell orders at a given price across both the auction and continuous order books. Other pairings and timings may be used in accordance with the embodiments of the present invention.

Within this auction design, the market is open to accepting orders until the time the auction algorithm runs.

In embodiments, limits order may be placed in auctions. Typically, limit orders have a side (e.g., buy or sell), a limit price in fiat (e.g., USD), and a quantity in digital asset (e.g., BTC).

In embodiments, once a limit order is placed for an auction, the order will rest until the auction runs and the auction window closes.

In embodiments, if the auction succeeds, limit orders will be filled based on:

1. Price-time priority

2. If the auction price is equal to the limit price or a price improvement (auction price is lower than the limit buy order or higher than the limit sell order).

In embodiments, auction-only market buys and sells are like their continuous book counterparts except that they will rest on the book until they are cancelled or the auction runs. If the auction succeeds, auction-only market orders may be filled according to time priority, unlike in the continuous book where market orders are filled immediately. Although uncommon, auction-only market orders may be partially filled or even unfilled. This can happen when the auction has an unusually large buy-sell interest imbalance.

In the example below, there are two prices, $99 and $100, that will execute the greatest aggregate quantity across both the auction and continuous order books, which is 30. However, at the $99 price, the imbalance between buy and sell orders is greater than it is at the $100 price. As a result, the final auction price will be $100 because this price executes the greatest aggregate quantity and minimizes the imbalance between buy and sell orders across both the auction and continuous order books.


	Total Buy	Total Sell	Auction
Price	Interest	Interest	Quantity	Imbalance

$98	100	10	10	90
$99	60	30	30	30
$100	30	30	30	0
$101	10	60	10	50
$102	0	100	0	100

In embodiments, all limit orders at the same specified price are treated equally and executed in the order in which they were received. Partially filled resting limit orders retain their priority until canceled.

In embodiments, a Walrasian auction that seeks to identify the price with the greatest aggregate quantity may be employed. In such embodiments, each possible price is tested summing up buy and sell quantities. The price that would execute the greatest possible “wins” may be selected. In embodiments, in the event of a tie between two or more prices that would execute the same quantity, the exchange may select the price that minimizes the imbalance between the buy and sell orders across the auction order book and/or the auction and continuous order books. In embodiments, in the event of a tie between two or more adjacent prices that would execute the same quantity, the auction price may be the midpoint of the two adjacent prices. In embodiments, in the event of a tie between two or more adjacent prices that would execute the same quantity, the auction price may be the price that is closest to the collar price. In the event that the two prices are equally close to the collar price, the auction price may be the midpoint of the two prices.

In embodiments, the auction price is established as the price that executes the greatest aggregate quantity (i.e. auction quantity) across both the auction-only and continuous order books. It is possible that there is not an exact match between buy and sell interest at this price, and so some orders will partially filled or not be filled at all. Auction-only market orders may be filled by time priority. To avoid time conflicts, the market may be paused for a brief period (e.g., milliseconds) while the final price, quantity, and controls are calculated.

In embodiments, in order to provide the most liquidity to the marketplace, resting limit orders on the continuous order book may be used in the auction price and quantity calculations. In embodiments, for a resting limit order to be eligible for inclusion, the auction price must be equal to or better than the resting limit price (less than or equal to for bids, or greater than or equal to for asks). Resting limit orders on the continuous order book may be filled according to time priority and are subject to improvements in price.

In embodiments, the auction may fail if an equilibrium cannot be achieved, for example, if the auction quantity is zero. A zero auction quantity could occur when no auction orders are received, or if only one-way auction orders are received (e.g., buy only or sell only orders). In embodiments, a collar may also be placed on the auction. For example, a collar may be placed on the auction price, by using fixed percentage (e.g., 1 percent, 5 percent, 10 percent) of a benchmark against the continuous book price at given time period or set of time period. In embodiments, the benchmark could be a midpoint of the spot price of the continuous book price at the given time period—e.g., auction price. In embodiments, the benchmark could be a weighted average (such as a time weighted average, volume weighted average, or time and volume weighted average) of the continuous book during a pre-set window (e.g., 10 minutes for before auction, 1 hour before the auction, 12 hours before the auction, 24 hours before the auction, to name a few).

In embodiments, digital asset exchange computer system 3230 may set a collar for the auction trade, including a collar minimum and a collar maximum. First, the digital asset exchange computer system 3230 may access, from at least a first database stored on a computer readable medium operatively connected to the digital asset computer system, pricing data associated with the first pair at a predefined time associated with a time of the auction trade order. In embodiments, pricing data can include a spot price. In embodiments, a pricing data may be based on the last transaction immediately prior to the auction. In embodiments, a pricing data may be based on an average of the most recent bid/ask price for the digital asset. In embodiments, the pricing data may be set based on a blended digital asset price as discussed elsewhere herein. For example, a single exchange digital asset price could be determined based on a volume weighted average and/or time weighted average of recent digital asset pricing. In embodiments, a blended digital asset price may be based on a pricing from digital assets taken from a plurality of exchanges (such as qualified exchanges). In embodiments, pricing data may be a blended digital asset price comprising a plurality of digital asset exchanges (e.g., 4) executing trade data for a fixed period of time (e.g., a 10 minute period) using a volume weighting with a fixed percentage (e.g., 5%) of the highest priced trades and a second fixed percentage (e.g., 5%) of the lowest priced trades removed. The digital asset exchange computer system 3230 may calculate a collar minimum for the auction based on the pricing data less an amount equal to a first percentage of the pricing data, and a collar maximum for the auction based on the pricing data plus an amount equal to the first percentage of the pricing data. Thus, a collar may be based on a spot price at the time for the auction, plus or minus a defined range, such as a percentage of the spot price or other pricing data. In embodiments, the collar could be set using percentages such as 1%, 2%, 3%, 5%, 10% of the spot price or other pricing data, to name a few. By way of illustration, if a 5% collar is used with a spot price of 1 BTC=USD$10,000, the collar would be set at between USD$9,500 and USD$10,500.

Accordingly, in embodiments, in substep S5604a, the digital asset exchange computer system 3230 may retrieve a current pricing information (e.g., bid/ask price) from continuous trading order book 5702a associated with a first digital asset pairing and establish a spot price for the first digital asset pairing. As noted above, in embodiments, the spot price may be the average of the current bid/ask price or may be the price used in the last transaction in the continuous trading book, to name a few. In embodiments, the spot price may be a blended digital asset price, in which one or more different order books from one or more digital asset exchanges or index databases may be required to be access to obtain such price. In embodiments, the blended digital asset price may be obtained by being calculated and/or by accessing a blended digital asset price database (not shown). In substep S5604b, the digital asset exchange computer system may establish the collar, for example, based on adding and/subtracting a fixed percentage of the spot price to the spot price as discussed above, for example.

In embodiments, the collar may be a blended digital asset price consisting of 4 digital asset exchanges' executed trade data for a 10 minute period volume weighted with 5% of the highest priced trades and 5% of the lowest priced trades removed.

In embodiments, the digital asset exchange computer system 3230 may determine whether the price in the auction is within the limits of the collar determined above (e.g., at or above the collar minimum and at or below the collar maximum).

In embodiments, if the final auction price falls outside the collar, the auction may also fail.

In embodiments, in the event auction fails, the exchange may cancel all the auction-only orders unfilled, close the auction and/or publish as market data for the auction that it failed, either with or without a reason for such failure. In embodiments, where the auction fails because the final auction price falls outside the collar, the price and quantity of the auction that would have otherwise been executed may be published as part of the market data, with an indication that the auction failed.

In embodiments, if the event auction succeeds, the digital asset exchange may fill all eligible auction only and/or continuous book order by strict time priority. In embodiments, continuous book orders may not be filled. The digital asset exchange may also notify the market participants whose orders were filled, such as through the alert system discussed herein. In embodiments, the digital asset exchange may also notify the market participants whose orders were not filled, such as through the alert system discussed herein. The digital asset exchange may also cancel all remaining unfilled and partially filled auction-only orders to the extent such partially filled auction-only orders remain unfiled. The digital asset exchange may then close the auction order book for this auction window. In embodiments, the digital asset exchange may published a market data auction event showing the outcome of the auction, through, e.g., an API or other electronic publication. In embodiments, historical trades may show a bulk trade event for the auction volume. In embodiment, normal operations, such as continuous order book trading, may resume once the auction process is completed.

In embodiments, in addition to publishing the final auction price and whether or not it failed, the collar price may also be published as part of an API or other electronic publication.

In embodiments, marketplace controls may be put in place in an effort to foster a fair and orderly market. Examples of marketplace controls can include one or more of the following:

- Orders: Automatic cancellation of any order, or the remaining portion of any order, on a continuous order book that would move the market price by more than a defined percentage (e.g., 20%) in either direction, as compared to the prior prevailing market price;
- Auctions: Automatic cancellation of an auction if the final auction price deviates from the collar price by more than five percent in either direction at the time the auction runs; and
- Self-trade prevention: a digital asset exchange may prohibit a client from crossing with itself on a continuous order book or with itself on an auction order book.

In embodiments, other controls may be put in place consistent with the present invention.

A digital asset exchange may, in embodiments, declare a transaction null and void when it is determined to be clearly erroneous.

Errors or disruptions may occur on an exchange during the order entry, order matching, or trading process. In embodiments, if any such errors or disruptions occur, the digital asset exchange may cancel any order and/or reverse any trade, in whole or in part.

In embodiments, the results of each auction may be made available as pricing data for a digital asset though, e.g., an API. In general, an API is a set of routines or subroutines, protocols and tools for building software applications, which facilitate communications between various software components. An API may be for a web-based system, operating system, database system, computer hardware or software library. An API specification can take many forms, but often includes specifications for routines, data structures, object classes, variables or remote calls. POSIX, Windows API and ASPI are examples of different forms of APIs. Documentation for the API is usually provided to facilitate usage.

In embodiments, auction order book data may not be publically available. In embodiments, auction order book data may be available with a time delay after each auction completes through, e.g., an API. In embodiments, auction data, like other digital asset pricing data, may be used an input to a blended digital asset price, or other index or benchmark.

In embodiments, a digital asset exchange may publish market data using APIs, such as public REST APIs and private REST APIs. Public REST APIs may provide market data such as: current order book, recent trading activity and/or trade history, to name a few. Private REST APIs allows participants to manage both orders and funds, by for example, placing and/or cancelling orders, viewing active orders, viewing trading history and/or trade volume, retrieving available balances, to name a few.

In embodiments, individual auction-only and continuous order book market participants may be notified their order has been filled via an email, sms, push notification, or other message and/or a status update on their activity feed. In embodiments, the same alerting system may be used for continuous order book execution.

FIGS. 34A-B are a schematic diagram and corresponding flow chart showing participants in and processes for a digital asset exchange system in accordance with exemplary embodiments of the present invention. A digital asset exchange may provide conversions among digital math-based assets and fiat currencies. In embodiments, conversions may be performed between differently denominated digital math-based assets. In embodiments, a digital asset exchange may facilitate the buying and selling of digital assets in exchange for other digital assets, non-digital assets, fiat currencies, or other financial instruments. The parties to such a transaction may be individuals, organizations, and or institutions. In embodiments, the exchange itself or its operator or owner may be the counter-party to an exchange transaction.

FIG. 34B is a flow chart corresponding to the digital asset exchange system illustrated in FIG. 34A. In a step S3150, one or more exchange computers comprising an exchange computer system may receive from a digital asset buyer acceptances of transaction terms comprising a digital asset price and a quantity of digital assets.

In a step S3152, the exchange computer system may receive from the digital asset buyer authorization to transfer funds from the digital asset buyer's account in an amount based at least in part upon the accepted digital asset price.

In a step S3156, the exchange computer system may receive from a bank, a notification of funds transferred to an exchange bank account from the digital asset buyer.

In a step S3158, the exchange computer system may provide to a digital asset seller a notification of funds transferred to the exchange bank account from the digital asset buyer.

In a step S3160, the exchange computer system may provide to a digital asset seller, an instruction to transfer digital assets to a digital wallet associated with the seller in an amount based at least in part upon the accepted digital asset quantity. In embodiments, the digital asset seller may transfer digital assets to a digital wallet associated with (e.g., owned by and/or operated by) the exchange. The exchange may hold such funds in escrow until the buyer's payment is received, e.g. into a bank account (for fiat currencies) or into a digital wallet (for other digital assets).

In a step S3164, the exchange computer system may receive from the digital asset buyer a notification of received digital assets from the digital asset seller.

In a step S3166, the exchange computer system may provide to the bank, an instruction to release the digital asset buyer's funds to the digital asset seller.

In another embodiment, the exchange can act as a counter-party to transactions where digital assets are bought and/or sold for a differently denominated digital asset or a fiat currency. In embodiments, the system illustrated in FIG. 34A can be used to perform exchange transactions with multiple counter-parties. An exchange computer system may identify a digital asset seller and a plurality of buyers. The exchange computer system may determine, obtain, or receive (e.g., from computers, digital asset kiosks, or user electronic devices associated with the buyers) public addresses of digital asset wallets associated with the buyers. The exchange computer system may also determine, obtain, or receive digital wallet information (e.g., public address, public key, and/or private key) associated with the seller. In embodiments, wallet information of any exchange participant may be stored by the exchange computer system in one or more databases, which may be accessed as part of a transaction. A participant in an exchange transaction may also input (e.g., via downloadable software or a website associated with the exchange) and/or otherwise transmit to the exchange required digital wallet information from which to send or in which to receive digital assets. The exchange computer system may use the digital wallet information of the exchange transaction participants to generate transaction instructions. For example, the exchange computer system may pre-program instructions to transfer a certain amount of digital assets from the seller wallet to each buyer wallet. The exchange computer system may also input the digital wallet access credentials (e.g., a public and private key) so that the transaction may proceed.

The present invention relates to methods, systems and program products for lending digital assets, such as crypto currency, and related products.

The present invention creates a process where digital assets may be lent for a set period of time (“loan duration” or “duration”) based on an agreed interest rate (“interest rate”) through a competitive bidding process. In embodiments, rather than using an agreed interest rate, an agreed payment amount for the loan may be used. In embodiments, examples of loan duration may include, e.g., 1 day, 1 week, 2 weeks, 1 month, 3 month, 6 month, 12 month, periods to name a few. Other loan durations may also be selected consistent with exemplary embodiments of the present invention.

In order to define a market for loaning of digital assets, one or more order books may be set up on a digital asset exchange, such as Gemini, Coinbase, to name a few. In embodiments, a regulated digital asset exchange may be preferred. In embodiments, the digital asset exchange, or other platform, may be maintained by as a trust company, a regulated trust company, a bank, a broker dealer, or some other form of entity, to name a few. In embodiments, the computer systems operated by entities involved in the process may be provided at the same data center and/or may have fast interconnections to provide for more efficient and timely transactions. In embodiments, a FIX order message system, cross connect message system and/or a third party order management system provider, to name a few, may be used to send and enter orders.

In embodiments, the use of surveillance technologies, such as NASDAQ Smart surveillance technologies, such as used by Gemini, is also preferred.

In embodiments, order books may take various forms, such as continuous order books, auction order books, block trading order books, to name a few. For a detailed description of such order books, please see U.S. patent application Ser. No. 15/920,042, filed Mar. 13, 2018 and entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR VERIFYING DIGITAL ASSETS HELD IN A CUSTODIAL DIGITAL ASSET WALLET, U.S. patent application Ser. No. 15/973,175, filed May 7, 2018 and entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR EXCHANGING DIGITAL ASSETS FOR FIAT AND/OR OTHER DIGITAL ASSETS and U.S. patent application Ser. No. 15/973,140, filed May 7, 2018 and entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR EXCHANGING DIGITAL ASSETS FOR FIAT AND/OR OTHER DIGITAL ASSETS, which are hereby incorporated by reference as if fully set forth herein.

In embodiments, a digital asset computer system may be used to lend digital assets. In embodiments, digital assets may be lent via a digital asset computer system using a continuous order book. In other embodiments, digital assets may be lent via a digital asset computer system using an electronic auction. In alternate embodiments, digital assets may be lent via a digital asset computer system using a block trade order book. In embodiments an over the counter (OTC) order book may be used.

In embodiments, digital assets may be lent via a digital asset computer system using a continuous order book. FIGS. 61A-B shows an exemplary process for the loaning of digital assets by a digital computer system. In a step S6100, a digital asset computer system comprising one or more computers, the digital asset computer system being operatively connected to a decentralized digital asset network that uses a decentralized ledger in the form of a blockchain maintained by a plurality of physically remote computer systems to track at least one of asset ownership or transactions in a digital asset system, one or more exchange account databases stored on non-transitory computer-readable memory and comprising a plurality of exchange accounts, provides digital asset account information for a respective exchange account and user authentication data.

In a step S6101, the digital asset computer system receives, a deposit of digital assets to at least a first respective exchange account, from a first digital asset account, through use of a first digital asset account identifier associated with the first respective exchange account, where the deposit is recorded on the decentralized electronic ledger.

In a step S6102, the digital asset computer system provides a loan order database associated with a first digital asset and a first duration period, stored on the non-transitory computer-readable memory comprising at least a digital asset borrow order information comprising for each borrow order: borrow order identification information, borrow order digital asset quantities and corresponding borrow order interest rates and digital asset lend order information comprising for each lend order: lend order identification information, lend order digital asset quantities and corresponding lend order interest rates. In embodiments, the borrow order information and/or lend order information may include user identifications information, a time stamp, a credit score associated with the borrower or lender, margin information related to the borrower or lender and account balance information, to name a few.

In a step S6103, the digital asset computer system provides an electronic ledger comprising digital asset account balance data for each of the exchange accounts.

In a step S6104, the digital asset computer system receives, from a first user electronic device associated with a first user associated with a first exchange account, a first electronic digital asset borrow order comprising first borrow order information comprising a first borrow order digital asset quantity and a corresponding first borrow order interest rate.

As shown in FIG. 61B, in a step S6105, the digital asset computer system stores the first electronic digital asset borrow order information in the loan orders database.

In a step 6106, the digital asset computer system receives, from a second user electronic device associated with a second user associated with a second exchange account, a first electronic digital asset lend order comprising first lend order information comprising a lend order digital asset quantity from the deposit of digital assets and a corresponding lend order interest rate. In embodiments, step S6106 may occur either before or after step S6104. Thus, by way of example, in embodiments, a lend order may be received before a borrow order or a borrow order may be received before a lend order. Similarly, in embodiments, more than one lend order may be received before more than one borrow order, and vis-versa. Further, in embodiments, more than one lend order and/or more than one borrow order may be received in any order prior to matching in Step S6109, as discussed below. Thus, in embodiments, the digital asset system may store the first electronic asset lend order in the loan order database in step S6105.

In a step S6107, the digital asset computer system verifies that the first digital asset account balance data indicating a first digital asset account balance of a lender digital asset account associated with the second exchange account at least equals the lend order digital asset quantity.

In embodiments, the digital asset computer system may allow lenders to lend assets on margin. For example, the lender may be permitted to lend digital assets that are not already included in its account on the lender. In such case, the digital asset computer system may verify that the lender has sufficient assets to cover the value of the digital assets to be lent, wherein the assets may include fiat, digital assets or any other asset. In embodiments, the digital asset computer system, may verify the lender has sufficient credit, even without holding sufficient assets in the digital asset computer system, to go forward with the transaction.

In a step S6108, the digital asset computer system stores the first electronic digital asset lend order information in the loan orders database. In the case where the lend order is received before the borrow order, the first electronic digital asset borrow order may be stored in the loan order database at step S6108.

In embodiments, the digital asset computer system may receive a plurality of electronic digital asset lend orders and a plurality of electronic digital asset borrow orders. In embodiments the electronic digital asset lend order information and the electronic digital asset borrow order information from the plurality of borrow orders and lend orders is stored in the loan order database.

In a step S6109, the digital asset computer system matches the first electronic digital asset loan order with the first electronic digital asset lend order. In embodiments, where digital asset computer system may receive a plurality of electronic digital asset lend orders and a plurality of electronic digital asset borrow orders, a borrow order may be matched with one or more lend order and/or a lend order may be matched with one or more borrow orders.

In a step S6110, the digital asset computer system generates first machine-readable transaction instructions for a first loan transaction having a first transaction digital asset quantity satisfying the first electronic digital asset borrow order and the first electronic digital asset lend order.

In a step S6111, the digital asset computer system executes the first machine-readable transaction instructions by updating the electronic ledger by decreasing, by the first transaction digital asset quantity, the first digital asset account balance data corresponding to the lender digital asset account and increasing, by the first transaction digital asset quantity, second digital asset account balance data corresponding to a first borrower digital asset account associated with the first exchange account.

In embodiments, the digital asset computer system may send electronic transfer confirmations to one or both of the first and second user electronic devices at the completion of the transaction. The digital asset computer system may also send electronic transaction confirmations to a computer system associated with an institution associated with the exchange institutional account.

In embodiments the interest rate or lending rate may be used as a benchmark for a financial instrument. In embodiments, the financial instrument may be an exchange traded product. In embodiments the digital asset may be a derivative product of a type selected from the group consisting of: an exchange traded derivative product, a fund, a company, an exchange traded fund, a note, an exchange traded note, a security, a debt instrument, a convertible security, an instrument comprising a basket of assets including one or more digital math-based assets and an over-the-counter product, to name a few.

In embodiments, the first digital asset may be a digital math-based asset. In embodiments the digital asset may be Bitcoin, Ether, Litecoin, Bitcoin Cash or Zcash, to name a few. In embodiments, the digital asset may be a token, such as a stable value token.

In embodiments, the user authentication data may comprise a username and password. The user authentication data may also comprise multi-factor authentication data.

In embodiments, digital assets may be lent via a digital asset computer system using an auction. FIGS. 62A-C shows an exemplary process for the loaning of a first digital asset for a first duration by a digital computer system.

In a step S6200, a digital asset computer system generates a first electronic auction loan order book for the first digital asset for the first duration, on or after a first time associated with opening the electronic auction until a second time associated with closing the electronic auction. Part of this step includes a step S6201, of a digital asset computer system receiving a first plurality of auction loan orders associated with the first digital asset from a first plurality of user devices associated with a first plurality of users wherein each auction loan order may include characteristics representing the asset type of the first digital asset, the respective quantity of units of the first digital asset, a respective side of the transaction (borrow or lend), the duration of the loan and a respective interest rate on the loan. Another part of this step includes a step S6202, of a digital asset computer system verifying that each of the first plurality of auction loan orders is qualified based on the steps of the digital asset computer system verifying that the order characteristics of the respective loan order are valid auction order characteristics and, in the cases where the side of the transaction is lend, the digital asset computer system verifying that the respective user has sufficient amounts of the first digital asset to cover the first auction loan order if filled in full.

If step S6202 results in successful verification, the next step of step S6200 is step S6203, comprising a first step S6204 of the digital asset computer system updating each respective lender user account associated with each respective lender to set aside sufficient reserves in the first digital asset, sufficient to cover each respective auction loan order which has been successfully verified if filled in full and the step S6205, of the digital asset computer storing in the first electronic auction loan order book (on or more computer readable systems) each representative auction loan order which has been successfully verified.

In embodiments, in optional step S6206, the digital asset computer system may publish, at set time intervals starting with a third time and continuing until the second time, respective indicative results of the first auction loan order book if the auction were to close at the end of each respective time interval. The respective indicative results may comprise a respective indicative interest rate which is calculated by the digital asset computer system determining using the first auction loan order book, a respective indicative auction interest rate in terms of the first digital asset that will execute the greatest quantity of the first digital assets being transacted for the interest rate and in the case where more than one respective indicative auction interest rate is identified as having the same greatest quantity of the first digital assets being transacted, selecting as the respective indicative auction interest rate based on the midpoint of the two adjacent indicative auction interest rates identified for the fourth time. In embodiments, other tie breaking criteria may be used to select the indicative auction interest rate, exampled of which are discussed below. The respective indicative results also comprise a respective auction quantity, which is determined by the digital asset computer system, as the quantity of units of the first digital asset to be loaned at the respective indicative interest rate as of the fourth time.

In step S6207, the digital asset computer system closes the first auction loan order book, at the second time, and stops accepting new auction loan orders to be added to the first auction order book

In step S6208, the digital asset computer system calculates final results of the first auction loan order book. The final results comprise a final auction price interest rate at the second time which is calculated by the digital asset computer system determining, using the first auction loan order book at the second time, a final auction interest rate in term of the first digital asset that will execute the greatest quantity of first digital assets being transacted and in the case where more than one respective final auction interest rate is identified as having the same greatest quantity of the first digital assets being transacted, selecting as the respective final auction interest rate based on the midpoint of the two adjacent indicative auction interest rates identified for the fourth time. In embodiments, when the more than one respective final auction interest rate is identified as having the same greatest quantity of the first digital assets being transacted, the final auction interest rate may be selected by some other tie breaking criteria, including lowest imbalance, the lower rate, the higher rate, the rate closest to the U.S. treasury rate for the same duration, the rate closest to a benchmark crypto asset rate at the same duration. the rate closer to LIBOR at the same duration, the rate closer to the continuous order book at the time of the auction, and the rate closer to a predetermined index rate at the time of the auction, to name a few. The final results also comprise a final auction quantity, which is determined by the digital asset computer system, as the quantity of units of the first digital asset which match the final auction interest rate as of the second time.

In embodiments, the order book data may be used to create a benchmark to be used in a financial product. In embodiments, the financial product may be, by way of illustration, an exchange traded product, a fund, an exchanged traded note, an exchange traded product, a call, a put, an option, an exchange traded derivative product, a fund, a company, an exchange traded fund, a note, an exchange traded note, a security, a debt instrument, a convertible security, an instrument comprising a basket of assets including one or more digital math-based assets and an over-the-counter product, an interest rate future, a future on swaps, an option on interest rate futures, an interest rate swap, a bond forward, a floating rate agreement (FRA), a structured, product such as a note bond or bill, a foreign exchange future, a foreign exchange forward, a foreign exchange listed option, a currency linked note and a currency swaption, to name a few.

In embodiments, the first digital asset may be a digital math-based asset. In embodiments the digital asset may be Bitcoin, Ether, Litecoin, Bitcoin Cash or Zcash. In embodiments, the digital asset may be a token, to name a few.

In embodiments, other forms of order books may be used to lend digital assets, such as block trade order books and limited order books, to name a few. In embodiments, requests for quotes (RFQs) or OTC voice transactions may be used to lend digital assets.

In embodiments, a method for lending digital assets by a digital asset computer system includes: (a) providing, by the digital asset computer system comprising one or more computers, the digital asset computer system being operatively connected to a decentralized digital asset network that uses a decentralized electronic ledger in the form of a blockchain maintained by a plurality of physically remote computer systems to track at least one of asset ownership or transactions in a digital asset system, one or more exchange account databases stored on non-transitory computer-readable memory and comprising for a plurality of exchange accounts the following information: (i) digital asset account information for a respective exchange account; (ii) user authentication data; (b) receiving, by the digital asset computer system, a deposit of digital assets to at least a first respective exchange account, from a first digital asset account, through use of a first digital asset account identifier associated with the first respective exchange account, where the deposit is recorded on the decentralized electronic ledger; (c) providing, by the digital asset computer system, a loan order database associated with a first digital asset and a first duration period, stored on the non-transitory computer-readable memory comprising at least the following information: (i) digital asset borrow order information comprising for each borrow order: borrow order identification information, borrow order digital asset quantities and corresponding borrow order interest rates; (ii) digital asset lend order information comprising for each lend order: lend order identification information, lend order digital asset quantities and corresponding lend order interest rates; (d) providing, by the digital asset computer system, an electronic ledger comprising, for each of the plurality of exchange accounts, digital asset account balance data; (e) receiving, by the digital asset computer system from a first user electronic device associated with a first user associated with a first exchange account, a first electronic digital asset borrow order comprising first borrow order information comprising a first borrow order digital asset quantity and a corresponding first borrow order interest rate; (f) storing, by the digital asset computer system in the loan orders database, the first electronic digital asset borrow order information; (g) receiving, by the digital asset computer system, from a second user electronic device associated with a second user associated with a second exchange account, a first electronic digital asset lend order comprising first lend order information comprising a lend order digital asset quantity from the deposit of digital assets and a corresponding lend order interest rate; (h) verifying, by the digital asset computer system, that first digital asset account balance data indicating a first digital asset account balance of a lender digital asset account associated with the second exchange account at least equals the lend order digital asset quantity; (i) storing, by the digital asset computer system in the loan orders database, the first electronic digital asset lend order information; (j) matching, by the digital asset computer system, the first electronic digital asset loan order with the first electronic digital asset lend order; (k) generating, by the digital asset computer system, first machine-readable transaction instructions for a first loan transaction having: (i) a first transaction digital asset quantity satisfying the first electronic digital asset borrow order and the first electronic digital asset lend order; and (l) executing, by the digital asset computer system, the first machine-readable transaction instructions by updating the electronic ledger according to the following steps: (i) decreasing, by the first transaction digital asset quantity, the first digital asset account balance data corresponding to the lender digital asset account; and (ii) increasing, by the first transaction digital asset quantity, second digital asset account balance data corresponding to a first borrower digital asset account associated with the first exchange account. The method of claim 1, wherein the first digital asset is a digital math-based asset.

In embodiments, the first digital asset may be one or more of Bitcoin, Ether, Litecoin, Bitcoin Cash, Zcash or a token.

In embodiments, a method for conducting an electronic auction to loan a first digital asset for a first duration, on a digital asset computer system, includes: (a) on or after a first time associated with opening the electronic auction until a second time associated with closing the electronic auction, generating, by the digital asset computer system, a first electronic auction loan order book for the first digital asset for the first duration, comprising: (i) receiving, by a digital asset computer system from a first plurality of user devices associated with a first plurality of users, a first plurality of auction loan orders associated with the first digital asset, wherein each auction loan order specifies order characteristics comprising: (1) the first digital asset as digital asset type; (2) a respective quantity of units of the first digital asset; (3) a respective side of the transaction, where the side is either borrow or lend; (4) the first duration as the duration for the loan; and (5) a respective interest rate on the loan; (ii) for each of the first plurality of auction loan orders, verifying, by the digital asset computer system, each respective first auction loan order is qualified, based on the steps of: (1) verifying, by the digital asset computer system, the order characteristics of the respective loan order are valid auction order characteristics; (2) in the case where the side of the transaction is lend, verifying, by the digital asset computer system, the respective user has sufficient amounts of the first digital asset to cover the first auction loan order if filled in full; (iii) upon successful verification of each respective auction loan order in step (a)(ii), the steps of: (1) updating, by the digital asset computer system, each respective lender user account associated with each respective lender to set aside sufficient reserves in the first digital asset, sufficient to cover each respective auction loan order which has been successfully verified if filled in full; and (2) storing in first electronic auction loan order book, by the digital asset computer system on one or more computer readable mediums, each respective auction loan order which has been successfully verified; (b) starting with a third time and continuing until the second time, electronically publishing, by the digital asset computer system, at set time intervals between the third time and the second time, respective indicative results of the first auction loan order book if the auction were to close at the end of each respective time interval, wherein the respective indicative results comprise: (i) a respective indicative interest rate, which is calculated, as of a respective fourth time, by: (1) determining, by the digital asset computer system, using the first auction loan order book, a respective indicative auction interest rate in terms of the first digital asset that will execute the greatest quantity of the first digital assets being transacted for the interest rate; and (2) in the case where more than one respective indicative auction interest rate is identified as having the same greatest quantity of the first digital assets being transacted, selecting as the respective indicative auction interest rate by applying the following order of priority: (A) the midpoint of the two adjacent indicative auction interest rates identified for the fourth time; and (ii) a respective auction quantity, which is determined by the digital asset computer system, as the quantity of units of the first digital asset to be loaned at the respective indicative price interest rate as of the fourth time; (c) at the second time, closing the first auction loan order book, by the digital asset computer system, and stop accepting new auction loan orders to be added to the first auction order book; (d) after step (c), calculating, by the digital asset computer system, final results of the first auction loan order book, wherein the final results comprise: (i) a final auction price interest rate at the second time, which is calculated by: (1) determining, by the digital asset computer system, using the first auction loan order book at the second time, a final auction interest rate in term of the first digital asset that will execute the greatest quantity of first digital assets being transacted; and (2) in the case where more than one respective final auction interest rate is identified as having the same greatest quantity of the first digital assets being transacted, selecting as the respective final auction price interest rate by applying the following order of priority: (A) the midpoint of the two adjacent indicative auction interest rates identified for the fourth time; and (ii) a final auction quantity, which is determined by the digital asset computer system, as the quantity of units of the first digital asset which match the final auction interest rate as of the second time; and (e) publishing, by the digital asset computer system, for the first auction loan order book, auction results comprising: the first digital asset, the first duration, the final auction interest rate and final auction quantity.

In embodiments, the first digital asset may be one or more of a digital math-based asset, Bitcoin, Ether, Litecoin, Bitcoin Cash, a token and Zcash.

In embodiments, the loan may be collateralized by a stable value digital asset (e.g. Gemini Dollar, TrueUSD, USD Tether, Paxos Standard, and/or Bitcoin Air, to name a few) a fiat backed digital asset (e.g. Libra), and/or a commodity-backed digital asset (e.g. Digix Gold Tokens).

In embodiments, the third time is 10 minutes prior to the second time.

In embodiments, the plurality of fourth times are one minute apart from each other.

In embodiments, digital assets held in, e.g., a custodial account may be used in a return swap. In a return swap, a return on a first asset may be swapped or exchanged for the return on a second asset for a period of time. Conventionally, the owner of an asset with a volatile return will swap or exchange this return for a less volatile return. FIG. 63A illustrates an exemplary embodiment of a method of performing a total return swap including digital assets.

In the context of digital assets, technological challenges are created due to the nature of the digital assets, being tied to a blockchain, and having high level of volatility.

In embodiments, in a step S6300, a digital asset computer system that includes one or more computer, provides an electronic ledger that includes user account information associated with each user of a plurality of users. The user account information includes at least user identification information and user collateral information indicating a value of collateral associated with each user of the plurality of users. In embodiments, the user collateral information may include a value of digital assets in accounts associated with the user, a quantity of digital assets in accounts associated with the user, a value of fiat in accounts associated with the user and/or a value of other assets in accounts associated with the user, to name a few. In embodiments, the user account information may also include obligation information associated with each user's payment obligations to others.

As step S6301, the digital asset computer system provides to a first user device associated with a first user and a second user device associated with a second user, swap transaction information that includes details regarding the swap. In embodiments, the swap transaction information includes swap information, a swap duration, at least one fixing date, and at least one benchmark rate. In embodiments, the swap information identifies the assets involved in the swap and preferably includes at least one digital asset and may include another digital asset, fiat, or any other asset, to name a few. In embodiments, the at least one fixing date is a date on which an agreed to interest rate, discussed below, is applied to determine the payment owed on both sides of the swap. In embodiments, there may be additional fixing dates which may apply to one or both sides of the swap. In embodiments, the swap information may also include a swap quantity which identifies the quantity of assets that are involved in the swap. In embodiments, each swap may include a quantity of one with users entering into multiple swaps if they wish to swap quantities of more than one.

In step 6302, the digital asset computer system receives from a first user device, associated with the first user of the plurality of users, swap bid information including first user side information and a first interest rate. In embodiments, the first user side information indicates whether the first user is buying protection or selling protection in the swap. Users who are buying protection are generally trading the return on a digital asset such as bitcoin which is unknown, for example, for another predetermined return. In embodiments, a benchmark rate such as LIBOR may be used as a basis for the predetermined return. In embodiments, the predetermined return may be based on LIBOR plus some additional percentage. The two returns are swapped for the swap duration. In embodiments, the first interest rate is the first user's proposal for an interest rate and may be expressed in terms of a benchmark rate (LIBOR, for example) plus a predetermined percentage. This is the rate which the protection buyer would like to get. In embodiments, the first interest rate may be based on a notional value of the assets relative to each other. In embodiments, for example, where the swap is bitcoin for U.S. dollars, the notional value of a bitcoin in U.S. dollars is $10,000. The return rate may be set at a percentage that is based on the performance of bitcoin. In this case, the owner of a bitcoin may exchange the potential return on a bitcoin for the swap duration for a set return rate, for example 10% of the notional value of the bitcoin. In embodiments, as noted above, the interest rate may be set as a percentage of a benchmark rate or a benchmark rate plus a percentage. In such a case, the bitcoin owner is referred to as a buyer of protection.

In step S6302a, the digital asset computer system receives, from the second user device, associated with the second user of the plurality of users a swap ask request including second user side information and a second interest rate. In embodiments, the second user side information indicates whether the second user is buying protection or selling protection. The second interest rate is the interest rate proposed by the second user for the swap. In embodiments, the second interest rate may be presented as a benchmark rate plus a predetermined percentage. In embodiments, the benchmark rate is one of the first benchmark rate and the second benchmark rate. Where the second user is a protection seller, the second interest rate is the rate which the second user is willing to pay in exchange for the potential return of the protection buyer's asset.

At step S6303, the digital asset computer system calculates margin requirements based on margin considerations. The margin requirements apply to both the first user and the second user (buyer and seller). In embodiments, an initial margin requirement is based on the margin considerations, including the swap pair information, continuous order book market data and/or one of more reference indexes. In embodiments, both the protection buyer and protection seller must provide sufficient collateral to cover at least a portion of the total value of the swap, which corresponds to the initial margin.

At step S6304, the digital asset computer system verifies that the value of collateral associated with each of the first user and the second user is equal to or greater than the initial margin requirement.

As shown in FIG. 63B, at step S6305, where the digital asset computer system verifies that the first user and the second user have sufficient collateral to meet the initial margin requirement, the digital asset computer stores the swap bid request and the swap ask request.

At step S6306, the digital asset computer system matches the first user side information with the second user side information where a match is achieved when the first user side information indicates a side opposite that of the second user side information.

At step S6306a, the digital asset computer system matches the first interest rate with the second interest rate where a match is achieved when the first interest rate is the same as the second interest. In embodiments, if there is no match, the digital asset computer system may continue to wait until there is a match, or at some point in time (as may be defined by the system) terminate the process.

At step S6307 the digital asset computer system generates transaction instructions in accordance with the swap transaction information, the first side user information, the second side user information and the matched first interest rate and second interest rate to transact the swap.

In step 6308, the digital asset computer system, updates the electronic ledger to change the account information of the first user and second user to reflect a decrease in the amount of collateral associated with the first user and second user in an amount equal to the initial margin. The digital asset computer system also updates the electronic ledger to change the obligation information of the first user and the second user in accordance with the swap transaction information and the matched first interest rate and second interest rate.

In step S6309, the digital asset computer system transmits a confirmation of the transaction to at least the first user device associated with the first user and the second user device associated with the second user.

In step 6309a, the digital asset computer system may publish the matched first interest rate and second interest rate.

As shown in FIG. 63C, in step S6310, the digital asset computer system may recalculate the margin to determine a variation margin. In embodiments, this recalculation step is performed periodically. In embodiments, the recalculation step may be based on the same considerations discussed above with respect to the initial margin.

At step 6311, the digital asset computer system may determine whether the recalculated margin exceeds the collateral of the first user or the second user. If so, in embodiments, the digital asset computer system may issue an alert to the first user or second user to increase their account balance to meet the recalculate margin. In embodiments, the first user and second user are provided a set period of time to increase their collateral prior to the computer asset computer system transferring collateral from the account of the first user or second user to the account of the other of the first user and the second user.

In embodiments, a Swap Token tied to an underlying blockchain, such as the Ethereum Blockchain may be provided.

By way of illustration and referring to the exemplary block diagram of FIG. 67B and the exemplary flow chart of FIG. 67A, a Swap Token may be implemented in accordance with the following steps. In this exemplary embodiment, the Swap Token may be used in conjunction with a stable value token (e.g., SVCoin), to set up a swap trade between User 1 (having a user address, User Address 1, associated with a private key User Private Key 1), and User 2 (having a user address, User Address 2, associated with a private key User Private Key 2). The user addresses, and associated private key, will typically be mathematically related to each other as used in PKI encryption. Each token may have one or more administrators associated with it, which have public addresses (e.g., admin1, admin2, etc.) and corresponding private keys (adminPriv1, adminPriv2, etc.).

In embodiments, the Swap Contract may include such terms as a duration.

In Step S6702, a Stable Value Token (such as SVCoin) is provided as discussed previously, with its own Contract Address, (e.g., svt), on an underlying Blockchain (e.g., the Ethereum Blockchain). In embodiments, the Stable Value Token will have its own smart contract (e.g., SV Coin Contract), using one or more contract addresses, consistent with embodiments otherwise described herein.

In Step S6704, a Swap Token is provided with its own Contract Address, (e.g., swapt) on the same underlying Blockchain. In embodiments, the Swap Token will have its own smart contract (e.g., Swap Contract), using one or more contract addresses, consistent with embodiments otherwise described herein. In embodiments, the Swap Contract may include instructions providing for:

- Setting up trades (e.g., “setupTrade”), which will also assign a trade number (e.g., swapt.101) to each trade when set up, as well as track parties to the trade (e.g., User Public Address 1 and User Public Address 2);
- Checking balance of a particular address for the SVCoin Token (e.g., getbalanceof ([user address]));
- Getting approval for a trade (e.g., svt.approve(swapt, 101)
- Funding the trade (e.g., swapt.fundTrade(trade001))
- Withdrawal funds (e.g., withdrawal(trade001, User Public Address 1)

In Step S6706, User 1 and User 2 agree to a trade, which the swap admin is aware of it. In embodiments, Step S6706 may be performed through an order book, such as a continuous order book or an auction order book, as discussed above.

In Step S6708, the swap admin calls a function on the smart contract ‘swapt’ to set up the trade (e.g., ‘setupTrade’ function). The setupTrade function may include as parameters, the parties to the trade (e.g., User 1 and User 2), the addresses of the participants in the trade (e.g., User Public Address 1 and User Public Address 2), the side of each party to the contract (e.g., buy or sell), as well as the other parameters, such as how much collateral is required, (e.g., 101), to name a few. The ‘setupTrade’ function returns some unique identifier (e.g., ‘trade001’), to identify this particular trade and notifies User 1 and User 2 of the identifier ‘trade001’. At the end of Step S6708, the trade is in an unfunded state.

In Step S6710, User 1 and User 2 will fund their collateral requirements for the trade (trade001) using the stable value token. In embodiments, this amount may be from a preexisting account (e.g., User Public Address 1 for User 1 and User Public Address 2 for User 2). In embodiments, each user's balance may be checked by using a function such as check balance function against the svt contract address (e.g., svt.balnceOf(User Public Address 1), and svt.balanceOf (User Public Address 2). In embodiments, one or more users may need to purchase new stable value tokens to fund the collateral requirement, in accordance with embodiments elsewhere discussed. Before the next step (Step S6710a), both users will have to have sufficient balances of stable value tokens in their respective public addresses to support the collateral requirements of the sap transaction.

In Step S6710a, User 1 will send to the svt contract address a message to fund the swapt contract address with the required collateral amount (e.g., 101 SVCoins). In embodiments, User 1 sends the transaction from User Public Address 1 to svt Contract Address with message instruction the transfer of the SVCoins from user's public address to the swap contract address (e.g., ‘svt.approve(swapt, 101)’). This message would be signed by User 1, using User Private Key 1. Assuming User Public Address has a sufficient balance, and User Private Key 1 is authorized to sign for the transfer, the Stable Value Token Contract should approve and record the transfer.

In Step S6710b, User 1 makes a second transaction to fund the trade by, e.g., calling a fundTrade Function in the swap contract, including reference to the unique identifier of the trade (e.g., trade001). In this example, User 1 would send to the underlying blockchain, a transaction from User Public Address 1 to swapt Contract Address, with a message such as ‘swap.fundTrade(trade001)’. In response, the swap contract, executing the ‘fundTrade’ function, may internally call ‘svt.transferFrom(User Public Address 1, swap, 101)’ to transfer the previously approved tokens to itself (otherwise failing if User Public Address 1 did not approve the required tokens to fund the trade) and, if successful, marks trade001 in its datastore as being funded by User 1's side of the trade. At this point, trade001 has been half funded by User 1.

In Steps S6710c and S6710d, User 2 will need to carry out comparable steps as S6710a and S6710b for User 2's SVCoin tokens in User Public Address 2 and to support User 2's collateral obligations for its side of the trade (e.g., trade001).

In Step S6710c, User 2 will send to the svt contract address a message to fund the swapt contract address with the required collateral amount (e.g., 101 SVCoins). In embodiments, User 2 sends the transaction from User Public Address 2 to svt Contract Address with message instruction the transfer of the SVCoins from user's public address to the swap contract address (e.g., ‘svt.approve(swapt, 101)’). This message would be signed by User 2, using User Private Key 2. Assuming User Public Address has a sufficient balance, and User Private Key 2 is authorized to sign for the transfer, the Stable Value Token Contract should approve and record the transfer.

In Step S6710d, User 2 makes an additional transaction to fund the trade by, e.g., calling a fundTrade Function in the swap contract, including reference to the unique identifier of the trade (e.g., trade001). In this example, User 2 would send to the underlying blockchain, a transaction from User Public Address 2 to swapt Contract Address, with a message such as ‘swap.fundTrade(trade001)’. In response, the swap contract, executing the ‘fundTrade’ function, may internally call ‘svt.transferFrom(User Public Address 2, swap, 101)’ to transfer the previously approved fiat currency to itself (otherwise failing if User Public Address 2 did not approve the required tokens to fund the trade) and, if successful, marks trade001 in its datastore as being funded by User 2's side of the trade.

At this point, trade001 has been fully funded by User 1 and User 2, and should be in a fully funded state. At a later point in time, in embodiments, either User 1 or User 2 may send a call request to the swapt contract address to collect from the posted collateral in trade001 if appropriate conditions have been met, using, e.g., a ‘withdrawal’ command.

In embodiments, a method for performing a return swap using a digital asset includes: (a) providing, by the digital asset computer system comprising one or more computers, an electronic ledger including user account information for a plurality of users, the user account information for each user of the plurality of users including: 1. user identification information; 2. collateral information; and 3. obligation information; (b) providing, from the digital asset computer system to a first user device associated with a first user and a second user device associated with a second user, swap transaction information including: 1. swap information; 2. a swap duration; 3. a t least one fixing date; and 4. at least one benchmark rate; (c) receiving, by the digital asset computer system from the first user device associated with the first user, a swap bid request, the swap bid request including: 1. first user side information; and 2. a first interest rate; (d) receiving, by the digital asset computer system from the second user device associated with the second user, a swap ask request, the swap ask request including: 1. second user side information; and 2. a second interest rate; (e) calculating, by the digital asset computer system, an initial margin amount based on margin consideration wherein the margin considerations include: 1. the swap information; 2. continuous order book market data; and 3. index information; (f) verifying, by the digital asset computer system, that an amount of collateral for the first user and for the second is greater than or equal to the sum of the initial margin; (g) where the digital asset computer system verifies that an amount of collateral for the first user and the second user is greater than or equal to the initial margin, storing the swap bid request and the swap ask request; (h) matching, by the digital asset computer system, the first user side swap information with the second user side swap information, where a match is achieved where the first user side information identifies a side opposite that identified by the second user side information; (i) matching, by the digital asset computer system, the first interest rate with the second interest rate, where a match is achieved where the first interest rate is the same as the second interest rate; (j) generating, by the digital asset computer system, transaction instructions in accordance with the swap transaction information, the first user side information, the second user side information and the matched first interest rate and second interest rate; (k) updating, by the digital asset computer system, the electronic ledger to: 1. change the account information of the first user and the second user to decrease the amount of collateral associated with the first user and second user in an amount equal to the initial margin; and 2. change the obligation information associated with the first use and second user to reflect their obligations including the swap transaction information and the matched first rate and second rate; (l) transmitting, by the digital asset computer system, a confirmation of the transaction to at least the first user device and the second user device; and (m) publishing, by the digital asset computer system, the matched first interest rate and second interest rate.

In embodiments, the method further includes the steps of: (n) recalculating, by the digital asset computer system, the margin; and (o) determining, by the digital asset computer system, whether the recalculated margin exceeds the collateral of the first user and the second user and issuing an alert to the first user and the second user to increase their collateral when the recalculated margin exceeds the collateral of the first user and the second user.

The present invention also relates to methods, systems and program products for depositing, holding and/or distributing collateral in the form of a stable value token for a security token, the tokens being on the same underlying blockchain.

FIG. 68 illustrate a schematic drawing of an exemplary network for holding collateral in a smart contract on an underlying blockchain in accordance with exemplary embodiments of the present invention. The network shown in FIG. 68 may include a security token administrator system 6801 associated with an issuer of a security token 6805 (Security Token), a stable value token administrator system 6809 associated with an issuer of a stable value token 6807 (SV Coin Token), and a plurality of end user devices 105a, 105b, . . . 105N, each associated one or more corresponding end users. In embodiments more than one end user device may be associated with the same end user.

In embodiments, each of systems 6801, 8609 and user devices 105a, 105b 105N may communicated with and/or among each other directly and/or indirectly, e.g., through a data network 15, such as the Internet. In embodiments, encryption and/or other security protocols may be used. In embodiments, data network 15, may be a wide area network, a local area network, a telephone network, dedicated access lines, a proprietary network, a satellite network, a wireless network, a mesh network, or through some other form of end-user to end-user interconnection, which may transmit data and/or other information. Any participants in a digital asset network may be connected directly or indirectly, as through the data network 15, through wired, wireless, or other connections.

In embodiments, issuer of the security token may be one or more entities. In embodiments, the issuer of the stable value token may be one or more entities. In embodiments, the issuer of the security token and the issuer of the stable value token may be the same or different entity. In embodiments, one or more administrators may operate the security token administrator system 6801 on behalf of the issuer of the stable value token. In embodiments, the same or different administrators may operate the stable value token administrator system 6809. In embodiments, the issuers and/or administrators may be a trust company, a regulated trust company, a bank, a broker dealer, or some other form of entity, to name a few.

In embodiments, the administrator system 6801 may access one or more databases stored on non-volatile computer readable memory including contract parameters data base 6801B, key information data 6801C and smart contract information 6801D. As further illustrated in FIG. 69A, in embodiments, contract parameters database 6801B may include at least the following smart contract terms or attributes: (1) inception date data 6902; (2) inception value data 6904; (3) benchmark data 6906; (4) contract duration data 6908; (5) collateral requirements data 6910; and (6) notional value data 6912, to name a few. In embodiments, other contract parameters may be stored in the contract parameters database. Additional databases, to name a few, are discussed above in connection with FIGS. 6A, 10, 26, 29, 30E, 57, 60, 61A, 61B, and 65C-1-2. Moreover, additional databases may include the databases discussed above in connection with the descriptions of Blockchain Financial Instruments, Digital Asset Exchanges, and Digital Wallets, to name a few. In embodiments, inception date data 6902 may refer to data that indicates dates at which smart contracts actually begin. In embodiments, inception value data 6904 may refer to data that indicates a value of smart contracts at a corresponding inception date. Benchmark data 6906 may refer to data that indicates benchmark information of which smart contracts are based off In embodiments, contract duration data 6908 may refer to durations of smart contracts. In embodiments, collateral requirements data 6910 may refer to specific collateral requirements for smart contracts. In embodiments, notional value data 6912 may refer to the total amount of a security's underlying asset at its spot price in reference to smart contract values.

As illustrated in FIG. 68, the administrator system 6801, stable value administrator 6809, and/or user devices 105a, 105b and/or 105N may communicate with a blockchain network to access and/or add blocks to blockchain 6803. The blockchain 6803 may include one or more tokens, such as Security Token 6805 and SVCoin Token 6807 as illustrated. Each token will have at least one corresponding smart contract address (e.g., smart contract address 6805A for Security Token 6805, and smart contract address 6807A for SVCoin Token 6807, to name a few) by which instructions for each token may be accessed. In embodiments, the smart contract address may be associated with a proxy smart contract which may then issue calls to one or more other smart contracts having their own smart contract addresses.

As illustrated in FIG. 69B, a security token smart contract 6805B is provided on the underlying blockchain 6803. Security token 6805 may also include a plurality of instruction modules that collectively make up the smart contract associated with the security token. By way of illustration, in embodiment, such modules may include modules of instructions such as: (1) a create security tokens module 6918; (2) a transfer tokens module 6920; (3) a destroy security tokens module 6922; (4) an access data module 6924; (5) an authorize instructions module; (6) a calculate excess collateral module 6928; (7) a generate collateral information message module 6930; and (8) a send collateral information message module, to name a few.

In embodiments, the create security token module 6918 may include one or more authorization instructions related to creating security tokens. Such instructions may specify one or more authorized key pairs or contract addresses that may be authorized to create security tokens under specified conditions. In embodiments, the create security module 6918 may include instructions on increasing the token supply. In embodiments, the create security token module 6918 may include instructions on how to create new tokens within pre-approved token supply limits and how to assign newly created or “minted” tokens to specific designated public addresses or contract addresses on the underlying blockchain.

In embodiments, the transfer tokens module 6920, in embodiments, may include authorization instructions related to transferring security tokens. In embodiments, such transfer instructions may include rules by which certain transfer are allowed or blocked and may specify one or more key pair or contract addresses that may be authorized to perform one or more types of transfer operations. In embodiments the transfer tokens module 6920 may include authorization instructions related to transferring stable value tokens to smart contract address 6805A. In embodiments, the transfer tokens module 6920 may include authorization instructions related to transferring stable value tokens from smart contract address 6805A.

In embodiments, the destroy security tokens module 6922 may include authorization instructions related to destroying security tokens, including, in embodiments, instructions on when, and with whose authority, security tokens associated with one or more specified addresses shall be destroyed or “burned”, and thus removed from the security token supply.

The access data module 6924, in embodiments, may include authorization instructions related to accessing data supplied by a first authorized third party database (i.e. administrator system 6801), as discussed in further detail elsewhere.

The authorize instructions module 6926 may further include instructions to authorize the transfer of stable value tokens from the second contract address 6805B.

The generate collateral information message module 6930, in embodiments, may include instructions to generate a collateral confirmation message to the administrator system 6801 confirming receipt of at least one of a first amount of collateral and a second amount of collateral when at least one of the first amount of collateral and the second amount of collateral is received.

In embodiments, the send collateral information message module 6932 may include instructions to send the collateral confirmation message to the administrator system 6801 confirming receipt of at least one of a first amount of collateral and a second amount of collateral when at least one of the first amount of collateral and the second amount of collateral is received.

As illustrated in FIG. 69C, a stable value token smart contract 6807B is provided on the underlying blockchain 6803. Stable value token 6807 may also include a plurality of instruction modules that collectively make up the smart contract associated with the stable value token. By way of illustration, in embodiment, such modules may include modules of instructions such as: (1) a create stable value token module 6934; (2) a transfer stable value token module 6936; (3) a destroy stable value token module 6938; and (4) authorization instruction module.

In embodiments, the create stable value token module 6934 may include authorization instructions related to creating stable value tokens.

The transfer stable value token module 6936, in embodiments, may include authorization instructions related to transferring stable value tokens.

In embodiments, the destroy stable value token module 6938 may include authorization instructions related to destroying stable value tokens.

In embodiments, the authorization instruction module 6940 may include authorization instructions related to functions associated with the stable value tokens. In embodiments, authorization instructions module 6940 may also include instructions to authorize request received, the requests, in embodiments, being transaction requests from administrators, user public addresses, or other smart contracts.

While security token 6805 is described as a security token, in embodiments, the security token may reflect other types of tokens, such as tokens associated with a security, a bond, a financial instrument, a contract, and stock, to name a few. Similarly, while the SVCoin token 6807 is describe a stable value token, in embodiments, the SVCoin token 6807, may reflect other kinds of token which may not necessarily reflect a stable value, e.g., Gas tokens, and/or some other kind of token which the parties to the transaction reflect as an appropriate collateral.

Referring to FIG. 73, an exemplary process for generating a smart contract in accordance with an embodiment of the present application is provided. In embodiments, the process shown in FIG. 73 may begin at a step S7302. In step S7302, an administrator system (i.e. administrator system 6801) may receive a contract request. In embodiments, the contract request may be received from a first user, and includes user identification information and a request to generate a smart contract. In embodiments, the first user may be an individual, associated with a first user device. In embodiments, the user identification information may be associated with the first user. In embodiments, the user identification information may be associated with a first user device. In embodiments, the first user may not be an individual, but may be an organization or entity such as a financial institution, exchange or brokerage house, to name a few. In embodiments, the first user device may be associated with a financial institution, exchange or brokerage house, to name a few. In embodiments, the first user device may be User device 105a. The contract request, in embodiments, may also include a smart contract generation request. The smart contract generation request, in embodiments, is a request from a user device, associated with a first user, to an administrator system to generate a smart contract.

In embodiments, a contract request may be from more than one user. In embodiments, a first user and second user may agree in advance, as to contract parameters, and one or the other may send a contract request that includes first user identification information associated with a first user device that is associated with a first user as well as second used identification information associated with a second user device that is associated with a second user. The first user device, in embodiments, may be User device 105a. In embodiments, the second user device may be User device 105b. The contract request, in embodiments, may include a smart contract generation request. The smart contract generation request, in embodiments, is a request from a user device to an administrator system to generate a smart contract.

In embodiments, the contract request may be for a contract where the parameters are already agreed upon by more than two users (i.e. User device 105a, User device 105b . . . User device 105n). For example, where the contract parameters are already agreed upon by more than two users, the contract request may include user information for each of the users of which have already agreed upon the parameters of the requested contract. The contract request, in embodiments, may also include a smart contract generation request.

Once a contract request is received by the administrator system, at step S7304, the administrator system may generate graphical user interface (GUI) information including at least one prompt for the first user to provide contract parameters related to the smart contract to be generated. For example, the administrator system may generate graphical user interface information to provide a GUI similar to that shown in FIG. 74. In embodiments, the administrator system may also generate GUI information that prompts a user to input information corresponding to the contract parameters similar to or the same as the published contracts parameters described in connection with FIGS. 71A-71B (i.e. inception date 7104, inception value 7106, benchmark data 7108, contract duration data 7110, collateral requirement 7112, notional value 7114, early termination rules 7130, and second benchmark data 7132, to name a few) and the contract parameters of contract parameters data base 6801B described in connection with FIG. 69A, the descriptions of which applying herein. In embodiments, the administrator system may generate graphical user interface (GUI) information including at least one prompt for the second user to provide contract parameters related to the smart contract to be generated.

Once the GUI information is generated, at step S7306, the administrator system may send the GUI information to the first user device. In embodiments, once received by the first user device, the first user device may use the GUI information to display a GUI, which may be similar to GUI shown in connection with FIG. 74. In embodiments, such as embodiments where the contract parameters are already agreed upon by more than one user, the administrator system may send the GUI information to the first user device and the second user device. In embodiments, once received, the first and second user devices may each use the GUI information to display a GUI, which may be similar to GUI shown in connection with FIG. 74. In embodiments, such as embodiments where the parameters are already agreed upon by more than two users, the administrator system may send the GUI information to more than two user devices. In embodiments, once received, the more than two user devices may each use the GUI information to display a GUI, which may be similar to GUI shown in connection with FIG. 74.

In embodiments, once the GUI information is received by the first user device, the first user device may receive one or more inputs which may include contract information including the contract parameters. For example, the user device may receive inputs that indicate an inception date 7104, inception value 7106, benchmark data 7108, contract duration data 7110, collateral requirement 7112, notional value 7114, early termination rules 7130, and second benchmark data 7132, to name a few. In embodiments, where the GUI information is sent to more than one device, for example, where the GUI information is sent to a first user device and a second user device, at least one of the user devices may receive inputs which may include contract information including the contract parameters. The contract information including the contract parameters may, in embodiments, be sent from the first and or second user devices to the administrator system.

At a step S7308, the administrator system may receive, from the first user device, in response to the at least one prompt included in the graphical user interface information, contract information including the contract parameters of the contract to be generated. In embodiments, such as embodiments where the contract parameters are already agreed upon by more than one user, the administrator system may receive contract information including the contract parameters of the contract to be generated from at least one of the first user device and the second user device. In embodiments, such as embodiments where the parameters are already agreed upon by more than two users, the administrator system may receive contract information including the contract parameters of the contract to be generated from at least one of the user devices associated with the users that have already agreed upon the contract parameters.

Once the contract information is received by the administrator system, at a step S7310, the administrator system may store the contract information including the contract parameters in memory operably connected to the administrator system. In embodiments, the contract information may be stored in smart contract information database 6801D.

In embodiments, the contract parameters provided in the process described in connection with FIG. 73 may be used in arranging for multiple transactions based on the contract parameters. In embodiments, the contract parameters that are provided by the first user device, for example, may published to a plurality of user devices, in the same manner as is described below with respect to step S7002. In this case, users may indicate their desire to participate in the contract consistent with step S7004 discussed below.

The steps of the process described in connection with FIG. 73 may be rearranged or omitted.

In embodiments, the process of FIG. 73 may continue with the process in FIG. 70A. In alternative embodiments, FIG. 70A may be its own process, beginning with step S7002. Referring to FIG. 70A, in a step S7002, an administrator system 6801 may publish (via, e.g. a public or private website or mobile application) a contract having contract parameters. Contract parameters, as described in step S7002 may be retrieved from contract parameters database 6801B as shown in FIG. 69A and discussed before. The published contract, in embodiments, may have a graphical user interface (GUI), including such information as shown in connection with FIG. 71A. The published contract may show some or all of the data described earlier in connection with FIG. 69A. For example, as shown in FIG. 71A, the published contract 7102 may have (1) an inception date 7104 of Jul. 19, 2018; (2) an inception value 7106 of $10,000; (3) benchmark data 7108 from the S&P 500; (4) a contract duration 7110 of 5 days; (5) a collateral requirement 7112 of 100 Stable Value Coins; and (6) a notional value 7114 of $10,000, to name a few.

A more detailed description of contract parameters and collateral requirements associated with an oracle is located below in connection with the descriptions of FIGS. 95A-95D and FIGS. 96A-96C, the descriptions of which applying herein. A more detailed description of calculating an oracle collateral requirement is located below in connection with the descriptions of FIGS. 95A-95D, and FIGS. 96A-96C, the descriptions of which applying herein.

In embodiments, the oracle fee may be a fee associated with using an oracle. The fee, in embodiments, may be applied to the first user and second user equally (e.g. if the fee is 2 Gemini Dollars, the first user pays 1 Gemini Dollar and the second user pays 1 Gemini Dollar). In embodiments, the fee may be applied to the user who proposed an incorrect settlement amount. In embodiments, the oracle fee may be waived if the first user and/or the second user use an SV Coin (e.g. Gemini Dollar) to collateralize the published contract. In embodiments, the fee may be waived if the first user and/or second user collateralize the published contract with the same digital asset type as the digital asset type used by the oracle to collateralize the published contract (e.g. if the oracle uses Bitcoin and the first or second user also use Bitcoin). In embodiments, the fee may be waived for one or more of the users (e.g. only the first user, only the second user, or both the first user and the second user). In embodiments, the fee may be waived by the administrator system 6801.

In embodiments, other values and parameters may be included consistent with embodiments of the present invention. In embodiments, these other values and parameters may include information that may be used to determine the contract parameters discussed above, and/or other parameters including: (1) asset identification information; (2) a current (spot) price; (3) a type of derivative; (4) a side (buy/sell); (5) a call/put designation, (6) an expiration date or term, (7) a strike price; (8) pricing model information, and (10) volatility information, to name a few. In embodiments, user input of certain information may prompt requests for additional information. In one example, input of an identification of a particular type of derivative may require user identification of other information, such as upper or lower price limit, to name a few.

In embodiments, the type of derivative may be any one of: vanilla, fx hedge, flexi forward, knock out, knock in, double knockout, double knock in, no touch, one touch, double no touch, double one touch, digital, digital knockout, digital knockin, digital double knockout, digital double knockin, compound, sequential—kiko & kiki, koki—no sequential, digital sequential, average (Asian), fader, digital accrual, accrual, accumulator, accumulator KO, accumulator KI, cas, dcd vanilla, dcd knockout, dcd knockin, average forward, euro-american KO, target redemption forward, dual-strike tarf, kockin tarf, pivot tarf, variance swap, volatility swap and forward volatility agreement, to name a few.

In embodiment, the pricing model may be any one of: black-scholes, vanna-volga, heston, local vol, stoch-local vol, stochastic, to name a few.

In embodiments, the smart contract parameters database may further include: (10) early termination rule data 6914; and/or (11) second benchmark data 6916, to name a few. In embodiments, early termination rule data 6914 may include rules that charge a fee associated with a user terminating the smart contract before the contract duration is completed. Second benchmark data 6916 in some embodiments may be different than benchmark data 6906. The published contract, in embodiments, may include a GUI with such information as shown in connection with FIG. 71B. In embodiments, the published contract may show some or all of the data described earlier in connection with FIG. 69A. For example, as shown in FIG. 71B, the published contract 7116 may have (1) an inception date 7118 of Jul. 20, 2018; (2) an inception value 7120 of $1,000; (3) benchmark data 7122 from the S&P 500; (4) a contract duration 7124 of 2 days; (5) a collateral requirement 7126 of 10 Stable Value Coins; (6) a notional value 7128 of $1,000; (7) no early termination rules 7130; and (8) second benchmark data 7132 from Winkdex®. While there are no early termination rules shown in the published contract of FIG. 71B, early termination rules may include, for example, a fee for terminating the contract early. Other values and parameters may be included consistent with embodiments of the present invention.

Referring to FIG. 70A, in a step S7004, the administrator system 6801 may receive a plurality of indications of interest (“IOIs”) or bids from users. Referring to FIGS. 71C-71E, the IOIs may include at least a first indication of interest (e.g. first indication of interest 7134 described in connection with FIG. 71C or first indication of interest 7140 described in connection with FIG. 71D) and a second indication of interest (e.g. second indication of interest 7150 described in connection with FIG. 71E or second indication of interest 7156 described in connection with FIG. 71F). In embodiments, the first indication of interest may be a first user response sent from a first user device 105a to administrator system 6801. In embodiments, the first user device 105a may be associated with a first user (e.g. Alice). In embodiments, as illustrated in FIGS. 71C and 71D, the first indication of interest 7134, 7140 may include at least first user identification information 7136, 7142 associated with the first user (e.g., a name, user number, email address, to name a few used to identify the indication of interest as coming from the first user (Alice)), and first side information 7138, 7144 (e.g., buy). First side information may include identification of a first leg of the smart contract (e.g., buy or sell). In embodiments, additional information, such as shown in FIG. 71D may also be included in an indication of interest. For example, referring to FIG. 71C, a first indication of interest 7134 may be sent by Alice (as the first user) to Gemini (as the security token administrator). Alice's indication of interest 7134 may include her user identification number 7136, ID No. 12345 (as the first user identification information), and information indicating that Alice would like to buy 7138 (as the first side information). In embodiments, the first indication of interest may also include information indicating: an oracle preference, whether an oracle will be used, a proposed oracle fee, and/or a proposed oracle.

In embodiments, the first indication of interest may further include additional information such as, a first user public address and/or first collateral information, to name a few. In embodiments, such additional information may not be necessary to include in the indication of interest because it may be included in the contract parameters as published and thus implied. First collateral information may be in stable value digital asset tokens (SVCoins). For example, referring to FIG. 71D, a first indication of interest 7140 may be sent by Alice (as a first user) to Gemini (as the security token administrator). Alice's indication of interest may include: (1) her user identification number 7142, ID No. 12345 (as the first user identification information); (2) information indicating that Alice would like to buy 7144 (as the first side information); Alice's Public Address 7146 (as the a first user public address); and (4) information indicating a collateral 7148 of 100 Stable Value Coins (as the first collateral information).

In embodiments, the second indication of interest may be a second user response sent from a second user device 105b to administrator system 6801. In embodiments, the second user device 105b may be associated with a second user (e.g. Bob). The second indication of interest (e.g. second indication of interest 7150 described in connection with FIG. 71E or second indication of interest 7156 described in connection with FIG. 71F) may include second user identification information 7152, 7158 associated with the second user (e.g. a name, user number, email address, to name a few used to identify the indication of interest as coming from the second user (Bob), and second side information (e.g. sell). The second side information may include identification of a second leg of the smart contract (e.g. buy or sell). In embodiments, the second leg is different from the first leg. In embodiments, additional information, such as shown in FIG. 71F, may also be included in an indication of interest. For example, referring to FIG. 71E, a second indication of interest 7150 may be sent by Bob (as the second user) to Gemini (as the security token administrator). Bob's indication of interest 7150 may include his user identification number 7152, ID No. 54321 (as the second user identification information), and information indicating 7154 that Bob would like to sell (as the first side information). In some embodiments, the second indication of interest my further include additional information such as, a second user public address 7162 and/or second collateral information 7164, to name a few. The second collateral information 7164 may be in stable value digital asset tokens (“SVCoins”). For example, referring to FIG. 71F, a second indication of interest 7156 may be sent by Bob (as the second user) to Gemini (as the security token administrator). Bob's indication of interest 7156 may include: (1) his user identification number 7158, ID No. 54321 (as the second user identification information); (2) information indicating that Bob would like to sell 7160 (as the second side information); Bob's Public Address 7162 (as the second user public address); and (4) information indicating a collateral 7164 of 100 Stable Value Coins (as the second collateral information). In embodiments, the second indication of interest may also include information indicating: an oracle preference, whether an oracle will be used, a proposed oracle fee, and/or a proposed oracle.

In embodiments, step S7004 may further include the administrator system may receive a third and fourth user responses from a fourth user device and a fifth user device, for example. The third user response, in some embodiments, may include fourth user identification information associated with the fourth user. In embodiments, the third user response may also include third side information comprising identification of the first leg of the contract. In embodiments, the third user response may be similar to first indication of interest 7134 described in connection with FIG. 71C, first indication of interest 7140 described in connection with FIG. 71D, second indication of interest 7150 described in connection with FIG. 71E and/or second indication of interest 7156 described in connection with FIG. 71F, the descriptions of which applying herein.

The fourth user response may include fifth user identification information associated with the fifth user. In embodiments, the fourth user response may also include fourth side information comprising identification of the second leg of the contract, the fourth side information being different than the third side information. In embodiments, the fourth user response may be similar to first indication of interest 7134 described in connection with FIG. 71C, first indication of interest 7140 described in connection with FIG. 71D, second indication of interest 7150 described in connection with FIG. 71E and/or second indication of interest 7156 described in connection with FIG. 71F, the descriptions of which applying herein.

Referring back to FIG. 70A, after receiving the first user response (i.e. a first indication of interest) and the second user response (i.e. a second indication of interest), in a step S7006, the administrator system 6801 matches the first user response with the second user response. For example, referring to FIGS. 71C-F, administrator 6801 may match Alice with Bob because Alice wants to buy and Bob would like to sell. In embodiments, such as embodiments where more than one user has agreed to the contract provisions in the published contract (as discussed above in connection with FIG. 73), matching may not be required and step S7006 may be omitted.

In embodiments, such as the embodiments where a third user response and fourth user response are received by the administrator system, the third user response may be matched with the fourth user response.

In a step S7008, a stable value token smart contract associated with a stable token 6807 and first smart contract instructions 6807B associated with a first contract address 6807A associated with the blockchain 6803 for the underlying digital asset are provided. In embodiments, the first smart contract instructions 6807B are saved in the blockchain 6803 for the underlying digital asset. In embodiments, the first smart contract instructions 6807B may include the stable value token smart contract instructions 6807B described in connection with FIG. 69C, the same description applying herein.

Referring back to FIG. 70A, in a step S7010, a security token smart contract associated with a security token 6805 and second smart contract instructions 6805B associated with the blockchain 6803 for the underlying digital asset are provided. In embodiments, the second smart contract instructions 6805B are saved in the blockchain 6803 for the underlying digital asset. In embodiments, the second smart contract instructions 6805B may include the security token smart contract instructions 6805B described in connection with FIG. 69B, the same description applying herein.

In embodiments, the second smart contract instructions 6805B may also include oracle instructions associated with the oracle (e.g. dispute instructions module 6942). A more detailed description of oracle instructions is located below in connection with the description of FIGS. 95A-95D, and FIGS. 96A-96C, the descriptions of which applying herein.

In embodiments, the mathematical solution may correspond to a mathematical puzzle, which may be generated by one or more of: the first user device, the second user device, the administrator, and/or the oracle, to name a few. In embodiments, the administrator 6801 (e.g. digital asset exchange computer system 3230, a trusted entity, the digital asset exchange computer system described in connection with FIGS. 92A-92D and/or the digital asset exchange computer system described in connection with FIGS. 93A-93C, to name a few) may generate a first mathematical puzzle and a corresponding first mathematical solution may be generated. In embodiments, the digital asset exchange computer system may generate the first mathematical puzzle and first mathematical solution. In embodiments, the timing of the generation of the puzzle may vary. For example, puzzles may be pre-generated in advance of the generation of the smart contract instructions, and/or may be generated on the fly at some point after the smart contract instructions are generate. To generate the first mathematical puzzle and solution, the digital asset exchange computer system may, in embodiments, may provide an algorithm used to generate the puzzle and solution. In embodiments, and as used herein, algorithm and/or hash algorithm, may refer to one or more of the following: (1) a mathematical algorithm; (2) a one-way hash function; (3) a cryptographic hash function; (4) a one-way function; (5) a trapdoor one-way function; (6) a Data Encryption Standard encryption algorithm; (7) a Blowfish encryption algorithm; (8) An Advanced Encryption Standard or Rijndael encryption algorithm; (9) a Twofish encryption algorithm; (10) an IDEA encryption algorithm; (11) an MD5 encryption algorithm; (12) an MD4 encryption algorithm; (13) a SHA 1 hashing algorithm; (14) an HMAC hashing algorithm; and/or (15) an RSA Security algorithm, to name a few.

The algorithm, in embodiments, may be applied to a puzzle seed that is obtained by the digital asset exchange computer system. In embodiments, the puzzle seed may be a randomly generated series of numbers, letters, and/or characters. Alternatively, in embodiments, the puzzle seed may be a semi-randomly generated series of numbers and/or letters based on at least one of the following: (1) a first user public address; (2) a second user public address; (3) a public key associated with the digital asset exchange computer system; (4) a public key associated with the first user; (5) the oracle address; (6) a public key associated with the oracle’ (7) a private key associated with the oracle; (8) a private key associated with the first user; (9) a private key associated with the second user; and/or (10) a private key associated with the digital asset exchange computer system, to name a few. In embodiments, the first user public address may be a public address on blockchain 6803 and associated with the first user. The first user public address may be associated with a first user public key. In embodiments, the first user public key may correspond to a first user private key—which combined may be a first user key pair. In embodiments, the second user public address may be a public address on blockchain 6803 and associated with the second user. The second user public address may be associated with a second user public key. In embodiments, the second user public key may correspond to a second user private key—which combined may be a second user key pair.

In embodiments, one or more processor(s) of the digital asset exchange computer system may apply an algorithm to a puzzle seed to generate a first mathematical puzzle. Continuing the example, the algorithm may be applied to the first mathematical puzzle. The result of the second application of the algorithm may be the corresponding first mathematical solution. In embodiments, the algorithm may be applied a plurality of times, resulting in a plurality of mathematical puzzles and corresponding solutions. Thus, in embodiments, the first mathematical puzzle may be a plurality of mathematical puzzles. Similarly, the corresponding first mathematical solution may be a plurality of mathematical solutions. The below table is an example of an overly simplified algorithm applied to a puzzle seed, resulting in a plurality of mathematical puzzles and corresponding solutions, merely for exemplary purposes. For the purposes of the example in the below table, (1) the puzzle seed is 123456; and (2) the algorithm applied is X*4+5, where X represents the puzzle seed. Thus, the first puzzle may be (123456)*4+5, or in other words, 493829.

TABLE 1-A

	Puzzle	Solution

First Puzzle/Solution:	493829	1975321
Second Puzzle/Solution:	1975321	7901289
Third Puzzle/Solution:	7901289	31605161
Fourth Puzzle/Solution:	31605161	126420649
Fifth Puzzle/Solution:	126420649	505682601

As another example, below is a second table illustrating an exemplary generation of puzzle sequences for a sequence of length 5.

TABLE 1-B

	Value

Puzzle Seed:	fd8c373d34931f7c2edad4d82c09c3e120ee0b2a094164f6124f0d4d768d5748
Puzzle #5	7452fa77c71f7a2696e5e81177c80a8fb5c7lbdfldcee2d4b2c94b2aba7ccfb2
Puzzle #4	448cd914d4baaa94940d9ef6d0674a94d743fd3bb3ece91f2295c7f1eac5fa0a
Puzzle #3	0e136f491A47edc0ccf35a90a2dbd87b551439a2cealb8ff817P950c0e8061e
Puzzle #2	5af2db926aP985f25e2ddbcdb24db5f58a44476ea840bbbd4a51c0d978b4852c
Puzzle #1	689af04fa477accc9fe21482e3cf1c44842b29b5cbb 8e7f022797ce7f1301c3b

Table 1-B, in embodiments, may be an example of an asymmetric puzzle. An asymmetrical puzzle sequence, for example, may refer to a puzzle sequence including N puzzles, where the Nth puzzle is generated first, based off the seed. Continuing the example, the second puzzle in the puzzle sequence, the N−1 puzzle, may be generated second based of the Nth puzzle. This may continue until the first puzzle is generated. The below diagram, in embodiments, may illustrate the order in which an asymmetric puzzle sequence is generated.

Asymmetrical Puzzle Sequence Diagram

As shown in the above diagram, the seed is hashed to create the Nth puzzle, which is hashed to create the N−1 Puzzle which continues until the Second Puzzle is hashed to create the First Puzzle. Hashed, as used herein, may refer to the application of a hash algorithm.

In practice, the algorithm and seeds used to generate the puzzle and solution will be more complex, and each layer may potentially use a different algorithm to increase complexity and avoid reserve engineering of puzzle solutions. In embodiments, by building a nested puzzle/solution basis, where the current solution to the current puzzle is the next puzzle, the process can be more efficient.

As shown in the above table the first mathematical solution may correspond to the second mathematical puzzle. Similarly, the second mathematical solution may correspond to the third mathematical puzzle. Moreover, the third mathematical solution may correspond to the fourth mathematical puzzle. Furthermore, the fourth mathematical solution may correspond to the fifth mathematical puzzle. In embodiments, the digital asset exchange computer system may continue applying the algorithm, generating dozens, hundreds, thousands, millions, and/or billions of puzzle/solution combinations. In embodiments, each puzzle/solution combination may be unrelated. In embodiments, a first user device associated with the first user and/or a second user device associated with the second user may generate the first mathematical puzzle and corresponding solution.

The corresponding first solution to the first mathematical puzzle may be used to protect the first user, the second user, and/or the digital asset exchange computer system in the event of a security incident or breach (e.g. a data breach; a data incident; untrustworthy actions on behalf of the first user, second user, and/or the digital asset exchange computer system, and/or a system crash, to name a few—a data security incident or breach response is described more fully below in connection with FIG. 94, the description of which applying herein). If there is a security incident or breach, the digital asset exchange computer system may transmit the solution to the corresponding puzzle to the first user device and/or the second user device to allow the first user and/or second user to retrieve any and/or all digital assets at risk or to retrieve the collateral supplied by the digital asset exchange computer system. Because the solution may enable a user to drain an account prematurely and/or retrieve assets that are not rightfully owned by the user, in embodiments the digital asset computer exchange system may only transmit the mathematical puzzle to the first user device and/or second user device, storing the corresponding solution for later use if needed.

In embodiments, the generated puzzle may be transmitted to one or more of the first user public address, the second user public address, a public address associated with the administrator 6801 and/or the oracle address, to name a few. In embodiments, the generated puzzle may be transmitted by the party that generated the puzzle and corresponding solution (e.g. the first user, the second user, the administrator 6801, and/or the oracle, to name a few).

In embodiments, step S7008 and step S7010 may be performed before step S7002, step S7004, and step S7006.

Referring back to FIG. 70A, the process may continue with step S7012, in which the administrator system 6801 sets up a first trade (e.g. trade001) between the first user (e.g. the user associated with first user device 105a) and the second user (e.g. the user associated with the second user device 105b) using the security token smart contract 6805B on the underlying blockchain 6803 with collateral in the form of stable value digital assets (i.e. stable value token 6807). Step S7012 is described in more detail in connection with FIGS. 70B-D.

Referring to FIG. 70B, in embodiments, setting up the first trade between the first user and the second user may begin at step S7016, where the administrator system 6801 generates first trade instructions for the security token smart contract 6805B. The first trade instructions may include instructions to execute the first trade between a first user public address associated with the first user (e.g. the user associated with user device 105a) and a second user public address associated with a second user (e.g. the user associated with user device 105b). In embodiments, the first trade is based at least on the contract terms from step S7002 (i.e. one or more of the contract parameters discussed in connection with FIG. 69A), the first user response from step S7004 (associated with a received IOI—i.e. the IOI's described in connection with FIGS. 71C-71D), and the second user response from step S7004 (associated with another received IOI—i.e. the IOI's described in connection with FIGS. 71E-71F).

In a step S7018, the administrator system 6801 may generate first hashed trade instructions, the first hashed trade instructions being generated by applying a hash algorithm to the first trade instructions. Examples of hash algorithms include MD 5, SHA 1, SHA 256, RIPEMD, and Keccak-256 to name a few. Hash algorithms take an input of any length and create an output of fixed length, allowing the trade instructions to be detectable and usable by administrators and users on the underlying blockchain. However, applying a hash algorithm is not always necessary if trade instructions are published ahead of time

In a step S7020, the administrator system 6801 sends a first transaction request from an administrator public address associated with the administrator system 6801 to the second contract address 6805A via the underlying blockchain 6803. In embodiments, the first transaction request, includes a first message which may include: (1) the first hashed trade instructions; (2) a request to assign a first trade identification to a first trade associated with the hashed trade instructions. In embodiments, the first message may include requests to assign a first trade identification to the first trade associated with the hashed trade instructions and include the first trade identification associated with the first hashed trade instructions. In embodiments, the first transaction request may further include first transaction fee information. The first transaction fee information, in embodiments, may be for miners on the blockchain 6803 to process the first transaction request. The first transaction request may also be electronically signed by an administrator private key. The administrator private key may be mathematically related to the administrator public address.

The process may continue with step S7022. In step S7022, the administrator system 6801 obtains the first trade identification of the first trade. In embodiments, the administrator system 6801 may determine the first trade identification, as calculated by the security token smart contract, by monitoring transactions on the blockchain 6803 (as shown in connection with a step S7024 of FIG. 70B). In response to obtaining the first trade identification of the first trade, the administrator system 6801 may notify the first user (e.g. the user associated with user device 105a) and the second user (e.g. the user associated with user device 105b) of the first trade identification. In a step S7026, the administrator system 6801 may send the first trade identification to the first user device 105a associated with the first user. Similarly, in step S7028, the administrator system 6801 sends the first trade identification to the second user device 105b associated with the second user.

In embodiments, as shown in a step S7030, the first user device 105a may send a second transaction request from a first user public address (the first user public address being associated with the first user and the first user device 105a) to the first contract address 6807A via the underlying blockchain 6803. The second transaction request may include a second message, the second message including requests to the stable value token smart contract 6807B regarding a first transfer of a first amount of collateral. In embodiments, the second message may include the first trade information. In embodiments, the second transaction request may include second transaction fee information. The second transaction fee information may be for miners on the blockchain 6803 to process the second transaction request. In embodiments, the second message may also include a transfer request to the stable value smart contract to transfer the first amount of collateral in the form of stable value digital asset tokens 6807 from the first user public address to the second contract address 6805A. The transfer request, in embodiments, will be executed upon receipt of a first collateral request from the second contract address 6805A. In embodiments, the transfer request included in the second message may be executed upon receipt of a first collateral request from the administrator system 6801. The second transaction request is also electronically signed by a first user private key. The first user private key may be mathematically related to the first user public address.

In embodiments, the process described in FIG. 70B may continue with the process shown in connection with FIG. 70C. In embodiments, as shown in a step S7032, the second user device may send a third transaction request from a second user public address (associated with the second user and the second user device 105b) to the second contract address 6805A via the underlying blockchain 6803. The third transaction request may include a third message including a second transfer request to the stable value token smart contract 6807B regarding a second transfer of the second amount of collateral from the second user public address to the second contract address 6807A. In embodiments, the third transaction request may further include third transaction fee information. The third transaction fee information, in embodiments, may be for miners on the blockchain 6803 to process the third transaction request. The second transfer request of the third message, in embodiments, will be executed upon receipt of a second collateral request from the second contract address 6805A. Alternatively, the second transfer request of the third message will be executed upon receipt of a second collateral request from the administrator system 6801. The third transaction request may also be electronically signed by a second user private key. The second user private key may be mathematically related to the second user public address.

The process may continue with a step S70121. In a step S7034, the administrator system 6801 monitors transactions of the stable value digital asset tokens 6807 on the blockchain 6803 to determine that the second contract address 6805A has received at least the following: (1) the first amount of collateral in stable value digital asset tokens from the first user (e.g. the user associated with user device 105a); and (2) the second amount of collateral in stable value digital asset tokens from the second user (e.g. the user associated with user device 105b). In embodiments, the administrator system 6801 may further monitor the first contract address 6807A to determine whether the first amount of collateral is received at the second contract address 6805A and whether the second amount of collateral is received at the second contract address 6805A (as shown in connection with a step S7036 of FIG. 70C and step S7038 of FIG. 70C).

Alternatively, the administrator system 6801 may receive a collateral confirmation message confirming that the first amount of collateral and the second amount of collateral are received by the second contract address 6805A (as shown in connection with a step S7040 of FIG. 70C). In embodiments, either the first amount of collateral, the second amount of collateral, or both may not be received at the second contract address. If either or both are not received, in embodiments, the collateral confirmation message may indicate a lack of collateral, or the collateral confirmation message may not be sent.

In embodiments, the administrator system 6801 may also determine the second contract address 6805A has also received the oracle collateral. In embodiments, the administrator system 6801 may further monitor the first contract address 6807A to determine whether the oracle collateral is received at the second contract address 6805A. Alternatively, the administrator system 6801 may receive a collateral confirmation message confirming that the oracle collateral was received by the second contract address 6805A (similar to the step illustrated as shown in connection with a step S7040 of FIG. 70C). In embodiments, the oracle collateral may not be received at the second contract address. If the oracle collateral is not received, in embodiments, the collateral confirmation message may indicate a lack of collateral, or the collateral confirmation message may not be sent.

Upon determining that the first amount of collateral from the first user (e.g. the user associated with user device 105a), the second amount of collateral from the second user (e.g. the user associated with user device 105b), and/or the oracle collateral have been received by the second contract address 6805A, in a step S7042, the administrator system 6801 may send a fourth transaction request from the administrator public address to the second contract address 6805A via the underlying blockchain 6803. The fourth transaction request may include a fourth message including the first trade instructions and the first trade identification. In embodiments, the fourth transaction request may further include fourth transaction fee information. The fourth transaction fee information, in embodiments, may be for miners on the blockchain 6803 to process the fourth transaction request. The fourth transaction request may also be electronically signed by the administrator private key.

In embodiments, the second contract address 6805A may further include modules with instructions to: (1) generate a first collateral request when the third message is received by the second contract address 6805A; (2) send the first collateral request to the first contract address 6807A associated with the stable value token smart contract; (3) generate a second collateral request when the third message is received by the first contract address 6807A; (4) send the first collateral request to the first contract address 6807A associated with the stable value digital asset token smart contract; confirming that the first amount of collateral from the first user (e.g. a user associated with user device 105a) and the second amount of collateral from the second user (e.g. a user associated with user device 105b) has been received by the second contract address; and (5) sending a collateral confirmation message to the administrator public address.

Upon receiving the confirmation message, the administrator system 6801 may send a fourth transaction request from the administrator public address to the second contract address 6805A via the underlying blockchain 6803. The fourth transaction message may include a fourth message comprising first trade instructions and the first trade identification.

Referring to FIG. 70D, in embodiments, step S7012 may being with a step S7042. In step S7042, the administrator system 6801 may send a first transaction request from the administrator public address to the second contract address 6805A via the underlying blockchain 6803. The first transaction request, in embodiments, may include a first message comprising requests to create a first trade between the first user and the second user in accordance with the security token smart contract 6805B. In embodiments, the first transaction request may further include first transaction fee information. The first transaction fee information, in embodiments, may be for miners on the blockchain 6803 to process the first transaction request. The first transaction request may also be electronically signed by the administrator private key. The administrator private key is mathematically related to the administrator public address.

In embodiments, as shown in a step S7044, the first user device 105a may then send a second transaction request from a first user public address (the first user public address being associated with the first user and the first user device 105a) to the first contract address 6807A via the underlying blockchain 6803. The second transaction request may include a second message, the second message authorizing the stable value token smart contract 6807B to accept a request to transfer a first amount of collateral from the first user public address to the second contract address 6805A. In embodiments, the second transaction request may further include second transaction fee information. The second transaction fee information, in embodiments, may be for miners on the blockchain 6803 to process the second transaction request. The second transaction request may be electronically signed by the first user private key. The first user private key is mathematically related to the first user public address.

The process may continue at step S7046. At a step S7046, the second user device may send a third transaction request from a second user public address (associated with the second user and the second user device 105b) to the second contract address 6805A via the underlying blockchain 6803. The third transaction request may include a third message authorizing the stable value digital asset smart contract 6807B to accept a request to transfer a second amount of collateral from the second user public address to the second contract address 6805A. In embodiments, the third transaction request may further include third transaction fee information. The third transaction fee information, in embodiments, may be for miners on the blockchain 6803 to process the third transaction request. The third transaction request may be electronically signed by the second user private key. The second user private key is mathematically related to the second user public address.

In step S7048, the administrator system 6801 may send a fourth transaction request from the administrator public address to the first contract address 6807A via the underlying blockchain 6803. The fourth transaction request may include a fourth message including requests to: (1) transfer of the first amount of collateral of stable value digital asset tokens from the first user public address to the second contract address 6805A; and (2) transfer of a second amount of collateral of stable value digital asset tokens 6807 from the second user public address to the second contract address 6805A. The fourth transaction request may also be electronically signed by the administrator private key.

Alternatively, the second contract address 6805A may send a fourth transaction request to the first contract address 6807A via the underlying blockchain 6803. The fourth transaction request may similarly include a fourth message including requests to: (1) transfer of the first amount of collateral of stable value digital asset tokens 6807 from the first user public address to the second contract address 6805A; and (2) transfer of a second amount of collateral of stable value digital asset tokens from the second user public address to the second contract address 6805A.

In alternative embodiments, steps S7010 and S7012 (and accompanying substeps described above in connection with FIGS. 70B-D) may be replaced by a method of generating the security token contract associated with the security token 6805 associated with blockchain 6803 for the underlying digital asset. The method, in embodiments, may begin by an administrator 6801 generating the security token smart contract associated with a security token 6805 and second smart contract instructions 6805B associated with a second smart contract address 6805A associated with the blockchain 6803 for the underlying digital asset. In embodiments, the second smart contract instructions 6805B are saved in the blockchain 6803 for the underlying digital asset.

The second smart contract instructions 6805B may include one or more of the following: (1) first trade instructions for the security token smart contract; (2) fifth authorization instructions regarding transferring security tokens (which may be included in the transfer security tokens module 6920); (3) sixth authorization instructions regarding destroying security tokens (which may be included in the destroy security tokens module 6922); (4) seventh authorization instructions regarding transferring stable value tokens to the second contract address (which may be included in the authorize instructions module 6926); (5) eighth authorization instructions regarding transferring stable value tokens from the second contract address (which may be included in the authorize instructions module 6926); (6) calculating instructions regarding calculating excess collateral (which may be included in the calculate excess collateral module 6928); (7) generating collateral information instructions regarding excess collateral (which may be included in the generate collateral information message module 6930); and (8) sending collateral information message instructions regarding excess collateral (which may be included in the send collateral information message module 6932). In embodiments, the first trade instructions may include execution instructions to execute a first trade between the first user and the second user. The first trade, in embodiments, may be based on at least (1) the contract request or proposal and (2) the first user response.

In embodiments, once the security token contract is generated by an administrator 6801, the administrator 6801 may send the security token smart contract and associated second smart contract instructions 6805B to the second smart contract address 6805A via the blockchain 6803 for the underlying digital asset.

In embodiments, the first trade instructions may be implemented via the blockchain 6803 for the underlying digital asset by computers systems among the plurality of geographically distributed computer systems in the peer-to-peer network.

Referring back to FIG. 70A, the process of FIG. 70A may continue with step S7014. In a step S7014, excess collateral from the first trade may be collected from the security token contract. Step S7014 is described in more detail in connection with FIGS. 70E-F.

Referring to FIG. 70E, in embodiments, collecting excess collateral may begin at step S7050. In a step S7050, the administrator system 6801 may send a fifth transaction request from the administrator public address to the second contract address 6805A via the underlying blockchain 6803. In embodiments, the fifth transaction request may include a fifth message comprising requests for the security token smart contract 6805B to determine and distribute excess collateral for the first trade in accordance with the security token smart contract 6805B and the first trade instructions. The fifth transaction request may be electronically signed by the administrator private key. The administrator private key is mathematically related to the administrator public address.

In response to the requests contained in the fifth message, as shown in step S7052, the security token smart contract 6805B sends a sixth transaction request from the second contract address 6805A to an oracle address associated with an oracle smart contract on the blockchain 6803 associated with an oracle interface in contact with a trusted third party database. The sixth transaction request, in embodiments, may include a sixth message to obtain first benchmark data from the trusted third party database. In response to sending the sixth transaction request, in step S7054, the security token smart contract 6805B may receive a callback message from the oracle interface including the first benchmark information. In embodiments, access to the trusted third party database through the oracle smart contract may be limited to certain authorized or approved addresses on the blockchain. In embodiments, as described further below, a whitelist of authorized (or approved) requesting addresses may be provide in which the first benchmark information is provided only in response to requests from an authorized address. In embodiments, the whitelist of authorized requesting addresses may be updated. In embodiments, the administrator system may update the whitelist of authorized requesting addresses to reflect the address of the security token contract that is provided using the process of the present application.

In embodiments, the whitelist of authorized addresses may be included at the oracle smart contract address. In embodiments, the oracle smart contract address may include authorization instructions to request the first contract address only when the requester address is one of the addresses on the whitelist. In embodiments, the oracle smart contract may include authorization instructions related to an update key pair for updating the whitelist of authorized addresses to allow for the white list to be updated.

In embodiments, the whitelist of authorized addresses may be provided in memory element associated with the trusted third party database. In embodiments, the trusted third party database will not provide the first benchmark information to the oracle contract unless the requester address is included in the whitelist of authorized addresses.

In response to receiving a callback message, in step S7056, the security token smart contract 6805B executes instructions to: (1) store the first benchmark information and (2) calculate the excess collateral for the first user (e.g. the user associated with user device 105a) and the second excess collateral for the second user (e.g. the user associated with user device 105b) by using the first trade instructions and the first benchmark information. In embodiments, the first excess collateral is the first amount of collateral less the difference between the first benchmark information and the inception value, to the extent it is greater than zero. In embodiments, the second excess collateral is the second amount of collateral less the difference between the inception value and the first benchmark information, to the extent it is greater than zero.

To the extent that the first excess collateral is greater than zero or the second excess collateral is greater than zero, in step S7058, the security token smart contract 6805B sends a seventh transaction request from the second contract address 6805A to the first contract address 6807A via the underlying blockchain 6803. The seventh transaction request, in embodiments, may include a seventh message requesting the stable value token smart contract 6807B to transfer: (1) the first excess collateral in stable value digital asset token from the second contract address 6805A to the first user public address (associated with the first user and user device 105a), to the extent the first excess collateral is greater than zero; and (2) the second excess collateral in stable value digital asset token from the second contract address 6805A to the second user public address (associated with the second user and user device 105b).

Referring to FIG. 70F, in embodiments, collecting excess collateral (e.g. settling the published contract) may begin at step S7060 where an oracle service sends a fifth transaction request from an oracle address associated with an oracle interface to the second smart contract address 6805A via the underlying blockchain 6803. In embodiments, the fifth transaction request may include a fifth message comprising first benchmark information. In response to receiving the fifth message, in step S7062 the second smart contract 6805B executes instructions to store first benchmark information. In embodiments, the first benchmark information may, as mentioned above, be different and/or substantially different from benchmark information associated with a similar contract associated with the oracle address. A more detailed description of these embodiments is located below in the description of FIGS. 95A-95D and FIGS. 96A-96C, the descriptions of which applying herein.

The process in FIG. 70F may continue at step S7064. In step S7064, the administrator system 6801 may send a sixth transaction request from the administrator public address to the second contract address 6805A via the underlying blockchain 6803. The sixth transaction request, in embodiments, may include a sixth message comprising requests to the security token smart contract 6805B to determine and distribute excess collateral for the first trade in accordance with the security token smart contract 6805B and the first contract instructions. The sixth transaction request may also be electronically signed by an administrator private key (located in key information 6801C of FIG. 68). The administrator private key is mathematically related to the administrator public address. In embodiments, the sixth transaction request may be sent by user device 105a from the first user public address (associated with a first user and user device 105a) to the second contract address 6805A. In embodiments where the sixth transaction request is sent by user device 105a, the sixth transaction request may also be electronically signed by a first user private key. The first user private key is mathematically related to the first user public address. Furthermore, in embodiments, the sixth transaction request may be sent by user device 105b from the second user public address (associated with a second user and user device 105b) to the second contract address 6805A. In embodiments where the sixth transaction request is sent by user device 105b, the sixth transaction request may also be electronically signed by a second user private key. The second user private key is mathematically related to the second user public address.

In response to the requests contained in the sixth message, in step S7014′D, the security token smart contract 6805B executes instructions via the blockchain 6803 to calculate first excess collateral for the first user (e.g. a user associated with user device 105a) and second excess collateral for the second user (e.g. a user associated with user device 105b) using the first trade instructions and the first benchmark information. In embodiments, the first excess collateral is the first amount of collateral less the difference between the first benchmark information and the inception value, to the extent it is greater than zero. In embodiments, the second excess collateral is the second amount of collateral less the difference between the inception value and the first benchmark information, to the extent it is greater than zero.

To the extent that the first excess collateral is greater than zero or the second excess collateral is greater than zero, in step S7014′E, the security token smart contract 6805B sends a seventh transaction request from the second contract address 6805A to the first contract address 6807A via the underlying blockchain 6803. The seventh transaction request, in embodiments, may include a seventh message requesting the stable value token smart contract 6807B to transfer: (1) the first excess collateral in stable value token from the second contract address 6805A to the first user public address (associated with the first user and user device 105a), to the extent the first excess collateral is greater than zero; and (2) the second excess collateral in stable value token from the second contract address 6805A to the second user public address (associated with the second user and user device 105b). As in step S7014E, if there is excess collateral, the second contract address 6805A sends the excess collateral to the user of which that excess collateral belongs.

In embodiments, such as the embodiments where a third user response and fourth user response are received by the administrator system and matched, the administrator system may set up a second trade between the fourth user and the fifth user. This process of setting up a trade between two users may be similar to the process described in connection with FIGS. 70B-70D, the same description applying herein.

In embodiments, the steps within the process described above in connection with FIGS. 70A-F may be rearranged or omitted.

In embodiments, a separate security token smart contract may be generated and published to the underlying blockchain for each separate trade.

For example, in embodiments, generating a security token smart contract between a first user and a second user may be implemented, in accordance with the following example. In embodiments, generating a security token smart contract between a first user and a second user may begin with an administrator system associated with an administrator 6809 of a security token smart contract receiving a contract proposal. In embodiments, the security token smart contract is maintained on a distributed public transaction ledger maintained by a plurality of geographically distributed computer systems in a peer-to-peer network in the form of a blockchain 6803 of an underlying digital asset. In embodiments the underlying digital asset may be a digital math-based asset, Ether, or Neo, to name a few. In embodiments the contract proposal includes: first user information associated with a first user device 105a that is associated with a first user; and first contract information including at least the following contract parameters 6801B: an inception date 6902; an inception value 6904; at least one benchmark 6906; a contract duration 6908; at least one collateral requirement 6910; a notional value of the smart contract 6912; and first side information including identification of a first leg of the contract (e.g. the side information including a leg of a contract described in FIGS. 71C-71F—ref nos. 7138, 7144, 7154, 7160 respectively). In embodiments, the first user information further includes a first user public address (e.g., Alice Public Address 7146 described above in reference to FIG. 71D) associated with the blockchain 6803 of the underlying digital asset. In embodiments the first user public address corresponds to a first user private key that is mathematically related to the first user public address. In embodiments the first contract information further includes at least one of the following: derivative type information; early termination rules 6914; a second benchmark 6916; asset identification information; pricing model information; and volatility information. In embodiments the first contract information further includes first collateral information in stable value tokens (e.g., 100 Stable Value Coins 7148 described above in reference to FIG. 71D). In embodiments the first contract information further includes second collateral information in stable value tokens. In embodiments the first contract information includes first transaction fee information. In embodiments, the administrator system may generate graphical user interface information including at least one prompt for the first user to provide the contract proposal. The administrator system may then send the graphical user interface information to the first user device. In embodiments, the administrator system may then receive the contract proposal in response to the at least one prompt.

In embodiments, the method continues with the administrator system receiving at least one indication of interest (e.g., second indication of interest 7150 described above in reference to FIG. 71E). In embodiments, the at least one indication of interest includes at least a first user response, from a second user device 105b associated with a second user. In embodiments, the first user response includes second user information associated with the second user. In embodiments, the second user information further includes a second user public address (e.g., Bob Public Address 7162) associated with the blockchain 6803 of the underlying digital asset. In embodiments the second user public address corresponds to a second user private key that is mathematically related to the second user public address. In embodiments, the first user response further includes second side information which may include an identification of a second leg of the contract (e.g. the side information including a leg of a contract described in FIGS. 71C-71F—reference numbers 7138, 7144, 7154, and 7160 respectively).

In embodiments, the method continues with the administrator system matching the first contract information and the first user response. Matching, by the administrator system, may be similar to S7006 of FIG. 70A.

In embodiments, the method continues with an administrator system providing a stable value token smart contract associated with a stable value token 6807 and first smart contract instructions 6807B for a digital asset token. The digital asset token, in embodiments, may be associated with a first smart contract address 6807A that may be associated with the blockchain 6803 for the underlying digital asset. In embodiments, the first smart contract instructions 6807B are saved in the blockchain 6803 for the underlying digital asset. In embodiments, the first smart contract instructions 6807B include: first authorization instructions regarding creating stable value tokens (which may be included in the create stable value token module 6934); second authorization instructions regarding transferring stable value tokens (which may be included in the transfer stable value token module 6936); third authorization instructions regarding destroying stable value tokens (which may be included in the destroy stable value token module 6938); and fourth authorization instructions regarding functions associated with the stable value token (which may be included in the authorization instruction module 6940). In embodiments the first smart contract instructions of the first stable value smart contract are associated with more than one smart contract address. For example, Smart Contract Address 6807A may may be associated with a plurality of smart contract addresses associated with the blockchain 6803 for the underlying digital asset.

In embodiments, the method continues with the administrator system generating the security token smart contract, which may be associated with a security token 6805 and second smart contract instructions 6805B which may be associated with a second smart contract address 6805A which may be associated with the blockchain for the underlying digital asset. In embodiments, the second smart contract instructions 6805B are saved in the blockchain 6803 for the underlying digital asset. In embodiments, the second smart contract instructions 6805B include: first trade instructions for the security token smart contract (which may be similar to step S7016 described above in reference to FIG. 70B), fifth authorization instructions regarding transferring security tokens (which may be included in transfer security tokens module 6920); sixth authorization instructions regarding destroying security tokens (which may be included in destroy security tokens module 6922); seventh authorization instructions regarding transferring stable value tokens to the second contract address (which may be included in authorize instructions module 6926); eighth authorization instructions regarding transferring stable value tokens from the second contract address (which may be included in authorize instructions module 6926); and calculating instructions regarding calculating excess collateral (which may be included in calculate excess collateral module 6928). In embodiments, the first trade instructions include execution instructions to execute a first trade between the first user and the second user (which may be included in authorize instructions module 6926). In embodiments, the first trade is based on at least: the contract proposal and the first user response.

In embodiments, the method continues with the administrator system sending the security token smart contract and associated second smart contract instructions. In embodiments, the security token smart contract and associated second smart contract instructions 6805B may be sent via the blockchain 6803 for the underlying digital asset to the second smart contract address 6805A.

In embodiments, the method may continue with the second smart contract address 6805A receiving a first amount of collateral. In embodiments the first amount of collateral may be a first amount of stable value tokens associated with the first user as collateral. In embodiments the first amount of stable value tokens associated with the first user is based on the at least one collateral requirement 6910. In embodiments, the first user device 105a may send a first message. The first message may include a request to transfer the first amount of collateral from the first user public address to the second smart contract address. In embodiments the first message may be sent via the underlying blockchain 6803 from the first user public address associated with the underlying blockchain 6803 to the first smart contract address 6807A associated with the underlying blockchain 6803. In embodiments the first user device 105a may send a second message to the first smart contract address 6807A. The second message may include authorization for the security token smart contract to request a transfer of the first amount of collateral. In embodiments the administrator system may send a third message including instructions to send a request from the second smart contract address 6805A to the first smart contract address 6807A. The request, in embodiments, may be for the first amount of collateral to be transferred from the first user public address to the second smart contract address 6805A. In embodiments, the third message is sent by the administrator system via the underlying blockchain 6803 to the second smart contract address 6805A.

In embodiments, the method may continue with the second smart contract address 6805A receiving a second amount of collateral. In embodiments the second amount of collateral may be a second amount stable value tokens associated with the second user as collateral. In embodiments the second amount of stable value tokens associated with the second user is based on the at least one collateral requirement 6910. In embodiments the second user device 105b may send a fourth message including a request. In embodiments, the request may be to transfer the second amount of collateral from the second user public address to the second smart contract address 6805A. In embodiments the fourth message may be sent via the underlying blockchain 6803 from the second user public address associated with the underlying blockchain 6803 to the first smart contract address 6807A associated with the underlying blockchain 6803. In embodiments the second user device 105b may send a fifth message to the first smart contract address 6807A. The fifth message, in embodiments, may include authorization for the security token smart contract to request a transfer of the second amount of collateral via the blockchain 6803. In embodiments, the administrator system may send a sixth message. The sixth message, in embodiments, may include instructions to send a request. The request, in embodiments, may be for the second amount of collateral to be transferred from the second user public address to the second smart contract address 6805A. In embodiments, the sixth message is sent via the underlying blockchain 6803 to the second smart contract address 6805A.

In embodiments, the first trade instructions are implemented via the blockchain for the underlying digital asset by computer systems among the plurality of geographically distributed computer systems in the peer-to-peer network. In embodiments, the first trade instructions are implemented as a result of a message sent from the administrator system via the blockchain 6803 to the second smart contract address 6805A.

In embodiments, the method may continue with the first collateral amount being recalculated based on the at least one collateral requirement 6910 and current benchmark information (this may be similar to steps S6310 and S6311, both described above in reference to FIG. 63C). In embodiments, the recalculation may be performed by the first user device 105a. In embodiments, the recalculation is performed by the administrator system. In embodiments, a first additional collateral amount may be determined based on a difference between the recalculated first collateral amount and the first collateral amount. The first additional collateral amount may then be received at the second smart contract address 6805A. In embodiments the first additional collateral may not be received. In embodiments, the administrator system may generate an alert. The alert, in embodiments, may include the first additional collateral amount. Once generated, the administrator system may send the alert to the first user device 105a. In embodiments, the alert may be generated and sent by security token smart contract to the first user device 105a (e.g., using the generate collateral information message module 6930 and the send collateral information message module 6932). Once the alert regarding the first additional collateral amount is received by the first user device 105a, the method may continue with the administrator system monitoring the second contract address 6805A on the blockchain 6803 associated with the underlying digital asset (this may be similar to step S7034 described above in reference to FIG. 70C). The administrator system may then, in embodiments, determine whether the first additional collateral amount is received by the second contract address 6805A (this may be similar to step S7034 described above in reference to FIG. 70C). If the first additional collateral is not received by the second contract address 6805A, the administrator system may generate a default notification. The default notification may be sent by the administrator system to at least one of the first user device 105a, the second user device 105b, and the second smart contract address 6805A. In embodiments, the default notification may be generated and sent by security token smart contract to at least one of the first user device 105a and the second user device 105b (e.g., using the generate collateral information message module 6930 and the send collateral information message module 6932). After the default notification is sent, the administrator system, in embodiments, may generate a seventh message. The seventh message, in embodiments, may include a request to transfer the first collateral amount and the second collateral amount in accordance with the first trade instructions. The seventh message may be sent by the administrator system to the second smart contract address 6805A. In embodiments the transfers of the first collateral amount and the second collateral amount are implemented by the plurality of geographically distributed computer systems in the peer-to-peer network.

In embodiments, the method may continue with the second collateral amount being recalculated based on the at least one collateral requirement 6910 and current benchmark information (this may be similar to steps S6310 and S6311, both described above in reference to FIG. 63C). In embodiments, the recalculating step is performed by the second user device 105b. In embodiments the recalculating step is performed by the administrator system. In embodiments, a second additional collateral amount may be determined based on a difference between the recalculated second collateral amount and the second collateral amount. In embodiments, the second additional collateral amount is received at the second smart contract address 6805A. In embodiments the second additional collateral may not be received and the administrator system may generate an alert. The alert, in embodiments, may include the second additional collateral amount. Once generated, the administrator system may send the alert to the second user device 105b. In embodiments, the alert may be generated and sent by security token smart contract to the second user device 105b (e.g., using the generate collateral information message module 6930 and the send collateral information message module 6932). Once the alert regarding the second additional collateral amount is received by the second user device 105b, the method may continue with the administrator system monitoring the second smart contract address 6805A on the blockchain 6803 associated with the underlying digital asset (this may be similar to step S7034 described above in reference to FIG. 70C). The administrator system may monitor the second smart contract address 6805A to determine whether the second additional collateral amount is received by the second contract address (this may be similar to step S7034 described above in reference to FIG. 70C). If the administrator system determines that the second additional collateral amount is not received by the second smart contract address 6805A, the administrator system may generate a default notification. The default notification may be sent by the administrator system to at least one of: the first user device 105a, the second user device 105b, and the second smart contract address 6805A. In embodiments, the default notification may be generated and sent by security token smart contract to at least one of the first user device 105a and the second user device 105b (e.g., using the generate collateral information message module 6930 and the send collateral information message module 6932). After sending the default notification, the administrator system may generate an eighth message. The eighth message, in embodiments, may include a request to transfer the first collateral amount and the second collateral amount in accordance with the first trade instructions. The eighth message, in embodiments may be sent by the administrator system to the second smart contract address 6805A, where transfers of the first collateral amount and the second collateral amount are implemented by the plurality of geographically distributed computer systems in the peer-to-peer network.

In embodiments, the method may include the administrator system determining, at the end of the contract duration, a payout amount based on at least the first trade instructions. The payout instructions may be generated by the administrator system. In embodiments, the payout instructions may be based at least on the first side information and the second side information (e.g. the first and/or second side information including a leg of a contract described in FIGS. 71C-71F—ref nos. 7138, 7144, 7154, 7160 respectively). The administrator system may, in embodiments, send the payout instructions to the second contract address 6805A via the blockchain 6803 for the underlying digital asset. The payout instructions may provide the payout amount to one of the first user public address and the second user public address. The payout amount, in embodiments, being based on at least the first trade instructions. In embodiments the payout instructions are implemented by the plurality of geographically distributed computer systems in the peer-to-peer network.

In embodiments, the method may include the administrator system collecting excess collateral from the first trade (this may be similar to S7014 described above in reference to FIGS. 70A, 70E, and 70F). The administrator system may collect excess collateral by first sending a ninth message to the second smart contract address 6805A via the underlying blockchain 6803 for the underlying digital asset. The ninth message may include, in embodiments, requests for the security token to: determine first excess collateral for the first trade in accordance with the security token smart contract (this may be similar to S7014 described above in reference to FIGS. 70A, 70E, and 70F) and the first trade instructions; determine second excess collateral for the first trade in accordance with the security token smart contract and the first trade instructions (this may be similar to S7014 described above in reference to FIGS. 70A, 70E, and 70F); distribute the first excess collateral for the first trade in accordance with the security token smart contract and the first trade instructions to the first user address (this may be similar to S7014 described above in reference to FIGS. 70A, 70E, and 70F); and distribute the second excess collateral for the first trade in accordance with the security token smart contract and the first trade instructions to the second user address (this may be similar to S7014 described above in reference to FIGS. 70A, 70E, and 70F).

In embodiments, the administrator system may return the remaining collateral from the first trade (this may be similar to S7014 described above in reference to FIGS. 70A, 70E, and 70F). The remaining collateral, in embodiments, may be from the security token smart contract. In embodiments returning the remaining collateral may begin by the administrator system sending a tenth message to the second smart contract address 6805. The tenth message, in embodiments, may include requests for the security token smart contract to: determine first remaining collateral for the first trade in accordance with the security token smart contract and the first trade instructions (e.g. using calculate excess collateral module 6928); determine second remaining collateral for the first trade in accordance with the security token smart contract and the first trade instructions (e.g. using calculate excess collateral module 6928); distribute the first remaining collateral for the first trade in accordance with the security token smart contract and the first trade instructions; and distribute the second remaining collateral for the first trade in accordance with the security token smart contract and the first trade instructions (this may be similar to S7014 described above in reference to FIGS. 70A, 70E, and 70F).

In embodiments, a first benchmark value 6906 may be determined. The first benchmark value 6906 may be determined by the security token smart contract sending, via the blockchain 6803 for the underlying digital asset, a request. The request may be sent from the second smart contract address 6805A to an oracle smart contract at a third contract address associated with the blockchain 6803 for the underlying digital asset (this may be similar to S7014 described above in reference to FIGS. 70A, 70E, and 70F). The oracle smart contract may be associated with an oracle interface in contact with an authorized third party database. The request may include an eleventh message (this may be similar to S7014 described above in reference to FIGS. 70A, 70E, and 70F). The eleventh message may include a request to obtain first benchmark value 6906 (this may be similar to S7014 described above in reference to FIGS. 70A, 70E, and 70F). In response to the eleventh message, the oracle smart contract may send the first benchmark value 6906 to the security token smart contract (this may be similar to S7014 described above in reference to FIGS. 70A, 70E, and 70F). In response to receiving the first benchmark value, the security token smart contract may execute instructions to store the first benchmark value 6906.

In the case where the first excess collateral is greater than zero the first excess collateral may be calculated for the first user (this may be similar to S7014 described above in reference to FIGS. 70A, 70E, and 70F). In the case where the second excess collateral is greater than zero, the second excess collateral may be calculated for the second user (this may be similar to S7014 described above in reference to FIGS. 70A, 70E, and 70F). The first and second excess collateral, in embodiments, may be calculated using the first trade instructions and the first benchmark information 6906 (this may be similar to S7014 described above in reference to FIGS. 70A, 70E, and 70F). Once the excess collateral is calculated, the second smart contract address may send a twelfth message to the first smart contract address. The twelfth message may include a request for the stable value token smart contract to transfer the excess collateral—the first excess collateral being requested to transfer if greater than zero and the second excess collateral being requested to transfer if greater than zero (this may be similar to S7014 described above in reference to FIGS. 70A, 70E, and 70F).

In embodiments, the smart contract may pull data from a trusted third party by using a query function, examples of which include Oraclize, etc. The query from the smart contract may include the address of the web API to be queried and the data requested. The third party service then accesses data through web APIs and provides this data to the smart contract through a callback response. The data obtained from web APIs may be parsed to provide data that is compatible with the smart contract, examples of such parsing including JSON, XML and HTML parsing, to name a few. The authenticity of the data provided by the third party may be verified by a cryptographic proofing service, examples of which can include TLSNotary Proofs, Android Proofs and Ledger Proofs, to name a few. In embodiments, the third party service may provide a pointer to an uploaded proof rather than provide the proof itself in order to limit the amount of data provided to the smart contract.

In embodiments, data may be pushed to a smart contract from an external intermediary. In embodiments, the external intermediary may be automated or manually controlled. The external intermediary may be identified in the smart contract as a trusted address. In embodiments, the external intermediary may push data to the smart contract that is representative of a value used by the smart contract. The data may be a copy of data that the external intermediary obtains through a web API. In other embodiments, the data may be derived from one or more sources of data, for example a blended price value based on data from multiple exchanges, as discussed elsewhere. In embodiments, the external intermediary may be a service that provides price information for one or more digital assets. In embodiments, the external intermediary may be hosted by an exchange or other digital asset computer system that provides price information for one or more digital assets. In embodiments, the external intermediary may be the administrator computer system or a digital asset exchange computer system.

In embodiments, the smart contract may pull data from a decentralized network of oracles. Queries for the same data may be sent to multiple oracles and the data returned by the oracles may be compared in order to establish the veracity of the data. In embodiments, the decentralized network of oracles may be an opinion market, examples of which include Auger and Gnosis, to name a few.

In embodiments, an oracle contract ‘c’ may be accessible to other smart contracts. That is, the address of oracle contract ‘c’ may already be used by other smart contracts. One or more of these other smart contracts may call the oracle contract ‘c’ to invoke its function. Inside the implementation of the oracle contract ‘c’, the contract may make a call to the oracle (as a trusted source) with a query, e.g. oracle.query( . . . ). In embodiments, however, some function of contract ‘c’ may be called in order to trigger the call to the oracle. In embodiments, the parameters to query the function may include: (1) an identifier for the data source; (2) a timestamp; (3) additional parameters to specify the query to the data source, to name a few. In embodiments, the call may return a unique identifier (such as ‘id’) to identify the query that was made to the oracle, as the oracle query does not directly return a query result.

In embodiments, contract ‘c’ may include smart contract instructions that include a callback function, for example, function callback(bytes 32 queryId, string result)

In embodiments, information may be retrieved from outside the blockchain. When the trusted intermediary has completed the execution of the query outside the blockchain, accessing whatever external datasource is required, it may send the query result back to the blockchain with a transaction that calls back to the contract ‘c’ as follows:

TO: ‘c’

FROM: CallbackAddress

DATA: _callback(id, “query_result_data_ . . . ”)

Thereafter, the contract ‘c’ may store the result data at the callback address for use as appropriate.

In embodiments, the above model may be used where the domain of query-able things is not known ahead of time or where the domain of query results is far larger than desirable to pre-emptively load into the blockchain. For example, where the query is related to a time series of market data with very granular time precision, it would be impractical to store all of this information in the blockchain. In contrast, the above model is suitable where a small, targeted value out of a large data set is needed. In embodiments, a simpler model may be used where the datasource is fixed ahead of time (e.g. Gemini BTC auction) and domain cardinality is small (e.g. one value per day, one value per week, one value per month, to name a few).

In embodiments, an oracle model may include two smart contracts, the ‘oracle’ and some contract ‘c’ using it. When the contract ‘c’ calls the oracle's query function, the query result is returned directly (as opposed to the query id in the model discussed above) and there is no need for a callback.

In embodiments, when such a push model is used, a transaction must first occur targeting contract ‘c’ to query the ‘oracle’, and thus may be considered a “pull” of data instigated by ‘c’. However, data is generally not pulled into the blockchain. Instead, in embodiments utilizing the pull model discussed above, a second transaction occurs from the trusted intermediary (such as the Oraclize service), which sends the desired result to contract ‘c’ via the callback, and thus, is really a push.

In embodiments, using a small oracle model, in a first transaction, the operator, such as the administrator system, pushes data, such as an auction result, in a transaction so that it is stored in the oracle. Later transactions may occur based on calls to contracts that may then query the oracle to fetch that auction result, which may be considered a lookup, (or a pull). Thus, this model uses a push followed by a pull.

In embodiments, another variation of the model may utilize a subscribe and publish model. In embodiments, the subscribe and publish model may be used for a query that is a one-time action, for a datasource, or a datastream, such as periodically occurring events like the Gemini auction. In embodiments, instead of a call with parameters that specify a single results such as: oracle.query( . . . ) the contract ‘c’ may make a call with parameter that specifies a stream of future events that it wishes to receive, such as: oracle.subscribe( . . . ). In this case, when the operator pushes a new event to the oracle (say an auction result) then the oracle may call each of its subscribers on their respective callback functions to broadcast the event. This model may be considered pull, push, push, push, etc.

In embodiments, access to oracle information may be limited. In embodiments using the small oracle model discussed above, as the query result is returned directly to the query function itself, to limit access, an authorization check of the message sender against a whitelist of permitted callers may be used. The oracle operator may maintain such a whitelist to enable contracts to use its oracle.

In embodiments, there may not be an authorization (in the oracle contract) that is required to restrict which contracts may interact with the oracle. In embodiments, while any contract may query the oracle, the service or operator may decide if and when to push the requested data via the callback, and it may elect to drop queries if the calling contract is deemed not to be authorized. Of course, the oracle could also adhere to a whitelist and reject any query from an unauthorized sender.

In the subscription and publication module discussed above, subscriptions may be gated by a whitelist to limit access. Alternatively, the publish step may only target those contracts that are authorized, similarly to restrictions discussed above.

In embodiments, a method for holding collateral in a smart contract on an underlying blockchain includes: (a) publishing, by an administrator system associated with an administrator, contract information comprising at least the following contract terms: (1) an inception date; (2) an inception value; (3) at least one benchmark; (4) a contract duration; (5) at least one collateral requirement; and (6) a notional value of the contract; (b) receiving, by the administrator system, a plurality of indications of interests, wherein the plurality of indications of interests include at least: (1) a first user response, from a first user device associated with a first user, the first user response including: (i) first user identification information associated with the first user; and (ii) first side information comprising identification of a first leg of the contract; and (2) a second user response, from a second user device associated with a second user, the second user response including: (i) second user identification information associated with the second user; and (ii) second side information comprising identification of a second leg of the contract wherein the second leg is different than the first leg; (c) matching, by the administrator system, the first user response with the second user response; (d) providing, on the underlying blockchain, a stable value token smart contract having a first contract address on the underlying blockchain for a stable value digital asset token comprising instructions to: (1) create stable value tokens; (2) transfer stable value tokens; (3) destroy stable value tokens; and (4) authorization instructions; (e) providing, on the underlying blockchain, a security token smart contract having a second contract address on the underlying blockchain comprising instructions to: (1) create security tokens; (2) transfer security tokens; (3) destroy security tokens; (4) access data supplied by a first authorized third party database; (5) authorize instructions to transfer of stable value token to the second contract address; (6) authorize instructions to transfer of stable value token from the second contract address; and (7) calculate excess collateral; (f) setting up, by the administrator system, a first trade between the first user and the second user, the first trade using the security token smart contract on the underlying blockchain with collateral in the form of stable value digital asset tokens, the step of setting up further comprising: (1) generating, by the administrator system, first trade instructions for the security token smart contract, the first trade instructions including instructions to execute the first trade between a first user public address on the underlying blockchain associated with the first user and a second user public address on the underlying blockchain associated with the second user, wherein the first trade is based at least on: (i) the contract terms; (ii) the first user response; and (iii) the second user response; (2) generating, by the administrator system, hashed trade instructions by applying a hash algorithm to the first trade instructions; (3) sending, by the administrator system via the underlying blockchain, a first transaction request, from an administrator public address on the underlying blockchain to the second contract address on the underlying blockchain, wherein the first transaction request includes a first message including: (i) the hashed trade instructions; and (ii) request to assign a first trade identification to a first trade associated with the hashed trade instructions, wherein the administrator public address on the underlying blockchain has a corresponding administrator private key, wherein the administrator private key being mathematically related to the administrator public address, and wherein the first transaction request is signed by the administrator private key; (4) obtaining, by the administrator system, the first trade identification of the first trade; (5) sending, by the administrator system, the first trade identification to the first user device associated with the first user; (6) sending, by the administrator system, the first trade identification to the second user device associated with the second user; (7) monitoring, by the system administrator, transactions of stable value digital asset tokens on the underlying blockchain to determine that the second contract address has received at least the following: (i) a first amount of collateral in stable value digital asset tokens from the first user; and (ii) a second amount of collateral in stable value digital asset tokens from the second user; (8) sending, by the administrator system via the underlying blockchain, a second transaction request, from the administrator public address on the underlying blockchain to the second contract address on the underlying blockchain, wherein the second transaction request includes a second message including: (i) the first trade instructions; and (ii) the first trade identification; and wherein the second transaction is signed by the administrator private key; and (g) collecting, by the administrator system from the security token smart contract, excess collateral from the first trade, wherein collecting comprises: (1) sending, by the administrator system via the underlying blockchain, a third transaction request from the administrator public address on the underlying blockchain to the second contract address on the underlying blockchain, the third transaction request including a third message comprising requests for the security token smart contract to: (i) determine excess collateral for the first trade in accordance with the security token smart contract and the first trade instructions; and (ii) distribute excess collateral for the first trade in accordance with the security token smart contract and the first trade instructions, and wherein the third transaction is signed by the administrator private key; (2) sending, by the security token smart contract via the underlying blockchain in response to the instructions contained in the third message, a fourth transaction request from the second contract address on the underlying blockchain to an oracle address on the underlying blockchain, wherein the oracle address is associated with an oracle interface, and wherein the fourth transaction request includes a sixth message to obtain first benchmark data; (3) receiving, by the security token smart contract from the oracle interface, a callback message; (4) executing, by the security token smart contract in response to receiving the callback message, instructions to: (i) store the first benchmark information; and (ii) calculate the first excess collateral for the first user and second excess collateral for the second user by using the first trade instructions and the first benchmark information; and (5) in the cases where at least one of the first excess collateral is greater than zero or the second excess collateral is greater than zero, sending, by the security token smart contract via the underlying blockchain, a fifth transaction request, from the second contract address on the underlying blockchain to the first contract address on the underlying blockchain, wherein the fifth transaction request including a fifth message requesting the stable value token smart contract to transfer: (i) the first excess collateral in stable value tokens from the second contract address on the underlying blockchain to the first user public address on the underlying blockchain, if the first excess collateral is greater than zero; and (ii) the second excess collateral in stable value tokens from the second contract address on the underlying blockchain to the second user public address on the underlying blockchain, if the second excess collateral is greater than zero.

In embodiments, the contract further includes: (7) early termination rules; and (8) a second benchmark.

In embodiments the first user response further includes: (iii) a first user public address on the underlying blockchain; and (iv) first collateral information in stable value tokens.

In embodiments, the second user response further comprises: (iii) a second user public address on the underlying blockchain; and (iv) second collateral information in stable value token.

In embodiments the first transaction request further includes first transaction fee information. In embodiments the second transaction request further includes second transaction fee information.

In embodiments, the first trade identification further includes: (i) monitoring, by the administrator system, transactions on the underlying blockchain to determine the first trade identification as calculated by the security token smart contract.

In embodiments, the step of monitoring transactions of the stable value digital asset token on the underlying blockchain further includes monitoring, by the administrator system, the first contract address on the underlying blockchain to determine: (i) the first amount of collateral is received at the second contract address on the underlying blockchain; and (ii) the second amount of collateral is received at the second contract address on the underlying blockchain.

In embodiments the step of monitoring transactions of the stable value digital asset token on the underlying blockchain further includes monitoring, by the administrator system, the first contract address on the underlying blockchain to determine: (i) the first amount of collateral is received at the second contract address on the underlying blockchain; and (ii) the second amount of collateral is received at the second contract address on the underlying blockchain. In embodiments, the second contract address further includes instructions to: (8) generate a collateral confirmation message to the administrator system confirming receipt of at least one of the first amount of collateral and the second amount of collateral when at least one of the first amount of collateral and the second amount of collateral is received; and (9) send the collateral confirmation message to the administrator system confirming receipt of at least one of the first amount of collateral and the second amount of collateral when at least one of the first amount of collateral and the second amount of collateral is received.

In embodiments the first excess collateral is the first amount of collateral less the difference between the first benchmark information and the inception value.

In embodiments the second excess collateral is the second amount of collateral less the difference between the inception value and the first benchmark information.

In embodiments the first user public address has a corresponding first user private key which is mathematically related to the first user public address.

In embodiments, the second user public address has a corresponding second user private key which is mathematically related to the second user public address.

In embodiments, prior to the step of monitoring transactions of the stable value digital asset token on the underlying blockchain, a sixth transaction is sent by the first user device via the underlying blockchain, from the first user public address on the underlying blockchain to the first contact address on the underlying blockchain, wherein the sixth transaction request comprises a sixth message including requests to the stable value token smart contract regarding a first transfer of the first amount of collateral, wherein the first user public address has a corresponding first user private key which is mathematically related to the first user public address; and wherein the sixth transaction request is signed by the first user private key.

In embodiments, the sixth transaction request further includes third transaction fee information.

In embodiments, the requests to the stable value token smart contact regarding the first transfer of the first amount of collateral include requests to the stable value smart contract to transfer the first amount of collateral in the form of stable value digital asset tokens from the first user public address on the underlying blockchain to the second contract address on the underlying blockchain.

In embodiments, the requests to the stable value smart contract to transfer the first amount of collateral in the form of stable value digital asset tokens from the first user public address on the underlying blockchain to the second user public address on the underlying blockchain are executed upon receipt of a first collateral request from the second contract address.

In embodiments, the seventh transaction request includes fourth transaction fee information.

In embodiments, the requests regarding transfer of the second amount of collateral include requests to the stable value smart contract to transfer the second amount of collateral in the form of stable value digital asset tokens from the second user public address on the underlying blockchain to the second contract address on the underlying blockchain.

In embodiments, the requests to the stable value smart contract to transfer the second amount of collateral in the form of stable value digital asset tokens from the second user public address on the underlying blockchain to the second contract address are executed upon receipt of a second collateral request from the second contract address on the underlying blockchain.

In embodiments, the requests to the stable value smart contract to transfer the second amount of collateral in the form of stable value digital asset tokens from the second user public address on the underlying blockchain to the second contract address on the underlying blockchain are executed upon receipt of a second collateral request from the second administrator system.

In embodiments, the step of collecting the excess collateral occurs in response to the security token smart contract verifying the first trade instructions against the hashed instructions.

In embodiments, a method for holding collateral in a smart contract on an underlying blockchain, the method includes: (a) publishing, by an administrator system associated with an administrator, contract information comprising at least the following contract terms: (1) an inception date; (2) an inception value; (3) at least one benchmark; (4) a contract duration; (5) at least one collateral requirement; and (6) a notional value of the contract; (b) receiving, by the administrator system, a plurality of indications of interests, wherein the plurality of indications of interests include at least: (1) a first user response, from a first user device associated with a first user, the first user response comprising: (i) first user identification information associated with the first user; and (ii) first side information comprising identification of a first leg of the contract; and (2) a second user response, from a second user device associated with a second user, the second user response including: (i) second user identification information associated with the second user; and (ii) second side information comprising identification of a second leg of the contract wherein the second leg is different than the first leg; (c) matching, by the administrator system, the first user response with the second user response; (d) providing, on the underlying blockchain, a stable value token smart contract having a first contract address on the underlying blockchain for a stable value digital asset token including instructions to: (1) create stable value tokens; (2) transfer stable value tokens; (3) destroy stable value tokens; and (4) authorization instructions; (e) providing, on the underlying blockchain, a security token smart contract having a second contract address on the underlying blockchain including instructions to: (1) create security tokens; (2) transfer security tokens; (3) destroy security tokens; (4) access data supplied by a first authorized third party database; (5) authorize instructions to transfer stable value tokens to the second contract address; (6) authorize instructions to transfer stable value tokens from the second contract address; and (7) calculate excess collateral; (f) setting up, by the administrator system, a first trade between the first user and the second user using the security token smart contract, the step of setting up further comprising: (1) sending, by the administrator system via the underlying blockchain a first transaction request, from an administrator public address on the underlying blockchain to the second contract address on the underlying blockchain, wherein the first transaction request comprises a first message including requests to create a first trade between a first user public address on the underlying blockchain associated with the first user device and a second user public address on the underlying blockchain associated with the second user device in accordance with the security token smart contract, wherein the administrator public address has a corresponding administrator private key which is mathematically related to the administrator public address, and wherein the first transaction request is signed by the administrator private key; (2) sending, by the administrator system via the underlying blockchain a second transaction request from the administrator public address on the underlying blockchain to the first contract address on the underlying blockchain, the second transaction request comprising a second message including requests to: (i) transfer of a first amount of collateral of stable value digital asset tokens from the first user public address to the second contract address; and (ii) transfer of a second amount of collateral of stable value digital asset tokens from the second user public address to the second contract address; wherein the second transaction request is signed by the administrator private key; and (g) collecting, by the administrator system from the security token smart contract, excess collateral from the first trade, wherein collecting comprises: (1) sending, by the administrator system via the underlying blockchain, a third transaction request from the administrator public address on the underlying blockchain to the second contract address on the underlying blockchain, the third transaction request including a third message comprising requests for the security token smart contract to: (i) determine excess collateral for the first trade in accordance with the security token smart contract and the first trade instructions; and (ii) distribute excess collateral for the first trade in accordance with the security token smart contract and the first trade instructions; and wherein the third transaction request is signed by the administrator private key; (2) sending, by the security token smart contract via the underlying blockchain in response to the requests contained in the third message, a fourth transaction request from the second contract address on the underlying blockchain to an oracle address on the underlying blockchain, wherein the oracle address is associated with an oracle interface; and wherein the fourth transaction request includes a fourth message to obtain first benchmark data; (3) receiving, by the security token smart contract from the oracle interface, a callback message; (4) executing, by the security token smart contract in response to receiving the callback message, instructions to: (i) store the first benchmark information; and (ii) calculate the first excess collateral for the first user and second excess collateral for the second user by using the first trade instructions and the first benchmark information; and (5) in the cases where at least one of the first excess collateral is greater than zero or the second excess collateral is greater than zero, sending, by the security token smart contract, via the underlying blockchain, a fifth transaction request, from the second contract address on the underlying blockchain to the first contract address on the underlying blockchain, wherein the fifth transaction request including a fifth message requesting the stable value token smart contract to transfer: (i) the first excess collateral in stable value tokens from the second contract address on the underlying blockchain to the first user public address on the underlying blockchain, if the first excess collateral is greater than zero; and (ii) the second excess collateral in stable value tokens from the second contract address on the underlying blockchain to the second user public address on the underlying blockchain, if the second excess collateral is greater than zero.

In embodiments, a method for holding collateral in a smart contract on an underlying blockchain, the method including: (a) publishing, by an administrator system associated with an administrator, contract information including at least the following contract terms: (1) an inception date; (2) an inception value; (3) at least one benchmark; (4) a contract duration; (5) at least one collateral requirement; and (6) a notional value of the contract; (b) receiving, by the administrator system, a plurality of indications of interests, wherein the plurality of indications of interests include at least: (1) a first user response, from a first user device associated with a first user, the first user response comprising: (i) first user identification information associated with the first user; and (ii) first side information comprising identification of a first leg of the contract; and (2) a second user response, from a second user device associated with a second user, the second user response comprising: (i) second user identification information associated with the second user; and (ii) second side information comprising identification of a second leg of the contract wherein the second leg is different than the first leg; (c) matching, by the administrator system, the first user response with the second user response; (d) providing, on the underlying blockchain, a stable value token smart contract having a first contract address on the underlying blockchain for a stable value digital asset token comprising instructions to: (1) create stable value tokens; (2) transfer stable value tokens; (3) destroy stable value token; and (4) authorization instructions; (e) providing, on the underlying blockchain, a security token smart contract having a second contract address on the underlying blockchain comprising instructions to: (1) create security tokens; (2) transfer security tokens; (3) destroy security tokens; (4) access data supplied by a first authorized third party database; (5) authorize instructions to transfer stable value tokens to the second contract address; (6) authorize instructions to transfer stable value tokens from the second contract address; and (7) calculate excess collateral; (f) setting up, by the administrator system, a first trade between the first user and the second user, the first trade using the security token smart contract on the underlying blockchain with collateral in the form of stable value digital asset tokens, the step of setting up further comprising: (1) generating, by the administrator system, first trade instructions for the security token smart contract, the first trade instructions including instructions to execute the first trade between a first user public address on the underlying blockchain associated with the first user and a second user public address on the underlying blockchain associated with the second user, wherein the first trade is based at least on: (i) the contract terms; (ii) the first user response; and (iii) the second user response; (2) generating, by the administrator system, hashed trade instructions by applying a hash algorithm to the first trade instructions; (3) sending, by the administrator system via the underlying blockchain, a first transaction request, from an administrator public address on the underlying blockchain to the second contract address on the underlying blockchain, wherein the first transaction request includes a first message comprising: (i) the hashed trade instructions; and (ii) instructions to assign a first trade identification to a first trade associated with the hashed trade instructions, wherein the administrator public address on the underlying blockchain has a corresponding administrator private key, wherein the administrator private key being mathematically related to the administrator public address, and wherein the first transaction request is signed by the administrator private key; (4) obtaining, by the administrator system, the first trade identification of the first trade; (5) sending, by the administrator system, the first trade identification to the first user device associated with the first user; (6) sending, by the administrator system, the first trade identification to the second user device associated with the second user; (7) monitoring, by the system administrator, transactions of stable value digital asset tokens on the underlying blockchain to determine that the second contract address has received at least the following: (i) a first amount of collateral in stable value digital asset tokens from the first user; and (ii) a second amount of collateral in stable value digital asset tokens from the second user; (8) sending, by the administrator system via the underlying blockchain, a second transaction request, from the administrator public address on the underlying blockchain to the second contract address on the underlying blockchain, wherein the second transaction request includes a second message including: (i) the first trade instructions; and (ii) the first trade identification; and wherein the second transaction request is signed by the administrator private key; and (g) collecting, from the security token contract, first trade excess collateral, wherein collecting comprises: (1) sending, by the administrator system via the underlying blockchain a third transaction request from the administrator public address on the underlying blockchain to the second contract address on the underlying blockchain, wherein the third transaction request includes a third message comprising requests for the security token smart contract to: (i) determine excess collateral for the first trade in accordance with security token smart contract and the first trade instructions; and (ii) distribute excess collateral for the first trade in accordance with security token smart contract and the first trade instructions; wherein the third transaction request is signed by the administrator private key; (2) executing, by the security token smart contract in response to receiving the requests contained in the third message, instructions to calculate first excess collateral for the first user and second excess collateral for the second user by using the first trade instructions and the first benchmark information; and (3) in the cases where at least one of the first excess collateral is greater than zero or the second excess collateral is greater than zero, sending, by the security token smart contract via the underlying blockchain a fourth transaction request from the second contract address on the underlying blockchain to the first contract address on the underlying blockchain, the fourth transaction request comprising a fourth message including requests for the stable value token smart contract to transfer: (i) the first excess collateral, if the first excess collateral is greater than zero, in stable value token from the second contract address on the underlying blockchain to the first user public address on the underlying blockchain; and (ii) the second excess collateral, if the second excess collateral is greater than zero, in stable value token from the second contract address on the underlying blockchain to the second user public address on the underlying blockchain.

In embodiments, obtaining the first trade identification further includes (i) monitoring, by the administrator system, transactions on the underlying blockchain to determine the first trade identification as calculated by the security token smart contract.

In embodiments, a method for holding collateral in a smart contract on an underlying blockchain, the method including: (a) publishing, by an administrator system associated with an administrator, contract information comprising at least the following contract terms: (1) an inception date; (2) an inception value; (3) at least one benchmark; (4) a contract duration; (5) at least one collateral requirement; and (6) a notional value of the contract; (b) receiving, by the administrator system, a plurality of indications of interests, wherein the plurality of indications of interests include at least: (1) a first user response, from a first user device associated with a first user, the first user response comprising: (i) first user identification information associated with the first user; and (ii) first side information comprising identification of a first leg of the contract; and (2) a second user response, from a second user device associated with a second user, the second user response comprising: (i) second user identification information associated with the second user; and (ii) second side information comprising identification of a second leg of the contract wherein the second leg is different than the first leg; (c) matching, by the administrator system, the first user response with the second user response; (d) providing, on the underlying blockchain, a stable value token smart contract having a first contract address on the underlying blockchain for a stable value digital asset token comprising instructions to: (1) create stable value tokens; (2) transfer stable value tokens; (3) destroy stable value tokens; and (4) authorization instructions; (e) providing, on the underlying blockchain, a security token smart contract having a second contract address on the underlying blockchain comprising instructions to: (1) create security tokens; (2) transfer security tokens; (3) destroy security token; (4) access data supplied by a first authorized third party database; (5) authorize instructions to transfer stable value tokens to the second contract address on the underlying blockchain; (6) authorize instructions to transfer stable value tokens from the second contract address on the underlying blockchain; and (7) calculate excess collateral; (f) setting up, by the administrator system, a first trade between the first user and the second user using the security token smart contract, the step of setting up further comprising: (1) sending, by the administrator system via the underlying blockchain a first transaction request, from an administrator public address on the underlying blockchain to the second contract address on the underlying blockchain, wherein the first transaction request comprises a first message including requests to create a first trade between a first user public address on the underlying blockchain associated with the first user device and a second user public address on the underlying blockchain associated with the second user device in accordance with the security token smart contract; wherein the administrator public address has a corresponding administrator private key which is mathematically related to the administrator public address on the underlying blockchain; and wherein the first transaction request is signed by the administrator private key; (2) sending, by the administrator system via the underlying blockchain a second transaction request from the administrator public address on the underlying blockchain to the first contract address on the underlying blockchain, the second transaction request comprising a second message including requests to: (i) transfer of a first amount of collateral of stable value digital asset tokens from the first user public address to the second contract address on the underlying blockchain; and (ii) transfer of a second amount of collateral of stable value digital asset tokens from the second user public address to the second contract address on the underlying blockchain; wherein the second transaction request is signed by the administrator private key; and (g) collecting, from the security token contract, first trade excess collateral, wherein collecting comprises: (1) sending, by the administrator system via the underlying blockchain a third transaction request from the administrator public address on the underlying blockchain to the second contract address on the underlying blockchain, wherein the third transaction request includes a third message comprising requests to the security token smart contract to: (i) determine excess collateral for the first trade in accordance with security token smart contract and the first trade instructions; and (ii) distribute excess collateral for the first trade in accordance with security token smart contract and the first trade instructions; wherein the third transaction request is signed by the administrator private key; (2) executing, by the security token smart contract in response to receiving the requests contained in the third message, instructions to calculate first excess collateral for the first user and second excess collateral for the second user by using the first trade instructions and the first benchmark information; and (3) in the cases where at least one of the first excess collateral is greater than zero or the second excess collateral is greater than zero, sending, by the security token smart contract via the underlying blockchain a fourth transaction request from the second contract address on the underlying blockchain to the first contract address on the underlying blockchain, the fourth transaction request comprising a fourth message including requests for the stable value token smart contract to transfer: (i) the first excess collateral, if the first excess collateral is greater than zero, in stable value token from the second contract address on the underlying blockchain to the first user public address on the underlying blockchain; and (ii) the second excess collateral, if the second excess collateral is greater than zero, in stable value token from the second contract address on the underlying blockchain to the second user public address on the underlying blockchain.

In embodiments, a method is disclosed which includes: (a) receiving, by an administrator system associated with an administrator of a security token smart contract, a contract proposal. In embodiments, the security token smart contract is maintained on a distributed public transaction ledger maintained by a plurality of geographically distributed computer systems in a peer-to-peer network in the form of a blockchain of an underlying digital asset. In embodiments the contract proposal includes: (i) first user information associated with a first user device that is associated with a first user; and (2) first contract information including at least the following contract parameters: (A) an inception date; (B) an inception value; (C) at least one benchmark; (D) a contract duration; (E) at least one collateral requirement; (F) a notional value of the smart contract; and (G) first side information including identification of a first leg of the contract. In embodiments, the method continues with (b) receiving, by the administrator system at least one indication of interest. In embodiments, the at least one indication of interest includes at least: (i) a first user response, from a second user device associated with a second user, the first user response including: (1) second user information associated with the second user; and (2) second side information including identification of a second leg of the contract. In embodiments, the method continues with (c) matching, by the administrator system, the first contract information and the first user response. In embodiments, the method continues with (d) providing a stable value token smart contract associated with a stable value token and first smart contract instructions for a digital asset token associated with a first smart contract address associated with the blockchain for the underlying digital asset. In embodiments, the first smart contract instructions are saved in the blockchain for the underlying digital asset and include: (i) first authorization instructions regarding creating stable value tokens; (ii) second authorization instructions regarding transferring stable value tokens; (iii) third authorization instructions regarding destroying stable value tokens; and (iv) fourth authorization instructions regarding functions associated with the stable value token. In embodiments, the method continues with (e) generating, by the administrator system, the security token smart contract associated with a security token and second smart contract instructions associated with a second smart contract address associated with the blockchain for the underlying digital asset. In embodiments the second smart contract instructions are saved in the blockchain for the underlying digital asset and include: (i) first trade instructions for the security token smart contract, wherein the first trade instructions include execution instructions to execute a first trade between the first user and the second user, the first trade is based on at least the following: 1 the contract proposal; and 2 the first user response; (ii) fifth authorization instructions regarding transferring security tokens; (iii) sixth authorization instructions regarding destroying security tokens; (iv) seventh authorization instructions regarding transferring stable value tokens to the second contract address; (v) eighth authorization instructions regarding transferring stable value tokens from the second contract address; and (vi) calculating instructions regarding calculating excess collateral. In embodiments, the method continues with (f) sending, by an administrator system via the blockchain for the underlying digital asset to the second smart contract address, the security token smart contract and associated second smart contract instructions. In embodiments, the method may continue with (g) receiving, by the second contract address, a first amount of collateral. In embodiments, the first amount of collateral is a first amount of stable value tokens associated with the first user as collateral. In embodiments the first amount of stable value tokens associated with the first user is based on the at least one collateral requirement. In embodiments, the method may continue with (h) receiving, by the second contract address, a second amount of collateral. In embodiments the second amount of collateral is a second amount stable value tokens associated with the second user as collateral. In embodiments the second amount of stable value tokens associated with the second user is based on the at least one collateral requirement. In embodiments, the first trade instructions are implemented via the blockchain for the underlying digital asset by computers systems among the plurality of geographically distributed computer systems in the peer-to-peer network.

In embodiments, the first trade instructions are implemented as a result of a message sent from the administrator system via the blockchain to the second smart contract address.

In embodiments, the first user information further includes a first user public address associated with the blockchain of the underlying digital asset. In embodiments the first user public address corresponds to a first user private key that is mathematically related to the first user public address. In embodiments, the second user information further includes a second user public address associated with the blockchain of the underlying digital asset. In embodiments the second user public address corresponds to a second user private key that is mathematically related to the second user public address.

In embodiments, the step of receiving a first amount of collateral further includes sending, by the first user device via the underlying blockchain from the first user public address associated with the underlying blockchain to the first smart contract address associated with the underlying blockchain, a first message including a request to transfer the first amount of collateral from the first user public address to the second smart contract address.

In embodiments, the first user device sends a second message to the first smart contract address including authorization for the security token smart contract to request a transfer of the first amount of collateral. In embodiments, the administrator system sends a third message via the underlying blockchain to the second smart contract address with instructions to send a request from the second smart contract address to the first smart contract address for the first amount of collateral to be transferred from the first user public address to the second smart contract address. In embodiments, the step of receiving a second amount of collateral further includes sending, by the second user device via the underlying blockchain from the second user public address associated with the underlying blockchain to the first smart contract address associated with the underlying blockchain, a fourth message including a request to transfer the second amount of collateral from the second user public address to the second smart contract address. In embodiments, the second user device sends a fifth message to the first smart contract address including authorization for the security token smart contract to request a transfer of the second amount of collateral via the blockchain, and the administrator system sends a sixth message via the underlying blockchain to the second smart contract address with instructions to send a request for the second amount of collateral to be transferred from the second user public address to the second smart contract address.

In embodiments, the method further includes (i) recalculating the first collateral amount based on the at least one collateral requirement and current benchmark information; (j) determining a first additional collateral amount based on a difference between the recalculated first collateral amount and the first collateral amount; and (k) receiving, at the second smart contract address, the first additional collateral amount. In embodiments the recalculating step is performed by the first user device. In embodiments the recalculating step is performed by the administrator system, and further includes: (i) generating, by the administrator system, an alert including the first additional collateral amount; and (ii) sending, by the administrator system, to the first user device, the alert. In embodiments, the method further includes: (l) monitoring, by the administrator system, the second contract address on the blockchain associated with the underlying digital asset; (m) determining, by the administrator system, whether the first additional collateral amount is received by the second contract address; (n) generating, by the administrator system, a default notification when the administrator system determines that the first additional collateral amount is not received by the second contract address; (o) sending, by the administrator system, the default notification to the first user device, the second user device and the second smart contract address; (p) generating, by the administrator system, a seventh message including a request to transfer the first collateral amount and the second collateral amount in accordance with the first trade instructions; and (q) sending, by the administrator system, the seventh message to the second smart contract address, where transfers of the first collateral amount and the second collateral amount are implemented by the plurality of geographically distributed computer systems in the peer-to-peer network.

In embodiments, the method further includes (i) recalculating the second collateral amount based on the at least one collateral requirement and current benchmark information; (j) determining a second additional collateral amount based on a difference between the recalculated second collateral amount and the second collateral amount; and (k) receiving, at the second smart contract address, the second additional collateral amount. In embodiments, the recalculating step is performed by the second user device. In embodiments the recalculating step is performed by the administrator system, and further includes: (i) generating, by the administrator system, an alert to the second user including the second additional collateral amount; and (ii) sending, by the administrator system, to the second user device, the alert. In embodiments, the method further includes: (l) monitoring, by the administrator system, the second contract address on the blockchain associated with the underlying digital asset; (m) determining, by the administrator system, whether the second additional collateral amount is received by the second contract address; (n) generating, by the administrator system, a default notification when the administrator system determines that the second additional collateral amount is not received by the second contract address; (o) sending, by the administrator system, the default notification to the first user device, the second user device and the second smart contract address; (p) generating, by the administrator system, an eighth message including a request to transfer the first collateral amount and the second collateral amount in accordance with the first trade instructions; and (q) sending, by the administrator system, the eighth message to the second smart contract address, where transfers of the first collateral amount and the second collateral amount are implemented by the plurality of geographically distributed computer systems in the peer-to-peer network.

In embodiments, the method further includes: (i) determining, by the administrator system, at the end of the contract duration, a payout amount based on at least the first trade instructions; (j) generating, by the administrator system, payout instructions based at least on the first side information and the second side information; and (k) sending, by the administrator system, the payout instructions to the second contract address via the blockchain to provide the payout amount to one of the first user public address and the second user public address, wherein the payout instructions are implemented by the plurality of geographically distributed computer systems in the peer-to-peer network.

In embodiments, the method further includes: (i) collecting, by the administrator system from the security token, excess collateral from the first trade. In embodiments, the collecting step includes: (1) sending, by the administrator system via the blockchain for the underlying digital asset, a ninth message including first requests for the security token to: (A) determine first excess collateral for the first trade in accordance with the security token smart contract and the first trade instructions; (B) determine second excess collateral for the first trade in accordance with the security token smart contract and the first trade instructions; (C) distribute the first excess collateral for the first trade in accordance with the security token smart contract and the first trade instructions to the first user address; and (D) distribute the second excess collateral for the first trade in accordance with the security token smart contract and the first trade instructions to the second user address.

In embodiments, the method further includes: (i) returning, by the administrator system from the security token smart contract, remaining collateral from the first trade. In embodiments returning includes: (1) sending a tenth message including requests for the security token smart contract to: (A) determine first remaining collateral for the first trade in accordance with the security token smart contract and the first trade instructions; (B) determine second remaining collateral for the first trade in accordance with the security token smart contract and the first trade instructions; (C) distribute the first remaining collateral for the first trade in accordance with the security token smart contract and the first trade instructions; and (D) distribute the second remaining collateral for the first trade in accordance with the security token smart contract and the first trade instructions.

In embodiments, the method further includes: (i) determining a first benchmark value. In embodiments, determining the first benchmark value includes: (1) sending, by the security token smart contract via the blockchain for the underlying digital asset, a request from the second contract address to an oracle smart contract at a third contract address associated with the blockchain for the underlying digital asset, wherein the oracle smart contract is associated with an oracle interface in contact with an authorized third party database, wherein the message includes an eleventh message to obtain first benchmark information; (2) receiving, by the security token smart contract from the oracle smart contract, the first benchmark information; and (3) executing, by the security token in response to receiving the first benchmark information, instructions to: (A) store the first benchmark information. In embodiments, in the case where at least one of the first excess collateral is greater than zero or the second excess collateral is greater than zero, the method further includes: (j) calculating the first excess collateral for the first user and second excess collateral for the second user by using the first trade instructions and the first benchmark information; and (k) sending, from the second smart contract address to the first smart contract address, a twelfth message including a request for the stable value token smart contract to transfer: (i) the first excess collateral in stable value tokens from the second contract address to the first user public address, if the first excess collateral is greater than zero; and (ii) the second excess collateral in stable value tokens from the second contract address to the second user public address, if the second excess collateral is greater than zero.

In embodiments, the step 1(a), receiving a contract proposal, further includes: (i) generating, by the administrator system, graphical user interface information including at least one prompt for the first user to provide the contract proposal; (ii) sending, by the administrator system to the first user device, the graphical user interface information; and (iii) receiving, from the first user device in response to the at least one prompt, the contract proposal.

In embodiments, the first contract information further includes at least one of the following: (H) derivative type information; (I) early termination rules; (J) a second benchmark; (K) asset identification information; (L) pricing model information; and (M) volatility information.

In embodiments, the first contract information further includes: (H) first collateral information in stable value tokens.

In embodiments, the first contract information further includes: (H) second collateral information in stable value tokens.

In embodiments, the first contract information includes first transaction fee information.

In embodiments, the underlying digital asset is a digital math-based asset.

In embodiments, the underlying digital asset is Ether.

In embodiments, the underlying digital asset is Neo.

In embodiments, the first smart contract instructions of the first stable value smart contract are associated with more than one smart contract address.

In embodiments, a method for generating a smart contract on an underlying blockchain includes: (a) receiving, at an administrator system associated with an administrator, a contract request, the contract request including: (1) first user information associated with a first user device that is associated with a first user; and (2) a smart contract generation request; (b) generating, by the administrator system, graphical user interface information including at least one prompt for the first user to provide contract parameters related to the smart contract to be generated; (c) sending, by the administrator system, the graphical user interface information to the first user device; (d) receiving, from the first user device, in response to the at least one prompt, contract information related to the contract parameters of the contract to be generated; (e) storing, in a memory operably connected to the administrator system, the contract information; (f) publishing, by the administrator system, the contract information, wherein the contract information comprises at least the following contract parameters: (1) an inception date; (2) an inception value; (3) at least one benchmark; (4) a contract duration; (5) at least one collateral requirement; and (6) a notional value of the contract; (g) receiving, by the administrator system, a plurality of indications of interests, wherein the plurality of indications of interests include at least: (1) a first user response, from a second user device associated with a second user, the first user response comprising: (i) second user identification information associated with the second user; and (ii) first side information comprising identification of a first leg of the contract; and (2) a second user response, from a third user device associated with a third user, the second user response comprising: (i) third user identification information associated with the third user; and (ii) second side information comprising identification of a second leg of the contract, wherein the second leg information is different than the first leg information; (h) matching, by the administrator system, the first user response with the second user response; (i) providing a stable value token smart contract associated with a stable value token and first smart contract instructions associated with a first contract address associated with the blockchain for the underlying digital asset, wherein the first smart contract instructions are saved in the blockchain for the underlying digital asset and include: (1) authorization instructions related to creating stable value tokens; (2) authorization instructions related to transferring stable value tokens; (3) authorization instructions related to destroying stable value tokens; and (4) authorizing instructions related to functions associated with stable value tokens; (j) providing a security token smart contract associated with a security token and second contract instructions associated with a second smart contract address associated with the blockchain for the underlying digital asset, wherein the second smart contract instructions are saved in the blockchain for the underlying digital asset and include: (1) authorization instructions related to creating of security tokens; (2) authorization instructions related to transferring security tokens; (3) authorization instructions related to destroying security tokens; (4) authorization instructions related to accessing data supplied by a first authorized third party database; (5) authorization instructions related to transferring stable value tokens to the second contract address; (6) authorization instructions related to transferring stable value tokens from the second contract address; and (7) calculating instructions relating to calculating excess collateral; (k) setting up, by the administrator system, a first trade between the first user and the second user, the first trade using the security token smart contract with collateral in the form of stable value digital asset tokens, the step of setting up further comprising: (1) generating, by the administrator system, first trade instructions for the security token smart contract, the first trade instructions including instructions to execute the first trade between a first user public address associated with the underlying blockchain associated with the second user and a second user public address associated with the underlying blockchain associated with the third user, wherein the first trade is based at least on: (i) the contract parameters; (ii) the first user response; and (iii) the second user response; (2) generating, by the administrator system, hashed first trade instructions by applying a hash algorithm to the first trade instructions; (3) sending, by the administrator system via the underlying blockchain, a first transaction request, from an administrator public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain, wherein the first transaction request includes a first message comprising: (i) the hashed first trade instructions; and (ii) a request to assign a first trade identification to a first trade associated with the hashed first trade instructions; wherein the administrator public address associated with the underlying blockchain has a corresponding administrator private key, the administrator private key being mathematically related to the administrator public address; and wherein the first transaction request is signed by the administrator private key; (4) obtaining, by the administrator system, a first trade identification of the first trade; (5) sending, by the administrator system, the first trade identification to the first user device associated with the first user; (6) sending, by the administrator system, the first trade identification to the second user device associated with the second user; (7) sending, by the administrator system, the first trade identification to the third user device associated with the second user; (8) monitoring, by the system administrator, transactions of stable value digital asset tokens associated with the underlying blockchain to determine that the second contract address has received at least the following: (i) a first amount of collateral in stable value digital asset tokens from the second user; and (ii) a second amount of collateral in stable value digital asset tokens from the third user; (9) sending, by the administrator system via the underlying blockchain, a second transaction request, from the administrator public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain, wherein the second transaction request includes a second message comprising: (i) the first trade instructions; and (ii) the first trade identification; and wherein the second transaction is signed by the administrator private key; and (1) collecting, by the administrator system from the security token, excess collateral from the first trade, wherein collecting comprises: (1) sending, by the administrator system via the underlying blockchain, a third transaction request from the administrator public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain, the third transaction request including a third message comprising requests for the security token to: (i) determine excess collateral for the first trade in accordance with the security token smart contract and the first trade instructions; and (ii) distribute excess collateral for the first trade in accordance with the security token smart contract and the first trade instructions; and wherein the third transaction is signed by the administrator private key; (2) sending, by the security token smart contract via the underlying blockchain in response to the instructions contained in the third message, a fourth transaction request from the second contract address associated with the underlying blockchain to an oracle smart contract at a third contract address associated with the underlying blockchain, wherein the oracle smart contract is associated with an oracle interface in contact with the authorized third party database; and wherein the fourth transaction request includes a fourth message to obtain first benchmark information; (3) receiving, by the security token smart contract from the oracle smart contract, the first benchmark information; (4) executing, by the security token in response to receiving the callback message, instructions to: (i) store the first benchmark information; and (ii) calculate the first excess collateral for the second user and second excess collateral for the third user by using the first trade instructions and the first benchmark information; and (5) in the cases where at least one of the first excess collateral is greater than zero or the second excess collateral is greater than zero, sending, by the security token via the underlying blockchain, a fifth transaction request, from the second contract address associated with the underlying blockchain to the first contract address associated with the underlying blockchain, wherein the fifth transaction request includes a fifth message requesting the stable value token smart contract to transfer: (i) the first excess collateral in stable value tokens from the second contract address associated with the underlying blockchain to the second user public address associated with the underlying blockchain, if the first excess collateral is greater than zero; and (ii) the second excess collateral in stable value tokens from the second contract address associated with the underlying blockchain to the third user public address associated with the underlying blockchain, if the second excess collateral is greater than zero.

In embodiments, the contract parameters may further include at least one of: (7) derivative type information; (8) early termination rules; (9) a second benchmark; (10) asset identification information; (11) pricing model information; and (12) volatility information.

In embodiments, the first user response may further include: (iii) a first user public address associated with the underlying blockchain; and (iv) first collateral information in stable value tokens.

In embodiments, the second user response may further include: (iii) a second user public address associated with the underlying blockchain; and (iv) second collateral information in stable value token.

In embodiments, the first transaction request may include first transaction fee information.

In embodiments, obtaining the first trade identification further comprises: monitoring, by the administrator system, transactions on the underlying blockchain to determine the first trade identification as calculated by the security token smart contract.

In embodiments, the step of monitoring transactions of the stable value digital asset token on the underlying blockchain further comprises monitoring, by the administrator system, the first contract address associated with the underlying blockchain to determine: (i) the first amount of collateral is received at the second contract address associated with the underlying blockchain; and (ii) the second amount of collateral is received at the second contract address associated with the underlying blockchain.

In embodiments, the step of monitoring transactions of the stable value digital asset token on the underlying blockchain further comprises receiving, from the second contract address associated with the underlying blockchain, a collateral confirmation message confirming that: (i) the first amount of collateral has been received at the second contract address associated with the underlying blockchain; and (ii) the second amount of collateral has been received at the second contract address associated with the underlying blockchain.

In embodiments the second contract address is associated with instructions including: (8) authorization instructions related to generating a collateral confirmation message to the administrator system confirming receipt of at least one of the first amount of collateral and the second amount of collateral when at least one of the first amount of collateral and the second amount of collateral is received; and (9) authorization instructions related to sending the collateral confirmation message to the administrator system confirming receipt of at least one of the first amount of collateral and the second amount of collateral when at least one of the first amount of collateral and the second amount of collateral is received.

In embodiments, the second transaction request further includes second transaction fee information.

In embodiments, the first excess collateral is the first amount of collateral less the difference between the first benchmark information and the inception value.

In embodiments the second excess collateral is the second amount of collateral less the difference between the inception value and the first benchmark information.

In embodiments the second user public address has a corresponding second user private key which is mathematically related to the second user public address.

In embodiments the third user public address has a corresponding third user private key which is mathematically related to the third user public address.

In embodiments, prior to the step of monitoring transactions of the stable value digital asset token associated with the underlying blockchain, a sixth transaction is sent by the second user device via the underlying blockchain, from the second user public address associated with the underlying blockchain to the first contract address associated with the underlying blockchain, wherein the sixth transaction request comprises a sixth message including requests to the stable value token smart contract regarding a first transfer of the first amount of collateral; wherein the second user public address has a corresponding second user private key which is mathematically related to the second user public address; and wherein the sixth transaction request is signed by the second user private key. In embodiments, the sixth transaction request further includes third transaction fee information. In embodiments, the requests to the stable value token smart contact regarding the first transfer of the first amount of collateral include requests to the stable value smart contract to transfer the first amount of collateral in the form of stable value digital asset tokens from the second user public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain. In embodiments the requests to the stable value smart contract to transfer the first amount of collateral in the form of stable value digital asset tokens from the second user public address associated with the underlying blockchain to the second contract associated with the underlying blockchain are executed upon receipt of a first collateral request from the second contract address. In embodiments, the requests to the stable value smart contract to transfer the first amount of collateral in the form of stable value digital asset tokens from the second user public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain are executed upon receipt of a first collateral request from a fourth contract address associated with the second contract address. In embodiments the requests to the stable value smart contract to transfer the first amount of collateral in the form of stable value digital asset tokens from the second user public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain are executed upon receipt of a first collateral request from the administrator system.

In embodiments, prior to the step of monitoring transactions of the stable value digital asset token associated with the underlying blockchain, a seventh transaction is sent by the fourth user device via the underlying blockchain, from the third user public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain, wherein the seventh transaction request comprises a seventh message including requests to the stable value token smart contract regarding a second transfer of the second amount of collateral; wherein the third user public address has a corresponding third user private key which is mathematically related to the fourth user public address; and wherein the seventh transaction request is signed by the third user private key. In embodiments the seventh transaction request includes fourth transaction fee information. In embodiments the requests regarding transfer of the second amount of collateral include requests to the stable value smart contract to transfer the second amount of collateral in the form of stable value digital asset tokens from the third user public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain. In embodiments the requests regarding transfer of the second amount of collateral include requests to the stable value smart contract to transfer the second amount of collateral in the form of stable value digital asset tokens from the third user public address associated with the underlying blockchain to a fourth contract address related to the second contract address associated with the underlying blockchain. In embodiments the requests to the stable value smart contract to transfer the second amount of collateral in the form of stable value digital asset tokens from the third user public address associated with the underlying blockchain to the second contract address are executed upon receipt of a second collateral request from the second contract address associated with the underlying blockchain. In embodiments the requests to the stable value smart contract to transfer the second amount of collateral in the form of stable value digital asset tokens from the third user public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain are executed upon receipt of a second collateral request from the second administrator system.

In embodiments the step of collecting the excess collateral occurs in response to the security token smart contract verifying the first trade instructions against the hashed instructions. In embodiments the step (g) further comprises receiving: (3) a third user response, from a fourth user device associated with a fourth user, the third user response comprising: (i) third user identification information associated with the fourth user; and (ii) third side information comprising identification of the first leg of the contract; and (4) a fourth user response, from a fifth user device associated with a fifth user, the fourth user response comprising: (i) fourth user identification information associated with the fifth user; and (ii) fourth side information comprising identification of the fourth leg of the contract, wherein the fourth side information is different than the third side information. In embodiments, the matching step (h) further comprises matching the third user response with the fourth user response. In embodiments, in the event that there is no match the process may terminate and/or wait until there is a match to proceed. In embodiments the process further includes: (m) setting up, by the administrator system, a second trade between the fourth user and the fifth user, the second trade using the security token smart contract associated with the underlying blockchain with collateral in the form of stable value digital asset tokens, the step of setting up further comprising: (1) generating, by the administrator system, second trade instructions for the security token smart contract, the second trade instructions including instructions to execute the second trade between a fourth user public address associated with the underlying blockchain associated with the fourth user and a fifth user public address associated with the underlying blockchain associated with the fifth user, wherein the second trade is based at least on: (i) the contract parameters; (ii) the third user response; and (iii) the fourth user response; (2) generating, by the administrator system, hashed second trade instructions by applying the hash algorithm to the second trade instructions (3) sending, by the administrator system via the underlying blockchain, a sixth transaction request, from an administrator public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain, wherein the sixth transaction request includes a sixth message comprising: i. the hashed second trade instructions; and ii. a request to assign a second trade identification to the second trade; wherein the administrator public address associated with the underlying blockchain has a corresponding administrator private key, wherein the administrator private key being mathematically related to the administrator public address; and wherein the sixth transaction request is signed by the administrator private key; (4) obtaining, by the administrator system, the second trade identification of the second trade; (5) sending, by the administrator system, the second trade identification to the first user device associated with the first user; (6) sending, by the administrator system, the second trade identification to the fourth user device associated with the third user; (7) sending, by the administrator system, the second trade identification to the fifth user device associated with the fourth user; (8) monitoring, by the system administrator, transactions of stable value digital asset tokens associated with the underlying blockchain to determine that the second contract address has received at least the following: (i) a third amount of collateral in stable value digital asset tokens from the third user; and (ii) a fourth amount of collateral in stable value digital asset tokens from the fourth user; (9) sending, by the administrator system via the underlying blockchain, a seventh transaction request, from the administrator public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain, wherein the seventh transaction request includes a seventh message comprising: (i) the second trade instructions; and (ii) the second trade identification; and wherein the seventh transaction request is signed by the administrator private key; and (n) collecting, by the administrator system from the security token smart contract, excess collateral from the second trade, wherein collecting comprises: (1) sending, by the administrator system via the underlying blockchain, an eight transaction request from the administrator public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain, the eight transaction request including an eight message comprising requests for the security token smart contract to: (i) determine excess collateral for the second trade in accordance with the security token smart contract and the second trade instructions; and (ii) distribute excess collateral for the second trade in accordance with the security token smart contract and the second trade instructions; and wherein the eight transaction request is signed by the administrator private key; (2) sending, by the security token smart contract via the underlying blockchain in response to the instructions contained in the eight message, a ninth transaction request from the second contract address associated with the underlying blockchain to the oracle smart contract at the third contract address associated with the underlying blockchain, wherein the oracle smart contract is associated with the oracle interface in contact with the authorized third party database; and wherein the ninth transaction request includes a ninth message to obtain second benchmark information; (3) receiving, by the security token smart contract from the oracle interface, the second benchmark information; (4) executing, by the security token smart contract in response to receiving the callback message, instructions to: (i) store the second benchmark information; and (ii) calculate the third excess collateral for the fourth user and fourth excess collateral for the fifth user by using the second trade instructions and the second benchmark information; and (5) in the cases where at least one of the third excess collateral is greater than zero or the second excess collateral is greater than zero, sending, by the security token smart contract via the underlying blockchain, a tenth transaction request, from the second contract address associated with the underlying blockchain to the fourth contract address associated with the underlying blockchain, wherein the tenth transaction request includes an eleventh message requesting the stable value token smart contract to transfer: (i) the third excess collateral in stable value tokens from the second contract address associated with the underlying blockchain to the fourth user public address associated with the underlying blockchain, if the third excess collateral is greater than zero; and (ii) the fourth excess collateral in stable value tokens from the second contract address associated with the underlying blockchain to the fifth user public address associated with the underlying blockchain, if the fourth excess collateral is greater than zero.

In embodiments the fourth message further comprises the second contract address and the oracle smart contract only provides the first benchmark information to the second contract address when the second contract address is included in a list of approved contract addresses.

In embodiments the list of approved contract addresses may be modified periodically.

In embodiments the list of approved contract addresses may be modified aperiodically.

In embodiments, a method for generating a smart contract on an underlying blockchain includes: (a) receiving, at an administrator system associated with an administrator, a contract request, the contract request including: (1) first user information associated with a first user device that is associated with a first user; (2) second user information associated with a second user device that is associated with a second user; and (3) a request to generate the smart contract; (b) generating, by the administrator system, graphical user interface information including at least one prompt for the first user to provide contract parameters related to the smart contract to be generated; (c) sending, by the administrator system, the graphical user interface information to the first user device and the second user device; (d) receiving, from at least one of the first user device and the second user device, contract information related to contract parameters of the smart contract to be generated; (e) storing, in a memory operably connected to the administrator system, the contract information; (f) publishing, by the administrator system, the contract information, wherein the contract information comprises at least the following contract parameters: (1) an inception date; (2) an inception value; (3) at least one benchmark; (4) a contract duration; (5) at least one collateral requirement; (6) a notional value of the contract; (7) first leg information associated with the first user; and (8) second leg information associated with the second user; (g) providing a stable value token smart contract associated with a stable value token and first smart contract instructions associated with a first contract address associated with the blockchain for the underlying digital asset, wherein the first smart contract instructions are saved in the blockchain for the underlying digital asset and include: (1) authorization instructions related to creating stable value tokens; (2) authorization instructions related to transferring stable value tokens; (3) authorization instructions related to destroying stable value tokens; and (4) authorizing instructions related to functions associated with stable value tokens; (h) providing a security token smart contract associated with a security token and second contract instructions associated with a second smart contract address associated with the blockchain for the underlying digital asset, wherein the second smart contract instructions are saved in the blockchain for the underlying digital asset and include: (1) authorization instructions related to creating security tokens; (2) authorization instructions related to transferring security tokens; (3) authorization instructions related to destroying security tokens; (4) authorization instructions related to accessing data supplied by a first authorized third party database; (5) authorization instructions related to transferring stable value tokens to the second contract address; (6) authorization instructions related to transferring stable value tokens from the second contract address; and (7) calculating instructions relating to calculating excess collateral; (i) setting up, by the administrator system, a first trade between the first user and the second user, the first trade using the security token smart contract associated with the underlying blockchain with collateral in the form of stable value digital asset tokens, the step of setting up further comprising: (1) generating, by the administrator system, first trade instructions for the security token smart contract, the first trade instructions including instructions to execute the first trade between a first user public address associated with the underlying blockchain associated with the first user and a second user public address associated with the underlying blockchain associated with the second user, wherein the first trade is based at least on the contract parameters; (2) sending, by the administrator system via the underlying blockchain, a first transaction request, from an administrator public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain, wherein the first transaction request includes a first message comprising a request to assign a first trade identification to a first trade; wherein the administrator public address associated with the underlying blockchain has a corresponding administrator private key, wherein the administrator private key being mathematically related to the administrator public address; and wherein the first transaction request is signed by the administrator private key; (3) obtaining, by the administrator system, the first trade identification of the first trade; (4) sending, by the administrator system, the first trade identification to the first user device associated with the first user; (5) sending, by the administrator system, the first trade identification to the second user device associated with the second user; (6) monitoring, by the administrator system, transactions of stable value digital asset tokens on the underlying blockchain to determine that the second contract address has received at least the following: (i) a first amount of collateral in stable value digital asset tokens from the first user; and (ii) a second amount of collateral in stable value digital asset tokens from the second user; (8) sending, by the administrator system via the underlying blockchain, a second transaction request, from the administrator public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain, wherein the second transaction request includes a second message comprising: (i) the first trade instructions; and (ii) the first trade identification; and wherein the second transaction is signed by the administrator private key; and (j) collecting, by the administrator system from the security token smart contract, excess collateral from the first trade, wherein collecting comprises: (1) sending, by the administrator system via the underlying blockchain, a third transaction request from the administrator public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain, the third transaction request including a third message comprising requests for the security token smart contract to: (i) determine excess collateral for the first trade in accordance with the security token smart contract and the first trade instructions; and (ii) distribute excess collateral for the first trade in accordance with the security token smart contract and the first trade instructions; and wherein the third transaction is signed by the administrator private key; (2) sending, by the security token smart contract via the underlying blockchain in response to the instructions contained in the third message, a fourth transaction request from the second contract address associated with the underlying blockchain to an oracle smart contract associated with a third contract address associated with the underlying blockchain to retrieve first benchmark information, wherein the oracle smart contract is associated with an oracle interface in contact with the authorized third party database; and wherein the fourth transaction request includes a fourth message to obtain first benchmark information; (3) receiving, by the security token smart contract from the oracle smart contract, the first benchmark information; (4) executing, by the security token smart contract in response to receipt of the first benchmark information, instructions to: (i) store the first benchmark information; and (ii) calculate the first excess collateral for the first user and second excess collateral for the second user by using the first trade instructions and the first benchmark information; and (5) in the case where at least one of the first excess collateral is greater than zero or the second excess collateral is greater than zero, sending, by the security token smart contract via the underlying blockchain, a fifth transaction request, from the second contract address associated with the underlying blockchain to the first contract address associated with the underlying blockchain, wherein the fifth transaction request including a fifth message requesting the stable value token smart contract to transfer: (i) the first excess collateral in stable value tokens from the second contract address associated with the underlying blockchain to the first user public address associated with the underlying blockchain, if the first excess collateral is greater than zero; and (ii) the second excess collateral in stable value tokens from the second contract address associated with the underlying blockchain to the second user public address associated with the underlying blockchain, if the second excess collateral is greater than zero.

In embodiments the contract parameters further comprise at least one of: (7) derivative type information; (8) early termination rules; (9) a second benchmark; (10) asset identification information; (11) pricing model information; and (12) volatility information.

In embodiments, the first user response further comprises: (iii) a first user public address associated with the underlying blockchain; and (iv) first collateral information in stable value tokens.

In embodiments, the second user response further comprises: (iii) a second user public address associated with the underlying blockchain; and (iv) second collateral information in stable value token.

In embodiments, the first transaction request further includes first transaction fee information. In embodiments obtaining the first trade identification further comprises: (i) monitoring, by the administrator system, transactions on the underlying blockchain to determine the first trade identification as calculated by the security token smart contract.

In embodiments the step of monitoring transactions of the stable value digital asset token on the underlying blockchain further comprises receiving, from the second contract address associated with the underlying blockchain, a collateral confirmation message confirming that: (i) the first amount of collateral has been received at the second contract address associated with the underlying blockchain; and (ii) the second amount of collateral has been received at the second contract address associated with the underlying blockchain.

In embodiments, the second transaction request further includes second transaction fee information.

In embodiments the first excess collateral is the first amount of collateral less the difference between the first benchmark information and the inception value.

In embodiments, the second excess collateral is the second amount of collateral less the difference between the inception value and the first benchmark information.

In embodiments the first user public address has a corresponding first user private key which is mathematically related to the first user public address.

In embodiments the second user public address has a corresponding second user private key which is mathematically related to the second user public address.

In embodiments, prior to the step of monitoring transactions of the stable value digital asset token associated with the underlying blockchain, a sixth transaction is sent by the second user device via the underlying blockchain, from the second user public address associated with the underlying blockchain to the first contract address associated with the underlying blockchain, wherein the sixth transaction request comprises a sixth message including requests to the stable value token smart contract regarding a first transfer of the first amount of collateral; wherein the second user public address has a corresponding second user private key which is mathematically related to the second user public address; and wherein the sixth transaction request is signed by the second user private key. In embodiments the sixth transaction request further includes third transaction fee information. In embodiments, the requests to the stable value token smart contact regarding the first transfer of the first amount of collateral include requests to the stable value smart contract to transfer the first amount of collateral in the form of stable value digital asset tokens from the first user public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain. In embodiments the requests to the stable value smart contract to transfer the first amount of collateral in the form of stable value digital asset tokens from the second user public address associated with the underlying blockchain to the third user public address associated with the underlying blockchain are executed upon receipt of a first collateral request from the second contract address. In embodiments, the requests to the stable value smart contract to transfer the first amount of collateral in the form of stable value digital asset tokens from the second user public address associated with the underlying blockchain to the third user public address associated with the underlying blockchain are executed upon receipt of a first collateral request from a fourth contract address associated with the second contract address. In embodiments, the requests to the stable value smart contract to transfer the first amount of collateral in the form of stable value digital asset tokens from the second user public address associated with the underlying blockchain to the third user public address associated with the underlying blockchain are executed upon receipt of a first collateral request from the administrator system.

In embodiments, prior to the step of monitoring transactions of the stable value digital asset token associated with the underlying blockchain, a seventh transaction is sent by the third user device via the underlying blockchain, from the second user public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain, wherein the seventh transaction request comprises a seventh message including requests to the stable value token smart contract regarding a second transfer of the second amount of collateral; wherein the third user public address has a corresponding third user private key which is mathematically related to the third user public address; and wherein the seventh transaction request is signed by the third user private key. In embodiments the seventh transaction request includes fourth transaction fee information. In embodiments, the requests regarding transfer of the second amount of collateral include requests to the stable value smart contract to transfer the second amount of collateral in the form of stable value digital asset tokens from the third user public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain. In embodiments the requests regarding transfer of the second amount of collateral include requests to the stable value smart contract to transfer the second amount of collateral in the form of stable value digital asset tokens from the third user public address associated with the underlying blockchain to a fourth contract address related to the second contract address associated with the underlying blockchain. In embodiments the requests to the stable value smart contract to transfer the second amount of collateral in the form of stable value digital asset tokens from the third user public address associated with the underlying blockchain to the second contract address are executed upon receipt of a second collateral request from the second contract address associated with the underlying blockchain. In embodiments, the requests to the stable value smart contract to transfer the second amount of collateral in the form of stable value digital asset tokens from the third user public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain are executed upon receipt of a second collateral request from the second administrator system. In embodiments, the step of collecting the excess collateral occurs in response to the security token smart contract verifying the first trade instructions against the hashed instructions.

In embodiments, the fourth message further comprises the second contract address and the oracle smart contract only provides the first benchmark information to second contract address when the second contract address is included in a list of approved contract addresses.

In embodiments the list of approved contract addresses may be modified periodically.

In embodiments the list of approved contract addresses may be modified aperiodically.

In embodiments, a method for generating a smart contract on an underlying blockchain includes: (a) receiving, at an administrator system associated with an administrator, a contract request, the contract request including: (1) first user information associated with a first user device that is associated with a first user; and (2) a request to generate a contract; (b) generating, by the administrator system, graphical user interface information including at least one prompt for the first user to provide contract parameters related to the smart contract to be generated; (c) sending, by the administrator system, the graphical user interface information to the first user device; (d) receiving, from the first user device, in response to the at least one prompt, contract information related to the contract parameter of the contract to be generated; (e) storing, in a memory operably connected to the administrator system, the contract information; (f) publishing, by the administrator system, the contract information, wherein the contract information comprises at least the following contract parameters: (1) an inception date; (2) an inception value; (3) at least one benchmark; (4) a contract duration; (5) at least one collateral requirement; (6) a notional value of the contract; and (7) first leg information associated with the first user; (g) receiving, by the administrator system, at least one indication of interest, the at least one indication of interests including at least: (1) a first user response, from a second user device associated with a second user, the second user response comprising: (i) second user identification information associated with the second user; and (ii) second leg information associated with the second user, wherein the second leg information is different from the first leg information; (h) matching, by the administrator system, the first user response with the contract request of the first user based at least on the first leg information and the second leg information; (i) providing a stable value token smart contract associated with a stable value token and first smart contract instructions associated with a first contract address associated with the blockchain for the underlying digital asset, wherein the first smart contract instructions are saved in the blockchain for the underlying digital asset and include: (1) authorization instructions related to creating stable value tokens; (2) authorization instructions related to transferring stable value tokens; (3) authorization instructions related to destroying stable value tokens; and (4) authorizing instructions related to functions associated with stable value tokens; (j) providing a security token smart contract associated with a security token and second contract instructions associated with a second smart contract address associated with the blockchain for the underlying digital asset, wherein the second smart contract instructions are saved in the blockchain for the underlying digital asset and include: (1) authorization instructions related to creating security tokens; (2) authorization instructions related to transferring security tokens; (3) authorization instructions related to destroying security tokens; (4) authorization instructions related to accessing data supplied by a first authorized third party database; (5) authorization instructions related to transferring stable value tokens to the second contract address; (6) authorization instructions related to transferring stable value tokens from the second contract address; and (7) calculating instructions relating to calculating excess collateral; (k) setting up, by the administrator system, a first trade between the first user and the second user, the first trade using the security token smart contract associated with the underlying blockchain with collateral in the form of stable value digital asset tokens, the step of setting up further comprising: (1) generating, by the administrator system, first trade instructions for the security token smart contract, the first trade instructions including instructions to execute the first trade between a first user public address associated with the underlying blockchain associated with the first user and a second user public address associated with the underlying blockchain associated with the second user, wherein the first trade is based at least on the contract parameters and the first user request; (2) generating, by the administrator system, hashed first trade instructions by applying a hash algorithm to the first trade instructions; (3) sending, by the administrator system via the underlying blockchain, a first transaction request, from an administrator public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain, wherein the first transaction request includes a first message comprising: (i) the hashed first trade instructions; and (ii) a request to assign a first trade identification to a first trade associated with the hashed trade instructions; wherein the administrator public address associated with the underlying blockchain has a corresponding administrator private key, wherein the administrator private key being mathematically related to the administrator public address; and wherein the first transaction request is signed by the administrator private key; (3) obtaining, by the administrator system, the first trade identification of the first trade; (4) sending, by the administrator system, the first trade identification to the first user device; (5) sending, by the administrator system, the first trade identification to the second user device; (6) monitoring, by the system administrator, transactions of stable value digital asset tokens on the underlying blockchain to determine that the second contract address has received at least the following: (i) a first amount of collateral in stable value digital asset tokens from the first user; and (ii) a second amount of collateral in stable value digital asset tokens from the second user; (7) sending, by the administrator system via the underlying blockchain, a second transaction request, from the administrator public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain, wherein the second transaction request includes a second message comprising: (i) the first trade instructions; and (ii) the first trade identification; and wherein the second transaction is signed by the administrator private key; and (1) collecting, by the administrator system from the security token smart contract, excess collateral from the first trade, wherein collecting comprises: (1) sending, by the administrator system via the underlying blockchain, a third transaction request from the administrator public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain, the third transaction request including a third message comprising requests for the security token smart contract to: (i) determine excess collateral for the first trade in accordance with the security token smart contract and the first trade instructions; and (ii) distribute excess collateral for the first trade in accordance with the security token smart contract and the first trade instructions; and wherein the third transaction is signed by the administrator private key; (2) sending, by the security token smart contract via the underlying blockchain in response to the instructions contained in the third message, a fourth transaction request from the second contract address associated with the underlying blockchain to an oracle smart contract associated with a third contract address associated with the underlying blockchain, wherein the oracle smart contract is associated with an oracle interface in contact with the authorized third party database; and wherein the fourth transaction request includes a sixth message to obtain first benchmark information; (3) receiving, by the security token smart contract from the oracle interface, the first benchmark information; (4) executing, by the security token smart contract in response to receiving the first benchmark information, instructions to: (i) store the first benchmark information; and (ii) calculate the first excess collateral for the first user and second excess collateral for the second user by using the first trade instructions and the first benchmark information; and (5) in the cases where at least one of the first excess collateral is greater than zero or the second excess collateral is greater than zero, sending, by the security token smart contract via the underlying blockchain, a fifth transaction request, from the second contract address associated with the underlying blockchain to the first contract address associated with the underlying blockchain, wherein the fifth transaction request includes a fifth message requesting the stable value token smart contract to transfer: (i) the first excess collateral in stable value tokens from the second contract address associated with the underlying blockchain to the first user public address associated with the underlying blockchain, if the first excess collateral is greater than zero; and (ii) the second excess collateral in stable value tokens from the second contract address associated with the underlying blockchain to the second user public address associated with the underlying blockchain, if the second excess collateral is greater than zero.

In embodiments the first user response further comprises: (iii) a first user public address associated with the underlying blockchain; and (iv) first collateral information in stable value tokens.

In embodiments the second user response further comprises: (iii) a second user public address associated with the underlying blockchain; and (iv) second collateral information in stable value token.

In embodiments the first transaction request further includes first transaction fee information.

In embodiments obtaining the first trade identification further comprises: (i) monitoring, by the administrator system, transactions on the underlying blockchain to determine the first trade identification as calculated by the security token smart contract.

In embodiments the step of monitoring transactions of the stable value digital asset token on the underlying blockchain further comprises monitoring, by the administrator system, the first contract address associated with the underlying blockchain to determine: (i) the first amount of collateral is received at the second contract address associated with the underlying blockchain; and (ii) the second amount of collateral is received at the second contract address associated with the underlying blockchain.

In embodiments the second transaction request further includes second transaction fee information.

In embodiments the first excess collateral is the first amount of collateral less the difference between the first benchmark information and the inception value.

In embodiments the second excess collateral is the second amount of collateral less the difference between the inception value and the first benchmark information.

In embodiments, the first user public address has a corresponding first user private key which is mathematically related to the first user public address.

In embodiments the second user public address has a corresponding second user private key which is mathematically related to the second user public address.

In embodiments, prior to the step of monitoring transactions of the stable value digital asset token associated with the underlying blockchain, a sixth transaction is sent by the second user device via the underlying blockchain, from the second user public address associated with the underlying blockchain to the first contract address associated with the underlying blockchain, wherein the sixth transaction request comprises a sixth message including requests to the stable value token smart contract regarding a first transfer of the first amount of collateral; wherein the second user public address has a corresponding second user private key which is mathematically related to the second user public address; and wherein the sixth transaction request is signed by the second user private key. In embodiments the sixth transaction request further includes third transaction fee information. In embodiments the requests to the stable value token smart contact regarding the first transfer of the first amount of collateral include requests to the stable value smart contract to transfer the first amount of collateral in the form of stable value digital asset tokens from the first user public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain. In embodiments the requests to the stable value smart contract to transfer the first amount of collateral in the form of stable value digital asset tokens from the second user public address associated with the underlying blockchain to the third user public address associated with the underlying blockchain are executed upon receipt of a first collateral request from the second contract address. In embodiments the requests to the stable value smart contract to transfer the first amount of collateral in the form of stable value digital asset tokens from the second user public address associated with the underlying blockchain to the third user public address associated with the underlying blockchain are executed upon receipt of a first collateral request from a fourth contract address associated with the second contract address. In embodiments the requests to the stable value smart contract to transfer the first amount of collateral in the form of stable value digital asset tokens from the second user public address associated with the underlying blockchain to the third user public address associated with the underlying blockchain are executed upon receipt of a first collateral request from the administrator system.

In embodiments, prior to the step of monitoring transactions of the stable value digital asset token associated with the underlying blockchain, a seventh transaction is sent by the third user device via the underlying blockchain, from the second user public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain, wherein the seventh transaction request comprises a seventh message including requests to the stable value token smart contract regarding a second transfer of the second amount of collateral; wherein the third user public address has a corresponding third user private key which is mathematically related to the third user public address; and wherein the seventh transaction request is signed by the third user private key. In embodiments the seventh transaction request includes fourth transaction fee information. In embodiments the requests regarding transfer of the second amount of collateral include requests to the stable value smart contract to transfer the second amount of collateral in the form of stable value digital asset tokens from the third user public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain. In embodiments the requests regarding transfer of the second amount of collateral include requests to the stable value smart contract to transfer the second amount of collateral in the form of stable value digital asset tokens from the third user public address associated with the underlying blockchain to a fourth contract address related to the second contract address associated with the underlying blockchain. In embodiments the requests to the stable value smart contract to transfer the second amount of collateral in the form of stable value digital asset tokens from the third user public address associated with the underlying blockchain to the second contract address are executed upon receipt of a second collateral request from the second contract address associated with the underlying blockchain. In embodiments the requests to the stable value smart contract to transfer the second amount of collateral in the form of stable value digital asset tokens from the third user public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain are executed upon receipt of a second collateral request from the second administrator system. In embodiments the step of collecting the excess collateral occurs in response to the security token smart contract verifying the first trade instructions against the hashed instructions.

In embodiments the fourth message further comprises the second contract address and the oracle smart contract only provides the first benchmark information to second contract address when the second contract address is included in a list of approved contract addresses.

In embodiments the list of approved contract addresses may be modified periodically.

In embodiments the list of approved contract addresses may be modified aperiodically.

A method for holding collateral in a smart contract on an underlying blockchain may include: (a) publishing, by an administrator system associated with an administrator, contract information comprising at least the following contract parameters: (1) an inception date; (2) an inception value; (3) at least one benchmark; (4) a contract duration; (5) at least one collateral requirement; and (6) a notional value of the contract; (b) receiving, by the administrator system, a plurality of indications of interests, wherein the plurality of indications of interests include at least: (1) a first user response, from a first user device associated with a first user, the first user response comprising: (i) first user identification information associated with the first user; and (ii) first side information comprising identification of a first leg of the contract; and (2) a second user response, from a second user device associated with a second user, the second user response comprising: (i) second user identification information associated with the second user; and (ii) second side information comprising identification of a second leg of the contract wherein the second leg is different than the first leg; (c) matching, by the administrator system, the first user response with the second user response; (d) providing a stable value token smart contract associated with a stable value token and first smart contract instructions associated with a first contract address associated with the blockchain for the underlying digital asset, wherein the first smart contract instructions are saved in the blockchain for the underlying digital asset and include: (1) authorization instructions related to creating stable value tokens; (2) authorization instructions related to transferring stable value tokens; (3) authorization instructions related to destroying stable value tokens; and (4) authorizing instructions related to functions associated with stable value tokens; (e) providing a security token smart contract associated with a security token and second contract instructions associated with a second smart contract address associated with the blockchain for the underlying digital asset, wherein the second smart contract instructions are saved in the blockchain for the underlying digital asset and include: (1) authorization instructions related to creating security tokens; (2) authorization instructions related to transferring security tokens; (3) authorization instructions related to destroying security tokens; (4) authorization instructions related to accessing data supplied by a first authorized third party database; (5) authorization instructions related to transferring stable value tokens to the second contract address; (6) authorization instructions related to transferring stable value tokens from the second contract address; and (7) calculating instructions relating to calculating excess collateral; (f) setting up, by the administrator system, a first trade between the first user and the second user, the first trade using the security token smart contract associated with the underlying blockchain with collateral in the form of stable value digital asset tokens, the step of setting up further comprising: (1) generating, by the administrator system, first trade instructions for the security token smart contract, the first trade instructions including instructions to execute the first trade between a first user public address associated with the underlying blockchain associated with the first user and a second user public address associated with the underlying blockchain associated with the second user, wherein the first trade is based at least on: (i) the contract terms; (ii) the first user response; and (iii) the second user response; (2) generating, by the administrator system, hashed trade instructions by applying a hash algorithm to the first trade instructions; (3) sending, by the administrator system via the underlying blockchain, a first transaction request, from an administrator public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain, wherein the first transaction request includes a first message comprising: (i) the hashed trade instructions; and (ii) request to assign a first trade identification to a first trade associated with the hashed trade instructions; wherein the administrator public address on the underlying blockchain has a corresponding administrator private key, wherein the administrator private key being mathematically related to the administrator public address; and wherein the first transaction request is signed by the administrator private key; (4) obtaining, by the administrator system, the first trade identification of the first trade; (5) sending, by the administrator system, the first trade identification to the first user device associated with the first user; (6) sending, by the administrator system, the first trade identification to the second user device associated with the second user; (7) monitoring, by the system administrator, transactions of stable value digital asset tokens on the underlying blockchain to determine that the second contract address has received at least the following: (i) a first amount of collateral in stable value digital asset tokens from the first user; and (ii) a second amount of collateral in stable value digital asset tokens from the second user; (8) sending, by the administrator system via the underlying blockchain, a second transaction request, from the administrator public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain, wherein the second transaction request includes a second message comprising: (i) the first trade instructions; and (ii) the first trade identification; and wherein the second transaction is signed by the administrator private key; and (g) collecting, by the administrator system from the security token smart contract, excess collateral from the first trade, wherein collecting comprises: (1) sending, by the administrator system via the underlying blockchain, a third transaction request from the administrator public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain, the third transaction request including a third message comprising requests for the security token smart contract to: (i) determine excess collateral for the first trade in accordance with the security token smart contract and the first trade instructions; and (ii) distribute excess collateral for the first trade in accordance with the security token smart contract and the first trade instructions; and wherein the third transaction is signed by the administrator private key; (2) sending, by the security token smart contract via the underlying blockchain in response to the instructions contained in the third message, a fourth transaction request from the second contract address associated with the underlying blockchain to an oracle smart contract associated with a third contract address associated with the underlying blockchain, wherein the oracle smart contract is associated with an oracle interface in contact with the authorized third party; and wherein the fourth transaction request includes a sixth message to obtain first benchmark data; (3) receiving, by the security token smart contract from the oracle smart contract, the first benchmark information; (4) executing, by the security token smart contract in response to receiving the callback message, instructions to: (i) store the first benchmark information; and (ii) calculate the first excess collateral for the first user and second excess collateral for the second user by using the first trade instructions and the first benchmark information; and (5) in the cases where at least one of the first excess collateral is greater than zero or the second excess collateral is greater than zero, sending, by the security token smart contract via the underlying blockchain, a fifth transaction request, from the second contract address associated with the underlying blockchain to the first contract address associated with the underlying blockchain, wherein the fifth transaction request including a fifth message requesting the stable value token smart contract to transfer: (i) the first excess collateral in stable value tokens from the second contract address associated with the underlying blockchain to the first user public address associated with the underlying blockchain, if the first excess collateral is greater than zero; and (ii) the second excess collateral in stable value tokens from the second contract address associated with the underlying blockchain to the second user public address associated with the underlying blockchain, if the second excess collateral is greater than zero.

In embodiments the contract parameters further comprise at least one of: (7) early termination rules; and (8) a second benchmark.

In embodiments the first user response further comprises: (iii) a first user public address on the underlying blockchain; and (iv) first collateral information in stable value tokens.

In embodiments the second user response further comprises: (iii) a second user public address on the underlying blockchain; and (iv) second collateral information in stable value token.

In embodiments the first transaction request further includes first transaction fee information.

In embodiments, obtaining the first trade identification further comprises: (i) monitoring, by the administrator system, transactions on the underlying blockchain to determine the first trade identification as calculated by the security token smart contract. In embodiments the step of monitoring transactions of the stable value digital asset token on the underlying blockchain further comprises monitoring, by the administrator system, the first contract address on the underlying blockchain to determine: (i) the first amount of collateral is received at the second contract address associated with the underlying blockchain; and (ii) the second amount of collateral is received at the second contract address associated with the underlying blockchain. In embodiments the step of monitoring transactions of the stable value digital asset token on the underlying blockchain further comprises receiving, from the second contract address associated with the underlying blockchain, a collateral confirmation message confirming that: (i) the first amount of collateral has been received at the second contract address associated with the underlying blockchain; and (ii) the second amount of collateral has been received at the second contract address associated with the underlying blockchain. In embodiments the second contract instructions include: (8) authorization instructions that relate to generating a collateral confirmation message to the administrator system confirming receipt of at least one of the first amount of collateral and the second amount of collateral when at least one of the first amount of collateral and the second amount of collateral is received; and (9) authorization instructions that relate to sending the collateral confirmation message to the administrator system confirming receipt of at least one of the first amount of collateral and the second amount of collateral when at least one of the first amount of collateral and the second amount of collateral is received.

In embodiments the second transaction request further includes second transaction fee information.

In embodiments the first excess collateral is the first amount of collateral less the difference between the first benchmark information and the inception value.

In embodiments the second excess collateral is the second amount of collateral less the difference between the inception value and the first benchmark information.

In embodiments the first user public address has a corresponding first user private key which is mathematically related to the first user public address.

In embodiments the second user public address has a corresponding second user private key which is mathematically related to the second user public address.

In embodiments, prior to the step of monitoring transactions of the stable value digital asset token on the underlying blockchain, a sixth transaction request is sent by the first user device via the underlying blockchain, from the first user public address associated with the underlying blockchain to the first contact address associated with the underlying blockchain, wherein the sixth transaction request comprises a sixth message including requests to the stable value token smart contract regarding a first transfer of the first amount of collateral; wherein the first user public address has a corresponding first user private key which is mathematically related to the first user public address; and wherein the sixth transaction request is signed by the first user private key. In embodiments the sixth transaction request further includes third transaction fee information. In embodiments the requests to the stable value token smart contact regarding the first transfer of the first amount of collateral include requests to the stable value smart contract to transfer the first amount of collateral in the form of stable value digital asset tokens from the first user public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain. In embodiments the requests to the stable value token smart contact regarding the first transfer of the first amount of collateral include requests to the a second contract address associated with the stable value smart contract to transfer the first amount of collateral in the form of stable value digital asset tokens from the first user public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain. In embodiments the requests to the stable value smart contract to transfer the first amount of collateral in the form of stable value digital asset tokens from the first user public address associated with the underlying blockchain to the second user public address associated with the underlying blockchain are executed upon receipt of a first collateral request from the second contract address. In embodiments the requests to the stable value smart contract to transfer the first amount of collateral in the form of stable value digital asset tokens from the first user public address associated with the underlying blockchain to the second user public address associated with the underlying blockchain are executed upon receipt of a first collateral request from a third contract address associated with the second contract address. In embodiments the requests to the stable value smart contract to transfer the first amount of collateral in the form of stable value digital asset tokens from the first user public address associated with the underlying blockchain to the second user public address associate with the underlying blockchain are executed upon receipt of a first collateral request from the administrator system.

In embodiments, prior to the step of monitoring transactions of the stable value digital asset token on the underlying blockchain, a seventh transaction is sent by the second user device via the underlying blockchain, from the second user public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain, wherein the seventh transaction request comprises a seventh message including requests to the stable value token smart contract regarding a second transfer of the second amount of collateral; wherein the second user public address has a corresponding second user private key which is mathematically related to the second user public address; and wherein the seventh transaction request is signed by the second user private key. In embodiments the seventh transaction request includes fourth transaction fee information. In embodiments the requests regarding transfer of the second amount of collateral include requests to the stable value smart contract to transfer the second amount of collateral in the form of stable value digital asset tokens from the second user public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain. In embodiments the requests to the stable value smart contract to transfer the second amount of collateral in the form of stable value digital asset tokens from the second user public address associated with the underlying blockchain to the second contract address are executed upon receipt of a second collateral request from the second contract address associated with the underlying blockchain. In embodiments the requests to the stable value smart contract to transfer the second amount of collateral in the form of stable value digital asset tokens from the second user public address associated with the underlying blockchain to the second contract address are executed upon receipt of a second collateral request from a third contract address associated with the second contract address associated with the underlying blockchain. In embodiments the requests to the stable value smart contract to transfer the second amount of collateral in the form of stable value digital asset tokens from the second user public address associated with the underlying blockchain to the second contract address associated with the underlying blockchain are executed upon receipt of a second collateral request from the second administrator system.

In embodiments the step of collecting the excess collateral occurs in response to the security token smart contract verifying the first trade instructions against the hashed instructions.

In embodiments the list of approved contract addresses may be modified periodically.

In embodiments the list of approved contract addresses may be modified aperiodically.

FIG. 95A is a flow chart illustrating a process for holding collateral for a security token in the form of a stable value token in a smart contract on an underlying blockchain in accordance with exemplary embodiments of the present invention. The process of FIG. 95A may optionally start with step S9502. At step S9502, an administrator system (e.g. administrator system 6801) may generate and send machine readable instructions including graphical user interface (GUI) information. In embodiments, the GUI information may include a GUI with at least one prompt for a user to provide a contract proposal. The machine readable instructions may be sent, in embodiments, from the administrator system 6801 to a first user device (e.g. user device 105a) associated with a first user via a network (e.g. network 15). In embodiments, the machine readable instructions may be sent in response to receiving log-in credentials that have been verified by the administrator system 6801. Upon receipt of the machine readable instructions, in embodiments, the first user device may display the GUI on a display screen of the first user device. In embodiments, step S9502 may be similar to steps S7304 and S7306 described above in connection with FIG. 73, the descriptions of which applying herein.

The process of FIG. 95A may continue with step S9504. At step S9504, the administrator system 6801 may receive a contract proposal via network 15. The contract proposal, in embodiments, may include first user information associated with the first user and first contract information. The first user information, in embodiments, may include one or more of the following: (1) a public address associated with the first user (e.g. a first user public address); (2) a public key associated with the first user (e.g. a first user public key), the first user public key, in embodiments, being mathematically related to the first user public address; (3) a private key associated with the first user (e.g. a first user private key), the first user private key, in embodiments, being mathematically related to the first user public key; and/or (4) whitelist information associated with the first user, to name a few.

In embodiments, the contract proposal may include one or more contract parameters of contract parameters database 6801B. In embodiments, the contract proposal may include one or more of the following parameters: (1) inception date data 6902; (2) inception value data 6904; (3) benchmark data 6906; (4) contract duration data 6908; (5) collateral requirements data 6910; and (6) notional value data 6912; (7) a trusted oracle selection 6917 (e.g. oracle 6811); (8) an oracle address (e.g. oracle public address 6813); (9) an oracle collateral requirement; and/or (10) an oracle fee, to name a few. A trusted oracle selection 6917 may be one or more oracles that the first user would like to use for their contract proposal. An oracle address may be one or more public addresses associated with the one or more trusted oracle selections 6917. The oracle collateral requirement, in embodiments, may be an amount of stable value tokens which the oracle deposits into a contract—the amount of which may be lost by the oracle if the oracle is found to be giving unreliable information (e.g. unreliable benchmark information). An oracle fee, in embodiments, may refer to the amount the oracle 6811 is paid to provide reliable information. Step S9504 may be similar to step S7308, described above in connection with FIG. 73, the description of which applying herein.

After receiving the contract proposal from the first user device, in embodiments, the administrator system may publish the received contract proposal, which may be similar to the published contracts described above in connection with FIGS. 70A-70F and FIGS. 71A-71B, the descriptions of which applying herein. In embodiments, the contract proposal may also be transmitted by the administrator system 6801 to the one or more selected oracles of trusted oracle selection 6917. In embodiments, a published contract may include instructions for contacting an oracle. An oracle, in embodiments, may be associated with an oracle address. The oracle, in embodiments, may be in contact and/or operatively connected with a trusted third party database a digital asset exchange computer system, and/or the administrator system 6801. In embodiments, the oracle associated with the published contract may be required to meet the aforementioned one or more collateral requirements. The oracle collateral requirement(s) may be based on one or more of the following: (1) a percentage of the collateral requirement 7112; (2) a percentage of the notional value 7114; (3) a percentage of the inception value 7106; (4) the type of smart contract (e.g. if the contract is a highly volatile contract, the collateral may increase); (5) a predetermined value; (6) a predetermined value based on the contract duration 7110; and/or (7) a combination thereof, to name a few.

In embodiments where the at least one collateral requirement requires an oracle to provide collateral, the calculation of the oracle collateral may be performed by one or more of the following: (1) the oracle; (2) the administrator system 6801; (3) a third party; and/or (4) one or more parties associated with the published contract (e.g. the first user, the second user, to name a few), to name few. In embodiments, the administrator system 6801 may calculate the oracle collateral requirement and send it to the oracle address. In embodiments, the administrator system 6801 may receive the oracle collateral requirement at a public address associated with the administrator system 6801 from the oracle address. In embodiments, after receiving the oracle collateral requirement, the administrator system 6801 may calculate the oracle collateral requirement to verify the received oracle collateral requirement. If the receipt of the oracle collateral is not verified, the administrator system 6801, may, in embodiments, impose a penalty fee; generate and send a notification indicating the verification failure, stop the process of FIGS. 70A-70F, and/or use a different oracle for the published smart contract, to name a few.

The process of FIG. 95A may continue with step S9506. At step S9506, the administrator system 6801 may receive an indication of interest from a second user device (e.g. user device 105b) associated with a second user via network 15. In embodiments, the indication of interest may include second user information associated with the second user and second side information. In embodiments, the second user information may include one or more of the following: (1) a public address associated with the second user (e.g. a second user public address); (2) a public key associated with the second user (e.g. a second user public key), the second user public key, in embodiments, being mathematically related to the second user public address; (3) a private key associated with the second user (e.g. a second user private key), the second user private key, in embodiments, being mathematically related to the second user public key; and/or (4) whitelist information associated with the second user, to name a few. The second side information may be information related to a leg of the contract proposal (e.g. “buy”, “sell”, to name a few). The indication of interest, in embodiments, may be similar to the indications of interest described above in connection with FIGS. 71C-71F, the descriptions of which applying herein. In embodiments, step S9506 may be similar to step S7004, described above in connection with FIG. 70A, the description of which applying herein. In embodiments, the received indication of interest may also include one or more of the following: a trusted oracle selection 6917 (e.g. oracle 6811); an oracle address (e.g. oracle public address 6813); an oracle collateral requirement; and/or an oracle fee.

In embodiments, the administrator system 6801 may also receive one or more indications of interest from one or more oracles. As described above, the received contract proposal may be transmitted by the administrator system 6801 to the one or more selected oracles of trusted oracle selection 6917. In embodiments, in response to receiving the contract proposal, one or more oracles that received the contract proposal may send an indication of interest to the administrator system 6801. For example, an oracle may send an indication of interest including one or more of the following: (1) an identifier unique to the contract proposal; (2) an oracle collateral requirement; (3) an inception date; (4) an inception value; (5) benchmark data; (6) second benchmark data; (7) a user collateral requirement (e.g. collateral requirement 7126); (8) a notional value of the contract; (9) early termination rules; and/or (10) dispute rules, to name a few. Dispute rules are described more fully below in connection with step S9512, the description of which applying herein. In embodiments, the administrator system 6801 may receive indications of interest from oracles not of the selected oracles of the contract proposal. In embodiments, an indication of interest from an oracle may be similar to the indications of interest described in connection with FIGS. 71C-71F, the descriptions of which applying herein.

The process of FIG. 95A may continue with step S9508. At step S9508, the administrator system 6801 may match the first contract information and the second side information. For example, if Alice's first contract information includes first side information of “buy” (e.g. side information 7138) and Bob's indication of interest includes second side information of “sell” (e.g. side information 7154), the administrator system 6801 may match Alice and Bob. If for example Alice's first side information is “buy” and Bob's second side information is “buy”, the administrator system 6801 may not match Bob and Alice, instead moving to other indications of interest in search of a match of the first contract information and second side information. The administrator system 6801, in embodiments, may also match an oracle to the published contract proposal. For example, if the administrator system receives one or more indications of interests from one or more oracles, the oracle most closely matching the published contract parameters may be selected by the administrator system 6801. In embodiments, the administrator system 6801 may select a default oracle. Step S9508 may be similar to step S7006, described above in connection with FIG. 70A, the description of which applying herein.

In embodiments, after the administrator system 6801 matches the first user and the second user based on the received first trade information and the second side information, the administrator system 6801 may publish the second smart contract at the second smart contract address (e.g. step S9512).

The process of FIG. 95A may continue with step S9510. At step S9510, a first smart contract (e.g. a stable value smart contract) may be provided. In embodiments, the first smart contract may refer to a module for a fiat-backed digital asset (e.g. Libra). In embodiments, the first smart contract may refer a smart contract for a pegged fiat-backed digital asset (e.g. Gemini Dollar, TUSD, BitCoin Cash, etc.). The first smart contract provided herein may be similar to the stable value smart contract provided in step S70008 of FIG. 70A, the description of which applying herein. Step S9510 may be similar to step S7008, described above in connection with FIG. 70A, the description of which applying herein.

In embodiments, the first smart contract may be associated with a digital asset token. The digital asset token, in embodiments, may be a fiat-backed digital asset token (e.g. Libra). The fiat-backed digital asset token, may be similar to the fiat-backed digital asset described throughout, the description of which applying herein. For example, the fiat-backed digital asset token may be backed by a reserve of fiat and/or governmental bonds. The reserve, in embodiments, may be maintained by or on behalf of the issuer that created the fiat-backed digital asset token. In embodiments, the digital asset may be a stable value token (e.g. Gemini Dollar). In embodiments, the first smart contract instructions may be associated with the blockchain for the underlying digital asset.

The process of FIG. 95A may continue with step S9512. At step S9512, a second smart contract may be provided. In embodiments, step S9512 may be similar to step S7010, described above in connection with FIG. 70A, the description of which applying herein. In embodiments, the second smart contract may be provided and published in a similar manner to the security token smart contract described in connection with FIG. 70A, the description of which applying herein. In embodiments, the second smart contract instructions 6805B may further include dispute instruction module 6942. The dispute instructions module 6942, may include oracle instructions for receiving, analyzing, and executing instructions to handle disputed information received from an oracle. In embodiments, the oracle instructions may account for an instance where the oracle produces current benchmark data that is disputed and/or believed to not be correct. For example, as described herein, an oracle may be used to produce benchmark data to settle the second smart contract. As another example, if at the time of settlement, Alice believes the benchmark data has a value of X and Bob believes the benchmark data has a value of Y (where Y does not equal X), an oracle may be the tie breaker and receive a request to determine the actual value at the time of settlement. Continuing the example, the oracle may return actual benchmark data has a value of Z. In embodiments, the transaction is executed based on the benchmark Z.

Referring to FIG. 96B, an oracle may produce benchmark data in the form of a first digitally signed benchmark message 9604. In embodiments, the first digitally signed benchmark message 9604 may include one or more of the following: (1) oracle identification 9616 (e.g. a unique identifier that may be used to identify the oracle submitting the first digitally signed benchmark message 9618); (2) first current benchmark data 9618 (e.g. the information being retrieved and published by the oracle to settle the contract); (3) first time stamp 9620 (e.g. the time at which the first current benchmark data 9618 was retrieved); (4) an oracle digital signature 9622 (e.g. a private key associated with the oracle public address 6813); and/or (5) the public address of the party who requested the first current benchmark data 9618 (e.g. a public address associated with the administrator 6801, the first user, the second user, and/or a watchtower, to name a few), to name a few. In embodiments, the first digitally signed benchmark message 9604 may be sent from an oracle public address to the second smart contract address via the blockchain.

In embodiments, the benchmark information received from the oracle may be disputed. For example, in embodiments, the oracle may be associated with multiple published contracts and be tasked to provide each of those smart contracts with current benchmark data. In embodiments, the oracle may provide second current benchmark data 9628 to a third smart contract address (e.g. not the second smart contract) that differs from the first current benchmark data 9618 provided to the second smart contract address. The first current benchmark data 9618, for example, may be transmitted to the second smart contract address at the same or substantially same time (e.g. the difference in time does not materially affect the benchmark data) as the second current benchmark data 9628 was transmitted to the third smart contract address. In embodiments, any party to the second smart contract may dispute the benchmark data provided by the oracle. In embodiments, the dispute instructions module 6942 may include wait period instructions, that allow for a predetermined wait period (e.g. 10 minutes, 1 hour, 5 hours, 1 day, 5 days, and/or a week, to name a few) for a party to the contract to dispute the current benchmark data provided by the oracle. The dispute instructions module 6942, in embodiments, may set requirements for a dispute message. Referring to FIG. 96A, the dispute message 9602 may be required to include one or more of the following: the first digitally signed benchmark message 9604 (e.g. the information supplied by the oracle to the second smart contract), the second digitally signed benchmark message 9606 (e.g. information provided by the oracle to another smart contract), the first current benchmark data 9608, the first time stamp 9610, the second current benchmark data 9612, second time stamp 9614, and/or a private key associated with the sender of the dispute message 9602. In embodiments, the dispute instructions module 6942 may require the dispute message 9602 to include one or more of the following: (1) evidence of the difference between the benchmark data supplied to the published smart contract between Alice and Bob and the different benchmark data associated with the other smart contract (e.g. not the smart contract between Alice and Bob); (2) evidence of the similarities between the time of the published smart contract and the another published smart contract; (3) a digital signature from the first user (e.g. the first user private key); (4) a digital signature from the second user (e.g. the second user private key); (5) a digital signature form the administrator (e.g. the administrator private key); (6) a designated public address to receive the oracle collateral (associated with, for example, one or more of: the first user, the second user, and/or the administrator, to name a few); and/or (7) a mathematical solution, to name a few. In embodiments, to receive a penalty fee, the second smart contract instructions 6805B may require receipt of a message (e.g. the dispute message 9602) by the second smart contract address 6805A from the first user public address, the second user public address, and/or an administrator public address indicating an error in the oracle supplied benchmark data. If the requirements set forth in the second smart contract instructions 6805B are met, in embodiments, the second smart contract address 6805A may transfer half of the oracle collateral to the first user public address and half of the oracle collateral to the second user address.

In embodiments, the dispute message 9602 may be analyzed to determine whether a penalty fee is warranted—the description of which is located below in connection with steps S9528, S9530, and S9532, described below in connection with FIG. 95C, the description of which applying herein. In embodiments, the dispute message 9602 may be analyzed by the second smart contract and/or the administrator 6801. In embodiments, if it is determined that a penalty fee is warranted (e.g. the information received by the oracle was unreliable and/or incorrect), the penalty fee may be the amount of collateral required by an oracle collateral requirement.

The second smart contract instructions 6805B, in embodiments, may also include instructions to settle based on the benchmark data supplied by the oracle, even if the oracle pays the penalty fee. Alternatively, in embodiments, the second smart contract instructions 6805B may, in the case where the oracle pays the penalty fee, include instructions for the second smart contract 6805 to refund the collateral associated with the first user to the first user and refund the collateral associated with the second user to the second user. In embodiments, in the case where the oracle pays the fee, the second smart contract instructions 6805B may include instructions for the second smart contract 6805 to query an additional oracle to settle the published contract.

In embodiments, the first benchmark information may, as mentioned above, be different and/or substantially different from benchmark information associated with a similar contract associated with the oracle address. In the case where the first benchmark information is different and/or substantially different from benchmark information associated with a similar contract, as mentioned above, the oracle may be required to pay a penalty fee. In the case where the first benchmark information is not different or substantially different from benchmark information associated with a similar contract, an additional transaction request may be generated by the administrator system 6801 (and/or the oracle) and sent to the second smart contract address 6805A. The second smart contract instructions, in embodiments, may require the additional transaction request: (1) be sent after a predetermined amount of time after the oracle sends the first benchmark information; (2) include a ledger of contracts the oracle address is associated with; (3) include the amount of oracle collateral; and/or (4) include a digital signature of the oracle (e.g. the private key associated with the oracle). The second smart contract address 6805A, upon receipt of the additional transaction request, may verify the transaction request by determining whether the one or more requirements associated with the additional transaction request and the second smart contract instructions 6805B are met. If the requirements are met, in embodiments, the second smart contract address 6805B may execute the additional transaction request, resulting in the oracle collateral being returned to the oracle address from the second smart contract address 6805A. If the requirements are not met, in embodiments, the second smart contract instructions 6805B may require the oracle to lose the collateral and be required to pay the penalty fee. In embodiments, if the requirements are not met, the second smart contract instructions 6805B may cause the second smart contract 6805 to generate and send a notification to the oracle address indicating that the additional transaction request was rejected because the requirements were not met.

In embodiments, the first smart contract and the second smart contract may be one smart contract and/or module. In embodiments, a third smart contract and/or module may include the first smart contract and the second smart contract. In embodiments, the first smart contract address and the second smart contract address may be the same smart contract address. In embodiments, the third smart contract address may be the first smart contract address and/or the second smart contract address.

Referring to FIG. 95A, the process of FIG. 95A may continue with step S9514. At step S9514, a first amount of collateral, a second amount of collateral, and/or a third amount of collateral are received by the second smart contract. In embodiments, the second smart contract may require collateral from the first user, the second user, and/or the oracle. The second smart contract address, in embodiments, may receive: (1) the first amount of collateral from a first user public address, (2) the second amount of collateral from a second user public address; and/or (3) the third amount of collateral from the oracle public address 6813. In embodiments, the first amount of collateral may be received by the second smart contract address as a result of a first transaction request sent by the first user device. In embodiments, step S9514 may be similar to step S7012, described above in connection with FIG. 70A, the description of which applying herein.

In embodiments, the first transaction request may be generated by the first user device and digitally signed by the first user private key. The first transaction request, in embodiments, may include a request to transfer the first amount of collateral in the digital asset token from the first user public address to the second smart contract address. In embodiments, once generated and signed, the first transaction request may be transmitted by the first user device from the first user public address to the first smart contract address via the underlying blockchain. The first transaction request may be verified and executed by the first smart contract, causing the first amount of collateral to be transferred from the first user public address to the second smart contract address.

In embodiments, the second amount of collateral may be received by the second smart contract address as a result of a second transaction request sent by the second user device. In embodiments, the second transaction request may be generated by the second user device and digitally signed by the second user private key. The second transaction request, in embodiments, may include a request to transfer the second amount of collateral in the digital asset token from the second user public address to the second smart contract address. In embodiments, once generated and signed, the second transaction request may be transmitted by the second user device from the second user public address to the first smart contract address via the underlying blockchain. The second transaction request may be verified and executed by the first smart contract, causing the second amount of collateral to be transferred from the second user public address to the second smart contract address.

In embodiments, the third amount of collateral may be received by the second smart contract address as a result of a third transaction request sent by the oracle 6811. In embodiments, the third transaction request may be generated by the oracle 6811 and digitally signed by a private key associated with the oracle 6811 and the oracle public address 6813 first user private key. The first transaction request, in embodiments, may include a request to transfer the third amount of collateral in the digital asset token from the oracle public address to the second smart contract address. In embodiments, once generated and signed, the third transaction request may be transmitted by the oracle from the oracle public address to the first smart contract address via the underlying blockchain. The third transaction request may be verified and executed by the first smart contract, causing the third amount of collateral to be transferred from the oracle public address to the second smart contract address.

In embodiments, the administrator system 6801 and/or a third party may monitor the second smart contract address to confirm that the first, second, and third amount of collateral have been received by the second smart contract. If any of the first, second, or third amount of collateral is not received by the second smart contract and/or partially not received by the second smart contract, the administrator system 6801, in embodiments, may generate a notification indicating that the collateral amount is not received by the second smart contract address; The generated notification, in embodiments, may be sent by the administrator system 6801 to the first user device, the second user device, the first smart contract address, and/or the oracle, to name a few. In embodiments, after the notification is sent, the administrator system 6801 may wait for a predetermined amount of time, allowing the deficient party to cure the collateral defect. In embodiments, the administrator system 6801 may generate and send a third message to the second smart contract address. The third message, in embodiments, may include a request to transfer the first amount of collateral, the second amount of collateral, and/or the third amount of collateral in accordance with the first trade instructions. The disbursement of the collateral when one or more parties to the second smart contract have not transferred sufficient collateral may be controlled by the first trade instructions. In embodiments, the disbursement may include a penalty fee to the deficient party or parties. In embodiments, each party may receive a refund of their collateral.

In embodiments, the administrator system 6801 may receive a request to update the second smart contract based on new benchmark data and recalculate the first amount of collateral and the second amount of collateral. The request, in embodiments, may be received from one or more of: the first user device, the second user device, and/or the oracle 6811. In embodiments, in response to receiving the request (and/or in accordance with the first trade instructions) the administrator system 6801 may generate and send a message to the second smart contract. The message, in embodiments, may request the second smart contract to recalculate the first collateral amount and the second collateral amount based on current benchmark data. In embodiments, the current benchmark data may be retrieved by the second smart contract generating and sending a request to the oracle public address 6813. In embodiments, the current benchmark data may be retrieved by the administrator system 6801, first user device, and/or second user device generating and sending a request to the oracle public address 6813. The oracle, in response, may return the current benchmark data (e.g. first digitally signed benchmark message 9604).

In embodiments, the request to update the second smart contract may be sent directly to the second smart contract via the blockchain from one or more of the following: the first user public address, the second user public address, the oracle public address 6813, and/or the administrator public address, to name a few.

Once the message is received by the second smart contract address, the second smart contract may recalculate the excess collateral. Recalculating excess collateral, in embodiments, may be similar to step S7014, described above in connection with FIGS. 70A, 70E, and 70F, the description of which applying herein. In embodiments, the second smart contract may determine that the first user, second user, and/or oracle 6811 owes additional collateral, based on the current benchmark information. In embodiments, if one or more parties owes additional collateral, the administrator system 6801 and/or the second smart contract may generate a notification indicating that one or more parties to the second smart contract owes additional collateral and/or the time period in which the one or more parties can transfer the additional collateral into the second smart contract. The generated notification, in embodiments, may be sent to the first user device, the second user device, the oracle 6811, the first smart contract address, the second smart contract address, and/or the administrator system 6801.

In embodiments, the administrator system 6801 and/or a third party may monitor the second smart contract address to confirm that the additional collateral has been received by the second smart contract. If any of the additional collateral is not received by the second smart contract, the administrator system 6801, in embodiments, may generate a notification indicating that the additional collateral amount is not received by the second smart contract address; The generated notification, in embodiments, may be sent by the administrator system 6801 to the first user device, the second user device, the first smart contract address, and/or the oracle, to name a few. In embodiments, after the notification is sent, the administrator system 6801 may wait for a predetermined amount of time, allowing the deficient party to cure the collateral defect. In embodiments, the administrator system 6801 may generate and send a third message to the second smart contract address. The third message, in embodiments, may include a request to transfer the first amount of collateral, the second amount of collateral, and/or the third amount of collateral in accordance with the first trade instructions. The disbursement of the collateral when one or more parties to the second smart contract have not transferred sufficient collateral may be controlled by the first trade instructions. In embodiments, the disbursement may include a penalty fee to the deficient party or parties. In embodiments, each party may receive a refund of their remaining collateral.

The process of FIG. 95A may continue with step S9516. At step S9516, the administrator system 6801 implements the first trade instructions. In embodiments, the first trade instructions may be implemented in response to the administrator system 6801 receiving a request to settle the contract by one or more of the following: the first user device, the second user device, and/or the oracle, to name a few. In embodiments, the first trade instructions may be implemented because the second smart contract was intended to last a certain amount of time, which has elapsed, causing the administrator system 6801 to begin implementing the first trade instructions. Step S9516 may be similar to step S7014, described above in connection with FIG. 70A, the description of which applying herein. In embodiments, step S9516 may include the process described in connection with FIG. 95B. Referring to FIG. 95B, implementing the first trade instructions may begin at step S9518. At step S9518, the second smart contract address receives a first digitally signed benchmark message (e.g. first digitally signed benchmark message 9604) from an oracle (e.g. oracle 6811) and/or an oracle public address (e.g. oracle public address 6813).

In embodiments, the oracle may send the first digitally signed benchmark message 9604 in response to receiving directions to send the current benchmark information. In embodiments, the directions may be received by one or more of: the first user, the second user, the administrator 6801, the first smart contract, and/or the second smart contract, to name of few. For example, the second smart contract may generate a transaction request, signed by a private key associated with the second smart contract. The generated transaction request may include a request to retrieve current benchmark information (e.g. first current benchmark data 9618) and send the current benchmark information to the second smart contract address. The generated transaction request, in embodiments, may be transmitted from the second smart contract address to the oracle public address 6813. In response to receiving the generated transaction request, the oracle may verify the transaction request (e.g. verify the digital signature), retrieve the current benchmark data, and generate a benchmark message (e.g. first digitally signed benchmark message 9604). The generated benchmark message, in embodiments, may be digitally signed by the oracle private key and sent from the oracle public address 6813 to the second smart contract address. The received benchmark message, in embodiments, may be verified and/or stored on the blockchain by the second smart contract address, and/or sent to another public address (e.g. the first smart contract address, the administrator public address, the first user public address, and/or the second user public address, to name a few) for verification and/or storage. The generated transaction request, in embodiments, may be generated by one or more of the following: the first user device, the second user device, the first smart contract, and/or the administrator, to name a few. The generated transaction message may be sent to the oracle public address 6813 and/or a computer system associated with the oracle 6811 from one or more of the following: the first user device via network 15, the second user device via network 15, the administrator via network 15, the first user public address via the blockchain, the second user public address via the blockchain, and/or the administrator public address via the blockchain, to name a few.

In embodiments, when the current benchmark data is received, the second smart contract may publish the current benchmark data on the blockchain.

The process of implementing the first trade instructions may continue with step S9520. At step S9520, the administrator system monitors the second smart contract for a predetermined amount of time. In embodiments, the predetermined amount of time may correspond to the amount of time allotted by the dispute instructions module 6942 to dispute the benchmark information received from the oracle. In embodiments, a trusted third party, e.g. a watchtower, may monitor the second smart contract address. In embodiments, no dispute message is received, and the second smart contract may continue implementing the first trade instructions (e.g. continued with step S9522). However, in embodiments, the information received by the oracle 6811 may be disputed. In embodiments, a dispute message is received by the second smart contract address. In embodiments, a process for receiving and processing dispute messages is illustrated in connection with FIGS. 95C-95D.

Referring to FIG. 95C, the process for receiving and processing dispute messages may begin at step S9526. At step S9526, the second smart contract receives a dispute message. The dispute message 9602, in embodiments, may be generated and/or sent from one or more of the following: the first user device via network 15, the second user device via network 15, the administrator via network 15, the first user public address via the blockchain, the second user public address via the blockchain, and/or the administrator public address via the blockchain, to name a few. In embodiments, the dispute message 9602 may include one or more of the following: (1) the first digitally signed benchmark message 9604; (2) the second digitally signed benchmark message 9606; (3) first current benchmark data 9608; (4) first time stamp 9610; (5) second current benchmark data 9612; (6) second time stamp 9614; and/or (7) a digital signature from the sender (e.g. the first user private key, the second user private key, and/or the administrator private key, to name a few), to name a few. The first digitally signed benchmark message 9604, in embodiments, may be the benchmark message received by the second smart contract in connection with step S9518 and include one or more of the following: (1) first oracle identification 9616, (2) first current benchmark data 9618, (3) first time stamp 9620, and/or (4) the first oracle digital signature 9622, to name a few. The second digitally signed benchmark message 9606, in embodiments, may be a benchmark message received by a smart contract that is not the second smart contract and include one or more of the following: (1) second oracle identification 9624, (2) second current benchmark data 9626, (3) second time stamp 9628, and/or (4) the second oracle digital signature 9628, to name a few.

In embodiments, the second smart contract may verify the dispute message 9602. In embodiments, the second smart contract address may transmit the dispute message 9602, for verification purposes, to one or more of: the administrator system 6801, the first smart contract, the first user device, and/or the second user device, to name a few. To verify the dispute message 9602, in embodiments, the data within the dispute message 9602 may be verified. For example, one or more of the following may be compared to determine if they are the same, and thus verified: (1) the first oracle identification 9616, the second oracle identification 9624, and the oracle 6811; (2) the first current benchmark data 9608 and the first current benchmark data 9618; (3) the first time stamp 9610 and the first time stamp 9620; (4) the second current benchmark data 9612 and the second current benchmark data 9626; (5) the second time stamp 9614 and the second time stamp 9628; and/or (6) the first oracle digital signature 9622 and the second oracle digital signature 9630. In embodiments, if the above respective information does not match its respective counterpart, the dispute message 9602 may not be verified. In embodiments, if the dispute message 9602 is not verified, a penalty fee may be imposed on the user(s) which submitted the dispute message 9602. In embodiments, if the dispute message is not verified, the predetermined amount of time will continue to toll, and, when the predetermined amount of time has elapsed, the process may continue with step S9522.

In embodiments, if the administrator system 6801 (and/or the first smart contract, the first user device, and/or the second user device) receives and verifies the dispute message 9602, the administrator system 6801 may generate and send a message to the second smart contract address from the administrator public address via the blockchain. The message, in embodiments, may indicate whether the dispute message was verified.

Continuing the process of FIGS. 95C-95D, at step S9528, the second smart contract compares the first digitally signed benchmark message and the second digitally signed benchmark message. Once the dispute message 9602 is verified, the dispute message 9602 may be analyzed to determine whether a penalty fee is warranted. To determine whether a penalty fee is warranted, the second smart contract may compare the first digitally signed benchmark message 9604 and the second digitally signed benchmark message 9606. In embodiments, the first digitally signed benchmark message 9604 and the second digitally signed benchmark message 9606 may be compared by the administrator system 6801, the first smart contract, the second smart contract, the first user device, and/or the second user device, to name a few.

Continuing the process of FIGS. 95C-95D, at step S9530, the second smart contract may determine a first difference between the first current benchmark data and the second current benchmark data. The second smart contract's comparison of the first digitally signed benchmark message 9604 and the second digitally signed benchmark message 9606 may result in determining a first difference between the first current benchmark data 9618 and the second current benchmark data 9626. In embodiments, the first difference may be determined by the administrator system 6801, the first smart contract, the second smart contract, the first user device, and/or the second user device, to name a few.

Continuing the process of FIGS. 95C-95D, at step S9532, the second smart contract may determine a second difference between the first time stamp and the second time stamp. The second smart contract's comparison of the first digitally signed benchmark message 9604 and the second digitally signed benchmark message 9606 may result in determining a second difference between the first time stamp 9620 and the second time stamp 9628. In embodiments, the second difference may be determined by the administrator system 6801, the first smart contract, the second smart contract, the first user device, and/or the second user device, to name a few.

In embodiments, a successful dispute may require the first difference to be above a first predetermined threshold and/or the second difference to be below a second predetermined threshold. The first predetermined threshold may require that the difference between the first current benchmark data 9618 and the second current benchmark data 9626 be above a certain amount. The second predetermined threshold may require that the first current benchmark data 9618 and the second current benchmark data 9626 be retrieved by the oracle 6811 within a time period that did not materially affect the benchmark data. The first and second predetermined thresholds, in embodiments, may be static thresholds or dynamic, based on the asset associated with the second smart contract (e.g. the volatility of the asset).

In embodiments, the determination of whether the differences exceed the predetermined thresholds may be performed by one or more of: the second smart contract, the administrator system 6801, the first smart contract, the second smart contract, the first user device, and/or the second user device, to name a few.

If, in embodiments, the first difference is below the first predetermined threshold and/or the second difference is above the second predetermined threshold, the dispute may be unsuccessful, and the predetermined amount of time will continue to toll. When, in embodiments, the predetermined amount of time has elapsed, the process may continue with step S9522.

In embodiments, the first difference is above a first threshold and the second difference is below a second threshold and the process of FIGS. 95C-95D may continue with FIG. 95D. Referring to FIG. 95D, at step S9534, the administrator system may send a second message to the second smart contract. In embodiments, if the dispute is successful, the second smart contract may generate and send a message indicating that the dispute was successful. After determining the dispute was successful, the administrator system 6801 may generate and send the second message to the second smart contract address via the blockchain. The generated second message may be sent to the second smart contract address from one or more of the following: the first user device via network 15, the second user device via network 15, the administrator via network 15, the first user public address via the blockchain, the second user public address via the blockchain, and/or the administrator public address via the blockchain, to name a few.

The second message, in embodiments, may include a request to recalculate the collateral based on the dispute instructions. The dispute instructions, as mentioned above, may impose a penalty fee to the oracle 6811 if the benchmark information received from the oracle 6811 is confirmed to be inaccurate, incorrect, and/or unreliable. In embodiments, the penalty fee may be the entire amount of the collateral from the oracle (e.g. the third amount of collateral). In embodiments, the third amount of collateral may be transferred to the sender of the dispute message 9602 and/or split between the first user and the second user. In embodiments, the fee may be predetermined, or dynamic based on the degree of unreliability or incorrectness of the information received from the oracle 6811. In embodiments, the recalculation of the excess collateral may set the oracle's excess collateral (e.g. the third amount of excess collateral) to zero.

Continuing the process of FIGS. 95C-95D, at step S9536, the administrator system may send a third message to the second smart contract. In embodiments, the administrator system 6801 may generate a third message including a request to distribute the excess collateral based on the dispute instructions. In embodiments, the second and third message may be one message—e.g. a fourth message—which is sent by the administrator system 6801 to the second smart contract address. The generated message may be sent to the second smart contract address from one or more of the following: the first user device via network 15, the second user device via network 15, the administrator via network 15, the first user public address via the blockchain, the second user public address via the blockchain, and/or the administrator public address via the blockchain, to name a few.

After a successful, or unsuccessful dispute, the process of implementing the first trade instructions may continue. In embodiments, if there is a successful dispute, the predetermined amount of time may default to ending—the predetermined amount of time being for disputes, the dispute being completed. In embodiments, if the dispute is unsuccessful, the predetermined amount of time will continue to toll until the predetermined amount of time has elapsed. Referring to FIG. 95B, the process of implementing the first trade instructions may continue with step S9522. At step S9522, the excess collateral is calculated. To trigger the calculation of excess collateral, in embodiments, the administrator system 6801 may generate and send a fourth message to the second smart contract address via the blockchain. The fourth message, in embodiments, may include a request to recalculate the collateral based on the at least one collateral requirement and/or the dispute instructions. The generated fourth message may be sent to the second smart contract address from one or more of the following: the first user device via network 15, the second user device via network 15, the administrator via network 15, the first user public address via the blockchain, the second user public address via the blockchain, and/or the administrator public address via the blockchain, to name a few. In embodiments, the excess collateral may be recalculated by one or more of the following: the first user device, the second user device, the administrator system 6801, the oracle 6811, the second smart contract, and/or the first smart contract, to name a few.

The excess collateral, in embodiments, may be recalculated based on one or more of the following: the at least one collateral requirement; the first current benchmark data 9618, the second current benchmark data 9626, benchmark data gathered from an additional oracle, and/or a complete refund of the first amount of collateral and the second amount of collateral. In embodiments, a successful dispute may indicate that the first current benchmark data 9618 is unreliable. If the first current benchmark data 9618 is unreliable, the second smart contract may implement the first trade instructions based on the at least one collateral requirement and one or more of the following: first current benchmark data 9618; second current benchmark data 9626; benchmark data gathered from an additional oracle, and/or a complete refund of the first amount of collateral and the second amount of collateral. The aforementioned options may be preselected and defined by the first trade instructions—e.g. if the second current benchmark data 9626 is more accurate, use the more accurate benchmark data. The aforementioned options may be agreed upon as a dispute occurs—e.g. the data was completely wrong—refund the collateral and give the first user and the second user the penalty fee from the oracle 6811.

The process of implementing the first trade instructions may continue with step S9524. At step S9524, the excess collateral is distributed. In embodiments, step S9524 may be similar to step S7014 described in connection with FIGS. 70A,70E, and 70F, the descriptions of which applying herein. In embodiments, in response to receiving the fourth message, the second smart contract may verify the fourth message (e.g. checking digital signatures) and send the first excess collateral to the first user public address, the second excess collateral to the second user public address, and the third excess collateral to the oracle public address 6813.

The steps of the processes described in connection with FIGS. 95A-95D may be rearranged or omitted.