## Abstract

Proposed here is a goal for a legal structure to set up to properly house the entity which is currently called Smart Invoice. A major part of this is moving the current DAO structure to something that can scale as necessary. Given the several ideas that exist to build on top of the smart contract system, it makes sense to split into separate entities that are set up to produce a specific outcome. What will be described is the move from a DAO to a non-profit foundation to support the protocol, and then separate for-profit entities which attempt to capture particular use cases in a way that caters to the particular needs of a given market.

## Current situation

RaidGuild first created Smart Invoice as a generalized version of the escrow system it had set up for securing funds to work on raids. After receiving funds to build out Smart Invoice further it was recognized that RaidGuild isn't set up to support a product like this, so a vote was undertaken to allow Smart Invoice to split off. At this point the Smart Invoice DAO (built on DAOhaus v2) could be considered a separate entity from RaidGuild, though with no legal wrapper in any jurisdiction.

Since then we have migrated to a DAOhaus v3 DAO, but are still managing the project by consensus and distributing funds by vote. Discussions of legal structure have occured, but nothing has been decided upon. In order to grow while maintaining the open source project, we need to structure in a way that provides sustainability for the protocol on which different projects can build while allowing for different business models and opportunities for investment.

## Protocol Foundation

We need to separate out the assets and structure that is needed to serve the protocol. This will allow anyone to build on the protocol and determine which features are added that will benefit the different products that come out of it. The existing DAO will become the governing body over the protocol, and it will aim to gain non-profit status as the Smart Invoice Foundation (just a placeholder). Protocol fees will go to a community treasury that is used to maintain the system and perhaps establish grants to encourage projects to build on the protocol.

## Product LLCs

The foundation (protocol DAO) will not originate the for-profit products that may form around the protocol. The existing product (also known as Smart Invoice) will take ownership of the necessary assets to run this product and build market-share based on the direction of the members of this team. There is likely overlap in the protocol and the product early on, but they should be separate in legal terms and in how work is planned.

Other products can form around the central protocol, one such idea we have had is SmartGrants. Any assets that the existing DAO holds relative to SmartGrants should be transferred to this new entity. By allowing each product to operate on its own, the team can be nimble and find proper product market fit.

A new form of DAO that looks closer to a start-up is what we call a Pirate Ship DAO (also a placeholder name). This DAO structure described [here](https://hackmd.io/QKF6iMgPQ1CmZGJ3IpTkmw?view) elects a captain who acts as like a CEO of the product such that they can lead and make decisions different from the consensus building traditional DAO model. Whether a product team takes up this form depends on the team, but this experiment may prove useful.

## Coordination

The protocol will be operated by granting product teams funds to build out use cases. The protocol fee should go towards maintaining the protocol and growing the ecosystem. The product teams may earn a distribution of governance rights for successfully drawing in customers, so the protocol ends up being controlled by the stakeholders who have invested effort and time in a project. To avoid capture of the protocol, governance rights should be given in a way to avoid one product team from having too much power. By creating multiple teams the competition should be healthy and force proper decentralization at a protocol level.

## Conclusion

Building a product with a consensus-driven approach has proved difficult. Splitting the product building from the protocol governance will allow for consensus on the major decisions that demand such an approach, but finding a market and making product decisions can be done without the overhead needed at the protocol level. This approach will change up the way we do business, which is necessary at this point.