The Gridcoin Treasury

[jring-o]

This is a combination of #187 and #191.

---

The Gridcoin Treasury

Table of Contents

1. Introduction
2. The Gridcoin Treasury
3. The Gridcoin Treasury - Generating Funds
4. The Gridcoin Treasury - Allocating Funds
5. The Gridcoin Treasury - Releasing Funds
6. 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?
2. How can we raise funds for marketing and outreach for the Gridcoin protocol and network?
3. How can we raise funds for research, science, BOINC projects, and other endeavors that use the Gridcoin protocol and network?
4. How can we distribute these funds?

What is Needed:

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

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

3. 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
2. User-defined
3. Combination

Stake-Surrender and ERR-Surrender can be implemented separately or together.

Combination-Funding

Combination funding uses both Generation- and Surrender-Funding. 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.

[G-UK]

Note I need to read through your post properly but seeing it pop up made me think of this I quickly threw together the other week (It then got put on the back burner). It's not ready for anything public and was just an initial brain dump but may be useful/related.

Gridcoin Expense Guidelines.docx

[jring-o]

@G-UK I will check that out when I'm near a burner.

---

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.

[hot-bit-git]

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.

Gridcoin protocol and network development funding is more important than limiting number of coins in circulation.
There was never-ending discussion in Dogecoin community (100B + suply; 250x the amount of GRC) - despite the number of coins Dogecoin market cap recently reached $2B. There are more examples - Stellar Lumens - 80% are still to be dumped (distributed) but Stellar is in top 10 most valuable blockchains.

[jring-o]

Here is the text from @G-UK's document posted above:

Gridcoin Expense Guidelines

This document outlines guidelines on how expenses are claimed from the Gridcoin foundation wallet.

Alternative funding such as through donations etc. should be sought to fund where ever possible.

Foundation Expenses can only be claimed for the following purposes:
Task Bounties
Core development (must show deliverable)

Proposed Expense

The claimant must put together a proposal prior to carrying out any work that they expect to be paid for which must then be accepted by the community via a vote in the client. The vote should be in the form:

(Expense) Do you approve this expense payment from the Foundation Wallet?
2 Weeks
Stake & Magnitude
Link to Proposal and Discussion (Github?, CCT?)
Options: Approve, Deny, Abstain

Vote must be approved by both vote share and number of unique CPID’s.

The proposal as a minimum should contain the following information:

• Expense Overview
  • currency that the expense will be calculated in (eg. GRC, USD, GBP etc).
  • The Total Expense value in said currency.
  • Length of project.
  • Wallet Address(s) where payments to be made.
  • Username(s) making the claim.
• Itemised Expenses
  • Line Item expense type (Receipt, Labour)
  • Line item value
  • Line item payment date
• Work to be done

Payment of Expenses

All currency conversions to GRC will be calculated on the payment date as specified in the approved payment schedule and be based upon the exchange rate that day.

Receipted Expenses: Will only be paid once the receipt has been uploaded to ??? and verified. Receipts may be submitted up to 90 calendar days after the date specified in the expense proposal, any claim after this point will not be paid.

Labour Expenses: Will be paid on the proposed dates once a self-certified timesheet is uploaded to ??? and verified. Labour expenses may only be claimed once the verifiable deliverable as defined in the approved proposal has been achieved.

Supplementary Funding

Any change to an approved expense proposal including change of timescales or additional expenses must be approved through the same method as a new proposal. This is intended to stop project creep.

[jring-o]

@hot-bit-git

Market supply doesn't factor into price as much in crypto as it does in other markets. It's too new, too volatile, and too bull. It does, however, give confidence to the market in that market participants don't need to worry about a massive foundation dump (an exit). Additionally, people looking around see frozen supplies as signs of commitment and future planning. This concept is built into steemit, for example. It is also a tactic used regularly in other endeavors both in and outside of crypto. A decent recent crypto example is Ripple.

I agree with you on priorities. The frozen circulation supply would be an added benefit, not the reason for doing it. And "frozen" things can be unfrozen based on defined protocols put in place at the time of freezing. I think it might be beneficial to reserve a portion of GRC for use at a later time. Say, 5 years or after a certain set of conditions are met.

