Skip to main content

Approvals

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.

Mangrove call sequence induced by a taker order

Maker approvals

As a maker you either post on-the-fly offers directly from an EOA, or post smart offers connected to maker contracts.

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.

Referring to the call sequence diagram this maker approval is required for the transferFrom from the Offer Logic(s) to Mangrove.

Maker contracts inheriting from MangroveOffer

Maker contracts inheriting from MangroveOffer provide two methods to assist with approvals:

  • activate performs the required approvals so as to allow the contract itself to interact with Mangrove on a set of assets.
  • checklist verifies that this contract's current state is ready to be used by msg.sender to 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:

  • activate performs all router-centric approvals necessary to route liquidity for a given token.
  • checklist verifies that router has necessary approvals to route liquidity for a given token and a given reserve (see below for more on reserve approvals).

Please refer to the section on Routers for more details, and refer to the API Reference for AbstractRouter - the base that Strat Lib routers are implemented on top of.

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 Forwarder contract.

Please refer to the section on the Forwarder building block and to the API Reference for the Forwarder base for further reading.

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 transferFrom calls.

Taker approvals

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.