Impuesto invisible en Solana

Escrito por: SpecialistXBT

Hace menos de un año, un artículo titulado «Payment for Order Flow on Solana» reveló una esquina oscura del mercado de tarifas en Solana, generando una atención fenomenal en Twitter en inglés.

PFOF (Pago por Flujo de Ordenes) es una modalidad comercial madura desde hace tiempo en las finanzas tradicionales. Robinhood fue pionero en esta estrategia, lanzando su «negocio de comisiones cero» y logrando destacar rápidamente entre los corredores tradicionales. Esta estrategia no solo hizo que Robinhood ganara sumas considerables, sino que también obligó a gigantes como Charles Schwab, E-Trade y otros a imitarla, cambiando el panorama de los corredores minoristas en EE. UU.

Solo en 2021, Robinhood generó cerca de 1,000 millones de dólares en ingresos por PFOF, representando la mitad de sus ingresos totales ese año; incluso en 2025, sus ingresos trimestrales por PFOF seguían alcanzando varios cientos de millones de dólares. Esto demuestra la enorme rentabilidad de este modelo de negocio.

En los mercados tradicionales, los creadores de mercado prefieren en extremo las órdenes minoristas. La razón es simple: las órdenes minoristas suelen considerarse «no tóxicas», basadas en emociones o necesidades inmediatas, sin predicciones precisas sobre futuros movimientos de precios. Los creadores de mercado aceptan estas órdenes, asegurando ganancias en el diferencial de compra y venta, sin preocuparse por enfrentarse a operadores informados (como grandes instituciones).

Basándose en esta demanda, los corredores (como Robinhood) empaquetan el flujo de órdenes de los usuarios y lo venden en masa a gigantes creadores de mercado como Citadel, recibiendo enormes comisiones de reembolso.

La regulación en los mercados financieros tradicionales protege en cierta medida a los minoristas: la SEC, mediante la Regulación del Sistema de Mercado Nacional, exige que incluso las órdenes empaquetadas se ejecuten a precios no peores que el mejor mercado.

Sin embargo, en el mundo en cadena, donde no hay regulación, las aplicaciones aprovechan la asimetría de información para inducir a los usuarios a pagar tarifas prioritarias y propinas mucho mayores que las necesidades reales en la cadena, y se quedan con esas primas de forma encubierta. Este comportamiento, en esencia, es un «impuesto invisible» de gran beneficio para quienes lo practican, a usuarios desprevenidos.

Monetización del tráfico

Para las aplicaciones que controlan grandes entradas de usuarios, las formas de monetizar el tráfico son mucho más variadas de lo que imaginas.

Las aplicaciones frontend y las wallets pueden decidir a dónde van sus transacciones, cómo se ejecutan y qué tan rápido se registran en la cadena. Cada «puerta» en el ciclo de vida de una transacción oculta un negocio para «exprimir» el valor del usuario.

Vender a los creadores de mercado el «acceso» a los usuarios

Al igual que Robinhood, las aplicaciones en Solana también pueden vender «derechos de acceso» a los creadores de mercado.

RFQ (Request For Quote, Solicitud de Cotización) es una manifestación directa de esta lógica. A diferencia de los AMM tradicionales, RFQ permite a los usuarios (o aplicaciones) solicitar cotizaciones y realizar transacciones directamente con creadores de mercado específicos. En Solana, agregadores como Jupiter ya integran este modelo (JupiterZ). En este sistema, las aplicaciones pueden cobrar tarifas de conexión a estos creadores de mercado o, de manera más directa, empaquetar y vender en masa el flujo de órdenes minoristas. Con la reducción constante de los diferenciales en la cadena, se espera que este tipo de «venta de leads» sea cada vez más común.

Además, los DEX y los agregadores están formando alianzas de interés. Los AMMs propios (Prop AMMs) y los DEX dependen en extremo del tráfico generado por los agregadores, que pueden cobrar a estos proveedores de liquidez y devolver parte de las ganancias en forma de «reembolsos» a las aplicaciones frontend.

