Голосования об обновлении Stellar Bell, Protocol 30, намечены на 3 ноября 2026 года для testnet и 23 ноября для mainnet, оба на 17:00 UTC. На дату этого подготовительного разбора, 27 октября, они ещё впереди. Задача интеграции — подготовить новые адреса контрактов с идентификатором и чтение реестра. План голосования нужно отделять от уже активированных правил сети.
Подготовьте весь путь обработки адреса получателя
Анонс Bell описывает адреса контрактов с мультиплексированием, проверку подписей ML-DSA в смарт-контрактах и миллисекундную точность времени реестра. Согласно инструкции обновления, SDK предоставляет разбор нового W-типа. Самому приложению нужно разрешить вариант в проверке, отображении и хранении адресов. Поэтому установка нового парсера ещё не завершает подготовку.
Принимающему сервису важно проверить весь процесс. Библиотека может разобрать адрес, а старое условие приложения — отклонить его тип. Либо экран сократит сведения, нужные сотруднику для сверки получателя. Используйте адрес в том виде, который выдал принимающий сервис. Нельзя изготовить новый формат заменой первой буквы существующего адреса. Подтверждение правильного назначения должно относиться к полной записи, а не к внешнему сходству.
| Граница интеграции | Что проверить | Какое доказательство нужно |
|---|---|---|
| Адрес получателя | Принимают ли вариант проверка, отображение, хранение и маршрутизация? | Тест всего пути приложения, а не одного парсера SDK |
| Сверка перевода | Сохраняет ли система идентификатор получателя? | Запись теста, связывающая назначение с событием перевода |
| Декодер реестра | Читаются ли значения XDR Protocol30? | Тест декодирования с обновлёнными определениями |
| Обработка времени | Не предполагает ли код обязательное увеличение на целую секунду? | Тест разных записей реестра внутри одной отображаемой секунды |
| Авторизация аккаунта | Принял ли аккаунт новую функцию проверки подписей? | Его собственная реализованная политика авторизации |
Точность времени меняет смысл проверки отметок
В спецификации CAP-88 существующее поле closeTime сохраняет смысл целых секунд, добавляются миллисекундная точность и новые варианты XDR. Временные условия протокола продолжают использовать секунды. Потребителям исходных данных всё равно требуются обновлённые определения. Нельзя просто начать читать старое секундное поле как миллисекунды без изменения его назначения.
Условный тест обработки данных: одна запись реестра закрылась в 12:00:00.100, следующая — в 12:00:00.900. После округления вниз они показывают одну секунду. Это не делает записи одинаковыми и не подтверждает повторный платёж. Если программа различает новые записи только по показанной секунде, пример выявляет ненадёжное предположение. Времена вымышлены и не являются измерением работы основной сети.
Повышение точности часов также не задаёт само по себе период закрытия реестра или время зачисления биржевого аккаунта. Предпосылка для будущей оптимизации не равна обещанию немедленного миллисекундного перевода. Разделяйте сетевое время, результат конкретной транзакции и внутреннюю обработку получателя. Для завершения задачи может потребоваться подтверждение последнего этапа, даже когда предыдущий уже отражён в сети.
Проверка подписей в контракте не меняет сразу все аккаунты
В анонсе Bell поддержка ML-DSA относится к смарт-контрактам; сетевые подписи транзакций пока остаются Ed25519. Поэтому новость нельзя описывать как одновременную квантовую защищённость каждого аккаунта Stellar. Контракту нужна собственная принятая политика авторизации. Обычный держатель не должен выводить из анонса требование заменить ключи или перевести средства на адрес квантового обновления.
Для оператора это несколько самостоятельных проверок. Читает ли конвейер данных новый реестр? Принимает ли приложение разрешённый адрес? Изменилась ли политика подписи конкретного аккаунта? Один положительный ответ не подтверждает остальные. И ни один не заменяет проверку исхода голосования. В подготовительном документе важно оставить статус будущего события, пока его результат действительно не установлен.
- Откройте действующую инструкцию и подтвердите запланированное голосование нужной среды: testnet либо mainnet.
- Обновите SDK и определения исходных данных, затем проверьте весь путь обработки адреса приложением.
- Пересмотрите сверку и временные предположения на явных тестах, включая разные записи в одну секунду.
- После голосования установите фактический этап сети; до реального перевода проверьте текущую поддержку у получателя.
Что проверить держателю перед обменом
Используйте действующие реквизиты получателя и нужную ему информацию маршрутизации. Протокольный анонс не разрешает убрать сведения, которые сервис продолжает требовать. Сохраните котировку и запись транзакции: они помогут отличить доставку от ошибки внутренней обработки приложения. Возможности формата адреса и правила конкретного пополнения не следует подменять друг другом.
Проверьте поддерживаемые активы и сети, порядок заявки и предлагаемое направление простого обмена. Эти страницы KOT.CASH не заявляют поддержку W-адресов, особую политику подписи или обещанный срок расчёта Bell. Уточняйте фактические инструкции именно той обменной операции, которую собираетесь выполнить.
Частые вопросы
Голосование Stellar Protocol30 означает уже выполненную активацию?
Опубликованные даты относятся к плану голосований, а включение зависит от одобрения. До заявления о работающей функции нужно проверить фактический этап сети.
Новый формат адреса Stellar требует исправить старый адрес?
Используйте полные реквизиты, выданные получателем. Замена префикса не создаёт правильное назначение и не подтверждает поддержку сервиса.
Проверка адреса Stellar доказывает поддержку W в приложении получателя?
Парсер проверяет только часть процесса. Сам сервис должен обрабатывать вариант в проверке, отображении, хранении и маршрутизации.