AIP 41: Delegated voting implementation (security)

[agriimony]

• by VladislavW Consolidated from #32

Summary

• Currently, stakers have to expose their wallet addresses when voting. This is not ideal for stakers who would like to use a cold wallet to store their staked AST.
• AirSwap should implement a delegate function in which a single wallet can appoint another wallet address to vote and claim rewards
• Delegation will be implemented on-to-one (i.e. each staked wallet can only have one delegate wallet and vice versa)

Specification

• A new delegate function should be created with the new Staking contract required for AIP 37.
• The delegate function should specify a wallet address which would act as the proxy for voting and claiming of rewards.
• The Activate interface would need to be updated to allow for a create delegate option when connecting with the staking wallet
• Any staking events performed by the delegate wallet (e.g. if claiming rewards as sAST as defined in AIP 18) should proceed via a stakeFor function for the original staking wallet address.
• Each staking wallet can only define a single delegate wallet. Likewise, each delegate wallet must be unique for each staking wallet (i.e. 2 staking addresses cannot define the same delegate wallet address)
• Any claiming events performed by the delegate wallet should proceed via a claimRewardFor function for the original staking wallet address.
• If ethereum address was set as Delegate, it should be unable to stake AST.
• Delegate could be set once and couldn't be changed.
• Delegate does not block any Staker functions (stake more, unstake, vote, claim).
• If Delegate has voted and/or claimed at current cycle, it is considered as Staked did it. Staker cannot vote and/or claim if Delegate already did it in one cycle and vice versa.

  Rationale

The main benefit is security. Long term AST holders may want to stake their AST and save them at a cold wallet but would not want to miss out on governance and rewards. It would be great to have the option to vote (and claim) from the dedicated address without revealing the staked address.

Copyright

Copyright and related rights waived via CC0.

[agriimony]

agrimony Jul 13

I think the main idea here is to allow for staking and voting from a cold wallet. Going to try and tidy up the language here. Summary

Currently, stakers have to expose their wallet addresses when voting. This is not ideal for stakers who would like to use a cold wallet to store their staked AST.
AirSwap should implement a delegate function in which a single wallet can appoint another wallet address to vote and claim rewards
Delegation will be implemented on-to-one (i.e. each staked wallet can only have one delegate wallet and vice versa)

Specification

A new delegate function should be created with the new Staking contract required for AIP 37 1.
The delegate function should specify a wallet address which would act as the proxy for voting and claiming of rewards.
The Activate interface would need to be updated to allow for a create delegate option when connecting with the staking wallet
Any staking events performed by the delegate wallet (e.g. if claiming rewards as sAST as defined in AIP 18) should proceed via a stakeFor function for the original staking wallet address.
Each staking wallet can only define a single delegate wallet. Likewise, each delegate wallet must be unique for each staking wallet (i.e. 2 staking addresses cannot define the same delegate wallet address)

Rationale

The main benefit is security. Long term AST holders may want to stake their AST and save them at a cold wallet but would not want to miss out on governance and rewards. It would be great to have the option to vote (and claim) from the dedicated address without revealing the staked address. Copyright

Copyright and related rights waived via CC0.

---

greypixel Jul 19

This makes sense, but could we clarify whether or not a delegate may also have their own sAST?

---

VladislavW Jul 19

To make it the most simple way to go, i think the staking function should be unavailable if address is already a delegate, to avoid collisions like rewards claiming to the stakers address at the expense of delegate staked AST. OR we can let it like it is. Delegate address sAST voting power and points could just be added to those which received from the staker address and send the total reward to staker address. What do you think? I like the second option because it is the simplest one (as i see it).