Skip to content

Commit

Permalink
add getEncodedTokenIdentifier
Browse files Browse the repository at this point in the history
  • Loading branch information
jameswenzel authored and GitHub Actions Bot committed Apr 21, 2023
1 parent 1770975 commit 5b36079
Showing 1 changed file with 25 additions and 7 deletions.
32 changes: 25 additions & 7 deletions EIPS/eip-6912.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,9 +13,9 @@ requires: 721

## Abstract

This EIP proposes an extension to the [ERC-721](./eip-721.md) non-fungible token standard by introducing a Versioned TokenId standard for "dynamic" NFTs with on or offchain properties that may change over time. The new versionedTokenId is meant to track both the "identifier" of a token as well as its current "version" so that old outstanding orders and approvals for updated tokens are automatically invalidated.
This EIP proposes an extension to the [ERC-721](./eip-721.md) non-fungible token standard by introducing a Versioned TokenId standard for "dynamic" NFTs with on or offchain properties that may change over time. The new versionedTokenId is meant to track both the "identifier" of a token as well as its current "version number" so that old outstanding orders and approvals for updated tokens are automatically invalidated.

A `uint256 versionedTokenId` MUST encode both the true token "identifier" along with a "version number". Encoding details should be left up to individual token implementations.
A `uint256 versionedTokenId` MUST encode both the true token "identifier" along with a "version number". Encoding, storage, and retrieval specific details should be left up to individual token implementations, and this EIP does not make specific recommendations.

When any onchain action occurs that changes a dynamic token's metadata (on or offchain), the token contract MUST emit a transfer event for the current `versionedTokenId` from the current owner to the null address (i.e., "burning" the old token). It also then MUST emit a transfer event of an updated `versionedTokenId` (which encodes the new "version number" and the same "identifier") from the null address to the original owner. The actual encoded token "identifier" MUST not change, and the encoded "version number" MUST change.

Expand All @@ -35,17 +35,35 @@ Currently, if a token has a metadata update that makes it subjectively more or l
function getCurrentVersionedTokenId(uint256 tokenId) external view returns (uint256);
```

This method MUST return the current Versioned TokenId for the "identifier" encoded by a given `tokenId`.
This method is meant to ensure that it is always possible to find the current valid `cversionedTokenid` for a given token, even with an out-of-date or otherwise incorrect `versionedTokenId`, so long as the encoded "identifier" is valid.

It MUST revert if passed a `tokenId` with an invalid or non-existent "identifier."
This method MUST return the current `versionedTokenId` for the "identifier" encoded by a given `tokenId`.

It MUST return the current "version number" for the "identifier" encoded by the `tokenId`.
This method MUST revert if passed a `tokenId` with an invalid or non-existent "identifier."

It MUST NOT revert if the encoded "version number" is incorrect or outdated. This is to ensure it is always possible to find the current "version number" for a given token, even with an out-of-date or otherwise incorrect `versionedTokenId` (so long as the encoded "identifier" is valid).
This method MUST return the current "version number" for the "identifier" encoded by the `tokenId`.

It MUST NOT revert if the encoded "version number" is incorrect or outdated.

Implementation details about storage and retrieval of versioned token IDs SHOULD be left up to individual implementations.


#### getEncodedTokenIdentifier

```solidity
function getEncodedTokenIdentifier(uint256 versionedTokenId) external view returns (uint256);
```

This method is meant to ensure it is always possible to find the encoded "identifier" for a given `versionedTokenId`, even with an out-of-date or otherwise incorrect `versionedTokenId`. It MAY also enforce that the encoded "identifier" is valid.

This method MUST return the encoded "identifier" for a given `versionedTokenId`.

The method MAY revert if no token exists for the encoded "identifier" or the "identifier" is otherwise invalid.

The method MUST NOT revert if the encoded "version number" is incorrect or outdated.



### Changes to ERC-721 Methods

The following methods from ERC-721 MUST be updated to handle `versionedTokenIds`:
Expand Down Expand Up @@ -76,7 +94,7 @@ The standard ERC-721 `Transfer` event MUST be emitted when a token's metadata ch

## Rationale

The introduction of versioned token IDs allows for better and safer marketplace handling of NFTs with changing metadata, and ensures that only the latest "version" of a token is used in onchain transactions. The specified behavior in this EIP minimizes the changes to the ERC-721 standard while maintaining full backwards compatibility with all known marketplaces.
The introduction of versioned token IDs allows for better and safer marketplace handling of NFTs with changing metadata, and ensures that only the latest "version number" of a token is used in onchain transactions. The specified behavior in this EIP minimizes the changes to the ERC-721 standard while maintaining full backwards-compatibility with all known marketplaces.

## Security Considerations

Expand Down

0 comments on commit 5b36079

Please sign in to comment.