Politeia in Production
Today, Decred’s proposal system, Politeia, goes into production on mainnet. This corresponds with the development organization ceding control over the accumulated project subsidy, which is roughly DCR 570,000, currently valued at approximately USD 23 million, to the Decred stakeholders.
BY JAKE YOCOM-PIATT ON OCTOBER 15, 2018
Today, Decred’s proposal system, Politeia, goes into production on mainnet. This corresponds with the development organization ceding control over the accumulated project subsidy, which is roughly DCR 570,000, currently valued at approximately USD 23 million, to the Decred stakeholders. We have been working towards this milestone for roughly 18 months, so we are very excited to put Politeia into production. That said, it is important to understand that Politeia is a very powerful tool: it can enable all manner of positive developments for Decred, but if used unwisely, it can lead to a wide variety of problems. Politeia allows Decred users and stakeholders to propose, discuss, collaborate on, and fund new projects, initiatives, and consensus changes. If stakeholders exercise bad judgment, it can have serious negative consequences, so I am sharing my experiences and observations as the custodian of the Treasury to date, in an attempt to inform our stakeholders about the potential hazards of this role. Since the launch of Decred in February 2016, the development organization has been very conservative with spending, having spent a total of USD 2.8 million, roughly DCR 130,000, in that period. In the remainder of this entry, I will discuss a variety of topics related to managing the Treasury.
Once Politeia is in production on mainnet, all releases of Treasury funds will require a stakeholder vote. However, to release the funds, it still requires me to sign transactions as a Manager of the development organization, meaning that this control of funds is “soft” control. Since release of project treasury funds will still require my approval as a Manager and route through a conventional corporate entity, I will retain the ability to veto releases of funds. It is my expectation and hope that I will never need to exercise such a veto, and the only circumstances I would even consider exercising a veto would be (1) if I feel that the release of funds would place the entire project in jeopardy or (2) it would place the development organization and/or myself in legal jeopardy. Once the Treasury is backed by a smart contract, this veto could no longer be exercised and the considerations cited above would be moot. Development of the Treasury contract will begin shortly, and we will make a draft proposal about it in the next 3 months.
Open Source Ethos
Decred is both a financial system and an open source project, so it makes sense for Decred to adopt many of the practices of successful open source projects. Despite the vast majority of cryptocurrency projects being open source, many of them are run like conventional corporate entities, e.g. there is a core developer group that does not have open membership and whatever they say goes. Decred is setup to accommodate multiple groups of developers working simultaneously on various repositories, and we have met with a decent amount of success running more like a typical open source project than a corporate entity.
In a corporate environment, developers are hired and assigned to work on projects in a top-down fashion, where the hiring process is used to perform quality control on the new developers. As someone who has hired quite a few promising devs over the past 10 years, I have found the reality on the ground to be that the hiring process does a poor job of determining who is and is not a good fit from a developer perspective. Instead of perpetuating this same error-prone process with Decred, I have pushed prospective developers to show up, hack on whatever they find most interesting, see if they get along with the existing devs, and see if the existing devs like the deliverables being created.
There have been some attempts to short-circuit this process, and while I have found them challenging to deal with, it has proved extremely instructive. This has made it very clear to me that contractors in various subdomains need to undergo a vetting process that involves contractors in that particular subdomain, e.g. prospective marketing contractors need to be sure they integrate well with the existing marketing contractors and deliver good work. Based on what I have seen to date, I will be submitting a proposal that formalizes this process, creating a Decred Contractor Clearance process. Many nation state governments use a Security Clearance system to vet staff for their various national-security-related agencies and working groups, where the intention is to ensure you’re not a foreign spy, otherwise untrustworthy, or a risk to the organization. For Decred, this clearance process would be about verifying that individual prospective contractors are a good fit for the organization before they are allowed to bill for their work. Note that this would apply to contractors and their subcontractors, where the clearance process will be more involved for developers than other subdomains of the project. This means that any corporate contractor that plans to employ a large team needs to have each team member cleared before they can bill the project for their labor.
By putting our proposal system into production, I am substantially reducing my own influence within the project. This is a major milestone for Decred, and my relinquishing sovereignty over the financial decisions for the project is a notable increase in sovereignty for stakeholders.
In light of this increased sovereignty on part of stakeholders, it is important to consider the nature of decision making within Decred. Decred’s governance system is a form of collective intelligence, where stakeholders have influence proportional to their stake, similar to a corporation with a single class of voting shares. Despite the similarities to a corporation, it also has elements of a nation state government, and this adds complexity in the context of making decisions. Making good decisions requires a combination of understanding, intuition and long-term planning, and I hope to see stakeholders make decisions on this basis going forward. Bad decisions are often driven by ignorance, greed and short-term thinking, which we need to make an effort to avoid.
Since the act of voting necessarily becomes political at some scale, it is useful to discuss collusion and the creation of political groups. I, personally, try to judge the world around around me independent of others’ opinions, and I have found this to be a healthy approach in many different contexts, including with Decred. As stakeholders form their own opinions about the various issues that Decred encounters in the future, I encourage them to think independently and exercise their sovereignty accordingly. If stakeholders resort to forming voting blocks with predefined agendas or become unduly swayed by oracles within the space, I expect we will retrace the path cut by many nation state governments where we become a vehicle for preserving the status quo, as opposed to creating a new, better world. By engineering out elected and appointed officials, we have already substantially reduced the incentives that align for nation state political groups, e.g. that you need some minimum threshold group size in order to actually impact the legislative process. Decred was designed from the ground up to give permissionless representation to anyone willing to have skin-in-the-game, and I encourage stakeholders to think independently and exercise their sovereignty accordingly in that same spirit.
Conflicts of Interest
While acting as custodian of the development organization, I have endeavored to keep the organization free from conflicts of interest. Since we are building a new kind of infrastructure with Decred, this process has not been straightforward. Decred is about aligning incentives to accomplish great things, so if we are not careful, it is relatively easy to misalign incentives via the Treasury. I encourage our users and stakeholders to give added thought to whether or not proposals create conflicts of interest, and to avoid it where possible.
There are several examples of conflicts of interest that I have avoided while managing the Treasury. Early on, it was suggested that the Treasury funds be staked, so it could collect staking returns. However, this process not only creates risk from a computer security standpoint, it begs the question “How should these tickets be voted?”. This ambiguity is fertile ground for conflicts of interest and creates issues with custody going forward, so I decided it was not appropriate to stake the Treasury. Another suggestion was that the Treasury be used to fund either GPU or ASIC mining of Decred. This would have placed the development organization at odds with corporations creating mining hardware, so users and stakeholders would be incentivized to block new entrants to the mining hardware ecosystem. Sia chose to go this route and ran into precisely the conflict of interest that I saw when the idea was suggested, and they have, as a result, suffered from substantial community fragmentation and frustration. There will be plenty more examples of potential conflicts of interest in the future, and it is important that we work together to avoid them.
I have pretty mixed experiences dealing with professional service providers, e.g. legal, accounting, compliance, and marketing services, both in my other businesses, as well as with Decred. I have found that many professional service providers will bill you what they think can get away with, as opposed to what they should be billing you, based on deliverables and actual hours worked. In order to avoid these kinds of scenarios, it is ideal to have in-house staff that directly and routinely supervises and manages the work performed by professional service firms. If there is not someone who is a full-time contractor managing these outside contractors, it can quickly become a giant waste of money.
A common misconception with Politeia is that it can be used by stakeholders to micromanage the existing contractors. Per my comments above about our open source project ethos, I have found that people do their best work when they are working on whatever interests them most, whether we’re talking about inside a given subdomain or across subdomains. Attempting to use Politeia in this context would likely backfire spectacularly, driving contractors away from the project.
Politeia is intended to act as a digital commons where new ideas are proposed, discussed, funded and completed in a voluntary manner. In the event of a particularly contentious disagreement between contractors within a given subdomain, e.g. where a contractor is accused of bad behavior and their termination is called for, but they are vigorously disputing the claim against them, such a disagreement could be resolved via a Politeia proposal. Outside of resolving these more extreme disputes, contractor management should not occur via Politeia, or else we run the risk of turning staffing into a stakeholder popularity contest and driving voter apathy.
Elected and Appointed Officials
One of the design goals of Decred is to engineer out elected and appointed officials wherever possible. By keeping our hierarchy as flat as possible, we can avoid the typical gatekeeper roles that are present in corporations, e.g. the HR staff only hire people who look like X, attended school Y, and have work experience Z. Simple observation of nation state politics makes it clear that most elected officials have a persistent and deep-seated conflict of interest: they are incentivized to say what is needed to get elected, then they pursue their own or their financiers’ agendas after being elected. Similarly, appointed officials who cannot be easily replaced or removed create an enormous amount of friction in certain scenarios, e.g. the Supreme Court of the US. Rather than re-implementing known-flawed systems, we should be building the next, better system, just like we have already done with our consensus system and Politeia.
As a resident of Chicago and the State of Illinois in the US, I am very aware of how bad things can get when entitlements are not properly managed. Entitlements are a serious problem for many municipal, state and federal governments, and could very well become a problem within Decred. Some people may view Politeia and the Treasury as an opportunity to get rich at the expense of the project, which runs counter to the purpose of the Treasury, which is to magnify the value of Decred according to the will of its stakeholders. We should remain vigilant with respect to any entitlements within the project, with an eye to preventing them from consuming large portions of the Treasury payouts.
In terms of contractors, I believe that contractors should not be paid when there are no substantive corresponding deliverables. I have terminated several contractors on the basis that their deliverables do not line up with what they have billed and been paid. Cutting the dead weight on an ongoing basis will take a fair deal of work and a critical eye from our in-house staff.
Easing into Politeia
Politeia constitutes a substantial change in how Decred operates, so don’t expect massive output from it right away. Maintenance and ongoing dev work will continue as usual, but new larger projects may take a while to spin up. New individual and corporate contractors should make a point to demonstrate their ability to deliver on smaller projects before attempting to take on major deliverable sets. Early on, expect to see several proposals regarding policies, which will help manage expectations for both contractors and users, e.g. Decred Contractor Clearance process.
Accumulating the existing Treasury funds required discipline and foresight, so I suggest making a point not to draw it down excessively or too quickly. At the current accumulation rate, roughly DCR 17,000 was added to the Treasury in September 2018, while the contractor expenses from the same month were roughly USD 200,000. This means approximately 28% of the roughly USD 700,000 added to the Treasury was spent in September 2018. From a growth perspective, I believe it would be ideal for the Treasury to ease into increased spending in the future. If the burn rate grows too quickly, we run the risk of an exchange rate drop causing serious drawdowns in the Treasury along with the efficiency of the expenditures dropping. Currently, roughly 60% of the monthly Treasury payout is spent on development.
While Politeia will be used to approve all Treasury payouts, the process for “core” staff will differ from other groups that use Politeia. Just like a nation state government, Decred has numerous ongoing processes that require staffing and ongoing work. Creating proposals on a regular basis and having stakeholders vote on it is both time consuming from the perspective of creating a proper proposal and it can create vote exhaustion in stakeholders. From a workflow and productivity standpoint, it does not make sense to regularly create new proposals when there are minor changes in the work product being generated by core staff.
In the absence of a steady flow of proposals from core staff, I suggest that we create budgetary constraints for the core staff. Currently, the bulk of the monthly Treasury payout goes to fund the core staff, and it is important that stakeholders are able to both reign this spending in or increase it as they feel appropriate. In the event that the core staff is pursuing activities that the stakeholders consider counterproductive, it would be reasonable to create a proposal calling for a corresponding change in focus for the core staff. Per the prior comments about contractor independence, it is important that proposals for changes in core staff focus be large in scope, to avoid micromanagement.
The bulk of the work done by the core staff is already public, where there are only a few things that remain private. The outstanding items are the initial privacy work and the bookkeeping for the development organization, which will both be made public in the next few months. Neither of these activities are creating a substantial financial burden, so I am requesting patience on this front until 2019.
To date, contractors have been paid almost exclusively on an hourly basis, where we have mostly location-independent rates that are reasonable, but not high enough to suit some staff who live in areas with high living costs. While we have done fine using this model so far, I acknowledge that this model has issues attracting and retaining top talent. Internally, at Company 0, I offer bonuses to my staff in DCR for delivering major milestones. This model of offering bonuses, commonly made in stock, options or cash in a conventional corporate context, is very common in a financial or tech company.
With Politeia going into production, there is the opportunity to implement a similar model as a component of a proposal budget. Both at Company 0 and with Decred contractors, I have a strong aversion to paying high hourly rates or salaries since it often does a poor job aligning incentives, e.g. less ambitious staff are incentivized to take a long time to complete work. However, once a major milestone has been hit, I have found granting a bonus for that work to be a much better process for aligning incentives. The contractors or employees are keen to hit the milestone, management is keen to hit the milestone, and external parties can verify that the milestone has indeed been hit. I suggest that prospective contractors include a bonus schedule when creating larger proposals, and that the bonuses correspond with externally-verifiable milestones.
I had overpromised on the financial transparency front when Decred launched in February 2016, but this transparency is now on the horizon. I will deliver a breakdown of Treasury outflows from February 2016 to late 2018, where transactions will be tagged and classified according to the type of expense, e.g. marketing, design, development. This work will be completed before 2019 and the process of making this information public will become semi-automated, so I am no longer a bottleneck for this process.
Managing the Decred contractors has become a larger task as time wears on, both in terms of the head count and the variety of projects under consideration. Work has begun to automate parts of the contractor management, starting with the invoicing process. The contractor invoice format will be standardized, so that every contractor invoice submitted will have each line item classified according to expense type. Standardizing the invoices will allow for semi-automated creation of expense summaries, which will create financial transparency on an ongoing basis. This contractor system is based on Politeia, where the users are the contractors, the proposals are invoices, and the administrators are auditors for the project. Contractor invoices will be reviewed, audited, and then aggregated into a single payout for each calendar month, where each of these payouts will be approved in a proposal. Once the basic invoicing functionality of the system is working, we plan to add the ability to propose adding, removing and auditing contractors. We will make a more detailed announcement about the contractor system once it is ready for testing.
I am very excited for our stakeholders and users to participate in managing the Treasury and the project more broadly. Acting as custodian over the Treasury has been an interesting role, but I am keen to share the sovereignty in managing the Treasury. Now that the Decred stakeholders can participate in managing the Treasury, we can expand the scope of our work and engage more meaningfully with our users. There will surely be surprises along the way, so expect the unexpected and stay vigilant.