# **Minimalistic yet flexible Stablecoin**

**--Three main principles of prototype development--**

*Paranoic*, *Independent*, *Mathematic*

*Paranoic* : Decision-making and system design WILL be done in a paranoic and over-thinking manner. "In Crypto, the sky is always falling"

*Independent* : The protocol SHALL AVOID using external libraries. The risk is minimized by not relying on external tools. "Home made kimchi is better than Carrefoure kimchi"

*Mathematic* : Decisions on parameters that affect the protocol's economy MUST be made based on exploratory data analysis based.

**--Two versions of the Prototype--**

This documentation covers the 1st version of stablecoin prototypes

"**Simple(but not easy)**" version - 3 months development - : Based on system design as described below in the draw.io file, the prototype is will be built.

"**DAC is my father**" version - 0.5 months development - : Once the Simple version is developed, we try to import all modules as items of DAC. It is a great chance to experiment with DAC's flexibility which is beneficial for new DeFi protocols.

# --Blueprint--


# --Modules--

All modules(except admin modules) must be stoppable and protected from reentrancy attacks.

All modules should be upgradeable.

All modifiers will be implemented after all modules are coded. ERC20 token manipulations are encouraged to be done via the SafeToken library.

**Explanation about the modules are as follows**

# Admin_Module/Module#1


*3 smart contracts*

-RolesConfig.sol
-CollateralPoolConfig.sol
-ShowStopper.sol

*RolesConfig.sol* saves roles of the protocol as message digests of strings. Each smart contract has its roles and their roles are saved in 11 storage slots. Storage slots are not updated later. In the DAC version, functionalities of this smart contract can be replaced with rules engine permission.

*CollateralPoolConfig.sol* sets up parameters for collateral assets. It uses two structs to store info about a particular collateral asset. When adding new collateral, a new key is added to the mapping below

mapping(bytes32 => ICollateralPoolConfig.CollateralPool) private _collateralPools;

Collateral Assets will be tokens that follow ERC20 (Wrapped, Liquidity tokens, etc) standard.

*ShowStopper.sol* has functions that are directly related to the emergency shutdown of the protocol. Functions in this smart contract **MUST BE PROTECTED**.

# Book Keeper/Module#2 #


-BookKeeper.sol

*BookKeeper.sol* keeps track of CDPs and manipulates them. It can be considered the main ledger which keeps track of money in the system. It is **the most important smart contract** of the protocol, therefore, the contract **must be implemented first** to write other contracts. Storages related to CDPs are constantly updated. This contract is related to the 'stabilization mechanism' of CDP stablecoin. A stablecoin can remain stable only if people know and strongly believe that per each stablecoin, there is more backing from other more stable crypto assets worth more than the issued debt. CDP stablecoin protocol is a credit expansion machine. BookKeeper.sol keeps track of the credit expansion's sanity level.

# Arb Module/Module#3


-StableSwapModule.sol

*StableSwapModule.sol* allows USF and some other stablecoins to be swapped at a 1:1 ratio. It provides the **pegging mechanism**. A pegging mechanism is needed to keep USF price near $1. It is costly since the pegging mechanism is based on providing arbitrage opportunities with the protocol's funds. When the price of USF < $1, arbitrageurs buy USF from the secondary market and sells USF in the StableSwapModule (Positive price pressure). When the price of USF > $1, arbitrageurs buy USF from StableSwapModule and sell USF in the secondary market (Negative price pressure). Such a mechanism is seen in MakerDAO. It is important to remember that StableSwapModule is related to the 'pegging mechanism' not the 'stabilization mechanism' of the stablecoin. The stabilization mechanism is rather related to CDPs remaining safe LTV ratio. There is little or no need to provide arb bots since the market participants will do their best to react to arb opportunities to pick up the easy money.

Some may argue that it is possible to peg USF to $1 by controlling interest rate, and LTV ratio for CDPs. I argue that such an approach is doable but should never be the main manipulator for the pegging mechanism. Moreover, attempts to peg stablecoin by controlling the supply through direct minting **MUST NEVER HAPPEN.**

First, it is the demand-side influence that pegs a stablecoin to $1, not the supply-side influence. The reason that stablecoin stays pegged by demand is that it **stablecoin protocol *DOES NOT & CAN NOT* print tokens out of thin air like the FED. Stablecoins are minted/supplied only when assets are collateralized**.

