«Скрытый налог» на Solana

Автор: SpecialistXBT

В преддверии Нового года статья под названием «Оплата за поток заказов на Solana» раскрыла одну из тёмных сторон рынка комиссий Solana, вызвав феноменальный отклик в англоязычном Твиттере.

PFOF (оплата за поток заказов) давно является зрелой бизнес-моделью в традиционных финансах. Robinhood именно благодаря этой модели запустил «беспроцентную торговлю» и быстро прорвался среди множества старых брокеров. Эта стратегия не только принесла Robinhood огромные прибыли, но и заставила гигантов отрасли, таких как Charles Schwab, E-Trade и другие, последовать примеру, изменив ландшафт розничной брокерской деятельности в США.

Только в 2021 году Robinhood заработал почти 1 миллиард долларов на PFOF, что составляло половину его общего дохода за год; даже к 2025 году доход от PFOF в одном квартале достигал нескольких сотен миллионов долларов. Очевидно, что за этой бизнес-моделью скрывается огромная прибыль.

На традиционном рынке маркет-мейкеры крайне предпочитают заказы розничных трейдеров. Причина проста: такие заказы обычно считаются «безопасными», так как они часто основаны на эмоциях или текущих потребностях, не включают точных прогнозов будущих ценовых движений. Обрабатывая эти заказы, маркет-мейкеры могут стабильно зарабатывать на спреде и не бояться противостояния с инсайдерскими трейдерами (например, крупными институциональными игроками).

Исходя из этого, брокеры (например, Robinhood) объединяют поток заказов пользователей и продают его крупным маркет-мейкерам, таким как Citadel, получая за это крупные комиссионные.

Регулирование традиционного рынка частично защищает розничных трейдеров: SEC в своих «Правилах регулирования национальной системы рынка» требует, чтобы даже упакованные заказы выполнялись по цене, не хуже рыночной.

Однако в мире блокчейна, где регулирование отсутствует, приложения используют информационную асимметрию, чтобы побуждать пользователей платить значительно больше, чем реально требуется для транзакции, и тихо присваивать эти излишки. По сути, такие действия — это скрытая «налоговая» схема, взимаемая с доверчивых пользователей.

Монетизация трафика

Для приложений, обладающих большим количеством пользовательских входов, способы монетизации трафика гораздо разнообразнее, чем кажется.

Фронтенд-приложения и кошельки могут управлять тем, куда идут транзакции пользователей, как они совершаются и даже с какой скоростью транслируются в блокчейн. Каждый «узел» в жизненном цикле транзакции скрывает возможность «выжать» максимальную ценность из пользователя.

Продажа пользовательских потоков маркет-мейкерам

Как и Robinhood, приложения на Solana могут продавать «право доступа» маркет-мейкерам.

RFQ (запрос котировок) — это прямой пример такой логики. В отличие от AMM, RFQ позволяет пользователям (или приложениям) напрямую запрашивать цену у конкретных маркет-мейкеров и совершать сделки. На Solana такие агрегаторы, как Jupiter, уже интегрировали этот режим (JupiterZ). В этой системе приложения могут взимать плату за подключение к маркет-мейкерам или напрямую продавать пакеты розничных заказов. По мере сужения спредов на цепочке, автор ожидает, что такой «продажный» бизнес станет всё более распространённым.

Кроме того, между DEX и агрегаторами формируется своего рода альянс интересов. Prop AMMs (самостоятельные маркет-мейкеры) и DEX сильно зависят от трафика, который приносят агрегаторы, и могут взимать плату с этих поставщиков ликвидности, возвращая часть прибыли в виде «кэшбэка» фронтенд-приложениям.

Например, когда кошелек Phantom маршрутизирует транзакцию пользователя через Jupiter, поставщик ликвидности (например, HumidiFi или Meteora) может заплатить Jupiter за право исполнения этой сделки. После получения «платежа за канал» Jupiter частично возвращает его кошельку Phantom.

Хотя такие предположения ещё не подтверждены официально, автор считает, что в условиях конкуренции внутри цепочки подобные «разделы прибыли» — почти естественный феномен.

«Кровососание» рыночных ордеров

Когда пользователь нажимает «подтвердить» и подписывает транзакцию в кошельке, по сути, это рыночный ордер с параметром скольжения (slippage).

Для приложений есть два варианта обработки такой транзакции:

Благоприятный сценарий: продавать возможность «задержки» (Backrun — арбитраж за спиной) профессиональным торговым фирмам, деля прибыль. Backrun — это ситуация, когда пользователь создает ордер на DEX1, повышающий цену токена, а арбитражный робот в тот же блок покупает на DEX2 (не влияя на цену в DEX1) и затем продает на DEX1.

Вредоносный сценарий: помогать «захватчикам» (медведям-«медвежьим» арбитражникам) атаковать своих пользователей, искусственно повышая цену сделки.

Даже при благоприятном сценарии это не означает, что у приложений есть совесть: чтобы максимизировать прибыль от «задержки», они могут намеренно замедлять вывод транзакций в цепочку. В условиях конкуренции приложения могут также целенаправленно маршрутизировать пользователей в менее ликвидные пулы, создавая искусственные колебания цен и возможности для арбитража.

По данным, некоторые известные фронтенд-приложения на Solana уже используют такие схемы.

Кто забирает ваши чаевые?

Если вышеописанные методы требуют определённых технических навыков, то скрытые махинации с «транзакционными комиссиями» — это уже «без маскировки».

