The withdrawal flow requires the PerpetualVault::_transferToken function to successfully transfer the required tokens to the user. The transfer is executed inside a try-catch block, and on a failed transfer, the funds are sent to the PerpetualVault::treasury address. At this point, there is no way for the user to try to recover these funds.
PerpetualVault::_transferToken contains the following code:
This function is executed in PerpetualVault::_handleReturn calls which happen at the end of the withdrawal flow as long as the withdrawal amount is non-zero. The recipient address and the relevant deposit ID have been through multiple checks for their validation. If the try block still fails, the funds are transferred to the treasury address, which the user has no way of interacting with. Thus, the user cannot attempt to withdraw their funds again.
Managing user funds is not the responsibility of the treasury, so at a minimum this is a centralization risk. Responding to a failed withdrawal would require trying to push the funds into the recipient's account, which is not recommended. At worst, this could lead to loss of user funds.
Create a function to respond to the event emitted in the catch block. This can be done in the treasury, if there is no logic relying on balance(this) or balanceOf(this) for handling accounting. Depending on the frequency of the issue, it may make sense to have a secondary address for this. Maintain a mapping of user => amount with the fixed amount calculated during the withdrawal flow. Create PerpetualVault::tryWithdrawalAgain so that users can retry withdrawing their funds without affecting internal accounting in PerpetualVault.
There is no real proof, concrete root cause, specific impact, or enough details in those submissions. Examples include: "It could happen" without specifying when, "If this impossible case happens," "Unexpected behavior," etc. Make a Proof of Concept (PoC) using external functions and realistic parameters. Do not test only the internal function where you think you found something.
Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.
There is no real proof, concrete root cause, specific impact, or enough details in those submissions. Examples include: "It could happen" without specifying when, "If this impossible case happens," "Unexpected behavior," etc. Make a Proof of Concept (PoC) using external functions and realistic parameters. Do not test only the internal function where you think you found something.
Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.