Second, the supply-focused way of price pegging causes an ideological paradox since it is the approach of Central Banks that controls exchange rates with money supplies. The moment a stablecoin works like Central Banks, it is no longer a DeFi product.

For more information about the pegging of stablecoin by demand-driven influence, please refer read the article below.

https://www.jbs.cam.ac.uk/wp-content/uploads/2020/08/2020-conference-paper-lyons-viswanath-natraj.pdf

# Price Module/Module#4


-PriceOracle.sol

The price module provides price information on collateral assets. For this prototype, oracle services are likely to be used. In the future, off-chain price feed may also be considered. *PriceOracle.sol* should provide price feed with x minutes of delay. The delay is to protect the protocol from price feed manipulation.

The delay is 15 min in Alpaca and 1 hour in MakerDAO.

Alpaca 15 min delay:

https://docs.alpacafinance.org/ausd/ausd-liquidation#time-delay

MakerDAO 1 hour delay:

https://docs.makerdao.com/smart-contract-modules/oracle-module#relationship-between-the-osm-and-the-median

The delay should be changeable by the owner|governance addresses of the protocol. There was no reasoning found for the length of delay in Alpaca and MakerDAO. Length of delay will be the topic of further discussion.

# CDP Module/Module#5


Users do not directly speak to Bookkeeper.sol and rather go through PositionManager.sol.

-FathomStablecoinProxyActions.sol
-PositionManager.sol
-ERC20CollateralAdapter.sol

*FathomStablecoinProxyActions.sol* is the entry point for clients to manage their positions(CDPs).

*PositionManager.sol* is the proxy for PositionManager to talk to *BookKeeper.sol*. Alpaca USD is using this strictly as a library. More research is required to understand the risk of setting storage and direct calls to this contract.

