Summary
@SamWilsn There’s a bit of discussion on this in the PR. Essentially, we’re questioning how much new terminology needs to be introduced, particularly for token transfers and approval/participation. I’m on the fence about it.
(See below for side-by-side comparisons.)
Transfer
The first iteration implemented transfer for minting and transferFrom for reallocating and burning. I was trying to align with ERC-20 and ERC-721. Here’s the previous definition:
`
/// @notice Transfers EXP from zero address to a participant.
/// @dev MUST throw unless msg.sender is operator.
/// MUST throw unless _to address is participating.
function transfer(address _to, uint256 _amount) external;
/// @notice Reallocates EXP from one address to another, or burns to zero address.
/// @dev MUST throw unless msg.sender is operator.
/// MUST throw unless _to address is participating.
/// MAY throw if _from address is NOT participating.
function transferFrom(address _from, address _to, uint256 _amount) external;
And the mint, burn, allocate iteration:
`
/// @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;
Participation
This is a similar issue to using the language of “approval” versus “participation”, here’s a definition that would be aligned with ERC-721:
/// @dev This emits when operator is enabled or disabled for a participant.
/// The operator can manage all EXP of the participant.
event ApprovalForAll(address indexed _participant, address indexed _operator, bool _approved);
/// @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 Approval status of _participant.
function approveForAll(address _participant, bool _approved) external;
And the “participation” iteration:
/// 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 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;
My Perspective
There are several reasons to be for or against this new terminology:
- Good – More intuitive for EXP use cases, and perhaps more intuitive generally.
- Bad – Less aligned with existing token standards.
- Bad – Introduces new names.
My gut says EXP use cases are not sufficiently different to require new naming conventions, but I’m open to being convinced and will somewhat accede to folks who have a longer history with the ETH ecosystem.
. My point is, you can specify all the rules you want, the nature of smart contracts being self-sovereign and EIPs simply being agreed-on guidelines means they aren’t really too useful for preventing abuse. If someone creates a token meant to harm people, clients with filters tend to hide them pretty quick, regardless of what EIPs they follow. I’m not sure this adds enough to warrant an EIP, for that reason.