Apply suggestions from initial review

co-authored-by: Pandapip1 <[email protected]> update links Apply initial suggestions from code review Update EIP number and typos. Co-authored-by: William Schwab <[email protected]> Co-authored-by: lightclient <[email protected]> rename, add enumerable, update language update name conventions, ERC165 identifier update backwards compatability
ethereum · Apr 7, 2022 · 7d38d92 · 7d38d92
1 parent 904be25
commit 7d38d92
Show file tree

Hide file tree

Showing 4 changed files with 526 additions and 0 deletions.
diff --git a/EIPS/eip-4974.md b/EIPS/eip-4974.md
@@ -0,0 +1,198 @@
+---
+eip: 4974
+title: EXP Token Standard
+description: A standard interface for fungible, non-tradable tokens, also known as EXP.
+author: Daniel Tedesco (@dtedesco1)
+discussions-to: https://ethereum-magicians.org/t/8805
+status: Draft
+type: Standards Track
+category: ERC
+created: 2022-04-02
+requires: 165
+---
+
+## Abstract
+The following describes a standard interface for fungible non-tradable tokens, or EXP. This standard provides basic functionality for participant addresses to consent to receive tokens and for an operator address to mint, transfer, and burn tokens.
+
+EXP, shorthand for "experience points", may represent accumulated recognition within a smart contract. Like experience points in video games, citations on an academic paper, or Reddit Karma, EXP is bestowed for useful contributions, accumulates as indistinguishable units, and should only be reallocated or destroyed by a reliable authority so empowered.
+
+The standard described here allows reputation earned to be codified within a smart contract and recognized by other applications: from a five-member local bicycle club to a million-member green energy DAO.
+
+## Motivation
+How reputation manifests across groups can vary widely. But healthy communities allocate reputation to their members using three key principles:
+1. Consent -- No one is forced to be part of the group, but joining requires abiding by the governance structure of the group. 
+2. Meritocracy -- Reputation is earned by recognition from the group. It cannot be claimed, purchased, or sold.
+3. Ethics -- The group can decrease an individual's reputation after bad behavior.
+
+Since the creation of Bitcoin in 2008, the vast majority of blockchain applications centered on buying and selling digital assets. While these use cases are substantial, digital assets need not be created with trading in mind. In fact, trading can be detrimental to community-based blockchain projects. This was evident in the pay-to-play dynamics of many EVM-based games and DAOs in 2021.
+
+A smart contract cannot directly imbue consent, meritocracy, and ethics into a community, but it can encourage those principles. In doing so, the standard set out below will hopefully unlock a diverse array of new use cases for tokens. 
+
+We considered a diverse array of use cases, though this may just be the beginning:
+- Voting weight in a DAO
+- Experience points in a decentralized game
+- Loyalty points for customers of a business
+
+This standard is influenced by the [ERC-20](./erc-20) and [ERC-721](./erc-721) token standards and takes cues from each in its structure, style, and semantics. Neither, however, was created for fungible operator-managed token contracts such as EXP. Nor do existing proposals for non-tradable tokens meet the requirements of EXP use cases.
+
+## Specification
+The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
+
+Every ERC-4974 compliant contract MUST implement the ERC4974 and ERC165 interfaces:
+
+```
+// SPDX-License-Identifier: CC0
+
+pragma solidity ^0.8.0;
+
+/// @title ERC-4974 EXP Token Standard
+/// @dev See https://eips.ethereum.org/EIPS/EIP-4974
+///  Note: the ERC-165 identifier for this interface is 0x225bcaf2.
+///  Must initialize contracts with an `_operator` address that is not `address(0)`.
+///  Must initialize contracts assigning participation approval for both `_operator` and `address(0)`.
+interface IERC4974 /* is ERC165 */ {
+
+    /// Emits when operator changes.
+    /// @dev MUST emit whenever `operator` changes.
+    event Appointment(address indexed _operator);
+
+    /// Emits when an address activates or deactivates its participation.
+    /// @dev MUST emit whenever participation status changes.
+    ///  `Transfer` events SHOULD NOT reset participation.
+    event Participation(address indexed _participant, bool _participation);
+
+    /// @notice Emits when operator transfers EXP. 
+    /// @dev MUST emit when EXP is created (`from` == 0), 
+    ///  destroyed (`to` == 0), or reallocated to another address.
+    event Transfer(address indexed _from, address indexed _to, uint256 _amount);
+
+    /// @notice Reassign operator authority.
+    /// @dev MUST throw unless `msg.sender` is `operator`.
+    ///  MUST throw if `operator` address is either already current `operator`
+    ///  or is the zero address.
+    ///  MUST emit an `Appointment` event.
+    /// @param _operator New operator of the smart contract.
+    function setOperator(address _operator) external;
+
+    /// @notice Activate or deactivate participation.
+    /// @dev MUST throw unless `msg.sender` is `participant`.
+    ///  MUST throw if `participant` is `operator` or zero address.
+    ///  MUST emit a `Participation` event.
+    /// @param _participant Address opting in or out of participation.
+    /// @param _participation Participation status of _participant.
+    function setParticipation(address _participant, bool _participation) external;
+
+    /// @notice Returns total EXP allocated to a participant.
+    /// @dev Should register each time `Transfer` emits.
+    ///  Should throw for queries about the zero address.
+    /// @param _participant An address for whom to query EXP total.
+    /// @return uint256 The number of EXP allocated to `participant`, possibly zero.
+    function balanceOf(address _participant) external view returns (uint256);
+
+    /// @notice Mints EXP from zero address to a participant.
+    /// @dev MUST throw unless `msg.sender` is `operator`.
+    ///  MUST throw unless `to` address is participating.
+    ///  MUST emit a `Transfer` event.
+    /// @param _to Address to receive the new tokens.
+    /// @param _amount Total EXP tokens to create.
+    function mint(address _to, uint256 _amount) external;
+
+    /// @notice Burns EXP from participant to the zero address.
+    /// @dev MUST throw unless `msg.sender` is `operator`.
+    ///  MUST emit a `Transfer` event.
+    ///  MAY throw if `from` address is NOT participating.
+    /// @param _from Address from which to destroy EXP tokens.
+    /// @param _amount Total EXP tokens to destroy.
+    function burn(address _from, uint256 _amount) external;
+
+    /// @notice Transfer EXP from one address to another.
+    /// @dev MUST throw unless `msg.sender` is `operator`.
+    ///  MUST throw unless `to` address is participating.
+    ///  MUST throw if either or both of `to` and `from` are the zero address. 
+    ///  MAY throw if `from` address is NOT participating.
+    /// @param _from Address from which to reallocate EXP tokens.
+    /// @param _to Address to which EXP tokens at `from` address will transfer.
+    /// @param _amount Total EXP tokens to reallocate.
+    function reallocate(address _from, address _to, uint256 _amount) external;
+
+}
+
+interface ERC165 {
+    /// @notice Query if a contract implements an interface
+    /// @param interfaceID The interface identifier, as specified in ERC-165
+    /// @dev Interface identification is specified in ERC-165. This function
+    ///  uses less than 30,000 gas.
+    /// @return `true` if the contract implements `interfaceID` and
+    ///  `interfaceID` is not 0xffffffff, `false` otherwise
+    function supportsInterface(bytes4 interfaceID) external view returns (bool);
+}
+```
+
+The *metadata extension* is OPTIONAL for ERC-4974 smart contracts. This allows an EXP smart contract to be interrogated for its name and description.
+```
+// SPDX-License-Identifier: CC0
+
+pragma solidity ^0.8.0;
+
+import "./IERC4974.sol";
+
+/// @title ERC-4974 EXP Token Standard, optional metadata extension
+/// @dev See https://eips.ethereum.org/EIPS/EIP-4974
+///  Note: the ERC-165 identifier for this interface is 0x74793a15.
+interface IERC4974Metadata is IERC4974 {
+    /// @notice A descriptive name for the EXP in this contract.
+    function name() external view returns (string memory);
+
+    /// @notice A one-line description of the EXP in this contract.
+    function description() external view returns (string memory);
+}
+```
+
+## Rationale
+### Approval
+EXP drops SHALL require pre-approval from the delivery address. This ensures the receiver is a consenting participant in the smart contract.
+
+### Mints & Transfers
+EXP mints and transfers SHALL be at the sole discretion of the contract operator. This party may be a sports team coach or a multisig DAO wallet. We decide not to specify how governance occurs, but only *that* governance occurs. This allows for a wider range of potential use cases than optimizing for particular decision-making forms.
+
+ERC-4974 standardizes a control mechanism to allocate community recognition without encouraging financialization of that recognition or easily allowing non-contributors to acquire EXP representing contribution. While it does not ensure meritocracy, it opens the door.
+
+### Token Destruction
+EXP SHOULD allow burning tokens by contract operators. If Bob has contributed greatly to the community, but then is caught stealing from Alice, the community may decide this should lower Bob's standing and influence in the community. Again, while this does not ensure an ethical standard within the community, it opens the door.
+
+### EXP Word Choice
+EXP, or experience points, are common parlance in the video game industry and generally known among modern internet users. Allocated EXP typically confers to strength and accumulates as one progresses in a game. This serves as a fair analogy to what we aim to achieve with ERC-4974 by encouraging members of a community to have more strength in that community the more they contribute.
+
+*Alternatives Considered:  Soulbound Tokens, Soulbounds, Fungible Soulbound Tokens, Non-tradable Fungible Tokens, Non-transferrable Fungible Tokens, Karma Points, Reputation Tokens*
+
+### Participants Word Choice
+Participants have agency over their *participation* in an activity, but not over the *outcomes*. Parties to ERC-4974 contracts are not owners in the same sense as owners of ERC-20 or ERC-721 tokens. Yes, the EXP sits in their wallet, but they do not directly control any use of those tokens. 
+
+*Alternatives Considered:  members, parties, contributors, players, entrants*
+
+### ERC-165 Interface
+We chose Standard Interface Detection (ERC-165) to expose the interfaces that an ERC-4974 smart contract supports.
+
+### Privacy
+Users identified in the motivation section have a strong need to identify how much EXP a user has. 
+
+### Metadata Choices
+We have required `name` and `description` functions in the metadata extension. Name common among major token standards (namely, ERC-20 and ERC-721). We eschewed `symbol` as we do not wish them to be listed on any tickers that might tempt operators to engage in financial activities with these assets. We included a `description` function that may be helpful for games or other applications with multiple ERC-4974 tokens.
+
+We remind implementation authors that the empty string is a valid response to `name` and `description` if you protest to the usage of this mechanism. We also remind everyone that any smart contract can use the same name and symbol as your contract. How a client may determine which ERC-4974 smart contracts are well-known (canonical) is outside the scope of this standard.
+
+## Backwards Compatibility
+We have adopted `Transfer`, `balanceOf`, `totalSupply`, and `name` semantics from the ERC-20 and ERC-721 specifications. An implementation may also include a function `decimals` that returns `uint8(0)` if its goal is to be more compatible with ERC-20 while supporting this standard. However, we find it contrived to require all ERC-4974 implementations to support the `decimals` function.
+
+
+## Reference Implementation
+
+A reference implementation of this standard can be found at [../assets/EIP-4974/](../assets/EIP-4974/).
+
+## Security Considerations
+The `operator` address has total control over the allocation and transfer of tokens. Therefore, ensuring this party is secure and trustworthy is critical for the contract to function. No alternative exists if the operator is corrupted or lost.
+
+We strongly encourage `operator` to be a smart contract with robust access control features to manage EXP.
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).