¿Qué es el MEV? Valor máximo extraíble explicado para desarrolladores

Definición y alcance del valor máximo extraíble

El valor máximo extraíble (MEV) es la ganancia máxima obtenible de la producción de bloques más allá de la recompensa estándar por bloque y las comisiones de transacción, mediante la inclusión, exclusión o reordenación de transacciones dentro de un bloque. El término comenzó como "valor extraíble por mineros" bajo prueba de trabajo, cuando los mineros controlaban el contenido de los bloques. Tras el paso de Ethereum a prueba de participación, los validadores asumen ese rol, por lo que la comunidad adoptó "máximo" para describir la misma superficie económica sin atarla a la minería.

El MEV no es un único ataque. Es una categoría de valor que surge siempre que el orden importa: el arbitraje en exchanges descentralizados, las liquidaciones, el sándwich, el sniping de acuñaciones de NFT y el backrunning de actualizaciones de oráculos entran todos en ella. Parte de ello es creación de mercado benigna que ajusta los precios entre venues; parte transfiere directamente valor fuera de los usuarios ordinarios. La distinción importa cuando decides qué mitigar.

Este artículo cubre el mecanismo, los roles de los actores, diagnósticos ejecutables que puedes correr contra un endpoint RPC y los compromisos de las mitigaciones comunes. No publica cifras de referencia de ningún proveedor; cuando se necesita medición, se da el procedimiento para que puedas producir tus propios resultados.

• El MEV es valor proveniente del orden, la inclusión y la exclusión, no de mantener o hacer staking por sí solo.
• Existe en cualquier cadena donde un productor de bloques controla el orden de las transacciones y las transacciones pendientes son observables.
• La exposición depende de tu tipo de transacción, la configuración de slippage y cómo envías las transacciones.

Supuestos y requisitos previos

Debes estar cómodo con transacciones, bloques, gas y la diferencia entre un mempool público y un relay privado de transacciones. La familiaridad con un creador de mercado automatizado (AMM) ayuda, porque la mayoría de los ejemplos de MEV orientados al usuario involucran swaps cuyo impacto en el precio depende del orden.

Necesitas un endpoint RPC para diagnósticos de solo lectura. Cualquier endpoint confiable sirve; si estás eligiendo uno, la guía de endpoints RPC cubre qué evaluar, y precios de RPC explica cómo el volumen de solicitudes se traduce en costo. Para cargas de trabajo en producción que necesitan latencia consistente, un nodo dedicado elimina los efectos de vecino ruidoso que pueden distorsionar mediciones sensibles al tiempo.

El modelo mental: el orden como recurso escaso

Piensa en un bloque como una secuencia con capacidad fija. Cada transacción en él tiene un efecto sobre el estado compartido, y el efecto de una transacción depende de lo que se ejecutó antes. Un swap mueve el precio de un pool a lo largo de su curva; una liquidación cambia la salud de un prestatario; una actualización de oráculo cambia los precios que ven los contratos. Como el orden cambia los resultados, el derecho a elegir el orden es valioso.

En un modelo simple, un buscador identifica una secuencia rentable, la envía como un bundle y ofrece parte de la ganancia al constructor de bloques por la inclusión. El constructor arma el bloque más valioso y pasa una puja al validador, quien lo propone. La parte garantizada del validador proviene de la puja; el buscador se queda con el resto. La competencia eleva las pujas, por lo que en oportunidades muy disputadas la mayor parte del valor puede fluir a constructores y validadores en lugar de al buscador.

Por eso a veces se llama al MEV un impuesto invisible para los usuarios: el valor es real, pero se paga mediante una peor ejecución en lugar de una partida explícita. El tamaño de ese impuesto depende de cuánto revela tu transacción sobre sí misma antes de aterrizar.

Roles de los actores: buscadores, constructores, validadores y relays

Los buscadores ejecutan algoritmos sobre datos pendientes e históricos para encontrar órdenes rentables y luego envían bundles. Los constructores agregan bundles y transacciones ordinarias en bloques candidatos, optimizando el valor total. Los validadores (o proponentes) seleccionan un bloque y atestiguan sobre él. Los relays actúan como intermediarios que pasan bundles entre buscadores y constructores sin exponer el contenido prematuramente.

La separación no es universal. En algunas redes los roles se colapsan en un único proponente, y en otras el mercado de constructores está menos desarrollado. Cuando razones sobre MEV en una nueva cadena, primero pregunta quién controla el orden y si existe una vía de envío privada. El directorio de redes lista las cadenas soportadas y sus entornos de ejecución, lo que es un punto de partida útil antes de asumir infraestructura al estilo Ethereum.

