Skip to content

HashesDAO: Permutation Five

A simple UI to create/deploy NFT collections on existing smart contract infrastructure

David Matheson
David Matheson
4 min read
HashesDAO: Permutation Five

We’ve recently finished a major milestone for Permutation Five: a v1 dynamic user experience that allows anyone to easily create a new NFT collection on our existing smart contract infrastructure.

As a long-time UI engineer that was completely new to crypto, this was a solid opportunity to dive into learning about the Ethereum ecosystem, specifically around how smart contracts work, and the interaction between user → UI → smart contract. Through working on Permutation Five, I learned about Typechain, ABIs, Solidity basics, Solidity testing, and a wealth of info around smart contracts in general (ex: how factory contracts create other contracts, and how interoperability exists via various standards and interfaces).

New Workflow

Artists can now easily use an interface to create the settings for their collection’s mint details, kicking off the new “create flow” via a button on our “collections” page:

Afterward, artists are able to set numerous settings about their new collection:

For setting eligibility criteria, artists can choose to set a flat fee in ETH, use their own mint contract, or choose a more complex “multi-stage” allow list, which lets artists specify individual minting stages with their own granular criteria (i.e “how many mints are available and who is specifically eligible?”) based off either ETH wallet address and/or hash token ID:

Finally, artists are able to specify their own royalty percentages, the baseTokenUri to be used to serve the NFT asset, and an optional signature block address to establish provenance over the collection.

After completing the UI flow for creating a new hashes NFT collection, an artist can review all collection settings and then deploy the associated contracts to the Ethereum network with a single click:

Upon deployment success, artists will see a success message with links to their mint page (and allow list page, if applicable).

After a collection is deployed, eligible users can go to the new collection’s mint page (all collections are discoverable at and mint using their associated hash token IDs and/or ETH Wallet addresses.

For a multi-stage allow list, users have an allow list page that they may view to see the collection’s stages and its current status, which is discoverable via a link on the collection’s individual mint page.

For owners of a multi-stage allow list contract, they can connect their associated wallet and use the allow list page to set a series of settings:

  • start the minting process
  • advance their collection to the next stage (if already started)
  • pause/resume the minting process
  • edit eligible ETH wallet addresses for each stage
  • edit eligible hash token IDs for each stage
  • permanently end the minting process

Technical Details

Working on the frontend was pretty straight-forward using the existing toolchain (NextJS, React and Typescript, Typechain, Chakra-UI, and various scripts for building/generating contract types/deploying). We also created four associated smart contracts (+ their associated unit tests and deploy script) to go along with this new UI flow:

  • AllHashesEligibilityPredicate - used when creating a Hashes NFT collection (CollectionNFTCloneableV1) where all hash holders are eligible to mint.
  • DAOHashesEligibilityPredicate - used when creating a Hashes NFT collection where all DAO hash holders (token IDs 0-999) are eligible to mint.
  • StaticMintFeePredicateCloneable - a cloneable contract ​​used to provide mint fee logic upon creating a new Hashes NFT collection. This is used in the dynamic UI in the case that a user has specified a flat mint fee rather than their own mint fee contract.
  • MultiStageAllowlistCloneable - a cloneable contract used to provide individual mint stages that include their own mint fee logic and various eligibility details

The predicate contracts work in concert with the existing Hashes’ cloneable NFT collection contract (CollectionNFTCloneableV1) during the deployment flow: being deployed first, their resulting predicate contracts’ addresses are used as parameters that are then ABI encoded and deployed with a new instance of CollectionNFTCloneableV1 (aka the new NFT collection).

In the case of using a multi-stage allow list, mint fee and eligibility details will be added for each stage within a cloned instance of the MultiStageAllowlistCloneable contract, which is then deployed and its resulting contract address is then used as an ABI-encoded parameter to be deployed with the new instance of CollectionNFTCloneableV1. After a multi-stage collection is deployed, we then associate the multi-stage contract with the new collection by calling the multi-stage contract’s `setNFTAddress()` function with the deployed CollectionNFTCloneableV1 address as a parameter.

Next Steps

We’re in the process of finding artists to pilot our new user experience via creating new collections on the Hashes ecosystem, and are looking toward implementing our existing payment splitter contract within this ‘create flow’ to allow artists to specify multiple creators to be paid out automatically upon minting. If you have questions or feedback (or would like to join us!), send us a shout on Discord or Twitter. Thanks for reading!

P.S. We want to give a big THANK YOU to our friends over at PopBlocks for their work in creating the multi-stage allow list contract for this project!


Related Posts

Members Public

New Work: a community-based generative art editor

Create generative art without writing a line of code, share project links to friends and collectors.

New Work: a community-based generative art editor
Members Public

Case Study: Rebuilding the Bitly Browser Extension

Re-establishing a product's moat with technical best practices

Case Study: Rebuilding the Bitly Browser Extension
Members Public

On Merit

Experiences with the Tech mentorship platform