94 lines
4.5 KiB
Markdown
94 lines
4.5 KiB
Markdown
|
---
|
|||
|
|
eip: 4950
|
|||
|
|
title: Entangled Tokens
|
|||
|
|
description: ERC-721 extension with two tokens minted that are tied together
|
|||
|
|
author: Víctor Muñoz (@victormunoz), Josep Lluis de la Rosa (@peplluis7), Easy Innova (@easyinnova)
|
|||
|
|
discussions-to: https://ethereum-magicians.org/t/entangled-tokens/8702
|
|||
|
|
status: Draft
|
|||
|
|
type: Standards Track
|
|||
|
|
category: ERC
|
|||
|
|
created: 2022-03-28
|
|||
|
|
requires: 20, 721, 1155
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Abstract
|
|||
|
|
|
|||
|
|
This EIP defines an interface for delegating control of a smart contract wallet to pairs of users using entangled [ERC-721](./eip-721.md) 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:
|
|||
|
|
|
|||
|
|
1. NFT authorship / art creation
|
|||
|
|
2. Distribution of royalties by the creator.
|
|||
|
|
3. 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).
|
|||
|
|
4. Usowners (users that consume an NFT also become -partial- owners of the NFT)
|
|||
|
|
5. Reformulation of property rights: the one who owns the property receives it without having to follow in the footsteps of the owners.
|
|||
|
|
6. Identity: Only those credentials that have an entangled token with you are related to you.
|
|||
|
|
7. Vreservers (value-reservers).
|
|||
|
|
|
|||
|
|
## Specification
|
|||
|
|
|
|||
|
|
An entangled token contract implements [ERC-721](./eip-721.md) 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](./eip-20.md) tokens owned by the contract/NFT itself. The function signature is as follows:
|
|||
|
|
|
|||
|
|
```solidity
|
|||
|
|
function tokenTransfer(IERC20 token, address recipient, uint256 amount) public onlyOwners;
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## Rationale
|
|||
|
|
|
|||
|
|
We decide to extend [ERC-721](./eip-721.md) ([ERC-1155](./eip-1155.md) 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:
|
|||
|
|
|
|||
|
|
```solidity
|
|||
|
|
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:
|
|||
|
|
|
|||
|
|
```solidity
|
|||
|
|
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](../LICENSE.md).
|