• Buscador: encuentra y envía bundles de transacciones rentables.
• Constructor: arma bloques a partir de bundles y transacciones.
• Validador/proponente: selecciona y propone el bloque.
• Relay: mueve bundles entre las partes con divulgación limitada.

Patrones comunes de extracción y su impacto en el usuario

El arbitraje en DEX corrige diferencias de precio entre pools y venues. Generalmente es la categoría más grande por volumen y es en su mayoría neutral a dañina para los usuarios, ya que empuja los precios hacia una tasa de mercado única. Las liquidaciones mantienen solventes a los protocolos de préstamo y son un incentivo legítimo para los keepers, aunque pueden ser agresivas durante la volatilidad.

El sándwich es el patrón que los usuarios sienten más directamente. Un buscador observa un swap pendiente que moverá el precio de un pool, compra antes, deja que la operación de la víctima empuje el precio aún más y luego vende después. La víctima recibe una peor tasa. El ataque es rentable solo cuando la tolerancia de slippage de la víctima deja margen, por lo que la configuración de slippage es la palanca principal que controlan los usuarios.

El frontrunning y el backrunning son las primitivas generales: colocar una transacción antes o después de un objetivo. El frontrunning generalizado copia una transacción rentable y reemplaza al remitente. El sniping de NFT y el frontrunning de acuñaciones aplican la misma lógica a acuñaciones escasas. Cada patrón tiene un perfil de mitigación diferente, por lo que el consejo general como "usa un RPC privado" es incompleto.

Procedimiento de diagnóstico: inspeccionar transacciones pendientes y recientes

Antes de cambiar nada, establece cómo se ven tus transacciones desde fuera. El siguiente script de Python consulta un endpoint JSON-RPC para el último bloque e imprime hashes de transacción, precios de gas y tamaños de entrada. Ejecútalo contra tu propio RPC_URL; no codifiques un endpoint público. Trata la salida como una línea base que puedes comparar después de cambiar el comportamiento de envío.

El script usa solo módulos de la biblioteca estándar y el método eth_getBlockByNumber, que todo endpoint compatible con EVM soporta. Si tu proveedor aplica límites de tasa, reduce el rango de bloques o añade retroceso.

import json, urllib.request

RPC_URL = "RPC_URL"

def rpc(method, params):
    payload = json.dumps({"jsonrpc": "2.0", "id": 1, "method": method, "params": params}).encode()
    req = urllib.request.Request(RPC_URL, data=payload, headers={"Content-Type": "application/json"})
    with urllib.request.urlopen(req, timeout=20) as resp:
        return json.loads(resp.read())["result"]

block = rpc("eth_getBlockByNumber", ["latest", True])
print("block", int(block["number"], 16), "txs", len(block["transactions"]))
for tx in block["transactions"][:20]:
    print(tx["hash"], int(tx["gasPrice"], 16) if tx.get("gasPrice") else "n/a", len(tx.get("input", "")))

Medir tu propia exposición con un método reproducible

No puedes reducir lo que no puedes ver. Una prueba práctica de exposición es enviar un swap pequeño por tu ruta normal y comparar el precio ejecutado con un precio de referencia tomado inmediatamente antes y después. Registra los siguientes campos para cada prueba en una tabla: marca de tiempo, pool, cantidad de salida cotizada, cantidad de salida ejecutada, tolerancia de slippage, ruta de envío (mempool público o relay privado) e impacto en el precio observado.

Ejecuta al menos diez pruebas por configuración y reporta la mediana y la dispersión en lugar de un solo resultado. Un solo swap puede tener suerte o mala suerte; la distribución es lo que te dice si una mitigación ayuda. No compares pruebas realizadas a distintas horas del día o con distinta volatilidad de mercado sin anotarlo, porque la actividad de MEV no es estacionaria.

La tabla de resultados a continuación es una plantilla, no datos medidos. Rellénala con tus propias observaciones.

• | Prueba | Ruta | Salida cotizada | Salida ejecutada | Slippage bps | Impacto en el precio |
• | 1 | pública | (tu valor) | (tu valor) | (tu valor) | (tu valor) |
• | 2 | relay privado | (tu valor) | (tu valor) | (tu valor) | (tu valor) |
• Reporta la mediana de ejecutado menos cotizado entre pruebas, no un único mejor caso.

Implementación: enviar un swap con restricciones más estrictas

La mitigación más directa del lado del usuario es reducir la ganancia disponible para un sándwich. Baja la tolerancia de slippage, divide órdenes grandes y establece una fecha límite. El fragmento de JavaScript a continuación muestra la forma de una llamada de swap usando marcadores de posición al estilo ethers. Es ilustrativo; sustituye el ABI de tu router y las direcciones de los tokens. Nunca confirmes PRIVATE_KEY en el control de versiones.

