About “A Treasury System for Cryptocurrencies”
IOHK’s Roman Oliynykov recently published a paper in cooperation with Bingsheng Zhang and Hamed Balogun from the Lancaster University, UK describing a treasury system that could be deployed on various cryptocurrencies regardless of the consensus mechanism used. A prototype has been implemented in Scala over the Scorex 2.0 framework. You can find a detailed presentation here. Rob Viglione explained the implications in a short video on twitter.
I will try to summarize the paper in this article and provide some context for those, who can’t make the time to read the somewhat complex paper. I have a feeling that it will turn out to be a rather long read, but I’ll try not to waste your time!
Introduction
Building a cryptocurrency requires a lot of things. It requires developers willing to commit their time to the project. It does require some marketing these days, not only to make your coin attractive to potential investors but also to attract developers willing to commit their time to the project. Since regulators are watching the crypto space more closely, it requires a legal team, to make sure all endeavours are compliant with the existing regulation and will be compliant with future regulations. Many other things could be added to this list and most of them have one thing in common: they require some sort of funding.
This funding should be sustainable long term. There are three main sources of funding identified in the paper, namely:
- patron organizations and donations
- an ICO
- hair-cut/tax/founders reward (part of the miners reward)
Other people also included transaction fee’s in this list before, but the total amount of TX fees outside the major projects like Bitcoin and Ethereum is not anywhere near sufficient for continuous development.
The first option, donations, is not reliable long term. The second option, an ICO, does not provide sustainable funding over years and became a legally challenging option lately. The third option was identified to be the most promising means of funding. For the foreseeable future there will be mining rewards to be earned with most POW currencies and finding new sources of funding will turn into a problem that generations to come have time dealing with until the issuance ends (with currencies that adopted the Bitcoin issuance schedule roughly till 2140).
Decentralization is Key
Decentralization being the key factor in this space does not just avoid single points of failure, it also helps to improve on privacy. A central party will always be able to gather more information on a given user, than a truly distributed system would. Another area, besides the network architecture, that should be as decentralized as possible is the funding of development and maintenance and the decision making regarding what the funds at hand are used for. This is where the treasury model enters the scene. The treasury system proposed does not really care where the funds are coming from. It could be realized within a project that funded itself through an ICO or donations. It is just that taking a cut out of the miners reward is the most sustainable funding method.
The team coming up with the treasury system was mostly concerned with two questions: i) what voting structure or system to use and ii) how to design the voting process, so that it can be implemented on a number of different projects.
Voting Structure
“The core component of a treasury system is a decision-making system that allows members of the community collectively reach some conclusions/decisions.”
Every member of the community will be able to submit a proposal for projects to be funded and the community should collaboratively come to a conclusion which projects to fund. This could be the development of a new feature for the wallet and a developer getting paid for his work, a community member travelling to a conference to raise awareness of the project or sponsoring an event.
There are two categories of voting schemes: i) preferential or ranked voting and ii) approval voting
With preferential voting voters rank the given options and the highest ranked proposals would be funded. Ranking is very time consuming and difficult when it comes to comparing apples with oranges. It’s hard to decide on which features, conferences and events are the most important by itself. Now comparing a conference to a feature does not make it easier.
Approval voting with a Yes-No-Abstain scheme simplifies the decision making process a lot and is the option the team around Bingsheng, Roman and Hamed chose for the treasury system. At the end of the voting period a score for each proposal can easily be calculated from the difference in Yes and No votes and the highest scoring proposals will get funded in turns, until the treasury pool is depleted for the month. It also leverages the expertise of the experts that I will talk more about in a second.
If you are an expert in programming, you will likely cast a vote for all proposals regarding new code to be implemented. At the same time you might not be very experienced when it comes to marketing and feel, that other people should make decisions regarding which conferences to attend and events to support. A marketing expert will want to decide on which conferences to attend but might not have a strong opinion about what code to implement… you get the idea. Now how do you realize this? The answer is liquid democracy or delegated voting.
Liquid Democracy
With liquid democracy you have the option of delegating your vote to an expert, that you feel represents your views. This might sound familiar. Basically this is similar to what you do, when you cast a vote in a political poll. The key difference is, that you can delegate your vote to whomever you like, be it your brother that is really knowledgable on the topic or anybody else and you can withdraw your delegation at any given time. If politicians were held accountable during the entire legislation period of (mostly) 4 years and you could withdraw your support at any time if you feel they do not represent your views or don’t keep their promises made during their campaign, I think this would result in decision making that actually keeps the voters in mind.
The Different Entities
Getting closer to describing the voting process itself it is necessary to introduce the entities partaking.
- Project Owners {O} are the people that have submitted a proposal to be funded. Anybody can submit a proposal but has to pay a little fee in order to avoid spam.
- The voting committees {C} are stake holders that are willing to help with the voting process. They are responsible for generating a voting public key together and announcing the voting result once a voting epoch ends.
- The voters {V} lock a certain amount of their stake to participate. Their vote is weighted according to their locked up stake.
- The experts {E} are a special type of voters that have expertise in some field. Anybody can register as an expert though. More on that when we get to how to register as one of the entities.
In short: Anybody can submit a proposal for funding, and become a project owner. Anybody that owns a stake can register as a voter or an expert. Some of the voters will “randomly” get the option to become a voting committee member. I’ll explain the randomly in a bit.
Treasury System Epochs
There are three epochs in each treasury period. In the pre-voting epoch all the project owners have time to submit their proposals in an encrypted form. All proposals will be revealed at once when the proposing stage ends. This increases fairness and prevents tactical timing of proposal submissions. During the pre-voting epoch the community members also have time to register as a voter or an expert by submitting a special kind of transaction.
During the voting epoch the voting committee is selected, a voting key is setup and the ballot is held. Let’s first talk about the committee selection and the “randomly” I mentioned before.
As you probably know a hash function takes an input and calculates a pseudo-random output of fixed length. Before I elaborate on this let me help you with the notation used above:
- vk(i)… Address of the registered voter i
- sign(sk’i)(seed)… An encryption (signature) of the seed used in the previous voting period under a key, that corresponds to vk(i)
- st(i)… The stake the registered voter i has
- T… a threshold variable to limit the number of committee members
I am not entirely sure if this won’t lead to confusion but I’ll try to make sense of this in a straightforward fashion, bear with me.
Imagine you are the voter i: What happens here, is that your address vk(i) and your signature of some data (the seed of the last voting period) is hashed. This will yield a “random” string of fixed length. This string is calculated for every registered voter. Now the inequality describes the criterion for being eligible as a committee member. Your hash value (the string of numbers and letters) has to be less than or equal to your stake multiplied by the threshold. Now, if you stake a large amount, the chance of your pseudorandom hash being smaller than st(i)*T is greater than in the case of a small stake. Therefore your chance of being able to become a committee member increases with your amount of stake.
I hope I managed to make the following sentence taken from the paper more relatable: “…a set of voting committees will be randomly selected from the registered voters who are willing to be considered for the committee selection. The probability of being selected is proportional to their locked stake.”
The key setup stage is where a public voting key for the treasury epoch is generated (used as an address that all the casted votes are send to). The votes are casted privately and only the end result will be public. As a basic concept in all voting schemes it should be possible for a voter to express his opinion privately, thats why there are voting cabinets in “analog” polls. The protocol ensures that the end result does indeed represent the sum of all votes.
Voting in private is achieved by all voters and experts encrypting their vote with the public voting key. Only the voting committee members can decrypt the casted votes in the tally stage. “Once all the committees have opened the tally, any party can read the tally”.
The ballot casting stage is where all the voters and experts cast their votes. Each individual vote is represented as a vector. Since there are three possible votes — Yes, No, Abstain — there are three possible vectors that can be submitted.
The basic concept works something like this: In the example below there have been 4 voters partaking in total. 2 voted Yes on the proposal, 1 No and 1 Abstain.
If you are familiar with the concept of vector addition it is easy to tell the sum of those four vectors. One of the Yes votes is cancelled out by the No vote. The remaining Yes vote added together with the Abstain vote yields the diagonal vector shown below. For the tally only the x-axis is considered. The final result on this proposal, revealed in the tally stage, would be a Yes.
More specifically, a score for each proposal will be calculated by taking the number of Yes votes minus the number of No votes. The resulting difference has to account for at least 10% of all the votes submitted to be considered for funding. If 100 votes are casted (without Abstain votes), there have to be at least 55 Yes votes to reach that threshold. The highest scoring proposals will be funded until the treasury is depleted for the month.
The post-voting epoch consists of the tally stage and execution stage. Note that each vector is submitted in an encrypted fashion and only in the tally stage the committee jointly reveals all the casted votes. The score for each proposal will be calculated and the proposals ranked according to their score.
In the execution stage the committee jointly signs off on the transactions funding the approved proposals.
Rewards
The last feature I want to talk about is the voters, experts and committee members being rewarded for participating in the governance of the protocol. There is a phenomenon called rational ignorance. Wikipedia says:
Rational ignorance is refraining from acquiring knowledge when the cost of educating oneself on an issue exceeds the potential benefit that the knowledge would provide.
It is a huge problem in todays democracies all over the world. The time and effort it takes, to acquire all the information needed, to make the best possible decision in an election exceeds the benefit of being able to cast a single vote. To tackle this issue, resulting in voter apathy, people that participate in the governance proposed in the paper get rewarded for their efforts. This creates an incentive to be informed and partake in the process. Voters will get rewarded proportional to their stake and experts will get rewarded proportional to the amount of stakes that were delegated to them, or in other words the trust that was placed in them and their decision making.
How ZenCash wants to implement all of this
ZenCash recently published a blogpost that contains a short explanation of the proposed treasury system and outlined how it could be implemented. The initial plan is to integrate the system in a sidechain. Sidechaining is one of the major protocol upgrades that ZenCash is working on. It will enable different dApps to each run on their own sidechain without having the main chain effected in case something goes wrong.
Further Thinking
I am a very UI/UX focused person and to me the usability is always a very important factor. The best treasury system does not help a lot, if it is hard to partake in.
One challenge will be to come up with a structured and informative “governance-central”. By that I mean a go-to place, may it be a website or a functionality embedded in the wallet, where the proposal-, voter-, expert- and committee-registration is happening. As we now know the registration is formally a transaction, therefore it would be practical to have a function implemented in the wallet to make it easy for every stakeholder to participate in the governance.
Next, there needs to be a place where all the experts are listed, where their past decisions are visible and displayed in a comprehensive way. They should be able to create a profile and add a little biography so that you get to know who you are delegating your stake to. They will define their domain of expertise and the entirety of the provided information makes them accountable for future decisions. Don’t forget that you can revoke your delegation at any time if you do not agree with an expert any longer. This should be just as easy as delegating your vote to an expert in the first place.
I hope I managed to give you a high-level overview of how the proposed treasury system is working. Feedback, criticism or advice are most welcome. I am only getting started on writing articles here because it is something I believe might be helpful for others and I enjoy doing it. Please leave a clap if you fancy:P
