Add EIP: Soul Resonance Token

EIPS/eip-7699.md

@@ -0,0 +1,90 @@
+---
+eip: 7699
+title: Soul Resonance Token
+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/1
+status: Draft
+type: Standards Track
+category: ERC
+created: 2024-04-28
+requires: 20
+---
+
+## Abstract
+
+This EIP proposes the following improvements to Soul Bond Tokens:
+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 [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 [ERC-20](./eip-20.md), with the exception of transfer operations. Furthermore, exclusivity to implementing solely this EIP is required.
+
+## Token Methods
+
+### Internal _update Function Override
+
+```solidity
+function  _update(address from, address to, uint256 value) internal virtual override { 
+    if (from != address(0) && to != address(0)) {
+        revert TransferNotAllowed();
+    }
+    super._update(from, to, values);
+}
+```
+
+
+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
+
+```solidity
+function mint(address to, uint256 amount) public {
+    _mint(to, amount);
+}
+```
+
+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
+
+```solidity
+ function burn(address from, uint256 amount) public {
+    _burn(from, amount);
+}
+```
+
+Description: This function allows token holders to burn a specific amount of their tokens. It decreases the balance of the specified address by the given amount of tokens. Burning tokens means removing them from circulation permanently. This function provides token holders with the ability to reduce their token balances voluntarily.
+
+## Backwards Compatibility
+
+This proposal is only partially compatible with [ERC-20](./eip-20.md) because it makes tokens non-transferable after the first transfer.
+
+## 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.
+
+## References
+
+**Implementations**
+
+- [ERC-7699 Reference Implementation](https://github.com/mike0x1024/srt-template)
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).