fix typos in Candy Machine Core docs (#276)

* fix typos

* more typos

* fix build

src/pages/core-candy-machine/create.md

@@ -43,7 +43,7 @@ Available arguments that can be passed into the createCandyMachine function.
 
 A newly generated keypair/signer that is used to create the Core Candy Machine.
 
-{% dialect-switcher title="Create CandyMahcine Args" %}
+{% dialect-switcher title="Create CandyMachine Args" %}
 {% dialect title="JavaScript" id="js" %}
 
 | name                      | type                          |
@@ -161,7 +161,7 @@ sellerFeeBasisPoints: number
 {% /dialect-switcher %}
 
 The `sellerFeeBasisPoints` fields is the royalty basis points that will be written to each created Asset from the Candy Machine.
-This is designated as a number based on 2 decimal places, so `500` basis points is eqaul to `5%`.
+This is designated as a number based on 2 decimal places, so `500` basis points is equal to `5%`.
 
 There is also a `percentageAmount` helper than can also be used for calculation that can be imported from the `umi` library.
 
@@ -209,9 +209,9 @@ isMutable: boolean
 
 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.
+By storing the Assets name and URI prefix 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.
+For example if all your Assets 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.
 
@@ -237,7 +237,7 @@ ConfigLineSettings = {
 
 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.
+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 attach the index to the end of the string.
 
 #### nameLength
 
@@ -251,7 +251,7 @@ For Example given...
 
 #### prefixUri
 
-The base URI of your metadata excluding the varible identification id.
+The base URI of your metadata excluding the variable 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/`.
 
@@ -267,7 +267,7 @@ For Example given...
 
 #### isSequential
 
-Indicates whether to use a senquential index generator or not. If false the Candy Machine will mint randomly.
+Indicates whether to use a sequential index generator or not. If false the Candy Machine will mint randomly.
 
 #### configLineSettings
 
@@ -305,7 +305,7 @@ await createIx.sendAndConfirm(umi)
 
 ### 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 allows the Core Candy Machine to mint exactly the same Asset to all purchasers. The design principle 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.
 
 {% dialect-switcher title="Hidden Settings" %}
 {% dialect title="JavaScript" id="js" %}
@@ -336,7 +336,7 @@ 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.
+The purpose behind the hash is to store a cryptographic 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.
 
 {% dialect-switcher title="Hashing Reveal Data" %}
 {% dialect title="JavaScript" id="js" %}
@@ -385,7 +385,7 @@ const createIx = await create(umi, {
   collectionUpdateAuthority,
   sellerFeeBasisPoints: percentAmount(10),
   itemsAvailable: 5000,
-  hiddenSettings = {
+  hiddenSettings: {
     name: "Hidden Asset",
     uri: "https://example.com/hidden-asset.json",
     hash,

src/pages/core-candy-machine/custom-guards/generating-client.md

@@ -56,14 +56,14 @@ Now you should be able to generate the IDL and the initial client. From the root
 pnpm run generate
 ```
 
-this will in turn execute both scripts `pnpm generate:idls` and `pnpm generate:clients` and build out the intial clients.
-If you need to run these seperately for what ever reason you are able to do so.
+this will in turn execute both scripts `pnpm generate:idls` and `pnpm generate:clients` and build out the initial clients.
+If you need to run these separately for what ever reason you are able to do so.
 
 ## Adding Guard(s) to the client
 
 ### Create Guard File
 
-Once a sucessful generation of the intial client is made navigate to `/clients/js/src`.
+Once a successful generation of the initial client is made navigate to `/clients/js/src`.
 
 The first step would be to add you new guard into the `/clients/js/src/defaultGuards` folder.
 

src/pages/core-candy-machine/guard-route.md

@@ -184,7 +184,7 @@ await create(umi, {
 await route(umi, {
   candyMachine: candyMachine.publicKey,
   guard: 'allowList',
-  group: some('listA'), // <- We are veryfing using "allowListA".
+  group: some('listA'), // <- We are verifying using "allowListA".
   routeArgs: {
     path: 'proof',
     merkleRoot: getMerkleRoot(allowListA),

src/pages/core-candy-machine/guards/asset-gate.md

@@ -111,7 +111,7 @@ API References: [create](https://mpl-core-candy-machine.typedoc.metaplex.com/fun
 ## Mint Settings
 
 The Asset Gate guard contains the following Mint Settings:
-- **Asset Adress**: The address of the Asset to prove ownership with. This must be part of the required collection and must belong to the minter.
+- **Asset Address**: The address of the Asset to prove ownership with. This must be part of the required collection and must belong to the minter.
 - **Collection Address**: The Address of the Collection that is used to prove ownership.
 
 Note that, if you’re planning on constructing instructions without the help of our SDKs, you will need to provide these Mint Settings and more as a combination of instruction arguments and remaining accounts. See the [Core Candy Guard’s program documentation](https://github.com/metaplex-foundation/mpl-core-candy-machine/tree/main/programs/candy-guard#assetgate) for more details.

src/pages/core-candy-machine/guards/asset-payment-multi.md

@@ -134,7 +134,7 @@ API References: [create](https://mpl-core-candy-machine.typedoc.metaplex.com/fun
 ## Mint Settings
 
 The Asset Payment guard contains the following Mint Settings:
-- **[Asset Adress]**: An array of the Assets to pay with. These must be part of the required collection and must belong to the minter.
+- **[Asset Address]**: An array of the Assets to pay with. These must be part of the required collection and must belong to the minter.
 - **Collection Address**: The Address of the Collection that is used for payment.
 - **Destination**: The address of the wallet that will receive all Assets.
 

src/pages/core-candy-machine/guards/asset-payment.md

@@ -131,7 +131,7 @@ API References: [create](https://mpl-core-candy-machine.typedoc.metaplex.com/fun
 ## Mint Settings
 
 The Asset Payment guard contains the following Mint Settings:
-- **Asset Adress**: The address of the Asset to pay with. This must be part of the required collection and must belong to the minter.
+- **Asset Address**: The address of the Asset to pay with. This must be part of the required collection and must belong to the minter.
 - **Collection Address**: The Address of the Collection that is used for payment.
 - **Destination**: The address of the wallet that will receive all Assets.
 

src/pages/core-candy-machine/guards/bot-tax.md

@@ -8,7 +8,7 @@ description: "The Core Candy Machine 'Bot Tax' guard allows you to set up a conf
 
 The **Bot Tax** guard charges a penalty for invalid transactions to discourage bots from attempting to mint NFTs. This amount is usually small to hurt bots without affecting genuine mistakes from real users. All bot taxes will be transferred to the Candy Machine account so that, once minting is over, you can access these funds by deleting the Candy Machine account.
 
-This guard is a bit special and affects the minting behaviour of all other guards. When the Bot Tax is activated and any other guard fails to validate the mint, **the transaction will pretend to succeed**. This means no errors will be returned by the program but no NFT will be minted either. This is because the transaction must succeed for the funds to be transferred from the bot to the Candy Machine account.
+This guard is a bit special and affects the minting behavior of all other guards. When the Bot Tax is activated and any other guard fails to validate the mint, **the transaction will pretend to succeed**. This means no errors will be returned by the program but no NFT will be minted either. This is because the transaction must succeed for the funds to be transferred from the bot to the Candy Machine account.
 
 Additionally, the Bot Tax guard enables us to ensure the mint instruction was the last instruction of the transaction. This prevents bots from adding malicious instructions after the mint and returns an error to avoid paying the tax.
 

src/pages/core-candy-machine/guards/freeze-sol-payment.md

@@ -306,7 +306,7 @@ Owner: Candy Machine Core Program {% .whitespace-nowrap %}
 
 {% /diagram %}
 
-{% sperator h="6" %}
+{% seperator h="6" /%}
 
 {% dialect-switcher title="Initialize the Freeze Escrow" %}
 {% dialect title="JavaScript" id="js" %}

src/pages/core-candy-machine/guards/freeze-token-payment.md

@@ -348,7 +348,7 @@ To thaw a Frozen Asset, we must provide the following arguments to the route ins
 - **Path** = `thaw`: Selects the path to execute in the route instruction.
 - **Mint**: The address of the mint account defining the SPL Token we want to pay with.
 - **Destination Associated Token Address (ATA)**: The address of the associated token account to eventually send the tokens to.
-- **Asset Adress**: The mint address of the Frozen Asset to thaw.
+- **Asset Address**: The mint address of the Frozen Asset to thaw.
 - **Asset Owner**: The address of the owner of the Frozen Asset to thaw.
 
 {% diagram  %}

src/pages/core-candy-machine/guards/third-party-signer.md

@@ -84,7 +84,7 @@ The Third Party Signer guard contains the following settings:
 
 - **Signer Key**: The address of the signer that will need to sign each mint transaction.
 
-{% dialect-switcher title="Set up a Candy Machine using the Third Pary Signer Guard" %}
+{% dialect-switcher title="Set up a Candy Machine using the Third Party Signer Guard" %}
 {% dialect title="JavaScript" id="js" %}
 {% totem %}
 

src/pages/core-candy-machine/guides/create-a-core-candy-machine-ui.md

@@ -15,7 +15,7 @@ If you're looking for guidance on general web development practices or how to us
 ## Prerequisites
 
 - An already created Candy Machine. Find more info on how to create one [here](https://developers.metaplex.com/core-candy-machine/create).
-- Basic familiarity with web development and your chosen framework. We recommend Next JS for easiest compatability to umi.
+- Basic familiarity with web development and your chosen framework. We recommend Next JS for easiest compatibility to umi.
 
 ## Required Packages
 
@@ -66,7 +66,7 @@ This would return the Candy Machine Data like this:
 {% dialect title="JSON" id="json-cm" %}
 
 {% totem-accordion title="Candy Machine Data" %}
-```tson
+```json
 {
     "publicKey": "Ct5CWicvmjETYXarcUVJenfz3CCh2hcrCM3CMiB8x3k9",
     "header": {
@@ -732,7 +732,7 @@ let builder = transactionBuilder()
   .add(mintV1(...))
 ```
 
-If you add to many `mintV1` instructions into a transaction you will recieve a `Transaction too large` error. The function [`builder.fitsInOneTransaction(umi)`](/umi/transactions#transaction-builders) allows to check for this before sending the transaction so that the transaction can be split before being sent. In case splitting is needed using [`signAllTransactions`](/umi/transactions#building-and-signing-transactions) is recommended so that only one popup has to be approved in the Wallet Adapter.    
+If you add to many `mintV1` instructions into a transaction you will receive a `Transaction too large` error. The function [`builder.fitsInOneTransaction(umi)`](/umi/transactions#transaction-builders) allows to check for this before sending the transaction so that the transaction can be split before being sent. In case splitting is needed using [`signAllTransactions`](/umi/transactions#building-and-signing-transactions) is recommended so that only one popup has to be approved in the Wallet Adapter.    
 
 ### Guard Groups
 

src/pages/core-candy-machine/index.md

@@ -4,7 +4,7 @@ metaTitle: Overview | Core Candy Machine
 description: Provides a high-level overview of Core Candy Machines.
 ---
 
-The Metaplex Protocol **Candy Machine** is the leading minting and distribution program for fair NFT collection launches on Solana. With the introduction of the `Metaplex Core Protocol` simplifying the NFT process on Solana it was only fitting for a Core edition of the Candy Machine to come to the masses. Much like its name suggests, you can think of a Candy Machine as a temporary structure which is first loaded by creators and then unloaded by buyers. It allows creators to bring their digital assets onchain in a secure and customisable way. {% .lead %}
+The Metaplex Protocol **Candy Machine** is the leading minting and distribution program for fair NFT collection launches on Solana. With the introduction of the `Metaplex Core Protocol` simplifying the NFT process on Solana it was only fitting for a Core edition of the Candy Machine to come to the masses. Much like its name suggests, you can think of a Candy Machine as a temporary structure which is first loaded by creators and then unloaded by buyers. It allows creators to bring their digital assets onchain in a secure and customizable way. {% .lead %}
 
 The name refers to the vending machines that dispense candy for coins via a mechanical crank. In this case the candy are NFTs and the payment is SOL or a SPL token.
 

src/pages/core-candy-machine/overview.md

@@ -6,7 +6,7 @@ description: An overview of the Core Candy Machine program and its feature sets
 
 ## 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.
+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` protocol which redefines NFTs on Solana and with it a new Candy Machine to accommodate the same minting mechanics users loved for the `Core` standard.
 
 Here are some of the features it offers.
 
@@ -144,7 +144,7 @@ The onchain account structure of an MPL Core Asset. [Link](https://github.com/me
 
 ## 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.
+Now that we understand how Core Candy Machines work, let’s dig into the various ways creators can protect and customize 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**](/core-candy-machine/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.
 

src/pages/core-candy-machine/preparing-assets.md

@@ -24,17 +24,17 @@ Assets support the following categories:
 
 ## Preparing Images
 
-While there are no inherant rules regarding images, it's in best practice to optimize you images to be as `web deliverable` as possible. You need to take into account that not all users may not have access to a super quick broadband connection. Users might be in remote areas where accesss to the internet is sparse so trying to get your user to view a 8mb image may impact their experiance with your project.
+While there are no inherent rules regarding images, it's in best practice to optimize you images to be as `web deliverable` as possible. You need to take into account that not all users may not have access to a super quick broadband connection. Users might be in remote areas where access to the internet is sparse so trying to get your user to view a 8mb image may impact their experience with your project.
 
 Even if your Asset is of the type `audio`, `video`, `html`, or `vr` it is still worth preparing images as these will be used as fallback for areas such as wallets or marketplaces that may not support the loading of the other Asset types.
 
 ## Preparing Animation Files
 
-Animation files consist of the remaining types of Asset catergories `audio`, `video`, `vr`, and `html`
+Animation files consist of the remaining types of Asset categories `audio`, `video`, `vr`, and `html`
 
 The same applies here as to preparing image files. You need to take into account. You need to take into consideration the file size and expected download sizes for your users.
 
-The following file types have been tested and confirmed working in nearlly all major wallets and marketplaces.
+The following file types have been tested and confirmed working in nearly all major wallets and marketplaces.
 
 - video (.mp4)
 - audio (.wav, .mp3)
@@ -194,7 +194,7 @@ You will need to upload all your JSON metadata to a storage medium of choice and
 The final step in preparation for your Core Candy Machine creation is create a Core Collection that the Core Candy Machine can use to group all the Assets together that the users purchase from your Core Candy Machine. For this we will require the `mpl-core` package.
 
 {% callout %}
-You will need to upload an image and also prepare and upload the JSON metadata like in the previous steps to have the nessacery data to create your Core Collection.
+You will need to upload an image and also prepare and upload the JSON metadata like in the previous steps to have the necessary data to create your Core Collection.
 {% /callout %}
 
 The below example creates a basic Core Collection with no plugins. To view a list of available plugins and more advanced Core Collection creation you can view the documentation over at Core's [Collection Management](/core/collections).
@@ -229,7 +229,7 @@ await createCollectionV1(umi, {
 
 ## Conclusion
 
-At this point you should have all completed all the preperations needed in order to create a Core Candy Machine.
+At this point you should have all completed all the preparations needed in order to create a Core Candy Machine.
 
 - Upload images and other media files.
 - Assign image and media file URIs to JSON Metadata files.