Create a new semi-fungible token standard request #4635
Conversation
|
The bot won't ping the appropriate people until you mark the PR as ready for review. |
Hi Micah |
| @param _data Additional data with no specified format | ||
| @return `bytes4(keccak256("onERCSFTBatchReceived(address,address,uint256[],uint256[],bytes)"))` | ||
| */ | ||
| function onERCSFTBatchReceived(address _operator, address _from, uint256[] calldata _types, uint256[] calldata _values, bytes calldata _data) external returns(bytes4); |
There was a problem hiding this comment.
I've added the number 0x198fb191 in "This function MUST return bytes4(keccak256("onERCSFTReceived(address,address,uint256,uint256,bytes)")) (i.e. 0x198fb191) if it accepts the transfer." and 0xa3a64bf1 in "This function MUST return bytes4(keccak256("onERCSFTBatchReceived(address,address,uint256[],uint256[],bytes)")) (i.e. 0xa3a64bf1) if it accepts the transfer(s)." I will also add the number in the return
|
Hi! I'm a bot, and I wanted to automerge your PR, but couldn't because of the following issue(s): (fail) eip-4635.md
|
There was a problem hiding this comment.
Left a few comments - I think I generally am not understanding the concept of "semi-fungibility" and how this differs from EIP-1155. The prose is a bit difficult to understand, I recommend spending some time to revise your abstract and motivation sections. Thanks.
| requires: 721 | ||
| --- | ||
|
|
||
| ## Simple Summary |
There was a problem hiding this comment.
This field has been deprecated in favor of the description preamble field. Please update accordingly.
| A standard interface for contracts that manage semi-fungible token(s). A single deployed contract usually includes multiple types of fungible tokens and one single transformational non-fungible token. | ||
|
|
||
| ## Abstract | ||
| This standard outlines a smart contract interface that can represent semi-fungible tokens (SFT). SFTs start out as types of fungible tokens and finally end as non-fungible tokens to provide value. ERC-1155 can manage combination of fungible tokens and non-fungible tokens, however, it's intractable for semi-fungible token representation. So this standard is specially for semi-fungible token use, in which fungible token types are managed like ERC-1155 and non-fungible tokens are totally managed by ERC-721. |
There was a problem hiding this comment.
It's not clear to me what the term "semi-fungible" means here?
There was a problem hiding this comment.
SFTs are a relatively new group of tokens that can be both fungible and non-fungible during their lifecycle.
e.g. the art museum tickets, it is FT in the beginning. and when it is bought by someone, the ticket will be updated with specific ID and name and now it is NFT.
| - [ERC-SFT Reference Implementation](https://github.com/linvictor88/ERC-SFT) | ||
|
|
||
| ## Security Considerations | ||
| All EIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. EIP submissions missing the "Security Considerations" section will be rejected. An EIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers. |
There was a problem hiding this comment.
Please remove this text and describe any security considerations regarding the EIP.
When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md
We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met: