ERC-7704: Soul Resonance Token

Abstract

This EIP proposes the following improvements to Soul Bond Tokens: Extensibility to ERC-20. 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 assets, possessing both the soul-binding characteristics of SBT and the tradability of traditional ERC-20 assets.

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, with the exception of transfer operations. Furthermore, exclusivity to implementing solely this EIP is required.

Rationale

SRT serves as an extension to ERC-20, ERC-721, or ERC-1155, enabling seamless integration with any of these standards. It advocates for the deactivation of the transfer method to uphold clarity in ownership relations. Token transactions are exclusively conducted through minting and burning methods, facilitating uncomplicated permission management. Furthermore, reputation computation can be customized using bonding curves, with implementation guided by adherence to the SRT interface.

Backwards Compatibility

This proposal is only partially compatible with ERC-20 because it makes tokens non-transferable after the first transfer.

Implementations

Reference Implementation

// SPDX-License-Identifier: MIT
// Compatible with OpenZeppelin Contracts ^5.0.0
pragma solidity ^0.8.20;

import {ERC20} from "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract SRT20Minimal is ERC20 {
    error TransferNotAllowed();

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

    function _update(
        address from,
        address to,
        uint256 value
    ) internal virtual override {
        if (from != address(0) && to != address(0)) {
            revert TransferNotAllowed();
        }
        super._update(from, to, value);
    }

    function mint(address to, uint256 amount) public {
        _mint(to, amount);
    }

    function burn(address from, uint256 amount) public {
        _burn(from, amount);
    }

}

// SPDX-License-Identifier: MIT
// Compatible with OpenZeppelin Contracts ^5.0.0
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";

contract SRT721Minimal is ERC721 {
    error TransferNotAllowed();

    constructor() ERC721("Soul Resonance Token 721", "SRT721") {}

    function _update(
        address to,
        uint256 tokenId,
        address auth
    ) internal virtual override returns (address) {
        address from = super._update(to, tokenId, auth);
        if (from != address(0) && to != address(0)) {
            revert TransferNotAllowed();
        }
        return from;
    }

    function safeMint(address to, uint256 tokenId) public {
        _mint(to, tokenId);
    }

    function burn(uint256 tokenId) public {
        _update(address(0), tokenId, msg.sender);
    }

}

// SPDX-License-Identifier: MIT
// Compatible with OpenZeppelin Contracts ^5.0.0
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC1155/ERC1155.sol";

contract SRT1155Minimal is ERC1155 {
    error TransferNotAllowed();

    constructor() ERC1155("srt") {}

    function _update(
        address from,
        address to,
        uint256[] memory ids,
        uint256[] memory values
    ) internal virtual override {
        if (from != address(0) && to != address(0)) {
            revert TransferNotAllowed();
        }
        super._update(from, to, ids, values);
    }

    function mint(
        address to,
        uint256 id,
        uint256 amount,
        bytes memory data
    ) public {
        _mint(to, id, amount, data);
    }

    function burn(
        address account,
        uint256 id,
        uint256 amount
    ) public {
        _burn(account, id, amount);
    }
}

Security Considerations

While we maintain high standards for code quality and test coverage throughout the development process of this project, it is crucial to acknowledge that the overall security of the implementation cannot be guaranteed at this time. The Soul Resonance Token (SRT) protocol and its associated smart contracts have not yet undergone a comprehensive, independent security audit by a reputable third-party organization.

As with any blockchain-based project, particularly those involving novel token mechanisms like SRT, there may be unforeseen vulnerabilities or edge cases that could potentially be exploited. Users and implementers should exercise caution and conduct their own thorough risk assessment before deploying or interacting with SRT contracts in production environments.

Key points to consider: The absence of a formal security audit means that potential vulnerabilities may exist in the codebase. The unique nature of SRT, combining non-transferability with tradability, introduces new dynamics that may not have been fully explored in terms of security implications. The customizable market curve feature, while offering flexibility, also introduces additional complexity that could potentially be a source of security risks if not implemented or configured correctly. As with any smart contract system, the SRT protocol may be subject to common blockchain vulnerabilities such as reentrancy attacks, front-running, or other forms of manipulation. The interaction between SRT and existing token standards (ERC-20, ERC-721, ERC-1155) may introduce unforeseen complications or security considerations.

We strongly recommend that any implementation of the SRT protocol undergo a rigorous security audit by experienced blockchain security professionals before being deployed in a live environment. Additionally, we encourage the community to review the code, provide feedback, and report any potential security issues they may discover.

Copyright

Copyright and related rights waived via CC0.