Anatomía del MEV: sandwiches, frontrunning y el bosque oscuro del mempool

Cuando firmas un swap en un exchange descentralizado y lo transmites a un endpoint RPC público, no has enviado una instrucción privada a un motor de emparejamiento. Has publicado una declaración de intención firmada y ejecutable en un tablón de anuncios global, y le has adjuntado una recompensa —el precio del gas— para quien acepte ejecutarla. Cualquiera puede leer esa declaración. Nadie está obligado a ejecutarla de forma justa, en orden, ni a ejecutarla en absoluto. El orden en el que se incluye respecto a otras transacciones no es una propiedad de tu envío; es una decisión que toma un tercero que se beneficia de tomarla en tu contra.

Este es el núcleo incómodo del trading on-chain. En Arbitraje estadístico y pairs trading en mercados cripto mencionamos, de pasada, que mover una posición entre un CEX y un DEX conlleva "riesgo de MEV" y dejamos el término suelto. Este artículo salda esa deuda. Es la puerta de entrada a una serie sobre la economía de la ejecución on-chain, y su función es definir el vocabulario —mempool, bundle, backrun, sandwich, PBS— con la precisión suficiente para que las siguientes piezas sobre arbitraje atómico con flash loans y liquidez concentrada de Uniswap v3 para quants puedan asumir que ya entiendes la máquina.

El MEV —Maximal (o Maximum) Extractable Value, valor extraíble máximo— es la ganancia que una parte puede extraer al elegir la inclusión, exclusión y ordenamiento de las transacciones dentro de un bloque, más allá de la recompensa estándar del bloque y las tarifas de prioridad. No es un bug; es una consecuencia estructural de cómo las blockchains sin permiso ordenan las transacciones. Desde que el mecanismo se caracterizó formalmente en 2019, el valor extraído acumulado ha llegado a miles de millones de dólares, y toda una industria —searchers, builders, relays, proponentes de bloques— ha crecido para capturarlo y redistribuirlo. Si haces trading on-chain, o estás pagando este impuesto o has tomado medidas deliberadas para no hacerlo.

1. El ciclo de vida de una transacción: por qué tu intención es pública

Para ver dónde se filtra el valor, sigamos una transacción desde tu wallet hasta un bloque finalizado.

El mempool público

Cuando tu wallet firma una transacción y la envía al endpoint RPC de un nodo estándar, el nodo la valida (firma, nonce, saldo suficiente) y, si pasa, la propaga por la red peer-to-peer a otros nodos. Cada nodo mantiene estas transacciones aún no incluidas en un buffer local llamado mempool (memory pool, pool de memoria). En uno o dos segundos, esencialmente todos los nodos de la red —incluidos nodos operados por partes cuyo negocio entero consiste en extraer valor de transacciones pendientes— tienen una copia de tu transacción firmada y completamente decodificada.

"Completamente decodificada" es la frase clave. Tu transacción no es un blob opaco. Es una llamada codificada en ABI a un contrato conocido. Cualquiera que observe el mempool puede decodificarla y leer, en términos simples: esta dirección está a punto de cambiar 40 ETH por USDC en el pool WETH/USDC de Uniswap v2, y aceptará como mínimo 96.000 USDC. Esa última cláusula —el output mínimo aceptable— es tu tolerancia de slippage, y no es una pista. Es un parámetro duro compilado dentro del calldata. Pronto veremos que también es el presupuesto del atacante.

Al mempool a veces se le llama el bosque oscuro (dark forest), en referencia a un ensayo de 2020 de Dan Robinson y Georgios Konstantopoulos que tomó prestada la metáfora de Liu Cixin: un espacio donde cualquier entidad visible es cazada de inmediato por depredadores que no puedes ver. Transmite una transacción rentable e ingenua al mempool público y puede que nunca llegue a un bloque en la forma en que la firmaste: un bot habrá consumido la oportunidad y reconfigurado el bloque circundante en tu contra.

El precio del gas como cola de prioridad

