Shared, Upgradable and Backward-Compatible Standards
Non-standard ERC implementations are a nightmare for dApp developers. The most popular example is USDT, valued at more than $17B. Just to be able to manage USDT, dApps are forced to hardcode their Smart Contracts with customized implementations.
ITEMs, however, all share the same standard methods. It is in fact impossible for them not to. Using ITEMs, dApp developers can finally work together on building amazing things without having to deal with broken ERC20s, non-standard interpretations of ERC1155, and so on…
The ITEM standard can also be upgraded via the ETHITEM DFO to new versions that incorporate new standards alongside the evolution of the Ethereum Ecosystem. But anytime the EthITEM DFO does upgrade the factory contract, this doesn’t automatically upgrade ITEMs of an older version. It enables ITEMs to upgrade themselves, and allows them to easily switch back and forth between old and new versions.
The Version model is a LEGO from one “Starter” Version, one Main Interface version and one Interoperable Interface version.
For “The Starter” there are 4 types: Native, Wrapped ERC20, Wrapped ERC721, Wrapped ERC1155. The Main Interface and the Interoperable Interface are just two separate types. Basically like this:
The versions are expressed in this simple way:
[Starter indicator_] - [Interoperable Interface Version] - [Main Interface Version] - [Starter Implementation]
Native ITEM:
Native_1.1.1 (Created by the Native Starter, Version 1, Main Interface Version 1 and Interoperable Interface Version 1)
ERC721 Wrapped:
W721_1.3.6 (Created by the Wrapper ERC721 Starter Version 6, Main Interface Version 1 and Interoperable Interface Version 3)
ERC1155 Wrapped:
W1155_2.4.9 (Created by the Wrapper ERC1155 Starter Version 9, Main Interface Version 2 and Interoperable Interface Version 4)
ERC20 Wrapped:
W20_1.1.1 (Created by the Wrapper ERC20 Starter Version 1, Main Interface Version 1 and Interoperable Interface Version 1)
//The version number of the EthItem Main Interface implemented by this Collection
var mainInterfaceVersion = await collection.contract.methods.mainInterfaceVersion().call();
//The version number of the EthItem Interoperable Interface model containing the code of every Item of this Collection;
var interoperableInterfaceModelVersion = (await collection.contract.methods.interoperableInterfaceModel().call())[1];
//The address of the Collection created by the Factory
var modelVersion = await collection.contract.methods.modelVersion().call();
//So every Collection cumulative version can be expressed in a way similar to this
var collectionVersion = `${category}_${mainInterfaceVersion}.${interoperableInterfaceModelVersion}.${modelVersion}`;
Example: W721_1.5.3 means that the Collection is an ERC721 Wrapper one, based on the first version of the EthItem Token Standard Interface. All its Items implement the Interoperable Interface model v5 and it has been created following the ERC721Wrapper v3 Collection Model.
Thanks to the event architecture, this structure helps dApps call specific ITEMs based not just on the type (native, wrapped) but also on the versions they trust.
For example, if v0.3 of the Main Interface has any bugs or functionalities that a dApp doesn't support, or which are in some way malicious, the dApp can just call items from all of the versions aside from this specific one.
Last modified 2yr ago