Proposal: Not missing the AI train
Non-Constitutional
Context
This proposal is put forward by RnDAO as a critical need we have identified and not as a service provider bid. We don’t have a direct financial interest. As such, we invite the DAO to rally around this cause and offer not just feedback but also solutions and leadership.
Abstract
This proposal aims to make Arbitrum an ideal home for onchain AI Agents. We’ll set up an Agile team to identify, build, and communicate key enablers (developer tooling, documentation, and other resources as needed). This team can act as a key point of contact for AI builders, continuously identifying and rapidly delivering on what’s needed, thanks to continuous prioritisation and agile development (fast sprints).
Motivation
AI Agents are reshaping the internet as we know it. All kinds of interfaces, workflows, and processes are being disintermediated and a significant portion of the tools and ways of working we know will soon be replaced by swarms of AI agents coordinating. Said coordination can best be enabled onchain, and the race for where said coordination will happen is on. Blockchain ecosystems compete not only among themselves but also with Microsoft, OpenAI, etc.
If Arbitrum is going to have a chance, we need to act fast.
Approach
Speed should not be an excuse for doing things haphazardly and wasting money building the wrong thing. Onchain AI is a rapidly evolving space, and what’s needed will change frequently. A large program with many fixed milestones and detailed deliverables is likely to take a long time to negotiate and ultimately miss the mark as the landscape changes. So instead of committing upfront to a large build (waterfall approach), we’re proposing to set up a team that can work on fast sprints, experiment, and iterate (Agile approach).
To compensate for the lack of upfront visibility, we’re also proposing an oversight structure to ensure the team performs and remains Arbitrum-aligned.
We already have fund deployment systems like Questbook track for dev tooling. However, this system relies on builders proposing to create their own infra instead of building a project. And although service providers cover some gaps, there’s no systematic way to gather insights about what’s most needed. Also, the Questbook system is not currently creating RFPs and as such has to wait for proposals by 3rd parties. As such, this program is designed to work together with Questbook track managers (especially Dev Tooling but also making warm introductions to other tracks and Arbitrum entities as needed).
In essence, we’re proposing a public interface for AI builders where we’ll have the team at hand to deliver what’s needed and coordinate with other entities to avoid duplication of efforts and still mobilise all the resources at hand effectively.
Specifications
The base structure is that of a delivery team, a multisig for small expenses, and the MSS directly paying contributors and replenishing the expenses multisig as needed.
Team composition:
The exact mix of team members is not fixed, but rather used to provide a starting point for the initiative. The Program Manager will make hiring decisions and can restructure the team as needed.
- Program Manager: in charge of managing the initiative, ensuring the team is functioning and has the right people involved and processes in place. In charge of alignment with other Arbitrum programs and organisations and reporting to the DAO. Also, get their hands dirty as needed.
- Comms and Community Manager (DevRel): the first point of contact for AI builders. In charge of writing documentation, engaging with AI builders, promoting the program in coordinating with the AF, and making introductions for builders to other Arbitrum programs/stakeholders.
- Technical Lead: scopes technical tasks and RFPs (to be funded internally or in coordination with Questbook track), oversees the delivery of dev tooling and technical infra needed. Also gets their hands dirty.
- Additional team members: selected by the Program Manager (Expected 1-2 devs to support technical lead).
The program manager is elected via a DAO vote (snapshot vote with majority) and can be replaced via the same mechanism.
Expenses Multisig
With the Program manager, technical lead and DevRel as signers (⅔). The multisig is meant to reimburse small expenses such as SaaS subscriptions or conference travel if needed but can also be used for additional costs such as design and other unplanned needs.
Reporting and KPIs
Reporting requirement for the program manager to the DAO:
- Disclose a detailed expense breakdown monthly
- Maintain an up-to-date (updated at least bi-weekly) public kanban with work items undertaken by the team.
- Monthly progress report, including achievements, challenges identifies, and priorities.
- Make themselves available to answer delegates’ questions
KPIs:
- TBD: which ones do you think it should have?
What will the team work on?
There’s A LOT of work to do, but as a starting point this is a good inspiration: https://www.coinbase.com/en-gb/developer-platform/discover/launches/introducing-agentkit
Budget
500k USD
Funds Management
- The Arbiturm Foundation will receive the funds, convert to stables and send to the MSS. Any remaining Arb will be returned to the DAO.
- Monthly payments to contributors are paid directly by the MSS.
- Expenses multisig top up with up to $10k per month.
Steps to Implement
Rough timeline: with parallel election and onchain vote to accelerate the launch and avoid missing the AI train
-
Proposal to gather sentiment and complete the team Feb 7 - 21
-
Snapshot for sentiment check Feb 21-28
-
Election: candidate submissions for program manager: March 3rd to 9th
Program Manager candidates are encouraged but not required to disclose their team (DevRel and Tech Lead) -
Election: candidate election vote: March 10 -17th
-
Onchain Vote: March 3rd to 25th
-
Contracting: March 26th to April 12th
-
Program kick-off: April 13th