US20220230195A1

Movatterモバイル変換

Info

Publication number: US20220230195A1
Application number: US17/580,272
Authority: US
Inventors: Michael B. ROHLFS
Original assignee: Dearborn Financial Inc
Current assignee: Dearborn Financial Inc
Priority date: 2020-10-13
Filing date: 2022-01-20
Publication date: 2022-07-21
Anticipated expiration: 2040-10-13
Also published as: US11403655B1

Abstract

A server connected to a network generates a database including a first data structure configured to store attributes of fungible assets, where the attributes determine market values of the fungible assets, and a second data structure having fields referentially related to the attributes stored in the first data structure such that a change in any field induces a change in real time in a corresponding attribute in the first data structure. The server receives a stream of data regarding the attributes of the fungible assets from the network, modifies the fields of the second data structure, and allows cycling, liquidating, and replenishing of one or more of the fungible assets while maintaining a relative value equivalence of the fungible assets. The server securely validated, verifies, records, traces, and tracks transactions for cryptocurrency specimens. The server generates tokens based on the fungible assets for trading over subnetworks and provides price discovery.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation-in-part of U.S. patent application Ser. No. 17/380,488 filed on filed on Jul. 20, 2021, which is a continuation-in-part of U.S. patent application Ser. No. 17/069,336 filed on filed on Oct. 13, 2020 (U.S. Pat. No. 11,107,160 issued Aug. 31, 2021). The present disclosure is related to the following U.S. patents and patent application publication: U.S. Pat. No. 10,510,115 issued Dec. 17, 2019 titled Computerized Exchange-Controlled Network System and Related Method; U.S. Pat. No. 10,269,070 issued Apr. 23, 2019 titled System and Method for Sharia-based Market Hedging and Related Method; U.S. Pat. No. 9,460,470 issued Oct. 4, 2016 titled System and Market Hedging and Related Method; U.S. Pat. No. 9,002,741 issued Apr. 7, 2015 also titled System and Market Hedging and Related Method; U.S. Pat. No. 9,741,042 issued Aug. 22, 2017 titled Global Pollution Control System Employing Hybrid Incentive Trade Instruments and Related Method of Establishing Market Values, which is related in part to U.S. Pat. No. 8,722,002 issued May 13, 2014 titled System for Recycling Captured Agglomerated Diesel Soot and Related Methods; and U.S. Patent Application Publication No. 2019/0095995 published Mar. 28, 2019 titled Systems and Methods for Operating Exchange Controlled Network Handling Digitized Asset-Backed Medium of Exchange. The entire disclosures of the U.S. patents and the patent application publication referenced above are incorporated herein by reference.

FIELD

The present disclosure relates to referential data structures for automatically updating asset attributes in real time based on streaming data cross-reference to related applications.

BACKGROUND

The background description provided here is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventor, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.

SUMMARY

A server connected to a network comprises a processor and memory storing instructions which when executed by the processor configure the processor to generate a database. The database comprises a first data structure configured to store attributes of fungible assets. The attributes determine market values of the fungible assets. The database comprises a second data structure having fields referentially related to the attributes stored in the first data structure such that a change in any one of the fields induces a change in real time in a corresponding one of the attributes in the first data structure. The instructions configure the processor to receive a stream of data regarding one or more of the attributes of the fungible assets from the network, and to modify one or more of the fields of the second data structure based on the stream of data received from the network. The instructions configure the processor to allow at least one of cycling, liquidating, and replenishing of one or more of the fungible assets associated with the first data structure based on the modified one or more fields of the second data structure. The instructions configure the processor to maintain a relative value equivalence of the fungible assets based on the at least one of cycling, liquidating, and replenishing of the one or more of the fungible assets associated with the first data structure.

In other features, the first data structure is automatically updated in real time as the stream of data modifies the one or more of the fields of the second data structure, and the updating of the first data structure automatically updates the attributes and valuations of the fungible assets in real time.

In other features, the attributes of the fungible assets include an asset type, valuation data, and geographic data of the fungible assets.

In another feature, the stream of data is based on trading activity associated with the one or more of the fungible assets over the network.

In other features, the instructions further configure the processor to maintain a plurality of baskets of the fungible assets in the database, and modifying the one or more of the fields of the second data structure automatically updates the attributes and valuations of the fungible assets across the baskets in real time.

In other features, the instructions further configure the processor to receive via the network buy and sell orders from counterparties for trading one or more of the fungible assets in the baskets and to match the orders based on practically opposite rather than absolute opposite trading interests of the counterparties while maintaining the relative value equivalence of the fungible assets in the baskets.

In other features, the instructions further configure the processor to generate a weighted average benchmark based on a plurality of asset forms of one or more of the fungible assets and to match the orders using the weighted average benchmark.

In other features, the instructions further configure the processor to provide liquidity and physical delivery of the traded fungible assets to the counterparties via the network upon matching the orders while maintaining the relative value equivalence of the fungible assets in the baskets.

In another feature, the instructions further configure the processor to align the orders to comply with Sharia law.

In another feature, the instructions further configure the processor to generate a digitized medium of exchange that is based on a set of baskets comprising the fungible assets and that is usable for trading the fungible assets over the network.

In another feature, the instructions further configure the processor to securitize and tokenize the digitized medium of exchange for trading the fungible assets over the network.

In another feature, the server further comprises a dongle that cryptographically authenticates access to the server via the network and that secures data transfers between the server and the network.

In another feature, the server further comprises a dongle that provides transformational data protection via encryption that adds authentication and fault tolerant information to data transfers between the server and the network.

In still other features, a method comprises generating a database on a server. The database comprises a first data structure configured to store attributes of fungible assets. The attributes determine market values of the fungible assets. The database comprises a second data structure having fields referentially related to the attributes stored in the first data structure such that a change in any one of the fields induces a change in real time in a corresponding one of the attributes in the first data structure. The method comprises receiving a stream of data regarding one or more of the attributes of the fungible assets at the server from a network, and modifying one or more of the fields of the second data structure based on the stream of data received from the network. The method comprises allowing at least one of cycling, liquidating, and replenishing of one or more of the fungible assets associated with the first data structure based on the modified one or more fields of the second data structure. The method comprises maintaining a relative value equivalence of the fungible assets based on the at least one of cycling, liquidating, and replenishing of the one or more of the fungible assets associated with the first data structure.

In other features, the method further comprises automatically updating the first data structure in real time as the stream of data modifies the one or more of the fields of the second data structure, and automatically updating, based on the updating of the first data structure, the attributes and valuations of the fungible assets in real time.

In another feature, the method further comprises receiving the stream of data in response to trading activity associated with the one or more of the fungible assets over the network.

In other features, the method further comprises maintaining a plurality of baskets of the fungible assets in the database, and automatically updating, based on the modifying of the one or more of the fields of the second data structure, the attributes and valuations of the fungible assets across the baskets in real time.

In other features, the method further comprises receiving, at the server via the network, buy and sell orders from counterparties for trading one or more of the fungible assets in the baskets, and matching, at the server, the orders based on practically opposite rather than absolute opposite trading interests of the counterparties while maintaining the relative value equivalence of the fungible assets in the baskets.

In other features, the method further comprises generating a weighted average benchmark based on a plurality of asset forms of one or more of the fungible assets, and matching the orders using the weighted average benchmark.

In other features, the method further comprises providing liquidity and physical delivery of the traded fungible assets to the counterparties via the network upon matching the orders while maintaining the relative value equivalence of the fungible assets in the baskets.

In another feature, the method further comprises aligning the orders to comply with Sharia law.

In another feature, the method further comprises generating, at the server, a digitized medium of exchange that is based on a set of baskets comprising the fungible assets and that is usable for trading the fungible assets over the network.

In other features, the method further comprises securitizing and tokenizing, at the server, the digitized medium of exchange for trading the fungible assets over the network.

In another feature, the method further comprises cryptographically authenticating access to the server via the network and securing data transfers between the server and the network by using a dongle coupled to the server.

In another feature, the method further comprises providing transformational data protection via encryption and adding authentication and fault tolerant information to data transfers between the server and the network by using a dongle coupled to the server.

In still other features, a server connected to a network comprises a processor and memory storing instructions which when executed by the processor configure the processor to generate a database comprising a first data structure and a second data structure. The first data structure is configured to store attributes of fungible assets. The attributes determine market values of the fungible assets and include an asset type, valuation data, and geographic data of the fungible assets. The second data structure has fields referentially related to the attributes stored in the first data structure such that a change in any one of the fields induces a change in real time in a corresponding one of the attributes in the first data structure. The instructions configure the processor to receive a stream of data regarding one or more of the attributes of the fungible assets from the network and modify one or more of the fields of the second data structure based on the stream of data received from the network. The first data structure is automatically updated in real time as the stream of data modifies the one or more of the fields of the second data structure. The updating of the first data structure automatically updates the attributes and valuations of the fungible assets in real time. The instructions configure the processor to allow at least one of cycling, liquidating, and replenishing of one or more of the fungible assets associated with the first data structure based on the modified one or more fields of the second data structure. The instructions configure the processor to maintain a relative value equivalence of the fungible assets based on the at least one of cycling, liquidating, and replenishing of the one or more of the fungible assets associated with the first data structure. The instructions configure the processor to maintain a plurality of baskets of the fungible assets in the database. Modifying the one or more of the fields of the second data structure automatically updates the attributes and valuations of the fungible assets across the baskets in real time. The instructions configure the processor to at least one of securely validate, verify, record, trace, and track transactions for cryptocurrency specimens based on the stream of data, the cryptocurrency specimens having net cumulative values derived from digitized asset-backed mediums of exchange comprising one or more of the plurality of baskets.

In other features, the instructions further configure the processor to convert one or more digitized asset-backed mediums of exchange comprising one or more of the plurality of baskets into one or more cryptocurrency specimens.

In other features, the instructions further configure the processor to securely validate, verify, record, trace, and track the transactions for the cryptocurrency specimens without using proof-of work mining based processes.

In other features, the instructions further configure the processor to securely validate, verify, record, trace, and track the transactions for the cryptocurrency specimens by encoding the digitized asset-backed mediums of exchange with a history of attributes and activities unique to the one or more of the plurality of baskets underpinning the digitized asset-backed mediums of exchange; verifying, using the encoding, that unitary ownership interests associated with the digitized asset-backed mediums of exchange are validly linked to the cryptocurrency specimens placed in and removed from external circulation; and providing cryptographic keys for a dongle-based authentication system to create immutable and traceable data and records of the transactions for access using the dongle-based authentication system.

In other features, the instructions further configure the processor to securely validate, verify, record, trace, and track the transactions for the cryptocurrency specimens by implementing one or more application programming interfaces that allow users dongle-based access to view and evaluate continuously updated and compiled price discovery data related to the net cumulative values of the cryptocurrency specimens.

In other features, the instructions further configure the processor to securely validate, verify, record, trace, and track the transactions for the cryptocurrency specimens by interfacing, using the one or more application programming interfaces, with one or more graphical user interfaces configured to: provide bids, offers, and executed prices attendant to each underlying net cumulative value component to the users; and allow the users to post counter prices of net cumulative value components via iterative processes culminating in execution of the transactions of the cryptocurrency specimens with a specific time and date stamp.

In other features, the instructions further configure the processor to account for and reconcile periodically reported information for each unitary ownership-based cryptocurrency specimen in circulation over the network.

In other features, the instructions further configure the processor to encode the digitized asset-backed mediums of exchange with a history of attributes and activities unique to the one or more of the plurality of baskets underpinning the digitized asset-backed mediums of exchange that have migrated through formulation, securitization, issuance, and initial valuation processes as of a specified date of origin.

In other features, the instructions further configure the processor to verify, using the encoding, that unitary ownership interests associated with the digitized asset-backed mediums of exchange are validly linked to the cryptocurrency specimens placed in and removed from external circulation.

In other features, the instructions further configure the processor to generate cryptographic keys for a dongle-based authentication system to create immutable and traceable data and records of the transactions for access using the dongle-based authentication system.

In other features, the instructions further configure the processor to implement one or more application programming interfaces that allow users dongle-based access to view and evaluate continuously updated and compiled price discovery data related to the net cumulative values of the cryptocurrency specimens.

In other features, the instructions further configure the processor to interface, using the one or more application programming interfaces, with one or more graphical user interfaces configured to provide bids, offers, and executed prices attendant to each underlying net cumulative value component to users.

In other features, the instructions further configure the processor to interface, using the one or more application programming interfaces, with one or more graphical user interfaces configured to allow the users to post counter prices of net cumulative value components per iterative processes culminating in execution of the transactions of the cryptocurrency specimens with a specific time and date stamp.

In other features, the stream of data is based on trading activity associated with the one or more of the fungible assets over the network.

In other features, the server further comprises a dongle that cryptographically authenticates access to the server via the network and that secures data transfers between the server and the network. The server further comprises a dongle that provides transformational data protection via encryption that adds authentication and fault tolerant information to data transfers between the server and the network.

In other features, the instructions further configure the processor to align the orders to comply with Sharia law.

In other features, the instructions further configure the processor to generate a digitized medium of exchange that is based on a set of baskets comprising the fungible assets and that is usable for trading the fungible assets over the network. The instructions further configure the processor to securitize and tokenize the digitized medium of exchange for trading the fungible assets over the network.

In other features, the instructions further configure the processor to securely validate, verify, record, trace, and track the transactions for the cryptocurrency specimens using processes selected from a group consisting of proof of work, proof of stake, delegated proof of stake, proof of capacity, proof of elapsed time, proof of identity, proof of authority, and proof of activity.

In still other features, a server connected to a network comprises a processor and memory storing instructions which when executed by the processor configure the processor to generate a database comprising a first data structure and a second data structure. The first data structure is configured to store attributes of fungible assets. The second data structure has fields referentially related to the attributes stored in the first data structure such that a change in any one of the fields induces a change in real time in a corresponding one of the attributes in the first data structure. The instructions configure the processor to receive a stream of data regarding one or more of the attributes of the fungible assets from the network and modify one or more of the fields of the second data structure based on the stream of data received from the network. The first data structure is automatically updated in real time as the stream of data modifies the one or more of the fields of the second data structure. The updating of the first data structure automatically updates the attributes and valuations of the fungible assets in real time. The instructions configure the processor to maintain a plurality of baskets of the fungible assets in the database. Modifying the one or more of the fields of the second data structure automatically updates the attributes and valuations of the fungible assets across the baskets in real time. The instructions configure the processor to at least one of securely validate, verify, record, trace, and track transactions for cryptocurrency specimens based on the stream of data, the cryptocurrency specimens having net cumulative values derived from digitized asset-backed mediums of exchange comprising one or more of the plurality of baskets.

In other features, the instructions further configure the processor to allow at least one of cycling, liquidating, and replenishing of one or more of the fungible assets associated with the first data structure based on the modified one or more fields of the second data structure; and maintain a relative value equivalence of the fungible assets based on the at least one of cycling, liquidating, and replenishing of the one or more of the fungible assets associated with the first data structure.

In other features, the attributes include an asset type, valuation data, and geographic data of the fungible assets.

Further areas of applicability of the present disclosure will become apparent from the detailed description, the claims and the drawings. The detailed description and specific examples are intended for purposes of illustration only and are not intended to limit the scope of the disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure will become more fully understood from the detailed description and the accompanying drawings, wherein:

FIGS. 1A and 1B show an example of Asset-Backed Exchange Traded Baskets (ABETB's) for an ABETB-centric order matching system according to the present disclosure;

FIG. 2 shows an example of a database comprising first and second data structures for the ABETB-centric order matching system according to the present disclosure;

FIG. 3 shows a simplified example of a distributed computing system that can implement the ABETB-centric order matching system of the present disclosure;

FIG. 4 shows a simplified example of a client device ofFIG. 3;

FIG. 5 shows a simplified example of a server ofFIG. 3;

FIG. 6 shows a flowchart of a method performed by the ABETB-centric order matching system for automatically updating attributes of fungible assets according to the present disclosure;

FIG. 7 shows a flowchart of a method performed by the ABETB-centric order matching system for maintaining a relative value equivalence of the fungible assets according to the present disclosure;

FIG. 8 shows a flowchart of a method performed by the ABETB-centric order matching system for maintaining a relative value equivalence of the fungible assets according to the present disclosure;

FIG. 9 shows a flowchart of a method performed by the ABETB-centric order matching system for automatically updating attributes of fungible assets across a set of baskets comprising the fungible assets according to the present disclosure;

FIG. 10 shows a flowchart of a method performed by the ABETB-centric order matching system for matching buy and sell orders according to the present disclosure;

FIG. 11 shows a flowchart of a method performed by the ABETB-centric order matching system for generating a weighted average benchmark for matching buy and sell orders based on practically opposite rather than absolute opposite trading interests of counterparties according to the present disclosure;

FIG. 12 shows a flowchart of a method performed by the ABETB-centric order matching system for ensuring that buy and sell orders comply with Sharia law according to the present disclosure;

FIG. 13 shows a flowchart of a method performed by the ABETB-centric order matching system for generating, securitizing, to organizing a digitized medium of exchange for trading fungible assets according to the present disclosure;

FIG. 14 shows a flowchart of a method performed by the ABETB-centric order matching system for providing secure transactions between devices used for trading fungible assets across a network according to the present disclosure;

FIG. 15 shows multiple dimensions impacting data structures developed around BCS-based hybrid paradigm according to the present disclosure;

FIG. 16 shows operations of the ABETB-centric order matching system performed by an exchange (i.e., by a server at the exchange; e.g., the server ofFIGS. 3-5) in an ABETB-centric order matching system500 according to the present disclosure;

FIG. 17 shows a method for securely validating, verifying, recording, tracing, and tracking transactions for cryptocurrency specimens according to the present disclosure;

FIG. 18 shows a method for securely validating, verifying, recording, tracing, and tracking transactions for cryptocurrency specimens using a three-layer encoding system according to the present disclosure;

FIG. 19 shows a system for securely trading tokens over subnetworks and validating, verifying, recording, tracing, and tracking transactions for tokens over the subnetworks according to the present disclosure; and

FIG. 20 shows a method for securely trading tokens over subnetworks and validating, verifying, recording, tracing, and tracking transactions for tokens over the subnetworks using the system ofFIG. 19 according to the present disclosure.

In the drawings, reference numbers may be reused to identify similar and/or identical elements.

DETAILED DESCRIPTION

The following abbreviations and definitions are used throughout the present disclosure.

GLEBS: Global e-Bourse Suites, is an organization of affiliated exchanges whose computerized trading platforms are uniquely integrated according to the teachings of U.S. Pat. No. 10,510,115, which is incorporated herein by reference in its entirety.

ABETB: Asset-Backed Exchange Traded Baskets, are investment products with meaningful prospects in their own right, are structured inter alia to serve as major drivers of tradable asset liquidity throughout multiple markets targeted by Global e-Bourse Suites (“GLEBS”).

BCS: Benchmark Complex Solutions (as disclosed in U.S. Pat. Nos. 9,002,741, 9,460,470, and 10,269,070; and in U.S. patent application publication 20190095995) result in matching practically opposite orders for fungible-yet varying tradable assets that would otherwise be victims of illiquidity inherent to absolute opposite matching.

ABMoE: Asset-Backed Medium of Exchange comprising sets of ABETB.

DABMoE: Digitized Asset-Backed Medium of Exchange

ECN: Exchange-Controlled Network

ETD: Exchange Traded Derivatives

ETF: Exchange-Traded Funds

EFP: Exchange for Physical

FPDDI: Forward Point Delivery Differential Index

CDI: Complementary Differential Index

COI: Communities of Interest

CPL: Customized Permissioned Ledger

WAB: Weighted Average Benchmark

NAV: Net Asset Value

CUspCF: Commodity User posts bid data for specific commodity form

Repos: Repurchase Agreements

All-in: A function of price discovery mechanisms whereby each fungible-yet-varying asset qualifying as a member of an ABETB is valued on the basis of its operative WAB contact price±the net price effects of its requisite number of long or short CDI and FPDDI contracts specified by the exchange as called for under the circumstances. Each time a bid, offer or executed price is reported by the Exchange's automated market data provider for any of the forgoing contracts, an updated all-in market price indication is provided for each qualifying member. The net sum of the updated all-in prices attributable to the various qualifying members then equals the updated market value of the operative WAB, after giving effect to the respective Exchange-specified weighting attributes attendant to each of its contents.

Overview of present disclosure: The present disclosure relates to an ABETB-centric order matching system that uses synergy created by a computer implemented hybrid paradigm leveraging multi-market price discoveries to optimize all-in BCS-based price liquidity achieved over a plurality of trading platforms integrated via an ECN that connects an organization of Affiliated Exchanges, their customers, and COI.

ABETB holders can gain connectivity and liquidity when the exchanges uniformly employ systems, methods, and instruments that work together to contemporaneously maintain macro level NAV equilibrium as cross-listed trading contracts attendant to qualifying fungible-yet-varying assets underpinning an Exchange-specified basket, formulated to emulate a WAB Set, are exposed to continuous micro level price fluctuations throughout each trading day.

Central to these processes are continuously updated bids, offers, and latest execution prices provided as part of a graphical user interface (GUI) data feed offered by the Exchange's automated market data provider to ECN-authenticated customers, at which point those customers may use said data to place new orders. The GUI data feed includes prices posted for Exchange-specified WAB, CDI, and FPDDI contracts, as well as for pro-forma all-in market value indications, compiled therefrom, for products that emulate BCS-based WAB Sets: e.g., ABETB representing the sum of its qualified underlying assets; and the sum of ABETB sets underpinning an Exchange-formulated ABMoE or DABMoE.

Pro-forma all-in market value indications are by-products of computer implemented algorithmic formulas applied to each of the hybrid paradigm's compendium of physical, financialized, and digitized assets when they are being bought, sold, financed, hedged, cycled (e.g., physically exchanged between ABETB's and Exchange managed/controlled inventories), securitized, and tokenized over Affiliated Exchange trading platforms. Having the ability to apply the algorithms to pluralities of assets and trading platforms creates iterative opportunities for liquidity gains to take hold symbiotically throughout the Affiliated Exchange organization, culminating in growth of physically-settled transactions whereby counterparties' practically, rather than absolute, opposite trading interests can be matched directly over one platform or via back-to-back order executions employing multiple markets and platforms.