The main goal of the frozen fund would be to create a "faucet" of sorts that can continuously supply funding for endeavors other than development, as opposed to a single lump sum that's used for everything and slowly dwindles into nothing.

I think the path would be to take the estimate cost of development over a year - on January 5th that was about 75,000GRC/mo, or 900,000GRC/year. This number is based on only a few months of data and since we pay in USD ($30USD/hr) will fluctuate with the price of GRC. I expect that this number will reduce drastically over the coming year, but for now let's use it as is.

The foundation has ~37,000,000 GRC. What if:

1. We reserve 7,000,000 for "immediate development"
2. We incorporate the foundation
3. We legitimately hire developers instead of the current freelance approach
4. we increase developer pay to $60/hr + subcontracting + code audits

This would give us 3-5 years of development at January 5th, 2018 prices with that 7,000,000 GRC.
This does not include interest earned on that 7,000,000 if we keep it in a hot wallet.

Following:

We would now have 30,000,000 GRC in a frozen-hot fund earning interest or CBR. We define a protocol that allocates that interest or CBR to the treasury system. Using interest that's 450,000 GRC a year that can be used for any approved treasury addresses or sub-addresses depending on the network's needs.

---

---

@G-UK

I love this. This will be very useful as we start to build funding/treasury structures.

My favorite ideas:

• Using vote share + CPID to approve a proposal: until we get around to really digging into the polling and voting system, I think this is an entirely reasonable route to take.

• The proposal requirements outline. I'm looking forward to building on this.

I think we could begin by developing and formalizing a proper Request for Development Reimbursement format or form and ask that developers submit all future reimbursement requests using the resulting product.

Note that this suggestion is for a request for reimbursement, not a request for development funding.

For those unfamiliar, a request for reimbursement is like when you are sent on a business trip and come home with a bunch of receipts that you paid for, and the company then gives you the money (assuming they are business related expenses). A request for development funding is like when you go to your boss with an idea that will cost money to explore, develop, build, and implement. Requests for development funding generally require a much more in depth process, which is why I think we should start with reimbursement. We can say that labor is a reimbursed expense, as we already do. Start simple, build on that.

[jring-o]

From steemit. User: rhoff

---

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.

[RichardHoffpauir]

My idea (from the steemit comment posted above) 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.

[jring-o]

I do not support the current poll in the Gridcoin client.
I did not make the poll.
I will vote no.

[barton2526]

The poll is invalid because it does not contain an Abstain option.

[xaminmo]

The budget/treasury ideas seem very... spendy. I think much of the discussion around a treasury is still based on centralized power over the coin. Trying to define too much of the budget right now looks more like a power shift between central authorities, and not any measurable effort at decentralization.

Do we want taxation and a foundation wallet as our long term strategy? I envision the long-term system being something where pay would come from blockchain. People could vote on whether to pay before, after, what work, etc, and the results would direct direct minting of developer coins. I think we would have several iterations of change to get there, but until then, the bounty system suggested by Toggleton seems a good step in the right direction.

Just brainstorming. I think there are plenty of architectural changes in the long-term pipeline that could support any option, and the long-term picture I painted is pretty complex.

[jring-o]

@xaminmo I think there is some confusion.

A treasury and a budget are two different things. A budget is about how much money comes in and how much goes out. A treasury is the funds held by an entity, and a treasury system can include the process by which those funds are raised.

With a blockchain, these processes can be decentralized, automated, and put in an open-source protocol.

The discussion around a treasury system is about creating income structures for the blockchain, which does not currently exist. It also explores how to release these funds to specific endeavors. This type of system exists in several blockchains and is actively being developed by many more. It does not revolve around spending any money because there is no money to spend. It's about decentralization and automation through a blockchain.

The discussion around the budget deals with two main things:

1. Finding a less centralized way to release funds from the foundation. It is currently extremely centralized.
2. Making a structure so we can properly manage the funds in the foundation.

The budget deals with the foundation funds, while a treasury is about making a blockchain protocol.

---

Currently, the treasury post above details a few different ways to raise funds for a treasury. One is similar to taxes as we all understand them. Another is exactly what you describe: pay coming from the blockchain. This is still a form of taxation, but it is a tax that is spread around through inflation instead of individually focused. Another is donation based. Another is bounty based.

---

