Voting Proxy

[Freydal]

Background

Currently, accounts within the contract system are affiliated with single owner address. This means one address controls deposits, withdrawals, listing management, and voting. This presents a challenge for large stakeholders who wish to leverage their large holdings to participate in votes, as they would be required to have their funds controlled with a hot-wallet that frequently interacts with the contract system.

Proposal overview

This proposal suggests the addition of voterProxy addresses (name yet to be finalized) which may be arbitrary addresses authorized (and de-authorized) on behalf of an account owner to commit and reveal votes on their behalf, leveraging their holdings.

The designated voterProxy addresses for a given account may only be used to commit and reveal votes on behalf of the owner. They may not take action that moves funds (withdrawals, new listings, new challenges, etc.). The owner can authorize and de-authorize these addresses at will.

Specification

Contract system

• Voting
  • New Functions
    • commitProxyVote: Different entry point capitalizing on existing commitVote implementation providing the address being proxied
    • revealProxyVote: Different entry point capitalizing on existing revealVote implementation providing the address being proxied
• Treasury
  • Storage
    • Merge address mappings into a struct (validate gas)
    • Adding address => boolean for votingProxies
  • New Functions
    • registerProxyVote: Different entry point capitalizing on existing registerVote implementation providing the address being proxied.
    • authorizeProxy: Allow provided address to proxy votes
    • deauthorizeProxy: Disallow provided address from proxy votes.
    • isProxyFor: Check the proxy status ( mostly for reveal transaction)

Network client

No changes to network client needed for this PR.

Considerations

[hrharder]

Looking great -- not sure you wanted to merge yet, but will approve in case you do.