El mercado de tarifas de Ethereum (tras EIP-1559) divide el precio del gas en una tarifa base del protocolo, que se quema, y una tarifa de prioridad (la "propina"), que va al proponente del bloque. Cuando se construye un bloque, el builder está económicamente motivado a incluir las transacciones que más le pagan. En una primera aproximación, el mempool es una cola de prioridad ordenada por la propina: a mayor propina, inclusión más temprana.

Este es el mecanismo que hace que el ordenamiento sea comprable. Si veo tu swap pendiente y quiero que mi transacción se ejecute inmediatamente antes que la tuya, no necesito hackear nada. Simplemente envío una transacción que paga una propina más alta. El builder, siguiendo su incentivo, coloca la mía primero. El ordenamiento no es una garantía de equidad que ofrece el protocolo; es una subasta que el protocolo ejecuta, y el lote subastado es el derecho a actuar sobre la información contenida en tu transacción pendiente.

Dos hechos se combinan para formar todo el problema del MEV:

1. Las transacciones pendientes son visibles (mempool público).
2. Su ordenamiento está en venta (subasta por prioridad de propina).

Todo lo que sigue es un corolario de esto.

2. Mecánica del sandwich, con la matemática real

El sandwich es la estrategia tóxica canónica de MEV contra un trader, y vale la pena desarrollar la aritmética porque los números explican por qué tu configuración de slippage es el parámetro defensivo más importante que controlas.

El invariante de producto constante

Un pool de Uniswap v2 mantiene reservas $x$ del token X e $y$ del token Y, y hace cumplir el invariante

$x \cdot y = k$

después de cada operación (ignorando las comisiones por un momento). Si un trader vende $\Delta x$ del token X en el pool, la nueva reserva de X es $x + \Delta x$, y para preservar $k$ el pool debe pagar

$\Delta y = y - \frac{k}{x + \Delta x} = \frac{y \, \Delta x}{x + \Delta x}.$

Con la comisión del 0,3% de Uniswap v2, el input se escala por $\gamma = 0.997$:

$\Delta y = \frac{y \, \gamma \, \Delta x}{x + \gamma \, \Delta x}.$

La propiedad clave: cuanto más compras en una dirección, peor es tu precio marginal. El impacto de precio es convexo. Esta convexidad es exactamente lo que el atacante monetiza.

El escenario

Tomemos un pool WETH/USDC. Para mantener los números limpios, supongamos reservas que sitúan al ETH en aproximadamente 2.500 USDC:

• $x = 10.000$ WETH
• $y = 25.000.000$ USDC
• $k = 2.5 \times 10^{11}$

Quieres comprar USDC con 40 WETH (una venta de WETH al pool). Ignorando las comisiones para la ilustración, un fill honesto en un bloque vacío te daría

$\Delta y = \frac{25{,}000{,}000 \cdot 40}{10{,}000 + 40} = \frac{1{,}000{,}000{,}000}{10{,}040} \approx 99{,}601 \text{ USDC}.$

El precio spot antes de tu operación es $25.000.000 / 10.000 = 2.500$ USDC/WETH, así que 40 WETH "valen" 100.000 USDC al mid previo a la operación. Recibes 99.601 —la brecha de ~399 USDC es tu propio impacto de precio más las comisiones. Ahora supongamos que estableces una tolerancia de slippage del 1%. El amountOutMin de tu transacción es

$99{,}601 \times 0.99 \approx 98{,}605 \text{ USDC}.$

Ese número ahora es público en el mempool. Le dice a cualquier observador: esta persona aceptará hasta un mínimo de 98.605 USDC por sus 40 WETH. La diferencia entre lo que obtendrías en un bloque limpio (99.601) y tu piso (98.605) —unos 996 USDC— es el margen que le has entregado voluntariamente a quien te haga frontrunning. Este es el presupuesto del atacante.

El ataque, paso a paso

Un searcher construye tres transacciones y fuerza este orden dentro de un mismo bloque:

