Basic crafting factory pattern for discussion.

[alex-connolly]

Our currently recommended approach for games building crafting mechanics is:

• Deploy your own version of the GuardedMulticaller contract
• Wait for Immutable to add your GMC implementation to the operator allowlist

There are a few problems with this approach:

• It requires us to constantly update the operator allowlist, delaying customer implementations
• It requires all customers to deploy separate contracts, even to implement basic crafting mechanics
• Once the user approves the GMC contract, the game can transfer all assets from the user, with no additional signing (though this is similar to the risk posed by our current implementation of Instant Signing)
• It is challenging for Passport to recognise these transactions as crafting (as GMC can be used for multiple purposes).
• We don't support any on-chain logic as part of games' crafting mechanics (e.g. on-chain randomness)
• We can't support atomic user-initiated and admin-only interactions (e.g. burning assets, then minting an asset). TODO: is this true?

Here's a new design: the CraftingFactory.

• Only one central contract deployed by Immutable - the only contract we need to add to the operator allowlist
• Games can implement whatever logic they want for crafting via smart contract hooks to customer-defined Recipe contracts, including admin actions
• Customers can use pre-built Recipe contracts for common crafting patterns to avoid writing any smart contract code themselves. This could later be wrapped further in a Crafting API or similar.
• All transactions are transparent to Passport

[openzeppelin-code]

Basic crafting factory pattern for discussion.

Generated at commit: cd1cf2630fae33ba00f0946f0f744547235d556c

🚨 Report Summary

	Severity Level	Results
Contracts	Critical High Medium Low Note Total	1 0 0 12 34 47
Dependencies	Critical High Medium Low Note Total	0 0 0 1 68 69

---

For more details view the full report in OpenZeppelin Code Inspector

[drinkcoffee]

@alex-connolly , my understanding is that the user would need to ERC20 approve / ERC 721 approve / ERC 1155 approve the CraftingFactory contract. Would a security issue be that the user would approve the contract in the context of one game, and then another game could use the approval to do something that the user didn't authorise?

[alex-connolly]

@alex-connolly , my understanding is that the user would need to ERC20 approve / ERC 721 approve / ERC 1155 approve the CraftingFactory contract. Would a security issue be that the user would approve the contract in the context of one game, and then another game could use the approval to do something that the user didn't authorise?

We use msg.sender directly for all the ERC20/ERC721/ERC1155 interactions, so the user themselves needs to be the initiator of the transaction and therefore aware of all the inputs/outputs/recipe they're using.

If we didn't want this restriction, we could try:

• Requiring the user to provide per-recipe approval to be validated by the contract
• Requiring the user to provide a signature of the inputs, outputs and recipe

But I don't think it's necessary given the use of msg.sender rather than a user-provided from address?

[alex-connolly]

We also need to put in some restrictions to make sure people can't use the flexibility of Recipes to create trading contracts that work around our fees.