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!
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.
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.
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.
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.
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.
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.
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.
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.
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 .
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).