Update EIP 7699

EIPS/eip-7699.md

@@ -1,48 +1,43 @@
 ---
 eip: 7699
 title: Soul Resonance Token
-description: this EIP defines an interface for Soul Resonance Tokens (SRT), which are non-transferable tokens designed to represent the historical influence or significance of Ethereum accounts.
-author: Authors	Abe Johnson（abe@burve.io） Mike Smith（Mike@burve.io)， Alvis Kaiser(alvis@burve.io), Wurst Tsao(wurst@burve.io
+description: this EIP defines an interface for Soul Resonance Tokens
+author: Mike Smith (@mike0x1024), Abe Johnson <abe@burve.io>, Alvis Kaiser <alvis@burve.io>, WurDst Tsao <wurst@burve.io>
+discussions-to: https://ethereum-magicians.org/t/
+type: Standards Track
+category: ERC
 status: Draft
-type: ERC
 created: 2024-04-28
 requires: 20
 ---
 
 ## Abstract
 
 This EIP proposes the following improvements to Soul Bond Tokens:
-Extensibility to ERC-20.
+Extensibility to [ERC-20](./eip-20.md).
 Token Minting and Burning while preserving non-transferability.
 
 ## Motivation
 
-The inspiration behind this EIP stems from discussions surrounding the advantages and potential applications of Soulbound/Account Bound Tokens (SBTs). However, upon analysing the pros and cons of SBTs, it has been determined that while the non-transferable nature of SBTs, which binds them to user accounts, can serve as a notable feature akin to a badge of honour, it also impedes the fluidity and evolution of the tokens themselves. SRT, short for Soul Resonance Token, is a special token protocol. Like SBT, SRT does not support transfer methods, meaning users cannot transfer SRT assets between different accounts. What makes SRT special is that, through the Bonding Curve protocol, the mint() and burn() methods are constructed to achieve pricing and trading functions for SRT. Therefore, SRT is a type of asset that cannot be transferred but can be traded. SRT fills the gap between SBT and traditional ERC20 assets, possessing both the soul-binding characteristics of SBT and the tradability of traditional ERC20 assets.
+The inspiration behind this EIP stems from discussions surrounding the advantages and potential applications of Soulbound/Account Bound Tokens (SBTs). However, upon analysing the pros and cons of SBTs, it has been determined that while the non-transferable nature of SBTs, which binds them to user accounts, can serve as a notable feature akin to a badge of honour, it also impedes the fluidity and evolution of the tokens themselves. SRT, short for Soul Resonance Token, is a special token protocol. Like SBT, SRT does not support transfer methods, meaning users cannot transfer SRT assets between different accounts. What makes SRT special is that, through the Bonding Curve protocol, the mint() and burn() methods are constructed to achieve pricing and trading functions for SRT. Therefore, SRT is a type of asset that cannot be transferred but can be traded. SRT fills the gap between SBT and traditional [ERC-20](./eip-20.md) assets, possessing both the soul-binding characteristics of SBT and the tradability of traditional [ERC-20](./eip-20.md) assets.
 
 ## Characteristics
+
 The tokens are confined solely to minting and burning functionalities, precluding any transferability.
 During the execution of minting and burning transactions, the system logs the cumulative reputation associated with the respective account.
 On-chain events are deployed to meticulously capture and document the progression of reputation accumulation.
 
 ## Specification
+
 Notes:
 The contract is designed to be compiled with a Solidity compiler version greater than or equal to 0.8.20 but less than 0.9.0.
 
-The smart contract realising this EIP mandate must fully incorporate all methods prescribed by ERC20, with the exception of transfer operations. Furthermore, exclusivity to implementing solely this EIP is required. Additionally, the implementation necessitates the inclusion of the EIP-165 supportsInterface method, which must consistently return the boolean value true when queried with the designated interface ID 0xe55ab48f.
-
+The smart contract realising this EIP mandate must fully incorporate all methods prescribed by [ERC-20](./eip-20.md), with the exception of transfer operations. Furthermore, exclusivity to implementing solely this EIP is required.
 
-### Token Methods
-
-#### Constructor
-
-```solidity
-constructor() ERC20("Soul Resonance Token 20", "SRT20") {}
-```
+## Token Methods
 
-Description: 
-This is the constructor function of the contract. It is executed only once during the deployment of the contract. It sets the name of the token to "Soul Resonance Token 20" and the symbol to "SRT20" using the constructor of the ERC20 contract.
+### Internal _update Function Override
 
-#### Internal _update Function Override
 ```solidity
 function  _update(address from, address to, uint256 value) internal virtual override { 
     if (from != address(0) && to != address(0)) {
@@ -53,9 +48,10 @@ function  _update(address from, address to, uint256 value) internal virtual over
 ```
 
 
-Description: This function overrides the _update function inherited from the ERC20 contract. It is an internal function that is used internally by the ERC20 contract to update the balances of token holders during transfer operations. In this contract, it restricts transfers between non-zero addresses, reverting the transaction with the “TransferNotAllowed” error if both the sender and receiver addresses are non-zero.
+Description: This function overrides the _update function inherited from the [ERC-20](./eip-20.md) contract. It is an internal function that is used internally by the [ERC-20](./eip-20.md) contract to update the balances of token holders during transfer operations. In this contract, it restricts transfers between non-zero addresses, reverting the transaction with the “TransferNotAllowed” error if both the sender and receiver addresses are non-zero.
+
+### Mint
 
-#### Mint
 ```solidity
 function mint(address to, uint256 amount) public {
         _mint(to, amount);
@@ -64,7 +60,8 @@ function mint(address to, uint256 amount) public {
 
 Description: This function allows the contract owner to mint new tokens and allocate them to a specified address. It increases the balance of the specified address by the given amount of tokens. This function can be used to create new tokens and distribute them as needed.
 
-#### Burn
+### Burn
+
 ```solidity
  function burn(address from, uint256 amount) public {
         _burn(from, amount);
@@ -76,14 +73,17 @@ Description: This function allows token holders to burn a specific amount of the
 
 
 ## Backwards Compatibility
-This proposal is only partially compatible with EIP-20 because it makes tokens non-transferable after the first transfer.
+
+This proposal is only partially compatible with [ERC-20](./eip-20.md) because it makes tokens non-transferable after the first transfer.
 Reference Implementation
 You can find an implementation of this standard in [srt-template](https://github.com/mike0x1024/srt-template/)
 
 
-## Copyright  
+## Copyright
+
 Copyright and related rights waived via CC0.
 
-## Citation 
+## Citation
+
 Please cite this document as:
 Burve Labs. "Bridging the Gap: Soul Resonance Token (SRT)  Non-transferable yet Tradable Asset Type based on Bonding Curve"Burve Labs. 20 Apr. 2024.