👾
Items
Why Is the Item Standard Needed?
Token Interoperability Across All of Ethereum
All Items—native and wrapped—are naturally interoperable with all applications on Ethereum. And by allowing any ERC20, ERC721 or ERC1155 to be wrapped as an Item, the protocol also serves as a bridge for all of Ethereum to cross over and enjoy the capabilities of the standard.
This allows for the possibility of projects and applications that aren’t limited to any one realm of Ethereum. Instead of having just a DeFi DApp or just an NFT DApp, for example, you can have a DApp that is native to both the DeFi and NFT realms.
You can pool the same token on Uniswap, list it on OpenSea, use it to govern a DAO, and so on…
Inter-Collection Batching and Sophisticated Operations
With batch operations, the ERC1155 standard brought a new level off efficiency and sophistication to Ethereum tokens.
The Item standard pushes things even further, allowing you to use more tokens, in more ways, often spending less gas, and wasting less time.
First of all, it allows you to batch operate with not only multiple ERC1155s in one transaction, but in fact all Ethereum tokens in existence. This is made possible with v2 of the protocol because you can not only wrap all ERC20s, ERC721s and ERC1155s, but batch all Items of all Collections at once.
For example, you could transfer, in a single transaction, 10 Items of Collection 1, 73 of Collection 2, 15 Item-wrapped ETH and 2 Item-wrapped CryptoPunks.
In the future, when new Extension models will be released and available through the Extension Factory, it will be possible to allow for more than this. Not only you will use it to batch any and all Ethereum tokens together, but you will also do so using multiple operations at once; you will be able to perform several batch burns and a batch transfers all in a single transaction.
So, you could batch transfer 5 Items in C1, batch burn 100 Items of C2 and batch transfer 20 Item-wrapped CryptoPunks all in a single transaction.
And the core of the Item standard is coded to take batching even further, with a function called ‘batch-single'. This will allow you to do as above, but with mint operations too, as well as multiple sender, receiver and operator addresses.
So, as an example, you'll be able to: mint 1000 Items of C1; transfer them to 1000 different receiver addresses (with each receiving 1); and (just for kicks) send, from another address, 1 Item-wrapped CryptoPunk to ten different receiver addresses (wrapping an ERC721 NFT allows you to fractionalize it; each receives 0.1 CryptoPunk).
All of this in a single transaction, again saving significant gas in the process. This will become available with future versions of the Factory Extensions that are discussed below.
Granular Permissions for Collections
Using the Extension (MultiOperatorHost), you can create a Collection of Items that is governed by one or two different Operator addresses. One can govern its itemId and Item minting permissions, and the other can govern the modification of the metadata of it and its Items.
These operators can be smart contracts, which means you build an entire application on top of an Item Collection, or design a Collection in such a way that it becomes an important architectural wing of one. For example, you could have creation / minting permissions governed by a subDAO that is ruled by a governance token. Then you could have the metadata modification permission governed by a different subDAO altogether. Overall, this would set you up with a decentralized, multi-token, multi-layer governance system for your Collection; this could be incorporated into an NFT art DAO, or a blockchain game...
Upgradable Protocol
An Extension can be cloned via the Extension Factory and then linked to a Collection. In the future, the EthereansOS Organization can upgrade the Factory with new models that can be used in the same way. These future models will make it possible to introduce new features and granulate the permission system further.
This means that the Item protocol can be upgraded via the Factory system without having to rewrite new code from scratch and deploy new cores each time.
Dynamic Metadata
As things are, most metadata on Ethereum is stored in the off-chain, centralized databases of paid services like Google Storage and Trust Wallet, or distributed ones like IPFS, represented by tokens and applications in the form of addresses saved as on-chain uri parameters.
That doesn’t measure up to the security standards of Ethereum. When those services cease to be operational or available, that metadata is gone. For NFTs in particular, that will be tantamount to the complete loss of their value.
Metadata must be always on-chain, decentralized, and censorship-resistant. But that's not all.
A year after v1 of the Items protocol first brought fully on-chain data to Ethereum, others in the industry are beginning to follow suit, such as CryptoPunks, and Uniswap with their NFT LPs.
While this is great, there are some major limitations to their implementations, which are just static, single-purpose verticalizations.
The Dynamic on-chain Metadata protocol differs in that it is the first fully decentralized, fully-fledged protocol for anyone to easily use and manage on-chain metadata for their tokens.
Developers can use it code their metadata engine smart contracts according to their needs. Using an Extension, they can granulate the way their Item Collections are governed via multi-layered permission systems.
Last modified 2mo ago