Pegged tokens are generally useful for payments, treasury management, exchanges, and wealth preservation. A Pegged Token network defines a set of pegged tokens, which reflect real market assets such as currencies, precious metals, other cryptocurrency assets, commodities, etc. For example, a token pegged to USD can be used to make USD purchases, and both the buyer and seller can be assured of the payment with the pegged value will be very close to equal to the dollar equivalent. For companies holding cryptocurrency assets, the ability to convert parts of those assets into a dollar peg can help to preserve capital when the cryptocurrency market is low. Exchanges that deal only with cryptocurrencies can use values pegged to real-world currencies to create pegs to USD or EUR without having to deal with the traditional banking system to hold those assets. Tokens pegged to other assets like precious metals allow users to hold Gold or Silver values on a cryptocurrency exchange. Pegging to cryptocurrencies can facilitate transactions representing Bitcoin or other cryptocurrency values without the transaction limitations that might exist on the those blockchains. Pegging values to other commodities or assets are possible, expanding the use cases for a Pegged Token Network. This paper describes Pegged Token Networks in more detail, and goes into an implementation and design of such a network, based on the Factom Protocol.
A pegged token is often referred to as a stable coin. To date, stable coins are single tokens that use a range of mechanisms to maintain their peg to the real world assets they represent. PegNet is a Pegged Token Network, and it leverages simple game theory and a set of pegged tokens that self reinforce each other in holding their mutual pegs. The network provides a mechanism for managing payments, treasury allocations, risk abatement, arbitrage, and budgets across jurisdictions without requiring expensive and slow processes through external parties such as financial institutions, payment processors, exchanges, etc.
A possible set of assets that would have corresponding pegged tokens might include:
|US Dollar||Gold||PEG (The PegNet Token)|
|Swiss Franc||Bitcoin Cash|
|Indian Rupee||Binance Coin|
|Hong Kong Dollar||Monero|
The pegged token for an asset would be designated by adding a ‘p’ to the asset designator. So the pegged token tracking USD would be pUSD. Gold would have a pegged token of pGold. Having a range of pegged tokens would allow the user of PegNet to maintain their holdings in any of the assets supported, and to make transactions in any of the assets supported. Asset selection should be driven by market value, availability of market data, and value of the use cases for the pegged token.
The Pegged Network implementation is very simple. First of all, the Peg (PEG) is the base token of the PegNet. To bootstrap the network the value of PEG will be pegged to 1 to 1 with the aggregated value of all the assets on the network. After PEG is listed on exchanges the peg will be removed and the PEG price will be allowed to float according to the market price on the exchanges.
A Pegged Network works by allowing users to convert between assets as they wish, according to a set of prices supplied by the Oracles parties that publish price data to the Pegged Network. See the section on Oracles. When a Pegged Network launches, there are only PEG tokens created through mining and the burning of the Factom Protocol’s FCT token to pFCT. pFCT can be converted to other assets according to the Oracle prices. And PEG can be priced by the assets in the PegNet, allowing its conversion into other assets. When the Peg is converted, it is destroyed, and the pegged token is created. The source of the conversion is the backing for the creation of the destination.
Arbitrage will be the mechanism to maintain the pegged prices on exchanges. Consider the case in the figure below. In this example, pUSD is being priced at .95 cents at an exchange, while PegNet can convert 1 PEG (worth $3 at the exchange) to 3 pUSD.
A savvy trader can now use PEG to buy pUSD at a discount on the exchange while making the opposite conversion on the Pegged Network:
In this example, users are motivated to buy up low priced pUSD on exchanges, since the peg value of pUSD is below the market for USD. Users can both wait for the peg to recover, or go to the Peg Network and maintain their position with a balancing conversion on the Pegged Network. The gain is a shade over 5 percent, and in the example above the user takes that 5% in PEG. Of course, they can easily take the 5 percent in USD as well.
The same principle also applies in reverse. In the figure above, the pUSD token is priced higher on an exchange than the value that can be gained from the conversion of tokens through PegNet. Users are then motivated to buy PEG with high priced pUSD on exchanges since the peg value of pUSD is above the market for USD. First Image
Users can simply take their gain on the exchange, or go to the Peg Network and maintain their position with a balancing conversion on the Pegged Network. The gain is a shade over 5 percent, and in the example above the user takes that 5% in pUSD on the exchange. Of course, they could keep their gain in PEG too. Second Image
A network of pegged tokens is more efficient than a simple two token system, such as one with a peg token and a pegged asset. The PegNet increases liquidity and stability of value by aggregating the fractional interests of each reference currency/commodity/token (population of participants) capable of executing an arbitrage. This is because having more tokens means that the arbitrage has greater leverage when balancing a pegged token that is below its peg with a pegged token that is above its peg. So for example if pUSD is below its peg by 5% and pEUR is above its peg by 5%, you might get the following:
In this example, pEUR is below its peg by 5 percent, and pUSD is above its peg by ~5 percent. The arbitrage works to bring both the pEUR and the pUSD to their pegged values and netting the arbitrager 10% gain, which can be held in pEUR or pUSD (choice of the arbitrager).
One of the acknowledged issues with cryptocurrency for payments is the currency risk taken by the buying and selling side of a transaction. Users may feel more comfortable with a particular mix of assets and wish to frictionlessly leverage those assets in a purchase. For example, a consumer might hold a volatile asset like Bitcoin and make purchases with that asset from time to time. In an ideal world, the consumer should be able to convert the Bitcoin to the payment asset requested by a Merchant and make the payment without the friction of going to an exchange.
Of course, cryptocurrency and commodities like metals generally involve a third party to convert to USD or EUR or any other fiat currency, and that friction is fairly large. Currencies are more easily converted, but at the cost of currency exchange. These rates and fees can be quite significant, adding friction to transactions. The PegNet allows conversion to pegged tokens that track a wide range of currencies, and allow the user to maintain their value in a large set of currencies and assets, and make payments in any of the other pegged currencies and assets without a third party, at a fair market rate, and on-demand. This limits the friction of transactions and simplifies the payment process on both the buyer and seller side. Additionally, the on-ramp and off-ramp into the PegNet is quite flexible. Any of the Pegged tokens on an exchange can serve as a means of moving value from fiat and cryptocurrencies into pegged tokens. When moved from an exchange to a user’s wallet, those tokens can be converted at will to the desired token or currency, or utilized for payments in any pegged token. Likewise, users can move value from pegged tokens into fiat or cryptocurrencies, via exchanges.
The implementation of the conversion between tokens is pretty simple. You take a source token and specify a destination token. The source token and destination token can be the PEG token or any of the pegged tokens like pUSD, pEUR, pGold, pBTC, etc. The source token is destroyed, and the destination token is created. The value of each side of the conversion is defined by the oracle, and no additional value is created or destroyed. Consider converting 1 token of pBTC to pGold (price in grams). The Peg Net software computes (from the Oracle Price) the USD value of pBTC and the USD value of pGold. The pBTC token is destroyed (destroying the USD value of the pBTC), and the pGold tokens created (creating the same USD value of pGold). Today a FCT address in the Factom Protocol is actually the hash of an RCD (Redeem Condition Data structure). This hash serves as the public key providing control of any number of the PegNet assets, as well as FCT. Each user of the PegNet protocol is potentially an issuer of tokens (by either burning FCT to create pFCT as a one-way conversion process), mining PEG (by providing oracle data), or converting assets they are holding in the PegNet to other PegNet assets. So an address in the PegNet can be used to make conversions between any of the tokens in the PegNet, and to create transactions that send PegNet tokens to other PegNet addresses. Conversions between tokens have the following fields:
A single address can carry balances for all of the tokens in the PegNet. So a user can send and receive pUSD from the same address as they can send and receive PEG. From a user experience perspective, the wallet generates particular typed address representations for a particular token in the PegNet. This prevents someone from accidentally sending PEG to a pUSD address.
The PegNet uses a Proof of Work system to collect pricing data from the market. Miners are required to invest resources in providing the real time market data to PegNet. As part of the Proof of Work, bad market data is filtered out. Where the investment for submitting data is significant, submitting bad data is not worthwhile because it is ignored, and submitting good data is rewarded.
As long as most miners submit good data, the pricing data from the Oracle can be trusted. This means that the network can access real-world market data. Once collected, the Oracle data is published to the Factom blockchain. The PegNet Oracle algorithm leverages the protocol’s 10-minute blocks and has a flexible difficulty mechanism to fit within the Factom block structure.
Factom blocks are ten minutes long and are divided into 1-minute sections. Data can be viewed as having been recorded in each one minute section of a block as the protocol records the data. So Oracle mining is proposed to work like this:
The goal here is to encourage mining the latest price in the 10-minute block (where using delta^4 scoring for the rewards would herd miners too hard towards price agreement, which most easily occurs early in the 10 minutes).
The PegNet wallet is built off the FAT protocol wallet. It enables the user to convert between Pegged Tokens. This only involves the user, and the user’s construction of a conversion, and writing the conversion to the PegNet chain on Factom. No exchanges or other intermediaries are involved.
The PegNet Wallet evaluates all the transactions, and computes the balances for all assets at all addresses. The wallet picks up and uses the Oracle Price Records for token conversions.
The PegNet Wallet is also compatible with other fungible and non-fungible FAT tokens. An ecosystem that allows the exchange of FAT tokens with PegNet tokens is possible. Key to the PegNet network is that the wallets calculate the balances of tokens without the need for operators or centralized authorities.
The PegNet explorer will display the activity that happens on the PegNet protocol. It will also show price histories as recorded by the Oracle Miners. Statistics like hash power, submitted values, differences in values, and more can be shown as well.
Using the Factom Protocol a PegNet Chain will be created that defines the assets to be tracked by the PegNet. The chain will have an Asset Entry where its fields the assets to be tracked, as designated by ISO 4217 (where possible), and their PegNet designation. So the fields would be:
|Hong Kong Dollar||HKD||pHKD|
|Gold Troy Ounce||XAU||pXAU|
|Silver Troy Ounce||XAG||pXAG|
The PegNet Chain defines the assets that are included in the Oracle Price Records built and mined by the PegNet miners.The suggested list above would launch the PegNet with 32 assets. This list can be updated in the future via one of a number of decentralized decision processes, where the demand in the user community is assessed, the miners signal agreement by including pricing information, and the developers provide updates that activate the changes. In order to begin mining, the code to grade and rank the Oracle Price Records, and provide the mining balances for review has to be written. Starting with the above mentioned set of assets will provide for many use cases. Particularly the support for 14 of the most significant currencies of the world in terms of commerce, remittance, and store of value can stand in for settlement and support payments without currency exchanges taking a cut in the middle. Assets pegged to cryptocurrencies and precious metals will allow transactions in those assets with a relatively easy transition to currencies.
The mining of the PegNet allows CPU mining and avoids the centralization of mining that occurs when mining becomes dominated by ASICs and even GPUs. This is done by using a new mining algorithm that targets a different bottleneck in computation than simple hash execution.
Because sha256 and other mining algorithms are computationally expensive, they are limited by the speed of execution of their code, and computation consumes about 90 percent of the power of most computer systems. Specialized hardware may use less power, but the energy usage for computation may be higher.
Early algorithms like Litecoin’s script hash require more memory, but remain mostly computationally bound.
LXRHash targets random byte access speed over a large ByteMap of randomized data. This approach pushes more than 90% of the time of calculating hashes to the time it takes to access a byte from memory outside the caches on the processors running the hash.
This can be demonstrated in the figure below looking at LXRHash performance as the ByteMap grows.
LXR Hash Community Testing #1 - Link On Discord
Because processors are designed to have memory access optimized and associated with the cores available in a processor, more hashes can be achieved by running in parallel threads of mining software for every core in the processor. Running more threads over the number of cores does not increase the hash rate once the thread count is higher than the core count. As seen in the graph below: LXR Hash Community Testing #2 - Link On Discord
This section will go into game theory and economics of the Pegged Network in greater depth in this section.
This section introduces several possible scenarios where there is a lack of balance in the market and demonstrates how these would be resolved by the incentives built into the design of the PegNet.
A) The pXXX token is traded with low liquidity, at a price below the peg recorded as the Oracle Price in PegNet. pUSD is traded at the peg recorded in the Oracle Price, but with low liquidity. An arbitrager can make the purchase of pXXX with any asset they might have, move pXXX to the pegged network and convert to pUSD. If pXXX has low liquidity, very little arbitrage is required to buy pXXX at the below reference price, move the resulting pXXX to the PegNet, and convert to a high liquidity asset like pUSD.
B) The pXXX token is traded with high liquidity, at a price below the peg recorded as the Oracle Price in PegNet. pUSD is traded at the peg recorded in the Oracle Price, but with low liquidity. An arbitrager can go the same route as in example A), but can only do so over time as the arbitrager will be constrained by the liquidity of the pegged tokens. With high liquidity, pXXX requires more arbitrage to reach its pegged value, but this is also a greater opportunity for arbitragers.
C) All pegged tokens, pXXX traded on exchanges are below the peg recorded in the Oracle Price, and the liquidity of all assets is low. PEG will remain at the market price (as its price is set by the market). So arbitrage that sells PEG to buy any pXXX assets can be balanced by conversions to PEG in the PegNet. This will reduce the supply of the pXXX assets and allow the arbitrager to gain in XXX assets on the Exchange, pXXX assets, or PEG.
In addition, The arbitrager taking the longer view can buy any of the pegged tokens with any exchange asset XXX. If XXX has a peg in the pegged network, they can accumulate that value within the pegged network. Only very small numbers of such traders are required to correct pegs when liquidity is low.
D) All pegged tokens traded on an exchange are below the peg recorded in the Oracle Price, and liquidity of all assets is high. Same as C, only with high liquidity there are both buyers and sellers of the pegged tokens. This informs the arbitragers that once the sellers are out of tokens, the price will recover. So the same path as C) works.
E) All pegged tokens traded on an exchange are above the peg recorded in the Oracle Pricepeg, and the liquidity of all assets is high. PEG remains at market price (because its price is set on the market) and can be used to arbitrage against all the pXXX assets above peg. So PEG assets can be moved to the PegNet to increase pXXX supplies, move them to exchanges, and continue selling pXXX assets until they match their reference price in the market.
PegNet enables solutions to a host of financial services use cases. Here are three example areas:
If insufficient hash power is provided by Oracle Miners, then it will be difficult to prevent bad actors from publishing false Oracle prices. If a majority of Oracle Miners publish bad data to the PegNet then Pegged Tokens will be converting at incorrect or misleading prices.
The first mitigation strategy is the selection of the LXR hash algorithm. As existing miners of other crypto projects are not yet using this algorithm there will be a time lag before members outside the direct PegNet community are likely to join as Oracle Miners. The second mitigation method is to achieve a wide distribution of Oracle miners to place a sufficient amount of Hash power on the PegNet at the time of launch to ensure good actors who are interested in the success of the PegNet system are the earliest adopters.
There are two legitimate ways to generate pegged tokens in the PegNet system. Firstly to burn FCT into pFCT and the second is to mine PEG as an Oracle and convert the resulting PEG into any pegged token. It seems likely that the amount of hash power that will be attracted to the PegNet will be in proportion to the amount of Pegged Tokens that are generated. This may be an incorrect assumption, but as an experimental system, it will be interesting to see the balance that develops between users generating pegged tokens via FCT burning or Oracle Mining.
Because mining is more time and labor-consuming than burning FCT into pFCT and converting to other PegNet tokens, it would be expected that the majority of the assets will be generated via burning. However, this also depends on how the market values the PEG token which is rewarded to the Oracle Miners.
For mitigation of this risk, the PegNet community can encourage exchanges, traders and arbitrators to create a healthy and consistent volume of Pegged Tokens created via burning and flowing onto and off of exchanges. Arbitrageurs will use tokens most above their reference value to sell to buy tokens most below their reference value as that provides the most gain. At the end of the day, PEG becomes the fallback asset for arbitrage as it’s peg is set to the market price and thus will always be very close to the PegNet value for PEG as it comes from the market. Demand for PEG will be driven by arbitrage and scarcity, as it never has to be liquidated as PEG on the markets. Both FCT and PEG will serve as gateways into the PegNet. FCT when the market is growing, and PEG if the market contracts or is stable for the PegNet.