Аудит библиотеки и обновляемых контрактов TRON Foundation

- 17 сентября 2026 г.

OpenZeppelin Security

Сводка

Тип: БиблиотекаСроки: 2026-07-02 → 2026-07-22Языки: Solidity

РезультатыВсего проблем: 11 (11 исправлено)Критические: 0 (0 исправлено) · Высокие: 2 (2 исправлено) · Средние: 1 (1 исправлено) · Низкие: 3 (3 исправлено)

Замечания и дополнительная информация5 замечаний (5 исправлено)

Проблемы, о которых сообщил клиент0 проблем (0 исправлено)

Содержание

• Содержание
• Сводка
• Область применения
• Обзор системы
• Модель безопасности и допущения о доверии Привилегированные роли Допущения о доверии Дополнительные соображения
• Привилегированные роли
• Допущения о доверии
• Дополнительные соображения
• Высокая степень серьезности TRC4626 и VestingWallet не могут отправить USDT из-за ложноположительных результатов переводов Аудируемые контракты наследуют уязвимости из вышестоящих контрактов OpenZeppelin
• TRC4626 и VestingWallet не могут отправить USDT из-за ложноположительных результатов переводов
• Аудируемые контракты наследуют уязвимости из вышестоящих контрактов OpenZeppelin
• Средняя степень серьезности InputSettlerEscrowTron использует адрес Permit2 из Ethereum, что нарушает работу openFor в TRON
• InputSettlerEscrowTron использует адрес Permit2 из Ethereum, что нарушает работу openFor в TRON
• Низкая степень серьезности TRC20FlashMint отклоняет заемщиков флеш-кредитов, соответствующих стандарту TIP-3156 В документации указаны стандарты под именами ERC/EIP из Ethereum, хотя они были переименованы в идентификаторы TRON Отсутствует документация по десекодированию 21-байтовых адресов TRON
• TRC20FlashMint отклоняет заемщиков флеш-кредитов, соответствующих стандарту TIP-3156
• В документации указаны стандарты под именами ERC/EIP из Ethereum, хотя они были переименованы в идентификаторы TRON
• Отсутствует документация по десекодированию 21-байтовых адресов TRON
• Замечания и дополнительная информация Время блока TRON сокращает окна управления, измеряемые в блоках, примерно в четыре раза Устаревшие предупреждения и предостережения в кодовой базе Переименование контрактов из OpenZeppelin Contracts в Tron Contracts Исполнители управления не поддерживают пересылку или восстановление токенов TRC-10 README и документация ссылаются на артефакты с именами ERC/EIP, которые существуют только под именами TRC
• Время блока TRON сокращает окна управления, измеряемые в блоках, примерно в четыре раза
• Устаревшие предупреждения и предостережения в кодовой базе
• Переименование контрактов из OpenZeppelin Contracts в Tron Contracts
• Исполнители управления не поддерживают пересылку или восстановление токенов TRC-10
• README и документация ссылаются на артефакты с именами ERC/EIP, которые существуют только под именами TRC
• Заключение
• Приложение Классификация проблем
• Классификация проблем

Область применения

OpenZeppelin провела аудит трех репозиториев. Первые два составляют портированную на TRON версию библиотеки OpenZeppelin Contracts, а третий представляет собой адаптацию контрактов расчетов Open Intents Framework для TRON:

• репозиторий OpenZeppelin/tron-contracts в коммите 06d69bc,
• репозиторий OpenZeppelin/tron-contracts-upgradeable в коммите f66f953
• репозиторий openintentsframework/oif-contracts в коммите 39df288.

Для двух библиотек OpenZeppelin в область применения вошли все исходные файлы Solidity в каталоге contracts/, за исключением вспомогательных файлов заглушек и тестов в contracts/mocks/. Обе библиотеки имеют одинаковую структуру модулей; репозиторий обновляемых контрактов предоставляет обновляемые варианты тех же стандартов и поэтому исключает модули прокси и интерфейсов, которые поставляются только в необновляемой библиотеке. Для репозитория Open Intents Framework в область применения вошли специфичные для TRON контракты расчетов по входящим переводам. Полные списки файлов, вошедших в область аудита, приведены ниже.

