Ondo Finance - Aymen0909's results

Institutional-Grade Finance, Now Onchain.

General Information

Platform: Code4rena

Start Date: 29/03/2024

Pot Size: $36,500 USDC

Total HM: 5

Participants: 72

Period: 5 days

Judge: 3docSec

Total Solo HM: 1

Id: 357

League: ETH

Ondo Finance

Findings Distribution

Researcher Performance

Rank: 55/72

Findings: 1

Award: $8.28

🌟 Selected for report: 0

🚀 Solo Findings: 0

Lines of code

https://github.com/code-423n4/2024-03-ondo-finance/blob/main/contracts/ousg/ousgInstantManager.sol#L278-L324 https://github.com/code-423n4/2024-03-ondo-finance/blob/main/contracts/ousg/ousgInstantManager.sol#L388-L456

Vulnerability details

Issue Description

Users can mint OUSG/ROUSG tokens by calling mint or mintRebasingOUSG functions respectively and by providing a certain amount of USDC tokens and they can also redeem their USDC afterwards by calling redeem or redeemRebasingOUSG.

For each of these operation (mint or redeem) the current OUSG/USD price is fetched from the oracle and is used as the main exchange rate between OUSG and USDC, this is done in both minting and redeeming functions through invoking getOUSGPrice() function and then converting between OUSG/USDC using _getMintAmount (when minting) or _getRedemptionAmount (when redeeming).

As we all know token prices can fluctuate between the moment a tx is submit on chain and when its executed, for example tx could stay pending for relatively long time in mempool. Knowing this and the fact that neither the minting or redeeming functions implement some sort of slippage protection mechanism (like min amount out or tx deadline), users will be at risk of losing a portion of the token they are expecting to receive (either OUSG/ROUSG when minting or USDC when redeeming) due to slippage occurring on OUSG price fluctuations.

NOTE: This issue is different from the out of scope issues related to OUSG price which are more related to price manipulation or unrealistic price mouvements, this issue is related to normal OUSG price fluctuation in the market when a user submit a mint/redeem tx.

To illustrate this issue, consider the following scenario:

  • Current OUSG price is 120e18 USD.

  • Bob submit tx to redeem 1000e18 OUSG tokens (burn) and is expecting to receive 120000e6 USDC tokens in return.

  • While Bob's transaction is pending in the mempool (for some time), the OUSG price drops to 112e18 USD.

  • SO now when Bob's transaction goes through, he will only receive: 112000e6 USDC tokens.

  • Thus, instead of receiving 120000 USDC tokens, he only gets 112000 back, resulting in a loss of 8000 USDC tokens which is huge.

If Bob had known that the OUSG price had dropped, he would have waited until the price increased again to redeem his tokens.

And the same issue can occur when minting, in that case if OUSG price increase while users tx is pending they will receive less OUSG tokens that expected.

Impact

Users at risk of losing funds when minting or redeeming OUSG/ROUSG from OUSGInstantManager due OUSG price change which result in important slippage.

Tools Used

Manual review, VS Code

Minting (mint, mintRebasingOUSG) and redeeming (redeem or redeemRebasingOUSG) functions in OUSGInstantManager should include slippage protection parameters provided by the users (either minimum amount out or a tx deadline).

Assessed type

Context

#0 - c4-pre-sort

2024-04-04T03:00:48Z

0xRobocop marked the issue as duplicate of #250

#1 - c4-pre-sort

2024-04-04T22:59:56Z

0xRobocop marked the issue as duplicate of #156

#2 - c4-judge

2024-04-09T08:00:23Z

3docSec marked the issue as satisfactory

#3 - c4-judge

2024-04-11T15:13:13Z

3docSec changed the severity to QA (Quality Assurance)

#4 - c4-judge

2024-04-11T15:16:05Z

3docSec marked the issue as grade-b

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