﻿---
title: "ERC-721"
description: "ERC-721 — стандартный интерфейс Ethereum для невзаимозаменяемых токенов (NFT): каждый токен идентифицируется отдельно, а смарт-контракт записывает правила владения и передачи."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# ERC-721

> Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.

<a id="answer"></a>

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

ERC-721 — стандартный интерфейс Ethereum для невзаимозаменяемых токенов. Вместо одного взаимозаменяемого баланса контракт ERC-721 отслеживает каждый токен через `tokenId`, показывает его владельца и определяет правила передачи и разрешений. Токен идентифицируется парой «адрес контракта и `tokenId`»; сам стандарт не устанавливает цену, подлинность, редкость или юридические права на актив.

ERC-721 отличается от ERC-20 тем, что единицы ERC-20 взаимозаменяемы: одну единицу предполагается обменивать на другую. Токены ERC-721 могут относиться к одной коллекции, но иметь разные идентификаторы и метаданные. Кошелёк или маркетплейс может поддерживать оба стандарта, однако вызовы передачи и разрешений различаются.

Важно не то, заявляет ли проект об использовании «ERC-721», а то, что на самом деле делают его контракт и окружающие системы. До того как считать NFT активом, проверьте реализацию, права доступа, метаданные, разрешения маркетплейса, ликвидность и обещанные держателям права.

<a id="mechanism"></a>

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

### Идентичность и владение

Контракт записывает владельца каждого существующего `tokenId`. `ownerOf` возвращает этот адрес, а `balanceOf` считает количество токенов у адреса. Минт обычно создаёт новый идентификатор и испускает событие `Transfer` из нулевого адреса; при сжигании обычно испускается перевод на нулевой адрес. События удобны для индексации, но источником истины является состояние контракта.

### Передача и разрешения

Владелец может напрямую вызвать `transferFrom` или разрешить один адрес для одного токена через `approve`. `setApprovalForAll` даёт оператору право управлять всеми токенами владельца в этой коллекции. Это удобно для маркетплейсов, но разрешение широкое. Проверяйте оператора по адресу контракта и отзывайте ненужные разрешения on-chain. Подписанный ордер маркетплейса отличается от разрешения в блокчейне: отмена одного не обязательно отменяет другое.

`safeTransferFrom` дополнительно проверяет, реализует ли контракт-получатель `IERC721Receiver`. Это снижает риск отправки токена в контракт, который не умеет его принимать; `transferFrom` не вызывает такой callback. Ни одна функция не гарантирует, что маркетплейс, мост или кошелёк корректно обработает токен.

### Метаданные и роялти

Необязательное расширение метаданных предоставляет `tokenURI`, которое может указывать на данные в блокчейне или вне его. Изменяемый базовый URI, обновляемый контракт, администратор или централизованный хостинг могут изменить отображение токена после минтинга. Постоянное и децентрализованное хранение уменьшает некоторые зависимости, но не доказывает авторство, происхождение или право собственности на интеллектуальную собственность.

ERC-721 не обязывает вторичные рынки платить создателю роялти. Коллекция может реализовать необязательный интерфейс роялти `EIP-2981`, но маркетплейс сам решает, соблюдать ли его; интерфейс не рассчитывает и не принуждает к оплате. Лимиты выпуска, случайность, подлинность произведения, лицензии на товарные знаки и другие обещания нужно отдельно проверять по коду, правилам распределения и юридическим документам.

<a id="example"></a>

## Пример

Предположим, контракт минтит токен `#42` для Alice. Токен не идентифицируется во всём мире одним числом `42`: частью идентичности является адрес контракта коллекции. Alice может выставить его на маркетплейсе, предоставив `approve` для этого токена или `setApprovalForAll` оператору. При продаже маркетплейс вызывает функцию передачи, а контракт проверяет владение и разрешение. После этого Alice стоит отозвать разрешение для всей коллекции, если оно больше не нужно.

Изображение, которое показывает маркетплейс, — отдельный вопрос метаданных. Alice должна проверить поведение `tokenURI`, права обновления, хостинг и лицензию коллекции, а не считать, что владение токеном передаёт авторские или коммерческие права.

<a id="risks"></a>

## Риски

- Риск контракта: ошибка, вредоносное обновление, привилегированный администратор или неверный хук передачи могут заблокировать или переместить токены.

- Риск разрешений: `setApprovalForAll` для всей коллекции или взломанный маркетплейс могут переместить все разрешённые токены этой коллекции.

- Риск метаданных и права: файлы вне блокчейна могут исчезнуть или измениться, а владение токеном автоматически не даёт авторских, товарных или иных юридических прав.

- Рыночный риск: цены NFT могут быть волатильными, ликвидность — низкой, а заявленная минимальная цена может быть недостижима для конкретного токена.

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

<a id="misconceptions"></a>

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

### Миф 1: ERC-721 гарантирует редкость

Стандарт лишь различает токены внутри одного контракта. Эмитент может выпустить дополнительные токены, развернуть похожие коллекции или направить несколько идентификаторов на равноценные медиафайлы. Редкость зависит от правил выпуска и прав, которые их обеспечивают.

### Миф 2: NFT включает все права интеллектуальной собственности

Блокчейн записывает передачу токена. Авторское право, воспроизведение, коммерческое использование, переработка и права на товарный знак зависят от лицензии коллекции и применимого закона; из `ownerOf` их вывести нельзя.

### Миф 3: Отмена объявления на маркетплейсе удаляет все разрешения

Объявление, его подпись и срок действия, а также on-chain `approve` или `setApprovalForAll` — разные состояния. Ненужное разрешение в блокчейне нужно отдельно проверить и отозвать.

<a id="related"></a>

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

- [Криптографический аккумулятор](/ru/crypto/cryptographic-accumulator/)
- [ERC-20](/ru/crypto/erc20/)
- [NFT](/ru/crypto/nft/)
- [Мнемоническая фраза](/ru/crypto/seed-phrase/)
- [Стандарт токенов](/ru/crypto/token-standard/)

<a id="sources"></a>

## Источники

- [ERC-721: Non-Fungible Token Standard](https://eips.ethereum.org/EIPS/eip-721) - Ethereum Improvement Proposals (дата обращения: 2026-08-20)
- [ERC-721 Non-Fungible Token Standard](https://ethereum.org/en/developers/docs/standards/tokens/erc-721/) - Ethereum.org (дата обращения: 2026-08-20)
- [ERC-2981: NFT Royalty Standard](https://eips.ethereum.org/EIPS/eip-2981) - Ethereum Improvement Proposals (дата обращения: 2026-08-20)
- [Соблюдайте осторожность при покупке цифровых монет или токенов](https://www.cftc.gov/LearnAndProtect/AdvisoriesAndArticles/caution_of_digital_currencies.html) - CFTC (дата обращения: 2026-08-20)

Source: https://wiki.fcontext.com/ru/crypto/erc721/index.mdx