Файлы tron-contracts, вошедшие в область аудита (216 файлов):

Файлы tron-contracts-upgradeable, вошедшие в область аудита (84 файла):

Файлы oif-contracts (адаптация расчетов TRON), вошедшие в область аудита:

Обновление: Исправления для проблем, выявленных в этом отчете, были объединены в коммите d260982 для tron-contracts и в коммите 8e38b9b для oif-contracts.

Обзор системы

Два репозитория, вошедших в область аудита, представляют собой портированную версию OpenZeppelin Contracts v5.6.1 для виртуальной машины TRON (TVM). Это библиотеки общего назначения, состоящие из повторно используемых компонентов: стандартов взаимозаменяемых (TRC-20 / ERC-20), невзаимозаменяемых (TRC-721 / ERC-721), мультитокеновых (TRC-1155 / ERC-1155) и минимальных мультитокеновых (ERC-6909) токенов и их расширений, средств контроля доступа, управления, криптографических утилит и утилит для работы с подписями, прокси, метатранзакций (TRC-2771 / ERC-2771), кроссчейн-мостов и финансовых вспомогательных средств (а не развернутого протокола). Нисходящие проекты наследуют эти контракты и используют их в своей структуре, поэтому область, имеющая значение для безопасности, включает корректность каждого компонента, а также точки, в которых выполнение в TVM отличается от EVM.

Репозиторий tron-contracts представляет собой стандартную библиотеку. Репозиторий tron-contracts-upgradeable является обновляемым вариантом тех же исходных кодов, сгенерированным для использования за прокси: его контракты используют паттерн инициализатора вместо конструкторов и сохраняют состояние в хранилищах с пространствами имен (TIP-7201 / ERC-7201) для обеспечения безопасности при обновлениях. Обе библиотеки переименовывают стандарты, которые TRON публикует под собственными идентификаторами TIP (например, ERC20 в TRC20, EIP712 в TIP712), и дублируют ссылки на спецификации TRON (TIP / TRC) и Ethereum (EIP / ERC) там, где они существуют одновременно. Несколько стандартов сопоставлены с утвержденными TIP, включая расширение permit (TIP-2612 / ERC-2612), платный токен (TIP-1363 / ERC-1363), токенизированное хранилище (TIP-4626 / ERC-4626), флеш-кредиты (TIP-3156 / ERC-3156), обнаружение интерфейсов (TIP-165 / ERC-165), проверку подписей контрактов (TIP-1271 / ERC-1271), слоты хранения прокси (TIP-1967 / ERC-1967) и минимальный прокси (TIP-1167 / ERC-1167). Другие пока не имеют TIP, например ERC-6909, верификаторы подписей ERC-7913, а также кроссчейн-интерфейсы ERC-7786 и ERC-7802.

В портированной версии адаптированы те части библиотеки, где TVM ведет себя иначе, чем EVM. Наиболее значимыми для безопасности адаптациями являются: вычисление адресов CREATE2, в котором используется префикс TRON 0x41 (TIP-26) вместо префикса 0xff в EVM (EIP-1014); разделитель домена для типизированных данных (TIP-712 / EIP-712), привязанный к четырехбайтовому идентификатору цепочки, который TRON предоставляет через eth_chainId (TIP-474); префикс подписанного сообщения в MessageHashUtils, в котором используется строка TRON (TIP-191 / TIP-104), а не ERC-191; обратный вызов получателя TRC-721, для которого TRON определяет уникальное магическое значение; верификация secp256r1 (P256) (TIP-7951 / EIP-7951), выполняемая на чистом Solidity, поскольку в TVM отсутствуют активные встроенные прекомпилированные контракты; а также специальный вспомогательный контракт SafeTRC20 для переводов USDT в TRON, чей метод перевода возвращает false даже при успешном переводе. Модуль абстракции учетных записей EIP-7702, присутствующий в исходной библиотеке, не включен ни в один из репозиториев, так как TRON предоставляет функции мультиподписи и разрешений на уровне учетной записи (TIP-16 / TIP-105).

