All major L1 (and even most L2) blockchains have stable coins that are key to the success and scalability of the protocol. However, stable coins are a complex beast on their own: smart contracts need to properly deal with market volatility and the many possible ways attackers might exploit its pegging to the dollar to liquidate positions that rely on its stable value.
So, I wanted to kickoff this thread to discuss implementation ideas of stable coins with our community.
2 Likes
My proposal is to create a stable coin that is regulated through a feedback loop using a PID controller.
A PID controller is an instrument used in industrial control applications to regulate temperature, flow, pressure, speed and other process variables. PID (proportional integral derivative) controllers use a control loop feedback mechanism to control process variables and are the most accurate and stable controller.
PID control is a well-established way of driving a system towards a target position or level. It’s a practically ubiquitous as a means of controlling temperature and finds application in myriad chemical and scientific processes as well as automation. PID control uses closed-loop control feedback to keep the actual output from a process as close to the target or setpoint output as possible.
They are a simple, efficient, and effective way to exert control over a real life system.
The overall control function 
The PID controller could then control a function that issues more stables (when the price goes below the 1 USD peg) or which remove stables from circulation (or issues bounds at a discount) when price trades below the peg. We can control how sensitive the system is to the environment and how quickly the controller will correct/re-adjust its value by tuning the PID gains explained above.
PIDs work very well in real life scenarios, but they do not guarantee optimal control of the system or its control stability. The controller might exhibit excessive delays at times, but there are some work arounds to this problem, such as lead–lag compensation.
I think this would be a very interesting experiment that could introduce an already well known tool to deal with market volatility.
2 Likes
You seem like a polymath Joe! Interesting approach. from the PID equations, am I understanding right that it works best when u and e are in close regions? i.e. you need an USD input as e to achieve a stable coin USDx output u, or can you use Mina price as the input as well, in the similar fashion to LUNA-UST? Of course these two are very different approaches: the former pegged, while the latter algrithmic.
Either way, I’d be interested in the algorithm development, and happy to contribute if I can.
1 Like
Basically, the controller captures the history of the system (through I) and anticipates the future behavior of the system (through D). The system works by calculating the tracking error, the difference between the desired output (which is our 1 USD peg) and the actual output. Next, the error signal is fed to the PID controller, which computes both the derivative and the integral of this error signal with respect to time. Then, based on the error, the controller actuates by creating or destroying stables and the cycle repeats all over again. My biggest concern here is that the controller would need to be constantly running, but I believe all stable coins have something running 24/7 to control their peg.
This article explains the function of each gain very well:
P: Increasing the proportional gain ($K_p$) has the effect of proportionally increasing the control signal for the same level of error. The fact that the controller will “push” harder for a given level of error tends to cause the closed-loop system to react more quickly, but also to overshoot more. Another effect of increasing $K_p$) is that it tends to reduce, but not eliminate, the steady-state error.
D: The addition of a derivative term to the controller ($K_d$) adds the ability of the controller to “anticipate” error. With simple proportional control, if $K_p$ is fixed, the only way that the control will increase is if the error increases. With derivative control, the control signal can become large if the error begins sloping upward, even while the magnitude of the error is still relatively small. This anticipation tends to add damping to the system, thereby decreasing overshoot. The addition of a derivative term, however, has no effect on the steady-state error.
I: The addition of an integral term to the controller $K_i$ tends to help reduce steady-state error. If there is a persistent, steady error, the integrator builds and builds, thereby increasing the control signal and driving the error down. A drawback of the integral term, however, is that it can make the system more sluggish (and oscillatory) since when the error signal changes sign, it may take a while for the integrator to “unwind.”
The goal is to find a good set of values for PID that will be able to work well with any market conditions.
PS: Sorry for the crazy math formatting, I think we haven’t turned math symbols compatibility in here yet, so those aren’t really getting rendered the way I intended 
2 Likes
Thank you very much for the detailed explanations. No worries re the maths formatting - I work with LaTex so this is no issue.
I agree with you, this definitely seems a robust framework to work on. I think the potential things to think about are: 1). if you’re thinking about the pegged stable coins, the issuers more or less have a system to stablise them, and they probably won’t be too interested in this; 2). if algorithmic, then there is no point to deposit another stable coin to issue this one, you’d have to deposit Mina and work in similar fashion as DAI or UST. Then the challenge is to maintain the peg with volatility and the deposited assets having vastly different value from $1.
The plus sides are: 1). the added smoothing from the integral and derivative parts could be life saver in preventing overshooting and cascaded liquidation in the event of high volatility in market; and 2). Mina has potentially the best price oracle solutions upcoming. 
The solution could be purely algorithmic or a mix, like FRAX.
In a similar fashion to FRAX, I imagine the PID controller could then be in charge of the collateral rate to stabilize the price.
The protocol adjusts the collateral ratio during times of FRAX expansion and retraction. During times of expansion, the protocol decollateralizes (lowers the ratio) the system so that less collateral and more FXS must be deposited to mint FRAX. This lowers the amount of collateral backing all FRAX. During times of retraction, the protocol recollateralizes (increases the ratio). This increases the ratio of collateral in the system as a proportion of FRAX supply, increasing market confidence in FRAX as its backing increases.
If the market price of FRAX is below the price range of $1, then there is an arbitrage opportunity to redeem FRAX tokens by purchasing cheaply on the open market and redeeming FRAX for $1 of value from the system. At all times, a user is able to redeem FRAX for $1 worth of value from the system. The difference is simply what proportion of the collateral and FXS is returned to the redeemer. When FRAX is in the 100% collateral phase, 100% of the value returned from redeeming FRAX is collateral. As the protocol moves into the fractional phase, part of the value that leaves the system during redemption becomes FXS (which is minted to give to the redeeming user). For example, in a 98% collateral ratio, every FRAX can be redeemed for $.98 of collateral and $.02 of minted FXS. In a 97% collateral ratio, every FRAX can be redeemed for $.97 of collateral and $.03 of minted FXS.
1 Like
I believe this is something to be considered after snapps but also I favour collateralized stable coins for compensating volatility over the approaches that try to keep the system float automatically by their token structure.
2 Likes
I support this kind of privacy stable coin voting. For the ecological form of POS mechanism, it can effectively curb inflation. POS generates a mina, issues a privacy stable coin correspondingly, and destroys a mina token, which is perfect
2 Likes
I believe this idea should be scrapped after we have all witnessed the results of the UST failure. It has not only forever tarnished the terra ecosystem but has also caused increased federal government intervention and regulation. Not only could a depeg and subsequent crash tarnish Mina protocols reputation and permanently harm the token price it could also cause legal issues in the future as stablecoin legislation is passed. MINA is known for its industry leading ZKproof technology and given recent events I believe we should all stray away from anything that can possibly cause the ecosystems and projects reputation to be harmed.
I believe a better proposal is for MINA as an ecosystem to adopt the trialed and proven stablecoin FRAX. It did not get depegged during the UST fiasco and they will soon be moving to a 100% collateral of USDC meaning it can never be depegged while maintaining all the privacy benefits of a DEFI stablecoin. FRAX is also mathematically impossible to depeg due to the amount of protocol owned liquidity. There simply isn’t enough Frax on the open market to purchase to cause a bank run due to a liquidity crisis. Even if all the math on our end of a MINA stablecoin algorithm was perfect, the peg would still be at risk due to a wealthy malicious actor buying it on the open market and causing an intentional depeg due to liquidity issues like with what happened to UST and CONVEX. Because so many projects, protocols, and blockchains use FRAX even if anything did hypothetically happen to the FRAX peg it wouldn’t negatively effect MINAs price on the open market as it is an entirely different project separate from MINA.
An issue with forming stablecoin forks like Joseandro mentioned is they’re never as secure as the original. See Iron Finance and as of yesterday (5/16/2022) the FTM ecosystems stablecoin DEI which has now suffered a collapse
The risk of making our own stablecoin isn’t worth it when considering the astronomical risk it brings on the ecosystem.
Creating our own stablecoin would also take away time from the developers that could be spent on industry innovative things like ZKapp/ZKoracle improvement.