Platform: Code4rena
Start Date: 18/10/2023
Pot Size: $36,500 USDC
Total HM: 17
Participants: 77
Period: 7 days
Judge: MiloTruck
Total Solo HM: 5
Id: 297
League: ETH
Rank: 30/77
Findings: 2
Award: $144.51
🌟 Selected for report: 0
🚀 Solo Findings: 0
🌟 Selected for report: falconhoof
Also found by: 0x6d6164616e, Baki, Beosin, Krace, T1MOH, bitsurfer, immeas, pep7siup, tnquanghuy0512, twicek
90.3185 USDC - $90.32
Wrong surplusTransferPercentage
check condition in auctionSurplus
. Instead of under 100 WAD, it's currently check if the percentage is under 1 WAD, resulting major issue of not accepting correct surplus transfer percentage in a range of 1 - 100 WAD
There is a clear wrong check in AccountingEngine's auctionSurplus
function where it should be checking surplusTransferPercentage > ONE_HUNDRED_WAD
instead of surplusTransferPercentage > WAD
File: AccountingEngine.sol 199: if(_params.surplusTransferPercentage > WAD) revert AccEng_surplusTransferPercentOverLimit();
With current code, the surplusTransferPercentage
will only accept if the number is under a WAD. Meanwhile there is also check _params.surplusTransferPercentage < ONE_HUNDRED_WAD
in Line 213, which is contrary with the line 199, as ONE_HUNDRED_WAD
is 100 * WAD.
Manual Analysis
Replace WAD
to ONE_HUNDRED_WAD
,
if(_params.surplusTransferPercentage > ONE_HUNDRED_WAD) revert AccEng_surplusTransferPercentOverLimit();
Invalid Validation
#0 - c4-pre-sort
2023-10-26T05:30:05Z
raymondfam marked the issue as sufficient quality report
#1 - c4-pre-sort
2023-10-26T05:30:26Z
raymondfam marked the issue as duplicate of #26
#2 - c4-judge
2023-11-03T14:01:38Z
MiloTruck marked the issue as partial-50
#3 - c4-judge
2023-11-03T14:01:45Z
MiloTruck marked the issue as satisfactory
#4 - MiloTruck
2023-11-03T14:01:51Z
Partial credit as this report didn't point out how using ONE_HUNDRED_WAD
in percentage calculations results in _amountToSell
becoming massively inflated.
#5 - c4-judge
2023-11-03T16:47:53Z
MiloTruck marked the issue as partial-50
54.1911 USDC - $54.19
https://github.com/open-dollar/od-contracts/blob/v1.5.5-audit/src/contracts/oracles/UniV3Relayer.sol#L18 https://github.com/open-dollar/od-contracts/blob/v1.5.5-audit/src/contracts/oracles/CamelotRelayer.sol#L20
Wrong addresses for UniV3Relayer and CamelotRelayer (using GOERLI)
In UniV3Relayer's _UNI_V3_FACTORY
it still use GOERLI instead of UNISWAP_V3_FACTORY. Same case with CamelotRelayer.
In the UniV3Relayer.sol
file, on line 18, the constant _UNI_V3_FACTORY
is set to GOERLI_UNISWAP_V3_FACTORY
. This should likely be replaced with the correct address, which is UNISWAP_V3_FACTORY
.
Similarly, in the CamelotRelayer.sol
file, on line 20, the constant _CAMELOT_FACTORY
is set to GOERLI_CAMELOT_V3_FACTORY
. This should be updated to the correct address, which is CAMELOT_V3_FACTORY
.
File: UniV3Relayer.sol 16: contract UniV3Relayer is IBaseOracle, IUniV3Relayer { 17: // --- Registry --- 18: address internal constant _UNI_V3_FACTORY = GOERLI_UNISWAP_V3_FACTORY; File: CamelotRelayer.sol 18: contract CamelotRelayer is IBaseOracle, ICamelotRelayer { 19: // --- Registry --- 20: address internal constant _CAMELOT_FACTORY = GOERLI_CAMELOT_V3_FACTORY;
Understandably this might be because developer forgot to replace test variable to the intended one, but still this is a medium issue, wrong 'hardcoded' address may resulting a brick of the protocol.
Manual Analysis
Use the correct address of Uniswap and camelot v3 factory
Other
#0 - c4-pre-sort
2023-10-26T05:35:27Z
raymondfam marked the issue as low quality report
#1 - c4-pre-sort
2023-10-26T05:35:51Z
raymondfam marked the issue as duplicate of #119
#2 - c4-judge
2023-11-02T08:46:44Z
MiloTruck marked the issue as satisfactory