Оракулы и NAV в RWA: источники данных, точность, обновления и отказоустойчивость

Какие данные нужны RWA и зачем

RWA использует пять больших групп данных:

1) Рыночные цены базовых активов

1. Для товарных RWA: спот/фиксинг (золото/серебро).
2. Для долговых/денежных инструментов: курсы, доходности, индексы.
3. Зачем: оценка чистой стоимости, справедливая цена вторички.

2) NAV (Net Asset Value)

1. Для фондовой/портфельной модели и «сейфов» Erc 4626.
2. Публикуется по расписанию (день/неделя/квартал).
3. Зачем: подписка/выкуп по справедливой базе, расчёт доходности.

3) Корпоративные события

1. Купоны/дивиденды, амортизация, buyback, сплиты/конверсии.
2. Зачем: знать, кому платить и сколько (record date), и как меняются доли.

4) Резервы/аттестации

1. Для товарных RWA: наличие металла/товара, серийники, локация.
2. Для кредитных пулов/недвижимости: портфель, LTV/DSCR, просрочка.
3. Зачем: проверить, что ончейн-объём соотносится с оффчейн-активами.

5) Мультичейн-метаданные

1. Где «живёт» мастер-реестр, какие сети и мосты официальные.
2. Зачем: не потерять право при переносе и корректно обрабатывать выкуп.

Как сопоставлять отчёты и ончейн — см. Как читать отчёты по RWA: NAV, резервы, аудиты и корпоративные действия — полный гид для инвестора. Про вторичку и доступ — Доступ и оборот RWA: whitelist, категории инвесторов, гео-ограничения и вторичный рынок (ATS/DEX/OTC).

Как устроен «путь данных»: от источника до смарт-контракта

Шаг 1. Источники

• Прайс-провайдеры/биржи/индексы (цены, спот/фиксинги).
• Управляющий/трансфер-агент (NAV, корпоративные действия).
• Кастоди/депозитарии/аудиторы (резервы/аттестации).

Шаг 2. Агрегация

• Медианы/взвешивания по нескольким источникам, отбрасывание выбросов.
• Согласование таймзоны и времени отсечки (UTC, end-of-day).

Шаг 3. Подписи/доказательства

• Криптографические подписи поставщиков, хэши файлов, Merkle-proof для больших реестров/списков серийников.
• Для NAV — контрольные суммы расчётов.

Шаг 4. Доставка в ончейн

• Push-оракулы (провайдер «толкает» данные в контракт по расписанию/ивенту).
• Pull-оракулы (контракт «тянет» данные у совокупности подписантов/фидов).
• Гибрид: важные события пишутся в контракт (купоны/амортизация), тяжёлые данные (полные отчёты) — оффчейн с хэшами в ончейн.

Шаг 5. Потребление

• Контракты выпуска (ERC-1400/3643) и «сейфы» (ERC-4626) используют фиды для функций расчёта и валидации.
• В интерфейсах инвестора — графики NAV/цены и календари событий.

Минимум, который должен быть ончейн: метка времени обновления, версии данных, адреса подписантов и политика отказоустойчивости (что считаем валидным, если один источник падает).

NAV: методики, обновления и верификация

NAV — это правило, а не только число. В регламенте должны быть:

• Метод оценки (для фондов — рыночные котировки; для недвижимости — доходный/DCF; для кредита — амортизированная стоимость с резервами).
• Частота/время публикации (напр., ежедневно 16:00 UTC).
• Rounding (точность, правила округления долей).
• Комиссии (включены ли management/performance в NAV).
• Валютность (в какой валюте считаем NAV и как конвертируем).

Как инвестору проверять NAV:

1. Сверить даты NAV с вашим временем подписки/выкупа (см. Редемпшн RWA: как вывести деньги или получить актив — пошаговый гид, комиссии, сроки и риски).
2. Для ликвидных бумаг — сравнить с индексом/рынком; для недвижимости — капрейты/occupancy; для кредитов — просрочку/резервы (см. Как читать отчёты по RWA: NAV, резервы, аудиты и корпоративные действия — полный гид для инвестора).
3. Если выпуск использует Erc 4626, посмотреть totalAssets, convertToShares/Assets — это ончейн-срез методики.
4. Проверить, кто подписал NAV и где зафиксирован хэш отчёта (в контракте/репозитории).

Сигналы проблем:

• NAV «по линейке», без реакции на рынок.
• Плавающее время публикации без объяснений.
• Отсутствие авторов/подписей/хэшей.
• Разрыв между NAV и фактами выплат/портфельными метриками.

Оракулы цен: медианы, фильтры и защита от манипуляций

• Модель медианы. Собираем котировки нескольких провайдеров → сортируем → берём медиану. Плюс — устойчивость к выбросам. Минус — запаздывания и игнор «ширины» рынка.

• Взвешенная медиана. Источники с лучшей историей/объёмом получают больший вес. Требуется публичная политика весов.

