Skip to main content

More on failing offers

This section explains the reasons why some offers might fail using Kandel.


When we talk about an offer "failing", we mean that it could not execute. An offer can also fail to update itself. While we won't go into details in this part of the documentation, it is important to mention and differentiate those cases to further understand Kandel strategy's behavior.

  • makerExecute(): it is the callback function that is called when an offer is matched. Its role is to execute all offers that were posted on Mangrove by a given contract.
    • A failure in makerExecute() means the trade is canceled, and the bounty is given to the Taker as a compensation. The offer is removed from the book.
  • makerPosthook(): it is the callback function that is called after the offer execution (i.e. after a successful execution of makerExecute()).
    • A failure in makerPosthook() means the offer cannot update or repost itself after being taken. It does not cancel the trade, since it is called after makerExecute().

For a more visual explanation, see the call sequence overview diagram.

Kandel and makerExecute() failure​

After launching a Kandel strategy, Bids and Asks are populated with a certain volume. Kandel strategy's contract is handling all the posting for the user, using liquidity that has been previously deposited.
Therefore, since the user is not in charge of writing and maintaining the smart contract, failures to execute makerExecute() can be almost entirely ruled out, with the exception of some very specific scenarios such as:

  • Someone severely modifies the volume distribution/sourcing methods, creating issues when a Kandel Bid/Ask is taken (via the SDK)

  • Kandel runs on AAVE, and the user's liquidity is not available for sourcing at the time the offer is taken. That could happen if the user's funds are suddenly borrowed entirely (on AAVE)

Kandel and makerPosthook() failure​

The main failures that Kandel could run into are linked to reposting Bids and Asks. This has little incidence for the user, nor does it affect the behavior of his Kandel strategy.
Non-reposted liquidity will be placed into the Unallocated liquidity reserve, and the offer will be "empty" for Kandel, until the user replenishes it.


If too many empty offers stack up, it would diminish Kandel's ability to profit from the spread, and therefore the overall generated yield. Kandel is not intended as a "set and forget" strategy, and needs ongoing maintenance and checks.

Reposting offers is handled with makerPosthook(), and failure could happen if:

  • The residual of a partially taken offer is too small with regard to density:
    • A partially taken offer is the result of a Taker either partially sniping an offer, or placing a Market order
    • If an offer is almost entirely taken, the remainder (dust) could be too small to pass the density check, leading to a failure to repost itself
  • Kandel runs out of gas during the execution of the makerPosthook() because the gas requirements suddenly changed
    • This is unlikely to happen, but it theoretically could (if the order book becomes very dense in offers, for example)