Since, apparently, this isn’t an EIP yet?!
Would you mind adding a bit to the Rationale section about why exists needs to *ahem* exist at all?
Sure. The answer is simple: backward compatibility.
Does this support “backward compatibility,” though?
I presume this to mean consistency in existing ecosystem standards?
For example, Etherscan total supply would still be broken provided this implementation: Please (PLEAS) Token Tracker | PolygonScan and an individual token page does not even show supply (because it has not been standardized, obviously) Please (PLEAS) Token Tracker | PolygonScan.
Is the definition of this EIP accepting that the “enabled” functionality will have little result on the state of 1155s and that existing support for “Supply” extensions will still be non-functional at the collection level?
1 Like
The backwards compatibility section should reference ERC-20 and ERC-721. Clearly this function is modeled off the expectations set by those two specifications and ecosystem.
The backwards compatibility section should reference ERC-20 and ERC-721.
This is not backward compatible with EIP-20 or EIP-721. It is implicitly compatible with EIP-1155, as it is an extension.
Clearly this function is modeled off the expectations set by those two specifications and ecosystem.
This is true, and I will add a variation of this in the rationale.
It’s backward compatible with the most commonly used/widely supported supply extension; the OpenZeppelin one.
Relevant links:
Copying this from another thread:
OpenSea supports both of these functions. This is undocumented but is clear from their example repository. It’s also noted in the first thread I just linked to. I don’t know whether to mention this or not. I’m leaning slightly towards no (it’s undocumented!) but my mind can be easily changed on this.
OpenZeppelin, of course, has an implementation of this, as noted in the EIP itself.
I don’t see an easy way to track support for this for deployed contracts.
We’re trying a new process where we get a volunteer peer reviewer to read through your proposal and post any feedback here. Your peer reviewer is @dadybayo!
@dadybayo please take a look through EIP-5615 and comment here with any feedback or questions. Thanks!
One challenge I can think of with this EIP is: In order to have exists() work in some implementations, it may require adding additional counters in the implementation, leading to a higher gas usage.
I guess this could be fixed by making that function optional. It doesn’t seem fully necessary (even if it’s very useful).
In this EIP spec, it states that in totalSupply() that This MUST revert if exists(id) returns false.
It might be not ideal to revert, as it is possible that a function would want to check if totalSupply(some id) = 0. Instead of requiring a revert in totalSupply() if exists() equals false, it should just return 0 and let the respective functions that rely on totalSupply() handle the logic instead. This is the behavior in the existing OpenZeppelin contract.
This seems reasonable for backward compatibility. I’ll make that change.