Una taxonomía del abuso de mercado

Curiosidad

1. ¿Por qué un contrato de tokens necesita una clave de administrador si se supone que debe funcionar sin permisos?
2. ¿Cómo es posible que dos operaciones idénticas obtengan precios diferentes según quién las envíe primero?
3. Si el código no puede prevenir la ingeniería social, ¿qué parte del mercado sigue siendo vulnerable?

Explorar

Parte IUna taxonomía del abuso de mercado

1. El abuso de mercado se divide en seis capas distintas, cada una de las cuales explota una debilidad estructural específica. La capa del contrato implica poderes retenidos, como emitir o congelar tokens; la capa de estructura de mercado incluye pools poco profundos y diseños de curva; la capa de ordenamiento explota la secuenciación de las transacciones; la capa de actividad falsa infla el volumen y el número de holders; la capa social manipula la confianza mediante la suplantación de identidad; y la capa de billetera drena activos mediante phishing. Cada capa corresponde a uno de cuatro defensores (código, diseño de mercado, criptografía o personas), y este nivel muestra que ya existen herramientas para cada uno. Está escrito tanto para desarrolladores como para usuarios.
2. La capa del contrato es donde a menudo comienza el robo. Si un desarrollador conserva la autoridad de emisión, puede imprimir nuevos tokens a voluntad y venderlos en perjuicio de los holders existentes. Las funciones de congelamiento le permiten impedir que determinadas billeteras vendan, atrapando de hecho el capital. Los proxies actualizables permiten a los desarrolladores cambiar el código subyacente después del lanzamiento. Estos no son errores; son funcionalidades que crean una superficie de ataque. Eliminar estas claves elimina la amenaza, pero también quita la posibilidad de corregir errores críticos o responder a emergencias.
3. Los ataques de ordenamiento los aprovecha quien puede ver las transacciones pendientes antes de que se ordenen. El front-running ocurre cuando un trader ve una orden pendiente y envía su propia transacción con una comisión más alta para que se ejecute primero. El sandwiching consiste en comprar justo antes del swap grande de una víctima y vender inmediatamente después, obteniendo ganancias del impacto en el precio que causa ese swap. Estas pérdidas recaen sobre los traders comunes, que obtienen peores precios de ejecución. Los límites de deslizamiento acotan las pérdidas potenciales, pero no impiden el ataque en sí.
4. Los ataques de lanzamiento explotan la velocidad de los precios por orden de llegada. Los snipers compran tokens en el primerísimo bloque de un lanzamiento, a menudo usando bundles para agrupar varias transacciones y que se incluyan de forma atómica. Las billeteras Sybil permiten que un solo actor controle muchas direcciones, disimulando la concentración y acumulando recompensas por billetera. Estos ataques se basan en la creación barata de direcciones y en estructuras de recompensa que no son lineales respecto a las tenencias. La detección suele requerir analizar a posteriori los grafos de financiación.
5. La actividad falsa infla las métricas que atraen la atención. El wash trading consiste en comprar y vender tokens entre las propias billeteras para crear un volumen artificial. Los bots de volumen hacen rotar operaciones para escalar en las listas de tendencias, mientras que el envío masivo de dust (cantidades ínfimas) crea recuentos falsos de holders. Cuando cada operación paga una comisión, el wash trading se vuelve caro; pero cuando los algoritmos de tendencias ponderan las billeteras únicas, los ataques Sybil se vuelven rentables. Estas distorsiones engañan a los inversores sobre el interés real del mercado.
6. La capa social explota la confianza humana en lugar del código. Las promociones pagadas no reveladas, la suplantación de cuentas oficiales y los pump-and-dumps coordinados no requieren ninguna vulnerabilidad técnica. Los sitios de phishing y las aprobaciones maliciosas vacían las billeteras directamente a los usuarios. El código puede hacer visibles estos ataques mediante la verificación del historial on-chain, pero no puede prevenirlos. Estas amenazas residen en el comportamiento de las personas, no en la lógica de los contratos.

Parte IILo que el código puede arreglar y lo que no

7. La lógica del contrato define lo que es posible. Si el código conserva una función de emisión accesible solo para un administrador, esa clave sigue siendo una superficie de ataque permanente. Eliminar por completo la autoridad de emisión elimina el riesgo de inflación descontrolada. Del mismo modo, eliminar las variables de impuesto de venta o las funciones de congelamiento previene los honeypots y el abuso de listas negras. Son decisiones binarias: el poder existe o no existe.
8. La estructura del mercado determina el orden de ejecución. En el procesamiento secuencial, la primera compra de un bloque obtiene el mejor precio. Los mecanismos de liquidación por lotes agrupan las transacciones dentro de una ventana de tiempo y las ejecutan todas a un único precio de liquidación uniforme. Esto neutraliza el front-running y los sándwiches dentro del lote, porque cada orden recibe el mismo precio: ir primero, o envolver la orden de otro, no aporta nada.
9. Algunos riesgos están acotados, pero no eliminados. Un creador que posee el cuarenta por ciento del suministro puede venderlo de golpe y hundir el precio para los primeros compradores. El código puede bloquear el suministro del creador o someterlo a vesting, pero no puede impedir que un holder con tokens desbloqueados venda. Esto es riesgo de mercado, distinto del robo. Comprar en un bloque anterior también puede seguir siendo rentable. Los diseñadores deben aceptar que la volatilidad causada por los grandes holders es una característica inherente de los mercados sin permisos, no un error que haya que parchear.
10. La ingeniería social vive fuera de la base de código. Los enlaces de phishing, las cuentas suplantadas y las promociones pagadas explotan la confianza humana, no vulnerabilidades computacionales. Ningún contrato inteligente puede verificar si un influencer reveló su participación antes de promocionar un token. Estos ataques persisten independientemente de la seguridad técnica, porque operan sobre la atención y las creencias, no sobre transiciones de estado.
11. Un documento de diseño honesto enumera qué clases de ataque elimina el código, cuáles neutraliza la mecánica del mercado y cuáles siguen siendo irreducibles por depender del comportamiento humano. Afirma explícitamente: el abuso de emisión es imposible; los ataques sándwich se mitigan mediante el procesamiento por lotes; el phishing sigue siendo una responsabilidad de seguridad personal. Esta transparencia permite a los usuarios valorar su riesgo con precisión en lugar de suponer una seguridad total.
12. Abre un explorador de bloques para un token EVM con código fuente verificado y busca funciones como `mint`, `pause` u `owner`; en Solana, revisa en cambio las autoridades de emisión y de congelamiento y la autoridad de actualización del programa. Verifica si cualquiera puede llamar a estas funciones o si están restringidas a una dirección específica. Si no existen tales funciones y el contrato no es actualizable, esos vectores de ataque están estructuralmente ausentes, no simplemente desactivados.

Datos clave

Ejercicio nueve, seis, tres, uno

Verificación de hechos

Fechas, cifras y afirmaciones verificadas con las fuentes publicadas que se enumeran a continuación.

• Chainalysis, Crypto Crime Report (2024)
• P. Daian et al., 'Flash Boys 2.0' (IEEE S&P 2020)
• SPL Token documentation
• OpenZeppelin proxy documentation
• E. Budish, P. Cramton & J. Shim, 'The High-Frequency Trading Arms Race' (QJE 2015)