forked from DecentralizedClimateFoundation/DCIPs
72 lines
3.3 KiB
Markdown
Executable File
72 lines
3.3 KiB
Markdown
Executable File
---
|
||
eip: 5192
|
||
title: Minimal Soulbound NFTs
|
||
description: Minimal interface for soulbinding EIP-721 NFTs
|
||
author: Tim Daubenschütz (@TimDaub), Anders (@0xanders)
|
||
discussions-to: https://ethereum-magicians.org/t/eip-5192-minimal-soulbound-nfts/9814
|
||
status: Final
|
||
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-)transferability 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
|
||
|
||
A token with a `uint256 tokenId` may be bound to a receiving account with `function locked(...)` returning `true`. In this case, 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 Emitted when the locking status is changed to locked.
|
||
/// @dev If a token is minted and the status is locked, this event should be emitted.
|
||
/// @param tokenId The identifier for a token.
|
||
event Locked(uint256 tokenId);
|
||
|
||
/// @notice Emitted when the locking status is changed to unlocked.
|
||
/// @dev If a token is minted and the status is unlocked, this event should be emitted.
|
||
/// @param tokenId The identifier for a token.
|
||
event Unlocked(uint256 tokenId);
|
||
|
||
/// @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).
|