During trade settlement, Mangrove needs certain approvals for transferring funds between the offer taker and the maker with Mangrove as an intermediary.
Call sequence overview
In the following, we shall refer to the diagram depicting an overview of the call sequence for a successful trade when a maker offer is taken with a market order. For easy reference, the diagram is included below.
Refer to Contracts -> Technical Reference -> Overview and the pages linked there for more details on trade execution on Mangrove.
As the Mangrove contract handles transfers during trade settlement, this means that either the maker EOA or the maker contract needs to approve Mangrove for an outbound token transfer for at least the amount that the offer gives.
Maker contracts inheriting from
Maker contracts inheriting from MangroveOffer provide two methods to assist with approvals:
activateperforms the required approvals so as to allow the contract itself to interact with Mangrove on a set of assets.
checklistverifies that this contract's current state is ready to be used by
msg.senderto post offers on Mangrove.
Advanced maker approvals
As drawn, the call sequence diagram depicts a situation where the funds for the smart offer are available directly on the maker contract holding the offer logic. However, for more advanced smart offers several smart contracts may come into play when liquidity is sourced.
As an outset, the administrator of the maker contract and any other contracts involved in trade settlement initiated by Mangrove must ensure that the proper approvals for liquidity flow is in place before offers are executed.
For maker contracts that are built using the Strat Lib, the default behavior of the offer logic is to assume the funds will come from the offer owner reserve. If the address of the reserve is not the maker contract itself, then proper approvals need to be set up so that liquidity can be brought from there. There are two noteworthy cases we comment below.
When a Strat Lib router is used to manage the funds of the maker
As described under Liquidity routing the Strat Lib provides building blocks for advanced cash management strategies. The router abstraction is provided for managing transfers of outbound and inbound token reserves of offer owners.
For the maker contract it must approve its router for any token it wishes to push to an offer owner's reserve.
Strat Lib routers provide two methods to assist with their approvals:
activateperforms all router-centric approvals necessary to route liquidity for a given token.
checklistverifies that router has necessary approvals to route liquidity for a given token and a given reserve (see below for more on reserve approvals).
When a Forwarder-based contract manages offers belonging to several offer owners
The Forwarder building block provides a base for maker contracts that manages offers belonging to several offer owners.
A basic Forwarder strategy is to assume that each offer owner's reserve is actually the offer owner's address. In such cases, the offer owners need to approve the maker contract or its router (if it has one) for outbound token transfer.
In particular, for contracts based on the Forwarder building block the usage of a liquidity router is required - so in this case, the offer owners need only consider approval for the router of the
The schematic diagram below illustrates the case, where a maker contract manages offers with a router and external offer reserves. Such a maker contract may be implemented with the Forwarder building block combined with a router.
In this case,
- the router needs approval to transfer outbound from the Maker reserve and needs approval to transfer inbound from the maker contract.
- Mangrove needs approval to transfer outbound from the Maker contract.
This is illustrated in the diagram below where we only focus on the
While we are mainly focused on the maker-side in this section, it is worth noting that the offer taker (be that an EOA or a contract) needs to approve Mangrove for an inbound token transfer for at least the amount of tokens that the taker gives.
Looking at the call sequence diagram this taker approval is required for the
transferFrom from the Taker to Mangrove.