Like @JoJo , I was planning to publish my own SOS, but @maxlomu and @Entropy submissions captured the strategic goal I found to be a priority perfectly: Arbitrum DAO should be the go-to place for doing business with and in Arbitrum. That’s why I’m taking the opportunity Jojo opened by starting this discussion to share my two cents on the matter.
Something I liked and that really resonated with me is the following:
And I agree that the DAO’s approach to understanding and addressing builders’ needs has been suboptimal. Here’s how I see this potentially working, and the role the DAO can take on given its position and the context of defining its objectives:
We currently have a fragmented ecosystem comprising the DAO and the AAEs (before OpCO). There is no unified strategy for addressing problems and providing solutions to builders.
Builders go through a long journey from the moment they come up with an idea to deciding where to experiment and/or deploy. Throughout this process, they face different needs and concerns, which are often addressed—or attempts are made to address them—by the DAO, a Foundation program, or OCL’s business development efforts.
The good thing about having many programs and entities is that builders have plenty of opportunities to engage and secure funding to build on Arbitrum. The downside is that it has also created friction, inefficiencies, and sometimes confusion: uncertainty about who runs the different programs or initiatives, who is responsible for business development, and who oversees specific verticals within the Arbitrum ecosystem. Not to mention that there’s often an overlap between different initiatives or actions, which ends up leading to redundancy or inefficient allocation of resources.
Additionally, there’s often a lack of coordination between initiatives led by one entity -mainly the DAO through its multiple programs- and the operational capacity of others to support those initiatives. This leads to suboptimal initiatives by not making integrated use of the best available resources.
I appreciate how Entropy has outlined the distinct roles and responsibilities of the aligned entities:
Each aligned entity has a different mandate, objective, and set of capabilities. What has been lacking—and what this new structure of interrelation enables is better coordination of skills and initiatives, which will make it easier for external actors to navigate and onboard into the Arbitrum ecosystem.
That’s why I don’t just see the OpCo as a facilitator between the aligned entities and the delegates as Entropy describes — I see it as a bridge between the broader ecosystem and the DAO.
Effective and efficient coordination between these entities would make it significantly easier for builders to bring their products to Arbitrum. If the DAO, through the OpCo, can successfully coordinate the aligned entities in a way that allows them to communicate, learn, and address builders’ needs throughout the different stages of product development, the perception that Arbitrum is the place to build will grow immediately.
That’s why I thought of my objective as the Arbitrum DAO positioning itself, through coordination first and implementation second, as the place-to-go for builders in Web 3.
- I have an idea and would like some brainstorming or help to turn it into a product: the DAO can offer me a space and connections.
- Do I want to deploy? Arbitrum is the right choice, and the DAO will connect me with the right teams & OCL that can provide the necessary support.
- Do I need integrations? Arbitrum is the right choice, and the DAO will assist me with business development opportunities.
- Do I want to innovate? Arbitrum has the best teams, and through the DAO, I can get in touch with them.
- Am I already on Arbitrum? The DAO is here to support you with whatever you need. Above all, it’s here to help amplify your product, awareness, liquidity, and users.
These are just a few simple examples meant to illustrate the point: the DAO serves as an interface that connects all the teams and helps unify what often feels like a set of disconnected entities. Exactly what @JoJo says regarding allowing builders to enter and exit without friction at multiple stages of their development.
I know this kind of fragmentation was originally designed to ensure the DAO’s autonomy, but with the shift in intent around the other AAEs’ participation, I think the DAO should be the one to take ownership—especially since it already holds ownership over both the technology and the treasury—of that coordination and connection with builders. This could happen through the OpCo.
Why do I believe the OpCo is the right entity? Because it now includes through the OAT the participation of the two key players who are becoming more opinionated about what’s happening in the DAO: OCL and the Foundation.
Without this prior coordination, initiating effective, efficient, and frictionless support for builders from the DAO will not be possible. It will continue to consist of isolated initiatives rather than a comprehensive long-term program that adequately addresses the needs of projects at their various stages.
As a DAO, we don’t have, nor will we have, the necessary skills to implement an optimal program based on what the Arbitrum ecosystem can offer. However, through the OpCo, we can achieve the operational capacity to coordinate all the entities and deliver that optimal program.
Something like what tnorm describes as Operational Alignment:
The first step toward that coordination took place in last Friday’s call, where members from all five AAEs were present, and OCL and AF were able to express their new vision for the AAEs relationship. This new landscape of interrelation between AAEs brings many questions and challenges in implementation, which was reflected in the questions and back-and-forth discussions. It’s clear that not everything is defined, and it’s far from being settled.
I believe the DAO should lead, from the Opco, on Operational Alignment. By ensuring coordination and shared efforts, it can efficiently direct resources, identify builders’ needs, and provide sufficient support at all stages of development, as perfectly described by @maxlomu and @Entropy in their submissions, @tnorm in his approach to DeFi, and @JoJo with his contribution.