yuki-js
December 17, 2022, 6:08am
#1
I submitted an EIP, that is inspired by EIP-5172 and have a similar simple interface.
---
eip: 6268
title: Untransferability Indicator for EIP-1155
description: An extension of EIP-1155 for indicating the transferability of the token.
author: Yuki Aoki (@yuki-js)
discussions-to: https://ethereum-magicians.org/t/sbt-implemented-in-erc1155/12182
status: Draft
type: Standards Track
category: ERC
created: 2022-01-06
requires: 1155
---
## Abstract
The following standard is an extension of [EIP-1155](./eip-1155.md). It introduces the interface for indicating whether the token is transferable or not, without regard to non-fungibility, using the feature detection functionality of [EIP-165](./eip-165.md).
## Motivation
We propose the introduction of the UNTransferability Indicator, a universal indicator that demonstrates untransferability without regard to non-fungibility. This will enable the use of Soulbound Tokens (SBT), which are untransferable and fungible/non-fungible entities, to associate items with an account, user-related information, memories, and event attendance records, in a universal manner. The [EIP-5192](./eip-5192.md) specification was invented for this purpose, but SBT in [EIP-5192](./eip-5192.md) is non-fungible and has a tokenId, allowing them to be distinguished from each other using the tokenId. However, for example, in the case of event attendance records, it is not necessary to distinguish between those who attended the same event using the tokenId, and all participants should have the same indistinguishable entity. Rather, the existence of the tokenId creates discriminability.
show original
2 Likes
Make sure to use the latest eip-template!
yuki-js
January 6, 2023, 12:56pm
#4
Thank you for pointing out. I’ve corrected the problem. If the problem is still there, please let me know.
tinom9
January 8, 2023, 1:20pm
#5
Thoughts on renaming LockedSingle and UnlockedSingle to Locked and Unlocked for backwards EIP-5192 compatibility?
1 Like
It is inspired by EIP-5192 but it’s for EIP-1155. I thought the function/events naming convention should be conform to that of EIP-1155. It would be better to change it if other existing contracts use the name.