Overview of a Core Candy Machine

Introduction

By September 2022, 78% of all NFTs in Solana were minted through Metaplex’s Candy Machine. This includes most of the well known NFT projects in the Solana ecosystem. Come 2024 Metaplex introduced the Core prototcol which redefines NFTs on Solana and with it a new Candy Machine to accomendate the same minting mechanics users loved for the Core standard.

Here are some of the features it offers.

• Accept payments in SOL, NFTs or any Solana token.
• Restrict your launch via start/end dates, mint limits, third party signers, etc.
• Protect your launch against bots via configurable bot taxes and gatekeepers like Captchas.
• Restrict minting to specific Asset/NFT/Token holders or to a curated list of wallets.
• Create multiple minting groups with different sets of rules.
• Reveal your Assets after the launch whilst allowing your users to verify that information.
• And so much more!

Interested? Let’s give you a little tour of how Core Candy Machines work!

The Lifecycle of a Core Candy Machine

The very first step is for the creator to create a new Core Candy Machine and configure it however they want.

The created Core Candy Machine keeps track its own settings which helps us understand how all of its NFTs should be created. For instance, there is a collection parameter which will be assigned to all Assets created from this Core Candy Machine. We will see how to create and configure Core Candy Machines in more details, including some code examples, in the following pages: Core Candy Machine Settings and Managing Core Candy Machines.

However, we still don’t know which Assets should be minted from that Core Candy Machine. In other words, the Core Candy Machine is not currently loaded. Our next step, is to insert items.

Each item is composed of two parameters:

• A name: The name of the Asset.
• A uri: The URI pointing to the JSON metadata of the Asset. This implies that the JSON metadata has already been uploaded via either an on-chain (e.g. Arweave, IPFS) or off-chain (e.g. AWS, your own server) storage provider. The tools that you can use to create the Candy Machine, like Sugar or the JS SDK offer helpers to do so.

All other parameters are shared between Assets and are therefore kept in the settings of the Candy Machine directly to avoid repetition. See Inserting Items for more details.

Notice how, at this point, no real Assets have been created yet. We are simply loading the Candy Machine with all the data it needs to create Assets on-demand, at mint time. Which brings us to the next step.

Once the Candy Machine is loaded and all pre-configured conditions are met, users can start minting Assets from it. It’s only at this point that an Asset is created on the Solana blockchain. Note that, before minting, some users may need to perform additional verification steps — such as doing a Captcha or sending a Merkle Proof. See Minting for more details.

Once all Assets have been minted from a Candy Machine, it has served its purpose and can safely be deleted to free some storage space on the blockchain and claim some rent back. See Managing Candy Machines for more details.

Core Candy Machine Account Structure

Explain what data is stored and what role that data has for the user.

Candy Guards

Now that we understand how Core Candy Machines work, let’s dig into the various ways creators can protect and customise the mint process of their Core Candy Machine.

Creators can use what we call “Guards” to add various features to their Core Candy Machine. The Metaplex Core Candy Machine ships with an additional Solana Program called Candy Guard that ships with a total of 23 default guards. By using an additional program, it allows advanced developers to fork the default Candy Guard program to create their own custom guards whilst still being able to rely on the main Candy Machine program.

Each guard can be enabled and configured at will so creators can pick and choose the features they need. Disabling all guards would be equivalent to allowing anyone to mint our NFTs for free at any time, which is likely not what we want. So let’s have a look at a few guards to create a more realistic example.

Say a Core Candy Machine has the following guards:

• Sol Payment: This guard ensures the minting wallet has to pay a configured amount of SOL to a configured destination wallet.
• Start Date: This guard ensures minting can only start after the configured time.
• Mint Limit: This guard ensures each wallet cannot mint more than a configured amount.
• Bot Tax: This guard is a bit special. It doesn’t guard against anything but it changes the behaviour of a failed mint to prevent bots from minting Candy Machines. When this guard is activated, if any other activated guard fails to validate the mint, it will charge a small configured amount of SOL to the wallet that tried to mint.

What we end up with is a bot-protected Candy Machine that charges SOL, launches at a specific time and only allows a limited amount of mints per wallet. Here’s a concrete example.

As you can see, with more than 23 default guards and the ability to create custom guards, it enables creators to cherry-pick the features that matters to them and compose their perfect Candy Machine. This is such a powerful feature that we’ve dedicated many pages to it. The best place to start to know more about guards is the Candy Guards page. Documents the latest changes.