![IFRS-3-Escrow-agreement-on-acquisition.jpg](https://files.peakd.com/file/peakd-hive/edicted/EocDktFH1cRJp36CwQJTCK9QLTMgVq1Vo8Emrzdzz9Q9W8i98nFPv8gUQJiypyaJBGV.jpg)

#### The mental block continues!
This is actually an idea I had a couple years ago when trying to come up with a *permissionless* solution for swapping tokens built on Hive in and out of an L2 ecosystem.  Of course I haven't coded in years so the project is just sitting here untouched, so that's kind of annoying.   I really should get back to it but it seems that my psyche won't let that happen for whatever reason.   Ah well maybe if I do a deep review of everything I can jump back into the grind! 

#### Permissionless vs Decentralized
I've come to realize that while we often speak about these two attributes of crypto as though they are the same thing and interchangeable, they are anything but.  Take a multisig solution for example.  We can make an argument that multisig is decentralized, but is permissioned by design.  It requires the permission of multiple signatures, so it is arguably even more permissioned than a centralized implementation, and yet it is still "decentralized" to an extent because no one entity controls those permissions. 

#### That's not what I want to build. 
I want to create something that's completely permissionless that anyone can interact with using nothing but their own private key.  I don't like the idea of funds sitting in a huge honeypot guarded by a single account that's been secured by multisig.  While this might be a "good enough" solution in a lot of different situations it just feels like it would not scale well and would be a permanent existential threat to the network (no matter how small). 

#### L2 Smart Contracts on Hive
The 'big problem' with Hive is that we don't have smart contracts on the main chain, and we have decided that we're never going to.  This will give us a massive scaling advantage, allowing the main chain to act as a raw data layer that can then be fed into sharded networks that enforce that raw data as law independently rather than forcing Hive witnesses to make all those calculations and track all that data.  Outsourcing smart contracts to layer two is definitely the way to go, but we still have a lot of infrastructure to build before that reality becomes fully viable. 

#### L2 as a virtual operation solution
A virtual operation on Hive is one which is not broadcasted in a block.  Why and how can an operation happen without being broadcasted?  Because it does not require a signature.  It's just a thing that happens in which every single Hive node knows about in advance and enforces automatically.  An example of this would be getting a payout, unlocking stake, or earning HBD yields.  Nobody has to sign anything for these things to happen; they just happen after a set amount of time.  

![virtual operation names.png](https://files.peakd.com/file/peakd-hive/edicted/23tmmf7kijfL2cfy8YneXZ1L37MJJ5FCa6u4RsqfYu7hhPJwD3jXPBKS76J4Kbfq4fz3Z.png)

It stands to reason that layer two smart contract networks could consist entirely of virtual operations, meaning every single block could be produced independently without expressly requiring communication between other nodes within the L2 network.  This is accomplished through the data availability layer.  

Sending tokens somewhere requires the user's signature, but that signature already exists on Hive in the form of custom_json.  The L2 node's only job is to make sure the block data it's being fed from Hive is legit, as this is the only data required to enforce every contract and construct every block on the L2 by proxy.  On a technical level this could be confirmed in a couple of different ways and is beyond the scope of this post. 

#### Understanding HiveEngine
The biggest problem with an L2 solution on Hive is that L2 networks have complete 100% control over the assets they create and govern, while having 0% control over the Hive network itself.  So how does one swap Hive for an L2 token if there are opportunities to cheat the system and not send the Hive after receiving payment? 

HiveEngine 'solves' this with a permissioned system that wraps Hive into SWAP.HIVE.  This wrapped SWAP.HIVE token then obeys the same rules as the L2 and can be atomic-swapped or interacted with just like every other token.  Wrapping the asset into a native L2 token is the key.  How to get there is a little more tricky. 


![image.png](https://files.peakd.com/file/peakd-hive/edicted/23uFUA81pi3349LJ71Vm5GL7fHyh7MGxzGCAuUJoafVBMZ24u9o5pxu9mB6JLmkcrQZVH.png)

In order to explain this further I need to wrap some Hive if only so I can remember where all the money is stored.  I'm immediately bombarded with an enraging 0.75% fee.   In fact most Hive users will [highly recommend BEESWAP](https://beeswap.dcity.io/convert) to circumvent this nonsense (currently 0% fee on deposit + LP reward), but in this case the entire point is to use the main contract. 

 https://i.imgur.com/rdi9Mb1.png 

So I do the thing and we can see that the Hive gets transferred to the @honey-swap account, an account with 1.7M tokens powered up and 4.7M liquid.  Actually I didn't realize that people's money was apparently getting powered up?  Interesting development.  I'd say this is just another reason to call bullshit, but a simple search of the @honey-swap account reveals that it sits at 100% voting power and doesn't leech the reward pool, so powering up all that stake might just be to protect the honeypot or might not even contain any liabilities.  Unclear. 


 https://i.imgur.com/ofuxxER.png 

#### I send 100 Hive and I get 99.25 wrapped SWAP.HIVE in return.
This is where I say this fee is x7.5 higher than Binance (the trading fee), but it's actually infinitely higher than the deposit fees of all exchanges because exchanges have a deposit fee of 0% across the board.  That kind of economic friction can't be great. 

And where does the fee actually go?  
It goes to the centralized agent that created the contract.  
Again that is not good optics for a decentralized ecosystem.
But then again I'm sure a lot of us have been over this several times over. 
There are plenty of reasons to build it this way, as will become obvious.

### Escrow Liquidity explanation
So instead of all that bullshit I wanted to create something that was actually permissionless and only required the key of user in question.  I'll be honest the solution I came up with was... shall we say not great and potentially full of holes, but it's been years and I still can't think of a better one so it is what it is. 

It all comes back to this idea that the L2 has full control over itself but zero control over Hive.  Therefore what makes the most sense is that L2 tokens would be locked in a contract, and then when Hive is sent to that contract address: the escrow is unlocked and automatically delivered to the buyer.   However, a 'solution' like this has serious logistics issues. 

#### Secured vs Unsecured escrow
What happens if two users send Hive to the same escrow contract at the same time?   The L2 has no control over Hive so it can't issue a refund or reverse the transaction.  The resolution to this could be to simply trust the reputation of the liquidity provider knowing their account will be frozen if they don't pay back their debts.  If the provider in question had a huge whale-sized stack and a high reputation on the network this type of unsecured escrow would probably be just fine for most exchanges.  But that doesn't change the fact that we need a secured option for all the other edge cases.  

The secured version of escrow exchange requires the L2 buyer to signal their intent to purchase before sending the Hive.  That way the L2 token gets locked in a contract that can only be purchased by a single account named in advance.  If two or more people try to buy at the same time only one of them is going to get the greenlight.

There are advantages and disadvantages to both of these implementations.  Secured contracts could be exploited by a blackhat who just spams the network signaling their intent to buy every token for sale.  This would lead to no one being able to buy the L2 token because they'd all be reserved for accounts that had no intention of actually sending the Hive.  

There are a couple different ways this attack could be mitigated.  For starters I envision my own project Magitek as a proof-of-burn network in which assets are constantly destroyed to create derivatives.  In order to even participate in the system an account would have to destroy 1 HBD to get added to the database.  That combined with the cost of RCs and Hive accounts could be more than enough to mitigate several types of Sybil attacks. 


![amm-automated-market-maker.jpg](https://files.peakd.com/file/peakd-hive/edicted/Eoe7FTTAPCgUaavE77pyy9FoZBECmWHLDSeeU9EadyQF1a1kkQRjuEuhK9HeHcbMm7z.jpg)


## [Maker vs Taker orders](https://peakd.com/@edicted/trading-maker-vs-taker)
One of the biggest logistic issues for atomic-swap technology and similar P2P exchange solutions is liquidity.  In fact it is not an exaggeration to say that this problem dwarfs all others by exponential margins.  Atomic-Swaps on the Bitcoin network have existed for many years.  Nobody uses them!  Why?  Because matching buyers and sellers in a timely manner becomes a nearly impossible task using this infrastructure.

For example say I have $1000 worth of BTC and I want to trade it for $1000 worth of Ethereum.  First of all, not everyone wants to make a trade at market value.  A lot of users will post orders that will only fill if number goes up in their favor.  Not only that, imagine someone else has $10k worth of liquidity on the books and they want to trade at the current market value, but they don't want to trade with me because $1000 isn't enough and the on-chain fee is too high.  Just like I'm not going to trade with someone looking to swap $100 for the same reason.  

It's clear to see that, in a certain sense, atomic-swaps lack this type of fungibility, where even if two people want to make a trade with each other they might have second thoughts about being the chump who allows partial transactions to fill.  Everyone wants to sell their own position within a single trade.  Again, this is the biggest logistical issue with atomic-swaps by far.   The liquidity just isn't there, and there is no financial incentive for market makers to step in and help. 

Centralized exchanges grease the wheels on this problems in multiple ways.  The first way is by doing all the heavy lifting off-chain and not incurring any operation fees on the trade.  The exchange can then replace this with a much smaller trading fee so that the deal is still more than worth it and they get paid in the process, allowing their own business model to scale up and maintain profitability. 

The other very important advantage of centralized exchanges and orderbooks in general is that a single **taker** order can liquidate an unlimited amount of **maker** orders, and the entire process is completely automated and instant.  You simply can't do that with an atomic-swap between two networks because every maker order that gets liquidated needs to go into a different wallet on-chain.  Again, exchanges avoid this technicality by doing everything off chain and creating IOU digital accounts for their users.  As the name implies, a P2P solution can't do this as the operation only involves 2 people (not 100% accurate but you catch my drift).


![bot.jpg](https://files.peakd.com/file/peakd-hive/edicted/23zGyr63mzvZ3NUVn8DWfGjfb8dAqF8gtW6PfFnrCYrT9c5MVMU9FhMT8wUbSjSdzNXe4.jpg)

#### So how do we fix this? 
Just like with centralized exchanges, bots/automation tend to be the answer.  If it's going to take hundreds or even thousands of trades to consolidate secured liquidity from the minnows into unsecured whale liquidity then a bot that places automatic bids is going to be pretty useful for the whales.  Unfortunately arbitrage and market making in general are extremely competitive and cutthroat activities. 

It would be nice if the bot was open source and available to all,  but there is also a financial incentive to create proprietary tech that can outcompete the base case.   Although it is possible that a bot with enough options would be customizable enough to compete with itself and act completely differently given different configurations. 

#### The key is derivatives that smooth over volatility. 
It's much better if the assets being traded have some semblance of stability.  What happens if I go to sell my Bitcoin for $1000, but then the price of Bitcoin spikes to $1200?  If I'm not running a bot my liquidity just sits there until someone or another bot notices and scoops it up for free money.  I've actually made some real money once or twice on HiveEngine through this exact type of arbitrage through manual trades during big Hive spikes. 

My solution to this problem was the proof of burn idea that allows any user on Hive to permissionlessly create a derivative asset on the layer two.  On Magitek, burning 0.001 Hive to @null would mint 1 Fire on the L2, while burning 0.001 HBD would create 1 LIT (Lightning).   This allows for a much more seamless transition for exiting the network that also acts as a metric for how healthy liquidity is while simultaneously burning main-chain assets. 


![consensus_cartoon-node-derivative-virtual-contract.png](https://files.peakd.com/file/peakd-hive/edicted/23xLBQ71Syrb8MzHcTpxNXLRyU1s4mSz33ZqDKvgi4efeX2qUJ33bwA3DWmX8YFFjTRCQ.png)

For example: big Magitek whales might have their bots setup to fund the escrow contracts at a 1% discount.  So they are putting a lot of Fire into an unsecured Firewall contract and anyone on the network that sends them Hive (with the correct memo) will automatically get Fire in return instantly at a ratio of  [1010 FIRE : 1 HIVE].  In this situation any user can ignore the deal and just create fire natively at a [1000:1] ratio using the Inferno contract, but the whale is creating a financial incentive for users that want to enter to make this trade to provide exit liquidity instead.

#### So what happens when casual users want to exit?
They can just undercut the deal the whales are offering using a secured contract.  If liquidity is good and the whale bots are operating as intended, the whales will not allow minnows to undercut them.  The whales will instantly buyout the cheaper smaller positions and consolidate those tokens into their own position, theoretically earning arbitrage revenue in the process (assuming their own position eventually sells at the quoted price point).  As is always the case: casual users will pay a premium to makers so that they can execute the trade instantly with a taker order. 

At that point it becomes a game of maintaining the pegs of the derivatives at all costs.  If whales are offering a 10% discount on FIRE to flee the network, it could be a bad sign... or it could be just business as usual depending on how the tokenomics of the network are setup.  But again, this is way beyond the scope of this already way too long post. 

>### In the example you gave: the exit fee was 1% minimum, which is even more than HE.

This is incorrect thinking.  There is no fee.  If someone burns 1000 Hive to create 1M FIRE, and then they exit the network through the Firewall by taking a 2% loss, no fee was paid.  That's just slippage on a depegged asset.  Nobody profited from that action unless the user allowed it.   And even in that case, if the user lost 2% but the whale they sold to only profited 1%, where did the other 1% go?  

At the end of the day if users choose to destroy their Hive and send it to @null that value is gone forever and exists only in the form of the derivative that was created from it (in this case FIRE).  The only thing giving that derivative value is money sitting on the outside waiting to buy at some kind of discount (be it 0.1% or 30%). 

So nobody can guarantee it will be a good deal, but also imagine the flip side in which the FIRE token depegs 10% and everyone is buying Fire at a [1100 : 1] ratio.  Will the peg bounce back and allow all the believers of the network to turn a profit from this temporary volatility?  That's the idea anyway.  Less volatility implies a healthier network, but more volatility increases risk and reward. 


![ship-in-bottle-bottleneck.png](https://files.peakd.com/file/peakd-hive/edicted/23wCLJxZHxtTZVtgjhDjC5oKwnSUWXBPjHq9F2AGC8hT4iahWMNFn4HLyVjVU7P2y9XFW.png)

#### Conclusion
At the end of the day even if this implementation was a complete and utter disaster it would still result in a lower supply of Hive and HBD, so I think about it pretty often.  Creating interoperability between networks is not easy, even if the network in question is a layer 2.  Just look at the Lightning Network.  The problems between LN and Bitcoin are shockingly astronomical.  In fact a lot of the networks that we call L2 aren't even L2's at all, and are just fully segregated EVM clones.  Go figure.  Marketers gonna market. 

There could be some promise here, but I'm also still waiting to see what VSC, HAF, and SPK can come up with in terms of liquidity and their associated pools and pairings.  Multisig is very popular, so something like this could be worth developing even if only to showcase another option.  After all: multisig wrapping is not permissionless.  The war against bottlenecks continues.