A principios de año, un artículo titulado "Payment for Order Flow on Solana" expuso una faceta sombría del mercado de tarifas de Solana, generando una atención fenomenal en Twitter en inglés.
El PFOF (Pago por Flujo de Órdenes) ya es un modelo de negocio establecido en las finanzas tradicionales. Robinhood utilizó precisamente este modelo para lanzar su as bajo la manga de "comisiones cero en operaciones", permitiéndole destacar rápidamente entre numerosos corredores establecidos. Esta estrategia no solo hizo que Robinhood obtuviera ganancias enormes, sino que también obligó a gigantes de la industria como Charles Schwab y E-Trade a seguir su ejemplo, cambiando el panorama de los servicios de corretaje minorista en Estados Unidos.
Solo en 2021, Robinhood obtuvo casi 1000 millones de dólares en ingresos a través del PFOF, representando aproximadamente la mitad de sus ingresos totales anuales; incluso para 2025, sus ingresos trimestrales por PFOF seguían siendo de cientos de millones de dólares. Esto demuestra la rentabilidad detrás de este modelo de negocio.
En los mercados tradicionales, los creadores de mercado tienen una marcada preferencia por las órdenes de los minoristas. La razón es simple: las órdenes minoristas generalmente se consideran "no tóxicas", ya que suelen basarse en emociones o necesidades inmediatas y no contienen predicciones precisas sobre movimientos futuros de precios. Los creadores de mercado pueden aceptar estas órdenes, asegurando ganancias por el diferencial de compra y venta, sin preocuparse por ser la contraparte de operadores informados (como grandes instituciones).
Basándose en esta demanda, los corredores (como Robinhood) empaquetan el flujo de órdenes de sus usuarios y lo venden al por mayor a gigantes creadores de mercado como Citadel, obteniendo así enormes comisiones.
La regulación en los mercados financieros tradicionales protege en cierta medida a los minoristas. El Reglamento de Sistemas Nacionales de Mercado de la SEC exige que, incluso las órdenes vendidas empaquetadas, deben ejecutarse a un precio no inferior al mejor precio disponible en el mercado.
Sin embargo, en el mundo descentralizado y sin regulación de las cadenas de bloques, las aplicaciones están aprovechando la asimetría de información para inducir a los usuarios a pagar tarifas prioritarias y propinas que exceden con creces lo necesario para la inclusión real en la cadena, y se quedan silenciosamente con estas primas. Este comportamiento es, en esencia, un impuesto oculto y muy lucrativo aplicado a usuarios desprevenidos.
Monetización del tráfico
Para aquellas aplicaciones que controlan grandes puntos de entrada de usuarios, los medios para monetizar el tráfico son mucho más numerosos de lo que imaginas.
Las aplicaciones frontales y las billeteras pueden decidir a dónde van las transacciones de los usuarios, de qué manera se ejecutan e incluso la rapidez con la que se incluyen en la cadena. Cada "punto de control" en el ciclo de vida de una transacción alberga trucos comerciales para exprimir hasta la última gota de valor del usuario.
"Vender" usuarios a los creadores de mercado
Al igual que Robinhood, las aplicaciones en Solana pueden vender "acceso" a los creadores de mercado.
La RFQ (Solicitud de Cotización) es la manifestación directa de esta lógica. A diferencia de los AMM tradicionales, la RFQ permite a los usuarios (o aplicaciones) solicitar cotizaciones y realizar operaciones directamente con creadores de mercado específicos. En Solana, agregadores como Jupiter ya han integrado este modo (JupiterZ). En este sistema, el lado de la aplicación puede cobrar tarifas de conexión a estos creadores de mercado o, más directamente, empaquetar y vender flujos de órdenes minoristas al por mayor. A medida que los diferenciales de precios on-chain se estrechan, el autor anticipa que este negocio de "vender cabezas" se volverá cada vez más común.
Además, se está formando una especie de alianza de intereses entre los DEX y los agregadores. Los Prop AMMs (creadores de mercado de propietario) y los DEX dependen en gran medida del tráfico que traen los agregadores, y estos últimos tienen plena capacidad para cobrar a estos proveedores de liquidez y devolver parte de las ganancias a las aplicaciones frontales en forma de "comisiones de retroceso".
Por ejemplo, cuando la billetera Phantom enruta una transacción de usuario a Jupiter, el proveedor de liquidez subyacente (como HumidiFi o Meteora) podría pagar a Jupiter para asegurar el derecho a ejecutar esa transacción. Jupiter, al recibir esta "tarifa de canal", luego devuelve una parte a Phantom.
Aunque esta conjetura aún no ha sido confirmada públicamente, el autor cree que, impulsada por los beneficios, esta "regla no escrita de distribución de ganancias" dentro de la cadena industrial es un fenómeno casi natural.
Órdenes de mercado que chupan sangre
Cuando un usuario hace clic en "Confirmar" en su billetera y firma, esa transacción es esencialmente una "orden de mercado" (Market Order) con un parámetro de deslizamiento.
Para el lado de la aplicación, existen dos caminos para procesar esta orden:
Ruta benigna: Vender la oportunidad de "Backrun" (arbitraje de seguimiento) generada por la transacción a empresas comerciales profesionales y repartir las ganancias. El Backrun se refiere a cuando la orden de compra de un usuario en DEX1 empuja hacia arriba el precio del token en DEX1, y luego un bot de arbitraje, dentro del mismo bloque, compra en DEX2 (sin afectar el precio de compra del usuario en DEX1) y vende en DEX1.
Ruta maligna: Ayudar a los atacantes sándwich (arbitrajistas sándwich) a atacar a sus propios usuarios, inflando artificialmente el precio de ejecución del usuario.
Incluso tomar la ruta benigna no significa que el lado de la aplicación tenga conciencia. Para maximizar el valor del "arbitraje de seguimiento", el lado de la aplicación tiene incentivos para ralentizar deliberadamente la velocidad de inclusión de la transacción en la cadena. Impulsados por las ganancias, también podrían enrutar intencionalmente a los usuarios hacia grupos de liquidez menos profundos, creando artificialmente una mayor volatilidad de precios y espacio de arbitraje.
Según informes, algunas conocidas aplicaciones frontales en Solana están realizando las operaciones mencionadas anteriormente.
¿Quién se queda con tu propina?
Si los métodos anteriores tenían cierta barrera técnica, la manipulación opaca en las "tarifas de transacción" raya en lo descarado.
En Solana, las tarifas pagadas por el usuario se dividen en realidad en dos partes:
- Tarifa prioritaria: Es una tarifa dentro del protocolo, pagada directamente a los validadores.
- Propina de transacción: Es una transferencia de SOL a una dirección arbitraria, generalmente pagada a "proveedores de servicios de aterrizaje" (Landing Service) como Jito. El proveedor de servicio luego decide cuánto dar a los validadores y cuánto devolver (Rebate) al lado de la aplicación.
¿Por qué se necesitan proveedores de servicios de aterrizaje? Debido a que la red Solana, durante la congestión, tiene una comunicación extremadamente compleja, y la difusión ordinaria de transacciones puede fallar fácilmente. Los proveedores de servicios de aterrizaje actúan como "canales VIP", ofreciendo a los usuarios la promesa de una inclusión exitosa en la cadena a través de enlaces optimizados especializados.
El complejo mercado de constructores de bloques (Builder Market) de Solana y su sistema de enrutamiento fragmentado han dado lugar a este papel especial, creando también un espacio perfecto para la búsqueda de rentas por parte de las aplicaciones. El lado de la aplicación a menudo induce a los usuarios a pagar propinas elevadas para "garantizar" la transacción, y luego se reparte esta prima con el proveedor de servicios de aterrizaje.
Panorama del flujo de transacciones y las tarifas
Veamos algunos datos. En la semana del 1 al 8 de diciembre de 2025, la red Solana generó 450 millones de transacciones.
De estas, el servicio de aterrizaje de Jito procesó 80 millones de transacciones, dominando abrumadoramente el mercado (93.5% de cuota de mercado de constructores). Y dentro de estas transacciones, la gran mayoría estaban relacionadas con operaciones de Swap, actualizaciones de oráculos y operaciones de creadores de mercado.
En este enorme volumen de tráfico, los usuarios, en su afán por "rapidez", a menudo pagan tarifas elevadas. Pero, ¿realmente todo ese dinero se utiliza para acelerar?
No exactamente. Los datos indican que las billeteras con baja actividad (generalmente minoristas) pagaron tarifas prioritarias desproporcionadamente altas. Considerando que los bloques no estaban llenos en ese momento, está claro que estos usuarios fueron sobrecargados (Overcharged).
El lado de la aplicación aprovecha el miedo de los usuarios al "fracaso de la transacción" para inducirlos a establecer propinas extremadamente altas, y luego, a través de acuerdos con los proveedores de servicios de aterrizaje, se queda con esta prima.
Caso paradigmático negativo: Axiom
Para mostrar de manera más直观esta modalidad de "extracción", el autor realizó un estudio de caso en profundidad de la principal aplicación en Solana, Axiom.
Axiom genera las tarifas de transacción más altas de toda la red, no solo porque tiene muchos usuarios, sino porque también es la que más "cobra" a sus clientes.
Los datos muestran que la tarifa prioritaria mediana (p50) pagada por los usuarios de Axiom alcanza la enorme cifra de 1,005,000 lamports. En contraste, las billeteras de trading de alta frecuencia pagan solo alrededor de 5,000 a 6,000 lamports. Hay una diferencia de 200 veces.
En lo que respecta a las Propinas (Tips), la situación es similar.
Las propinas pagadas por los usuarios de Axiom en servicios de aterrizaje como Nozomi y Zero Slot superan con creces el promedio del mercado. El lado de la aplicación aprovecha la extrema sensibilidad de los usuarios a la "velocidad" y, sin ninguna retroalimentación negativa, completa la doble facturación al usuario.
El autor especula sin rodeos: "La gran mayoría de las tarifas de transacción pagadas por los usuarios de Axiom, terminan finalmente en los bolsillos del equipo de Axiom."
Recuperar el poder de fijación de precios de las tarifas
El grave desajuste entre los incentivos del usuario y los incentivos de la aplicación es la raíz del caos actual. Los usuarios no saben qué es una tarifa razonable, y el lado de la aplicación está feliz de mantener esta confusión.
Para romper esta situación, necesitamos comenzar con la estructura de mercado subyacente. Se anticipa que la introducción en Solana, alrededor de 2026, del Múltiple Proponente Concurrente (MCP) y el Mecanismo de Priorización de Órdenes (Priority Ordering), así como el ampliamente propuesto mecanismo de tarifa base dinámica, podrían ser la solución definitiva al problema.
Múltiple Proponente Concurrente (Multiple Concurrent Proposers - MCP)
El modo actual de proponente único de Solana es propenso a formar monopolios temporales, donde el lado de la aplicación solo necesita "arreglárselas" con el Líder actual para controlar temporalmente el derecho a empaquetar transacciones. Con la introducción del MCP, múltiples proponentes trabajan concurrentemente en cada ranura (Slot), aumentando significativamente el costo de los ataques y monopolios, mejorando la resistencia a la censura y dificultando que el lado de la aplicación acorrale a los usuarios controlando un solo nodo.
Mecanismo de Priorización de Órdenes (Priority Ordering)
Al imponer a nivel de protocolo la regla de "ordenar según el monto de la tarifa prioritaria", se elimina la aleatoriedad (Jitter) en el ordenamiento. Esto debilita la necesidad de los usuarios de depender forzosamente de canales de aceleración privados como Jito solo para "garantizar" la transacción. Para transacciones ordinarias, los usuarios ya no necesitan adivinar cuánta propina dar; siempre que paguen dentro del protocolo, todos los validadores de la red procesarán prioritariamente basándose en reglas deterministas.
Tarifa Base Dinámica (Dynamic Base Fee)
Este es el paso más crucial. Solana está intentando introducir un concepto similar a la Tarifa Base Dinámica (Dynamic Base Fee) de Ethereum.
Los usuarios ya no dan propinas a ciegas, sino que instruyen explícitamente al protocolo: "Estoy dispuesto a pagar un máximo de X Lamports por la inclusión de esta transacción en la cadena."
El protocolo establece el precio automáticamente según el nivel actual de congestión. Si no hay congestión, cobra un precio bajo; si hay congestión, cobra un precio alto. Este mecanismo devuelve el poder de fijación de precios de las tarifas, quitándoselo a las aplicaciones e intermediarios, y entregándoselo a algoritmos de protocolo transparentes.
Los Memes trajeron prosperidad a Solana, pero también dejaron una enfermedad de base, un gen浮躁 de búsqueda de ganancias. Si Solana quiere realizar verdaderamente la visión de ICM (Internet Computer Machine), no puede permitir que las aplicaciones que controlan el flujo frontal y los protocolos que controlan la infraestructura actúen en connivencia y hagan lo que quieran.
Como dice el refrán, "hay que barrer la casa antes de recibir invitados". Solo mediante actualizaciones en la arquitectura técnica subyacente, utilizando medios técnicos para erradicar el terreno fértil para la búsqueda de rentas, y desarrollando una estructura de mercado justa, transparente y que anteponga el bienestar del usuario, Solana podrá tener realmente la base para integrarse y competir con el sistema financiero tradicional.
