Creating a Core Candy Machine
Prerequisites
If you wish to create your Core Candy Machine Assets into a collection (new or existing) you will need to supply the Core Collection upon creation of the Core Candy Machine.
Creating a Candy Machine
Create a Core Candy Machine
JavaScript
Args
Available arguments that can be passed into the createCandyMachine function.
A newly generated keypair/signer that is used to create the Core Candy Machine.
Create CandyMahcine Args
JavaScript
authorityPda (optional)
Authority
JavaScript
The authorityPda field is the PDA used to verify minted Assets to the collection. This is optional an is calculated automatically based on default seeds if left.
authority (optional)
authority
JavaScript
payer (optional)
The wallet that pays for the transaction and rent costs. Defaults to signer.
authority
JavaScript
The authority field is the wallet/publicKey that will be the authority over the Core Candy Machine.
Collection
The collection the Core Candy Machine will create Assets into.
authority
JavaScript
Collection Update Authority
Update authority of the collection. This needs to be a signer so the Candy Machine can approve a delegate to verify created Assets to the Collection.
authority
JavaScript
itemsAvailable
The number of items being loaded into the Core Candy Machine.
itemsAvailable
JavaScript
Is Mutable
A boolean that marks an Asset as mutable or immutable upon creation.
isMutable
JavaScript
Config Line Settings
Config Line Settings is an optional field that allows advanced options of adding your Asset data to the Core Candy Machine making the Core Candy Machine's rent cost significantly cheaper.
By storing the Assets name and URI prefixs into the Core Candy Machine the data required to be stored is significantly reduced as you will not be storing the same name and URI for every single Asset.
For example if all your Assests had the same naming structure of Example Asset #1
through to Example Asset #1000
this would normally require you to store the string Example Asset #
1000 times, taking up 15,000 bytes.
By storing the prefix of the name in the the Core Candy Machine and letting the Core Candy Machine append the index number created to the string you save these 15,000 bytes in rent cost.
This also applies to the URI prefix.
ConfigLineSettings Object
JavaScript
prefixName
This stores the name prefix of the nfts and appends the minted index to the end of the name upon mint.
If your Asset's have a naming structure of Example Asset #1
then your prefix would be Example Asset #
. Upon mint the Core Candy Machine will attatch the index to the end of the string.
nameLength
The lengh of your prefixName.
If your Asset's prefix name is Example Asset #
then the length would be 15
prefixUri
The base URI of your metadata excluding the varible identification id.
If your Asset's will have a metadata URI of https://example.com/metadata/0.json
then your base metadata URI will be https://example.com/metadata/
.
uriLength
If your prefixUri is https://example.com/metadata/
this would have a length of 29
isSequential
Indicates whether to use a senquential index generator or not. If false the Candy Machine will mint randomly.
configLineSettings
Here is an example of creating a Core Candy Machine with configLineSettings
applied:
Create a Core Candy Machine with configLineSettings
JavaScript
Hidden Settings
Hidden settings allows the Core Candy Machine to mint exactly the same Asset to all purchasers. The design princple behind this is to allow the popular 'reveal' mechanic to take to take place at a later date. It also allows printing Core Editions when combined with the Edition Guard.
Hidden Settings
JavaScript
name
The name that appears on all Assets minted with hidden settings enabled. Note that, just like for the prefixes of the Config Line Settings, special variables can be used for the Name and URI of the Hidden Settings. As a reminder, these variables are:
$ID$
: This will be replaced by the index of the minted Asset starting at 0.$ID+1$
: This will be replaced by the index of the minted Asset starting at 1.
You should use this to be able to match the Assets that you want to your revealed data.
uri
The uri that appears on all Assets minted with hidden settings enabled.
hash
The purpose behind the hash is to store a crytographic hash/checksum of a piece of data that validates that each updated/revealed nft is the correct one matched to the index minted from the Candy Machine. This allows users to check the validation and if you have altered the data shared and in fact that Hidden NFT #39
is also Revealed NFT #39
and that the original data hasn't been tampered with to move rares around to specific people/holders.
Hashing Reveal Data
JavaScript
Example Core Candy Machine with Hidden Settings
Create a Candy Machine With Hidden Settings
JavaScript
Creating a Core Candy Machine with guards
To create a Core Candy Machine
with Guards
you can supply the guards:
field during creation and supply the default guards you with to apply to the Candy Machine.s
So far, the Core Candy Machine we created did not have any guards enabled. Now that we know all the guards available to us, let’s see how we can set up new Candy Machines with some guards enabled.
The concrete implementation will depend on which SDK you are using (see below) but the main idea is that you enable guards by providing their required settings. Any guard that has not been set up will be disabled.
Create a Core Candy Machine with guards
JavaScript
API References: create, DefaultGuardSetArgs
Last updated