1. Frontrun (el atacante compra primero). El atacante vende su propio WETH al pool antes que tú, empujando el precio del USDC hacia arriba (el del WETH hacia abajo) de modo que cuando tu operación se ejecute, recibas menos USDC por WETH. El atacante dimensiona esto de forma que tu transacción todavía cumpla tu amountOutMin —si no lo hace, tu swap revierte y no hay víctima que emparedar. El tamaño óptimo de frontrun es el mayor que te deja exactamente en tu piso.

Supongamos que el atacante hace frontrun con 40 WETH propios. El pool pasa a $x = 10.040$, y por el invariante el atacante recibe

$\frac{25{,}000{,}000 \cdot 40}{10{,}040} \approx 99{,}601 \text{ USDC out},$

dejando las reservas en $x = 10.040$ WETH, $y \approx 24.900.399$ USDC.

2. Víctima (tu swap se ejecuta contra el pool empeorado). Tus 40 WETH ahora se ejecutan contra estas reservas:

$\Delta y = \frac{24{,}900{,}399 \cdot 40}{10{,}040 + 40} = \frac{996{,}015{,}960}{10{,}080} \approx 98{,}811 \text{ USDC}.$

Verifiquemos la restricción: 98.811 > 98.605, así que tu transacción no revierte —se ejecuta, solo que peor. Recibiste 98.811 en lugar de los 99.601 que habrías obtenido en un bloque limpio. Pierdes aproximadamente 790 USDC, y no tienes idea de que sucedió; tu swap "tuvo éxito". El pool ahora es $x = 10.080$ WETH, $y \approx 24.801.588$ USDC.

3. Backrun (el atacante vende de vuelta). El atacante ahora vende de vuelta al pool el USDC que compró en el paso 1 —o equivalentemente recompra su WETH— capturando el precio elevado que tu operación creó. Comprando de vuelta WETH con los ~99.601 USDC que tiene:

$\Delta x = \frac{10{,}080 \cdot 99{,}601}{24{,}801{,}588 + 99{,}601} \approx \frac{1{,}004{,}010{,}080}{24{,}901{,}189} \approx 40.32 \text{ WETH}.$

El atacante gastó 40 WETH en el paso 1 y recuperó 40,32 WETH en el paso 3 —una ganancia de aproximadamente 0,32 WETH (~800 USDC) antes del gas, extraída casi por completo de tu presupuesto de slippage. Ajusta tu slippage y ese presupuesto se reduce; el tamaño óptimo de frontrun del atacante cae, y por debajo de cierto umbral el sandwich deja de ser rentable después del gas y el searcher te ignora.

La lección no es "la tolerancia de slippage es mala". Necesitas algo de tolerancia o tus transacciones revertirán ante un movimiento de precio ordinario. La lección es que la tolerancia de slippage es una cantidad directamente extraíble, y configurarla en un valor perezoso por defecto como 1% o, peor, "auto" en un pool poco líquido, equivale a dejar esa cantidad de dinero sobre la mesa para cualquiera que esté observando. En un pool de baja liquidez donde tu propia operación mueve el precio varios puntos porcentuales, un slippage por defecto puede entregar una fracción sorprendente de tu nocional.

Un esbozo mínimo de la condición de ganancia de un searcher:

def sandwich_profit(x, y, gamma, victim_dx, victim_min_out, attack_dx, gas_cost):
    out1 = (y * gamma * attack_dx) / (x + gamma * attack_dx)
    x1, y1 = x + attack_dx, y - out1
    vout = (y1 * gamma * victim_dx) / (x1 + gamma * victim_dx)
    if vout < victim_min_out:
        return None  # victim would revert; no sandwich
    x2, y2 = x1 + victim_dx, y1 - vout
    got_back = (x2 * gamma * out1) / (y2 + gamma * out1)
    return got_back - attack_dx - gas_cost  # profit in WETH

El searcher ejecuta una pequeña optimización sobre attack_dx para encontrar el mayor frontrun que mantenga vout >= victim_min_out. Ese óptimo es donde se activa tu piso de slippage —lo cual es otra forma de decir que la ganancia del atacante está limitada precisamente por el margen que dejaste.

