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

Автор: Jonah

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

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

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

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

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

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

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

Риск №1: выход платформы на рынок и прямая конкуренция с разработчиками

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

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

Риск №2: сопровождающий кошелек не будет зависеть от одной публичной сети

Кошелек не имеет никаких стимулов продвигать только проекты на одной конкретной цепи разработчика. Ключевая конкурентная способность продуктового решения кошелька заключается в предоставлении пользователям доступа ко всем криптоактивам отрасли; если он поддерживает лишь одну публичную сеть, его конкурентоспособность резко упадет, и пользователи перейдут на мультичейновые кошельки. Поэтому кошелек Coinbase обязан поддерживать совместимость с Solana, а сопутствующие кошельки Robinhood и Tempo в будущем столкнутся с тем же давлением необходимости кроссчейновой интеграции.

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

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

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

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

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

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

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

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

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

Как разработчикам реагировать?

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

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

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

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

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

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