Presiona ESC para cerrar

Bots de Liquidación DeFi: Cómo cazar ballenas al límite

El ecosistema de las finanzas descentralizadas (DeFi) se suele comparar con una jungla digital, y la verdad es que la descripción es clavadita. Mientras los traders minoristas se queman las pestañas mirando gráficos e intentando adivinar hacia dónde tirará la tendencia, los tiburones del sector —los MEV searchers (Maximal Extractable Value) y los operadores de bots de liquidación— escanean las entrañas de la propia blockchain buscando errores tácticos ajenos para hincarles el diente.

El momento crítico llega cuando un pez gordo (una "ballena") pide un préstamo descomunal colateralizando sus criptomonedas en plataformas de lending (como Aave, Compound, Spark o Morpho) y el mercado se le gira en contra. Si su posición se queda a un suspiro de que se la cierren a la fuerza, se genera una ineficiencia de mercado brutal y ultrasuculenta.

En este artículo vamos a destripar cómo funciona la mecánica para cazar estas posiciones, cómo rastrear ballenas que están a menos de un 1% de ser liquidadas y cómo hincarle el diente a esto tanto a nivel técnico como estratégico para llenarse los bolsillos.

Anatomía del lending en DeFi: ¿Por qué se producen las liquidaciones?

Para entender dónde están las grietas, hay que dominar al dedillo las matemáticas que mueven los protocolos de préstamo (Lending Protocols). A diferencia de los exchanges centralizados (CEX) —donde el motor de liquidación lo maneja la propia plataforma a puerta cerrada—, en DeFi este tinglado está 100% externalizado en actores independientes: los liquidadores.

El protocolo no puede cerrar una posición por arte de magia; no tiene un activador automático interno. Lo que hace es lanzar un cebo económico jugoso (un descuento al comprar el colateral, que suele rondar el 5-10%) للتنبيه para que cualquiera en la red venga, pague la deuda del moroso y se quede con sus garantías a precio de saldo.

La métrica sagrada: Health Factor (HF)

La salud y seguridad de cualquier posición de préstamo se mide con el llamado Factor de Salud (Health Factor). La fórmula en la gran mayoría de los protocolos compatibles con EVM (como Aave v3) es la siguiente:

1
 

Donde:

  • Collateral_i - El valor total del colateral i en la moneda base del protocolo (por ejemplo, en ETH o USD).
  • LiquidationThreshold_i (Umbral de liquidación) - La relación máxima entre deuda y colateral que fija el protocolo para ese activo en concreto (por ejemplo, un 85%).
  • Debt_j - El valor total del préstamo j solicitado, incluyendo los intereses acumulados que van corriendo.

El punto de no retorno: Mientras el HF esté por encima de 1, la posición está a salvo. En cuanto baja de 1, la posición se convierte en barra libre para que cualquiera la liquide públicamente.

¿Qué significa estar "a un 1% de la liquidación"?

Es ese estado de máxima alerta en el que el HF de la posición está encajonado en la zona de peligro, entre 1.0001 y 1.01. Cualquier movimiento milimétrico a la baja en el precio del colateral (o al alza en el del activo prestado) transforma instantáneamente esa posición en carne de cañón para los bots.

Estrategia "Ganar con el Dump": Dos escenarios de ataque

Mucha gente se piensa que el beneficio de un liquidador se reduce al extra que rasca del propio protocolo. Pero cuando hablamos de posiciones de decenas de millones de dólares (ballenas de las de verdad), se abren jugadas mucho más agresivas y lucrativas entre bastidores.

Escenario A: Liquidación clásica mediante Flash Loans

