In your EIP-5192 thread, specifically the post that inspired you to include the locked function.
You specifically mentioned token transferability is possible, and this “shut up the nay-sayers arguing for better key rotation”. It doesn’t matter who has the rights to change token transferability, contract owner of token receiver, the fact that this is changeable makes my previous point:
Again, it’s not about what is “possible” or “achievable with EIP-5192”. What’s important is that the flexibility of EIP-5192 diminishes credibility of SBTs’ immutability.
If you want to argue that oh wait, I have changed my mind, and EIP-5192’s lock status CANNOT be changed by either parties after issuance. There are few things you have to do. First,
This should be in your EIP’s specification section, not here in the comment section of a related proposal. Your proposal made it very vague and ambiguous on who has the rights to change/assign lock status. Previously I thought you leave it to the implementation to decide the specific rules, but if you want to argue that lock/unlock status is permanent after issuance (which is basically what you are arguing in the previous post), your current EIP-5192 definitely needs a lot of modification on clarifying the rules, and I recommend you roll it back to review status if you intend EIP-5192’s lock status to be permanent after issuance.
Thank you for your response! I would love to learn and also make use of myself in exchange for technical support
My idea is to create an adaptive learning platform - for children - using an LLM as a guidance system in a web3 setup. I feel like SBTs can be used to strengthen community traits, and different industries/communities can use them for different purposes. There are many use cases, but my idea is about changing the way we teach things. Thru adaptive learning, I think we can make more interactive or more individualistic education for the next generation. There is more to add to that. But, briefly put, it’s for children who are coming from different socio economic backgrounds.
We cannot enforce an implementation via an interface. If you’ve heard of e.g. sleepminting attacks, then they demonstrate that despite the EIP-721 standard mandating the mint event to go from addr(0) to the transaction.from field, someone may not implement that to fool Rarible or Etherscan user interfaces: What Is Sleepminting And Will It Ruin NFT Provenance?
Solidity interfaces do not enforce implementation.
For any EIP-5484 or EIP-5192, without users specifically auditing the actual implementation there is no credibility that implementing the interface correctly also means immutably soul binding the token. This information can only be derived from actually auditing the entire code of any contract.
Here, a fully working transferrable “Soulbound EIP-5633” implementation.
// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.0;
import "@openzeppelin/contracts/token/ERC1155/ERC1155.sol";
import "./IERC5633.sol";
/**
* @dev Extension of ERC1155 that adds soulbound property per token id.
*
*/
abstract contract ERC5633 is ERC1155, IERC5633 {
/// @dev See {IERC165-supportsInterface}.
function supportsInterface(bytes4 interfaceId) public view virtual override(ERC1155) returns (bool) {
return interfaceId == type(IERC5633).interfaceId || super.supportsInterface(interfaceId);
}
/**
* @dev Returns true if a token type `id` is soulbound.
*/
function isSoulbound(uint256 id) public view virtual returns (bool) {
return true;
}
}
Interesting idea Can you elaborate on what do you mean by LLM, and your ideas on how SBTs can be used to strengthen community traits? You can DM me about ur ideas so we can keep this thread focused on the EIP, thanks.
You are explaining something so basic I don’t know what to say.
It is pretty obvious we cannot force the exact implementations of sbts. If you read my previous posts carefully:
you wouldn’t waste your time explaining basic concept like EIP cannot enforce implementation, since the goal of this EIP is to set guidance, build credibility, and create a standard for burnauth number coding, not enforcement.
Furthermore, you are dodging all the important questions I have posted and focusing on useless details that you might think could help win your argument.
This conversation has become a total waste of my time. I am not going to respond to your further questions/comments if it’s just another childish attempt trying to nitpick some nonexistent problems to make yourself feel better.
I want to implement a SBT extending ERC721, what should I do? Do I have to implement both EIP5192 and EIP5484? Do I have to emit both a Locked and a Issued event on minting? It is very confusing to have two standards referring to the same thing without acknowledging one another. @TimDaub@BuzzCai
depends on what functionality you need. If you want to lock and unlock ERC721 tokens, just implement 5192 and that‘s it. If you need burn authorization and 5192 compatibility, come talk to me and we can find a solution with e.g. a new standard
@BuzzCai
Recently I’m working on an experimental implementation of semi-fungible SBT supporting EIP-5484. Having a BurnAuth defined when issuing SBT makes revocation rights more explicit.
I would really appreciate your feedbacks on semi-fungible SBTs.
