Why Have the Extension?

Granular Permission System

As outlined on the previous page, extensions make possible dynamic permission systems for Collections, allowing multiple operators to manage different features.

This design also secures users from shady Collection hosts from abusing their power and performing malicious operations.

[i] While there are few permission levels in the current Extension system, new versions may introduce more in the future.

Dedicated ERC1155 Collection Address

As discussed elsewhere, all Collections are linked to the Main Interface singleton contract, wherein they are stored virtually as their collectionIds.

This means they share the Main Interface as their collective ERC1155 interface.

However, if you link a Native extension with your Collection, it becomes your Collection’s unique ERC1155 interface; i.e, an additional ERC1155 interface that is separate to the Main Interface. It acts as a ‘projection’ of your Collection, implementing the IERC1155 interface.

This can be very useful because it allows a developer to integrate a specific Collection with his application at a time.

For example, imagine a videogame, where for gaming logic can be useful to be able to easily mint or transfer only Items of that specific collection using the Extension (while maintaining the ability to use all the power of the Main Interface to users).

To keep things synced, an extension writes directly onto the Main Interface whenever functions of the extension are called.

MultiOperatorHost Extension doesn't have this capability.

Batch-Operable With All Other Items

Even if a Collection has an Extension, it is still stored in the Main Interface as its virtualized collectionId, along with all other Collections, stored as their collectionIds. This is a significant change from v1 of the Items protocol, in which Collections were entirely separate contracts from the Main Interface.

One of the cooler things this allows for is cross-Collection batch operations. Users can perform batch transfer or batch burn operations using Items of different Collection at once.

Integration With External dApps

Another valuable use case for the Extension regards the integration with external Dapps when an Item needs to interact with an ERC1155-based protocol or application.

For example, if you want to list your Items on Opensea, you must pass Opensea the ERC1155 address. If you don't have an Extension linked to your Collection, while you have to pass the Main Interface contract, you can pass the Extension address if you have an Extension contract linked to your Collection.

In the first case, you'll see your Items as a part of the Main Interface singleton Collection together with all the other existing Items of the Main Interface. In the second case, you'll see only the Items of your specific Collection represented by the Extension contract.