Executing offers

Offers are created with an associated account (a %%maker contract|maker-contract%% or EOA) and listed on Mangrove offer lists.

• If the account is an EOA, no logic will be associated to the offer. These %%on-the-fly|on-the-fly-offer%% offers should have the promised liquidity on the EOA when the offer is matched during a market order.
• If the account is a maker contract, it should implement the offer logic through the IMaker interface. It must at least implement the makerExecute function, otherwise all offer executions will fail.

Here is the offer lifecycle, with the parts addressed in this section bolded:

1. A contract maker.eth creates an offer.
2. Mangrove stores the offer info, including the address maker.eth.
3. Account user.eth sends a market order to Mangrove which matches that offer.
4. Mangrove transfers tokens from user.eth to maker.eth.
5. Mangrove calls the function makerExecute of maker.eth.
6. Mangrove transfers tokens from maker.eth to user.eth.
7. The offer is now out of its offer list, but may be updated at step 9 by maker.eth.
8. If the transfer at step 6 is not a success, Mangrove reverts to the state prior to the transfer of step 4, and sends a %%bounty|bounty%% to user.eth taken from the offer's %%provision|provision%%.
9. Mangrove calls the function makerPosthook of maker.eth.

Multiple offers per address

An account can post more than one offer. When it gets called through makerExecute, it will receive the %%id|offer-id%% of the offer being executed as well as additional information.

Example scenario

Suppose that an offer managed by a contract promises 100,000 DAI in exchange for 100,000 USDC.

Upon being called, the contract has 100,000 USDC available (just given to it by Mangrove) and may source DAI from anywhere on the chain. It needs to end execution with 100,000 DAI available and ready to be transferred by Mangrove through transferFrom.