Main requirements

• Non-transferable tokens (NTTs) cannot be transferred between addresses, i.e any update of the balances of an address must either come from burning the tokens they hold or being minted new tokens.
• NTTs can either be non-fungible (like ERC721 NFTs) or fungible (experience points, credit-score like).
• An NTT cannot be minted to an address (either smart contract wallet or EOA) without consent.
• NTTs may be locked (staked) in a smart contract.

Optional requirements (Outside the scope of the standard)

• Each NTT may have a unique token URI.
• Non-fungible NTTs can be grouped as a collection such that it’s easy to know if an address owns one the badges from a specific collection.

Considerations and implementation details left to dApps

• Application creator should be very careful about the kind of data that they store on chain.
• Any logic regarding how NTTs are created or revoked are left to applications creators.
  • NTTs may be revoked by their issuer: We noted that for most use cases where a NTT represents an identity claim, issuers should always maintain the right to revoke the NTTs they issued. For instance, an issuer might discover that their system was compromised months after the day of issuance. Therefore, it needs to be able to revoke NTTs that were issued previously.
  • NTTs may be burned by their owner.