Inline with the proposed vision, we need to be able to scale the overall community to over a thousand individual on-chain communities which collectively reach a million on-chain members. There’s lots of work to be done!
I’d like to make a more concrete proposal (in response to this CTA) for simplifying Guilds, community funding and operations. Overall, there are 4 dimensions to this puzzle:
- Vision: Where this is all going. Posted about previously
- Operations: How to achieve the vision from a practical perspective. This post will cover this.
- Funding: How to get basic funding for communities and more specific funding for specific kinds of additional initiatives. This post will only cover the first part of this.
- Technical/Product: How to build the infrastructure we need to achieve the vision. This will be covered in another post.
Because we aren’t starting from scratch, I want to start by deconstructing and redefining the existing Guilds program, which merged together several concepts (services, communities and funding). I’ll then look at how we can retool some existing resources to support the scaled on-chain communities effort. I’m specifically not going to cover the back-end of how funding happens (just the front-end).
Deconstructing Guilds
Guilds were originally intended to create a container where communities could receive incentives related to how their activities align with the interests of the NEAR ecosystem overall and how well they support their members.
This Guild concept evolved last year to become more complicated. We also wanted to bootstrap key ecosystem functions like marketing, legal, development, etc that startups would need to survive, so we leaned into the parts of Guilds that were “doing work” for the ecosystem with their community-based teams. This was a good experiment but had mixed results.
Most importantly, this history meant that Guilds were actually several different concepts combined together – Community, Funding and Services – which muddied the water for everyone. It means that few people, especially prospective community leaders, have a clear idea of what exactly the Guilds program is and how communities on NEAR operate. That has hampered our ability to grow.
Thus, I think we should focus our energy on on-chain communities and acknowledge that Guilds are just one kind of these communities by shifting all website and other descriptions to use the “on-chain communities” term instead of “guilds”. Let’s also remove any extra language about providing services or extra special funding so it’s clear to anyone who wants to start a NEAR-based community that they can just plug in.
Guilds Today
The truth is, most of the 100+ Guilds we have today are communities first anyway. When I reviewed them, they roughly broke down into the following categories:
-
50% normal communities doing normal community stuff (like gathering around a specific project, tech, functional interest, etc)
-
30% regional communities (otherwise normal communities anchored in a specific region or language)
-
15% Service Guilds, meaning they primarily operate as talent pools performing services on behalf of the ecosystem or its participants (eg marketing, development, legal…)
-
5% funding pools dedicated primarily to funding other initiatives or teams
That means that 80% of Guilds are already primarily what we’d normally consider Communities of some type and don’t have a business model or major needs for outside funding. Many of them were also doing stuff that might require funding (like running twitter campaigns or events) but that’s not core to their existence.
So, for most existing communities on NEAR, this is just a change in terminology. But for potential new leaders, this is a major clarification which makes it easier to get involved.
Funding and Supporting Communities
You can easily kill the culture of a community with too much funding.
You need to fund them enough so the heroes who put in their time and energy to host events, moderate forums and otherwise herd cats can do this without creating unfair costs for themselves. BUT this should not be a fulltime job funded by outside capital… it should be intrinsically motivated. Any normal web2 or IRL community has people who step up and they do so for a variety of reasons like to be visible, to build dealflow for their startups/funds/consultancies, to provide a platform to teach, to meet people, etc.
When I started learning Ruby on Rails in San Francisco many years ago, I joined a wide range of communities and attended all sorts of meetups. None of these were supported by the “Ruby on Rails foundation”… they existed because people wanted to gather to learn and share and support each other. They were funded with pizza money by local companies and their members presented the cool stuff they built for fun and to help the community.
The basic operational funding for Onchain Communities should match the same kinds of funding that happens in those communities (which tbh looks more similar to sponsorship than “funding”). That means enough to help them pay for basic costs like pizza and tools without trying to hire people away from their day jobs.
Ultimately, the goal of funding communities is to reduce friction for starting and managing them so they can thrive but without creating a high dependency on a central funding mechanism for this. In our case, we need to make it easy and economical to start an on-chain community.
Funding Levels
Communities need to be funded to spark their creation and to encourage them to do the basic things that plug them in effectively to the NEAR ecosystem. To make things as scalable as possible, we need to keep it simple and remove as much subjective human interaction as we can.
I propose a very simple ladder, where the impact of a community correlates with higher levels of funding but the goal isn’t to support the whole community on the strength of that funding. Levels are:
- Off-chain Community: Just a group of people doing their best. Not funded in a special way and not (yet!) on-chain.
-
On-chain Community: A group of people whose community follows the permissionless NEAR community on-chain standard* so it is registered and its members “join” with their NEAR accounts. Tiered based on impact.
-
Basic: one-time $100 in $NEAR tokens micro-grant
- Community is on-chain
- Community has first 10 on-chain members linked to it (with some sybil protections enabled)
-
Active: $100/m in $NEAR tokens
- Community is on-chain
- Community has at least 100 on-chain members linked to it and 10 monthly active accounts linked to it.
-
Engaged: $500/m in $NEAR tokens
- Community is on-chain
- Has at least 500 on-chain members linked and 100 monthly active
- Leadership participates in forum discussions, votes and other meta governance
-
Basic: one-time $100 in $NEAR tokens micro-grant
This funding is specifically meant to cover the basic operations of the community and not additional variable costs like events or promotion. These numbers are just suggestions for a sense of scale and this would obviously shift over time as necessary.
At a scale of 1000 communities, as per our goal, the funding cost is thus in the range of $100-500k per month.
*: Not yet defined, but the community does not need to have a DAO to participate
Community Operations
If the goal is to help new leaders onboard and manage their communities, it’s very useful to have a dedicated team available. This team can own the fulfillment of this journey, both from a services perspective (answering questions, routing requests, etc) and from a product perspective (making sure this is all clear and easy to these leaders).
The sum of operational areas we need are:
- Education and Clarity: docs, Q&As, AMAs, moderation of meta spaces like forum and NEAR Discord, /r/nearprotocol, etc
- Product: websites, integrations [eg with wallets], standards development
- Funding: defining, administering, paying and following up funding requests, plus meta-funding for this effort itself
So, in terms of “who” should own making this possible, I suggest that the Concierges are already doing most of it anyway! The two new pieces are Product and Funding, each of which does require some real human oversight to be effective. This would mean either expanding what the Concierges are doing now to include some grant administration and product work or having another dedicated team available who can handle the extra stuff and work with the existing Concierges to support the more operational stuff.
To avoid unfairly pigeonholing the existing Concierges, I’ll call the team who would need to manage all of this the “On Chain Communities Team” and we can figure out what level of involvement makes the most sense from the Concierges.
Community Funding Operations
I don’t want to get too far ahead of the back-end funding discussion, which is deeper, but IMO there should be a dedicated fund which supports these basic community onboarding efforts, plus meta-community efforts like funding development of software. This fund is ideally structured as:
-
An endowment model where there is regular monthly funding provided from staking rewards, which can be scaled up as the community size and needs scale.
-
Onchain Communities Team handles the validation of new communities and triggering monthly payouts.
-
Onchain Communities Team subteams handle the meta and product/tech streams internally too.
-
A single Team Leader provides reporting and accountability for the funds, both to the community overall and the funding entity
These funds can be provided as part of the revamped Grants program, as described in a future post. The team overhead costs would need to be part of that grant as well.
Future Post: Community Product and Technology
To avoid making this even more of a mega-post, I’ll kick the can into another one to talk about the product and technical needs that support the community effort. Overall, the two biggest journeys are:
-
Prospective community leaders need to be able to discover, understand, create, onboard and manage their communities seamlessly.
-
Prospective community members (aka everyone on-chain) need to be able to discover, understand, join and participate within communities.
This will require:
-
Copy and information design for key community website properties
-
Standards development to underlie both the onchaining of communities and the linking of their members
-
Driving adoption of those standards among existing tools (eg wallets) and integrating them with new flows (eg tools for discovering and onboarding to communities)
Future Post: Beyond Basic Community Funding
This post only covered the bare bones community funding, inline with my goal to really separate out the basic community management stuff from the more advanced stuff. A key missing piece is now how to support valuable but less scalable community efforts like funding for events or other one-off activities.
I think these streams need to source from the standard grants pipeline, but via the hands of specific funding pools (including DAOs) which are specifically targeted to service those things. More details to come there.
Wrapping Up
So, just to reiterate, this proposal basically said:
-
Change pretty much anything that talks about “guilds” to talk about “on-chain communities”
-
Provide a very basic simplified funding framework for new communities, run by an Onchain Communities team (overlaps Concierges) and funded via an endowment grant
-
Onchain Communities team works with Concierges provides operational support for the community leaders and help ensure there is discoverability for these communities
Future posts will cover the details of the product/tech angle plus get deeper into setting up funding pools for more advanced things.
