RedStone Oracles – модульная инфраструктура данных для DeFi. Проект отделяет сбор и проверку информации от способа её доставки в блокчейн. Один и тот же подписанный набор цен можно передать по pull-модели внутри пользовательской транзакции, регулярно записывать через push-relayer или транслировать с высокой частотой для рынков деривативов.
Модульность важна не как маркетинговый термин, а как экономический выбор. Кредитному рынку нужна предсказуемая on-chain цена, perpetual DEX – низкая задержка, а редкому LST – специализированная методика расчёта. RedStone пытается обслуживать эти случаи общей data layer, не заставляя каждую сеть хранить каждое обновление.
Сбор и обработка данных
Система получает значения с централизованных и децентрализованных бирж, агрегаторов, протоколов и других источников. Узлы нормализуют форматы, проверяют выбросы и формируют data packages. Каждый пакет содержит значение, timestamp, идентификатор feed и подпись поставщика.
Подписанные пакеты проходят независимый data distribution layer и доступны relayers или пользователям. Целевой контракт не обязан доверять серверу, который передал байты: он проверяет подписи разрешённых nodes, время сообщения и требуемое число источников. При этом список подписантов и правила агрегации задаются конфигурацией, поэтому verifier не доказывает качество исходной методики.
В отличие от отдельной оракульной L1, RedStone не требует, чтобы все цены сначала прошли консенсус собственного блокчейна. Это сокращает задержку и позволяет менять канал доставки, но переносит акцент на управление ключами, разнообразие providers и корректность consumer contract.
Pull-модель RedStone Core
В RedStone Core данные передаются вместе с транзакцией dApp. Специальный payload добавляется в calldata, а библиотека consumer извлекает пакеты, проверяет подписи и агрегирует значения во время исполнения. После проверки приложению доступна цена, необходимая именно для этой операции.
Преимущество – не нужно постоянно платить за запись сотен feed в каждую сеть. Расход возникает, когда пользователь действительно взаимодействует с контрактом. Такое устройство подходит long-tail assets и приложениям с нерегулярными вызовами.
Недостаток – цена может не существовать в storage до начала транзакции. Frontend, keeper или backend должен получить правильный payload и приложить его без повреждений. Смарт-контракт обязан ограничить возраст данных и число подписей. Pull снижает стоимость публикации, но не освобождает интегратора от проверки.
RedStone Classic и push feeds
Classic – push-модель с привычным price feed contract. Relayer следит за данными и обновляет storage при достижении порога отклонения или heartbeat. Приложение читает последнее значение без добавления отдельного пакета к каждому вызову.
Это удобно для кредитования и совместимости с существующими EVM-интерфейсами. Компромисс состоит в расходах relayer и периодичности записи. Между обновлениями on-chain цена может отставать от рынка, поэтому heartbeat, deviation threshold и аварийные пределы должны соответствовать волатильности collateral.
Push feed RedStone не является копией Chainlink: сети поставщиков, процесс формирования пакетов и механизмы доставки различаются. Совпадение интерфейса чтения лишь облегчает интеграцию.
RedStone X и низкая задержка
RedStone X ориентирован на perpetual markets и другие приложения, которым нужно подтверждать цену непосредственно при исполнении ордера. Подписанные данные доставляются по optimized path, а контракт проверяет их в контексте транзакции. В зависимости от интеграции используются специализированные relayers и последовательность commit, execute или verify.
Низкая задержка уменьшает разрыв между off-chain рынком и расчётом позиции, но повышает требования к доступности инфраструктуры. Если update не пришёл, безопасная реакция – остановить чувствительную операцию, а не использовать произвольно старое значение. Поэтому fast feed должен иметь fallback и чёткие правила degraded mode.
Специализированные feeds
RedStone уделяет много внимания LST, LRT, yield-bearing stablecoins, Bitcoin liquid staking и RWA. Для таких активов простой spot price часто недостаточен. Нужны exchange rate, стоимость underlying collateral, состояние withdrawal queue, discount на вторичном рынке и защита от временного depeg.
Например, стоимость liquid staking token можно оценивать по внутреннему conversion rate или по доступной ликвидности обмена. Первый показатель медленнее реагирует на рынок, второй подвержен краткосрочным выбросам. Конкретная методика является частью риска feed и должна соответствовать задаче протокола, такого как Pendle.
Поддержка редких активов даёт RedStone конкурентную нишу, но увеличивает методологическую нагрузку. Чем сложнее underlying product, тем труднее построить единый показатель, устойчивый к манипуляции и техническому сбою.
Роли участников
Data providers собирают и подписывают значения. Distribution layer раздаёт пакеты. Relayers обновляют push contracts или обслуживают специализированную доставку. Consumer contracts проверяют подписи и применяют feed. Протокол-интегратор выбирает thresholds, staleness limits и аварийные меры.
Этот набор ролей не полностью permissionless. RedStone отвечает за допуск providers, конфигурации и программные релизы. Пользователь должен смотреть не только на число поддерживаемых сетей, но и на реальное число независимых подписантов конкретного feed.
EigenLayer AVS и экономическая безопасность
RedStone добавил экономический слой через Actively Validated Service в EigenLayer. Владельцы RED могут restake токен и делегировать operator, который участвует в защите oracle infrastructure. Доступно и liquid representation mRED через EigenPie.
Restaking должен связать нарушение правил с финансовым залогом. Однако наличие stake не заменяет криптографическую проверку и не гарантирует компенсацию каждому dApp. Практический эффект зависит от того, какие нарушения объективно доказуемы, как действует slashing contract и какую долю безопасности действительно обеспечивает AVS.
mRED добавляет отдельный smart-contract, liquidity и depeg risk. Его цена может отличаться от RED, а возможность выхода зависит от EigenPie и EigenLayer. Награды staking не являются фиксированной доходностью и могут меняться вместе с программой incentives и спросом на oracle services.
RED и токеномика
RED – ERC-20 token с максимальным предложением 1 млрд, закреплённым в non-upgradeable contract. При запуске в обращение поступило 28%, а 72% оставались заблокированы. График распределения рассчитан примерно на четыре года, поэтому разблокировки продолжают влиять на рынок.
Распределение: 31,7% – early backers, 24,3% – ecosystem и data providers, 20% – core contributors, 10% – protocol development, 10% – community and genesis, 4% – Binance Launchpool. Суммарные 51,7% для backers и contributors создают заметную концентрацию даже при vesting.
Основное применение RED – staking и экономическая защита oracle network. Токен не даёт автоматического права на revenue каждого feed и не является долей компании. План устойчивой экономики предполагает вознаграждение security participants из платежей пользователей данных, но фактический поток зависит от коммерческих договоров и работы AVS.
Управление
На старте RED не получил всеобъемлющую on-chain DAO с контролем каждого обновления. Значительная часть операционных решений остаётся у RedStone Distributed Data Association, core team и контрактных администраторов. Staking создаёт economic role, но не равен голосованию по всем конфигурациям.
Для оценки governance важны права upgrade, список multisig signers, процесс добавления providers, изменение thresholds и реакция на ошибочную цену. Даже если token distribution становится шире, технические ключи могут оставаться более концентрированными.
История
RedStone основали в 2021 году в инкубационной программе, связанной с Arweave. Первые версии использовали постоянное хранение подписанных данных и модульную доставку. В январе 2023 года команда объявила первый mainnet deployment, после чего расширила интеграции EVM и non-EVM chains.
В 2024 году фокус сместился к LST, LRT и BitcoinFi, а также к fast feeds для derivatives. В феврале 2025 года была опубликована tokenomics RED, затем состоялся запуск токена и staking через EigenLayer. Текущая версия сочетает Core pull, Classic push и X, тогда как ранние названия и experimental delivery paths нельзя считать отдельными действующими продуктами без проверки конкретной интеграции.
Команда
RedStone основали Jakub Wojciechowski и Marcin Kaźmierczak. Wojciechowski занимает должность CEO, Kaźmierczak – COO. Разработку и экосистему поддерживают RedStone core contributors и RedStone Distributed Data Association.
Проект сотрудничает с providers, operators и интеграторами, но партнёрство не означает совместную ответственность за каждую цену. Также RedStone Oracles не следует путать с Redstone, OP Stack chain от Lattice: это разные проекты с похожим названием.
Применение
Pull feeds подходят vaults, exotic collateral и приложениям с нерегулярными транзакциями. Push feeds удобны для lending markets. X предназначен для high-frequency execution и liquidations. Один протокол может использовать разные режимы для разных активов, но должен согласовать единые fail-safe rules.
Модульная доставка особенно полезна на новых rollups, где постоянный push дорог или infrastructure незрела. При этом перенос feed в ещё одну сеть увеличивает surface area: новый verifier, bridge path, relayer и upgrade process становятся дополнительными точками отказа.
Основные риски
- Data source risk. Подписанное значение может быть ошибочным или основанным на слабом рынке.
- Signer concentration. Конкретный feed может иметь меньше независимых providers, чем вся сеть в целом.
- Delivery risk. Pull payload, push relayer или fast path способны стать недоступными.
- Methodology risk. LST, LRT и RWA требуют сложных моделей, которые могут неверно отразить стресс.
- Integration risk. Неправильный threshold, timestamp или fallback создаёт уязвимость в dApp.
- Administrative risk. Конфигурации и обновления зависят от core organization и multisig.
- Restaking risk. EigenLayer AVS добавляет operator, slashing и delegation risks.
- Liquid staking risk. mRED зависит от стороннего protocol и собственной ликвидности.
- Unlock risk. Большие доли early backers и contributors продолжают разблокироваться.
- Smart-contract risk. Ошибка verifier или adapter может сделать корректные data packages бесполезными.
Итог
RedStone разделяет производство данных и доставку, позволяя приложению выбрать Core pull, Classic push или X. Это снижает лишние расходы и помогает обслуживать сложные активы, но не отменяет доверие к providers, конфигурациям и off-chain инфраструктуре. RED добавляет staking через EigenLayer, а не превращает каждый feed в полностью permissionless рынок. Перед интеграцией важнее всего изучить состав подписантов конкретной цены, путь доставки, fallback и реальные права администраторов.
