Introduction to the paper ‘A Treasury System for Cryptocurrencies’

English Education
1

Last week, IOHK released a paper ‘A Treasury System for Cryptocurrencies’. Here is an introductory summary of the basic concepts and ideas of the paper for the beginners!

The basic idea of Cardano’s treasury system stems from the “lack of secure and community-inclusive long-term sustainability of funding” in current blockchain systems. The major two approaches to the funding are initial coin offerings (ICO) and donations. Since the two approaches lack sustainability, no long term solution has been developed to date. In addition to that, those approaches have the risks of centralization, in terms of the decision-making on the development process on funding allocation, which is considered to be inappropriate in the decentralized architecture of blockchain technology. Also, disagreements within the community of a project can lead to further problems, as seen with some early blockchain projects.

The concept of a treasury system has been raised to address these issues.

“A treasury system is a community controlled and decentralized collaborative decision-making mechanism for sustainable funding of the underlying blockchain development and maintenance.”

A real-world example to date of a treasury system is Dash. This system still has a few potential theoretical drawbacks such as:

  • It does not offer ballot privacy to the voters
  • It fails to effectively utilize the knowledge of community experts in the decision-making process
  • The voting rule and the decision to allow only masternodes to vote in the election makes it “unfairly” difficult for proposals that do not have the support of the founders and core team to succeed

Thus, in this paper, IOHK team (Bingsheng Zhang, Roman Oliynykov, and Hamed Balogun) brings the concept of liquid democracy to achieve better collaborative intelligence. Some of the features are as follows:

Liquid democracy (also known as delegative democracy) is a hybrid of direct democracy and representative democracy. It provides the benefits of both systems (whilst doing away with their drawbacks) by enabling organisations to take advantage of experts in a treasury voting process, as well as giving the stakeholders the opportunity to vote. For each project, a voter can either vote directly or delegate his/her voting power to an expert who is knowledgeable and reknowned in the corresponding area.

Collaborative decision-making - is a core component of a treasury system that allows members of the community collectively reach some conclusion/decisions. Even though anyone can submit a proposal for projects to be funded during each treasury, due to a shortage of available funds, only a few can be supported. Therefore, a collaborative decision-making mechanism is required.

“This work aims to resolve the funding sustainability issue for long-term cryptocurrency development and maintenance by proposing a novel treasury system”

Contributions of this work :

This work provides and proposes ;

  • A rigorous security modeling for a blockchain-based treasury voting system that supports liquid democracy/delegative voting

    • Modeled the voting system in the Universally Composable (UC) framework. Via an functionality F_VOTE^(t,k). This allows the voters to either delegate their voting power to experts or vote directly on the project.

  • An efficient design of the treasury system

    • Collection of fundings can be done via:
      (i) Minting new coins, (ii) Taxation from Miners’ reward, (iii) Donations or charity.

    • Three epochs :
      (i) pre-voting epoch - Proposals are submitted, and the voters and experts are registered

      (ii) voting epoch - Voting committee is selected, and they generate the voting key. Voters cast ballots

      (iii) post-voting epoch – Voting committee computes and signs the treasury decision. The winning proposal will be funded

    • In this system, coin ownership is distinguished from stake ownership, so the owner of a coin can be different form the owner of the coin’s stake. This allows blockchain-level stake delegation without transferring the ownership of the coin. This hedges the risk of losing the ultimate control of the coin(s) for a coin owner when delegating his/her stake to someone else.

  • World’s first honest verifier zero-knowledge proof

    • This work proposed a novel special honest verifier ZK proof/argument

  • Prototype implementation of the proposed treasury system for running and benchmarking in the real world environment

    • Main functionality of the implementation includes proposal submission, registration of voters, experts, voting committee members and their corresponding deposit lock, randomized selection of the voting committee members among voters etc.
    • All implemented protocols are fully decentralized and resilient up to 50% of malicious or faulty participants.

Read the whole paper here: “A Treasury System for Cryptocurrencies: Enabling Better Collaborative Intelligence”

10 Likes
3

I wonder if project proposals must (or can) contain some milestone criterias, where additional post-votings (all supporters of thus project in the original voting) have to find a majority consensus to free up a further part of the overall funding?

1 Like
5
2 Likes
6

This is a copy&paste from Cardano Developer Telegram channel (Telegram: Contact @CardanoDevelopersOfficial)
regarding epoch times and project proposals as mentioned in Prof Roman Oliynykov’s video:

@vantuz-subhuman wrote
this scheme seriously needs a congress added to it
month voting epoch is way too short, people gonna vote for some shite nonsense =)
we need a built-in mechanism to delay any desision making untill all the hype around the proposal is gone, and untill 60% of people who wanted to vote has forgot about the whole issue )
CH told in some interview how some issue for ETC was discussed for 1,5 years before finally being sent to development (don’t remember whether it was about treasury or not) =)
month is maybe enough for (some) people to get to at least partially understand maybe one issue (proposal), but imagine having multiple proposals each month
I reckon the month is just a demo-case, tho, from the paper. Like the 1% threshold in the Ouroboros

