metaplex-foundation/mpl-candy-guard

Access control logic for Metaplex Candy Machine.

Metaplex Candy Guard

The Candy Guard program and its generated Solita library are now part of a separate mpl-candy-machine repository which contains all programs and clients related to Candy Machine V3.

Here are some useful links for you to find what you came here for:

• Repository: 📂 MPL Candy Machine
• Program documentation: 📄 Readme
• Solita SDK: 📦 NPM

mpl-candy-guard's Issues

Decouple payer in allow_list guard

The current implementation of the allowList guard uses the payer for validating against the merkle tree by default:

mpl-candy-guard/program/src/guards/allow_list.rs

Line 79 in 3e4a878

let user = ctx.accounts.payer.key();

Meaning, when calling the proof guard route and when minting with an active allow list the payer must be the one on the allow list. Enforcing the feePayer to be allow listed creates some pain points in our flow, mainly being:

1. It is not possible anymore to use an empty wallet for minting with an active allow list, forcing us to pre-fund empty custodial wallets
2. Complicating the minting flow by making us use hacky workarounds such as transferring SOL since we can't specify a treasury as feePayer anymore

Being able to specify a feePayer which is not on the allow list and instead validating another entity such as the mint authority would clean up the flow for our use-case immensely and elevate failure points, allowing us to more easily integrate clients asking for this feature.

Create payment guards

Move the payment logic from the candy machine to a guard. This will result in the creation of two new guards:

• NativePriceGuard that accepts payment in SOL
• SPLTokenPriceGuard that accepts payment in any spl-token

The CandyGuard PDA will be the signer (and needs to be the authority of the candy machine) of the CPI instruction – a candy machine behind a guard can only be minted by the authority.

Refactor anchor tests

Improve anchor tests by reusing code

Move tx pre-instructions to CPI calls

Currently the mint instruction requires a set of pre-instructions related to the allocation and initialization of accounts. We should move this instructions to CPI calls to save tx space.

Separate the logic of validation + actions on a guard

In order to avoid side-effects when a guard fails validation and bot tax is used, we need to separate the logic of validating a guard and the changes that a guard performs.

For example, the whitelist guard validates whether the user is a whitelist or not and then burns the whitelist token. A guard that happens after the whitelist might fail, triggering a bot tax. In this scenario, the whitelist token will be burned although no NFT was minted.

The suggested approach is to create a new function on the guard Condition trait, so the logic of a guard will be implemented as:

• evaluate: validates the guard logic
• actions: perform required actions before the CPI mint instruction (e.g., burning whitelist token, taking payment)

On a first step, all guards will be evaluated. Once the evaluating is successful, all actions from the guards are performed and the mint CPI is called.