Перейти к содержанию
Financial Context Wiki

Как проверить число десятичных знаков токена

Проверьте decimals ERC-20 по правильному контракту и блоку, затем сверьте исходные балансы, переводы, разрешения и конвертации моста без ошибок плавающей точки.

Обновлено

Только в образовательных целях; это не инвестиционная рекомендация и не совет по безопасности. Число десятичных знаков не доказывает личность, стоимость, обеспечение или безопасность токена.

Краткий ответ

Для токена ERC-20 функция decimals() — необязательные метаданные, которые указывают интерфейсам, как отображать целые единицы. Если она возвращает d, стандартное отображаемое количество равно raw / 10^d. Это не меняет арифметику контракта и не подтверждает подлинность токена. До доверия результату проверьте сеть, точный адрес, код или реализацию прокси и блок.

Прочитайте decimals() напрямую через независимый RPC на заданном блоке, декодируйте возврат ABI как uint8 и сравните с официальным реестром эмитента и надежным обозревателем. Затем проверьте масштаб по исходным значениям balanceOf, переводов, разрешений, квитанций и событий. Не подставляйте 18, если вызов отсутствует, откатывается, возвращает неверные данные или противоречит другим свидетельствам.

Как это работает

ERC-20 хранит и передает суммы как беззнаковые целые числа. Десятичную точку вставляет слой отображения; контракт по-прежнему получает целые числа. Преобразуйте ввод десятичными строками или целыми произвольной точности, но не двоичной плавающей точкой. Количество представимо, только если умножение на 10^d дает целое число.

Поскольку decimals() необязательна, совместимый токен может ее не реализовать. Пользовательская или обновляемая реализация может вернуть неожиданное значение или измениться после обновления. Для прокси ERC-1967 проверьте адрес прокси, реализацию или beacon, администратора и события обновления; читайте состояние по адресу прокси и привязывайте все сравнения к одному блоку.

Разрешения и значения ERC-2612 permit тоже являются исходными целыми. Верное отображение перевода не доказывает, что разрешение, минимум маршрутизатора, сумма моста или бухгалтерская база использовали тот же масштаб. Контракты моста в исходной и целевой сети могут иметь разные decimals; сравнивайте читаемую стоимость и исходные единицы на обеих сторонах по документированным правилам конвертации и округления.

Порядок проверки:

  1. Зафиксируйте ID сети или домен, контракт токена, номер блока, RPC-адрес и время наблюдения.
  2. Подтвердите адрес в официальном реестре эмитента; название, символ, значок и результаты поиска не являются авторитетными доказательствами.
  3. Проверьте развернутый код и является ли адрес прокси; запишите реализацию или beacon, администратора и недавние обновления.
  4. Вызовите decimals(), декодируйте uint8 через ABI и запишите успех, откат, пустой или неверный вывод, не подставляя значение по умолчанию.
  5. Прочитайте исходные balanceOf, totalSupply, разрешение, calldata, квитанцию и события на совместимых блоках; отформатируйте их с наблюдаемым масштабом.
  6. Пересчитайте перевод, разрешение, котировку и мост целыми числами, включая комиссии, округление, остатки, ребейз или налог на перевод.
  7. Смоделируйте и отправьте малую операцию, затем сверьте исходные балансы до и после; остановитесь при любом расхождении интерфейса, RPC, события или баланса.

Примеры

  • Одно исходное значение, два масштаба. При raw = 123456789 значение d = 6 отображает 123.456789, а d = 18 — 0.000000000123456789. Разница составляет 10^12 раз.
  • Представимость важна. При d = 6 количество 1.25 токена равно 1250000 исходных единиц. 0.0000001 токена меньше одной единицы и должно быть отклонено или округлено по явному правилу.
  • Неверный масштаб разрешения. Разрешение 100 токенов при d = 6 равно 100000000. Кодирование при d = 18 дает 100000000000000000000 — разрешение в 10^12 раз больше задуманного.
  • Масштабирование в мосте. Если документированный маршрут 1:1 преобразует исходный токен с d = 6 в целевое представление с d = 18, исходное 2500000 означает 2.5 токена, а целевое 2500000000000000000 тоже означает 2.5. Комиссии, лимиты, остатки и фактический баланс получения все равно требуют проверки.

Риски

  • Правильный адрес запрашивается в неправильной сети.
  • Скопированные название, символ или значок скрывают другой контракт.
  • Реализация прокси или beacon меняется после проверки.
  • RPC или обозреватель отдает устаревшее, нефинальное или несогласованное состояние.
  • Отсутствующие или неверные метаданные незаметно заменяются на 18.
  • Двоичная плавающая точка округляет крупную или точную сумму.
  • Кошелек верно форматирует перевод, но ошибается в разрешении или permit.
  • База данных смешивает исходные единицы и читаемые суммы.
  • Мост предполагает одинаковые decimals или не раскрывает округление остатков.
  • Комиссия перевода, ребейз, выпуск, сжигание, пауза или заморозка нарушают простую сверку.
  • Calldata, события, квитанции и реальные изменения баланса не совпадают.
  • Проверка decimals принимается за доказательство эмитента, резервов, ликвидности или безопасности.

Распространенные заблуждения

  • У всех ERC-20 по 18 десятичных знаков. Метаданные необязательны, а реализация может вернуть другое значение.
  • Decimals — это биты точности EVM. Это десятичное правило отображения; арифметика токена остается целочисленной.
  • Форматированный баланс обозревателя — независимое подтверждение. Он может зависеть от того же вызова и разделять ту же ошибку.
  • Одинаковые символ и decimals означают один актив. Нужны также правильная сеть, точный контракт и свидетельство эмитента.
  • Успешный малый перевод проверяет все интеграции. Разрешения, маршрутизаторы, мосты, биржи и учет могут масштабировать суммы отдельно.

Связанные темы

Источники

Навигация

Поиск по вики...