Как перевести предмет между кошельками шаг за шагом

Перевести предмет между кошельками шаг за шагом — значит начать не с кнопки «отправить», а с определения стандарта. Предмет по ERC-721 единичен, и в переводе указывается только его номер. Предмет по ERC-1155 переводится количеством, и поле количества там обязательно. От этой развилки зависит весь дальнейший порядок: формат вызова, вид разрешения, возможность отправить несколько предметов разом. Сначала стандарт, затем получатель, и лишь потом подпись.

Что происходит с сегментом сейчас

Два стандарта давно живут рядом: коллекционные предметы чаще выпускают по ERC-721, игровые ресурсы и расходуемые предметы — по ERC-1155, и в одном кошельке спокойно соседствуют оба типа. Интерфейсы приложений эту разницу прячут, показывая всё единой галереей.

Текст ERC-1155 описывает модель прямо: контракт позволяет «each token ID to represent a new configurable token type, which may have its own metadata, supply and other attributes» и допускает в одном контракте «fungible tokens, non-fungible tokens or other configurations». Сверено по первоисточнику на eips.ethereum.org 17 октября 2026 года. Значит, у номера бывает тираж. Один экземпляр и сто экземпляров выглядят в галерее одинаково.

Отсюда главный источник ошибок сегмента. Владелец, привыкший к единичным предметам, отправляет предмет из серии и не замечает поля количества, а в кошельке остаётся ещё девяносто девять копий либо, наоборот, уезжает вся серия сразу. Поле количества читают до подписи.

Как перевести предмет между кошельками шаг за шагом

Порядок строится от предмета к получателю. Сначала определяют стандарт: страница контракта в обозревателе показывает заявленные интерфейсы, а характерный признак ERC-1155 — наличие остатка по номеру вместо единственного владельца. Затем выясняют, где предмет находится: в кошельке под вашим ключом или под управлением контракта площадки, которому вы ранее выдали разрешение.

Разрешения различаются охватом, и путаница здесь стоит дороже всего остального. По EIP-721 функция approve задаёт «the approved address for an NFT», то есть доступ к одному номеру, а setApprovalForAll включает оператора, управляющего «all of msg.sender’s assets». У ERC-1155 разрешения на отдельный номер в базовом стандарте нет вовсе: оператор получает права на весь набор ваших токенов этого контракта. Разница в интерфейсе малозаметна.

Проверка получателя — обязательный шаг, а не формальность. Спецификация ERC-1155 требует отката, если получатель-контракт не реализует нужные функции интерфейса, и называет ожидаемые значения: 0xf23a6e61 для одиночного перевода, 0xbc197c81 для перевода пачкой. У ERC-721 проверка выполняется безопасной функцией, а небезопасная её не делает.

Издержки: комиссии, роялти, газ

Состав расходов зависит от выбранного пути: прямой перевод со своего кошелька — это одна транзакция, без сборов площадки и без роялти, поскольку продажи при смене владельца не происходит. Перевод через интерфейс площадки добавляет её правила и выданное ранее разрешение; подробности собраны в разборе комиссий площадки и её контрактов.

Полная раскладка слагаемых есть в материале о том, как перевести предмет между кошельками и понять структуру комиссий.

Пошаговый сценарий

1. Определите стандарт предмета по странице контракта в обозревателе: единственный владелец номера указывает на ERC-721, остаток по номеру — на ERC-1155.
2. Выпишите три значения — адрес контракта, номер предмета и количество для ERC-1155; без них подпись проверить невозможно.
3. Проверьте, кто распоряжается предметом: ваш ключ или контракт площадки, которому выдано разрешение.
4. Снимите активные лоты и предложения, иначе после перевода сделка закроется у нового владельца.
5. Сверьте адрес получателя: есть ли по нему код и умеет ли этот код принимать предметы вашего стандарта.
6. Подпишите безопасный перевод, указав номер и количество, затем сверьте владельца и отзовите лишние разрешения.

Риски и мошеннические схемы сегмента

Первое место держат запросы разрешения, замаскированные под перевод. Страница обещает перенос, обмен или участие в бесплатной раздаче предметов, а кошелёк показывает запрос setApprovalForAll. Подпись отдаёт оператору доступ ко всей коллекции в этом контракте, а не к одному номеру, и срок у такого доступа один — до отзыва. Отличить запрос можно по названию метода в данных транзакции.

Второй риск — метаданные. Описание и файл по стандарту лежат вне токена, и ERC-1155 прямо перекладывает сборку адреса на клиента: «If the string {id} exists in any URI, clients MUST replace this with the actual token ID in hexadecimal form». После перевода новый владелец получает номер, а доступность картинки зависит от внешнего хранилища. Проверяйте ссылку заранее. Исключения редки: модель цифровых артефактов на базовом слое Bitcoin хранит данные в самой транзакции и внешнего хранилища не требует.

Третий сюжет касается остатка. Мошенники просят «перевести один экземпляр для проверки», а в подготовленном вызове количество подставлено по всему остатку. Поле количества читают глазами, а не доверяют интерфейсу. При серии предметов это единственная защита.

Итог

• Стандарт предмета определён до начала операции.
• Контракт, номер и количество выписаны.
• Известно, кто распоряжается предметом: ключ или контракт.
• Лоты и предложения сняты.
• Адрес получателя проверен на наличие кода и обработчика.
• Разрешение выдано на номер, где это возможно, и отозвано после перевода.

Частые вопросы

Нормативные формулировки приводятся по текстам спецификации EIP-721 и спецификации EIP-1155. Сверка выполнена 17 октября 2026 года.