How DAOs Deploy

Traditional companies deploy contracts and dapps via the unilateral action of authorized individuals working for the company. In a decentralized organization individual participants are still the ones building and executing, but it is unacceptable to give individuals unilateral authority over key assets. Key assets must be controlled directly by the DAO, with actions being taken with the consensus of the collective. How then does a DAO deploy smart contracts and dapps?

DXdao pioneered a process of smart contract and Dapp deployment in the spring of 2020 with the launch of its bonding curve fundraiser. After observing the process, I summarized what had happened in this tweet thread: https://twitter.com/jpkcambridge/status/1259900794259857409 Generalizing this process, it can be described as these three steps:

  1. The DAO hires developers to build the dapps and smart contracts. These could be members of the DAO or contractors. They could live anywhere in the world. They might be psuedonymous. The DAO also acquires an ENS domain name, e.g. newproduct.eth.

  2. Upon completion of their work, the developers hired to build the dapp and smart contracts deliver their work product, announcing the production ready release of the smart contracts and dapp to the community.

  3. A community member deploys the smart contracts, configures the dapp to point to these contracts and deploys the dapp to IPFS. They then make a proposal to the DAO to set the contenthash of newproduct.eth, which is owned by the DAO, to the IPFS hash of the dapp. The proposal illustrates how other community members can verify the code is the same as released by the developers and configured as previously approved by the DAO. This community member or members could be known or anonymous.

While this process allows a DAO to collectively launch a new dapp and smart contract protocol, there is room for improvement. Note that, when the proposal is made, the world will know about the deployments and be able to access the dapp and smart contracts but that the outcome of the proposal will not be known until the DAO’s consensus has been found. In the case of the DXdao’s bonding curve fundraiser this was less than ideal. People who wanted to buy from the bonding curve were incentivized to do so before knowing whether the smart contracts they were interacting with would be approved by the DXdao. To improve this process, we need a way for the DAO to approve the smart contracts before anyone can access them. This is possible through the use of a deployer contract. Now the process looks like this:

  1. Same as before

  2. Same as before

  3. A community member deploys the deployer contract and makes a proposal to the DAO to authorize the deployment and/or call the deployment directly.

  4. After the smart contracts are deployed by the DAO, the developers hired by the DAO can update the dapp with the known contract addresses and make a new release.

  5. A community member deploys the latest release of the dapp, which points to the contracts deployed by the DAO and makes a proposal to the DAO to set the contenthash of its product’s ENS domain to the IPFS hash.

5 Likes