Platform: Code4rena
Start Date: 21/06/2022
Pot Size: $50,000 USDC
Total HM: 31
Participants: 99
Period: 5 days
Judges: moose-code, JasoonS, denhampreen
Total Solo HM: 17
Id: 139
League: ETH
Rank: 41/99
Findings: 1
Award: $119.25
🌟 Selected for report: 0
🚀 Solo Findings: 0
🌟 Selected for report: 0x1f8b
Also found by: BowTiedWardens, Lambda, StErMi, berndartmueller, csanuragjain, neumo, rfa
https://github.com/code-423n4/2022-06-yieldy/blob/main/src/contracts/BatchRequests.sol#L37
Function removeAddress(address _address) in BatchRequests.sol simply deletes the address from the array, so it turns into the zero address. If there is an address in the array of contracts that is not a Staking contract, calls to canBatchContracts() will fail with "Transaction reverted: function call to a non-contract account". So removind an address renders the function canBatchContracts useless as there is no way in the contract to update a contract from the contracts array.
I added this test to batchRequests.ts to prove that calls to canBatchContracts will fail after an address is removed:
it("Should'nt call canBatchContracts after removing an address", async () => { await batchRequests.addAddress(staking.address); await batchRequests.addAddress(staking2.address); await batchRequests.addAddress(staking3.address); await batchRequests.removeAddress(staking2.address); const canBatchContracts = await batchRequests.canBatchContracts(); });
Hardhat
Update the code of removeAddress to resize the array and don't leave gaps when removing addresses from the array.
#0 - toshiSat
2022-06-27T23:52:59Z
duplicate #89
#1 - neumoxx
2022-09-08T13:03:24Z
Hi @toshiSat, I can't see whats the difference in what I describe here with issue #38 , isn't it the same?
#2 - neumoxx
2022-09-08T13:53:06Z
Hi @toshiSat, I can't see whats the difference in what I describe here with issue #38 , isn't it the same?
@JasoonS sorry I pinged Toshi, I thought he was the judge. This message was originally for you!
#3 - moose-code
2022-09-19T13:01:32Z
Hi @neumoxx - after further consideration, we have re-assessed that issues #82, #283, #115, #89, #61, and #241 should have all been marked as duplicates of #38.
CC @JasoonS