UMA – протокол optimistic verification для утверждений, которые смарт-контракт не может проверить самостоятельно. Вместо непрерывной публикации ответа оракул исходит из предположения, что заявление верно, если никто не оспорил его в заданное время. Спор передаётся владельцам staked UMA, которые определяют результат через Data Verification Mechanism.
Такой дизайн подходит prediction markets, bridge assertions, insurance claims и governance actions, где запросы происходят нерегулярно и не всегда сводятся к числовой цене. Он экономит работу в обычном случае, но требует достаточного bond, активных monitors и однозначной формулировки.
Оптимистический принцип
Любой разрешённый asserter публикует claim и вносит bond. Затем начинается liveness period. Если dispute не поступил, утверждение считается истинным и consumer contract продолжает действие. Оракул не доказывает факт заранее – он создаёт экономическое окно, в котором ложь должна быть замечена.
Disputer блокирует встречный bond и отправляет спор в более медленный DVM. После решения правильная сторона возвращает залог и получает часть проигранного bond, а неверная теряет средства. Размер залога должен превышать возможную выгоду от лжи с учётом вероятности обнаружения.
Модель работает только при наблюдаемости. Если claim опубликован в малозаметной сети, liveness слишком короткий или мониторинг отключён, экономически неверное утверждение может пройти без проверки. Optimistic security – не отсутствие trust, а распределение ответственности между asserter, disputer и voters.
Optimistic Oracle V2
OOv2 использует request-propose-dispute flow. Requester запрашивает значение для identifier, timestamp и ancillary data. Proposer предлагает ответ, а disputer может его оспорить. Без спора result становится доступен после liveness, со спором – после голосования DVM.
Эта версия хорошо подходит числовым данным и уже существующим identifiers. Prediction markets используют ancillary data, чтобы описать источник и критерии разрешения. Чем точнее формулировка, тем меньше пространства для разных добросовестных трактовок.
OOv2 остаётся действующим. Его не следует называть устаревшим только из-за появления V3: у версий разные interfaces и типичные сценарии, а ряд production applications сохраняет V2.
Optimistic Oracle V3
OOv3 упрощает произвольные assertions. Asserter вызывает contract, передаёт текстовое claim, callback recipient, escalation manager, liveness, currency и bond. Oracle создаёт assertion ID. После settlement callback сообщает consumer, признано ли утверждение истинным.
V3 удобна для фразы вроде «событие произошло по таким-то правилам», а не только для цены в определённый timestamp. Но arbitrary bytes не делают смысл объективным. Разрешение зависит от выбранного identifier, ancillary context и того, смогут ли voters одинаково интерпретировать evidence.
С декабря 2025 года для новых assertions V3 используется identifier ASSERT_TRUTH2. Старый ASSERT_TRUTH deprecated с 15 декабря. Функция assertTruthWithDefaults жёстко содержит старый identifier и теперь всегда отклоняется. Это действующая migration boundary, а не рекомендация на будущее.
Escalation Managers
Escalation Manager – дополнительный contract, меняющий правила конкретного assertion. Он может ограничить круг asserters или disputers, задать собственный arbitration, блокировать disputes либо решить, учитывать ли финальный ответ oracle. Это позволяет адаптировать UMA к приложению.
Гибкость снижает permissionlessness. Если manager разрешает disputes только whitelist или способен отбросить DVM result, безопасность уже определяется его кодом и администратором. Пользователь должен изучать не только адрес Optimistic Oracle, но и параметры каждого assertion.
Managed escalation полезна для phased rollout и специализированных рынков, однако её нельзя рекламировать как полностью trustless resolution. Чем больше полномочий у manager, тем меньше экономическая защита общего DVM.
Data Verification Mechanism 2.0
DVM – арбитраж последней инстанции. Владельцы UMA stake токены и голосуют в commit-reveal rounds. В commit phase участник отправляет hash ответа и secret salt, не раскрывая выбор. В reveal phase публикует ответ и salt, позволяя контракту проверить commitment.
Текущая базовая длительность – 24 часа на commit и 24 часа на reveal. Правильные активные voters получают rewards, а не проголосовавшие, не раскрывшие vote или оказавшиеся на проигравшей стороне могут быть slashed. Перераспределение stake создаёт стимул искать Schelling point – наиболее обоснованный общий ответ.
DVM 2.0 использует slashing и delegation. Staker может передать voting operations delegate, сохраняя экономический риск. Это удобно для пассивного holder, но концентрация delegation у нескольких профессиональных voters создаёт политическую и операционную зависимость.
Некоторые proposals проходят Governance Approved Proposal process. DVM способен разрешать contract upgrades и emergency actions, поэтому атака на голосование затрагивает не только отдельный market. Economic security должна быть выше потенциальной прибыли от corrupting oracle.
Bond, liveness и экономика спора
Bond выбирается в currency, разрешённой для assertion. Слишком маленький залог делает ложь дешёвой; чрезмерный мешает честным участникам и снижает число monitors. Liveness должен дать время обнаружить claim и собрать evidence, но длинное окно задерживает settlement.
У currency есть собственные риски. Документация UMA отдельно предупреждает о blacklistable tokens: если issuer заморозит адрес Optimistic Oracle, возврат bond может стать невозможным и заблокировать settlement. Stablecoin удобен как единица расчёта, но добавляет административный риск эмитента.
Reward для proposer или disputer должен покрывать gas, капитал и исследование. Нельзя предполагать, что altruistic watcher будет проверять каждый рынок. Applications часто используют bots и специализированные monitoring services.
UMA и tokenomics
UMA – governance и security token DVM. Он не является автоматической долей fee Optimistic Oracle. Токен блокируется в staking contract, даёт voting power и подвергается slashing в зависимости от участия и correctness.
При запуске было создано 100 млн UMA. Первоначально 48,5% направили founders, early contributors и investors, 35% – developer and user incentives, 14,5% – future token sales, 2% – initial Uniswap listing. Эти категории описывают genesis distribution, а не текущие балансы.
Supply динамический. Актуальная документация указывает базовую инфляцию 0,05% total supply, распределяемую между active correct voters. Реальная yield зависит от participation, slashing и параметров governance. Старые fixed reward programs и доходности нельзя переносить на 2026 год.
Security DVM зависит от рыночной стоимости staked UMA относительно value at risk. Рост числа защищаемых приложений без соответствующего роста stake может сделать атаку экономически привлекательнее. Одновременно высокая инфляция ради staking размывала бы holders, поэтому governance балансирует безопасность и dilution.
Управление
UMA holders голосуют за protocol upgrades, price identifiers, contract registrations и treasury decisions. Голосование DVM одновременно служит dispute resolution и governance mechanism. Это связывает техническую корректность с token politics.
Emergency proposals могут действовать быстрее обычного процесса. Такой механизм нужен при уязвимости, но повышает роль multisig и core contributors, которые готовят изменения. Проверяемая on-chain транзакция не гарантирует широкого общественного обсуждения.
Применение
Prediction markets используют UMA, чтобы разрешать исходы событий. Bridge и intent protocols могут утверждать, что перевод или fill произошёл в другой сети. Insurance products проверяют событие страхового случая. Governance integrations вроде oSnap связывают off-chain Snapshot vote с исполнением on-chain через optimistic assertion.
Across использует UMA для проверки межсетевых состояний и settlement. При работе в Arbitrum, Optimism и других сетях важно учитывать время публикации assertions и bridge finality. Optimistic Oracle проверяет claim, но не устраняет smart-contract risk самого приложения.
UMA не заменяет price feeds общего назначения. Для частого ETH/USD приложения обычно используют специализированный oracle вроде Chainlink. UMA сильнее там, где вопрос редкий, спорный или содержит произвольное условие.
История
UMA основали в 2018 году как Universal Market Access для создания synthetic assets. В 2020 году вышел токен, а ранние contracts позволяли выпускать collateralized synthetic positions. Со временем команда обнаружила, что общий механизм разрешения споров ценнее одной линейки синтетики.
Optimistic Oracle стал основной инфраструктурой, V2 закрепил request-propose-dispute flow, а V3 добавил arbitrary assertions и escalation managers. В 2023 году DVM 2.0 перешёл к staking и slashing. В декабре 2025 года ASSERT_TRUTH был заменён ASSERT_TRUTH2, и эта миграция обязательна для новых V3 integrations.
Команда
UMA основали Hart Lambur и Allison Lu. Lambur ранее работал в Goldman Sachs, Lu – в Goldman Sachs и Tala. Разработку и ecosystem support ведёт Risk Labs Foundation вместе с open-source contributors и delegates.
Risk Labs играет крупную роль в software, grants и partnerships, но разрешение disputed assertions выполняют stakers DVM. Для оценки децентрализации нужно отдельно смотреть разработку clients, emergency powers, stake distribution и delegation.
Основные риски
- Monitoring failure. Ложный claim проходит, если никто не оспорил его до конца liveness.
- Ambiguity risk. Неясная формулировка приводит voters к разным разумным ответам.
- Bond risk. Недостаточный bond не сдерживает прибыльную атаку, чрезмерный снижает участие.
- Voter capture. Крупный stake или concentrated delegation способен влиять на DVM result.
- Slashing risk. Ошибка, пропуск reveal или неверный vote уменьшает stake.
- Currency risk. Blacklistable bond token может заблокировать возврат средств.
- Escalation risk. Custom manager способен ограничить disputes или игнорировать oracle.
- Latency risk. Спор добавляет минимум полный voting round к settlement.
- Integration risk. Использование deprecated ASSERT_TRUTH или defaults теперь приводит к revert.
- Economic security. Value secured может расти быстрее стоимости честно staked UMA.
Итог
UMA проверяет не поток цен, а спорные утверждения. В обычном случае assertion проходит после challenge window, а сложный случай решают stakers DVM через commit-reveal. Это масштабируемая модель для редких событий, но её безопасность держится на наблюдателях, bond и ясном языке claim. OOv2 и OOv3 продолжают работать параллельно, а интеграторам V3 необходимо использовать ASSERT_TRUTH2. UMA связывает голосование со slashing, но не обещает владельцу фиксированную доходность или долю всех fees.
