Part 2: Enter the Mangrove, the exchange where offer is code
This is Part 2 of our ‘Enter Mangrove’ series where we’ll be exploring the Mangrove protocol in depth, its core engine as well as its key features.
In the first part we unveiled the raison d’etre of the protocol, head over here to read it.
We presented in the first part that Total Value Locked (TVL) is often ‘the’ metric used to gauge the success of a DeFi protocol. Mangrove disrupts this narrative and unleashes the liquidity in DeFi, as Liquidity Providers (LPs) do not need to ‘lock’ in their liquidity beforehand but promise it and only deliver when called upon.
Enter Mangrove, the exchange where offer is code
The Mangrove protocol is a decentralized exchange with a global orderbook, capable of aggregating all the available on-chain liquidity with an optimized matching engine. You could view it as a liquidity offer protocol which does not require collateralization.
In simpler terms, it is a marketplace for promises of liquidity, where “offer is code”. Actually, when an offer from the orderbook is matched, the portion of code embedded within it will execute. This code’s mission is to find the liquidity requested by the taker of the order : it can pull it from the maker’s inventory, source it from a pool or even borrow it from a lender, or any on-chain sourcing strategy that the maker has built in his offer code. When the order is successfully executed, the orderbook gets updated. Easy as that (lol).
This new flexibility enables liquidity providers & DeFi traders to post offers that are not fully provisioned. Liquidity can be shared, borrowed, lent and, at the same time, be displayed and amplified in the Mangrove's orderbook, ready to be sourced when, and only when, an offer is hit.
The Maker, the Taker and the Keeper
Making liquidity available
An offer posted on Mangrove can be summarized as follows:
(volume A given, volume B wanted, gasreq) + code + bounty (implicitly defined), where:
An offer on Mangrove contains the following information:
A volume of tokens A that the offer gives
A volume of tokens B that the offer wants
An amount of gas requested to execute the offer ("gasreq")
The smart contract that will be called when the offer is executed ("code")
The native chain token provisioned in case the offer fails to execute ("bounty")
With Mangrove, Makers can experience a new trading environment, with unprecedented features in the DeFi space:
Reactive liquidity: no capital locked in the order book
Last look: defensive last look mechanism to renege on an offer (for instance if market conditions are not satisfactory enough for the Maker)
No exclusivity: the maker can post several offers for the same assets, Mangrove acting as a liquidity amplifier for the DeFi markets
What if everyone makes empty promises? This is where we need providers to leave a native token provision. It is a key element of the Mangrove ecosystem, as it provides an absolute flexibility for the liquidity provider to accept or renege an offer:
Taking available liquidity
Just like a classical orderbook, the Taker can buy or sell digital assets on Mangrove, with market or limit orders. He has access to an interface where he can look at the orderbook in real time and take available orders from the offer list.
When the Taker sends an order out, Mangrove executes the offer logic of all the offers it crossed:
If the first order is successful and the liquidity promise is fulfilled, it is removed from the book, and the Mangrove moves on to the next offer until the entirety of the Taker’s order is filled (whether it’s a limit or market order).
If during the execution, on order reneges on his offer, and the liquidity is not matched, the gas incurred is reimbursed to the Taker and Mangrove executes the next offer logic from the orderbook until desired volume or limit price.
The Taker can also add a level of complexity to his strategies by having the ability to snipe specific orders from the orderbook, we’ll get to that in Part 3!
Cleaning the orderbook
To ensure a clean orderbook, free from spam and failing offers, bots (or Keepers) are continuously scanning the orderbook. Keepers are responsible for detecting failing offers and making the offer fail on-chain, with a gas price set such that the offer's bounty compensates for the spent gas. They act as guardians of the Mangrove ecosystem.
A new on-chain strategies design space
The set of features proposed by mangrove present an opportunity for sophisticated on-chain participants, EVM wizards, MEV researchers, or more classical market-makers to come up with new on-chain trading strategies.
In the Part 3 of our introduction series, we’ll explore some of the strategies you’ll be able to deploy on Mangrove. Stay tuned!