This is a post of should have written before my last two about HBD.
@edicted/hbd-10-debt-haircut-is-too-low
Why?
Because there are many mechanics I gloss over regarding my idea for the CDP smart-contract system that I don't really explain. Many of these mechanics (like liquidation percent and collateral_percent would absolutely require governance votes to give the network control of changing these numbers dynamically on demand to maintain the peg and secure the network from possible bubbles and black swan events.
Sliding scale governance voting will be all the rage in DPOS. I plan on using it on my own projects/tokens assuming I ever finish them :D
It's essentially one of the main reasons I get infuriated with people on Hive saying we need to drastically change the system in one way or another... because no... obviously that's a bad idea. If we want to change core mechanics we need to do it slowly. That's what strong hands do: not panic.
The main example here is the powerdown period. The only arguments I see are on opposite ends of the spectrum:
- Change the powerdown period to 4 weeks like HiveEngine tokens.
- Leave the powerdown period at 13 weeks.
Literally no one argues for anything in-between (except me), and it's super obnoxious.
Powerdown?
- What about 5 weeks?
- What about 11 weeks?
- What about 7 weeks?
- Are you annoyed yet?
- What about 8 weeks?
- What about 6 weeks?
- What about 10 weeks?
- Are you raging yet?
- What about 9 weeks?
- What about 12 weeks?
Yeah, now you know what I feel like.
I rage every time I see people argue about this like it's binary two-options-only. Why would we jump straight from 13 weeks to 4 weeks and never look back? There needs to be a way to slide these numbers back and forth through a governance system, and I think I've come up with a pretty good solution on that front.
Inspired by the "Tug-of-War" videogame genre, Hive too can play tug of war with governance votes. For example, instead of aggressively and recklessly changing the powerdown period to 4 weeks, we simply leave it at 13 weeks and enable monthly tug-of-war voting.
Magic of DPOS
Imagine, if you will, a voting system that simply allowed us to change the powerdown-period by one week every so often. It might be 13 weeks now, but you can vote for it to go to 12, and if that vote passes at the end of the month, the powerdown period shifts to 12 weeks. Next month, with another vote, it could be reduced again to 11 weeks with enough support.
Is it really that far fetched?
It's really not. This is a system that will likely be deployed across all DPOS chains. This is a huge advantage of DPOS systems: governance is built in, allowing for agile movement over time.
How does it work?
Every vote has a:
- time period
- threshold level
- level/tick system
Time Period
How long does the vote last? How often can said variable be tugged in one direction or the other? This is the time period. On my Card's Against Humanity clone (Magic Words) the time period for many of the votes will be 30k Hive blocks (about 25 hours).
In the case of a big vote like modifying the powerdown period, the time period would have to be much longer; something like 1 month instead of one day. This way it can't be changed super often and destabilize the system.
Threshold Level
Imagine there was a vote that nobody knew or cared about. Imagine if randomly one month nobody voted on whether to increase or decrease the powerdown period, and a single user jumped on at the last second to cast the vote in one direction. We wouldn't want a single user to be able to determine such an important vote alone.
The threshold level prevents this from happening by deactivating the result until the required amount of stake has voted for or against the proposition. In the context of powerdown-period, let's say the threshold was 20M. This would mean twenty million hive needs to vote to either raise or lower the period in order for it to become active.
Once 20M is achieved, it is guaranteed that the powerdown period would change at the end of the voting process unless enough votes rallied against that change. The same stake is allowed to vote for multiple outcomes.
For example
Say that the powerdown period sits at 10 weeks, and a group on Hive is campaigning to get that reduced to 9 weeks at the end of the month. In the event that they only get 19M votes, nothing happens. However, if they get the required threshold of 20M stake voting in their direction, now they will win the vote at the end of the month unless other users rally against it with more vote power.
Let's say, at the same time, there was another group of people that wanted to increase the period to 11 weeks. These people could not only vote for an increase to 11 weeks, but they could also vote to keep it the same in case they lose the main vote. This is called a secondary vote, which will not be applied if the primary vote wins.
Level System
Tug of war "ticks" need to be pre-defined so that users know what they are voting for in advance, and to where the numbers can go in the future. You can only go from 10 weeks to 9 weeks, then to 8, then 7. You can't skip straight from 10 weeks to 7. That's how tug of war works; everything must be in sequential order and enough time must pass so the network doesn't become destabilized.
The ticks for powerdown period are simple:
- 4 weeks
- 5 weeks
- 6 weeks
- 7 weeks
- 8 weeks
- 9 weeks
- 10 weeks
- 11 weeks
- 12 weeks
- 13 weeks
Pretty much no one argues that we should increase the period to 14 weeks or higher, so there's really no point in cluttering the system with options that don't make sense.
K-I-S-S: keep it simple, stupid
Unfortunately, it's not always that easy. In the example above, the numbers were pretty obvious. We know we don't want less than 4 weeks, and we know we don't want more than 13... and we know we don't need fractions of a week. This makes the tug-of-war tick boxes easy to decide on in terms of scale when it comes to powerdown period.
There is another system I mean to employ for governance votes as it pertains to Magic Words. This is a stackable base-10 system that is infinitely scalable in both directions. This kind of scale is needed for crypto, because you really have no idea how high price can go or how fast it will pump/dump.
This is what I came up with one day when I was randomly droning away at Amazon:
100
125
150
175
200
225
250
300
350
400
450
500
600
700
800
900
1000
For these numbers to make sense I probably need to explain what I plan on applying them to in terms of voting. Magic Words is a proof-of-burn/proof-of-brain (POB²) system where users must destroy currency (either HBD or LEO to @null) to create dust.
Don't worry, the dust is magic.
Dust is used to create cards. The only way to create cards and play the game is to destroy currency. The problem is: what happens if LEO moons? What happens if I say: okay guys, it costs 1 LEO to create 100 dust, and it costs 100 dust to create a card? That's fine... right?
Wrong
Because then if LEO spikes to $10 I have to fork the entire consensus of the game because the cost to make a single card is prohibitively expensive. That's where this voting system comes in. Because the system is infinitely scalable and stackable in either direction, we can create the accurate ticks:
1
0.9
0.8
0.7
0.6
0.5
0.45
0.4
0.35
0.3
0.25
0.225
0.2
0.175
0.15
0.125
0.1
These are the exact numbers as before, only this time they have been divided by 1000 to reflect that I want 1 LEO to be the equivalent of making 100 dust. However, the network can use their MGW governance tokens to vote to reduce or raise this cost accordingly. This way the network can target a price somewhere around $1, or if they're feeling generous, perhaps lower than that in some kind of firesale. Or perhaps they even decide to jack up the prices because that's the profitable thing to do... who knows.
There are several advantages and disadvantages to this scale. An obvious disadvantage is the clunkiness of the system. The difference between 100 and 125 is obviously 25%. That's a pretty big jump, and it's a lot more than some of the other jumps like 900 to 1000 (~11%).
Also these numbers are very consistent. What happens if I raised prices by 10% from 1 to 1.1, and then tried to lower it 10%? 10% off of 1.1 is 0.99, which is obviously not the original number of 1 flat, so the clunkier version of the system is more predictable. If the number in question is 15000, anyone familiar with the system knows a vote up will raise the number to 17500, while a vote down would reduce it to 12500. Similarly a vote up on a number like 0.005 would increase to 0.006, while a decrease would be 0.0045
I've thought about this system a lot, and I like it because it reminds me of the Bitcoin halving event. Why did Satoshi decide that Bitcoin inflation should be reduced by HALF every 4 years when he could have just as easily reduced it slowly over time? Turns out, there are a lot of advantages to a clunky system like this.
For Bitcoin, it creates these 4 year hype-cycles that generate a ton of immediate attention. God bless the mega-bubble year of 2021. For Magic Words, this scale allows prices to change by x10 every 16 jumps/ticks. Seeing as the standard time period for MGW will be 30k blocks (25 hours) that would allow the network to move prices up or down by x100 about every month maximum. It's an agile system.
DEXchange orderbook
Another system I wanted to apply this too was rewards for liquidity. Imagine a traditional orderbook exchange like Hiveengine, except there are massive buy wall and sell walls at every one of these ticks, because those ticks are being rewarded by inflation just like the LEO Geyser provides rewards in a similar way.
For example, say the market price of MGW is trading at 0.26 HBD. The Magic Words network could reward anyone who posts liquidity at all the ticks within x10 the price. Because the current price is trading between the ticks of 0.25 and 0.3, that means that the following levels would be eligible to be paid on the exchange in the form of this unique geyser via inflation:
Let's say 10 ticks above and below the current price:
Below:
0.25
0.225
0.2
0.175
0.15
0.125
0.1
0.09
0.08
0.07
Above:
0.3
0.35
0.4
0.45
0.5
0.6
0.7
0.8
0.9
1
In this scenario, let's assume the network decided it was profitable to provide liquidity to each of these levels evenly. There are 20 ticks here, so lets also assume the network dedicates 2000 MGW tokens a day in order to provide said liquidity. That means each tick would be rewarded 100 tokens for their liquid assets at these exact levels. Users who posted coins at ticks with less liquidity would scoop more of the rewards for themselves.
An example would be: say no one was posting at the 0.7 level, you could park some tokens there and scoop all 100 tokens for yourself. But if someone decided to match your contribution you'd only make 50 tokens and you'd both scoop half.
This has a huge advantage in that many users will stop undercutting each other by 0.00001 at a time. Users providing liquidity looking to farm the system will simply all post on the same wall, while other users will be allowed to undercut if they want a faster sell, but they won't be eligible for Geyser rewards.
Uniswap has an extreme flaw in that everyone who provides liquidity to the pool is forced to buy and sell at the current market value, creating "impermanent loss" slippage. With a traditional orderbook, MGW users would be able to provide deep liquidity at 10 ticks away from the current market price while also getting rewarded inflation for there services, without having to suffer this impermanent loss... and if their stake gets sold by a flash-crash or dump they just made x10 on the trade: Something that is impossible on Uniswap.
Conclusion
Well, there you have it, I think that about covers everything. Rather than argue about the knobs we should be tweeking on Hive in one direction or another, we need to be creating this tug of war voting system. This is essentially a free market that allows the network to govern itself without having to argue about how things should be all the time. Let the free-market decide: I say!
This applies to everything. We can print inflation this way. We can change the % of HBD we are printing. We can change the powerdown period. We can change the number of consensus witness and/or paid backup witnesses. We can change how much money the dev fund gets, how many days money is locked in the savings accounts, curation percentage, time to convert HBD, number of witness votes, HBD CDP liquidation/collateral percent requirements, how much of the ninjamine to pump into the dev pool, or whatever else.