Encuentras una posición con un HF por debajo de 1. El problema es que no tienes 10 millones de dólares limpios en la wallet para saldar la deuda de ese usuario. Ahí es donde entran los Flash Loans (préstamos instantáneos):

  1. Pides prestados 10 millones de DAI en Uniswap o Aave dentro de la misma transacción y sin poner ni un céntimo de garantía.
  2. Saldas la deuda de la ballena directamente en el contrato del protocolo.
  3. A cambio, te dan su colateral (por ejemplo, ETH) con ese 5% de descuento (es decir, te llevas el equivalente a 10.5 millones de dólares en ETH).
  4. En el mismo segundo, vendes ese ETH en un DEX para recuperar los DAI, devuelves los 10 millones del Flash Loan + la pequeña comisión del préstamo.
  5. El beneficio neto (~490,000 dólares, restando las comisiones de gas) se va directo a tu bolsillo. Limpio y rápido.

Escenario B: Short direccionado y empujón al abismo (Whale Hunting)

Esta es una jugada de nivel avanzado y mucho más agresiva, idónea para quienes leen la liquidez del mercado como un libro abierto:

  1. Detectas a una ballena con un HF en 1.005 (a un mísero 0.5% de caer al precipicio). Su colateral son 50,000 WBTC y su deuda está en USDT.
  2. Echas números para calcular a qué precio exacto de WBTC su HF tocará el 1. Pongamos que solo necesita caer unos míseros 150 dólares.
  3. Abres una posición en corto (short) masiva de WBTC en el mercado de futuros o en un DEX de derivados con un apalancamiento potente.
  4. Si el libro de órdenes (order book) en el mercado spot está más bien flojo de liquidez, tú u otros actores soltáis una orden gorda de venta de WBTC en spot, provocando un micro-crash de un par de segundos.
  5. El precio toca el resorte de liquidación. Los bots liquidadores (o tu propio script) empiezan a devorar a la ballena en cascata. Para cubrir la deuda, se vuelcan a la fuerza cantidades ingentes de WBTC al mercado, lo que acelera todavía más el desplome (efecto bola de nieve).
  6. Tu posición en corto se cierra clavando el Take-Profit justo en el fondo de ese movimiento artificial o acelerado. Te ha salido la jugada redonda.

El arsenal para rastrear "ballenas heridas"

Intentar monitorizar la blockchain a mano con Etherscan es una utopía y una pérdida de tiempo. Los profesionales se montan un flujo de trabajo combinando tres niveles de herramientas: dashboards ya cocinados, APIs de infraestructura y parsers propios conectados a sus nodos.

1. Plataformas analíticas listas para usar (Para arrancar rápido)

  • DeFi Saver (sección Loan Shifter / Simulation): Es ideal para ver de forma gráfica y rápida las posiciones más bestias abiertas en los principales protocolos.
  • Debank / Arkham Intelligence: Las mejores opciones para crearte listas de seguimiento (Watchlists) de wallets específicas. Si localizas a un gran prestatario cruzando datos de los mayores holders de un token, le metes una alerta para vigilar cada paso que dé.
  • Dune Analytics: Hay dashboards públicos brutales que trackean el Health Factor de los grandes jugadores en tiempo real. (Busca usando etiquetas como: Aave v3 liquidation thresholds o Compound positions monitoring).

2. APIs especializadas (Para automatizar el tinglado)

La manera más robusta de recibir datos limpios y filtrados sin comerte el marrón ni el coste de mantener un Archive Node propio es atacar directamente las APIs oficiales de los subsistemas.

Aave, por ejemplo, tiene un endpoint abierto de GraphQL (vía The Graph) con el que puedes sacar una radiografía financiera de todos los usuarios del tirón.

ParámetroDescripción¿Por qué monitorizarlo?
collateralBalanceUSDVolumen total del colateral en USDPara cribar y quedarte solo con las ballenas de verdad (de 1 millón de dólares para arriba).
totalBorrowsUSDDeuda total en USDClave para evaluar cuánta liquidez vas a necesitar para cerrar la posición de golpe.
currentLiquidationThresholdUmbral de liquidación actual del activoIndispensable para clavar el precio exacto del punto de no retorno hasta el último centavo.

Guía práctica: Programando un parser de posiciones críticas

