Skip to content

Current design

Current MV-Crowdfund DAO Specification

This is a living design document composed of requirements and specifications on a crowdfund DAO running on Bitcoin. The justifications for the choices made will be available in other documents/sections.

Requirements

  • Use of Bitcoin network
    • as medium of financial value
    • to provide security guarantees through its consensus mechanism
  • No trust required between users
    • i.e. no treasurer
  • All users can take on any role in protocol (fully P2P)
  • Use of ipv8/trust-chain to coordinate key management protocols and other parts of the protocol

  • Scalable

    • large number of users should not use ever-increasing amount of on-chain data

  • No governance tokens (unfair for numerous reasons and often unneeded)

  • No protocol fees (no financial incentive required between users)

Small Glossary

  • DKG: Distributed Key Generation; the shared public key generation through coordination of all members in the DAO

Design

The DAO itself is a collection of UTXO (wallet) with Bitcoin locked up using a shared public key. This shared public key is created by a thresh-hold signature scheme (FROST). The shares of the corresponding private key are held by the DAO members.

The ownership of the Bitcoin lie with the DAO members. These members can also be regarded as a set of validators. At any point t-n members can agree to sign a transaction to spend the funds from a UTXO.

The specification below on the joining, leaving and spending of DAO funds rely on at least a t-n amount of participants acting fairly. Acting fairly entails only participating in the signing of transactions when the protocol specifies to do so. The validation of this is done by all members themselves.

Thus, the over-arching architecture is that off-chain on ipv-8/trust-chain, validation logic and the thresh-hold scheme is run by all members (and new members) in order to decide what transactions to create, sign and publish on Bitcoin.

Creation

  • Creation of a DAO entails:
    • the specification of the parameters (thresh-hold and other possible rule parameters)
    • the creation of a UTXO on the Bitcoin network
    • the publication of this information off-chain (ipv8/trust-chain).

Joining

  • Joining requires a fixed amount of Bitcoin

  • 2 join models:

  • Closed join model:
    • A set of n users agree to join or create the DAO at once
  • Open join model:
    • A user joins an existing DAO 1-by-1
    • A group of users joins an existing DAO in a batch group

  • Every one of the join actions above requires 1 transaction (of varying size).

  • A user joining the DAO will first have to spend a minimum amount of one of Bitcoin of his own addresses with the shared public key of the DAO.

  • The members of the DAO validate this and then include the new members in DKG of the new shared public keys.
  • The old funds and new funds are then locked up in a new transaction using the new shared public keys with a Bitcoin transaction.

Governance

  • Any member can make a proposal to spend funds from the DAO to a certain address
  • A proposal is a yet to be signed Bitcoin transaction spending the amount of funds to a certain address
  • The proposal is then put on ipv8/trust-chain to be voted on
  • Voting is equivalent to members participating in the thresh-hold signature creation
  • If t-n members participate, a valid signature is created and the proposal passes
  • Any members can broadcast the valid transaction on the network

"Dynamic Digital Democracy Problem."

  • Low voting participation can lead to locked up funds.

  • The ability for an increasingly lower thresh-hold number of members to be required over time to spend the funds can help remedy this problem.

  • DAO funds are locked up by a specially constructed Taproot Script.

  • Everytime a shared public key is created using DKG, multiple different thresh-hold values are used i.e. t_1, t_2, t_3, and multiple different public keys will be returned.
  • A Taproot script can be set-up roughly as follows (example):
  • There are 3 shared public keys P_1, P_2, P_3 with 3 different thresh-holds.
  • Using a hashed time locked contract, after X amount of time, public key P_1 with thresh-hold t_1 will be able to create a valid transaction.
  • After more time has passed, in addition to P_1, P_2 with a lower thresh-hold t_2 will be able to create a valid transaction.
  • After more time has passed, in addition to P_1 and P_2, P_3 with an even lower thresh-hold t_3 will be able to create a valid transaction.

Thresh-hold Signature Schemes

  • FROST is used to create shared public keys in and signatures of messages (= Bitcoin transactions) in a trust-less manner.
  • Coordination of this protocol is done on ipv8/trust-chain.
  • Secure messages can be stored on Trust-chain.