3. Una taxonomía del MEV: tóxico versus benigno

"MEV" se usa como insulto, pero no todo es extracción de una víctima. Ayuda clasificar las estrategias según si alguien queda peor por el ordenamiento.

Frontrunning. Observar una transacción pendiente rentable, copiarla o adelantarse a ella, y pagar una propina más alta para ejecutarse primero. El arquetipo es ver una compra grande que moverá un precio y comprar antes que ella. Puramente tóxico: la víctima obtiene un precio peor, o su oportunidad se roba directamente.

Backrunning. Colocar tu transacción inmediatamente después de una transacción objetivo para actuar sobre el estado que esta crea. Fundamentalmente, un backrun puro no degrada la ejecución del objetivo —se ejecuta después, por lo que el precio de la víctima ya está fijado. Si tu swap grande desalinea el pool WETH/USDC respecto a Binance, un arbitrajista hace backrun sobre ti para realinearlo y se embolsa la diferencia. Tú no sales perjudicado; de hecho, este arbitraje es lo que mantiene los precios on-chain alineados con el mercado más amplio. El backrunning es el extremo benigno del espectro, y —como veremos— los sistemas modernos de protección contra MEV están construidos precisamente para devolver la ganancia de backrun al usuario que la creó.

Sandwiching. Un frontrun y un backrun envolviendo a la misma víctima, como diseccionamos arriba. Tóxico por construcción: el frontrun existe únicamente para empeorar el fill de la víctima de modo que el backrun pueda cosecharlo.

Arbitraje atómico. Una única transacción que compra un activo barato en una plataforma y lo vende caro en otra —digamos WETH más barato en Uniswap que en Sushiswap— generando una ganancia libre de riesgo, todo o nada dentro de una sola transacción (revierte si no es rentable). No hay una víctima específica; está cerrando una discrepancia de precio que el mercado dejó abierta. Generalmente considerado benigno —mejora la consistencia de precios entre plataformas— y es el tema de la pieza sobre arbitraje atómico y flash loans de esta serie, donde la propiedad de "sin capital requerido" de los flash loans lo hace especialmente contundente.

Liquidaciones. Cuando una posición de préstamo (Aave, Compound, Maker) cae por debajo de su umbral de colateral, el protocolo ofrece una bonificación a quien repague la deuda incobrable y se quede con el colateral. Los searchers compiten por ser ese liquidador. Hay una "víctima" —el prestatario liquidado— pero de todos modos será liquidado según las reglas del protocolo; la competencia de MEV mayormente determina quién obtiene la bonificación y, mediante la competencia, puede reducirla. Podríamos llamarlo neutral a benigno para la salud del mercado, desagradable para el prestatario.

Un mapa aproximado:

La línea tóxico/benigno importa porque toda la pila moderna de mitigación de MEV es un intento de suprimir las estrategias tóxicas mientras se preservan —y redistribuyen— las benignas. No se pueden prohibir los juegos de ordenamiento sin romper también el arbitraje que mantiene honestos los precios de los DEX. El truco consiste en devolver el valor tóxico a la persona a quien se le quitó.

4. Una breve historia: de las subastas de gas a Flashbots

Flash Boys 2.0 y las subastas de gas por prioridad

El fenómeno fue nombrado y medido en el paper de 2019 "Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges" de Philip Daian, Steven Goldfeder, Tyler Kell, Yunqi Li, Xueyuan Zhao, Iddo Bentov, Lorenz Breidenbach y Ari Juels. El paper introdujo el término "miner extractable value" (más tarde generalizado a valor extraíble máximo a medida que la industria pasó de los mineros de proof-of-work a los proponentes de proof-of-stake) y documentó las subastas de gas por prioridad (PGAs): bots pujando unos contra otros por el precio del gas, en tiempo real, para ganar el ordenamiento de una oportunidad rentable.

