Add EIP-5192 - Minimal Soulbound NFTs (#5192)

* Add EIP-5555 * 5555->5192 * Add discussions link * Fix line break * Update EIPS/eip-5192.md Co-authored-by: Pandapip1 <[email protected]> * Update EIPS/eip-5192.md Co-authored-by: Pandapip1 <[email protected]> * Update EIPS/eip-5192.md Co-authored-by: Sam Wilson <[email protected]> * Update EIPS/eip-5192.md Co-authored-by: Sam Wilson <[email protected]> * Add function locked(...) * Attempt to fix tests * Update EIPS/eip-5192.md Co-authored-by: aram.eth <[email protected]> Co-authored-by: Pandapip1 <[email protected]> Co-authored-by: Sam Wilson <[email protected]> Co-authored-by: aram.eth <[email protected]>
ethereum · Aug 1, 2022 · 40617ab · 40617ab
1 parent d099627
commit 40617ab
Showing 1 changed file with 61 additions and 0 deletions.
diff --git a/EIPS/eip-5192.md b/EIPS/eip-5192.md
@@ -0,0 +1,61 @@
+---
+eip: 5192
+title: Minimal Soulbound NFTs
+description: Minimal interface for soulbinding EIP-721 NFTs
+author: Tim Daubenschütz (@TimDaub)
+discussions-to: https://ethereum-magicians.org/t/eip-5192-minimal-soulbound-nfts/9814
+status: Review
+type: Standards Track
+category: ERC
+created: 2022-07-01
+requires: 165, 721
+---
+
+## Abstract
+
+This standard is an extension of [EIP-721](./eip-721.md). It proposes a minimal interface to make tokens soulbound using the feature detection functionality of [EIP-165](./eip-165.md). A soulbound token is a non-fungible token bound to a single account.
+
+## Motivation
+
+The Ethereum community has expressed a need for non-transferrable, non-fungible, and socially-priced tokens similar to World of Warcraft’s soulbound items. But the lack of a token standard leads many developers to simply throw errors upon a user's invocation of transfer functionalities. Over the long term, this will lead to fragmentation and less composability.
+
+In this document, we outline a minimal addition to [EIP-721](./eip-721.md) that allows wallet implementers to check for a token contract's permanent (non-)transferrability using [EIP-165](./eip-165.md).
+
+## Specification
+
+The keywords "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.
+
+### Contract Interface
+
+Upon minting a token implementing this EIP, it must be permanently inseparable from the receiving account. All [EIP-721](./eip-721.md) functions of the contract that transfer the token from one account to another must throw.
+
+```solidity
+// SPDX-License-Identifier: CC0-1.0
+pragma solidity ^0.8.0;
+
+interface IERC5192 {
+  /// @notice Returns the locking status of an Soulbound Token
+  /// @dev SBTs assigned to zero address are considered invalid, and queries
+  /// about them do throw.
+  /// @param tokenId The identifier for an SBT.
+  function locked(uint256 tokenId) external view returns (bool);
+}
+```
+
+To aid recognition that an [EIP-721](./eip-721.md) token implements soulbinding via this EIP upon calling [EIP-721](./eip-721.md)'s `function supportsInterface(bytes4 interfaceID) external view returns (bool)` with `interfaceID=0xb45a3c0e`, a contract implementing this EIP must return `true`.
+
+## Rationale
+
+The above model is the simplest possible path towards a canonical interface for Soulbound tokens. It reflects upon the numerous Soulbound token implementations that simply revert upon transfers.
+
+## Backwards Compatibility
+
+This proposal is fully backward compatible with [EIP-721](./eip-721.md).
+
+## Security Considerations
+
+There are no security considerations related directly to the implementation of this standard.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).