# Minter Suite Migration Runbook

This page provides a step-by-step guide on how to migrate a V3 Art Blocks Engine core contract from the legacy non-shared minter suite to the new shared minter suite. This migration is required for all V3 Engine contracts that want to use the new shared minter suite, which has the following benefits:

  • All minter contracts are indexed by the Art Blocks subgraph, and can therefore be configured in the new Artist Dashboard website (coming soon)
  • All minter Art Blocks Flagship minting contracts become available for use by Engine projects
  • Collectors can purchase from the same trusted contract they interact with on Flagship.
  • Art Blocks will release an SDK to simplify the minting process for Engine projects (coming soon)

Migration is not available for V2 Engine contracts; for Engine partners that wish to upgrade to a V3 Engine contract, please contact the Art Blocks team.

Migration is not required for V3 Engine contracts that wish to continue using the legacy non-shared minter suite. However, we recommend migrating to the new shared minter suite for the benefits listed above.

# Migration Steps

# 1. Engine partner frontend updated to support new minter suite

The Engine partner's frontend must be updated to support the new shared minter suite. In general, the new shared minter suite requires the following changes:

  • When specifying a project to configure or purchase from, an additional input arg of coreContract (address) must be specified. This is because one minter/minter filter contract is used for many core contracts.
  • View functions on the minter contracts may have changed slightly. This is due to some minor architectural changes to the minter contracts that we believe simplifies their codebase and make them more extensible.

The source code of all new, shared minter contracts is available on the Art Blocks smart contracts monrorepo. The complete list of all new, shared minter contracts is:

  • MinterSetPriceV5
  • MinterSetPriceERC20V5
  • MinterSetPriceMerkleV5
  • MinterSetPriceHolderV5
  • MinterSetPricePolyptychV5
  • MinterSetPricePolyptychERC20V5
  • MinterDAExpV5
  • MinterDALinV5
  • MinterDAExpHolderV5
  • MinterDALinHolderV5
  • MinterDAExpSettlementV3

# 2. Schedule downtime for any live projects

The migration process requires all artists with live projects configure a new minter. All live projects should be paused during the migration process. Switching to the new minter filter is simple, but after migrating to the new minter filter, the artist of every live project must configure their minter in the new minter suite. This is also only a few transactions, but it is fully reliant on coordinating with artists to be ready to re-configure minters of open projects after switching to the new minter filter.

# 3. Core contract admin sends migration transactions (testnet before mainnet)

The Engine partner's core contract admin should send 2 transactions to the core contract:

  1. Engine Admin calls updateRandomizerAddress on the core contract, passing in the address of the shared randomizer
Network Shared Randomizer Contract Address
Mainnet (Ethereum) 0x13178A7a8A1A9460dBE39f7eCcEbD91B31752b91
Artist Staging Sepolia 0x28f2D3805652FB5d359486dFfb7D08320D403240
Artist Staging Goerli 0xC91CFC2062D8B4Ff53A7c8836CAEf925a7C78c81
Arbitrum One 0x6a5976391E708fBf918c3786cd1FcbB88732fbc1
Artist Staging Arbitrum-Sepolia 0x28f2D3805652FB5d359486dFfb7D08320D403240
  1. Engine Admin calls updateMinterContract on the core contract, passing in the address of the shared minter filter.
Network Shared Minter Filter Contract Address
Mainnet (Ethereum) 0xa2ccfE293bc2CDD78D8166a82D1e18cD2148122b
Artist Staging Sepolia 0xa07f47c30C262adcC263A4D44595972c50e04db7
Artist Staging Goerli 0xD1d9aD8B1B520F19DFE43Cc975b9470840e8b824
Arbitrum One 0x94560abECb897f359ee1A6Ed0E922315Da11752d
Artist Staging Arbitrum-Sepolia 0xa07f47c30C262adcC263A4D44595972c50e04db7

You are now using the new shared minter suite!

# 4. Artists re-configure minters for ALL LIVE PROJECTS

AFTER step 3, artists must re-configure their minters for all live projects. This is a quick process, but requires coordination with artists to ensure they are ready to re-configure their minters after the switch.

Artists can re-configure their minters manually by following the instructions documented in the engine project launch/assigning a minter section. Additionally, soon, artists will be able to configure their project minters via the (new) Artist Dashboard.

The process for most open projects will likely be to switch to a fixed price minter.

After configuring a minter, the project is now using the new shared minter suite and live for minting!

# 5. Engine partner monitors migration progress

It is recommended that the Engine partner monitor the migration process to ensure that all artists have successfully re-configured their minters. Additionally, the Engine partner should use diligence to ensure that purchases and payment splits after the migration are working as expected.

# 6. Add any custom, one-off minters to the shared minter suite

The new shared minter suite provides all Art Blocks Flagship minters to Engine projects. However, if the Engine partner has any custom, one-off minters that they would like to use for their core contract, they can be added for their specific contract. Please see please see the Adding custom, one-off minters page for steps on how to do this.

Note that at this time, custom, one-off minters will not be indexed in the Art Blocks Subgraph or API. This is likely not a change for custom minters being used prior to migration.

# 7. Explore new minter suite features

The new shared minter suite provides all Art Blocks Flagship minters to Engine projects. Feel free to explore integrating new minters into your product!

# Migration FAQ

# What happens if an artist does not re-configure their minter?

If an artist does not re-configure their minter, their project will not be able to mint tokens. The artist will need to re-configure their minter before their project can mint tokens.

# What happens if an artist re-configures their minter incorrectly?

If an artist re-configures their minter incorrectly, best case scenario is that their project will not be able to mint tokens, and troubleshooting can identify the issue. Worst case scenario is that their project will be able to mint tokens, but the price per token will be incorrect (e.g. incorrect price entered) or the maximum invocations will be too high (e.g. forgot to set minter-max-invocations to a lower value than set on the core contract, if desired). For these reasons, artists should use diligence when re-configuring their minters.

# What happens if I migrate to the new shared minter suite?

If you migrate to the new shared minter suite, you will be able to use any new minters developed for Art Blocks Flagship. Additionally, you will be able to use the Artist Dashboard to configure your minters, because your minter suite will be indexed. You will also be able to use the new minting SDK to simplify your minting process.

# What happens if I do not migrate to the new shared minter suite?

If you do not migrate to the new shared minter suite, nothing will change, but you will miss out on new developments. You will not be able to use any new minters developed for Art Blocks Flagship. Additionally, you will not be able to use the Artist Dashboard to configure your minters, because your minter suite will not be indexed. You will need to continue to use the legacy non-shared minter suite.

# What happens if I migrate to the new shared minter suite, but I do not want to use the (coming soon) Artist Dashboard to configure my minters?

There are many reasons why a partner might want to do this!

If you migrate to the new shared minter suite, but you do not want to use the Artist Dashboard to configure your minters, you can continue to configure your minters via your frontend, etherscan, etc., but your process will be slightly updated to support the new shared minter suite. Comparing the new minter contracts and the legacy minter contracts will help you understand the changes.

# What happens if I migrate to the new shared minter suite, but I do not want to use the new (coming soon) minting SDK?

No problem!

If you migrate to the new shared minter suite, but you do not want to use the new minting SDK, you can continue to use your existing minting process, but your process will be slightly updated to support the new shared minter suite.