Create ESD (and clones) "advance" and "CouponClipper" inspectors

[Austin-Williams]

(This is a brain-dump of all the info needed to write inspectors for ESD (Empty Set Dollar) MEV.

Intro

For the purposes of this inspector it is not important to understand how ESD works or what it is. The only important thing to know is that there are two race conditions that occur in the protocol, and the winner of the races wins (sometimes astronomical) profits. This creates a lot of MEV - enough that it is worth writing an inspector for it.

ESD has several clones, and most of them use the same pattern. So an inspector for ESD could also be used (or slightly tweaked) to find MEV for all/most of ESD clones.

There are two types of MEV created by ESD: "Advance incentives" and "Coupon redemption".

ESD has a DAO Contract where most of the interesting action happens. This is a proxy contract that points to an implementation contract that can be updated by governance.

Advance Incentives

ESD operates on 8 hour epochs. In order to advance to the next epoch, someone (anyone) must call the advance function on the DAO. In order to incentivize this call to happen on time, the protocol mints some amount of ESD tokens into existence and gives it to whoever called the advance function. (The amount of ESD can vary. It was once 100 ESD per advance. Now it is 1000 ESD per advance).

As a result, there is usually a race -- in the form of a PGA -- to call the advance function. So this is one form of MEV.

Detecting and measuring success

When a user calls the advance function, an Advance event is emitted. Any tx that emits an Advance event is a successful capture of MEV. So detection of success is straightforward.

Here is an example tx that calls advance and receives a reward (note that the call to advance is an internal call).

The amount of MEV captured by the successful tx is value of the ESD tokens the caller receives for advancing (this is known as the "advance incentive"). In the example above, that is 1000 ESD. The amount of tokens can be detected by looking for an ERC20 event that transfers from address(0) to the caller of the advance function. Note that not all ERC20 transfers from address(0) to some other address are "advance rewards" (there is usually more than one such event). Only the transfer from address(0) to the caller of the advance function should be counted as the "advance reward".

Detecting checks and failures

There are two ways bot txs "check" to see if advance can be called:

1. Checking block.timestamp against the timestamp when the epoch can be advanced. This is usually done by passing in the target timstamp as a parameter to the function call. For this reason, these checks are hard to detect (or at least classify as "attempts to advance an epoch") because they never actually interact with any ESD contracts. So it might be worth ignoring these.
2. Checking the "epoch time" by calling the epochTime function and comparing it either to a passed in parameter, or by comparing it to the output of the epoch function. Either way, any call to the epochTime function and/or the the epoch function by any contract (other than the ESD DAO contract itself) should be considered a "check".

If a tx "checked" and the tx did not result in an Advance event emitting, then it was a failure.

Coupon redemptions

By far the largest amount of MEV created by ESD is during "CouponRedemptions".
Under some conditions, ESD allows users to burn ESD for "coupons". Under other conditions (called "expansions"), users can cash these "coupons" in for ESD (usually more ESD than they originally burned). However, during expansions, there is a very limited number of coupons that can be redeemed per epoch. And redemption is on a first-come-first-served basis.

This creates a race condition during expansions: as soon as the epoch is advanced, there is a huge race (in the form of a PGA) to be the first to redeem coupons.

A user's coupons can be redeemed by a third party (with the user's permission), and this fact results in an interesting dynamic. Bot runners offer a service: "We'll use our bots to win the race and redeem your coupons for you, in exchange for some percentage of the ESD you get from the redemption".

This bot-user coordination happens primarily via a smart contract called CouponClipperV2. (Originally it started with CouponClipperv1, so having the inspector look at that contract as well will mean it finds more MEV).

Detecting and measuring success

Bots race to call the redeem function on the CouponClipper contract (same function name for both CouponClipperV1 and CouponClipperV2). Any tx that calls redeem and gets paid out some ESD (which is detectable by an ERC20 Transfer event from the CouponClipper contract to the caller of the redeem function) is a success. There often (though not always) several calls to redeem in a single transactions, with each call earning the caller more ESD as a reward.

The total sum of all the ESD transferred to the caller (from the CouponClipper contract) is the measure of MEV captured.

Note: Coupon redemptions usually (but not always) occur in the same tx as an "epoch advance". The most common thing to see is call to advance to get into the new epoch (which makes coupon redemption available if it is an expansion phase), followed by a few coupon redemptions in the same tx.

Detecting checks and failures

The most common way to check if coupon clipping is available is to call the totalRedeemable function to see if returns a number greater than 0.

Any call to the totalRedeemable function that doesn't come from the DAO contract itself can be considered a "check".

ESD copycats

There are several ESD "copycats". Almost all of them have died on the vine. Most have created a decent amount of MEV in the form of "advance incentives". But I don't think any have survived long enough to have a meaningful amount of MEV created by coupon redemptions. So any efforts to find MEV in the ESD clones should probably just focus on advance incentives.

Links to clones' DAO contracts:

• DSD
• ZAI
• BSD
• ZSD
• U8D

And there exist a few others as well (I don't have links handy for them).

Conclusion

Hopefully these explanations are clear enough. If not, please feel free to ask me any questions.
There should be a few million dollars (7-8 figures) worth of MEV to be found here.
I don't know that I'll have time to write these inspectors myself.