Liquidity in crypto is the fundamental backbone that enables all interoperability, to not only other crypto networks but also to the legacy fiat system in which we all live and breathe. If we can't transfer our money to where it needs to go it becomes quarantined. This is not necessarily a systemic deal-breaker but just look what happens to countries that get embargoed and sanctioned. It's not easy to get everything we need within the current local systems in which we operate. Trade is a pivotal facet of any economy.
On a small network like Hive liquidity is the crux of the entire network. We are in serious trouble if we don't have it. I can't pay my rent with Hive or buy food or pay my utility bill. Hell, I can't even do any of those things with Bitcoin yet, which is why the regulators are scrambling to put a lid on this thing before it gets too out of control.
Because liquidity is so important we're always looking for another solution to acquire more and expand logistics. Centralized exchanges work great until they get hacked, are victim to an inside job, are incompetent (defi integration), or just decide to freeze our money for whatever reason.
The problem with atomic swaps? They're still just local swaps. The only difference is that devs can build new assets on the network using things like ERC-20 protocol, BEP-20 protocol, and now most recently with Ordinals BRC-20 protocol. Yes, it turns out devs are very creative with their naming schemes.
EVM gets around the liquidity problem with "atomic swaps", but the thing about EVM atomic swaps is that it can only be done between tokens that are all verified by block-producers and all on the same chain. Hive refuses to move in this direction because it is not a scalable solution. Meanwhile, atomic swaps between separate chains require trusted "decentralized" oracles as the middleman to make sure everything goes smoothly. Of course many of these oracles are enforced by nothing but a multisig solution which is an unacceptable systemic risk in the long term as these systems get bigger and bigger.
Ah well truly I'm hoping someone else (namely the speak network) creates a much better solution than what I had in mind. My solution would be very fragmented and decentralized, which is bad. Decentralization isn't always good, folks. It's the main reason why DEXes fail in the first place.
If I have $5000 worth of Bitcoin and I want to trade it for $5000 worth of Hive... how do I do that in a decentralized way? Oh no problem... I just need to find someone in the world who wants to trade exactly $5000 worth of Hive for my $5000 worth of Bitcoin. See the problem here? There's a very high likelihood that I'll never find this person within a reasonable amount of time unless there is some whale in the background greasing the wheels. And why would that whale be risking their money like that unless they had something to gain? Where does that gain come from on a decentralized permissionless system?
This is the problem with decentralized p2p liquidity. The more decentralized it is, the less actual liquidity exists in one place. Not good! This is the nature of decentralization. We only want just enough decentralization to make it so that the entity in charge is much more resistant to becoming corrupt and there are enough players involved that have an incentive to keep the group honest. Going for a full distributed solution sounds good on paper and from a philosophical standpoint but is almost never the optimal layout for the real world.
Ah yes, well, it would be an escrow solution. The idea here being that if someone builds a token on the second layer that token will have self-sovereignty and full control over its own assets, but will have zero control over the network it's built on (in this case Hive). Therefore any second layer token can be created and locked in an escrow contract and if Hive happens to get sent to that contract the L2 token would automatically be unlocked to the account that sent the Hive.
Because it creates fragmented liquidity. Can you imagine trying to move tokens back and forth between L2 & Hive with a system like this? Imagine a thousand escrow positions all with different price points and offers on the table. Sure, if we have Hive and we want to buy the L2 we can sort all these positions from cheapest to most expensive, but market orders are essentially impossible because Hive might need to be sent to a dozen different accounts for a single order to take place.
So we have these escrow positions with locked L2 tokens in them... what happens when two people send Hive to the same contract at the exact same time? Hm, not good because the L2 can't reverse that transaction. So now the contract has to pay out the tokens first come first serve and pay the operation higher up on the list (and then puts a burden on the person who received extra Hive to give it back to the rightful owner or pay out more L2 tokens).
What happens if users exploit this by sending money to their own account hoping to trick someone else into sending them Hive to a broken escrow contract? Hell, what happens when bots enter the picture and then simultaneous bids are extremely common and not even malicious?
These are the questions I've been mulling over within the context of my own Magitek project. I'd like to shy away from a multisig solution if I can avoid it and create something a little bit different. Diversity is good within a decentralized ecosystem.
Well as far as escrow ambiguity is concerned (two people sending Hive to the same contract at the same time) something like this could be fixed by reserving the assets in question. An account would announce their intent to buy the position in advance and that position would get temporarily locked long enough to prevent the double-spend.
Of course this just introduces yet another attack vector. What if someone creates a bot that's constantly locking up all the liquidity on the network without forking over the Hive to liquidate the contract? Certainly there are some ways to mitigate this from happening but this is more an example to show how the rabbit hole keeps expanding just as we thing we are getting closer to the end-goal.
An exchange is basically a bot that allows a single market (taker) order to liquidate multiple limit (maker) orders. This in turn changes the spot price as orders are liquidated and line between bids and asks moves one way or the other. The solution here is to create a bot that smooths out the UX and allows users to make swaps like they would do on any other exchange. Big players running their own bot would have big enough limit orders in escrow to allow other users to buy directly from them and no other accounts, so there's a good chance that not everyone would actually need to be running a bot in order to get the same UX. Rather the bots would be sniping the small discounted offers and consolidating them into their own bigger positions.
One of the big problems with these market standards is that everyone is in disagreement about what the underlying asset is worth. Sure, right now Bitcoin's spot price is at $27600. But how many people around the world are actually buying/selling at that price? There of plenty of people out there that won't buy Bitcoin unless it hits $20k and won't sell it until it hits $40k. These trading strategies create yet even more fragmented liquidity, even on centralized order books. This is an issue that's existed long before the Internet. It's as old as supply and demand.
This is why I really like the idea of creating derivative L2 assets that represent Hive assets. In the context of Magitek, FIRE would be a derivative of Hive (burn Hive to 
Creating derivative assets like this within the L2 ecosystem gives the L2 absolute control over the new assets, while also largely allowing the derivative to remain loosely pegged to the token burned to mint it. Therefore there is no question as to how much FIRE is worth. It can't be worth more than Hive because Hive can be burned 1:1 to get more FIRE... and it also likely won't be worth much less than Hive either because of the cost to mint it. Or at least we hope that a certain symbiosis and balance could be maintained between the derivative and the collateral giving it value. Unfortunately that's well beyond the scope of this post.
Once derivatives like this are in play the liquidity becomes much more centralized consolidated and hovers in a much narrower band than something like Bitcoin. There is no question as to how much money someone should sell FIRE for. If it can be sold for the equivalent value of Hive that's the best possible deal anyone can get because of the hard-capped ceiling. It may be deemed acceptable that even a 10% discounted price is acceptable as well (or even the standard price).
Still, a 10% range is very small compared non-derivative assets in which we'd all like to see 10x or even 100x gains (potential swings of 1000%-10000%). Interestingly enough because the derivative can be a volatile asset (like Hive/Fire) then those huge gains can be made on the derivative in terms of USD even if they can't be made in terms of the collateral that underpins it (AKA Hive mooning).
Well if you can't tell I'm REALLY trying to hype myself up into getting back into the coding game. Creating a new liquidity solution on Hive would be great for the robustness of the network so hopefully one day I can help make that happen. Although I can't help but feel like I'd be wasting my time and other smarter more determined people around here will create something superior. Maybe not though who knows?
Liquidity is the key to interoperability, trade, and fully functioning economy. While other networks seem to think they can run their governance on Reddit and their liquidity through centralized exchanges, the Hive community has realized for years that these are not viable long-term options. Just the fact that we have no CEO has completely prevented us from getting listings at places like Coinbase.
We all know that there's a better way to go about these things, but the path that needs to be taken is overgrown by dense jungle that we are slowly cutting through with a manchette. These things take time, but we are playing the long-game.
