Closed sherlock-admin2 closed 1 year ago
1 comment(s) were left on this issue during the judging contest.
Trumpero commented:
invalid, contract
BalancerBeethovenAdapter
is used byBalancerAuraDestinationVault
, but there is no function call fromBalancerAuraDestinationVault
toBalancerBeethovenAdapter.removeLiquidity()
. So no impact here
Escalate
This is an error in the code. The protocol team should review it and determine if it indeed causes no impact on other contracts (internal or external) or off-chain componentsand fix them if necessary.
Another point that I would like to highlight is that based on the judging comment, if this issue indeed has no impact after the protocol has reviewed, it should be marked as Low/Informational instead of Invalid. If an issue is technically correct, it should not be marked as invalid due to the following reasons:
1) The protocol team might miss out on valid low/informational issues , which they might be interested in fixing if they have seen them in the first place if they are tagged correctly. During fixing review, some project teams I have worked with in Sherlock are also interested in fixing Low/Information issues. 2) Watson's ratio might unnecessarily be penalized for an issue that is valid in the first place.
Escalate
This is an error in the code. The protocol team should review it and determine if it indeed causes no impact on other contracts (internal or external) or off-chain componentsand fix them if necessary.
Another point that I would like to highlight is that based on the judging comment, if this issue indeed has no impact after the protocol has reviewed, it should be marked as Low/Informational instead of Invalid. If an issue is technically correct, it should not be marked as invalid due to the following reasons:
1) The protocol team might miss out on valid low/informational issues , which they might be interested in fixing if they have seen them in the first place if they are tagged correctly. During fixing review, some project teams I have worked with in Sherlock are also interested in fixing Low/Information issues. 2) Watson's ratio might unnecessarily be penalized for an issue that is valid in the first place.
You've created a valid escalation!
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.
Hello @xiaoming9090, thank you for your feedback on my judging. I appreciate your input, and I will take more care when evaluating issues as low or invalid in the future.
Regarding this specific issue, I believe it should be categorized as low. Here's my reasoning: In my view, if a function is actually used in a larger codebase within Tokemak and that codebase is not currently within the scope of the audit, the issue should still be marked as low. This approach is similar to the treatment of view functions. We cannot determine whether a view function can be used in a larger codebase or not. Therefore, it would be unfair to competitors who submit view-related issues and do not receive any rewards. That's why I have categorized this report as low.
Planning to reject escalation and keep issue state.
It's unclear to me why this has high severity impact. It's unclear how a potential loss can occur.
Result: Invalid Unique
xiaoming90
high
BPT_IN_FOR_EXACT_TOKENS_OUT
should be used instead ofEXACT_BPT_IN_FOR_ALL_TOKENS_OUT
forremoveLiquidity
functionSummary
The incorrect type of exit is performed when the affected
removeLiquidity
function is executed, leading to a revert or an error while withdrawing liquidity from Balancer.Vulnerability Detail
For the
BalancerBeethovenAdapter.removeLiquidity
function, it was understood from the sponsor that its purpose is to perform a "variable BPT in, exact tokens out" for the Balancer pools. Thus, this function accepts the exact tokens expected to receive and the max acceptable number of LP tokens to be burned.https://github.com/sherlock-audit/2023-06-tokemak/blob/main/v2-core-audit-2023-07-14/src/destinations/adapters/BalancerBeethovenAdapter.sol#L151
However, "exact BPT in, variable tokens out" is performed instead for Balancer's Composable pools due to the wrong
ExitKindComposable.EXACT_BPT_IN_FOR_ALL_TOKENS_OUT
flag being used.ExitKindComposable.EXACT_BPT_IN_FOR_ALL_TOKENS_OUT
used in Line 160 above is wrong because it performs an_exitExactBPTInForTokensOut
function as per the Balancer's source code.https://github.com/balancer/balancer-v2-monorepo/blob/227683919a7031615c0bc7f144666cdf3883d212/pkg/pool-stable/contracts/ComposableStablePool.sol#L843
Impact
The incorrect type of exit is performed when the affected
removeLiquidity
function is executed, leading to a revert or an error while withdrawing liquidity from Balancer.Code Snippet
https://github.com/sherlock-audit/2023-06-tokemak/blob/main/v2-core-audit-2023-07-14/src/destinations/adapters/BalancerBeethovenAdapter.sol#L151
Tool used
Manual Review
Recommendation
Update the affected function to use the
ExitKindComposable.BPT_IN_FOR_EXACT_TOKENS_OUT
flag instead of theExitKindComposable.EXACT_BPT_IN_FOR_ALL_TOKENS_OUT
flag as shown below.