EIP-6268: UNTransferability Indicator for EIP-1155

I submitted an EIP, that is inspired by EIP-5172 and have a similar simple interface.
This is something like EIP-5172 for EIP-1155.


I made a PR.

Make sure to use the latest eip-template!

Thank you for pointing out. I’ve corrected the problem. If the problem is still there, please let me know.

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.

This looks really good! :+1:

A minor comment on the title: I think the best possible title for all these standards (after having one year of time to think about this) is “Lockable NFTs.” It is because “Lockable” allows all the following states:

  • permanently locked (Soulbound or account bound or non-transferable)
  • temporarily or conditionally locked/transferrable (loaned)
  • permanently transferrable

Lockable has the added benefit that it hasn’t been social-media captured by some special interest group wanting to push their solution for X (as has been done with SBTs and NTTs). People have genuinely no understanding yet of lockable tokens. But already the name implies: “This thing is lockable, but it also means that it is potentially unlockable.” It can, however, also mean: “this thing is permanently lockable.”

Then, let me please explain a different feature that you may want to consider that has been implemented in: ERC-5058: Lockable Non-Fungible Tokens approving locks.

See, with transfers on EIP-20 and EIP-721 tokens, we can approve a contract or another account to make a transfer on our behalf. And the nice thing about it is that this isn’t hard coded with respect to the approved account. And it translates into e.g. Uniswap contracts managing my EIP20 tokens for trading (which is a very nice feature).

Now, with EIP-5192, I had intended to build something like that by allowing the users to implement the locked function themselves and to revert to transfer as they saw fit. But then, this forces hard coding of the values in the respective implementation. So what ERC-5058: Lockable Non-Fungible Tokens, by allowing to approve an operator to manage the lock function, is much better because it generalizes the lock operator instead of the developer hard coding it.

I’d consider implementing this @yuki-js unless you see very big drawbacks to this.

Hello, I think that eip is good, I’ve been considering eip similar recently
But I found “created” date field is weird, Is that 2022?

Thank you for pointing out. Yes, indeed this is incorrect. I made a mistake because it spans 2022 and 2023. It’s a subtle mistake, but to avoid confusion, I will create a pull request later.