Vamos a mancharnos las manos con el código. Para cazar una wallet que esté operando a menos de un 1% de la liquidación, necesitamos estructurar un script que vaya bombardeando a preguntas a los contratos Pool o DataProvider del protocolo que elijamos.

Aquí abajo tienes un ejemplo de script en Python usando la librería web3.py. Se conecta al contrato del Aave Protocol Data Provider en la red de Arbitrum (la favorita para liquidaciones: comisiones ridículas y ejecución inmediata), extrae las métricas de la cuenta y calcula lo cerca que está del abismo.

import os
from web3 import Web3
# Conectamos con un nodo RPC rápido (por ejemplo, Alchemy o QuickNode)
RPC_URL = "https://arb-mainnet.g.alchemy.com/v2/YOUR_API_KEY"
w3 = Web3(Web3.HTTPProvider(RPC_URL))
if not w3.is_connected():
    raise Exception("No se ha podido conectar a la blockchain")
# Dirección del contrato de Aave v3 Pool en Arbitrum
AAVE_POOL_ADDRESS = "0x794a61358D6845594F94dc1DB02A252b5b4814aD"
# ABI mínimo que solo incluye la función getUserAccountData
AAVE_POOL_ABI = [
    {
        "inputs": [{"internalType": "address", "name": "user", "type": "address"}],
        "name": "getUserAccountData",
        "outputs": [
            {"internalType": "uint256", "name": "totalCollateralBase", "type": "uint256"},
            {"internalType": "uint256", "name": "totalDebtBase", "type": "uint256"},
            {"internalType": "uint256", "name": "availableBorrowsBase", "type": "uint256"},
            {"internalType": "uint256", "name": "currentLiquidationThreshold", "type": "uint256"},
            {"internalType": "uint256", "name": "ltv", "type": "uint256"},
            {"internalType": "uint256", "name": "healthFactor", "type": "uint256"}
        ],
        "stateMutability": "view",
        "type": "function"
    }
]
pool_contract = w3.eth.contract(address=AAVE_POOL_ADDRESS, abi=AAVE_POOL_ABI)
def check_whale_position(user_address):
    try:
        # Extraemos los datos de la cuenta directamente del smart contract
        data = pool_contract.functions.getUserAccountData(w3.to_checksum_address(user_address)).call()
        
        # Los datos vienen devueltos con una precisión de 18 decimales (en la moneda base de Aave)
        collateral = data[0] / 1e8  # Depende de la moneda base de v3 (suele ser USD con 8 decimales)
        debt = data[1] / 1e8
        hf = data[5] / 1e18 # El Health Factor se devuelve con 18 decimales
        
        # Filtramos para quedarnos solo con los peces gordos (Colateral > $500,000)
        if collateral > 500000:
            print(f"Dirección: {user_address}")
            print(f"  Colateral: ${collateral:,.2f} | Deuda: ${debt:,.2f}")
            print(f"  Health Factor: {hf:.4f}")
            
            # Comprobamos si la posición ha entrado en la zona caliente del 1% antes de liquidar
            # Como la liquidación salta cuando el HF es <= 1.0, la zona de riesgo va de 1.0000 a 1.0100
            if 1.0000 < hf <= 1.0100:
                print(f"⚠️ ESTADO CRÍTICO: ¡Ballena a menos de un 1% de la liquidación! Riesgo inminente de dump del colateral.")
                # Aquí es donde meterías tu webhook para alertas de Telegram o llamarías a la función de tu bot de liquidación
            print("-" * 50)
            
    except Exception as e:
        print(f"Error al verificar la dirección {user_address}: {e}")
# Ejemplo de prueba con una wallet objetivo (cambia esto por una dirección real de tu lista)
whale_target = "0x..." 
check_whale_position(whale_target)

¿De dónde sacamos las wallets para alimentar el escáner?

