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 Protocol -> Technical Reference -> Overview and the pages linked there for more details on trade execution on Mangrove.

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 to post offers 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.

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

The maker contract should approve its router for any token it wishes to push to an offer owner's reserve.

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 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 router for outbound token transfer.

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

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.