Репозиторий oif-contracts представляет собой Open Intents Framework — кроссчейн-систему исполнения намерений, в которой пользователь блокирует входные токены на эскроу-счете в исходной сети, чтобы исполнитель (filler) мог удовлетворить намерение в целевой сети. В область рассмотрения входит адаптация для TRON, InputSettlerEscrowTron, которая расширяет InputSettlerEscrow фреймворка для работы в TVM и использует библиотеку tron-contracts в качестве зависимости. Адаптация направляет выплаты токенов через SafeTRC20, чтобы расчеты работали с TRON USDT. Она также полагается на контракт Permit2 для спонсируемого пути сбора openFor. Поскольку TRON формирует адреса CREATE2 с префиксом 0x41, Permit2 развертывается по другому адресу в TRON, чем в Ethereum, поэтому хук адреса Permit2 во фреймворке должен указывать на развертывание в TRON.

Модель безопасности и предположения о доверии

Поскольку рассматриваемые репозитории являются библиотеками, а не развернутой системой, их безопасность зависит от того, как интеграторы настраивают и компонуют их, а также от семантики выполнения целевой сети TRON. В этом разделе зафиксированы предположения о доверии, на которые опирались при проверке. Любая находка, влияние которой зависит от нарушения одного из этих предположений, выходит за рамки рассмотрения, если только интегратор или непривилегированный субъект не может правдоподобно его нарушить.

Привилегированные роли

• Библиотеки не определяют собственных глобальных привилегированных ролей. Они предоставляют примитивы контроля доступа и управления (Ownable, Ownable2Step, AccessControl, AccessManager, Governor и TimelockController), которые интеграторы настраивают для своих собственных развертываний. Доверие, оказываемое владельцам, администраторам, инициаторам предложений и исполнителям, полностью определяется этой конфигурацией.

Библиотеки не определяют собственных глобальных привилегированных ролей.

• Они предоставляют примитивы контроля доступа и управления (Ownable, Ownable2Step, AccessControl, AccessManager, Governor и TimelockController), которые интеграторы настраивают для своих собственных развертываний. Доверие, оказываемое владельцам, администраторам, инициаторам предложений и исполнителям, полностью определяется этой конфигурацией.
• Полномочия по обновлению развертываемого контракта являются полностью доверенными. Для контрактов, развернутых за прокси, администратор прокси (для прозрачных прокси и прокси-маяков) или учетная запись, авторизованная через _authorizeUpgrade (для UUPS-прокси), может заменить реализацию и, следовательно, все поведение контракта.

Полномочия по обновлению развертываемого контракта являются полностью доверенными.

• Для контрактов, развернутых за прокси, администратор прокси (для прозрачных прокси и прокси-маяков) или учетная запись, авторизованная через _authorizeUpgrade (для UUPS-прокси), может заменить реализацию и, следовательно, все поведение контракта.

Предположения о доверии

• Кодовая база рассматривается как прямой порт OpenZeppelin Contracts v5.6.1. Не ожидается никакой специфичной для TRON функциональности, такой как нативные опкоды голосования или стейкинга, помимо адаптаций, необходимых для работы в TVM, и большая часть отличий от исходного кода заключается в переименовании, а не в изменении логики. Там, где поведение не отличается от исходного, используются соответствующие свойства безопасности исходного кода, и они не выводятся заново.

Кодовая база рассматривается как прямой порт OpenZeppelin Contracts v5.6.1.

