Withdraw helper contract to support collecting funds from channels

[abarmat]

Summary

Introduces a contract called GRTWithdrawHelper. The main goal of this contract is to encode custom logic in the process of withdrawing funds from the Vector Channel Multisigs. The contract receives funds from a Channel Multisig, then it forwards them to the Staking contract related to an Allocation.

Features

• The GRTWithdrawHelper is deployed with the token address that will be used for transfers, in our case it is the GRT token address. It can't be changed at later stage but this can easily be solved deploying a new contract if needed.
• The contract expects to have available tokens in balance when execute(WithdrawData calldata wd, uint256 actualAmount) is called by the Channel. For that to happen the Channel needs to transfer funds to the WithdrawHelper before execute is called.
• On execute the WithdrawHelper will approve the funds to send to the Staking contract and then execute collect() passing the proper allocationID and amount. The Staking contract will then pull the tokens.
• If the call to collect() fails, the funds are returned to the channelAddress. This is important for Vector accounting of funds.

Requirements

• Set the GRTWithdrawHelper contract as AssetHolder in the Staking contract. This way we allow accepting funds from this contract.
• The cooperative withdrawal commitments must have the following data (indicated with arrows):

struct WithdrawData {
    address channelAddress;
    address assetId;  // -> GRT token address
    address payable recipient; // -> GRTWithdrawHelper contract address
    uint256 amount;
    uint256 nonce;
    address callTo; // -> GRTWithdrawHelper contract address
    bytes callData; // -> CollectData struct defined below
}

struct CollectData {
    address staking;  // -> Staking contract address
    address allocationID; // -> AllocationID to send collected funds
}

The parties must agree and sign the WithdrawalCommitment with that information to achieve proper execution of the withdrawals.

Exceptions

The following conditions will result in reverts of the execution:

• assetId in WithdrawData not matching the token address configured in the GRTWithdrawHelper.
• GRTWithdrawHelper not having enough balance to transfer the Staking contract as stated in actualAmount.
• Setting an invalid staking contract address.

Note: To avoid unexpected conditions in the Vector offchain logic, it is encouraged that the parties verify the WithdrawData does not revert by doing a call/estimateGas.

Handled Exceptions

These reverts are handled and will make the contract to return the funds to the channel address.

• Doing a withdrawal on a non-existing allocationID as defined in CollectData when calling collect().

Known Behaviour

• This contract does not know if a WithdrawalCommitment is right or wrong. It just accepts a transfer and WithdrawData that defines a destination.
• A properly formatted WithdrawData can be crafted to send outside funds to the Staking contract. In that case, the person will get those funds distributed with Curators + Delegators + taxed a protocol percentage. There is no rational economic incentive to do so.

[rhlsthrm]

If this function reverts, the channel funds will be gone. We need to try-catch this call and provide a backup address the funds can be sent to (can even be the channel multisig address which is already part of the withdraw data).

[abarmat]

The collect function will only revert if: the allocation ID passed id 0x0 or invalid, it will then accept funds in any case.

My question is, why is that those funds will be lost? won't the collect call reverting make the transaction fail?

I based this on how the https://github.com/connext/vector-withdraw-helpers/blob/main/contracts/UniswapWithdrawHelper/UniswapWithdrawHelper.sol works.

[rhlsthrm]

The transaction will fail, but the funds are already signed out of the channel offchain, so they are effectively marked as "used".

[lastperson]

@rhlsthrm and if the transfer to the channel is made instead, it will be credited to Bob, even though it might've being made by Alice?

[abarmat]

@rhlsthrm what happens if this transaction fails due to an out of gas exception?

[rhlsthrm]

@rhlsthrm and if the transfer to the channel is made instead, it will be credited to Bob, even though it might've being made by Alice?

Yes, if the transfer is made directly to the channel address, it will be credited to Bob. However, you can call depositAlice. We might be able to program the logic to send to channel vs call depositAlice into the helper itself.

[rhlsthrm]

@rhlsthrm what happens if this transaction fails due to an out of gas exception?

If it fails with hitting the gas limit on the transaction, you can resubmit the withdrawal commitment with a higher gas limit. It's only the case of a permanent failure that the funds are unrecoverable.

[abarmat]

Perfect

[abarmat]

Rebased