El script que ves ahí arriba solo analiza una wallet de forma aislada. Para montar un radar en condiciones, necesitas que le entre un flujo continuo de direcciones. Los bots profesionales consiguen esa base de datos haciendo lo siguiente:

  • Parsing de eventos históricos (Logs): El bot hace un barrido completo del historial de la blockchain desde el bloque en que se desplegó el protocolo, extrayendo todas las wallets que hayan lanzado eventos de tipo Supply, Borrow o CollateralSwitch.
  • Suscripción a logs en tiempo real: Mediante WebSockets (usando w3.eth.subscribe('logs', ...)), el script se queda escuchando los bloques nuevos para cazar al vuelo cualquier dirección nueva que interactúe con el pool. Estas wallets únicas se guardan del tirón en una base de datos local (como MariaDB o PostgreSQL).
  • Bucle continuo de monitorización: Un worker en segundo plano va recorriendo esa base de datos sin parar, ejecutando la función getUserAccountData para cada perfil y actualizando el estado de riesgo en tiempo real.

Anatomía del "Hunt": Cómo Calcular el Punto de Gatillo Exacto

Para sacarle el jugo de verdad a la información de un "ballena herido", no basta con saber su Health Factor actual. Un searcher profesional tiene que dominar la dinámica de precios. Necesitamos saber el valor exacto del colateral que va a hacer que la posición pase por el cuchillo.

Vamos a formalizar el cálculo. Supongamos que nuestra ballena tiene un solo activo de colateral (por ejemplo, ETH) y un solo activo prestado con precio estable (USDT). El umbral de liquidación (Liquidation Threshold, o sea, LT) para ETH en el protocolo es del 85% (0.85).

La fórmula para clavar el precio crítico del colateral Price_crit funciona así:

Formula for the critical price of collateral
 

Ejemplo Práctico de Cálculo

Imagínense una posición enorme abierta en el mercado:

  • Colateral (Collateral_Amount): $10,000\ ETH$
  • Precio actual de ETH: $3,400\ USD$
  • Valor del colateral en Fiat: $34,000,000\ USD$
  • Deuda actual (Debt_USD): $28,500,000\ USDT$
  • Umbral de Liquidación (LT): 85% (0.85)

Primero, vamos a sacar el Health Factor actual de la posición:

position-health-factor
 

La posición está respirando en el piso, a tan solo 1.4% de ser liquidada. Ahora vamos a ver a qué precio de ETH se va a desplomar todo:

The ETH price at which the position will collapse
 

En cuanto el precio de ETH en el oracle del protocolo (que suele ser Chainlink) toque la marca de $3,352.94, la posición se vuelve liquidable al instante.

Data insider (Alpha puro): Los smart contracts no tienen idea de cuál es el precio spot en Binance en el segundo exacto. Dependen totalmente de los oracles. Los oracles de Chainlink actualizan el precio on-chain ya sea por tiempo (por ejemplo, cada 20 minutos) o cuando el precio off-chain se desvía más de un porcentaje fijo (Deviation Threshold), que suele ser de 0.5% o 1% para los pares principales. Sabiendo este tope, los traders más experimentados pueden predecir el segundo exacto del "gatillazo" de la liquidación, mucho antes de que la transacción del oracle se confirme en el mempool.

Estrategia de "Whale Hunting" en la Práctica: La Mecánica de Ejecución

Con el objetivo fijado y el precio crítico calculado, un searcher tiene dos formas de llenarse los bolsillos: el camino pasivo (quedarse de caza esperando la liquidación) o el camino activo (dar un empujón para acelerar el dump).

1. Ingeniería de Liquidez (Flash Loans vs. Capital Propio)

Si planeas quedarte con el bono de liquidación (en nuestro ejemplo, el 5% de $34 millones es $1.7 millones de ganancia bruta), necesitas conseguir $28.5 millones de la nada para cerrar la deuda.

Como tener semejante guita parada en la wallet es una ineficiencia de capital tremenda, se tira de un Flash Loan en los pools de liquidez de Uniswap v3 o los prestamistas de Aave. Pedís prestados los $28.5 millones dentro de la misma transacción atómica, ejecutás la función liquidationCall en el contrato de Aave, te quedás con el ETH del colateral e inmediatamente convertís una parte de ese ETH de vuelta a USDT usando un agregador (1inch / Paraswap) para devolver el flash loan con su respectivo interés (0.05%). El ETH que te sobra es tu ganancia neta.