Las PGAs eran visiblemente patológicas. Como la única palanca que tenían los bots era el precio de gas público, libraban guerras de pujas abiertas —reenviando repetidamente con propinas cada vez más altas dentro de los mismos segundos— para reclamar un solo arbitraje o liquidación. De esto se derivaron dos consecuencias desagradables. Primero, esto congestionaba la red e inflaba los precios de gas para todos, estuvieran o no relacionados con MEV. Segundo, y más alarmante, el paper argumentaba que si el MEV disponible en un bloque superaba la recompensa del bloque, los mineros racionales estarían incentivados a reorganizar la cadena para robarlo, amenazando la estabilidad del propio consenso. El MEV no era solo un problema de equidad para los usuarios; era una amenaza para la cadena.

Flashbots como respuesta

Flashbots se lanzó en 2020 para desactivar la PGA. Su idea: mover la subasta de ordenamiento fuera del mempool público hacia un canal de pujas selladas, fuera de la cadena. En lugar de transmitir una transacción y pelear una guerra de gas pública, un searcher ensambla un bundle —una lista ordenada de transacciones que se incluirán de forma atómica, todo o nada, en un orden relativo específico— y lo envía de forma privada a un block builder, junto con una puja (a menudo pagada como una transferencia directa al proponente en lugar de a través del precio del gas). El builder ensambla el bloque más valioso que puede a partir de todos los bundles y transacciones que recibe y se lo ofrece al proponente.

Dos cosas mejoran a la vez. Los searchers dejan de saturar el mempool público con pujas fallidas, por lo que la externalidad del precio de gas sobre los usuarios ordinarios se reduce. Y el bundle ganador o se incluye intacto o no se incluye en absoluto, eliminando las transacciones de "frontrun fallido" que solían congestionar los bloques. La guerra de pujas sigue ocurriendo —solo que ahora ocurre como una subasta privada dentro del builder en lugar de una pelea a gritos pública en la cadena.

PBS: separación entre proponente y builder

La arquitectura de Flashbots se generalizó en la separación entre proponente y builder (PBS, proposer-builder separation), el modelo dominante en Ethereum hoy. Los roles se dividen:

• Los searchers encuentran oportunidades de MEV y las empaquetan en bundles.
• Los builders compiten para ensamblar el bloque completo más valioso a partir de bundles y transacciones públicas.
• Los relays se ubican entre builders y proponentes, recibiendo bloques completos de los builders y pasando al proponente únicamente los encabezados del bloque más una puja de valor, de modo que el proponente se compromete con un bloque antes de ver su contenido (evitando que el proponente simplemente robe el MEV).
• Los proponentes (validadores) eligen el encabezado con la puja más alta, lo firman y cobran el pago.

Esto se implementa fuera del protocolo mediante MEV-Boost, un middleware que ejecuta la abrumadora mayoría de los validadores de Ethereum —del orden del 80-90% de los bloques se construyen a través de builders externos vía MEV-Boost. Funciona, pero depende de relays confiables. El siguiente paso, la PBS consagrada (ePBS, EIP-7732), busca incorporar la separación entre proponente y builder directamente en el protocolo de Ethereum y eliminar la dependencia de relays confiables. A mediados de 2026 está prevista para la actualización Glamsterdam, con el objetivo de una activación en mainnet más adelante en 2026, y sus proponentes afirman que puede reducir sustancialmente las pérdidas de MEV para los usuarios al mejorar cómo se comprometen los bloques y al estrechar la ventana para el reordenamiento tóxico. Trata las cifras exactas como aspiracionales hasta que se lance, pero la dirección es clara: el protocolo está absorbiendo la cadena de suministro de MEV que durante años fingió no existir.

MEV-Share: devolviendo el valor

