FEI and TRIBE Redemption contest - cccz's results

Do not understand what the issue presented is. If the attacker sends funds to the contract so the balances are not 0, then the user would be able to redeem as normal. How do they suffer any loss if they 'redeem early'?

The balances will only be 0 when all users have redeemed. Not an issue

@thomas-waite Consider the following scenario.

1. there are no reward tokens in the TribeRedeemer contract now, (the administrator will transfer 100M reward tokens to the contract in exchange for the user's redeemedToken only after some time).
2. when the user provides redeemedToken to call the redeem function, the transaction reverts in the previewRedeem function because the reward token balance is 0 (this prevents the user from getting 0 reward tokens).

        for (uint256 i = 0; i < tokensReceived.length; i++) {
            uint256 balance = IERC20(tokensReceived[i]).balanceOf(address(this));
            require(balance != 0, "ZERO_BALANCE");

3. a malicious user can send 100 reward tokens to the contract in advance.
4. At this point, if the user calls the redeem function, the transaction will not revert and the contract will exchange the 100 reward tokens for the user's redeemedToken. The user could have exchanged the redeemedToken for more reward tokens, but the user only got a small amount of reward tokens

Redemptions can only begin when the contract has non-zero balances for all redeemed tokens, but the start redemption time isn't explicitly stated.

Malicious users can break this assumption by sending paltry amounts to the contract as explained above. Naiive users might begin redemptions early, thus losing out on the tokens they would've otherwise received after the full redemption token amounts have been sent to the contract.

It is unclear if there is a time lag between the contract deployment and time at which redemption funds are sent, and if so, its duration.

While unlikely to happen, it would be a case of users losing out on rewards they should be entitled to. Hence, I'm siding with the warden in this instance.

@HickupHH3 , the contract gets deployed ahead of time by necessity (the address is needed for the DAO vote). The DAO vote which funds the contract executes after deployment, there is a time lag of >= 3 days.

I do not agree that the situation described is a vulnerability in the contract and instead it would be down to user/deployer error. Clearly, no user was encouraged to redeem before funds were available and the contract address was not publicised. So no user attempted to redeem before funds were available.

I respectfully disagree.

There is no doubt that there a number of prerequisites to enable this attack, which makes the likelihood low:

• Malicious actor has to know what the redeemer contract is
• Malicious actor has to deposit some tokens into redeemer contract
• Malicious actor must be able to trick users into redeeming early

From a game theory POV, small TRIBE holders could band together to target a few large TRIBE holders.

With these external requirements, it is only then that we will see what could be deemed as "protocol leaked value".

2 — Med: Assets not at direct risk, but the function of the protocol or its availability could be impacted, or leak value with a hypothetical attack path with stated assumptions, but external requirements

The scenario thankfully remained hypothetical.