O “Imposto Invisível” na Solana

Há alguns anos, o artigo “Payment for Order Flow on Solana” revelou um lado obscuro do mercado de taxas da Solana, desencadeando um intenso debate na comunidade cripto anglófona no Twitter.

Payment for Order Flow (PFOF) é um modelo consolidado nas finanças tradicionais. A Robinhood destacou-se ao recorrer ao PFOF para lançar a “negociação sem comissão”, ultrapassando rapidamente as corretoras convencionais. Esta estratégia gerou lucros expressivos para a Robinhood e obrigou líderes como Charles Schwab e E-Trade a seguirem o mesmo caminho, transformando de forma profunda o mercado de corretagem de retalho nos Estados Unidos.

Em 2021, só a Robinhood obteve quase 1 bilião $ em receitas de PFOF, cerca de metade do seu rendimento anual. Mesmo em 2025, as receitas trimestrais de PFOF da Robinhood continuaram a atingir centenas de milhões $, comprovando a extraordinária rentabilidade deste modelo de negócio.

Os market makers nas finanças tradicionais preferem fortemente o fluxo de ordens de retalho. Isto porque as ordens de retalho são consideradas “não tóxicas” — são normalmente motivadas por emoções ou necessidades imediatas e não refletem previsões informadas sobre movimentos futuros de preços. Ao absorver estas ordens, os market makers conseguem capturar o spread bid-ask de forma consistente, sem o risco de negociar contra participantes institucionais informados.

Para capitalizar esta dinâmica, corretoras como a Robinhood agrupam o fluxo de ordens de retalho e vendem-no em larga escala a gigantes do market making como a Citadel, recolhendo generosos rebates no processo.

A regulação financeira tradicional oferece alguma proteção aos investidores de retalho. O Regulation NMS da SEC obriga a que mesmo ordens agrupadas sejam executadas a preços não inferiores ao melhor preço de mercado disponível.

Por contraste, o ambiente on-chain não regulado permite que aplicações explorem assimetrias de informação. Incentivam os utilizadores a pagar taxas de prioridade e gorjetas muito acima das necessidades reais da rede, ficando silenciosamente com o excedente. Na prática, esta conduta impõe um “imposto invisível” elevado aos utilizadores desinformados.

Monetização do Fluxo de Utilizadores

Nas aplicações que controlam os pontos de acesso dos utilizadores, as estratégias de monetização são bastante mais sofisticadas do que a maioria imagina.

As aplicações front-end e as wallets determinam para onde são enviadas as transações dos utilizadores, como são executadas e até a rapidez com que chegam à blockchain. Cada fase do ciclo de vida de uma transação representa uma oportunidade de extrair valor do utilizador.

Venda de Acesso de Utilizadores a Market Makers

Tal como a Robinhood, as aplicações Solana podem vender “direitos de acesso” a market makers.

O modelo Request for Quote (RFQ) é exemplo desta abordagem. Ao contrário dos AMM tradicionais, o RFQ permite que utilizadores ou aplicações solicitem cotações e negoceiem diretamente com market makers específicos. Na Solana, agregadores como o Jupiter já implementaram este modelo (JupiterZ). Aqui, as aplicações podem cobrar aos market makers uma taxa de ligação ou, mais diretamente, agrupar e vender o fluxo de ordens de retalho. À medida que os spreads on-chain se estreitam, este modelo de “corretagem de utilizadores” tende a tornar-se ainda mais comum.

Além disso, estão a surgir alianças entre DEX e agregadores. AMM e DEX proprietários dependem fortemente do tráfego gerado por agregadores, enquanto estes têm poder para cobrar aos fornecedores de liquidez e repartir uma parte dos lucros com as aplicações front-end.

Por exemplo, quando a wallet Phantom encaminha uma negociação do utilizador para o Jupiter, fornecedores de liquidez como HumidiFi ou Meteora podem pagar ao Jupiter pelo direito de executar a negociação. O Jupiter, após recolher esta “taxa de canal”, partilha parte do valor com a Phantom.

