DexModule7579

Solves the common MEV attack when attacker tries to insert his transactions in front of you.

The DEX Module is instrumental in interfacing with any DEX protocol to manage liquidity, execute swaps, and handle positions in liquidity pools. It encapsulates functionalities that facilitate seamles

Core Functionalities

  • Position Management:

    • mintNFT: Facilitates the minting of NFTs representing positions in the liquidity pool, extending the system's engagement in liquidity provision.

    • changeTickRange: Adjusts the tick range for a position by burning the previous one and minting a new one, ensuring the positions are kept within desired parameters.

  • Liquidity Provision:

    • addLiquidity: Adds liquidity to a pre-existing NFT.

    • Liquidity pool position withdraw: Allows for the withdrawal of liquidity pool positions to the vault or owner, ensuring control over assets.

  • Swaps and Asset Exchanges:

    • swap: Features custom MEV-Protection based on deviation threshold from oracle price.

    • swap to target R: Automates the preparation of liquidity tokens for adding liquidity or minting actions, aligning with target rate R.

  • Fees and Compounding:

    • Collect fees to vault address: Accumulates fees from liquidity provision to the vault address.

    • Autocompound: Collects fees to the vault and re-invests them into the pool, optimizing asset growth through compounding.

Solution for Deferred Execution:

The DexModule7579 facilitates asset swaps on the uniswap v3 with built-in protection against MEV (Maximal Extractable Value) attacks, specifically designed for account abstraction. When account invokes DexModule7579, it passes the swap parameters with the allowed deviation between the asset’s spot price and the oracle price stored in the target pool. This deviation is calculated as the average over a specified time period, ensuring that the swap can be fulfilled without slippage tolerance while still reverting in case of the slippage attack. The module enables deferred execution of the swap without explicitly providing the slippage comparing the resulted price with the weighted average and protecting against MEV attacks.

Note: To successfully protect against MEV attacks, it is necessary to increase the maximum number of liquidity observations. Pay attention to the cardinalityInit function in the tests. You can find more information about oracle's work in the Uniswap Oracle documentation.

Ditto JS SDK further expands the functionality to instantiate the cardinality on the relevant pool in case it is not initialized when creating automation. Sample deferred swap creation without explicit slippage parameter:

...
tokens[0] = wethAddress;
tokens[1] = usdcAddress;
deviation = 0.005e18;    // protects against the MEV via comparing the resulted price 
                         // with the weighted average in the pool
bytes memory swapInfo = abi.encode(tokens, poolFees, 0.5e18, false, false, deviation);
bytes memory executeData = abi.encodeWithSelector(
    dexModule7579.swapFromAccount.selector, 
    DexModule7579.SwapType.ExactInput, 
    swapInfo);
bytes memory callData = encodeExecute(address(dexModule7579), 0, executeData);
...

Example

You want to exchange Ether for USDC. But before your swap, a MEV attack was committed, which will not allow you to make an exchange at the desired price. The module has built-in protection against MEV attacks. The current spot price is compared with the weighted average price for the last 60 seconds, if the delta is greater than the deviation threshold, then the transaction reverts explicitly protecting from sandwiching.

PreviousCheckersNextAaveModule7579

Last updated