SBT Standards Discussion

SBT needs to have the characteristics of non-transferability and revocability. When implementing SBT on the Sui public chain, we explored the engineering aspects and proposed it as a technical standard.

To enable the sender to revoke SBT on Sui, the SBT object needs to be held by the sender so that the destroy function can be called. The receiver can obtain a pointer object pointing to the SBT object, which needs to include certain specifically named field to indicate the address of the SBT object, which recommended to be named as SBTID.

The SBT object standard can align with the NFT standard, including metadata and other relevant information for easy display. If the receiver has a pointer object on asset display platforms such as wallets, the pointed SBT object can be displayed directly. There are several benefits to this implementation. It is easier for the sender to index their published SBT and withdraw incorrectly published SBT. If the sender withdraws the SBT object containing detailed information, it also saves online storage resources. It does not affect the display of the receiver’s SBT.

To restrict SBT from being transferred, the generated SBT object and pointer object can only have the key ability, without the store ability.
Based on this idea, we have implemented an SBT smart contract on Sui, and the project address is GitHub - RandyPen/certificate-SBT: certificate SBT


and by the way, it might make sense for the sui network


@CharmingPen thanks for the info