Magitek Fire & Ice: Shifting Some Bits

avatar
(Edited)

Bit-Shift-programming.png

Original "Whitepaper"

My last post about Magitek was unceremoniously ended because It was about to turn into a ridiculous 5000 word rant, so I'm returning today to continue the journey. Note that this blog post is perhaps more for me than anyone else, but than again so is all good "art".

For example, how many movies out there get created with demographics in mind and simply exist to try to target those demographics and make money? Nothing actually good ever gets created in this way. Real creators create the things they want to create, for themselves, not to make money. If others enjoy what gets created this is just an added bonus. This is how all the best stuff gets produced. These things cannot be forced. Skill can only take a person so far; a bit of luck is always required for something to go truly viral.

My original vision of Magitek was a system of interlinked derivatives. Send Hive to @null to create Fire. Send HBD to @null to create Lightning. And then Ice would be an in-house stable coin created by locking collateral within the CACHE.

The reason why Lightning would be the HBD derivative is because I wanted LIT to "power the network". Basically everything would be bought and priced in LIT and it was hoped that the value of it would fluctuate in a tight sine wave. Because HBD is largely stable and largely capped at a USD value of $1 this would be good for pricing things like NFTs so that the value of consumer products would not spike during bull markets. Same idea as DEC with Splinterlands. Nobody wants to pay $30 for a small pack of cards that was supposed to cost $3. Volatility is very bad for units of account and mediums of exchange.

However ultimately a big problem with this model is that the governance token MANA (potentially referred to as TEK outside the network because there are already too many MANA tokens) would have to be constantly burned to create LIT tokens to meet demand. Otherwise all the value that the network created would be outsourced to Hive and the entire project would slowly bleed out just like every other DEFI network. Surely I want some of the value created to flow out to Hive but certainly not all of it.

This would have created a silly little conversion game of figuring out when to burn mana to create lightning and vice versa, and conversions like this tend to be a systemic threat and have to be done very carefully. I think I do have a very careful way of doing it but still it's potentially overcomplicated, and it purposefully makes it so the HBD derivative is never 1:1 pegged, which is kind of annoying for several other reasons that I won't get into.

yin-yang-fire-ice-alchemy-convert.png

Swapping ICE with LIT

The original vision of ICE was that it was going to be a derivative stablecoin. So ICE made sense. It was slow and wasn't supposed to be volatile or anything like that; Just kind of on the side doing its thing. However, now that HBD is outperforming itself exponentially compared to just a few years ago: Magitek has zero need for another stable coin; that's way too redundant and pointless. So I realized that the in-house derivative should actually be a volatility token whose job is to be volatile on purpose to keep MANA on a more stable course.

So the governance token MANA won't be a true stablecoin but it can get steered into the correct direction using these mechanics. When MANA price gets too high the derivative gets destroyed to create more MANA to bring the price down. When MANA is too low in value it will cannibalize the derivative's value by burning MANA to create the other token.

With all this in mind I realized it makes way way more sense to switch the ICE and LIT labels. The derivative token will be Lightning, which makes sense because Lightning itself is totally volatile and unpredictable. The HBD derivative will be ICE, which again makes sense because ICE was always supposed to be the stable asset. Not to mention that Fire and Ice come as a pair much like Hive/HBD do, so the analogies of the system will be in much tighter alignment.

Given this new path of 'consensus' both the FIRE and ICE tokens will largely be pegged 1:1 with no conversions allowed in either direction. The only way to create FIRE will be Hive burns and LIT will be HBD burns. Of course I will probably still allow these conversions to be enabled or disabled on the backend in case my code gets cloned by others who want to make their own tokens that would utilize these features. For this most part this is pretty much already how it works. Most conversions are disabled by default because they carry inherent systemic risk and they have to be flipped on/off using a governance vote.

image.png

It may be worth noting that only circular conversions create systemic risk. Meaning if an asset can be burned to create MANA and MANA can be used to create the derivative an infinite loop can potentially be created that ends up minting infinite tokens.

However, one-way conversions do not have this risk because they can't travel backwards and synergize with themselves. Thus conversions like HIVE >> FIRE, HBD >> LIT, and MANA >> ASH have zero risk associated with them because the process can never be undone. Once Hive/HBD is sent to @null it's trapped within Hive's consensus algorithm indefinitely and there is no way to reclaim it. This is the ultimate burn feature.

Pricing NFTs

Because MANA will theoretically be stable-ish due to its relationship with the LIT volatility token we can utilize it as a unit of account and a way to mint NFTs and other assets directly without having to involve the other derivatives. The prices of these assets should not change much over time, and I'm planning on adding a separate NFT price multiplier that can raise or lower prices as needed across the board to make up for any volatility in the governance token. As of right now the plan is to loosely peg the cost NFT minting to around $1 using the underlying economic toolkit.

Why even mess around with derivatives?

Why even bother creating these FIRE/ICE/LIT tokens when it could just be the one governance token? One token to rule them all! It's a good question; one that I think about pretty often. When I first came up with this idea the plan was always to burn HBD on Hive so that both the parent layer one chain and the layer two chain create value at the exact same time. It's obviously pretty good for my reputation if I create an L2 that burns millions of Hive and single handedly manages to push up the spot price a bit. Everyone loves them moonbags. Could be a pipe dream but that is still the goal nonetheless.

