CC Fund: expenses, responsibilities, spending guidelines and follow-up processes

If you thought the plan was wrong you should have voiced that opinion at that time in the many discussions on the forum and on KeyBase. There it was decided by the majority to buy so many, way more that there were volunteers even when compensating electricity. So if you want to influence decisions, join the discussions and meetings that lead to these decisions.

1 Like

I came up with the original idea, lead the discussions, joined the meetings. I also did the same when the idea resurfaced… I’m not blaming anyone or anything like that. I’m correcting your factually inaccurate suggestions that they are hard to maintain (you plug them in and point them to the stratum server) or that there was some kind of lack of discussion or participation.

The moral of the story of this entire thread is that people with the keys spending large sums of money need to be accountable to at the very least keep an accurate record of spends. I don’t think key holders are responsible for bad spends (unused asics, MIA grounds keepers, unfinished dev), that is unproductive hindsight conversation and they were decisions made by the entire group. But key holders are being asked to fix their poor accounting and consider better spending practices.


Thank you to those who spent time to read and reply productively, you shared many different opinions and I will try to summarize your suggestions for the next CC meeting or the one after that, I encourage you to join us there to take part in the discussion.

Let’s start from the end, the topic most of you replied about is the miners and I probably could have explained it better in the original post.

I mentioned 2 different issues regarding the community miners, transparency and responsibility:

  1. Transparency:

This issue can be easily resolved if @Cobragrin as our GK will be able to gets access for the relevant information, it’s not too complicated, the information is just not transparent at the moment and it requires active action from CC members to make it happen.

Later we can discuss what it should look like or a template structure for “Community miners” reports under the GrinCC repo and the GrinCC website.

  1. Responsibility:

I mentioned this issues under “CC role definition” because it was never clearly clarified who is responsible for the ongoing maintenance, mainnet/testnet, reports, tech issues and the rest of the list I mentioned above, is it the community? If so, how? because it is impossible without full transparency and clearly definition of the roles.

The decision-making process itself was public, long and many members of the community participated and expressed positive and negative opinions. In the end the decision was passed because of the community support.

And the question “Have we really considered the long term responsibility of running a mining community farm…?” was for us, “we” as the community members.

@Anynomous explained it (CC meeting 2022-12-6) before:

I think it is important to clarify that these miners are in fact “community miners”. We bought them as community council, but the decision and responsibility is for the whole Grin community, similar to how this council is also just a representative body for the whole community. As such the council members should cut ourselves some slack and not always take the burden upon ourselves.


Any idea how much was mined? If you know when they were delivered, we could try and figure out what should of been mined and compare it to what is reported as mined. If there is a significant difference, then those who are mining and those who authorised it should explain themselves.

1 Like

I really appreciate the updates you provided, and thank you for sharing them on the Telegram group.

I’m eager to assist in translating the information for Chinese community members, but I have limited English proficiency.

If possible, I kindly request that you consider sharing the updates in both English and Chinese after the meeting. This would greatly benefit the Chinese community members who may have difficulty understanding English.

Thank you for your understanding and assistance.

I want to make you aware that I use a translation tool to communicate, so please let me know if any part of my message is unclear.

1) Feedback on the governance and the need for the CC and community to better check deliverables will be take to heart.
2) Respect our long term developers, but let @davidtavarez first wrap up his deliverables for the previous funding request, before moving to funding the next request.
3) Give biweekly bullet-point update/follow-up on progress
4) Explain to the community the relevance of features like PIDB and Nostr, their benefits for users. When a feature gets enough up-votes, move to a funding request for and a vote for the request. In this way we are certain the community is supportive of the funding request.

I want to post some suggestions here since there has been some criticism on how the CC checks the deliverables of funding requests and one how developers updates their progress on the deliverables of his funding requests.
Let me start with saying that some of the criticisms is deserved, although I think we should keep it general since criticism is on governance and procedures in governance and not specific to @davidtavarez who only happens to be the only full time developer governed by the CC.
he has contributed greatly to the project both as a developer and as a CC member and we should give him some slack and credits for that and not target him. But to get back to the criticism, yes we should be more strict in putting value to deliverables and checking deliverables and perhaps even move to paying per achieved deliverable, although I want to keep that to a separate discussion.

