Orbiter Finance – bridge и routing-инфраструктура, выросшая вокруг быстрых переводов между Ethereum rollups. В классической модели пользователь отправляет актив напрямую на EOA Maker, а Maker выдаёт соответствующий актив из собственного кошелька в целевой сети. Margin и arbitration должны защитить отправителя от неисполнения.
Проект постепенно расширил продукт: добавил router contracts, OPool для открытых токенов, API и сети за пределами EVM. При этом часть заявленной децентрализации Maker System остаётся незавершённой: документация всё ещё помечает самостоятельный Maker Client как testnet и whitelist-only.
Sender и Maker
Sender выбирает исходную и целевую сеть, токен и сумму. Quote содержит адрес Maker, withholding fee, trading fee и лимиты. Пользователь переводит средства на EOA Maker в исходной сети с кодированными параметрами назначения.
Maker наблюдает платеж и отправляет актив пользователю из своей ликвидности в целевой сети. Такая схема быстрая, потому что не ждёт вывода rollup через Ethereum. Она похожа на авансирование Bonder в Hop Protocol, но Orbiter строит расчёт вокруг прямых EOA-платежей и собственной arbitration.
Пользователь доверяет не обещанию Maker, а возможности доказать неисполнение и получить компенсацию из залога. На практике безопасность зависит от корректной кодировки, достаточного margin, доступности арбитражного пути и реальной возможности проверить обе сети.
MDC, EBC и ZK-SPV
Maker Deposit Contract, или MDC, хранит excess margin. Его размер связан с установленными лимитами маршрута. Если Maker не докажет выплату, залог должен покрыть возврат и предусмотренную компенсацию.
Event Binding Contract, или EBC, сопоставляет source и destination events: токен, сумму, получателя и идентификатор заказа. Он не перемещает средства сам, а помогает определить, соответствовала ли выплата намерению пользователя.
ZK-SPV должен доказать существование и действительность транзакций rollup относительно базовой сети. Zero-knowledge proof уменьшает необходимость доверять централизованному наблюдателю, но требует корректных circuits, verifier contracts и доступных данных. Поддержка конкретной сети не означает, что для неё уже действует полностью permissionless ZK arbitration.
Как проходит спор
Если выплата не пришла, Sender открывает arbitration case. Maker может предоставить proof, что destination transaction существует и соответствует условиям. При отсутствии валидного доказательства контракт использует margin для компенсации.
Спор не равен мгновенному chargeback. Пользователь должен дождаться требуемой финальности, правильно подать claim и оплатить gas. Если ошибка произошла из-за неверного адреса, неподдерживаемого токена или отправки вне лимита, компенсация может не применяться.
Maker System и его статус
Целевая модель позволяет любому запустить Maker Node, выбрать сети, лимиты и fees, внести margin и обслуживать transfers. Конкуренция должна улучшить цену и уменьшить зависимость от официальных адресов.
Однако текущая документация прямо указывает, что Maker Client работает в testnet и доступен whitelist-участникам. В production интерфейс публикует набор известных Maker addresses. Поэтому обещание permissionless makers следует считать направлением развития, а не полностью реализованным текущим состоянием.
OrbiterRouter и агрегатор
Новые контракты OrbiterRouterV3 и API позволяют строить маршруты для разных токенов и виртуальных машин. Quote может включать swap, bridge и destination action. Адреса контрактов различаются по сети и продукту, а некоторые маршруты всё ещё идут через EOA Maker.
Агрегатор расширяет охват, но добавляет сторонние источники ликвидности. Поддержка Starknet, Solana, Sui или TON требует разных форматов адресов и финальности. Ошибка преобразования может быть опаснее обычного EVM-to-EVM transfer.
OPool
OPool – контрактная система для открытого подключения токенов. Проект размещает ликвидность своего EToken в пулах нескольких сетей и следит за балансами. Пользователь блокирует актив в source OPool, а выходная операция выдаёт его на destination.
Эта модель отличается от прямой EOA-выплаты Maker. Она больше похожа на распределённые liquidity pools и требует постоянной ребалансировки. Низкий остаток целевого пула делает перевод недоступным, даже если токен формально числится поддерживаемым.
Комиссии
Maker задаёт withholding fee для destination gas и trading fee как долю суммы в пределах разрешённых параметров. Route с обменом добавляет swap fee и slippage. API показывает расчёт по конкретной котировке, поэтому старое фиксированное число нельзя использовать для всех сетей.
Низкая базовая стоимость достигается прямыми переводами между EOA, но она не учитывает цену капитала Maker и редкие arbitration costs. Перед подписью важны сумма к получению, лимит и адрес Maker из текущего quote.
O-Points и токен
O-Points учитывают bridge, swap, bundle, задания, NFT-карты и вклад в экосистему. Это off-chain программа лояльности, а не transferable token и не подтверждённое право на airdrop. Правила начисления могут меняться.
На дату обзора официальный FAQ не подтверждает TGE, ticker, supply или token allocation Orbiter Finance. Следовательно, у проекта нет опубликованной токеномики, которую можно считать действующей. Любая одноимённая монета требует отдельной проверки и не должна связываться с O-Points автоматически.
История
Orbiter Finance появился в 2021 году на фоне роста Ethereum L2 и предложил быстрые transfers через Makers. Ранний продукт сосредоточился на ETH между zkSync Lite, Arbitrum, Optimism и Ethereum, затем добавлял rollups и ERC-20.
В 2023–2024 годах команда развивала ZK-SPV, arbitration, Vizing и концепцию Ethereum Acceleration Engine. Позднее появились RouterV3, OPool, REST API и поддержка нескольких VM. O-Points расширили программу активности, но token launch остался неподтверждённым.
Команда
Orbiter Finance развивает частично анонимная команда, которая не публикует в текущей документации устойчивый полный список основателей и руководителей. Это само по себе не доказывает небезопасность, но усложняет оценку ответственности. Пользователю важнее проверять production contracts, Maker addresses, audits, margin и фактическую децентрализацию операторов.
Основные риски
Maker liquidity. Недостаток средств задерживает выплату. Концентрация маршрутов у нескольких EOA создаёт operational и censorship risk.
Arbitration. Ошибка proof, verifier или claim-процедуры может лишить пользователя своевременной компенсации.
Margin. Залог должен покрывать обязательство. Резкое изменение цены или неверные лимиты могут сделать его недостаточным.
Разные продукты. EOA bridge, RouterV3 и OPool имеют разные контракты и trust assumptions. Бренд Orbiter не гарантирует одинаковую защиту.
Новые VM. Адресные форматы, token decimals и finality отличаются. Ошибка интеграции с Sui или другой non-EVM сетью может привести к необратимому выводу.
Централизация развития. Permissionless Maker System остаётся testnet-направлением, а production зависит от официального backend и списка операторов.
Спекуляция на points. O-Points не гарантируют token allocation. Траты ради предполагаемого airdrop могут превысить любую будущую награду.
Orbiter предлагает быстрый и понятный maker-based перенос между rollups, а OPool расширяет модель на новые токены. Но заявленная ZK-защита и permissionless участие должны оцениваться по фактически включённым контрактам, а не по дорожной карте.