На Solana расходы пользователя делятся на две части:

• Приоритетная плата: это внутренняя комиссия протокола, которая напрямую идёт валидатору.

• Транзакционный чаевые: это SOL, переводимый на любой адрес, обычно — «сервисам по обеспечению транзакций» (Landing Service), таким как Jito. Эти сервисы решают, сколько отдавать валидаторам и сколько возвращать (Rebate) приложению.

Зачем нужны сервисы по обеспечению транзакций? Потому что при перегруженности сети Solana обычная трансляция транзакций часто терпит неудачу. Эти сервисы выступают в роли «VIP-канала», обеспечивая успешное включение транзакции в блок.

Сложный рынок строителей блоков (Builder Market) и фрагментированная система маршрутизации создают уникальную роль таких сервисов, а также предоставляют приложениям отличную возможность для «схемы» заработка. Обычно приложения побуждают пользователей платить высокие чаевые «для гарантии», а затем делят эти излишки с сервисами.

Рынок транзакционного трафика и комиссия

Рассмотрим данные. За период с 1 по 8 декабря 2025 года в сети Solana было совершено 4,5 миллиарда транзакций.

Из них, сервисы Jito обработали 800 миллионов, что составляет 93,5% рынка строителей блоков. Большая часть этих транзакций — обмены, обновления оракулов и операции маркет-мейкеров.

В этом огромном потоке пользователи, чтобы «поторопиться», часто платили высокие комиссии. Но действительно ли все эти деньги шли на ускорение?

Не совсем. Данные показывают, что низкоактивные кошельки (обычно розничные трейдеры) платили астрономические приоритетные сборы. При этом, учитывая, что блоки не были заполнены полностью, эти пользователи явно переплачивали.

Приложения используют страх «неудачи транзакции», чтобы побуждать пользователей ставить очень высокие чаевые, а затем делить эти излишки с сервисами по обеспечению транзакций.

Пример Axiom

Чтобы нагляднее показать схему «сбора», автор провёл глубокое исследование одного из ведущих приложений на Solana — Axiom.

Транзакционные сборы Axiom — рекордные по всей сети, не только потому, что у него много пользователей, но и потому, что он наиболее «жадный».

Данные показывают, что медиана приоритетных сборов пользователей Axiom (p50) достигает 1 005 000 лампортов. Для сравнения, у высокочастотных трейдеров — около 5 000–6 000 лампортов. Разница — в 200 раз.

Что касается чаевых, ситуация аналогична.

Пользователи Axiom платили значительно больше за сервисы Nozomi, Zero Slot и другие. Приложение использует крайнюю чувствительность пользователей к скорости, и без негативных отзывов осуществляет двойную «наживу».

Автор прямо предполагает: «Большая часть транзакционных сборов пользователей Axiom в конечном итоге попадает в карман команде Axiom.»

Возврат контроля над ценообразованием

Глубокий дисбаланс между стимулом пользователей и приложений — корень нынешних проблем. Пользователи не знают, что считать разумной платой, а приложения охотно поддерживают хаос.

Чтобы изменить ситуацию, нужно реформировать рыночную структуру снизу. Предполагается, что к 2026 году внедрение Solana таких механизмов, как MCP (многочисленные параллельные предложители) и приоритетный порядок (Priority Ordering), а также широко обсуждаемый механизм динамической базовой платы (Dynamic Base Fee), станет ключом к решению.

Многочисленные параллельные предложители (Multiple Concurrent Proposers)

Текущая модель с одним предложителем легко приводит к временному монополизму: приложение достаточно договориться с текущим лидером, чтобы контролировать упаковку транзакций. Внедрение MCP позволит нескольким предложителям работать одновременно, значительно повысив стоимость атак и монополизации, а также усложнив цензуру, что затруднит контроль приложений над пользователями.

Механизм приоритетного порядка (Priority Ordering)

Через протокол принудительно устанавливается «сортировка по приоритетной плате», исключая случайность (Jitter). Это уменьшает необходимость в приватных ускорителях, таких как Jito, для «гарантированного» прохождения транзакции. Для обычных транзакций пользователи больше не должны гадать, сколько чаевых платить — достаточно оплатить внутри протокола, и валидаторы по определённым правилам обработают их в порядке очереди.

Динамическая базовая плата (Dynamic Base Fee)

Это самый важный шаг. Solana пытается внедрить концепцию, аналогичную Ethereum — динамическую базовую плату.

Пользователи больше не дают слепые чаевые, а явно указывают протоколу: «Я готов заплатить максимум X лампортов за эту транзакцию.»

Протокол автоматически устанавливает цену в зависимости от текущей загруженности сети: при низкой нагрузке — низкую цену, при высокой — высокую. Такой механизм возвращает право ценообразования из рук приложений и посредников в прозрачные алгоритмы протокола.

Meme принес Solana процветание, но также и корень проблем — жажду быстрой прибыли и неустойчивое настроение. Чтобы Solana реализовала свою мечту о полноценной интеграции с ICM, она должна избавиться от сговора приложений, контролирующих трафик, и протоколов, владеющих инфраструктурой.

Как говорится, «чистить дом перед гостями» — только при обновлении базовой архитектуры и устранении условий для поиска прибыли на стороне, можно создать честный, прозрачный рынок, ориентированный на благосостояние пользователей, и обеспечить конкурентоспособность в интеграции с традиционными финансовыми системами.