Understanding Artblocks V0 Contract

Tom Terado
5 min readJun 24, 2022

Generative art is something I have always been fascinated by. Self-expression to create art with randomness and algorithms. The more I learn about it, I am drawn to the intersection of web3 and generative art which led me to Artblocks. It also occurred that a life goal of mine is to own a Fidenza ^_^

Listening to Erick Snowfro’s story (founder of Artblocks) was very interesting. He went from Cryptopunk enthusiast to wanting to recreate the experience so he learned Solidity to make it happen. Then did an invite system to onboard artists one by one to create an authentic experience.


The platform now attracts some of the greatest artists and provides them with a platform to showcase the power of generative art. Recently they open-sourced their contracts so was interested to see how it works. I break down their V0 contract and how the minting, projects, scripts, and general framework of the contract work.

Resources on Artblocks

The aim purpose is to understand this contract so I can eventually reverse engineer it.

Used a tool called Stately Registry to map this out. It outputs a map, JSON data representing the structure, and a preview link. All work is also pointed to my Github.

GenArt721 (V0)

This was the original contract that was deployed and created with Solidity 0.5.0^. I have only used > 0.6.0 so it was interesting to see the ERC165 constructor.

Broke it down into:

  • Libraries
  • Interfaces
  • Supporting Contracts
  • GenArt721 Contract
  • Events
  • Structs
  • Mappings
  • Constructor
  • Modifiers
  • Functions (the main part)


An invocation event that references the address _to, token_id, project_id, _invocations, and _value for the specific user and the project they interfaced with


Quite a lot of data types that hold strings, addresses, and uint’ regarding the project, IPFS hashes, script, and description of the project.


Mapping defaults with the Project which is standard for the indexing and the other ones are related to the project id and referencing.


To make the contract more modular, these are primarily used to function for the


Takes two specific parameters (_tokenName, _tokenSymbol) through the CustomERC721Metadata support contract which registers the two variables and returns a string.


The main part of the GenArt721 contract. In order to best understand it, decided to split them into several categories

  • Financial functions
  • Project + script functions
  • View functions

Financial functions

This one primarily focuses on the minting of the piece by the user. It is a combination of logic with purchase, purchaseTo, splitFunds and _mintToken.

By hierarchy, the top to bottom level interaction is:

  1. Purchase
  2. purchaseTo
  3. _mintToken
  4. splitFunds

Purchase: Takes in the selected _projectId and calls purchaseTo

Purchase_to: Checks if user is able to purchase it. The main parameter is that the project must already be invocated/initialized via addProject which allows for the _mintToken and _splitFunds to be invoked

MintToken: Adds invocation to the projectId, then converts the tokenId to a hash which interfaces with the standard IERC721 _mint function. Relevant mapping is then called alongside the Mint event.

SplitFunds: An additional function to split the total funds sent to projectFund, Artblocks foundation and optional refunds, additionalPayeeAmount, and creatorFunds.

Project functions

Primary project function: addProject

These are related functions to the Project and Artist with the metadata and IPFS hosting urls. The two primary ones were:

addProject: As referencing in purchase_to, this could be seen as an initializer function as it allows the project and artist to create the piece.

addProjectScript: This is an important function that allows the ‘script’ to run through and generate the minting piece. It is a string so would imagine it is quite a long JSON as seen in the Project struct scriptJSON. How big this will be is a question

The rest of the functions here would be updater/modifier functions that would change or remove details that need to be amended.

View Functions.

These view and return functions serve a purpose to check if the data has been added correctly or if they need amending.

The general flow I understood was:

  1. Deploy/initialize the contract
  2. addProject
  3. addScript
  4. Check other variables are working with the view call functions
  5. ‘Mint’ which calls the other “financial’ functions

This was a general overview of the flow of the V0 contract and the origins of a platform that has grown to be the standard for Generative Artists using the Blockchain. Look forward to diving deeper into their newer contracts. Would also be interested to create a full-stack Proof of Concept on Artblocks.

Their contract repo can be found here and Artblocks Website