Allow transferring the ownership of lockups

[arlai-mk]

It would be nice for Hydro to offer a LSM-like feature where Hydro users could transfer the ownership of any of their own lockups to a different address.

The lockups would stay locked with the exact same duration, only the owner of the lockup would change.

Ideally, any unclaimed rewards would stay claimable by the previous owner, but it would add some complexity, as Hydro would need to keep track of users "in the past rounds".

For vote aggregators, it would allow a frictionless onboarding of existing Hydro users.

[p-offtermatt]

Thanks for the suggestion!

I don't see major issues with supporting your ideal way of past rewards staying claimable.

In general, rewards seem fine with this transfer:
They are given based on user votes; it would look like a user has voted in the past with a lock id that now doesn't belong to them anymore.

The complexity on this issue is that the transfer needs to correctly "unvote" the transferred lockups beforehand, so #211 might be helpful to implement first.

[arlai-mk]

A quick comment here. I think it would be good if the Transfer message would be able to call a potentially receiving Smart Contract to have this Smart Contract complete the transfer to the user.

What I mean is that

• In Hydro: MsgExecute::TransferLockup will take 2 arguments: Recipient (address) and isSmartContract (boolean).
• In case isSmartContract === false then the transfer will just change the "owner" in LOCKS_MAP for those LockEntry.
• However, in case isSmartContract === false, then after changing the "owner", it will call a WasmMsg::Execute with a msg that would be defined by Hydro, which would include the lock_ids and the owner, and that any vote aggregator willing to receive transfers would need to implement.

For instance, it could look like:

TransferLockedTokens {
    lock_ids: Vec<u64>,
    owner: String,
},

let transfer_locked_tokens = TransferLockedTokens {
    lock_ids: hydro_lock_ids,
    owner: info.sender.into_string(),
};

let execute_transfer_locked_tokens = WasmMsg::Execute { 
    contract_addr: recipient.into_string(), 
    msg: to_json_binary(&transfer_locked_tokens)?, 
    funds: vec![],
};

Then, it's up to the receiving party (smart contract), typically a vote aggregator, to implement this message, and to take appropriate actions for their user.

If Hydro wanted, Hydro's frontend could just offer a basic transfer (from one address to another) to their users.

[p-offtermatt]

That sounds reasonable to me, great idea. Afaict this doesn't seem like it poses a security risk at all; at worst it might be that the outgoing call uses a lot of gas, but the Hydro contracts state should be impossible to corrupt through this.
I think we should probably error if the outgoing message gives an error (i.e. the vote aggregator rejects the transfer for some reason)