*ERC20CollateralAdapter.sol* This smart contract integrates ERC20 into the protocol. For this contract to work well, this contract needs to have allowances(approved amount from the collateral assets' owners).

# Liquidation Module/Module#6


-LiquidationEngine.sol
-FixedSpreadLiquidationStrategy.sol
-Liquidator Bot

*LiquidationEngine.sol* is the router to *FixedSpreadLiquidationsStrategy.sol*

*FixedSpreadLiquidationsStrategy.sol* is the smart contract which speaks to *BookKeeper.sol* in times of liquidation.

Liquidator Bot: We provide a template liquidator bot so that liquidators, who are external participants of our protocol, can get involved with a lower hurdle.

The function liquidate() from *LiquidationEngine.sol* checks if the targeted CDP is truly in a bad state. If it is then it calls the execute() function in *FixedSpreadLiquidationsStrategy.sol*.

The maximum amount of collateral that could be liquidated in a CDP does not necessarily have to be 100%. Alpaca is currently using 25%. The ratio is also a topic for future discussion.

# Debt Module/Module#7


-SystemDebtEngine.sol

*SystemDebtEngine.sol* deals with the surplus and debt of the system. It manipulates CDPs in *BookKeeper.sol*

It is crucial to managing the level of debt in the CDP-based stablecoin protocol. The Loan to Value ratio (LTV) of the system must always stay at a sane level. It can be ensured only when each CDP in the system keeps a safe level of Loan to Value ratio.

# Stability Fee Module/Module#8


-StabilityFeeCollector.sol

*StabilityFeeCollector.sol* sets parameters for global stability fee (which is like the base rate of central banks).

Stability fee = base fee + collateral specific fee.

The base fee is applied to all collateral assets and the collateral specific fee is applied to a specific collateral asset. The collateral-specific fee is similar to the default rate in traditional finance. (What is the default rate? Corporate bonds will generally have a higher interest rate than T-bond and the spread between the T-bond's risk-free rate and the cortporate bonds rate, is the default rate. Lenders get more interest revenue from risky assets. Companies that are generally riskier than the government pay a higher interest rate to borrow money). Higher return (or interest rate) on a financial instrument implies there is a higher chance of default. In summary, *StabilityFeeCollector.sol* collects the fee from the system.

The stability fee of each collateral asset will differ since each asset has its level of price volatility. There is a consensus that BTC is safer than $OHM or $SexyDogeApe tokens. The level of the collateral-specific fee must be decided by the governance.

# Stablecoin Module/Module#9


-USFStablecoin.sol.sol
-StablecoinAdapter.sol

*USFStablecoin.sol* is a Mintable/Burnable ERC20.

*StablecoinAdapter.sol* is the only smart contract that can Mint/Burn USF stablecoin based on deposit() or withdraw(). deposit() and withdraw() functions are part of the opening and closing procedures of CDPs.

**It is extremely important that the Mint/Burn functions of the token are protected** so that there would not be supply manipulation from actors with bad intentions.

# ProxyWallet Module/Module#10

ProxyWalletFactory.sol
ProxyWalletRegistry.sol
ProxyWallet.sol

Creation process

https://github.com/alpaca-finance/alpaca-stablecoin/blob/main/test/helper/proxy.ts

Also refer

https://github.com/alpaca-finance/alpaca-stablecoin/blob/main/test/integrations/stablecoin-core/LiquidationEngine.test.ts

# --Costs--

**Liquidity pool on DEX pool**

e.g. USF/DAI

at least in millions of $.

AUSD has a $4 mil liquidity pool.

**StableSwapModule pool USF/DAI**

at least in millions of $.

$1 mil DAI and $1 mil USF

It means that the team needs to collateralize assets in the beginning to provide USF liquidity.

# --Risks--

The pegging mechanism weakens when StableSwapModule's balance goes to zero. It is the current state of Alpaca USD. Alpaca USD, unfortunately, is staying pegged at the moment due to its small activity. Alpaca's StableSwapModule balance is 0.

Illiquid collateral assets may harm the balance sheet and undermine stability.

<!-- **Slow liquidation of institutional assets:**
When the liquidation of institutional assets is delayed, the system may have more debt than backing with collateral assets. It is a question of whether forcing the liquidation of institutional assets (off-chain) is at all quick enough. In the case of cash equivalents (MMFs), Euro bonds, or T-bond, the liquidation process may be quick enough. However, if the collateral assets are real estate, the liquidation process would be too slow. -->

# --Opportunities--

Stablecoin as a haven

Once our protocol is perceived as stable enough, we may be able to have a position as a haven. Position as a haven is beneficial since it may reduce redemption risk (when debtors just close all CDPs, thus, dismantling the foundation of a CDP-based protocol).


Image from the article 'Stablecoins: Growth Potential and Impact on Banking by Gorden Y. Liao and John Caramichael' https://www.federalreserve.gov/econres/ifdp/stablecoins-growth-potential-and-impact-on-banking.htm

# --The last resort price defense mechanism--

A possible defense mechanism from de-pegging is selling off governance tokens to buy back stablecoin. Fully algorithmic stablecoins use this scheme to protect their token price. Since our stablecoin protocol would have StableSwapModule which would provide an arb opportunity, selling off of governance tokens for token price defense can be used as 'a last resort'. We mustn't officially implement any of these mechanisms on smart contracts and keep this last resort in secret. We broaden our scope to be attacked if we implement this in our smart contracts and announce that governance tokens would be sold off in case of emergency.

# --Credit expansion machine--

It is important to note that the stablecoin (a.k.a programmable money) protocol can be viewed as a credit expansion machine. CDP stablecoin protocol contributes to the positive price pressure of collateral assets. One can pull leverage by collateralizing collateral assets to receive stablecoin and buy more collateral assets in the secondary market. Circulating supply of the collateralized asset is reduced, creating a possitive price preasure.

(
((( ((( # #(
(((( ((((( ((((((
(((( ((((( (((((
#((((((((((((((
(((((,,,,,,,,,
**,,,,,,,,,,,,,,,
***,,,,,,,,,,,,,,,,,
****,,,,,,,,,,,,,,,,,
****,,,,,,,,,,,,,$$,,
****$$ ,,,,,,,,,,,$,,
****,,,,,,,,,,,,,,,,,
****,,,,,,#(((,,.....
****,,,,,,,,,,,,,,,,
****,,,,,,,,,,,,,,,,
*****,,,,,,,,,,,,,,, ,,,
,,,,,,,,,,,,,,,,,,,,,,
*****,,,,,,,,,,,,,
****,,,,,,,,,,,,,
****,,,,,,,,,,,, Document edited '22 Jul 22 Fri