@rickymac answered to

@vantuz-subhuman month is maybe enough for (some) people to get to at least partially understand maybe one issue (proposal), but imagine having m

The formally written proposal has to be framed clearly and concisely enough that the average person can understand it in about 2 minutes or less. Any more than 3 paragraphs on 1 sided paper is too much. (not for me, but you know what I mean).

@vantuz-subhuman
we need a built-in mechanism to delay any desision making untill all the hype around the proposal is gone, and untill 60% of peo

If any one particluar crypto currency is that complicated then it will not receive main stream adoption, IMHO.

@vantuz-subhuman
this scheme seriously needs a congress added to it

Thanks for posting that video. I think the coolest part, at time 19:30 to 24:50 when Prof. Oliynykov demonstrates the proposal submission and voting. It would be really neat if that feature was released for testing by the community for a month or so.

@anon20038177 answered to

@vantuz-subhuman
this scheme seriously needs a congress added to it

I agree with Ruslan, 1 month is such a short time and I also hope this timing is only for the testnet, even if the proposal to spend treasury funds is well written, the writer of such a proposal would have opportunity to “hype” the project within such a short period that a vote could possibly be influenced by the “hype”, the redcross and it’s advertising comes to mind when I think of how someone might play on someones emotions in a short period of time (just pointing out they gain more when their advertising is directly after a tragedy and stresses that sooner contributions are better than later) I like the idea of 100 days from proposal to vote - what could be so urgent that 100 days is not enough to release treasury funds? I could get behind some type of an emergency vote for very specific time sensitive issue’s but as far as I see what treasury will be used for I believe that the community needs to look ahead and have an idea of what they will be used for initially, I do not really feel a congress is important… but a constitution that a similar body can be built on makes sense to me.

@werkof wrote
I’m with you that a short and single standard epoch time is not adequate for complex and worthy projects.
Why not think about S, M and L sized project proposals? each one with a certain epoch time AND max budget.
And then have some threshold criterias like: project can be proposed with S-epoch and L-budget but then requires at least 85% of consens.

@vantuz-subhuman answered to

@werkof
I’m with you that a short and single standard epoch time is not adequate for complex and worthy projects. Why not think about S

I am 100% with this idea. There could be some very simple proposals, like “Let’s fix some buttons in the Daedalus, we need 3 days of work and 3000 ADA for this.” And there could be fundamental projects that take millions of ADA, months of work, potentially multiple rounds of funding and would change the way platform works. I just was thinking about maybe a limit of some sort, like 1 proposal a month (if we want a month to be a universal epoch), but that would delay small projects unnecessary. So something like different levels of proposals would be awesome. Like there may be 5-10 very small projects each epoch, and then maybe 1-3 medium-sized projects, and only 1 large proposal at a time and that would require that some minimum amount of stake DID vote and like 75% of VOTED stake is for the project

@rickymac
If any one particluar crypto currency is that complicated then it will not receive main stream adoption, IMHO.

Rick, I was talking more about a time for people to understand, whether the project should be voted in, or not, rather than the time, to understand the project itself. There could be very simple proposals, appealing at first glance, like:
“Let’s burn a billion of coins! Everyone gets richer!! Ain’t it cool?!”
Very short and simple :slightly_smiling_face: But lots of people would really be appealed to vote for this proposal, even tho it isn’t necessarily does any good for the system. I understand we are building a democracy, which means that if the majority voted for something - then that’s how it should be, and I would even agree with that, if the proposal author can still convince the people after 3 or 6 months of voting preparation.

Afaik, the US congress was created exactly for this purpose, because the founders understood that they are building a democracy, and that people are easily hyped and any really useful issue can wait (I am not a political specialist and I don’t want this discussion to shift this way. I might be wrong about the congress specifically, but I just mean that any democracy needs an instrument like this, to “de-hype” any issues). :slightly_smiling_face:
Especially in the context of a public treasury. I think we can look thru the EIP repository to see an example of what sorts of technical proposals there could be, and what a quality requirements for a proposal should be - https://github.com/ethereum/EIPs/tree/master/EIPS . But with a public treasury system - actors would most definetely actively try to exploit “the human factor”, knowing that there isn’t a team of technical specialists (core devs, etc) that could just decline anything. So people could (and I think - will) propose hyped changes with oversimplified naive descriptions, written in such a way that would specifically trigget people. Just a normal side-effect of a system like this :man_shrugging:
Proposals also might be pretty controversial in nature. So even if everyone understands the meaning of the change - not everyone might understand the necessity of it (or necessity to NOT implement it). So any serious proposal might require time for serious posts and reviews (debate) to be created, so people who really know something abot the stuff could get info out to the public

@rickymac
If any one particluar crypto currency is that complicated then it will not receive main stream adoption, IMHO.

