Yesterday I wrote a post where I wanted to talk about what I feel is the greatest risk to stake holders in a Hive Engine Tribe but I got side tracked talking about how easy it is to mess with the market cap of low volume tokens.
Today I want to talk about my original thought, how tribes are at the mercy of their owners and propose a solution to minimize this risk.
The problem
When a tribe is created there are a few parameters selected to configure how the reward pool will distribute tokens. There are two key parameters rewards_token and rewards_token_every_n_block. These two parameters determine how often tokens are automatically issued into the reward pool which is then paid out to pending posts.
rewards_token specifies how many tokens are issued and rewards_token_every_n_block specifies how many blocks these tokens are issued. Each tribe defines these differently but combine the two parameters create the core parameters for the inflation in a tribe.
There are two more interesting parameter that controls how much the reward pool shrinks as time goes on. 'reduction_every_n_block' specifies how many blocks the rewards get reduced and reduction_percentage determines by how much.
Let's use POB as an example and show these parameters in action.
Review the ScotBot API, I can see POB is set up with these parameters.
"reduction_every_n_block": 42000000
"reduction_percentage": 50.0
"rewards_token": 10.0
"rewards_token_every_n_block": 40
Here 42000000 represents 4 years, and 50 represents a 50% reduction in tokens. POB is set up to issue 10 tokens every 40 blocks, or 2,628,000 tokens in the first year. Most tribes have an initial supply where a certain amount of tokens are allocated to different things like bounties, airdrop, team funds, and this amount is specified in the initial tribe announcement or white paper. The initial supply and these four parameters allows you to calculate the inflation of a tribe token and give you some idea of what to expect as time goes on.
Technically the inflation of POB is 262800000.00% as it started from one single token. Most tribes have an initial supply of 10 million tokens or some large number that reduces the inflation to about 5-25%. After the first 4 years, POB will have an inflation rate of 17.71% after the first halving. This is more in line with other tribes.
Here is the thing though, Hive Engine provides no protection to stake holders on these numbers. A tribe owner can issue tokens whenever they want, and even change the golden four parameters that controls the reward pool.
Here you can see I am free to issue (MINT) as many tokens as I have left in my max supply. In most cases, no one would ever know. This allows tribes to print tokens whenever they want beyond the promised initial supply and in excess of the promised inflation.
In many cases, all the initial supply will not be issued immediately. For STEMGeeks I allocated 10M STEM to the initial supply and most of that isn't issued. When a token is created most will allocate some really large number like 5 billion as a max supply as they are not 100% sure what the inflation will be at the time and they want some room. Once I calculated how STEM will be distributed, I burned 4 billion tokens to provide a contract that I will never issue those tokens.
This is a large risk for all stake holders, tribe owners can issue tokens as they please and no one is auditing or watching to keep them accountable. When wLEO v1 was hacked, more tokens were issued to reimburse those who lost tokens. I am not 100% sure where these tokens were issued from, I believe @khaleelkazi used the team supply or bounties, I forget at this point, nor do I know if it is all accounted for and audited. It could have been a straight issue tokens which would increase the inflation beyond what was promised initially.
In the case of POB, the initial supply was 1 and the only tokens issued would be through the reward pool via the ScotBot Engine. In theory, but nothing stops them from issuing tokens for whatever reason they want and frankly no one is watching.
This ability for tribe owners to issue tokens outside of the initial supply and outside of the reward pools specified in the whitepaper or tribe launch is a risk to all stake holders and a way to undermine their investment. I haven't done enough research to see how often and if ever this has been done, it would require a lot of work to compare what was promised and audit all the issued tokens.
I think most people are already aware of this concern, if not you should be when you are talking about market caps in the millions and inflation rates already in the 20%+.
A potential solution
I recently was thinking about this after a discussion with a large stake holder in another tribe, and I think there is a solution that would eliminate this risk and provide more transparency to all stake holders.
I propose a new parameter and a change to the smart contract that handles Hive Engine. I am not sure if this is even possible or practical at this point in time but it would eliminate this concern.
I propose Hive Engine having a new parameter when creating tokens that can never be changed. This parameter represents the initial supply of a token. When you create a token you specify the max supply of the token that represents how many tokens can ever exist.
With a new parameter representing Initial Supply, a token can be blocked off from issuing any tokens beyond this Initial supply parameter. For this to be effective, the smart contract would need to be adjusted to not allow a token owner to issue tokens beyond the initial supply but still allow ScotBot to issue tokens via reward pool payouts.
I also suggest some way to disclose when a token is issued and when ScotBot issues it to the reward pool. This currently isn't possible without changes as even if an issue was stamped with what did it, the tribe owner still has the same access as ScotBot.
Seeing as both the tribe owner and ScotBot both use active keys to issue tokens, this is a rather difficult problem to solve and why I am such a big advocate of native smart contracts on Hive to eliminate these type of risks. There is also a solution to this I had in mind, using multisig to have an official ScotBot sign the transaction along with the token owners account to ensure a transaction was done via ScotBot and not the token owner. While this is a viable solution to this problem, the new "SMT" direction of Hive Engine allows tribe owners to completely own the ScotBot and Indexing process making this a moot point.
By making these changes, stake holders will have some guarantees the inflation will be as promised and not deviate in an undisclosed and sudden fashion, it would also increase the ability to audit and report on token actions.
As tribes break the 1 million USD market cap, there is a responsibility to provide more protection and risk mitigation to stake holders so they don't become bag holders.
I suggest @eonwarped, @thecryptomancer, @aggroed give this some thought and see if it is even possible under the current system.
There may not be a good solution to this in the current ecosystem, but I wanted to throw out some ideas that could be talked about by the Hive Engine team and make everyone more aware of this problem and come up with solutions. Investors also should be fully aware of the risks involved.
Why you should vote me as witness
