Entangled Tokens
The ERC-4950 proposal suggests an extension to the ERC-721 standard for non-fungible tokens in Ethereum, where two tokens are minted together and are entangled. This means that only one transfer is possible for the two tokens, and they are tied together. The proposal aims to provide an easy way to share a wallet through NFTs, where buying an NFT in a marketplace gives the buyer access to a given wallet. The use case for this proposal is to keep contact between an artist and a buyer of its NFTs, where the artist creates two entangled tokens A and B, keeps A, and transfers B to the buyer. By construction of entangled tokens, only one transfer is possible for them, thus the artist proves they have been the creator of the digital piece of art by sending a transaction to A that is visible from B. The proposal suggests that these applications of entangled tokens could be useful for NFT authorship/art creation and distribution of royalties by the creator.
Video
Original
Abstract
This EIP defines an interface for delegating control of a smart contract wallet to pairs of users using entangled ERC-721 non-fungible tokens.
Motivation
The motivation is to provide an easy way to share a wallet through NFTs, so that the act of buying an NFT (in a marketplace) gives the buyer the privilege to have access to a given wallet. This wallet could have budget in many tokens, or even be the owner of other NFTs.
A use case is to keep contact between an artist and an buyer of its NFTs. If an artist T has created a digital piece of art P with an NFT, then T creates 2 entangled tokens A and B so that he keeps A and transfer B to P. By construction of entangled tokens, only one transfer is possible for them, thus the artist proofs he’s been the creator of P by sending a transaction to A that is visible from B. Otherwise, the owner of P might check the authenticity of the artist by sending a transaction to B so that the artist might proof by showing the outcome out of A.
A version of this use case is when one user U mints his piece of art directly in the form of an entangled token A; then the user U sells/transfers it while keeping the entangled token B in the U's wallet. The piece of art and the artists will be entangled whoever is the A's owner.
These applications of entangled tokens are envisaged to be useful for:
- NFT authorship / art creation
- Distribution of royalties by the creator.
- Authenticity of a work of art: creation limited to the author (e.g. only 1000 copies if there are 1000 1000 entangled tokens in that NFT).
- Usowners (users that consume an NFT also become -partial- owners of the NFT)
- Reformulation of property rights: the one who owns the property receives it without having to follow in the footsteps of the owners.
- Identity: Only those credentials that have an entangled token with you are related to you.
- Vreservers (value-reservers).
Specification
An entangled token contract implements ERC-721 with the additional restriction that it only ever mints exactly two tokens at contract deployment: one with a tokenId
of 0
, the other with a tokenId
of 1
. The entangled token contract also implements a smart contract wallet that can be operated by the owners of those two tokens.
Also, a tokenTransfer
function is to be be added in order to allow the token owners to transact with the ERC-20 tokens owned by the contract/NFT itself. The function signature is as follows:
function tokenTransfer(IERC20 token, address recipient, uint256 amount) public onlyOwners;
Rationale
We decide to extend ERC-721 (ERC-1155 could be also possible) because the main purpose of this is to be compatible with current marketplaces platforms. This entangled NFTs will be listed in a marketplace, and the user who buys it will have then the possibility to transact with the wallet properties (fungible and non fungible tokens).
Backwards Compatibility
No backwards compatibility issues.
Reference Implementation
Mint two tokens, and only two, at the contract constructor, and set the minted
property to true:
bool private _minted; constructor(string memory name, string memory symbol, string memory base_uri) ERC721(name, symbol) { baseUri = base_uri; _mint(msg.sender,0); _mint(msg.sender,1); _minted = true; } function _mint(address to, uint256 tokenId) internal virtual override { require(!_minted, "ERC4950: already minted"); super._mint(to, tokenId); }
Add additional functions to allow both NFT user owners to operate with other ERC-20 tokens owned by the contract:
modifier onlyOwners() { require(balanceOf(msg.sender) > 0, "Caller does not own any of the tokens"); _; } function tokenTransfer(IERC20 token, address recipient, uint256 amount) public onlyOwners { token.transfer(recipient, amount); }
Security Considerations
There are no security considerations.
Copyright
Copyright and related rights waived via CC0.
Adopted by projects
Not miss a beat of EIPs' update?
Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.
View all