How Can You Build a Digital Economy When When You Base It On External Metrics of Others
There are two opposing goals for the value of the DataGrid Token (DGT):
· The first is the desire to create a usable currency. For this it needs to be stable and related to externalities, such as national economies reflected in currency exchange rates. If the DGT is stable it can see adoption for use as a means of commerce for a decentralized global economy.
· The second is the desire for the DGT to gain in value against other currencies so we can exchange some of it (i.e. USD or EUR) during an initial phase. That is, the DGT should have a lower inflation rate than other currencies during an initial phase, and a negative internal price inflation rate.
To accomplish either of these goals a means of currency supply management of the DGT is needed.
Existing Cryptocurrency Supply Management
Existing cryptocurrency supply management approaches consist of three solutions:
· Incentive rewards for performing the block mining algorithm (i.e. proof-of-work). The amount of reward per block received diminishes over time, eventually reducing to zero. This is the Bitcoin model. Eventually all of the Bitcoin tokens that will ever exist will be mined. The token supply is fixed in the longterm.
· Similarly, incentive rewards for performing the block mining algorithm, except the amount of reward per block is fixed and never diminishes. In this case the token supply increases forever. However, the percentage of increase per incentive reward as related to the total token continuously decays.
· A token generation event (TGE), which creates a fixed supply of tokens. These tokens are then distributed to accounts via some mechanism (i.e. “airdrops). Although theoretically there can be multiple TGE’s for a given token, in general such designs envision a single TGE, or at most predetermined periodic TGE’s.
In summary 2 out of the 3 solutions are essentially a fixed supply of tokens, and the 3rd ‘s rate of change of the token supply drops to negligible amounts over time, thus effectively making it also a fixed supply. In short currency supply management does not exist in the blockchain and cryptocurrency implementations.
Volume of Token Exchange
The measurement of volume of exchange of a specific token can be found on crypto exchange listing such as CoinMarketCap. This measurement shows the relationship between the token and other currencies, usually the USD. A higher volume indicates a higher demand for the token. Since the supply of any specific token is essentially fixed, as described above, the price of the token marked to other currencies increases. That is, the token itself becomes a rare commodity, resulting in large price fluctuations. Although this satisfies the second goal above, that of increasing value of the token during an initial phase, it doesn’t satisfy the first and primary goal, a usable currency.
The measurement of exchange pricing of a token with other currencies, as described above does not measure any pricing of that token used directly as a currency. If we consider a token on a blockchain used directly for instances of commerce either B2B, B2C or any other form, the token and the associated blockchain can be thought of as forming their own economy. The measurement of this economy can be thought of in similar terms to any economy as having a gross domestic product (GDP). To distinguish this from a national, regional or other geographically defined economy, we are introducing the term “Digital GDP”. Thus, the more commerce, the more things traded directly on the token’s blockchain, the larger the digital GDP of that blockchain.
The demand for a token as determined by the volume of currency exchange on an exchange listing, does not take into account demand for that token within the economy of its blockchain. As the digital GDP grows within that token’s economy, the demand for the token will increase. This has the effect of reducing the amount of token available for currency exchange since the token supply is fixed as described above, and in increasing use within the token’s blockchain economy. This simultaneously has the effect of internal price deflation within the token’s blockchain economy, while increasing the exchange rate pricing. The most notorious example of this is the “$800 million dollar pizza”.
Thus, with a fixed token supply, the internal price deflates continuously and becomes more valuable externally making it unattractive to use as a currency of exchange. Instead it becomes more of a store of value. Mining dominates over use of currency, which in the short term is very attractive and lucrative for the miners. But in the longer term, and in the extreme with dropping usage, a collapse can occur. When a large majority of the tokens are being held and not used for commerce on the blockchain, and the volume of exchange starts to drop off, hyperinflation sets in, making the coin worthless to exchange.
Digital GDP and Token Supply Management
To create a stable token with respect both to internal pricing within its digital GDP and to external exchange pricing, the supply of the token must be managed. That is, using any of the three fixed token supply models described above cannot result in a stable usable token for general commerce. Although this may be good for speculators and the initial blockchain developers, it doesn’t satisfy the first primary goal for the DGT.
In general, a well-managed economy needs a money supply management approach that controls the money supply in a manner that reflects the change in the size of the economy. As the economy is measured in GDP (nominal and real), the money supply, as measured in supply and volume, must reflect such changes. If this is accomplished than pricing, such as measured by the CPI, remains stable, and our primary goal of a stable currency is achieved.
Therefore, a decision to inflate the money supply would reflect an increasing GDP, and conversely a decision to deflate the money supply would reflect a decreasing GDP. Since it is hard to track GDP growth exactly in national economies, the usual objective is to have moderate price inflation instead. The theory is that this essentially keeps the money supply growing in line with a generally growing GDP. This makes the value of the money stable in the long run.
Relating this to the DGT in the DataGrid Blockchain economy, to realize a stable token usable for general commerce, the supply management of the DGT must reflect the digital GDP on the DGB blockchain. If this is accomplished, the phenomenon of the “$800 million pizza” is eliminated creating both internal stable pricing, and external exchange rates. This accomplishes the primary goal above.
As described above, the two goals are in opposition to each other. Since we want there to be a growth in store of value for the DGT at least in the short term, DGT supply management tracking the internal economy to eliminate price inflation and deflation (assuming we have that metric) means there would be minimal increase in the DGT value with respect to currency exchange rates. That would eliminate accumulation of value in the DGT as an investment opportunity.
What we want is a high initial growth of the DGT value, that slows down eventually to match digital GDP growth of the internal economy, and eventually targets zero internal price inflation. The initial growth satisfies the secondary goal making the DGT an investable entity, while the target of zero internal price inflation satisfies the primary goal of a cryptocurrency usable for general commerce.
Given that national economies such as the US, target a continuous price inflation, an eventual zero internal price inflation for the DGT would enable an exchange rate that increases slowly in value against other economies, (USD and EUR in particular). Stated another way, the DGT supply growth needs to reflect the growth of the internal economy as time goes on, instead of a fixed supply (either as a TGE or over time). Most people in the crypto world will not accept this concept currently, given the influence of the current success of Bitcoin as valued on crypto exchanges, focusing exclusively on deflation and store-of-value.
Managing the DataGrid Token Supply for Value Accumulation and Currency Usability
So, the question and challenge, is how to come up with a mix that satisfies short term ROI for us early investors and early adopters, while making sure in the long run that the DGT stabilizes and becomes a general, usable, currency.
The answer is that the money supply inflation initially must be less than the digital GDP growth, which will cause DGT deflation and thus accumulation in value, then allow for some sort of price stabilization, and adjust money supply against digital GDP resulting in longer term DGT price stability and usability as a general currency.
Now, the question is, how to come up with a mix that satisfies short term value accumulation and thus an ROI for us, early investors and early adopters, while making sure in the long run that the DGT stabilizes.
The way to do this is to combine the experience of both the cryptocurrency models and the national economy models. The cryptocurrency models, typified by the Bitcoin model for initial coin incentive rewards give us the deflationary model and the value accumulation and ROI desired, but add a second term in DGT supply management equation that inflates and/or deflates for digital GDP which is initially has no weighting in the supply management decision, but becomes heavier weighted over time, eventually completely dominating the supply management decision.
There are two fundamental GDP questions: what is digital GDP; and how do we measure the GDP of the rest of the world economies; Note: We’re assuming that fiat currency economies remain dominant and do not go away (e.g. USD and EUR).
For external GDP, we pick several indices, meaning GDP measurements not things like the DOW. Thus, we want both a real GDP and a nominal GDP measurement of world economies. Those type of statistics are available.
Note that since the accuracy and availability of such measurements may change over time, the DGT supply management algorithms support changing and replacing such sources of statistics under governance.
Measuring GDP in a sector can be reduced to taking total sales, dividing by average unit price, and adjusting for inflation against a baseline. So, we have to ask, how do we measure total sales and units on the blockchain.
A blockchain such as Bitcoin does not directly have any concept of sale of units of anything, which makes the concept of internal digital GDP unmeasurable. Bitcoin is kind of like having a bank account ledger where you can see the debits and credits but you can’t see what any of them were for.
Smart contracts as implement on blockchains such as Ethereum, create a separate token for each smart contract. Although it may be possible to categorize each smart contract into a market sector and determine the number of units of an entity that each token represents, then use exchange listings to come up with a measurement of internal GDP, this does not lend itself to a general token supply management solution. Further, such smart contracts do not have any common structure between them which makes any such evaluation extremely difficult.
If there is a means for internal digital GDP measurement, then there is a means to look at the P*Y side of the monetary equation for DGT supply management. If not, we can only go with an arbitrary money supply inflation model ever, just like any other cryptocurrency. That would mean the primary goal above is likely never to be fulfilled.
We are proposing as a solution that our initial incentive model is a decaying model like Bitcoin but coupled with a digital GDP inflation/deflation tracking model that dominates in the long run. We can write a function in the DataGrid Blockchain for this fairly easily, using the DGB smart object model. We would target an objective that the deflationary incentive model dies off after more like 10 years instead of the longer Bitcoin model. We believe that the digital GDP concept is a critical missing component of crypto in general.
Smart Objects Supporting Digital GDP Measurement
We can easily design smart object classes that enable measuring digital GDP. This would include fields that specify units, price, and market segment minimally. As all transactions are recorded on the DGB, and are priced in DGT, a digital GDP measurement may be derived directly. The issue is how to make sure such smart object classes get used. Further, if we mandate the use of such classes, do we cut off other unforeseen uses, which makes the DataGrid Blockchain (DGB) become less useful functionally. And, how do we make sure such a contract can’t be manipulated.
Do we consider non-smart object wallet-to-wallet exchanges as part of the Digital GDP? Foreign currency exchange essentially looks like a wallet-to-wallet exchange. This can impact velocity, independent of digital GDP. Our current thinking is that only smart contracts measure digital GDP. Wallet-to-wallet require transaction fees (i.e. “gas): Manipulating the velocity this way is likely to be a short run event.
Assuming there is a smart object class model that enables reporting units sold and price, do we mandate its use, or make it optional? If optional, then a non-reporting smart object still impacts money supply and velocity. Thus, such smart objects could cause the money supply adjustment to increase inflation. If we do make it optional, are there market forces or a Schelling point that will cause all rational users to use the smart object classes anyway?
Put another way is there a gain in doing a digital “underground economy” by not using such smart object classes? If so, can we come up with a way to abstractly measure any smart contract regardless of format against a digital GDP measurement.
We could also use a very macro scale measurement and consider a short-term smart object as a unit of measurement.
Some assumptions for Digital GDP enabled Smart Objects:
• We allow for a mix of smart objects classes that provide measurements and those that are arbitrary transfers of DGT.
• We define “one shot” exchanges which are often wallet-to-wallet, versus multi-payment which are usually instances of commerce of some kind.
• We use the smart object class concept to create “buckets” of types of commerce similar to sectors in economies.
• Smart objects that do not follow any models are considered in their own sector type.
· These can be distinguished as oneshot and multipayment only.
· They are prorated for the digital GDP based on their volume in units where a unit equals the oneshot, or a transaction for the multipayment times average price, against total DGB volume.
· Their contribution to digital GDP is then weighted by this.
These are essentially then “virtual units” and are figured in to the total digital GDP.
We couple this with a first type of smart object classes specifically for the IoT data markets as a first example. Using the XBOM smart object model, any Dapp designer can inherit the means for recording the metrics for digital GDP by using the smart object classes in the foundation classes of the DataGrid Blockchain.
Given the significant improvement in ease of use with the XBOM smart objects, and the expected Dapps that depend on them, it is expected that they will become part of standard usage and thus digital GDP measurement will become increasing more accurate as the usage of the DGB increases.
Decentralized DGT Supply Management with Digital GDP Metrics
The Digital GDP metrics derived from the DGB are calculated locally be each node given the current consensus state of the blockchain. The metrics are input to the DGT supply management function and result in changes of rate of increase or decrease of the DGT using the incentive reward and token burning mechanisms implemented in the DGB monetary policy.
Creating Digital GDP Metrics for non-conforming Smart Object Classes
As described above, we have 3 sectors: one-shot; multi-payment; and wallet-to-wallet. To determine their digital GDP, we sum the number of transactions of each type, and divide by total transactions to get their weighting. We then come up with the average unit price as total for each divided by the transaction count. We could then compare the change in transaction count against a baseline developed historically. We consider a positive change times average unit price as a weighted increase in GDP. This gives us a usage metric.
Wallet-to-wallet transfers imply token utility, but we don’t know of what. Let’s say we call all basic ledger transfers of DGT a form of general commerce. Thus wallet-to-wallet is under general commerce. We could do something like take some sort of global average of “unit price of goods”, as a measurement for general commerce measurements. The unit price of goods would be taken across all sectors defined by all smart object classes.
The implication is that something of value must have changed hands for the instances of general commerce as well. This works reasonably well if the conforming smart object classes dominate the transactions overall. Or more specifically if, the smart object classes track the average unit price of goods reasonably well. We make the assumption that this will be the case based both on ease-of-use of the smart object classes, and a Schelling point hypothesis.
Digital DGP Metrics and Conforming Smart Object Classes
The XBOM foundation classes implemented on the DGB shall include the categories of commerce defined by the US, Europe (and/or whatever is appropriate such as the G20). Using that as a basis, creates a means to establish a common set of metrics that can be understood both with the internal DGB economy and external economies. As the DGT token supply management initially is using a deflationary decaying incentives reward model, that essentially ignores all GDP metrics during the initial phase, the initial phase will be used to establish baselines for tracking.
We think what we do is create initial smart contracts that include all the categories of commerce defined by the US, Europe (or something like the G20). That way we have some means to try to establish a common set of metrics. Given that initially we are using a decaying incentives model, we can establish tracking before we use it. This allows for the establishment of long term money supply goals used as the token management supply transitions from DGT value accumulation to price stability.
External Economies and “Oracles”
Although the Digital GDP metrics can be determined locally and independently by all DGB nodes, and thus are decentralized by design, the metrics of national economies are centralized and reported by often a single source. By definition, such sources are reported as oracles with respect to the DGB. The smart objects that implement the token supply management on the DGB shall initially define the oracle sources for all such external reporting. These smart objects include methods to replace the oracle sources if/when such a need arises. A voting body shall be established consisting of stake holders in the DGB, defined as owning sufficient DGT, and/or certification of authentic identification for the purposes of controlling changes to all parameters to the DGT supply management implementation, as the form of governance. The XBOM Smart Objects can enable complete security against any unauthorized changes through the use of threshold multiple signature designs.
Note that changes to the parameters of the DGT supply management functions does not impact the functionality, but it does allow the governance body to perhaps manipulate the money supply by manipulating the source oracles for external economy metrics. Thus, the value of the DGT could become hostage to such a governance body. If confidence is lost in the governance body, then a malicious governance body might change the GDP measurements, causing either hyperinflation or stagnation. We can’t mandate that the Prasaga Foundation always controls this. That would substitute centralization in the Foundation creating the concern that the Foundation would engage in similar manipulations.
The Prasaga Foundation shall perform at least the following functions:
1: Running a root chain permanently. This is a continuity requirement to protect against catastrophic global network failures.
2: Running full backup nodes — these may be used for downloading by new joining nodes optionally
3: supporting the DGB and XBOM source code and the Foundation Institute
For consideration, the Foundation could include a charter to also provide structure for a DGT supply management governance body. Such that, if the governance body fails to elect members, the Foundation will continue to operate as a stand-in it until such seats are filled again, with some minimum quorum before the Foundation steps aside. (A discussion of how to “bootstrap” the DGB is under development.)
 Note that we are not considering political motivations that affect supply management, which have often less than optimal results.