• Не ожидается никакой специфичной для TRON функциональности, такой как нативные опкоды голосования или стейкинга, помимо адаптаций, необходимых для работы в TVM, и большая часть отличий от исходного кода заключается в переименовании, а не в изменении логики. Там, где поведение не отличается от исходного, используются соответствующие свойства безопасности исходного кода, и они не выводятся заново.
• Название TRC не подразумевает наличие ратифицированного стандарта TRON. Там, где переименованный стандарт соответствует существующему TIP, ожидается, что его реализация будет соответствовать этому TIP, и о любом отклонении сообщается. Там, где TIP отсутствует, копирование стандарта Ethereum считается приемлемым и не рассматривается как отклонение. Таким образом, артефакт с названием TRC не считается соответствующим опубликованному стандарту TRON.

Название TRC не подразумевает наличие ратифицированного стандарта TRON.

• Там, где переименованный стандарт соответствует существующему TIP, ожидается, что его реализация будет соответствовать этому TIP, и о любом отклонении сообщается. Там, где TIP отсутствует, копирование стандарта Ethereum считается приемлемым и не рассматривается как отклонение. Таким образом, артефакт с названием TRC не считается соответствующим опубликованному стандарту TRON.
• Токены TRC-10 считаются неподдерживаемыми. Контракты не реализуют обработку TRC-10, и не ожидается, что активы TRC-10 будут направляться через них. В ходе проверки все же рассматривается, может ли баланс TRC-10, удерживаемый контрактом в области рассмотрения, быть использован для создания неблагоприятного сценария, например, через произвольный вызов, выполненный контрактом управления или таймлоком.

Токены TRC-10 считаются неподдерживаемыми.

• Контракты не реализуют обработку TRC-10, и не ожидается, что активы TRC-10 будут направляться через них. В ходе проверки все же рассматривается, может ли баланс TRC-10, удерживаемый контрактом в области рассмотрения, быть использован для создания неблагоприятного сценария, например, через произвольный вызов, выполненный контрактом управления или таймлоком.
• Количество знаков после запятой для токенов TRC-20 по умолчанию равно 18. Значение decimals() по умолчанию для реализации TRC-20 равно 18, а не шести, как в нативном TRON, и ожидается, что оно будет переопределено там, где требуется другая точность. Ожидается, что интеграции, связывающие эти токены с активами с шестью знаками после запятой, будут учитывать эту разницу.

Количество знаков после запятой для токенов TRC-20 по умолчанию равно 18.

• Значение decimals() по умолчанию для реализации TRC-20 равно 18, а не шести, как в нативном TRON, и ожидается, что оно будет переопределено там, где требуется другая точность. Ожидается, что интеграции, связывающие эти токены с активами с шестью знаками после запятой, будут учитывать эту разницу.
• Токены, которые возвращают false при успешном переводе, обрабатываются только специальным вспомогательным методом. TRON USDT возвращает false из метода transfer, даже если перевод прошел успешно. Только SafeTRC20.safeTransferUSDT, который проверяет успех через изменение баланса, а не через возвращаемое значение, используется для таких токенов; потоки, использующие обычный safeTransfer, не должны настраиваться с ними. Токены с комиссией за перевод (fee-on-transfer) и ребазирующиеся токены считаются неподдерживаемыми, как и в исходной библиотеке.

Токены, которые возвращают false при успешном переводе, обрабатываются только специальным вспомогательным методом.

• TRON USDT возвращает false из метода transfer, даже если перевод прошел успешно. Только SafeTRC20.safeTransferUSDT, который проверяет успех через изменение баланса, а не через возвращаемое значение, используется для таких токенов; потоки, использующие обычный safeTransfer, не должны настраиваться с ними. Токены с комиссией за перевод (fee-on-transfer) и ребазирующиеся токены считаются неподдерживаемыми, как и в исходной библиотеке.
• Верификация secp256r1 (P256) выполняется в Solidity без использования прекомпиляции. В TVM не активна прекомпиляция P256 (TIP-7951 / EIP-7951), поэтому верификация направляется через Solidity, при этом сигнатуры функций остаются неизменными. Вычисления более затратны, чем при использовании прекомпиляции, и ограничены лимитами выполнения транзакций в TRON.

Проверка secp256r1 (P256) выполняется в Solidity, без использования прекомпилятора.

