Jupiter – liquidity and execution platform в Solana, начавшаяся как DEX aggregator. Она не объединяет все tokens в одном собственном AMM. Routing engines читают доступные markets, сравнивают пути и формируют transaction, которая может пройти через несколько независимых programs. Отдельно Jupiter развивает perpetuals, limit orders, lending и другие products со своими contracts и risks.
К августу 2026 года важно различать поколения swap stack. Ultra Swap API существует в документации, но больше активно не поддерживается. Его заменил единый Swap V2 API с Meta-Aggregator и Router paths. Поэтому слово Ultra полезно для понимания эволюции managed execution, но не должно выдаваться за рекомендуемый developer endpoint.
Что делает агрегатор
Пользователь задаёт input mint, output mint и amount. Router собирает состояние доступных pools и quotes, ищет один или несколько путей и оценивает итоговый output. Маршрут может разделить сумму между venues, если split даёт лучший ожидаемый результат.
Jupiter не создаёт liquidity из воздуха. Качество quote зависит от Raydium, Orca, Meteora, market makers и других sources, включённых в конкретный routing engine. Если pool мелкий, token имеет transfer fee или market state меняется до исполнения, финальный результат ухудшается.
Aggregator решает combinatorial routing problem: прямой swap A в B не всегда выгоднее пути A в SOL, затем SOL в B. В Solana transaction ограничена compute units, account locks и размером сообщения, поэтому теоретически лучший маршрут может быть слишком сложным или ненадёжным для on-chain execution.
Архитектура самой сети, parallel execution и account model подробно разобраны в обзоре Solana.
Swap V2: два действующих пути
Swap V2 объединяет capabilities под одним API. Meta-Aggregator предназначен для большинства integrations: engines конкурируют, Jupiter возвращает собранную transaction, пользователь подписывает её, а managed pipeline отправляет и отслеживает execution.
Router path использует Metis и возвращает raw swap instructions. Integrator сам собирает transaction, может добавить свои instructions, использовать CPI и выбрать инфраструктуру отправки. Этот путь даёт control, но перекладывает на developer compute budgeting, priority fees, RPC reliability, slippage и confirmation handling.
Meta-Aggregator использует order and execute endpoints. Router – build и самостоятельную отправку либо Jupiter landing service. Эти flows нельзя смешивать: transaction, полученную от RFQ path, нельзя произвольно модифицировать после quote.
Routing engines
Metis – on-chain routing engine Jupiter. Он ищет multi-hop и multi-split paths по Solana DEX liquidity. Его используют Meta-Aggregator и Router. Для custom transaction или CPI это основной путь.
JupiterZ – RFQ system. Off-chain market makers конкурируют за quote и могут оплачивать transaction costs. RFQ liquidity доступна только в Meta-Aggregator, потому что market maker получает last-look execution rights, а flow требует контролируемой transaction.
Dflow и OKX добавляют сторонние routing and liquidity sources. Self-learning layer сравнивает фактическое качество, а underperforming sources может sidelining. Это уменьшает зависимость от одного engine, но создаёт operational dependency на Jupiter selection logic.
Лучший displayed quote не равен лучшему executed price. Симуляция может устареть, RFQ может не подтвердиться, pool state – измениться. Поэтому Swap V2 сравнивает execution paths, а не только теоретические outputs.
Ultra: что это было и что осталось
Ultra позиционировался как end-to-end swap engine. Клиент запрашивал order, подписывал prepared transaction и передавал её execute service. Jupiter управлял slippage estimation, priority fees, transaction landing и status polling без обязательного собственного RPC.
В Ultra использовались Juno liquidity engine, Metis, JupiterZ and third-party sources, Real-Time Slippage Estimator и Jupiter Beam для отправки. Gasless mode мог включаться для подходящих routes. Shield and token search endpoints помогали отображать сведения о tokens.
Эти идеи не исчезли полностью: managed Meta-Aggregator унаследовал competition between routers и Jupiter-controlled landing. Но Ultra V1 endpoint официально deprecated, а Ultra overview прямо указывает на Swap V2 как replacement. Новую интеграцию нужно строить по current Swap docs, а не копировать прежний Ultra example.
Deprecated не означает, что каждый historical transaction был небезопасен. Это означает отсутствие активного развития и риск несовместимости. Разработчик должен пройти migration, а пользователь – не делать вывод о current architecture из старого tutorial.
Slippage, RTSE и landing
Slippage tolerance задаёт худший приемлемый output, но слишком узкое значение повышает failures, а слишком широкое – допускает нежелательную цену. Ultra применял RTSE, который учитывал category token, historical and real-time data, volatility и failure rate.
В Swap V2 managed path Jupiter оптимизирует slippage и priority fees в execution pipeline. Это сервисная оценка, не гарантия. Rapid market move, bad token mechanics или congestion всё равно приводят к failure либо execution у лимита.
Jupiter Beam и собственные senders уменьшают latency и скрывают transaction до отправки от части публичной инфраструктуры. Однако Solana не обещает включение в конкретный slot. Validator path, account contention и block limits остаются.
Для защиты от неверного ожидания minimum received полезно различать slippage и price impact. Split route может иметь хороший общий quote, но включает несколько independent pools и больше мест отказа.
Platform fees и gasless
Meta-Aggregator включает Jupiter platform fee, размер которой зависит от pair category. Quote возвращает fee amount, bps и mint, поэтому фактический параметр нужно читать перед signing. Router path не использует ту же platform fee model, хотя integrator может добавить собственную fee.
Gasless не означает, что Solana operation бесплатна. Fee payer меняется: расходы покрывает market maker, Jupiter или integrator при выполнении условий. Rent для нового associated token account также должен кто-то оплатить. Пользователь всё равно подписывает разрешённую transaction.
Любая prepared transaction требует inspection. Подмена сайта способна добавить перевод, закрытие account или чужой authority. Hardware wallet может показывать blind signing, поэтому domain и transaction simulation имеют особое значение.
Token safety
Solana token identified by mint address, а ticker и logo легко копируются. Aggregator способен найти route для вредоносного или неликвидного token, если рынок существует. Наличие token в search не является endorsement.
Token-2022 extensions могут включать transfer fees, transfer hooks, freeze or permanent delegate features. Они меняют received amount и control model. Перед swap нужно проверять mint, authorities, extensions и liquidity distribution.
Общий порядок проверки описан в материале о том, как проверить контракт токена с одинаковым тикером. Принцип одинаков для Solana: адрес mint важнее символа, хотя инструменты explorer отличаются от EVM.
Jupiter Perpetuals
Perpetuals – отдельный on-chain program, а не режим aggregator route. Trader открывает long или short с collateral, платит position and borrowing costs и рискует liquidation. Price feeds and keepers определяют execution и состояние позиции.
JLP pool предоставляет liquidity. Он держит basket custodies и учитывает assets under management за вычетом резервов для выплат trader profits. JLP holder получает exposure к assets, fees и противоположной стороне aggregate trader PnL.
Pool account содержит custodies, AUM, limits, fee parameters и target weights. Deposit или withdrawal может быть ограничен, если действие уводит token composition за допустимый buffer. Это защищает pool balance, но означает, что выход не всегда доступен в желаемом asset и размере.
JLP не равен JUP. JLP – liquidity token perpetual pool, JUP – governance and ecosystem token. Доходность JLP не гарантирована: падение basket assets или крупная прибыль traders уменьшает value. Риски leveraged trading удобно сравнить с обзором dYdX, где используется другая chain and order-book architecture.
Другие продукты
Limit orders, DCA, token launch tools, lending, mobile products и bridge-like interfaces расширили Jupiter за пределы swap aggregation. Каждый product использует отдельный set of programs, oracles, keepers and permissions.
Единый brand не создаёт единый insurance pool. Ошибка Perpetuals не тождественна ошибке Metis, а lending collateral risk не равен swap route risk. Перед action нужно определить contract program и source of liquidity.
JUP
JUP – governance and ecosystem token Jupiter. Genesis supply составлял 10 миллиардов tokens и был разделён поровну между team-controlled and community-controlled allocations. В январе 2025 года после community decision были уничтожены 3 миллиарда JUP, поэтому total supply уменьшился примерно до 7 миллиардов.
Community side финансировала Jupuary distributions, active staking rewards, DAO initiatives and grants. Team side включает contributors, strategic reserve и liquidity needs. Tokens находятся в multisigs и vesting schedules, поэтому circulating supply растёт неравномерно.
JUP используется для голосования, delegation и участия в DAO. Active staking rewards исторически стимулировали voting, но incentive program и конкретные epochs меняются. Нельзя рассчитывать вечную fixed yield.
Protocol revenue, buybacks and community decisions влияют на narrative value accrual, однако token не является прямой долей во всех products. Нужно читать approved proposal and execution, а не предполагать автоматическую передачу каждой fee holder.
Управление
Jupiter DAO голосует по ecosystem proposals, funding, launch decisions and token policy. Holders lock or stake JUP in governance system, delegates аккумулируют voting power. Multisigs исполняют часть решений и хранят reserves.
DAO governance сосуществует с быстрым product development core team. Routing algorithms, APIs and interface updates не проходят отдельное token vote на каждый release. Это практично для engineering, но показывает границу между economic governance и operational control.
Крупные delegates, team reserves and voter apathy создают concentration risk. Community audits and on-chain multisig transactions улучшают transparency, но пользователю нужно отличать proposal discussion от passed vote и фактической transaction.
История
Jupiter появился в 2021 году как Solana swap aggregator. Первоначальная задача была узкой: собрать fragmented liquidity и дать wallet один route. По мере роста network Metis стал основным routing engine, появились limit orders, DCA и developer APIs.
Perpetuals и JLP расширили Jupiter в leveraged trading. В январе 2024 года состоялся launch JUP and first Jupuary distribution, после чего заработала DAO governance. В 2024–2025 годах Ultra развивал managed execution, JupiterZ добавил RFQ liquidity, а команда расширила mobile and product ecosystem.
В январе 2025 года 3 миллиарда JUP были burned. Затем Ultra прошёл несколько iterations. К 2026 году developer stack консолидирован в Swap V2: Meta-Aggregator для managed execution и Router для raw instructions. Старый Ultra V1 теперь documented as deprecated.
Команда
Проект возглавляет сооснователь под псевдонимом Meow. Jupiter начинался небольшой командой Solana builders, связанной с прежней Mercurial ecosystem, затем вырос через hiring и acquisitions. Публичные communications называют также product and engineering leads, но состав быстро меняется.
Псевдоним основателя не отменяет публичной accountability, однако пользователю не следует приписывать ему неподтверждённую юридическую биографию. Проверять нужно contracts, multisigs, audits, DAO votes и историю releases.
Jupiter team управляет routing infrastructure, APIs, landing services and interfaces. Независимые DEX teams поставляют liquidity, market makers участвуют в RFQ, а JUP delegates – в governance. Это распределённая ecosystem, но core execution services остаются важной точкой operational concentration.
Что проверить перед swap
- Mint addresses обоих tokens и Token-2022 extensions.
- Какой path выбран – Meta-Aggregator или custom Router integration.
- Route plan, minimum received, platform fee и price impact.
- Fee payer, создание token accounts и содержимое transaction.
- Окончательный signature status в explorer, а не только сообщение интерфейса.
Основные риски
Swap layer зависит от source pools, token programs, routing quality, simulations, RPC and landing infrastructure. Multi-hop route расширяет поверхность отказа. RFQ добавляет market maker and last-look mechanics, managed API – availability and policy risk.
Perpetuals добавляет liquidation, oracle, keeper, JLP composition and trader PnL risks. JUP несёт unlocks, governance concentration, incentive changes and market volatility. Ни один из этих risks не компенсируется автоматически успешностью другого product.
Solana congestion, account contention или validator incident способны задержать inclusion. Privacy of managed sender снижает отдельные MEV vectors, но не гарантирует лучшую цену. Поддельные Jupiter sites особенно опасны из-за привычки пользователей быстро подписывать готовую transaction.
Итог: современный Jupiter – это Swap V2 с конкурирующими routing engines и отдельным Router path, а не только прежний Ultra. Aggregator объединяет fragmented Solana liquidity, Perpetuals использует собственный JLP pool, а JUP отвечает за governance and ecosystem coordination. Пользователю нужно оценивать конкретный product, route and contract, а не доверять бренду как единому механизму.
