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.
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.
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
Requester, 1 contract role
Fund as well as 1 actor-contract role,
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
Funder has a time-period for vetoing the use of their tokens for that
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
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.
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
Funds or actors as subreddit equivalents, showing the main proposal and any delegated tokens as a list to other
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.
Conversation is currently happening on #status-dao.
We are currently forming the team, getting familiarity with the contracts and setting requirements.
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!