• На TVM не активирован прекомпилятор P256 (TIP-7951 / EIP-7951), поэтому проверка направляется через Solidity, при этом сигнатуры функций остаются неизменными. Вычисление обходится дороже, чем прекомпилятор, и ограничено лимитами выполнения транзакций в TRON.
• Энергетическая модель отличается от модели газа EVM. Компоненты перенаправления газа (gas-forwarding), в частности TRC2771Forwarder и пути доступа на основе полномочий, зависят от поведения перенаправления газа, которое отличается в сети TRON, где выполнение измеряется в энергии, а семантика gas-limit и gas-price не идентична EVM. Интеграциям, полагающимся на подвызовы с ограничением газа, необходимо валидировать поведение в TRON.

Энергетическая модель отличается от модели газа EVM.

• Компоненты перенаправления газа, в частности TRC2771Forwarder и пути доступа на основе полномочий, зависят от поведения перенаправления газа, которое отличается в сети TRON, где выполнение измеряется в энергии, а семантика gas-limit и gas-price не идентична EVM. Интеграциям, полагающимся на подвызовы с ограничением газа, необходимо валидировать поведение в TRON.
• Доставка межсетевых сообщений делегирована доверенному внешнему шлюзу. Межсетевые мосты делегируют доставку сообщений и защиту от повторного воспроизведения внешнему шлюзу, которому доверяют доставлять каждое сообщение не более одного раза и правильно атрибутировать исходную сеть и контрагента.

Доставка межсетевых сообщений делегирована доверенному внешнему шлюзу.

• Межсетевые мосты делегируют доставку сообщений и защиту от повторного воспроизведения внешнему шлюзу, которому доверяют доставлять каждое сообщение не более одного раза и правильно атрибутировать исходную сеть и контрагента.
• Расчеты в Open Intents Framework полагаются на внешнее развертывание Permit2 и off-chain участников. Контракты расчетов TRON зависят от внешнего развертывания Permit2 для спонсируемого пути сбора входных данных (ожидается, что он будет настроен с правильным адресом TRON Permit2), а также от off-chain филлеров и солверов для выполнения интентов. On-chain гарантии касаются только кастодии и освобождения заблокированных в эскроу входных данных.

Расчеты в Open Intents Framework полагаются на внешнее развертывание Permit2 и off-chain участников.

• Контракты расчетов TRON зависят от внешнего развертывания Permit2 для спонсируемого пути сбора входных данных, который должен быть настроен с правильным адресом TRON Permit2, а также от off-chain филлеров и солверов для выполнения интентов. On-chain гарантии касаются только кастодии и освобождения заблокированных в эскроу входных данных.

Дополнительные соображения

• Детерминированное развертывание использует деривацию адресов TRON. Вспомогательные функции Create2, Clones и ретранслятора (relayer) выводят адреса с префиксом TRON 0x41 CREATE2 (TIP-26), а не с префиксом EVM 0xff (EIP-1014). Off-chain инструменты и вычисление контрафактуальных адресов должны использовать ту же деривацию для получения правильных адресов.

Детерминированное развертывание использует деривацию адресов TRON.

• Вспомогательные функции Create2, Clones и ретранслятора выводят адреса с префиксом TRON 0x41 CREATE2 (TIP-26), а не с префиксом EVM 0xff (EIP-1014). Off-chain инструменты и вычисление контрафактуальных адресов должны использовать ту же деривацию для получения правильных адресов.
• Библиотеки предполагают, что фича-гейты (feature gates) TVM целевой сети активны. Поведение, зависящее от фича-гейта, такое как временное хранилище (transient storage, TIP-650 / EIP-1153) и оптимизированное возвращаемое значение идентификатора сети (chain-identifier, TIP-474), должно быть подтверждено для целевой сети, а развертывания должны быть ориентированы на версию EVM, которую принимает сеть.

Библиотеки предполагают, что фича-гейты TVM целевой сети активны.

