Distribution & Dynamic Ceilings
In this post I discuss our Contribution Model, Status Genesis Tokens and how to earn them.
Please read our Whitepaper in English or Chinese for more details.
Why Distribution is Important
Tokens not only align incentives among network participants but also break down the barriers of traditional organisational structures. With the issuance of the Status Network Token we hope to foster the creation of the Status Community; a borderless tribe working towards widespread adoption of Web 3.0 technologies.
In order for token-based communities to be the most-effective, we believe a wide distribution of tokens is desirable. In recent events, however, we’ve seen one Token Launch finalised within just a few blocks, and total contributions limited to just a handful of addresses.
For us, centralisation is the antithesis of what we’re hoping to achieve. Ultimately, the vision of Status is to be open source software whose development and governance is dictated by its very own users.
For that to be the case, we need to ensure the democratisation of power not just by maximising the amount of token holders, but with token holders that believe in public blockchains and decentralisation.
Our goal is maximise both quantity and quality of token-holders. With Status Genesis Tokens we address quality by subjectively allocating tokens to those who have supported decentralisation, and with Dynamic Ceilings we attempt to favour smaller contributors over large ones, addressing quantity.
Status Genesis Tokens
Status wouldn’t be what it is today without the support of the Ethereum community. There has been many people who have helped out in not only code contributions but also cultivating the growth of the Status community.
We created Status Genesis Tokens (‘SGT’) as a way for us to say thank-you to all of those who believe in decentralisation and helped Status grow. SGT allows us to support free culture and meritocracy — to reward those who have helped out in non-monetary ways. SGT holders can redeemed SNT after the Contribution Period has been finalised.
51% of the total supply of Status Network Tokens (SNT) are available in this contribution period, with a maximum of 10% of the total supply being allocated to SGT. The total supply of SGT is 50000000.0 and at the time of writing 19132396.5 SGT has been allocated, or 3.83% of the total supply.
SGT is allocated subjectively by Carl and Myself — to learn more about SGT you can read our post Encoding the Status ‘Genesis Block’.
How can I earn SGT?
Between now and June 17th we’ll be allocating SGT to those who can prove they have helped grow or are a part of the Status community.
We’ve setup a bot in our #status Slack channel, that allows you to post your proof, and if you can convince 5 or more other community members to give you a :heart: emoji reaction you will get a :sgt: emoji reaction and SGT. Carl and I will manually review each and every submission who reaches 5 :heart: emojis so the system is not game-able.
Some ideas include: Contributing directly to our codebase, creating a video or writing an article about Status on your personal blog or Medium, inviting your friends to our Slack, educating others on what Status is, following us on Twitter or Facebook, posting about Status on social media, helping us out with translations, or contribute to our Wiki or Documentation.
Here are some examples of how people have already earned SGT:
Contribution Model
The second part of the equation is the Contribution Period itself, which begins June 17th. The approach we’re taking is a series of Dynamic Ceilings, which are designed to present hurdles for larger contributors, whilst at the same time favour smaller contributors.
Often the first idea people have is “well just limit the amount contributed per address”. The problem with this is that it’s trivial to generate addresses for practically free. We had thought of introducing Proof-of-Work into the addresses themselves (0x000…), meaning leading 0’s in an address would determine the maximum amount to be deposited by that address. The problem with this approach is you favour more technically oriented people.
Now lets review the two most popular approaches used by other projects to achieve similar ends.
Soft Caps
A soft cap is often a time-based closing period after a certain limit has been achieved, the idea behind this is it allows smaller contributors to enter during a time window after the allocation has been fulfilled.
Unfortunately this does little to stop a larger contributor from acquiring more tokens.
Hidden Caps
Another approach has the hidden cap, where participants do not know when the allocation is finalised, and will be revealed during the event . This makes it more difficult for larger participants to know how much to contribute in order to control the supply.
The problem with this approach is that it is possible to receive more than intended, and presents no upper limit to larger contributors.
Collect and Return
Another promising model being discussed is the ‘Collect and Return’ model, this is the idea that the total contribution amount is fixed, but the Smart Contract is open to contributions which can exceed the fixed amount. Upon finalisation, the contributions are adjusted by ratio and the difference of the contributions are returned back to their rightful owners.
The problem I see with this, is to do Collect and Return fairly, you cannot have a failsafe amount, otherwise it can be considered a hard cap that larger contributors can ‘blow out’ and achieve market dominance. This means the Smart Contract is open and holding substantial amounts of ETH which sounds like a nightmare from a smart contract security perspective.
Furthermore with this model you are incentivising people to contribute all their ETH for a larger ratio on return.
Dynamic Ceilings
With Dynamic Ceilings, we aim to take the benefits of Soft Caps and Hidden Caps and avoid their downsides. The easiest way to think about Dynamic Ceilings is as a series of mini ‘Hidden Hard Caps’ at specific block intervals.
Unlike Hidden Caps, we must first reveal a ceiling to receive contributions — this means we cannot receive more contributions than intended. Because we can time delay each ceiling, we can emulate the benefits of a soft cap.
The idea behind Dynamic Ceilings is to make it more costly for larger contributors, in the form of transaction fees with minimal impact to smaller contributors.
With Dynamic Ceilings we can limit the maximum amount that can be deposited for any given ceiling. This means that larger contributors would have to split up their transactions into much smaller ones, thereby incurring more costs per transaction. If a transaction goes beyond the ceiling, it is thrown.
To minimise transactions you would need to know the height of the ceiling in advance, but because they are revealed during the Contribution Period, they are not known. The margin difference between each ceiling starts to shrink as smaller contributors start filling up the allocation.
The initial ceiling of 12M CHF is intentionally large and made known to incentivise larger contributors. That is, during this ceiling they can contribute a larger amount in one transaction and therefore incur less fees.
Click here to read our Contribution Period Smart Contracts.
Designing the Curve
How we decide to design the curve and finalise the Contribution Period will not be made public. However I think some illustrations might help show how we could potentially structure the Contribution Period.
In this illustration we could potentially have a series of ‘mini-contribution periods’ spread over time. This could potentially help people over different timezones
Another way we could potentially write the curve is via a smooth progression, this would only allow smaller contributions as they would get filled up over time.
Closing Thoughts
Achieving fair and decentralised token issuance, given participants possess pseudonymous addresses, is non-trivial. With Blockchain Identity systems still in their infancy, many more methods will be tried and tested in the years ahead.
We hope our approach is an improvement over the ‘standard’ issuance model, but are keenly aware it too is not without its own shortcomings and assumes transaction availability. We feel humbled to be a part of this experiment and would like to hear your feedback.