2. Arbitraje de Mercado y Short Direccionado

Si el tamaño de la ballena es demasiado bestia para los pools normales de flash loan, o si la liquidez en las DEXes de spot es tan delgada que no podés swappear el colateral sin comerte un Slippage (deslizamiento de precio) gigante, el juego se pasa a los derivados con front-running:

  1. Paso 1: Ves que para llegar al punto crítico de 3,352.94 faltan apenas unos 15 o 20 dólares de movimiento en el precio.
  2. Paso 2: Se abre un short agresivo con bastante apalancamiento en una DEX de perps (Hyperliquid, dYdX, Vertex) o en un CEX grande.
  3. Paso 3 (El Catalizador): En el mercado spot (buscando el momento justo en que el order book esté más vacío), se tira una orden de venta pesada. Por lo general, market makers gigantes o sindicatos de searchers hacen esto coordinados para forzar un dump temporal.
  4. Paso 4 (La Cascada): En el segundo en que el precio rompe el gatillo, bots de todo el mundo empiezan a spamear las funciones de liquidación. Para asegurar sus ganancias, estos bots empiezan a reventar a mercado el ETH liquidado para pasarlo a stablecoins.
  5. Paso 5 (Toma de ganancias): Semejante pared de venta de 10,000 ETH tirada en cuestión de uno o dos minutos rompe los soportes locales, hundiendo el precio un 2-3% extra. Tu posición corta se cierra con un take profit perfecto en el fondo absoluto de ese pánico artificial.

Arquitectura de un Bot de Liquidación: Cómo Pasarles el Trapo a los Competidores en el Dark Forest

Si estás pensando en armar un bot para meter estas liquidaciones por tu cuenta, ni lo intentes con un script de Web3 básico; te van a hacer front-run en la cara. En este nicho hay una guerra de milisegundos brutal, conocida como PGA (Priority Gas Auction) y peleas de MEV-boost.

Cualquier transacción común mandada al mempool público va a ser captada por bots genéricos de front-running al instante. Te van a clonar el calldata, van a subir el gas 1 gwei más alto y te van a soplar la ganancia de las manos.

El tech stack de un bot de MEV profesional para producción: 

  • Lenguaje de Programación: Todo lo que es recolección de datos y analytics se suele manejar en Python o Go. Pero el smart contract ejecutor (el que saca el flash loan y triggerea la liquidación) tiene que estar escrito estrictamente en Solidity / Yul para exprimir cada gota de gas. Últimamente, la gente que corre bots pro se pasó en masa a Rust para el backend (usando el ecosistema de la librería alloy).
  • Conexión Directa con Block Builders: Los profesionales esquivan el mempool público a toda costa. Mandan sus transacciones a través de relays privados como Flashbots (MEV-Share / MEV-Boost), BeaverBuild o Titan. La transacción viaja empaquetada en un "Bundle" derecho al validador. Básicamente vas con el validador y le decís: "Meté mi transacción pegada justo atrás de la transacción del oracle que va a tirar el precio de ETH, y a cambio te dejo el 50% de mi ganancia de liquidación como propina (tip)".

Abajo se muestra el flujo lógico de cómo interactúan los componentes de este bot:

[Blockchain Node / Websocket] 
       │ (Escucha bloques nuevos y transacciones en el mempool sin parar)
       ▼
[Parser & DB] ────► [Health Factor Calculator] 
                         │ (Triggerea si el HF es <= 1)
                         ▼
                  [Flashbots / MEV Builder] ──► [Private Validator] ──► [Profit]

Arquitectura del Smart Contract de Ejecución (Solidity)