In his recent funding period, @davidtavarez got distracted by all the enthusiasms in the community for implementing Nostr as an alternative to tor. Nostr has many potential benefits. Not only is tor sometimes unreliable and requires bridges to work in some countries, but it also does not serve as a buffer/bulletin board to store transactions when a receiving wallet is not online. Wanting to work on Nosr is therefore understandable and might bring a lot benefit to the community, but it was not in the deliverables of his funding request.

Back to those deliverables. It is true that @davidtavarez got distracted and did not finish the client implementation and API part + documentation. I would therefore propose he works to wrap-up these deliverables to his and the communities satisfaction before applying new funding. Does that mean the work on Nostr goes unaccredited/unpaid? Not at all. I discussed it with @Mokhtar and he proposed we will first discuss which functions the community wants to be implemented and explain there relevance and then let the community up-vote if they want a feature and which to implemented first. I am quite certain that Nostr implementation will be funded at some point in the future, so all work done by @davidtavarez on Nostr will save him time when the funding request for Nostr gets approved. Below I will shortly discuss the two main functions that I think are relevant to be implemented in the near future. We will create separate posts to discuss them with the community and see if they want to support their funding, here I will give a short summary of them.

1. Partial Initial Block Transfer (PIDB).
PIDB is currently on testnet implemented for grin-rust and hopefully is soon stable enough to be brought to main-net. The benefit is that users will be able to download blocks when they first install their wallet and node from multiple peers. Many users experienced having to wait in some cases for a day to fully download the grin blockchain, or having errors when first syncing and needing to restart the whole process. Considering the Grin blockchain is < 3GB this means the current system of initially downloading the blockchain as .zip file from a single peer is slow and unstable. PIDB will allow nodes to sync with multiple peers making initial syncing more robust, decentralized and in the future with some tweaking it might become faster since you can benefit from the upload speed of multiple peers. Of couse we do not only want PIDB working for only a part of the nodes (the rust nodes), but for the whole network to reap its benefits. Therefore implementing it in Grin++ is important for the whole network
2. Nostr.
Nostr is a decentralized network protocol for distributed and free social networking system. Posts are particularly resistant to censorship and are cryptographically validated. As of April 2023, Nostr has 1.1 million users. One of Nostr’s main innovations is its concept of relays, software that sends, receives, and stores text messages. In the case of Grin this would mean that if a wallet is offline, that he download transaction slates when going online from the relay. So Nostr not only serves as an alternative transfer protocol but also serves as sort of a bulletin board.

Regarding follow-up and updates on developments. As agreed in previous CC meetings, he can keep us updated with a few bullet-points update each two weeks or so. Apart from that I think @davidtavarez should be free to work in whatever way he wants, as long as the final deliverables get merged on Github in the end. Yes, it would be great to work with commits, but in the end who cares as longs as the final code is released.

This is my personal opinion and proposal to move forward while taking in consideration the recent criticism on governance by the community, feel free to give feedback.


I like this post, well done putting it together.

I think the biggest issue with the whole project is the lack of direction. People have their own interpretations of what Grin is, so we get pulled in different directions and it’s hard to come to a consensus on many aspects, including development. Which I guess is also the beauty of the project.

Re CC Spending guidelines/ CC Role Definition

  • Spending guidelines should be reviewed. Happy to see suggestions made here. I like what @renzokuken has suggested. For me, the key thing about spending is that it’s inline with the original donors request:

  • My opinion re the CC role is still what you’ve quote me saying

I would also suggest a periodic review of CC members, so being on the CC becomes an elected role with a “term” period ( This in itself should be more motivation for CC members) new members then have the opportunity to join at the end of each term. We don’t want the CC to turn into some old boys club where the wider community feels let down and is questioning our transparency. This would also make the whole community more accountable as a whole.

I also think the CC should have an elected President or someone incharge of overseeing everything, including the GK duties. Like a stripped down role of what Daniel used to do( which for reference was more than what the CC paid for the trial period with 2x GKs and one of the reasons why I approved the requests). Having someone akin to a President seems the best way to improve transparency and hold the CC more accountable. It would be great if we had people step up and do mundane admin tasks without funding, but the reality is most projects pay people just to manage their discord/ telegram groups. Although clearly Grin is vastly different to most projects.

