An introduction to the PRISM Smart Contracts
The first wave of NFT projects is past us and it is time to explore more advanced concepts for enabling creative endeavours. PRISM is our take on re-envisioning collaboration among artists, fans and communities at large.
Everything is a remix
Have you ever wondered why music from a certain time period sounds so similar? Have you ever heard a new song and thought, “damn, that sounds familiar!” Well, it might actually be familiar!
Human creativity is largely based on taking existing ideas and topics, remixing them and generating new creations along the way. Kirby Ferguson’s epic short film “Everything is a remix” displayed in an entertaining and educating manner how remixing existing works into new outputs has been the foundation of art for generations.
However, historically remixing had its troubles. Major reasons have been the in-transparency surrounding derived artworks and the lack of credit toward original artists. Often, those troubles were only resolved via the legal system.
Composa….What?
As outlined by Malte in his recent article on Media Composability and NFTs, blockchains have created new opportunities to enable programmatic traceability for derivatives. It will enable artists to easily declare whose artwork they remixed. Additionally, revenue stream splitting from layered artworks can be built in. In short, artworks become composable. Layers can be added or subtracted from existing artworks, enabling artists to add their own spin to the creation. This is PRISM.
All fun and games but how does it work?
Let’s have a look at the PRISM ERC-1155 together. Prism is split into two contracts:
- The Prism Project Contract: Enable artists and collaborators to administer their projects.
- The Prism Token Contract: Contract where the (ERC1155 Token) magic happens.
In the Prism Projects Contract, we have 2 objects: Projects and Collections. Projects are created by the ominous ProjectChef. They can create many different collections in their projects. For each collection, a contributor is put in charge. This might be an artist the project chef wants to work with.
Within a collection, a collaborator can create different tokens. The quantity is dependent on how many tokens the project chef defines when creating the collection. This way, the Project Chef remains in charge of the project.
On the projects also the layerTypes get defined. Those are the different categories that a layer might belong to fall under. LayerTypes might be armour, head, body, background etc. This enables collaborators and users to create token batches to distribute which are different in kind. As a user, I am interested in having one token of each instead of 10 armours when minting layers.
/**
@dev structs
*/
struct Project {
uint256 id;
string name;
address chef
string[] layerTypes;
}struct Collection {
string name;
uint256 id;
uint256 projectId;
uint256 royalties; // in 1000th e.g. 1000 for 10%
address manager; // gets royalties
uint256 invocations;
uint256 maxInvocations;
AssetType assetType;
bool paused;
}
The Prism Project Token is an ERC1155 and holds all Tokens within a collection are created in this contract. We differentiate between different AssetTypes such as Layer Tokens and Canvas Tokens. Depending on their AssetType Tokens behave differently.
Before we can mint a Token, we create the token via the createToken() function. This function enables us to configure the token before we start minting it. This enables us to specify different Token settings such as AssetType , ImageCID , MaxSupply , etc. Given that Tokens in ERC1155 can have a quantity > 1 we are able to now mint the specified token partly or completely via the mintTo() function.
/**
@dev structs
*/
struct Project {
uint256 id;
string name;
address chef
string[] layerTypes;
}struct Collection {
string name;
uint256 id;
uint256 projectId;
uint256 royalties; // in 1000th e.g. 1000 for 10%
address manager; // gets royalties
uint256 invocations;
uint256 maxInvocations;
AssetType assetType;
bool paused;
}
Let’s have a look at the different AssetTypes. Layer Tokens are pretty straight forward they represent the different layers of any artwork. The tokenURI leads to the metadata and a visual (e.g. png).
Layer Tokens might be non- or semi-fungible, creating different rarities. For example, a golden armour might exist 5 times while a flying ninja star exists 20 times. Users are able to equip and, therefore, combine the layer they own. The recombination of layers lead to unique Canvases.
Canvas Tokens are the object that Layers Tokens get equipped to. To equip a Layer Token, the Layer and the Canvas must be owned by the person equipping it. Canvas Tokens each have a unique tokenID enabling us to identify which tokens are connected to which Canvas.
To equip and un-equip NFTs of a canvas you just enter the tokenID of the canvas and the layers you want to equip. All previous layers get removed and the new layers get added. To make this transparent on-chain, we emit a CanvasEdit event. DApps can listen to the event to load the new visual of the CanvasNFT.
To summarise: Splitting the different Tokens by AssetTypes enables us to have different categories of Tokens in the same contract. This way we enable the specified interactions between the Canvas and Layer relationship.
Alright, that was a lot! If you are interested in learning more about the contracts, jump into our code base or reach out to me anytime. We are interested incollaborating with others on this to build out further use-cases.
Best, Clepp
