Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ERC: Splitable utility NFT extension for ERC-721 #136

Closed
wants to merge 12 commits into from
155 changes: 155 additions & 0 deletions ERCS/erc-7567.md
@@ -0,0 +1,155 @@
---
eip: 7567
title: Splitable utility NFT extension for ERC-721
description: Interfaces for adding splitable utility properties to ERC-721
author: Aditya Shukla (@adityashukla700), Akshat Modani (@Akshat12210), Namish Khandelwal (@Namishk), Sparsh Goud (@sparsh76)
discussions-to: https://ethereum-magicians.org/t/splitable-utility-nft-token-for-erc-721/16380
status: Draft
type: Standards Track
category: ERC
created: 2023-11-28
requires: 165, 721
---

## Abstract


Comment on lines +15 to +16
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change


This standard is an extension of [ERC-721](./eip-721.md). It proposes splitable utility properties to a NFT, which will allow user to have or trade specific utilities instead of whole set as an NFT. It gives creators ability to add new utility functionality to their tokens.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your abstract is a bit light on technical details. What is a "utility"? How does this standard accomplish its goals? The abstract should have enough detail that readers get a high-level technical overview of your proposal.


Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change


## 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.

**Overview**
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use subheadings to start subsections.

Suggested change
**Overview**
### Overview


Multiutility token contracts, compliant with the [ERC-721](./eip-721.md) standard, `MAY` implement this extension to provide standard methods for `managing` the `distribution` and `transfer` of `utilities` associated with NFTs.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More specifically, only use backticks (`) for code snippets. Use italics or bold for non-code terms with specific definitions.


**Token Utility Management:** Token owners `MAY` assign specific utilities to their NFTs using the `mintUtilityNFT(uint256[] memory utilityIndex)` function. This function mints a new NFT with the specified utility IDs. Existing NFTs can also be augmented with additional utilities using the `mintNewUtilityToNFT(uint256 tokenId, uint256 utilityIndex)` function.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just use "MAY" (no quotes, without backticks) when referencing the RFC 2119 keywords. This applies throughout the document.


**Utility Transfer:** Token owners `MAY` transfer a `subset` of utilities from their NFTs to a newly minted NFT for a designated recipient using the `transferUtilities(uint256 tokenId, address receiver)` function. This mechanism enables the `selective distribution` of utilities among NFT holders.

**Utility Administrator:** Administrators of the contract `MAY` add new utilities to the list of available utilities using the `addUtilities(Utility memory utility)` function. This function allows for the `expansion` of the utility ecosystem without explicit creation of NFT and the introduction of new utility types.

**Utility Information Access:**
The contract provides functions for retrieving information about utilities and their association with NFTs:
- `getUtilitiesOf(uint256 _tokenID)`: It retrieves the list of utility IDs associated with a specific NFT's tokenID.
- `allUtilitiesList()`: This function retrieves the complete list of available utilities, including their IDs, names, issuers, and transferability status.
- `allUtilityIndexList()`: This function returns the list of IDs of all available utilities.
- `utilityMap(uint256 id)`: Returns the details of a specific utility based on its ID.

**Interface**
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
**Interface**
### Interface

```solidity
// SPDX-License-Identifier: CC0
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// SPDX-License-Identifier: CC0
// SPDX-License-Identifier: CC0-1.0


pragma solidity ^0.8.20;

/// @title Multiutility Contract Interface
/// @dev Interface for the Multiutility contract
/// @author []

interface Multiutility {
struct Utility {
​ uint256 id;
​ string name;
​ address issuer;
​ bool transferable;
}

/**
* @dev Mint a new utility NFT with the specified utility indices.
* @param utilityIndex Array of utility indices to be associated with the NFT.
*/

function mintUtilityNFT(uint256[] memory utilityIndex) external;
/**
* @dev Mint a new utility NFT with all available utilities.
*/
function mintFullNFT() external;

/**
* @dev Transfer utilities from one token to another, and transfer the new token to the receiver.
* @param tokenId The ID of the token containing the utilities to be transferred.
* @param receiver The address to receive the new token with transferred utilities.
*/

function transferUtilities(uint256 tokenId, address receiver) external;

/**
* @dev Add a new utility to the contract.
* @param utility The utility struct to be added.
*/

function addUtilities(Utility memory utility) external;

/**
* @dev Mint a new utility to an existing NFT.
* @param tokenId The ID of the existing NFT.
* @param utilityIndex The index of the utility to be minted to the NFT.
*/

function mintNewUtilityToNFT(uint256 tokenId, uint256 utilityIndex) external;

/**
* @dev Get the utilities associated with a specific token.
* @param \_tokenID The ID of the token to query for utilities.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The backslash here is unnecessary.

Suggested change
* @param \_tokenID The ID of the token to query for utilities.
* @param _tokenID The ID of the token to query for utilities.

* @return An array of utility indices associated with the token.
*/

function getUtilitiesOf(uint256 \_tokenID) external view returns (uint256[] memory);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
function getUtilitiesOf(uint256 \_tokenID) external view returns (uint256[] memory);
function getUtilitiesOf(uint256 _tokenID) external view returns (uint256[] memory);


/**
* @dev Get a list of all utilities defined in the contract.
* @return An array of utility structs representing all utilities.
*/

function allUtilitiesList() external view returns (Utility[] memory);

/**
* @dev Get a list of all utility indices defined in the contract.
* @return An array of utility indices.
*/

function allUtilityIndexList() external view returns (uint256[] memory);

/**
* @dev Get information about a specific utility based on its ID.
* @param id The ID of the utility to query.
* @return A utility struct representing the specified utility.
*/

function utilityMap(uint256 id) external view returns (Utility memory);
}
```

## Rationale
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A lot of your rationale below justifies the existence of the EIP as a whole. The Rationale section should explain technical choices made within the EIP itself.

Motivation: "Why do we need a shed?"
Rationale: "Why did we paint the shed red?"

The concept of the Multi NFT standard suggests a method, for incorporating multiple functionalities into a single NFT. This approach aims to tackle issues commonly associated with NFT implementations:


**Limited Functionality:**
Traditional NFTs typically represent ownership of digital assets like images or videos but they lack the capability to include additional functionalities or benefits. The Multi utility NFT standard enables NFTs to serve as a platform that can integrate utilities expanding their potential beyond just being tokens of ownership.



Comment on lines +132 to +133
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change

**Fragmented Utility Management:**
Managing utilities linked to NFTs can become burdensome and inefficient. The Multi utility NFT standard consolidates these utilities within one NFT simplifying user management and enhancing the utility experience.



Comment on lines +137 to +138
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change

**Unstructured Utility Integration:**
Integrating utilities into NFTs often involves custom code and complex interactions, with contracts making it difficult for developers to create reusable utility components. The Multi utility NFT standard introduces an interface that defines and integrates utilities promoting interoperability and facilitating adoption.




Comment on lines +142 to +144
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change


## Backwards Compatibility
This standard is compatible with [ERC-721](./eip-721.md) standards.

Existing Upgradedable [ERC-721](./eip-721.md) can upgrade to this standard, enabling locking capability inherently and unlock underlying liquidity features.

## Security Considerations
There are no security considerations related directly to the implementation of this standard for the contract that manages [ERC-721](./eip-721.md).

## Copyright
Copyright and related rights waived via CC0.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please use the exact copyright waiver from the template.