Entrypoint for receiving staking rewards

[dorranh]

While working on the design for #213, I noticed what might be an issue. We currently support delegation of burrow contracts, allowing users to specify a delegate in their call to create_burrow or set_delegate. The delegation works as expected, allowing a Checker user to delegate their collateral. However, I'm not sure that we have a correct way of receiving delegation rewards from a baker. The burrow contract itself (defined here) is restricted to only accept calls from the main Checker contract, and does not support the kind of transaction that tools like tezos-reward-distributor would use to transfer rewards to the delegator burrow. If it did support these kinds of transactions, we would also need to take care that the transactions are recorded in the state somewhere to avoid underestimating the burrow's collateral. Any thoughts?

cc @utdemir, @gkaracha

[utdemir]

I think the delegation is transitive; so, I think it should be possible to set the checkers delegation to another contract, which itself has a baker as the delegate and collect the rewards. If my assumptions are correct, we might not need to change our contract(s).

[dorranh]

Thanks for the info, @utdemir, that has also been my working assumption so far. I couldn't find any info on this online, so I went ahead and tested this out.

I created three implicit (tz) accounts on a local flextesa sandbox using the faucet:

• account1
• account2
• account3

I registered account2 and account3 as delegates. Then, I attempted to set account2 as the delegate for account1. This operation succeeds as expected. However, when I try to set account3 as the delegate for account2 I get a proto.010-PtGRANAD.delegate.no_deletion error. It seems that this is expected behavior, with the answer here indicating that you can't set a delegate for an account registered as a baker. I think this means that the delegation logic we have at the moment is a bit lacking since delegated burrows won't be able to actually receive their baking rewards 🙁. It shouldn't be a huge deal adding an entrypoint for this, but it might mean that we also need to expand our burrow logic slightly to ensure that our collateral state stays up to date.

[gkaracha]

Nice find @dorranh! 👌 The least intrusive way I can see to address this omission is to have a default entrypoint for burrow contracts, that just wires the tez directly to the burrow owner. I am not sure if having an entrypoint with a unit type is a good idea (especially considering #18 (comment)) though. I am also thinking that this whole issue might be shifted elsewhere, if we proceed with #213.

[dorranh]

It looks like ctez is using a whitelist of authorized depositors to address this. Adding similar logic to wtez could be a potential solution for this issue.

[gkaracha]

Deprioritizing this one for now.

[gkaracha]

I guess adopting the whitelist of authorized depositors is not trivial, since the tez wrapper's vaults need to be able to receive tez from other vaults as well. Informing all vaults whenever a new vault is created (so that it can be whitelisted) would take linear time so that's not an option. We could instead ask the tez wrapper directly, but that would cost in gas and complications. I am thinking that online views would probably simplify this problem a lot.

Either way, deprioritizing this one for now, assuming that users can always come to an agreement with delegates directly.