Designing MEV Resistance Into a Compounding Liquidity Engine: The AFX Approach

#web3 #cryptocurrency #dao #defi

When I was building the POL compounding engine for AFX, one problem kept coming up that I had not fully thought through at the start: the protocol's own execution was a potential MEV target.
Every week, AFX needs to collect accumulated trading fees, rebalance them into the correct SOL/NONPC ratio, and reinvest them as permanently locked LP. That rebalancing step requires a swap. And a swap that executes on a predictable schedule, for a predictable amount, on a known pool — that is a sandwich attack waiting to happen.
I actually got this wrong at first. My initial assumption was that the execution would be small enough that it would not be worth targeting. That assumption did not hold up when I started modeling it seriously.

The Core Problem

MEV in DeFi is mostly unavoidable. Validators can reorder transactions. Searchers monitor the mempool. Anyone who knows a large swap is coming can front-run it and sell back at a profit.
At first I thought just executing and eating the cost might be acceptable. That turned out to be a mistake. For a typical user making a one-time swap, MEV is an annoyance. For a protocol executing weekly reinvestments indefinitely, it is a structural drain. Small extractions per execution, compounded over months, add up to a meaningful loss against what the compounding engine is trying to build.
So the question became: how do you make the execution pattern expensive enough to target that rational actors stop trying?

Why I limited execution to once per week

This wasn't originally about MEV mitigation, but it ended up influencing it more than I expected.
A protocol that executes daily creates more pattern recognition opportunities than one that executes weekly. More importantly, weekly execution lets fees accumulate to a meaningful size before reinvestment.
There is also a minimum threshold: execution only runs if the swap amount is at least 0.25 SOL equivalent on the rebalancing side. If fees fall below that, the week is skipped. I tested this threshold against pools ranging from roughly $50k to $2M in liquidity. At $50k, 0.25 SOL is a real fraction of weekly fee accumulation. At $2M, it is almost irrelevant. The threshold is mostly protective for early-stage operation when pool depth is thin.

Why the execution size cap ended up mattering

At first I thought size would not matter much for MEV resistance. Wrong again.
Capping execution to 0.5% of pool SOL reserves per week ended up being one of the more effective constraints. A sandwich attack extracts value proportional to slippage. Small execution, small slippage, small profit. At some point the gas cost and capital lockup for a successful attack approaches the expected return.
That initial framing held reasonably well — but not in thin markets. In one test case, a 1.2 SOL rebalance on a pool with roughly $80k liquidity triggered about 0.8% slippage. Above the cap and correctly rejected. On a $500k pool, the same 1.2 SOL produced under 0.1%. The cap is calibrated for early-stage operation where pools are not yet deep.
I enforced this against the on-chain reserve ratio rather than any off-chain price feed. Off-chain data can be stale or manipulated. 0.5% seemed like the least bad option across what I tested, though I am not convinced it is globally optimal.

Slippage cap

Maximum permissible slippage: 0.5%. Transaction fails entirely if exceeded. Not partial execution. Not retry at worse terms. Fail.
What I noticed after testing was that it affected both execution quality and attack surface in ways I had not anticipated. It prevents execution at terms that actively degrade the compounding base. It also removes the ability to force execution through adversarially manipulated pool conditions. If someone is manufacturing a situation where the protocol has to execute at bad terms, refusing is the right response.

Random delay: the part I underestimated

Failed executions retry on this schedule:

1st attempt: 100% of target, immediate
2nd attempt: 70%, random delay 2 to 4 hours
3rd attempt: 50%, another random delay 2 to 4 hours

The split execution I understood from the start. The random delay I initially treated as a minor detail.
Bigger deal than I expected. A fixed retry schedule is predictable. Anyone monitoring the protocol knows when the next attempt is coming. A random 2 to 4 hour window is not something you can reliably position around.

Accumulation suppression

One edge case I worked through late in the design: what happens if multiple weeks of skipped executions cause the reinvestment target to accumulate to an unusually large amount?
Large single execution. High-value target. Exactly the wrong outcome.
AFX splits accumulated targets above a pre-defined threshold across multiple weekly executions rather than processing them all at once. Keeps execution sizes within normal range regardless of how many weeks were skipped.

What this does not eliminate

These constraints do not eliminate MEV. A sophisticated actor with enough capital can still find profitable windows within them. The random delay creates unpredictability but not invisibility.
What the constraints do is raise the cost of extraction. Small execution sizes, hard slippage caps, random timing, split retries — the combination is designed to push expected profit below attack cost under typical conditions.
Whether it holds under adversarial conditions with higher-capital actors is something that can only be verified through actual operation. The specification is public. The execution constraints are on-chain. Anyone who wants to model the attack surface can do so.