De Solana al EVM: Un nuevo camino para los AMM propietarios

Los Prop AMMs han capturado rápidamente el 40% del volumen total de trading en Solana. ¿Por qué no están presentes en EVM?

Los Automated Market Makers propietarios (Prop AMMs) se han consolidado como actores predominantes en el ecosistema DeFi de Solana, generando más del 40% del volumen de negociación en los principales pares. Estos espacios especializados, gestionados por market makers profesionales, ofrecen liquidez profunda y precios competitivos, principalmente al minimizar la exposición de los market makers al front-running de arbitrajistas que aprovechan cotizaciones desactualizadas.

https://dune.com/the_defi_report/prop-amms

No obstante, su éxito se ha limitado casi exclusivamente a Solana. ¿Por qué no han prosperado en el ecosistema EVM, incluso en Layer 2 rápidas y de bajo costo como Base u Optimism?

Este análisis examina qué son los Prop AMMs, las barreras técnicas y económicas que enfrentan en las cadenas EVM, y una arquitectura emergente que podría posicionarlos en el centro de la DeFi sobre EVM.

¿Qué son los Prop AMMs?

Un Prop AMM es un Automated Market Maker donde la liquidez y la fijación de precios de un pool son gestionadas activamente por un único market maker profesional, en contraste con la provisión pasiva y pública de los AMMs convencionales.

A diferencia de los AMMs tradicionales, que utilizan la ecuación x * y = k para establecer precios (donde x e y representan las cantidades de los dos activos en el pool y k es una constante), los Prop AMMs emplean fórmulas distintas que suelen actualizarse varias veces por segundo. Dado que los Prop AMMs suelen ser cajas negras, la fórmula específica de cada uno es desconocida. Sin embargo, el smart contract del Prop AMM de Obric en Sui es público (gracias a @ markoggwp por identificarlo), y en él la invariante k depende de variables internas mult_x, mult_y y concentración. La siguiente imagen ilustra cómo el market maker ajusta constantemente estas variables.

Conviene aclarar que el lado izquierdo de la fórmula de la curva de precios de Obric es más complejo que x * y, pero lo esencial para comprender los Prop AMMs es que equivale a una invariante k, la cual el market maker modifica para ajustar la curva de precios.

Recordatorio: ¿Cómo se determinan los precios en un AMM?

El concepto de “curva de precios” aparecerá repetidamente, ya que determina el precio que paga el usuario al operar en un AMM y es lo que el market maker ajusta en su Prop AMM para modificar precios. Antes de profundizar en los Prop AMMs, es útil comprender cómo se determinan los precios en un AMM. Considere un pool Uniswap v2 para WETH-USDC sin comisiones. El precio se determina pasivamente mediante la fórmula x * y = k, donde x e y son las cantidades de ambos activos en el pool y k es constante. Solo los puntos de la curva representan precios posibles para la operación del usuario.

Por ejemplo, en un pool WETH-USDC con 100 WETH y 400,000 USDC, el punto actual es x = 100 WETH, y = 400,000 USDC, lo que implica un precio inicial de 400,000 USDC / 100 WETH = 4,000 USDC por WETH. El producto constante es xy = k = 40,000,000. Si un trader compra 1 WETH, añade USDC al pool y el saldo de WETH baja a 99. Para mantener k, los nuevos valores x e y deben estar en la curva, por lo que el saldo de USDC aumenta a 40,000,000 / 99 ≈ 404,040.40 USDC. El trader paga 4,040.40 USDC por ese WETH, un precio superior al inicial de $4,000 debido al impacto de precio (slippage). Por eso x y = k se denomina curva de precios: cualquier precio posible debe corresponder a un punto de la curva.

¿Por qué un Market Maker optaría por un AMM en vez de un CLOB?

Analicemos por qué un market maker preferiría un diseño AMM para market making. Imagine que opera en un Central Limit Order Book (CLOB) onchain. Para actualizar sus cotizaciones, debe cancelar y reemplazar miles de órdenes límite individuales. Si tiene N órdenes, esto implica una operación O(N), lenta y costosa en blockchain.

¿Y si pudiera representar todas sus cotizaciones como una sola curva matemática? En vez de gestionar N órdenes distintas, solo ajustaría unos pocos parámetros que definen la curva. Así, un problema O(N) se convierte en una operación O(1) constante.

