EIP-2309: ERC-721 Consecutive Transfer Extension

[pizzarob]

Original discussion in #2309

Simple Summary

A standardized event emitted when creating/transferring one, or many non-fungible tokens using consecutive token identifiers.

Abstract

The optional ERC-721 Consecutive Transfer Extension provides a standardized event which could be emitted during the creation/transfer of one, or many non-fungible tokens. This standard does not set the expectation of how you might create/transfer many tokens it is only concerned with the event emitted after the creation, or transfer of ownership of these tokens. This extension assumes that token identifiers are in consecutive order.

Motivation

This extension is provides even more scalibility of the ERC-721 specification. It is possible to create, transfer, and burn 2^255 non-fungible tokens in one transaction. However, it is not possible to emit that many Transfer events in one transaction. The Transfer event is part of the original specification which states:

This emits when ownership of any NFT changes by any mechanism.
This event emits when NFTs are created (from == 0) and destroyed
(to == 0). Exception: during contract creation, any number of NFTs
may be created and assigned without emitting Transfer. At the time of
any transfer, the approved address for that NFT (if any) is reset to none.

This allows for the original Transfer event to be emitted for one token at a time, which in turn gives us O(n) time complexity. Minting one billion NFTs can be done in one transaction using efficient data structures, but in order to emit the Transfer event - according to the original spec - one would need a loop with one billion iterations which is bound to run out of gas, or exceed transaction timeout limits. This cannot be accomplished with the current spec. This extension solves that problem.

Many decentralized marketplaces and block explorers utilize the Transfer event as a way to determine which NFTs an address owns. The Consecutive Transfer Extension provides a standard mechanism for these platforms to use to determine ownership of many tokens.

Specification

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

ERC-721 compliant contracts MAY implement this Consecutive Transfer Extension to provide a standard event to be emitted at the time of creation, burn, or transfer of one or many consecutive tokens

pragma solidity ^0.5.10;

/**
  @title ERC-2309: ERC-721 Consecutive Transfer Extension
  @dev https://github.com/ethereum/EIPs/issues/2309
 */

interface ERC721ConsecutiveTransfer /* is ERC721 */ {
  /**
    @notice This event is emitted when ownership of a consecutive batch of tokens changes by any mechanism.
    This includes minting, transferring, and burning.

    @dev The address executing the transaction MUST own all the tokens within the range of
    fromTokenId and toTokenId, or MUST be an approved operator to act on the owners behalf.
    The fromTokenId and toTokenId MUST be a consecutive range of tokens IDs.
    When minting/creating tokens, the `fromAddress` argument MUST be set to `0x0` (i.e. zero address).
    When burning/destroying tokens, the `toAddress` argument MUST be set to `0x0` (i.e. zero address).

    @param fromTokenId The token ID that begins the batch of tokens being transferred
    @param toTokenId The token ID that ends the batch of tokens being transferred
    @param fromAddress The address transferring ownership of the specified range of tokens
    @param toAddress The address receiving ownership of the specified range of tokens.
  */
  event ConsecutiveTransfer(uint indexed fromTokenId, uint toTokenId, address indexed fromAddress, address indexed toAddress);
}

The ConsecutiveTransfer event can be used for a single token as well as many tokens:

Single token creation

emit ConsecutiveTransfer(1, 1, address(0), toAddress);

Batch token creation

emit ConsecutiveTransfer(1, 100000, address(0), toAddress);

Rationale

Standardizing the ConsecutiveTransfer event gives decentralized platforms a standard way of determining ownership of large quantities of non-fungible tokens without the need to support a new token standard. There are many ways in which the batch creation and transfer of NFTs can be implemented. The Consecutive Transfer Extension allows contract creators to implement batch creation, transfer, and burn methods however they see fit, but provides a standardized event in which all implementations can use. By specifying a range of consecutive token identifiers we can easily cover the transfer, or creation of 2^(256-1) tokens and decentralized platforms can react accordingly.

Take this example. I sell lemons and have a farm with 10,000 lemon trees and 1,000 new lemon trees every few years. I want to turn each lemon tree into a non-fungible token that people can own. Each person that owns one of my non-fungible lemon tree tokens will receive a quarterly percentage of each harvest from that tree. The problem is that I would need to create and transfer each of these tokens individually - which will cost me a lot of time and money and frankly would keep me from doing this.

With this extension I would be able to to mint my initial 10,000 lemon tree tokens in one transaction. I would be able to quickly and cheaply mint my additional 1,000 lemon tree tokens when a new batch is planted. I would then be able to transfer all of the 10,000+ lemon tree tokens to a special smart contract that keeps track of the selling and distribution of funds in one transaction all while adhering to a specified standard.

Copyright

Copyright and related rights waived via CC0.

[axic]

This should be a Draft not a last call.

[pizzarob]

Thanks. Updated