EIP-5646: Require only mutable state properties to be included in the…

… state fingerprint (#6095)

* Add EIP-5646: Token state fingerprint

* Update EIP-5646: add link to discussion

* Update EIP-5646: reference ERC standards as EIP-N

* Update EIP-5646: update all EIP references to links

* Update EIP-5646: fix incorrect EIP references

* Update EIP-5646: Rework the structure of the whole draft

* EIP-5646: Use mutable tokens instead of derivative tokens in spec

* EIP-5646: Require only mutable state properties to be inlcuded in state fingerprint

EIPS/eip-5646.md

@@ -13,7 +13,7 @@ requires: 165
 
 ## Abstract
 
-This specification defines the minimum interface required to unambiguously identify the state of a derivative token without knowledge of implementation details.
+This specification defines the minimum interface required to unambiguously identify the state of a mutable token without knowledge of implementation details.
 
 ## Motivation
 
@@ -40,17 +40,19 @@ interface ERC5646 is ERC165 {
 
 - `getStateFingerprint` MUST return a different value when the token state changes.
 - `getStateFingerprint` MUST NOT return a different value when the token state remains the same.
-- `getStateFingerprint` MUST factor in all parameters that might change the state of a token.
+- `getStateFingerprint` MUST include all state properties that might change during the token lifecycle (are not immutable).
 - `getStateFingerprint` MAY include computed values, such as values based on a current timestamp (e.g., expiration, maturity).
 - `getStateFingerprint` MAY include token metadata URI.
 - `supportsInterface(0xf5112315)` MUST return `true`.
 
 ## Rationale
 
-Protocols can use state fingerprints as a part of a token identifier and support derivative tokens without knowing any state implementation details.
+Protocols can use state fingerprints as a part of a token identifier and support mutable tokens without knowing any state implementation details.
 
 ![](../assets/eip-5646/support-per-eip.png)
 
+State fingerprints don't have to factor in state properties that are immutable, because they can be safely identified by a token id. 
+
 This standard is not for use cases where token state property knowledge is required, as these cases cannot escape the bottleneck problem described earlier.
 
 ## Backwards Compatibility
@@ -62,8 +64,8 @@ This EIP is not introducing any backward incompatibilities.
 ```solidity
 pragma solidity ^0.8.0;
 
-/// @title Example of a token with computed state fingerprint.
-contract LPTokenComputed is ERC721, ERC5646 {
+/// @title Example of a mutable token implementing state fingerprint.
+contract LPToken is ERC721, ERC5646 {
 
     /// @dev Stored token states (token id => state).
     mapping (uint256 => State) internal states;
@@ -73,8 +75,8 @@ contract LPTokenComputed is ERC721, ERC5646 {
         address asset2;
         uint256 amount1;
         uint256 amount2;
-        uint256 fee;
-        address operator;
+        uint256 fee; // Immutable
+        address operator; // Immutable
         uint256 expiration; // Parameter dependent on a block.timestamp
     }
 
@@ -91,9 +93,9 @@ contract LPTokenComputed is ERC721, ERC5646 {
                 state.asset2,
                 state.amount1,
                 state.amount2,
-                state.fee,
-                state.operator,
-                block.timestamp < state.expiration ? false : true
+                // state.fee don't need to be part of the fingerprint computation as it is immutable
+                // state.operator don't need to be part of the fingerprint computation as it is immutable
+                block.timestamp >= state.expiration
             )
         );
     }
@@ -110,7 +112,7 @@ contract LPTokenComputed is ERC721, ERC5646 {
 
 Token state fingerprints from two different contracts may collide. Because of that, they should be compared only in the context of one token contract.
 
-If the `getStateFingerprint` implementation does not include all parameters that could change the token state, a token owner would be able to change the token state without invalidating the token identifier. It could break the trustless assumptions of several protocols, which create, e.g., buy offers for tokens. The token owner would be potentially able to decrease the value of a derivative token before accepting an offer.
+If the `getStateFingerprint` implementation does not include all parameters that could change the token state, a token owner would be able to change the token state without changing the token fingerprint. It could break the trustless assumptions of several protocols, which create, e.g., buy offers for tokens. The token owner would be able to change the state of the token before accepting an offer.
 
 ## Copyright