Para visualizar cómo una curva de precios (ej. x*y = k) puede generar diferentes precios efectivos, veamos SolFi, el Prop AMM de Ellipsis Labs. Aunque la curva de precios es privada, Ghostlabs elaboró el siguiente gráfico que muestra el precio efectivo de SOL a USDC para diversas cantidades de SOL a intercambiar en un slot de Solana (en EVM, el slot equivale al número de bloque). Cada línea representa un pool WSOL/USDC distinto, mostrando cómo pueden ofrecer diferentes niveles de precios simultáneamente. Al actualizar la curva de precios, el market maker modifica el gráfico de precios efectivos entre slots.

https://github.com/tryghostxyz/solfi-sim/blob/main/static/curves_333436948.png

La clave aquí es que, con una sola actualización de algunos valores de la curva de precios, el market maker puede modificar el gráfico de precios efectivos a su conveniencia, sin tener que actualizar N órdenes distintas. Este es el principal valor de un Prop AMM: permite ofrecer liquidez profunda y dinámica con gran eficiencia de capital y computacional.

Por qué la arquitectura de Solana es óptima para Prop AMMs

Los Prop AMMs requieren gestión activa, lo que implica dos factores: actualizaciones de bajo costo y ejecución prioritaria. En Solana, la economía de las actualizaciones permite que estas tengan prioridad en la ejecución.

¿Por qué son necesarias ambas condiciones? Los market makers actualizan sus curvas de precios al ritmo de la cadena, según inventario y variaciones en el precio índice del activo (por ejemplo, desde exchanges centralizados). En cadenas rápidas como Solana, esto sería costoso si las actualizaciones no fueran baratas.

Además, si el market maker no logra que su actualización esté al inicio del bloque, sus cotizaciones desactualizadas serán aprovechadas por arbitrajistas, generando pérdidas aseguradas.

Sin ambos requisitos, los market makers no operarían eficientemente, lo que impactaría negativamente los precios para el usuario.

Por ejemplo, Prop AMMs como HumidiFi en Solana actualizan sus cotizaciones hasta 74 veces por segundo (agradecimiento a @ SliceAnalytics por los datos), como muestra la siguiente imagen:

https://dune.com/queries/5980584/9644764

Desde la perspectiva EVM, surge la pregunta: “Si los slots de Solana duran ~400ms, ¿cómo puede un Prop AMM actualizar precios varias veces en un solo slot?”

La explicación está en la arquitectura continua de Solana, muy diferente del modelo de bloques discretos de EVM.

• EVM: Las transacciones se ejecutan secuencialmente cuando se propone y finaliza un bloque completo. Una actualización enviada a mitad de bloque no se reflejará hasta el siguiente bloque.
• Solana: El validador líder no espera a construir un bloque completo. Divide las transacciones en paquetes (“shreds”) y los transmite continuamente a la red. Puede haber múltiples swaps en un slot, pero una actualización de precio en el shred #1 afecta el swap #1, mientras que la actualización en el shred #2 impacta el swap #2.

Nota: Soluciones como Flashblocks son equivalentes a los shreds de Solana. Según @ Ashwinningg (Anza Labs, CBER), hay un límite superior de 32,000 shreds por slot de 400ms, es decir, hasta 80 shreds por milisegundo. Si los Flashblocks de 200ms son suficientemente rápidos para los market makers en comparación con Solana, es una cuestión abierta.

¿Por qué las actualizaciones son tan económicas en Solana y cómo esto favorece la ejecución prioritaria?

Aunque la implementación de los Prop AMMs en Solana es privada, existen librerías como Pinocchio para crear programas optimizados en Compute Units (CU). El blog de Helius analiza cómo esta librería reduce programas de Solana de ~4000 CU a ~100 CU (ver aquí).

https://github.com/febo/p-token?tab=readme-ov-file#compute-units

En cuanto a la priorización, Solana selecciona las transacciones con la mayor relación Fee / Compute Units (CU), análogo al Gas en EVM.

