Saltar al contenido
Financial Context Wiki

Fecha límite, deslizamiento y calldata de un swap: qué verificar antes de firmar

Aprende a decodificar una llamada de swap en un DEX y a verificar el router, la función, los límites de importe, la ruta, el destinatario y la fecha límite antes de firmar.

Actualizado

Solo con fines educativos; no constituye asesoramiento ni recomendación de inversión. Las inversiones pueden generar pérdidas.

Respuesta directa

Antes de firmar un swap en un DEX, verifica la cadena, el contrato de destino, la función decodificada, las direcciones de los tokens, el límite de entrada o salida, la ruta, el destinatario y cualquier fecha límite. El porcentaje que una interfaz muestra como «deslizamiento» no es en sí una instrucción on-chain. Suele emplearse para calcular un límite como amountOutMin o amountOutMinimum en un swap exact-input, o amountInMax o amountInMaximum en uno exact-output.

La fecha límite protege el tiempo, no garantiza un precio. Si el router comprueba la fecha límite y la transacción se ejecuta después, la llamada debería revertirse. Antes de ese momento aún puede ejecutarse a cualquier precio permitido por el límite de importe. Una fecha lejana mantiene la autorización utilizable durante más tiempo; una demasiado próxima aumenta la posibilidad de que expire antes de incluirse.

Calldata no se describe a sí misma. Decodifícala con la ABI verificada del contrato exacto en la cadena elegida, incluidas las llamadas multicall o instrucciones de Universal Router anidadas. Si el monedero no muestra campos decodificados fiables, no deduzcas su significado solo por la posición de los bytes o por una base de datos de nombres de funciones.

Cómo funciona

Decodificar la llamada real

Según la ABI de Solidity, los primeros 4 bytes de calldata son el selector de función y los argumentos codificados empiezan en el quinto byte. Un selector puede colisionar o estar mal etiquetado, por lo que debe contrastarse con la ABI del contrato de destino verificado. Un proxy, agregador o router puede envolver el swap en multicall, execute u otra función; decodifica cada carga anidada capaz de transferir tokens o cambiar el destinatario final.

En un swap exact-input, la entrada es fija y el campo de protección establece la salida mínima aceptable. En uno exact-output, la salida deseada es fija y el campo de protección limita la entrada. Un límite cero o inesperadamente amplio puede eliminar una protección de precio significativa. Los decimales del token importan: asocia cada dirección con sus decimales y símbolo correctos antes de comparar enteros sin formato.

Comprobar la ruta, el destinatario y value

Confirma que la ruta empieza con el token que se gasta y termina con el que se espera recibir. Revisa tokens intermedios, comisiones de pools y cualquier instrucción que envuelva, desenvuelva, barra o transfiera saldos. El destinatario debe ser el monedero previsto o un contrato cuyo comportamiento se comprenda. Comprueba también el value nativo de la transacción; puede estar separado de los importes ERC-20 codificados en calldata.

Localizar la fecha límite

La ubicación de la fecha límite depende de la versión del router. Las funciones de routers al estilo Uniswap V2 incluyen un argumento deadline, y las estructuras del ISwapRouter original de Uniswap V3 también. Universal Router ofrece tanto execute(commands, inputs, deadline) como una sobrecarga sin fecha límite. Por eso no debes suponer que todo swap tiene una fecha límite ni que esta aparece dentro de los mismos parámetros anidados.

Normalmente, la fecha límite se compara con la marca temporal del bloque usada durante la ejecución. No cancela una transacción pendiente, no garantiza una inclusión rápida ni evita un precio desfavorable que siga dentro del límite. Para cancelar, el remitente debe usar el mecanismo de sustitución de transacciones de su cadena y monedero, y la sustitución no está garantizada si la original ya se incluyó.

Ejemplo completo

Una cotización espera recibir 10,000 USDC en un swap exact-input y el usuario elige un deslizamiento de 1%. Sin contar las comisiones ya incorporadas a la cotización, el mínimo esperado es 9,900 USDC. Como USDC usa 6 decimals, el entero sin formato de ese límite es 9900000000.

Sin embargo, la llamada decodificada contiene amountOutMinimum = 9000000000, es decir, 9,000 USDC. Eso permite recibir hasta un 10% menos que la cotización, no un 1%. El destinatario también es una dirección desconocida y faltan varias horas para la fecha límite. Cualquiera de esas discrepancias basta para rechazar la solicitud y reconstruirla mediante una interfaz fiable. Después, simula la transacción exacta sin firmar contra un estado reciente y vuelve a comprobar la carga decodificada antes de firmar.

Lista de verificación y riesgos

  • Contrasta la cadena elegida y la dirección del router o proxy con los registros oficiales de despliegue del protocolo.
  • Decodifica con la ABI del contrato verificado; despliega las llamadas anidadas y las instrucciones del router en vez de revisar solo la función externa.
  • Comprueba direcciones, sentido, decimales, importe fijo, límite protector, ruta, niveles de comisión, destinatario y value nativo.
  • Convierte la fecha límite en una hora absoluta y decide si el margen restante es intencionado. Trata la ausencia de fecha límite como una decisión de diseño que requiere revisión aparte.
  • Simula la transacción exacta desde la dirección firmante contra un estado reciente. Una simulación satisfactoria solo es evidencia para ese estado, no una garantía de inclusión o ejecución final.
  • Revisa por separado las aprobaciones o permisos Permit2. Unos límites correctos no vuelven segura una autorización de tokens ilimitada o maliciosa.
  • Los límites estrictos pueden revertir con movimientos normales; los laxos aumentan el riesgo de precio de ejecución y de ataque sándwich. Una transacción on-chain revertida aún puede consumir gas.

Errores frecuentes

Mito: se firma el porcentaje de deslizamiento mostrado

Normalmente, la carga firmada contiene límites de importe derivados de ese ajuste. Verifica los enteros reales y los decimales del token; una etiqueta correcta no prueba que calldata use la misma tolerancia.

Mito: todos los swaps usan amountOutMin y deadline

Los nombres y ubicaciones varían según el router y la función. Los swaps exact-output protegen el lado de entrada, y algunos puntos de entrada omiten la fecha límite o la sitúan en una llamada externa.

Mito: una fecha límite evita un mal precio

Solo limita cuándo se permite la ejecución si el código llamado la aplica. La protección de precio procede del límite de importe, que aun así permite cualquier ejecución dentro de él.

Mito: basta con decodificar la función externa

Los agregadores y routers universales pueden contener varias llamadas, permisos de tokens, transferencias e instrucciones de limpieza. El destinatario o importe relevante para la seguridad puede estar en una carga anidada.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...