usmannk - Users can avoid the max payout limit for FPA and OFDA auction types

[sherlock-admin]

usmannk

medium

Users can avoid the max payout limit for FPA and OFDA auction types

Summary

The OSDA auction type updates the sale price of a bond after each sale. However the price of the next sale is only dependent on previous sales. For a sale at time t only the actions taken in time [0,t-1] are considered. To avoid a buyer at time t making an outsized impact based on the previous state, a maxPayout parameter was introduced. This way buyers have to split large orders into several, allowing for state updates to occur within the order.

However, the FPA and OFDA auction types have no such dependence between price and previous sales. For these auctions, the maxPayout parameter only causes the buyer to waste gas as making two identical orders will use the same price as just making one order twice as large.

Vulnerability Detail

The maxPayout parameter in FPA and OFDA auctions can be avoided by simply making many transactions in between oracle updates. This is an identical operation to just removing the maxPayout parameter from these auction types altogether.

https://github.com/sherlock-audit/2023-02-bond/blob/main/bonds/src/bases/BondBaseFPA.sol#L286-L287

Impact

maxPayout limit is totally avoided by buyers

Code Snippet

Tool used

Manual Review

Recommendation

Remove the maxPayout parameter from auctions where price is independent of previous sales.

[Oighty]

Acknowledge that users can exceed the max payout by making consecutive transactions. Market creators can set max payout to 100% of the market capacity by making the depositInterval the same as the market duration. However, we kept the option for maxPayout in these variants for consistency with the other auction types and to allow market creators to create some friction to a user buying out the whole capacity if they wish. This is functioning as designed.

[UsmannK]

Escalate for 10 USDC.

I identified a way to avoid the maxPayout parameter, extracting more tokens from the contract than should be possible simply by splitting an invalid loan into two, identical, half-sized loans.

There was no way for watsons or Sherlock to know that the maxPayout parameter was actually meant to do nothing, in spite of its name and calculations.

Furthermore, I discussed the issue with protocol dev indigo#0520 at the time, and they supported this finding stating this is the best suggestion i've got since the audit started.

By any expectations of watsons during the contest, this issue identifies a way to break the maxPayout parameter and extract more funds than should be possible.

[sherlock-admin]

Escalate for 10 USDC.

I identified a way to avoid the maxPayout parameter, extracting more tokens from the contract than should be possible simply by splitting an invalid loan into two, identical, half-sized loans.

There was no way for watsons or Sherlock to know that the maxPayout parameter was actually meant to do nothing, in spite of its name and calculations.

Furthermore, I discussed the issue with protocol dev indigo#0520 at the time, and they supported this finding stating this is the best suggestion i've got since the audit started.

By any expectations of watsons during the contest, this issue identifies a way to break the maxPayout parameter and extract more funds than should be possible.

You've created a valid escalation for 10 USDC!

To remove the escalation from consideration: Delete your comment.

You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final.

[hrishibhat]

Escalation rejected

Not a valid medium The bypassing of maxpayout can be considered low in this case: As there is no loss of funds or does not break the core functionality of the contract which may result in adverse situations. While the documentations for these parameters could have been improved, there is no risk of funds

[sherlock-admin]

Escalation rejected

Not a valid medium The bypassing of maxpayout can be considered low in this case: As there is no loss of funds or does not break the core functionality of the contract which may result in adverse situations. While the documentations for these parameters could have been improved, there is no risk of funds

This issue's escalations have been rejected!

Watsons who escalated this issue will have their escalation amount deducted from their next payout.