Оракулы на TON: RedStone, Pyth и альтернативы в 2026

Оракулы — это инфраструктура, которая поставляет ценовые данные с off-chain рынков в on-chain смарт-контракты. Без них невозможны лендинг, perp-DEX, опционы, страхование и любая логика, опирающаяся на «сколько сейчас стоит TON в USDT». На Ethereum рынок оракулов зрелый — Chainlink, Pyth, RedStone, API3 покрывают тысячи активов. На TON ландшафт сложился позже: основные провайдеры пришли в 2024 году, и в 2026 у нас есть рабочая, но менее насыщенная сцена.

Разбираемся, кто реально работает на TON, как устроены push и pull модели, какие протоколы какие оракулы используют, и где главные риски манипуляций.

Зачем нужны оракулы

Любая DeFi-логика, привязанная к цене, нуждается в источнике этой цены on-chain. Примеры:

• Лендинг (EVAA, DAOlama). Чтобы оценить залог (например, в TON или jUSDT) и понять, нужно ли ликвидировать позицию.
• Perpetual-DEX (Storm Trade). Mark price для расчёта PnL открытых позиций и инициации ликвидаций.
• Опционы и структурные продукты. Settlement по цене на момент истечения.
• Стейблкоины с CDP. Оценка collateral ratio.
• Insurance / страхование от depeg. Триггер выплат.

Сама блокчейн-сеть про off-chain цены ничего не знает. Оракул — это мост.

Кто работает на TON в 2026

Основные имена:

1. Pyth Network. Запустился на TON в конце 2024 года. Pull-модель: цены подписываются провайдерами off-chain, потребитель «подтягивает» их в момент использования. Покрытие — основные пары (TON/USD, USDT, BTC, ETH, крупные jetton’ы), latency — суб-секундная (в момент подтягивания), частота обновлений у источника — около 400 мс.
2. RedStone. Интеграция с TON произошла в 2024 году. Тоже pull-модель с атестацией: подписанные ценовые пакеты доставляются on-chain через специальный сервис, потребитель верифицирует подпись. Особенность — поддержка большого числа long-tail активов через модульную архитектуру.
3. Stork. Третий заметный провайдер на TON, фокус на низкая латентность для perp-DEX. Меньшая распространённость, но используется как secondary feed в ряде интеграций.
4. Нативные / протокольные оракулы. Часть протоколов запускает собственные оракулы под свою логику. Пример — pool-based TWAP-оракулы (читают цену из ликвидных DEX-пулов STON.fi / DeDust). Это дёшево и нативно, но уязвимо к манипуляции при низкой ликвидности.

Также используется multi-oracle aggregation: лендинг-протокол берёт цены из 2–3 источников и применяет median, что снижает риск зависимости от одного провайдера.

Push vs pull: как это работает

Две основные архитектуры:

Push-модель

Оракул сам публикует цены на цепь по расписанию (каждые N секунд) или при значимом изменении (heartbeat / deviation threshold).

• Плюсы. Цена всегда доступна on-chain, не нужно вызывать дополнительные сообщения.
• Минусы. Дороже в долгосрочной перспективе — каждый update стоит газа, оплачиваемого либо протоколом, либо оракулом. На TON это особенно заметно из-за форвард-fee на каждое сообщение.

Chainlink — классический пример push-модели. На TON push-оракулы реализуются проще для нативных protocol-specific решений, чем для универсальных провайдеров.

Pull-модель

Цена хранится off-chain в виде подписанных пакетов. Потребитель (например, EVAA при ликвидации) сам подтягивает свежую цену в момент, когда она ему нужна, и платит за этот update.

• Плюсы. Дёшево в случае редких обращений. Цена всегда «свежая» на момент запроса.
• Минусы. Усложняет UX — каждая операция требует дополнительного шага. Latency между подписью off-chain и подтверждением on-chain создаёт окно для front-run.

Pyth работает именно так. RedStone использует вариант с атестацией: пакеты подписаны валидаторами сети, и on-chain проверяется только подпись, не источник цены.

Какие протоколы какие оракулы используют

Реальная картина в TON DeFi на май 2026:

Не все протоколы используют один и тот же стек, и это нормально — у разных задач разные требования к латентности, точности и устойчивости.

Манипуляции оракулом: где главные риски

Манипуляция оракулом — один из самых частых классов exploit’ов в DeFi. Базовый паттерн:

1. Атакующий находит низколиквидный jetton, котирующийся в оракуле через DEX TWAP.
2. Делает крупную покупку, пампая цену в пуле.
3. TWAP постепенно подтягивается к новой «цене».
4. Атакующий вносит этот jetton как залог на лендинг-протоколе и берёт кредит против раздутой оценки.
5. Сливает залог, не возвращает кредит. Протокол списывает плохой долг.

Защитные меры, применяемые на TON:

• Multi-source median. Лендинг использует 2–3 независимых feed’а и берёт медиану. Атаковать одно ценовое окно из двух мест сложнее.
• Time-Weighted Average Price (TWAP). Цена усредняется по окну (обычно 5–30 минут), что делает мгновенный pump бесполезным — приходится держать цену долго и тратить капитал.
• Циркул-брейкеры. При резком отклонении (например, цена выросла на 30% за минуту) протокол приостанавливает использование feed’а до подтверждения из других источников.
• Списки разрешённых активов. EVAA и DAOlama поддерживают как залог только активы с глубокой ликвидностью на основных DEX. Малоликвидные long-tail jetton’ы либо не принимаются, либо принимаются с очень высоким haircut.

