Update ERC-5727: Remove stale assets (ethereum#6670)

* chore: update compatibility

* fix: change ERC references naming

* chore: remove old interface design

* chore: fix link issue

* chore: remove stale descriptions about shadowing

* chore: remove stale assets

* fix: remove stale link

EIPS/eip-5727.md

@@ -15,7 +15,7 @@ requires: 165, 712, 721, 3525, 4906, 5192, 5484
 
 An interface for soulbound tokens (SBT), which are non-transferable tokens representing a person's identity, credentials, affiliations, and reputation.
 
-Our interface can handle a combination of fungible and non-fungible tokens in an organized way. It provides a set of core methods that can be used to manage the lifecycle of soulbound tokens, as well as a rich set of extensions that enables DAO governance, privacy protection, token expiration, and account recovery.
+Our interface can handle a combination of fungible and non-fungible tokens in an organized way. It provides a set of core methods that can be used to manage the lifecycle of soulbound tokens, as well as a rich set of extensions that enables DAO governance, delegation, token expiration, and account recovery.
 
 This interface aims to provide a flexible and extensible framework for the development of soulbound token systems.
 
@@ -27,12 +27,12 @@ We have already seen many attempts to create such non-transferable tokens in the
 
 Our interface can be used to represent non-transferable ownerships, and provides features for common use cases including but not limited to:
 
-- granular lifecycle management of SBTs (e.g. minting, revocation, expiration)
+- granular lifecycle management of SBTs (e.g. minting, revocation, subscription and expiration)
 - management of SBTs via community voting and delegation (e.g. DAO governance, operators)
-- recovery of SBTs (e.g. switching to a new wallet)
-- token visibility control (e.g. private SBTs, hiding negative tokens)
-- fungible and non-fungible SBTs (e.g. membership card and loyalty points)
+- recovery of SBTs (e.g. account recovery and key rotation)
+- fungible and non-fungible SBTs (e.g. membership cards and loyalty points)
 - the grouping of SBTs using slots (e.g. complex reward schemes with a combination of vouchers, points, and badges)
+- claimable SBTs (e.g. airdrops, giveaways, and referrals)
 
 A common interface for soulbound tokens will not only help enrich the Web3 ecosystem but also facilitates the growth of a decentralized society.
 
@@ -426,7 +426,7 @@ interface IERC5727Expirable is IERC5727, IERC5643 {
 
 We adopt semi-fungible token storage models designed to support both fungible and non-fungible tokens, inspired by the semi-fungible token standard. We found that such a model is better suited to the representation of SBT than the model used in [ERC-1155](./eip-1155.md).
 
-Firstly, each slot can be used to represent different categories of SBTs. For instance, a DAO can have membership SBTs, role badges, scores, etc. in one SBT collection.
+Firstly, each slot can be used to represent different categories of SBTs. For instance, a DAO can have membership SBTs, role badges, reputations, etc. in one SBT collection.
 
 Secondly, unlike [ERC-1155](./eip-1155.md), in which each unit of fungible tokens is exactly the same, our interface can help differentiate between similar tokens. This is justified by that credential scores obtained from different entities differ not only in value but also in their effects, validity periods, origins, etc. However, they still share the same slot as they all contribute to a person's credibility, membership, etc.
 
@@ -436,10 +436,6 @@ To prevent the loss of SBTs, we propose a recovery mechanism that allows users t
 
 Since SBTs are bound to an address and are meant to represent the identity of the address, which cannot be split into fractions. Therefore, each recovery should be considered as a transfer of all the tokens of the owner. This is why we use the `recover` function instead of `transferFrom` or `safeTransferFrom`.
 
-### Token visibility control
-
-Our interface allows users to control the visibility of their tokens (shadowing and revealing). This is useful when a user wants to hide some of their tokens from the public, for example, when they want to keep their membership secret. Generally, the issuer and the owner of the token have access to the token by default and can control the visibility of the token. After the token is shadowed, information about the token (e.g. token URI, owner of the token) cannot be queried by the public.
-
 ## Backwards Compatibility
 
 This EIP proposes a new token interface which is compatible with [ERC-721](./eip-721.md), [ERC-3525](./eip-3525.md), [ERC-4906](./eip-4906.md), [ERC-5192](./eip-5192.md), [ERC-5484](./eip-5484.md).
@@ -452,7 +448,7 @@ Our sample implementation includes test cases written using Hardhat.
 
 ## Reference Implementation
 
-You can find our sample implementation [here](../assets/eip-5727/contracts/ERC5727Example.sol).
+To be updated.
 
 ## Security Considerations