The Gridcoin Treasury - A Proposal
The github thread for this outline proposal can be found here
The Gridcoin Treasury
Table of Contents
- Introduction
- The Gridcoin Treasury
- The Gridcoin Treasury - Generating Funds
- The Gridcoin Treasury - Allocating Funds
- The Gridcoin Treasury - Releasing Funds
- Side-Staking
1. Introduction
This outline seeks to sketch potential protocols and processes and does not define or support any one implementation. The number of possible implementations and combinations makes this outline incredibly complex, and I probably do not do the best job explaining how each possible iteration would look. I expect this outline to raise more questions than it answers. Ask the questions, ask for clarification, and let’s get this discussion rolling and a serious proposal ironed out. If you think of another possible way to build a treasury, allocate funds, and release funds, this is a great place to explore its potential. I will update this outline as we discuss things.
The Questions:
- How can we raise funds for Gridcoin protocol development and maintenance?
- How can we raise funds for marketing and outreach for the Gridcoin protocol and network?
- How can we raise funds for research, science, BOINC projects, and other endeavors that use the Gridcoin protocol and network?
- How can we distribute these funds?
What is Needed:
A protocol or process to fund a Gridcoin treasury.
A protocol or process to release funds from the treasury.
A protocol or process to raise funds for non-treasury related endeavors such as faucets, charity and relief efforts, non-Gridcoin related programs, personal crowd-sourcing projects, or others.
2. The Gridcoin Treasury
The Gridcoin treasury is an address or set of addresses and sub-address that funds approved endeavors and proposals. The number of addresses or sub-addesses depends on fund allocation and release, which are described later in this outline.
What Does the Treasury Fund?
Development
Marketing
Outreach
Other network approved endeavors
Potential Sources of Funds:
Generation-Funding - Directly generating and depositing a set number of GRC when GRC is otherwise minted and depositing these generated GRC into the treasury. GRC is currently minted through staking, later described as Stake-Generation, and GRCResearch-Mint, later described as ERR-Generation.
Surrender-Funding - Similar to Generation-Funding, however instead of generating new GRC, a user surrenders an amount of their earned GRC. A user earns GRC when they stake a block, later described as Stake-Surrender, and when they receive their ERR, later described as ERR-Surrender.
Anti-Spam Mechanisms (AS-Fees) - Fees generated by the blockchain to prevent DDoS-type attacks. Transaction fees, for example.
Donations - Users donating for a cause.
Existing Examples:
Dash - Dash uses a generation-funding protocol-defined mechanism (specifically stake-surrender, which will be defined later). The mechanism reserves 10% of all minted Dash (minted when a block is staked) for use by the Dash treasury. Treasury funds are allocated by a masternode consensus and released as defined by submitted proposals which are approved through masternode consensus.
PINK - PINK uses a donation-based user-defined mechanism. The mechanism allows users to automatically split their stake reward by percentage among any number of wallet addresses. These addresses include official marketing and development addresses set up by the PINK core team. They call this protocol side-staking.
3. The Gridcoin Treasury - Generating Funds
This outline describes using Generation-Funding, Surrender-Funding, Combination-Funding, Anti-Spam Mechanisms (AS-Fees), and donations for raising treasury funds.
Generation-Funding
Generation-Funding occurs whenever the Gridcoin protocol mints GRC.
Gridcoin mints GRC when a block is staked and when a user receives their ERR. It may be possible to generate treasury funds when a user receives their ERR, however we have not quite decided how to distribute ERR to users, so it might be unwise to seek funding from ERR-generation until that process is worked out.
Therefore, let us say that Generation-Funding can be implemented in one way: Stake-Generation.
- Stake-Generation would generate an additional protocol-defined mint of GRC when a block is staked. It would automatically deposit this mint into the treasury fund address, addresses, or sub-addresses as defined in allocation.
- For example, 2% of a stake reward would automatically be generated and deposited to the treasury.
Surrender-Funding
Surrender-Funding occurs every time a user receives any type of earned reward.
Users receive rewards when they stake a block, Stake-Surrender, and when they receive their ERR, ERR-Surrender.
Stake-Surrender can be implemented in one of three ways:
1. Protocol-defined: A protocol-defined percentage of each stake reward is automatically deposited into the treasury fund address, addresses, or sub-addresses as defined in allocation.
- For example, 10% of a stake reward would automatically be deposited into the treasury.
2. User-defined: A user decides what percentage of their stake reward is deposited into the treasury fund address, addresses, or sub-addresses as defined in allocation.
- For example, user A could surrender 10% of their stake reward; user B could surrender 5% of their stake reward; user C could surrender 15% of their stake reward; user D could surrender 0% of their stake reward.
3. Combination: A combination of protocol- and user-defined stake-surrender mechanisms
- For example, 10% of a stake reward would automatically be deposited into the treasury while user A could surrender an additional 10% and user B could surrender an additional 0%.
ERR-Surrender can be implemented in one of the same three ways:
- Protocol-defined
- User-defined
- Combination
Stake-Surrender and ERR-Surrender can be implemented separately or together.
Combination-Funding
Combination funding uses both Generation- and Surrender-Funding protocols and processes. Part of the treasury funds are generated by the blockchain when GRC is minted and part of the funds are surrendered by users when they receive rewards.
Anti-Spam-Mechanisms
AS-Fee Funding Mechanisms can be implemented in one of three ways.
Protocol-defined: A protocol-defined percentage of each AS-Fee is automatically deposited into the treasury funds
User-defined: A user decides what percentage of their AS-Fee is deposited into the treasury funds.
Combination: A combination of protocol- and user-defined AS-Fee funding
Donation
Donation funding can be used to supplement Mint and AS-Fee funding. See side-staking.
4. The Gridcoin Treasury - Allocating Funds
The Gridcoin Treasury could operate through a single address that collects all funds and releases them as defined in the Releasing Funds section.
Alternatively, the Gridcoin Network could vote on approved treasury addresses. For this exploration, let us assume 5 official treasury addresses are agreed upon:
- Development
- Marketing
- Outreach
- BOINC Project Funding
- Gridcoin Grants
For simplicity, let us assume that Stake-Generation and AS-Fee Funding Mechanisms are implemented.
Funds raised through these mechanisms could be allocated through protocol-definitions, user-definitions, or a combination of the two.
Let us assume that they are allocated through a combination.
Let us say that the protocol defines that:
10% of all revenue generated by both mechanisms is guaranteed for development funding
5% of all revenue generated by both mechanisms is guaranteed for marketing funding
2% of all revenue generated by both mechanisms is guaranteed for grant funding
For example, let us say that a stake reward of 10 GRC generates an additional 1 GRC for the treasury. 0.1 GRC of that GRC is guaranteed for development, 0.05 GRC is guaranteed for marketing, and .02 GRC is guaranteed for grant funding.
Following, if a user performs a blockchain transaction that costs 1 GRC as an AS-Fee, the same breakdown would apply. In real implementation, a % of AS-Fees would likely be reserved for stakers based on protocol-definitions. We are ignoring this detail for this example.
In this definition, 17% of revenue generated by both Stake-Generation and AS-Fee mechanisms is automatically distributed to the appropriate treasury addresses as defined by the protocol.
The user would have the choice of how to allocate the remaining 83% of revenue generated through the Mint-Generation and AS-Fee processes.
Using the above example, a user receiving 10 GRC for staking a block would have (1 - 0.1 - 0.05 - 0.02), or 0.83 GRC from stake generation to allocate however they wished.
For example, of the 1 GRC generated from stake-generation, a user could decide to send an additional 48% to the Gridcoin Grants address, 25% to fund BOINC projects, 4% to further fund development, and 4% for outreach funding.
If desired, approved treasury addresses could be broken further into sub-addresses. For example, the BOINC Project Funding address could be broken into sub-addresses for each whitelisted project. Protocols, users, or a combination could determine how sub-addresses are allocated funds.
Each treasury address would have its own requirements and processes for its release of funds.
5. The Gridcoin Treasury - Releasing Funds
Whether there is one treasury address or multiple treasury addresses and sub-addresses, each address would have its own requirements and processes for release of its funds.
Let us continue with the example defined in the section The Gridcoin Treasury - Allocating Funds
We have 5 approved treasury addresses:
- Development
- Marketing
- Outreach
- BOINC Project Funding
- Gridcoin Grants
When an entity, group, or individual seeks treasury funds, or in the case of BOINC projects, seeks a treasury sub-address, they must write and submit a proposal.
This proposal must contain:
- Requested funds
- Timeline of proposal
- Fund release parameters
- Evaluation periods
- A reputation score (To be describe in a future proposal, if it turns out to be an idea worth following. In concept, this is an IF replacement -- Impact Factor is a rating of scientific journals that we can possibly put in a protocol. Developers with reputation have more say when it comes to verifying development proposals, marketers with marketing proposals, BOINC admins with BOINC project proposals, scientists and researchers with grant proposals, etc. I digress.)
...
The proposal is then voted on and either approved or rejected.
There are two main ways to release funds that the definitions in the prior sections allow.
Weight-Based Voting
When a proposal is approved, the funds requested by the proposal are released from the appropriate address based on the proposal’s definitions and the addresses defined processes.
A marketing example: A proposal could be presented to the marketing treasury address, which requires proposals to be broken into three phases. The total proposal request funds could be $100,000 USD. Phase one could be the planning phase and last 3 months. The proposal could request $5,000 USD for phase one. Phase two could be the building phase. Phase two could last 6 months and request $75,000 USD. Phase three could be the execution phase. Phase three could last 3 months and request the remaining $20,000 USD. The proposal could include evaluation periods at the end of each phase to determine if the endeavor should continue to be funded.
A development example: A development proposal could be presented to the development treasury address which requires security and stability audits for the release of the majority of requested funds. It could be presented in three phases and ask for $200,000 USD. Phase one could be proof of concept, last 3-6 months, ask for $2000 USD and require evaluation of the proof of concept. Phase two could be development and design, last 6-12 months, and request $73,000 USD broken into monthly payments with audits and evaluations every 4 months. Phase three could be implementation, last 4 months, and require a security and stability audit before the final $125,000 USD is released from the treasury.
A BOINC project example: A BOINC project could request a treasury sub-address. To qualify for a subaddres, the BOINC project must adhere to network defined parameters. Some examples of parameters are: SSL, verified identification of admins, and clearly defined goals. The project submits a proposal requesting funds from the BOINC treasury address coffers, let’s say $5,000 USD/yr. It could propose that this $5,000 USD is split into monthly installments and automatically released on a proposed date of each month.
Crowdsource Funding
Crowdsource funding is based off of concepts like kickstarter.com. An entity, group, or individual submits a proposal under one of the approved treasury addresses while following the required parameters. The proposal might be voted in, or could be automatically accepted so long as it adheres to a set of defined parameters. Either way, once accepted it is given a treasury sub-address. Once a proposal’s sub-address reaches its requested funding, the treasury funds are released. The idea here is voting with your money.
Using the same marketing example laid out in the Weight-Based Voting section, phase one would be funded once $5,000 USD was deposited into the proposal’s address. Phase two, once and additional $75,000 USD was deposited into the proposal’s address. Phase three would be funded once an additional $20,000 USD was deposited into the proposal’s address.
6. Side-Staking
With a side-staking protocol, based largely on PINK's protocol, a user can automatically donate any percentage of their stake or ERR to any address they wish, whether it is a treasury address or their kid’s address -- they do need some cash for university, after all.
Edits and Additions
Added on 1/22:
I want to add this question to the conversation:
How can the foundation funds be integrated to the treasury protocols and processes?
What if we lock the current GRC balance away -- it is GRC never to be touched. Then we use its interest to help fill the treasury coffers. Treasury funds are then released as defined in one of the possible implementations of the outline above.
So if the foundation has 30 million GRC and earns 450,000+ GRC/year, that 450,000 GRC is split by protocol among the approved treasury addresses. The 30 million is locked funds, essentially meaning it is taken out of circulation. This benefits everyone in the network.
Posted on Utopian.io - Rewarding Open Source Contributors
The conversation continues! Be sure to follow the github.
https://github.com/gridcoin-community/Gridcoin-Tasks/issues/202
self-upvoted for visibility
Wow. You put a lot of work into this, but implementing this stuff seems really hard.
You'd be surprised what a group of people working toward a common goal can accomplish... while still having fun.
Don't forget the having fun part!
I have no doubts that we can work through all of this and get something concrete proposed, voted on, and implemented. It may cost money, but we'll cross that bridge if and when we get there.
Here is an idea that could be added under Generating Funds.
Let's say a research institution has a grant that includes funding for computations on a large project, or a private corporation has a need to crunch through a massive dataset. The Gridcoin Treasury could have a mechanism in place for bringing self-funded computational work onto BOINC. The research institution or corporation could propose their idea to the Gridcoin Team. If it passes certain tests (legitimate computational work, etc), then the Gridcoin Team could provide the project with a path to quickly get their project onto a self-funded whitelist. The research institution or corporation could purchase GRC on the open market or directly from the Gridcoin Treasury. The purchased GRC would be used to fund the rewards for those who lend their computers to crunching the BOINC project. The Gridcoin Treasury could charge a fee for providing support to get the project to BOINC and integrating it into the self-funded whitelist.
For example, Company XYZ wishes to test a large dataset of potential biomarkers for genetic research. They see BOINC as a cost effective solution for the computational work. Company XYZ proposes their project to the Gridcoin Team and it is accepted (there may need to be an extra step for helping the Company to get the project into a format for BOINC work unit distribution). Company XYZ buys $1MM worth of GRC on the open market and/or from the Gridcoin Treasury. Their project gets added to a special whitelist for self-funded projects. Gridcoin participants direct their computing power towards the project. The rewards for generating RAC/magnitude are directly withdrawn from the Company's account that is held by the Gridcoin Treasury, i.e., the rewards from this project are not taken from the normal GRC supply awarded each day. The Company may wish to sweeten the pot to attract participants to their project by awarding higher levels of GRC for the RAC/magnitude than is typical with other whitelisted projects. Therefore, Company XYZ gets their computational work completed faster and sees quicker return on investment. When their GRC account is drawn down or the workunits are completed, the project is complete and taken down from the self-funded whitelist.
I'm adding this to the github thread so we don't lose it. Excellent idea.
My idea is somewhat based on what is being proposed with Golem. However, Gridcoin is already up and running (Golem is still in development) and could bring a solution to market sooner and with the proven technology of the BOINC system. Also, BOINC/Gridcoin might be more attractive to a different set of clientele than Golem, such as research institutions or clients with larger computing needs.
True regarding clientele.
Also, I think implementation in the Gridcoin network would be a bit different than what they end up doing with Golem.
Looking forward to folding the idea into a more concrete proposal in the coming weeks.
I'm sure there is a market for research institutions or companies that need a large amount of computation but don't have unlimited work units and/or need their work completed in a rapid manner. Otherwise a project with unlimited work units or a long time horizon could go with a standard BOINC implementation and have to work done voluntarily like the other normal whitelisted projects.
I do not support the current poll in the client discussing the treasury. I did not make the poll. This is not a proposal. This is a summary of potential paths. There is much discussion still to be had.
3/8/18
Note that the poll is also invalid because it does not contain an "Abstain" option as required.
Great idea! I support it.
Hello partner, I use boinc and the customer Gridcoin as an investor to win the gridcoins coins, will this change anything in the past projects?
should we all migrate to this proposal if approved?
No and no. This would just be an extra, optional service
Hello @jringo, Your contribution can not be approved because the repository which you are currently referring to seems to have only the
Readme.md
andLicense.md
. Please always confirm that you are writing to the correct repository before submitting a contribution. Thank you.[utopian-moderator]
Just to put a blurb from my github comment on this, but I think we're a little premature for a treasury. Beyond that, I feel a treasury is a central component, and that would make this just a competitor to fiat currency, with oligarchs controlling the big buckets of coins.
If something could be woven into the blockchain (minting system tied to voting maybe?), then that could help decentralize.
As it is, GRC and really most cryptos are at risk by early-adopter/foundation whale wallets at least as much as any exchange whale wallets. eg, MtGox liquidating 30k BTC and shifting the entire crypt market is expected, but when we willfully push our coins into someone else's wallet, it's a trust system. Eventually, we get to a point where it is simply not possible to ensure trust. Imagine of a country's central bank held all of the spare cash, and the administrator had free access, AND anonyminity.
Maybe that's a rabbit hole, but we've already seen what unregulated currency markets do (both fiat and crypto). For a currency to survive long-term, it needs to be intrinsically resistant to abuse, even in a zero trust environment.