But we are talking about a cryptographic protocol here. Proposals will get complex. At least, imo, if we really want to make the system better and not vote only on issues like “let’s add X translation to the Daealus.” or “Gimme money on a new Cardano logo”, etc :slightly_smiling_face: Again, I think we can look at EIPs for an example: EIP-1057: ProgPoW, a Programmatic Proof-of-Work . In cases like this, I think we need a longer pre-voting time so that more technical specialists could review and really think-thru the idea, cuz there might be some fundamental problems in it that are not visible at the first glance. Some proposals migth need to be turned down to be fixed or reworked. But, imo, if we gonna have multiple proposals a month like this EIP - no one will have any time to even properly go thru them, much less to think it thru and discuss. And even more so if there will also be some hyped but stupid proposals in the same epoch, so specialists will have to spend their time to try and debate that )
It’s a complex issue, whether proposals may get any serious, or only contracted at the moment dev-company can make any serious changes; and also how exactly public will vote on very technical issues without understanding much of it (the experts system should help). I think time and free market will show how it all plays out, of course :slightly_smiling_face: My main argumen is that the system itself at least should include the automated mechanisms to help people come to the eventual “golden middle”. The treasury functionality can also be changed thru the voting and proposals, and something tells me that it is possible to come from very strict system to a mildly strict system in time, if everyone agrees (and time shows) that things get delayed too much and that voting can be made faster. But if we have a very relaxed system from the start - it may be extremely hard if not impossible to come from this to a stricter version, if time shows that voting is too fast and primitive.

@anon20038177
I agree with Ruslan, 1 month is such a short time and I also hope this timing is only for the testnet, even if the proposal to s

Also agree and like very much the phrase: “what could be so urgent that 100 days is not enough to release treasury funds?” The MAIN purpose of the treasury (as we all know :slightly_smiling_face:) is to hire IOHK back (ok, maybe not necessarily IOHK, but someone) - so the public hires “the core devs” whos job is to improve and change the protocol, and fix any problems. So I think it might be reasonable to expect that any actually pressing issues are solved by this hired team - bugs fixed, urgent features added, etc. So the treasury proposals should not deal with that kind of things, and should be more of a long-term ideas, improvements, and side-projects that community want to have.
Btw (just brainstorming), since we, as a community, hire a team of technical specialists to support the platform exactly for the main reason of them being professionals in this field - would that be rational to maybe implement a 5-10 built-in specialist “chairs” that must be appointed by the hired team (and would change when community hire new team) that may (or have to) participate in the voting process as standard “experts”, so people could delegate their votes to them? :thinking:

3 Likes
7

Thank you for setting up this thread @werkof, good place to continue the discussion with @vantuz-subhuman who I consider a brilliant young man. I am just going to lay out some what I consider realistic user vote example below. There are some engineering decisions that are too detailed to put to a vote. I am not referring to those kind of decisions. For example if a community in Russia needs to build a bridge, they might vote whether or not the bridge should be built. They might vote on where the bridge should be built. They might vote on how to pay for it. But the one thing that the community will not vote on is “How is the bridge engineered?”.

Here is an example of how I imagine several rounds of voting would go for the average person, as it relates to 1 thread of development.

THREAD 1 Payment systems.
Round 1:
Proposal: Which form of mobile payment should be developed next?

Discussion, Risk and Cost paragraphs.

Voter options: (vote for order of priority)

  1. Mobile Phone.
  2. Credit Card.
  3. Hardware security device.
  4. Biometric scanner.
  5. Delegate my vote to an expert.

The vote is to prioritize which one should be worked on first with the voters putting the options on the list in the order in which they prefer. Lets say that credit card wins the vote for example, because the average user carries a credit card and does not trust the mobile phone (we may or may not know why they vote a certain way). But Development contiues with little delay.

Round 2:
Proposal: Which credit card system should we partner with the block chain? (pick one)

Discussion, Risk and Cost paragraphs.

Voter options: (pick one)

  1. American Express
  2. Visa
  3. Discover
  4. Build our own
  5. Delegate my vote to an expert.

Lets say Visa wins the vote because it is the most widely used in Europe and Asia. Development and efforts continue.

THREAD 2: Block chain storage.
Round 1:
Proposal: The block chain will grow too large in X years, how do we fix it?

Discussion, Risk and Cost paragraphs.

Voter options (pick one):

  1. Conduct more research.
  2. Centralize the block chain.
  3. Establish trusted start points in the chain.
  4. Increase storage requirements.
  5. Delegate my vote to an expert.

Lets say number 5 “Delegate” wins and results in the Experts voting in #1… Development and research continues.

Round 2:
Proposal: “Conduct more research” won round 1, so now “Who should do the research?” (pick one)

Discussion, Risk and Cost paragraphs.

Voter options (pick one):

  1. Company A
  2. Company B
  3. Company C
  4. Ruslan, Rick, and Werkof will do it for free.
  5. Delegate my vote to an expert.

Development continues…

But users will not vote on how the security of the protocol will be made quantum resistant for example. Decisions like that are beyond the scope of a user vote and best left to the developer who was selected by the voters and experts. There will be thousands and thousands of engineering decisions that are far too detailed to be voted on.

4 Likes