Skip to main content

Reneging on offers

Since Mangrove offers do not provision liquidity, there must be a mechanism that ensures that most of the time, the order book does not contain 'fake offers', that is, offers that renege on their promises.

Mangrove uses Offer Provisions as a protection mechanism.

Consider an offer that promises 100 WETH for 100 DAI and requires 300k for execution. That gas will be paid for by the taker. If the 100 WETH is delivered, all is well.

If they are not, the taker must be compensated for the wasted gas. This is why, when creating an offer, market makers must provision for a potential bounty in the native token. The bounty depends on :

  • The average gas price, as estimated by Mangrove itself. Let's name it gasprice.
  • The amount of gas requested by the offer. Let's name it gasreq.
  • A minimum gas expense determined by Mangrove. Let's name it offer_gasbase.

To post their offer, the maker must lock gasprice * (gasreq + offer_gasbase) wei in Mangrove.

  • If the maker retracts their offer, the maker can choose to leave the provision on the offer for later reuse or deprovision the offer which will make the provision available to the maker for withdrawal.
  • If the offer is successfully executed, the provision stays locked inside the offer.
  • If the offer is executed and fails, part of the provision goes to the taker and the rest is available to the maker for withdrawal.
    • The bounty that goes to the taker depends on the gas actually used during the execution of the offer.

Now, a few observations about how the mechanism is implemented.

Encouraging early renege​

It is in the interest of a maker to code their contract such that, if they decide not to fill their promise, they do so as early as possible. This reduces the gas effectively spent and thus minimizes their operating costs.

Bounties finance fast updates​

During the lifecycle of a market order, makers of executed offers are called twice. Once to fulfill their promise, and once again to reinsert offers in the book. So even if an offer fails, the bounty mechanism lets the maker pay for reinserting their offer without delay. This reinsertion can use any on-chain information available at the time, such as oracles.

Don't update gasprice​

A small tip: an implementation detail means that as a maker, you can save a write if you make sure that the gas price associated with your offer does not change between offer updates. The best way to do that is to radically overestimate the gasprice when calling newOfferByTick / newOfferByVolume and to then maintain that gasprice on every subsequent call to updateOfferByTick / updateOfferByVolume.

Overestimate gasprice​

Internally, Mangrove will overestimate the gasprice to give a margin of error. This increases the lockup size for makers, but protects takers and Mangrove against a sudden gasprice increase which would leave any cleaning unprofitable.

Keeper mechanism​

Since Mangrove internal gasprice is overestimated, the activity of 'book cleaning' is profitable. For instance, consider a failing offer which requires 10k gas at an estimated gasprice of 100 gwei. A specialized Keeper bot can come in and execute the offer (after a local dry-run to ensure the offer does fail). As long as they pay a gasprice below 100 gwei, they will come out of the transaction earning a net profit.