Embora este arranjo não seja oficialmente confirmado, o autor considera que, perante os incentivos financeiros, práticas de partilha de receitas como esta são praticamente inevitáveis no setor.

Ordens de Mercado Predatórias

Quando um utilizador clica em “Confirmar” e assina uma transação na wallet, está a criar uma ordem de mercado com um parâmetro de slippage.

As aplicações têm duas opções principais para tratar estas ordens:

Construtiva: Vender a oportunidade de “backrun” (arbitragem sequencial) a empresas de trading profissionais e dividir os lucros. O backrun acontece quando a ordem de compra de um utilizador na DEX1 faz subir o preço do token, e um bot de arbitragem compra imediatamente na DEX2 no mesmo bloco (sem afetar o preço de execução do utilizador na DEX1), vendendo depois na DEX1.

Exploratória: Colaborar com atacantes sandwich para visar os próprios utilizadores, inflacionando artificialmente os preços de execução.

Mesmo na via construtiva, as aplicações podem não agir no melhor interesse dos utilizadores. Para maximizar o valor do backrun, podem atrasar propositadamente o envio das transações. Motivadas pelo lucro, podem também encaminhar utilizadores para pools de baixa liquidez, gerando oscilações de preço maiores e mais oportunidades de arbitragem.

Há relatos de que algumas aplicações front-end de destaque na Solana recorrem a estas práticas.

Quem Fica com as Suas Gorjetas?

Enquanto as estratégias acima envolvem elevada complexidade técnica, a manipulação das “taxas de transação” é frequentemente flagrante.

Na Solana, as taxas dos utilizadores dividem-se em dois componentes:

• Taxa de Prioridade: Taxa ao nível do protocolo paga diretamente aos validadores.
• Gorjeta de Transação: Pagamento em SOL para qualquer endereço, normalmente um “landing service provider” como a Jito. Estes provedores decidem depois quanto partilhar com os validadores e quanto reembolsar à aplicação.

Porquê recorrer a landing service providers? Durante períodos de congestionamento da rede, as transmissões padrão de transações tendem a falhar. Os landing service providers funcionam como “canais VIP”, otimizando rotas e garantindo aos utilizadores a inclusão das transações.

O mercado complexo de builders da Solana e o sistema fragmentado de routing fomentaram este papel, criando oportunidades ideais de rent-seeking para as aplicações. Estas frequentemente incentivam os utilizadores a pagar gorjetas elevadas por “inclusão garantida”, partilhando depois o prémio com os landing service providers.

Fluxo de Transações e Panorama de Taxas

Analisando os dados: Entre 1 e 8 de dezembro de 2025, a Solana processou 450 milhões de transações em toda a rede.

O serviço de landing da Jito tratou 80 milhões destas, dominando com uma quota de mercado de builders de 93,5 %. A maioria envolvia swaps, atualizações de oráculos e operações de market making.

Neste ambiente de elevado volume, os utilizadores pagam frequentemente taxas elevadas na esperança de uma inclusão mais rápida das transações. Mas serão essas taxas realmente necessárias?

Nem sempre. Os dados mostram que wallets de baixa atividade — sobretudo utilizadores de retalho — pagam taxas de prioridade desproporcionadamente elevadas. Como os blocos não estavam cheios, estes utilizadores foram claramente sobrecarregados.

As aplicações exploram o receio dos utilizadores de falha na transação, incentivando-os a definir gorjetas excessivas. Através de acordos com landing service providers, captam este prémio.

Axiom: O Exemplo Negativo

Para ilustrar este modelo de “extração”, o autor realizou um estudo de caso sobre a Axiom, uma das principais aplicações da Solana.

A Axiom gerou as taxas de transação mais elevadas da rede, não apenas pela sua vasta base de utilizadores, mas também por práticas agressivas de cobrança de taxas.

