Antes do Ano Novo, um artigo intitulado "Pagamento por Fluxo de Ordens em Solana" revelou um canto sombrio do mercado de taxas de Solana, gerando uma atenção fenomenal no Twitter em inglês.
O PFOF (Payment for Order Flow, ou pagamento pelo fluxo de encomendas) já é há muito uma estratégia comercial madura no setor financeiro tradicional. Foi precisamente através deste modelo que a Robinhood lançou o seu "comércio sem comissões", um verdadeiro trunfo que lhe permitiu rapidamente destacar-se entre muitas corretoras tradicionais. Esta estratégia não só rendeu à Robinhood grandes lucros, como também obrigou gigantes do setor, como a Charles Schwab e a E-Trade, a imitarem a estratégia, alterando assim o panorama do mercado de corretagem retalhista nos Estados Unidos.
Apenas em 2021, a Robinhood arrecadou perto de 1.000 milhões de dólares em receita através do PFOF (Payment for Order Flow), representando metade da sua receita total anual. Mesmo em 2025, a receita trimestral proveniente do PFOF mantinha-se elevada, na ordem dos centos de milhões de dólares. Isso demonstra claramente o elevado lucro gerado por este modelo de negócios.
Nos mercados tradicionais, os market makers (fazedores de mercado) preferem extremamente as ordens dos investidores individuais. A razão é simples: normalmente, as ordens dos investidores individuais são consideradas "inofensivas", pois tendem a ser baseadas em emoções ou necessidades imediatas, não contendo previsões precisas sobre futuras variações de preços. Ao absorver estas ordens, os market makers conseguem lucrar com a diferença entre os preços de compra e venda, sem terem de se preocupar em ficarem do lado oposto de investidores informados (como grandes instituições).
Com base nessa demanda, corretoras (como a Robinhood) agrupam os pedidos dos usuários e os vendem em lote a grandes market makers, como a Citadel, recebendo assim generosas comissões.
A regulação dos mercados financeiros tradicionais protege, em certa medida, os investidores individuais. O regulamento do sistema nacional de mercados da Comissão de Valores Mobiliários (SEC) exige que, mesmo os pedidos agrupados, obtenham uma execução que não seja pior do que o melhor preço disponível no mercado.
No entanto, no mundo descentralizado sem regulação, as aplicações estão a aproveitar-se da assimetria de informação para induzir os utilizadores a pagarem taxas e gorjetas muito superiores às necessárias para a inclusão nas cadeias, retenção silenciosa desses prémios. Este comportamento, essencialmente, é uma "imposto oculto" altamente lucrativo cobrado a utilizadores desprevenidos.
Monetização de tráfego
Para aplicações que possuem um grande número de entradas de usuários, as formas de monetização do tráfego são muito mais variadas do que você imagina.
Aplicações front-end e carteiras podem decidir para onde as transações dos utilizadores vão, como são concluídas e até que velocidade são incluídas na cadeia. Cada "etapa" no ciclo de vida de uma transação esconde oportunidades de negócio para "explorar ao máximo" o valor dos utilizadores.
Vender utilizadores aos market makers
Assim como o Robinhood, as aplicações na Solana também podem vender «acesso» aos market makers.
A RFQ (Solicitação de Cotação) é uma expressão direta dessa lógica. Ao contrário dos AMM tradicionais, a RFQ permite que os utilizadores (ou aplicações) solicitem diretamente cotações e concluam negócios com market makers específicos. Na Solana, agregadores como o Jupiter já integraram este modelo (JupiterZ). Neste sistema, o lado da aplicação pode cobrar taxas de ligação a estes market makers, ou, de forma mais direta, vender fluxos de ordens de retalho em lote. À medida que as diferenças de preços na cadeia continuam a diminuir, os autores prevêem que este tipo de "negócio de vender ordens" tornar-se-á cada vez mais comum.
Além disso, está a formar-se uma certa aliança de interesses entre DEXs e agregadores. Os AMMs (market makers autónomos) e as DEXs dependem fortemente do tráfego trazido pelos agregadores, enquanto estes têm plena capacidade para cobrar taxas a estes fornecedores de liquidez e devolver parte do lucro sob a forma de "reembolsos" às aplicações front-end.
Por exemplo, quando o carteiro Phantom roteia uma transação do utilizador para o Jupiter, os fornecedores de liquidez subjacentes (tais como HumidiFi ou Meteora) podem pagar ao Jupiter para executar esta transação. Após receber esta "taxa de passagem", o Jupiter devolve uma parte a Phantom.
Embora esta conjectura ainda não tenha sido publicamente comprovada, o autor acredita que, impulsionada por interesses, esta "regra tácita de divisão de lucros" dentro da cadeia produtiva é quase um fenómeno natural.
Stop de sangue
Quando o utilizador clica em "Confirmar" na carteira e assina, essa transação é essencialmente uma "ordem de mercado" (Market Order) com um parâmetro de deslizamento (slippage).
Para a aplicação, existem duas formas de processar este pedido:
Caminho benigno: Vender as oportunidades de "Backrun" (arbitragem de seguimento) geradas pelas transações a empresas de transações profissionais, partilhando os lucros. O que é um "Backrun"? Trata-se de uma situação em que, após um utilizador comprar num DEX1 e elevar o preço do token no DEX1, um robô de arbitragem compra imediatamente no mesmo bloco num DEX2 (sem afetar o preço da compra do utilizador no DEX1) e depois vende no DEX1.
Estratégia maliciosa: Ajudar o "sanduicheur" (arbitragem de sanduíche) a atacar os próprios utilizadores, aumentando o preço de transação dos utilizadores.
Mesmo seguindo uma rota aparentemente legítima, isso não significa que a aplicação (frontend) seja honesta. Para maximizar o valor do "arbitragem de cauda", a aplicação pode ter incentivos para deliberadamente atrasar a velocidade com que as transações são adicionadas à blockchain. Movida pelo lucro, a aplicação também pode intencionalmente encaminhar os utilizadores para piscinas com menor liquidez, criando artificialmente maiores oscilações de preços e oportunidades de arbitragem.
Alguns aplicativos front-end conhecidos na Solana estão a realizar a operação mencionada acima, segundo relatos.
Quem levou a sua gorjeta?
Se os meios acima mencionados ainda envolvem alguma barreira técnica, então as manipulações nas "taxas de transação" já não se dão nem a farsa de representar algo.
Na Solana, as taxas pagas pelos utilizadores dividem-se, de facto, em duas partes:
- Taxa de prioridade: esta é uma taxa incluída no protocolo, paga diretamente aos validadores.
- Gorjeta de transação: trata-se de uma quantia de SOL transferida para qualquer endereço, normalmente paga a fornecedores de serviços de "landing", como a Jito. O fornecedor de serviços decide então quanto repartir com os validadores e quanto devolver (Rebate) ao lado da aplicação.
Por que é necessário um provedor local? Devido à complexidade extrema da comunicação na rede Solana durante congestionamentos, transações comuns de difusão falham facilmente. Provedores locais desempenham o papel de "canal VIP", comprometendo-se a incluir com sucesso as transações na cadeia, através de ligações otimizadas especificamente para esse fim.
O mercado complexo de construtores de blocos (Builder Market) e o sistema fragmentado de encaminhamento da Solana deram origem a este papel especial, criando também um excelente espaço para práticas de arrecadação de vantagens (rent-seeking) por parte das aplicações. Frequentemente, as aplicações incentivam os utilizadores a pagarem gorjetas elevadas para "garantir a passagem", depois dividem esse valor acrescentado com os provedores de serviços finais.
Mapa de Tráfego e Custos de Transações
Vamos analisar um conjunto de dados. Na semana de 1.º a 8.º de Dezembro de 2025, a rede Solana registou 450 milhões de transações.
Entre eles, os serviços de implementação do Jito processaram 80 milhões de transações, dominando o mercado (93,5% de participação de mercado dos construtores). Dessas transações, a maioria é composta por swaps relacionados a transações, atualizações de oráculos e operações de market makers.
Neste grande grupo de tráfego, os utilizadores, na tentativa de "acelerar", frequentemente pagam altas taxas. Mas será que todo esse dinheiro realmente é utilizado para acelerar?
Não necessariamente. Os dados mostram que carteiras com baixa atividade (geralmente de pequenos investidores) pagam taxas de prioridade absurdamente elevadas. Tendo em conta que os blocos na altura não estavam cheios, é evidente que estes utilizadores foram cobrados excessivamente.
A aplicação aproveita-se do medo dos utilizadores perante uma "transação falhada", induzindo-os a definirem gorjetas muito elevadas, que depois retém, mediante acordo com os fornecedores no local.
Exemplo Contrário Axioma
Para ilustrar mais claramente este "modo de colheita", o autor realizou um estudo de caso aprofundado sobre a principal aplicação na Solana, o Axiom.
As taxas de transação geradas pelo Axiom são as mais altas da rede, não apenas porque tem muitos utilizadores, mas também porque são as mais abusivas.
Os dados mostram que a mediana (p50) das taxas prioritárias pagas pelos utilizadores do Axiom atinge 1.005.000 lamports. Para comparação, carteiras de negociação de alta frequência pagam apenas cerca de 5.000 a 6.000 lamports. Há uma diferença de 200 vezes entre estes valores.
O mesmo se aplica às gorjetas.
Os utilizadores da Axiom pagam gorjetas muito superiores à média de mercado nos serviços implementados, como Nozomi, Zero Slot, entre outros. A aplicação aproveitou exatamente a extrema sensibilidade dos utilizadores em relação à "velocidade", cobrando os utilizadores duas vezes sem qualquer feedback negativo.
O autor afirma claramente: "A maior parte das taxas de transação pagas pelos utilizadores do Axiom acaba por voltar para os bolsos da equipa do Axiom."
Recuperar o direito de fixação de preços
A grave desalinhamento entre a motivação dos utilizadores e a motivação das aplicações é a raiz dos problemas actuais. Os utilizadores não sabem quais são os custos razoáveis, enquanto as aplicações preferem manter este estado de confusão.
Para quebrar esse impasse, precisamos abordar a estrutura fundamental do mercado. A introdução, prevista para cerca de 2026, de propostas concorrentes múltiplas (MCP) e mecanismos de priorização (Priority Ordering) no Solana, juntamente com o amplamente proposto mecanismo de taxas base dinâmicas, pode ser a solução ideal para resolver o problema.
Múltiplos Propostores Concorrentes
O atual modelo de proposta única da Solana é suscetível a monopolização temporária, permitindo que a aplicação, ao manipular o líder atual, obtenha o direito de incluir transações num curto período de tempo. Com a introdução do MCP, cada intervalo (slot) contém múltiplos proponentes a trabalhar em simultâneo, aumentando significativamente o custo de ataques e monopolização, melhorando a resistência à censura e dificultando que as aplicações controlem um único nó para bloquear utilizadores.
Mecanismo de Prioridade (Priority Ordering)
Ao impor, a nível do protocolo, a ordenação "por prioridade de taxa", elimina-se a aleatoriedade (Jitter) na ordenação. Isso enfraquece a necessidade dos utilizadores de dependerem de canais acelerados privados, como o Jito, apenas para "garantir a passagem". Para transações normais, os utilizadores já não precisam de adivinhar quanto gorjeta devem pagar; basta pagarem dentro do protocolo, e todos os validadores da rede tratarão as transações com base em regras determinísticas de prioridade.
Taxa Básica Dinâmica (Dynamic Base Fee)
Este é o passo mais crucial. A Solana está tentando introduzir um conceito semelhante à taxa base dinâmica (Dynamic Base Fee) do Ethereum.
O utilizador não está mais a dar gorjetas de forma cega, mas sim a emitir instruções claras ao protocolo: "Estou disposto a pagar uma taxa máxima de X Lamports para esta transação ser adicionada à cadeia."
O protocolo define automaticamente os preços com base no nível atual de congestionamento. Quando não há congestionamento, cobra-se apenas um preço baixo; quando há congestionamento, é cobrado um preço mais elevado. Esse mecanismo transfere a definição dos custos das aplicações e intermediários para um algoritmo transparente do protocolo.
Os memes trouxeram prosperidade à Solana, mas também deixaram sequelas, deixando uma genética superficial e movida pelo lucro. Para que a Solana realize verdadeiramente a visão do ICM, não pode permitir que aplicações que dominam o tráfego inicial e protocolos que dominam a infraestrutura colaborem de forma descontrolada e actuando livremente.
Como diz o provérbio, "limpe a casa antes de convidar convidados". Apenas através da actualização da arquitectura técnica subjacente, usando meios técnicos para erradicar os meios de corrupção e desenvolvendo uma estrutura de mercado justa, transparente e centrada no bem-estar dos utilizadores, a Solana poderá verdadeiramente ter a confiança necessária para se integrar e competir com o sistema financeiro tradicional.