Spending/ bad decision making

  • For me the purpose of CC having funds was so the community could fund development outside of the core protocol and to allow Grin to be more experimental. But outside of Grin++ there hasn’t really been any direct funding requests for dev work( CC picked up the funding for CoinSwap, but this was something OC would have (likely ) funded aswell, we just took action on it)

  • The Miners have turned into a logistical nightmare and was poorly executed by CC and ultimately a mistake on our behalf( at least so far) . It was a large financial outlay aswell, fortunately BTC was at much higher price when this was executed. It’s also not as large of an outlay when you consider we’d previously paid the equivalent of 120k per year for a fulltime rust dev. Part of the logic with the mining farm was that we wanted to encourage funding requests in Grin or atleast in a % of Grin ( Many used to complain about all the funding being granted in BTC, that it was misaligned and that devs should be funded in Grin). The intention of having the miners, was so we would have Grin available to do this, as opposed to having to buy it on market.

  • Even with clear guidelines, It’s still be hard to gauge on what should be granted funding, especially with the ongoing funding to Grin++. How do we ascertain what is justified/ what is best for the project? It seems many are split on their opinions here and there’s no right or wrong answer.

Commitment/ Engagement/ Decision making

It’s hard to find community members who actively engaged in the project, motivated enough to always been around to offer their opinion and actually take action. On a personal note( As someone in the Grin community) I’d like to see people like @renzokuken @vegycslol @johndavies24 on the CC, perhaps even yourself. CC needs more technical people to help make better funding decisions and needs long term community members with conviction to help shake things up.

^Obviously @Cobragrin aswell


As requested by @l33d4n in the CC meeting of 24th of May, I will post this summary here:

Summary on Governance improvement

1) Finance reports were not up to date and need fixing.
This should be taking care of now since @cekickafa will get admin rights to the GitHub page. CC members have merged the finance overview pull requests.

2) Spending guidelines, are they followed?
Yes and no. The spending is properly done, but the CC and as community should do a better job at defining and checking deliverables. I discussed this with @l33d4n and we want to make some changes to the Grin CC description, clarifying which responsibilities council members have (key-holder and preferably active community members), but decision making, checking deliverables and reviewing are a community effort. Clarifying this should avoid differences in expectations.

3) Checking deliverables
In case of recent Funding Requests, like the one from @dtavarez we did not yet check the deliverables, while a new funding request was made.
I therefore propsed to first finish the deliverables before moving to any new funding request.

4) Change the way we move to funding requests
After discussing it with @mo5ito and also as part of what was proposed by @renzokuken, we will first discuss features on the forum, only if they get enough support from the community, we will propose to move forward with a funding request. For example, we will discuss Nostr and PIDB in separate posts with the community to see if there is support for implementing them in Grin++

5) Community mining farm. Update for transparency and clarify who has the responsibility for the farm.
In short, all miners except G1 are now in a professional mining farm where we pay 30% of mined Grin for electricity and housing. A fair and honest deal, in practice this means we pay something like 0.04$ per kWh + free housing.

6) Funding Requests VS Bounties OR something in between?
We will have to discuss again the funding models, Funding Request versus Bounties. Should we put bounties on deliverables and only pay afterwards or is this the path to lose the few developers we have…? That is something we should not easily change. A lot of previous discussion on the topic needs to be red in order to shape one’s opinion. Feel free to reopen this discussion in a separate forum post


Bounties will make it much easier, also whole process can be more transparent, CC projects just need better management to understand status, I am sure we will come back to this topic again when more projects will come, this is why I suggested to create Kanban board for CC projects at Github to know who is working and where.

It opens some kind of hackathon format: everybody can come to help anytime if some part of project is slowing down or has problems, having all information at one place is much better for project management and transparency for whole community.

It can be based on project I guess, if developer needs hardware for example. As we said before actual development cost is zero, only result matters.

This increases responsibility and motivation, cause developer knows he will just not get his reward if work will not be done.

