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: Extended Multiphase Fractional NFTs #344

Open
wants to merge 19 commits into
base: master
Choose a base branch
from
71 changes: 71 additions & 0 deletions ERCS/erc-7661.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,71 @@
---
eip: 7661
title: Extended Multiphase Fractional NFTs
description: Allows for ERC-721 tokens to be broken into multiple phases of fungible tokens
author: Jonathan Else (@JEflyer)
discussions-to: https://ethereum-magicians.org/t/erc-7661-xmf-nfts-extended-multiphase-fractional-nfts/19346
status: Draft
type: Standards Track
category: ERC
created: 2024-03-25
requires: 165, 721
---

## Abstract

An extension of [ERC-721](./eip-721.md) to enable tokens to have multiple phases of fractionalisation into [ERC-20](./eip-20.md)-like tokens.

This standard introduces a framework allowing [ERC-721](./eip-721.md) Non-Fungible Tokens (NFTs) to be broken down into phase-based tokens (PB Tokens) representing fractional ownership or states at various lifecycle phases. Unlike standard [ERC-20](./eip-20.md) tokens, PB Tokens accommodate the multifaceted nature of asset transformation, encapsulating phase transitions that reflect changes in the underlying asset's state, form, or value.

## Motivation

In industries involving supply chains or assets undergoing various forms of processing, a singular representation (as either a fungible or non-fungible token) falls short of depicting the asset's evolving nature. This standard addresses this gap by enabling dynamic representation and management of assets throughout their transformation phases, enhancing tracking and interaction with these assets on the blockchain.
Copy link
Contributor

Choose a reason for hiding this comment

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

Could you include some example use cases or assets that you think would be particularly suited to being represented as PB tokens?

Copy link
Author

Choose a reason for hiding this comment

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

The best usecase that I could think of was a pallet of 1 item that break down into boxes of items & then individual items.

I put an example on the explainer website. https://www.erc9988.info/

Copy link
Contributor

Choose a reason for hiding this comment

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

If you don't have a particular use case you're building towards, perhaps it's a bit early to standardize?


## Specification

### Phase Tokens (PB Tokens)

- PB Tokens are associated with an ERC-721 NFT, representing fractional ownership or specific attributes of the NFT in a given phase.
- Each PB Token phase reflects a distinct state or condition of the underlying asset, with the contract managing transitions between these phases.
Comment on lines +28 to +29
Copy link
Contributor

Choose a reason for hiding this comment

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

These aren't really implementable requirements, or at least they aren't phrased as such. Content in the specification section should have specific criteria that implementations can be judged against.


### Phase Transition

- Defines rules for transitioning PB Tokens between phases, simulating real-world asset transformations.
- Transition rules specify conditions for phase changes, potentially altering the token count to reflect consolidation or division of the asset.

### API

- `mint(address to, uint256[] memory phaseMultipliers)`: Mints a new token with specified phase multipliers. Each multiplier defines the conversion rate for transitioning from one phase to the next.
- `transitionPhase(uint256 parentTokenId, uint256 phaseFrom, uint256 phaseTo, uint256 amount)`: Transitions a specified amount of tokens from one phase to another for a given parent token ID.
- `burn(uint256 parentTokenId, uint256 phase, uint256 amount)`: Burns a specified amount of tokens in a given phase for a parent token ID.
- `tokenURI(uint256 tokenId)`: Returns the token URI for a given token ID, providing access to its metadata.
- `phaseURI(uint256 tokenId, uint256 phase)`: Returns the phase URI for a specific phase of a given token ID, providing access to phase-specific metadata.

### Events

- `MintingPhase(uint256 indexed tokenID, uint256 indexed phase, address indexed to, uint256 amount)`: Emitted when a new token is minted, indicating the phase and the amount of tokens created.
- `TransferPhase(uint256 indexed parentTokenId, uint256 indexed phaseFrom, uint256 indexed phaseTo, address to, uint256 amount)`: Reflects a phase transition of tokens from one phase to another, including the parent token ID, phases involved, and the amount transferred.
- `BurnPhase(uint256 indexed parentTokenId, uint256 indexed phase, address indexed from, uint256 amount)`: Logged when tokens are burned in a specific phase, showing the parent token ID, phase, sender, and amount burned.
- `ERC7661Transfer(address indexed from, address indexed to, uint256 tokenId, uint256 phase, uint256 amount)`: Indicates the transfer of tokens between accounts, specifying phases and amounts.

## Rationale

Introducing this standard fills a critical niche, blending the characteristics of ERC-721 and ERC-20 tokens to accurately represent dynamic assets. This standard is particularly suited for applications requiring detailed asset management through various phases of transformation.
Copy link
Contributor

Choose a reason for hiding this comment

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

This content belongs in the Motivation section. The Rationale section is here so you can explain why you made the choices you did while developing your standard. My favourite analogy is:

Motivation: We need to build a shed because...
Rationale: We painted the shed red because...


## Backwards Compatibility

This standard extends ERC-721 standards and introduces multi-phase fungibility within the scope of a single NFT. It is designed to be compatible with existing blockchain infrastructure, with considerations for unique interactions required by phase transitions and fractional ownership.

## Reference Implementation

An implementation can be found here: `https://github.com/JEflyer/ERC9988`
Copy link
Contributor

Choose a reason for hiding this comment

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

Please remove this external link. You can include a reference implementation in the assets/ directory if you'd like.


## Security Considerations

- Implementations must ensure secure handling of phase transitions, preventing unauthorized state changes.
- Approval and transfer mechanisms need to address the intricacies of phase-based token management, safeguarding against unauthorized access and manipulation.
- Interoperability with wallets and platforms requires careful consideration to accurately represent and manage PB Tokens' multi-phase nature.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).
Loading