Vectores de ataque

Un AMM es un objetivo atractivo para código adversarial: los fondos de los LPs están en pools completamente visibles; cada swap cambia el precio de forma determinista. Esta página cataloga las clases de ataque que se han demostrado contra AMMs en cualquier lugar, cómo se aplican específicamente a Raydium, y qué hace Raydium (e integradores) para defenderse.

​

1. Ataques sandwich / MEV

​

Ataque

Un bot observa el mempool / flujo de gossip, ve un swap de un usuario, hace front-run con una compra en la misma dirección (empujando el precio), deja que la tx del usuario se ejecute a un precio peor, y luego hace back-run con una venta en dirección opuesta. El bot se beneficia del spread.

​

Exposición

• Más expuesto: pools CPMM de bajo TVL y pools AMM v4 — incluso pequeños trades mueven el precio significativamente.
• Menos expuesto: pools CLMM profundos — trades dentro de un tick no mueven el precio.
• No expuesto: cosechas de granjas, depósitos de LP (ratio forzado, no sensible al precio de la misma manera).

​

Defensas

• Bundles de Jito (integration-guides/routing-and-mev) ocultan la tx del mempool público.
• Slippage ajustado — minimum-out más cercano al esperado hace que los sandwiches sean no rentables. Por debajo de ~0.3%, la mayoría de sandwiches pierden dinero.
• Tamaños de trade más pequeños — divide un swap de $100k en 10× $10k; cada uno mueve el precio menos.

​

Postura de Raydium

Los programas principales de Raydium no fuerzan protecciones anti-MEV — son neutrales a nivel de programa. La protección ocurre en la capa de envío (Jito, protección integrada de wallets). La UI establece por defecto el slippage en 0.5%, lo cual es razonable para la mayoría de pools.

​

2. Manipulación de precios

​

Ataque

Un trader grande mueve temporalmente el precio de un pool (mediante un flash loan o capital propio), dispara alguna acción descendente que depende del precio (una liquidación, un préstamo derivado de oráculo, un pago de derivado), y luego devuelve el precio a la normalidad.

​

Exposición

• Operaciones nativas de Raydium: no expuesto. Un swap spot dentro y fuera solo incurre en tarifas de ida y vuelta; el trader pierde dinero.
• Programas integrados: expuesto si leen el precio del pool de Raydium ingenuamente.

​

Defensas

• Usa TWAPs, no precios spot, para composabilidad (ver security/oracle-and-token-risks).
• CLMM ObservationState proporciona un TWAP de ventana corta que no es manipulable sin compromiso de capital sostenido.
• Consenso multi-oráculo: si tu programa lee Raydium y Pyth y Jupiter y solo actúa cuando están de acuerdo dentro del 1%, la manipulación de flash-loan de cualquier fuente única no es suficiente.

​

Postura de Raydium

CLMM incluye soporte TWAP de ObservationState; los integradores que lo ignoran y usan precios spot están por su cuenta. El frontend de Raydium usa múltiples fuentes de precio para la visualización en USD.

​

3. Ataques de donación / inflación

​

Ataque

El primer LP en un nuevo pool deposita una cantidad minúscula (p. ej., 1 token cada uno de mints de 6 decimales → 1 unidad de LP emitida). Luego el atacante “dona” 1,000,000 tokens directamente al vault del pool mediante transferencia SPL Token. Ahora 1 unidad de LP representa 500,000 de cada mint. Cualquier LP posterior que deposite menos que eso se redondea a 0 unidades de LP y pierde su depósito.

​

Exposición

• CPMM / AMM v4: potencialmente expuesto en pools recién creados de baja liquidez.
• CLMM: no expuesto (sin mint de LP compartido; cada posición es su propio NFT con valor de liquidez explícito).

​

Defensas

La instrucción initialize de CPMM bloquea una cantidad mínima de LP al pool (inspirada en el patrón MINIMUM_LIQUIDITY de Uniswap V2). Esto significa que el primer LP recibe sqrt(x × y) - MINIMUM_LIQUIDITY, con el MINIMUM_LIQUIDITY (1000 unidades) quemado a null. Un ataque de donación requiere que el atacante done >> el depósito inicial, lo que se vuelve no económico. Además, el SDK de Raydium advierte fuertemente cuando el depósito inicial es minúsculo y guía a los usuarios hacia cantidades sensatas.