• Поведение, зависящее от фича-гейта, такое как временное хранилище (transient storage, TIP-650 / EIP-1153) и оптимизированное возвращаемое значение идентификатора сети (TIP-474), должно быть подтверждено для целевой сети, а развертывания должны быть ориентированы на версию EVM, которую принимает сеть.

Высокая критичность

TRC4626 и VestingWallet не могут выводить USDT из-за переводов, возвращающих false при успехе

Обе функции (withdraw и redeem) в TRC4626 выплачивают базовый актив через одну внутреннюю функцию _transferOut, которая вызывает SafeTRC20.safeTransfer. Этот хелпер считает перевод успешным только тогда, когда токен возвращает true или не возвращает ничего.

В сети TRON контракт USDT возвращает false после перевода, который на самом деле был успешным. safeTransfer считывает это значение false, делает вывод, что перевод не удался, и завершает выполнение с ошибкой SafeTRC20FailedOperation. Депозиты не затрагиваются, так как _transferIn привлекает активы с помощью safeTransferFrom, а USDT возвращает true при вызове transferFrom. Порт уже сталкивался с этим поведением и добавил safeTransferUSDT для обработки такой ситуации, используя его на пути высвобождения средств моста в _onReceive, однако это же изменение не было перенесено в хранилище (vault).

Это означает, что если базовым активом является USDT, пользователи могут вносить депозиты (deposit) и чеканить токены (mint), но любой вывод (withdraw) и погашение (redeem) возвращаются с ошибкой (revert), из-за чего доли (shares) невозможно погасить.

Та же недоработка присутствует и в VestingWallet. Единственный способ выплатить разблокированный баланс TRC-20 — функция release — также вызывает SafeTRC20.safeTransfer, поэтому кошелек, пополненный USDT, принимает депозит, но никогда не может выдать его. Контракт не имеет функции спасения средств (rescue function) и не является обновляемым; передача прав владения не помогает, поскольку новый владелец сталкивается с тем же вызывающим revert вызовом.

Рекомендуется выплачивать базовый актив через safeTransferUSDT (или другой хелпер перевода, подтверждающий успех по итоговому изменению баланса) на пути вывода средств TRC4626, как это уже сделано в BridgeTRC20. Кроме того, рекомендуется применить аналогичное исправление к VestingWallet.

Обновление: Решено в pull request #131. Команда заявила:

TRC4626._transferOut, VestingWallet.release и TRC20Wrapper.withdrawTo теперь выплачивают средства через SafeTRC20.safeTransferChecked, который подтверждает успех по дельте баланса вызывающей стороны, а не по возвращаемому логическому значению (boolean). TRC20Wrapper.withdrawTo не указан в отчете, но имеет тот же дефект — его базовый актив был заблокирован за оберткой. Исправлено попутно. Мы сделали проверенный перевод дефолтным, а не исключением для конкретного токена, переименовав safeTransferUSDT в safeTransferChecked: эти контракты не могут знать во время развертывания, какой токен они содержат, поэтому привязка к настроенному адресу USDT оставила бы сломанным любой другой токен с возвратом false при успехе. Использование safeTransferUSDT было обновлено до safeTransferChecked в OIF в PR: #195

TRC4626._transferOut, VestingWallet.release и TRC20Wrapper.withdrawTo теперь выплачивают средства через SafeTRC20.safeTransferChecked, который подтверждает успех по дельте баланса вызывающей стороны, а не по возвращаемому логическому значению.

• TRC20Wrapper.withdrawTo не указан в отчете, но имеет тот же дефект — его базовый актив был заблокирован за оберткой. Исправлено попутно.

TRC20Wrapper.withdrawTo не указан в отчете, но имеет тот же дефект — его базовый актив был заблокирован за оберткой. Исправлено попутно.

• Мы сделали проверенный перевод (checked transfer) стандартным поведением, а не исключением для отдельных токенов, переименовав safeTransferUSDT в safeTransferChecked: эти контракты не могут знать во время развертывания, какой токен они будут содержать, поэтому ограничение только настроенным адресом USDT привело бы к некорректной работе всех остальных токенов с поведением false-on-success.

