DAO mistakes: First-Hand Lessons from Panda DAO

A lot of things can be learned from studying failure; their mistakes helped us understand how to navigate the murky water of coordinating a team, finding product-market fit, and running decentralized organizations. It is obviously a pity that good-natured, well-intentioned projects failed. But by studying their failures, we make sure that their death is not in vain. This article serves as a guide to help aspiring DAO leaders find their path to success.

On September 24th, PandaDAO (@hellopandadao) made an announcement they will

• Burn all $PANDA owned by treasury & the 50 million $PANDA tokens owned by the core team

• Remove $PANDA from the Uniswap liquidity pool and transfer all $PANDA to the Eater Address, while the rest of $ETH will be refunded

• They estimate to refund $500-700 million in total to members

• After the refund, they will unregister and delete Discord server and all official social accounts.

PandaDAO started as a DAO tooling research & development group, with the intention of making decentralized work easier, reducing the control centralized organizations have.

They raised over 1900 ETH on crowdfunding platform Juicebox, and the treasury was owned by the community since its inception. Token holders get 100% control over treasury spending. And that is where the problem begins.

Source

In summary, the core team declared that they spent "too much time in governance, too little time in development, too many voices in price. Too tired and refund it all"

Some community members want more governance power, others want Panda to become a VC, and some want an instant messaging product.

It's easy to ask 100 people to tear down a building, but to ask them to build one it's 100x harder. –Balaji Srinivasan

Startups are so difficult because founders often have so many investors and customers pulling them in different, sometimes opposing directions. Leaders don't know which metrics to track and focus on. Worse, spending too much time on the wrong direction can lead to the project’s death.

How to determine priorities? Geoff Ralston, partner at Y Combinator offered this advice to founders:

First build the features that affect lots of users as profoundly as possible, and which you can build quickly and cheaply.

In a DAO’s early days, it is crucial to understand how engaged users are with your offering. Find out the most important features– the ones that are indispensable to your users, the ones they really love– and iterate on that quickly.

2) Letting governance hijacks the product:

The Panda team complained that they spent 80~90% of time on solving community requests for Claim, Refund, Buyback contracts etc, which eats away the time and energy for developing products.

Sometimes you need to fire your members. They might be killing you. Michael Seibel, co-founder of Justin.tv/Twich emphasisized discarding “users you don’t want” in his blog post.

Their needs present an entirely new set of problems, problems that could be solved by a startup but not necessarily by ours. Remember you don’t have to pivot your business because a customer needs something that you don’t offer.

If you let anyone that joins the discord steer the product roadmap you’re going to end up doing a poor job at half-solving a lot of problems.

This brings up the question of can highly decentralized DAOs ever work?

Elad Verbin, partner at Lunar VC, argued that “DAOs & Token-based Governance is a fantasy.”

Source

His claim that DAO should more resemble traditional corporation is very thought-provoking. I agree that many crypto projects have dysfunctional management practice.

DAOs today already do have executives. They're just self-appointed, unofficial, de-facto executives, but no duty of fairness, nor checks & balances, nor the right to officially represent the org. Today's DAOs are not free of executives, they just have dysfunctional executives.

How can newer generations of DAOs remain decentralized while avoiding the pitfall of governance hijacks?

To this, Vitalik gives us a practical framework on deciding between centralized & decentralized power.

When decisions are convex, decentralizing the process of making that decision can easily lead to confusion and low-quality compromises. When decisions are concave, on the other hand, relying on the wisdom of the crowds can give better answers. –Vitalik Buterin

Examples of a compromise (concave): public good funding, judicial decisions, tax rates.

Examples of a conflip (convex): pandemic response, military strategy, technologies choices in crypto protocols.

Vitalik predicted that we will likely have a small group of DAOs that functions like the former, while the rest will be in the second category.

If the outcome is concave, choose decentralized power and gather the wisdom of the crowd. If it’s convex, choose centralized power; let the executive pick an option and stick to it.

• Gather large amounts of capital into a single pool

• Using token-holder voting to fund each allocation

• Split DAO functions up into many pods, where each pod works as independently as possible

• A top layer of governance can create new pods, but once a pod is made and endowed with resources, it functions largely on its own, doesn't take orders from the core

Let’s say we want to create a new solution for Panda from scratch, what would that look like?

Assumption: “PandaDAO focuses on funding DAO tooling R&D, hence it falls into the compromise (concave) outcome category”

On making decentralization work:

• not everyone who holds Panda NFT gets governance tokens

• split up DAO into various individual working groups, with each group controlling its own fund and thus acting autonomously

• keep decisions making enclosed within the working group, achievable through assigning NFT pass to the group members only

• minimize DAO-wide governance or voting

• only allow governance power once a member has reached a certain level of contribution

By breaking down a DAO into various basic units, we hope to remain true to the vision of decentralization, granting individuals more autonomy than protocol-wide governance.