tldr: In this layer we will re-appropriate Liquid Democracy (Liquid Funding) & evaluate Quadratic Voting (Liberal Radicalism) for the purposes of allocating tokens, instead of votes we will be utilizing and allocating tokens of value directly for the purposes of community-driven creation of public goods.
Summary
Status will be setting up a network for coordination, commonly referred to as a Decentralised Autonomous Organisation, this network is made up of many instances of various Smart Contracts and actors, whether human or machines. While this network will ultimately be comprised of many different entities from various authors, in this document we will be outlining the use of smart contracts to allocate tokens. It is erronous to view this as an on-chain analogue of a ‘company’.
This move allows Status to recontextualise its operations within the greater Ethereum community, allowing Status to scale beyond the limits of traditional organisations and allows for voluntary participation. In this layer 1 context, we allow for permissionless participation in both funding and requesting tokens. Such a network will allow a public good to continue in the event of adversarial intervention.
We will likely use technology from Giveth & Aragon.
The Problem
While the original longer term reasoning revolves around continuance of the public good in the face of adversary, the short-to-medium term goal recognizes Status as an organisation predominantly cares about public goods as deliverables. How public goods get created, how people socially organise or who creates them is not required to be prescribed.
Currently Status has created permissioned access to work on a community-driven project via the means of salary-based employment, while at the same time excluding the community from having influence over the direction over the work.
To remedy this Status assigns its organisational design to a free market (network), and with its tokens, act as node in the network that focuses on modern procurement, supply-chain management of public goods, cultivating culture and movement building relevant to advancing web3.
Such a system will create an ecosystem to provide competition for the Status GmbH, for example, against Gitcoin. This would move Status’ role to the procurement of design & specification as its central activity while enabling the whole community to participate in reaching Ethereum’s goals.
Why not votes?
In short, Dark DAOs. Essentially Identities & Votes can be bought, and it seems unlikely we’ll be able to raise the costs of identity creation anytime soon.
We should also recognize that Liberal Radicalism, as with any democratic system, is susceptible to fraud and collusion. While we can experiment with it with smaller amounts of tokens, we should still allow the decision to be audited (by funders?), perhaps when we have shielded transactions this will be easier.
Liquid Funding (Liquid Pledging)
caveat: my knowledge on Delegates might be slightly wrong in implementation.
This is a technology created by the wonderful people over at Giveth, our use case of their contracts will be to fund public goods, where their intended use-case is for charity, for clarity we’ve been recommended to call it Liquid Funding.
With Liquid Funds there are 2 actor roles Funder & Requester, 1 contract role Fund as well as 1 actor-contract role, Delegate.
It’s easiest to imagine a Fund like smart contract based wallet, anybody(Funder) can send tokens to the Fund, and anybody(Requester) can request to withdraw tokens from the Fund. Like a wallet a Fund can hold many different ETH & ERC20-compatible tokens.
Liquid Funding essentially acts like a Liquid (Delegative) Democracy, where Funders ‘vote’ on ‘topics’ (Funds) by transferring tokens. Unlike Liquid Democracy Funders show intent by transferring token and can always withdraw any unspent tokens at anytime. When Requesters make a request to the Fund, a Funder has a time-period for vetoing the use of their tokens for that Requester.
This puts a burden on the Funder as they will have to accurately monitor each individual request. Perhaps Requesters should stake a certain amount not unlike a dominant assurance contract to have their request reviewed.
While the details are unclear, implementing a system such as Liberal Radicalism would allow a Funder to allocate their tokens spread over multiple Requesters as chosen by other Funders.
To further alleviate this burden Funders can delegate their committed tokens to Delegates, which are other Funds or other actors within the network. This allows Funds to form hierarchies or chains of funding across many different Delegates. These Fund hierarchies can be viewed as a sort of budget for the procurement of public goods, split upon topics.
In the future we can add other layers, such as prediction markets on Fund payouts, to act as signals of project health.
Note these Smart Contracts do not formalize the conditions on which tokens are released to Requesters, this is assumed to happen off-chain.
User Interface
Before using the network, all participants should sign and prove on-chain they have signed the Status principles.
Since the agreement is made off-chain (at least initially), each Fund should have a corresponding means of coordination between actors, I would suggest a whisper chat #topic (string), a proposal title (string) & body (ipfs/swarm hash) (string), a threaded comment section and tagging system to allow actors to coordinate and sort.
For the user interface itself I don’t have any strong opinions, Giveth has provided 2 interfaces, both in their main application and more of a wallet-management interface. I personally find the main application, while visually stunning - hard to navigate and information-poor given screen real estate.
While it would be nice to show a graph (cytoscape.js) of funding chains through Delegates perhaps a more old.reddit.com style interface would be suitable. You could navigate Delegates whether Funds or actors as subreddit equivalents, showing the main proposal and any delegated tokens as a list to other Delegates
How Funds are listed also presents a problem, due to the nature of screen real estate, ordering Funds are important, it may be the case that a good idea can go unnoticed depending on how we present and order proposals.
One other UI item is the Network’s ‘event log’, ideally a time-ordered list of changes in the Network to quickly see where activity is in the network.
We should provide templates of contracts to be deployed, instantiations/factories to prove code is identical. We should also provide proposal and submission templates.
How will this be used?
So while the above does little to describe anything more than showing intent to fund, and funding of requests. This allows for the way the system is used to evolve. Status’ initial intended use will be cultivating culture, movement building and modern procurement.
There is many well tested processes and strategies in procurement and will allow us to scale horizontally over the community. We can map some procurement terms to software development patterns we see in the crypto-community. A process can generally follow 3 phases.
-
Request for Information (RFI) - analogous to Research, to be presented openly to help inform RFP’s
-
Request for Proposal (RFP) - analogous to Specification, to be presented openly to help inform RFQ’s
-
Request for Quotation (RFQ) - analogous to Implementation, where the work gets done.
How bids are accepted is beyond the scope of this document, however human Delegates can be viewed as evaluation committees.
The UI should support but not overfit to this use-case, as there may be many other use-cases, for example budgets for cultivating culture and movement building will be less formal.
Next Steps
Conversation is currently happening on #status-dao.
We are currently forming the team, getting familiarity with the contracts and setting requirements.
Team Formation
The team currently includes Jarrad, Graeme, Barry & Richard. The Embark team is likely to be involved as they are currently migrating Liquid Pledging contracts to Embark.
Feedback, comments and suggestions are of course welcome and encouraged!
