eip:
title: Non-fungible Data Token
author: Ben ben@ost.com, Johann <@JohBa>
discussions-to: https://ethereum-magicians.org/t/auditable-storage-passing/1722
status: Draft
type: Standards Track
category (*only required for Standard Track): ERC
created: 2018-10-29
requires: ERC721

Simple Summary

Some use-cases require to have dynamic data associated with a non-fungible token that can change during its live-time. Examples for dynamic data:

• cryptokitties that can change color
• intellectual property tokens that encode rights holders
• tokens that store data to transport them across chains

The existing meta-data standard does not suffice as data can only be set at minting time and not modified later.

Abstract

Non-fungible tokens (NFTs) are extended with the ability to store dynamic data. A 32 bytes data field is added and a read function allows to access it. The write function allows to update it, if the caller is the owner of the token. An event is emitted every time the data updates and the previous and new value is emitted in it.

Motivation

The proposal is made to standardize on tokens with dynamic data. Interactions with bridges for side-chains like xDAI or Plasma chains will profit from the ability to use such tokens. Protocols that build on data tokens like distributed breeding will be enabled.

Specification

pragma solidity ^0.5.2;

import 'openzeppelin-solidity/contracts/token/ERC721/ERC721.sol';

contract ERC1537 is ERC721 {
  
  event DataUpdated(uint256 indexed tokenId, bytes32 oldData, bytes32 newData);
  mapping(uint256 => bytes32) data;

  function mint(address _to, uint256 _tokenId) public {
    super._mint(_to, _tokenId);
  }

  function burn(uint256 _tokenId) public {
    super._burn(ownerOf(_tokenId), _tokenId);
    delete(data[_tokenId]);
  }

  function readData(uint256 _tokenId) public view returns (bytes32) {
    require(_exists(_tokenId));
    return data[_tokenId];
  }

  function writeData(uint256 _tokenId, bytes32 _newData) public {
    require(msg.sender == ownerOf(_tokenId));
    emit DataUpdated(_tokenId, data[_tokenId], _newData);
    data[_tokenId] = _newData;
  }

}

Rationale

The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->

The data field is used either for storing data directly, like a counter or address. If more data is required the implementer should fall back to authenticated data structures, like merkle or patricia trees.

Copyright

Copyright and related rights waived via CC0.