DCIPs/EIPS/eip-6047.md

eip	title	description	author	discussions-to	status	type	category	created	requires
6047	ERC-721 Balance indexing via Transfer event	Mandates emitting the Transfer event for ERC-721 NFTs during contract creation	Zainan Victor Zhou (@xinbenlv)	https://ethereum-magicians.org/t/eip-xxx-require-erc721-to-always-emit-transfer/11894	Draft	Standards Track	ERC	2022-11-26	721

Abstract

This EIP extends ERC-721 to allow the tracking and indexing of NFTs by mandating that a pre-existing event be emitted during contract creation.

ERC-721 requires a Transfer event to be emitted whenever a transfer or mint (i.e. transfer from 0x0) or burn (i.g. transfer to 0x0) occurs, except during contract creation. This EIP mandates that compliant contracts emit a Transfer event regardless of whether it occurs during or after contract creation.

Motivation

ERC-721 requires a Transfer event to be emitted whenever a transfer or mint (i.e. transfer from 0x0) or burn (i.e. transfer to 0x0) occurs, EXCEPT for during contract creation. Due to this exception, contracts can mint NFTs during contract creation without the event being emitted. Unlike ERC-721, the ERC-1155 standard mandates events to be emitted regardless of whether such minting occurs during or outside of contract creation. This allows an indexing service or any off-chain service to reliably capture and account for token creation.

This EIP removes this exception granted by ERC-721 and mandates emitting the Transfer for ERC-721 during contract creation. In this manner, indexers and off-chain applications can track token minting, burning, and transferring while relying only on ERC-721's Transfer event log.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

1. Compliant contracts MUST implement ERC-721
2. Compliant contracts MUST emit a Transfer event whenever a token is transferred, minted (i.e. transferred from 0x0), or burned (i.g. transferred to 0x0), including during contract creation.

Rationale

Using the existing Transfer event instead of creating a new event (e.g. Creation) allows this EIP to be backward compatible with existing indexers.E

Backwards Compatibility

All contracts compliant with this EIP are compliant with ERC-721. However, not all contracts compliant with ERC-721 are compliant with this EIP.

Security Considerations

No new security concerns.

Copyright

Copyright and related rights waived via CC0.