• Фильтры выбросов. Отбрасываем точки, которые сильно отклоняются от центральной тенденции или в «тонкие» часы.

• Защита времени. Публикация по фиксированному расписанию (например, end-of-day) снижает волатильность, но нужна политика «внеплановых апдейтов» при экстремальных событиях.

• Подписи. Каждый поставщик должен подписывать свой фид (ключ, срок действия, ротация). Контракт принимает данные только от разрешённых ключей.

• Прозрачность. Документация должна перечислять источники, методику, частоту и адреса подписантов.

Для товарных RWA сравнивайте фид со спотом/фиксингом и учитывайте премию за хранение — см. Товарные RWA (commodities): золото, серебро и другие активы — устройство, обеспечение, комиссии и риски.

Корпоративные события и снапшоты на record date

• Record date — дата «среза», кто числится держателем на момент X. В RWA действуют две модели фиксации:

1. On-chain snapshot. Контракт (или внешний сервис) фиксирует балансы на высоте блока. Прозрачно и проверяемо.
2. Offchain registry snapshot. Трансфер-агент формирует список по реестру на закрытие дня; в контракт пишется только событие и сумма.

Что важно для инвестора:

1. Дата/время record и payment/settlement.
2. Ссылка на TXID события (если выплаты ончейн).
3. Формула начисления (ставка, база, период).
4. Совпадают ли суммы в отчёте и в ончейн-логах (см. Трансфер-агент и реестр держателей RWA: как устроены корпоративные действия, выкуп и синхронизация с блокчейном).

Грязные кейсы:

1. Выплата «мимо» whitelist → контрагент не получает деньги.
2. Срез сделан по времени, но ончейн-трафик на блок выше — нужны правила тайм-алайнмента.
3. Изменение ролей/апгрейд у контракта перед выплатой (проверьте Админ-ключи и апгрейды в RWA: pause/freeze/wipe, прокси-контракты, timelock и мультисиг — полный гид).

Резервы и proof-of-reserves (PoR) для RWA

Что считаем «доказательством»:

1. Аттестация независимой стороной (аудитор/трастовый отчёт) с датой, областью охвата и оговорками.
2. Публичные серийники для металлов, их сопоставление с объёмом токенов.
3. Хэши/подписи отчёта в ончейн/репозитории.
4. Фотографии/инвентаризационные акты — как дополнение, а не замена отчёта.

Антипаттерны:

1. «Скриншоты» вместо отчётов.
2. Неподписанные PDF.
3. Отчёт без даты/области охвата.
4. Несходящиеся суммы с totalSupply.

Шаблон проверки отчётов — в Как читать отчёты по RWA: NAV, резервы, аудиты и корпоративные действия — полный гид для инвестора.

Мультичейн и мосты: как не потерять «правильность» данных

Правило №1: используйте официальные маршруты и сети (см. Мосты и мультичейн для RWA: официальные маршруты, модели перевыпуска, реестр прав и риски). Если токен «перевыпущен» в другой сети, проверьте:

1. Где master-реестр (offchain у агента или сеть X)?
2. Реплицируются ли фиды цен/NAV/событий в каждую сеть одинаково?
3. Соответствуют ли таймстемпы и высоты блоков между сетями (иначе — споры по record date)?
4. В целевой сети ваш адрес проходит Whitelist?

Риски мостов (консенсус, хранение, ликвидность, «обёртки») — подробно в Bridge Risks. Даже идеальные оракулы бессильны, если вы используете неофициальный бридж и теряете признание реестра.

Отказоустойчивость: что, если фид молчит или «врет»

Политика failover должна быть прописана заранее:

• N-of-M подписантов: если подписались хотя бы N источников — фид валиден.
• Last good value + bounds: используем последнее корректное значение в пределах «коридора» до восстановления.
• Circuit breaker: при экстремальных отклонениях — пауза ценообразования/подписок (см. Админ-ключи и апгрейды в RWA: pause/freeze/wipe, прокси-контракты, timelock и мультисиг — полный гид и Редемпшн RWA: как вывести деньги или получить актив — пошаговый гид, комиссии, сроки и риски).
• Manual attestation: уполномоченное лицо публикует подписанное заявление с расчётом, а затем «догоняет» ончейн-логи.

Для NAV-публикаций:

• Если не выпустили NAV в срок — обязателен адвайзори с причинами и ETA.
• Любой «ручной» NAV должен сопровождаться подписью и последующим сверочным отчётом.

Как инвестору проверять оракулы и NAV: пошаговый чек-лист

A. Перед входом в продукт

• Есть ли документация о фидах (источники, частота, подписи)?
• Публикуется ли NAV по расписанию? Где хэш/подпись?
• Для товара — есть ли серийники и аттестация?
• Указаны ли официальные сети/мосты?
• Видны ли админ-роли и timelock у контракта?

B. Перед подпиской/выкупом

• Понимаю cutoff и дату valuation?
• Проверил последний NAV/цену с альтернативными источниками?
• Нет ли pause/freeze и апгрейдов вокруг даты?
• Для мультичейна — фид обновляется в моей сети?