​

Postura de Raydium

El bloqueo MINIMUM_LIQUIDITY se incluye en CPMM; AMM v4 tiene un mecanismo similar. Los usuarios que crean pools deben sembrar con al menos 10,000+ unidades de cada mint para hacer que los ataques de donación sean no económicos de todas formas.

​

4. Abuso de transfer-hook de Token-2022

​

Ataque

El transfer hook de un mint es actualizable. El atacante despliega un hook inocente en el lanzamiento del mint, se lista en Raydium, acumula LP de usuarios. Más tarde, actualiza el hook para bloquear todas las transferencias (efectivamente un soft-rug — los usuarios no pueden retirar). El atacante hace que el pool sea comercializable solo en una dirección, compra LP barato, desbloquea hooks, gana.

​

Exposición

Pools que incluyen un mint con transfer-hook.

​

Defensas

• Nivel de programa: Los programas de Raydium invocan el hook durante swaps; si el hook bloquea, el swap se revierte. Esto no previene el ataque mecánicamente.
• Nivel de UI: Raydium marca pools con mints de transfer-hook.
• Nivel de integrador: los agregadores deben omitir mints de transfer-hook por defecto y permitir solo hooks verificados.

​

Postura de Raydium

Raydium no prohíbe pools de transfer-hook (existen hooks legítimos), pero los etiqueta claramente. Los agregadores que filtran en tags.includes("TRANSFER_HOOK") pueden excluir si lo desean.

​

5. Exploits de composabilidad / CPI

​

Ataque

Un programa compone Raydium vía CPI e introduce un bug: p. ej., pasa el observation_state incorrecto, los tick arrays incorrectos para un swap CLMM, o gasta doble una cuenta. El atacante identifica la composición buggy y la explota.

​

Exposición

• El integrador buggy — usualmente la fuente del bug.
• Raydium — solo si el bug dispara comportamiento no intencionado en los programas de Raydium mismos.

​

Ejemplos históricos

Ninguno de los programas de Raydium ha sido explotado vía CPI — los validadores de cuenta de Raydium atrapan cuentas mal formadas y revierten. Los exploits en el ecosistema más amplio han ocurrido vía bugs de programa personalizado que componían con un AMM pero no provenían del AMM.

​

Defensas

• Los programas que llaman deben usar los helpers CPI de Anchor (no instrucciones construidas a mano) cuando sea posible — la seguridad de tipos atrapa la mayoría del mal uso.
• Las pruebas de integración contra estado forked de mainnet cubren los casos de composición.

​

6. Compromiso de admin / clave

​

Ataque

Una clave de admin (autoridad de actualización, admin de AmmConfig, reclamación de tarifa de protocolo) se ve comprometida. El atacante despliega una actualización maliciosa que drena pools, o modifica AmmConfigs para enrutar tarifas a una wallet de atacante, o drena tarifas de protocolo.

​

Exposición

Todos los roles documentados en security/admin-and-multisig.

​

Defensas

• Multisig 3/4 en autoridad de actualización requiere comprometer 4 firmantes independientes.
• Timelock de 24 horas en actualizaciones da a los usuarios tiempo para deshacer antes de que una actualización maliciosa se active.
• Monitoreo operacional — alertas en cualquier actividad de multisig vía cola pública de Squads.

​

Incidente histórico

La clave de autoridad del pool de AMM v4 fue comprometida en diciembre de 2022 (pre-multisig). Solución: movió toda la autoridad a multisig de Squads. Post-solución, sin incidentes.

​

7. Ataques económicos en matemática de tick de CLMM

​

Ataque

Un atacante sofisticado explota redondeo o casos extremos de contabilidad de tarifas en matemática de tick de CLMM. Ejemplos que se han encontrado en otras implementaciones de CLMM (no Raydium):

• Contabilidad de crecimiento de tarifas que redondea contra el usuario, acumulando polvo.
• Cruce de tick que acredita/debita el delta fee_growth incorrecto.
• Desbordamiento de enteros en productos sqrtPrice * liquidity.

​

Exposición

Matemática compleja personalizada. Las auditorías y fuzzing son la defensa principal.

​

Postura de Raydium

