«Два RPC показывают разную высоту. Риск пока не разрешает открыть вывод средств»
Пауза сети вызывает сотни вопросов о времени запуска. Разная высота, условие открытия и ответственный показывают сообщение, которое стоит прочитать дважды.

Сигналы для наблюдения
- Команда называет, что по-прежнему не работает: высоты RPC расходятся, индексатор не сходится или откат обновления не проверен
- Кошелёк, биржа, риск, безопасность или операции объясняет, что должно произойти до открытия депозитов, вывода, подписи или другой функции
- В сообщении есть тест, отчёт, окно стабильных блоков или срок, который превращает общую срочность в проверяемую задачу
В 08:47 одновременно оживают три Web3-группы в Telegram.
«Mainnet Ontology на паузе. Когда запустят?»
«Теперь всем кошелькам нужно отключить депозиты и вывод?»
«Два наших RPC показывают разную высоту блока. Риск ждёт отчёт о согласованности и до этого не откроет вывод средств».
Если вы продаёте RPC, эксплуатацию узлов, блокчейн-мониторинг или интеграцию кошельков и бирж, какое сообщение важнее?
Третье.
Первые два — нормальные вопросы, но в них нет работы для внешнего поставщика. Третье называет ошибку, нужный отчёт и операцию, которая без него останется закрытой.
Все сообщения, люди, компании и рабочие сцены в статье вымышлены и показывают типичные ситуации. Это не цитаты клиентов. Реальны только публичные сообщения Ontology.
Слова «до открытия» меняют смысл
Во время паузы почти все спрашивают, когда сеть вернётся. Сам по себе такой вопрос не является лидом.
Полезная часть сообщения часто стоит после слова до:
- «до открытия вывода средств»;
- «до включения переводов в кошельке»;
- «до одобрения обновления операционной командой»;
- «до того, как индексатор снова станет доверенным».
Фраза показывает, что у команды есть собственное условие выхода. Даже если блоки снова производятся, кто-то внутри компании ждёт доказательство перед возвращением продукта к обычной работе.
Для продавца это полезнее, чем «сеть не работает». Можно спросить, какого доказательства не хватает, кто его принимает и какая операция ждёт.
Что произошло — простыми словами
Официальный статус изменился между двумя сообщениями.
31 августа Ontology объявила немедленную паузу. Производство блоков остановилось, транзакции не обрабатывались. На тот момент компания заявила, что подтверждённый инцидент не выявлен и признаков потери или компрометации пользовательских активов нет.
Первое сообщение фиксирует сведения на тот момент; оно не означает, что последующее расследование ничего не обнаружило.
1 сентября Ontology выпустила второе обновление. Расследование выявило вредоносную активность, направленную против сети. Компания также сказала, что пользовательские активы не были затронуты или скомпрометированы.
Второе сообщение меняет статус инцидента, сохраняя заявленную границу по активам.
Сеть оставалась на паузе для обновления, проверки целостности и стабильности и тестирования. Целью было восстановить операции в следующие 24 часа, но только при успешном завершении проверок, исправлений и обновления. Это цель, а не обещанный час запуска.
24-часовую цель нельзя повторять потенциальному клиенту как гарантию.
Эти факты помогают не ошибиться в разговоре. Они не показывают, у какой биржи застрял индексатор и какому оператору негде проверить обновление. Это видно только из сообщений самой команды.
Полезное сообщение состоит из трёх частей
Что-то всё ещё не работает
«Сеть на паузе» — публичное событие. Проблема команды звучит иначе:
«Основной RPC показывает блок 18 420 510, а резервный отстаёт на 17 блоков».
RPC — соединение, через которое приложение читает данные сети и отправляет транзакции. Если два RPC показывают разные высоты, команда пока не знает, какой картине доверять.
Другие примеры:
«Эксплорер догнал сеть, а депозитные балансы не сходятся со вчерашним снимком».
«Обновление валидатора готово, но откат ни разу не репетировали».
«Чтение работает, а отправка транзакции из мобильного кошелька всё ещё падает».
В каждом случае работа не закончена. Поставщик может и не понадобиться, но теперь есть о чём спросить.
Реальная операция остаётся закрытой
Сильный сигнал связывает техническую ошибку с работой бизнеса:
«Риск не откроет депозиты, пока оба RPC не совпадут».
«Wallet operations требует успешный тест депозита и вывода».
«Переводы останутся выключенными, пока не пройдут Android и iOS».
Это уже не красный индикатор. Ждут депозиты, вывод, переводы или релиз.
Поэтому «сеть запущена» недостаточно. Биржа может ждать стабильные блоки, кошелёк — показывать баланс, но блокировать отправку, а индексатор — ещё догонять сеть. Каждая компания открывает свою дверь отдельно.
Кто-то должен принять результат
Ищите того, кто скажет «да»:
«Риск подписывает отчёт».
«Безопасность хочет присутствовать на тесте отката».
«Решение об открытии принимает wallet operations».
«Результат нужен релиз-менеджеру к 18:00 UTC».
Ответственный показывает, где находится решение. Он не доказывает закупочные полномочия автора, но полезнее фразы «нужно срочно исправить».
Сочетание читается просто:
Два RPC расходятся + вывод закрыт + риск ждёт отчёт.
Это возможная работа. «Mainnet остановлена, когда запуск?» — пока вопрос.
Три естественных вопроса
Когда RPC расходятся
Если RPC расходятся:
«Риску нужна разовая сверка высоты и хеша блока или наблюдение за endpoint в течение какого-то времени?»
Так вы поймёте, нужен один отчёт или постоянный мониторинг.
Когда биржа хочет наблюдать стабильные блоки
Если биржа хочет увидеть 200 стабильных блоков:
«После запуска будем наблюдать 200 блоков. Риск подпишет отчёт до открытия депозитов».
«Правило 200 блоков уже утверждено и нужен только отчёт, или команда ещё решает, какое исключение обнулит отсчёт?»
В первом случае собирают данные, во втором ещё проектируют условие открытия.
Когда для обновления нет репетиции отката
Если не проверен откат:
«Не хватает безопасного тестового окружения или инструкции, как вернуться в прежнее состояние при неудачном обновлении?»
Вопрос отделяет нехватку среды от нехватки процедуры и не обещает решение до уточнения узлов, версий, доступа и срока.
Две ошибки при меняющемся статусе
Не повторяйте старое сообщение как текущую истину. В первом говорилось, что инцидент не подтверждён на тот момент. Во втором вредоносная активность уже была выявлена.
Не превращайте 24-часовую цель в срок покупателя. Она зависела от успешных проверок и обновления. Биржа может открыться позже, оператору узлов нужно действовать раньше, кошелёк может ждать дольше. Спросите срок самой команды.
Не говорите о потерянных средствах, не придумывайте техническую причину и не обвиняйте поставщика. В официальных сообщениях активы названы незатронутыми, а окончательная причина не опубликована.
Как TOP Prospect помогает, когда одна история попала в пять групп
Важная фраза может появиться не в первой группе.
В одной пишут: «Высоты RPC расходятся». Через час в другом разрешённом источнике: «Риск не открывает вывод». Третье сообщение упоминает отчёт к 16:00. По отдельности это обычная переписка; вместе с временем и соседним контекстом они могут описывать один заблокированный процесс.
В TOP Prospect продавец может отслеживать Telegram-источники, на использование которых у него есть разрешение, и искать не только название сети. Полезные фразы:
- «до открытия»;
- «риск должен подписать»;
- «высоты не совпадают»;
- «всё ещё выключено»;
- «откат не проверен»;
- «отчёт нужен к…».
TOP сохраняет сообщение, источник, время и соседнюю переписку для проверки человеком. Он не осматривает узел, не выбирает правильную высоту, не сертифицирует обновление, не проверяет личность автора и не подтверждает допуск внешнего поставщика. Это выясняет продавец напрямую.
Задача не в том, чтобы сохранить все сообщения о паузе. Важно не потерять одну фразу, связанную с реальным решением об открытии.
Увидели «сеть на паузе» — читайте дальше.
Увидели «два RPC расходятся, вывод закрыт, риск ждёт отчёт» — остановитесь и спросите, чего не хватает.
Часто задаваемые вопросы
Ontology подтвердила атаку в первом сообщении о паузе?
Нет. В первом сообщении говорилось, что на тот момент подтверждённый инцидент не выявлен. Позднее официальное обновление сообщило о вредоносной активности против сети.
Ontology гарантировала восстановление mainnet за 24 часа?
Нет. Это была цель, зависевшая от успешного завершения проверок безопасности, исправлений и обновления.
Может ли TOP Prospect проверить готовность RPC, валидатора, кошелька или биржи к открытию?
Нет. Сервис сохраняет совпавшие сообщения и контекст из разрешённых источников. Состояние узла, личность, полномочия, результаты и доступ поставщика проверяют люди.
Источники и дополнительное чтение
Материал подготовлен редакцией. TOP Prospect обрабатывает только явно подключённые и доступные пользователю группы Telegram. Результаты помогают продавцу принять решение, но не заменяют человека и не отправляют сообщения участникам автоматически.
Как обнаруживается Signal, заслуживающий внимания
Методика показывает, как Top Prospect находит и упорядочивает Signals, которые стоит проверить, сохраняет исходный контекст Telegram, удаляет дубли и помогает определить порядок просмотра. Решение о дальнейших действиях остаётся за вами.