C. При аномалиях

• Расхождение NAV и рынка > X% — есть ли объяснение?
• Задержка публикации — есть ли официальный анонс?
• Несходится totalSupply и резервы — срочно в поддержку/TA.
• Снял ли я снимок (архив PDF/хэш/TXID) на время события?

Частые ошибки и как их избежать

• Опора на один источник цены. Итог — манипуляции/перебои. → Требуйте медиану/взвешивание и публичную политику.
• Игнор таймингов. Подали на выкуп после cutoff NAV → другое окно/цена. → Держите календарь, см. Редемпшн RWA: как вывести деньги или получить актив — пошаговый гид, комиссии, сроки и риски.
• Слепая вера PDF без подписи. → Ищите хэши/подписантов; сохраняйте файлы.
• Мост «мимо» официального. Потеря признания реестра → «мертвые» токены. → Только Мосты и мультичейн для RWA: официальные маршруты, модели перевыпуска, реестр прав и риски и проверка whitelist в целевой сети.
• Неучтённые комиссии и округления. Итог не бьётся. → Читайте методику NAV и правила округления, см. Как читать отчёты по RWA: NAV, резервы, аудиты и корпоративные действия — полный гид для инвестора.
• Отсутствие журналирования. Потом нечего предъявить. → Ведите архив: отчёты, TXID, скриншоты, высоты блоков.

Мини-гид по валидации данных (формулы и примеры)

1) Проверка NAV для 4626-сейфа expected_totalAssets ≈ Σ (позиции × цены) – комиссии ± округления Сверяем с ончейн totalAssets. Расхождение объясняется лагом публикации или учётной базой (до/после комиссий).

2) Проверка купонной выплаты выплата_адресу = доля_на_record × купон_за_период Сверяем сумму по реестру/контракту и фактический платёж (ончейн/фиат).

3) Проверка товарных резервов объём_металла (в унциях) ↔ totalSupply токена Проверяем серийники и хэш отчёта; допускаем техническую дельту на перемещения/плату за хранение, но не «пропасть».

4) Верификация мультичейн-события Пара burn (сеть A) ↔ mint (сеть B) с согласованным объёмом и временем. Проверяем, что адрес в B прошёл Whitelist.

Кейсы из практики

• Кейс 1. Задержка NAV, вторичка «плывёт».

Рынок ждёт ежедневный NAV в 16:00 UTC, но публикации нет. ATS уходит в дисконт. Действия: проверяем анонсы эмитента, смотрим ончейн-логи апгрейдов/паузы, удерживаемся от паник-продаж до официального апдейта. Если задержка системная — минус к довериям; ставим галочку в Red Flags.

• Кейс 2. Серийники «исчезли» из отчёта по золоту.

В новом файле — только общий тоннаж. Действия: поднимаем прошлый отчёт, сверяем totalSupply, запрашиваем у поддержки версию с серийниками и подписанным аттестатом. До разъяснений — не увеличиваем позицию.

• Кейс 3. Апгрейд контракта перед купоном.

В логах Upgraded и смена ролей. Действия: проверяем наличие timelock, публикацию новой реализации, ретест событий Paused/Unpaused. Если апгрейд «тихий» — фиксируем как риск управления, оцениваем влияние на наш процессинг.

• Кейс 4. Кросс-чейн перенос перед выкупом.

Эмитент принимает заявки в сети X, наши токены — в Y. Действия: официальный мост → тест → проверка whitelist в X → заявка на выкуп. В отчёте должны появиться обе TXID и дата отсечки в X (см. Мосты и мультичейн для RWA: официальные маршруты, модели перевыпуска, реестр прав и риски).

FAQ

Нужен ли ончейн-оракул, если NAV приходит из PDF? Да. Минимум — хэш/подпись отчёта в контракте и ончейн-метаданные (время, версия). Иначе нельзя воспроизвести историю.

Почему NAV не совпадает с моей «ручной» оценкой? Методика (до/после комиссий), время отсечки, разные источники цен, округления. Сверьте правила и тайминг.

Можно ли торговать «по NAV»? Нет. NAV — база внебиржевых расчётов (подписка/выкуп). На вторичке цена = спрос/предложение ± премии/дисконты.

Что надёжнее: on-chain snapshot или offchain registry? Зависит от модели выпуска. Для security-подобных RWA приоритет у реестра, но on-chain snapshot — сильное доказательство и лучший UX.

Как понять, что оракул «ломают»? Резкие скачки вне рынка, расхождения между сетями, публикации без подписей, смена источников без анонса, частые emergency-апдейты — заносим в Red Flags.

См. также (серия RWA)

• Как читать NAV/резервы/отчёты
• Трансфер-агент и реестр держателей
• Редемпшн RWA
• Мосты и мультичейн
• Риски мостов для RWA
• Админ-ключи и апгрейды
• Приватный кредит on-chain
• Недвижимость on-chain
• Товарные RWA