Enabling ABETB, ABMoE, and DABMoE products and their underlying assets to exploit these innovations advances art in the field by addressing challenges faced by fund holders and managers alike: (i) risks attendant to standalone asset illiquidity causing market dislocations; and (ii) relatively cumbersome, less-automated legacy processes increasingly experiencing difficulties attempting to mitigate the risks.

Risks go up when supplies of useful standalone assets confined to absolute opposite order matching increase relative to demand, especially from speculators that thrive on liquidity. Risks are particularly extended to fungible-yet-varying credit instruments and commodities held in conventional exchange-traded products, like ETF's, which employ multi-basket structures (i.e., creation, redemption and holding baskets). To mitigate such ETF risks, “insider” transactions with Authorized Parties are permitted to increase liquidity and narrow differences between the product's publicly traded price and its NAV. Also, Fund Managers focus more on end-of-day NAV machinations, rather than providing more efficient price discovery and market valuation processes throughout each trading day. The teachings of the present disclosure conversely rely on use of computer implemented BCS-based algorithms to continuously mitigate risks of standalone asset illiquidity and market dislocations. As a result, ABETB's, ABMoE's and DABMoE's are offered as novel and commercially more efficient and proactive means to deal with excess illiquidity.

Organization of present disclosure: The present disclosure is organized as follows. Initially, a detailed description of the ABETB-centric order matching system according to the present disclosure is provided. Thereafter, BCS, key policies regarding trading ETD contracts employing BCS, and attendant security features are described. Subsequently, the ABETB-centric order matching system is described in detail with reference to various block diagrams and flowcharts shown and described with reference toFIGS. 1A-14.

ABETB-centric order matching system: The ABETB-centric order matching system according to the present disclosure is designed to transform connectivity between physical asset markets and the financial sector, comprising an exchange-specified plurality of fungible assets possessing varying quantitative, qualitative, logistics, and settlement timing properties, each gaining transparency and liquidity via hybrid paradigm formed by Benchmark Complex Solutions (“BCS”) that satisfy practically, rather than absolute, opposite counterparties' trading interests to facilitate continuous market price discoveries sufficient to consistently maintain relative value equivalency among all qualifying assets underpinning the ABETB and maintained in exchange-segregated, -managed, and -controlled inventories.

Conventional exchange traded derivatives (“ETD”) platforms dealing almost exclusively with cash-settled commodity and financialized futures, options, etc. have experienced tremendous growth in trading contract volumes during this millennium to ultimately attain a state of hyper-liquidity where markets operate at their most efficient and transparent levels. Key factors in attaining such levels are progressive IT advances in data transmission and validation speeds and high degrees of standardization whereby ETD contracts arbitrarily denote single-form asset benchmarks for absolute opposite order matching, theoretically satisfying (arguably incorrectly) all counterparties dealing with varying forms of the operative asset.

Those scenarios are described in U.S. Pat. Nos. 9,002,741; 9,460,470; 10,269,070; 10,515,115; and U.S. patent application publication 20190095995. These filings advanced art in the field inter alia by defining BCS comprising uniformly applied systems, methods, and instruments developed to maximize physical settlements of standardized-yet-customizable ETD orders for fungible-yet-varying assets (not merely financialized trading contracts) involving processes whereby counterparties are authenticated to gain wider satisfaction when placing orders for asset form matching based on practically opposite interests, while their respective COI are authenticated to access requisite trade data pertaining to such orders over an attendant ECN on a need-to-know, -act, and -store basis.

Matching practically opposite counterparty interests within the confines of ABETB requires considerably more complex processes involving a wider range of trading and other platforms compared to those engaged in merely matching absolute opposite orders for arbitrarily specified cash-settled futures and options contracts. The present disclosure describes how a BCS-based order matching system can overcome those complexities to enable multitudes of platforms, counterparties, and their COI to benefit from the aforementioned IT advances aimed at optimizing connectivity, further still, between physical asset markets and the financial sector as part of a novel and more efficient path toward hyper-liquidity.

The teachings of the present disclosure further the scope of technology protected by previously cited patent filings directed to BCS developed for trading and hedging fungible-yet-varying assets qualifying as members of an exchange-formulated Weighted Average Benchmark (“WAB”) Set. The present disclosure relates to ABETB, a novel financial product backed by exchange-specified tradable assets formulated in baskets that can be transparently maintained and regularly replenished by proprietary asset-cycling systems employing practically opposite matching and relative value equivalency processes predicated on BCS. Designed to compete with Exchange-Traded Funds (“ETF's”) and other investment products gaining popularity in secondary markets by exploiting the use of fractionalized interests, ABETB's can be described as possessing the following characteristics.

Specifically, ABETB's are single asset baskets designed to emulate WAB sets linked to exchange-specified varying assets, with many billions of dollars of commodities and credit instruments particularly suited for inclusion since GLEBS affiliated ETD platforms would benefit considerably by added transparency and liquidity ensuing from such arrangements. Under BCS, each asset in an ABETB is valued at the operative WAB set market price±adjustments linked to market prices for cash-settled Complementary and Forward Point Delivery Differential Indexes (CDI's and FPDDI's), the requisite number of contracts of which are determined by proprietary algorithms formulated to factor the impact of qualitative, logistics, and settlement timing variability applying under the circumstances, as well as any positive or negative asset carrying costs not otherwise provided for directly as part of CU and FPDDI contracts.

ABETB's are sets of single asset baskets, structured for more diversified offerings, e.g., Asset-Backed Medium of Exchange (“ABMoE”) developed for the Global e-Counter barter and countertrade platform described in U.S. Pat. No. 9,460,470. Complementing core physical asset baskets with varying levels of US dollar and/or foreign currency baskets, ABETB's produce meaningful stores of value aimed inter alia at consistently outperforming the annual rate of inflation. Digitized (i.e., securitized and tokenized) ABMoE, called DABMoE, can also be formulated to offer secondary cryptocurrency markets diversely substantive alternatives to Bitcoin and the plethora of Altcoins in the field.

ABETB's are structured to enable each of a single asset basket's contents to be periodically replenished and continuously valued by a proprietary asset-cycling system based on practical (rather than absolute) equivalency and links to market prices of the operative WAB set and differential indexes discovered throughout each trading day via ECN and CPL, achieved by integrating GLEBS' computerized trading platforms as elucidated throughout the patents referenced above.

The BCS-based counterparty matching comprises the following operations performed by one or more exchange affiliates. The BSC-based counterparty matching includes one or more exchange affiliates formulating a weighted average benchmark (“WAB”) set linked to an exchange-specified plurality of qualifying asset forms, rather than arbitrarily denoting one single asset form as the benchmark for all forms of that asset. The BSC-based counterparty matching includes one or more exchange affiliates identifying and factoring the impact of quantitative, qualitative, logistics, and settlement timing properties unique to each of the qualifying asset forms comprising a neutral WAB formulated by the exchange for the entire set.

The BSC-based counterparty matching further includes one or more exchange affiliates providing uniform allowances for cases where traders physically own or are seeking to own varying-yet-fungible asset forms, each qualifying as an interchangeable component of an exchange-specified set, offer or bid their specific asset form pursuant to standardized spot or forward Exchange for Physical (EFP) contracts calling for settlement by physical delivery or receipt of their respective underlying assets, with each contract's specifications linked to an operative WAB formulated by the exchange to cover an entire set of qualified asset forms.

The BSC-based counterparty matching further includes one or more exchange affiliates ensuring that each component in a Weighted Average Benchmark (WAB) possesses quantitative characteristics, as well as varying qualitative, logistics, and settlement timing properties that customarily add to or detract from each respective asset's market value, the net aggregate effects of which are uniformly balanced exchange-wide by methods integral to the following: establishing benchmark-specific WAB sets, each formulated for incorporation into a family of standardized exchange-traded derivatives (“ETD”) contracts, the ETD contracts typically including spots, forwards, futures, options and spreads, specifications of which differ only by timing and type of settlement taking place; requiring EFP spot and forward traders to acquire a specific number of long or short Complementary Differential Index (CDI) contracts, for cash tendered or received as the case may be, linked to varying qualitative and logistics attributes of underlying assets respectively delivered or received, and to ensure co-delivery of such contracts as of an operative EFP physical delivery date; and requiring EFP spot and forward traders to acquire a specific number of long or short Forward Point Delivery Differential Index (FPDDI) contracts, for cash tendered or received as the case may be, linked to the negotiated timing of underlying assets respectively delivered or received, and to ensure co-delivery of such contracts as of an operative EFP physical delivery date.

The BSC-based counterparty matching further includes one or more exchange affiliates uniformly employing the forgoing methods to formulate, acquire, maintain, and hedge future price volatility risks of ABETB and ABMoE on a practically equivalent basis, achieved by instilling parameters for cycled interchange of varying-yet-fungible assets qualified within exchange-specified baskets underpinning the forgoing, the parameters serving to account for qualitative, logistics, supply chain, life cycle and any other positive or negative cost of carry factors unique to the assets held and, when necessary, securitized by exchange(s), all taking place prior to deliveries scheduled to meet future commitments to counterparties, plus assets held in reserve by exchange(s) to ensure their ongoing role as order liquidity provider(s), with such parameters incorporated as part of proprietary float processes employed within the confines of an affiliated exchange organization-wide inventory management and control system.

Different from the DABMoE exchange or the DABMoE Conversion Module (“DCM”) disclosed in U.S. patent application publication 20190095995, Global d-Bourse is designed to cooperate with GLEBS-affiliated platforms, plus others when necessary, to undertake the following functions: formulating WAB Sets specified for ABETB; enhancing aggregate GLEBS-wide liquidity by cross-listing ABETB products over multiple platforms inside and outside GLEBS and effectuating back-to-back order executions accordingly; exercising constructive management and control over assets acquired and stored prior to satisfying physical delivery commitments to ETD and other platforms inside and outside the GLEBS group, including those assets employed to underpin ABETB; exercising constructive management and control over assets cycled in and out of ABETB in a manner that consistently maintains market value equivalence as practically, rather than absolute, opposite assets are interchanged, which involves continuously maintaining a transactional database containing all GLEBS affiliates' ETD contract market prices attendant to EFP spots and forwards, futures, options, and swaps, and using proprietary algorithms to determine which Complementary and Forward Point Delivery Differential Indexes (CDI and FPDDI) and should be used to determine the extent to which cash adjustments must be paid or received as part of any asset cycling transaction; and otherwise acting as a liquidity provider engaged in BCS-based order matching processes, as shown inFIG. 15 and exemplified in more detail below.

The BCS-based algorithms uniformly factor the integrated effects of each trader's specified asset form posted in its bid/offer vis-a-vis the latest offers/bids posted for their operative spot or forward contract. The algorithm output identifies the requisite quantities of Complementary Differential Index and Forward Point Delivery Differential Index (CDI and FPDDI) contracts to be bought or sold by each counterparty pursuant to an exchange-wide pursuit of aggregate zero-sum equivalence achieved within the confines of practically opposite matching. Graphical User Interfaces (GUI's) display algorithm-generated output to provide each buyer and seller with computed data that continuously indicates net cumulative all-in market prices and values attributable to each asset on an equivalent-for-equivalent basis. For example, see claims 9 through 13 of U.S. Pat. No. 10,269,070 that provide more detailed teachings regarding the forgoing.

The BCS-based order matching for commodities is now described. Following is an overview of counterparty matching processes integral to organizing affiliated exchanges' computerized trading platforms dealing with commodities, each qualified in a basket of varying-yet-fungible commodity forms comprising an ABETB formulated and offered as alternatives to certain ETF's and other financial products.

The counterparty matching processes include identifying trading party types (denoted for each respective party at dongle-enabled sign-in). The trading party types include Commodity Producers (Sellers), Commodity Users (Buyers), Exchange Market Makers (Covering Buy and Sell Sides), Commodity Trading Firms (Covering Buy and Sell Sides), and Global d-Bourse (Covering Buy and Sell Sides).

The processes followed to fill buy-side orders (iterative until a match is executed) include the following. Commodity User posts bid data for specific commodity form (the “CUspCF”) that qualifies within a specified plurality of forms comprising an operative exchange-formulated WAB Set, with the bid data indicating desired quantity, incoterms and price, as well as exchange confirmation that the Commodity User is logistically and financially qualified to take delivery of the denoted commodity pursuant to the terms of its bid. The exchange compares Commodity User's bid data with offer data posted by Sellers—in this case, primarily Commodity Producers, Exchange Market Makers, and Commodity Trading Firms—aimed at identifying whether an absolute matching offer exists to offset against Commodity User's bid.

