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

EIP-4469: Wrapped metaverse tokens #4469

Closed
hskang9 opened this issue Nov 20, 2021 · 4 comments
Closed

EIP-4469: Wrapped metaverse tokens #4469

hskang9 opened this issue Nov 20, 2021 · 4 comments
Labels

Comments

@hskang9
Copy link
Contributor

hskang9 commented Nov 20, 2021

Simple Summary

Defines a standard interface for viewing the addresses and balances of wrapped metaverse tokens.

Abstract

Metaverses(e.g. Decentraland, SandBox, etc) are now emerging in Ethereum ecosystem, and the standard of the tokens in each metaverse are all aggregated into ERC1155 for efficiency.
Invented by Witek Radomski from Enjin, this has made many metaverse/game project to accomodate their assets to provide ownerships.
However, current ERC1155 has been sacrificing its interoperability to other universes and current defi ecosystem due to different data structure and mechanics. A certain contract to bridge them into prepared erc20 could be possible, but this just can create duplicate datas in the global state if source is not uniform. Due to this, I propose the standard wrapped metaverse token contract to wrap metaverse assets into the most widely used ERC20 tokens.

This EIP introduces a simple interface for exposing the addresses of all wrapped ERC1155 tokens in metaverses, as well as querying wrapped assets' balances.

Motivation

Many metaverse(or game) projects are choosing ERC1155 for efficiently generating their assets. Choosing ERC1155 for managing non-fungible tokens or other tokens in the game has brought memory efficiencies and less contract address for systems to operate. However, this has brought incompatibility between other existing defi infrastructure(e.g. Dexes, Lending, etc). When a user wants to liquidate their game assets or metaverse assets, he or she needs to change it to intermediary assets to acquire it then change it to ETH then buy other assets in different metaverse. This is very inefficient for interoperability between connecting ecosystems between metaverses as well due to gas fees required to convert one asset with another. Just as Wrapped ether has been invented, I propose to have wrapped ERC1155 asset that can be both backward compatible to existing decentralized finance infrastructure and free trade between metaverses.

Example

For example, if a user wants to sell their assets from existing metaverse, he or she wraps through the wrapper

Specification

Using create2, Wrapped metaverse tokens must be generated from creating wrapped ERC20 from the owner of ERC1155.
Once wrapped erc20 of metaverse assets are created, people can deposit ERC1155 to the contract then get the same kind and amount of designated ERC20 tokens.
Deposited ERC1155 tokens can be withdrawn from the contract by depositing designated wrapped ERC20 token.

Rationale

The specification designates a corresponding wrapped ERC20 token assigned to the ERC1155 token contract.
Wrapped ERC20 tokens are identified via their assetId, ERC1155 address, and data(for receiver).
ERC 1155 does not require any change.

Introspection

Contracts implementing this standard should make their interface available, such as IMeta for unwrapping and wrapping.

Backwards Compatibility

This EIP is backwards compatible with all existing contracts, as it only provides new view functions. Wrapped ERC20 in this specifcation adds data for receiver, assetId/ERC1155 address to identify itself, but it fully manages to support other ERC20 functionalities. ERC721 can also be included for wrapping(WIP)

Implementation

Implementation is currently made in this repo.

Standards of fragmentizing non-fungible-tokens could be added upon wrapping or come up with another standard.

Security Considerations

There may be security concerns regarding create2 as it has not yet been tested for this use case.
Other than that, this EIP does not introduce any significant security concerns, as it simply standardizes the access to information that is already available in many contracts.

It should be noted that this EIP does not enforce any guarantees about the validity of the information provided. A token could easily report inaccurate balance data, potentially misleading or scamming users.

Copyright

Copyright and related rights waived via CC0.

@hskang9 hskang9 changed the title EIP-4465: Wrapped metaverse tokens EIP-4469: Wrapped metaverse tokens Nov 20, 2021
@jaybutera
Copy link

Hi a few initial comments.

  • Consider removing application specific references to the metaverse as this generally describes a way to wrap ERC-1155 in ERC-20.
  • The reference implementation is small so code should be embedded in the document rather than linked to a another page which may change.
  • The specification needs more details at each step. For instance are there requirements for the salt parameter in create2 and if not why? Also show api examples for depositing the ERC-1155 token and for withdrawing.

@jaybutera
Copy link

Digging through the EIPs I found EIP-3386 which looks like the same design: An ERC-20 wrapper for 721/1155.

@hskang9
Copy link
Contributor Author

hskang9 commented Nov 22, 2021

Digging through the EIPs I found EIP-3386 which looks like the same design: An ERC-20 wrapper for 721/1155.

Nope, different design. it does not use create2, and it does not provide wrapped ERC20 corresponding to 721/1155.

@hskang9
Copy link
Contributor Author

hskang9 commented Nov 22, 2021

@jaybutera If you could read and understand the code, eip-4469 has requirement where one who creates wrapped tokens should be the ERC-1155 creator instead of mint and burning in batch. Also, you cannot consider ERC721 same as ERC1155. ERC1155 appeared as ERC721 is able to manage only one nft of its kind, and EIP-3386 is not compatible with ERC 1155 where its assets can be fungible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants