Dismantling the core team and governance structure


Solicit ideas and approaches on how best to break down the current governance structure and replace it with something new. I pledge to help write an RFC and/or shepherd it if I can be convinced it will be an improvement over the existing structure.


Rather than making empty threats to “destroy the core team”, let’s instead embrace the thought and work together in the open to see if we can come up with a better governance structure to replace it with. It’s very possible that what’s worked well in the past may not be suitable for the future of the project[1]. The main reason we’ve evolved into today’s structure is because we didn’t see a better approach at the time, and I have no reason to believe it’s perfected or that improvements cannot be made.

Quick overview

(write below fixes and suggestions and I’ll add / update accordingly)

Some of the current responsibilities

  • Managing keys to general fund
  • Taking fund spending decisions, approving/rejecting funding requests
  • Administering & moderating the /mimblewimble GitHub org
  • Administering & moderating the forum and keybase
  • Managing non-public discussions like exchange listings
  • Adding/removing sub-teams, like security, wallet, node
  • Approving/rejecting project-wide RFCs, like governance

Some pros

  • Clear process to make decisions
  • Resistant to attacks
  • Focal point for project communication

Some cons

  • Point of centralization / single point of failure:
    • For consensus changes
    • For releases
    • For spending decisions
    • For RFC approvals
    • For project leadership
  • Negative feedback loop:
    • Creates “us” and “them” in the community, those on the inside, and those on the outside
    • This leads to the assumption that core team is “responsible” for the project’s direction and success, fosters complacency by non-core members.
    • This leads to more work for core team, makes it more tolling to be part of the core team, which reinforces the first point.

Flaws in the design

  • Core team members have the right to stay for an indefinite time, there are no terms.
  • Only core members can add new core members / remove existing ones.
  • There are no checks and balances. Community can protest and object in case of conflict, but nothing technically prevents the core team to going against the will of the community.
  • The system sucks up contributors. Either there are no new core team members added (which is bad optics). Or you add contributors that work hard in the community and are worthy of membership (which leads to only core members being the strong contributors, which reinforces the “us” and “them” which leads to bad optics and another slew of problems).
  • Because of the general lack of non-core engagement, it ends up being core team members that fill most the spots in sub-teams, defeating their purpose.

Some challenges / limitations with any approach

  • There’s a general lack of engagement and contributions
  • On top of that, there’s a lack of technical / developer expertise
  • Ignotus left abruptly, and took with him a lot of the legitimacy and authority of the project’s leadership. There is undeniably a power vacuum in Igno’s absence where there’s no clear leader to rally around.
  • We received clear show of support from the anonymous donor to “keep doing what you’re doing”, which means that I personally at least have a sense of obligation and duty to this donor to do what I think is right. I can obviously be overruled by others, but I’m not going to be bullied into doing something I don’t believe is in the best interest of the project.

My conclusion

  • It’s… messy.
  • For any replacement structure I think the two most crucial questions are:
    • How to handle the funds in the General fund (and its keys)
    • How to handle the GitHub org.

Money is what created most of the contention in the community, and is hardest to manage appropriately for a project like Grin. The rest can probably be figured out more easily.

Possible approaches

(come with your suggestions and I’ll update)

  • Return the funds to the anonymous donor
  • Burn the funds
  • Split funds to core team members and break up the band
  • Split funds between implementations
  • Open application process:
    • For funds with the purpose of having spent all of it before a certain point in time; or
    • For new “teams” to be formed, i.e. groups or individuals, each get an equal chunk of the funds and have to work in the best interest of Grin according to their best abilities.
  • Temp core teams, existing core team keeps the mu-sig keys but are not the core team any more. We have temporary core teams (say a new team every 6 or 12 months), that people somehow appoint, and they get a pre-determined amount to spend according to their best discretion, perhaps via filing a budget for it.

… what else?

My pledge

I’ll work with whoever wants to be involved in this thread, in good faith. If a proposal arises that I believe in and think will be an improvement over the status quo, I offer either to write or to shepherd a future RFC that introduces this and lobby for it.

I also pledge to heavily moderate this thread, so please stay on-topic and stay constructive, no bad faith rants or trolling will be tolerated.


[1] See for instance this article on the subject: https://a16z.com/2020/01/09/progressive-decentralization-crypto-product-management/


  • Sep 05: First draft

Thanks for getting this discussion started @lehnberg!

This overview is top notch. An excellent breakdown of the current situation, the pros and cons of it, and a thorough explanation of why things are the way they are. A few quick questions and comments about the overview:

I’m not sure I follow. What kind of attacks are you referring to?

Though we risk derailing a bit, it might be important to understand why there’s such limited participation, and whether this is something we can improve upon as a result of any governance changes that may take place. I’m sure there are a great variety of reasons why people are leaving the project, or why we fail to attract new contributors. I’m sure plenty of those reasons are beyond our control, but I’m also sure there must be things we can do to improve the status quo. Here’s some things we might have some influence over that could be a contributing factor (some only tangentially related to governance):

  1. Lack of visibility
    I’ve heard from numerous people who’ve said that Grin feels like a dying project, and I totally understand that feeling. There was once a bit of clout (even if exaggerated or altogether imaginary) that came from working on Grin. It was an exciting project with lots of attention. Now, the very very little publicity we get is never positive [1].

  2. Lack of adoption
    The price continues to tumble, more exchanges and services are delisting Grin than are adding it, and the community is shrinking, not growing. While some of the early contributors we lost are gone because of the lack of attention, most of them left when they found it was unprofitable. There were once a number of projects & businesses started around Grin that hoped to make a profit but are now dead or dying (vault713, cycle42, GrinGoldMiner, Galleon, superlinear, countless mining operations, etc). The potential for profit drives innovative ideas, but aside from a few exchanges and mining pools, there’s almost no chance of profiting off of Grin with its current usage and interest levels.

  3. Old guard discouraging new ideas
    It sometimes feels as if the earliest grin developers are stuck in the ways of the past, and refusing to adjust to a changing climate. The Grin community looks much different than it did in 2017/18 when Grin was being planned and developed by those with the optimistic belief that this was going to be a better bitcoin. There was a widespread belief that launching in the most fair way possible a beautiful & minimalistic protocol that improves scalability and privacy was all it would take to guarantee Grin’s place in the future. There are still a few key players who hold onto this belief, and at least seem to be actively combating new ideas they see as impure or never part of the original plan, despite the market very clearly indicating that purity is not nearly as valuable as believed. I’ve even seen claims like “the grin protocol is largely complete”. Many devs who hear statements like that, or believe new ideas will be written off because they’re not part of The Original Plan ™, will be naturally less inclined to work on the protocol.

  4. Paying devs discourages volunteers
    Having a few paid developers can be discouraging for outside contributors. Back when everybody was volunteering, and there was no central fund to pay for developers, there was little reason to be envious of others. It has been shown[2] that people don’t care as much about their income (or in our case, whether they’re being paid at all) as they do their income in relation to their peers.

  5. Not paying enough devs
    On the flipside, maybe we aren’t doing enough to make it known that funding is available to outside devs. Coins that have fancy quarterly budgets for community initiatives and clear guidelines for applying (eg. Zcash) seem to have no shortage of devs looking to contribute.


What makes you say this? I’m one of the largest critics of our current governance structure, and money has only ever been a secondary concern for me (unless by “money”, you’re just talking about Grin - A better money ツ). Funding has no doubt been a source of contention, but a much larger problem (and harder to solve imho) is centralized decision making. I personally got involved with Grin because I wanted a decentralized money with no kings, rulers, or federal reserve board members making all the decisions. What we have now feels a lot like a rebranding of the status quo. This is supposed to be a trustless & decentralized cryptocurrency, but having a centralized team with ultimate decision making power seems antithetical to what we (at least I) hoped to achieve.

Gotta get some sleep now. I’ll weigh in tomorrow on the “possible approaches” to dealing with funding and also start discussing ways to overcome the flaws and challenges you outlined, and the causes of poor participation that I mentioned. Hopefully we’ll also have suggestions from others by then.

[1] 18 Months In, Few People Use, Mine or Buy Privacy Coin Grin - CoinDesk
[2] https://www.researchgate.net/publication/43348242_Money_and_Happiness_Rank_of_Income_Not_Income_Affects_Life_Satisfaction


Some people seem to be forgetting that Grin is just an highly experimental project with absolutely no guarantee of success.

I don’t see the point to try to change it so some kind of get rich quick business.

I can see a lot of wishful thinking and day dreaming going on around. Let’s get back to earth and only invest what you can afford to lose.

Governance of the “core” implementation should be kept technical and development related only.

1 Like

Your comment adds very little value to this discussion.

Are you saying that because there’s no guarantee of success, we shouldn’t strive to make it successful? What a strange attitude to have.

Who said anything about making it a get rich quick business?

I’m not even an investor in Grin, so what are you talking about?

So they shouldn’t have a fund with 100+ BTC in it? What should we do with those funds then?

The market indicates no such thing. That’s just wishful thinking on your part.

No developer I’ve ever met has wished purity was less valuable. I would love nothing more than to make a nice, simple, pure protocol. But if it’s not usable by the people who are supposed to benefit from it, then it’s not very useful or valuable.

Anyhow, we’ll just have to agree to disagree here, I guess.


Core team is doing a great job even if i don’t really understand what they are doing, i trust them. on the other hand i see a lot of people like @david working on Grin ++, always here to help and improve stuff avg user can discuss. unfortunately he’s not getting paid for that and he doesn’t even care. i wish we had more volunteers like him. let’s be honest, avg users are paying way more attention to community projects than to the core dev, and funding these projects will help Grin gain more users.

my idea is to allocate some budget to create a new fund, and donators can have the choice between donating to core or community projects. each 3 month let’s say, we open an application for developers/creative/docs etc .
community then have to chose between improving an existant app, approving a new app dev, creating artworks, motion graphics, improving UI of an app etc.

this way we can have a good balance between technical stuff, and more concret stuff.

Thank you all

1 Like

An experiment should’t strive for success. Tweaking the results won’t make it successful. In fact, in real life, most experiments fail. Let’s stay humble here.

Seems like you are mainly focused on lack of visibility and adoption. This won’t change the results of the experiment. If the experiment is succesful, visibility and adoption will be there. Just like it did for Bitcoin. Let’s stay confident.

I wasn’t talking about you in particular :wink:

These funds were donated to the current “core” team, they should do whatever they want with them. We should respect the donors here.

Uh no. They donated it to the project Grin which boundaries go further then a bunch of guys giving themselves this status of whom two of them are pretty much afk for all the time.

They gave the funds to the owner(s) of the donation address private keys, pretty simple.

Everything else is wishful thinking.

Wishful thinking on your part. if they walk out with the funds this will be called an exit scam.

1 Like

It’s definitely a possibility :wink: And the donors have taken this into consideration.

1 Like

Sure it is a possibility and sorry I probably missed the cititations were the donators accepted that their donations where used for personal purposes of core members. Please quote the phrases from the donators that back such a statement.

But again… exit scam. That is how it would be remembered.

Please don’t agree to disagree. It sounds like you’ve had this discussion before, but I haven’t seen it and I’m very interested in it.

@tromp, why is that wishful thinking on his part?

The market does not tell you its reasoning.

Off-topic comment about price discovery and layer 2

Grin needs to have a price discovery mechanism based on Dex instead of relying on Cex. And Grin needs more technical exploration on layer 2.

mod: off-topic, hiding

Off-topic response to previous comment

If there only were trustworthy DEX that are truly private, decentralized and mainstream to begin with…

mod: off-topic, hiding

I probably missed the cititations

@bluimes you might find this thread informative Donation to the Grin General Fund - Nov 11

Let’s stop with the discussions about donor intentions in this thread now, unless it directly relates to a concrete proposal for a change. Those who want to discuss further are directed to open a new thread for this.


This thread is about:

How could we best go about dismantling the core team and the governance structure, what would we then replace it with, and how would this be an improvement to the status quo?

I see some topics above that are to some degree related, but not immediately on topic, such as:

  • What is the reason behind the lack of engagement and new contributions?
  • What are the most important design priorities of Grin?
  • What does the market value?
  • What’s the purpose of Grin?
  • What were the true intentions of the anonymous donors?

While many of these are interesting topics and deserve to be discussed further, I’d like to keep this thread from derailing. I urge you to open up new topics on the forum for them.

1 Like

Attacks on Grin’s governance. Governance is a massive security risk for any blockchain project. Example of possible attacks:

  • Sibyl, bribing, or collusion attacks on any kind of voting or signalling by community.
  • Attempts to gain control of mu-sig wallet.
  • Subversion of decision making process in order to gain unduly influence for personal gain, for example through changing emission, pow, and so forth.

it might be important to understand why there’s such limited participation, and whether this is something we can improve upon as a result of any governance changes that may take place.

To explain my intention a bit better, I listed the lack of participation as something that should be taken as a given, to avoid proposals for some new system that would rely on a large and active community of contributors, as this is unfortunately not realistic today.

It would be great to see proposals that can lead to improved engagement and contributions, perhaps this could be motivated as part of the actual proposal itself.

What makes you say this? I’m one of the largest critics of our current governance structure, and money has only ever been a secondary concern for me

Because to me, “what do we do with the mu-sig?” is the hardest question to answer, and I can see how it can become infected.

Adding to this, there’s been a lot of back and forths about

All of the above, relates to money, and the fact that the core team has control of some, which means we need to make (sometimes tough, sometimes easy) spending decisions. If we had no money, there would be no decisions to make, and less contention as a result.

The question “who decides what gets merged in /grin and /grin-wallet” seems to be way less contentious, and has easy solutions if it’s not working as it should: Developers can fork the repos or write their own implementation from scratch.

The question “who decides what Grin’s consensus rules should be?” is more complicated, but still much easier to reason about (at least right now) than Bitcoin - there is a process in which to propose and introduce consensus changes. And given that there’s been some clear design decisions and directives set out very early in the project’s life cycle (like emission, minimalism, scalability), there is definitely some kind of “checklist” for how we can reach agreement amongst ourselves for that.

Furthermore, regardless of the outcome of this thread, there are larger questions that we will need to figure out at some point. Right now there are two Grin implementations. What happens when there’s three, or four, or five? How do we reach agreement amongst implementations about the right rules, when to make changes, and how to do so? The current governance model doesn’t really account for this, there is no governance process between implementations.