From 3587cb97da02d1fd4f44ff3b68ed0f863011c30c Mon Sep 17 00:00:00 2001 From: Jan Turk Date: Tue, 7 Feb 2023 15:50:28 +0100 Subject: [PATCH 01/10] Propose Minimalistic Souldbound Extension for Non-Fungible Tokens Proposed an interface for Non-Fungible Tokens extension allowing for them to be non-transferrable. --- EIPS/eip-x.md | 87 +++++++++++++++++++ assets/eip-x/contracts/ISoulbound.sol | 13 +++ .../contracts/mocks/ERC721SoulboundMock.sol | 61 +++++++++++++ assets/eip-x/hardhat.config.ts | 17 ++++ assets/eip-x/package.json | 28 ++++++ assets/eip-x/test/soulbound.ts | 57 ++++++++++++ 6 files changed, 263 insertions(+) create mode 100644 EIPS/eip-x.md create mode 100644 assets/eip-x/contracts/ISoulbound.sol create mode 100644 assets/eip-x/contracts/mocks/ERC721SoulboundMock.sol create mode 100644 assets/eip-x/hardhat.config.ts create mode 100644 assets/eip-x/package.json create mode 100644 assets/eip-x/test/soulbound.ts diff --git a/EIPS/eip-x.md b/EIPS/eip-x.md new file mode 100644 index 0000000000000..69ecfbbed62d8 --- /dev/null +++ b/EIPS/eip-x.md @@ -0,0 +1,87 @@ +--- +eip: x +title: Minimalistic Souldbound interface for NFTs +description: An interface for Soulbound Non-Fungible Tokens extension allowing for tokens to be non-transferrable. +author: Bruno Škvorc (@Swader), Francesco Sullo(@sullof), Steven Pineda (@steven2308), Stevan Bogosavljevic (@stevyhacker), Jan Turk (@ThunderDeliverer) +discussions-to: x +status: Draft +type: Standards Track +category: ERC +created: 2023-01-31 +requires: 165, 721 +--- + +## Abstract + +The Minimalistic Souldbound interface for Non-Fungible Tokens standard extends [EIP-721](./eip-721.md) by preventing NFTs to be transferred. + +This proposal introduces the ability to prevent a token to be transferred from their owner, making them bound to the externally owned account, smart contract or token that owns it. + +## Motivation + +With NFTs being a widespread form of tokens in the Ethereum ecosystem and being used for a variety of use cases, it is time to standardize additional utility for them. Having the ability to prevent the tokens to be transferred introduces new possibilities of NFT utility and evolution. + +This proposal is designed in a way to be as minimal as possible in order to be compatible with any usecases that wish to utilize this proposal. + +This EIP introduces new utilities for [EIP-721](./eip-721.md) based tokens in the following areas: + +- [Foo](#foo) + +### Foo + +The ability to prevent the tokens to be transferred + +## Specification + +The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. + +```solidity +/// @title EIP-x Minimalistic Souldbound interface for NFTs +/// @dev See https://eips.ethereum.org/EIPS/eip-x +/// @dev Note: the ERC-165 identifier for this interface is 0x0. + +pragma solidity ^0.8.16; + +interface IERCx is IERC165 { + /** + * @notice Used to check whether the given token is soulbound or not. + * @param tokenId ID of the token being checked + * @return Boolean value indicating whether the given token is soulbound + */ + function isSoulbound(uint256 tokenId) external view returns (bool); +} +``` + +## Rationale + +Designing the proposal, we considered the following questions: + +## Backwards Compatibility + +The Emotable token standard is fully compatible with [EIP-721](./epi-721.md) and with the robust tooling available for implementations of EIP-721 as well as with the existing EIP-721 infrastructure. + +## Test Cases + +Tests are included in [`soulbound.ts`](../assets/eip-x/test/soulbound.ts). + +To run them in terminal, you can use the following commands: + +``` +cd ../assets/eip-x +npm install +npx hardhat test +``` + +## Reference Implementation + +See [`Soulbound.sol`](../assets/eip-x/contracts/Soulbound.sol). + +## Security Considerations + +The same security considerations as with [EIP-721](./eip-721.md) apply: hidden logic may be present in any of the functions, including burn, add asset, accept asset, and more. + +Caution is advised when dealing with non-audited contracts. + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md). diff --git a/assets/eip-x/contracts/ISoulbound.sol b/assets/eip-x/contracts/ISoulbound.sol new file mode 100644 index 0000000000000..66dafa782980f --- /dev/null +++ b/assets/eip-x/contracts/ISoulbound.sol @@ -0,0 +1,13 @@ +// SPDX-License-Identifier: CC0-1.0 + +pragma solidity ^0.8.16; + +interface ISoulbound { + + /** + * @notice Used to check whether the given token is soulbound or not. + * @param tokenId ID of the token being checked + * @return Boolean value indicating whether the given token is soulbound + */ + function isSoulbound(uint256 tokenId) external view returns (bool); +} \ No newline at end of file diff --git a/assets/eip-x/contracts/mocks/ERC721SoulboundMock.sol b/assets/eip-x/contracts/mocks/ERC721SoulboundMock.sol new file mode 100644 index 0000000000000..843735ca74b01 --- /dev/null +++ b/assets/eip-x/contracts/mocks/ERC721SoulboundMock.sol @@ -0,0 +1,61 @@ +// SPDX-License-Identifier: CC0-1.0 + +pragma solidity ^0.8.16; + +import "@openzeppelin/contracts/token/ERC721/ERC721.sol"; +import "../ISoulbound.sol"; + +error CannotTransferSoulbound(); + +/** + * @title ERC721SoulboundMock + * Used for tests + */ +contract ERC721SoulboundMock is ISoulbound, ERC721 { + constructor( + string memory name, + string memory symbol + ) ERC721(name, symbol) {} + + function mint(address to, uint256 amount) public { + _mint(to, amount); + } + + function burn(uint256 tokenId) public { + _burn(tokenId); + } + + function isSoulbound(uint256 tokenId) public view returns (bool) { + return true; + } + + function _beforeTokenTransfer( + address from, + address to, + uint256 firstTokenId, + uint256 batchSize + ) internal virtual override { + super._beforeTokenTransfer(from, to, firstTokenId, batchSize); + + // exclude minting and burning + if ( from != address(0) && to != address(0)) { + uint256 lastTokenId = firstTokenId + batchSize; + for (uint256 i = firstTokenId; i < lastTokenId; i++) { + uint256 tokenId = firstTokenId + i; + if (isSoulbound(tokenId)) { + revert CannotTransferSoulbound(); + } + unchecked { + i++; + } + } + } + } + + function supportsInterface( + bytes4 interfaceId + ) public view virtual override(ERC721) returns (bool) { + return interfaceId == type(ISoulbound).interfaceId + || super.supportsInterface(interfaceId); + } +} diff --git a/assets/eip-x/hardhat.config.ts b/assets/eip-x/hardhat.config.ts new file mode 100644 index 0000000000000..f1b6fdec4582d --- /dev/null +++ b/assets/eip-x/hardhat.config.ts @@ -0,0 +1,17 @@ +import { HardhatUserConfig } from "hardhat/config"; +import "@nomicfoundation/hardhat-chai-matchers"; +import "@typechain/hardhat"; + +const config: HardhatUserConfig = { + solidity: { + version: "0.8.16", + settings: { + optimizer: { + enabled: true, + runs: 200, + }, + }, + }, +}; + +export default config; diff --git a/assets/eip-x/package.json b/assets/eip-x/package.json new file mode 100644 index 0000000000000..b9dffe2c49a63 --- /dev/null +++ b/assets/eip-x/package.json @@ -0,0 +1,28 @@ +{ + "name": "soulbound-tokens", + "scripts": { + "test": "yarn typechain && hardhat test", + "typechain": "hardhat typechain", + "prettier": "prettier --write ." + }, + "engines": { + "node": ">=16.0.0" + }, + "dependencies": { + "@openzeppelin/contracts": "^4.6.0" + }, + "devDependencies": { + "@nomicfoundation/hardhat-chai-matchers": "^1.0.1", + "@nomicfoundation/hardhat-network-helpers": "^1.0.3", + "@nomiclabs/hardhat-ethers": "^2.2.1", + "@typechain/ethers-v5": "^10.1.0", + "@typechain/hardhat": "^6.1.2", + "@types/chai": "^4.3.1", + "chai": "^4.3.6", + "ethers": "^5.6.9", + "hardhat": "^2.12.2", + "ts-node": "^10.8.2", + "typechain": "^8.1.0", + "typescript": "^4.7.4" + } +} diff --git a/assets/eip-x/test/soulbound.ts b/assets/eip-x/test/soulbound.ts new file mode 100644 index 0000000000000..cbc2a72422e51 --- /dev/null +++ b/assets/eip-x/test/soulbound.ts @@ -0,0 +1,57 @@ +import { ethers } from "hardhat"; +import { expect } from "chai"; +import { BigNumber } from "ethers"; +import { loadFixture } from "@nomicfoundation/hardhat-network-helpers"; +import { SignerWithAddress } from "@nomiclabs/hardhat-ethers/signers"; +import { ERC721SoulboundMock } from "../typechain-types"; + +async function soulboundTokenFixture(): Promise { + const factory = await ethers.getContractFactory("ERC721SoulboundMock"); + const token = await factory.deploy("Chunky", "CHNK"); + await token.deployed(); + + return token; +} + +describe("Soulbound", async function () { + let soulbound: ERC721SoulboundMock; + let owner: SignerWithAddress; + let otherOwner: SignerWithAddress; + const tokenId = 1; + + beforeEach(async function () { + const signers = await ethers.getSigners(); + owner = signers[0]; + otherOwner = signers[1]; + soulbound = await loadFixture(soulboundTokenFixture); + + await soulbound.mint(owner.address, 1); + }); + + it("can support IRMRKSoulbound", async function () { + expect(await soulbound.supportsInterface("0x911ec470")).to.equal(true); + }); + + it("does not support other interfaces", async function () { + expect(await soulbound.supportsInterface("0xffffffff")).to.equal(false); + }); + + it("cannot transfer", async function () { + expect( + soulbound + .connect(owner) + ["safeTransferFrom(address,address,uint256)"]( + owner.address, + otherOwner.address, + tokenId + ) + ).to.be.revertedWithCustomError(soulbound, "CannotTransferSoulbound"); + }); + + it("can burn", async function () { + await soulbound.connect(owner).burn(tokenId); + await expect(soulbound.ownerOf(tokenId)).to.be.revertedWith( + "ERC721: invalid token ID" + ); + }); +}); From a6c701de271a4c3aae2fb47726312b463795a573 Mon Sep 17 00:00:00 2001 From: Jan Turk Date: Tue, 7 Feb 2023 15:57:45 +0100 Subject: [PATCH 02/10] Assigned EIP number Assigned the EIP number based on the PR number. --- EIPS/eip-6454.md | 104 ++++++++++++++++++ EIPS/eip-x.md | 87 --------------- .../contracts/ISoulbound.sol | 0 .../contracts/mocks/ERC721SoulboundMock.sol | 0 assets/{eip-x => eip-6454}/hardhat.config.ts | 0 assets/{eip-x => eip-6454}/package.json | 0 assets/{eip-x => eip-6454}/test/soulbound.ts | 0 7 files changed, 104 insertions(+), 87 deletions(-) create mode 100644 EIPS/eip-6454.md delete mode 100644 EIPS/eip-x.md rename assets/{eip-x => eip-6454}/contracts/ISoulbound.sol (100%) rename assets/{eip-x => eip-6454}/contracts/mocks/ERC721SoulboundMock.sol (100%) rename assets/{eip-x => eip-6454}/hardhat.config.ts (100%) rename assets/{eip-x => eip-6454}/package.json (100%) rename assets/{eip-x => eip-6454}/test/soulbound.ts (100%) diff --git a/EIPS/eip-6454.md b/EIPS/eip-6454.md new file mode 100644 index 0000000000000..043c1a4350c71 --- /dev/null +++ b/EIPS/eip-6454.md @@ -0,0 +1,104 @@ +--- +eip: 6454 +title: Minimalistic Souldbound interface for NFTs +description: An interface for Soulbound Non-Fungible Tokens extension allowing for tokens to be non-transferrable. +author: Bruno Škvorc (@Swader), Francesco Sullo(@sullof), Steven Pineda (@steven2308), Stevan Bogosavljevic (@stevyhacker), Jan Turk (@ThunderDeliverer) +discussions-to: https://ethereum-magicians.org/t/minimalistic-transferable-interface/12517 +status: Draft +type: Standards Track +category: ERC +created: 2023-01-31 +requires: 165, 721 +--- + +## Abstract + +The Minimalistic Souldbound interface for Non-Fungible Tokens standard extends [EIP-721](./eip-721.md) by preventing NFTs to be transferred. + +This proposal introduces the ability to prevent a token to be transferred from their owner, making them bound to the externally owned account, smart contract or token that owns it. + +## Motivation + +With NFTs being a widespread form of tokens in the Ethereum ecosystem and being used for a variety of use cases, it is time to standardize additional utility for them. Having the ability to prevent the tokens to be transferred introduces new possibilities of NFT utility and evolution. + +This proposal is designed in a way to be as minimal as possible in order to be compatible with any usecases that wish to utilize this proposal. + +This EIP introduces new utilities for [EIP-721](./eip-721.md) based tokens in the following areas: + +- [Verifiable attribution](#verifiable-attribution) +- [Immutable properties](#immutable-properties) + +### Verifiable attribution + +Personal achievements can be represented by non-fungible tokens. These tokens can be used to represent a wide range of accomplishments, including scientific advancements, philanthropic endeavors, athletic achievements, and more. However, if these achievement-indicating NFTs can be easily transferred, their authenticity and trustworthiness can be called into question. By binding the NFT to a specific account, it can be ensured that the account owning the NFT is the one that actually achieved the corresponding accomplishment. This creates a secure and verifiable record of personal achievements that can be easily accessed and recognized by others in the network. The ability to verify attribution helps to establish the credibility and value of the achievement-indicating NFT, making it a valuable asset that can be used as a recognition of the holder's accomplishments. + +### Immutable properties + +NFT properties are a critical aspect of non-fungible tokens, serving to differentiate them from one another and establish their scarcity. Centralized control of NFT properties by the issuer, however, can undermine the uniqueness of these properties. + +By tying NFTs to specific properties, the original owner is ensured that the NFT will always retain these properties and its uniqueness. + +In a blockchain game that employs soulbound NFTs to represent skills or abilities, each skill would be a unique and permanent asset tied to a specific player or token. This would ensure that players retain ownership of the skills they have earned and prevent them from being traded or sold to other players. This can increase the perceived value of these skills, enhancing the player experience by allowing for greater customization and personalization of characters. + +## Specification + +The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. + +```solidity +/// @title EIP-6454 Minimalistic Souldbound interface for NFTs +/// @dev See https://eips.ethereum.org/EIPS/eip-6454 +/// @dev Note: the ERC-165 identifier for this interface is 0x911ec470. + +pragma solidity ^0.8.16; + +interface IERCx is IERC165 { + /** + * @notice Used to check whether the given token is soulbound or not. + * @dev If this function returns `true`, the transfer of the token MUST revert execution + * @param tokenId ID of the token being checked + * @return Boolean value indicating whether the given token is soulbound + */ + function isSoulbound(uint256 tokenId) external view returns (bool); +} +``` + +## Rationale + +Designing the proposal, we considered the following questions: + +1. **Should we propose another Soulbound NFT proposal given the existence of existing ones, some even final, and how does this proposal compare to them?**\ + This proposal aims to provide the minimum necessary specification for the implementation of soulbound NFTs, we feel none of the existing proposals have presented the minimal required interface. Unlike other proposals that address the same issue, this proposal requires fewer methods in its specification, providing a more streamlined solution. +2. **Why is there no event marking the token as Soulbound in this interface?**\ + The token can become soulbound either at its creation, after being marked as soulbound, or after a certain condition is met. This means that some cases of tokens becoming soulbound cannot emit an event, such as if the token becoming soulbound is determined by a block number. Requiring an event to be emitted upon the token becoming soulbound is not feasible in such cases. +3. **Should the soulbound state management function be included in this proposal?**\ + A function that marks a token as soulbound or releases the binding is referred to as the soulbound management function. To maintain the objective of designing an agnostic soulbound proposal, we have decided not to specify the soulbound management function. This allows for a variety of custom implementations that require the tokens to be non-transferable. + +## Backwards Compatibility + +The Emotable token standard is fully compatible with [EIP-721](./epi-721.md) and with the robust tooling available for implementations of EIP-721 as well as with the existing EIP-721 infrastructure. + +## Test Cases + +Tests are included in [`soulbound.ts`](../assets/eip-6454/test/soulbound.ts). + +To run them in terminal, you can use the following commands: + +``` +cd ../assets/eip-6454 +npm install +npx hardhat test +``` + +## Reference Implementation + +See [`Soulbound.sol`](../assets/eip-6454/contracts/Soulbound.sol). + +## Security Considerations + +The same security considerations as with [EIP-721](./eip-721.md) apply: hidden logic may be present in any of the functions, including burn, add asset, accept asset, and more. + +Caution is advised when dealing with non-audited contracts. + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md). diff --git a/EIPS/eip-x.md b/EIPS/eip-x.md deleted file mode 100644 index 69ecfbbed62d8..0000000000000 --- a/EIPS/eip-x.md +++ /dev/null @@ -1,87 +0,0 @@ ---- -eip: x -title: Minimalistic Souldbound interface for NFTs -description: An interface for Soulbound Non-Fungible Tokens extension allowing for tokens to be non-transferrable. -author: Bruno Škvorc (@Swader), Francesco Sullo(@sullof), Steven Pineda (@steven2308), Stevan Bogosavljevic (@stevyhacker), Jan Turk (@ThunderDeliverer) -discussions-to: x -status: Draft -type: Standards Track -category: ERC -created: 2023-01-31 -requires: 165, 721 ---- - -## Abstract - -The Minimalistic Souldbound interface for Non-Fungible Tokens standard extends [EIP-721](./eip-721.md) by preventing NFTs to be transferred. - -This proposal introduces the ability to prevent a token to be transferred from their owner, making them bound to the externally owned account, smart contract or token that owns it. - -## Motivation - -With NFTs being a widespread form of tokens in the Ethereum ecosystem and being used for a variety of use cases, it is time to standardize additional utility for them. Having the ability to prevent the tokens to be transferred introduces new possibilities of NFT utility and evolution. - -This proposal is designed in a way to be as minimal as possible in order to be compatible with any usecases that wish to utilize this proposal. - -This EIP introduces new utilities for [EIP-721](./eip-721.md) based tokens in the following areas: - -- [Foo](#foo) - -### Foo - -The ability to prevent the tokens to be transferred - -## Specification - -The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. - -```solidity -/// @title EIP-x Minimalistic Souldbound interface for NFTs -/// @dev See https://eips.ethereum.org/EIPS/eip-x -/// @dev Note: the ERC-165 identifier for this interface is 0x0. - -pragma solidity ^0.8.16; - -interface IERCx is IERC165 { - /** - * @notice Used to check whether the given token is soulbound or not. - * @param tokenId ID of the token being checked - * @return Boolean value indicating whether the given token is soulbound - */ - function isSoulbound(uint256 tokenId) external view returns (bool); -} -``` - -## Rationale - -Designing the proposal, we considered the following questions: - -## Backwards Compatibility - -The Emotable token standard is fully compatible with [EIP-721](./epi-721.md) and with the robust tooling available for implementations of EIP-721 as well as with the existing EIP-721 infrastructure. - -## Test Cases - -Tests are included in [`soulbound.ts`](../assets/eip-x/test/soulbound.ts). - -To run them in terminal, you can use the following commands: - -``` -cd ../assets/eip-x -npm install -npx hardhat test -``` - -## Reference Implementation - -See [`Soulbound.sol`](../assets/eip-x/contracts/Soulbound.sol). - -## Security Considerations - -The same security considerations as with [EIP-721](./eip-721.md) apply: hidden logic may be present in any of the functions, including burn, add asset, accept asset, and more. - -Caution is advised when dealing with non-audited contracts. - -## Copyright - -Copyright and related rights waived via [CC0](../LICENSE.md). diff --git a/assets/eip-x/contracts/ISoulbound.sol b/assets/eip-6454/contracts/ISoulbound.sol similarity index 100% rename from assets/eip-x/contracts/ISoulbound.sol rename to assets/eip-6454/contracts/ISoulbound.sol diff --git a/assets/eip-x/contracts/mocks/ERC721SoulboundMock.sol b/assets/eip-6454/contracts/mocks/ERC721SoulboundMock.sol similarity index 100% rename from assets/eip-x/contracts/mocks/ERC721SoulboundMock.sol rename to assets/eip-6454/contracts/mocks/ERC721SoulboundMock.sol diff --git a/assets/eip-x/hardhat.config.ts b/assets/eip-6454/hardhat.config.ts similarity index 100% rename from assets/eip-x/hardhat.config.ts rename to assets/eip-6454/hardhat.config.ts diff --git a/assets/eip-x/package.json b/assets/eip-6454/package.json similarity index 100% rename from assets/eip-x/package.json rename to assets/eip-6454/package.json diff --git a/assets/eip-x/test/soulbound.ts b/assets/eip-6454/test/soulbound.ts similarity index 100% rename from assets/eip-x/test/soulbound.ts rename to assets/eip-6454/test/soulbound.ts From dd26e7bb63c6e952928a59598f70ff4674717479 Mon Sep 17 00:00:00 2001 From: Jan Turk Date: Tue, 7 Feb 2023 16:03:39 +0100 Subject: [PATCH 03/10] Fix author formatting --- EIPS/eip-6454.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-6454.md b/EIPS/eip-6454.md index 043c1a4350c71..e426711fd5f72 100644 --- a/EIPS/eip-6454.md +++ b/EIPS/eip-6454.md @@ -2,7 +2,7 @@ eip: 6454 title: Minimalistic Souldbound interface for NFTs description: An interface for Soulbound Non-Fungible Tokens extension allowing for tokens to be non-transferrable. -author: Bruno Škvorc (@Swader), Francesco Sullo(@sullof), Steven Pineda (@steven2308), Stevan Bogosavljevic (@stevyhacker), Jan Turk (@ThunderDeliverer) +author: Bruno Škvorc (@Swader), Francesco Sullo (@sullof), Steven Pineda (@steven2308), Stevan Bogosavljevic (@stevyhacker), Jan Turk (@ThunderDeliverer) discussions-to: https://ethereum-magicians.org/t/minimalistic-transferable-interface/12517 status: Draft type: Standards Track From ceb9da2917947969cc05e6bcf4a4785b7b0db7de Mon Sep 17 00:00:00 2001 From: Jan Turk Date: Tue, 7 Feb 2023 16:06:54 +0100 Subject: [PATCH 04/10] Fix links --- EIPS/eip-6454.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-6454.md b/EIPS/eip-6454.md index e426711fd5f72..b527dd93e6737 100644 --- a/EIPS/eip-6454.md +++ b/EIPS/eip-6454.md @@ -75,7 +75,7 @@ Designing the proposal, we considered the following questions: ## Backwards Compatibility -The Emotable token standard is fully compatible with [EIP-721](./epi-721.md) and with the robust tooling available for implementations of EIP-721 as well as with the existing EIP-721 infrastructure. +The Emotable token standard is fully compatible with [EIP-721](./eip-721.md) and with the robust tooling available for implementations of EIP-721 as well as with the existing EIP-721 infrastructure. ## Test Cases @@ -91,7 +91,7 @@ npx hardhat test ## Reference Implementation -See [`Soulbound.sol`](../assets/eip-6454/contracts/Soulbound.sol). +See [`ERC721SoulboundMock.sol`](../assets/eip-6454/contracts/ERC721SoulboundMock.sol). ## Security Considerations From 71d72060b703b7626b8f1c25805f7b0211b88356 Mon Sep 17 00:00:00 2001 From: Jan Turk Date: Tue, 7 Feb 2023 16:07:45 +0100 Subject: [PATCH 05/10] Fix typo in the title --- EIPS/eip-6454.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-6454.md b/EIPS/eip-6454.md index b527dd93e6737..991ea46e7a38d 100644 --- a/EIPS/eip-6454.md +++ b/EIPS/eip-6454.md @@ -1,6 +1,6 @@ --- eip: 6454 -title: Minimalistic Souldbound interface for NFTs +title: Minimalistic Soulbound interface for NFTs description: An interface for Soulbound Non-Fungible Tokens extension allowing for tokens to be non-transferrable. author: Bruno Škvorc (@Swader), Francesco Sullo (@sullof), Steven Pineda (@steven2308), Stevan Bogosavljevic (@stevyhacker), Jan Turk (@ThunderDeliverer) discussions-to: https://ethereum-magicians.org/t/minimalistic-transferable-interface/12517 From a3f26d29a8dfb75023a637676ff9a156159847ca Mon Sep 17 00:00:00 2001 From: Jan Turk Date: Tue, 7 Feb 2023 16:08:08 +0100 Subject: [PATCH 06/10] Fix typos --- EIPS/eip-6454.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-6454.md b/EIPS/eip-6454.md index 991ea46e7a38d..7f6a605c4a397 100644 --- a/EIPS/eip-6454.md +++ b/EIPS/eip-6454.md @@ -13,7 +13,7 @@ requires: 165, 721 ## Abstract -The Minimalistic Souldbound interface for Non-Fungible Tokens standard extends [EIP-721](./eip-721.md) by preventing NFTs to be transferred. +The Minimalistic Soulbound interface for Non-Fungible Tokens standard extends [EIP-721](./eip-721.md) by preventing NFTs to be transferred. This proposal introduces the ability to prevent a token to be transferred from their owner, making them bound to the externally owned account, smart contract or token that owns it. @@ -45,7 +45,7 @@ In a blockchain game that employs soulbound NFTs to represent skills or abilitie The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. ```solidity -/// @title EIP-6454 Minimalistic Souldbound interface for NFTs +/// @title EIP-6454 Minimalistic Soulbound interface for NFTs /// @dev See https://eips.ethereum.org/EIPS/eip-6454 /// @dev Note: the ERC-165 identifier for this interface is 0x911ec470. From 72d6bfce9a0369994a2955ba43739daafed503c5 Mon Sep 17 00:00:00 2001 From: Jan Turk Date: Tue, 7 Feb 2023 16:11:51 +0100 Subject: [PATCH 07/10] Fixed the backwards compatimility typo --- EIPS/eip-6454.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-6454.md b/EIPS/eip-6454.md index 7f6a605c4a397..6c3e0f9a7e109 100644 --- a/EIPS/eip-6454.md +++ b/EIPS/eip-6454.md @@ -51,7 +51,7 @@ The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL pragma solidity ^0.8.16; -interface IERCx is IERC165 { +interface IERC6454 is IERC165 { /** * @notice Used to check whether the given token is soulbound or not. * @dev If this function returns `true`, the transfer of the token MUST revert execution @@ -75,7 +75,7 @@ Designing the proposal, we considered the following questions: ## Backwards Compatibility -The Emotable token standard is fully compatible with [EIP-721](./eip-721.md) and with the robust tooling available for implementations of EIP-721 as well as with the existing EIP-721 infrastructure. +The Minimalistinc Soulbound token standard is fully compatible with [EIP-721](./eip-721.md) and with the robust tooling available for implementations of EIP-721 as well as with the existing EIP-721 infrastructure. ## Test Cases From 7f6488be38e7924045dabf508693da381e425437 Mon Sep 17 00:00:00 2001 From: Jan Turk Date: Tue, 7 Feb 2023 16:13:12 +0100 Subject: [PATCH 08/10] Fixed reference link --- EIPS/eip-6454.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-6454.md b/EIPS/eip-6454.md index 6c3e0f9a7e109..64889d4ebc4cd 100644 --- a/EIPS/eip-6454.md +++ b/EIPS/eip-6454.md @@ -91,7 +91,7 @@ npx hardhat test ## Reference Implementation -See [`ERC721SoulboundMock.sol`](../assets/eip-6454/contracts/ERC721SoulboundMock.sol). +See [`ERC721SoulboundMock.sol`](../assets/eip-6454/contracts/mocks/ERC721SoulboundMock.sol). ## Security Considerations From 7670b1cca4de21538f493610668bf14b1ec4e16d Mon Sep 17 00:00:00 2001 From: Jan Turk Date: Tue, 7 Feb 2023 16:20:44 +0100 Subject: [PATCH 09/10] Added explanation why we feel that this should be an EIP --- EIPS/eip-6454.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/EIPS/eip-6454.md b/EIPS/eip-6454.md index 64889d4ebc4cd..880586728b790 100644 --- a/EIPS/eip-6454.md +++ b/EIPS/eip-6454.md @@ -72,6 +72,9 @@ Designing the proposal, we considered the following questions: The token can become soulbound either at its creation, after being marked as soulbound, or after a certain condition is met. This means that some cases of tokens becoming soulbound cannot emit an event, such as if the token becoming soulbound is determined by a block number. Requiring an event to be emitted upon the token becoming soulbound is not feasible in such cases. 3. **Should the soulbound state management function be included in this proposal?**\ A function that marks a token as soulbound or releases the binding is referred to as the soulbound management function. To maintain the objective of designing an agnostic soulbound proposal, we have decided not to specify the soulbound management function. This allows for a variety of custom implementations that require the tokens to be non-transferable. +4. **Why should this be an EIP if it only contains one method?**\ + One could argue that since the core of this proposal is to only prevent EIP-721 tokens to be transferred, this could be done by overriding the transfer function. While this is true, the only way to assure that the token is soulbound before the smart contract execution, is for it to have the soulbound interface.\ + This also allows for smart contract to validate that the token is soulbound and not attempt transferring it as this would result in failed transactions and wasted gas. ## Backwards Compatibility From 8fc0016007b82afa63882667fb5792913186fd1e Mon Sep 17 00:00:00 2001 From: Jan Turk Date: Tue, 7 Feb 2023 16:24:54 +0100 Subject: [PATCH 10/10] Fix a typo in backwards compatibility --- EIPS/eip-6454.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-6454.md b/EIPS/eip-6454.md index 880586728b790..ca7ad541d3059 100644 --- a/EIPS/eip-6454.md +++ b/EIPS/eip-6454.md @@ -78,7 +78,7 @@ Designing the proposal, we considered the following questions: ## Backwards Compatibility -The Minimalistinc Soulbound token standard is fully compatible with [EIP-721](./eip-721.md) and with the robust tooling available for implementations of EIP-721 as well as with the existing EIP-721 infrastructure. +The Minimalistic Soulbound token standard is fully compatible with [EIP-721](./eip-721.md) and with the robust tooling available for implementations of EIP-721 as well as with the existing EIP-721 infrastructure. ## Test Cases