Executing Offers

Overview

Offers listed on Mangrove are tied to an associated account, either an Externally Owned Account (EOA) or a Maker Contract.

• If the account is an EOA, the offer has no custom logic. These are called on-the-fly offers. The EOA must already hold the promised liquidity when its offer is matched.

• If the account is a maker contract, it must implement the IMaker interface. At minimum, it must define the makerExecute function, otherwise all offer executions will fail.

Offer Lifecycle

1. A maker contract (maker.eth) creates an offer.

2. Mangrove stores the offer data, including the maker’s address maker.eth.

3. A taker (user.eth) submits a market order that matches the offer.

4. Mangrove transfers tokens from user.eth → maker.eth.

5. Mangrove calls makerExecute on maker.eth.

6. Mangrove transfers tokens from maker.eth → user.eth.

7. The offer is removed from the offer list.

8. If execution fails, Mangrove rolls back to the pre-trade state (step 4) and compensates the taker with a bounty, paid from the offer’s provision.

9. Mangrove calls makerPosthook on maker.eth (if implemented), allowing the maker to update or repost offers.

Multiple Offers per Maker

A single maker contract or EOA can manage multiple offers. When Mangrove calls makerExecute, it includes the offer id and related execution data, allowing the maker contract to identify which specific offer was triggered.

Example Scenario

A maker contract has an offer promising 100,000 DAI in exchange for 100,000 USDC.

Execution proceeds as follows:

1. Mangrove calls makerExecute, having just transferred 100,000 USDC from the taker to the maker contract.

2. The maker contract sources 100,000 DAI, possibly from another protocol, pool, or on-chain strategy.

3. By the end of execution, the maker must ensure that 100,000 DAI are available for Mangrove to transfer to the taker via transferFrom.

If this final transfer fails, Mangrove cancels the trade and compensates the taker using the offer’s provision.