This DAO is archived. Data may be stale and governance actions are disabled. Want to reactivate this DAO? Contact support.
Delegating 1.7 ARB to:
Building some cool and I hope useful stuff at Jones DAO, helping Arbitrum through the advisor activity for protocols to let them get a grant and build even cooler stuff
Arbitrum Delegation Statement
Protocol
Grants Programs
Name: JoJo
Wallet Address or ENS: 0x4F685B29514eed0c9D929386E86D9cd81981118B / jojothecow.eth
What area are you most interested in contributing to? choose up to two tags:
- DeFi development on Arbitrum
- Tooling, Improving protocol decentralization

Please share your stance on overall goals for the DAO: The DAO is a powerful, chaotic entity with almost unlimited potential upside: it's the only entity able to gather talent from all over the world wanting to contribute to it in an industry, crypto, that has the highest growth speed so far. This means that inherently there is a need for delegates able to properly evaluate initiatives that are not only the best suited for this growth but also don't create tail risks for our ecosystem.
The main goals of the DAO should be to assess the best contributors, proposals, and programs, and leverage them. There is and will always be a high degree of experimentation. This is natural in a field where there is no playbook and decentralization is a key characteristic. Scaling success stories that favor the Arbitrum ecosystem growth against other L2s and bring value to ARB token holders is the main goal to which I want to commit.
Since I am a builder first, I firmly believe there has to be a higher representation of Arbitrum builders in the DAO. People working on native Arbitrum protocols likely have the highest alignment with our ecosystem and DAO.
Sample Voting Issue 1:
- Voting: I would vote For
- Amendments: As it is, the proposal doesn’t have enough checks and balances in case of malicious behavior by the service provider, Flipside in this case. The number of seats makes it easy for them to steer votes. An independent oversight entity, elected by the DAO, capable of reporting to the DAO any non-aligned behavior from the service provider with the ability of the DAO to create a vote to revoke Flipside's position, would mitigate risks. The oversight entity would need to periodically report to the DAO, specifically calling out behavior that might need more scrutiny. There could also be merit in introducing other checks and balances on the seats of the committee: since Flipside just needs another aligned vote to steer any decision, the ability to veto the candidacy of certain entities or remove them during the mandate in the above malicious case is also a good safety mechanism. Finally, a rotation of the elected parties, with the provision that they cannot be elected for more than two consecutive mandates, can help create a more diverse environment and set of stakeholders.
- Decentralisation vs Centralisation: In decentralized entities there is always, at some point, the need of "some" centralization to remove friction in certain tasks, and the above is a good example. We don't need to give up decentralization: subsidizing the task to a service provider/third party, with oversight from the DAO + elections of key members from the DAO is potentially a good way to implement and execute. Decentralization is still guaranteed by the ability to remove figures which would lead to a discussion and then either a new election or a partial/total amendment of the initiative in a dencetralized way. This means: decentralized decision process on assigning a mission, centralized execution, decentralized oversight.
Sample Voting Issue 2:
- Voting: I would vote Full Reimbursement
- Previous vote vs. Current vote: Overthrowing the result of a vote, especially a vote like this one, is a very dangerous precedent and should not be taken lightly at all. Besides, the moment there is a hack is the moment of maximum crisis among users and holders. Evaluating all possibilities in the most objective way and letting them vote on it is a “healthy” path, likely a path that could restore trust, for example, in a future restart of the protocol. Throwing that away with a second vote that tries to subvert the first achieves the opposite result. That said, some pitfalls were likely in the process that led to the first vote. Since the situation is so critical, all stakeholders need to clearly understand the options on the table, the outcomes for individual users, and for the protocol itself. Only then should they vote; any gut-feeling type of decision will only lead to poor, suboptimal execution. Finally, any reimbursement type of action should be fair toward affected users and, if possible, align these users with the protocol itself in case of continuation. Emissions of tokens that can just be dumped on top of other holders is the worst design. Reimbursement in stables/ETH is a good design but places a burden on the team. Reimbursement through preferential revenue sharing is a better design. This is obviously just an example to show how even a bad situation could potentially be resolved by aligning users to the protocol and creating an even better situation than before.
Languages I speak and write: English, Italian
Disclosure of Conflict(s) of Interest:
I am a full time contributor to Jones; beside that, I contribute part time or advise several others, both in Arbitrum and outside of it.
| Proposal | Votes for | Votes against | Voted? |
|---|---|---|---|
Executed Jun 8th, 2026 | 206.39M | 8.67M | For |
Executed May 11th, 2026 | 193.12M | 4.05K | For |
Executed Apr 20th, 2026 | 193.92M | 266.93K | For |
Executed Feb 23rd, 2026 | 247.89M | 362.6K | For |
Executed Dec 1st, 2025 | 263.67M | 16K | For |
| Proposal | Ballot |
|---|---|
For | |
For | |
For | |
For | |
For |
