Patent Application
20240420114
This disclosure relates to distributed consensus networks and more particularly to cryptographic protocols relating to immutable public blockchain ledgers.
Cryptocurrencies such as Bitcoin and Ethereum operate on distributed consensus networks that are recorded by blockchain data structures. A blockchain is an immutable, append-only public ledger. A benefit of such a data structure is that it is reliable, secure, and open. Some blockchain networks make use of programmable tokens and smart contracts that execute programs via a virtual machine. One such blockchain network is the Ethereum network.
The present disclosure is generally directed to providing digital token assets that simulate the performance or behavior of external real assets while reducing the influence of token exchange dynamics within the token environment. In particular, the present disclosure provides technical solutions addressing the technical challenges of providing digital twins or simulations that are susceptible to deviating from their target based on the use of the digital twins/simulations within the digital virtual environment.
In exemplary aspects of the present disclosure, a custom token protocol is designed to maintain a peg between the oracle value and the market price for a given token. The peg effectively bounds or confines the market price for a given token from deviating too far from the oracle value (e.g., the target that the given token is intended to simulate), which may occur due to fluctuations in either one or both of the market price and the oracle value. Specifically, the peg is to an externally validated value that itself can change. A given example of a peg value that may be evaluated externally and is variable is a property value of a given neighborhood or municipality. With a peg like the example provided, the custom token protocol empowers users to gain exposure to the price movement of residential real estate. Therefore, if a user buys a token, and the associated neighborhood appreciates in value by 50%, the user rightfully expects that token to appreciate in value by an amount as close to 50% as possible. In this way, holding the token can simulate the experience of holding the real estate/property/asset, while providing other benefits such as better exchangeability or liquidity and easier management. Market forces will push the token price upward or downward from the oracle value, so there is an expectation that there will be a price difference; however, a variety of token peg mechanics will keep that difference low. In the custom token protocol, the peg mechanism involves no counterparty. The smart contract to which the token is beholden causes the peg mechanism to occur without the need for both a buyer and a seller.
Furthermore, if that difference is consistent (i.e., there is a 3% token premium when a user obtains a token, and a 3% premium when that user sells the token), then it will effectively have no impact on the overall goal: if the premium on exit remains equal to the premium on entry, the net investment result will equal the price movement of the underlying real estate. The pegging function is a “soft” function in that the pegging function operates based on enabling smart contract user actions based on the externally evaluated data.
There is a trade-off between “hard” vs. “soft” peg mechanics and user experience. This user-friendly approach allows a minimal amount of token price drift vs. the underlying oracle/peg price, but that price difference is maintained to be as consistent as possible, thus rendering the difference to be an irrelevant factor when it comes to correlation between token performance and the performance of the underlying real estate.
The main peg mechanism employed is that the collateral requirement to mint tokens is linked to the oracle value, which creates an anchor to real-world real estate pricing. If the token price exceeds the collateral required ($110 in the above example), a miner can mint at the minimum collateral level and sell at the market price for an immediate risk-free profit. Even if the token price does not exceed the required collateral but approaches it from below, a miner has a strong incentive to issue and sell tokens because the de facto cost of doing so approaches zero. This mechanism limits the extent to which the token price can exceed the oracle value. An analogous mechanism exists if the token price is below the oracle value. In this case, no additional tokens would be issued, and existing issuers would have an incentive to buy tokens on the open market and burn them to retrieve their collateral, which at that point would be high relative to the token price. The essence of the above mechanism is to allow for small fluctuations in demand to be absorbed primarily by token price changes, while allowing larger fluctuations to be absorbed primarily by changes in token supply.
The blockchain includes a history of all transactions that have ever occurred on the network. Each full node in the distributed network holds a full copy of the blockchain. To participate in the network at all, the blockchain history must be consistent with the history of at least a majority of other nodes. This consistency rule has an important effect of causing the blockchain to be immutable. In order to effectively attack a blockchain, one must control 51% or more of the processing power of the entire network. Where the network comprises thousands of nodes, assembling the requisite 51% is exceedingly difficult. While it is true that many nodes often group into pools to work together to solve for nonces to propagate the blockchain, the grouped nodes of the pool do not necessarily share common control. While they have agreed to pay any mined coins to a central pot that is shared among the nodes of the pool, this is a far cry from agreeing to make changes to the blockchain.
When a given node intends to generate a transaction, the transaction is propagated throughout the nodes until it reaches a node or group of nodes that can assemble that transaction and other transactions generated during a contemporaneous period of time into a block. Until a transaction appears in a block, it is not published or public. Often a transaction isn't considered confirmed until 6 additional blocks have been added.
At the time of this filing, Bitcoin blocks are limited to the size of 1 MB and are generated approximately every 10 to 15 minutes. This illustrates an important limitation of the Bitcoin network: that it processes approximately only 7 transactions per second. Conversely, Ethereum limits block size based on the amount of processing the contracts in the given block call for, and blocks are appended every 5 to 15 seconds. While cryptocurrency networks technically begin processing transactions in real time, and the existence of a block including a given transaction verifies that transaction's authenticity, until that block is published to the blockchain, the transaction is not verified.
The presence of gaps in verification time introduces the issue within the Bitcoin network at a given moment of “who has the money?” During the 10- to 15-minute span between generation of one block and the next, transactions that have been submitted may not actually process. This would occur when a user spends money they didn't have, or double spends. This is not to say the network has no verification mechanism between blocks. For example, when a given user attempts to pay another user, the system may easily query older blocks to inspect the given user's balance as of at least the most recently published block. If the given user has sufficient funds, it is moderately safe to trust the transaction.
However, if the given user is attempting to double spend all their money, only one of those transactions will publish in the next block. The other will be rejected (which transaction is rejected and which one processes is subject to a race condition and is not necessarily dependent on time of generation).
Thus far, Bitcoin has been discussed as a network for trading Bitcoins. However, Bitcoin transactions have additional utility in that they can embed additional data. As contemplated above, Bitcoin can be used to purchase and record the existence of data at a given point in time. Recording data is performed by including hashed data within an output field of a given transaction. In this manner, the proof of existence for any document or recorded data may be embedded into the immutable history of the blockchain.
Systems that utilize the Bitcoin blockchain to transfer the ownership of non-coin assets require software that is separate from and merely relies upon the immutability of the blockchain. The separate software is not necessarily secure or immutable itself. Extra-blockchain software is thus an inherent weak point in a system that relies upon the immutability of the blockchain to ensure security. Ethereum takes the ability to buy and sell non-coin assets a step further.
Ethereum smart contracts are in effect software that runs on the blockchain. That software is open source and subject to inputs that are related to the blockchain itself. Of course, one can still write code including vulnerabilities, but the platform enables greater security and results in fewer weak links in the chain.
Every operation that can be performed by a transaction or contract on the Ethereum platform costs a certain number of gas, with operations that require more computational resources costing more gas than operations that require fewer computational resources. For example, a multiplication instruction requires 5 gas, whereas an addition instruction requires 3 gas. Conversely, more complex instructions, such as a Keccak256 cryptographic hash, requires 30 initial gas and 6 additional gas for every 256 bits of data hashed.
The purpose of gas is to pay for the processing power of the network on execution of smart contracts at a reasonably steady rate. That there is a cost at all ensures that the work/processing being performed is useful and valuable to someone. Thus, the Ethereum strategy differs from the Bitcoin transaction fee, which is dependent only on the size in kilobytes of a transaction. As a result of Ethereum's gas costs being rooted in computations, even a short segment of code can result in performance of a significant amount of processing. The use of gas further incentivizes coders to generate efficient smart contracts/algorithms; otherwise, the cost of execution may spiral out of control. Unrestricted, an exponential function may bankrupt a given user.
While operations in the EVM have a gas cost, gas has a “gas price” measured in ether. Transactions specify a given gas price in ether for each unit of gas. The fixing of price by transaction enables the market to decide the relationship between the price of ether and the cost of computing operations (as measured in gas). The total fee paid by a transaction is the gas used multiplied by the gas price.
If a given transaction offers very little in terms of a gas price, that transaction will have low priority on the network. In some cases, the network miners may place a threshold on the gas price each is willing to execute/process for. If a given transaction is below that threshold for all miners, the process will never execute. Where a transaction does not include enough ether attached (e.g., because the transaction results in so much computational work that the gas costs exceed the attached ether), the used gas is still provided to the miners. When the gas runs out, the miners will stop processing the transaction, revert any changes made, and append to the blockchain with a “failed transaction.” Failed transactions may occur because the miners do not directly evaluate smart contracts for efficiency. Miners will merely execute code with an appropriate gas price attached. Whether the code executes to completion or stalls out due to excessive computational complexity is of no matter to the miner.
Where a high gas price is attached to a transaction, the transaction will be given priority. Miners will process transactions in order of economic value. Priority on the Ethereum blockchain works similarly to priority on the Bitcoin blockchain. Where a user attaches more ether to a given transaction than necessary, the excess amount is refunded back to that user after the transaction is executed/processed. Miners only charge for the work that is performed. A useful analogy regarding gas costs and price is that the gas price is similar to an hourly wage for the miner, whereas the gas cost is like a timesheet of work performed.
One type of smart contract that exists on the Ethereum blockchain involves ERC-20 (Ethereum Request for Comment 20) tokens. ERC-20 is a technical specification for fungible utility tokens. ERC-20 defines a common list of rules for Ethereum tokens to follow within the larger Ethereum ecosystem, allowing developers to accurately predict interaction between tokens. These rules include how the tokens are transferred between addresses and how data within each token is accessed. ERC-20 provides a framework for a means to build a token on top of a base cryptocurrency. In some embodiments herein, enhancements are built on top of the ERC-20 framework, though use of the ERC-20 technical specification is not inherently necessary and is applicable to circumstances where Ethereum is used as the base cryptocurrency.
Thus far, discussion has been focused around Bitcoin and Ethereum. As applicable in this disclosure, these are base cryptocurrencies. Other base cryptocurrencies exist now and will exist in the future. This disclosure is not limited to application specifically on the Bitcoin and Ethereum blockchains.
The custom token is a protocol that allows anyone to trade synthetic land tokens that track the price of residential real estate in a given neighborhood. Each land token represents a square foot of real estate for a given neighborhood, and the pricing of each token tracks the average $/sqft of residential real estate for that neighborhood.
In step 300, a peg mechanism obtains an oracle value. The oracle value is an externally verifiable datapoint that varies over time. Step 300 is performed at regular intervals to update the existing oracle value. The oracle value pertains to a particular cryptographic token, and the disclosed platform may include a significant plurality of different digital token assets. For example, a first token associates with an oracle value of a square foot of real estate in the San Francisco Bay area of California, whereas a second token associates with an oracle value of a square foot of real estate in the city of San Francisco proper. A third token associates with an oracle value of a square foot of real estate in San Jose, California. A fourth token associates with an oracle value of a square foot of real estate in the SoMa (South of Market) neighborhood of San Francisco.
Which externally verifiable data is used as an oracle value alters the manner in which the data is obtained. With respect to real estate values, real estate sales data is public information, and all sales occurring in the relevant geographic area associated with a given token over a period of time are averaged together. The period of time is predetermined and included in the smart contract for the custom token protocol. Example periods include daily, weekly, and monthly.
In step 302, a user makes a request of automated market makers (AMMs) on public blockchains, taking long positions on various neighborhoods and subsequently realizing gains (or losses) depending on market performance. While counterparty trades are available to users, smart contract peg functions do not make use of counterparties. The action taken by the user is a “mint” action. Anyone can mint a land token by locking up collateral in the form of a digital asset (e.g., a stablecoin). The mint action is functionally akin to receiving or purchasing a token from the protocol (e.g., from a token pool with a finite supply of tokens).
Core to the custom token protocol are the neighborhood oracles. These oracles act as the source of truth for the actual $/sqft pricing of each neighborhood supported on the platform. When a user wants to mint a land token, the collateral needed is calculated against the oracle value for the given neighborhood. For any given land token, there is a minimum collateral requirement that is a multiple of the underlying price of the neighborhood's real world $/sqft price (for example, 110% for stablecoin collateral in low-volatility neighborhoods). For instance, the minting value or price simulates or approximates the real world $/sqft price by a variable approximation factor, which can be the collateral requirement. For instance, if houses in a given neighborhood are selling for an average of $100/sqft, then in order to mint a land token for that neighborhood, a user would need to put up at least $110 worth of stablecoin as collateral.
In step 304, the user executes a “burn” function. A user who has previously minted/borrowed tokens can burn (or “redeem”) up to the initially minted amount of tokens to receive their locked collateral. This may be done at a later point in time, so that the user receiving their locked collateral may be processed according to a different real world $/sqft price (e.g., an increased real world price, a decreased real world price) and/or a different market value of the tokens.
The custom token protocol is designed to maintain a peg between the oracle value and the market price for a given token. Ultimately, the goal of the custom token protocol is to empower investors to gain exposure to the price movement of residential real estate. Therefore, if a user buys/mints a token, and the associated neighborhood appreciates in value by 50%, the user rightfully expects that token to appreciate in value by an amount as close to 50% as possible. Market forces will push the token price upward or downward from the oracle value, so there is an expectation that there will be a price difference; however, a variety of token peg mechanics will keep that difference low.
The smart contract allows for a minimal amount of price drift vs. the underlying oracle value, but the smart contract maintains that price difference to be as consistent as possible, thus rendering the difference to be an irrelevant factor when it comes to correlation between token performance and the performance of the underlying real estate. That is, the smart contract maintains the underlying real world values or prices as the principal driver for token value, and provides a degree of resilience for the token value to token market forces.
In step 306, when the token has a value a threshold percentage above the oracle value, the smart contract enables free or discounted minting. For example, the minting function defined in the token specification or protocol is modified to provide free or discounted minting. If a user can mint a token for less than they can sell it for, then an arbitrage opportunity exists that will exert downward price pressure due to supply flooding the market. Specifically, the “free” minting action drops the required collateral ratio (e.g., or variable approximation factor) or introduces negative fees. The platform moves the required collateral ratio down or makes fees negative in order to trigger “free minting” at a lower price than outlined above in step 302.
Conversely, in step 308, when a token has a value a threshold percentage below the oracle value because of oracle upward price movement (i.e., real estate has gone up), the smart contract enables short liquidation. For example, short positions that were enabled by the functions defined in the token specification or protocol are closed and disabled after the functions are (temporarily) modified. Specifically, if the oracle value moves up, existing short positions (e.g., borrowed amounts of a token) are liquidated (e.g., returned to the token pool) in order to buy back tokens to be burned. This will occur because short positions will drop below their minimum required collateral level.
In step 310, when the token has a value a threshold percentage lower than the oracle value because of token downward price movement (i.e., there is a token over-supply in the token pool), the smart contract enables short closing positions, for example, by enabling borrowing requests for amounts of the token (i.e., shorting the token). For example, the functions defined in the token specification or protocol are modified or made available to enable short positions. Where the token price goes down, short positions are incentivized to buy tokens in order to burn and get their collateral back, thus adding upward pressure to the token price. Bidirectional mechanics push the oracle and the token value together, regardless of which is higher or why.
The oracle is a compromise between accuracy and ease of replicability. The oracle operates on objective and consistent rules and does not seek to maximize pricing accuracy for all homes. In other words, the oracle methodology is designed to capture market evolution of a typical home over time. It is not an automated valuation system.
In step 402, the oracle determines the physical characteristics of a typical home for a particular neighborhood selected. An example of such a determination uses all transactions from the past 60 days that are similar to the typical home. If there are not enough transactions, geography is expanded to include transactions that are similar to the typical home until a predetermined minimum of number transactions is reached (e.g., 50). The oracle then computes the median price per square foot of the selected transactions. Below, Table 1 describes a number of illustrative factors that the oracle can use to identify a typical home in a particular geography.
In some embodiments, the oracle uses the characteristics in table 1 and no others. Notably, Table 1 is a rather limited list of ways to classify real estate. Many other physical and neighborhood characteristics influence the price of a home. For example, factors such as school quality and walkability are critical determinants of home prices. However, the oracle defines neighborhood as a relatively small geographic space, the exemplary geographic factors affect the price of all properties within a neighborhood in a similar way. Therefore, there is no need to use these variables to select the sub-set of observations that are most alike the typical house.
That said, the above does not mean neighborhood characteristics are ignored. On the contrary, changes in neighborhood characteristics over time affect transaction prices, which, in turn, determine the oracle price. In some embodiments, the oracle further relies on neighborhood boundary data. The boundary data allows the oracle to identify the transactions that fall within each neighborhood for which a cryptographic token is available.
Determining the proper physical characteristics to consider and the proper filters is the result of substantial experimentation. There are trade-offs between including more observations and including only similar observations, and the oracle uses limited characteristics to offer a good compromise between conflicting goals.
The oracle does not make use of traditional economic evaluation of real estate. The method is distinct from other valuation methods because the method focuses on the time evolution of the price of a typical or representative home, rather than the evaluation of every home. The oracle does so in a basic and simple way that captures change over time as opposed to accurate quotes.
In step 404, the observed data is filtered. As the goal is to capture the evolution of the price of a typical home over time, rather than estimate the value of a wide range of homes, the oracle applies filters to observed data. For example, observations whose house size and lot size are below 10th percentile or above 90th percentile of the sample are filtered out. Observations whose number of bedrooms and number of bathrooms are below the 1st percentile or above the 80th percentile are filtered out. Once filtered, the oracle determines the median characteristics of the remaining homes in each neighborhood. A property with the median characteristics defines the typical or representative home for each neighborhood. This representative property may be hypothetical or virtual, being the median of multiple dimensions of attributes or characteristics.
To estimate the median price, the oracle includes completed sales from a preceding period (e.g., 30, 60 days) includes observations whose size, lot size, number of bedrooms, and number of bathrooms are within 75% of the same characteristics for the typical home.
In step 406, the oracle is distributed across a blockchain network. The values in step 402/404 are sourced for typical homes in each neighborhood from community providers. The providers are rewarded for the accuracy of their estimation. Distribution eliminates a potential single point of failure for the system that provides the peg the land tokens are associated with. Distribution is performed first by identifying homes that are currently listed for sale and that meet the filters described in step 404 above. In step 408, periodically (e.g., daily) each distributed oracle provider estimates a sale price for those homes, assuming the home sells on that day. If and when a home sells, the difference between the predicted price for the sale date and the actual sale price is recorded. Oracle providers are rewarded based on the accuracy of their price prediction. In this manner, the predictive function of the oracle providers can be trained and improved.
In step 410, the platform periodically determines the median price prediction for each home and then the median across all homes in the sample. With a large number of participants, no participant has the ability to influence the median price. Oracle participants are incentivized to provide accurate predictions. Distribution estimates the current market value of each home in the sample in a decentralized and robust manner.
In some embodiments, once the oracle defines the physical characteristics and location of a typical home in a given geography, the oracle does not change those characteristics even if the composition of sales or homes changes over time. The consistency ensures that changes in the oracle values reflect changes in the market prices in a neighborhood, rather than changes in the characteristics of the typical home.
Below is an example computation of an oracle value for Beverly Hills, California. Table 2 below describes home variables for Beverly Hills.
The estimated value and price per square foot for this typical home on a day contemporaneous with filing of the instant application is $1197.
Table 3 provides a sample list of real estate transactions that occurred in prior to that date from which the $1197 figure is derived and meet the filters described above. The median price per square foot of the 8 transactions reported in Table 3 is $1236. As stated above, the median of full sample is $1197, which constitutes the oracle price but differs from the actual values.
In the free mint region 502, the collateral cost of minting is lower than the market value. In the liquidation region 504, the collateral that can be obtained by burning tokens has more value than the token. Both functions operate without a counterparty and are native functions of the smart contract.
In the illustrated embodiment, the processing device 600 includes one or more processors 610, memory 611, a communication device 612, and one or more input/output (I/O) devices 613, all coupled to each other through an interconnect 614. The interconnect 614 may be or include one or more conductive traces, buses, point-to-point connections, controllers, scanners, adapters, and/or other conventional connection devices. Each processor 610 may be or include, for example, one or more general-purpose programmable microprocessors or microprocessor cores, microcontrollers, application-specific integrated circuits (ASICs), field-programmable gate arrays, or the like, or a combination of such devices. The processor(s) 610 control the overall operation of the processing device 600. Memory 611 may be or include one or more physical storage devices, which may be in the form of random access memory (RAM), read-only memory (ROM) (which may be erasable and programmable), flash memory, miniature hard disk drive, or other suitable type of storage device, or a combination of such devices. Memory 611 may store data and instructions that configure the processor(s) 610 to execute operations in accordance with the techniques described above. The communication device 612 may be or include, for example, an Ethernet adapter, cable modem, Wi-Fi adapter, cellular transceiver, Bluetooth transceiver, or the like, or a combination thereof. Depending on the specific nature and purpose of the processing device 600, the I/O devices 613 can include devices such as a display (which may be a touch screen display), audio speaker, keyboard, mouse or another pointing device, microphone, camera, etc.
Unless contrary to physical possibility, it is envisioned that (i) the methods/steps described above may be performed in any sequence and/or in any combination, and that (ii) the components of respective embodiments may be combined in any manner.
The techniques introduced above can be implemented by programmable circuitry programmed/configured by software and/or firmware, or entirely by special-purpose circuitry, or by a combination of such forms. Such special-purpose circuitry (if any) can be in the form of, for example, one or more ASICs, programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), etc.
Software or firmware to implement the techniques introduced here may be stored on a machine-readable storage medium and may be executed by one or more general-purpose or special-purpose programmable microprocessors. A “machine-readable medium,” as the term is used herein, includes any mechanism that can store information in a form accessible by a machine (a machine may be, for example, a computer, network device, cellular phone, personal digital assistant (PDA), manufacturing tool, any device with one or more processors, etc.). For example, a machine-accessible medium includes recordable/non-recordable media (e.g., ROM, RAM, magnetic disk storage media, optical storage media, or flash memory devices), etc.
Physical and functional components (e.g., devices, engines, modules, data repositories, etc.) associated with the processing device 600 can be implemented as circuitry, firmware, software, other executable instructions, or any combination thereof. For example, the functional components can be implemented in the form of special-purpose circuitry, one or more appropriately programmed processors, a single board chip, an FPGA, a general-purpose computing device configured by executable instructions, a virtual machine configured by executable instructions, a cloud computing environment configured by executable instructions, or any combination thereof. For example, the functional components described can be implemented as instructions on a tangible storage memory capable of being executed by a processor or other integrated circuit chip (e.g., software, software libraries, application program interfaces, etc.). The tangible storage memory can be computer-readable data storage. The tangible storage memory may be volatile or non-volatile memory. In some embodiments, the volatile memory may be considered “non-transitory” in the sense that it is not a transitory signal. Memory space and storages described in the figures can be implemented with the tangible storage memory as well, including volatile or non-volatile memory.
The processing device 600 may be described as a “node.” A “node” or “network node” may refer to a connection point in a communication network. A network node can be a physical electronic device that is capable of creating, receiving, or transmitting data. In some embodiments, a network node may be a computing device within a record-keeping network (e.g., a blockchain network). A network node may be able to create a data package (e.g., a data payload), transfer a data package, receive a data package, validate a data package, access a central record, and/or perform any other suitable functions. Different types of network nodes may be able to perform different sets of functions within a recording network. In some embodiments, a network node may be associated with and/or operated by a resource provider such as an online service provider, a content provider, a certificate authority, a financial institution (e.g., a bank), a merchant, a transaction processing network, or any other suitable entity.
This application claims priority to and the benefit of U.S. Provisional Application No. 63/508,124 titled “DISTRIBUTED BLOCKCHAIN PROTOCOL THAT AUTOMATICALLY ADJUSTS TO EXTERNALLY MEASURED CIRCUMSTANCES” and filed on Jun. 14, 2023. The entirety of the contents of the aforementioned application are incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 63508124 | Jun 2023 | US |
