![GRCHorizontal_Purple&Purple_Solid.png](https://res.cloudinary.com/hpiynhbhq/image/upload/v1516660071/jyl5tczranbotot4wmju.png)


The github thread for this outline proposal can be found [here](https://github.com/gridcoin-community/Gridcoin-Tasks/issues/202)

---

# The Gridcoin Treasury

**Table of Contents**

1. Introduction
1. The Gridcoin Treasury
1. The Gridcoin Treasury - Generating Funds
1. The Gridcoin Treasury - Allocating Funds
1. The Gridcoin Treasury - Releasing Funds
1. 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:**

1. How can we raise funds for Gridcoin protocol development and maintenance?
1. How can we raise funds for marketing and outreach for the Gridcoin protocol and network?
1. How can we raise funds for research, science, BOINC projects, and other endeavors that use the Gridcoin protocol and network?
1. How can we distribute these funds?

**What is Needed:**

1. A protocol or process to fund a Gridcoin treasury.

1. A protocol or process to release funds from the treasury.

1. 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_.

1. 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:

1. Protocol-defined
1. User-defined
1. 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:

**<Parameters To Be Defined By the Community>**
- 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.


<br /><hr/><em>Posted on <a href="https://utopian.io/utopian-io/@jringo/the-gridcoin-treasury-a-proposal">Utopian.io -  Rewarding Open Source Contributors</a></em><hr/>