Os dados mostram que os utilizadores da Axiom pagaram uma taxa de prioridade mediana (p50) de 1 005 000 lamports. Em comparação, wallets de trading de alta frequência pagaram apenas 5 000–6 000 lamports — uma diferença de 200 vezes.

O mesmo se aplica às gorjetas.

Os utilizadores da Axiom pagaram gorjetas em landing services como Nozomi e Zero Slot muito acima da média de mercado. A aplicação explorou a sensibilidade dos utilizadores à velocidade, cobrando-lhes em duplicado sem qualquer reação negativa.

O autor conclui sem rodeios: “A grande maioria das taxas de transação pagas pelos utilizadores da Axiom acaba, em última instância, nos bolsos da equipa da Axiom.”

Recuperar o Poder de Definição das Taxas

O desalinhamento profundo entre os incentivos dos utilizadores e das aplicações é a origem dos desafios atuais. Os utilizadores não sabem qual é uma taxa justa, e as aplicações têm todo o interesse em mantê-los na ignorância.

Para resolver este problema, é necessário reformar a estrutura de mercado subjacente. A introdução prevista de Multiple Concurrent Proposers (MCP), Priority Ordering e um mecanismo dinâmico de base fee na Solana — esperada para 2026 — poderá ser a solução.

Multiple Concurrent Proposers (MCP)

O modelo atual de proposer único da Solana é vulnerável a monopólios temporários, em que aplicações podem obter controlo influenciando o líder do momento. O MCP introduz múltiplos proposers a trabalhar em paralelo para cada slot, aumentando significativamente o custo de ataques e monopólios, reforçando a resistência à censura e dificultando que aplicações subjuguem utilizadores controlando um único nó.

Priority Ordering

Ao impor a ordenação ao nível do protocolo pela taxa de prioridade, elimina-se a aleatoriedade (jitter) na ordem das transações. Isto reduz a dependência dos utilizadores de canais privados de aceleração como o Jito para inclusão garantida. Para transações padrão, basta pagar ao protocolo para garantir que os validadores priorizam as transações de acordo com regras determinísticas.

Dynamic Base Fee

Esta é a reforma mais crítica. A Solana está a preparar um modelo dinâmico de base fee semelhante ao da Ethereum.

Os utilizadores deixam de dar gorjetas cegamente; instruem o protocolo: “Estou disposto a pagar até X lamports para que esta transação seja incluída.”

O protocolo define as taxas automaticamente com base no congestionamento em tempo real da rede. Se a rede não estiver congestionada, só é cobrada uma taxa baixa; se estiver, a taxa aumenta proporcionalmente. Este mecanismo transfere o poder de definição de preços das aplicações e intermediários para um algoritmo transparente do protocolo.

As memecoins impulsionaram o crescimento da Solana, mas também deixaram uma cultura de especulação e busca de lucro rápido. Para que a Solana concretize a sua visão de ICM, é fundamental evitar que aplicações que controlam o tráfego de utilizadores e protocolos que controlam a infraestrutura colaborem sem restrições.

Como diz o provérbio, “Limpa a casa antes de receber convidados.” Só ao atualizar a arquitetura técnica, eliminar o rent-seeking e construir uma estrutura de mercado justa e transparente centrada no utilizador poderá a Solana competir verdadeiramente e integrar-se no sistema financeiro tradicional.

Declaração:

1. Este artigo foi republicado de [BlockBeats], com direitos de autor pertencentes ao autor original [SpecialistXBT]. Para questões de republicação, contacte a equipa Gate Learn para resolução célere segundo os procedimentos aplicáveis.
2. Declaração de responsabilidade: As opiniões expressas pertencem exclusivamente ao autor e não constituem aconselhamento de investimento.
3. As versões noutras línguas são traduzidas pela equipa Gate Learn. Exceto referência a Gate, os artigos traduzidos não podem ser copiados, distribuídos ou plagiados.