forked from DecentralizedClimateFoundation/DCIPs
83 lines
3.2 KiB
Markdown
83 lines
3.2 KiB
Markdown
|
---
|
||
|
|
eip: 4944
|
||
|
|
title: Contract with Exactly One Non-fungible Token
|
||
|
|
description: An ERC-721 compatible single-token NFT
|
||
|
|
author: Víctor Muñoz (@victormunoz), Josep Lluis de la Rosa (@peplluis7), Andres El-Fakdi (@Bluezfish)
|
||
|
|
discussions-to: https://ethereum-magicians.org/t/erc721-minting-only-one-token/8602/2
|
||
|
|
status: Draft
|
||
|
|
type: Standards Track
|
||
|
|
category: ERC
|
||
|
|
created: 2022-03-25
|
||
|
|
requires: 721
|
||
|
|
---
|
||
|
|
|
||
|
|
## Abstract
|
||
|
|
|
||
|
|
The following describes standard functions for an [ERC-721](./eip-721.md) compatible contract with a total supply of one.
|
||
|
|
This allows an NFT to be associated uniquely with a single contract address.
|
||
|
|
|
||
|
|
## Motivation
|
||
|
|
|
||
|
|
If the ERC-721 was modified to mint only 1 token (per contract), then the contract address could be identified uniquely with that minted token (instead of the tuple contract address + token id, as ERC-721 requires).
|
||
|
|
This change would enable automatically all the capabilities of composable tokens [ERC-998](./eip-998.md) (own other ERC-721 or [ERC-20](./eip-20.md)) natively without adding any extra code, just forbidding to mint more than one token per deployed contract.
|
||
|
|
Then the NFT minted with this contract could operate with his "budget" (the ERC-20 he owned) and also trade with the other NFTs he could own. Just like an autonomous agent, that could decide what to do with his properties (sell his NFTs, buy other NFTs, etc).
|
||
|
|
|
||
|
|
The first use case that is devised is for value preservation. Digital assets, as NFTs, have value that has to be preserved in order to not be lost. If the asset has its own budget (in other ERC-20 coins), could use it to autopreserve itself.
|
||
|
|
|
||
|
|
## Specification
|
||
|
|
|
||
|
|
The constructor should mint the unique token of the contract, and then the mint function should add a restriction to avoid further minting.
|
||
|
|
|
||
|
|
Also, a `tokenTransfer` function should be added in order to allow the contract owner to transact with the ERC-20 tokens owned by the contract/NFT itself. So that if the contract receives a transfer of ERC-20 tokens, the owner of the NFT could spend it from the contract wallet.
|
||
|
|
|
||
|
|
## Rationale
|
||
|
|
|
||
|
|
The main motivation is to keep the contract compatible with current ERC-721 platforms.
|
||
|
|
|
||
|
|
## Backwards Compatibility
|
||
|
|
|
||
|
|
There are no backwards compatibility issues.
|
||
|
|
|
||
|
|
## Reference Implementation
|
||
|
|
|
||
|
|
Add the variable `_minted` in the contract:
|
||
|
|
|
||
|
|
``` solidity
|
||
|
|
bool private _minted;
|
||
|
|
```
|
||
|
|
|
||
|
|
In the constructor, automint the first token and set the variable to true:
|
||
|
|
|
||
|
|
``` solidity
|
||
|
|
constructor(string memory name, string memory symbol, string memory base_uri) ERC721(name, symbol) {
|
||
|
|
baseUri = base_uri;
|
||
|
|
mint(msg.sender,0);
|
||
|
|
_minted = true;
|
||
|
|
}
|
||
|
|
```
|
||
|
|
|
||
|
|
Add additional functions to interact with the NFT properties (for instance, ERC-20):
|
||
|
|
|
||
|
|
``` solidity
|
||
|
|
modifier onlyOwner() {
|
||
|
|
require(balanceOf(msg.sender) > 0, "Caller is not the owner of the NFT");
|
||
|
|
_;
|
||
|
|
}
|
||
|
|
|
||
|
|
function transferTokens(IERC20 token, address recipient, uint256 amount) public virtual onlyOwner {
|
||
|
|
token.transfer(recipient, amount);
|
||
|
|
}
|
||
|
|
|
||
|
|
function balanceTokens(IERC20 token) public view virtual returns (uint256) {
|
||
|
|
return token.balanceOf(address(this));
|
||
|
|
}
|
||
|
|
```
|
||
|
|
|
||
|
|
## Security Considerations
|
||
|
|
|
||
|
|
No security issues found.
|
||
|
|
|
||
|
|
## Copyright
|
||
|
|
|
||
|
|
Copyright and related rights waived via [CC0](../LICENSE.md).
|