El desarrollo más trascendente para los traders ordinarios es MEV-Share, la subasta de flujo de órdenes de Flashbots. La idea invierte el bosque oscuro. En lugar de que tu transacción sea visible para todos los depredadores, la envías de forma privada a un nodo MEV-Share, que revela solo pistas parciales sobre ella (tú eliges cuánto) a los searchers. Los searchers pujan por hacer backrun de tu transacción —recuerda, un backrun no te perjudica— y una gran fracción de la ganancia resultante se te reembolsa, mientras el resto se reparte entre el searcher y el proponente para lograr que el bundle se incluya.

El replanteamiento económico es elegante. Un swap grande crea una oportunidad de backrun; la pregunta es quién la captura. En el mundo del bosque oscuro, los searchers y builders se quedan con todo. Bajo MEV-Share, el valor que tu propia transacción creó se te devuelve en gran parte. El RPC orientado al consumidor de Flashbots, Flashbots Protect, enruta las transacciones minoristas a través de este sistema, y en 2025 añadió reembolsos de tarifas de gas encima, aumentando de forma significativa lo que los usuarios recuperan. Este es el principio de "redistribuir lo benigno, suprimir lo tóxico" hecho concreto.

5. Defensas prácticas para un trader

No necesitas operar un searcher para dejar de ser presa. En orden aproximado de impacto:

Configura el slippage de forma deliberada, por pool

La sección 2 estableció que tu tolerancia de slippage es el presupuesto del atacante. De ahí se derivan dos reglas. Primero, dimensiona el slippage según la liquidez real del pool y el impacto de precio de tu operación, no según un 1% habitual. En un pool profundo, una tolerancia de 0,1-0,3% puede ser suficiente; en uno poco líquido, o aceptas que no puedes operar ese tamaño con seguridad o lo divides en tramos más pequeños. Segundo, nunca uses slippage "auto"/"ilimitado" en un par de baja liquidez —es un cheque en blanco firmado. Si un swap sigue revirtiendo con una tolerancia ajustada, eso es el mercado diciéndote que tu operación es demasiado grande para el pool, no una señal para aflojar el piso.

Enruta a través de un RPC privado

La solución estructural más limpia es mantener tu transacción completamente fuera del mempool público. Apunta tu wallet a un RPC privado que reenvíe las transacciones directamente a los builders en lugar de propagarlas:

• Flashbots Protect —envía tu transacción al sistema MEV-Share, de modo que nunca es públicamente visible para los frontrunners, y devuelve una parte de cualquier valor de backrun más reembolsos de gas.
• MEV Blocker (de CoW Protocol y otros) —un servicio de RPC privado similar que protege contra frontrunning y sandwiching y reembolsa la ganancia de backrun a los usuarios, con un modelo de tarifas de uso gratuito.

Como un sandwich requiere que el atacante vea tu transacción pendiente e inserte un frontrun antes de ella, eliminar tu transacción del mempool público elimina de raíz la oportunidad de frontrun. La oportunidad de backrun permanece, pero ahora se te subasta de vuelta en lugar de robártela. La contrapartida es un poco de confianza en el operador del RPC y, ocasionalmente, una inclusión marginalmente más lenta —normalmente trivial frente a eliminar el riesgo de sandwich. (Un estudio de benchmark de 2025 sobre RPCs de protección privada encontró que su liquidación en el mundo real no es siempre estrictamente mejor que el envío público, así que el efecto es fuerte pero no universal; para la mayoría de los swaps de DEX de tamaño minorista, el enrutamiento privado sigue siendo la opción por defecto correcta.)

Prefiere plataformas de subasta por lotes y basadas en intenciones

Algunos diseños de DEX eliminan la ventaja de ordenamiento por construcción. CoW Protocol liquida operaciones en subastas por lotes con un precio de liquidación uniforme: cada operación dentro de un lote se liquida al mismo precio, por lo que no hay una posición "primera" ni "última" que explotar, y los solvers compiten por darte la mejor ejecución en lugar de reordenar en torno a ti. Los sistemas basados en intenciones, donde firmas lo que quieres y dejas que los solvers encuentren la ejecución, en lugar de firmar una ruta específica, de manera similar le niegan al sandwich su punto de apoyo. Si operas volumen, estas plataformas valen más que cualquier ajuste de slippage.

