Resumen
Un MEV blocker es un endpoint RPC que cambia el destino de tus transacciones firmadas antes de que lleguen a un bloque. En lugar de transmitir una transacción sin procesar al mempool público, la envías a un relay privado o a una subasta de flujo de órdenes que la oculta de los bots de frontrunning y sándwich, y en muchos diseños devuelve parte del valor extraído al remitente.
Eso convierte a un MEV blocker en una decisión de enrutamiento, no en una característica de la cadena. Mantienes el mismo chain ID y el mismo flujo de firma; solo cambias la URL RPC que tu billetera o backend usa para eth_sendRawTransaction. Las lecturas, los logs y las consultas de estado todavía necesitan un nodo completo normal detrás, por lo que los equipos suelen combinar un endpoint de protección con un proveedor RPC estándar como la API RPC de OnFinality para todo lo que no sea el envío de transacciones.
Este artículo explica cómo funcionan los MEV blockers, contra qué protegen y contra qué no, y cómo decidir si enrutar las transacciones de los usuarios a través de uno, además de cómo mantener saludable tu ruta de lectura y la conmutación por error una vez que lo hagas.
Puntos clave
- Un MEV blocker es un endpoint RPC que enruta transacciones firmadas a través de un mempool privado o una subasta de flujo de órdenes en lugar del mempool público.
- Protege principalmente contra ataques de frontrunning y sándwich en el envío de transacciones; no cambia el consenso, el precio del gas ni tu ruta de lectura.
- Los endpoints de protección suelen ser específicos de cada cadena y a menudo se centran en Ethereum, así que verifica el chain ID, los métodos admitidos y el comportamiento de reversión antes de cambiar.
- La mayoría de los diseños solo interceptan
eth_sendRawTransaction;eth_call,eth_getLogsy los métodos de trace todavía necesitan un nodo completo convencional. - Mantén un RPC estándar como respaldo para que el envío de transacciones no se convierta en un punto único de fallo.
- Prueba en una testnet o con un valor pequeño primero, y monitorea la tasa de inclusión, la tasa de reversión y el comportamiento de reembolso después del despliegue.
La respuesta corta: un MEV blocker es un enrutador de transacciones
Un MEV blocker es un endpoint RPC al que apuntas tu billetera o backend cuando quieres que tus transacciones eviten el mempool público. Firmas localmente como de costumbre y luego envías la transacción sin procesar al blocker. El blocker la reenvía a un relay privado, una red de constructores o una subasta de flujo de órdenes, donde los searchers pueden pujar por el derecho a incluirla. Como la transacción no es visible en el mempool público antes de la inclusión, los bots no pueden hacerle frontrunning ni sándwich fácilmente.
El matiz importante: el blocker no es una cadena, un rollup ni un cambio de consenso. Tu transacción todavía se liquida en la misma cadena con el mismo chain ID. Lo que cambia es la ruta entre tu firma y el constructor de bloques.
La mayoría de los MEV blockers también actúan como un mecanismo de reembolso parcial. Si tu transacción crea oportunidades de backrunning, los searchers pagan por ellas y parte de ese valor puede volver a ti. El modelo exacto de reembolso, el comportamiento de reversión y el nivel de privacidad difieren según el endpoint, así que lee la referencia del endpoint del proveedor en lugar de asumir un comportamiento.
- Misma cadena, mismo flujo de firma: solo cambia la URL de envío.
- La protección se aplica al envío de transacciones, no a lecturas, logs ni traces.
- El comportamiento de reembolso y reversión varía según la ruta del endpoint, así que prueba antes de confiar en él.
Guía de decisión: ¿deberían tus transacciones pasar por un blocker?
Usa esta tabla para decidir por carga de trabajo en lugar de por proyecto. Muchos equipos enrutan solo la ruta de envío de transacciones a través de un endpoint de protección y mantienen todo lo demás en un proveedor RPC convencional.
- Enruta de forma selectiva: protección para transacciones de usuarios que conllevan valor, RPC estándar para todo lo demás.
- Mantén un endpoint de respaldo documentado y un tiempo de espera para que el envío nunca se quede colgado indefinidamente.
| Criterio | Qué revisar | Por qué importa |
|---|---|---|
| Carga de trabajo | ¿La transacción crea valor visible en el mempool (swaps, mints, liquidaciones, lanzamientos de NFT)? | Si es así, el riesgo de frontrunning y sándwich es real y vale la pena evaluar un blocker. Las transferencias rutinarias y las transacciones administrativas suelen ganar poco. |
| Orientado al usuario vs backend | ¿La transacción la firman los usuarios finales en una billetera o tu firmante de backend? | La protección a nivel de billetera es un cambio de configuración al que los usuarios pueden optar. El envío desde el backend necesita una ruta de código que controles y monitorees. |
| Soporte de cadena | ¿El blocker admite tu chain ID y los métodos que llamas? | Los endpoints de protección suelen ser específicos de cada cadena; enviar a la cadena incorrecta o usar un método no admitido falla silenciosamente o con errores confusos. |
| Política de reversión | ¿El endpoint descarta las transacciones que revierten o las incluye y cobra gas? | Esto cambia tu contabilidad de gas y tu lógica de reintentos, especialmente para bots y estrategias automatizadas. |
| Ruta de respaldo | ¿Qué sucede si el blocker está lento, caído o rechaza tu transacción? | El envío no debería convertirse en un punto único de fallo para tu producto. |
Contra qué protege realmente un blocker y contra qué no
La protección principal es contra ataques de frontrunning y sándwich en transacciones que de otro modo permanecerían en el mempool público. Al ocultar la transacción hasta la inclusión, el blocker elimina la ventana que los bots usan para insertar transacciones alrededor de la tuya.
No elimina el MEV del sistema. El valor todavía puede extraerse mediante backrunning, y la subasta del blocker es uno de los lugares donde ese valor se cotiza. Tampoco te protege de un precio desfavorable en tu propia transacción, de exploits a nivel de contrato ni de reorganizaciones. Y no reemplaza una ruta de lectura saludable: si tu aplicación no puede leer el estado o los logs de manera confiable, la protección en el envío no salvará la experiencia del usuario.
- Trata la protección como una capa: reduce una superficie de ataque específica, no reemplaza la higiene de las transacciones.
| Criterio | Qué revisar | Por qué importa |
|---|---|---|
| Amenaza | Sí: transacción oculta hasta la inclusión | La razón principal por la que los equipos adoptan un blocker. |
| Captura de valor por backrunning | Parcialmente: mediante subasta y posibles reembolsos | Los modelos de reembolso difieren; consulta la referencia del endpoint. |
| Gas de transacciones fallidas | Depende de la política de reversión del endpoint | Afecta el costo y la lógica de reintentos para emisores automatizados. |
| Reorganizaciones y finalidad | No | Sigue siendo tu responsabilidad manejar las confirmaciones. |
| Confiabilidad de la ruta de lectura | No | Combínalo con un RPC estándar para eth_call, eth_getLogs y traces. |
Integrar un endpoint de protección en una billetera o backend
Para los usuarios finales, el cambio es una entrada de red en la billetera: mismo chain ID, mismo símbolo de moneda, mismo explorador, diferente URL RPC. Para los backends, el cambio es más acotado: normalmente mantienes tu proveedor normal para lecturas y envías solo transacciones sin procesar al endpoint de protección.
El siguiente ejemplo muestra el patrón de división en JavaScript. Utiliza un proveedor JSON-RPC estándar para lecturas y una URL de protección separada para el envío. Reemplaza el marcador de posición con el endpoint que el blocker elegido publique para tu cadena.
- Mantén dos clientes: un cliente de lectura y un cliente de envío.
- Establece un tiempo de espera explícito en el envío y recurre a tu RPC estándar si el endpoint de protección no responde.
- Registra el endpoint utilizado por transacción para que puedas atribuir la inclusión y el comportamiento de reversión más adelante.
| Criterio | Qué revisar | Por qué importa |
|---|---|---|
| Elemento de configuración | Debe coincidir exactamente con la cadena de destino | Una discrepancia envía fondos o transacciones al contexto de red incorrecto. |
| URL RPC de lectura | El endpoint de tu proveedor estándar | Se usa para eth_call, eth_getLogs, eth_getTransactionReceipt y traces. |
| URL RPC de envío | El endpoint documentado del blocker para tu cadena | Solo el envío de transacciones sin procesar debe ir aquí. |
| URL de respaldo | El endpoint de tu proveedor estándar | Evita que las interrupciones en el envío bloqueen tu producto. |
| Tiempo de espera | Unos pocos segundos, ajustado a tu UX | Evita bloqueos indefinidos cuando la ruta de protección está degradada. |
Dónde encaja OnFinality junto a un endpoint de protección
Un MEV blocker responde una pregunta: ¿a dónde van las transacciones firmadas? Todo lo demás —lecturas de saldo, logs de eventos, llamadas a contratos, recibos de transacciones, datos de trace y suscripciones WebSocket— todavía necesita un nodo completo. Esa es la capa que OnFinality proporciona a través de sus ofertas de API RPC y nodo dedicado en redes compatibles.
Una forma común en producción es: un endpoint de protección para eth_sendRawTransaction, un RPC gestionado para lecturas y recibos, y un nodo dedicado cuando necesitas rendimiento predecible o políticas personalizadas de mempool. Si todavía estás seleccionando el lado de lectura, la guía de selección de proveedor RPC cubre criterios de carga de trabajo, archivo, trace y conmutación por error.
Dos verificaciones prácticas antes de comprometerte: confirma que la cadena que estás protegiendo es compatible en el lado de lectura, y confirma que tu ruta de respaldo es un proveedor en el que ya confías para el envío. Revisa los precios de RPC para dimensionar el lado de lectura según tu volumen de solicitudes esperado.
- Endpoint de protección: solo envío.
- RPC gestionado: lecturas, logs, recibos, suscripciones.
- Nodo dedicado: control de rendimiento, políticas personalizadas, peering privado.
Lista de verificación para despliegue y monitoreo
Cambiar las rutas de envío es un cambio en producción. Despliégalo por etapas y observa las señales que indican si la protección funciona según lo previsto.
- Comienza con una pequeña porción del tráfico o una testnet cuando esté disponible.
- Configura alertas sobre la frecuencia de respaldo y las caídas en la tasa de inclusión, no solo sobre errores.
- Vuelve a leer la referencia del endpoint del proveedor después de cualquier cambio; las rutas y políticas pueden diferir entre modos de protección.
| Criterio | Qué revisar | Por qué importa |
|---|---|---|
| Señal | Las transacciones se incluyen en un número razonable de bloques | Una caída repentina sugiere que la ruta de protección está degradada. |
| Tasa de reversión | Estable o más baja que antes | Los cambios en la política de reversión pueden modificar los costos de gas. |
| Latencia de envío | Dentro de tu presupuesto de tiempo de espera | Un envío lento perjudica la UX más que una lectura lenta. |
| Frecuencia de respaldo | Baja y explicada | Un respaldo frecuente significa que la ruta principal no es confiable. |
| Comportamiento de reembolso o rebate | Coincide con el modelo documentado del proveedor | Reembolsos inesperados o su ausencia total indican un endpoint mal configurado. |
Conclusiones clave
Un MEV blocker es una elección de enrutamiento para el envío de transacciones, no una actualización de la cadena. Oculta las transacciones firmadas del mempool público para reducir el riesgo de frontrunning y sándwich, y algunos diseños devuelven parte del valor extraído al remitente. No soluciona tu ruta de lectura, tu precio de gas ni el manejo de confirmaciones.
El patrón práctico es un stack dividido: un endpoint de protección para el envío de transacciones sin procesar, un RPC estándar confiable para lecturas, logs, recibos y traces, y una ruta de respaldo para que el envío nunca se convierta en un punto único de fallo. Prueba la política de reversión y el modelo de reembolso antes de desplegarlo, y luego monitorea la tasa de inclusión, la tasa de reversión y la frecuencia de respaldo.
Si necesitas el lado de lectura de ese stack, comienza con la API RPC de OnFinality, consulta las redes compatibles y revisa los precios de RPC para dimensionarlo según tu carga de trabajo.
- La protección es una capa; la confiabilidad de la ruta de lectura es otra.
- Verifica el chain ID, los métodos admitidos y la política de reversión por endpoint.
- Mantén siempre un respaldo documentado para el envío.
Preguntas frecuentes
¿Un MEV blocker es lo mismo que un RPC privado?
Se superponen. Un MEV blocker es una ruta de envío privada con enrutamiento específico para MEV, que a menudo incluye una subasta de flujo de órdenes y reembolsos. Un RPC privado puede simplemente ocultar transacciones sin una subasta. Consulta la documentación del proveedor para saber qué sucede después del envío.
¿Usar un MEV blocker cambia mi chain ID o mi flujo de firma?
No. Firmas la misma transacción para la misma cadena. Solo cambia la URL RPC utilizada para el envío de transacciones sin procesar. Las lecturas y los recibos todavía provienen de un nodo estándar.
¿Puede un MEV blocker detener toda la extracción de MEV?
No. Reduce principalmente el riesgo de frontrunning y sándwich en el envío. El backrunning y otras formas de extracción de valor todavía pueden ocurrir, y la subasta del blocker es uno de los lugares donde ese valor se cotiza.
¿Todavía necesito un proveedor RPC normal si uso un blocker?
Sí, en la mayoría de las configuraciones. Métodos como eth_call, eth_getLogs, eth_getTransactionReceipt y las llamadas de trace necesitan un nodo completo. Un RPC gestionado como la API RPC de OnFinality cubre esa capa.
¿Qué sucede si el endpoint de protección está caído?
Si no tienes un respaldo, el envío se detiene. Configura un tiempo de espera y un respaldo a un RPC estándar en el que confíes, y alerta sobre la frecuencia de respaldo para detectar degradaciones a tiempo.
¿Debería toda transacción pasar por un blocker?
Normalmente no. Enruta transacciones de usuarios que conllevan valor donde el riesgo de frontrunning es real. Las transferencias rutinarias y las operaciones administrativas suelen ganar poco y añaden una dependencia adicional.
Ethereum
Solana
Polygon
Base
Arbitrum
BNB Chain
Polkadot
Optimism
