ERC-7743: Multi-Owner Non-Fungible Tokens (MO-NFT)
A new type of non-fungible token that supports multiple owners, allowing shared ownership and transferability among users.
Abstract
This ERC proposes a new standard for non-fungible tokens (NFTs) that supports multiple owners. The MO-NFT standard allows a single NFT to have multiple owners, reflecting the shared and distributable nature of digital assets. This model incorporates mechanisms for provider-defined transfer fees and ownership burning, enabling flexible and collaborative ownership structures. It maintains compatibility with the existing ERC-721 standard to ensure interoperability with current tools and platforms.
Motivation
Traditional NFTs enforce a single-ownership model, which does not align with the inherent duplicability and collaborative potential of digital assets. MO-NFTs allow for shared ownership, promoting wider distribution and collaboration while maintaining secure access control. The inclusion of provider fees and ownership burning enhances the utility and flexibility of NFTs in representing digital assets and services.
Specification
Data Structures
-
Owners Mapping: A mapping from
tokenId
to an enumerable set of owner addresses. -
Balances Mapping: A mapping from owner addresses to the number of tokens they own.
-
Providers Mapping: A mapping from
tokenId
to the provider's address. -
Transfer Values Mapping: A mapping from
tokenId
to thetransferValue
fee.
Token Creation and Ownership Model
-
Minting:
-
The function
mintToken()
allows the creation of a new MO-NFT. The caller becomes both the initial owner and the provider of the token. -
A new
tokenId
is generated, and the caller is added to the owners set and recorded as the provider. ThebalanceOf
the caller is incremented.
-
-
Ownership List:
- The MO-NFT maintains a list of owners for each token. Owners are stored in an enumerable set to prevent duplicates and allow efficient lookup.
-
Provider Role:
- The provider is the initial owner who can set and update the
transferValue
fee. Only the provider can modify certain token parameters.
- The provider is the initial owner who can set and update the
-
Transfer Mechanism:
-
Owners can transfer the token to new owners using
transferFrom
. The transfer adds the new owner to the list without removing existing owners and transfers thetransferValue
fee to the provider.
-
Transfer of Ownership
-
Additive Ownership:
- Transferring ownership adds the new owner to the ownership list without removing current owners. This approach reflects the shared nature of digital assets.
-
Ownership Tracking:
- The smart contract tracks the list of owners for each MO-NFT using the
_owners
mapping.
- The smart contract tracks the list of owners for each MO-NFT using the
-
Provider Fee Handling:
- During a transfer, the specified
transferValue
fee is transferred to the provider. The contract must have sufficient balance to cover this fee.
- During a transfer, the specified
-
Burning Ownership:
-
Owners can remove themselves from the ownership list using the
burn
function.
-
Value Depreciation
-
Value Model:
- As the number of owners increases, the value of the MO-NFT may decrease to reflect the reduced exclusivity. This is an optional model and can be implemented at the application level.
-
Depreciation Mechanism:
- The value depreciation model can be defined based on the asset type and distribution strategy. This standard does not enforce a specific depreciation mechanism but acknowledges its importance.
Interface Definitions
Minting Functions
-
function mintToken() public onlyOwner returns (uint256);
-
function provide(string memory assetName, uint256 size, bytes32 fileHash, address provider, uint256 transferValue) external returns (uint256);
Transfer Functions
-
function transferFrom(address from, address to, uint256 tokenId) public;
-
function safeTransferFrom(address from, address to, uint256 tokenId) public;
(Disabled or overridden) -
function safeTransferFrom(address from, address to, uint256 tokenId, bytes memory data) public;
(Disabled or overridden)
Ownership Management Functions
-
function isOwner(uint256 tokenId, address account) public view returns (bool);
-
function getOwnersCount(uint256 tokenId) public view returns (uint256);
-
function balanceOf(address owner) external view returns (uint256 balance);
-
function ownerOf(uint256 tokenId) external view returns (address owner);
Provider Functions
function setTransferValue(uint256 tokenId, uint256 newTransferValue) external;
Burn Function
function burn(uint256 tokenId) external;
Events
-
event TokenMinted(uint256 indexed tokenId, address indexed owner);
-
event TokenTransferred(uint256 indexed tokenId, address indexed from, address indexed to);
-
event TokenBurned(uint256 indexed tokenId, address indexed owner);
-
event TransferValueUpdated(uint256 indexed tokenId, uint256 oldTransferValue, uint256 newTransferValue);
ERC-721 Compliance
The MO-NFT standard is designed to be compatible with the ERC-721 standard. It implements required functions such as balanceOf
, ownerOf
, and transferFrom
from the IERC-721 interface.
-
Approval Functions: Functions like
approve
,getApproved
,setApprovalForAll
, andisApprovedForAll
are intentionally disabled or overridden, as they do not align with the MO-NFT multi-owner model. -
Safe Transfer Functions: The
safeTransferFrom
functions are restricted because traditional ERC-721 transfer safety checks are not applicable when ownership is additive rather than exclusive. -
Supports Interface: The
supportsInterface
function ensures that the MO-NFT declares compatibility with the ERC-721 standard, allowing it to be integrated with existing tools and platforms.
Rationale
-
Multi-Ownership Model:
- Digital assets are inherently duplicable and can be shared without loss of quality. The multi-owner model allows broader distribution and collaboration while maintaining a unique token identity.
-
Additive Ownership:
- By adding new owners without removing existing ones, we support shared ownership models common in collaborative environments and digital content distribution.
-
Provider Fee Mechanism:
- Incorporating a provider fee incentivizes creators and providers by rewarding them whenever the asset is transferred. This aligns with models where creators receive royalties or fees for their work.
-
Ownership Burning:
- Allowing owners to remove themselves from the ownership list provides flexibility, enabling owners to relinquish rights or convert their digital ownership into real-world assets.
-
ERC-721 Compatibility:
- Maintaining compatibility with ERC-721 allows MO-NFTs to leverage existing infrastructure, tools, and platforms, facilitating adoption and interoperability.
Backwards Compatibility
While the MO-NFT standard aims to maintain compatibility with ERC-721, certain deviations are necessary due to the multi-owner model:
-
Approval Functions: Disabled or overridden to prevent their use, as they do not align with the MO-NFT's ownership structure.
-
Safe Transfer Functions: Restricted because the additive ownership model does not fit the exclusive ownership assumptions in ERC-721.
-
ownerOf
Function: Returns the first owner in the owners list for compatibility, but the concept of a single owner does not fully apply.
Developers should be aware of these differences when integrating MO-NFTs into systems designed for standard ERC-721 tokens.
Test Cases
-
Minting an MO-NFT and Verifying Initial Ownership:
-
Input:
- Call
mintToken()
as the provider.
- Call
-
Expected Output:
-
A new
tokenId
is generated. -
The caller is added as the first owner.
-
The
balanceOf
the caller increases by 1. -
The provider is recorded for the token.
-
TokenMinted
event is emitted.
-
-
-
Transferring an MO-NFT and Verifying Provider Fee Transfer:
-
Input:
- Call
transferFrom(from, to, tokenId)
wherefrom
is an existing owner andto
is a new address.
- Call
-
Expected Output:
-
The
to
address is added to the owners list. -
The
transferValue
fee is transferred to the provider. -
The
balanceOf
of theto
address increases by 1. -
TokenTransferred
event is emitted.
-
-
-
Burning Ownership:
-
Input:
- An owner calls
burn(tokenId)
.
- An owner calls
-
Expected Output:
-
The owner is removed from the owners list.
-
The
balanceOf
of the owner decreases by 1. -
If the owners list becomes empty, the token is effectively non-existent.
-
TokenBurned
event is emitted.
-
-
-
Setting Transfer Value:
-
Input:
- The provider calls
setTransferValue(tokenId, newTransferValue)
.
- The provider calls
-
Expected Output:
-
The
transferValue
is updated in the contract. -
TransferValueUpdated
event is emitted.
-
-
-
Failing Transfer to Existing Owner:
-
Input:
- Attempt to
transferFrom
to an address that is already an owner.
- Attempt to
-
Expected Output:
-
The transaction reverts with the error
"MO-NFT: Recipient is already an owner"
. -
No changes to ownership or balances occur.
-
-
Reference Implementation
The full reference implementation code for the MO-NFT standard is included in the EIPs repository under assets folder. This ensures the code is preserved alongside the EIP and remains accessible.
-
Contracts:
-
MONFT.sol
: The base implementation of the MO-NFT standard. -
DigitalAsset.sol
: An extended implementation for digital assets with provider fees.
-
-
Interfaces:
IDigitalAsset.sol
: Interface defining the functions for digital asset management.
Key Functions in Reference Implementation
Minting Tokens
Transferring Tokens
Burning Ownership
Security Considerations
-
Reentrancy Attacks:
-
Mitigation: Use the Checks-Effects-Interactions pattern when transferring Ether (e.g., transferring
transferValue
to the provider). -
Recommendation: Consider using
ReentrancyGuard
from OpenZeppelin to prevent reentrant calls.
-
-
Integer Overflow and Underflow:
- Mitigation: Solidity 0.8.x automatically checks for overflows and underflows, throwing exceptions when they occur.
-
Access Control:
-
Ensured By:
-
Only owners can call transfer functions.
-
Only providers can set the
transferValue
. -
Use of
require
statements to enforce access control.
-
-
-
Denial of Service (DoS):
-
Consideration: Functions that iterate over owners could be expensive in terms of gas if the owners list is large.
-
Mitigation: Avoid such functions or limit the number of owners.
-
-
Data Integrity:
- Ensured By: Proper use of Solidity's data types and structures, and by emitting events for all state-changing operations for off-chain verification.
-
Ether Handling:
-
Consideration: Ensure the contract can receive Ether to handle provider payments.
-
Mitigation: Implement a
receive()
function to accept Ether.
-
Copyright
Copyright and related rights waived via CC0.