Por ejemplo, cuando la wallet Phantom enruta las transacciones de los usuarios a Jupiter, los proveedores de liquidez subyacentes (como HumidiFi o Meteora) podrían pagar a Jupiter para obtener el derecho a ejecutar esas transacciones. Luego, Jupiter devuelve una parte de esa tarifa de canal a Phantom.

Aunque estas suposiciones aún no han sido confirmadas públicamente, el autor opina que, impulsados por intereses, estas «reglas no escritas» en la cadena de beneficios internos son casi inevitables.

Sangrado de órdenes de mercado

Cuando un usuario hace clic en «confirmar» y firma en la wallet, en esencia está enviando una orden de mercado con un parámetro de deslizamiento (slippage).

Para las aplicaciones, hay dos caminos para gestionar esta orden:

Camino benigno: vender las oportunidades de «Backrun» (arbitraje de seguimiento) a empresas de trading especializadas, compartiendo beneficios. El Backrun consiste en que, cuando un usuario realiza una compra en DEX1 que impulsa el precio del token en esa plataforma, un robot de arbitraje en la misma bloque ejecuta una compra en DEX2 en la misma cadena (sin afectar el precio en DEX1) y luego vende en DEX1.

Camino malicioso: ayudar a los atacantes de tipo «sandwich» a atacar a sus propios usuarios, inflando el precio de ejecución.

Incluso en el camino benigno, no significa que la aplicación tenga conciencia ética; para maximizar el valor del «arbitraje de seguimiento», puede tener incentivos para ralentizar deliberadamente la publicación de la transacción en la cadena. Impulsados por beneficios, también podrían dirigir intencionadamente a los usuarios a pools con menor liquidez, creando artificialmente mayor volatilidad y oportunidades de arbitraje.

Según informes, algunas aplicaciones frontend conocidas en Solana están realizando estas prácticas.

¿Quién se queda con tus propinas?

Si las técnicas anteriores aún requieren cierto nivel técnico, las manipulaciones en las «tarifas de transacción» son un espectáculo en sí mismas.

En Solana, las tarifas que paga el usuario en realidad se dividen en dos partes:

• Tarifa prioritaria: es la tarifa dentro del protocolo, que se paga directamente a los validadores.

• Propina de transacción: es una SOL transferida a cualquier dirección, generalmente a «Landing Service» como Jito. Estos servicios deciden cuánto devolver a los validadores y cuánto reembolsar (Rebate) a la aplicación.

¿Por qué se necesitan estos servicios? Porque en momentos de congestión, la comunicación en la red Solana se vuelve muy compleja y las transacciones broadcast pueden fallar fácilmente. Los Landing Services actúan como «canales VIP», optimizando las rutas y garantizando la inclusión de las transacciones.

El mercado complejo de constructores de bloques (Builder Market) y la fragmentación en las rutas generan este rol especial, creando un espacio para que las aplicaciones se lucren. Las aplicaciones suelen inducir a los usuarios a pagar altas propinas para «garantizar» la inclusión, y luego comparten esas primas con los Landing Services.

Mapa de flujo de transacciones y tarifas

Veamos unos datos. Entre el 1 y el 8 de diciembre de 2025, la red de Solana procesó 450 millones de transacciones.

De ellas, los Landing Services de Jito gestionaron 80 millones, dominando el mercado (93.5% de cuota de mercado de los constructores). La mayoría de estas transacciones fueron swaps, actualizaciones de oráculos y operaciones de creadores de mercado.

En este enorme volumen, los usuarios, en su afán de «ganar velocidad», suelen pagar tarifas elevadas. Pero, ¿realmente se usan para acelerar?

La respuesta es no del todo. Los datos muestran que las wallets con menor actividad (generalmente minoristas) pagan tarifas prioritarias exorbitantes. Considerando que los bloques no estaban llenos en ese momento, claramente estos usuarios estaban siendo sobrecargados (Overcharged).

