Patent ID: 12205108

DETAILED DESCRIPTION

Aspects of the present disclosure relate to a novel system architecture that implements an offline crypto asset custodian system(s) and methods for wallet-less transactions involving cryptocurrencies. In an example embodiment, the transactions may include cleared transactions of crypto asset futures contracts. The (offline) custodian system may interface with public ledger systems (e.g., blockchain systems), electronic exchanges and clearinghouses. However, it should be clear that the offline custodian system of the present disclosure is not itself a public ledger system. Through its various interfaces, the custodian system may be used to securely store the cryptocurrencies (offline), which may then be physically delivered according to the transactions (on the electronic exchanges) involving crypto asset futures contracts, for example. In general, the transactions may include transactions where crypto assets represents the commodity being traded and transactions (with crypto assets) involving any other commodity (e.g., oil).

As discussed above, crypto asset transactions between public wallets are prone to security risks, such as hacking. Exemplary offline crypto asset custodian systems and methods of the present disclosure create a closed transaction system that is offline (e.g., separate and apart from public ledger systems) and secure from public transactions. As a condition for participation in crypto asset-based transactions, users of the custodian system may need to prove that they have title and possession of crypto asset(s) (e.g., cryptocurrency) before they are able to participate in transactions internally within an electronic exchange system. As part of the possession validation, users may transfer crypto asset(s) into the custodian system, such that the custodian system has physical possession of the crypto asset(s) prior to granting permission to the user to participate in transactions. Because users provide the custodian system with physical possession of the crypto asset(s) prior to initiating and/or participating in any transactions (internally within the electronic exchange system), the custodian system may ensure that users do not overdraw their accounts and guarantee physical delivery (e.g., full payment) during a settlement process. In other words, the custodian system may ensure that each account is prefunded with digital assets (e.g., crypto assets) before users may participate in transactions, and those transactions will be limited in value to the amounts that the users have prefunded.

Example custodian systems of the present disclosure may also maintain a centralized (offline) ledger for keeping track of ownership of (and/or transactions involving) crypto assets, for example, as part of an electronic exchange system. The centralized ledger may be configured to be offline and inaccessible to or by public ledgers. Crypto assets transferred into the custodian system may be retitled to a custodian entity designating a user as the beneficiary of the transferred crypto asset(s). Thus, all crypto assets stored within the custodian system may be titled to the custodian entity. The custodian system may also store crypto assets in an offline secure storage, such that the assets may be inaccessible to external sources, thereby preventing information leakage and hacking. Moreover, all transactions (internally) within the custodian system may be performed without any public crypto asset wallets, and information regarding transactions between counterparties of the electronic exchange system may remain within the electronic exchange system, through the custodian system.

In some examples, the custodian system may communicate with external accounts (such as public wallets) to transfer crypto assets into secure accounts that are stored within the custodian system (i.e., offline secure accounts) or out of the offline secure accounts (and out of the custodian system) into public wallet accounts, for example. In some examples, the custodian system may include a public-facing wallet for temporarily storing crypto assets (during a pending transfer), and for transfer of crypto assets between the custodian system and public accounts. Any crypto assets held during a pending deposit may immediately be transferred from the public wallet to the offline secure storage to reduce any security risks.

