Raft Finance Audit Competition- Final Note

It’s been a record-breaking month for the Hats team! We are proud to officially end our competition with Raft Finance and share the list of winners with you. Huge shoutout to all security researchers for their contribution to the web3 ecosystem.

On May 11th, we launched an audit competition for Raft Finance, and in total, we received 61 submissions, of which 19 qualified for a prize.

We have known the Raft Finance team for a while, and while they are familiar with our decentralized procedure, the audit competition was a new product they were excited to try. Overall, we had a good experience working together and got exceptional entries from participants.

Continue reading to explore the detailed breakdown of submissions and the highly anticipated announcement of the winner, who will be awarded a substantial total prize of $64,000.

High severity

0xb…EBc

0x4….47D

0xb…EBc

Attacker can trigger redistributions and liquidate safe positions in a multi-collateral system: In PositionManager, it is possible to trigger a liquidation of collateral that is different from what was originally used to open a position. When this happens, the entirePositionCollateral will be zero, as will the icr variable. As a result, a redistribution will occur, and “safe” accounts (which have ICR >= MCR in reality) will be open to liquidation. An attacker can use this to liquidate safe positions in a cascade.

OneStepLeverage — When closing a position excess collateral tokens are not transferred to the user: When closing a position the total collateral amount of the position is transferred to the contract. And minReturnOrAmountToSell amount of collateral tokens is swapped to rToken to repay flash mint. But if this value is less than the position’s collateral token balance transferred to the contract, only a part of the tokens is swapped.

Redemptions in the case of a multi-collateral system allows anyone to liquidate healthy positions: Redemptions allow anyone to burn their rTokens, and redeem collateralTokens of equal value in return. Inside redeemCollateral(), total debt is decreased for all of the borrowers. However, the collateral would only be decreased for collateral token address passed inside the redeemCollateral. Hence, The decrease in total debt is spread over all borrowers, while a decrease in collateral is only spread over borrowers using specified collateral.

Medium Severity

0xb…ebc

0x4…672

0x4…672

0x3…fd3

ChainlinkPriceOracle deviation formula can lead to invalid responses being accepted: ChainlinkPriceOracle._chainlinkPriceChangeAboveMax uses the larger price as the denominator in order to calculate the deviation percent between the current and previous responses. However, this can lead to invalid responses being accepted.

TellorPriceOracle can be manipulated, pushing any price: Because there’s no check for a delay any attacker can place a malicious value in tellor and get the oracle to use that.

Incorrect use of Redstone oracle exposes protocol to incorrect collateral evaluation: RedstoneConsumerIntegration.sol defines stETH as DATA_FEED_ID as constant, and hence use stETH price feed only. However, the conversion for _convertIntoWstETHPrice is not done in RedstonePriceOracle.sol to accommodate stETH price feed.

Self Redemption can be caused to break Debt Accounting: The first depositor may be malicious, they can do a deposit for the minimum amount (borrow 301e18 tokens), then self-redeem causing all the future debt to be improperly counted.

Low Severity

0xb…EBc

0xb…EBc

0x4…672

0x4…672

0x4…672

0x4…672

0xb…EBc

0x3…fd3

0x3…fd3

0xB…4Ad

0x7…B2E

All low-severity findings can be found in the Raft GitHub repo.

Gas Savings

First Price- 0xb…EBc

Liquidate Gas Saving: liquidate call is always going to call priceFeed.fetchPrice(), which in turn would always call getPriceOracleResponse on chainlink oracle. Hence if getPriceOracleResponse of chainlink oracle is optimized, it would reflect in the gas costs of liquidation as well. And well there is one easy optimization, raft team can do inside getPriceOracleResponse. getPriceOracleResponse is always going to execute _chainlinkPriceChangeAboveMax to check if the price has changed above the max deviation. And there, since the calculation is done in ratios, the conversion _convertIntoWstETHPrice is unnecessary, it would get canceled out anyway due to division down there. (decimals of chainlink responses would always remain the same).

Disqualified submissions

Submissions that were not accepted were either invalid, duplicated, or out of scope. If you did not qualify for a bounty, and believe the evaluation process was unfair, email security@hats.finance with the following:

-Transaction ID of your submission

-Link to the PR (Pull Request)

-A detailed explanation of your concern

-Screenshots of communication with the Raft team

Final Remarks from the Raft Committee

It was great working with the Hats team, as well as all participants. We got a very good outcome, which helped us to make the protocol way safer. One thing that can be better is easier checking of on-chain submissions, which is something already being worked on. Keep up the great work.

Congratulations to the competition winners! You are all making a difference in the security world.

The competition with Raft was an incredible experience for us, as it allowed us to test new features and develop the best solution for both projects and security researchers.

Here are some key highlights:

Fast response: The Raft team was enthusiastic about ensuring the safety of their contracts, so they quickly decided to participate in the competition. Within just 14 days, they set up everything and launched the campaign. It is worth mentioning the swift evaluation process by the Raft team. Their familiarity with the code enabled them to respond promptly and encourage more feedback from the community.Submission process: We have taken note of the issues raised by security experts and worked on developing an on-chain submission process that automatically opens a GitHub issue. Although we didn’t have enough time to test it before the Raft competition began, we continued the development, and it is now ready. Starting the next competition, you can now submit an on-chain submission using a simplifying process. Please check the following video for more information: https://www.loom.com/share/d4d8076ebf414c44b1542cc73def06fa.Pointing system: We are currently discussing the pointing system internally, considering proposals from security researchers. While no formal decision has been made yet, we encourage you to stay tuned and share your thoughts in our Discord.Cap for high rewards: After two competitions with a cap on high severity rewards, we believe it will become a standard in Hats competitions. Both the projects and security experts are in favor of this measure.Dispute process: We are still in the process of developing an arbitrator process (MVP) for the audit competition. However, we have noticed that when skilled developers can assess and evaluate projects, disputes are minimized. We believe in challenging the system, but when everything is working smoothly, it is a testament to its effectiveness. We thank the Raft committee for their professional approach.Submission reports: We are actively working on providing the committees with more tools to simplify the classification process. We rely on your feedback, so please keep sharing your thoughts and suggestions.Formal verification: We will introduce formal verification severities in our next competition. We are excited about incorporating new security primitives into our competition.

What’s next:

In the coming weeks, we have several contests planned, not only for Solidity. Additionally, we are working on spec’ing the audit competition as a full-fledged product that we will offer. Based on our previous competitions, we have learned that Hats offers the best solution in the market for the 2nd+ audit round, providing the best incentive for both parties to participate.A new user interface will be launched within the next three weeks, incorporating all your feedback in one place. We encourage you to share more inputs with us, so we can continuously improve our process.

Thank you all for your support and contributions. Together, we can create a more secure and innovative environment for the blockchain community.

Hats team