Para que la liquidación pase con éxito dentro de una sola transacción atómica (atomic transaction), toda la lógica de interacción con el Flash Loan y el protocolo de lending tiene que estar empaquetada en un smart contract personalizado. Olvídate de enviar transacciones sueltas desde una wallet (EOA): los bots de MEV de la competencia te van a hacer front-run y te van a volar el colateral en un pestañeo.

Abajo te dejo un ejemplo de arquitectura de un smart contract en Solidity ^0.8.20, optimizado para interactuar con Aave v3 usando el mecanismo de Flash Loan.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
interface IPool {
    function liquidationCall(
        address collateralAsset,
        address debtAsset,
        address user,
        uint256 debtToCover,
        bool receiveAToken
    ) external;
    function flashLoanSimple(
        address receiverAddress,
        address asset,
        uint256 amount,
        bytes calldata params,
        uint16 referralCode
    ) external;
}
interface IERC20 {
    function totalSupply() external view returns (uint256);
    function balanceOf(address account) external view returns (uint256);
    function transfer(address recipient, uint256 amount) external returns (bool);
    function approve(address spender, uint256 amount) external returns (bool);
    function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);
}
contract LiquidatorBot {
    address public immutable owner;
    IPool public immutable aavePool;
    modifier onlyOwner() {
        require(msg.sender == owner, "No eres el owner");
        _;
    }
    constructor(address _pool) {
        owner = msg.sender;
        aavePool = IPool(_pool);
    }
    // Estructura para pasar los parametros al callback del flash loan
    struct LiquidationParams {
        address collateralAsset;
        address debtAsset;
        address userToLiquidate;
        uint256 debtToCover;
    }
    // 1. Trigger externo: lo llama tu backend (en Rust/Go/Python) en cuanto detecta al objetivo
    function calmedDownTrigger(
        address _collateralAsset,
        address _debtAsset,
        address _userToLiquidate,
        uint256 _debtToCover
    ) external onlyOwner {
        bytes memory params = abi.encode(
            LiquidationParams({
                collateralAsset: _collateralAsset,
                debtAsset: _debtAsset,
                userToLiquidate: _userToLiquidate,
                debtToCover: _debtToCover
            })
        );
        // Pedimos el Flash Loan a Aave exactamente por el volumen de la deuda de la ballena
        aavePool.flashLoanSimple(
            address(this),
            _debtAsset,
            _debtToCover,
            params,
            0
        );
    }
    // 2. Callback de Aave: se ejecuta dentro de la MISMA transaccion DESPUES de recibir los fondos en el contrato
    function executeOperation(
        address asset,
        uint256 amount,
        uint256 premium,
        address initiator,
        bytes calldata params
    ) external returns (bool) {
        require(msg.sender == address(aavePool), "Llamada invalida");
        
        LiquidationParams memory lParams = abi.decode(params, (LiquidationParams));
        // Le damos approve al pool para que tome nuestros fondos prestados y ejecute la liquidacion
        IERC20(lParams.debtAsset).approve(address(aavePool), lParams.debtToCover);
        // Ejecutamos la liquidacion tal cual
        // El ultimo parametro en false significa que queremos el colateral limpio, no su derivado aToken
        aavePool.liquidationCall(
            lParams.collateralAsset,
            lParams.debtAsset,
            lParams.userToLiquidate,
            lParams.debtToCover,
            false
        );
        // En este punto, el colateral liquidado (por ejemplo, ETH) ya esta en el balance del contrato
        // Tarea: Hacer swap del colateral en un DEX (Uniswap/1inch) de vuelta a la moneda de la deuda (ej. USDT)
        // Para cubrir el principal del prestamo (amount) + la comision del flash loan (premium)
        
        uint256 totalOwed = amount + premium;
        
        // [Aqui va la logica para llamar a swap() en el Router de Uniswap v3 / 1inch]
        // Al final, debemos tener un saldo >= totalOwed en el balance con la moneda debtAsset
        
        // Aprobamos la devolucion del flash loan
        IERC20(lParams.debtAsset).approve(address(aavePool), totalOwed);
        // Le mandamos las ganancias netas que queden directo al owner del contrato
        uint256 profit = IERC20(lParams.debtAsset).balanceOf(address(this));
        if (profit > 0) {
            IERC20(lParams.debtAsset).transfer(owner, profit);
        }
        return true;
    }
    // Funcion de retiro de emergencia para sacar cualquier token del contrato
    function withdrawToken(address _token) external onlyOwner {
        uint256 balance = IERC20(_token).balanceOf(address(this));
        IERC20(_token).transfer(owner, balance);
    }
}

