Skip to content

Commit

Permalink
Update ERC-7743: Move to Review
Browse files Browse the repository at this point in the history
Merged by EIP-Bot.
  • Loading branch information
jamesavechives authored Feb 9, 2025
1 parent 99c224b commit 5f0558c
Showing 1 changed file with 4 additions and 44 deletions.
48 changes: 4 additions & 44 deletions ERCS/erc-7743.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ title: Multi-Owner Non-Fungible Tokens (MO-NFT)
description: A new type of non-fungible token that supports multiple owners, allowing shared ownership and transferability among users.
author: James Savechives (@jamesavechives)
discussions-to: https://ethereum-magicians.org/t/discussion-on-eip-7743-multi-owner-non-fungible-tokens-mo-nft/20577
status: Draft
status: Review
type: Standards Track
category: ERC
created: 2024-07-13
Expand All @@ -20,32 +20,6 @@ Traditional NFTs enforce a single-ownership model, which does not align with the

## Specification

### Data Structures

- **Owners Mapping**: A mapping from `tokenId` to an enumerable set of owner addresses.

```solidity
mapping(uint256 => EnumerableSet.AddressSet) internal _owners;
```

- **Balances Mapping**: A mapping from owner addresses to the number of tokens they own.

```solidity
mapping(address => uint256) private _balances;
```

- **Providers Mapping**: A mapping from `tokenId` to the provider's address.

```solidity
mapping(uint256 => address) private _providers;
```

- **Transfer Values Mapping**: A mapping from `tokenId` to the `transferValue` fee.

```solidity
mapping(uint256 => uint256) private _transferValues;
```

### Token Creation and Ownership Model

1. **Minting**:
Expand Down Expand Up @@ -80,32 +54,18 @@ Traditional NFTs enforce a single-ownership model, which does not align with the
- Transferring ownership adds the new owner to the ownership list without removing current owners. This approach reflects the shared nature of digital assets.
2. **Ownership Tracking**:
- The smart contract tracks the list of owners for each MO-NFT using the `_owners` mapping.
3. **Provider Fee Handling**:
2. **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.
4. **Burning Ownership**:
3. **Burning Ownership**:
- Owners can remove themselves from the ownership list using the `burn` function.
```solidity
function burn(uint256 tokenId) external;
```
### Value Depreciation
1. **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.
2. **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**
Expand Down Expand Up @@ -152,7 +112,7 @@ Traditional NFTs enforce a single-ownership model, which does not align with the
### [ERC-721](./eip-721.md) Compliance
The MO-NFT standard is designed to be compatible with the [ERC-721](./eip-721.md) standard. It implements required functions such as `balanceOf`, `ownerOf`, and `transferFrom` from the IERC-721 interface.
The MO-NFT standard is designed to be compatible with the [ERC-721](./eip-721.md) standard. It implements required functions such as `balanceOf`, `ownerOf`, and `transferFrom` from the `ERC721` interface.
- **Approval Functions**: Functions like `approve`, `getApproved`, `setApprovalForAll`, and `isApprovedForAll` are intentionally disabled or overridden, as they do not align with the MO-NFT multi-owner model.
Expand Down

0 comments on commit 5f0558c

Please sign in to comment.