Receiver might not support deposits

Summary

A user can deposit on behalf of another address. However, it is not accounted for that the receiver might not be able to withdraw or perform other actions on the protocol later.

Vulnerability Detail

deposit and other functions, can be called with an arbitrary _receiver. The receivers get minted tokens of shares. Later when the tokens are unlocked the receivers have to withdraw their tokens themselves. However, the protocol did not verify initially that the receiver is aware of how to interact with the protocol, so there is a possibility that this address is a smart contract that cannot handle the withdrawals.

Impact

The tokens will remain stuck in the contract if the receiver is not able to claim them. The protocol does not try to minimize the risk of user errors.

Code Snippet

    function deposit(uint256 _amount, uint256 _duration, address _receiver) external override {
        ...
        depositToken.safeTransferFrom(_msgSender(), address(this), _amount);
        ...
        depositsOf[_receiver].push(Deposit({
            amount: _amount,
            shareAmount: mintAmount,
            start: uint64(block.timestamp),
            end: uint64(block.timestamp) + uint64(duration)
        }));

        _mint(_receiver, mintAmount);
    }

   function withdraw(uint256 _depositId, address _receiver) external {
        ...
        depositsOf[_msgSender()][_depositId] = depositsOf[_msgSender()][depositsOf[_msgSender()].length - 1];
        depositsOf[_msgSender()].pop();

        _burn(_msgSender(), userDeposit.shareAmount);

        depositToken.safeTransfer(_receiver, userDeposit.amount);

Tool used

Manual Review

Recommendation

Consider checking if the receiver is EOA and if not, if the contract implements the correct interface that can handle withdrawals (e.g. EIP-165 https://eips.ethereum.org/EIPS/eip-165).

sherlock-audit / 2022-10-merit-circle-judging

HonorLt - Receiver might not support deposits #104