Add protocol sdk and minting features

[iainnash]

Add new functions to the premint-sdk and rename it to protocol-sdk.

Mint token (not premint):

(Ideally this can also handle premints but the data paths are too different for now).

const { send } = await minter.mintToken({
  address: targetContract,
  tokenId: targetTokenId,
  publicClient,
  sender: creatorAccount,
  mintArguments: {
    mintToAddress: creatorAccount,
    quantityToMint: 1,
  },
});

Create token/contract:

const new1155TokenRequest = await createNew1155Token({
  publicClient,
  contract: {
    name: "testContract",
    uri: demoContractMetadataURI,
  },
  tokenMetadataURI: demoTokenMetadataURI,
  account: creatorAccount,
  mintToCreatorCount: 1,
});

[iainnash]

Current dependencies on/for this PR:

• main
  • PR remove supply royalty deprecation test #342
    • PR Protocol SDK #348
      • PR Moved some premint-sdk files to protocol-sdk #349
      • PR Add protocol sdk and minting features #322 👈
        • PR Example of returning prepared tx from mint client #334
          • PR Rename some params for better understanding what they mean #335
        • PR Adding automated anvil testing client creation. #324
    • PR Move deployment related config to protocol-deployments #339
      • PR Deploy 2.4.0 #340
        • PR Upgrade simulation and call data generation fork tests #369

This stack of pull requests is managed by Graphite.

[oveddan]

this is more around creating an 1155 using the fixed priced minter. do we want to have it's name to reflect that? cause this naming implies that this is the only way to create an 1155 token

[oveddan]

this function only works for contracts created via determinstic contract addresses, i.e. premint.

[iainnash]

We're only using this for when people don't pass in a contract address. I'll document it.

[oveddan]

i think it may be cleaner to just break this into two functions:

const getDeterminsticContractExists({contractConfig})

const getContractExists({address})

[oveddan]

id avoid having this base class just for holding the chain and network config. how about just having the subclasses contain these objects and have utility functions to extract whats needed from both objects?

inheritance can be kind of hard to follow, and id be concerned that more stuff gets thrown in here than is needed.

[oveddan]

fine resolving this in a future PR (to get this out)

[iainnash]

The main reason I have things setup this way is the ease to override a network client without adding a ton of parameters.