Skip to content

Commit

Permalink
Update EIP 7699
Browse files Browse the repository at this point in the history
  • Loading branch information
@mike0x1024
mike0x1024 committed Apr 28, 2024
1 parent a5bbe60 commit 9bfa55c
Showing 1 changed file with 18 additions and 18 deletions.
36 changes: 18 additions & 18 deletions EIPS/eip-7699.md
View file
Original file line number Diff line number Diff line change
@@ -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>
status: Draft
type: ERC
type: Standards Track
discussions-to: http:
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](https://github.com/ethereum/ercs/blob/master/ERCS/erc-20.md).

Check failure on line 16 in EIPS/eip-7699.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

references to proposals with a `category` of `ERC` must use a prefix of `ERC` 

error[markdown-refs]: references to proposals with a `category` of `ERC` must use a prefix of `ERC`
  --> EIPS/eip-7699.md
   |
16 | Extensibility to [erc-20](https://github.com/ethereum/ercs/blob/master/ERCS/erc-20.md).
   |
   = help: see https://ethereum.github.io/eipw/markdown-refs/
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](https://github.com/ethereum/ercs/blob/master/ERCS/erc-20.md) assets, possessing both the soul-binding characteristics of SBT and the tradability of traditional [erc-20](https://github.com/ethereum/ercs/blob/master/ERCS/erc-20.md) assets.

Check failure on line 21 in EIPS/eip-7699.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

references to proposals with a `category` of `ERC` must use a prefix of `ERC` 

error[markdown-refs]: references to proposals with a `category` of `ERC` must use a prefix of `ERC`
  --> EIPS/eip-7699.md
   |
21 | 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](https://github.com/ethereum/ercs/blob/master/ERCS/erc-20.md) assets, possessing both the soul-binding characteristics of SBT and the tradability of traditional [erc-20](https://github.com/ethereum/ercs/blob/master/ERCS/erc-20.md) assets.
   |

Check failure on line 21 in EIPS/eip-7699.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

references to proposals with a `category` of `ERC` must use a prefix of `ERC` 

error[markdown-refs]: references to proposals with a `category` of `ERC` must use a prefix of `ERC`
  --> EIPS/eip-7699.md
   |
21 | 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](https://github.com/ethereum/ercs/blob/master/ERCS/erc-20.md) assets, possessing both the soul-binding characteristics of SBT and the tradability of traditional [erc-20](https://github.com/ethereum/ercs/blob/master/ERCS/erc-20.md) assets.
   |

## Characteristics

Check failure on line 23 in EIPS/eip-7699.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

body has extra section(s) 

error[markdown-order-section]: body has extra section(s)
  --> EIPS/eip-7699.md
   |
23 | ## Characteristics
   |
  ::: EIPS/eip-7699.md
   |
86 | ## Citation
   |
   = help: see https://ethereum.github.io/eipw/markdown-order-section/

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](https://github.com/ethereum/ercs/blob/master/ERCS/erc-20.md), 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.

Check failure on line 34 in EIPS/eip-7699.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

the first match of the given pattern must be a link 

error[markdown-link-first]: the first match of the given pattern must be a link
  --> EIPS/eip-7699.md
   |
34 | The smart contract realising this EIP mandate must fully incorporate all methods prescribed by [erc-20](https://github.com/ethereum/ercs/blob/master/ERCS/erc-20.md), 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.
   |
   = info: the pattern in question: `(?i)(?:eip|erc)-[0-9]+`
   = help: see https://ethereum.github.io/eipw/markdown-link-first/

Check failure on line 34 in EIPS/eip-7699.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

references to proposals with a `category` of `ERC` must use a prefix of `ERC` 

error[markdown-refs]: references to proposals with a `category` of `ERC` must use a prefix of `ERC`
  --> EIPS/eip-7699.md
   |
34 | The smart contract realising this EIP mandate must fully incorporate all methods prescribed by [erc-20](https://github.com/ethereum/ercs/blob/master/ERCS/erc-20.md), 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.
   |

Check failure on line 34 in EIPS/eip-7699.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

references to proposals with a `category` of `ERC` must use a prefix of `ERC` 

error[markdown-refs]: references to proposals with a `category` of `ERC` must use a prefix of `ERC`
  --> EIPS/eip-7699.md
   |
34 | The smart contract realising this EIP mandate must fully incorporate all methods prescribed by [erc-20](https://github.com/ethereum/ercs/blob/master/ERCS/erc-20.md), 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.
   |


### Token Methods

#### Constructor

```solidity
constructor() ERC20("Soul Resonance Token 20", "SRT20") {}
```

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

```solidity
function _update(address from, address to, uint256 value) internal virtual override {
if (from != address(0) && to != address(0)) {
Expand All @@ -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](https://github.com/ethereum/ercs/blob/master/ERCS/erc-20.md) contract. It is an internal function that is used internally by the [erc-20](https://github.com/ethereum/ercs/blob/master/ERCS/erc-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.

Check failure on line 51 in EIPS/eip-7699.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

references to proposals with a `category` of `ERC` must use a prefix of `ERC` 

error[markdown-refs]: references to proposals with a `category` of `ERC` must use a prefix of `ERC`
  --> EIPS/eip-7699.md
   |
51 | Description: This function overrides the _update function inherited from the [erc-20](https://github.com/ethereum/ercs/blob/master/ERCS/erc-20.md) contract. It is an internal function that is used internally by the [erc-20](https://github.com/ethereum/ercs/blob/master/ERCS/erc-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.
   |

Check failure on line 51 in EIPS/eip-7699.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

references to proposals with a `category` of `ERC` must use a prefix of `ERC` 

error[markdown-refs]: references to proposals with a `category` of `ERC` must use a prefix of `ERC`
  --> EIPS/eip-7699.md
   |
51 | Description: This function overrides the _update function inherited from the [erc-20](https://github.com/ethereum/ercs/blob/master/ERCS/erc-20.md) contract. It is an internal function that is used internally by the [erc-20](https://github.com/ethereum/ercs/blob/master/ERCS/erc-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);
Expand All @@ -65,6 +61,7 @@ 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

```solidity
function burn(address from, uint256 amount) public {
_burn(from, amount);
Expand All @@ -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.

Check failure on line 77 in EIPS/eip-7699.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

the first match of the given pattern must be a link 

error[markdown-link-first]: the first match of the given pattern must be a link
  --> EIPS/eip-7699.md
   |
77 | This proposal is only partially compatible with EIP-20 because it makes tokens non-transferable after the first transfer.
   |
   = info: the pattern in question: `(?i)(?:eip|erc)-[0-9]+`
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.

0 comments on commit 9bfa55c

Please sign in to comment.