Должны ли разработчики размещаться в таких корпоративных блокчейнах, как Base и Robinhood?

作者：Jonah

Перевод: Luffy，Foresight News

Должны ли разработчики строить в Robinhood-блокчейне или на блокчейне Tempo, принадлежащем Stripe? У этих двух проектов есть одна общая ключевая черта: оператор одновременно контролирует базовую платформу блокчейна и при этом держит в руках самые крупные ончейн-приложения по объёму трафика.

Судя по прежним кейсам — от Amazon и Microsoft до Base, дочерней сети Coinbase, — такая модель «платформа + собственное топ-приложение» порождает конфликты интересов, негативно влияя на разработчиков, которые приходят со стороны: разработчики ради трафиковых преференций берут на себя риски контроля со стороны платформы, но при этом вынуждены сталкиваться с непостоянной векторностью платформы — в соответствии с её собственными приоритетами. В этой статье разберём, где именно возникают противоречия интересов, как это бьёт по разработчикам на практике, и какие меры по снижению рисков следует применять.

Соблазнительный «маркетинговый крючок»: поддержка распределения трафика

Почему разработчики изначально выбирают корпоративные блокчейны? Чего они ожидали? Часть сетей напрямую предлагает крупные субсидии за подключение; в большинстве случаев же ключевым аргументом блокчейна выступает именно поддержка трафика. Например, в случае с Coinbase Base логика внешней коммуникации сводится к следующему: при входе в экосистему Base платформа будет направлять трафик на проекты разработчиков через кошелёк Coinbase или приложение. Robinhood-блокчейн и Tempo от Stripe следуют той же логике.

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

Но на практике возникают проблемы одна за другой, и корень в том, что платформа по умолчанию будет отдавать приоритет поддержке собственных нативных продуктов, а не сторонних разработчиков. Coinbase склоняет ресурсы в пользу собственной биржи и кошелька; Robinhood — в пользу собственного брокера и кошелька; Stripe — делает ставку на разработанную собственными силами платёжную систему. Ниже разберём пять основных рисков по очереди.

Риск первый: платформа выходит «в поле» и напрямую конкурирует с разработчиками

Предприятия, которые одновременно управляют базовой платформой и ончейн-приложениями, подавляют сторонних разработчиков — это уже давно подтвержденная фактами практика. The Wall Street Journal сообщала, что руководство Amazon запрашивает операционные данные сторонних продавцов, отбирает бестселлеры и запускает собственные конкурирующие товары. Продавцы проверяют спрос на Amazon, а Amazon тем временем конкурирует на той же арене, опираясь на преимущества эксклюзивных данных.

Ещё один хрестоматийный пример — Microsoft и браузер Netscape. Netscape полностью зависел от пользователей Windows, и затем Microsoft предустановила IE в операционную систему, полностью уничтожив конкурента. Base, Robinhood-блокчейны, Tempo — и корпоративные сети подобного типа — повторяют ту же схему конфликта интересов по отношению к третьим проектам, заходящим на их платформу.

Риск второй: комплектный кошелёк не будет привязан к одной-единственной сети

У кошелька нет стимула просто продвигать проекты разработчиков на «одной» цепочке. Главная конкуренция кошелька — в способности предоставлять пользователям услуги по хранению и использованию криптоактивов по всей индустрии: если поддерживать только одну цепочку, продуктовая ценность резко падает, а пользователи напрямую переходят к мультчейн-кошелькам. Поэтому кошелёк Coinbase должен быть совместим с Solana, и кошельки-«компаньоны» Robinhood и Tempo в будущем столкнутся с тем же давлением по совместимости.

Это означает, что кошелёк будет показывать активы и приложения других сетей. Более того, оптимальная продуктовая стратегия для кошелька — напрямую подключать лидирующие приложения в сегменте, даже если само приложение не разворачивается на той сети, к которой «приписан» кошелёк. Так, например, Phantom встраивает в себя торговлю бессрочными контрактами Hyperliquid, хотя Hyperliquid не обязан размещаться на блокчейне Phantom.

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

Риск третий: конкурентные продукты платформы будут отталкивать продукты разработчиков

Сторонние игроки из отрасли, которые конкурируют с этой платформой, не имеют причин продвигать их же проекты в собственной экосистеме. Зачем поддерживать конкурентную экосистему? USDC уже сталкивался с похожей проблемой: поскольку он «привязан» к Coinbase, многие сторонние платформы не хотели листить этот стейблкоин. Аналогично: проект, развёрнутый только в Robinhood-сети, кошелёк Coinbase не будет активно подключать для продвижения — и наоборот.

Риск четвертый: платформа держит пользователей и делит прибыль с разработчиками

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

Более устойчивый маршрут — построить собственные каналы дистрибуции, а сторонние платформы использовать лишь как ускорители трафика. Hyperliquid и Polymarket — типичные примеры: они напрямую строят собственные каналы привлечения пользователей, а затем через коды поощрения разработчиков разворачивают свой протокол на множестве платформ.

Риск пятый: обещанная поддержка трафика полностью не реализуется

Обещанное платформой продвижение и экспозиция трафика могут вообще не быть выполнены. Многие разработчики жалуются: кошелёк Coinbase на протяжении долгого времени отдаёт приоритет социальным функциям и почти не предоставляет ресурсов для экспонирования проектов внутри Base. Хотя представители Base официально заявляли, что ситуацию исправят, этот кейс уже доказывает главное: стратегические перестановки на уровне руководства напрямую определяют качество политики поддержки трафика.

Как разработчикам действовать?

На контрасте преимущество полностью нейтральных блокчейнов выглядит особенно очевидным. В Ethereum и Solana нет таких платформенных рисков, потому что там существует полностью нейтральная базовая инфраструктура: любой разработчик, который разворачивает проект на Ethereum, не должен беспокоиться о том, что Ethereum Foundation выпустит аналогичное приложение и начнёт конкурировать с ним. Эта нейтральность — ключевое преимущество, которое долгие годы недооценивали.

Тогда стоит ли разработчикам входить в корпоративные сети?

Есть несколько способов смягчить риски, связанные с конфликтом интересов:

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

Платформа даёт жёсткое письменное обязательство: не выходить в конкурентную борьбу и обеспечить поддержку трафика (но коммерческая история показывает, что такие обязательства слабо связуют стороны и легко дают сбой);

Самостоятельно диверсифицировать риски: мультичейн-развёртывание + собственные каналы трафика. Это даёт право выбора экосистем и позволяет удерживать собственное пространство для прибыли.

С этой точки зрения корпоративные сети подходят для холодного старта проекта: использовать трафик платформы, чтобы завершить cold start, но главная цель — накопить собственных пользователей, а не оставаться долгосрочно зависимым от платформы.

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