Secretos a voces y trampas ocultas (Información Alfa pura)

Si esto fuera tan fácil, cualquier programador se haría millonario en una semana. En el mundo real, detrás de las bambalinas de esta industria (el famoso "dark forest"), se esconden movidas técnicas muy densas.

1. El dolor de cabeza de las "Liquidaciones Suaves" (Close Factor)

No puedes liquidar la posición completa de una ballena de un solo golpe si su volumen es de decenas de millones. La mayoría de los protocolos modernos tienen configurado un parámetro llamado Close Factor (que suele ser del 50%). Esto significa que en una sola transacción solo te permiten pagar la mitad de la deuda pendiente del usuario.

Si cazas a una ballena con una deuda de $20,000,000, tu bot tiene que mandar una transacción para cubrir máximo $10,000,000. El resto de la deuda se recalcula, el Health Factor (HF) respira un poco y, si la posición sigue en zona de riesgo, se le puede volver a liquidar en el siguiente bloque.

2. Desfases del Oráculo y liquidaciones "fantasma"

Los peces gordos no dejan sus posiciones desprotegidas. Suelen cubrirse con sistemas automatizados descentralizados (como Gelato network o Chainlink Automation) que inyectan margen (top-up) al instante si el HF se va al suelo.

Es más, en momentos de volatilidad extrema (cracs del mercado), la red de Ethereum o las L2 (Arbitrum, Base) se suelen saturar por completo (Gas Spike). El oráculo puede actualizar el precio on-chain con un retraso de 1 o 2 bloques. Un bot que toma como referencia el precio spot de derivados fuera de la red (por ejemplo, en Binance) puede lanzar la transacción de liquidación asumiendo que el HF < 1, pero a nivel de smart contract la transacción tirará un REVERT porque el oráculo interno de la red aún no ha actualizado el precio. Te quedarás con cara de tonto habiendo tirado el dinero del gas en una transacción fallida.

3. Protección contra Front-running usando RPCs privados

Cuando tu bot manda un bundle a través de Flashbots, estás compitiendo con otros searchers puramente por cómo repartes las ganancias con el validador. Si encuentras una liquidación de $10,000 de beneficio, pero tu competidor configuró su bot para darle al validador el 99% de esa ganancia como soborno (Gas Tip), él se va a quedar con el bloque (llevándose apenas $100 limpios) y tu transacción será rechazada.

Hack Estratégico: En redes con comisiones ridículamente baratas y alta velocidad (Base, Arbitrum, Solana), los bundles clásicos de Flashbots funcionan de otra forma o ni existen tal cual. Ahí gana el que esté físicamente más cerca de los validadores (menor ping de red al nodo RPC) y el que tenga la capacidad de spamear transacciones en ráfaga usando conexiones gRPC personalizadas.

Checklist: Cómo armar una estrategia enfocada en liquidación de ballenas