I still think we need some kind of Code-Of-Conduct for CC projects with rules, it deserves single separate post, I agree.


Thank you again. I’ll address to @Neo and @Anynomous replies together about the issues from the original post first to keep it short, hope it’s not mixing things up:

CC Role definition / CC Spending guidelines:

@Anynomous pushed PR that defines the role of the CC members:

Grin Community Councilm members are primarily representatives of the community and are keyholders of the community funds. … Decision making on funding request as well as defining, checking and reviewing deliverables is a community effort.

We (as a community) will have to take a more active part as mentioned above but I think It is important to add a clarification that the responsibility of the CC members (as the keyholders) is to approve only expenses that meet the spending guidelines.

Just to make sure that the “final word” is the spending guidelines to avoid misunderstandings what can/cannot be funded. It makes sense?

@davidtavarez explained it better a year ago:

GK duties:

if we clarified the responsibility of the CC members as keyholders, it’s basically transfers most of the responsibility to the community, and the GK as part of his duties will publishes regular updates to keep the community informed about the mentioned topics:

Right now I’m just trying to solve the issues from the original post without additional expenses or changing the rules so I think the one GK role covers it. Let me know if you think we should add or change something.

Transparency reports:

I asked @Cobragrin about the GRIN wallet report, he explained to me that he does not have access to the GRIN wallet and he got the records from the CC members, but…

I tried to verify it again after the last merged PR from 2023-05-24 (2 days ago) but when calculating the total revenue - total expenses we get -240,478 GRIN while the stated current balance is 128,307 GRIN

@Anynomous Can you please update the GRIN wallet missing records first to solve this issue?

Mining reports:

Can we add “Mining report” under the Docs repo or maybe a new repo?

Paying 30% of the base currency makes the accounting work easier, so basically this is a one time task (info file + list) and then only requires a regular updates from the GRIN wallet report so it doesn’t add any ongoing administrative work but solves all the transparency issues.

Decision making:

The engagement with this post is an good example how the community members share their opinion and engage if they understand the topic or if it’s enough important to them.

For example, we can improve the community engagement as suggested in the replies of this post:

Personally, I’m not sure what is the “best way”, but we can be sure that once the information are more transparent and accessible, the community members will be able to share an opinion and contribute to the discussions.

Some of us may even be able to contribute code or take part in other things.

Funding requests vs Bounties:

I think that this post proved that the funding requests method is much more complicated, especially when we can’t enforce it, make sure what the end result will be or what will go wrong along the way as happened several times. It worked, until it didn’t.

The question that needs to be asked is, why put community funds at risk in the first place?

Bounties reduces the risk to zero and simplifies the whole process with a clear definition for the end result, so we can avoid unnecessary arguments and dramas:

There are still issues that need to be discuss (thanks to @renzokuken who explained above) but I think the community supports the need for changes, at least in this post.


I am aware the total does not add up, I also tried to find the mistake before. It is unfortunately not so easy to find the problem, but the total amount is always correct and verified since there are two CC members with access to the wallet. My guess is that I forgot to put a minus somewhere, but that is just a guess.
I had to recover the Grin CC wallet multiple times due to errors in the wallet. Each time I recovered, I lose the whole history of transactions that involve spend UTXO’s. Since we actively use the wallet, this means most historic transactions cannot be seen after a restore. Grin wallets do not have a record of all transaction on the chain, unless you run a archive node which does contain a record of spend transaction outputs.

The solution for the long run is clear, but involves some work that I do not have time fore right now.

  1. I have to setup an archive node
  2. write some code to convert the transaction history (JSON) to a .csv and drop all the fields that are not relevant or privacy leaking.
  3. Manually merge the automatically generated transaction table with the current wallet overview which contains the metadata/descriptions for transactions.

I just updated the description to specifically mention that spending have to be in accordance to the Spending Guidelines

1 Like

Source: Trust me Bro.

1 Like

I will take care of the mining reports once I get access to the Github repo, as mentioned at last meeting.

I think irregularities has happened becuz of piling up review of reports. Short time intervals for ex. 3 months period will solve this.

:joy:. Tust two CC members :wink:. But working on getting that archive node running.