Feedback on NFT Community Tokens

Introducing Community Tokens

The Radicle Funding team has developed a design for NFT-based “Community Tokens” which will allow FOSS projects (initially just projects on Github or Radicle) to sustainably finance their operations. Supporters will purchase Community Tokens with the understanding that keeping them active requires a monthly contribution to the project, governed by the NFT. In exchange for their support, token holders will gain influence over the direction of the project through Snapshot polling and may also gain access to special, permissioned content and/or support.

Radicle Funding also includes an optional feature called “Drips”, which allows any project receiving support to “spread the love” and pass along a small percentage of its funding to one or more other projects or addresses. For example, a project might choose to Drip funds down to another software project that it depends upon, or to an individual contributor who has committed a large amount of code. Or to a researcher who wrote a paper that inspired the project in the first place.

A full set of wireframe mockups for the Community Tokens UX can be seen here.

To follow along with development of Radicle Community Tokens, please visit our Discord channel here.

We are seeking feedback from the community on this design and would love to hear your thoughts and ideas!

How It Works

At a high-level, the process works like this:

Using the Radicle Funding Registry Contract, any open source software project can register and deploy a special type of ERC-721 smart contract that allows it to issue Community Tokens. When the contract is created, the project must specify a minimum monthly support amount and also a “sustainability goal” which is the total amount of monthly support it hopes to receive.

Supporters are then able to interact with the smart contract to purchase NFT Community Tokens. Each supporter purchasing an NFT token chooses a monthly support amount that they would like to give, which must be more than the minimum specified by the project. The cost to purchase the token initially is just the first month’s payment of the chosen amount.

The supporter receives the NFT, which functions as a badge of support and also unlocks (soft) influence over the project through polls on Snapshot, as well as access to permissioned project-related content. Influence is granted to supporters in proportion to the size of their monthly donations.

At any time, the supporter may choose to transfer a quantity of DAI into the community token. That DAI is then treated like an account balance and used to cover future monthly payments, similar to a prepaid phone card. Each token must always have enough DAI locked up to cover monthly support fees when they come due, or the token will become inactive.

Identity and Authority Model


Supporters are identified and authorized using ordinary Ethereum addresses. Whichever Ethereum address owns the ERC-721 token is considered to be the supporter. Supporters can also choose to associate an ENS name with their Ethereum address, and in such a case the supporter could also be identified by her ENS name as well.


Project identity and authority are also managed using Ethereum addresses. In particular, the Ethereum address that creates the project is taken to be the owner of the project. All privileged functions in any ERC-721 contract created as part of the project can only be called by this address.

In the future, project maintainers will be able to utilize a Gnosis safe to achieve multisig-based control over a project. However, because app-based support for Gnosis safes in web browsers is currently limited, for now, from a practical perspective, most projects will likely be owned by a single address. With that in mind, the Radicle Funding registry provides a function that allows the project to be assigned to a new owner address in case the owner wants to transfer control of the project, or rotate their keys.

Radicle Orgs

If project maintainers wish, they can choose to associate the project to a Radicle Org. This is accomplished in a similar way to how Radicle Orgs are associated with ENS names. Namely, through a two-step process where the Project must make a call to set its Org address to point to the Org and then also set the Org metadata to point to the project.

Github Ownership Certification

If the project repository is hosted in Github, the project maintainer may (optionally) choose to add a Radicle Funding certificate file to their Github repo in order to prove ownership of the project and to build more trust with project supporters. Proof of ownership is accomplished through the use of a signed certificate (signed by the owning Ethereum account) placed in the project’s Github repository.

Token Model

Token Standard – ERC-721

The Community Tokens will be built on the ERC-721 standard. When a project wishes to issue a Community Token, it does so by deploying a specific type of ERC-721 smart contract that supporters may interact with to mint Community Tokens for the project.


Once a project creates a community token contract, supporters may mint a new token at any time by purchasing a new token from the contract, as long as the minting limit has not been reached. To purchase a new token, the supporter simply pays the support amount that they would like to contribute for the current period (which must be more than the minimum specified by the project) and receives a Community Token in exchange. The supporter must then continue to pay the monthly support amount each month for that token, or it will become inactive.

Funding Period

The funding period is monthly for all projects (30 day cycle). When one funding period ends, a new one immediately begins.

Supporting a Funding Period

A token holder will support a funding period if she has at least the minimum amount of required DAI locked in the NFT at the start of the period. In addition a user can lock additional funds into the NFT to pay for upcoming funding periods.

