Frankencoin - 3th's results

A decentralized and fully collateralized stablecoin.

General Information

Platform: Code4rena

Start Date: 12/04/2023

Pot Size: $60,500 USDC

Total HM: 21

Participants: 199

Period: 7 days

Judge: hansfriese

Total Solo HM: 5

Id: 231

League: ETH

Frankencoin

Findings Distribution

Researcher Performance

Rank: 7/199

Findings: 2

Award: $2,047.21

🌟 Selected for report: 1

πŸš€ Solo Findings: 1

Findings Information

🌟 Selected for report: 3th

Labels

bug
2 (Med Risk)
disagree with severity
downgraded by judge
primary issue
selected for report
edited-by-warden
M-12

Awards

2024.6136 USDC - $2,024.61

External Links

Lines of code

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

Vulnerability details

Impact

Under certain extreme, but inevitable, network conditions, auctions will not be effective in covering the bad debt of a challenged position. Worse, certain position parameters under these conditions can lead to extremely small bids winning large amounts of collateral. More details follow in the next section, but it should be noted that this same design oversight was responsible for almost destroying Dai in March of 2020--the closest MakerDAO has ever been to utilizing its emergency shutdown module.

Proof of Concept

When the Ethereum network becomes highly congested, the price of gas can skyrocket to incredible levels. During times like these, users of the network will limit their activity to only the most urgent matters--in the case of March 12th, 2020, for example, the only people paying the exorbitant network fees were rushing to exit their positions as the price of ETH (and everything else) began to free fall.

On that day, MakerDAO's collateral auctions were slipping by unnoticed, as the bots that would typically compete in the majority of these auctions saw failing transactions, hit cost limits defined by their owners, or were simply deactivated. An attacker noticed them, however, and began winning auctions on liquidated collateral with bids of zero ETH.

This exact vulnerability exists in the Frankencoin system, and it can be exploited under exactly the same circumstances. If a challenge only has a single bid when the challenge period ends, and that bid is near zero, the bid will still win the collateral regardless of how much it is actually worth.

At first glance, Frankencoin developers might be tempted to believe that the dynamic challenge period on its positions will allow for the system to rely primarily on auctions that can outlast abnormally volatile days. In practice, however, this is unlikely to be true, since "safe" positions will likely end up with very short challenge periods. This is unavoidable, because the vast majority of ZCHF will be backed by these types of collateral, and the system risks carrying untenable amounts of bad debt ever more the longer these challenge periods are extended. And extending these windows does not actually solve the problem anyways, since the bad debt cannot be covered until they end.

Consider, as well, that Frankencoin has a significant additional barrier to liquidating its positions when compared with MakerDAO: challenging requires collateral. I'll actually discuss this piece of the challenge design in more detail in a separate report, but it bears mentioning that such a requirement will only make it less likely that positions will be challenged under extreme network and market conditions in the first place. If huge swaths of positions against a highly trusted collateral type all violate their liquidation prices concurrently, the amount of capital required to challenge all unsafe positions at once is unlikely to materialize quickly. This will lead to a severe loss of confidence in the ZCHF peg, as the system's bad debt balloons, auctions clear for pennies on the dollar, and large, undercollateralized positions remain unchallenged. The peg likely could not withstand the ZCHF panic selling that would doubtlessly occur alongside this.

In fact, this vulnerability does not even require a malicious actor to make the protocol insolvent in market conditions such as these. Since a challenge with no bids will determine the collateral to be worthless, the protocol will fail to liquidate any collateral from some or all of its unsafe positions.

Tools Used

N/A

Since the high barrier to challenging positions is better covered in another report, its mitigation will be discussed there as well.

For the greater underlying problem in this report, the mitigation is actually relatively simple: the auctions should be converted to "dutch auctions." This simply means that, rather than starting from zero and accepting the highest bid, the auction should start above the liquidation price and gradually decrease. This will prevent any challenges from ending with winning near-zero bids.

#0 - c4-pre-sort

2023-04-26T11:21:25Z

0xA5DF marked the issue as low quality report

#1 - 0xA5DF

2023-04-26T11:39:01Z

Under certain extreme, but inevitable, network conditions, auctions will not be effective in covering the bad debt of a challenged position

The main function of challenges here is to prevent positions with wrong pricing from being minted, but will leave open for sponsor's comment since in some cases a low bid can cause loss to the protocol

#2 - c4-pre-sort

2023-04-26T11:41:17Z

0xA5DF marked the issue as primary issue

#3 - luziusmeisser

2023-05-03T07:17:16Z

Very interesting input.

However, I'm not convinced that a Dutch auction would always be preferrable. One of the strength of the FRankencoin system is that its auction mechanism can handle relatively exotic collaterals. For those, it might take a few days for the bidders to evaluate them or to organize the bid. If the price falls too low during that time, the challenge might be successful even though the market price is above the liquidation price...

#4 - luziusmeisser

2023-05-03T07:18:11Z

I would acknowledge this issue as medium severity.

#5 - c4-sponsor

2023-05-03T07:18:17Z

luziusmeisser marked the issue as disagree with severity

#6 - c4-judge

2023-05-18T04:10:35Z

hansfriese changed the severity to 2 (Med Risk)

#7 - c4-judge

2023-05-18T04:10:46Z

hansfriese marked the issue as selected for report

AuditHub

A portfolio for auditors, a security profile for protocols, a hub for web3 security.

Built bymalatrax Β© 2024

Auditors

Browse

Contests

Browse

Get in touch

ContactTwitter