Sandbox DAO Case Study, Part 1: Built the System

This is the first of a three-part series on what I learned building, running, and winding down a $10M governance system.

In May 2024, The Sandbox DAO was an idea on paper. By March 2026, it was a fully operational governance system with thousands of members from more than 20 countries, 39 proposals funded, over 3 million SAND distributed, and 8,000 forum posts across 500 threads.

I was the one who built it, ran it, and ultimately helped formalize its pause. This is what I learned from the first phase: the eight months it took to design and launch.

Governance design is not a document

The design phase took eight months. That surprised people, including me at times. But governance design isn’t a document you write and sign off on. It’s a series of interconnected decisions where every choice has downstream consequences, and you don’t always see them until later.

The first piece was the constitution. How do community members propose ideas? How does voting work? How is voting power calculated? These aren’t abstract questions when real money is on the line. Every rule we wrote had to balance accessibility (anyone holding SAND or LAND could participate) with accountability (public funds needed oversight and structure). We went through multiple iterations, testing edge cases, debating trade-offs, before arriving at something we believed could hold up under pressure.

Alongside the constitution, we had to design the governance bodies. Who reviews proposals before they go to vote? Who oversees the treasury? Who represents the Foundation legally? This meant defining the admin team’s role, scoping a Special Council as an advisory body, and establishing how these groups related to each other and to the broader community. We also had to define a reporting cadence that would keep the community informed without drowning them in updates.

Building the infrastructure from scratch

Then came the operational infrastructure. We built a website from scratch, stood up a community forum on Discourse, integrated Snapshot for on-chain voting, DNS, ENS, analytics, and all the communication channels to keep thousands of members across more than 20 countries informed.

The treasury workflow was one of the most sensitive design challenges. We used Fireblocks for self-custody, which meant configuring and maintaining every transaction authorization policy ourselves: who can initiate a payment, who approves it, what thresholds trigger additional sign-offs. In a team this small, the temptation is to centralize everything for speed. But that creates exactly the kind of unchecked power that a DAO is supposed to prevent. So we designed the workflow with checks and balances built in, making sure that no single person, including me, could move funds without oversight. Xero handled accounting, Consola served as our sub-ledger to track every token movement, and Request Finance managed payments.

We also had to develop our own KYC and KYB policies from scratch. There was no off-the-shelf compliance framework for a Cayman Foundation running a decentralized grants program. We assessed providers, selected Shufti for identity verification and TRM for transaction monitoring, and wrote the policies that governed when and how we screened participants. Same with contract templates: every agreement between the DAO and a funded project had to be drafted, reviewed with lawyers, and standardized into a repeatable template that could handle different project types and jurisdictions.

The team and the legal wrapper

We had to assess and select a director to represent the Cayman Foundation, which serves as the DAO’s legal wrapper, protecting participants from personal liability. That meant interviewing candidates, understanding their appetite for risk, and making sure they were comfortable with the pace and ambiguity of a DAO environment. We went through two directors over the life of the DAO. We also established a working relationship with lawyers who understood both the Cayman regulatory environment and the realities of decentralized governance.

And I had to hire my own team. We ended up small and distributed: a project management team, an accountant, a treasurer, a community manager, spread across Italy, Spain, France, India, and California. Everything was lean and built on trust. There was no office, no shared timezone, no corporate infrastructure. We ran on Slack, Notion, and a shared commitment to making this work.

By the time we launched in May 2024, we had a complete operating system. But the real test was about to begin.

What I took away from this phase

Every governance project I’ve worked on since has confirmed what I learned during those eight months: you cannot rush the design phase. The pressure to “just launch” is constant, and every stakeholder wants to see something live. But every shortcut in design becomes a crisis in operations.

Every shortcut in design becomes a crisis in operations.

The time you invest in getting the constitution right, the treasury workflow right, the compliance stack right, that time pays for itself ten times over once the system is running and you’re too busy to redesign anything.

---

Next: Part 2, “Ran the System,” on what happens when the framework meets reality.