Why Arbitrum Governance Resembles Italian Politics
A tale of decentralized governance, how it works in practice, and what can be improved
The Arbitrum community is voting on over 100 projects applying to the Arbitrum Short-Term Incentives Program (STIP).
This program is a grant initiative to incentivize development on Arbitrum, aside from “private” grants issued by the Arbitrum Foundation.
It is arguably the biggest decentralized governance exercise taking place on an L2 (and perhaps on a blockchain network). As such:
It’s interesting to observe whether the Decentralized dynamics lead to participation and transparency
There’s a lot of room to improve
This is mostly going to be an opinion piece, for this reason, any view expressed here is mine only and does not reflect Castle in any way.
Let’s start from the basics.
The Arbitrum STIP
Arbitrum or Optimism? On which L2 should I build?
This is what many newly launched projects have been wondering about lately.
While there’s no clear answer, we have seen several elements of differentiation between Arbitrum and OP:
Notably the OP RetroFunding Program has retroactively distributed a % of OP supply to builders who have contributed to Optimism;
The OP team has focused much more on Business Development: we have seen how several big brands names (Coinbase, Binance) have launched their L2 on Optimism rather than Arbitrum;
While many have criticized OP for their lack of fraud-proof, they have struck a balance between tech and BD whereby they have been mostly focused on attracting and retaining projects, making sure to compensate them for the work they do on Optimism;
As an L2 attracting projects often requires incentivizing them to build on your protocol. We have seen how Arbitrum has been fairly slow concerning its strategy, with many criticizing their approach as similar to Web2 (licensing its tech, being slow in distributing incentives)
For instance, we have seen such a bigger focus be placed on developing tech (Stylus, BOLD), with less practical incentives to stimulate builders.
Notably, the first proposal by the Arbitrum DAO for “special grants” on Arbitrum was voted down by over 75% of participants. The vote was supposed to allocate grants without a governance vote, to avoid “inundating governance with grants applications”. However, the DAO voted down as they wanted a say in funding decisions.
What’s the point of decentralized governance if we don’t use it?
To sum up and contextualize the series of events leading to the STIP:
Optimism continues getting incredible traction and its stack is widely adopted;
Arbitrum is slugging behind and is somewhat forced to act;
For this reason, the STIP was launched as somewhat of a “last resort”.
In fact, to a certain extent, the STIP was a bit of a rushed proposal: this appears obvious in the time of the proposal, and the relatively short time frame of implementation.
For this reason, I believe we have to be very pragmatic when discussing the process itself and its effectiveness.
“Sure it’s not the best way to move forward, but at least we get the ball rolling”
(cit. probably someone within the Arbitrum Foundation).
Ideally, sure, there are so many improvements that we can gather from the way things have been moving - but still, this is a fundamental first step in the right direction and one of the biggest exercises of decentralized governance: where all of the governance assumptions will be tested, improved, and iterated for the next governance votes.
Let’s not forget that the Arbitrum Treasury has over $3b in assets waiting to be deployed, and the 50m ARB involved in the STIP program is but a very small %.
As such, I believe this voting exercise will be used as a blueprint to analyze areas for improvements and continue making decentralized governance better.
The Proposals
In a week, over 100 projects posted their proposals for grants.
Cumulatively, they ended up asking over double the amount of grants available
(over 100m ARB).
This raises the question: what is the right way to analyze the proposals?
This puts every delegate in a difficult situation. Are you going to give priority to established projects that have contributed a lot to Arbitrum? Are you going to prioritize smaller and more innovative projects, although they have yet to prove their loyalty and contributions to the ecosystem?
Given the lack of an established framework, individual delegates had to create their own, at least establishing the key principles they would follow during the voting process.
This is the internal framework we used at Castle to define the governing values for the STIP:
Prioritise Arbitrum Native Protocols: Preference over teams that have a commitment to the chain and its stability and longevity, and have demonstrated that over an extended period.
Ecosystem-wide Incentive Goals: Granted ARB should trigger a wave of ecosystem benefits to Arbitrum, amplifying impact across the chain.
Innovation First: Favour teams building unique and innovative products in the L2 space. This is the driving force of crypto and should be continually incentivized to create new products not yet imagined.
Collaboration over Competition: Innovation can be accelerated massively due to crypto's open and permissionless nature, creating a vast ecosystem of interconnected products.
Robustly Effective Protocol: Prioritize teams and products that have proved effective, having found a strong product-market fit (PMF), whether on Arbitrum or not.
Among those, the main differentiating factor is ultimately the way these projects will end up using the incentives: are they going to be used to develop their products or will they be used with a broader scope that also benefits the wider ecosystem?
Unfortunately, we have still seen a lot of projects leveraging the STIP to ask for funds to launch their products or bootstrap their liquidity and ecosystem.
The STIP grants don’t have to be identified as subsidies, but rather as investments by the Arbitrum Foundation within the ecosystem.
Based on this framework, we analyzed and commented on over 40 proposals:
This was only possible due to an amazing turnout from our analysts and also raises a follow-up question: how do we expect every delegate to be able to thoroughly analyze all these proposals?
We had a big team and went through about 50% of them.
Perhaps bigger delegates will have a team behind which might help them - but what about smaller and individual delegates?
Surely the short timeframe and the amount of proposals have impacted this phase of the STIP and required great time and effort from the delegates.
Nonetheless, this is also a primary reason why we have expressed our comments: to incentivize openness and transparency while also publicly sharing our intentions and opinions on the vote, for the benefit of the Arbitrum ecosystem.
We are also extremely surprised by the feedback we have received and by the fact that many (15/50) have acknowledged our comments and made changes.
This is the spirit of decentralized governance, and we believe projects that listen more carefully showcase their broader alignment with the community.
It is my opinion that perhaps this phase should have seen more participation from bigger delegates: at the same time, it’s understandable that the efforts required were incredible and also that perhaps they didn’t want to show their cards too early.
The Voting Phase
For a proposal to be considered valid, it requires a minimum quorum of 71.5m ARB.
The voting phase is currently open and will last a week, with delegates being able to vote until the 13th of October.
While it might not seem like much, the quorum is a deciding factor in this voting procedure. Every project that asked for a grant has been counting its votes and has started lobbying delegates to get their favor.
The fact that most bigger delegates haven’t expressed their preferences meant that most projects (aside from the big ones) didn’t have a precise idea whether they’d reach the quorum or not.
This meant that for this week Arbitrum governance became very similar to Italian politics: DMs, bribes, and favors.
They probably made them an offer they can’t refuse. You help me, I help you.
This is also true for builders, who have spent most of this period looking to strike new deals and ensure the necessary votes.
Every big delegate has received many DMs from projects asking for votes and offering favors and bribes.
Especially those with more ARB delegates are in a position of favor: they can leverage their voting power to “bribe” others to vote for them in exchange for their vote.
Is this really how we imagine decentralized governance?
This system penalizes smaller protocols with fewer connections, which might struggle in this lobbying process.
Also, how do we make sure to align interests between participants to avoid a situation where everyone is casting votes for their friends and against their enemies, without looking at the merit of the proposals?
Without considering the increased reliance of the process on the bigger delegates. Even a handful of them could completely change the way the vote goes.
However, bigger delegates are probably the most elusive players, with some of them preferring not to vote rather than abstain or vote negatively, as this can impact their delegations.
They don’t want to expose themselves too much and perhaps they’d vote at the end, but at the same time they HAVE to vote and fulfill their duties, or they’ll see their delegation move towards more active participants.
Nonetheless aside from a few cases we’ve rarely seen delegates voting negatively. The argument can be made that voting is currently separated into different blocks, where delegates are voting based on projects they know and have relationships with - which may also be due to time constraints in analyzing all the requests.
Voting against means that you’ll have to justify your vote: but what if it’s just a matter of not knowing enough about the projects?
We have already seen how the contribution of smaller projects can put pressure on those big delegates: are they the ones you want to delegate to? Or would you prefer a somewhat smaller entity that has the energy and time to act as a steward of the ecosystem?
On the bright side, we have seen delegates creating communication channels to get ahold of other delegates, contributing to a broader discussion and coordination among them.
This is by all means positive and is already creating more entangled relationships across the ecosystem: to a certain extent, projects are forced to choose cooperation over competition.
Furthermore, I have seen many delegates opening up their calendar and organizing pitching sessions to get a deeper understanding of some proposals.
That is amazing indeed - although very impractical at scale.
Conclusion
Arbitrum governance is not static and has to be considered a work in progress.
The STIP is the first time that voting has occurred on such a big scale, and in many ways a guinea pig to further improve the process for the future.
As such, it’s normal to expect hick-ups.
The current process has shown how complex the incentives driving votes are and how difficult it is to align.
The large quorum as well as the reliance on votes from other protocols makes it harder for smaller protocols to compete with well-established ones.
Currently, 44 protocols (about 45%) out of 97 reached quorum - with 58m (or about 115%) of the total grant disbursed.
If the 50m ARB grant is filled, those who have more votes in favor will receive the grant on a first-come-first-serve basis.
Within this process, perhaps it arises the need for a more structured framework behind governance. Others such as Optimism have a dedicated council to grants. While this might not have to be the same for Arbitrum, a dedicated council would provide ad-hoc resources focused on making sure governance proceeds effectively and within the delineated framework, to make sure to maximize the impact on the ecosystem.
Nonetheless, this exercise has overall been very positive concerning:
The involvement of the broader community (anyone can comment on the proposals)
The fact that many projects have taken the feedback provided and have made changes based on that
The increased coordination between delegates and protocols within the ecosystem
The overall accountability of delegates towards other delegates, and the community towards protocols requesting grants
Higher transparency compared to other grant allocation processes
What will the future of Arbitrum governance look like?
As the process will increasingly diversify in different niches, it is hard to envision having delegates well-versed in all of them.
Perhaps the establishment of sub-committees or a council will be a viable way?
This design has trade-offs, using MakerDAO as an example we can see how sub-committees can make governance more complex and harder to follow for the community, as well as representing a financial burden and a fragmentation of interest alignment within the protocol.
I hope that the voting procedure for Arbitrum will be iterated after the STIP, to make the process easier on delegates and protocols altogether, as well as reduce frictions and mechanisms that resemble Web2 politics.
enjoyed the read!