✅RACE #17
Last updated
Last updated
Note: All 8 questions in this RACE are based on the below contract. This is the same contract you will see for all the 8 questions in this RACE. The question is below the shown contract.
deposit() can revert:
Comment:
A: If the ether (msg.value) provided with the call to deposit() is less than the specified amount, the attempt to call WETH.deposit() will revert.
B: If no ether was provided with the call and the caller has an insufficient balance of WETH, or given insufficient approval to their WETH balance, the attempt to call WETH.transferFrom() will revert.
C: For the "cap exceeded" error to be thrown, totalContributions + amount > TOTAL_CONTRIBUTION_CAP. But TOTAL_CONTRIBUTION_CAP = type(uint72).max and totalContributions is uint72. So the attempt to add an amount to totalContributions that would make it larger than type(uint72).max would revert from an integer overflow error before the require() ever could. This makes the require() basically redundant and it can be removed.
D: The deposit() function is a external. An attempt to call it internally would not revert but never compile in the first place. The contract could still call this function via this.deposit() though, which would make the contract CALL itself like it would an external contract.
What issues pertain to the deposit() function?
Comment:
A: For a re-entrancy an unsafe external call needs to be made. All the external calls being made within the deposit() are to the trusted WETH contract which does also not have any sender callbacks/hooks like an ERC777 would have.
B/C: If the specified amount was larger than the sent msg.value, the function would revert. But on the other hand, if the amount was smaller than the actual sent msg.value the deposit would only handle the amount and the rest of the ether would be locked in the Vault contract.
D: The fact that totalContributionCap isn't enforced on an individual level does not cause an issue as totalContributions's value would revert before any individual contributor would be able to make deposits beyond the cap.
Which of the following is/are true about withdraw()?
Comment:
A: The withdraw() function follows the Checks-Effects-Interactions pattern: (Check) Subtracting the amount from the individual's contribution would revert if the integer were to underflow. (Effect) The individual contributor's balance is updated before the value is transferred. (Interactions) The unsafe external call to the msg.sender is only made once all Checks and Effects have been applied. Re-entering the contract would not allow draining any funds.
B: It's true that there's improper accounting, but the effect is that funds would be stuck, not drained.
C: As only 63/64 gas is forwarded, the function should have sufficient gas remaining for execution (hence the high gas limit assumption).
D: True, if msg.sender reverts (eg. is a contract that lacks payable / fallback function).
Which of the following parameters are correctly emitted in the ContributorsUpdated() event?
Comment:
A: Option A is understandably ambiguous: if withdrawals were working, then you could have an existing contributor be recognized as a new one. Nevertheless, in its current state, we can take it to emit for only legitimately new contributors.
B: Generally, it's not safe to make assumptions about the evaluation order of expressions in Solidity. How obscure this can be especially for event emissions has been shown in last year's Underhanded Solidity contest: "The indexed parameters are evaluated first in right-to-left order, then the non-indexed parameters are evaluated left-to-right". Because of this, the general best practice is to avoid nested expressions whenever possible and do them within separate lines of code.
C: One of the most common gas optimizations seen in Code4rena reports is how the prefix increment (++i) is more efficient than postfix (i++). However, most aren't aware of a key difference: Prefix increments returns the value BEFORE the increment, postfix returns the value AFTER.
The vault deployer can pause the following functions:
What is the largest possible allowance given to the controller?
The requestAllowance() implementation would have failed after the 1st call for tokens that only allow zero to non-zero allowances. Which of the following mitigations do NOT work?
Comment:
There are some implementations of ERC20 tokens that require an approval to be reset to 0 before it can be updated to another non-zero value.
The safeIncreaseAllowance() / safeDecreaseAllowance() functions request the current allowance, adding/subtracting the specified amount and then update it by calling approve(). These functions do not set the approval to 0 in between, so for these tokens the function would still fail after the 1st call.
Which of the following gas optimizations are relevant in reducing runtime gas costs for the vault contract?
Comment:
A: Changing ALLOWANCE_CAP to be constant would actually consume more runtime gas as the expression would then be evaluated on every call, while with immutable the expression would be calculated during deployment and then become a static value. (Note that there's no difference between these options anymore when the via-IR compilation pipeline and optimization is used).
B: Increasing the optimizer's runs configuration will increase the deployment bytecode size but decrease the gas usage at runtime.
C: The smaller the function's ID the earlier it can be found by the function selector.
D: It wouldn't be safe to use unchecked math in the withdraw() function as it would potentially allow users to withdraw more than they should be able to. (The wording is intended to imply that the entire function's body would be put into an unchecked block.)
