Чи мають розробники приєднуватися/інтегруватися на таких підприємствах публічних ланцюгах, як Base, Robinhood?

Автор: Jonah

Переклад: Luffy, Foresight News

Чи мають розробники будуватися на публічному ланцюзі Robinhood або на публічному ланцюзі Tempo, що належить Stripe? Ці два проєкти мають одну спільну ключову рису: оператор одночасно контролює базову інфраструктуру публічного ланцюга, а також тримає в руках застосунки з найбільшою онлайновою (on-chain) трафіком.

З огляду на попередні кейси від Amazon, Microsoft і аж до Base-ланцюга, що належить Coinbase, така модель «платформа + власний топ-застосунок» породжує конфлікт інтересів, що негативно впливає на розробників, які заходять: розробники беруть на себе ризики контролю платформи в обмін на трафікові бонуси, але мають стикатися з коливаннями у векторі інтересів платформи. У цій статті буде розібрано суперечності інтересів, реальний вплив на розробників та відповідні рішення для уникнення ризиків.

Спокусливий рекламний трюк: підтримка розподілу трафіку

З чого саме розробники спочатку обирали підприємницькі (enterprise) публічні ланцюги? У чому була початкова мотивація? Частина публічних ланцюгів безпосередньо пропонує високі субсидії за розміщення; у більшості випадків головним торговим аргументом публічного ланцюга є саме підтримка трафіку. Наприклад, Base від Coinbase: логіка його основної зовнішньої промоції така — у разі входу в екосистему Base платформа через гаманець Coinbase або застосунок спрямовуватиме трафік на проєкти розробників, забезпечуючи їм помітність та експозицію. Robinhood Chain і Tempo, що належить Stripe, також використовують цю саму логіку.

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

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

Ризик перший: платформа виходить «у бій» і напряму конкурує з розробниками

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

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

Ризик другий: додаткові гаманці не прив’язані до одного-єдиного публічного ланцюга

У гаманця немає жодної мотивації просто просувати проєкти з того ланцюга, де знаходиться розробник. Головна конкурентна перевага продукту гаманця — надавати користувачам сервіс для криптоактивів по всій індустрії. Якщо гаманець підтримує лише один ланцюг, конкурентна сила продукту суттєво зменшиться, і користувачі прямо переключаться на мультичейн-галанці. Тому гаманець Coinbase має сумісність із Solana; Robinhood і Tempo — їхні супутні гаманці — у майбутньому також стикатимуться з аналогічним тиском на сумісність.

Це означає, що гаманець неминуче демонструватиме активи та застосунки інших публічних ланцюгів. Більше того, оптимальна стратегія продукту для гаманця — напряму підключати ключові застосунки в сегменті: наприклад, у Phantom-гананці вбудована торгівля ф’ючерсами Hyperliquid perpetual, навіть якщо цей застосунок не розгортається на публічному ланцюзі, якому належить гаманець.

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

Ризик третій: конкуренти платформи відштовхують продукти розробників

У гравців галузі, які перебувають у конкурентних відносинах із цією компанією (платформою), немає жодної мотивації просувати проєкти у її екосистемі. Навіщо підтримувати екосистему конкурентів? Раніше USDC вже стикалася з подібною дилемою: оскільки за нею стоїть Coinbase, багато сторонніх платформ не хотіли додавати (вивішувати) цей стейблкоїн. Аналогічно, якщо проєкт розгорнутий лише на Robinhood-ланцюзі, гаманець Coinbase не буде активно підключати та просувати його; і навпаки.

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

В криптоіндустрії є універсальне правило: сторона, що контролює кінцевих користувачів, як правило, отримує значно вищі прибутки, ніж протокол, що підключений до платформи. Після цього вона безперервно видавлює прибутки протоколу, доки прибуток не почне наближатися до граничних (маржинальних) витрат. Я описував цю бізнес-модель у своїх матеріалах 《Логіка захоплення цінності》 та статтях про AI-агентів. Навіть якщо розробник заходить у корпоративний ланцюг і платформа виконує обіцянку підтримки трафіку, повністю покладатися на канал розподілу через одну-єдину платформу все одно є вкрай ризиковано — платформа тримає «слово» щодо користувачів, має дуже сильні важелі для торгу (багато важелів переговорів) і безперервно стискає простір прибутку для розробників.

Надійніше — створити власні канали розповсюдження, а сторонні платформи використовувати лише як прискорювач трафіку. Hyperliquid і Polymarket — типові приклади: вони напряму будують власні канали для залучення користувачів, а потім через коди стимулювання розробників розкладають свій протокол по багатьох платформах.

Ризик п’ятий: обіцяна підтримка трафіку повністю не спрацьовує

Платформа може пообіцяти трафікову експозицію, але цілком імовірно, що вона так і не буде виконана. Багато розробників скаржаться: гаманець Coinbase довго пріоритетно розвивав соціальні функції та майже не давав ресурсів для експозиції проєктам у межах Base-ланцюга; хоча офіційна позиція Base стверджує, що це виправлять, сам факт цієї історії доводить: стратегічні зміни на рівні керівництва компанії безпосередньо визначають, наскільки добре працюватиме політика підтримки трафіку.

Як розробникам діяти?

Порівняйте: перевага чистих нейтральних публічних ланцюгів виглядає особливо очевидною. У Ethereum, Solana відсутні такі ризики платформи, вони є цілком нейтральною базою: будь-який розробник, що розгортає застосунок на Ethereum, не має причин хвилюватися, що офіційний Ethereum випустить такий самий застосунок і складе конкуренцію самому собі. Саме ця нейтральність — ключова перевага, яку тривалий час недооцінювали.

То чи варто розробникам заходити в корпоративні публічні ланцюги?

Є кілька способів зменшити ризики, спричинені конфліктом інтересів:

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

Платформа видає жорсткі письмові гарантії, що не буде виходити в конкуренцію, та реалізує підтримку трафіку (але бізнес-історія доводить, що такі угоди мають слабку обов’язкову силу й легко втрачають чинність);

Самостійно диверсифікувати ризики: багатоланцюгове розгортання + створення власних каналів трафіку. Це дає і право вибору серед багатьох екосистем, і можливість захистити власний простір прибутку.

З цієї точки зору корпоративні публічні ланцюги підходять для початкового холодного старту проєктів: за допомогою трафіку платформи можна виконати cold start, але ключова мета — накопичити (осадити) власних користувачів, а не довгостроково залежати від платформи.

Наразі бізнес-модель корпоративних ланцюгів усе ще перебуває на ранній стадії. У майбутньому платформи, можливо, запропонують рішення, щоб послабити існуючі суперечності, і водночас виникнуть зовсім нові ризики.