It’s been an exciting start of 2022 for DXgov and as always seems to be the case, so much has changed since the start of the year. The majority of work has been focused on guilds so that we can give the swapr token, protocol and community the governance it deserves. The main goals and milestones for the team have not changed drastically but a few important parts of the plan have changed a little so we’ll cover those here and what the next few months should look like.
Process
We have been making a lot of process improvements in DXgov and I think its one of the areas we have really improved most in and has been a great effort from the entire team. We have been having more technical discussions, more mob programming sessions, as well as better, documenting what we are working on. However, it hasn’t been super transparent from the outside mostly because the main work we have been doing has not been on a production application. However that will be changing, we will be making these posts and write-ups more publically available as well as of course launching into production soon.
Audits
We have two ongoing audits for guilds being done by Sigma prime and the DXdao governance contracts being down by Omega team. Once these are complete and determined secure enough they will be used far more publically.
Legacy vs New
We recently solidified some of the plans around our governance applications being built and maintained by DXgov. We have both the responsibility of ensuring DXdao governance is kept secure, accessible and resilient as well as building the next stage of governance for DXdao and the ecosystem as a whole. But splitting the team and concentration across both is challenging.
The original goal of DXvote was to replace alchemy as our main way of governing due to reliance at the time on subgraph which was unstable but more importantly on having an interface we actually owned, not relying on DAOstack.
When DXgov started out of Augusto’s own work, the goal was very much to improve DXvote into an application everyone could use. But it became apparent relatively quickly that there were some issues that made this difficult. The dependency on supporting what we considered legacy contracts (what DXdao currently uses now) slowed down and greatly complicated any efforts we made. The whole strategy was to do both efforts at the same time which was mirrored with our deployment plans of adding our new schemes then one day switching over to the new architecture.
Instead what we plan to do now is to split legacy and new. With the development of guilds came the realisation that we should really just take the opportunity to renew the entire application since the UX was getting a complete redo anyways. With this we are improving processes, planning decisions as a team, using proper localhost environments, unit, QA and integration testing and making lots of changes under the hood too.
The goal even from the start of guilds’ design was to have DXvote later use the UI but now it will be completely a part of the new application.
The decision was also made, on the suggestion of John, to deploy in parallel. So instead of changing the engine of the car as it is driving down a road, we are instead building another car to run alongside and then make the switch when we are confident it can secure the treasury.
So that defines our goals, how do we get there? A lot of complexity comes from supporting the myriad of schemes that all work differently, so from the start of the new application, we will only be supporting the new contract architecture and wallet schemes that are currently in the final stages of the audit. This should allow us to build a much more efficient and better application in the long run.
So what happens to the existing DAO if only wallet schemes are on the new application? We explored a little the idea again of running alchemy ourselves since the biggest risk now is the servers and site going down since we don’t own it. But I think it’s unlikely we will go down that path. I actually learned that the first DXvote was an alchemy fork (alchlembly) but it was abandoned due to the complexity and additional effort of running a server. So we can continue using it as a backup but not one we can rely on. The only option we have is ensuring DXvote runs as smoothly as possible. Obviously not easy but there are a few things we can do here. A lot of issues stem from DXvote’s reliance on RPCs and free ones at that, so we are going to get an enterprise RPC that should be far more stable and reliable (The new application will try to avoid this as pokt is what we want to be using long term). We can also strip out a lot of unused schemes that should be deprecated in DXdao as we no longer use a lot of them, this will help us go through DXvote and strip out complexity hopefully making it more maintainable. There is some additional work we are going to put into monitoring also to further strengthen the security of mainnet. The goal with all of this is to get the maximum security possible, especially on mainnet, with as little effort as possible.
So we will make the changes needed in DXvote and then freeze development except for bug fixes. Given everything goes smoothly with the new contracts and application we can move arbitrum over immediately and hopefully gnosis chain shortly after testing in parallel to the existing DAO. The goal of DXvote legacy will be to have just mainnet operating as securely as possible.
Eventually, we will, of course, deploy a parallel DAO in mainnet but it will take a long time before we move everything over and transfer the avatar.
You’ve likely also noticed I’ve been saying “new application” over and over, so we need a codename as we begin work on actual branding. Suggestions are welcome.
Brief diagram showing application split and responsibilities & features
Roadmap
The roadmap remains relatively similar with some more details ironed out. Of course, the end goal of DXgov still remains gov 2.0 which we are always thinking about. The planned upgrade and parallel deployment will be a huge step and great practice towards actually moving to 2.0. Steps such as a DXDguild will also provide some initial crossing over and power to DXD holders. Currently, we are getting ready to complete the first section just awaiting audits and have already started working on the second section’s deliverables.
The team
The team is another place where a lot of changes have occurred. It’s taken some challenges getting but the current contributors to DXgov with active worker proposals are all amazing developers and I am glad to have all of them on board to build an awesome governance application and system.
More reading
We have bi-weekly retrospectives as well as bi-weekly technical discussions which all have summaries posted to notion as well as GitHub discussions. We’ll also try to tweet out updates more often.
https://rossneilson.notion.site/DXgov-c1655a56255b4ad78d05162c634b0634
https://github.com/DXgovernance/dxvote/discussions
A few more technical articles you might enjoy:
Decoding call data: https://github.com/DXgovernance/dxvote/discussions/715
Forum: https://github.com/DXgovernance/dxvote/discussions/698
Refactor session summary: https://github.com/DXgovernance/dxvote/discussions/845
Cache refactor discussion: https://github.com/DXgovernance/dxvote/discussions/877
I’m also super excited to get the new application into everyone’s hands for feedback and testing.
In the meantime here is a quick bit of documentation of what I think is one of our most exciting and novel features that should be a huge impact to DAO accessibility and UX.
Proposal action builder docs