Alice would like to support with 10 DAI per month.
She locks 100 DAI in the funding contract.

The support would be invalid after the end of the 10th month.

Increase or Stop Funding

Funding can be stopped for an upcoming period by withdrawing some or all of the locked funds (the token will remain active for the current funding period, which has already been paid). If there is an insufficient account balance to pay the minimum at the start of a new funding period, the token becomes inactive. Inactive tokens can no longer be used to vote on Snapshot.

Sustainability Goal

When a project reaches its sustainability goal, the maintainer can choose to:

a) Disallow minting of any further tokens.

b) Continue raising additional funds like nothing has happened.

c) Do something with the extra capital in a programmatic way.

Project Attributes

The following variables will exist at the project level for each Radicle Funding project.

Value: Owning Address – The Ethereum address which “owns” the project and which is authorized by the registry contract to execute privileged functions.

Value: Owning Org – The address of the Radicle Org that owns the project. Note that the Org metadata must also be updated to point to the project in order to complete the two-step process.

Value: Sustainability Goal – Amount of DAI which defines the sustainability goal of the project in terms of monthly recurring support.

Value: ENS Domain – The ENS domain for the project. Note that the ENS metadata must also be updated to point to the project in order to complete the two-step process.

Value: List of Drips – A list of all drips for the project. Each drip specifies an Ethereum address and a percentage of the total project support that should be passed along to that address.

Function: Change Owner Address – Changes the Ethereum address that owns the project.

Token Attributes: ERC-721 Contract-Level

These variables will exist in the ERC-721 contract for each type of community token issued by the project.

Value:Type Code – the code used to indicate which type of community token it is. This is intended to be used by projects that wish to offer multiple types of community tokens, in order to distinguish them.

Value:Minting Limit – a limit to the number of active tokens that can be minted at any time. This could be used by projects to offer “limited edition” community tokens of a certain type, for instance, or by a project that did not want to raise more than a certain amount of funds, or to incentivize early supporters.

Value:Recurring Payment Required – a boolean flag indicating whether the token requires the supporter to make recurring monthly payment to keep the token active, or whether only the initial purchase price payment is required. If this is set to false, sale of the token will be a one-time fund-raise rather than a signup for an ongoing subscription.

Value:Minimum Contribution Amount – the minimum contribution amount that a supporter must contribute each month in order to keep a community token of this type active .

Token Attributes: Each NFT

This section contains variables which may have different values for each individual community token.

Value:Support Amount – the support amount for the token is an amount of DAI that the supporter commits to pay on a monthly basis to the project issuing the token. The supporter recognizes that if they do not pay this DAI, then their NFT will be invalidated and will no longer confer any benefits in terms of influence or access. If the supporter wants to change their support amount, the easiest way is to purchase a new token of the same series/type with the desired support amount, assuming that the minting limit of that series has not been reached. If that minting limit for the series has been reached, then the user can either use the “split” functionality, in case they wish to decrease the support amount. Or if she wishes to increase her total support, the user can purchase an additional token from a different series of project tokens if one is available.

Value:DAI Balance – the amount of DAI currently locked into the token. The token holder can always add DAI to the balance, and can always withdraw it, up until the point where it is deducted each month to cover the project support fee.

Function:Is-Valid – this is a boolean status code on the token that indicates whether it has been invalidated based on a failure to make a quarterly support contribution. In the implementation this might be a function based on the last-payment-timestamp and the amount locked in the contract. Once a token has been invalidated, it can never become valid again (although a supporter can always purchase a new Community Token at any time).


I love the idea that a github badge could be a go sponsor me via radicle link.

As radicle doesn’t have a pinning feature in IPFS (that I am aware of) can the act of ‘staring’ a project mean that you’re willing to peer that project? - that would be pretty cool way of supporting a project in a non-monetary way.

What exactly do you envision these polls to be about?

Freaking awesome post!
This is by far the feature I’m most anticipating.

Quick feedback on the UX below (I’ll try to respond more substantively on other details later).

Project Tab

  • Is it a good idea to put GitHub on the same footing as Radicle here? I’d say it’s worth exploring either of the following:
  1. Harder: Lead with Radicle link and instead have a button that says something like “Migrate from GitHub?”, which then leads to an entirely new flow (with as few steps as possible) to help users migrate their entire repos onto Radicle.
  2. Softer: Keep the GitHub button as is, but introduce a modal page that pop-ups, kindly asking if users want to (a) continue with GitHub or (b) migrate their project. This is probably the more friendly option.

