Vectores de ataque

Documentation Index

Fetch the complete documentation index at: https://docs.raydium.io/llms.txt

Use this file to discover all available pages before exploring further.

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 manera determinista. Esta página cataloga las clases de ataque que han sido demostradas contra AMMs en cualquier lugar, cómo se aplican específicamente a Raydium, y qué Raydium (e integradores) hace para defenderse.

​

1. Ataques sandwich / MEV

​

Ataque

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

​

Exposición

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

​

Defensas

• Bundles Jito (integration-guides/routing-and-mev) ocultan la transacción del mempool público.
• Slippage ajustado — mínimo de salida 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 operación más pequeños — divide un swap de 100k USD en 10× 10k USD; cada uno mueve el precio menos.

​

Postura de Raydium

Los programas principales de Raydium no imponen protecciones anti-MEV — son neutrales a nivel de programa. La protección ocurre en la capa de envío (Jito, protección incorporada de billeteras). La interfaz de usuario establece por defecto el slippage a 0,5%, que es razonable para la mayoría de pools.

​

2. Manipulación de precio

​

Ataque

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

​

Exposición

• Operaciones nativas de Raydium: no expuesto. Un swap spot de entrada y salida solo incurre en tarifas de viaje redondo; el comerciante pierde dinero.
• Programas integrados: expuestos si leen el precio del pool de Raydium de manera ingenua.

​

Defensas

• Usar 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 préstamo relámpago de una sola fuente no es suficiente.

​

Postura de Raydium

CLMM ofrece soporte TWAP ObservationState; los integradores que lo ignoran y usan precios spot están por su cuenta. La interfaz de usuario de Raydium usa múltiples fuentes de precio para la pantalla USD.

​

3. Ataques de donación / inflación

​

Ataque

El primer LP en un nuevo pool deposita una cantidad minúscula (por ejemplo, 1 token de cada mint de 6 decimales → 1 unidad de LP emitida). Luego el atacante “dona” 1.000.000 tokens directamente a la bóveda 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 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 en el pool (inspirada en el patrón MINIMUM_LIQUIDITY de Uniswap V2). Esto significa que el primer LP recibe sqrt(x × y) - MINIMUM_LIQUIDITY, con 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 montos sensatos.

​

Postura de Raydium

El bloqueo MINIMUM_LIQUIDITY se envía 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 que los ataques de donación sean no económicos en cualquier caso.

​

4. Abuso de transfer-hook Token-2022

​

Ataque

El transfer-hook de un mint es actualizable. El atacante despliega un hook inocente en el lanzamiento del mint, obtiene listado 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 retirarse). El atacante hace el pool comercializable solo en una dirección, compra LP barato, desbloquea los hooks, gana.

​

Exposición

Pools que incluyen un mint con transfer-hook.

​

Defensas

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

​

Postura de Raydium

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

​

5. Exploits de composabilidad / CPI

​

Ataque

Un programa compone Raydium mediante CPI e introduce un bug: por ejemplo, pasa el observation_state incorrecto, los tick arrays incorrectos para un swap CLMM, o gasta dos veces una cuenta. El atacante identifica la composición defectuosa y explota.

​

Exposición

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

​

Ejemplos históricos

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

​

Defensas

• Los programas que llaman deben usar los ayudantes de CPI de Anchor (no instrucciones construidas a mano) cuando sea posible — la seguridad de tipos captura la mayoría de 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 billetera atacante, o drena tarifas de protocolo.

​

Exposición

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

​

Defensas

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

​

Incidente histórico

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

​

7. Ataques económicos sobre matemáticas de tick CLMM

​

Ataque

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

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

​

Exposición

Matemáticas complejas personalizadas. 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 con impacto en producción encontrado hasta la fecha. La aritmética sqrt_price_x64 Q64.64 usa matemáticas de saturación de 128 bits con pruebas unitarias cubriendo ticks límite.

​

8. Confusión de position-NFT

​

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 position-NFT.

​

Defensas

• Las interfaces de usuario de billetera deben reconocer posición-NFTs de Raydium y mostrarlos distintivamente (no como NFTs genéricos para “enviar”).
• Los usuarios deben ser cautelosos al firmar transacciones que transfieran NFTs.

​

Postura de Raydium

Los position-NFTs implementan el estándar de metadatos de Metaplex; las aplicaciones de billetera que entienden posiciones CLMM las muestran como posiciones de liquidez en lugar de NFTs comercializables. La mayoría de billeteras principales de Solana las surfacean especialmente a partir de 2026.

​

9. Manipulación de flujo de recompensa de granja

​

Ataque

Un creador de granja financia la bóveda de recompensa, atrae apostadores, 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 firmemente; 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, por lo que ninguna acumulación pre-cambio se corrompe retroactivamente.

​

Postura de Raydium

La auditoría de granja de OtterSec específicamente probó escenarios de reinicio de recompensas; ningún exploit encontrado.

​

10. Divergencia 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 a billeteras que dependen de la simulación para visualización.

​

Exposición

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

​

Defensas

• Usa simulateTransaction con el mismo blockhash que la presentación real.
• Muestra la salida esperada como ”≈” (aproximadamente) no exacta.
• Re-simula inmediatamente antes de presentación.

​

Postura de Raydium

La simulación 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 mediante límites de slippage).

​

Tabla de resumen

​

Lo que los usuarios pueden hacer

• Defina slippage ajustado por defecto; aumente solo cuando sea necesario.
• Use billeteras / flujos de swap habilitados para Jito.
• Verifique extensiones de mint antes de LP.
• Monitoree multisig de Squads para actualizaciones pendientes.
• Diversifique entre pools; no concentre todo su LP en un pool de lanzamiento nuevo.

​

Lo que los integradores pueden hacer

• Use ObservationState TWAPs para fijación de precio de derivados.
• Valide restricciones de cuenta al componer mediante CPI.
• Filtre pools por campo tags (omita scam, honeypot, transfer-hook no verificado).
• Establezca límites de slippage razonables; no acepte slippage 0 de entrada de usuario.
• Use simulateTransaction con cuidado — documente que es una estimación.

​

Enlaces

• security/oracle-and-token-risks — Riesgos de Token-2022 en profundidad.
• security/admin-and-multisig — Estructura de autoridad.
• security/disclosure — Programa de recompensa por bugs.
• integration-guides/routing-and-mev — Mitigaciones de MEV.

Fuentes:

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