CLMM ha tenido dos auditorías independientes (OtterSec + MadShield) más fuzzing basado en propiedades en curso. Ningún bug impactante en producción encontrado hasta la fecha. La aritmética sqrt_price_x64 Q64.64 usa matemática saturante de 128-bit con pruebas unitarias cubriendo ticks límite.

​

8. Confusión de NFT de posición

​

Ataque

Un usuario es engañado para firmar una transacción que transfiere su NFT de posición CLMM a un atacante. El atacante ahora posee la liquidez de la posición.

​

Exposición

Cualquier titular de NFT de posición.

​

Defensas

• Las UIs de wallet deben reconocer NFTs de posición de Raydium y mostrarlos distintamente (no como NFTs genéricos para “enviar”).
• Los usuarios deben ser cautelosos al firmar transacciones que transfieren NFTs.
• Una nueva posición se congela solo cuando usa una ruta abierta V2 y la autoridad de congelación del mint del vault subyacente coincide con la lista de emisores restringidos de CLMM. Esa posición coincidente no puede ser transferida o tener su propietario de cuenta de token cambiado; todas las otras nuevas posiciones permanecen transferibles.

​

Postura de Raydium

Los NFTs de posición implementan el estándar de metadatos de Metaplex; las aplicaciones de wallet que entienden posiciones de CLMM las muestran como posiciones de liquidez en lugar de NFTs comercializables. La mayoría de wallets principales de Solana las muestran especialmente a partir de 2026. El congelamiento de emisores restringidos es dirigido y no protege posiciones transferibles ordinarias.

​

9. Manipulación de flujo de recompensas de granja

​

Ataque

Un creador de granja financia el vault de recompensas, atrae stakers, luego llama a restartRewards con parámetros que hacen que el cálculo de recompensa pendiente sea extraño, robando valor de cosecha.

​

Exposición

Granjas con creadores maliciosos. Farm v6 limita los poderes del creador estrictamente; este ataque no funciona.

​

Defensas

Las instrucciones de admin de Farm v6 (setRewards, restartRewards, addReward) preservan derechos pro-rata — el reward_per_share se ajusta en el momento del cambio, así que ningún accrual pre-cambio se corrompe retroactivamente.

​

Postura de Raydium

La auditoría de granja de OtterSec específicamente probó escenarios de restart-rewards; ningún exploit encontrado.

​

10. Divergencia de simulación vs ejecución

​

Ataque

Un atacante construye una transacción que simula exitosamente pero se revierte en ejecución (o viceversa). Se usa para acosar wallets que se basan en simulación para visualización.

​

Exposición

Wallets mostrando “recibirás X” basado en simulación.

​

Defensas

• Usa simulateTransaction con el mismo blockhash que el envío real.
• Muestra salida esperada como ”≈” (aproximadamente) no exacta.
• Re-simula inmediatamente antes del envío.

​

Postura de Raydium

La simulación de CLMM es determinista dado el estado actual del pool; la divergencia solo ocurre si el estado cambia entre simulación y ejecución (caso normal, manejado vía límites de slippage).

​

Tabla de resumen

​

Qué pueden hacer los usuarios

• Establece slippage ajustado por defecto; aumenta solo cuando sea necesario.
• Usa wallets / flujos de swap habilitados para Jito.
• Verifica extensiones de mint antes de LP.
• Monitorea multisig de Squads para actualizaciones pendientes.
• Diversifica entre pools; no concentres todo tu LP en un pool de nuevo lanzamiento.

​

Qué pueden hacer los integradores

• Usa TWAPs de ObservationState para precios de derivados.
• Valida restricciones de cuenta al componer vía CPI.
• Filtra pools por campo tags (omite scam, honeypot, transfer-hook no verificado).
• Establece límites de slippage razonables; no aceptes slippage 0 de entrada de usuario.
• Usa simulateTransaction con cuidado — documenta que es una estimación.

​

Referencias

• security/oracle-and-token-risks — Riesgos de Token-2022 en profundidad.
• security/admin-and-multisig — estructura de autoridad.
• security/disclosure — programa de bug-bounty.
• integration-guides/routing-and-mev — mitigaciones de MEV.

Fuentes:

• Rekt News — post-mortems de DeFi informando esta lista.
• Reportes de auditoría vinculados en security/audits.