DYNAMIC BLOCKCHAIN-DRIVEN TRADING DATA FEEDS
Example methods and systems are directed to providing a dynamic, blockchain-driven data feed, such as a performance tracking data feed associated with a virtual trading environment (VTE). A method may include causing one or more self-executing contracts deployed on a blockchain network to generate the virtual trading environment (VTE) and associate the VTE with the performance tracking data feed on the blockchain network. A trading entity may perform a simulated trade in the VTE. Responsive to detecting the simulated trade, performance data of the VTE is updated in the performance tracking data feed via the one or more self-executing contracts. The method may include providing controlled access to the performance tracking data feed to enable a requesting entity to utilize the performance data. A message indicative of the performance data of the VTE may be transmitted to a user device.
This application claims the benefit of priority to U.S. Provisional Application Ser. No. 63/396,047, filed on Aug. 8, 2022, which is incorporated herein by reference in its entirety.
TECHNICAL FIELDSubject matter disclosed herein generally relates to virtual trading systems. More specifically, but not exclusively, the subject matter herein includes methods and systems for providing a data feed in the context of a virtual trading system.
BACKGROUNDThe term “virtual trading” generally refers to simulated trading in a risk-free environment. Computer-implemented virtual trading environments (VTEs) can provide users with a trading experience without actual financial risk. However, the deployment of such VTEs in isolation may be regarded as zero-sum, given that it simulates trading without a mechanism to generate additional value or integrate with non-virtual environments.
Some embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings. In the drawings, which are not necessarily drawn to scale, like numerals may describe similar components in different views. To easily identify the discussion of any particular element or act, the most significant digit or digits in a reference number refer to the figure number in which that element is first introduced. Some non-limiting examples are illustrated in the figures of the accompanying drawings in which:
Examples described herein utilize computer-implemented techniques to provide VTEs. Examples in the present disclosure allow a trading entity to perform simulated trades of virtual assets, e.g., cryptocurrency assets, without risking real capital. Furthermore, a dynamic data feed is provided in association with a VTE. The data feed may enable tracking of the performance of the VTE, and may thus be referred to as a performance tracking data feed. A performance tracking data feed may automatically track the performance of a VTE associated with a trading entity, thereby allowing performance data associated with the VTE to be used downstream, e.g., by an external protocol, such as a synthetic asset protocol.
VTEs as described herein may be implemented and operate automatically, e.g., without active management or without requiring adjustments from software developers. For example, asset prices may be automatically obtained when a trading entity performs a trade or when a portfolio value of a VTE is calculated, and a VTE's data feed may be automatically updated and accessed by one or more requesting entities.
In some examples, a requesting entity may only access or be permitted to utilize the performance data of a VTE after a successful validation or authorization operation. A trading entity may monetize the performance data originating from its VTE. For example, a portfolio value of the VTE (representing performance of the VTE, e.g., lifetime performance since inception) may be used downstream as a token by the requesting entity, against payment of access fees. Systems described herein may be used to implement a data marketplace that facilitates such monetization.
The term “blockchain network,” as used herein, refers to a digital, decentralized, and distributed system, network, or configuration of systems, in which data is stored in multiple records (e.g., “blocks”) that are cryptographically linked to each other. Each record or block may contain a list of transactions or other forms of data records, and may be connected to each other through a cryptographic hash function, thus forming a chain. A blockchain network may comprise a single blockchain structure, or multiple, interrelated blockchain systems, e.g., interconnected blockchains, sidechains, or child chains. A blockchain network may include public, private, or hybrid blockchains.
A blockchain network may provide a digital ledger of transactions that is duplicated and distributed across a network of computer systems. Blockchain networks may utilize different consensus mechanisms to validate and verify transactions or data blocks, such as Proof-of-Work (PoW), Proof-of-Stake (PoS), or Delegated Proof-of-Stake (DPoS). A blockchain network accommodates the use of self-executing contracts (e.g., “smart contracts”), decentralized finance (“DeFi”) protocols, decentralized applications (“dApps”), non-fungible tokens, blockchain-based data storage, or other applications, services, or tools that are deployable on a blockchain.
In some examples, a self-executing contract is a digital agreement that is automatically executed and enforced by a computing system when certain predefined conditions are met. The self-executing contract contains a set of rules that define the terms of the agreement, as well as the conditions under which the rules are executed. Once the self-executing contract is deployed on the computing system, it operates autonomously to execute the encoded rules when the appropriate conditions are satisfied, without requiring further human intervention. A self-executing contract can be executed by a distributed ledger, such as a blockchain network, or any other system capable of deploying and operating the digital contract. The self-executing contract may be implemented using software code that executes to perform the steps or operations required. It is noted that, in some examples, such as in the case of an Ethereum Virtual Machine™ (EVM) blockchain, the code stored in a self-executing contract is immutable and is guaranteed to execute as described in the deployed bytecode whenever a transaction is sent to the contract.
In some examples, a virtual trading system is implemented by deploying one or more self-executing contracts to a blockchain network. A method may include causing the one or more self-executing contracts deployed on a blockchain network to generate a VTE and associate the VTE with a data feed (e.g., a performance tracking data feed) on a blockchain network. A trading entity may perform a simulated trade in the VTE. Responsive to detecting the simulated trade, performance data of the VTE is updated in the performance tracking data feed via the one or more self-executing contracts. The method may include providing controlled access to the performance tracking data feed to enable a requesting entity to utilize the performance data. A message indicative of the performance data of the VTE may be transmitted to a user device, e.g., via a user interface.
In the context of a VTE, a simulated trade may be a trade involving a virtual asset or multiple virtual assets. In some examples, the VTE stores position data with respect to one or more positions held by the trading entity. Each position may be associated with a respective virtual asset.
Providing controlled access to the performance tracking data feed may include receiving, from the requesting entity, a request to access the performance data of the VTE. The method may include providing the requesting entity with access to the performance data based on determining that the requesting entity is authorized to access the performance tracking data feed. Determining that the requesting entity is authorized to access the performance tracking data feed may include validating a data usage payment. The data usage payment may be associated with a fee specified by the trading entity of that VTE.
Providing the requesting entity with access to the performance data may include determining a current portfolio value of the VTE based on at least a previously stored portfolio value of the VTE and a current price of each virtual asset of the VTE, and providing the requesting entity with access to the current portfolio value. The current portfolio value may also be determined based at least partially on a portfolio change value detected by the one or more self-executing contracts. Furthermore, in some examples, smoothing can be applied when determining the current portfolio value of the VTE, e.g., responsive to a request from a requesting entity.
In some examples, a user interface is provided. The user interface may implement aspects of a data marketplace. The method may include receiving, from the trading entity and via the user interface, an indication that the requesting entity is authorized to access the performance data. In response, the requesting entity may be permitted or enabled to access the performance tracking data feed on the blockchain network.
In some examples, a price of the virtual asset is linked to a price of a real-world asset, e.g., a cryptocurrency asset. The self-executing contracts may be deployed to obtain the price of the real-world asset such that the price of the real-world asset can be applied in the simulated trade, or in calculating a portfolio value of the VTE.
The position data may include, for each position, a virtual asset identifier and a leverage factor. For example, the leverage factor may have a scalar value that represents exposure of the position. The position data may further include a position type indicator that indicates whether the position is a short position or a long position.
The self-executing contracts may be deployed so as to identify an order transmitted to the blockchain network by the trading entity, perform the simulated trade based on the order, update a portfolio value of the VTE, and store the portfolio value in the performance tracking data feed on the blockchain network.
In some examples, there is a one-to-one relationship between the VTE and the data feed. The self-executing contracts may enable generation of a plurality of VTEs and a plurality of corresponding performance tracking data feeds, with a one-to-one relationship existing between each VTE and its corresponding performance tracking data feed. In some cases, each trading entity can thus create a dedicated VTE which has a unique data feed to track its performance. The trading entity may be the only entity permitted to trade in the relevant VTE, while other entities may view and/or utilize the performance data associated with the VTE. Data feeds may charge for access to the performance data, as mentioned above.
A requesting entity may utilize the performance data of the VTE in an external protocol. For example, in an external protocol such as a synthetic asset protocol, the requesting entity (or an entity associated with the requesting entity) may tokenize the performance of the VTE. In some examples, the requesting entity is a self-executing contract. The requesting entity may send a transaction to a data feed together with a data usage payment to obtain performance data from the data feed.
In some examples, the one or more self-executing contracts are deployed on the blockchain network to receive, from the trading entity, a request to adjust a position associated with a virtual asset in the VTE, determine that the adjusted position does not result in breaching of a VTE limit, and responsive to the determining that the adjusted position does not result in breaching of the VTE limit, update position data in the VTE to reflect the adjusted position associated with the virtual asset. The VTE limit may, for example, be a maximum leverage factor or a maximum number of positions. Accordingly, the self-executing contracts may automatically perform a check to confirm that a simulated trade would not breach any VTE limits before finalizing the trade.
The self-executing contracts implementing a VTE may include, for example, a VTE contract that provides the VTE, a data feed contract that provides the performance tracking data feed associated with the VTE, a VTE factory contract that generates the VTE contract, and/or a VTE registry contract that provides one or more functions for interacting with the VTE. Further examples of self-executing contracts are described below.
Examples described herein address or alleviate various technical challenges associated with virtual trading systems and the effective use of trading performance data. Existing trading systems, e.g., for stocks, may be zero-sum, at least when viewed in isolation. In contrast, examples described herein provide technology to enable a positive-sum environment, e.g., by adding a data feed to the ecosystem, allowing participants to gain value as new value is generated in a way that benefits the overall system. This may solve or alleviate a technical problem of how to create a VTE ecosystem to which value can accrue automatically, rather than merely simulating trades and/or redistributing value between participants.
In some examples, developers can use data feeds to build synthetic assets that replicate existing trading systems. Data feed owners then collect fees when developers use the data feeds, allowing both to benefit. The price of a VTE could represent its performance, which protocols could treat as a token to gain exposure. This may address technical challenges associated with effectively leveraging data from a VTE or integrating such data with a non-virtual system. In some examples, a virtual trading system generates and/or integrates valuable data for building synthetic assets and other protocols, rather than merely facilitating trading by participants. For example, even trading entities with relatively poor performance may benefit from their data since developers may build protocols to “bet against” trading entities.
VTEs can operate without relying on the stability of other protocols, reducing risks such as contagion risk. Examples described herein also address technical challenges that could lead to price manipulation attacks, e.g., that could drain funds from participants. In the cryptocurrency trading context, this is achieved by relying on simulated trades rather than actual trades, isolating a VTE from the rest of the rest of the cryptocurrency ecosystem and obviating the need to use an external decentralized exchange (DEX) to execute trades.
A VTE may utilize a leverage factor to scale a position with a scalar rather than borrowing assets, avoiding liquidating leveraged positions or incentivizing lenders. This may solve or alleviate technical challenges associated with implementing leverage in a computer-implemented trading system without requiring asset borrowing or facing liquidation risks.
Examples described herein thus provide a specific technical solution for providing a dynamic, blockchain-driven data feed associated with a virtual trading environment. The disclosure provides a concrete discussion of steps for deploying self-executing contracts to a blockchain network to generate a VTE, link it to a performance tracking data feed, update the data feed based on simulated trades, and provide controlled access to the data feed. Implementing techniques described herein may provide improvements in computer systems, such as distributed computer systems implementing trading environments.
In some examples, the distributed, transparent, and secure nature of blockchains is used to generate valuable performance data from simulated trades and enable new methods for monetizing and integrating that data. This may not be achievable through manual or conventional computerized means. By deploying self-executing contracts to a blockchain network, the system can operate autonomously and transparently without requiring a central authority or manual intervention. This provides technical benefits of efficiency, reliability, transparency, and security, and may also enhance data privacy.
When the effects in this disclosure are considered in aggregate, one or more of the methodologies or systems described herein may obviate a need for certain efforts or resources that otherwise would be involved in computerized trading systems. Computing resources used by one or more machines, nodes, databases, or networks may be more efficiently utilized or even reduced, e.g., as a result of automatic or self-executing operations that reduce interactions between end user computing devices and blockchain network nodes. Examples of such computing resources may include processor cycles, network traffic, memory usage, processing unit resources, data storage capacity, power consumption, and cooling capacity.
The virtual trading system 102 is shown to include a user interface component 104, a trading engine 106, a data feed component 108, a portfolio management component 110, an access control component 112, a notification engine 114, and an administrator interface component 116. The components in
Referring firstly to the user interface component 104, the user interface component 104 may allow trading entities, e.g., human users or trading “bots,” to interact with and utilize the virtual trading system 102. The user interface component 104 may provide graphical user interfaces and other interfaces (e.g., Application Programming Interfaces (APIs)) that allow a trading entity to access the features and functions of the virtual trading system 102. In some examples, the user interface component 104 provides a data marketplace that a trading entity can use to control access to the performance data of its VTE.
The trading engine 106 executes simulated trades placed by a trading entity and updates performance data, e.g., in or via the data feed component 108, based on the simulated trades. The trading engine 106 may implement rules and logic to simulate buying, selling, and managing of positions in a VTE. The trading engine 106 may allow for various types of transactions to adjust positions, e.g., opening, closing, adding to, or reducing positions, as described further below.
The data feed component 108 tracks the performance of a VTE. The data feed component 108 stores and updates performance data, such as one or more of a current portfolio value, open positions, entry prices, and other metrics that quantify the performance of simulated trades in the virtual trading environment. The data feed component 108 provides controlled access to this performance data.
The portfolio management component 110 maintains current positions and portfolio values of a VTE based on simulated trades executed by the trading engine 106. The portfolio management component 110 may store data on one or more of open positions, entry prices, leverage factors, and other portfolio attributes. The portfolio management component 110 may work with the user interface component 104 to allow a trading entity to manage its portfolio, e.g., to specify limits, access rights, fees, and so forth.
The access control component 112 enforces rules around accessing of the performance data in the data feed component 108. The access control component 112 may implement a paywall, allowlist, or other access control mechanism to control third-party access to the performance data. In some examples, a VTE and its performance tracking data feed are implemented on a blockchain network, and the access control component 112 enforces rules around access to the performance tracking data feed, e.g., by self-executing contracts in the blockchain network.
The notification engine 114 transmits messages and notifications to the trading entity or other system users. The notification engine 114 may send messages indicating performance data, updates to portfolio performance, access requests, payments received, and other system events. The notification engine 114 may work with the user interface component 104 to provide messages to a user device of the trading entity via one or more user interfaces.
The administrator interface component 116 allows an administrator to manage the virtual trading system 102. The administrator interface component 116 provides an interface for an administrator device to configure system settings, manage user access, monitor system performance, and perform other administrative tasks.
It is noted that the components or layers in
One or more servers in a server system 204 provide server-side functionality via one or more networks 202 to a networked device, in the example form of a user device 206 that is accessed by a user 208. The user 208 is an example of a trading entity in a virtual trading system. The user 208 may be a human or non-human user (e.g., “bot”), or a combination thereof As described further below, the user 208 may perform simulated trades in a VTE that is executed in the virtual trading system. Other users, referred to herein as requesting entities, may also communicate with the server system 204, e.g., to request access to performance data of a VTE associated with the user 208. Requesting entities may also, or alternatively, interact directly with a blockchain network 238 to access or utilize performance data.
A web client 212 (e.g., a browser) or a programmatic client 210 (e.g., an “app”) may be hosted and executed on the user device 206. An API server 220 and a web server 222 provide respective programmatic and web interfaces to components of the server system 204. A specific application server 218 hosts a deployment system 224, an interface system 226, and a marketplace system 228, each of which includes components, modules, or applications.
The user device 206 can communicate with the application server 218, e.g., via the web interface supported by the web server 222 or via the programmatic interface provided by the API server 220. It will be appreciated that, although only a single user device 206 is shown in
The application server 218 is communicatively coupled to database servers 230, facilitating access to an information storage repository or database 232. In some examples, the database 232 includes storage devices that store information to be processed or transmitted by the deployment system 224, by the interface system 226, or by the marketplace system 228, e.g., details of self-executing contracts, details of VTEs, or details of performance data of VTEs.
The application server 218 uses the deployment system 224 to deploy a set of self-executing contracts to the blockchain network 238 in order to provide certain functionality of or in relation to a virtual trading system, e.g., the example virtual trading systems described with reference to
The blockchain network 238 may be a network of computing devices or computing nodes (e.g., a peer-to-peer network) that stores and manages at least one blockchain. The blockchain is a list of records, called blocks, that are cryptographically linked. In some examples, the blockchain network 238 is an Ethereum™ blockchain network. The blockchain network 238 may store blocks, calculate new blocks, process transactions (e.g., via self-executing contracts) and the like. Examples of self-executing contracts are described below.
The application server 218 further, via the interface system 226, accesses application data (e.g., application data stored by the database servers 230) to provide an application (“app”) to the user device 206 via a web interface 234 or an app interface 236. The app may be a virtual trading app. The virtual trading app may facilitate interactions between the user 208 and a VTE on the blockchain network 238, e.g., facilitate simulated trades that the user 208 wishes to perform.
The user 208 may access the virtual trading app using a dedicated programmatic client 210 (e.g., installed on a computing device, such as a desktop computer or a portable computing device), with some functionality being provided client-side and other functionality provided server-side. Some or all functionality of the virtual trading app may thus be deployed by a programmatic client 210 executing on the user device 206.
In some examples, the user 208 may either directly access the blockchain network 238 (e.g., by calling self-executing contract functions directly via the network 202) via the network 202 or utilize functionality of the virtual trading app to facilitate or simplify accessing of the blockchain network 238. The interface system 226 may provide a GUI via the app interface 236 or the web interface 234 that enables the user 208 to provide input data and view or receive outputs generated by the interface system 226. For example, the GUI may enable the user 208 to request trades and to receive messages with information, such as information relating to VTE performance. In some examples, the virtual trading app may also be used by requesting entities to track performance data of the VTE of the user 208.
In some examples, the virtual trading app is designed to “abstract away” certain technical aspects of blockchain-driven transactions, making it easier for users to interact with a blockchain-based VTE and/or blockchain-based data feed. For example, the virtual trading app may simplify virtual asset selection, transaction approval, investments, data requests, price tracking, or gas fees, and may make it easier for users to view data such as transaction status, investment status, or performance data.
To access the virtual trading app, the user 208 may create an account with an entity associated with the server system 204, e.g., a service provider (or access an existing account with the entity). The user 208 may use account credentials to access the app interface 236 or web interface 234 (via a suitable web browser) and request access to the application.
The virtual trading app may integrate with a wallet that facilitates transactions on the blockchain network 238. Alternatively or additionally, the user may have a wallet running on the user device 206. The wallet may be used, for example, to manage and store private keys securely. In some examples, when a transaction is initiated on the GUI of the interface system 226, the wallet signs the transaction with the private key. This signed transaction provides cryptographic proof that the transaction is authorized by the holder of the wallet without revealing the private key itself. Once a transaction is signed, it may be propagated through the blockchain network 238 via nodes in the blockchain network 238. The transaction may be in a pending stage at first, after which it may be picked by a miner or validation and included in a next block. When a transaction is included in a block, the relevant self-executing contract on the blockchain network 238 carries out the instruction set in the transaction. For instance, in the case of a simulated trade involving the selling of an asset, the self-executing contract ensures that the trade happens at the correct rate (e.g., the current price of a real-world asset linked to a virtual asset in the VTE, as described elsewhere) and that the value of the VTE's simulated portfolio is updated. The wallet may then update a balance and transaction state, which may be reflected on the GUI of the virtual trading app.
The application server 218 may also provide a data marketplace, e.g., via the marketplace system 228. The marketplace system 228 may allow the user 208 to provide other users or entities with access to performance data of a VTE. The marketplace system 228 may facilitate payment by a requesting entity to the user 208 in exchange for access to the performance data. The marketplace system 228 may provide a GUI that can be used by the user 208 or a requesting entity, e.g., to view or set fees associated with performance data access, to view balances, to change or request access rights, or the like.
One or more of the application server 218, the database servers 230, the API server 220, and the web server 222 may each be implemented in a computer system (e.g., a personal computer, a tablet computer, or a mobile phone), in whole or in part, as described below with respect to
The network 202 may be any network that enables communication between or among machines, databases, and devices. Accordingly, the network 202 may be a wired network, a wireless network (e.g., a mobile or cellular network), or any suitable combination thereof The network 202 may include one or more portions that constitute a private network, a public network (e.g., the Internet), or any suitable combination thereof
Any one or more of the components (e.g., systems or modules) described herein may be implemented using hardware (e.g., a processor of a machine) or a combination of hardware and software. For example, any component described herein may configure a processor to perform the operations described herein for that component. Moreover, any two or more of these components may be combined into a single component, and the functions described herein for a single component may be subdivided among multiple components. Furthermore, according to various examples, components described herein as being implemented within a single machine, database, or device may be distributed across multiple machines, databases, or devices.
The virtual trading system 302 allows users, such as the trading entity 304, to perform simulated trades. The virtual trading system 302 is deployed on a blockchain network and operates in an automated manner. An external protocol 310 can access the performance tracking data feed 308, e.g., the trading entity 304 can sell the performance data of the VTE 306, that is available in the performance tracking data feed 308, to the external protocol 310 via the marketplace system 228.
The external protocol 310 may, for example, tokenize the performance of the VTE 306. The external protocol may be a synthetic asset protocol. It may operate by minting synthetic assets based on a price given by the underlying asset's data feed (in this case the VTE's simulated portfolio value). The price of these synthetic assets, e.g., associated tokens, may be loosely pegged through a DEX, e.g., to incentivize users to keep the synthetic asset price on the DEX as close to the data feed's price as possible due to arbitrage opportunities.
Referring specifically to the interactions shown in
The VTE 306 is a simulated trading environment that enables the trading entity 304 to perform simulated trades. The VTE 306 is uniquely associated with the performance tracking data feed 308 that quantifies the performance of simulated trades executed in the VTE 306 (arrow 318). When a simulated order is placed by the VTE 306, the performance tracking data feed 308 may be updated. The performance tracking data feed 308 tracks the performance of simulated trades in the associated VTE 306 and/or a portfolio value of the VTE 306. The performance tracking data feed 308 stores and updates performance data such as the current portfolio value, open positions, entry prices, and other metrics that quantify the performance of simulated trades in the VTE 306. The performance tracking data feed 308 provides controlled access to this performance data, e.g., to the external protocol 310, as described above.
For example, the external protocol 310 may represent a third-party system or application that may access the performance data in the performance tracking data feed 308 (arrow 320). As mentioned above, the external protocol 310 may be a synthetic asset protocol using the value of the VTE 306 as a token to track its price. In some examples, the external protocol 310 accesses the performance data in the performance tracking data feed 308 through a paywall or against payment of a blockchain-based usage fee.
The performance tracking data feed 308 may store performance data and state information (e.g., portfolio value of the VTE 306, entry or exit prices, or the like) and use the library 312 to facilitate calculations (arrow 322).
The self-executing contracts 402 are shown to include a data source contract 404, an oracle contract 406, a data feed registry contract 408, a data feed contract 410, a VTE registry contract 412, and a VTE factory contract 414. It is noted that the self-executing contracts 402 shown in
Referring firstly to the data source contract 404, the data source contract 404 obtains price data originating from an external feed and converts the data to a format that is compatible with the virtual trading system. For example, an unsigned integer format may be used. The data source contract 404 may support a “getPrice()” function to retrieve the latest price data for the relevant assets, e.g., the price of a real-world asset to which a virtual asset in a VTE is linked from a pricing perspective.
The data source contract 404 may be configured to cooperate with the oracle contract 406. For example, the data source contract 404 may be an intermediary between the oracle contract 406 and a VTE, converting data obtained by the oracle contract 406 to the appropriate format. For example, the oracle contract 406 may retrieve, from an external feed, price data (e.g., for cryptocurrency assets such as Bitcoin™ or Ethereum™), which is then used for entry prices and exit prices in the VTE.
The data feed registry contract 408 creates a data feed contract 410 specifically for each VTE. The data feed registry contract 408 further provides functions for interacting with a data feed contract 410. In some examples, only the data feed registry contract 408 is able to generate a data feed contract 410 to ensure control over data feeds, e.g., to ensure that each VTE only has one dedicated performance tracking data feed.
In some examples, and as mentioned above, the data feed contract 410 represents exactly one data feed per VTE. The data feed contract 410 tracks the performance of a VTE and handles requests for VTE data. In some cases, the data feed contract 410 enforces a paywall for accessing the VTE price (e.g., portfolio value, as described in more specific examples below) or performance data. In some cases, a requesting entity can view the data in the data feed contract 410 if they pay the data request fee specified by the owner, e.g., the trading entity. The data feed contract 410 may update the order history of a VTE whenever the VTE owner executes a simulated trade.
The VTE registry contract 412 provides functions for interacting with VTE contracts 416. The VTE registry contract 412 may also enforce a limit of one (or another number of) VTE per trading entity, e.g., the user 208. For example, the VTE registry contract 412 may run an allowlist, perform signature-based access control, or cause checking of a “msg.sender” against the address that created a contract. The VTE registry contract 412 calls the VTE factory contract 414 to create VTE contracts 416.
The VTE factory contract 414 creates VTE contracts 416. In some examples, the VTE factory contract 414 is solely responsible for creating VTE contracts 416, while the VTE registry contract 412 can also perform other functions, such as providing wrapper functions to query data from VTE contracts 416. The VTE factory contract 414 may be used to solve technical problems associated with self-executing contract size limits, e.g., the VTE factory contract 414 can be used together with the separate VTE registry contract 412 to avoid exceeding the contract size limit of the EVM, in the case of an Ethereum™ blockchain network, while still providing the required functionality. In some examples, only the VTE registry contract 412 can call functions of the VTE factory contract 414.
The VTE contract 416 enables its “owner,” e.g., the trading entity, to execute simulated trades. The VTE contract 416 obtains current price data, e.g., from the data source contract 404 and/or the oracle contract 406. The VTE contract 416 sends order information to its dedicated data feed contract 410 to update performance data.
The VTE contract 416 stores position data relating to respective virtual assets of a trading entity in the virtual trading system. In some examples, the VTE contract 416 stores an array of position structures, with each structure containing a symbol (e.g., BTC or ETH), leverage factor, and direction (long or short). In some examples, the VTE contract 416 does not store price data, with the data feed instead being responsible for price data aspects of the virtual trading system. In such cases, a VTE may only store position information, such as position count and total leverage factor, to enforce the protocol's limits.
The leverage factor may be a scalar used to simulate leverage (e.g., a leverage factor of 1 represents 100% of the portfolio invested, while a leverage factor of 10 represents 10× leverage). Any price movement is multiplied by the leverage factor. As alluded to above, the VTE contract 416 may be used to enforce limits on the maximum number of positions, and maximum leverage factor as defined in the VTE registry contract 412. The VTE contract 416 may also show whether a position is long or short, e.g., after an order is executed.
In some examples, the positions stored in the VTE contract 416 are for limit enforcement and are not used for price calculations, e.g., VTE portfolio value calculations. Instead, data stored in the data feed contract 410 associated with the VTE contract 416 are used for such price calculations, as described further below. In some examples, only the associated VTE contract 416 can call functions of its corresponding data feed contract 410.
The VTE contract 416 may receive a request to adjust or add a position associated with a virtual asset from a trading entity, and check whether the addition or adjustment would result in breaching of a VTE limit. If so, the VTE contract 416 may disallow the proposed trade. If not, the VTE contract 416 may update its position data to reflect the trade, as further described below.
Referring again to leverage, as mentioned, a position may be expressed using its leverage factor as opposed to using a monetary value. Each position stored for a trading entity may have a leverage factor (e.g., represented by the symbol l) which is a scalar value representing the leverage applied to that position.
In some examples, the leverage factor l acts as a multiplier that scales the performance of a position by li, where i represents a specific position. Positions can have a leverage factor of 1, representing a fully invested position with no leverage, greater than 1, representing leveraged positions, or less than 1, representing partially invested positions. For example, a leverage factor of 0.25 would scale price movements by 0.25×, representing a position with 25% exposure.
In some examples, short positions are represented by a positive li value and a Boolean flag indicating the position is short. This may allow for the use of an unsigned integer as the leverage factor l, in which negative values cannot be represented directly. For example, a short position may have a negative flag and a long position has a positive flag.
In some examples, a cumulative leverage factor for a VTE is calculated by adding leverage factors of each open position. The cumulative leverage factor may be used to enforce a maximum leverage limit, such as 10×, but is not used to calculate the portfolio value, as further described below. For purposes of calculating cumulative leverage, both short and long positions may be regarded as positive or “unsigned,” thereby preventing attempts to circumvent the leverage limit by balancing highly leveraged long and short positions. In some examples, a cumulative leverage factor of 1 represents a portfolio with 100% investment.
A virtual trading system of this nature may operate solely on price data, e.g., it does not actually borrow or lend assets, allowing leverage to be represented by a scalar value without concern for debt management or associated risks, such as black swan events. In some examples, when calculating the profitability of a short position, the order of subtraction is reversed to prevent negative values from appearing. A short position may be considered profitable if a current price is below an entry price for the relevant virtual asset in the VTE.
The self-executing contracts 402 allow the virtual trading system to operate automatically responsive to trades or other instructions, including the execution of simulated trades, updating of prices, and performance tracking. Where trading is performed automatically, a fully automated virtual trading ecosystem may thus be implemented.
Main contracts, e.g., contracts that are not deployed by factory contracts, may, for example, be deployed using the “Ethers” Javascript library. “Ethers” is a Javascript library that allows interacting with the Ethereum™ blockchain from Javascript applications, and it can be used to deploy self-executing contracts. A contract may be deployed from a one-time script, e.g., a script that runs once to deploy each contract.
Each user 508, 510, 512 uses their respective user device 502, 504, 506 to access one or more of the self-executing contracts 402 of
The virtual trading system of
In some examples, users can execute simulated trades using any trading strategy they choose, providing more flexibility than algorithmic trading protocols where the strategy is often defined on-chain. Even if trading performance is poor, the performance data (e.g., the performance data of the VTE 514 as provided by the data feed 520) could still generate revenue, because other developers may build protocols that allow betting against the trading entity or the relevant VTE.
In some examples, a user may call the relevant contract to create a VTE, with the restriction that only one VTE can be created per user. As mentioned, once a VTE is created, a unique data feed is also created for that VTE. In such cases, there is a one-to-one relationship between VTEs and data feeds. When a VTE is created, the VTE registry contract (e.g., the VTE registry contract 412) automatically calls the data feed registry contract (e.g., the data feed registry contract 408) to create a new data feed, which returns the address of the data feed contract (e.g., the data feed contract 410). The data feed contract is then associated with the VTE contract (e.g., the VTE contract 416).
Once the user, e.g., the user 508, has its own VTE and data feed, e.g., the VTE 514 and the data feed 520, the user 508 is the only trading entity permitted to execute simulated trades in that VTE. This restriction may be enforced in a number of ways:
The VTE contract may check the relevant address (e.g., “msg.sender”) of any trade function call against the address that created the VTE. If the addresses do not match, the trade function call would revert. This ensures that only the creator of the VTE can execute trades in that VTE.
The VTE registry contract may maintain a mapping of VTE addresses to the addresses of their creators. Whenever a VTE is created, this mapping may be updated. Then, the VTE contract could call a function in the VTE registry contract to check that the “msg.sender” of a trade function call matches the creator address for that VTE. If not, the trade function would revert. This separates access control logic into the VTE registry contract.
The VTE contract may implement an allowlist of approved addresses that are allowed to execute trades. In some examples, initially, only the creator address would be in the allowlist. The creator could then add other addresses to the allowlist if desired, but no one else would have permission to add or remove from the allowlist. Any trade function call from an address not in the allowlist would revert. The VTE contract may use a signature-based access control scheme where only signed trade function calls from the creator address are valid. The creator would sign trade function calls from their address before sending to the VTE contract, which would then validate the signature to ensure the call came from the creator. Unsigned or incorrectly signed trade function calls would revert.
While only the user 508 can perform trades, other users or entities can view the data feed 520 for the VTE if they pay the required fees or have the necessary access rights. In some examples, simple “viewing” of a price of the VTE 514 may be open to any address, but fees or other restrictions may be implemented for addresses wishing to utilize the data, such as by integrating the data feed 520 into another self-executing contract on the app interface 236.
In some blockchain implementations, when an external protocol sends a request to view the data feed's price, the data feed contract emits an event that contains the price before returning the price to the caller of the contract. Accordingly, while components such as off-chain applications and wallets could use these events to track performance data (e.g., through an indexing protocol, such as The Graph™), a self-executing contract wishing to use the performance data (e.g., in a synthetic asset protocol) would need to pay the required fee or have the necessary access rights, thereby addressing the technical problem of ensuring that a trading entity is rewarded for this type of usage of its performance data. In some examples, the virtual trading system does not require “keepers” (e.g., external accounts performing maintenance tasks) to function, because users may manually execute simulated trades and VTEs do not need to be rebalanced to provide accurate performance data. As described further elsewhere, the data feed 520 may retrieve the latest prices of the relevant virtual assets (e.g., cryptocurrency assets) when a user executes a simulated trade or the price of a VTE is being calculated. The price of a VTE, also referred to as its portfolio value, represents the performance of simulated trades in that VTE. The price of the VTE is not a token itself, but the external protocol 310 may utilize this price as a token.
The method 600 commences at opening loop element 602, and proceeds to operation 604, where a plurality of self-executing contracts, e.g., the self-executing contracts 402 of
At operation 606, a trading entity uses the self-executing contracts 402 to generate a new VTE (e.g., the VTE 514). At operation 608, one or more of the self-executing contracts 402 automatically generate a new performance tracking data feed (e.g., the data feed 520) that is associated with the new VTE.
The method 600 includes tracking the performance of the VTE via the performance tracking data feed (operation 610). Performance data in the performance tracking data feed are periodically updated to reflect changes resulting from simulated trades made by the trading entity (operation 612).
At operation 614, the self-executing contracts 402 provide controlled access to the performance data in the performance tracking data feed. For example, a requesting entity that is authorized or validated may track a portfolio value of the VTE by accessing the performance data in the performance tracking data feed. The method 600 may include transmitting a message indicative of the performance data (operation 616). For example, the interface system 226 of
In some examples, the virtual trading system obtains a latest price of a virtual asset when the trading entity makes a trade or when the portfolio value of the VTE needs to be calculated. The portfolio value of each VTE may be set to commence at a predefined value, such as $1, to make it easier to assess return on investment (ROI) and/or to provide a common benchmark. In some examples, the starting price of $1 may be reflected as 1e18. Using 18 decimals for VTE data may make data more easily interchangeable with data relating to virtual assets, such as linked cryptocurrency asset data.
As mentioned, in some examples, the VTE stores a leverage factor for each position, instead of an order size, such as a monetary amount, virtual asset quantity, or token quantity. The leverage factor is used as a scalar to reflect price changes in virtual assets and to calculate new portfolio values. At the time of updating, a VTE may have an old or previously stored portfolio value represented by Vo, and a new or updated portfolio value represented by Vn. These symbols are used in some examples below.
Generally, the virtual trading system accounts for the leverage factor of each position when calculating the new portfolio value, e.g., after a trade is made. In some examples, the equation used for this calculation ensures that the ROI of a position after the trade is equal to the ROI of a position before the trade.
In some cases, in order to update or determine the portfolio value of the VTE, the VTE contract 416 may compute a “change” value, referred to herein as the “C value,” which represents portfolio value change. In some examples, C represents the net change in portfolio value. Examples of the manner in which C can be calculated, and the use of the C value, are provided below.
In some examples, the following different C-related “Cases” may exist:
- Case 1 (any profit or zero profit): C equal to or greater than 0
- Case 2 (loss<100%): C greater than −1 but less than 0
- Case 3 (loss=100%): C equals −1
- Case 4 (loss>100%): C smaller than −1
In some examples, to determine which “Case” is relevant, the virtual trading system may loop over the open positions in a VTE and add each position's ROI in decimal format (e.g., 10%=0.1), as scaled by its leverage factor. The sum of the scaled ROIs provides the final C value that determines the “Case” (1-4) at a given point. The ROI can be determined by checking the current price of each relevant virtual asset, e.g., via the oracle contract 406 or the data source contract 404.
4 Cases Technique
When a requesting entity requests a price of the VTE, the C value and the previously stored portfolio value (Vo) may be used to determine which portfolio value (Vn) to return to the requesting entity. For example, responsive to a requesting entity accessing or requesting access to the price, the data feed contract 410 may use the abovementioned four “Cases” to determine Vn as follows:
- Case 1: Set Vn=Vo*(C+1)
- Case 2: Set Vn=Vo+(C*Vo*0.8)
- Case 3: Set Vn=Vo*0.2
- Case 4: Set Vn=Vo*0.2*(1/−C)
For example, an external protocol, e.g., a self-executing contract associated with a synthetic asset protocol, may “ping” the data feed contract 410 associated with a VTE, and receive the value for Vn, subject to any payment or other access rights restrictions. The system uses a formula to ensure portfolio values cannot drop below 0 or become negative, even with leverage factors greater than 1.
To prevent an abrupt transition from a positive to negative portfolio value, the system may implement “capping.” For example, to avoid “blowing up” portfolio values during large price drops while still accounting for the decay in leveraged positions, the system may apply smoothing. A portfolio could be considered “blown up” if (leverage factor*% loss)≥100%. Smoothing may ensure that (leverage factor*% loss) approaches, but never reaches, 100%, even if the quantity exceeds 100% otherwise. By using smoothing, the system avoids the technical need to implement keepers to liquidate positions or portfolios. In the example cases shown above, the smoothing factor is part of the formulas for the 4 cases respectively. In case 1, the smoothing factor is 1. In cases 2 and 3, the smoothing factor is 0.8. In case 4, the smoothing factor is (1/−c).
Referring now to position data in a VTE, when opening a position, the VTE may append the position data of the new position to the back of the relevant array (or create a new array for the first position). The leverage factor is set to the initial leverage and an entry price is set to the execution price of the order.
To add to an existing position, the virtual trading system updates the leverage factor to reflect the addition and updates the entry price of the position based on the new leverage factor. Adding to a position is described further below. In some examples, the portfolio value (Vo) does not need to be updated when adding to a position, because the new leverage factor and entry price maintain the same portfolio value (Vn) as before the additional order.
To reduce an existing position, the system updates the portfolio value (Vo) using a formula referred to below as the “16 cases formula,” sets the entry price of the position equal to the execution price of the order that reduces the position, and decreases the leverage factor of the position.
16 Cases Technique
When reducing a position, the entry price is set to the current price. Reducing a position leads to realized gains/losses, which cannot be represented merely by updating the entry price. Accordingly, the latest stored Vo in the data feed is scaled by α such that Vn remains unchanged. A scalar is applied to the current Vo such that multiplying the two values leads to a new Vo that produces the same Vn as before.
The calculations for α vary depending on which of the four “Cases” the C value starts out in and which case it would end in if the target position is removed without Vo being updated. Thus, the 16 cases formula refers to the equations used to update the portfolio value when reducing or closing a position. There are 16 possible combinations of cases to consider, based on the current “Case” (1-4) that the portfolio value falls under before the position is reduced/closed and the “Case” (1-4) that the portfolio value would fall under if the position were removed without updating V0.
In the formula below, Vn is the current portfolio value, V′n is the portfolio value with the “change” (C1), i is the case of C0, and f is the case of C1. C0 is the current value of “change” and C1 is the value of “change” with the target position removed.
As an example, consider position 1 with +80% ROI and a leverage factor of 1, and position 2 with −50% ROI and leverage factor of 1. V0 is equal to 1 and the trading entity wishes to close position 1. Using the formula described, the C0 value obtained is 0.3, which corresponds to Case 1 of the 4 cases. The formula for Case 1 provides an initial Vn (Vni) of 1.3. If one were to remove position 1 and then recalculate the C value, the C1 value would be −0.5, which corresponds to Case 2. The formula for Case 2 provides a Vnf of 0.6. Then, using the formula for alpha, one obtains α=2.167. Multiplying V0 by alpha provides a new V0 of 2.167.
To close an existing position, the system may update the portfolio value (Vo) using the 16 cases formula, move the position object at the last index of the array of positions to the index of the position being closed, and delete the position object at the last index.
Accordingly, to calculate the new stored portfolio value when reducing or closing a position, the system determines the current portfolio value “Case” (1-4) based on C, the portfolio value “Case” (1-4) that would result from removing the target position, the scalar (α) needed to update V0 such that V′0 produces the same V′n as in the step above, and the new portfolio value by multiplying the current V0 by the scalar (α).
The 16 cases formula may ensure that reducing or closing a position does not cause an abrupt change in portfolio performance. The system tracks the performance of simulated trades by updating an array of position objects. By updating position details and the overall portfolio value in response to orders, the system can provide an accurate view of how a portfolio of simulated trades is performing over time.
It is noted that, in some examples, the 4 cases technique is used for deriving current price based on oracle/feed prices and V0, while the 16 cases formula is used for updating the V0 whenever a position is reduced/closed.
As mentioned above, the system can sum the relevant scaled ROIs to determine the C value. To calculate a C value, the following formula can be used, where Pc is current price, Pe is entry price, i represents each respective position, l represents the leverage factor, and) β is 0 for a long position and 1 for a short position.
In some examples, when adding to a position (either long or short), the virtual trading system updates the position's entry price such that the performance remains the same. For example, each position has an ROI that is calculated based on current asset price, entry price, and leverage factor. Since the leverage factor changes when a trade is made, the entry price also needs to change such that the effects “cancel out.” The formulas below show how this can be updated for long and short positions respectively, where Pc is current price, Pe is entry price (with 0 representing the current entry price and 1 representing the new entry price), 1 represents the leverage factor, and delta l represents the amount being added to the position. For example, if a trading entity currently has a position in BTC with a 0.5 leverage factor, and makes another “buy” order with a 0.25 leverage factor (delta l=0.25), the new position will have a 0.75 leverage factor.
In use, in some examples, when a trading entity makes a simulated trade, the trading entity calls the VTE contract 416 to place an order. The order is sent to the data feed contract 410 linked to the VTE contract 416. The VTE contract 416 sends one or more of a virtual asset identifier (e.g., asset symbol), current price, buy/sell indicator, and leverage to the data feed contract 410, e.g., via an “updateData()” function. The VTE contract 416 also updates its position data to reflect the simulated trade.
In some examples, to update positions in response to orders, the virtual trading system first calculates the total positive value gained and total negative value lost across all positions, as well as whether the net change is positive or negative, e.g., using a “calculateCurrentValues()” function. In some examples, this is a similar process to that used to calculate the C value as described above. When unsigned integers are used, positive and negative components are separated out and the difference can be taken to obtain the final C value.
In some examples, the system loops through each position and updates details based on the type of order:
- If adding to an existing position (or opening a new position, which is treated the same as adding to a position with an initial leverage factor of 0), the system increases the leverage factor of the position. For example, if a position for Bitcoin™ already has a leverage factor of 1 (representing 100% of the portfolio), and an order is placed to buy another 50% of the portfolio in Bitcoin, the leverage factor would be increased to 1.5. The system also updates the entry price of the position using the current asset price, but does not use the 16 cases formula in this scenario. As mentioned, in some examples, when adding to a position, portfolio value does not need to be updated.
- If reducing an existing position or switching its direction from long to short or vice versa, the system first calculates the relevant scalar (α) using the 16 cases formula based on the current portfolio value case and the case that would result from simply removing the position, as described above. The system then updates the portfolio value (V0) by multiplying the current V0 by α. For example, if a is 0.8, V0 would be updated to 0.8 V0. The system also resets the entry price of the position to the current asset price and reduces the leverage factor of the position.
- If closing an existing position, the system updates the portfolio value (V0) using the 16 cases formula, moves the details of the last position in the array of positions to the index of the position being closed, and deletes the position at the last index.
By looping through positions and updating details based on the type of order, the system can properly track the performance of simulated trades over time as positions are opened, increased, reduced, switched, and closed. The system uses the 16 cases formula when reducing and closing positions to scale the portfolio value such that the resulting portfolio value case accurately reflects the performance of the remaining open positions. On the other hand, when opening or adding to positions, the system simply updates the leverage factor and entry price without needing to use the 16 cases formula.
The method 700 commences at opening loop element 702, and proceeds to operation 704, where the self-executing contracts 402 are used to generate a VTE (e.g., the VTE 514) and a corresponding performance tracking data feed (e.g., the data feed 520). The application server 218 of the
The marketplace system 228 may allow the trading entity of the VTE to specify which requesting entities may access the performance tracking data feed and which requirements must be met for access, e.g., a particular data usage payment and/or a particular requestor address. The marketplace system 228 updates the self-executing contracts 402 to specify the relevant access rights and restrictions.
At operation 708, a requesting entity requests access to the performance tracking data feed, e.g., via the data feed contract 410 linked to the VTE. The data feed contract 410 executes a function to check the access rights of the requesting entity (operation 710). If the requesting entity is not authorized or validated at decision operation 712, the requesting entity is not able to access (or utilize, depending on the implementation) the performance data in the performance tracking data feed. On the other hand, if the requesting entity is authorized or validated at decision operation 712, the data feed contract 410 provides access to the performance data (operation 714).
At operation 716, the marketplace system 228 detects that the requesting entity accessed the performance data and issues a reward (e.g., a portion of the data usage payment) to the trading entity. This allows the trading entity to monetize its data feed in a convenient manner.
The marketplace system 228 may cause the user interface to be updated at the user device of the trading entity to reflect the reward as well as other details, e.g., details of requesting entities accessing or using the performance data. For example, the marketplace system 228 may notify the trading entity that an external protocol (e.g., the external protocol 310) is paying to track the portfolio value of the VTE of the trading entity. The method 700 concludes at closing loop element 718.
In some examples, the virtual trading system described herein allows a trading entity to produce high-quality performance data by tracking simulated trades in isolated VTEs. The trading entity may benefit from the performance data, e.g., by generating revenue from the data rather than from the trading itself. This makes the virtual trading system a positive-sum “game,” where all participants can benefit.
Trading and data production is enabled without requiring users to risk their own capital or to risk capital in live markets. By using simulated trades on virtual assets, users can build up trading track records and create valuable data feeds without the possibility of losses. Users are provided with a way to monetize their trading skills even without access to large amounts of capital.
Examples described herein also automatically produce a new data source for developers to build on. For example, various protocols (e.g., synthetic asset protocols) can use the performance data from VTEs to create synthetic assets that track the trading outcomes, build prediction markets and betting systems, and more. Whereas DeFi protocols may rely on price oracles for cryptocurrencies and other assets, examples disclosed herein provide a source of data on simulated trading performance, creating further opportunities for downstream utilization and innovation.
The representative hardware layer 804 comprises one or more processing units 806 having associated executable instructions 808. Executable instructions 808 represent the executable instructions of the software architecture 802, including implementation of the methods, modules, subsystems, and components, and so forth described herein and may also include memory and/or storage modules 810, which also have executable instructions 808. Hardware layer 804 may also comprise other hardware as indicated by other hardware 812 and other hardware 822 which represent any other hardware of the hardware layer 804, such as the other hardware illustrated as part of the software architecture 802.
In the architecture of
The operating system 814 may manage hardware resources and provide common services. The operating system 814 may include, for example, a kernel 828, services 830, and drivers 832. The kernel 828 may act as an abstraction layer between the hardware and the other software layers. For example, the kernel 828 may be responsible for memory management, processor management (e.g., scheduling), component management, networking, security settings, and so on. The services 830 may provide other common services for the other software layers. In some examples, the services 830 include an interrupt service. The interrupt service may detect the receipt of an interrupt and, in response, cause the software architecture 802 to pause its current processing and execute an interrupt service routine (ISR) when an interrupt is accessed.
The drivers 832 may be responsible for controlling or interfacing with the underlying hardware. For instance, the drivers 832 may include display drivers, camera drivers, Bluetooth® drivers, flash memory drivers, serial communication drivers (e.g., Universal Serial Bus (USB) drivers), Wi-Fi® drivers, near-field communication (NFC) drivers, audio drivers, power management drivers, and so forth depending on the hardware configuration.
The libraries 816 may provide a common infrastructure that may be utilized by the applications 820 or other components or layers. The libraries 816 typically provide functionality that allows other software modules to perform tasks in an easier fashion than to interface directly with the underlying operating system 814 functionality (e.g., kernel 828, services 830 or drivers 832). The libraries 816 may include system libraries 834 (e.g., C standard library) that may provide functions such as memory allocation functions, string manipulation functions, mathematic functions, and the like. In addition, the libraries 816 may include API libraries 836 such as media libraries (e.g., libraries to support presentation and manipulation of various media format such as MPEG4, H.264, MP3, AAC, AMR, JPG, PNG), graphics libraries (e.g., an OpenGL framework that may be used to render two-dimensional and three-dimensional in a graphic content on a display), database libraries (e.g., SQLite that may provide various relational database functions), web libraries (e.g., WebKit that may provide web browsing functionality), and the like. The libraries 816 may also include a wide variety of other libraries 838 to provide many other APIs to the applications 820 and other software components/modules.
The frameworks/middleware layer 818 may provide a higher-level common infrastructure that may be utilized by the applications 820 or other software components/modules. For example, the frameworks/middleware layer 818 may provide various graphic user interface (GUI) functions, high-level resource management, high-level location services, and so forth. The frameworks/middleware layer 818 may provide a broad spectrum of other APIs that may be utilized by the applications 820 or other software components/modules, some of which may be specific to a particular operating system or platform.
The applications 820 include built-in applications 840 or third-party applications 842. Examples of representative built-in applications 840 may include, but are not limited to, a contacts application, a browser application, a book reader application, a location application, a media application, a messaging application, or a game application. Third-party applications 842 may include any of the built-in applications as well as a broad assortment of other applications. In a specific example, the third-party application 842 (e.g., an application developed using the Android™ or iOS™ software development kit (SDK) by an entity other than the vendor of the particular platform) may be mobile software running on a mobile operating system such as iOS™, Android™, Windows® Phone, or other mobile computing device operating systems. In this example, the third-party application 842 may invoke the API calls 824 provided by the mobile operating system such as operating system 814 to facilitate functionality described herein.
The applications 820 may utilize built in operating system functions (e.g., kernel 828, services 830 or drivers 832), libraries (e.g., system libraries 834, API libraries 836, and other libraries 838), and frameworks/middleware layer 818 to create user interfaces to interact with users of the system. Alternatively, or additionally, in some systems, interactions with a user may occur through a presentation layer, such as presentation layer 844. In these systems, the application/module “logic” can be separated from the aspects of the application/module that interact with a user.
Some software architectures utilize virtual machines. In the example of
Certain examples are described herein as including logic or a number of components, modules, or mechanisms. Components or modules may constitute either software components (e.g., code embodied (1) on a non-transitory machine-readable medium or (2) in a transmission signal) or hardware-implemented components. A hardware-implemented component or hardware-implemented module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. In examples, one or more computer systems (e.g., a standalone, client, or server computer system) or one or more hardware processors may be configured by software (e.g., an application or application portion) as a hardware-implemented component or module that operates to perform certain operations as described herein.
In various examples, a hardware-implemented component may be implemented mechanically or electronically. For example, a hardware-implemented component may comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware-implemented component may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or another programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a hardware-implemented component mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.
Accordingly, the term “hardware-implemented module” or “hardware-implemented component” should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired), or temporarily or transitorily configured (e.g., programmed) to operate in a certain manner or to perform certain operations described herein. Considering examples in which hardware-implemented modules/components are temporarily configured (e.g., programmed), each of the hardware-implemented modules need not be configured or instantiated at any one instance in time. For example, where the hardware-implemented modules/components comprise, a general-purpose processor configured using software, the general-purpose processor may be configured as respective different hardware-implemented modules/components at different times. Software may accordingly configure a processor, for example, to constitute a particular hardware-implemented module/component at one instance of time and to constitute a different hardware-implemented module/component at a different instance of time.
Hardware-implemented modules/components can provide information to, and receive information from, other hardware-implemented modules/components. Accordingly, the described hardware-implemented modules/components may be regarded as being communicatively coupled. Where multiple of such hardware-implemented modules/components exist contemporaneously, communications may be achieved through signal transmission (e.g., over appropriate circuits and buses that connect the hardware-implemented modules/components). In examples in which multiple hardware-implemented modules are configured or instantiated at different times, communications between such hardware-implemented modules may be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple hardware-implemented modules/components have access. For example, one hardware-implemented module/component may perform an operation, and store the output of that operation in a memory device to which it is communicatively coupled. A further hardware-implemented module/component may then, at a later time, access the memory device to retrieve and process the stored output. Hardware-implemented modules/components may also initiate communications with input or output devices, and can operate on a resource (e.g., a collection of information).
The various operations of example methods described herein may be performed, at least partially, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented modules/components that operate to perform one or more operations or functions. The modules referred to herein may, in some examples, comprise processor-implemented modules/components.
Similarly, the methods described herein may be at least partially processor-implemented. For example, at least some of the operations of a method may be performed by one or more processors or processor-implemented modules/components. The performance of certain of the operations may be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some examples, the processor or processors may be located in a single location (e.g., within a home environment, an office environment, or a server farm), while in other examples the processors may be distributed across a number of locations.
The one or more processors may also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service (SaaS).” For example, at least some of the operations may be performed by a group of computers (as examples of machines including processors), these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., APIs).
Examples may be implemented in digital electronic circuitry, or in computer hardware, firmware, or software, or in combinations of them. Examples may be implemented using a computer program product, e.g., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable medium for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers.
A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a standalone program or as a component, module, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.
In examples, operations may be performed by one or more programmable processors executing a computer program to perform functions by operating on input data and generating output. Method operations can also be performed by, and apparatus of some examples may be implemented as, special purpose logic circuitry, e.g., an FPGA or an ASIC.
The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In examples deploying a programmable computing system, it will be appreciated that both hardware and software architectures merit consideration. Specifically, it will be appreciated that the choice of whether to implement certain functionality in permanently configured hardware (e.g., an ASIC), in temporarily configured hardware (e.g., a combination of software and a programmable processor), or in a combination of permanently and temporarily configured hardware may be a design choice. Below are set out hardware (e.g., machine) and software architectures that may be deployed, in various examples.
The example computer system 900 includes a processor 902 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), a main memory 904, and a static memory 906, which communicate with each other via a bus 908. The computer system 900 may further include a video display unit 910 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 900 also includes an alphanumeric input device 912 (e.g., a keyboard or a touch-sensitive display screen), a user interface navigation (or cursor control) device 914 (e.g., a mouse), a storage unit 916, a signal generation device 918 (e.g., a speaker), and a network interface device 920.
The storage unit 916 includes a machine-readable medium 922 on which is stored one or more sets of data structures and instructions 924 (e.g., software) embodying or utilized by any one or more of the methodologies or functions described herein. The instructions 924 may also reside, completely or at least partially, within the main memory 904 or within the processor 902 during execution thereof by the computer system 900, with the main memory 904 and the processor 902 also each constituting a machine-readable medium 922.
While the machine-readable medium 922 is shown in accordance with some examples to be a single medium, the term “machine-readable medium” may include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) that store the one or more instructions 924 or data structures. The term “machine-readable medium” shall also be taken to include any tangible medium that is capable of storing, encoding, or carrying instructions 924 for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure, or that is capable of storing, encoding, or carrying data structures utilized by or associated with such instructions 924. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media. Specific examples of a machine-readable medium 922 include non-volatile memory, including by way of example semiconductor memory devices, e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and compact disc read-only memory (CD-ROM) and digital versatile disc read-only memory (DVD-ROM) disks. A machine-readable medium is not a transmission medium.
The instructions 924 may further be transmitted or received over a communications network 926 using a transmission medium. The instructions 924 may be transmitted using the network interface device 920 and any one of a number of well-known transfer protocols (e.g., hypertext transport protocol (HTTP)). Examples of communication networks include a local area network (LAN), a wide area network (WAN), the Internet, mobile telephone networks, plain old telephone (POTS) networks, and wireless data networks (e.g., Wi-Fi and Wi-Max networks). The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding, or carrying instructions 924 for execution by the machine, and includes digital or analog communications signals or other intangible media to facilitate communication of such software.
In view of the above-described implementations of subject matter this application discloses the following list of examples, wherein one feature of an example in isolation, or more than one feature of an example taken in combination, and, optionally, in combination with one or more features of one or more further examples, are further examples also falling within the disclosure of this application.
Example 1 is a system comprising: at least one memory component that stores instructions; and one or more processors configured by the instructions to perform operations comprising: causing one or more self-executing contracts deployed on a blockchain network to: generate a virtual trading environment (VTE) on the blockchain network, associate the VTE with a performance tracking data feed on the blockchain network, responsive to detecting a simulated trade performed in the VTE by a trading entity, update performance data of the VTE in the performance tracking data feed, and provide controlled access to the performance tracking data feed to enable a requesting entity to utilize the performance data; and transmitting, to a user device, a message that is indicative of the performance data of the VTE.
In Example 2, the subject matter of Example 1 includes, wherein the operations further comprise: deploying the one or more self-executing contracts to the blockchain network.
In Example 3, the subject matter of any of Examples 1-2 includes, wherein the simulated trade comprises trading of a virtual asset, the VTE storing position data with respect to one or more positions held by the trading entity, and each position being associated with a respective virtual asset.
In Example 4, the subject matter of Example 3 includes, wherein the providing of controlled access to the performance tracking data feed comprises: receiving, from the requesting entity, a request to access the performance data of the VTE; responsive to receiving the request to access the performance data, determining that the requesting entity is authorized to access the performance tracking data feed; and providing the requesting entity with access to the performance data based on the determining that the requesting entity is authorized to access the performance tracking data feed.
In Example 5, the subject matter of Example 4 includes, wherein the determining that the requesting entity is authorized to access the performance tracking data feed comprises validating a data usage payment.
In Example 6, the subject matter of any of Examples 4-5 includes, wherein providing the requesting entity with access to the performance data comprises: determining a current portfolio value of the VTE based on at least a previously stored portfolio value of the VTE and a current price of each virtual asset of the VTE; and providing the requesting entity with access to the current portfolio value.
In Example 7, the subject matter of any of Examples 1-6 includes, wherein the operations further comprise: providing a user interface; receiving, from the trading entity and via the user interface, an indication that the requesting entity is authorized to access the performance data; and responsive to receiving the indication that the requesting entity is authorized to access the performance data, allowing the requesting entity to access the performance tracking data feed on the blockchain network.
In Example 8, the subject matter of any of Examples 3-7 includes, wherein a price of the virtual asset is linked to a price of a real-world asset.
In Example 9, the subject matter of Example 8 includes, the operations further comprising causing the one or more self-executing contracts deployed on the blockchain network to: use a blockchain oracle to obtain the price of the real-world asset, the price of the real-world asset being applied in the simulated trade.
In Example 10, the subject matter of any of Examples 8-9 includes, wherein the real-world asset is a cryptocurrency asset.
In Example 11, the subject matter of any of Examples 3-10 includes, wherein the position data comprises, for each position, a virtual asset identifier and a leverage factor.
In Example 12, the subject matter of Example 11 includes, wherein the leverage factor comprises a scalar value that represents exposure of the position, and the position data includes a position type indicator that indicates whether the position is a short position or a long position.
In Example 13, the subject matter of any of Examples 1-12 includes, the operations further comprising causing the one or more self-executing contracts deployed on the blockchain network to: identify an order transmitted to the blockchain network by the trading entity; perform the simulated trade based on the order; responsive to performing the simulated trade, update a portfolio value of the VTE; and store the portfolio value in the performance tracking data feed on the blockchain network.
In Example 14, the subject matter of any of Examples 1-13 includes, wherein the associating of the VTE with the performance tracking data feed comprises storing a one-to-one relationship between the VTE and the performance tracking data feed, the one or more self-executing contracts enabling generation of a plurality of VTEs and a plurality of corresponding performance tracking data feeds, a one-to-one relationship existing between each VTE and its corresponding performance tracking data feed.
In Example 15, the subject matter of any of Examples 1-14 includes, the operations further comprising causing the one or more self-executing contracts deployed on the blockchain network to: receive, from the trading entity, a request to adjust a position associated with a virtual asset in the VTE; determine that the adjusted position does not result in breaching of a VTE limit; and responsive to the determining that the adjusted position does not result in breaching of the VTE limit, update position data in the VTE to reflect the adjusted position associated with the virtual asset.
In Example 16, the subject matter of any of Examples 1-15 includes, wherein the requesting entity utilizes the performance data of the VTE in a synthetic asset protocol.
In Example 17, the subject matter of any of Examples 1-16 includes, wherein the requesting entity is represented by a self-executing contract.
In Example 18, the subject matter of any of Examples 1-17 includes, wherein the one or more self-executing contracts comprise: a VTE contract that provides the VTE; a data feed contract that provides the performance tracking data feed associated with the VTE; a VTE factory contract that generates the VTE contract; and a VTE registry contract that provides one or more functions for interacting with the VTE.
Example 19 is a method comprising: causing one or more self-executing contracts deployed on a blockchain network to: generate a virtual trading environment (VTE) on the blockchain network, associate the VTE with a performance tracking data feed on the blockchain network, responsive to detecting a simulated trade performed in the VTE by a trading entity, update performance data of the VTE in the performance tracking data feed, and provide controlled access to the performance tracking data feed to enable a requesting entity to utilize the performance data; and transmitting, to a user device, a message that is indicative of the performance data of the VTE.
Example 20 is a non-transitory computer-readable medium that stores instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising: causing one or more self-executing contracts deployed on a blockchain network to: generate a virtual trading environment (VTE) on the blockchain network, associate the VTE with a performance tracking data feed on the blockchain network, responsive to detecting a simulated trade performed in the VTE by a trading entity, update performance data of the VTE in the performance tracking data feed, and provide controlled access to the performance tracking data feed to enable a requesting entity to utilize the performance data; and transmitting, to a user device, a message that is indicative of the performance data of the VTE.
Example 21 is at least one machine-readable medium including instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations to implement any of Examples 1-20.
Example 22 is an apparatus comprising means to implement any of Examples 1-20.
Example 23 is a system to implement any of Examples 1-20.
Example 24 is a method to implement any of Examples 1-20.
Although specific examples are described herein, it will be evident that various modifications and changes may be made to these examples without departing from the broader spirit and scope of the disclosure. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings that form a part hereof show by way of illustration, and not of limitation, specific examples in which the subject matter may be practiced. The examples illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other examples may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. This detailed description, therefore, is not to be taken in a limiting sense, and the scope of various examples is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.
Such examples of the inventive subject matter may be referred to herein, individually or collectively, by the “example” merely for convenience and without intending to voluntarily limit the scope of this application to any single example or concept if more than one is in fact disclosed. Thus, although specific examples have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific examples shown. This disclosure is intended to cover any and all adaptations or variations of various examples. Combinations of the above examples, and other examples not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.
The various features, steps, operations, and processes described herein may be used independently of one another, or may be combined in various ways. All possible combinations and subcombinations are intended to fall within the scope of this disclosure. In addition, certain method or process blocks or operations may be omitted in some implementations.
Some portions of the subject matter discussed herein may be presented in terms of algorithms or symbolic representations of operations on data stored as bits or binary digital signals within a machine memory (e.g., a computer memory). Such algorithms or symbolic representations are examples of techniques used by those of ordinary skill in the data processing arts to convey the substance of their work to others skilled in the art. As used herein, an “algorithm” is a self-consistent sequence of operations or similar processing leading to a desired result. In this context, algorithms and operations involve physical manipulation of physical quantities. Typically, but not necessarily, such quantities may take the form of electrical, magnetic, or optical signals capable of being stored, accessed, transferred, combined, compared, or otherwise manipulated by a machine. It is convenient at times, principally for reasons of common usage, to refer to such signals using words such as “data,” “content,” “bits,” “values,” “elements,” “symbols,” “characters,” “terms,” “numbers,” “numerals,” or the like. These words, however, are merely convenient labels and are to be associated with appropriate physical quantities.
Unless specifically stated otherwise, discussions herein using words such as “processing,” “computing,” “calculating,” “determining,” “presenting,” “displaying,” or the like may refer to actions or processes of a machine (e.g., a computer) that manipulates or transforms data represented as physical (e.g., electronic, magnetic, or optical) quantities within one or more memories (e.g., volatile memory, non-volatile memory, or any suitable combination thereof), registers, or other machine components that receive, store, transmit, or display information. Furthermore, unless specifically stated otherwise, the terms “a” and “an” are herein used, as is common in patent documents, to include one or more than one instance. Finally, as used herein, the conjunction “or” refers to a non-exclusive “or,” unless specifically stated otherwise.
Unless the context clearly requires otherwise, throughout the description and the claims, the words “comprise,” “comprising,” and the like are to be construed in an inclusive sense, as opposed to an exclusive or exhaustive sense, e.g., in the sense of “including, but not limited to.” As used herein, the terms “connected,” “coupled,” or any variant thereof means any connection or coupling, either direct or indirect, between two or more elements; the coupling or connection between the elements can be physical, logical, or a combination thereof Additionally, the words “herein,” “above,” “below,” and words of similar import, when used in this application, refer to this application as a whole and not to any particular portions of this application. Where the context permits, words using the singular or plural number may also include the plural or singular number, respectively. The word “or” in reference to a list of two or more items, covers all of the following interpretations of the word: any one of the it ems in the list, all of the items in the list, and any combination of the items in the list.
As used in this disclosure, phrases of the form “at least one of an A, a B, or a C,” “at least one of A, B, or C,” “at least one of A, B, and C,” and the like, should be interpreted to select at least one from the group that comprises “A, B, and C.” Unless explicitly stated otherwise in connection with a particular instance in this disclosure, this manner of phrasing does not mean “at least one of A, at least one of B, and at least one of C.” As used in this disclosure, the example “at least one of an A, a B, or a C,” would cover any of the following selections: {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, and {A, B, C}.
Although some examples, e.g., those depicted in the drawings, include a particular sequence of operations, the sequence may be altered without departing from the scope of the present disclosure. For example, some of the operations depicted may be performed in parallel or in a different sequence that does not materially affect the functions as described in the examples. In other examples, different components of an example device or system that implements an example method may perform functions at substantially the same time or in a specific sequence.
Claims
1. A system comprising:
- at least one memory component that stores instructions; and
- one or more processors configured by the instructions to perform operations comprising: causing one or more self-executing contracts deployed on a blockchain network to: generate a virtual trading environment (VTE) on the blockchain network, associate the VTE with a performance tracking data feed on the blockchain network, responsive to detecting a simulated trade performed in the VTE by a trading entity, update performance data of the VTE in the performance tracking data feed, and provide controlled access to the performance tracking data feed to enable a requesting entity to utilize the performance data; and transmitting, to a user device, a message that is indicative of the performance data of the VTE.
2. The system of claim 1, wherein the operations further comprise:
- deploying the one or more self-executing contracts to the blockchain network.
3. The system of claim 1, wherein the simulated trade comprises trading of a virtual asset, the VTE storing position data with respect to one or more positions held by the trading entity, and each position being associated with a respective virtual asset.
4. The system of claim 3, wherein the providing of controlled access to the performance tracking data feed comprises:
- receiving, from the requesting entity, a request to access the performance data of the VTE;
- responsive to receiving the request to access the performance data, determining that the requesting entity is authorized to access the performance tracking data feed; and
- providing the requesting entity with access to the performance data based on the determining that the requesting entity is authorized to access the performance tracking data feed.
5. The system of claim 4, wherein the determining that the requesting entity is authorized to access the performance tracking data feed comprises validating a data usage payment.
6. The system of claim 4, wherein providing the requesting entity with access to the performance data comprises:
- determining a current portfolio value of the VTE based on at least a previously stored portfolio value of the VTE and a current price of each virtual asset of the VTE; and
- providing the requesting entity with access to the current portfolio value.
7. The system of claim 1, wherein the operations further comprise:
- providing a user interface;
- receiving, from the trading entity and via the user interface, an indication that the requesting entity is authorized to access the performance data; and
- responsive to receiving the indication that the requesting entity is authorized to access the performance data, allowing the requesting entity to access the performance tracking data feed on the blockchain network.
8. The system of claim 3, wherein a price of the virtual asset is linked to a price of a real-world asset.
9. The system of claim 8, the operations further comprising causing the one or more self-executing contracts deployed on the blockchain network to:
- use a blockchain oracle to obtain the price of the real-world asset, the price of the real-world asset being applied in the simulated trade.
10. The system of claim 8, wherein the real-world asset is a cryptocurrency asset.
11. The system of claim 3, wherein the position data comprises, for each position, a virtual asset identifier and a leverage factor.
12. The system of claim 11, wherein the leverage factor comprises a scalar value that represents exposure of the position, and the position data includes a position type indicator that indicates whether the position is a short position or a long position.
13. The system of claim 1, the operations further comprising causing the one or more self-executing contracts deployed on the blockchain network to:
- identify an order transmitted to the blockchain network by the trading entity;
- perform the simulated trade based on the order;
- responsive to performing the simulated trade, update a portfolio value of the VTE; and
- store the portfolio value in the performance tracking data feed on the blockchain network.
14. The system of claim 1, wherein the associating of the VTE with the performance tracking data feed comprises storing a one-to-one relationship between the VTE and the performance tracking data feed, the one or more self-executing contracts enabling generation of a plurality of VTEs and a plurality of corresponding performance tracking data feeds, a one-to-one relationship existing between each VTE and its corresponding performance tracking data feed.
15. The system of claim 1, the operations further comprising causing the one or more self-executing contracts deployed on the blockchain network to:
- receive, from the trading entity, a request to adjust a position associated with a virtual asset in the VTE;
- determine that the adjusted position does not result in breaching of a VTE limit; and
- responsive to the determining that the adjusted position does not result in breaching of the VTE limit, update position data in the VTE to reflect the adjusted position associated with the virtual asset.
16. The system of claim 1, wherein the requesting entity utilizes the performance data of the VTE in a synthetic asset protocol.
17. The system of claim 1, wherein the requesting entity is represented by a self-executing contract.
18. The system of claim 1, wherein the one or more self-executing contracts comprise:
- a VTE contract that provides the VTE;
- a data feed contract that provides the performance tracking data feed associated with the VTE;
- a VTE factory contract that generates the VTE contract; and
- a VTE registry contract that provides one or more functions for interacting with the VTE.
19. A method comprising:
- causing one or more self-executing contracts deployed on a blockchain network to: generate a virtual trading environment (VTE) on the blockchain network, associate the VTE with a performance tracking data feed on the blockchain network, responsive to detecting a simulated trade performed in the VTE by a trading entity, update performance data of the VTE in the performance tracking data feed, and provide controlled access to the performance tracking data feed to enable a requesting entity to utilize the performance data; and
- transmitting, to a user device, a message that is indicative of the performance data of the VTE.
20. A non-transitory computer-readable medium that stores instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising:
- causing one or more self-executing contracts deployed on a blockchain network to: generate a virtual trading environment (VTE) on the blockchain network, associate the VTE with a performance tracking data feed on the blockchain network, responsive to detecting a simulated trade performed in the VTE by a trading entity, update performance data of the VTE in the performance tracking data feed, and provide controlled access to the performance tracking data feed to enable a requesting entity to utilize the performance data; and
- transmitting, to a user device, a message that is indicative of the performance data of the VTE.
Type: Application
Filed: Aug 7, 2023
Publication Date: Feb 8, 2024
Inventor: Xavier Enrique Negron (Austin, TX)
Application Number: 18/230,692
