Please note that “lockable” alone could refer to locking of metadata. Additionally, there is already a proposal for a similar name “Lockable Non-Fungible Tokens”.
PS: I’m disappointed that the eip5058 authors didn’t answer my call to merge our work streams in SEPTEMBER and that they’re now proposing a duplication of the work done in eip5192: EIP-5058: ERC-721 Lockable Standard - #2 by TimDaub
Certainly, as there is no direct mention of SBT in EIP, my explanation was incorrect. I apologize. The correct term is “Soulbound”. I mean the notion of soulbound is already accepted by the community.
I agree that “Minimal soulbound NFTs” is not appropriate, and the idea of SBTs should be divided into two traits: untransferability and non-fungibility, in the context of implementation. That’s why I named EIP-6268 “Untransferability Indicator for EIP-1155”. Actually, I first wanted to rename this EIP (see the first revision).
IMHO “Untransferability Indicator for EIP-721” has clearer meaning.
The goal of EIP5058 is quite different. They focus on token that can be locked, instead of being staked, with all the function that are needed to reach that goal. It is very close to the contracts I wrote for our application (GitHub - ndujaLabs/erc721lockable: A simple approach to lock NFTs without transferring the ownership), with the central difference that in my proposal is the owner of the token’s contract that whitelists the contracts authorized to lock the token, while in ERP5058, the owner of a tokenID can approve any contract, exactly like we do for spending.
I have to say that I like that approach because it is very general.
Of course, they could have extended EIP5192, as I did in my implementation after reading this thread. The only required change is to move the function isLocked to locked.
@TimDaub I made a PR to suggest the addition of a defaultLocked function in your proposal at
I made it there, because here the discussion seems not very active, while in the PR the reviewers will be required to intervene, avoiding long, not very useful discussions. Here is the text of the PR
I suggest to add
/// @notice Returns the default locking status of an Soulbound Token
/// @dev it avoid enforcing the emission of a Locked or Unlocked event at minting
/// It may be a `pure` function in most cases, but a view is more flexible
function defaultLocked() external view returns (bool);
to the interface.
I am currently working on a security-oriented project and developing a similar interface (protector-protected-protocol/IERC721Approvable.sol at main · ndujaLabs/protector-protected-protocol · GitHub). In our case, we need to control the approvability of a token. While investigating, I realized a significant problem with emitting events (such as Locked and Unlocked) is that you have to emit them each time there’s a change. However, when you mint a token, it typically starts with a default value for every tokenId, so emitting events at that point would be a waste of gas. For instance, with a typical soulbound token that is not transferable and never will be, it does not make any sense to emit the event. This would cause that whoever is deploying such a token would not use ERC5192.
In this proposal, the emission of the event at minting is unnecessary because an external actor can check if the token supports ERC5192 and query a function that returns the default status if no events have been emitted.
late to the part, but i particularly liked this spec since it’s quite lightweight, i appreciate simplicity just successfully implemented it for ERC-1155 in a way that each token id can be un/locked individually, was wondering why the spec is only applicable to 721s “officially”
I focused on specifying an addon to ERC721 only because I find it difficult to understand the entirety of the ERC1155 specification. I’m familiar with ERC721 and so I decided to only specify an addon for it. But anyone is welcome to transfer the ERC-5192 logic into ERC-1155!
@TimDaub
Following Pandapip1 suggestion (when he closed my PR on your EIP), I made an alternative proposal.
I would have preferred to work with you on that, but it looks like when an EIP is in the final stage nothing can be changed.
Thanks @TimDaub for putting this together. Been working on implementing support for this standard in an ERC721 NFT.
How has market adoption been? I don’t know of anyone using ERC5192.
This is definitely something that we need. I’m working on some ideas on this, since I have worked with ERC1155 and also have the requirement. Would be basing it off the ERC5192.
just successfully implemented it for ERC-1155 in a way that each token id can be un/locked individually, was wondering why the spec is only applicable to 721s “officially” 