API3 – инфраструктура оракулов, в которой данные подписывает сам API provider. Проект называет такую модель first-party oracle: между первичным источником и блокчейном нет отдельной сети независимых узлов, перепродающих тот же API. Пользователь получает криптографически проверяемую публикацию от организации, которая отвечает за исходные данные.
На этом принципе построены dAPI – именованные price feeds для смарт-контрактов. API3 дополняет их механизмом OEV, который продаёт право первым доставить особенно ценное обновление и возвращает часть выручки приложению. Такая конструкция отличается и от pull-модели Pyth, и от независимых операторов Chainlink, поэтому её риски нужно разбирать по слоям.
Airnode и first-party oracle
Airnode – программный узел, который API provider запускает от собственного имени. Он обращается к API организации, преобразует ответ по заранее заданному шаблону и подписывает результат своим oracle wallet. Смарт-контракт может проверить подпись и убедиться, что сообщение поступило от разрешённого источника.
Это убирает посредника между provider и блокчейном, но не делает саму цифру объективной. Ошибка биржи, сбой методики индекса или компрометация ключа Airnode остаются возможными. Для надёжного feed API3 может объединять несколько first-party источников и агрегировать их значения.
Airnode также поддерживает запрос-ответ, когда dApp вызывает конкретный endpoint. Однако текущая массовая инфраструктура цен строится вокруг подписанных потоков и push-обновлений, а не вокруг отдельного on-chain запроса к API для каждой операции.
Beacons, beacon sets и dAPI
Базовая единица feed называется beacon. Её идентификатор выводится из адреса Airnode и template ID, который описывает endpoint и параметры обработки. Один beacon соответствует одному подписанному потоку одного provider. Beacon set объединяет несколько beacon и выдаёт агрегированное значение.
dAPI добавляет человекочитаемое имя, например пару актива и валюты, и сопоставляет его с конкретным data feed ID. Если API3 меняет состав источников под тем же именем, приложение продолжает читать dAPI, а underlying beacon set обновляется. Это удобно для сопровождения, но означает доверие к процессу конфигурации.
В API3ServerV1 хранятся значения и соответствия имён. Приложение обычно читает данные через отдельный Api3ReaderProxyV1. Этот proxy развернут детерминированно для выбранной сети, feed и режима OEV, поэтому разработчик должен проверить адрес и не копировать его из случайного интерфейса.
Signed API и Airseeker
Airnode feed регулярно опрашивает API provider и отправляет подписанные значения в Signed API. Этот сервис хранит пакеты вне блокчейна и отдаёт их операторам обновлений. Подпись позволяет любому проверить происхождение пакета, но доступность самого сервиса всё равно зависит от обычной облачной и сетевой инфраструктуры.
Airseeker сравнивает off-chain значение с уже записанным on-chain. Когда отклонение превышает заданный порог или истекает максимальный интервал, он отправляет обновление. Параметры подбираются для каждого feed: слишком редкая запись повышает staleness, слишком частая увеличивает расходы.
Base feed permissionless на уровне исполнения: действительный подписанный пакет может отправить не только основной Airseeker. Это даёт резервный путь, однако участнику всё равно нужны актуальные подписи. Ротация mnemonic provider меняет Airnode address, и конфигурация должна своевременно перейти на новый источник.
Как работает OEV
Oracle Extractable Value возникает, когда новое значение оракула создаёт прибыльную liquidation или другую транзакцию. В обычной схеме поисковики конкурируют в публичном mempool, а ценность достаётся победившему liquidator и block builder. API3 пытается вернуть её приложению через отдельный аукционный канал.
Для участвующего dApp разворачивается Api3ReaderProxyV1 с неизменяемым dApp ID. Контракт читает более свежее из двух значений: общего base feed и специального OEV feed. Партнёрские searchers получают realtime signed data, рассчитывают прибыльную операцию и конкурируют за право обновить OEV feed вместе с полезным действием.
Base feed намеренно получает подписанные данные с задержкой, чтобы эксклюзивность OEV auction имела экономическую ценность. Если аукцион не дал обновления, приложение позднее видит общий feed. Это не бесплатное ускорение: модель обменивает небольшую задержку базового потока на шанс вернуть часть MEV.
На 25 августа 2026 года право отправлять OEV updates доступно только партнёрским searchers API3, а не любому участнику. В программе OEV Rewards приложение получает 80% зафиксированной выручки, остаток остаётся протоколу. Расчёты и выплаты проводятся периодически, поэтому интеграция не равна автоматическому on-chain revenue share в каждой транзакции.
Интеграция и роли
API provider отвечает за исходный endpoint и ключ подписи. API3 поддерживает контракты, Signed API, Airseeker, registry и Market. Searchers обслуживают OEV. Разработчик dApp выбирает feed, проверяет proxy, определяет допустимую свежесть и отвечает за реакцию на невалидное или отсутствующее значение.
Api3ReaderProxyV1 реализует привычный интерфейс AggregatorV2V3, что облегчает замену оракула в EVM-протоколах. Но совместимый интерфейс не делает semantics одинаковой: приложение должно понимать timestamp, decimals, состав источников и OEV delay.
Proxy является upgradeable. По текущей документации право исключительного upgrade принадлежит 4-of-8 multisig технической команды, а root конфигураций feed утверждает 4-of-4 multisig. Это позволяет срочно исправлять уязвимости, но создаёт административный риск и отличает фактическое управление инфраструктурой от голосования DAO.
API3, staking и tokenomics
API3 – ERC-20 token управления. Начальное предложение составляло 100 млн. Оно не является жёстким максимумом: награды staking выпускаются дополнительно. Поэтому сравнивать текущий оборот только с первоначальными 100 млн неправильно.
В исходном распределении 30% предназначались public sale и ecosystem, 25% – founders, 20% – partners и contributors, 15% – investors, 10% – seed investors. Для командных и инвестиционных долей применялись многолетние графики vesting, которые относятся к стартовой tokenomics и не описывают текущие балансы.
Staking в Ethereum DAO pool даёт voting power и долю weekly minted rewards. Награда автоматически compounding внутри pool и становится доступной после годовой блокировки. Выход состоит из scheduling unstake и последующего withdrawal после waiting period, поэтому API3 нельзя считать мгновенно ликвидным во время участия.
APR не задан навсегда. Контракт корректирует его на один процентный пункт в неделю в зависимости от отношения staked supply к управляемой цели и ограничивает минимальным и максимальным значением. В актуальной документации расчёта target указан как 40%. Старые публикации со стартовым APY и целью 50% описывают запуск 2021 года, а не гарантированные условия 2026 года.
Управление
Stakers создают и голосуют за proposals, финансируют grants и меняют параметры DAO pool. Voting power можно делегировать. Длительная блокировка rewards должна связывать голосующего с последствиями решений, но инфляция стимулирует участие и одновременно размывает пассивных holders.
Ранняя модель API3 предполагала service coverage и возможность выплаты claims из staking pool. Техническая документация прямо отмечает, что slashing по таким требованиям ещё не реализован. Поэтому нельзя представлять текущий staking как действующую страховую гарантию для всех dAPI.
API3 Foundation также управляет отдельным направлением Morpho vault curation, используя значительную часть treasury как капитал. Это действующий продукт, но риск lending vault и роль curator не являются свойствами oracle feed. Смешивать доходность vault с наградами API3 staking нельзя.
История
API3 был основан в 2020 году как проект децентрализованных API. Whitepaper сформулировал first-party oracle и Airnode, а public token distribution состоялся в конце того же года. В 2021 году на Ethereum заработали authoritative DAO и staking pool.
В следующие годы команда развивала dAPI, Signed API и Airseeker, расширяя список EVM networks. OEV Network вышла в production в 2024 году и затем превратилась в программу OEV Rewards. В 2025–2026 годах API3 усилил интеграции кредитных рынков и запустил curation vaults на Morpho. Старые планы страхового покрытия при этом не стали полноценной действующей системой claims.
Команда
API3 основали Heikki Vänttinen, Burak Benligiray и Saša Milić. До API3 участники команды работали над Honeycomb и oracle-инфраструктурой, связывавшей API providers со смарт-контрактами. Организационно протокол опирается на API3 DAO, API3 Foundation и технических contributors.
DAO контролирует treasury и высокоуровневые параметры, но ежедневная эксплуатация не полностью децентрализована. Multisig технической команды обновляет proxy, Foundation управляет продуктами и рисками, а providers самостоятельно ведут Airnode. Для пользователя важнее разделение этих полномочий, чем единый маркетинговый список команды.
Применение
dAPI используют lending markets, derivatives, stablecoins и vaults. В кредитовании first-party sources уменьшают один слой посредников, а OEV способен возвращать протоколу часть стоимости liquidations. На сетях вроде Base или Arbitrum совместимый reader упрощает подключение, но не отменяет тестирование конкретного адреса.
Модель особенно полезна, когда API provider готов сам подписывать данные. Если же исходник остаётся закрытым, слабым или централизованным, Airnode лишь доказывает происхождение ошибки. Для агрегированного feed качество определяется составом beacon set и независимостью его участников.
Основные риски
- Source risk. First-party подпись подтверждает автора, но не истинность его значения.
- Key risk. Компрометация Airnode wallet позволяет подписывать ложные данные до ротации конфигурации.
- Infrastructure risk. Signed API и Airseeker используют off-chain сервисы и облачную доступность.
- Configuration risk. Ошибка beacon set, decimals или dAPI mapping влияет на все приложения с этим именем.
- OEV delay. Base feed намеренно задержан, а доступ к realtime update ограничен partnered searchers.
- Upgrade risk. Технические multisig способны менять proxy и configuration roots.
- Liquidity risk. Доход OEV зависит от liquidation flow и конкуренции, а не является стабильной выплатой.
- Token inflation. Weekly minting увеличивает supply и размывает holders вне pool.
- Governance concentration. Voting power следует за staked API3 и может концентрироваться у крупных участников.
- Application risk. Протокол-потребитель сам отвечает за staleness checks и аварийные режимы.
Итог
API3 убирает отдельного oracle-middleman, давая API provider инструменты для прямой подписи данных. dAPI и proxy упрощают интеграцию, Airseeker поддерживает base feeds, а OEV превращает часть ценности ликвидаций в доход приложения. Цена такой модели – зависимость от providers, off-chain сервисов, технических multisig и ограниченного набора OEV searchers. Токен API3 управляет DAO и staking pool, но его награды инфляционны, а заявленная когда-то страховая функция не должна считаться реализованной.
