-
Notifications
You must be signed in to change notification settings - Fork 341
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ERC: Soul Resonance Token #414
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||||||
---|---|---|---|---|---|---|---|---|---|---|
@@ -0,0 +1,90 @@ | ||||||||||
--- | ||||||||||
eip: 7699 | ||||||||||
title: Soul Resonance Token | ||||||||||
description: this EIP defines an interface for Soul Resonance Tokens | ||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Your description just repeats your title. Try to expand on the idea you introduce there, instead of just restating it. Perhaps explain what a Soul Resonance Token is? |
||||||||||
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 | ||||||||||
Check failure on line 6 in ERCS/erc-7699.md
|
||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Please create a topic in Ethereum Magicians with a link to this PR. |
||||||||||
status: Draft | ||||||||||
type: Standards Track | ||||||||||
category: ERC | ||||||||||
created: 2024-04-28 | ||||||||||
requires: 20 | ||||||||||
--- | ||||||||||
|
||||||||||
Check failure on line 13 in ERCS/erc-7699.md
|
||||||||||
## Abstract | ||||||||||
|
||||||||||
This EIP proposes the following improvements to Soul Bond Tokens: | ||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
Assume you mean bound? |
||||||||||
Extensibility to [ERC-20](./erc-20.md). | ||||||||||
Token Minting and Burning while preserving non-transferability. | ||||||||||
Comment on lines
+16
to
+18
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Your abstract should layout the goal of the proposal, and give the reader a high level technical overview of how it accomplishes that goal. Yours is probably a bit light on the technical side. |
||||||||||
|
||||||||||
## 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](./erc-20.md) assets, possessing both the soul-binding characteristics of SBT and the tradability of traditional [ERC-20](./erc-20.md) assets. | ||||||||||
|
||||||||||
## Characteristics | ||||||||||
Check failure on line 24 in ERCS/erc-7699.md
|
||||||||||
|
||||||||||
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. | ||||||||||
Comment on lines
+32
to
+33
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Generally standards should be applicable across all Solidity versions. You shouldn't need to note this.
Suggested change
|
||||||||||
|
||||||||||
The smart contract realising this EIP mandate must fully incorporate all methods prescribed by [ERC-20](./erc-20.md), with the exception of transfer operations. Furthermore, exclusivity to implementing solely this EIP is required. | ||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is vaguely worded. For example, if an implementer wants to support ERC-165, would this prevent them? |
||||||||||
|
||||||||||
## Token Methods | ||||||||||
|
||||||||||
### Internal _update Function Override | ||||||||||
|
||||||||||
```solidity | ||||||||||
function _update(address from, address to, uint256 value) internal virtual override { | ||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
EIPs should only specify the externally visible behaviours of contracts, and not their implementation specifics. |
||||||||||
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](./erc-20.md) contract. It is an internal function that is used internally by the [ERC-20](./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); | ||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Same comment here: |
||||||||||
} | ||||||||||
``` | ||||||||||
|
||||||||||
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); | ||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. And again here with |
||||||||||
} | ||||||||||
``` | ||||||||||
|
||||||||||
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](./erc-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. | ||||||||||
Comment on lines
+77
to
+80
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
The renderer will generate this section for you. |
||||||||||
|
||||||||||
## References | ||||||||||
|
||||||||||
**Implementations** | ||||||||||
|
||||||||||
- [ERC-7699 Reference Implementation](https://github.com/mike0x1024/srt-template) | ||||||||||
Check failure on line 86 in ERCS/erc-7699.md
|
||||||||||
|
||||||||||
Comment on lines
+82
to
+87
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is a non-standard section of EIPs. If you'd like to include a reference implementation, you may do so in the |
||||||||||
## Copyright | ||||||||||
|
||||||||||
Copyright and related rights waived via [CC0](../LICENSE.md). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assigning next sequential EIP/ERC/RIP number.
Please also update the filename.