Los parámetros clave son amountOutMin y deadline. amountOutMin debe derivarse de una cotización fresca, no de una obsoleta, y debe ser lo suficientemente estricto como para que un sándwich deje de ser rentable después de las comisiones. Dividir una orden en piezas más pequeñas reduce el impacto en el precio que genera cada pieza, lo que a su vez reduce el valor que un buscador puede extraer de cualquier transacción individual.

import { ethers } from "ethers";

const provider = new ethers.JsonRpcProvider("RPC_URL");
const wallet = new ethers.Wallet("PRIVATE_KEY", provider);
const router = new ethers.Contract("ROUTER_ADDRESS", ROUTER_ABI, wallet);

const amountIn = ethers.parseUnits("1.0", 18);
const quotedOut = await router.getAmountsOut(amountIn, [TOKEN_IN, TOKEN_OUT]);
const minOut = quotedOut[1] * 995n / 1000n; // 0.5% tolerance, adjust deliberately
const deadline = Math.floor(Date.now() / 1000) + 60;

const tx = await router.swapExactTokensForTokens(
  amountIn, minOut, [TOKEN_IN, TOKEN_OUT], await wallet.getAddress(), deadline
);
console.log("submitted", tx.hash);
const receipt = await tx.wait();
console.log("status", receipt.status);

Verificación: confirmar que la mitigación funcionó

Después de cambiar el slippage o la ruta de envío, vuelve a ejecutar el procedimiento de exposición y compara las distribuciones. Una mitigación exitosa muestra una brecha más estrecha entre las cantidades cotizadas y ejecutadas y menos transacciones con un gran impacto negativo en el precio. No necesariamente muestra MEV cero; el arbitraje y otra actividad benigna seguirán apareciendo en los datos de bloques.

Usa un explorador de bloques o tu propio indexador para inspeccionar si tu transacción fue precedida por un swap en el mismo pool de un remitente diferente en el mismo bloque. Si lo fue, y el precio se movió en tu contra, eso es evidencia de un sándwich. Registra el número de bloque y los dos hashes de transacción para que la observación sea reproducible.

Solución de problemas comunes relacionados con MEV

Las transacciones que se revierten con errores de slippage suelen significar que el precio se movió entre la cotización y la ejecución, ya sea por volatilidad normal o por una operación intermedia. Amplía ligeramente la tolerancia o actualiza la cotización inmediatamente antes de firmar. Las transacciones que nunca aterrizan pueden estar atascadas detrás de una tarifa de prioridad baja; verifica el estado del mempool a través de tu proveedor y considera una transacción de reemplazo con el mismo nonce.

Si tu envío a un relay privado no se incluye, confirma que el relay soporta tu cadena y tipo de transacción. No todos los relays sirven a todas las redes, y algunos requieren un formato de bundle específico. Si ves sándwiches repetidos a pesar de un slippage estricto, verifica si tu billetera o frontend está sobrescribiendo tu configuración de slippage, lo cual es una fuente común de confusión.

• Swap revertido: actualiza la cotización, verifica la fecha límite, comprueba las aprobaciones de tokens.
• Transacción atascada: inspecciona el nonce y la tarifa de prioridad, considera un reemplazo.
• Rechazo del relay: verifica el soporte de la cadena y el formato del bundle.
• Slippage inesperado: audita los valores predeterminados de la billetera y el frontend.

Limitaciones, compensaciones y próximos pasos

El envío privado reduce la exposición al sándwich del mempool público pero no elimina el MEV; los constructores aún pueden reordenar dentro de sus propios bloques, y los supuestos de confianza se trasladan al relay. Un slippage más estricto protege contra sándwiches pero aumenta las transacciones fallidas, que cuestan gas. Dividir órdenes reduce el impacto por operación pero aumenta las comisiones totales y la complejidad operativa.

La medición misma tiene límites. Los datos públicos muestran lo que aterrizó, no lo que se intentó, y la competencia a nivel de bundle solo es parcialmente visible. Trata cualquier número único como una instantánea. Para sistemas en producción, monitorea continuamente y revisa los supuestos cuando cambie el mercado de constructores de la cadena.

Si estás construyendo infraestructura en torno a estos flujos de trabajo, comienza con un endpoint confiable: revisa el servicio de API para acceso gestionado, compara precios de RPC para el modelado de costos y consulta las redes soportadas antes de asumir que existe una API de relay o constructor. Para buscadores o keepers sensibles a la latencia, un nodo dedicado es el siguiente paso habitual después de establecer una línea base.