Fund Tab

  • I wouldn’t be able to complete this page without hitting up the team to ask questions. Is the goal monthly? Is the minimum monthly? Is the minimum a flat rate for any supporter or is it variable by some usage metric (think AWS usage)? How should I think about this entire page? I think it’s worth sprinkling in a bit more things like tooltips or maybe in-line text explaining each section.

Drips Tab

  • More or less makes sense. Might be nice to have tooltips explaining what the % is of (e.g. “Drips will automatically send overflow funds to other addresses you add here. For example, let’s say your funding goal is $100 per month, but you end up with $200, so an excess of $100. You’ve added 2 drip addresses, one with 75% and one with 25%. This means the former will get $75 this month, while the latter will receive the remaining $25.”)

Project A - Example

Nice. Love this.
One question: what are the units for the “Funding” (8.6K) and “Goal” (10K)? Is that DAI only or can be something else?

Slide 8

I don’t really get what the “Funds” tab is.
Is my understanding below correct?

  • Project = a project I own
  • Funds = other projects I support
    If so:
  • What happens if I withdraw my funds?
  • Is “Funds” the best word for this 2nd tab? I got a bit confused like “Is this my funds for my project? Or is this someone else’s project that I’m funding?” Like, directionally, it’s a bit vague.

Overall, this experience looks dead simple, which is awesome and seems to be the secret sauce of Radicle!

I think a FAQs section (slide 9) is great, but I’d really recommend tooltips that pop-up. I think this would ameliorate a lot the most basic questions people have right then and there, without the need to navigate to a FAQs section + ask people on chat/forums.

1 Like

Hey! thanks for the feedback @bordumb.

Yes, for the sake of brevity, the wireframe omits tooltips or help text, but they will be essential :slight_smile:

All monetary units are in DAI (we don’t plan to support other currencies in the first version.)

When creating a new project, in the Fund Tab/Step, the goal and minimum are monthly* based, and totally up to the project owner(s).

Interesting idea about the GitHub > Radicle migration modal. In general, we’re trying to minimize barriers to start a funding project and are currently agnostic on where code is hosted.

One initial question I have around these NFTs is:

Is there some sort of incentive tied not just to the amount a supporter gives but the timing of their support?

For example:

  • Supporter A gives $100 a month. But they were the 1st supporter ever and instrumental in getting the project off the ground 5 years ago
  • Support B gives $100 a month. But they were the 10,000th supporter and just started giving money last month

Will both of these supporters have the same “influence” score?

Put in other terms, is there a mechanism to incentivize people to support as soon as possible, rather than wait till later and essentially act a bit like free loaders in economics terms?

One good example I’ve seen is this is with Curation on The Graph where they issue “shares” to Curators, which are weighted to the amount + when they started curating on a subgraph.

Great question! We intend for the design to be flexible so that this is up to project maintainer to decide based on how they configure the community tokens.

I’m not sure we can anticipate all of the ways that projects might use the polls feature, so we’re excited to get an MVP in the hands of projects to see what they do.

With that said, I think one main use case we envision would be around prioritizing new features and bug fixes. When faced with a choice of which feature to build next, it can often be difficult for project maintainers and devs to easily get feedback from their user community about what should be built first. We think that the polls could help solve that, and especially help align project roadmaps with the needs of users who are most likely to support the project (and the maintainers/devs) with funding.

That is freaking awesome!

It will be interesting to see how everyone shares best practices across different use cases.

Have you thought about distinguishing between NFTs based on the amount a supporter contributes to a project? i.e. the higher spenders get an NFT thats different visually but also grants the holder other benefits (i.e. swag, etc.)

I am curious about the train of thought behind the decision on going with an erc721 vs an erc20 (where support can be quantified by contributed amount).
EDIT: @lftherios was kind enough to point me to Why Use NFTs for Project Membership?

It’s true that to the eyes of the funder, this will look better, as all funders will be “equal”, except if various NFTs can be issued based on the amount of contribution (e.g silver, gold, platinum, etc.).

I think that an important aspect that it’s worth pursuing (perhaps after MVP) is a system that incentives early adopters/funders. In essence, $100 in the project early on should not be the same as when the project is in series A. This “invest”-like system could have interesting effects that are beside the point of this post.