-
Notifications
You must be signed in to change notification settings - Fork 31
Delegation Proxy #20
Comments
Interesting idea. A couple of questions:
Understanding the user benefit and examples of how this fits into our product suite would be super helpful! |
Delegation Proxy would be used as an auxilary token. Anyone would be able to set their "proxy". This Delegation Proxy would be used in a tabulation, for several purposes. The design of Delegation Proxy is working well for offchain calls or inchain calls with small delegate chains, however inchain it is limited by gas block limit, and right now a too big delegate would break a inchain tabulation because a too long stack. Some examples of uses for the Delegation Proxy are the Token Curated Token Registry, a InterDAO watchdog for emergency stop dapps, any voting that needs to be less burocratic. |
While the research for a dynamic DelegateProxy system happens, a simplier should be used to ensure that will not break tabulation due gas restrictions. |
Closing this as its gone stale. Feel free to re-open if its still relevant or if there is someone working on it. |
Preamble
Summary
Delegation Proxy provides ability to set other account (some Delegate, any other address) to take influence on behalf of self.
Vision
"Having the promise of blockchain be trustless trust and be decentralized, how decentralized the system is in future when, currently, it might change it, only 5 to 30 people in this whole network really understands the ins and outs of such a great discussion. (...) when we need to take action at this moment we need to trust the experts."
Blockchain's Problems with Unknown Unknowns - Shermin Voshmgir
Delegation Proxy enables to set which expert you trust (can be none but yourself). There should be a root delegation proxy level, and for each expertize field there should be a specialized delegation proxy, which in case of unset for a determined account would lookup at parent proxy.
PoC
A specific topic for #18 can be used to improve reach of quorum in Token Registry consensus.
Swarm Participants
Requirements
Goals & Implementation Plan
Minimum Viable Product
Goal Date:
Description:
Iteration 1..N
Goal Date:
Description:
Supporting Role Communication
Post-Mortem
Copyright
Copyright and related rights waived via CC0.
The text was updated successfully, but these errors were encountered: