First of all, I’d like to thank everyone in this working group for your participation. I believe that the discussion we had during the call and the broad range of ideas presented here in this thread prove that this is a pressing issue that needs addressing and that the DAO as a collective can help brainstorm ideas to address it.
We apologize for the delays in our response and follow-up steps. We were waiting for the vision from AF that was just presented. We were informed about it even before the call, so we felt there was no point in rushing this working group further before its publication.
The issue at hand has two aspects - a technical one and a logistical one.
We believe the most pressing technical issues have mostly been resolved with the Token Registration Template. When we were helping the SuperBoring team register their token, we asked the OCL team to help prepare and validate the on-chain transaction so that we wouldn’t have to take on the work and risk associated with creating one. The result was an OCL script to create a payload for token registration that not only streamlines the process of creating an onchain proposal, but also enables any delegate to recreate the payload and confirm that the onchain transaction performs only the intended function. Of course, the process can be further streamlined by integrating the script with the Tally UI, as mentioned in the AFs post.
However, UI changes do not solve the logistical issues. Right now the whole process is pretty burdensome to delegates and projects that want to register their tokens.
Taking the Superboring proposal as an example, they first had to figure out how this process even works in the DAO. Arbitrum documentation does not explain it clearly. When they published their proposal on the forum there was instantly a discussion about it (supporting the proposal), but no immediate action followed as no one is really responsible to push it further. It took two months before I helped them with putting the proposal for Snapshot (huge shoutout to @CupOJoseph as he was the spiritus movens there), and I had to do my own due dilligence to assess whether this is an honest, justified ask and not something malicious. From this point it took another three weeks before we went onchain and after that another month before the vote was executed.
tl;dr - in total it took them 5 months from publishing the proposal on the forum to having the token registered. In my opinion it’s a terrible result for a small maintenance change that is necessary for a team to keep building on Arbitrum, but I understand that different people can have different benchmarks.
It’s worth noting that neither Arbitrum Foundation nor Offchain Labs engaged with Superboring proposal on the forum before being explicitly asked by me to help with the process. And even later on I felt like we’re forcing both teams to do something they really don’t want to be involved with. IMaybe it’s just my perception, but I think they’d agree that they weren’t really the ones taking the initiative to solve this issue, even though it was months after the New Vision for Arbitrum was posted on the forum.
All those issues won’t be solved by simple UI tricks, bundling similar proposals into one transaction or introducing calendar for such proposals (actually this would most likely even make the whole process lengthier for individual proposals). Validating and signing 10 similar, template-based transactions takes a couple of minutes at best. Going through the whole governance process to even have 10 transactions to sign - takes days. I believe that we’re focusing on optimizing wrong parts of the process in this discussion.
To make it clear, I don’t fully neglect the UI improvements proposed by Arbitrum Foundation. I fully agree with adding the token registration template to Tally’s UI interface. But I think that the other suggestions are not addressing the real issues at hand that I tried to briefly describe above and I’m not sure if their implementation is really worth the cost. How many times we’ll use that in the next two years? I guess it will make verifying the actual payload even more complex than it is right now. For me it’s not a huge difference between 1. signing three different transactions and 2. signing one transaction and ticking off in the UI which parts I support and which I don’t, in fact it might be even more complicated.
I would also like to comment on AFs stance regarding the proposed special council to handle such issues:
The former allows for greater security, but goes against the guiding principle of introducing a process capable of covering all currently uncontroversial proposals blocked by the constitutional process.
I’m not sure why we need universal process vs dedicated single-purpose processes that solve one issue well. The token registration template is an example of such a dedicated, narrowly focused tool that solves one particular issue well with a low cost. In my opinion this approach makes total sense.
The latter introduces new risks to the system and essentially implements a secondary Security Council, on-chain function-wise.
actually, we don’t need to introduce such a secondary Security Council, we already have a secondary Security Council (multisig that goes through simplified process that omits full DAO vote) since the DAO inception that was tasked to handle exact such issues in the DAO Constitution:
Non-Emergency Actions:
The Security Council may also approve and implement routine software upgrades, routine maintenance and other parameter adjustments in a non-emergency setting (such actions, “Non-Emergency Actions”), which require a 9-of-12 approval in order to take effect. Any Non-Emergency Action, after approval by the Security Council, will bypass Phases 1 to 3 of the AIP process and instead directly go through Phases 4 to 7 of the AIP process, to provide a delay before any Non-Emergency Action is deployed. The Security Council may optionally specify additional delays before deployment.
we even used it once to execute governance approved action to fix fee oversight in ArbOS 20. I find this argumentation even more surprising as I pointed that inconsistency with theory and practice in our DAO during the discussion on Security Council elections improvements and same Arbitrum Foundation commented in different place:
Right now, most upgrades go through the DAO as that is what gives an upgrade legitimacy. At some point, the Security Council may take a more proactive role, as outlined in the constitution, so it makes sense to preserve that optionality.
So to sum it up, Arbitrum Foundation is saying that it’s risky to introduce a secondary Security Council for maintenance updates even though we already have a secondary Security Council for maintenance updates but at the same time we don’t want to remove or clarify those maintenance update capabilities from this secondary Security Council because we foresee that at some point Security Council might actually use them proactively. I have to admit that I’m a bit lost in this logic.
One last thing - as I mentioned in the delegate chats already, we’ll be taking a more passive role in the DAO from now on, so I won’t be facilitating further calls for this Working Group. We encourage other delegates or AF to take the lead here if they see the value in discussing this further.