This research proposal describes a collateral-backed stable-coin system implemented on a public blockchain, where the exclusive backing collateral is the native blockchain asset token, and where the stable-coin is pegged to the value of a widely accepted reference currency.
A collateral backed stable-coin system ensures the stable value of a digital token, through securing backing collateral of equal or higher value, and by balancing token supply and demand through adjusting monetary variables using market pricing information. Variations of such a system, such as MakerDAO’s DAI token, have already been implemented on public blockchain smart contracts. In case of our Minimum Viable Product (MVP) implemented on Ethereum, the native blockchain asset token is ETH and the reference currency is USD ($). Unlike other similar systems however, the proposed system contains no on-chain governance process and no tokens for governance or equity. The proposal posits that eliminating these, in favor of an on-chain incentive system, reduces centralization, and increases the capital efficiency of the system.
Other sections outline:
This section outline:
The system supports pegging to any relatively stable real world currency, as well as other relatively stable baskets of assets, always backed with the most trust-minimized blockchain collateral (ETH in case of Ethereum). The main viable implementation of this system however will focus on the US dollar due to its relative ubiquity at time of this writing.
The pegged currency money is the product that is ultimate offered to everyday digital money users and holders. It will have a stable value, the unit of which, should already be (or will be) widely accepted and used in everyday commerce transactions by buyers and merchants. The Ethereum based MVP implementation of this system will use a custom ERC20 that represents the value of the US Dollar ($).
The token requires the base functionality already available in common programmable digital tokens, such as basic transfer functionality between accounts. The Ethereum community’s version of this functionality is described by the ERC20 standard also described here;
Additional functionality will be implemented to respectively “mint” or “burn” tokens upon “issuance” or “return” of the pegged currency on the loan contract.
This is the real world currency, or unit of account, the pegged currency will be pegged to. For example, the US dollar ($) is the most commonly used reference currency in most existing stable-coin implementations.
The system is designed such that it would work with any relatively stable currency, or basket of goods, assets and/or currencies. Any user can create a new currency peg to their target currency reference, by deploying the open source contracts including a custom token representing their pegged currency.
As mentioned, any public blockchain’s native asset token satisfies the role of backing asset given that it is likely to be:
It is essential for the system to prevent significant issuance of pegged currency, without securing a corresponding value of backing asset, per loan instance, and for the system as a whole. Similarly, it is crucial for the system to respond to backing asset release requests, when corresponding pegged currency is being returned to the system. In a healthy system, the value of the backing asset token is greater than the pegged currency by a healthy margin, in order to insure against the possibility of a major devaluation in that backing asset.
Loans (aka debt positions) are the logical structures that hold the state and value of the collateral backing aspect of the system. They have the following notable properties:
backing / issuance = 150%.
Loans consist of the following state or calculated values:
Loan takers pay a fee based on the value of the loan’s issued pegged currency, and based on a variable daily percent rate (See Loan fee rate under monetary variables) set by the main system’s monetary policy engine. The fee has to be paid as part of structural changes made to the loan, including changes to allocation or issuance. For example, at a given point, the loan fee rate might be
4% per year, (equivalent to
0.01096% per day). Assuming no change to the rate (unlikely), the loan taker should expect to pay
$400 per year in fees on a loan that has issued
$10,000 worth of pegged currency, upon closing the loan. In reality, the yearly fee is determined by the sum of all daily rates throughout that year.
A part of the fees paid by loan takers, will go to the price feed providers. The specific value going to price feed providers is calculated based a weekly variable rate determined by the monetary engine (See price feed revenue rate under monetary variables). This value is allocated to specific price feed providers based on the allocation table values (See loan price feed allocation) of the loan.
The rest of the fees paid by loan takers, will go to the savings pool, to eventually be distributed to savings account owners based on the monetary engine’s savings interest daily rate (See Savings interest rate under monetary variables).
Every loan (aka debt position) can allocate one or many price feeds providers by weight for their loan. For a given loan, these allocations are weighted by percentages that add up to
100%. For example: a loan may allocate
40% to the price feed maintained by Foundation X,
35% to Rating company Y and
25% to Financial company Z for a total of
A part of the fees paid by loan takers, will eventually go to the price feed providers as revenue. The specific value going to price feed providers is calculated based a weekly variable rate determined by the monetary engine (See price feed revenue rate under monetary variables). That value is distributed to specific price feed providers, based on the allocation table values of the loan. Loan takers are responsible for determining the allocation mentioned above, based on which price feed providers they trust and/or want to financially support.
At level of the entire system, we add up the total allocation values resulting from allocation percentages multiplied by the issuance value of each loan. For example consider a single loan with issuance value
$100,000, that has three allocations A at
50%, B at
35%, C at
25%. The single loan will contribute to the price feed providers’ revenue pools by
$50,000 for A,
$35,000 for B and
$25,000 for C. If the whole system consisted of say
200 loans, that are same as the one above (very unlikely), the total allocation numbers for the price feeds will be
$10,000,000 for A,
$7,000,000 for B and
$5,000,000 for C. Based on a projected price feed revenue rate of say
1% per year, the projected increase to each of their revenue pools would be
$100,000 for A,
$70,000 for B and
$50,000 for C.
From the perspective of reducing risk of system capture, it is ideal that there be more price feeds allocations, and that they be easily changed in case of bad behavior by price feeds. On the other hand however, an excessive number of allocations will cause excessive gas cost and cognitive overhead for the loan takers and other stakeholders. An average of 3 allocations seems like a good target, thus a max value of 5 is reasonable. See maximum price feed allocation.
Price feed allocation process is added as a separate call to the loan contract despite adding and extra step in some cases (eg. single allocation creation), and the call’s additional complexity, due to the following reasons:
Liquidation can be proposed by any blockchain user, who agrees to put up a deposit, and request for a specific debt liquidation position to be triggered. However the final liquidation decision would be accepted only if the specific monetary conditions of the position merit it and after the delayed dispute process also issues the validity of that request.
Liquidation trigger decision - A 100% allocation to one price feed will mean that liquidation decision will be solely made based on the price feed, and contents of the position itself. A combination of say 3 price feeds with 33.3% each will mean that liquidation condition will trigger only if all 3 price feeds are in approximate agreement, otherwise the position will have to go through the dispute resolution process.
The main responsibility of price feed providers is the truthful daily providing of historical prices to the contracts, consisting of 2 exchange rates, one for the native token in reference currency, and the other in its pegged version. These rates are expected to be the median rates based on volume. The system enforces having historical prices available within 1 day (See maximum price feed delay) enforced by an imposed penalty to the provider’s revenue pool.
For example, in our MVP implementation, this consists of ETH value in USD as well as in pegged USD as reported accurately from exchange market activity. If there was
10,000 ETH traded for USD during the day, and
50% of volume was under
$201.2 USD and the other
50% was over
$201.2 should be reported as the ETH/USD price. Similarly, let’s assume the Pegged USD was traded against ETH, with its median valued at
$0.9805 that day. The price provider would report the following and results:
Price feed values are results of formulas calculated from known market exchange prices and volumes. The ideal case is for all providers to have full access to the universe of all legitimate trades along with their volume and price, and good faith providers should strive to do so. However, due to many restraining factors, including uncertainty around authenticity of info from some sources or exchanges, as well as pure technical limitations, each provider will choose a specific set of samples they can depend on, at any given time. They should publish their methodology for compiling these historical prices, so the community can verify them in favor of higher level of trust and predictability for the ecosystem, as public good.
High trust providers are also expected to report something called instant price almost immediately, as they notice changes of over
1%. This reporting by highly trusted providers, would be strongly encouraged by the ecosystem members (community) however there is no hard penalty imposed by the system itself.
Loan fees - Each price feed has a corresponding global revenue pool that increases in value as a result of an incoming portion of loan fees. See loan fees and price feed revenue rate under monetary variables for more details.
Dispute resolution credibility - The total size of the price feed liquidity pool affects their level of credibility during dispute resolution phase.
Dispute penalties (slashing) - During the dispute process, any penalties issued to the price feed provider will come out of their liquidity pool. This is to incentivize the provider into constructive behavior.
Delayed/gradual/partial payouts - Price feed providers need to have a sustainable business model and so they are expected to have an income from the loan fees. This income takes the form of a delayed and gradual payout from the price feed liquidity pool belonging to the feed provider. The payout is long term delayed in order to incentivize the price feed provider to maintain a constructive long term engagement with the platform. The payout is partial because there needs to be a significant liquidity pool to use in case of dispute penalties.
The level of delay and resolution offered by a price feed provider will depend on a few important considerations amongst others, and we trust the providers to consistently reach an equilibrium based on these factors:
1 daydelay and
1 hourresolution, at another extreme, the market may demand instantaneous recording of prices on the blockchain, to enable almost instantaneous loan confirmation.
1 hour, minimizing storage cost. At another extreme, the provider may choose to provide up to the block price records despite significant storage cost.
Locking an amount of pegged currency in the savings contract, will allow for a collection of interest based on the variable daily savings rate (See savings interest rate under monetary variables), for the duration time of that locking. An call to withdraw the accumulated interest, calculates the to-date savings interest rate, savings interest amount and sets a timestamp for future interest withdrawal calls. An owner call to close the savings account, should be performed after withdrawing all applicable interest to that date.
Loan fees are also varied based on the global equilibrium price of the pegged currency, in order to incentivize increase or decrease the pegged currency supply based on changing the demand for pegged currency by consumers and thus affecting the equilibrium price. See savings interest rate under monetary variables.
Savings pool is a portion of pegged currency tokens held by the main system contracts, set to be payed out to money owners as interest, when they lock their tokens in a savings account contract for periods of time. A portion of the fee paid by loan takers is always transferred to this pool. Also, any penalties imposed on price feed are taken out of the offending provider’s revenue pool and transferred into the savings pool. Payout is based on the savings interest rate (see savings rate and variable definition under monetary variables).
Main system contracts hold the following variables related to the areas of the system like Savings, Loans, and Price Feeds:
The system will have multiple states of operation:
10%drops 3. Volatility of reported prices exceeding
20% weeklydespite lack of dispute.
2 daysand will be according to minimum of historical native token prices
2 weeksand will be evaluated against the maximum of historical native token prices
1 weekand will be according to minimum of historical native token prices
5 weeksand will be according to maximum of historical native token prices
The main goal of the automated monetary system is to balance supply of pegged currency with its demand, and maintain a price pegged to the reference currency, as reported by the price feed providers as historical prices. The main variables that the monetary system can affect are the following:
Loan fee rate - Is a daily rate set by the automated monetary system that determines the fee paid by loan takers upon structural changes made to their loan, such as allocation or issuance changes. For example, at a given point in time, the loan fee rate could be
0.01096% per day (equivalent to
4% per year). Assuming no future change to the rate (which is unlikely), the loan taker should project to pay
$400 per year in fees on a loan that has issued
$10,000 worth of pegged currency, upon closing the loan. The actual annual rate will be calculated by adding all the variable daily rates.
The monetary policy engine aims to vary the rates based on the global equilibrium price of the pegged currency, in order to incentivize increase or decrease the pegged currency supply based on the creation or cloning of debt positions, and thus affect the equilibrium price of the pegged currency itself from the supply side.
Price feed revenue rate - Is a weekly rate set by the automated monetary system that determines what percentage of total system issuance is expected to eventually be paid out to price feed providers. The revenue comes from part of the loan fee stream and so the price feed revenue daily rate has to always be lower than the loan fee daily rate. The rest of the loan fees will go into the savings pool to be paid out to savings account owners. For example, at a given point in time, the price feed revenue rate could be
0.01917% per week (equivalent to
1% per year). Assuming no future change to the rate (which is unlikely), a price feed provider can project its revenue pool to receive
$20,000 yearly assuming a total issuance allocation of
$2,000,000. This could be the case if total system issuance is
$10,000,000 and the providers average weighted allocation percentage is
Savings interest rate - Is a daily rate set by the automated monetary system that determines the interest paid to owners of savings accounts. For example, at a given point in time, the savings interest rate can be
0.01096% per day (equivalent to
4% per year). Assuming no future change to the rate (which is unlikely), the savings account owner can project an interest of
$400 per year on a savings account balance of
Loan collateral threshold ration -
In an ideal loan (debt position) system, one would expect perfect trust of the price feeds, very fine grained price feed resolution, and instantaneous response to loan taking requests or liquidation requests in appropriate conditions. However, given the constraints of highly decentralized protocols on public blockchain systems, as well as the urgent need for simplification, in order to reduce risks and increase efficiency, we choose to bend the ideal rules as long as these changes are communicated clearly to and are accepted by stakeholders, and as long as they result in a secure system overall.
Normally the loan taking process should be expected to complete in one transaction, however during times of dispute between the rates provided by the system’s price feed providers, it is reasonable to delay the loan taking process by a few days. Normal operation should be resumed on all other occasions.
The most acceptable cases of liquidation from the perspective of a loan taker is when there is a significant and non-intermittent drop in the value of the collateral, and they’ve had enough time to respond to it. We can adjust the definition of acceptable liquidation to such cases, and ask the loan liquidators to take on the additional risk of having to predict if the drop is non-intermittent. We would however need to compensate the liquidator for the additional risk they are taking. It is thus become acceptable to condition liquidation upon the drop being persistent over the course of a few days and expect the loan liquidator to make a judgement on the likelihood of this persistence, and take a profit or loss accordingly.
One of the key insights that helps with efficiency and simplicity of this on-chain loan system is that using a collateral in smart contract to peg relatively stable currencies, does not require a high level of time sensitivity, in the following ways:
All percent-based (%) penalties are enforced with respect to the corresponding provider’s price feed revenue pool. The penalized value os transferred to the savings pool.
100% * total value of all voting savings accounts / total value of all savings accounts
Asset - Any valuable object. It may not necessarily be used as money for exchange of value.
Money - A tool used by humans to exchange value. Any valuable object (such as a coffee mug) can theoretically be used as money, perhaps on rare occasions. However a good money candidate, can be used in more contexts.
Gold, Bitcoin (BTC) and Ether (ETH) are all examples of asset moneys, that can be used for exchange on occasion, but are not necessarily the best option when we have access to more widely accepted alternatives like USD.
Currency - A type of money that is commonly used in day to day commerce, as it is used and accepted by many buyers and merchants. Good currencies are stable in value and are therefore good Stores of Value (SoV). Good currencies also are used as Units of Account (UoA) by more people, and are accepted by more people as Medium of Exchange (MoE). US Dollars ($) is the example of a good currency money, so are Chinese Yuan, Japanese Yen, and Euro.
Token - The digital representation of value on a public blockchain. They can be the digital representation of a real world asset, or they can have inherent digital value like in the case of Bitcoin, Ether and others.
Medium trust price feed - Price feeds either in the top
25 in weighted allocation, or allocated at least
4% of all loans’ weighted value. The historical prices from all these feeds are used in weighted form to determine the median daily historical price.
High trust price feed - A select group of price feeds either in the top
5 in weighted allocation, or allocated at least
20% of all loans’ weighted value. Through social contract, High trust feeds will be, expected to report price changes of more than
5%, on the blockchain within
60 seconds. All high trust feeds are also considered part of the medium trust collection.
Low trust price feed - Simply any non-zero allocated feed that is not medium trust. Any price feed that is allocated a non-zero % of a loan with non-zero native token deposits, which is not a medium trust feed.
In software engineering, magic values refer to constant values selected by the software author, that determine the constraints that the system operates under. The selection of these values often involves significant deliberation and requires a level of justification. It is always a good question to ask: Why was that specific “magic value” selected, instead of higher or lower values?
Maximum price feed delay -
1 day -
Maximum price feed allocations -
High trust price feed count -
5 - Every feed with at least
20% is included.
Medium trust price feed count -
25 - Every feed with at least
4% is included.
Performing liquidations asynchronously and through and request initialization and finalization process, and providing aan initial grace window of a few blocks, ensures that no one can front-run another request and prevent them from participating also. At worst case, the two almost-simultaneous requests will share in the proceeds.
Also anonymizing liquidation requests, ensures that no front-runners can highjack the reputation of another liquidator, and requires them to also have their own logic for evaluating the liquidation conditions, at which point it no longer is much of a front running attempt anyways.
Historically, stable currencies have not shown a high level of short term volatility, where for example the price goes down 20% one day and goes back up a few minutes or hours. As such transaction delays have a much smaller chance of triggering costs to a stakeholder. There is often however clear longer term trends that can be observed with stable currency, at different points in time.
However one always needs to be prepared for short term volatility of the native value token due to unknown knowns such as general boom and bust cycles (or events), as well as unknown unknowns we can’t even imagine. Although not likely to occur in case of a mature blockchain, it is entirely reasonable to consider an hour long drop in the order of 50%, or a sudden rise in the order of 400%, as a possibilities, and prepare for them.
Since Ether (ETH) is the other side of the first viable product based on our proposed financial instrument, its volatility also affects our considerations. ETH in the recent years, due to its increasing uses as gas, speculative investment, and collateral, has been relatively more stable as compared to years before. Also due to its future staking use in Ethereum 2.0, we expect its long term volatility to decrease in general. However, it remains primarily a speculative asset subject to significant volatility.
The ultimate goal of such a decentralized smart contract system is to be ownerless and live forever. That is, if the current open source implementation were the solution to our original stable-coin problem, there should be no subsequent version needed.
However, due to possibilities of future upgrades to the underlying blockchain itself, as well as due to the remote possibility that the system may, at some point, operate in some unexpected ways, we are required to at least consider the possibility of winding down this version in favor of a next one.
We are currently witnessing this type of transition with the SAI to DAI migration by Maker. There are a few lessons to be learned from this experience, in the remote case migration is needed.
One of the price feeds to the system on Ethereum can be constructed as a decentralized contract, based on market pricing information provided by the UniSwap V2 decentralized exchange. This ownerless, decentralized price feed would then automatically transfer any of its revenue payouts back into the loan system as part of the savings pool.