code423n4 commented 1 year ago

Lines of code

https://github.com/code-423n4/2023-04-frankencoin/blob/1022cb106919fba963a89205d3b90bf62543f68f/contracts/MintingHub.sol#L140

Vulnerability details

Impact

Because challengers are required to submit collateral equal to the amount they are challenging, extremely large positions will be the slowest to be challenged and liquidated. This creates the probability that the system will become insolvent (at least temporarily). But stablecoin holders are not as forgiving to temporary insolvency as customers of fractional reserve banks: ZCHF does not need a bank run to destroy its value. All it needs is the insolvency narrative to precipitate immense sell-pressure.

While this could happen at any time, consider how greatly this risk increases in times of market stress. If the majority of collateral tokens are tightly correlated crypto assets and everything is crashing at once, there will be a flood of Positions dipping below their liquidation prices--precisely at the time when Frankencoin users are least likely and least able to raise huge amounts of collateral to challenge these unsafe Positions. ZCHF holders would be justified in looking at this series of events and concluding that ZCHF is rapidly becoming worthless.

This is exactly the type of scenario that warrants the use of an emergency shutdown mechanism. Without one, the above leads to ZCHF holders panic-selling at an ever greater discount (since the Bridge contract can only handle a percentage of the total ZCHF supply). The Frankencoin system would have no way to prevent a ZCHF death spiral.

Proof of Concept

One need only look to the recent crisis with USDC for a case study in how such events could unfold. The status of USDC's at-risk collateral (its $3.3b at SVB) was quite comparable to collateral trapped in unchallengeable positions: it did not disappear, and some unknown amount of it was likely to be recoverable, but its inaccessibility was enough to break the peg.

It might be tempting to look at this and say, "well, USDC turned out fine." But that's because, in the end, the $3.3b became accessible again after just a couple of days. USDC holders knew by the next day that they would be able to redeem USDC directly for USD once the weekend ended, so it made no sense for a rational USDC holder to continue selling for less than the peg in the meantime. Frankencoin can offer no such guarantee to users.

So consider how this situation would have played out with ZCHF. Its price would have continued to spiral downward as more Positions became unsafe and the Bridge became unusable. Eventually, the owners of these large Positions would probably take advantage of the extreme discount to withdraw their collateral and close their Positions. This might rebalance the system after some time, but there would never be a moment when users regained their faith in the system: instead, it would be clear that ZCHF is just as exposed to the volatility of crypto markets as its underlying collateral, which totally invalidates the utility of ZCHF--especially since many of its holders would have just eaten the losses of the Position owners by fleeing ZCHF for safer alternatives.

This is because a stablecoin is only as reliable as its liquidation mechanism, and the Frankencoin liquidation mechanism fails under volatile market conditions.

Tools Used

N/A

Recommended Mitigation Steps

In lieu of redesigning the challenge and auction mechanisms from the ground up--which is not entirely unwarranted, given both this vulnerability and the auction one specified in a separate finding--it would likely be good enough to design two additional modules for the Frankencoin system: a faster liquidation mechanism that could be toggled on by governance in times of high market stress (perhaps only on individual Positions, as needed), and an emergency shutdown that allows for direct collateral redemption with ZCHF.

Unfortunately, the faster liquidation mechanism would likely necessitate the use of an oracle, but if it's only used for times of extremely high market stress and stale, unchallengeable Positions, Frankencoin would still represent a dramatic decrease in oracle dependence compared with most other stablecoins and lending protocols.

The emergency shutdown module need not reinvent the wheel, and Frankencoin can look to the modules designed by MakerDAO and others to get an idea of how it could work.

These two modules would work together to address this vulnerability: the faster liquidations could defend against a wave of new unsafe Positions and prevent ZCHF from appearing to be indefinitely insolvent, and the emergency shutdown--even if it's never used--will assure holders that ZCHF cannot death spiral all the way to zero. This is similar to Circle's direct USD redemption, and simply communicating when it was set to resume was enough to stop the collapse of USDC's price. Consider as well that such a shutdown mechanism will be useful in the event of future contract upgrades.

c4-pre-sort commented 1 year ago

0xA5DF marked the issue as primary issue

0xA5DF commented 1 year ago

594 suggests an emergency pause mechanism too, due to stablecoin bridge risks

Severity is somewhat between med and QA imo

luziusmeisser commented 1 year ago

This report rests on the following false assumption:

Because challengers are required to submit collateral equal to the amount they are challenging, extremely large positions will be the slowest to be challenged and liquidated.

This is not true. It is possible to challenge a position partially. For example, if there is a billion dollar position, it is possible to only challenge 1000 dollar worth of the position.

The other criticism, namely that there is a risk of all collaterals being correlated in price and therefore dropping below the critical level at the same time, is valid. But this rests in the hands of the pool share holders who can deny positions. And here, I would argue that the system is not very permissive, as already having 3% of the votes suffices to veto any new collateral. If anything, the system might be too conservative.

c4-sponsor commented 1 year ago

luziusmeisser marked the issue as sponsor disputed

c4-judge commented 1 year ago

hansfriese changed the severity to QA (Quality Assurance)