• Con Jito, la fórmula es Jito Tip / Compute Units,
• sin Jito, Prioridad = (Prioritization fee + Base fee) / (1 + CU limit + Signature CUs + Write lock CUs) (https://solana.com/docs/core/fees)

Comparando los Compute Units de una actualización Prop AMM frente a un Jupiter Swap, la actualización Prop AMM es extremadamente barata, con una relación de 1 a 1000.

Actualización Prop AMM: Una actualización de curva puede costar tan solo 109 CU; la tarifa total de la transacción es 0.000007506 SOL

https://orb.helius.dev/tx/325EwPasEyXYuVqow9aGT44i17cZzd9G5GYPHxJr1JmLKwyWTS6rJgV6EP1svqExo9TnoqqmMF15si17x2s7wnSu?cluster=mainnet-beta&advanced=true&tab=summary

Jupiter Swap: Un swap en Jupiter puede consumir ~100,000 CU; la tarifa total es 0.000005 SOL.

https://orb.helius.dev/tx/4SbYyAEq6QBNv5YW517fLRatEPvBvh1kDit3C8NL84uBRXuE7FFEsVuX6BDG44reXtMt5WZCGxN7rS38jt4RSNY9?cluster=mainnet-beta&advanced=true&tab=summary)

Gracias a esta diferencia, el market maker puede lograr ejecución prioritaria pagando una pequeña tarifa en la transacción de actualización, obteniendo una relación Fee/CU mucho mayor que la de un swapper. Esto garantiza que la actualización se ejecute de forma eficiente y al inicio del bloque, protegiéndolo del arbitraje por flujo tóxico.

¿Por qué los Prop AMMs aún no están en EVM?

Supongamos que actualizar un Prop AMM implica escribir variables que definen la curva de precios de un par de trading. Aunque el código Prop AMM en Solana es privado, tras analizar la implementación de Obric en Sui, observamos que los parámetros se escriben en el smart contract mediante funciones de actualización.

https://suiscan.xyz/mainnet/object/0xb84e63d22ea4822a0a333c250e790f69bf5c2ef0c63f4e120e05a6415991368f/contracts

Gracias a @ markoggwp por este hallazgo.

Bajo esta premisa, la arquitectura EVM representa un obstáculo clave que dificulta replicar el modelo Prop AMM de Solana.

En blockchains Layer 2 OP-Stack como Base y Unichain, las transacciones se ordenan por Priority Fee por Gas (similar a Fee / CU en Solana).

En EVM, las escrituras en storage consumen mucho gas. Un simple SSTORE para un valor es mucho más costoso que una actualización en Solana.

• SSTORE (de cero a no cero): ~22,100 gas
• SSTORE (de no cero a no cero): ~5,000 gas
• Swap en AMM típico: ~200,000 - 300,000 gas

El Gas en EVM es comparable a los Compute Units en Solana.

Los valores SSTORE anteriores asumen una sola escritura por transacción (“cold writes”), lo que es razonable, ya que no se enviarían múltiples actualizaciones en una sola transacción.

Aunque una actualización es más barata que un swap, la relación de gas es solo ~10x (una actualización puede usar varios SSTORE), frente a ~1000x en Solana.

Esto genera dos implicaciones que hacen más riesgoso el modelo Prop AMM en EVM:

1. El alto consumo de gas implica que una pequeña priority fee no genera una alta relación Priority Fee / Gas. Garantizar que la actualización esté al inicio del bloque requerirá una priority fee mayor y más costosa.
2. La relación entre gas de actualización y gas de swap en EVM es solo 1:10, frente a 1:1000 en Solana. Un arbitrajista en EVM solo necesita aumentar su Priority Fee 10x respecto a la actualización para superar y hacer front-running, mientras que en Solana requeriría 1000x. En este entorno, es más fácil para el arbitrajista adelantarse a la actualización y aprovechar cotizaciones desactualizadas.

Innovaciones como EIP-1153 (TSTORE para almacenamiento transitorio) permiten escrituras de 100 gas, pero este storage es temporal y solo dura una transacción. No puede usarse para mantener una actualización de precio para un swap posterior (por ejemplo, durante un bloque).

¿Cómo podemos llevar los Prop AMMs a EVM?

Antes de responder, aclaremos el “por qué”. Los usuarios buscan mejores cotizaciones para sus trades, lo que les permite obtener mejores condiciones. Los Prop AMMs en Ethereum y Layer 2 permitirían cotizaciones más competitivas, hoy exclusivas de Solana y exchanges centralizados.

Para viabilizar Prop AMMs en EVM, recordemos una razón clave por la que funcionan en Solana:

• Las actualizaciones Prop AMM al inicio del bloque en Solana protegen al market maker del front-running. Esto es posible porque las actualizaciones consumen pocos Compute Units, de modo que una tarifa baja sigue generando una alta relación Fee / CU, especialmente comparado con swaps.

¿Cómo llevamos actualizaciones Prop AMM al inicio del bloque en Layer 2 EVM? Hay dos caminos: reducir el costo de las escrituras o crear un carril prioritario para actualizaciones Prop AMM.

Reducir el costo de las escrituras es inviable por el problema de crecimiento de estado en EVM, donde SSTOREs baratos facilitarían el spam.

Proponemos la segunda opción: crear un carril prioritario para actualizaciones Prop AMM.

Una propuesta innovadora, sugerida por @ MarkToda (Uniswap), plantea usar un smart contract de Global Storage (ver repositorio) junto con una política de builder especializada.

https://github.com/flashbots/global-storage-smart-contract

Funcionamiento:

• Global Storage Contract: Un smart contract público y sencillo actúa como almacén clave-valor. Los market makers escriben los parámetros de la curva de precios (ej. set(ETH-USDC_CONCENTRATION, 4000)).

Builder Policy: Componente offchain crítico. Los block builders implementan una política que identifica transacciones enviadas a la dirección Global Storage. La política reserva el primer 5-10% del gas de cada bloque para estas transacciones, ordenándolas por priority fee y evitando el spam.

Es clave que la transacción tenga “to” hacia Global Storage; no deben permitirse transacciones que llamen otras funciones de swap para estar al inicio del bloque.

• Ejemplo de algoritmo personalizado de construcción de bloques con rblib:

• Integración Prop AMM: El smart contract Prop AMM lee los datos de la curva de precios desde Global Storage en el momento del swap, al determinar la cotización para el usuario.

Esta arquitectura resuelve ambos problemas:

• Protección: La política del builder crea un “carril rápido” que garantiza que todas las actualizaciones de precios se ejecuten antes que los swaps, eliminando el riesgo de front-running en el mismo bloque.
• Eficiencia de costos: Los market makers solo compiten entre sí para acceder al inicio del bloque, no contra todos los usuarios DeFi. Esto reduce drásticamente el costo de la ejecución prioritaria.

El swap del usuario se ejecuta contra la curva de precios actualizada al inicio del bloque, asegurando cotizaciones frescas y protegidas. Este modelo recrea el entorno de actualizaciones económicas y prioritarias que ha permitido el éxito de los Prop AMMs en Solana, abriendo una nueva etapa de eficiencia de mercado sobre EVM.

Sin embargo, existen desventajas que quedan abiertas para debate al final del artículo.

Conclusión

La viabilidad de los Prop AMMs depende de resolver el problema económico fundamental: ejecución prioritaria y de bajo costo para evitar el front-running.

La arquitectura estándar de EVM lo hace costoso y arriesgado, pero un nuevo diseño plantea una solución diferente. Al combinar un smart contract de Global Storage onchain con una política de builder offchain, se crea un “carril rápido” para actualizaciones de precios. Este modelo garantiza ejecución al inicio de bloque para actualizaciones de oráculo y establece un mercado de tarifas local, abordando las barreras clave y posibilitando no solo Prop AMMs, sino una transformación para toda la DeFi EVM que dependa de actualizaciones de oráculo prioritarias.

Preguntas abiertas

• ¿Son los Prop AMMs en EVM con Flashblocks de 200ms suficientemente rápidos para competir con la arquitectura continua de Solana?
• En Solana, la mayor parte del flujo de órdenes de AMMs proviene de un agregador (Jupiter), que ofrece un SDK para conectar AMMs. En Layer 2 EVM, el flujo se divide entre varios agregadores sin SDK público. ¿Esto dificulta la adopción de Prop AMMs en EVM?
• ¿Cómo logran los Prop AMMs en Solana que sus actualizaciones solo consuman ~100 CU?
• El modelo de carril rápido solo pone actualizaciones Prop AMM al inicio del bloque. Si un Flashblock dura 200ms, puede haber varios swaps y el market maker podría querer actualizar precios entre ellos. ¿Cómo se implementaría?
• ¿Pueden Yul o Huff utilizarse para escribir programas EVM optimizados, como Pinocchio en Solana?
• ¿Cómo se comparan Prop AMMs y RFQs?
• ¿Cómo evitamos que el market maker muestre una cotización atractiva en el bloque N para atraer al usuario a enviar la transacción en el bloque N+1, donde la cotización se actualiza a una menos favorable? ¿Cómo lo previene Jupiter?
• Jupiter’s Ultra V3 introduce “Ultra Signaling”, permitiendo a los Prop AMMs distinguir entre flujo tóxico y no tóxico y ofrecer cotizaciones 3 bps más ajustadas. ¿Qué tan relevantes son estas funciones de agregador para llevar Prop AMMs a EVM?

P.D.: Actualmente busco espacios para conferencias sobre este tema. Si conoces eventos en Devconnect, me gustaría conversar sobre oportunidades para participar como ponente.

Aviso legal:

1. Este artículo se reproduce de [0xOptimus]. Todos los derechos de autor pertenecen al autor original [0xOptimus]. Si tienes objeciones a esta reproducción, contacta al equipo de Gate Learn para su gestión inmediata.
2. Descargo de responsabilidad: Las opiniones aquí expresadas son exclusivas del autor y no constituyen asesoramiento de inversión.
3. Las traducciones a otros idiomas son realizadas por el equipo de Gate Learn. Salvo indicación contraria, está prohibida la copia, distribución o plagio de los artículos traducidos.