Search projects, hackathons, sponsors and tech

    ← All projects

    Demo

    About

    The problem it solves Addressing Initial Liquidity Front-Running Attack The core feature of an initial liquidity front-running attack is the one-time purchase of a large quantity of tokens within the same block as the initial liquidity deployment, thereby monopolizing the initial token supply. To counter this key characteristic, MEV Guard’s solution provides protection for a specific range of blocks following the deployment of the initial liquidity pool. The details are as follows: 1.Protection Period Configuration: Based on the block times of different chains, an initial liquidity protection period is established, lasting for a variable number of blocks, typically extending over hundreds of blocks. 2.Randomness Check: Introduce a randomness check to dynamically adjust the probability based on the number of transactions attempted in the previous block. Transactions that fail the check will be interrupted rather than reverted, ensuring all transactions have an equal opportunity for execution. 3.Transaction Count Restriction: Within each block, the current liquidity pool can only process one executable transaction, with any subsequent transactions being interrupted to reduce the impact of Sybil attacks. 4.Transaction Size Limitation: The maximum token amount per transaction must not exceed one percent of the total reserves in the liquidity pool, preventing monopolization of the token supply. 5.Protection Period Termination: Upon the conclusion of the initial liquidity protection period, all the aforementioned restrictions are automatically removed. Addressing Sandwich Attack The core characteristic of a sandwich attack is that the attacker inserts their own transactions before and after a target transaction within the same block, involving both front-running and back-running. In other words, a single sandwich attack involves at least three transactions. To address this key feature, MEV Guard’s solution introduces an Anti-MEV switch, allowing users to choose whether to protect their transaction from sandwich attacks. The details are as follows: 1.Anti-MEV Switch: When activated, it enforces that the current transaction becomes the final executable transaction for this trading pair in the current block, reverting all subsequent transactions for that pair within the same block. This prevents the attacker from executing the back-running transaction, directly disrupting the conditions necessary for a sandwich attack, while also making flash loans unusable for such attacks, thereby raising the attacker’s capital costs. 2.Transaction Size Check: To prevent abuse, the protocol checks the size of Anti-MEV transactions. Only transactions with a token output exceeding a certain threshold (e.g., 0.5% of the total liquidity pool reserves, adjustable) can pass, preventing the protocol from becoming unavailable due to DDoS attacks. 3.MEV Fee: An additional MEV fee is charged for each Anti-MEV transaction to discourage unnecessary use while simultaneously increasing the market-making profits for liquidity providers (LPs).