Approvals
Last updated
Last updated
During trade settlement, Mangrove needs certain approvals for transferring funds between the offer taker and the maker with Mangrove as an intermediary.
In the following, we shall refer to the diagram depicting an for a successful trade when a maker with a market order. For easy reference, the diagram is included below.
Refer to and the pages linked there for more details on trade execution on Mangrove.
Both activate and checklist functions can be customized by hooks to adapt them to a particular strat built on top of the strat library.
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.
In this case,
the router needs approval to transfer outbound from the offer owner 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 transferFrom calls.
As a maker you either post offers directly from an EOA, or post connected to .
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 token transfer for at least the amount that the offer .
Referring to the this maker approval is required for the transferFrom from the to Mangrove.
Maker contracts inheriting from provide two methods to assist with approvals:
performs the required approvals so as to allow the contract itself to interact with Mangrove on a set of assets.
verifies that this contract's current state is ready to be used to post offers on Mangrove.
As drawn, the 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.
For maker contracts that are built using the Strat Lib, the default behavior of the is to assume the funds are in the maker contract itself. When this is not the case, additional 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 the Strat Lib provides building blocks for advanced cash management strategies. The abstraction is provided for managing transfers of and token reserves of .
The maker contract should approve its router for any token it wishes to push to an 's reserve.
Please refer to the section on for more details, and refer to the API Reference for - the base that Strat Lib routers are implemented on top of.
When a Forwarder-based contract manages offers belonging to several offer owners
The building block provides a base for maker contracts that manage offers belonging to several offer owners.
A basic Forwarder strategy is to assume that the funds of each offer comes from its owner's addres. In such cases, the offer owners need to approve the maker contract's for outbound token transfer.
Please refer to the section on the and to the API Reference for the base for further reading.
The schematic diagram below illustrates the case, where a maker contract manages offers with a . Such a maker contract may be implemented with the building block combined with a .
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 token transfer for at least the amount of tokens that the taker gives.
Looking at the this taker approval is required for the transferFrom from the Taker to Mangrove.