Пример: ликвидация на EVAA через Pyth feed

Условный сценарий, чтобы понимать, как всё работает в цепочке:

1. Алиса внесла 10 000 TON как залог на EVAA, заняла 30 000 USDT.
2. Цена TON падает с $5.50 до $4.20 — её collateral ratio проседает.
3. Бот-ликвидатор подтягивает свежую цену из Pyth (pull): off-chain пакет с подписью передаётся в смарт-контракт EVAA.
4. EVAA верифицирует подпись и timestamp пакета (например, не старше 60 секунд).
5. Подтверждается: позиция Алисы подпадает под ликвидацию.
6. Ликвидатор погашает часть долга и забирает залог с дисконтом (например, 5%).

Здесь Pyth выступает как «истина в последней инстанции» о цене TON в момент ликвидации. Если бы Pyth дал устаревшую цену или была бы возможность подсунуть фейковый пакет — ликвидация прошла бы некорректно. Поэтому верификация подписи и timestamp критична.

TWAP vs spot: когда что использовать

• Spot price. Текущая мгновенная цена. Дёшево, актуально, но манипулируемо за один блок.
• TWAP (Time-Weighted Average Price). Среднее за окно (5, 15, 30 минут). Дороже в вычислении, но манипулировать намного сложнее — нужно держать цену атаки в течение всего окна, что требует капитала.

Эмпирическое правило в TON DeFi:

Что это значит для пользователей

Практические выводы:

1. Если вы кладёте залог в лендинг — проверьте, какой оракул использует протокол. EVAA, DAOlama, Storm Trade публикуют это в документации.
2. Если используете long-tail jetton как залог — будьте осторожны: oracle может не работать как ожидаете в моменте резкого движения цены.
3. Если открываете leveraged-позицию — обращайте внимание на «mark price» в интерфейсе. Это и есть цена оракула, по которой вас будут ликвидировать, а не ваш entry.
4. Если строите свой протокол — не запускайте без multi-source feed’а и без TWAP-санити-чек. История EVM полна exploit’ов на slipshod oracle integration.
5. Если видите аномально дёшево / дорого свопающийся jetton — это может быть либо реальный листинг, либо атака на чей-то oracle. Проверяйте через несколько источников.

Сравнение оракулов: TON vs EVM

TON-сцена оракулов меньше и моложе, но опирается на проверенных глобальных игроков (Pyth и RedStone уже зарекомендовали себя на других сетях).

Латентность и финальность: незаметная, но критичная пара

Оракул — это не только «откуда цена», но и «насколько свежая». Здесь важно различать:

• Latency источника. Сколько проходит от изменения цены на off-chain рынке (Binance, Coinbase) до публикации подписанного пакета. Pyth даёт около 400 мс.
• Latency доставки on-chain. Сколько проходит от подписи до фактического использования в смарт-контракте. На TON это плюс время на forward-сообщение + блок (≈ 5 секунд). На Ethereum — один блок (12 секунд) для push, или пол-блока для pull.
• Финальность оракула. Когда цена считается «принятой» on-chain и не может быть переписана. На TON финальность сообщения наступает после inclusion в block + cross-shard confirmation.

В сумме latency «жизненного цикла» цены на TON составляет ориентировочно 5–10 секунд от рыночного движения до возможности использования в смарт-контракте. Для лендинга это нормально, для high-frequency perp — на грани, для арбитража — недостаточно.

Эта особенность объясняет, почему Storm Trade и подобные платформы вынуждены использовать сложные комбинации oracle-feed’ов и спот-цен с DEX, плюс mark-price smoothing, чтобы не давать ботам атаковать через oracle latency.

Регулирование и прозрачность: чего ждать в 2026

В EU MiCA-стиль регулирования вводит требования к «benchmark providers» — оракулы могут оказаться в этой категории. Pyth и RedStone уже работают над комплаенсом: публикация методологий, аудит ценовых пакетов, прозрачность источников. Для пользователя это значит, что в среднесрочной перспективе оракулы перестанут быть «чёрными ящиками».

Для протоколов на TON это создаёт новый critère при выборе провайдера: насколько готов оракул соответствовать регуляторным требованиям клиентских юрисдикций. Это не блокер, но это фактор, который будет проявляться через 1–2 года в зрелых лендинг-продуктах с европейской пользовательской базой.

Заключение

Оракулы — это та инфраструктура, без которой DeFi не работает, и одновременно одна из самых частых точек отказа всей системы. На TON в 2026 рынок оракулов сложился: Pyth и RedStone обеспечивают базовое покрытие, Stork добавляет low-latency, а нативные DEX-TWAP закрывают long-tail с разумной осторожностью.

Для пользователя главное правило простое: знайте, какой оракул вы доверяете когда оставляете залог или открываете leveraged-позицию. Прозрачность здесь — лучший friend.

Для разработчика — multi-source, TWAP-санити, circuit-breakers и осторожность с long-tail активами. История EVM показала, что 60% эксплойтов лендинга связаны с oracle-манипуляциями — TON не имеет иммунитета.

Для дальнейшего чтения смотрите наши обзоры EVAA, Storm Trade, DAOlama и метрики on-chain активности TON.