If no absolute matching offer emerges, the exchange inquires with Global d-Bourse to see if it is willing and able to sell CUspCF inventory in its possession to the Commodity User, which is a decision Global d-Bourse makes after determining the extent to which required quantity of CUspCF is physically available and uncommitted pursuant to Global d-Bourse inventory management and control guidelines; and after determining the extent to which different yet practically equivalent form(s) of the commodity (i.e., also qualifying in the attendant WAB Set's plurality) can be acquired to suitably replace the CUspCF at values acceptable to Global d-Bourse.

If the above process still fails to result in an absolute match, the exchange informs Commodity User whether matching offer(s) for the CUspCF are posted, albeit at higher selling price(s), by one or more of the aforementioned Sellers; or different yet practically equivalent form(s) of the desired commodity (i.e., qualified as another component in the WAB Set's specified plurality) are available in the quantity sought and at a comparably similar unit price equivalent to that originally sought by the Commodity User with respect to CUspCF.

The processes followed to fill sell-side orders (iterative until a match is executed) include the following. Commodity Producer posts offer data for a specific commodity form (the “CPspCF”) that qualifies within a specified plurality of forms comprising an operative exchange-formulated WAB set, with the offer data indicating desired quantity, incoterms and price, as well as exchange confirmation that the Commodity Producer is logistically and financially qualified to make delivery of the denoted commodity pursuant to the terms of its offer. The exchange compares Commodity Producer's offer data with bid data posted by Buyers—in this case, primarily Commodity Users, Exchange Market Makers, and Commodity Trading Firms—aimed at identifying whether bid(s) can be absolutely matched with Commodity Producer's offer.

If no absolute matching bid emerges, the exchange inquires with Global d-Bourse to see if it is willing and able to buy CPspCF from the Commodity Producer for inclusion as part of the tradable asset inventories under its constructive control, which is a decision Global d-Bourse makes pursuant to its inventory management and control guidelines. If the process still fails to result in an absolute match, the exchange informs Commodity Producer whether matching bid(s) for the CPspCF have been posted, albeit at lower price(s), by one or more of the aforementioned Buyers.

The BCS-based matching can also be used for credit instruments. Excluding the effects of Quantitative Easing (QE) pursued by central banks, globally, bond market liquidity has dropped significantly in the aftermath of global financial crises occurring during this millennium due to factors such as substantial growth in outstanding bond issue breadth and volume, bank and broker-dealer consolidations depleting the ranks of market makers, and government regulations cutting into capital levels that market makers can to commit to holding credit instrument inventories.

According to some financial institutions, lack of liquidity is most prevalent in non-U.S. Treasury markets entailing much larger volumes of outstanding issues. This is particularly true in the case of corporate bonds where investors are less likely to find parties to trade with, much less discover prices they want to transact at. Investors therefore desire more efficient, versatile and affordable means to satisfy all aspects of acquiring the right security, hedging against that security's price volatility risks and then selling the security to exit entirely or diversify within the asset class.

Some innovations have emerged for that purpose, e.g., diversified ETF's and distributed ledger technologies offering efficiencies to increase order transparency and decrease customer trading costs, respectively. GLEBS aims to advance diversity of art in this field via affiliated computerized trading platforms employing BCS within an ECN customized to facilitate the use of permissioned ledgers. This is the case for Global Credit e-Bourse, which is developed to generate standard systems, methods, and ETD contracts (esp. physically-settled spots and forwards) linked to pluralities of fungible credit instruments qualified in WAB sets to underpin ABETB, factoring attributes such as bond classifications and varying qualitative attributes. Examples of bond classifications include corporate industrials, transports, utilities, and financial services, plus various types of preferred stocks, leveraged loans, municipals and even Sharia-based Sukuks. Examples of varying qualitative attributes include coupon rate of interest, credit quality rating, and remaining time to maturity/convertibility/callability, each incorporated into standardized WAB integrated with Complementary Differential and Forward Point Delivery Differential Indexes (CDI and FPDDI).

Following is an overview of order matching processes integral to individual credit instruments qualifying within a diverse basket of securities comprising an ABETB comprising an exchange-formulated WAB Set. The order matching processes include identifying Trading Party Types (denoted by each respective party per dongle-enabled sign-in). The Trading Party Types include Buyers of physically-settled spot and forward ETD contracts linked to individual securities that qualify as components of an exchange-formulated WAB Set (i.e., a basket of credit instruments, also referred to as an Exchange-Traded Bond Basket or “ETBB”). The Trading Party Types include Buyers of physically-settled spot and forward ETD contracts linked to ETBB, qualifying as one or more components within a plurality of tradable asset baskets underpinning an ABMoE. The Trading Party Types further include Sellers of either of the forgoing, Exchange Market Makers (covering both buy and sell Sides), and Global d-Bourse (covering both buy and sell sides).

The processes followed to fill buy side orders (iterative until a match is executed) include the following. Buyer posts bid data for a specific credit instrument that is a qualified component of an operative exchange-formulated WAB Set, with the bid data including desired quantity and price. The exchange compares Buyer's bid data with offer data posted by Sellers, including Exchange Market Makers, aimed at identifying whether an absolute matching offer exists.

If no absolute matching offer emerges, the exchange inquires with Global d-Bourse to see if there is willingness and ability to sell inventory in its constructive possession to the Buyer, which is a decision Global d-Bourse makes after determining whether required quantity of the asset desired by Buyer is physically available and uncommitted pursuant to Global d-Bourse inventory management and control guidelines; or after determining whether practically equivalent alternative credit securities (i.e., also qualifying within attendant WAB Set's plurality) can be acquired, at satisfactory terms, to suitably replace assets removed from Global d-Bourse inventory for sale to Buyer.

If the process still fails to result in absolute match, the exchange informs Buyer whether matching offer(s) for the desired asset is posted, albeit at higher selling price(s), by one or more of the aforementioned Sellers; or whether practically equivalent alternative form(s) of the desired asset (i.e., qualified within the WAB Set's specified plurality) are available in the quantity and at a satisfactorily equivalent unit price to what was originally indicated by the Buyer.

The processes followed to fill sell side orders (iterative until a match is executed) include the following. Seller posts offer data for a specific credit Instrument security that's a qualified component of an operative exchange-formulated WAB Set, with the data including desired quantity and price. The exchange compares Seller's offer data with bid data posted by Buyers, including Exchange Market Makers, aimed at identifying whether absolutely matching bid(s) exist.

If no absolute matching bid emerges, the exchange inquires with Global d-Bourse to see if it is willing/able to buy the securities from the Seller for inclusion as part of the tradable asset inventories under its constructive control, a decision Global d-Bourse makes pursuant to its inventory management and control guidelines. If the process still fails to result in absolute match, the exchange informs Seller whether any matching bid(s) for the credit instrument securities have been posted, albeit at lower price(s), by one or more of the aforementioned Buyers.

Accordingly, ABETB's are novel financial products backed by exchange-specified tradable assets formulated into baskets whose contents can be continuously replenished and valued by proprietary asset-cycling systems and methods employing practically, rather than absolute, opposite matching processes predicated on BCS. Designed to compete with ETF's and other fractionalized interest investment products emerging in secondary markets today, ABETB's are structured as single asset baskets as well as sets of single asset baskets.

The single asset baskets are designed to emulate Weighted Average Benchmark (“WAB”) Sets linked to exchange-specified plurality of qualifying asset forms. Each single asset basket in an ABETB is backed by fungible-yet varying assets; and many billions of dollars of commodities and credit instruments particularly targeted for trading over GLEBS affiliated Exchange-Traded Derivatives (“ETD”) platforms should benefit considerably by the added liquidity ensuing from such arrangements. Assets are cycled in and out via practically opposite matches, executed at prevailing market prices±cash adjustments tied to BCS-based Complementary Differential Indexes (CDI's) uniquely valuing the intrinsic impacts of qualitative, logistics, and settlement timing variability.

ABETB's are also structured as sets of single asset baskets, structured for more diversified offerings, such as ABMoE fractionalized interest instruments developed for the Global e-Counter (barter and countertrade) platform per U.S. Pat. No. 9,460,470. Complementing with US Dollar and foreign currency baskets, these build meaningful stores of value aimed inter alia at outperforming annual rates of inflation. Digitized (i.e., securitized and tokenized) ABMoE (called “DABMoE”) are also designed to provide global cryptocurrency (“CC”) markets with diversely substantive alternatives to Bitcoin and the plethora of Altcoins in the field.

The ABETB systems and methods disclosed herein further the scope of technology protected by U.S. Pat. Nos. 9,002,741, 9,460,470, and 10,269,470 directed to BCS developed to trade and hedge individual fungible-yet-varying assets qualifying as members of an exchange-formulated WAB Set. BCS were originally developed to boost transparency, liquidity and volume of physically-settled ETD contracts predicated on matching practically, rather than absolute, opposite counterparty trading interests. The market values of assets cycled in and out of ABETB are linked to WAB Set prices that can be continuously discovered, transparently, throughout each trading day over a cryptographically assured Exchange-Controlled Network (“ECN”) and posted onto customized permissioned ledgers (“CPL”), all achievable by integrating GLEBS affiliates' computerized trading platforms as elucidated in the patents noted above, as well as more comprehensively in U.S. Pat. No. 10,510,115.

Additionally, U.S. Patent Application Publication No. 20190095995 is directed to a BCS-based hybrid paradigm formed to further increase transparency, liquidity, and volume by creating synergy to uniformly provide standardized-yet customizable trading, hedging, digitization, repo-based finance, and asset management and control systems, methods and instruments, GLEBS-wide, upon integration of its affiliates' IT Resources (esp. ECN and CPL) and reporting processes; and by cycling fungible-yet-varying assets in and out of ABETB alongside securitization and tokenization processes essential to DABMoE and CC offerings.

The following is a brief description of Benchmark Complex Solutions (BCS) and key policies for trading Exchange Traded Derivatives (ETD) contracts employing BCS. Rather than arbitrarily denoting a single asset form as the benchmark for all forms of that asset, BCS formulate a more practical weighted average benchmark (“WAB”) set linked to an exchange-specified plurality of qualifying asset forms. Geographic, quantitative, and qualitative properties unique to any plurality of denoted asset forms can provide the bases of a neutral and unbiased WAB formulated by the Exchange for the entire set.

Traders physically owning or seeking to own differing-yet-interchangeable asset forms (each qualified as a component of an exchange-specified set) can offer/bid their respective asset form via standardized set of EFP contracts linked with an operative WAB formulated by the exchange to cover the entire set of qualified asset forms. BCS' novel order-matching process—based on satisfying counterparties' practically, rather than absolute, opposite, interests—is designed to satisfy all parties' demands for more flexibility, transparency, liquidity and cost effectiveness. Spot and EFP-forward contracts specify physical delivery and receipt, respectively, of underlying assets.

Each component in a WAB has specific geographic and other quantitative characteristics, as well as varying qualitative properties that customarily add to or detract from that asset's market value, the net effects of which can be balanced exchange-wide by proprietary algorithms integral to the standardized ETD contracts designed for (i) benchmark specific (WAB) sets, (ii) complementary differential indexes and (iii) forward point delivery differential indexes. The forgoing ETD contracts [(i)-(iii)] have been custom-formulated for transparent trading in the open market; each/all structured to be co-settled as of the operative spot or EFP-forward contract's physical delivery date. Offering strictly financially-settled versions of those ETD contracts (each on a standalone basis) likewise offer considerable appeal to speculators and other financial investors.

The following are Key Policies for trading ETD contracts employing BCS. Each exchange-formulated WAB Set is based on distinct geographic, quantitative, qualitative, and logistics attributes that can be incorporated into a family of standardized ETD contracts, the specifications of which differ only by the timing and type of settlement taking place. Financially settled contracts linked to WAB Sets—available to all exchange customers—trade similarly to today's arbitrarily-denoted single asset form benchmark contracts (e.g., Brent or WTI crude oil) typically executed over conventional regulated futures exchanges. Spot and EFP-forward contracts linked to WAB Sets can be traded by qualifying (i.e., dongle-authenticated) customers meeting the exchange's applicable financial, logistics, and other requirements attendant to delivering/receiving their traded contracts' underlying assets.

Spot and EFP-forward customers must buy/sell a requisite number of financially settled Complementary Differential (“CD”) Index contracts determined by algorithms attendant to the varying qualitative attributes of respective underlying assets being delivered or received. Spot and EFP traders must co-deliver the CD Index contracts as of their contract's operative physical delivery date. The CD Index contracts, available for trading by all exchange customers, are listed with expiration dates.

EFP-forward customers must buy/sell a requisite number of financially settled Forward Point Delivery Differential (“FPDD”) Index contracts computed by algorithms attendant to negotiated timing of respective underlying assets being delivered/received. EFP-forward traders must co-deliver FPDD Index contracts as of their contract's operative physical delivery date. FPDD Index contracts, available for trading by all exchange customers, are listed with expiration dates.

Certain qualifying customers can convert their net open long or short cash-settled WAB Set contracts for EFP-forward contracts subject to (i) exchange verifying that sufficient physical assets are available as of those contracts' operative physical delivery dates; and (ii) the customer buying/selling requisite (algorithm determined) number of CD Index and FPDD Index contracts called for under the circumstances.

In summary, each one of GLEBS' standardized-yet-customizable ETD contract families is uniquely formed to enhance transparency, liquidity, and flexibility in a manner that will attract not only a wide range of commercials but also financial investors and speculators.

Accordingly, the present disclosure provides novel financial products in the form of Asset-Backed Exchange-Traded Baskets (ABETB's) and Asset-Backed Mediums of Exchange (ABMoE) comprised of sets of ABETB. Additionally, as shown inFIG. 15, Global d-Bourse serves as a liquidity provider engaged in BCS-based matching of practically opposite assets underlying physically-settled WAB set ETD contracts; serves as an automated market data provider of continuously updated standalone and BCS-based “all-in” bids, offers, and executed orders for WAB, CDI, and FPDDI contracts, as well as for ABETB, ABMoE, and DABMoE, thereby facilitating efficient price discovery; and serves as a provider of BCS-based algorithms applied to the forgoing, the net cumulative effects of which transform WAB set contracts to “all-in” market price indications for respective assets qualifying as underlying members of (i) ABETB and (ii) inventories managed and controlled to meet Exchange Affiliates-wide commitments for physically settled spot, forward, and ABETB asset-cycling transactions.

Additionally, integrating Global d-Bourse with GLEBS' already-patented platforms/ECN's yields an exclusive game-changing hybrid paradigm leveraging multi-market price discoveries to optimize all-in BCS-based price liquidity. The hybrid paradigm comprises digitizing (i.e., securitizing+tokenizing) and managing varying-yet-fungible and cyclable physical asset-backed units, baskets (distinct alternatives to ETF's backed by futures contracts—e.g., “USO” criticized for exacerbating recent oil market dislocation), and mediums of exchange (DABMoE) that can be financed by repurchase agreements or other debt instruments in special purpose vehicles. The hybrid paradigm further comprises managing the physical assets' price volatility risks via GLEBS' diverse ETD hedging solutions.

DABMoE can transform a nascent field that's been dominated to date by native cryptocurrency payment systems (i.e., Bitcoin) and thousands of so-called utility tokens (the latter, called “altcoins”, using funds raised from initial coin offerings or “ICO's”) since those competitors tend to lack backing of substantive assets other than fiat currencies, and their IT and social networking platforms.

Bitcoin and altcoins disregard many trillions of dollars of tangible assets, held globally, in storage facilities or investment venues. Many underutilized fungible assets are ripe for formulation into diversified weighted average DABMoE baskets that can be securitized into units of ownership made eligible for use and trading by wholesale customers over a variety of Global e-Bourse Suites platforms, as well as retail customers of external cryptocurrency exchanges (and related wallet and payment processing apps).

Until now, many real-world assets have been difficult to physically manage, control and subdivide to accommodate ownership by multiple investors. Conventional financialized futures linked to arbitrary single-form benchmarks (requiring monthly rolling) are not suited for truly substantive securitized tokens. Conversely, GLEBS' core inventions enable traders to overcome such challenges by uniformly employing exchange-based systems, methods, and standardized instruments that can be extended to the tradable assets comprising diverse DABMoE baskets, all designed to facilitate security, speed, and efficiency that is needed for optimal securitization and tokenization.

The investment field at large can benefit by Global d-Bourse working in cooperation with GLEBS' ETD platforms to help unlock values for many trillions of dollars of illiquid and otherwise under-utilized assets underpinning DABMoE unitary ownership interests and cryptocurrency tokens as they are bought, sold and traded in fractional shares transparently price-discovered over secondary markets—all taking place securely over centralized ECN. Attendant transaction costs can be minimized by way of the synergy created with GLEBS' other platforms.

Regarding security, ECN cryptography assures all key facets of Customized Permissioned Ledgers (“CPL”). Since Bitcoin going mainstream in years 2008-2009, Blockchain—today, a generic term for the type of technology solutions initially providing Bitcoin's cryptocurrency functionality—has gained increasing notoriety in media outlets, globally, not to mention IT investment spending. Today's fintech space features a variety of ledger system developers (e.g., consortiums like Digital Asset Holdings, R3 Corda, JP Morgan's Quorum; Ripple's payment protocol in the U.S. and others in Asia and Europe) vying to provide Blockchain-like solutions. With transactions, contracts, and other information maintained in databases consensually shared and synchronized over networks spread across multiple sites, institutions and geography, such ledger systems aim to eliminate needs for single/central authorities to keep a check against manipulation. Vying systems must interoperate and comply with standard policies before digital ledger technologies can be successfully exploited globally.

GLEBS' art in this field does not emulate existing decentralized crypto-currency solutions. Rather, it provides CPL solutions specifically attuned to ECN's that employs GLEBS' synergistic ETD systems, methods, and instruments. The following is a synopsis of the CPL solutions: (1) Privacy of transactional data shared with COI is critically important; (2) Data is securely and accurately produced and stored using cryptography; (3) Access involves authentication using keys and cryptographic signatures; and (4) Once stored, all the data is part of an immutable database governed by rules of the ECN.

Under GLEBS' security design, ECN and CPL would be very difficult to intrude—to succeed, all network copies shared with authorized COI nodes would have to be attacked simultaneously—and records would be resistant to malicious changes by any single party. Post-trade processing—where an exchange and its COI compare/approve transaction details; change ownership and custodial records; and arrange for asset and cash transfers—can take place efficiently and economically via the CPL system.

At this stage, if CPL processes, preceding what is termed “post-trade,” have not completely converged with low latency connectivity provided by current-day exchanges to optimize high-frequency trading, qualifying traders can merely (i) accumulate financially settled ETD positions (i.e., their “open interest”) via the exchange's existing low-latency connection and (ii) convert the positions to the required number of EFP contracts called for under the circumstances by using different-yet-efficient ECN connectivity that is compatible with the CPL needs of its COI members. Transitional processes can also take place whereby certain existing conventional ETD contracts (such as for WTI or Brent crude oil futures) get “grandfathered” pursuant to a conversion algorithm that comports with GLEBS' applicable BCS-based solutions.

Micro-segmentation (“μSeg”) is an option that can help customize and secure permissioned ledger systems employed over Global e-Bourse Suites' ECN. μSeg has become widely recognized as an efficient means of delivering operational agility for network virtualization that is foundational to modern software-defined data center networks. It is increasingly employed in cloud solutions provided by Amazon, Microsoft, VMware, IBM, etc. Agnostic solutions (e.g., Unisys Stealth) offer advanced cryptographic functionality.

μSeg can keep different parts of Global e-Bourse Suites platforms logically separate via hardware and/or software (defined in above patents as “dongles”) encrypted to maximize security of all authenticated network devices while also controlling (i) access to the ECN, (ii) what data is made available to each server over the ECN, (iii) where data is stored, and (iv) who manages various storage needs within the ECN's defined communities of interest (“COI”).

μSeg also enables buy and sell orders to be cryptographically authenticated, posted and ultimately matched, executed, and confirmed as trades to be cleared, settled, and reported over ECN in compliance with policies and rules established by the exchange; all accomplishable contemporaneously without use of intermediaries in the chain of communications. Globally compliant cryptography systems—a list which is growing—can be used to effectuate and protect each CPL.

μSeg implementation involves loading software to ECN devices, with a management console typically coupled with bits of code that run on IP devices in the ECN. Together, they allow the exchange to layer on controls that decide who gets to do what, and easily enforce those rules at the network packet level.

μSeg is identity driven, straight from Active Directory or LDAP systems already in place. It can simply/quickly take control of new or existing enterprises—which will help legacy systems be efficiently transitioned—without the need to deal with challenges like firewall rules, outdated applications, remote users, cloud-based services and 3^rdparty attack vectors.

An example of an implementation of the ABETB-centric order matching system is now described with reference toFIGS. 1A-5.FIGS. 1A-2 show unique data structures of the ABETB-centric order matching system according to the present disclosure. For example, the ABETB-centric order matching system can be implemented on a server (e.g.,server130 shown inFIGS. 3-5 and described below). The data structures improve the functioning of the server implementing a database generally and improve the functioning of the database specifically. The functioning of the server and the database is improved by using a unique referential relationship between the data structures in ways that did not exist in prior art systems and that are faster and more efficient than the prior art systems.

The referential relationship between the data structures significantly reduces storage capacity and processing time associated with the database, particularly when the number of tradeable assets is relatively very large. As explained below, the referential relationship simplifies the operation of the database due to automatic updating of attributes of assets stored in a first data structure in real time as a stream of trading data modifies fields of a second data structure that are referentially related to the first data structure. Normally many individual calculations and aggregation of results of those calculations would be necessary, which is obviated by the referential relationship between the two data structures, and which allows for real time updating of attributes and valuations of the assets.

FIGS. 1A and 1B show an example of Asset-Backed Exchange Traded Baskets (ABETB's) according to the present disclosure. In general, a plurality of ABETB's comprise a plurality of fungible assets. For example, a first ABETB, shown as ABETB-110-1, may comprise fungible assets Asset-120-1, Asset-220-2, . . . , and Asset-N20-N (collectively assets20), where N is a positive integer. A second ABETB, shown as ABETB-210-2, may comprise fungible assets Asset-120-1, Asset-220-2, . . . , and Asset-N20-N (collectively assets20), where N is a positive integer. An Nth ABETB, shown as ABETB-N10-N, may comprise fungible assets Asset-120-1, Asset-220-2, . . . , and Asset-N20-N (collectively assets20), where N is an arbitrary integer greater than or equal to 1. The ABETB's ABETB-110-1, ABETB-210-2, . . . , ABETB-N10-N, where N is an arbitrary integer greater than or equal to 1, may be collectively called ABETB's10. While each ABETB10 is shown as including thesame assets20, each ABETB10 can include different assets. Further, each ABETB10 can include different quantities of each of the assets.

FIG. 1B shows one of the ABETB's10 (e.g., the ABETB-N10-N) in further detail. Each of the ABETB's10 may have similar composition. For example, theABETB10 includes theassets20. Eachasset20 has a plurality of attributes, which are shown as Attribute-130-1, Attribute-230-2, . . . , and Attribute-n30-n(collectively attributes30), where n is an arbitrary integer greater than or equal to 1. While eachasset20 is shown as including thesame attributes30, eachasset20 can include different attributes. Further, eachasset20 can include different number of attributes. Thus, each ABETB10 is a data structure comprising fields associated withassets20 and subfields associated withattributes30 of theassets20.

FIG. 2 shows adatabase40 comprising first and

second data structures

50,60 according to the present disclosure. For example, thedatabase40 may be implemented as one of thedatabases188 shown inFIGS. 3-5. Thefirst data structure50 stores theattributes30 of theassets20 of the ABETB's10. Thesecond data structure60 comprises a plurality fields62-1,62-2, . . . , and62-N (collectively fields62), where N is an arbitrary integer greater than or equal to 1. The fields62 in thesecond data structure60 are referentially related to theattributes30 of theassets20 of the ABETB's10 stored in thefirst data structure50.

As a data stream comprising trading data associated with theassets20 is received in the database40 (e.g., via a distributedcommunications system110 shown inFIGS. 3-5), one or more of the fields62 in thesecond data structure60 are modified by the trading data in real time. A change in one or more of the fields62 in thesecond data structure60 automatically and contemporaneously updates one ormore attributes30 of one or more of theassets20 in the one or more ABETB's10 due to the referential relationship between the fields62 in thesecond data structure60 and theattributes30 of theassets20 of the ABETB's10 stored in thefirst data structure50.

The referential relationship between the second and

first data structures

60,50 significantly reduces storage capacity and processing time, particularly when the number ofunderlying assets20 in the ABETB's10 are numerous. The referential relationship simplifies the operation of thedatabase40 due to the automatic updating of thefirst data structure50 in real time as the stream of data modifies thesecond data structure60. Normally many individual calculations and aggregation of results of those calculations would be necessary, which is obviated by the referential relationship between the two

data structures

50,60, and which allows for real time updating of theattributes30 and valuations of theassets20.

Thus, the referential relationship between the two

data structures

50,60 improves the functioning of the server implementing thedatabase40 generally and improves the functioning of thedatabase40 specifically. The functioning of the server and thedatabase40 is improved by using the referential relationship between the two

data structures

50,60 in ways that did not exist in prior art systems and that are faster and more efficient than the prior art systems.

Accordingly, a server (e.g.,server130 shown and described below with reference toFIGS. 3-5) connected to a network (e.g., distributedcommunications system110 shown and described below with reference toFIGS. 3-5) may implement the ABETB-centric order matching system and may generate a database (e.g., one of thedatabases188 shown and described below with reference toFIGS. 3-5) similar to thedatabase40. Thedatabase188 may comprise thefirst data structure50 configured to storeattributes30 offungible assets20, where theattributes30 determine market values of thefungible assets20. Thedatabase188 comprises thesecond data structure60 having fields62 referentially related to theattributes30 stored in thefirst data structure50 such that a change in any one of the fields62 induces a change in real time in a corresponding one of theattributes30 in thefirst data structure50.

Theserver130 can receive a stream of data regarding one or more of theattributes30 of thefungible assets20 from thenetwork110. Theserver130 can modify one or more of the fields62 of thesecond data structure60 based on the stream of data received from thenetwork110. Theserver130 can allow at least one of cycling, liquidating, and replenishing of one or more of thefungible assets20 associated with thefirst data structure50 based on the modified one or more fields62 of thesecond data structure60. Theserver130 can maintain a relative value equivalence of thefungible assets20 based on the at least one of cycling, liquidating, and replenishing of the one or more of thefungible assets20 associated with thefirst data structure50.

Theserver130 maintains a plurality of baskets of thefungible assets20 in the form of data structures in a database (e.g.,database188 shown inFIGS. 3-5). Thus, each ABETB is a data structure stored in the database, and each ABMoE generated by theserver130 based on the ABETB's is also a data structure stored in the database. It follows that the DABMoE's generated by theserver130 based on the ABMoE's are also data structures. All of these data structures—the ABETB's, the ABMoE's, and the DABMoE's—are referentially related to thesecond data structure60 and are therefore automatically updated based on modifications to the fields62 of thesecond data structure60 made by the trading data received by theserver130 in real time.

FIG. 3 shows a simplified example of a distributedcomputing system100 that can be used by the ABETB-centric order matching system according to the present disclosure. Thesystem100 includes a distributedcommunications system110, one or more client devices120-1,120-2, . . . , and120-M (collectively, client devices120), and one or more servers130-1,130-2, . . . , and130-N (collectively, servers130). M and N are integers greater than or equal to one. The distributedcommunications system110 may include a local area network (LAN), a wide area network (WAN) such as the Internet, or other type of network. Theclient devices120 and theservers130 may be located at different geographical locations and communicate with each other via the distributedcommunications system110. Theclient devices120 and theservers130 may connect to the distributedcommunications system110 using wireless and/or wired connections.

For example, theclient devices120 may include smartphones, personal digital assistants (PDAs), tablets, laptop computers, personal computers (PCs), etc. For example, the clients of the ABETB-centric order matching system may use theclient devices120 to interact with the ABETB-centric order matching system via the distributedcommunications system110. For example, theclient devices120 may implement the devices used for trading by traders at various financial institutions (e.g., seeFIG. 16). The client devices120 (e.g., clients' mobile phones and/or laptops, the POS system70, and the recycling machines14) may execute suitable applications (shown asclient applications166 inFIG. 4) to perform respective functions (e.g., trading) by interacting with the ABETB-centric order matching system implemented on one ormore servers130 via the distributedcommunications system110.

One or more of theservers130 may implement the ABETB-centric order matching system. Theservers130 may provide multiple services to theclient devices120. For example, theservers130 may execute software applications developed by one or more vendors (shown asapplications186 inFIG. 5). Theservers130 may host multiple databases (shown as188 inFIG. 5) that are relied on by the software applications and the ABETB-centric order matching system in providing services to users of the client devices120 (e.g., clients' mobile phones and/or laptops). Theservers130 implementing ABETB-centric order matching system may be implemented in a cloud. For example, the software applications executed by theservers130 to implement the ABETB-centric order matching system may be distributed as software-as-a-service (SaaS).

FIG. 4 shows a simplified example of the client device120-1. As mentioned above, the client device120-1 may be any one of the clients' mobile phones and/or laptops. The client device120-1 may typically include a central processing unit (CPU) orprocessor150, one or more input devices152 (e.g., a keypad, touchpad, mouse, touchscreen, scanner, etc.), one or more output devices153 (e.g., a dispenser to dispense cash, coupons, receipts, etc. when the client device120-1 is the recycling machine14), adisplay subsystem154 including adisplay156, anetwork interface158,memory160, andbulk storage162.

Thenetwork interface158 connects the client device120-1 to the distributedcomputing system100 via the distributedcommunications system110. For example, thenetwork interface158 may include a wired interface (e.g., an Ethernet interface) and/or a wireless interface (e.g., a Wi-Fi, Bluetooth, near field communication (NFC), or other wireless interface). Thenetwork interface158 connects the client device120-1 to the distributedcommunications system110 via adongle159, which is described below in detail. Thememory160 may include volatile or nonvolatile memory, cache, or other type of memory. Thebulk storage162 may include flash memory, a magnetic hard disk drive (HDD), and other bulk storage devices.

Theprocessor150 of the client device120-1 executes an operating system (OS)164 and one ormore client applications166. Theclient applications166 include an application that accesses theservers130 via the distributedcommunications system110. For example, theclient applications166 may include mobile apps that theclient devices120 can use to interact with the ABETB-centric order matching system.

FIG. 5 shows a simplified example of the server130-1. As mentioned above, the server130-1 may implement the ABETB-centric order matching system. The server130-1 typically includes one or more CPUs orprocessors170, anetwork interface178,memory180, andbulk storage182. In some implementations, the server130-1 may be a general-purpose server and include one or more input devices172 (e.g., a keypad, touchpad, mouse, and so on) and adisplay subsystem174 including adisplay176.

Thenetwork interface178 connects the server130-1 to the distributedcommunications system110. For example, thenetwork interface178 may include a wired interface (e.g., an Ethernet interface) and/or a wireless interface (e.g., a Wi-Fi, Bluetooth, near field communication (NFC), or other wireless interface). Thenetwork interface178 connects the server130-1 to the distributedcommunications system110 via adongle179, which is described below in detail. Thememory180 may include volatile or nonvolatile memory, cache, or other type of memory. Thebulk storage182 may include flash memory, one or more magnetic hard disk drives (HDDs), or other bulk storage devices.

Theprocessor170 of the server130-1 executes an operating system (OS)184 and one ormore server applications186, which may be housed in a virtual machine hypervisor or containerized architecture, which include the reward system16. Thebulk storage182 may store one ormore databases188 that store data structures used by theserver applications186 to perform respective functions. For example, theserver applications186 may perform the functions of the ABETB-centric order matching system. Theserver applications186 may include the methods shown and described below with reference toFIGS. 6-14. Thedatabases188 comprise thedatabase40 comprising the first and

second data structures

50,60 shown and described above with reference toFIGS. 1A, 1B, and 2. Thus, the one ormore servers130, the one ormore server applications186, the one ormore databases188 comprising the

data structures

50,60 collectively implement the ABETB-centric order matching system.

FIGS. 6-14 show various methods performed by the ABETB-centric order matching system implemented on theserver130. The methods describe the operations and functions of the ABETB-centric order matching system implemented on theserver130 using theserver applications186, which includes these methods, and using thedatabases188, which include thedatabase40. The term control referenced in the methods below refers to theprocessor170 of theserver130 shown and described above with reference toFIGS. 3-5, which executes theserver applications186 using thedatabases188 and implements the ABETB-centric order matching system.

FIG. 6 shows amethod200 for automatically updating attributes of fungible assets according to the present disclosure. At202, control generates a database comprising two data structures that allow automatically updating the attributes of the fungible assets according to the present disclosure. The two data structures include a first data structure and a second data structure. The first data structure stores the attributes of the fungible assets. The second data structure includes fields that are referentially related to the attributes of the fungible assets stored in the first data structure. For example, see thedatabase40 and the first and

second data structures

50,60 shown and described above with reference toFIGS. 1A-2.

At204, control receives a stream of data regarding trades of one or more of the fungible assets over the network. At206, control modifies one or more fields of the second data structure based on the stream of data received over the network. At208, control automatically changes one or more of the attributes of the one or more fungible assets in the first data structure. The modification of one or more fields of the second data structure based on the received stream of data induces automatic changes to one or more attributes of the one or more fungible assets in the first data structure.

FIG. 7 shows amethod220 for maintaining a relative value equivalence of the fungible assets according to the present disclosure. At222, control generates a database comprising two data structures that allow automatically updating the attributes of the fungible assets according to the present disclosure. The two data structures include a first data structure and a second data structure. The first data structure stores the attributes of the fungible assets. The second data structure includes fields that are referentially related to the attributes of the fungible assets stored in the first data structure. For example, see thedatabase40 and the first and

second data structures

50,60 shown and described above with reference toFIGS. 1A-2.

At224, control receives a stream of data regarding trades of one or more of the fungible assets over the network. At226, control modifies one or more fields of the second data structure based on the stream of data received over the network. At228, control automatically changes/updates one or more of the attributes of the one or more fungible assets in the first data structure. The modification of one or more fields of the second data structure based on the received stream of data induces automatic changes to one or more attributes of the one or more fungible assets in the first data structure. At230, control maintains a relative value equivalence of the fungible assets regardless of the trades.

FIG. 8 shows amethod250 for maintaining a relative value equivalence of the fungible assets according to the present disclosure. At252, control generates a database comprising two data structures that allow automatically updating the attributes of the fungible assets according to the present disclosure. The two data structures include a first data structure and a second data structure. The first data structure stores the attributes of the fungible assets. The second data structure includes fields that are referentially related to the attributes of the fungible assets stored in the first data structure. For example, see thedatabase40 and the first and

second data structures

50,60 shown and described above with reference toFIGS. 1A-2.

At254, control receives a stream of data regarding trades of one or more of the fungible assets over the network. At256, control modifies one or more fields of the second data structure based on the stream of data received over the network. At258, control automatically changes one or more of the attributes of the one or more fungible assets in the first data structure. The modification of one or more fields of the second data structure based on the received stream of data induces automatic changes to one or more attributes of the one or more fungible assets in the first data structure.

At260, control allows at least one of cycling, liquidating, and replenishing of one or more of the fungible assets. At262, control maintains a relative value equivalence of the fungible assets regardless of the cycling, liquidating, and replenishing of one or more of the fungible assets.

FIG. 9 shows amethod300 for automatically updating attributes of fungible assets across a set of baskets (e.g., ABETB's) comprising the fungible assets according to the present disclosure. At302, control maintains a set of baskets of fungible assets in a database. At304, control generates in the database two data structures that allow automatically updating the attributes of the fungible assets according to the present disclosure. The two data structures include a first data structure and a second data structure. The first data structure stores the attributes of the fungible assets. The second data structure includes fields that are referentially related to the attributes of the fungible assets stored in the first data structure. For example, see thedatabase40 and the first and

second data structures

50,60 shown and described above with reference toFIGS. 1A-2.

At306, control receives a stream of data regarding trades of one or more of the fungible assets over the network. At308, control modifies one or more fields of the second data structure based on the stream of data received over the network. At310, control automatically changes one or more of the attributes of the one or more fungible assets in the first data structure and across the set of baskets. The modification of one or more fields of the second data structure based on the received stream of data induces automatic changes to one or more attributes of the one or more fungible assets in the first data structure and across the set of baskets.

FIG. 10 shows amethod320 for matching buy and sell orders according to the present disclosure. At322, control maintains a set of baskets (e.g., ABETB's) of fungible assets in a database. For example, see thedatabase40 and the first and

second data structures

50,60 shown and described above with reference toFIGS. 1A-2. At324, control automatically updates one or more attributes of the one or more fungible assets across the baskets by using referential data structures in the database based on a stream of data received regarding trades of one or more of the fungible assets over the network. At326, control receives buy and sell orders over the network from counterparties for trading one or more of fungible assets in the baskets. At328, control matches the orders based on practically opposite rather than absolute opposite trading interests of the counterparties while maintaining a relative value equivalence the fungible assets in the baskets.

FIG. 11 shows amethod350 for generating a weighted average benchmark for matching buy and sell orders based on practically opposite rather than absolute opposite trading interests of counterparties according to the present disclosure. At352, control maintains a set of baskets (e.g., ABETB's) of fungible assets in a database. For example, see thedatabase40 and the first and

second data structures

50,60 shown and described above with reference toFIGS. 1A-2. At354, control generates a weighted average benchmark based on characteristics of a plurality of asset forms of one or more of the fungible assets. At356, control receives buy and sell orders over the network from counterparties for trading one or more of fungible assets in the baskets. At358, using the benchmark, control matches the orders based on practically opposite rather than absolute opposite trading interests of the counterparties while maintaining a relative value equivalence the fungible assets in the baskets.

FIG. 12 shows amethod370 for ensuring that buy and sell orders comply with Sharia law according to the present disclosure. At372, control maintains a set of baskets (e.g., ABETB's) of fungible assets in a database. For example, see thedatabase40 and the first and

second data structures

50,60 shown and described above with reference toFIGS. 1A-2. At374, control receives buy and sell orders over the network from counterparties for trading one or more of fungible assets in the baskets. At376, control determines whether the buy and sell orders comply with the requirements of Sharia law. Control proceeds to380 if the buy and sell orders comply with the requirements of Sharia law. If the buy and sell orders do not comply with Sharia law, at380, control aligns the buy and sell orders with the requirements of Sharia law as described in detail in U.S. Pat. No. 10,269,070, which is incorporated herein by reference in its entirety. At380, control matches the orders based on practically opposite rather than absolute opposite trading interests of the counterparties while maintaining a relative value equivalence the fungible assets in the baskets.

FIG. 13 shows amethod400 for generating, securitizing, and tokenizing a medium of exchange for trading fungible assets according to the present disclosure. At402, control maintains a set of baskets (e.g., ABETB's) of fungible assets in a database. For example, see thedatabase40 and the first and

second data structures

50,60 shown and described above with reference toFIGS. 1A-2. At404, control generates a medium of exchange (e.g., ABMoE) based on the set of baskets of the fungible assets in the database and generates a digitized medium of exchange (e.g., DABMoE) therefrom. At406, control securitizes and tokenize the digitized medium of exchange for trading the fungible assets.

FIG. 14 shows amethod420 for providing secure transactions between devices used for trading fungible assets across a network (e.g.,element110 shown inFIGS. 3-5) according to the present disclosure. Each device (e.g., aserver130 orclient device120 shown inFIGS. 3-5) on the network includes a dongle described herein and performs the method described herein. The dongle is described in detail in U.S. Pat. No. 10,269,070, which is incorporated herein by reference in its entirety. At422, control secures data transfers between the device and the network via a dongle connected to the device. At424, control authenticates access to the server via the dongle connected to the server. At426, control provides transformational data protection via encryption that adds authentication and fault-tolerant information to data transfers between the server and the network.

FIG. 15 shows the multiple dimensions impacting data structures developed around BCS-based hybrid paradigm according to the present disclosure, which include the following: Physical assets (e.g., spots and forwards over conventional, Sharia-based and countertrade platforms); Financialized assets (e.g., futures and options over conventional exchange-traded derivatives platforms); Digitized assets (e.g., repos for asset financing; ABMoE for barter, and countertrade and other wholesale exchange-based settlements; and DABMoE for cryptocurrencies and other retail exchange-traded products); Order matching and execution directly over one exchange platform or via back-to-back order executions entailing multiple markets and platforms; and so on.

FIG. 16 shows the operations performed by an exchange502 (i.e., by a server at theexchange502; e.g., theserver130 shown inFIGS. 3-5) in an ABETB-centric order matching system500 according to the present disclosure. The system500 comprises theexchange502 that allows trading of various assets according to the ABETB-centric order matching system500 of the present disclosure. Examples of the assets include tradeable assets fromauthorized COI504, tradeable assets from affiliatedglobal e-Souks506, tradeable assets from affiliatedglobal e-counter508, tradeable assets from affiliatedglobal e-bourses510, and tradeable assets from affiliatedglobal e-credit512. Theexchange502 segregates, manages, and controlsasset inventories514. Additional assets handled by the exchange include currencies including the U.S. dollar and othernational currencies516.

Theexchange502 generates ABETB (commodities)518 and ABETB (credit instruments)520 as described above. The ABETB (commodities)518 includes commodity-based ETF's522 tradeable in secondary markets. The ABETB (credit instruments)520 includes credit-based ETF's524 tradeable in secondary markets. Theexchange502 generatesABMoE526 based on ABETB (commodities)518 and ABETB (credit instruments)520 as described above. Theexchange502 generatesDABMoE528 andWAB DABMoE530 as described above.

TheExchange502 formulates ABETB's518,520 for product offerings in their own right or as components ofABMoE526, whereby baskets emulate BCS-based WAB Sets, each underpinned by a specified plurality of fungible assets having varying quantitative, qualitative, logistics and settlement timing properties. Theexchange502 acts cooperatively in an organization of Exchange Affiliates506-512, their customers andrespective COI504, with fully automated multi-faceted order matching systems employed by integrated computerized trading platforms to optimize organization-wide liquidity by cross-listing products and effectuating back-to-back order executions, as needed, to match practically opposite orders for qualifying assets in ABETB and related Managed andControlled Inventories514, all predicated on BCS.

Theexchange502 exercises constructive management and control over assets acquired and stored as inventories that can be used in the future to satisfy physical delivery commitments to ETD and other platforms affiliated with theexchange502, including those assets qualified to underpin ABETB. Theexchange502 exercises constructive management and control over those qualified assets cycled in and out of ABETB and related inventories, in a manner that consistently maintains market value equivalence as practically, rather than absolute, opposite assets are interchanged based on BCS.

Theexchange502 continuously maintains a transactional database encompassing all Exchange and Affiliates' ETD contract market prices linked to cash-settled and physically-settled WAB's and Differential Indexes attendant to EFP spots and forwards, as well as futures, options and swaps. Theexchange502 employs algorithms to determine which Complementary and Forward Point Delivery Differential Indexes should be used to determine the extent to which cash adjustments must be paid or received as part of physically-settled spot, forward, and asset cycling transactions. Theexchange502 otherwise acts as a liquidity provider engaged in BCS-based order matching processes.

The following paragraphs specifically capture the features of the ABETB-centric order matching system according to the present disclosure. A computer implemented asset-backed Exchange-traded basket (“ABETB”)-centric order matching system employing multifaceted “all-in” price discovery processes predicated on synergies derived from a Benchmark Complex Solutions (“BCS”)-based hybrid paradigm formed to satisfy counterparties' practically, rather than absolute, opposite physical trading and hedging interests and create essential gains in multi-market liquidity over an integrated network of Exchange Affiliates' trading platforms engaged to cooperatively maintain contemporaneous ABETB-wide market value equilibrium as all cross-listed instruments attendant to the basket's underlying assets are continuously impacted by price movements throughout each trading day, wherein:

ABETB's are comprised of Exchange-specified baskets, emulating Weighted Average Benchmark (“WAB”) Sets linked to Exchange-traded derivatives (“ETD”), in each case underpinned by a plurality of fungible assets having varying quantitative, qualitative, logistics and settlement timing properties whose respective impacts on relative asset value are transparently discoverable via BCS-based Differential Index ETD contracts, the requisite quantities of which are determined by computer implemented algorithms formulated to uniformly maintain equilibrium within the context of macro-level ABETB-wide price movements emulating the operative WAB's micro-level price movements;

customer orders posted throughout an organization of Exchange Affiliates are amalgamated to enhance practically opposite asset matching prospects benefitting spot market buying and selling, repurchase agreement (“repo”) based financing, exchange-traded derivatives (“ETD”) based hedging, and asset cycling-based basket replenishment drawing from the Exchange's segregated, managed and controlled inventories available to underpin ABETB, all of which together, provide synergistic multi-market gains in liquidity throughout the organization of Exchange Affiliates;

transparent gains in liquidity attendant to WAB's and Differential Indexes collectively support continuous streams of “all-in” market price discovery required to contemporaneously maintain relative value equivalence for each qualifying asset among those underpinning an ABETB, and the contents of Exchange managed and controlled inventories, iterative processes incenting counterparty migration toward settling even larger volumes and wider swaths of orders throughout all Exchange Affiliates by physical delivery and receipt; and

all essential aspects of multifaceted ABETB-centric order matching are computer implemented to occur cooperatively over trading platforms unique to an organization of Affiliated Exchanges, their customers and respective communities of interest (“COI”) via integrated cloud-powered, cryptographically-assured and dongle-enabled Exchange-controlled networks (“ECN's”) and customized permissioned ledgers (“CPL's”) dealing with a diverse range of fungible-yet-varying individual assets, ABETB's and Asset-Backed Mediums of Exchange (“ABMoE”) cross-listed via physical (i.e., spots and forwards), financialized (i.e., futures and options), securitized (i.e., repos) and tokenized (i.e., cryptocurrency) product offerings in primary and secondary markets.

In the ABETB-centric order matching system, the BCS-based counterparty matching comprises one or more Exchange Affiliates configuring weighted average benchmark (“WAB”) sets, with each set linked to an Exchange-specified plurality of qualifying asset forms, rather than arbitrarily denoting one single asset form as the benchmark for all forms of that asset. The BCS-based counterparty matching comprises one or more Exchange Affiliates identifying and factoring impact of quantitative, qualitative, logistics and settlement timing properties unique to each of the qualifying asset forms serving as a basis of a neutral WAB formulated by the Exchange for an entirety of the set.

Additionally, the BCS-based counterparty matching comprises one or more Exchange Affiliates providing a uniform method of allowances for incidences where traders own or are seeking to own varying yet interchangeable physical asset forms, each qualified as a component of an Exchange-specified set, and to offer or bid their specific asset form pursuant to standardized spot or forward EFP contracts requiring settlement by physical delivery or receipt of their respective underlying assets, with each contract's specifications linked to an operative WAB formulated by the Exchange to cover an entire set of qualified asset forms.

Further, the BCS-based counterparty matching comprises one or more Exchange Affiliates ensuring that each component in a WAB provides quantitative characteristics, plus varying qualitative, logistics and settlement timing properties customarily adding to or detracting from such asset's market value, net aggregate effects of which are balanced Exchange-wide by methods comprised of the following.

establishing benchmark-specific WAB sets, each formulated for incorporation into a family of standardized ETD contracts, including spots, forwards, futures, options and spreads, specifications of which differ only by timing and type of settlement taking place;

requiring EFP spot and forward traders to acquire an algorithm-specified number of long or short Complementary Differential Index contracts in exchange for cash paid or received, as the case may be, with said contracts linked to varying qualitative and/or logistics attributes of the underlying assets delivered or received, respectively, and to ensure co-delivery of such contracts as of an operative EFP physical delivery date;

requiring EFP spot and forward traders to acquire an algorithm-specified number of long or short Forward Point Delivery Differential Index contracts in exchange for cash paid or received, said contracts linked to negotiated timing of underlying assets delivered or received, respectively, and to ensure co-delivery of such contracts as of an operative EFP physical delivery date; and

uniformly employing the forgoing to specify, acquire, finance, store as inventory, and hedge tradable assets underpinning ABETB on a practically equivalent basis, culminating in cycled interchange of varying-yet-fungible assets qualified within ABETB to reflect the impact of qualitative, logistical, supply chain and life cycle factors unique to assets being stored and, when necessary, securitized and/or tokenized prior to the Exchange(s) meeting future delivery commitments to counterparties, thereby ensuring their ongoing role as ETD liquidity provider(s) pursuant to float process guidelines within an affiliated Exchange organization-wide inventory management and control system.

In the ABETB-centric order matching system, the ECN is controlled by an Exchange. The ECN comprises a host server controlled by the Exchange. The host server is located at a first location. The ECN comprises a plurality of front-end virtual servers communicating with the host server; located at a plurality of locations, respectively; assigned to communities of interest (“COI”) authorized by the host server; and authenticated by the host server to cryptographically validate, process, transmit, and receive pre-approved digital information passed along the ECN without using intermediaries.

The ECN comprises a plurality of dongles operating in conjunction with the respective front-end virtual servers and performing the functions comprising the following: controlling access by the front-end virtual servers to the ECN and controlling availability and storage of digital data on the front-end virtual servers; enabling the front-end virtual servers to cryptographically authenticate, post and confirm buy and sell orders for trades ultimately matched, executed, cleared, settled and reported by the host server contemporaneously over the ECN in compliance with policies and rules established by the host server, and without using intermediaries; and facilitating transformational data protection via encryption that adds authentication and fault tolerant information to the digital data.

The host server comprises a processor and memory storing machine executable instructions which when executed by the processor perform the following functions: collecting data for a plurality of tradable assets, the data including parameters accounting for qualitative, logistical, supply chain, life cycle settlement timing factors unique to the tradable assets; selecting assets from the tradable assets based on the parameters; generating, based on the selection, sets of tradable assets underlying ABETB's; generating weights based on a rate denoting estimated global commercial value of a selected tradable asset relative to aggregate estimated global commercial value of all tradable assets underlying the ABETB; generating, using the weights, weighted averages for the ABETB's; generating specifications for tradable asset baskets based on aggregate weighted averages of the selected tradable assets in a weighted average ABETB; communicating specifications for ABETB to customers and their COI; collecting, generating and communicating, as noted above, for ABMoE comprising sets of ABETB; and receiving orders for tradable assets, ABETB and ABMoE from traders and other parties via the ECN.

The host server comprises a back-to-back execution module that reserves a portion of gross segregated tradable asset inventories on hand for each type of asset, the portion optimizing: efficiency of the host server in matching practically, rather than absolutely, the bilateral trading interests of its Exchange Affiliates' counterparties to physically settle their outstanding derivatives orders over a projected future time frame; and ability of the host server to substitute different varying-yet-fungible and cyclable tradable asset forms while managing individual traded assets, ABETB and ABMoE.

In the ABETB-centric order matching system, the tradable assets comprise at least one of the following types: any commodity produced for global consumption and having varying quality, logistics and settlement timing properties or attributes that impact a market place value of the asset; any credit or other financial instrument having varying quality, logistics and settlement timing properties or attributes that impact a market place value of the instrument; any national currency; and any other tradable asset that is subject to the terms of barter or countertrade transaction executed over an Exchange Affiliate's barter and countertrade platform.

In the ABETB-centric order matching system, the host server: updates the collected data periodically; updates the Exchange's specification for tradable assets, ABETB and ABMoE based on the collected and updated data; communicates specifications for tradable assets, ABETB and ABMoE to Exchange customers and their COI; works in cooperation with back-to-back execution module to acquire tradable assets from Exchange members including but not limited to asset producers, trading companies, financial institutions and investors, with such acquisitions transacted over the host server via cash payments, issuance of one or more Exchange memberships, issuance of ABETB and/or ABMoE ownership interests; and works in cooperation with back-to-back execution module to acquire, segregate, manage and control inventories of qualifying tradable assets for purposes of replenishing ABETB's while satisfying the diverse needs of all Exchange and Affiliates counterparties' spot and forward physically-settled trading interests.

In the ABETB-centric order matching system, the ECN is in communication with at least one of a wide area network and the Internet. The ECN further comprises a server in communication with a computing device used by the COI via the at least one of the wide area network and the Internet.

In the ABETB-centric order matching system, the ABETB's are single asset baskets designed to emulate WAB Sets linked to Exchange-specified fungible-yet-varying assets, wherein each asset in an ABETB is uniformly valued “all in” at the operative WAB Set market price±adjustments linked to market prices transparently discovered in connection with cash-settled Complementary and Forward Point Delivery Differential Indexes applicable under the circumstances.

The ABETB's are sets of single asset baskets comprising more diversified offerings, such as the ABMoE developed for barter and countertrade platform disclosed in U.S. Pat. No. 9,460,470, and upon being securitized and tokenized, Digitized ABMoE formulated to inter alia provide secondary cryptocurrency markets with substantive alternatives to Bitcoin and altcoins in the field.

The ABETB's are structured to allow each of a single asset basket's contents to be cycled in and out in exchange for other basket qualifiers as part of a system that practically, rather than absolutely, offsets their respective equivalent values by adjusting the prevailing market price of an operative WAB Set higher or lower to uniformly reflect the impact of applicable Differential Indexes' market prices, each and all of the aforementioned prices discovered continuously each trading day over transparent computerized trading platforms serving an organization of Affiliated Exchanges via integrated ECN and CPL, as elucidated in U.S. Pat. Nos. 9,002,741, 9,460,470, 10,269,070, and 10,515,115.

In the ABETB-centric order matching system, a back-to-back execution module amalgamates all Exchange Affiliates' customer bids and offers for ultimate execution at the host server pursuant to a cross-liquidity process factoring order flow of each Exchange trading platform and triggers, when necessary, back-to-back executions satisfying the needs of an ABETB that is being formulated for trading or replenished, whereby: the Exchange becomes a counterparty to the ABETB's required bid or offer; and the host server then posts an offsetting offer or bid of the Exchange, which upon processing by the back-to-back execution module becomes a committed component of the ABETB or Exchange managed and controlled inventories segregated for the sake of providing future liquidity satisfying the needs of all products cross-listed within the organization of Affiliated Exchanges.

In the ABETB-centric order matching system, the host server employs inventory management and control systems supporting gross and net segregated tradable assets qualified for present and future inclusion in an ABETB, with such systems employing at least private and public warehouse receipts and shipping certificates that can be reconciled with all tradable assets underpinning the ABETB's present and future composition.

In the ABETB-centric order matching system, the authorized COI includes at least one of: wholesale commercial and speculator customers of the Exchange; introducing brokers; non-clearing commercial merchants; clearing members of the Exchange or its Exchange Affiliates; non-clearing members of the Exchange or its Exchange Affiliates; one or more tradable asset inventory control and logistics service providers authorized by the host server; one or more tradable asset securitization and/or tokenization service providers authorized by the host server; one or more clearinghouses either affiliated with the Exchange or independently contracted; one or more trade reporting service firms; and one or more independent regulatory bodies charged with oversight responsibility in connection with the conduct of the Exchange's trading markets.

The ABETB-centric order matching system comprises counterparty matching processes for affiliated computerized trading platforms dealing with commodities, each qualified as a member of an Exchange-formulated basket of varying-yet-fungible commodity forms comprising an ABETB that can be offered as an alternative to certain conventional ETF's and other financial products. The trading party types are denoted by each respective party at its dongle-enabled sign-in, including the following: Commodity Producers (Sellers) as wholesale customers of the Exchange; Commodity Users (Buyers) as wholesale customers of the Exchange; Exchange Market Makers (covering Buy and Sell sides), including those that are clearing and non-clearing members of the Exchange; Commodity Trading Firms (covering Buy and Sell sides), including those that are clearing and non-clearing members of the Exchange; and Global d-Bourse (covering Buy and Sell sides), on behalf of the Exchange, cooperatively engaging with Affiliated Exchanges to perform the following functions:

formulate WAB Sets specified for each ABETB and ABMoE; enhance Exchange affiliate-wide liquidity by cross-listing ABETB products over multiple platforms to effectuate back-to-back order executions; exercise constructive management and control over assets acquired and stored prior to their use to satisfy physical delivery commitments to ETD and other trading platforms in the affiliated Exchange organization, including assets underpinning ABETB; exercise constructive management and control over assets cycled in and out of ABETB in a manner that contemporaneously maintains “all-in” market value equivalence for each qualifying asset while practically, rather than absolutely, opposite assets are interchanged; maintaining a transactional data base encompassing “all-in” bids and offers attendant to cash-settled and physically-settled ETD contract market prices, Exchange Affiliate-wide, including EFP spots and forwards, futures, options and swaps linked to an operative WAB, and factoring the impact of BCS-based algorithms directing the extent to which Complementary and Forward Point Delivery Differential Indexes should be acquired for cash adjustments paid or received as part of asset cycling transactions; and otherwise acting as a liquidity provider engaged in BCS-based order matching processes.

The ABETB-centric order matching system comprises matching processes to fill commodity buy-side orders (iterative until a match is executed). Commodity User posts “all-in” bid data for specific commodity form (the “CUspCF”) that qualifies within a plurality of forms comprising an operative Exchange-formulated WAB Set underpinning an ABETB, with said bid data indicating desired quantity, incoterms and price, as well as Exchange confirmation that Commodity User is logistically and financially qualified to take delivery of the denoted commodity pursuant to the terms of its bid. Exchange compares Commodity User's “all-in” bid data with all-in offer data posted by Sellers, in this case, primarily Commodity Producers, Exchange Market Makers, and Commodity Trading Firms, aimed at identifying whether an absolute matching offer exists to offset against Commodity User's bid.

If no absolute matching offer (per above) emerges, Exchange inquires with Global d-Bourse to see if it is willing to sell CUspCF inventory in its possession to the Commodity User, a decision Global d-Bourse makes after determining the extent to which: required quantity of CUspCF is physically available and uncommitted pursuant to Global d-Bourse Inventory Management and Control Guidelines; and different yet practically equivalent form(s) of the commodity, also qualifying in the operative WAB Set's plurality, can be acquired to replace the CUspCF at an all-in value (i.e., amounting to prevailing market price of operative WAB set±adjustments for prevailing market prices of applicable Differential Indexes) acceptable to Global d-Bourse.

If the forgoing process still fails to result in an absolute match, Exchange informs Commodity User whether: matching “all-in” offer(s) for the CUspCF are posted, albeit at higher selling price(s), by one or more of the aforementioned Sellers; or different yet practically equivalent form(s) of the desired commodity, also qualified as a component in the WAB Set's specified plurality, are available in the quantity sought and at an “all-in” prevailing market price equivalent to that originally sought by the Commodity User with respect to CUspCF.

The ABETB-centric order matching system comprises matching processes to fill sell-side orders (iterative until a match is executed). Commodity Producer posts “all-in” offer data for a specific commodity form (the “CPspCF”) that qualifies within a plurality of forms comprising an operative Exchange-formulated WAB Set, with said data indicating desired quantity, incoterms and price, as well as Exchange confirmation that the Commodity Producer is operationally, logistically and financially qualified to make delivery of the denoted commodity pursuant to the terms of its offer. Exchange compares Commodity Producer's “all-in” offer data with bid data posted by Buyers, in this case, primarily Commodity Users, Exchange Market Makers, and Commodity Trading Firms aimed at identifying whether bid(s) can be absolutely matched with Commodity Producer's offer.

If no absolute matching bid (per above) emerges, Exchange inquires with Global d-Bourse to see if it is willing and able to buy CPspCF from the Commodity Producer for inclusion as part of tradable asset inventories under its constructive control, a decision Global d-Bourse makes pursuant to its Inventory Management and Control Guidelines. If the forgoing process still fails to result in an absolute match, Exchange informs Commodity Producer whether matching bid(s) for the CPspCF have been posted, albeit at lower “all-in” price(s), by one or more of the aforementioned Buyers.

The ABETB-centric order matching system comprises counterparty matching processes integral to affiliated Exchanges' computerized trading platforms employing BCS within an ECN customized to facilitate use of permissioned ledgers, all linked to pluralities of fungible credit instruments qualifying to underpin an ABETB that emulates an Exchange-formulated WAB Set, factoring such quantitative attributes as bond classifications, such as corporate industrials, transports, utilities and financial services, and various types of preferred stocks, leveraged loans, municipals and even Sharia-based Sukuks, and varying qualitative attributes, such as coupon rate of interest, credit quality rating, remaining time to maturity, convertibility and callability, each incorporated into an operative WAB integrated with Complementary Differential and Forward Point Delivery Differential Indexes.

The trading party types denoted for each respective party at its dongle-enabled sign-in include: Buyers of physically-settled spot and forward ETD contracts linked to individual credit instruments that qualify as components of an Exchange-formulated WAB Set; Buyers of physically-settled spot and forward ETD contracts linked to an ABETB, qualifying as a component within a plurality underpinning an ABMoE; Sellers of either of the forgoing; Exchange market makers covering both buy and sell sides; and Global d-Bourse covering both buy and sell sides.

The ABETB-centric order matching system comprises processes to fill buy side orders (iterative until a match is executed). Buyer posts “all-in” bid data for a specific credit instrument qualifying as a component of ABETB emulating an Exchange-formulated WAB Set, with said bid data including desired quantitative and qualitative properties and price. Exchange compares Buyer's “all-in” bid data with “all-in” offer data posted by Sellers for the same credit instrument, including offers by Exchange Market Makers, aimed at identifying whether an absolute matching offer exists.

If no absolute matching offer (per above) emerges, Exchange inquires with Global d-Bourse to see if it is willing and able to sell the same credit instrument from inventory in its constructive possession to the Buyer at the “all-in” bid price, a decision Global d-Bourse makes after determining whether: required quantity of the asset desired by Buyer is physically available and uncommitted per Global d-Bourse Inventory Management and Control Guidelines; and practically equivalent alternative credit instruments also qualifying within attendant WAB Set's plurality can be acquired, at satisfactory prevailing “all-in” market prices, to replace the credit instruments removed from Global d-Bourse's inventory.

If above process still fails to result in absolute match, Exchange informs Buyer whether: matching offer(s) for the desired asset is posted, albeit at higher “all-in” selling price(s), by one or more of the aforementioned Sellers; or practically equivalent form(s) of the desired asset, qualifying within the WAB Set's specified plurality, are available in the quantity and at a prevailing “all-in” market price equivalent to what was originally sought by the Buyer.

The ABETB-centric order matching system comprises processes to fill sell side orders (iterative until a match is executed). Seller posts “all-in” offer data for a specific credit Instrument security that is a qualified component of an ABETB emulating an Exchange-formulated WAB Set, with said data including desired quantitative and qualitative properties and price. Exchange compares Seller's “all-in” offer data with “all-in” bid data posted by Buyers, including Exchange Market Makers, aimed at identifying whether absolutely matching bid(s) exist.

If no absolute matching bid (per above) emerges, Exchange inquires with Global d-Bourse to see if it is willing and able to buy said securities from the Seller for inclusion as part of tradable asset inventories under its constructive control, a decision Global d-Bourse makes pursuant to its Inventory Management and Control Guidelines. If the forgoing process still fails to result in absolute match, Exchange informs Seller whether any matching bid(s) for the credit instruments have been posted, albeit at lower price(s), by one or more of the aforementioned Buyers.

In the ABETB-centric order matching system, an order for derivatives contracts based on differences between actual properties of the tradable asset to be physically delivered under the terms of an operative derivatives contract and the aggregate qualities indicated by an operative tradable asset benchmark is processed by a computer implemented algorithm employed to compute the requisite number of long or short Complementary Differential Index-based contracts valuing attendant tradable asset quality or logistics variability, with said contracts being executable for co-delivery on the operative derivatives contract's settlement date.

In the ABETB-centric order matching system, theprocessor170 uses the computer implemented algorithm to compute the requisite number of co-deliverable long or short Complementary Differential Index-based contracts, in accordance with operations employing program logic summarized below. First, the algorithm identifies the extent of a traders open long position, which is the commitment to take physical delivery of Exchange-qualified tradable asset, or the trader's short position, which is the commitment to physically deliver the Exchange-qualified tradable asset, in the operative derivatives contract, each said operative derivatives contract being denominated in a standard unit of volume.

Next, the algorithm multiplies the trader's identified open long or short derivatives contract position by a factor, related to the standard unit of volume, which is a predetermined number, times the difference between the tradable asset's quality or logistics level specified in the operative tradable asset benchmark and the actual level contained in the tradable asset to be physically received or delivered; upon solving that equation the algorithm determines the extent to which the trader must buy or sell Complementary Differential Index contracts based on the factors described as follows:

Long traders with differentials where the benchmark level is greater (i.e., more valuable) than the actual level contained in the tradable asset to be received must sell Complementary Differential Index contracts; conversely, long traders with differentials where the benchmark level is less than the actual level contained in the tradable asset to be received must buy Complementary Differential Index contracts.

Short traders with differentials where the benchmark quality or logistics level is greater (i.e., more valuable) than the actual quality level contained in the tradable asset to be delivered must buy Complementary Differential Index contracts; conversely, short traders with differentials where the benchmark quality or logistics level is less than the actual quality level contained in the tradable asset to be delivered must sell Complementary Differential Index contracts.

The algorithm multiplies the trader's identified open long or short derivatives contract by a factor, related to the standard unit of volume, which is a predetermined number, time the difference between the quality or logistics level specified in the operative tradable asset benchmark and the actual level contained in the tradable asset to be physically received or delivered; once that equation is solved, the algorithm determines the extent to which the trader must buy or sell Complementary Differential Index contracts based on the factors described as follows.

Long traders with differentials where the benchmark level is greater, that is less valuable, than the actual level contained in the tradable asset to be received, must buy Complementary Differential Index contracts; conversely, long traders with differentials where the benchmark level is less than the actual level contained in the tradable asset to be received must sell Complementary Differential Index contracts.

Short traders with differentials where the benchmark level is greater, that is less valuable, than the actual level contained in the tradable asset to be delivered, must sell Complementary Differential Index contracts; conversely, short traders with differentials where the benchmark level is less than the actual level contained in the tradable asset to be delivered must buy Complementary Differential Index contracts.

In the ABETB-centric order matching system, the Exchanges assist their counterparties via pop-up screens (e.g., graphic user interfaces) that provide information concerning what the algorithm-derived bid or offer price would be based on the last published executed trades for each of their desired pair contracts, and then gives each counterparty the ability to place an order based on that Exchange-supplied price information or another price independently selected by the counterparty.

The ABETB-centric order matching system is configured to process orders for Forward Point Delivery Differential Index derivatives contracts based on differences between the actual, desired date for the tradable asset to be delivered under the terms of an operative derivatives contract and the date indicated by an operative tradable asset benchmark, wherein the orders are processed by a processor using an algorithm employed to compute the requisite number of long or short Forward Point Delivery Differential Index-based contracts valuing the tradable asset's forward point delivery variability, with said contracts being structured for co-delivery as of the operative derivatives contract's settlement date.

In the ABETB-centric order matching system, theprocessor170 uses the algorithm to compute the requisite number of co-deliverable long or short complementary Forward Point Delivery Differential Index derivatives contracts, in accordance with operations employing program logic summarized below. First, theprocessor170, using the algorithm, identifies the extent of a trader's open long position, which is a commitment to take physical delivery of exchange-qualified tradable asset, or short position, which is a commitment to physically deliver exchange-qualified tradable asset, in the operative derivatives, and wherein the operative derivatives contract is also known as the underlying EFP contract, and wherein each said operative derivatives contract is denominated in the standard unit of volume.

Next, the processor, using the algorithm, multiplies the trader's identified open long or short underlying EFP contract position by the number of trading days forward differing between the delivery date specified in the operative tradable asset benchmark and the actual, desired date specified by the trader for the tradable asset to be physically received or delivered under the underlying EFP contract; upon solving that said equation, the algorithm determines the extent to which traders must buy or sell Forward Point Delivery Differential Index contracts based on the factors described as follows:

Long traders experiencing a contango condition in their underlying EFP contract's market, that is where forward prices exceed spot prices, must buy complementary Forward Point Delivery Differential Index contracts; conversely, long traders experiencing a backwardation condition in their underlying EFP contract's market, that is where spot prices exceed forward prices, must sell Forward Point Delivery Differential Index contracts. Short traders experiencing a contango condition in their underlying EFP contract's market must sell Forward Point Delivery Differential Index contracts. Conversely, short traders experiencing a backwardation condition in their underlying EFP's market must buy Forward Point Delivery Differential Index contracts.

In the ABETB-centric order matching system, the Exchange continuously provides prevailing “all-in” market values attributable to each tradable asset underpinning an ABETB and imputes cumulative ABETB market values, as well as cumulative ABMoE market values, by computing the sum of those underpinnings, including effects of net cash paid or received to acquire all Differential Index contracts, applicable thereto, processes which negate (or circumvent) the need to employ a conventional multi-basket ETF structure encompassing creation, redemption and holding baskets, respectively, each specifying different assets, and Authorized Parties (“AP's”) that provide liquidity whenever there is an imbalance of buy and sell orders for ETF shares selling at a premium or discount to the ETF's net asset value computed at the end of each trading day by the ETF's Fund Manager.

In addition, the ABETB-centric order matching system described above with reference toFIGS. 1A-16 can implement multiple layered encoding systems and methods to securely validate, verify, record, trace and track transactions for cryptocurrency (“CC”) specimens. These systems and methods implemented by theserver130 and theclient devices120 shown inFIG. 3 are described below in detail with reference toFIGS. 17-18.

Briefly, the CC specimens are generated by theserver130 by converting one or more digitized asset-backed mediums of exchange (“DABMoE's”) comprising one or more Asset-Backed Exchange-Traded Baskets (“ABETB's) into one or more cryptocurrency specimens. Each CC specimen may be structured for transformative fair market price-discovery processes employed to uniquely compile Cumulative Net Asset Values (“CNAV's) attendant to an operative plurality of underlying components, including but not limited to the following:

Digitized Asset-Backed Mediums of Exchange (“DABMoE”) comprising one or more Asset-Backed Exchange-Traded Baskets (“ABETB's), market prices of which are automatically discovered continuously throughout each trading day over an affiliated Exchange Network of computerized trading platforms as described above in detail with reference toFIGS. 1A-16; and relative economic appeal as an intrinsic store of value reflective of the following:

Supply and market demand vis a vis other competing CC's; networks, wallet and payment apps, trading and investment API's, and other ecosystem embodiments developed by the Exchange Network's Originator (the “Originator”) and/or its sanctioned and authenticated external CC exchange organizations (“ECCEO's”); cost efficiencies for ECCEO retail user-customers that buy, sell, hold, spend, and transfer a CC specimen, including its validation, verification and recording processes attendant thereto, per operative distributed ledger technologies employed; and governance ensuring compliance with applicable securities and other regulations.

The multiple encoding systems and methods implemented on theserver130 and theclient devices120 employ several layers (described below) of crypto-modules, keying processes, and related algorithms to validate CC specimen transactions, instead of the costly and wasteful proof-of-work (“POW”) CC mining-based processes used by legacy cryptocurrencies. A first layer developed by the Originator is encoded onto DABMoE units placed into secondary CC markets, denoting that the Originator:

Assigned an encoded history of attributes and activities unique to ABETB's underpinning DABMoE units that have migrated through formulation, securitization, issuance, and initial valuation processes as of a specified date of origin;

Incorporated the forgoing into a Digitization Identification Scheme employed by theserver130, the purpose of which is to verify that DABMoE unitary ownership interests are validly linked to the CC specimens placed in and removed from external circulation, which guards against future threats of manipulated or falsified transactions that may be perpetrated in the field; and

Effectuates the forgoing via cryptographic signatures and keys provided by theserver130, including those employed as part of dongle-based authentication processes, to create immutable and traceable data and records that can be accessed by the Exchange Network's authorized communities of interest.

A second layer developed by the Originator in cooperation with sanctioned and dongle authenticated ECCEO's, whereby each ECCEO is:

Free to employ its own non-POW cryptographic consensus mechanism on theserver130 to track and trace DABMoE-based CC specimens accepted from the Originator for resales to user-customers, and validate CC transactions ultimately undertaken by those user-customers, provided that such CC specimens maintain their affiliation with the Exchange Network to facilitate future transactional validation, verification, recording, and reconciliation processes; and

Granted dongle-authenticated access to the Exchange Network comprising theserver130 and theclient devices120, which enables qualifying ECCEO user-customers using theclient devices120 to view and evaluate continuously updated and compiled price discovery data attendant to components comprising their respective CC specimen's CNAV as a precursor to ultimately undertaking transactions over the ECCEO.

A third layer is generated when a dongle-authenticated ECCEO shares its access to the Exchange Network's operative CNAV price discovery systems and methods described above with reference toFIGS. 1A-16 with qualifying CC user-customers via interactive graphic user interfaces implemented on theclient devices120 configured to: report the latest bids, offers, and executed prices attendant to each underlying CNAV component; and enable each user-customer to post counter prices of CNAV components per iterative processes culminating in the ultimate execution of CC transactions assigned a specific date and stamp, user ID (e.g., dongle ID, ID of theclient device120, etc.), execution price, etc. This information is added to the transaction history that is used to encode the transaction. This encoding allows theserver130 to verify that DABMoE unitary ownership interests are validly linked to the CC specimens placed in and removed from external circulation, which guards against future threats of manipulated or falsified transactions that may be perpetrated in the field. Thus, the encoding allows theserver130 to securely validate, verify, record, trace and track transactions for cryptocurrency specimens without using the POW mining-based processes used by legacy cryptocurrencies.

The ECCEO's non-POW cryptocurrency consensus mechanism implemented on theserver130 validates executed transactions attendant to all CC specimens encoded with the three layers of encryption described above.

Employing the forgoing processes and associated digital ledger technologies, including processes that may be facilitated by dongle-based authentication processes implemented on theserver130 and theclient devices120, the Originator and its sanctioned and dongle authenticated ECCEO's cooperatively account for and reconcile periodically reported information for each DABMoE unitary ownership-based CC specimen in circulation.

The periodically reported information includes but is not limited to: quantities issued by the Originator to each ECCEO and in total, less any redemptions, thus arriving at net quantities outstanding; quantities transferred among ECCEO's in connection with their user-customers' transactions (e.g., buying, selling, spending, transfers, etc.); quantities held by ECCEO's on behalf of their user-customers; quantities held privately by user-customers; and based on the forgoing, and respective CC specifications established by the Originator, extended unitary quantities and market values of operative DABMoE's and their underlying ABETB's.

Before describing the multiple layered encoding systems and methods implemented on theserver130 and theclient devices120 in further detail, it is noted that while these systems and methods securely validate, verify, record, trace and track transactions for cryptocurrency (“CC”) specimens without using the proof-of-work (“POW”) mining-based processes used by legacy cryptocurrency, these systems and methods can not only coexist with the POW mining-based processes used with the legacy cryptocurrencies, but do not require establishing exchanges having different, custom infrastructure. Indeed, the legacy cryptocurrencies can be a component of the underlying ABETB's.

Further, unlike the legacy cryptocurrencies that are not backed by any assets and that are valued directly in fiat currencies, since the CC specimens are derived from the ABETB's, which can include a wide variety of assets including fiat currencies and legacy cryptocurrencies, the CC specimens are asset-backed or investment-backed. Accordingly, the CC specimens are backed by and valued based on valuations of the underlying ABETB's.

Furthermore, unlike a legacy cryptocurrency, subunits of which are just that —mere subunits of the same cryptocurrency, each CC specimen is unique due to the specific but varied composition of the underlying assets in one or more ABETBs that back each CC specimen. That is, since a legacy cryptocurrency is not backed by any assets other than itself, the legacy cryptocurrency is simply subdivided into subunits of the legacy cryptocurrency, where the subunits again represent the same legacy cryptocurrency, just when a dollar is subdivided into quarters, and the quarters are further subdivide into dimes and cents, the subunits still represent the dollar.

In contrast, since a CC specimen is backed by a diverse array of assets, when a CC specimen is subdivided into subunits of the CC specimen, each subunit CC specimen resulting from the subdivision of the prior CC specimen can be different depending on how the prior CC specimen is subdivided. That is, the composition of each subunit of the CC specimen depends on the composition of the underlying assets that compose each subunit of the CC specimen upon the division of the CC specimen. Therefore, not only one CC specimen can differ from another CC specimen, but each subunit of a CC specimen can be unlike another subunit of the same CC specimen. Accordingly, unlike the legacy cryptocurrencies, valuations of which fluctuate unpredictably based on pure speculation, the valuations of the CC specimens vary based on variations of the underlying assets that back the CC specimens, which are not purely speculative.

It is to be noted that while the CC specimens are asset-backed, the CC specimens are not merely derivatives of the assets that back them. Rather, the digitized asset-backed mediums of exchange comprising ABETB's are converted into various cryptocurrency specimens, and multiple layers of encoding are applied thereto, which allows secure validation, verification, recording, tracing, and tracking of transactions related to the cryptocurrency specimens.

Theserver130, which implements the ABETB-centric order matching system as described above with reference toFIGS. 1A-5, further securely validates, verifies, records, traces, and tracks transactions for the cryptocurrency specimens using a three-layer coding system implemented by performing the methods described below. Theserver130 performs these methods in addition to (i.e., in conjunction) with the methods described above with reference toFIGS. 6-14.

FIGS. 17 and 18 show various methods performed by the ABETB-centric order matching system implemented on theserver130 for securely validating, verifying, recording, tracing, and tracking transactions for cryptocurrency specimens according to the present disclosure. These methods describe the operations and functions of the ABETB-centric order matching system implemented on theserver130 using theserver applications186, which includes these methods, and using thedatabases188, which include thedatabase40. The term control referenced in the methods below refers to theprocessor170 of theserver130 shown and described above with reference toFIGS. 3-5, which executes theserver applications186 using thedatabases188 and implements the ABETB-centric order matching system. Again, the following methods can be performed by theserver130 in addition to (i.e., in conjunction) with the methods described above with reference toFIGS. 6-14.

FIG. 17 shows amethod1000 for securely validating, verifying, recording, tracing, and tracking transactions for cryptocurrency specimens according to the present disclosure. At1002, control generates a database comprising two data structures that allow automatically updating the attributes of the fungible assets according to the present disclosure. The two data structures include a first data structure and a second data structure. The first data structure stores the attributes of the fungible assets. The second data structure includes fields that are referentially related to the attributes of the fungible assets stored in the first data structure. For example, see thedatabase40 and the first and

second data structures

50,60 shown and described above with reference toFIGS. 1A-2.

At1004, control receives a stream of data regarding trades of one or more of the fungible assets over the network. At1006, control modifies one or more fields of the second data structure based on the stream of data received over the network. At1008, control automatically changes one or more of the attributes of the one or more fungible assets in the first data structure. The modification of one or more fields of the second data structure based on the received stream of data induces automatic changes to one or more attributes of the one or more fungible assets in the first data structure.

At1010, control allows at least one of cycling, liquidating, and replenishing of one or more of the fungible assets. At1012, control maintains a relative value equivalence of the fungible assets regardless of the cycling, liquidating, and replenishing of one or more of the fungible assets. At1014, control maintains a set of baskets of fungible assets in the database. At1016, control generates a medium of exchange (e.g., ABMoE) based on the set of baskets of the fungible assets in the database and generates a digitized medium of exchange (e.g., DABMoE) therefrom.

At1018, control converts the digitized asset-backed mediums of exchange into various cryptocurrency specimens. At1020, control securely validates, verifies, records, traces, and tracks transactions for the cryptocurrency specimens using a three-layer encoding system, which is described below in detail with reference toFIG. 18. Control securely validates, verifies, records, traces, and tracks transactions for the cryptocurrency specimens without using proof-of work mining based processes.

FIG. 18 shows amethod1050 for securely validating, verifying, recording, tracing, and tracking transactions for cryptocurrency specimens using the three-layer encoding system according to the present disclosure. At1052, control securely validates, verifies, records, traces, and tracks the transactions for the cryptocurrency specimens by using the first layer of encoding, which comprises encoding the digitized asset-backed mediums of exchange with a history of attributes and activities unique to the one or more of the plurality of baskets underpinning the digitized asset-backed mediums of exchange.

At1054, as part of the first layer of encoding, control verifies, using the encoding, that unitary ownership interests associated with the digitized asset-backed mediums of exchange are validly linked to the cryptocurrency specimens placed in and removed from external circulation. At1056, control provides cryptographic keys for a dongle-based authentication system to create immutable and traceable data and records of the transactions for access using the dongle-based authentication system. The dongle-based authentication system is employed by both theserver130 and theclient devices120 to provide end-to-end encryption between theserver130 and theclient devices120, in addition to authenticating access by theclient devices120 to theserver130. As already described above, the dongles provide transformational data protection via encryption that adds authentication and fault tolerant information to data transfers between theserver130 and thenetwork110.

At1058, control securely validates, verifies, records, traces, and tracks the transactions for the cryptocurrency specimens by using the second layer of encoding, which comprises implementing one or more application programming interfaces (e.g., on the server130) that allow the users (e.g., the client devices120) dongle-based access to view and evaluate continuously updated and compiled price discovery data related to the net cumulative values of the cryptocurrency specimens.

At1060, control securely validates, verifies, records, traces, and tracks the transactions for the cryptocurrency specimens by using the third layer of encoding, which comprises: interfacing, using the one or more application programming interfaces (e.g., implemented on the server130), with one or more graphical user interfaces (e.g., implemented on client devices120) configured to provide bids, offers, and executed prices attendant to each underlying net cumulative value component to the users.

At1062, control interfaces, using the one or more application programming interfaces (e.g., implemented on the server130), with one or more graphical user interfaces (e.g., implemented on client devices120) configured to allow the users to post counter prices of net cumulative value components via iterative processes culminating in execution of the transactions of the cryptocurrency specimens with a specific date and time stamp, user ID (e.g., dongle ID, ID of theclient device120, etc.), execution price, etc. At this stage, the CC specimen transaction is ready for application of the ECCEO's other legacy cryptographic consensus mechanisms, examples of which are summarized below.

At1064, control accounts for and reconciles periodically reported information for each unitary ownership-based cryptocurrency specimen in circulation over the network. Thus, theserver130 securely validates, verifies, records, traces, and tracks the transactions for the cryptocurrency specimens by using the three-layer encoding system described above instead of using the conventional proof-of-work mining based processes.

Note that in addition to using the three-layer encoding system described above, theserver130 can securely validate, verify, record, trace, and track the CC specimen transactions using other legacy cryptographic consensus mechanisms, which include proof of work (POW) and other alternatives to proof of work (POW). Non-limiting examples of the legacy cryptographic consensus mechanisms include the following.

Proof of work (POW): This process is also called mining, and miners are called nodes. The miners solve complicated mathematical puzzles to produce a new block of information from a transaction, which requires extensive computational power. The miners utilize multiple mining methods like CPU mining, GPU mining, FPGA mining, mining pools, ASIC mining, and many more. After solving the mathematical puzzles, a miner receives a block as reward if the miner is the first one to find the solution. Additionally, the mathematical puzzles can only be solved with trial and error. Hence, the miners require an increasing amount of computational power for finding solutions rapidly. The level of difficulty for the mathematical puzzles changes according to the speed at which the blocks are being mined. If the blocks are created relatively rapidly, the mathematical puzzles can get relatively difficult (and vice versa). Therefore, new blocks have to be created within a particular time frame to adjust the difficulty level of the mathematical puzzles. Several popular cryptocurrencies like Bitcoin utilize proof of work process. However, the proof of work consensus mechanism consumes resources at a staggering rate. Hence, this approach can be expensive.

Proof of stake: This method uses a randomized process to figure out which miner get a chance to produce the next block. Blockchain users can lock up their tokens for a certain time for becoming a validator. After becoming a validator, a user can produce blocks. Validators can also be selected based on the design of blockchain. Generally, a user who owns the biggest stake or owns coins for the longest period of time has better odds of creating a new block. The validators usually get rewarded for their work with all or part of transaction fees of all the transactions carried out in the block they created. Alternatively, the validators may receive a specific amount of coins due to inflation. The proof of stake method offers incentives to validators for maintaining the blockchain network. This method is more energy efficient compared to other blockchain consensus mechanisms like proof of work.

Delegated proof of stake (DPOS): In this process, users can stake their coins and vote for a particular number of delegates to create a new block. The weight of a user's vote is based on the user's stake. The delegate that receives the highest number of votes gets a chance to produce new blocks. The delegates get rewarded with transaction fees or a specific amount of coins similar to other blockchain consensus mechanisms such as proof of stake. This mechanism is one of the fastest blockchain consensus mechanisms and can handle a higher number of transactions than the proof of work mechanism.

Proof of capacity: In this method, also called plotting, solutions to complex mathematical puzzles are stored in digital storages such as hard disks and are used to create new blocks. Users who are fastest in finding the solutions get a chance to create a new block. Hence, users having relatively large storage capacities can have higher chances of producing a new block.

Proof of elapsed time: This process randomly and fairly decides the producer of a new block based on their waiting time. This mechanism provides a random wait time for each user. The user whose wait time finishes the earliest can produce a new block. This consensus mechanism works with fairness if the system can verify that no users can run multiple nodes and the wait time is truly random.

Proof of identity: This method compares a private key of a user with an authorized identity. Proof of Identity is cryptographic evidence for a user's private key that is cryptographically attached to a specific transaction. Any identified user from a blockchain network can create a block of data that can be presented to anyone in the network. This method ensures integrity and authenticity of created data.

Proof of authority: This mechanism is a modified version of proof of take where identities of validators in the network are at stake. In this method, the identity is the correspondence between a validators' personal identification and the validator's official documentation used to verify the validator's identity. The validators stake their reputation on the network. In this method, the nodes that become validators are the only ones allowed to produce new blocks. The validators whose identities are at stake are incentivized to secure and preserve the blockchain network. The number of validators is generally relatively small.

Proof of activity: This mechanism is a combination of proof of work and proof of stake. In this method, miners try to find the solution to a puzzle and claim their reward. However, the blocks created in this mechanism are simple templates with mining reward address and header information. The header information is used to select a random group of validators for signing a block. The validators with larger stakes can have greater odds of being selected to sign a new block. After the selected validators sign a new block, the signed block becomes a part of the network. If a block remains unsigned by some validators, the block is discarded and a new block is utilized. The network fees generated in the process are distributed between a winning miner and the validators.

In addition, the ABETB-centric order matching system described above with reference toFIGS. 1A-18 and the system and method described below with reference toFIGS. 19 and 20 can implement systems and methods to generate and transmit market data streams derived from the trading of Exchange-formulated tokens backed by cash-settled Exchange Traded Derivatives (ETD) contracts linked to Weighted Average Benchmarks, Complementary Differential Indexes, and Forward Point Delivery Differential Indexes, which on a standalone basis enhance Benchmark Complex Solutions-based price discovery processes (“BCSBPDP”) developed for fungible physical assets underpinning the CC Specimens described above. Using these systems and methods, the tokens can be bought and sold over subnetworks directed by Exchange-affiliated Futures Commission Merchant (FCM) Clearing Firms where distributed ledger technologies and consensus mechanisms, as well as multiple encryption and encoding schemes cooperatively developed by the Exchange and its FCM's are used to more securely and efficiently validate, verify, record, trace, and track transactions whose market prices and related data are contemporaneously streamed into the ECN-accessible BCSBPDP, thereby increasing liquidity within the Exchange organization beyond that generated by the physical settlement based multi-platforms and -markets forming its Hybrid Paradigm. Subject to compliance with applicable regulatory guidelines, the tokens may also be bought and sold over subnetworks directed by foreign exchanges or boards of trade employing similar systems and methods.

The systems and methods described with reference toFIGS. 1A-20 address challenges posed by high-frequency and algorithmic trading protocols. Specifically, by lacking access to interoperable smart contract-driven distributed ledger technology (DLT) systems, Exchange organizations and traders tend to experience major challenges attempting to confirm and reconcile continually adjusted (due to the myriad of bids and offers being posted and cancelled iteratively) order execution data with compliant post-trade data needed for timely clearance, settlement, and reporting of all ETD contracts bought, sold, and held as open interest under high-frequency and algorithm-based trading protocols. Such challenges are exacerbated by relative disparities in communications systems and links, likely caused by Exchange organizations deciding to maximize order and transactional liquidity for the sake of revenue growth while being reluctant or unable to get slower and less efficient back-office processes up to speed.

The systems and methods described with reference toFIGS. 1A-20 overcome these challenges by employing Exchange-authorized order matching systems, subnetworks, and DLT systems directed by FCM Clearing Firms. The systems and methods use distributed consensus mechanism(s) to validate executed customer orders, information about which can then be routed to update all impacted files and ledgers belonging to authorized COI members. Included in the COI is the Exchange's owned or contracted Data Reporting Service, which upon receipt of requisite validated trade information, packages trade information into reports routed to the ECN-Accessible price discovery system described above as well as to other subscribers of the ECN.

As described above with reference toFIGS. 1A-18, there are a variety of distributed consensus mechanisms that can add to the security and efficiency of validated trade data; with adaptability to accommodate more mechanisms emerging with time. The systems and methods have the ability to engage a meaningful and efficient sample of validators from a universe of trusted parties that have established relationships with the Exchange, including FCM Clearing Firms (many of which perform compatible market-making functions) and other pertinent COI members.

In addition to trading and hedging of either individual fungible-yet varying physical assets or multi-asset investment products, such as those underpinning the CC Specimens, using the systems and methods described above with reference toFIGS. 1A-18 (and in the patents and patent application incorporated herein by reference), the system and method described below focus on trading and hedging Exchange-formulated Tokens underpinned by certain cash-settled ETD contracts: conventional-style futures linked to specified WAB's, Complementary Differential Indexes and Forward Point Delivery Differential Indexes integral to implementing BCS. Since such Tokens present standalone trading opportunities appealing to speculators and other financial interests, especially those exploiting use of high-frequency and other algorithm-based trading protocols, the tokens are capable of generating large trading volumes adding substantial liquidity to ECN-accessible price discovery processes previously defined by this Inventor. The system and method described below produce that result. These system and method described below with reference toFIGS. 19 and 20 operate in conjunction with the systems and methods described above with reference toFIGS. 1A-18.

These system and method described below with reference toFIGS. 19 and 20 differ from and provide the following advancements to the state of the art. First, the Exchange does not maintain direct control over all aspects of the systems and methods employed by the FCM Clearing Firms, or the network of organizations employing them within the Tokens' defined communities of interest (“COI”). Instead, the Exchange assigns considerable responsibility to affiliated Futures Commission Merchant (“FCM”) Clearing Firms.

FCM Clearing Firms are entities that are registered with applicable regulatory bodies (e.g., the National Futures Association and the Commodity Futures Trading Commission) and comply with their various rules, guidelines, and oversight regarding minimum regulatory capital, risk management, customer funds segregation, operational capacity and expertise, etc. As such, FCMs are authorized to perform the following operations (a non-exhaustive list is provided): solicit or accept orders to buy or sell futures contracts or options on futures in the open market; act as market makers that take positions opposite to customer orders for the purpose of providing market liquidity; accept money or other assets from customers to support their orders; affiliate with one or more Exchange organizations, which requires them to hold substantial deposits with the Clearinghouses (“CHs”) of which they are members; properly segregate each customer's funds from their own, as well as those of other parties; make margin calls and collect margin funds or return them to customers per CH requirements since customers generally do not have direct relationships with CHs; in fact, the CH looks to its member FCM Clearing Firms for financial performance as guarantors and “as if principals”; and ensure asset deliveries are made by the time futures contracts expire.

Second, according to the system and method described below, both the Exchange and its affiliated or contracted CH may benefit by relying on the use of one or more subnetworks serving as logical extensions of the ECN described above with reference toFIGS. 1A-18 to at least: allocate additional address space among each FCM Clearing Firm and its respective COI members; increase routing efficiency of orders executed, validated, and reported; and accommodate post-trade DLT-systems designed to provide efficient controls over inter alia operational, administrative, accounting, and reporting functions.

Third, according to the system and method described below, multiple encryption and encoding systems are employed to: identify the Exchange as the party responsible for (a) specifying and circulating the ETD Contracts underpinning Tokens formulated for trading over subnetworks organized around FCM Clearing Firms; and (b) ensuring that interoperable distributed ledger technology (“DLT”) systems and methods are implemented and practiced; grant all dongle-authenticated Token traders ECN-Access (as described above with reference toFIGS. 1A-18) to price discovery data and associated GUI embodiments to effectuate traders' placement and execution of Token orders in conformance with Exchange-authorized matching algorithms employed to keep a record of all open orders in the market and generate new trades when two offsetting orders can be fulfilled by each other over the subnetworks; securely validate all transactions transpiring from executed Token orders via use of Exchange-authorized distributed consensus mechanism(s); route all validated market data reports associated with Token transactions and their underlying ETD contracts to the ECN-Accessible price discovery portals that consolidate multi-market and multi-platform activity for viewing and evaluation by dongle-authenticated COI members prior to order placement (described above with reference toFIGS. 1A-18); and maintain Exchange's ability to reconcile its accounting ledgers with all relevant funds flowing into and out of its affiliated FCM Clearing Firms, members of their respective COI, and the CH. The system and method described below employs the three layers of encryption to optimize security and efficiency regarding the forgoing.

The system and method for token trading is now described with reference toFIGS. 19 and 20. The system works in conjunction with the systems and methods described above with reference toFIGS. 1A-18. The system and method is implemented partially in theserver130 and partially inservers1104 described below. Theservers1104 may be structurally similar to theservers130.

Client devices

1106 and1108 described below may be structurally similar to theclient devices120. The functionalities of theservers1104 and the

client devices

1106 and1108 are described below in detail.

FIG. 19 shows asystem1100 for trading the tokens according to the present disclosure. Thesystem1100 comprises thesystem100 shown inFIG. 3 and further comprises a plurality of subnetworks1102-1, . . . , and1102-N (collectively the subnetworks1102), where N is a positive integer. Thesubnetworks1102 are part of the ECN represented by thesystem100 shown inFIG. 3. In general, thesubnetworks1102 are similar to the distributedcommunications system110 shown inFIG. 3. Each of thesubnetworks1102 is controlled separately from the ECN. Specifically, each of thesubnetworks1102 is controlled by a respective FCM clearing firm. Each FCM clearing firm may work with traders and customers that trade the tokens using therespective subnetwork1102. The traders of each FCM clearing firm may use client devices to communicate with the servers of the FCM clearing firm via the subnetworks controlled by the FCM clearing firm. While eachsubnetwork1102 is shown as comprising one server for simplicity of illustration, eachsubnetwork1102 may comprise multiple servers connected to thesubnetwork1102.

For example, a first FCM clearing firm may control a first subnetwork1102-1. The first subnetwork1102-1 may comprise a server1104-1 and client devices1106-1, . . . , and1106-M (collectively the client devices1106), where M is a positive integer. An Nth FCM clearing firm may control an Nth subnetwork1102-N. The Nth subnetwork1102-N may comprise a server1104-N and client devices1108-1, . . . , and1108-P (collectively the client devices1108), where P is a positive integer. The server (or servers)130 of the ECN may be called theExchange server130 orECN server130, and theservers1104 of the subnetworks102 may be called thesubnetwork servers1104. The operations of the

servers

1104 and130 and the

client devices

1106 and1108 are now described below with reference toFIG. 20.

In general, thesystem100 comprises theECN server130 and further comprises one or more of thesubnetworks1102. TheECN server130 is configured to generate tokens based on one or more of the fungible assets for trading over one ormore subnetworks1102 that are controlled separately from theECN server130. While theECN server130 is controlled by the ECN, thesubnetworks1102 and thesubnetwork servers1104 are controlled by the FCM clearing firms. TheECN server130 receives trading data associated with the trading of the tokens from the one ormore subnetworks1102 in the stream of data received by theECN server130 to update the attributes and valuations of the fungible assets underpinning the cryptocurrency specimens.

The one ormore subnetworks1102 comprises therespective subnetwork servers1104 configured to securely validate, verify, record, trace, and track the trades of the tokens by: encoding the tokens with a history of attributes and activities unique to the one or more of the plurality of baskets underpinning the digitized asset-backed mediums of exchange; verifying, using the encoding, that unitary ownership interests associated with the digitized asset-backed mediums of exchange are validly linked to the tokens placed in and removed from external circulation; and providing cryptographic keys for a dongle-based authentication system to create immutable and traceable data and records of the trades for access using the dongle-based authentication system. In thesystem1100, thesubnetwork servers1104 are configured to process buy and sell orders from counterparties for trading the tokens and to match, clear, and settle the orders based on absolute opposite trading interests of the counterparties and to provide liquidity to the counterparties for the settled orders. In thesystem1100, thesubnetwork servers1104 are configured to securely validate, verify, record, trace, and track the trades of the tokens by implementing one or more application programming interfaces that allow traders dongle-based access to theECN server130 to view and evaluate continuously updated price discovery data compiled at theECN server130.

FIG. 20 shows amethod1150 performed by thesubnetwork servers1104 and theECN server130 for securely validating, verifying, recording, tracing, and tracking transactions for the tokens and providing liquidity and price discovery for the transactions according to the present disclosure. Themethod1150 describes the operations and functions of thesystem1100 implemented on thesubnetwork servers1104 and theECN server130, which include theserver applications186 and thedatabases188. Theserver applications186 of thesubnetwork servers1104 implement themethod1150 using thedatabases188 of thesubnetwork servers1104. A portion of themethod1150 is implemented on the ABETB-centric order matching system implemented on theECN server130 using theserver applications186 and thedatabases188 of theECN server130. The term control referenced in themethod1150 below refers to theprocessors170 of the

servers

1104 and130 shown and described above with reference toFIGS. 3-5, which execute theserver applications186 using thedatabases188 of the

servers

1104 and130. In addition, thesubnetwork servers1104 implement the three-layer encoding and encryption system, which is implanted by theECN server130 as described above with reference toFIGS. 6-14.

InFIG. 20, at1152, theECN server130 generates tokens based on one or more fungible assets for trading over the separately controlledsubnetworks1102. At1154, in each of the separately controlledsubnetworks1102, thesubnetwork servers1104 provide dongle-based access to theECN server130 for price discovery and allow users (e.g., traders) to place orders from trading the tokens. At1156, in each of the separately controlledsubnetworks1102, thesubnetwork servers1104 validate, verify, record, trace, and track the traded tokens using the encryption and encoding schemes and consensus mechanisms described above.

At1158, in each of the separately controlledsubnetworks1102, thesubnetwork servers1104 provide token trading counterparties with liquidity, order matching, clearing, and settlement. At1160, thesubnetwork servers1104 provide the validated trading data for the tokens to theECN server130 via the separately controlledsubnetworks1102. Using the validated trading data received from thesubnetwork servers1104, theECN server130 updates the attributes and valuations of the fungible assets underpinning the CC specimens. At1162, thesubnetwork servers1104 provide APIs to allow token traders'

client devices

1106 and1108 dongle-based access to theECN server130 to view and evaluate continuously updated price discovery data compiled at theECN server130.

Accordingly, thesystem1100 and themethod1150 can be used to trade Exchange-specified Tokens underpinned by (a) cash-settled ETD contracts linked to WAB's, Complementary Differential Indexes and Forward Point Delivery Differential Indexes, unique combinations of which are configured to value a WAB Set's qualifying fungible assets whose market prices are associated with data structure referencing described above with reference toFIGS. 1A-18; and (b) systems, methods, and instructional specifications developed by the Exchange in cooperation with its FCM Clearing Firms, as described above with reference toFIGS. 1A-18, to produce efficient and secure DLT functionality needed to: clear and settle Tokens traded by direct and indirect customers of FCM Clearing Firms while reconciling their respective open interest balances in the normal course; report all market price and other data attendant to said Token trades; and satisfy requisite payment obligations between and among the Exchange, its FCM Clearing Firms and their respective COI in conformance with DLT instructions established when each Token is approved for trading.

Thesystem1100 and themethod1150 utilize the three layers of cryptomodules, keying processes, and encoding described above with reference toFIGS. 1A-18 as follows. UsingLayer1, when theECN server130 formulates the Tokens for trading over conventional ETD markets implemented by thesubnetworks1102, theECN server130 assign a cryptographic vintage ID for each Token upon its origination. UsingLayer2, theECN server130, in cooperation with its Clearing FCM's controlling the subnetworks1102 (e.g., the subnetwork servers1104), grants qualifying dongle-authenticated customers (e.g., theclient devices1106 and1108) access to theECN server130 to view and assess operative the Tokens' price discovery information in the manner described above with reference toFIGS. 1A-18. Using layer3, the Clearing FCM customers (e.g., thesubnetwork servers1104 and theclient devices1106 and1108) access theECN server130, access the Token price discovery information compiled on theECN server130, and undertake order executions via the use of a GUI implemented on thesubnetwork servers1104 and the

client devices

1106 and1108.

Thesystem1100 and themethod1150 utilize permissioned DLT and distributed consensus protocols implemented on thesubnetworks1102 and thesubnetwork servers1104 as follows. Once the Tokens linked to operative ETD contracts are encoded with the forgoing layers of encryption, the FCM Clearing Firms (e.g., thesubnetworks1102 and thesubnetwork servers1104 therein) are authorized by theECN server130 to use the distributed consensus protocols to validate the customers' executed orders (e.g., via theclient devices1106 and1108), at which point they can be registered onto reports transmitted by contracted or affiliated data service providers that are members of the Exchange's COI. The reported validated market data (e.g., last bids, offers, trades, open interest and related prices and quantities) is transmitted inter alia from thesubnetworks1102 and thesubnetwork servers1104 to theECN server130 and becomes part of the continuously provided data streams as described above with reference toFIGS. 1A-18, which dongle-authenticated COI with ECN-access—including CC exchanges and their retail user-customers—can review and assess as part of their operative price discovery processes. The state of the art in the DLT field is advanced by synergy generated when theECN server130 complements permissionless (for underlying ETD contracts' executed and validated orders) with permissioned (for purposes of establishing and maintaining the ledgers of its FCM Clearing Firms and their COI) systems to facilitate enhanced security for attendant Tokens.

In general, thesystem1100 and themethod1150 implemented on the

servers

1104 and130 perform all of the functions and operations described above, which overcome the challenges described above by employing Exchange-authorized order matching systems, thesubnetworks1102, and DLT systems directed by FCM Clearing Firms. Thesystem1100 and themethod1150 use distributed consensus mechanism(s) to validate executed customer orders, information about which can then be routed to update all impacted files and ledgers belonging to authorized COI members. Included in the COI is the Exchange's owned or contracted Data Reporting Service, which upon receipt of requisite validated trade information, packages trade information into reports routed to the ECN-Accessible price discovery system implemented on theECN server130 described above as well as to other subscribers of the ECN.

Thesystem1100 and themethod1150 implemented on the

subnetwork servers

1104 and130 focus on trading and hedging Exchange-formulated Tokens underpinned by certain cash-settled ETD contracts: conventional-style futures linked to specified WAB's, Complementary Differential Indexes and Forward Point Delivery Differential Indexes integral to implementing BCS. Since such Tokens present standalone trading opportunities appealing to speculators and other financial interests, especially those exploiting use of high-frequency and other algorithm-based trading protocols, the tokens are capable of generating large trading volumes adding substantial liquidity to ECN-accessible price discovery processes previously defined by this Inventor. The1100 and themethod1150 described above produce that result and provide the advancements to the state of the art described above.

Thus, thesystem1100 and themethod1150 implemented on thesubnetwork servers1104 generate and transmit market data streams derived from the trading of Exchange-formulated tokens backed by cash-settled ETD contracts linked to Weighted Average Benchmarks, Complementary Differential Indexes, and Forward Point Delivery Differential Indexes, which on a standalone basis enhance the Benchmark Complex Solutions-based price discovery processes (“BCSBPDP”) developed for fungible physical assets underpinning the CC Specimens described above. Using thesystem1100 and themethod1150 implemented on the

servers

1104 and130, the tokens can be bought and sold over thesubnetworks1102 directed by the Exchange-affiliated FCM Clearing Firms where distributed ledger technologies and consensus mechanisms, as well as multiple encryption and encoding schemes cooperatively developed by the Exchange and its FCM's are used to more securely and efficiently validate, verify, record, trace, and track transactions whose market prices and related data are contemporaneously streamed into the ECN-accessible BCSBPDP, thereby increasing liquidity within the Exchange organization beyond that generated by the physical settlement based multi-platforms and -markets forming its Hybrid Paradigm.

The foregoing description is merely illustrative in nature and is not intended to limit the disclosure, its application, or uses. The broad teachings of the disclosure can be implemented in a variety of forms. Therefore, while this disclosure includes particular examples, the true scope of the disclosure should not be so limited since other modifications will become apparent upon a study of the drawings, the specification, and the following claims. It should be understood that one or more steps within a method may be executed in different order (or concurrently) without altering the principles of the present disclosure. Further, although each of the embodiments is described above as having certain features, any one or more of those features described with respect to any embodiment of the disclosure can be implemented in and/or combined with features of any of the other embodiments, even if that combination is not explicitly described. In other words, the described embodiments are not mutually exclusive, and permutations of one or more embodiments with one another remain within the scope of this disclosure.

Spatial and functional relationships between elements (for example, between modules, circuit elements, semiconductor layers, etc.) are described using various terms, including “connected,” “engaged,” “coupled,” “adjacent,” “next to,” “on top of,” “above,” “below,” and “disposed.” Unless explicitly described as being “direct,” when a relationship between first and second elements is described in the above disclosure, that relationship can be a direct relationship where no other intervening elements are present between the first and second elements, but can also be an indirect relationship where one or more intervening elements are present (either spatially or functionally) between the first and second elements. As used herein, the phrase at least one of A, B, and C should be construed to mean a logical (A OR B OR C), using a non-exclusive logical OR, and should not be construed to mean “at least one of A, at least one of B, and at least one of C.”

In the figures, the direction of an arrow, as indicated by the arrowhead, generally demonstrates the flow of information (such as data or instructions) that is of interest to the illustration. For example, when element A and element B exchange a variety of information but information transmitted from element A to element B is relevant to the illustration, the arrow may point from element A to element B. This unidirectional arrow does not imply that no other information is transmitted from element B to element A. Further, for information sent from element A to element B, element B may send requests for, or receipt acknowledgements of, the information to element A.

In this application, including the definitions below, the term “module” or the term “controller” may be replaced with the term “circuit.” The term “module” may refer to, be part of, or include: an Application Specific Integrated Circuit (ASIC); a digital, analog, or mixed analog/digital discrete circuit; a digital, analog, or mixed analog/digital integrated circuit; a combinational logic circuit; a field programmable gate array (FPGA); a processor circuit (shared, dedicated, or group) that executes code; a memory circuit (shared, dedicated, or group) that stores code executed by the processor circuit; other suitable hardware components that provide the described functionality; or a combination of some or all of the above, such as in a system-on-chip.

The module may include one or more interface circuits. In some examples, the interface circuits may include wired or wireless interfaces that are connected to a local area network (LAN), the Internet, a wide area network (WAN), or combinations thereof. The functionality of any given module of the present disclosure may be distributed among multiple modules that are connected via interface circuits. For example, multiple modules may allow load balancing. In a further example, a server (also known as remote, or cloud) module may accomplish some functionality on behalf of a client module.

The term code, as used above, may include software, firmware, and/or microcode, and may refer to programs, routines, functions, classes, data structures, and/or objects. The term shared processor circuit encompasses a single processor circuit that executes some or all code from multiple modules. The term group processor circuit encompasses a processor circuit that, in combination with additional processor circuits, executes some or all code from one or more modules. References to multiple processor circuits encompass multiple processor circuits on discrete dies, multiple processor circuits on a single die, multiple cores of a single processor circuit, multiple threads of a single processor circuit, or a combination of the above. The term shared memory circuit encompasses a single memory circuit that stores some or all code from multiple modules. The term group memory circuit encompasses a memory circuit that, in combination with additional memories, stores some or all code from one or more modules.

The term memory circuit is a subset of the term computer-readable medium. The term computer-readable medium, as used herein, does not encompass transitory electrical or electromagnetic signals propagating through a medium (such as on a carrier wave); the term computer-readable medium may therefore be considered tangible and non-transitory. Non-limiting examples of a non-transitory, tangible computer-readable medium are nonvolatile memory circuits (such as a flash memory circuit, an erasable programmable read-only memory circuit, or a mask read-only memory circuit), volatile memory circuits (such as a static random access memory circuit or a dynamic random access memory circuit), magnetic storage media (such as an analog or digital magnetic tape or a hard disk drive), and optical storage media (such as a CD, a DVD, or a Blu-ray Disc).

The apparatuses and methods described in this application may be partially or fully implemented by a special purpose computer created by configuring a general-purpose computer to execute one or more particular functions embodied in computer programs. The functional blocks, flowchart components, and other elements described above serve as software specifications, which can be translated into the computer programs by the routine work of a skilled technician or programmer.

The computer programs include processor-executable instructions that are stored on at least one non-transitory, tangible computer-readable medium. The computer programs may also include or rely on stored data. The computer programs may encompass a basic input/output system (BIOS) that interacts with hardware of the special purpose computer, device drivers that interact with particular devices of the special purpose computer, one or more operating systems, user applications, background services, background applications, etc.

The computer programs may include: (i) descriptive text to be parsed, such as HTML (hypertext markup language), XML (extensible markup language), or JSON (JavaScript Object Notation) (ii) assembly code, (iii) object code generated from source code by a compiler, (iv) source code for execution by an interpreter, (v) source code for compilation and execution by a just-in-time compiler, etc. As examples only, source code may be written using syntax from languages including C, C++, C#, Objective-C, Swift, Haskell, Go, SQL, R, Lisp, Java®, Fortran, Perl, Pascal, Curl, OCaml, Javascript®, HTML5 (Hypertext Markup Language 5th revision), Ada, ASP (Active Server Pages), PHP (PHP: Hypertext Preprocessor), Scala, Eiffel, Smalltalk, Erlang, Ruby, Flash®, Visual Basic®, Lua, MATLAB, SIMULINK, and Python®.

Claims

What is claimed is:

1. A server connected to a network, the server comprising:

a processor; and

memory storing instructions which when executed by the processor configure the processor to:

generate a database comprising:

a first data structure configured to store attributes of fungible assets, the attributes determining market values of the fungible assets, wherein the attributes include an asset type, valuation data, and geographic data of the fungible assets; and

a second data structure having fields referentially related to the attributes stored in the first data structure such that a change in any one of the fields induces a change in real time in a corresponding one of the attributes in the first data structure;

receive a stream of data regarding one or more of the attributes of the fungible assets from the network;

modify one or more of the fields of the second data structure based on the stream of data received from the network, wherein the first data structure is automatically updated in real time as the stream of data modifies the one or more of the fields of the second data structure, and wherein the updating of the first data structure automatically updates the attributes and valuations of the fungible assets in real time;

allow at least one of cycling, liquidating, and replenishing of one or more of the fungible assets associated with the first data structure based on the modified one or more fields of the second data structure;

maintain a relative value equivalence of the fungible assets based on the at least one of cycling, liquidating, and replenishing of the one or more of the fungible assets associated with the first data structure;

maintain a plurality of baskets of the fungible assets in the database, and wherein modifying the one or more of the fields of the second data structure automatically updates the attributes and valuations of the fungible assets across the baskets in real time;

at least one of securely validate, verify, record, trace, and track transactions for cryptocurrency specimens based on the stream of data, the cryptocurrency specimens having net cumulative values derived from digitized asset-backed mediums of exchange comprising one or more of the plurality of baskets; and

generate tokens based on one or more of the fungible assets for trading over one or more subnetworks that are controlled separately from the network; and

receive trading data associated with the trading of the tokens from the one or more subnetworks in the stream of data to update the attributes and valuations of the fungible assets underpinning the cryptocurrency specimens.

2. The server ofclaim 1 wherein the instructions further configure the processor to convert one or more digitized asset-backed mediums of exchange comprising one or more of the plurality of baskets into one or more cryptocurrency specimens.

3. The server ofclaim 1 wherein the instructions further configure the processor to securely validate, verify, record, trace, and track the transactions for the cryptocurrency specimens without using proof-of work mining based processes.

4. The server ofclaim 1 wherein the instructions further configure the processor to securely validate, verify, record, trace, and track the transactions for the cryptocurrency specimens by:

encoding the digitized asset-backed mediums of exchange with a history of attributes and activities unique to the one or more of the plurality of baskets underpinning the digitized asset-backed mediums of exchange;

verifying, using the encoding, that unitary ownership interests associated with the digitized asset-backed mediums of exchange are validly linked to the cryptocurrency specimens placed in and removed from external circulation; and

providing cryptographic keys for a dongle-based authentication system to create immutable and traceable data and records of the transactions for access using the dongle-based authentication system.

5. The server ofclaim 4 wherein the instructions further configure the processor to securely validate, verify, record, trace, and track the transactions for the cryptocurrency specimens by implementing one or more application programming interfaces that allow users dongle-based access to view and evaluate continuously updated and compiled price discovery data related to the net cumulative values of the cryptocurrency specimens.

6. The server ofclaim 5 wherein the instructions further configure the processor to securely validate, verify, record, trace, and track the transactions for the cryptocurrency specimens by:

interfacing, using the one or more application programming interfaces, with one or more graphical user interfaces configured to:

provide bids, offers, and executed prices attendant to each underlying net cumulative value component to the users; and

allow the users to post counter prices of net cumulative value components via iterative processes culminating in execution of the transactions of the cryptocurrency specimens with a specific time and date stamp.

7. The server ofclaim 1 wherein the instructions further configure the processor to account for and reconcile periodically reported information for each unitary ownership-based cryptocurrency specimen in circulation over the network.

8. The server ofclaim 1 wherein the instructions further configure the processor to encode the digitized asset-backed mediums of exchange with a history of attributes and activities unique to the one or more of the plurality of baskets underpinning the digitized asset-backed mediums of exchange that have migrated through formulation, securitization, issuance, and initial valuation processes as of a specified date of origin.

9. The server ofclaim 8 wherein the instructions further configure the processor to verify, using the encoding, that unitary ownership interests associated with the digitized asset-backed mediums of exchange are validly linked to the cryptocurrency specimens placed in and removed from external circulation.

10. The server ofclaim 8 wherein the instructions further configure the processor to generate cryptographic keys for a dongle-based authentication system to create immutable and traceable data and records of the transactions for access using the dongle-based authentication system.

11. The server ofclaim 1 wherein the instructions further configure the processor to implement one or more application programming interfaces that allow users dongle-based access to view and evaluate continuously updated and compiled price discovery data related to the net cumulative values of the cryptocurrency specimens.

12. The server ofclaim 11 wherein the instructions further configure the processor to interface, using the one or more application programming interfaces, with one or more graphical user interfaces configured to provide bids, offers, and executed prices attendant to each underlying net cumulative value component to users.

13. The server ofclaim 11 wherein the instructions further configure the processor to interface, using the one or more application programming interfaces, with one or more graphical user interfaces configured to allow the users to post counter prices of net cumulative value components per iterative processes culminating in execution of the transactions of the cryptocurrency specimens with a specific time and date stamp.

14. The server ofclaim 1 wherein the stream of data is based on trading activity associated with the one or more of the fungible assets over the network.

15. The server ofclaim 1 wherein the instructions further configure the processor to receive via the network buy and sell orders from counterparties for trading one or more of the fungible assets in the baskets and to match the orders based on practically opposite rather than absolute opposite trading interests of the counterparties while maintaining the relative value equivalence of the fungible assets in the baskets.

16. The server ofclaim 15 wherein the instructions further configure the processor to generate a weighted average benchmark based on a plurality of asset forms of one or more of the fungible assets and to match the orders using the weighted average benchmark.

17. The server ofclaim 15 wherein the instructions further configure the processor to provide liquidity and physical delivery of the traded fungible assets to the counterparties via the network upon matching the orders while maintaining the relative value equivalence of the fungible assets in the baskets.

18. The server ofclaim 1 further comprising a dongle that cryptographically authenticates access to the server via the network and that secures data transfers between the server and the network.

19. The server ofclaim 1 further comprising a dongle that provides transformational data protection via encryption that adds authentication and fault tolerant information to data transfers between the server and the network.

20. The server ofclaim 17 wherein the instructions further configure the processor to align the orders to comply with Sharia law.

21. The server ofclaim 1 wherein the instructions further configure the processor to generate a digitized medium of exchange that is based on a set of baskets comprising the fungible assets and that is usable for trading the fungible assets over the network.

22. The server ofclaim 21 wherein the instructions further configure the processor to securitize and tokenize the digitized medium of exchange for trading the fungible assets over the network.

23. The server ofclaim 1 wherein the instructions further configure the processor to securely validate, verify, record, trace, and track the transactions for the cryptocurrency specimens using processes selected from a group consisting of proof of work, proof of stake, delegated proof of stake, proof of capacity, proof of elapsed time, proof of identity, proof of authority, and proof of activity.

24. A system comprising the server ofclaim 1 and further comprising one or more subnetworks, the one or more subnetworks comprising respective subnetwork servers configured to securely validate, verify, record, trace, and track the trades of the tokens by:

encoding the tokens with a history of attributes and activities unique to the one or more of the plurality of baskets underpinning the digitized asset-backed mediums of exchange;

verifying, using the encoding, that unitary ownership interests associated with the digitized asset-backed mediums of exchange are validly linked to the tokens placed in and removed from external circulation; and

providing cryptographic keys for a dongle-based authentication system to create immutable and traceable data and records of the trades for access using the dongle-based authentication system.

25. The system ofclaim 24 wherein the subnetwork servers are configured to process buy and sell orders from counterparties for trading the tokens and to match, clear, and settle the orders based on absolute opposite trading interests of the counterparties and to provide liquidity to the counterparties for the settled orders.

26. The system ofclaim 24 wherein the subnetwork servers are configured to securely validate, verify, record, trace, and track the trades of the tokens by implementing one or more application programming interfaces that allow traders dongle-based access to the server to view and evaluate continuously updated price discovery data compiled at the server.

27. A server connected to a network, the server comprising:

a processor; and

generate a database comprising:

a first data structure configured to store attributes of fungible assets, the attributes determining market values of the fungible assets; and

at least one of securely validate, verify, record, trace, and track transactions for cryptocurrency specimens based on the stream of data, the cryptocurrency specimens having net cumulative values derived from digitized asset-backed mediums of exchange comprising one or more of the plurality of baskets;

28. The server ofclaim 27 wherein the instructions further configure the processor to allow at least one of cycling, liquidating, and replenishing of one or more of the fungible assets associated with the first data structure based on the modified one or more fields of the second data structure.

29. The server ofclaim 28 wherein the instructions further configure the processor to maintain a relative value equivalence of the fungible assets based on the at least one of cycling, liquidating, and replenishing of the one or more of the fungible assets associated with the first data structure.

30. The server ofclaim 27 wherein the attributes include an asset type, valuation data, and geographic data of the fungible assets.

31. The server ofclaim 27 wherein the instructions further configure the processor to convert one or more digitized asset-backed mediums of exchange comprising one or more of the plurality of baskets into one or more cryptocurrency specimens.

32. The server ofclaim 27 wherein the instructions further configure the processor to securely validate, verify, record, trace, and track the transactions for the cryptocurrency specimens without using proof-of work mining based processes.

33. The server ofclaim 27 wherein the instructions further configure the processor to securely validate, verify, record, trace, and track the transactions for the cryptocurrency specimens by:

34. The server ofclaim 33 wherein the instructions further configure the processor to securely validate, verify, record, trace, and track the transactions for the cryptocurrency specimens by implementing one or more application programming interfaces that allow users dongle-based access to view and evaluate continuously updated and compiled price discovery data related to the net cumulative values of the cryptocurrency specimens.

35. The server ofclaim 32 wherein the instructions further configure the processor to securely validate, verify, record, trace, and track the transactions for the cryptocurrency specimens by:

36. The server ofclaim 27 wherein the instructions further configure the processor to account for and reconcile periodically reported information for each unitary ownership-based cryptocurrency specimen in circulation over the network.

37. The server ofclaim 27 wherein the instructions further configure the processor to encode the digitized asset-backed mediums of exchange with a history of attributes and activities unique to the one or more of the plurality of baskets underpinning the digitized asset-backed mediums of exchange that have migrated through formulation, securitization, issuance, and initial valuation processes as of a specified date of origin.

38. The server ofclaim 37 wherein the instructions further configure the processor to verify, using the encoding, that unitary ownership interests associated with the digitized asset-backed mediums of exchange are validly linked to the cryptocurrency specimens placed in and removed from external circulation.

39. The server ofclaim 37 wherein the instructions further configure the processor to generate cryptographic keys for a dongle-based authentication system to create immutable and traceable data and records of the transactions for access using the dongle-based authentication system.

40. The server ofclaim 27 wherein the instructions further configure the processor to implement one or more application programming interfaces that allow users dongle-based access to view and evaluate continuously updated and compiled price discovery data related to the net cumulative values of the cryptocurrency specimens.

41. The server ofclaim 40 wherein the instructions further configure the processor to interface, using the one or more application programming interfaces, with one or more graphical user interfaces configured to provide bids, offers, and executed prices attendant to each underlying net cumulative value component to users.

42. The server ofclaim 40 wherein the instructions further configure the processor to interface, using the one or more application programming interfaces, with one or more graphical user interfaces configured to allow the users to post counter prices of net cumulative value components per iterative processes culminating in execution of the transactions of the cryptocurrency specimens with a specific time and date stamp.

43. The server ofclaim 27 wherein the instructions further configure the processor to securely validate, verify, record, trace, and track the transactions for the cryptocurrency specimens using processes selected from a group consisting of proof of work, proof of stake, delegated proof of stake, proof of capacity, proof of elapsed time, proof of identity, proof of authority, and proof of activity.

44. A system comprising the server ofclaim 27 and further comprising one or more subnetworks, the one or more subnetworks comprising respective subnetwork servers configured to securely validate, verify, record, trace, and track the trades of the tokens by:

45. The system ofclaim 44 wherein the subnetwork servers are configured to process buy and sell orders from counterparties for trading the tokens and to match, clear, and settle the orders based on absolute opposite trading interests of the counterparties and to provide liquidity to the counterparties for the settled orders.

46. The system ofclaim 44 wherein the subnetwork servers are configured to securely validate, verify, record, trace, and track the trades of the tokens by implementing one or more application programming interfaces that allow traders dongle-based access to the server to view and evaluate continuously updated price discovery data compiled at the server.