-
Notifications
You must be signed in to change notification settings - Fork 592
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
base: master
Are you sure you want to change the base?
Changes from all commits
a58c191
b339ce5
3c9e6ef
7cba32e
6f88253
6e86fa9
416ef05
4c2822f
0da34c5
502e7b5
1293b79
6a4828f
469057e
4733723
c700a3d
fe47ce4
d82b1e7
ca29c43
33a6d4f
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,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. | ||
|
||
## 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
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. 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. | ||
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 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:
|
||
|
||
## 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` | ||
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 remove this external link. You can include a reference implementation in the |
||
|
||
## 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). |
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.
Could you include some example use cases or assets that you think would be particularly suited to being represented as PB tokens?
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.
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/
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.
If you don't have a particular use case you're building towards, perhaps it's a bit early to standardize?