Las aplicaciones, aprovechando el miedo a las «transacciones fallidas», inducen a los usuarios a pagar propinas muy altas, y mediante acuerdos con los Landing Services, se quedan con esas primas adicionales.

Caso típico: Axiom

Para ilustrar mejor este patrón de «saqueo», el autor realizó un análisis profundo de la principal aplicación en Solana, Axiom.

Axiom lidera en tarifas de transacción en toda la red, no solo por su volumen de usuarios, sino también por su estrategia de cobro agresiva.

Los datos muestran que la tarifa prioritaria media (p50) pagada por los usuarios de Axiom alcanza los 1,005,000 lamports. En comparación, las wallets de trading de alta frecuencia pagan solo entre 5,000 y 6,000 lamports. ¡Una diferencia de 200 veces!

En cuanto a las propinas, la situación es similar.

Los usuarios de Axiom pagan propinas mucho más altas en servicios como Nozomi y Zero Slot que el promedio del mercado. La aplicación aprovecha la extrema sensibilidad de los usuarios a la velocidad, y sin ningún feedback negativo, realiza una doble carga a los usuarios.

El autor afirma sin rodeos: «La mayor parte de las tarifas de transacción pagadas por los usuarios de Axiom terminan en los bolsillos del equipo de Axiom.»

Recuperar el control del precio de las tarifas

La grave disfunción entre incentivos de usuarios y aplicaciones es la raíz del caos actual. Los usuarios no saben qué tarifas son razonables, y las aplicaciones prefieren mantener esta confusión.

Para cambiar esta situación, hay que comenzar desde la estructura del mercado en sus cimientos. Se prevé que, antes de 2026, la introducción de propuestas de múltiples concurrentes (MCP) y mecanismos de orden prioritario (Priority Ordering), junto con la propuesta ampliamente discutida de tarifas base dinámicas, sean la solución definitiva.

Propuestas de múltiples concurrentes (MCP)

El modelo actual de un solo proponente en Solana puede generar monopolios temporales: las aplicaciones solo necesitan gestionar al líder actual para controlar la agrupación de transacciones. La introducción de MCP, con múltiples proponentes en cada ranura (Slot), aumenta los costos de ataque y monopolización, fortaleciendo la resistencia a la censura y dificultando que las aplicaciones controlen un nodo único para bloquear a los usuarios.

Mecanismo de orden prioritario (Priority Ordering)

Al forzar en el protocolo que las transacciones se ordenen según la tarifa prioritaria (sin jitter), se elimina la aleatoriedad en el orden. Esto reduce la dependencia de canales privados como Jito para acelerar transacciones, y permite que los validadores prioricen las transacciones en función de reglas deterministas, sin que los usuarios tengan que adivinar cuánto propina pagar.

Tarifa base dinámica (Dynamic Base Fee)

Este es el paso más importante. Solana está intentando implementar un concepto similar a la tarifa base dinámica de Ethereum.

Los usuarios ya no darán propinas a ciegas, sino que emitirán instrucciones claras al protocolo: «Estoy dispuesto a pagar un máximo de X lamports para que esta transacción se registre en la cadena.»

El protocolo ajustará automáticamente el precio según la congestión actual. Si no hay congestión, cobrará tarifas bajas; si hay congestión, tarifas altas. Este mecanismo recupera la autoridad en la fijación de tarifas del control de las aplicaciones y los intermediarios, devolviéndola a un algoritmo transparente del protocolo.

Meme trajo prosperidad a Solana, pero también dejó raíces de inmediatez y búsqueda de lucro. Para que Solana realice verdaderamente la visión de ICM, no puede permitir que las aplicaciones que controlan el tráfico frontend y los protocolos que gestionan la infraestructura actúen en connivencia y a su antojo.

Como dice el refrán, «limpiar la casa antes de invitar a los invitados»: solo mediante la actualización de la arquitectura técnica, eliminando las bases para la búsqueda de rentas, y desarrollando un mercado justo, transparente y que priorice el bienestar del usuario, Solana podrá tener la confianza para integrarse y competir con el sistema financiero tradicional.