But that kind of thinking is just rooted in greed or whatever and there are some very real reasons to create these derivatives. First of all exit liquidity is a huge problem, and the 1:1 pegged derivatives greatly incentivize market makers (or in this case more like arbitragers) to come in and turn a profit at low risk.

If Magitek was just a totally volatile governance token this makes it very hard to create deep liquidity pools in a safe manner. If Hive is being traded for MANA directly... there are four different outcomes that can happen that muck up the process of providing exit liquidity.

  1. The USD price of Hive goes up.
  2. The USD price of Hive goes down.
  3. The USD price of MANA goes up.
  4. The USD price of MANA goes down.

If any one of these four movements happens then every single liquidity provider has to use a bot to identify this movement in real time and adjust all their positions accordingly. One single fuckup or glitch could cost someone their entire stack. The risk is too high and the reward is too low, which in turn creates huge liquidity gaps between buyers and sellers; it's basically just all bad.

However, using a derivative, players can instead trade their FIRE for HIVE or their LIT for HBD at a slight discount compared to the minting cost (as low as 0.1%). This completely eliminates a lot of the risks I just talked about. Instead of pairing two completely uncorrelated assets: we pair the parent token and the child token (derivative of the parent) together on a market where volatility should be very low and predictable.

Someone could buy FIRE during a "fire-sale" at a 10% discount to the mint price knowing full well this is a very good deal based on previous history and the chance of further decline from this point is very small. We simply can't get those types of assurances when employing USD as the unit of account with the prices of multiple assets constantly moving in different directions. In addition, this system gives less of an advantage to bots and allows manual and organic volume to flourish without being exploited.

frost-ice-elemental.jpg

Main Conversions

  • Hive >> FIRE
  • HBD >> ICE
  • MANA >> LIT

Internal value

Once we justify the existence of these derivatives they can then be allocated to secondary functions. What is the value of a derivative asset that tracks the price of Hive? What is the value of a derivative asset that tracks the price of HBD? If we're being honest ICE will be much more important than FIRE because stability is a rare quality for crypto to have; especially stability that is created without the need for dollars sitting in a traditional bank.

Our algo stable coin is only getting better and better every year compared to all the other garbage out there. The systemic failure of assets like LUNA/UST and TITAN/IRON prove this beyond any doubt. In fact we already understand that failure of HBD will at worst result in something like an HBD depeg to 60 cents and a Hive price of 10 cents. This has already occurred multiple times in the field in 'decades' past.

Futures market.

How amazing would it be if we could long/short Hive on a completely permissionless system that couldn't be shut down by regulators? These are the kinds of things that become possible on an L2 system that has complete control over the derivatives it creates. This is what I have planned, of course explaining what I have in mind would take another 2000 words so I'll have to kill it here and save that for next time.

Conclusion

Looking at what I've accomplished so far with this project it occurs to me that it is possible for me to launch it within a year if I was working very hard toward that goal. Would it be robust, secure, and decentralized? Probably not, but also at a certain point I just gotta get the thing up and running before tying up all the loose ends. If we are being honest this is almost how all crypto devs do business; stumbling into the future and hoping the bridge doesn't get burned behind us. It's a ragtag market; still early.

In any case there's a lot of exciting tech being built on Hive and it's inspired me to pick my own project back up and get to work. No telling how long I make it before I burnout again but here's for hoping for the best. Cheers.



0
0
0.000
8 comments
avatar

I've been in crypto long enough that I feel like I can at least grasp a little bit of most things that are created. This was so far over my head though. It has been a long day, so maybe I need to come back and try again tomorrow!

0
0
0.000
avatar

No I think I'm just quite bad at communicating what needs to be done here to others.
Like I said this reads more like taking notes for myself.
It assumes the reader has previous knowledge to the other posts linked at the top.

0
0
0.000
avatar

Ah, that is a good point. I definitely missed those, but I do remember you talking about your project in the Leo Discord in the past.

0
0
0.000
avatar

If you did this I'd have to dust off my plans to make my own arbitrage bot for my own use. Games seem to always resonate well with folks, and are a lot of fun so if you're going to dust off the project and get to work on it even for a little bit, it's a fun use of skills!

0
0
0.000
avatar

That's actually very nice to hear because a good arb bot would be an absolute requirement for something like this.
I'm guessing in the beginning with little competition they could make a lot of money as well.
A couple people (or even 1 person) could arb the entire market.

0
0
0.000
avatar

haha I would definitely make it entirely for practice rather than for personal profit but it'd sure be a fun project!

0
0
0.000
avatar

Indeed well the ultimate goal is to create a decentralized arb bot that anyone can use.
That way the system is fair and we can get deep liquidity pools across many players.
The bot would be customizable enough that everyone would configure theirs uniquely.

0
0
0.000
avatar

Happy Valentine, thanks for the support I enjoy from you

0
0
0.000