«Невидимый налог» на Solana

Несколько лет назад статья «Payment for Order Flow на Solana» раскрыла теневую сторону комиссии в сети Solana и вызвала широкий резонанс в англоязычном криптосообществе Twitter.

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

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

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

Для этого брокеры, как Robinhood, агрегируют розничный поток заявок и продают его оптом крупным маркет-мейкерам, например Citadel, получая за это значительные вознаграждения.

В традиционных финансах регулирование обеспечивает розничным инвесторам определённую защиту. Регламент NMS SEC требует, чтобы даже агрегированные заявки исполнялись не хуже текущей рыночной цены.

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

Монетизация пользовательского потока

У приложений, которые контролируют ключевые точки доступа пользователей, стратегии монетизации гораздо сложнее, чем принято думать.

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

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

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

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

Кроме того, формируются альянсы между DEX и агрегаторами. Собственные AMM и DEX сильно зависят от трафика агрегаторов, а агрегаторы могут взимать плату с поставщиков ликвидности и возвращать часть прибыли фронтенд-приложениям.

Например, если кошелёк Phantom направляет сделку пользователя в Jupiter, поставщики ликвидности, такие как HumidiFi или Meteora, могут платить Jupiter за право провести сделку. Jupiter, получая этот «канальный сбор», делится им с Phantom.

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

Хищнические рыночные заявки

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

У приложений есть два основных варианта работы с такими заявками:

Конструктивный: продавать возможность backrun (арбитража по следу) профессиональным трейдерам и делить прибыль. Backrun — это когда покупка пользователя на DEX1 поднимает цену токена, и арбитражный бот тут же покупает на DEX2 в том же блоке (не влияя на цену исполнения на DEX1), а затем продаёт на DEX1.

Эксплуататорский: сотрудничать с участниками sandwich-атак, чтобы искусственно завышать цену исполнения для собственных пользователей.

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

Есть сообщения, что некоторые крупные фронтенд-приложения Solana используют такие практики.

Кто получает ваши чаевые?

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

В Solana пользовательские комиссии состоят из двух частей:

• Priority Fee — комиссия на уровне протокола, выплачиваемая валидаторам напрямую.
• Transaction Tip — оплата в SOL на любой адрес, обычно сервису ускорения (landing service provider), например Jito. Такие сервисы сами решают, сколько выплатить валидаторам и сколько вернуть приложению.

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

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

Поток транзакций и структура комиссий

Приведём данные: с 1 по 8 декабря 2025 года сеть Solana обработала 450 000 000 транзакций.

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

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

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

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

Axiom: негативный пример

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

Axiom генерировал самые высокие комиссии в сети не только из-за большого числа пользователей, но и благодаря агрессивной политике сборов.

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

Аналогичная ситуация с чаевыми.

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

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

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

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

Для решения этой проблемы необходимо реформировать рыночную структуру. Ожидается, что внедрение Multiple Concurrent Proposers (MCP), Priority Ordering и динамического базового сбора в Solana, запланированное на 2026 год, может стать решением.

Multiple Concurrent Proposers (MCP)

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

Priority Ordering

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

Динамический базовый сбор

Это ключевая реформа. В Solana разрабатывается модель динамического базового сбора, аналогичная Ethereum.

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

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

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

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

Заявление:

1. Данная статья перепубликуется с ресурса [BlockBeats], авторские права принадлежат оригинальному автору [SpecialistXBT]. По вопросам перепубликации обращайтесь в команду Gate Learn для оперативного урегулирования в соответствии с установленными процедурами.
2. Отказ от ответственности: Мнения и взгляды, изложенные в статье, выражают исключительно позицию автора и не являются инвестиционной рекомендацией.
3. Переводы на другие языки выполняются командой Gate Learn. Если не указано Gate, запрещено копировать, распространять или использовать переведённые материалы.