Entiende por qué las L2 son diferentes

En la mayoría de los rollups de Ethereum actuales (Arbitrum, Optimism, Base), los bloques son producidos por un único secuenciador operado por el equipo del rollup. No hay un mempool público de transacciones pendientes para que los searchers lo observen, y hay una sola parte confiable decidiendo el orden. En la práctica, la mayoría de los secuenciadores ordenan las transacciones por orden de llegada y no ejecutan ataques sandwich contra sus usuarios, por lo que el sandwiching está en gran medida ausente en estas cadenas a nivel de protocolo.

Pero lee la contrapartida con precisión: la razón por la que estás a salvo de la extracción de MEV descentralizada es que estás confiando en un ordenador centralizado para que no la extraiga. El secuenciador podría hacerte frontrunning; simplemente elige (y está reputacionalmente obligado) no hacerlo. Este es un equilibrio temporal. A medida que los rollups descentralizan sus secuenciadores —secuenciadores compartidos, based sequencing, subastas estilo PBS en L2— la misma visibilidad del mempool y la dinámica de ordenamiento en venta pueden reaparecer, y la cuestión del MEV en L2 se convierte en un problema de diseño abierto en lugar de uno resuelto. No asumas que "estoy en una L2" significa "el MEV no puede tocarme" indefinidamente; significa "una parte confiable ha prometido no hacerlo, por ahora".

Qué llevarte para el resto de la serie

Reduce el tema a sus hechos fundamentales:

1. Un swap en el mempool público es intención pública más un slot de ordenamiento comprable. Esa combinación, no ningún bug puntual, es todo el problema.
2. En un AMM de producto constante, tu tolerancia de slippage es una cantidad que un atacante puede extraer, y la ganancia de un sandwich está acotada precisamente por el margen que dejaste. Configurar el slippage es una decisión de seguridad, no un ajuste de conveniencia.
3. El MEV no es monolítico: los frontruns y los sandwiches son tóxicos; los backruns y el arbitraje atómico son benignos e incluso útiles, porque mantienen la consistencia de los precios on-chain. Una buena mitigación suprime lo primero y redistribuye lo segundo.
4. La respuesta de la industria pasó de las PGAs (guerras de gas públicas, Flash Boys 2.0, 2019) a Flashbots / bundles / PBS (subastas privadas selladas) a MEV-Share (devolver el valor de backrun al usuario) y, a continuación, la PBS consagrada en el protocolo.
5. Como trader, tus defensas son un slippage ajustado por pool, RPCs privados (Flashbots Protect, MEV Blocker) y plataformas de subasta por lotes, además de la conciencia de que la seguridad en L2 es actualmente un supuesto de confianza en el secuenciador, no una ley física.

La pieza sobre arbitraje atómico y flash loans toma el lado del searcher en esta tabla —cómo se construye la extracción benigna, con capital prestado y reversiones atómicas como red de seguridad. La pieza sobre liquidez concentrada de Uniswap v3 retoma la matemática de producto constante de arriba y muestra cómo la liquidez concentrada reconfigura la curva de impacto de precio —y por tanto el presupuesto del sandwich— que derivamos aquí. El mempool es un bosque oscuro. Ahora sabes qué está cazando en él.

Referencias

• Daian, Goldfeder, Kell, Li, Zhao, Bentov, Breidenbach, Juels (2019), Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges. arXiv:1904.05234.
• Robinson & Konstantopoulos (2020), Ethereum is a Dark Forest.
• Documentación de Flashbots: MEV-Boost, MEV-Share, Flashbots Protect, reembolsos de MEV (docs.flashbots.net).
• Ethereum PBS / EIP-7732 (separación consagrada entre proponente y builder), materiales de la actualización Glamsterdam.
• MEV Blocker (mevblocker.io); diseño de subasta por lotes de CoW Protocol.
• Private MEV Protection RPCs: A Benchmark Study (arXiv:2505.19708, 2025).