Si quieres montar tu propio sistema de monitoreo o tradear estas cascadas de liquidación de forma manual o semiautomática, sigue este orden:

  • Armar el pool de objetivos: Haz un script para trackear las direcciones de los prestatarios en los protocolos grandes (Aave, Compound, Spark, Morpho, Radiant). Filtra las wallets que tengan más de $1,000,000 en colateral.
  • Calculadora de triggers: Programa un módulo matemático que tome los pesos actuales de las posiciones de las ballenas bajo la lupa y calcule el precio exacto del colateral donde el HF tocará el 1.0000.
  • Integración de alertas: Vincula esos puntos críticos con un parser del order book de los exchanges. En cuanto el precio de mercado se acerque a menos de un 1.5% del punto de liquidación de la ballena, el sistema tiene que saltar con una alerta de máxima prioridad.
  • Elegir el vector de monetización:
    • Para equipos con capital: Activar un bot de MEV puro, preparar la infraestructura para Flash Loans y pelear por el espacio del bloque a través de relays privados.
    • Para traders retail: Abrir un short agresivo en los mercados de futuros/perpetuos, contando con el dump en cascada que va a ocurrir en cuanto los bots empiecen a reventar el colateral de la ballena a precio de mercado de forma forzada.

El mercado de las liquidaciones en DeFi es pura matemática y velocidad de ejecución. El que sabe leer el estado de la blockchain y automatizar el cálculo de los puntos críticos siempre le va a sacar años luz de ventaja a los analistas técnicos que solo miran gráficos tradicionales.


FAQ

Los bots de liquidación en DeFi tiran de flash loans para pedir prestado exactamente el capital necesario para cubrir la deuda de una posición colapsada (distressed) dentro de una sola transacción atómica en la blockchain, lo que le ahorra al operador del bot tener que poner pasta (upfront capital) de su propio bolsillo. En cuanto el smart contract triggeréa la función flashLoanSimple en un lending pool tipo Aave, los assets recibidos se rutean al toque para ejecutar el liquidationCall, lo que permite confiscar el colateral subyacente con un buen descuento. Después, el bot pasa al instante ese colateral confiscado por agregadores de DEX o AMMs para swappearlo de vuelta al asset de la deuda, paga el principal más el premium del protocolo, y transfiere el spread de arbitraje restante a la wallet segura del operador antes de que la transacción se cierre en el bloque.

El lag de los oráculos (oracle latency) genera un desajuste (mismatch) entre los precios spot off-chain y el estado de los precios on-chain. Esto se traduce en bundles de ejecución fallidos y gas fees tirados a la basura por culpa de los opcodes de REVERT cuando los bots intentan liquidar posiciones cuyo Health Factor on-chain todavía no ha caído por debajo del umbral crítico de 1.0000. Como las redes de consenso y los rollups de Capa 2 sufren retrasos deterministas o frenan las actualizaciones basándose en deviation thresholds específicos, los price feeds de alta frecuencia de los CEXs suelen activar las simulaciones de los bots antes de tiempo. Los MEV searchers profesionales mitigan este riesgo haciendo backrunning de las transacciones de los price feeds directamente en el mempool: simulan el cambio de estado exacto post-update del oráculo y usan relays de RPC privados para evitar que su alfa se filtre a otros searchers que compiten en las Priority Gas Auctions.

El Close Factor es un parámetro a nivel de protocolo que capea el porcentaje máximo de la deuda pendiente de un borrower que se puede pagar en una sola transacción de liquidación, limitando normalmente a los liquidadores a neutralizar solo el 50% de la posición afectada de un solo golpe. Esta barrera estructural evita que un único searcher se coma (absorba) posiciones institucionales millonarias en un solo bloque, garantizando que el colateral restante y la deuda se recalculen para ir recuperando poco a poco las métricas de salud del portafolio. Para rascar todo el valor de una liquidación multimillonaria, los motores de búsqueda automatizados tienen que desplegar estrategias de ejecución iterativa de estados (iterative state execution), checkeando continuamente las liabilities restantes y enviando los siguientes payloads de ejecución bloque tras bloque hasta limpiar por completo el perfil de riesgo objetivo.
Sying Yu

I am a blockchain developer specializing in building secure, scalable, and innovative decentralized solutions. My expertise covers smart contracts, payment systems, and integrating crypto with fiat to optimize financial workflows. I thrive on creating modern, efficient tools for the evolving digital economy....

Escribe una opinión

Tu correo electrónico no será publicado. Los campos obligatorios están marcados *