Thanks to a grant by dYdX grants we developed a report on how delegates could move to v4 from v3.
The main sticking point is that IBC chains do not traditionally have delegates or other governance-focused roles but rely on validators to do the governance work.
Separating validator operations from governance research and participation would make a lot of sense from an operational PoV and a decentralization angle.
We recommend that v4 implement authz, so that delegates can use an established approach to delegating voting power.
Hello Rafael. Excellently written report on the situation with governance in the Cosmos ecosystem. I read it with great interest.
Unfortunately, there is no ideal system for transferring the current voting system to space. If we currently have a relationship between Delegator and Delegate, now a Validator is added. A token holder may want to stake to one validator but trust the voting opinion of a delegate who does not work with that validator. And triangular relationships usually do not lead to good outcomes :). Of course, the problem would be solved if a validator could delegate only a portion of his stake for voting to a specific delegate.
Btw @antonio stated that the team wont get any profits from V4 but they have a substantial number of tokens which can be used for the network security
Which leads me to the conclusion that the best outcome is some combination of the 6.1 Delegates run validators, if they can and 6.2 Foundation paying delegates. So it might be not a direct payment from foundation but a delegation of the stack which will be enough to cover the costs for the delegate to use third party provider like Flipside assisting in runing a validator. That validator should charge a competitive commission so other token holders who are interested in active governance can delegate to this validator
Basically dydx team stack can bootstrap a big number of independent validators which are active in the governance. Of course all the costs should be calculated and possibility of such scenario depends from the fees generate by protocol
The triangular relationship has its challenges, I totally agree.
Wrt the Foundation bootstrapping delegates: I think this could be a good way forward, but has some centralization issues. Wouldn’t it be perceived as all delegates being in the pocket of the Foundation to some extent?
Thanks, @rspa and the whole Flipside team for the research. Not only the coverage of the main topic on continuing the endorsed delegate system, but also the context and knowledge sharing of dYdX v4 in the Cosmos world are impressive. We truly appreciate your work.
Regarding the potential options we can pursue, mentioned in the section 6, while 6.1 Delegates running validators might be a way to go for some delegates, either themselves running their own validators or using the matching service, or 6.5 Delegates as governance research pods is an interesting add-on to the DAO operations, we also believe that implementing authz as suggested in 6.6 Separating strategy and execution. Enter x/authz will be the best option to take for the mid-long term prosperity of the dYdX protocol and community/DAO as Flipside suggested.
The key question is; who will implement the additional module on top of the currently-being-developed v4 stack? Likely dYdX Trading according to their priority and capacity, but can the community consider this as an opportunity for a grantee to take to contribute to the protocol development itself as the DAO manages the protocol beyond v4? We’d love to hear opinions from other community members.
Encourage everyone to check page 21/section 6.6 of what the suggested solution is by the flipside team. As someone that is mostly on the cosmos ecosystem and have seen the drawbacks of giving all voting decisions to validators, I think the idea of separating the governance function from the validator function is the best path forward. Happy to talk with anyone on the pros/cons of this.
who will implement the additional module on top of the currently-being-developed v4 stack?
To answer this specifically, the AuthZ module is already implemented and works with the several latest versions of the cosmos sdk. The development would have to be in the interface to delegate the voting power, if there was a need for a custom development of AuthZ then yeah, it would take some additional development work that could be tackled through a grant.
Here is a video of a cosmos dev explaining AuthZ for anyone that wants to learn more.
This blog post published by dYdX Trading specifically mentioned that the Authz module has been one of exceptions for the initial v4 implementation as described below:
The dYdX Chain software will utilize the standard Cosmos SDK modules listed in the official documentation, with the exception of Authz, Evidence, Feegrant, Mint, NFT, Circuit, and Genutil modules.
However, if it’s been already implemented, great news! And yes, it would be an additional challenge to craft and promote the interface for validators to delegate their staked tokens to the “delegates”.
I missed that, my bad. Yeah, the module would have to be included, module itself already exists so dev team would have to share why it isn’t included.
We believe a governance council should filter proposals before validators vote. We have ideas about this and would like to discuss. Please contact kagan@cipherlabs.xyz.
We’d really love to know more about why authz will not be included in the implementation. It’s de-facto standard across the IBC landscape. We’ve used it on various chains to vote on behalf of validators.
The UI is not pretty, but workable. A small-ish grant could help solve the user interface challenge quite well, we think.