Мы сделали проверенный перевод (checked transfer) стандартным поведением, а не исключением для отдельных токенов, переименовав safeTransferUSDT в safeTransferChecked: эти контракты не могут знать во время развертывания, какой токен они будут содержать, поэтому ограничение только настроенным адресом USDT привело бы к некорректной работе всех остальных токенов с поведением false-on-success.

• Использование safeTransferUSDT было обновлено до safeTransferChecked в OIF в PR: #195

Использование safeTransferUSDT было обновлено до safeTransferChecked в OIF в PR: #195

Аудированные контракты наследуют проблемы из вышестоящих контрактов OpenZeppelin

Аудированные контракты генерируются из репозитория tron-contracts с помощью OpenZeppelin Upgradeability Transpiler, а tron-contracts, в свою очередь, основан на OpenZeppelin Contracts v5.6.1. Несколько проблем в рамках аудита связаны не с различиями между EVM и TVM или транспиляцией, а унаследованы из вышестоящей кодовой базы. Большинство из них были исправлены в основной ветке после выпуска v5.6.1 и запланированы для версии 5.7, поэтому исправления отсутствуют в аудируемом коммите. В частности:

• Задержка baseDelaySeconds в GovernorTimelockAccessUpgradeable может быть обойдена путем выполнения предложения без постановки его в очередь. Функция execute принимает предложения как в состоянии Succeeded, так и в Queued, но etaSeconds записывается только при вызове queue. Таким образом, предложение, выполненное напрямую из состояния Succeeded, имеет proposalEta равное 0, проверка block.timestamp < etaSeconds проходит тривиально, и окно реакции после голосования пропускается для операций, не требующих предварительного планирования. Исправлено в upstream в PR #6386, с последующим дополнением в PR #6582.
• Атомарный режим TRC2771ForwarderUpgradeable не обеспечивает выполнение по принципу «все или ничего» (#30). Когда refundReceiver является нулевым адресом, executeBatch откатывается только при невалидных запросах. Валидный запрос, целевой вызов которого завершается ошибкой, не прерывает пакет: его nonce расходуется, предыдущие вызовы остаются зафиксированными, а значение неудачного запроса возвращается через Address.sendValue на нулевой адрес, навсегда блокируя соответствующий TRX. Исправлено в upstream в PR #6391.
• Задержка администратора для конкретной цели в AccessManagerUpgradeable может быть обойдена при изменении полномочий управляемого контракта, так как setAuthority может быть запланирован и вызван через путь execute, который не применяет задержку администратора, принудительно исполняемую в updateAuthority. Исправлено в upstream в PR #6388.
• Функции burn и burnBatch в TRC1155BurnableUpgradeable выполняют встроенную проверку isApprovedForAll вместо вызова виртуальной функции _checkAuthorized, поэтому переопределения авторизации, применяемые к переводам, незаметно обходятся для сжиганий. Исправлено в upstream в PR #6435.
• NatSpec функции _mintConsecutive в TRC721ConsecutiveUpgradeable гласит, что batchSize равный 0 возвращает количество последовательных ID, выпущенных к настоящему моменту, тогда как функция возвращает следующий последовательный ID токена, который отличается от этого количества всякий раз, когда _firstConsecutiveId переопределен на ненулевое значение. Эта ошибка в документации была исправлена в upstream в PR #6433.

Рассмотрите возможность переноса указанных исправлений из основной ветки в кодовую базу tron-contracts или обновления форка до версии 5.7 OpenZeppelin Contracts после ее публикации. Кроме того, рассмотрите возможность сообщения об обходе позднего кворума в основную ветку и устранения этой проблемы в обеих кодовых базах путем отслеживания состояния кворума отдельно от сохраненного продленного крайнего срока и реагирования на каждый переход кворума из состояния false в true.

Обновление: Решено в pull request #119, #120, #121, #122, #123, #136, #137 и #141. Команда заявила:

Низкая степень серьезности