feat(foundation): add support for ERC1155 mints

[mmackz]

Refactors the foundation plugin to add support for ERC-1155 mints.

Notes

For 1155 tokens, this implementation requires a tokenId or it will throw an error. Normally we target the initial tokenId in the collection, but this does not work here because the tokenIds are not sequential and can be any random number.

Here are the relative contracts:

• Implementation Contract: https://basescan.org/address/0x6d3e140383606af80b64ec1ee91ed4014ba86d34#code
• Minter: https://basescan.org/address/0x132363a3bbf47e06cf642dd18e9173e364546c99 (all base mints happen here)
• Collection: https://basescan.org/token/0xddcbe62d10dbee8492610fd1b4964403a0e087aa

[changeset-bot]

🦋 Changeset detected

Latest commit: 5cf124d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
@rabbitholegg/questdk-plugin-foundation	Minor
@rabbitholegg/questdk-plugin-registry	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[Quazia]

This looks good - but as the code exists it's going to cause issues with the way the backend implements fees.

Here's where it gets the fees

That value then gets saved into the quest object in the DB

Reading through this code the Dutch Auction fees are going to change, so the front-end embedded mint is going to need to look up the fees pre-flight, not rely on the cached values. Potentially requires backend and front-end changes to support the dynamic fees.

[Quazia]

This might actually be worth putting in utils - seems useful for most simulations

[mmackz]

This looks good - but as the code exists it's going to cause issues with the way the backend implements fees.

Here's where it gets the fees

That value then gets saved into the quest object in the DB

Reading through this code the Dutch Auction fees are going to change, so the front-end embedded mint is going to need to look up the fees pre-flight, not rely on the cached values. Potentially requires backend and front-end changes to support the dynamic fees.

Thankfully the dutch auction fee type is very rarely used. Good callout, the fees will definitely increase after a few mints are made.

What is the best way to deal with this in the short term? Should we just throw an error and prevent people from launching boosts with dutch auction?

[Quazia]

I'd say prevent it for now until we can modify it in the front-end and back-end if it's not used high frequency.