I agree that a bounty-bot is a great first step in any direction, though bounty systems do have some problems.

[frank0051]

@jring-o , @jamescowens : Not sure if this is still a practice, but don't beacons and transactions costs just get "burned" (I.e. destroyed). If so, could we quickly put together a poll to at least allow for quick consensus that those should go to the Foundation?

[jamescowens]

This requires a mandatory, and it is a trivial amount, so no, I do not not want to do a poll on only this. It focuses attention on the wrong end of the problem right now. Fees for transactions do not get burned. They get paid to the staker. The contract burn amounts for polls, votes, and beacon advertisements, which are separate from fees DO get burned. Again these are small amounts.

…

Sent from my iPhone

On May 6, 2021, at 2:04 PM, frank0051 ***@***.***> wrote:  @jring-o , @jamescowens : Not sure if this is still a practice, but don't beacons and transactions costs just get "burned" (I.e. destroyed). If so, could we quickly put together a poll to at least allow for quick consensus that those should go to the Foundation? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[jring-o]

I agree with Jim. That sounds like a waste of effort and time.

It's already in this document, which has been talked about at length within the community, as well.

[frank0051]

This requires a mandatory, and it is a trivial amount, so no, I do not not want to do a poll on only this. It focuses attention on the wrong end of the problem right now. Fees for transactions do not get burned. They get paid to the staker. The contract burn amounts for polls, votes, and beacon advertisements, which are separate from fees DO get burned. Again these are small amounts.

@jamescowens : Okay, so we have an additional point that can be added to the treasury proposal then - even if it's just a couple hundred GRC: contract burn amounts for polls, votes, and beacon advertisements, which are separate from fees DO get burned could instead go to the foundation.

@jring-o : I don't see it mentioned in the above thread. Is there another document? Or am I misunderstanding some of the language?

[jring-o]

Anti-Spam Mechanisms (AS-Fees) - Fees generated by the blockchain to prevent DDoS-type attacks. Transaction fees, for example.

[frank0051]

Anti-Spam Mechanisms (AS-Fees) - Fees generated by the blockchain to prevent DDoS-type attacks. Transaction fees, for example.

@jring-o : Just for future reference, it may be worth simplifying the language for an average audience so it's a bit more assessible. I am fairly well educated, a native English speaker, have hung around this community for over 4 years, and am a pretty decent writer when it comes to concept notes and white papers for fiscal and economic issues; yet, I interpreted this to mean we would incur/charge new transaction fees that not currently in place now (or at a higher level than currently in place now) rather than re-directing the existing burned fees. I recognize this is a proof-of-concept type of writing, but just providing some "two cents" feedback for consideration.

[jring-o]

I'll work to clarify it as we move forward with the details. Using fees to do things is a great idea though. It will almost certainly be included in a more comprehensive proposal. Doing it alone does not make sense.

Also, keep in mind that burning coins does come with benefits that influence funding development.

[frank0051]

Also, keep in mind that burning coins does come with benefits that influence funding development.

@jring-o : I would be interested in understanding the benefits of burning coins further. Is it solely about creating scarcity?

[hot-bit-git]

" I would be interested in understanding the benefits of burning coins further. Is it solely about creating scarcity?"
Dogecoin case shows this "scarcity" narrative is often wrong. Burning in most cases is a gimmick. In case of Gridcoin, If we'll burn 1 GRC worth that come in fees, how it compares to thousands newly minted each day?
P.S. I'm working on a GRC related project I will share within a few weeks. It will allow for a huge leap. Stay tuned!

[frank0051]

" I would be interested in understanding the benefits of burning coins further. Is it solely about creating scarcity?"
Dogecoin case shows this "scarcity" narrative is often wrong. Burning in most cases is a gimmick. In case of Gridcoin, If we'll burn 1 GRC worth that come in fees, how it compares to thousands newly minted each day?
P.S. I'm working on a GRC related project I will share within a few weeks. It will allow for a huge leap. Stay tuned!

@hot-bit-git : Looking forward to learning more - make sure you share on the sub-reddit too ;-).

[jring-o]

Burning is not a narrative. It is a tool and should be considered for a complete economic structure.

Dogecoin is a narrative. A glorious narrative on crypto adoption. It does not work for a case-study in economics. ETH might be a better study.