Referring toFIG.1,FIG.1is a functional block diagram of an example data structure management environment100for wallet-less futures transactions involving cryptocurrencies, according to aspects of the present disclosure. Environment100may include offline custodian system102(also referred to herein as system102), one or more buyer computers104, one or more seller computers106, one or more market maker (MM) computers108, and one or more public ledger computers112. Public ledger computer(s)112may maintain a publically viewable ledger114that lists crypto asset transfers. System102may be configured to communicate with public ledger computer(s)112, for example, to indicate crypto asset transfers within centralized ledger130, in order to update public ledger114. System102may also transfer crypto assets associated with seller computer(s)106to crypto asset (CA) account(s)128(e.g., from a seller's wallet that is associated with public ledger114), prior to permitting seller computer(s)106to initiate transactions with system102. In some examples, system102may communicate with public ledger computer(s)112when crypto assets is transferred into CA account(s)128, to update public ledger114with any change in title of the transferred crypto assets. Buyer computer(s)104, seller computer(s)106and MM computer(s)108may communicate with system102for initiating transactions including, in one example, crypto asset futures (CAF) transactions.

In system102, CA account(s)128represent an offline and secure data repository for storing crypto assets for registered members of system102, for minimizing security risks such as hacking and information leakage. In some examples, centralized ledger130may also represent an offline component that may not be connected to an external network. For example, centralized ledger130may be directly coupled to custodian computer126, but centralized ledger130may not be coupled to external network116(and, in some examples, network110). In this manner, centralized ledger130may be disconnected from public ledger computer(s)112and, thus, offline. In some examples, custodian computer126may be configured to only communicate with public ledger114(via public ledger computer(s)112) during transfer of crypto assets between a member's public wallet (e.g., member public wallet(s)220shown inFIG.2) and offline CA account(s)128of system102. In other words, custodian computer126may communicate with public ledger114during a deposit of crypto asset funds into CA account(s)128from a public wallet of a registered member of system102(e.g., member public wallet(s)220), and during a withdrawal of crypto asset funds from CA account(s)128into the member's public wallet220. During such transfers, custodian computer126may access public ledger114in order to retitle the transferred assets. For example, during a deposit into CA account(s)128, custodian computer126may retitle the assets in the name of a custodian entity. During a withdrawal, custodian computer126may retitle the assets in the name of the member. All other internal transactions within system102(i.e., amongst and between offline CA account(s)128) may be performed internally and offline (e.g., without any communication with (external) public ledger114and/or public ledger computer(s)112.

Buyer computer(s)104, seller computer(s)106and MM computer(s)108may be communicatively coupled to system102via one or more communication networks110. System102may be communicatively coupled to one or more of public ledger computer(s)112via one or more computer networks116. Each of networks110,116may include, for example, a private network (e.g., a local area network (LAN), a wide area network (WAN), intranet, etc.) and/or a public network (e.g., the Internet). In some examples, network110may be different from network116. In some examples, network110and network116may represent a same network. In some examples, one or more of computers104-108may be directly connected to system102.

Computers104-108may be configured to transmit electronic messages directed to system102. System102may similarly transmit electronic messages directed to one or more of computers104-108. Buyer computer(s)104and seller computer(s)106may represent market participants for participating in transactions via system102. Market maker computer(s)108may represent any suitable broker and/or dealer for maintaining an electronic market. Electronic messages from computers104-108may include, for example, order data (e.g., bid and/or offer data) for one or more digital assets and identification data of the respective users. Electronic messages from system102may include, for example, market data information, transaction information, etc.

Each of computers104-108may comprise a desktop computer, a laptop, a smartphone, tablet, or any other user device known in the art. A user may interact with buyer computer104, for example, via a graphical user interface (not shown) displayed on any type of display device including a computer monitor, a smart-phone screen, tablet, a laptop screen or any other device providing information to a participant. Computers104-108may include any suitable user interface, user input component(s), output component(s), and communication component(s) for creation and transmission and receipt of electronic messages. The electronic messages may include, without being limited to, instant messages, personal messages, text messages and email.

System102may include an order book module118, matching engine120, market data module122, trade data storage124, custodian computer126, CA accounts128, centralized ledger130, member data storage132and entity relationship storage134. Collectively, order book module118, matching engine120and market data module122may represent an electronic exchange and clearinghouse configured to support trading and clearing of CAF transactions involving buyer computer(s)104, seller computer(s)106and MM computer(s)108.

System102may receive order data (e.g., via electronic messages) from among computers104-108, and may store the received order data in one or more order books (not shown) of order book module118. Order book module118may be configured to determine current bid and offer prices based on the received order data in the order books. Order book module118may be communicatively coupled to matching engine120, and may transmit the current prices to matching engine120.

Matching engine120may match one or more orders in the order book(s) based on the current bid/offer prices determined by order book module118, to generate one or more trades from the matched orders. Matching engine120may store the generated trades in storage124. Matching engine120may also cause order book module118to update the order book(s), to remove the matched orders associated with the generated trades (stored in storage124). Trade data storage124may include any electronic storage device configured to store electronic trade data (e.g., matched orders representing trades (transactions)).

Market data module122may be configured to collect market data from one or more external data sources (not shown). The market data may include live and/or historical market data. In some examples, matching engine120may use the collected market data to match order(s) within the system102. For example, matching engine120may use current market data to allow or prevent particular orders from being matched.

System102may be configured to transmit the market data, collected by market data module112, as well as any data related to orders (stored in the order book(s) and/or trades stored in storage124) to one or more computers among computer(s)104-108. System102may provide the market/order/trade data to computer(s)104-108, for example, upon request, periodically, under one or more particular conditions and/or at one or more particular times.

In system102, members (e.g., users of buyer computer(s)104, users of seller computer(s)106, users of MM computer(s)108) may be associated with respective CA account(s)128. Members may be defined as registered users of system102that are permitted by system102to initiate and participate in crypto asset transactions. (The registration and permissioning is described further below with respect to custodian computer126.) Each CA account128may be associated with a particular member, and may store indications of crypto assets specific to the particular member. The indications of crypto assets, in CA accounts128, may represent physical commodities. In operation, CA accounts128may be used, in some examples, to facilitate physical delivery of CAF contracts among the members. In general, CA account(s)128may represent custodian entity-managed accounts which may track crypto asset ownership of members (such as, for example, clearing members, (registered) customers).

CA account(s)128may be stored, for example, in one or more databases. CA account(s)128may also be stored in a secure manner, to prevent tampering with and/or leakage of the account information. In some examples, CA accounts128may be stored in offline secure storage, such as offline storage208(FIG.2). In this manner, system102may reduce security risks in the storage of account information itself.

System102further stores member data in storage132. The member data may include information identifying each member permitted to initiate and participate in transactions with system102. The member data may include, for example, member identify information, computer identity information (e.g., an internet protocol (IP) address, hypertext transfer protocol (HTTP) cookies, etc.), and the like. The member data may also include information linking the member to a particular CA account128. In general, the member data may include any member identity information to track ownership of crypto assets in system102.

System102may further store one or more entity relationships in storage134. The entity relationships may include any existing relationships and/or legal framework between the members and system102. The entity relationships may be used by system102for updating CA accounts, thereby eliminating the need for any crypto asset wallets for conducting transactions. Because of the existence of the entity relationships, all shares of the digital asset may be tracked, including shares to brokers and/or dealers (e.g., market makers).

In some examples, member data, entity relationships and CA account information may be stored in an encrypted format, to prevent unauthorized access to member, entity and CA account information. In some examples, member data and entity relationships may be stored in offline secure storage. AlthoughFIG.1illustrates member data and entity relationship(s) as being stored in separate storage132and134, in some examples, the member data and entity relationship(s) may be stored in a same storage (e.g., a same database).

Centralized ledger130represents an offline centralized repository controlled and updated by custodian computer112. Centralized ledger130may be configured to indicate timestamped records of each CA transaction (including, in some examples, CAF transactions) in system102(for example, based on trade data in storage124). In some examples, clearing members (not shown) may keep their own ledgers (not shown). The combination of centralized ledger130and market maker ledgers may be used to track and verify shares of digital assets across environment100.

The combination of CA accounts128, centralized ledger130, member data and entity relationships (as controlled by custodian computer126) represents a wallet-less and offline crypto asset management and transfer system. Because the management/transfer system is wallet-less and offline, system102minimizes security risks such as hacking.

System102may also include custodian computer126configured to implement functions of registering and permissioning members for CA transactions with system102, maintaining centralized ledger130, storing crypto assets offline in CA accounts128, facilitating physical delivery (e.g., payment using crypto assets) of CAF transactions (for example) via CA accounts128and controlling transfer of crypto assets from public ledger114. Custodian computer126is described further below with respect toFIG.2. In the examples below, system102is described with respect to CAF transactions. However, it is understood that system102, including custodian computer126, may be configured to control processing of any suitable CA transaction (including but not being limited to CAF transactions).

System102, because of its architecture (including the arrangement and configuration of custodian computer126together with CA accounts128and centralized ledger130), centrally stores and maintains offline CA accounts, and maintains its own centralized ledger130that tracks transactions within system102. Moreover, system102monitors funds within each CA account128, requires users to physically deliver crypto asset funds to CA account(s)128of system102(i.e., prefund the CA account(s)) before the users are permitted to initiate trades, generates transactions according to the available funds (through the monitoring) in the respective CA accounts128, and transfers funds (at delivery) within CA accounts128maintained by system102itself. Accordingly, system102represents an offline custodian system (which may be part of an electronic exchange system). And, in this manner, the process by which system102guarantees physical delivery represents a new model for trading futures contracts.

In some examples, order book module118, matching engine120and market data module122may be embodied on a single computing device. In other examples, order book module118, matching engine120and market data module122may refer to two or more computing devices distributed over several physical locations, connected by one or more wired and/or wireless links. In some examples, order book module118, matching engine120, market data module122and custodian computer126may be embodied on a single computing device. In other examples, order book module118, matching engine120, market data module122and custodian computer126may refer to two or more computing devices distributed over several physical locations. It should be understood that system102refers to a computing system having sufficient processing and memory capabilities to perform the specialized functions described herein.

Referring next toFIG.2,FIG.2is a functional block diagram of example custodian computer126, according to aspects of the present disclosure. Custodian computer126may include entity interface202, account data module204, centralized ledger controller206, offline storage208, public ledger computer (PLC) interface210, crypto asset (CA) trade controller212, transaction settlement module214, and custodian public wallet216, which may communicate with each other via data and control bus218. AlthoughFIG.2illustrates CA account(s)128, centralized ledger130, trade data storage124, member data storage132and entity relationship(s) storage134being separate from custodian computer126, in some examples, one or more of components124and128-132may be part of custodian computer126.

Entity interface202may represent any electronic device including hardware circuitry or application on an electronic device configured to receive incoming messages from various entities (e.g., buyer computer(s)104, seller computer(s)106, MM computer(s)108) via network110. In some examples, custodian computer126may transmit information and/or data to various entities. In some examples, entity interface202may be configured to securely communicate with one or more of the entities.

Account data module204may be configured to register and permission new requesting entities (as members). The registration by account data module204may include creating a specific CA account128for the requesting entity, updating storage132with member information for the entity, and updating storage134with new entity relationship(s) associated with the entity. The permissioning by account data module204may include transferring crypto assets from one or more crypto asset accounts (e.g., a public crypto asset wallet) of the entity to newly created CA account128. In some examples, the permissioning may include transferring crypto assets to CA account128by way of a crypto asset fund transfer from the entity's public wallet (e.g., member public wallet(s)220) to custodian public wallet216(described further below). In some examples, the permissioning may further include communicating with public ledger computer(s)112(through PLC interface210) to update public ledger114to indicate the transferred crypto assets (e.g., if custodian computer126transfers the title of the crypto assets from the entity to a custodian entity). In an example, an entity may not be eligible to participate in transactions unless there is actual delivery of crypto assets into CA account128(through the permissioning by account data module204). An example registration and permissioning process performed by account data module204is described further below with respect toFIG.3.

In some examples, account data module204may access CA account(s)128via offline storage208. In some examples, account data module204may be configured to transfer crypto asset funds between (internal and offline) CA account(s)128and (external) public member crypto asset accounts. The transfer of crypto asset funds may include deposits into CA account(s)128and withdrawals from CA account(s)128. In some examples, the transfer of crypto asset funds may include a transfer of title of the crypto asset funds between a custodian entity and the member. An example of a deposit is shown inFIG.3. An example of a withdrawal is shown inFIG.5. In some examples, account data module204may operate with offline storage208, custodian public wallet216and member public wallet220in order to transfer the crypto asset funds. For example, in a deposit, funds may be transferred from member public wallet220to custodian public wallet216, and then immediately transferred from custodian public wallet216to offline storage208(to minimize security risks). In a withdrawal, funds may be transferred from offline storage208to custodian public wallet216, and then immediately transferred to member public wallet220.

Centralized ledger controller206(also referred to herein as CL controller206) may be configured to maintain and update centralized ledger130in response to transactions in trade data storage124and settling contracts based on crypto assets, such as CAF contracts. In some examples, CL controller206may operate in combination with transaction settlement module214(described further below) and account data module204to update centralized ledger130for transfer of crypto assets during a settlement process. CL controller206may include, for example, a processor, a microcontroller, a circuit, software and/or other hardware component(s) specially configured to perform the operations described herein.

Offline storage208may represent any electronic storage device configured to store CA account(s)128(and, in some examples, one or more of member data and entity relationship(s)) digitally in cold storage and in a secure manner, such that crypto asset funds of members of system102are offline (e.g., inaccessible via networks110,116). Accordingly, by storing crypto asset information in offline storage208, hacking of crypto assets may be prevented.

PLC interface210may represent any electronic device including hardware circuitry or application on an electronic device configured to communicate with public ledger computer(s)112, for updating public ledger114with any internal (i.e., within system102) crypto asset transfers into CA account(s)128and, in some examples, any crypto asset withdrawals from CA account(s)128into external entity accounts (not shown). In some examples, PLC interface210may be configured to securely communicate with public ledger computer(s)112. In some examples, PLC interface210may also support the transfer (i.e., a deposit) of crypto assets from an entity's external account (e.g., a wallet) into CA account(s)128. In some examples, PLC interface210may also support the transfer (i.e., a withdrawal) of crypto assets into an entity's external account (e.g., a wallet) from CA account(s)128.

CA trade controller212may include, for example, a processor, a microcontroller, a circuit, software and/or other hardware component(s) specially configured to control operation of entity interface202, account data module204, centralized ledger controller206, offline storage208, PLC interface210, transaction settlement module214, and custodian public wallet216, including for operations relating to registering and permissioning entities (requesting to perform transactions), transferring crypto asset funds into and out of system102, and transaction settlement at the time of contract expiration.

Transaction settlement module214may be configured to monitor expiration of contracts associated with transactions, and control settlement of transactions. Transaction settlement module214controls settlement through the transfer of crypto assets between counterparty accounts, internally within system102, via CA accounts128and centralized ledger130. More generally, transaction settlement module214may be configured to monitor any suitable transaction parameter (contract expiration, a predetermined time, a predetermined date etc.) associated with transaction data (such as trade data stored in storage124), which may trigger transfer of digital asset funds between CA accounts128of at least one first entity (member) and at least one second entity (member) of system100. An example transaction settlement process performed by transaction settlement module214is described further below with respect toFIG.4.

Custodian public wallet216may be configured to communicate with public ledger computer(s)112and member public wallet(s)220, for the transfer of crypto assets from (offline) CA account(s)128to (public/online) public crypto asset accounts (e.g., public wallets), and vice versa. As discussed above, custodian public wallet216may operate with offline storage208, such that custodian public wallet216may only temporarily hold crypto asset funds during a pending transfer of the crypto asset funds between (offline) custodian computer126and public accounts. Custodian public wallet216, thus, provide a means for communication with public (online) entities; and the use of custodian public wallet216as only temporary storage (with long-time storage via offline storage) reduces security risks to the crypto assets.

Some portions of the above description illustrate exemplary embodiments in terms of algorithms and symbolic representations of operations on information. These algorithmic descriptions and representations are understood by those skilled in the data processing arts to convey the substance of their work effectively to others skilled in the art. These operations, while described functionally, computationally, or logically, are understood to be implemented by data structures, computer programs or equivalent electrical circuits, microcode, or the like. Furthermore, it has also proven convenient at times, to refer to these arrangements of operations as modules, without loss of generality. The described operations and their associated modules may be embodied in specialized software, firmware, specially-configured hardware or any combinations thereof.

Those skilled in the art will appreciate that system102may be configured with more or less modules to conduct the methods described herein with reference toFIGS.3-5. As illustrated inFIGS.3-5, the methods shown may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (such as instructions run on a processing device), or a combination thereof. In one embodiment, the methods shown inFIGS.3-5may be performed by one or more specialized processing components associated with components118-134of data structure management environment100ofFIGS.1and2. InFIGS.3-5, it is understood that some of the steps may be performed by data structure management environment100concurrently with other steps or a combination of steps, or may be performed in a different sequence than shown.

FIGS.3and4describe example embodiments of system102relating to CAF transactions.FIG.5describes an example embodiment of system102relating to withdrawal of crypto asset funds from CA account(s)128of system102to a public account of a member. It is noted thatFIGS.3-5represent non-limiting examples of system102, and that system102may be used for storing, trading, clearing and settlement of any crypto assets in a wallet-less and offline procedure, to minimize security risks.

FIG.3illustrates a flowchart diagram of an example method for registering and permissioning an entity requesting to trade in CAF transactions, in accordance with an embodiment of the present disclosure. At step300, CA trade controller212, via entity interface202, may receive a request to trade from an entity among buyer computer(s)104, seller computer(s)106and MM computer(s)108(generally referred to herein as a requesting entity). At step302, CA trade controller212, via account data module204, may determine whether the requesting entity is a member. For example, account data module204may query member data storage132.

If the requesting entity is determined by account data module204to be a member, step302may proceed to step316, and CA trade controller212may permit the requesting entity to trade in crypto assets (for example, to initiate and participate in CAF transactions). CA trade controller212, in some examples, may prevent one or more of order book module118and matching engine120from accepting orders from entities that are not permissioned.

If the requesting entity is determined by account data module204to be a non-member, step302may proceed to step304. At step304, account data module204may create a CA account128for the requesting entity. At step306, account data module204may store member information for the requesting entity in storage132. At step306, account data module204may also update any entity relationships in storage134.

At step308, account data module204may communicate with an (external) account of the requesting entity (e.g., the entity's public wallet220), via custodian public wallet216, and transfer at least a portion of the crypto assets in the external account (e.g., the entity's public wallet220) into CA account128. The transferred crypto assets is associated with the requesting entity. For example, account data module204may cause the crypto assets to be transferred from the entity's public wallet220to custodian public wallet216(for temporary storage), and then may immediately cause the crypto assets to be transferred from custodian public wallet216to offline storage208(for long-term secure, offline storage).

At step310, account data module204may assign the title of the transferred crypto assets to a custodian entity associated with custodian computer126, and may designate the requesting entity as the owner of the transferred crypto assets. At step312, account data module204may communicate with public ledger computer(s)112, via PLC interface210, to update public ledger114to record the transferred title of the crypto assets. In this manner, custodian computer126may prefund the CA account, and may assume a risk of loss of the crypto assets, if the crypto asset information in system102is somehow compromised.

In some examples, steps310and312may be optional. For example, in some embodiments, the title of the crypto assets may remain with the requesting entity, and there may be no need to indicate a change of location of the crypto asset funds in public ledger114. In other examples where the title may not change, step310may be optional, and step312may be performed, for example, to indicate the change in funds of the entity's external account, to indicate the updated location of the funds, etc.

At step314, centralized ledger controller206may update centralized ledger130based on the titled crypto assets (at step316) (or, in some examples, based on the transferred crypto assets at step314). Step314may proceed to step316, and CA trade controller212may permit the requesting entity to trade.

The performance of steps308-314, prior to permissioning the requesting entity, guarantees that the physical commodity is delivered to custodian computer126, prior to trading. Steps308-314, thus, prevent seller computer(s)106(for example) from participating in transactions unless custodian computer first obtains the physical commodity. Steps308-314may also limit a seller's ability to sell (e.g., via seller computer(s)106) to the physical commodity stored in the associated CA account128.

AlthoughFIG.3illustrates a registration and permissioning process, steps308-314also represent a deposit process, for depositing crypto asset funds into CA account(s). Thus, in some examples, account data module204may receive a request to deposit crypto asset funds from a public member account (such as public wallet(s)220), and may perform steps308-314responsive to the request, thereby performing a crypto asset deposit process.

FIG.4illustrates a flowchart diagram of an example method for settling CAF transactions, in accordance with an embodiment of the present disclosure. At step400, transaction settlement module214may monitor and identify when one or more CAF contracts (stored in trade data storage124) expires. At step402, transaction settlement module214may, at expiration, pair off buyers and sellers among the trade data (in storage124) for delivery. In one example embodiment, the CAF contracts may be daily contracts with physical delivery each day. Thus, the expiration time may be one day. It is understood that the contract expiration time may be any suitable time period, including, but not limited to daily, hourly, weekly, monthly, etc.

At step404, account data module204may obtain CA account information for counterparties (e.g., the paired off buyers and sellers in step402), via member data and entity relationship(s) in storages132and134. At step406, transaction settlement module214may generate a CA transfer instruction. The instruction may modify the futures contract (titled to the custodian entity) to transfer the ownership, by designating the buyer as the owner of the contract.

At step408, CL controller206may update centralized ledger130to record the transaction based on the transfer instruction (step406). At step410, account data module204may transfer crypto assets associated with the transaction from the seller's CA account to the buyer's CA account. At step412, account data module204may update CA account information, as well as any member data and/or entity relationships (in storages132,134) of the buyer and seller.

FIG.5illustrates a flowchart diagram of an example method for withdrawal of crypto asset funds from CA account(s)128of system102to a public account of a member, in accordance with an embodiment of the present disclosure. At step500, account data module204, via entity interface202, may receive a request from a (registered) member (i.e., a member having an account among CA account(s)128) to withdraw an amount of crypto assets from the associated CA account128. At step502, account data module204may query the associated CA account128, to verify whether the withdrawal amount is available in the associated CA account128of the requesting member. Step502may proceed to step504.

If, at step504, the requested withdrawal amount is not verified by account data module204, step504proceeds to step506, and account data module204may deny the withdrawal request.

If the requested withdrawal amount, at step504, is verified, step504may proceed to step508. At step508, account data module204may retrieve public wallet information for the requesting member, for example, by querying member data storage132. At step510, account data module204may generate a CA transfer instruction transferring the title of crypto assets from the custodian entity to the requesting member, to transfer ownership of the crypto assets to the requesting member.

At step512, account data module204may transfer the withdrawal amount from the associated CA account128(in offline storage208) to custodian pubic wallet216(for temporary storage during the pending transfer). At step514, account data module204may transfer the withdrawal amount from custodian public wallet216to the requesting member's public wallet220, based on the retrieved member public wallet information (step508). At step516, account data module204may update CA account information of the associated CA account128, based on the withdrawn (and transferred) amount of crypto assets.

At step518, CL controller206may update centralized ledger130based on the transfer instruction (step510). At step520, account data module204may confirm the transfer of the withdrawal amount to the member public wallet220(in step512) by accessing public ledger114.

Systems and methods of the present disclosure may include and/or may be implemented by one or more specialized computers including specialized hardware and/or software components. For purposes of this disclosure, a specialized computer may be a programmable machine capable of performing arithmetic and/or logical operations and specially programmed to perform the functions described herein. In some embodiments, computers may comprise processors, memories, data storage devices, and/or other commonly known or novel components. These components may be connected physically or through network or wireless links. Computers may also comprise software which may direct the operations of the aforementioned components. Computers may be referred to with terms that are commonly used by those of ordinary skill in the relevant arts, such as servers, personal computers (PCs), mobile devices, and other terms. It will be understood by those of ordinary skill that those terms used herein are interchangeable, and any special purpose computer capable of performing the described functions may be used.

Computers may be linked to one another via one or more networks. A network may be any plurality of completely or partially interconnected computers wherein some or all of the computers are able to communicate with one another. It will be understood by those of ordinary skill that connections between computers may be wired in some cases (e.g., via wired TCP connection or other wired connection) or may be wireless (e.g., via a WiFi network connection). Any connection through which at least two computers may exchange data can be the basis of a network. Furthermore, separate networks may be able to be interconnected such that one or more computers within one network may communicate with one or more computers in another network. In such a case, the plurality of separate networks may optionally be considered to be a single network.

The term “computer” shall refer to any electronic device or devices, including those having capabilities to be utilized in connection with an electronic exchange system, such as any device capable of receiving, transmitting, processing and/or using data and information. The computer may comprise a server, a processor, a microprocessor, a personal computer, such as a laptop, palm PC, desktop or workstation, a network server, a mainframe, an electronic wired or wireless device, such as for example, a telephone, a cellular telephone, a personal digital assistant, a smartphone, an interactive television, such as for example, a television adapted to be connected to the Internet or an electronic device adapted for use with a television, an electronic pager or any other computing and/or communication device.

The term “network” shall refer to any type of network or networks, including those capable of being utilized in connection with data structure management systems and methods described herein, such as, for example, any public and/or private networks, including, for instance, the Internet, an intranet, or an extranet, any wired or wireless networks or combinations thereof.

The term “computer-readable storage medium” should be taken to include a single medium or multiple media that store one or more sets of instructions. The term “computer-readable storage medium” shall also be taken to include any medium that is capable of storing or encoding a set of instructions for execution by the machine and that causes the machine to perform any one or more of the methodologies of the present disclosure.

FIG.6illustrates a functional block diagram of a machine in the example form of computer system600within which a set of instructions for causing the machine to perform any one or more of the methodologies, processes or functions discussed herein may be executed. In some examples, the machine may be connected (e.g., networked) to other machines as described above. The machine may operate in the capacity of a server or a client machine in a client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be any special-purpose machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine for performing the functions describe herein. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. In some examples, offline custodian system102, buyer computer(s)104, seller computer(s)106, market maker computer(s)108, public ledger computer(s)112(FIG.1) and/or custodian computer126(FIG.2) may be implemented by the example machine shown inFIG.6(or a combination of two or more of such machines).

Example computer system600may include processing device602, memory606, data storage device610and communication interface612, which may communicate with each other via data and control bus618. In some examples, computer system600may also include display device614and/or user interface616.

Processing device602may include, without being limited to, a microprocessor, a central processing unit, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP) and/or a network processor. Processing device602may be configured to execute processing logic604for performing the operations described herein. In general, processing device602may include any suitable special-purpose processing device specially programmed with processing logic604to perform the operations described herein.

Memory606may include, for example, without being limited to, at least one of a read-only memory (ROM), a random access memory (RAM), a flash memory, a dynamic RAM (DRAM) and a static RAM (SRAM), storing computer-readable instructions608executable by processing device602. In general, memory606may include any suitable non-transitory computer readable storage medium storing computer-readable instructions608executable by processing device602for performing the operations described herein. Although one memory device606is illustrated inFIG.6, in some examples, computer system600may include two or more memory devices (e.g., dynamic memory and static memory).

Computer system600may include communication interface device612, for direct communication with other computers (including wired and/or wireless communication) and/or for communication with a network. In some examples, computer system600may include display device614(e.g., a liquid crystal display (LCD), a touch sensitive display, etc.). In some examples, computer system600may include user interface616(e.g., an alphanumeric input device, a cursor control device, etc.).

In some examples, computer system600may include data storage device610storing instructions (e.g., software) for performing any one or more of the functions described herein. Data storage device610may include any suitable non-transitory computer-readable storage medium, including, without being limited to, solid-state memories, optical media and magnetic media.

While the present disclosure has been discussed in terms of certain embodiments, it should be appreciated that the present disclosure is not so limited. The embodiments are explained herein by way of example, and there are numerous modifications, variations and other embodiments that may be employed that would still be within the scope of the present disclosure.