-
Notifications
You must be signed in to change notification settings - Fork 5.3k
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 EIP: NFT Dynamic Ownership #7158
Changes from all commits
cc3ec29
55e40b4
1019781
02b5787
0ee8785
6c01dbc
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
@@ -0,0 +1,213 @@ | ||||||
--- | ||||||
eip: 7110 | ||||||
title: NFT Dynamic Ownership | ||||||
description: An innovative extension to NFT token that introduces dynamic ownership and nesting capabilities. | ||||||
author: hiddenintheworld.eth (@hiddenintheworld) | ||||||
discussions-to: https://ethereum-magicians.org/t/erc-7110-nft-dynamic-ownership/14516 | ||||||
status: Draft | ||||||
type: Standards Track | ||||||
category: ERC | ||||||
created: 2023-06-01 | ||||||
requires: 721 | ||||||
--- | ||||||
|
||||||
## Abstract | ||||||
|
||||||
A standard interface for non-fungible tokens (NFTs) with dynamic ownership, which extends the capabilities of the original `ERC-721` standard by enabling NFTs to be owned by either addresses or other NFTs. The proposed `ERC-721D` standard introduces dynamic ownership in the world of NFTs. Instead of a token being owned solely by an address, as it is in the `ERC-721` standard, tokens following the `ERC-721D` standard can be owned by either an address or another token. This opens up new possibilities and adds an extra layer of complexity and opportunity in the NFT space. This EIP outlines the rules and functions needed to support this dynamic ownership model while maintaining compatibility with `ERC-721` standards. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. When you're referring to another proposal, don't enclose it in backticks. You have to use a link the first time (per proposal), but after that you can just reference the proposal as normal. When referring to your interfaces, however, you should use backticks.
Suggested change
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think you can probably cut a bit from your abstract and move it into motivation. The abstract should be a terse technical summary of the proposal that gives the reader a general idea of how the proposal works. |
||||||
|
||||||
## Motivation | ||||||
|
||||||
Non-fungible tokens (NFTs) have paved the way for unique digital assets. However, they are inherently restricted by their static ownership. `ERC-721D` aims to innovate the concept of NFT ownership by allowing tokens to have dynamic ownership chains. This could unlock an entirely new dimension for tokenized digital assets and decentralized applications (dApps). | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
|
||||||
## Specification | ||||||
|
||||||
|
||||||
|
||||||
### Overview | ||||||
|
||||||
`ERC-721D` is a standard interface for NFTs with dynamic ownership. It provides essential functionalities to manage, transfer, and track the ownership of tokens. It is an extension of the `ERC-721` standard. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
|
||||||
### Data Structures | ||||||
|
||||||
The `ERC-721D` standard introduces a new data structure, **```Ownership```**. Each token has an **```Ownership```** associated with it that consists of the **```ownerAddress```** and the **```tokenId```**. The **```ownerAddress```** is the address of the token owner, which can be an EOA or a contract address. If the owner is another NFT, then tokenId represents the ID of the owner token. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's a lot of bold!
Suggested change
|
||||||
|
||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Your specification section doesn't include enough detail to be implementable. You'll need more in-depth explanations of the changes to, for example, |
||||||
### Functions | ||||||
|
||||||
The `ERC-721D` standard defines a set of functions for interacting with tokens. It includes existing functions from the `ERC-721` standard, like **```balanceOf```** and **```ownerOf```**, with necessary modifications to support dynamic ownership. It also introduces new functions like **```setOwnership```** to manage dynamic ownership. The **```mint```** and **```burn```** functions have been overridden to account for changes in the balance of dynamic owners. The **```_transfer```** function has been updated to handle transfers involving dynamic owners. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The An ERC only defines the externally visible behaviour of a smart contract, and should not impose any particular implementation choices. |
||||||
|
||||||
### Implementation | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Please move any implementations to the reference implementation section. The specification section should only really contain an interface. |
||||||
|
||||||
Below is the full implementation: | ||||||
|
||||||
|
||||||
```solidity | ||||||
// SPDX-License-Identifier: MIT | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Code contained within the EIP itself must be |
||||||
|
||||||
pragma solidity ^0.8.0; | ||||||
|
||||||
import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol"; | ||||||
import "@openzeppelin/contracts/access/Ownable.sol"; | ||||||
|
||||||
/* | ||||||
|
||||||
The ERC721D standard is an advanced and dynamic implementation of the ERC721 token standard. | ||||||
This innovative contract takes the non-fungible token (NFT) concept a step further by introducing dynamic ownership. | ||||||
In conventional NFTs, a token can only be owned by an address. | ||||||
However, in the ERC721D standard, ownership can be dynamic, meaning an NFT can be owned by either an address or another NFT. | ||||||
This introduces a new layer of complexity and opportunity in the NFT space. | ||||||
|
||||||
*/ | ||||||
contract ERC721D is ERC721, Ownable { | ||||||
|
||||||
// The Ownership structure represents the owner of the token | ||||||
struct Ownership { | ||||||
address ownerAddress; // The address of the owner | ||||||
uint256 tokenId; // The token Id of the owner if the owner is an NFT | ||||||
} | ||||||
|
||||||
// Mapping from token ID to Ownership | ||||||
mapping(uint256 => Ownership) private _owners; | ||||||
|
||||||
// Mapping from owner address to token balance | ||||||
mapping(address => uint256) private _balances; | ||||||
|
||||||
constructor() ERC721("ERC721D", "ERC721D") {} | ||||||
|
||||||
// Mint new token | ||||||
// `to` is the address that will own the minted token | ||||||
// `tokenId` is the identifier for the new token | ||||||
function mint(address to, uint256 tokenId) public onlyOwner { | ||||||
_mint(to, tokenId); | ||||||
_owners[tokenId] = Ownership(to, 0); | ||||||
_balances[to] += 1; | ||||||
} | ||||||
|
||||||
// Burn token | ||||||
// `tokenId` is the identifier for the token | ||||||
function burn(uint256 tokenId) public { | ||||||
require(_isApprovedOrOwner(_msgSender(), tokenId), "ERC721D: caller is not owner nor approved"); | ||||||
|
||||||
Ownership memory oldOwnership = _owners[tokenId]; | ||||||
if (oldOwnership.ownerAddress != address(0)) { | ||||||
// Decrease the balance of the old owner | ||||||
_balances[oldOwnership.ownerAddress] -= 1; | ||||||
} | ||||||
|
||||||
// Set token ownership to the zero address (burning the token) | ||||||
_owners[tokenId] = Ownership(address(0), 0); | ||||||
_burn(tokenId); | ||||||
} | ||||||
|
||||||
// Transfer Nested Ownership of a token | ||||||
// `tokenId` is the identifier for the token | ||||||
// `newOwnerAddress` is the address of the new owner | ||||||
// `newTokenId` is the token Id of the new owner if the owner is an NFT | ||||||
function transferNestedOwnership(uint256 tokenId, address newOwnerAddress, uint256 newTokenId) public { | ||||||
require(_isApprovedOrOwner(_msgSender(), tokenId), "ERC721D: caller is not owner nor approved"); | ||||||
Ownership memory oldOwnership = _owners[tokenId]; | ||||||
|
||||||
// First time ownership, balance increases | ||||||
// Ownership is changing, adjust the balances | ||||||
if (oldOwnership.ownerAddress == address(0) || oldOwnership.ownerAddress != newOwnerAddress) { | ||||||
address oldOwner = oldOwnership.ownerAddress; | ||||||
_balances[oldOwner] -= 1; | ||||||
_balances[newOwnerAddress] += 1; | ||||||
} | ||||||
// Else: The token is being re-assigned to a different token but the same owner, do not change the balance. | ||||||
|
||||||
_owners[tokenId] = Ownership(newOwnerAddress, newTokenId); | ||||||
} | ||||||
|
||||||
// Overrides the 'ownerOf' function from the ERC721 standard. | ||||||
// Returns the current owner of the token identified by `tokenId`. | ||||||
// It navigates through potential layers of ownership, making it suitable for dynamic token structures. | ||||||
function ownerOf(uint256 tokenId) public view override(ERC721) returns (address) { | ||||||
address currentOwnerAddress = _owners[tokenId].ownerAddress; | ||||||
uint256 currentTokenId = _owners[tokenId].tokenId; | ||||||
|
||||||
// This loop will go through the ownership layers of the token. | ||||||
// It stops if the owner address is zero (no owner), or if there's an error calling the ownerOf function on the owner contract, | ||||||
// or if the returned owner is the same as the current owner (end of ownership chain). | ||||||
while (currentOwnerAddress != address(0)) { | ||||||
bytes memory payload = abi.encodeWithSignature("ownerOf(uint256)", currentTokenId); | ||||||
(bool success, bytes memory result) = currentOwnerAddress.staticcall(payload); | ||||||
if (!success || result.length == 0) { | ||||||
break; | ||||||
} | ||||||
|
||||||
address newOwnerAddress = abi.decode(result, (address)); | ||||||
if (newOwnerAddress != currentOwnerAddress) { | ||||||
currentOwnerAddress = newOwnerAddress; | ||||||
currentTokenId = _owners[currentTokenId].tokenId; | ||||||
} else { | ||||||
break; | ||||||
} | ||||||
} | ||||||
|
||||||
// Return the final owner in the chain | ||||||
return currentOwnerAddress; | ||||||
} | ||||||
|
||||||
// This internal function is used to implement the transfer of tokens, following the ERC721 standard but allowing dynamic token ownership. | ||||||
// It transfers the `tokenId` token from the `from` address to the `to` address. | ||||||
function _transfer(address from, address to, uint256 tokenId) internal virtual override { | ||||||
require(ownerOf(tokenId) == from, "ERC721D: transfer of token that is not owned"); | ||||||
Ownership memory oldOwnership = _owners[tokenId]; | ||||||
|
||||||
_approve(address(0), tokenId); | ||||||
_owners[tokenId] = Ownership(to, 0); | ||||||
|
||||||
if (oldOwnership.ownerAddress == address(0)) { | ||||||
// The token is being owned for the first time, increase the balance of the new owner | ||||||
_balances[to] += 1; | ||||||
} else if (oldOwnership.ownerAddress != to) { | ||||||
// The token is changing owner, adjust the balances | ||||||
address oldOwner = oldOwnership.ownerAddress; | ||||||
_balances[oldOwner] -= 1; | ||||||
_balances[to] += 1; | ||||||
} | ||||||
|
||||||
emit Transfer(from, to, tokenId); | ||||||
} | ||||||
|
||||||
// An internal function that checks if a `spender` is an approved operator or the owner of a token. | ||||||
// Returns true if the `spender` is an approved operator or the owner of the `tokenId` token. | ||||||
// The function follows the ERC721 standard requirements. | ||||||
function _isApprovedOrOwner(address spender, uint256 tokenId) internal view override returns (bool) { | ||||||
require(_exists(tokenId), "ERC721D: operator query for nonexistent token"); | ||||||
address owner = ownerOf(tokenId); | ||||||
return (spender == owner || getApproved(tokenId) == spender || isApprovedForAll(owner, spender)); | ||||||
} | ||||||
|
||||||
// Overrides the `balanceOf` function from the ERC721 standard. | ||||||
// Returns the balance (number of owned tokens) of the `owner` address. | ||||||
// It checks for the zero address and returns the balance from the internal _balances mapping. | ||||||
function balanceOf(address owner) public view override(ERC721) returns (uint256) { | ||||||
require(owner != address(0), "ERC721D: balance query for the zero address"); | ||||||
return _balances[owner]; | ||||||
} | ||||||
|
||||||
// This function returns the ownership details of the `tokenId` token. | ||||||
// Returns a struct with the owner's address and the token id of the token owned by the returned token (if any). | ||||||
function owners(uint256 tokenId) public view returns (Ownership memory) { | ||||||
return _owners[tokenId]; | ||||||
} | ||||||
|
||||||
} | ||||||
``` | ||||||
|
||||||
## Rationale | ||||||
|
||||||
The `ERC-721D` standard seeks to expand the potential of NFTs by introducing dynamic ownership. This innovation could open up new use cases in the fields of digital assets, dApps, digital identity, and more. As the digital economy evolves, the need for complex and dynamic relationships between tokens will become increasingly relevant, and the `ERC-721D` standard addresses this need. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This reads more like motivation. The Rationale section should justify technical choices made within the EIP itself, while the Motivation section justifies the EIP as a whole. An example of something you may want to explain in the Rationale section is why you chose EIP-721 as the base of your extension and not EIP-1155. |
||||||
|
||||||
## Backwards Compatibility | ||||||
|
||||||
`ERC-721D` is fully backward compatible with the `ERC-721` standard. It extends the `ERC-721` standard by adding dynamic ownership while maintaining all existing functionalities. Any existing `ERC-721` token can be upgraded to an `ERC-721D` token while retaining its original capabilities. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
|
||||||
## Security Considerations | ||||||
|
||||||
As with any smart contract standard, security considerations are paramount. Implementers of `ERC-721D` should ensure that they have robust systems in place for managing the Ownership structure and that transfers, minting, and burning of tokens are handled securely. It's crucial to thoroughly test and audit any contracts that implement `ERC-721D` to avoid potential security risks. Moreover, dealing with dynamic ownership presents additional complexities, which require extra caution while implementing this standard. | ||||||
|
||||||
## Copyright | ||||||
|
||||||
Copyright and related rights waived via CC0. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.