Each deployed shell collection manages various key-value stores that can be read and written by the currently installed engines.
This can be used to persist data across engine installs or application-level forks.
Overview
Storage in shell is a set of key-value stores for strings and ints (uint256). The key value stores are maintained within the collection contract deployed from the factory, not within the engine contracts. This separation ensures:
- Storage behavior can be enforced at the framework level and not abused by malicious engines.
- Data can be persisted in a simple and standard way across engine upgrades and hot-swaps.
- Data is persisted across forks, and any fork’s storage can be read (but not written) by any other fork
Token Storage
Data can be written to the NFT’s token storage by the engine running on the fork the NFT belongs to, or by the shell framework during minting:
- Mint Data - Immutable data associated with a specific token ID that is written during token minting by the installed engine on the root fork. Cannot be tampered with or modified.
- Framework Data - Immutable data associated with a specific token ID that can be written during token minting by the shell framework (such as timestamp and block height). Cannot be tampered with or modified.
- Engine Storage - Data associated with a specific token ID that can be modified at any time by the engine installed on the fork the token belongs to
Fork Storage
Each fork has its own siloed fork storage that can only be written to by the engine currently installed on the fork. Fork storage from other forks can be read at any time.
- Engine Storage - Data associated with an entire collection that can be modified at any time by the engine installed on the fork.