Due to an oversight, some functions do not work with permissioned tokens.
When creating a contingent pool, one of the parameters submitted is the address of a permissionedERC721Token
, which prevents addresses with zero balance of that asset to hold position tokens. The AaveDIVAWrapper allows a permissioned user to add liquidity with no issue, as the position tokens are submitted to an inputted address.
However, when removing liquidity through the AaveDIVAWrapper, the user has to first send their tokens to the wrapper in order to call removeLiquidity
, which burns them. This operation will revert if the contract does not hold the ERC721 asset, but the contract also does not include any functionality to interact with them, which means the asset will be lost in order for this functionality to be available. For ERC721s with real market value, this could be a costly operation not worth the effort.
Notice this issue does not exist for the DIVA protocol as the main function in there simply burns the position tokens of the `msg.sender` directly, without transfer of tokens.
Additionally, since the contract does not include an ERC721 receiver interface, transfer calls with the `safeTransferFrom` method will revert.
At least one ERC-721 will have to be sent and consequently lost in order to work for the contract.
Create a function that allows the contract's owner to transfer ERC721 tokens. This way, the asset can be successfully retrieved.
Alternatively, modify the permissioned ERC20 tokens contract in order to include a whitelist function, and include this contract's address into it.
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.