# Community Token
Make Your Own Community Token
You can deploy your own Community Token on the Rinkeby network using our deployer (what are deployers?)Deploy Your Own Community Token
A Community Token is similar to Prime and has mostly the same features.
In addition, Community Token has more advanced Suggestions and voting.
# Allocated Voting
Community Tokens can use Allocated Votes with Suggestions.
All token holders receive a certain number of votes depending on how many tokens they hold. All holders receive at least 1 vote, according to the following table:
|1,000 or less||1|
|1,001 to 10,000||2|
|10,001 to 100,000||3|
|100,001 to 1,000,000||4|
|1,000,001 to 10,000,000||5|
...and so on. For the specifics on how this is calculated, as well as how you can adjust it, see Vote Calculation.
You can vote multiple times on one suggestion, or spread your votes on different suggestions.
All token holder votes will refresh once a week. In other words, even if you spend all of your votes, you will be given more votes next week. You can read more about how this works in Vote Refresh.
Community Tokens have an additional type of suggestions called a Proposal.
Proposals can have different meanings for different tokens, but they typically represent suggestions that the community has approved of, and will receive added attention.
# Creating Proposals
Proposals cannot be created directly. Instead, once a suggestion reaches a certain number of votes, it will be promoted into a Proposal automatically. Proposals have a second round of voting that works differently from voting on suggestions.
Voting on a Proposal can only be done once per week by everyone, and you can never vote twice on the same Proposal. However, instead of your vote counting for a single vote, the Proposal will get votes equal to your total token balance. For example, if you have 200,000 tokens, when you vote for a Proposal, it will receive 200,000 votes.
The number of votes required on a suggestion for it to be promoted into a Proposal is configurable.
# Vote Calculation
The default configuration for calculating the number of votes token holders receive tries to keep voting fairly equal, but still give an advantage to those who have a bigger stake in the token. This is achieved by using a logarithm. In practice, that just means that to have more votes, you need to have exponentially more tokens.
There are two variables that can be set to configure how many votes token holders receive:
allocationLogarithmis a logarithm base. Default is
allocationStartspecifies the scale. Default is
The number of votes a token holder receives is calculated using a simple formula:
The default value of
10 means that to get an additional
vote, you need 10 times more tokens. That is, if you get 2 votes at 1,000 tokens,
you'll need 10,000 tokens to get 3 votes.
allocationStart value determines the base value of how many tokens is
considered 1 vote. In other words, if you have 10 times
allocationStart in tokens,
you'll receive 2 votes, and then 10 times that will give you 3 votes, and so on.
# Special Values
allocationLogarithm can have two special values that normally aren't allowed
0will turn off the logarithm and everyone receives a single vote regardless of balance.
1will give everyone as many votes as they have tokens, divided by
# A Note On Approximation
Because Ethereum doesn't support floating point or decimal math, the logarithm is an approximation using whole numbers, and the result is rounded up.
For example, using the default values of
a real logarithm for a token balance of 1001 is:
The algorithm approximates this and rounds up, so the result is
# Vote Refresh
All token holders are given new votes after a certain amount of time has passed. By default that time is 7 days, so new votes will be given once a week.
The number of votes will reset to its maximum value for each token holder's balance. For example, if someone uses 2 out of their 6 votes, they will go back to having 6 votes available, rather than the votes accruing over time. This encourages people to use the votes rather than save them up.
The period of time for votes to refresh is configurable, it can be any amount
of time and is specified as number of seconds. The default is
is the number of seconds in a week (excepting leap seconds).
Lastly, the vote refresh doesn't get applied immediately after the time period has passed. The new votes will be available right after the period, but on the blockchain it won't be applied until the next time someone votes. What that means in practice is that after the 7 days has passed, the countdown to the next refresh won't start until someone votes.
For example, let's say the time period is one week, and the next refresh happens on Monday at 10 in the morning. The first vote then happens at 11 in the morning, and that's where the next time period will be counted from. That means next week the new votes will be available at 11 in the morning.