limitation on number of groups in candy guard

[PratikBodawala]

I want to limit the number of mint per wallet which can be dynamic.
e.g. wallet1 has 5, wallet2 has 7, wallet3 has 10

to achieve this scenario, I have left the default guard empty and set 3 groups with the following settings.

groups

• label: 0, address gate = wallet1, mint limit = ld:0, limit 5
• label: 1, address gate = wallet2, mint limit = id:1, limit 7
• label: 2, address gate = wallet2, mint limit = id:2, limit 10

which works just fine.

the problem starts when I specify 50 groups, the length of the transaction would be ~2500 bytes, which exceeded the hard limit of 1232 bytes. and I can not do a partial update, as it needs all data to update Candy Guard.

Is there any trick that executes this transaction OR is there any other combination of guards that can achieve the above scenario

[PratikBodawala]

@lorisleiva, @febo, @sohrab-, @azerpas, Do you know something that can help me in this scenario?

[PratikBodawala]

There is one improvement, If I can group the same number of limits in one group and remove the AddressGate guard and replace it with AllowList, I can improve significantly, if I have more wallets with similar limits.

[sohrab-]

This sounds like a question for the Discord. I've seen dynamic allocation done by airdropping another NFT or SPL Token that they can burn to mint. Or off-chain validation with third-party signer.

[febo]

@PratikBodawala Unfortunately the creation and update of the Candy Guard config is limited by the transaction size. @sohrab- suggestions seem good. Another option is to create multiple Candy Guard minting from the same Candy Machine Core – the caveat is that the client code will need to know which candy guard to use depending on the user.

A long term solution would be to batch the update of the config – e.g., support updating individual groups at a time.