Axelar – сеть межсетевой связи, которая принимает сообщения из подключённых блокчейнов, подтверждает их собственным набором Proof of Stake-валидаторов и разрешает исполнение через Gateway-контракт в целевой сети. На этом механизме работают General Message Passing, перенос токенов, Interchain Token Service и набор инструментов MDS.
Axelar не является одним двусторонним мостом. Это отдельный блокчейн на Cosmos SDK, связанный с множеством Gateway-контрактов и внешних интеграций. Безопасность операции зависит одновременно от исходной цепи, голосования валидаторов Axelar, threshold-подписи, Gateway в пункте назначения, ретрансляции и кода приложения.
История
Проект основали Sergey Gorbunov и Georgios Vlachos. Оба ранее входили в founding team Algorand и работали над криптографией и распределёнными системами. Axelar задумывался как универсальный слой маршрутизации, которому не нужно создавать отдельную пару мостов для каждого сочетания сетей.
Mainnet и первые межсетевые подключения развивались в 2022 году. Нативный токен AXL стал доступен 27 сентября 2022 года. Сначала сеть была известна прежде всего передачей обёрнутых активов, затем фокус сместился к произвольным сообщениям и приложениям, работающим сразу в нескольких цепях.
В октябре 2024 года проект представил Mobius Development Stack. Обновление Cobalt заработало в феврале 2025 года и изменило экономику комиссий: основная часть сетевого gas направляется на сжигание, а небольшая – в грантовый контур сообщества. Interchain Amplifier расширил модель подключения цепей через наборы проверяющих и отдельные пулы наград. Эти новые интеграции не отменили классические валидаторские подключения – в сети сосуществуют разные модели.
Команда
Sergey Gorbunov и Georgios Vlachos остаются ключевыми сооснователями. Начальную разработку сети вела команда, ныне известная как Interop Labs. Axelar Foundation поддерживает экосистему, гранты и координацию. Валидаторы, разработчики приложений и интеграторы цепей действуют независимо от этих организаций.
Разделение фонда и разработчика не превращает обновления в полностью автоматическое token governance. Репозитории, клиент axelard, контракты Gateway, multisig-роли и процедуры интеграции поддерживают конкретные команды. Для оценки децентрализации важны не только число валидаторов, но и распределение stake, ключей управления Gateway и операторов ретрансляции.
Базовая сеть Axelar
Axelar Chain построена на Cosmos SDK и использует Delegated Proof of Stake. Валидаторы производят блоки, подтверждают состояние и голосуют по событиям во внешних цепях. Держатели AXL делегируют stake и разделяют награды и риск наказания с выбранным оператором.
Узел валидатора связан с отдельными процессами, которые наблюдают подключённые блокчейны и участвуют в threshold-криптографии. Для каждого внешнего события сеть ждёт достаточное число голосов. Затем валидаторы совместно формируют подпись для пакета команд, не собирая полный приватный ключ на одном сервере.
Threshold-схема учитывает вес валидаторов и периодически меняет ключи при ротации набора. Она устраняет единственного хранителя, но не делает компрометацию невозможной. Если достаточная доля stake действует злонамеренно или ключевые доли украдены, Gateway может принять опасную команду.
Gateway-контракты
Gateway – точка входа и проверки в подключённой сети. На исходной стороне контракт фиксирует запрос приложения или блокирует либо сжигает переносимый актив. Валидаторы Axelar наблюдают событие. На целевой стороне Gateway принимает подписанный пакет, сохраняет одобрение сообщения и не позволяет повторно использовать тот же command ID.
Gateway обычно имеет механизм управления и обновления. Это нужно для добавления операторов, ротации ключей и устранения уязвимостей, но создаёт административный риск. Перед крупным переводом важно проверить официальный адрес контракта конкретной сети, поскольку злоумышленник может развернуть внешне похожий Gateway.
Внешние цепи отличаются финальностью. Голосовать по событию слишком рано опасно из-за реорганизации, слишком поздно – неудобно пользователю. Axelar использует параметры подтверждений для каждой интеграции. Приложение не должно считать одинаковое число блоков универсальным для Ethereum, Sui или молодой EVM-сети.
General Message Passing
GMP позволяет контракту в сети A вызвать функцию контракта в сети B и при необходимости передать токены. Исходный контракт вызывает Gateway и публикует payload. Ретранслятор сообщает о событии Axelar, валидаторы голосуют и подписывают пакет, а другой ретранслятор отправляет его в целевой Gateway.
После одобрения любой исполнитель может вызвать целевое приложение. Оно проверяет через Gateway, что payload действительно одобрен, и выполняет свою внутреннюю функцию. Запись об использованном сообщении защищает от простого повторного исполнения.
Payload может содержать произвольные параметры. Это даёт межсетевой swap, управление, внесение залога или выпуск NFT в одной операции. Одновременно ошибка сериализации, неверно проверенный source address или незащищённая функция назначения превращают универсальность в широкий attack surface.
Gas Service и исполнители
Межсетевая операция требует расходов в нескольких сетях. Gas Service позволяет заранее внести средства на голосование, доставку одобрения и исполнение в целевой цепи. Оценка зависит от текущих цен газа и сложности целевого вызова, поэтому фиксированной комиссии для всех маршрутов нет.
Если средств недостаточно, сообщение может остановиться на промежуточном этапе, не становясь недействительным. Пользователь или сервис способен увеличить gas и продолжить исполнение. Переплата по поддерживаемому маршруту может быть возвращена согласно правилам сервиса, но это не отменяет волатильность цены газа и зависимость от ретрансляторов.
Ретрансляция permissionless в том смысле, что одобренный пакет может доставить любой участник. На практике приложения часто полагаются на доступные публичные сервисы. Их задержка ухудшает UX, хотя валидное сообщение обычно остаётся исполнимым другим оператором.
Межсетевой перенос токенов
Классическая передача блокирует или сжигает актив в исходной сети и выпускает представление в целевой. За каждым символом должна стоять точная схема происхождения. Токен с тем же тикером, выпущенный другим мостом, не становится взаимозаменяемым автоматически.
Нативный AXL существует в Axelar Chain. В EVM-сетях встречается обёрнутый WAXL. Адреса и формат различаются, поэтому отправка нативной монеты на несовместимый адрес может привести к потере. Кошелёк должен поддерживать выбранную сеть и маршрут.
Системный риск моста распространяется на выпущенные представления. Если исходный залог заморожен или Gateway скомпрометирован, обёрнутый актив может потерять обеспечение. Ликвидность на бирже не доказывает исправность канонического обратного выкупа.
Interchain Token Service
ITS помогает выпускать один логический токен в нескольких сетях с общим interchain token ID. Для каждой цепи разворачивается Token Manager, который управляет локальным выпуском, блокировкой или связью с уже существующим токеном. ITS Hub координирует маршрутизацию между интеграциями.
Режим зависит от исходного актива. Новый токен может сжигаться и чеканиться на разных цепях. Канонический актив часто блокируется в домашней сети и выпускается в остальных. Пользовательский Token Manager способен использовать собственную логику. Поэтому название ITS не гарантирует один и тот же trust model.
Роли minter и operator дают значительные полномочия. Разработчик может отказаться от них или передать управлению, но это нужно проверять по контракту. Flow limit ограничивает объём притока или оттока за период и помогает сдержать ущерб, однако не исправляет украденный admin-ключ.
Interchain Amplifier
Amplifier позволяет добавлять новые подключения без включения всей логики в основной валидаторский контур. Для цепи создаётся verifier set. Проверяющие вносят AXL, наблюдают события и получают награды из выделенного пула. Интеграция проходит процедуру onchain-управления.
Это расширяет доступ к нестандартным сетям и ускоряет эксперименты. Но безопасность конкретного маршрута определяется его проверяющими, порогом, Gateway и бюджетом наград. Нельзя автоматически приписывать ему весь stake основного Axelar validator set.
Пулы для Amplifier формируются из существующего предложения AXL, а не из отдельной инфляции за каждую подключённую цепь. Когда пул истощается, участникам нужна новая экономика. Высокая награда может привлечь stake, но не гарантирует техническую компетентность проверяющих.
MDS
Mobius Development Stack объединяет GMP, ITS, Amplifier и инструменты разработчика в общий набор для omnichain-приложений. Это продуктовый слой, а не новый консенсус. Приложение выбирает нужные компоненты и остаётся ответственным за разрешения, обработку ошибок и состояние в каждой сети.
Название omnichain иногда создаёт впечатление единой атомарной транзакции. На практике действия происходят в разных блоках и могут завершиться частично. Контракт должен уметь пережить задержку, возврат, недостаток gas и отказ целевого вызова.
Токен AXL и токеномика
AXL используется для staking, делегирования, комиссий, управления и экономической защиты Amplifier. Валидаторы получают эмиссию и комиссионные поступления, делятся ими с делегаторами и рискуют наказанием за нарушения.
Первоначальная токеномика включала инфляцию базовой сети и дополнительный выпуск за поддержку внешних цепей. Cobalt изменил траекторию: 98% сетевого gas направляется на burn address, 2% – в пул общественных грантов, а новые Amplifier-подключения могут финансироваться reward pools из уже существующего предложения.
На момент Cobalt годовая инфляция оценивалась примерно в 4,8%, но это историческая точка февраля 2025 года, а не обещание ставки в 2026 году. Реальное предложение зависит от параметров governance, числа блоков, наград, сжигания и разблокировок. Burn способен компенсировать часть выпуска только при достаточном использовании сети.
Управление
Держатели staked AXL участвуют в управлении Cosmos SDK-цепью через предложения и голоса валидаторов и делегаторов. Решения могут менять параметры, расходовать community pool и одобрять интеграции Amplifier. Делегатор обычно наследует голос валидатора, если не голосует самостоятельно.
Контракты Gateway в подключённых сетях имеют отдельное управление, которое не всегда совпадает с обычным governance-предложением Axelar Chain. Экстренная заморозка, ротация ключей и обновление реализации зависят от конкретной конфигурации. Поэтому onchain-голосование не устраняет все privileged roles.
Применение
Axelar используют для межсетевых обменов, единого управления ликвидностью, управления из одной цепи, multichain-токенов и приложений, где действие в одной сети запускает результат в другой. GMP удобнее ручной последовательности мостов, но приложение должно проектировать компенсацию при частичном сбое.
В сравнении с LayerZero Axelar чаще опирается на собственный PoS-набор и Gateway, тогда как LayerZero-приложения выбирают комбинации DVN и исполнителей. У Wormhole сообщения подтверждает Guardian set. Разные архитектуры нельзя сравнивать только числом поддерживаемых сетей.
Для передачи ликвидности специализированные решения вроде Across могут использовать intents и конкурирующих relayers, а Axelar предоставляет более общий вызов. Выбор зависит от того, нужен ли только быстрый перевод актива или произвольная межсетевая логика.
Основные риски
Сговор или компрометация валидаторов
Threshold-подпись безопасна лишь пока недостаточная доля весов контролируется злоумышленником. Stake и slashing повышают цену атаки, но стоимость активов в подключённых контрактах может превысить экономическую защиту AXL.
Ошибки Gateway и управления
Уязвимость прокси, upgrade-ключа или проверки пакета способна затронуть конкретную сеть. Rate limits и паузы сдерживают ущерб, но создают полномочия цензуры. Пользователь должен различать основную сеть и конкретный deployment.
Риск исходной и целевой цепи
Глубокая реорганизация исходной сети может отменить событие после того, как оно было подтверждено Axelar. Остановка целевой сети задержит исполнение. Безопасность GMP ограничена самым слабым подключённым блокчейном и приложением.
Прикладной payload
Контракт может принять сообщение от неверного source address, неправильно декодировать параметры или позволить повторное экономическое действие. Gateway подтверждает происхождение сообщения, но не его бизнес-смысл. Аудит межсетевого автомата должен охватывать все возможные состояния.
ITS-роли
Minter или operator способны изменить выпуск и маршрутизацию в пределах своих прав. Разные Token Manager используют разную модель. Маркетинговая надпись «interchain token» не заменяет проверку владельца и flow limit.
Экономика AXL
Инфляция размывает пассивного держателя, а burn зависит от спроса. Падение цены уменьшает стоимость stake относительно защищаемых активов. Amplifier-пулы способны закончиться, а высокая номинальная доходность может сопровождаться падением токена.
Операционные ошибки
Неверная сеть, токен или адрес приводят к необратимому переводу. Недостаточный gas оставляет сообщение незавершённым. Перед крупной суммой полезна тестовая операция и проверка статуса на всех этапах, как и при работе со Stargate.
Итог
Axelar превращает отдельный PoS-блокчейн в координационный слой для межсетевых сообщений. GMP даёт универсальные вызовы, ITS – управляемую многосетевую модель токена, а Amplifier – более гибкое подключение новых цепей. Главная ценность проекта состоит в общей маршрутизации вместо множества несвязанных мостов.
Эта универсальность увеличивает область риска. Для операции важны validator set, Gateway, финальность обеих сетей, права приложения, gas и ретрансляция. AXL связывает staking, управление и экономику подключений, но его капитализация не является абсолютной гарантией безопасности. Axelar следует оценивать по каждому маршруту и контракту, а не только по бренду сети.
