fix guide typos (#229)

.vscode/settings.json

@@ -1,35 +1,39 @@
 {
     "cSpell.words": [
-        "Arweave",
-        "bincode",
-        "blockhash",
-        "callout",
-        "Datas",
-        "Devnet",
-        "hashlist",
-        "Hookable",
-        "Irys",
-        "Keypair",
-        "Localnet",
-        "metadata",
-        "metaplex",
-        "msgpack",
-        "nonblocking",
-        "offchain",
-        "pdas",
-        "Preconfigured",
-        "println",
-        "Pubkey",
-        "publickey",
-        "rpcs",
-        "seperator",
-        "serde",
-        "Shdw",
-        "Solana",
-        "Solflare",
-        "Solscan",
-        "Struct",
-        "usize"
+      "Arweave",
+      "bincode",
+      "blockhash",
+      "Bundlr",
+      "callout",
+      "Datas",
+      "Devnet",
+      "eddsa",
+      "hashlist",
+      "Hookable",
+      "Irys",
+      "Keypair",
+      "Localnet",
+      "Merkle",
+      "metadata",
+      "metaplex",
+      "msgpack",
+      "nonblocking",
+      "offchain",
+      "pdas",
+      "Preconfigured",
+      "println",
+      "Pubkey",
+      "publickey",
+      "rpcs",
+      "seperator",
+      "serde",
+      "Shdw",
+      "Solana",
+      "Solflare",
+      "Solscan",
+      "SPACEBAR",
+      "Struct",
+      "usize"
     ],
   "editor.codeActionsOnSave": {
     "source.sortImports": "explicit"

src/pages/guides/general/how-to-diagnose-solana-transaction-errors.md

@@ -163,4 +163,4 @@ Assert errors are matching errors. Assert will normally take 2 variables (in mos
 
 ### 0x1 Attempt to Debit
 
-This is a common error that reads `Attempt to debit an account but found no record of a prior credit`. This error basicly implies that the account does not have any SOL within it.
+This is a common error that reads `Attempt to debit an account but found no record of a prior credit`. This error basically implies that the account does not have any SOL within it.

src/pages/guides/index.md

@@ -6,6 +6,6 @@ description: Guides by Metaplex about the Solana blockchain.
 
 ![image info](./assets/banners/touch-screen.jpg)
 
-The guides in this section are **designed to help new Solana developers start their journey** by providing step-by-step instructions and practical examples they can execute. These guides focus on teaching key concepts with a structured learning path that gradually introduces developers to the Solana ecosystem. They cover everything from the basics of blockchain and Solana's unique features to advanced topics such as program developement and optimization techniques.
+The guides in this section are **designed to help new Solana developers start their journey** by providing step-by-step instructions and practical examples they can execute. These guides focus on teaching key concepts with a structured learning path that gradually introduces developers to the Solana ecosystem. They cover everything from the basics of blockchain and Solana's unique features to advanced topics such as program development and optimization techniques.
 
-By incorporating a variety of learning resources, including tutorials and code samples, **the guides are designed to be accessibly to be new and experianced developers in the space**. The guides are regularly updated to reflect the latest developments in the Solana ecosystem.
+By incorporating a variety of learning resources, including tutorials and code samples, **the guides are designed to be accessibly to be new and experienced developers in the space**. The guides are regularly updated to reflect the latest developments in the Solana ecosystem.

src/pages/guides/javascript/how-to-create-an-nft-on-solana.md

@@ -9,7 +9,7 @@ updated: '06-18-2024'
 
 Metaplex provides 3 different standards for creating NFTs on the Solana blockchain including **Core**, **Token Metadata**, and **Bubblegum**. Each standard and protocol provides unique advantages for projects and spread across the wide spectrum of minting and NFT requirements for projects.
 
-## Core Asset (Recommmended)
+## Core Asset (Recommended)
 
 Token Metadata is a protocol within Metaplex that focuses on the metadata aspects of NFTs. This standard defines how metadata is stored, retrieved, and associated with NFTs, ensuring that NFTs have rich, meaningful, and verifiable information attached to them.
 
@@ -17,7 +17,7 @@ Token Metadata is a protocol within Metaplex that focuses on the metadata aspect
 
 - Newest Standard: Core is the newest and most powerful digital asset standard created by Metaplex to date.
 - Simplicity: Core was designed from the ground up with a **simplicity first approach**.
-- Plugins: Core provides an advanced plugin system that allows Core Assets and Collections to store extra state, provide lifecycle validations, and an enhanced dynamic experiance. The possibilities here are endless!
+- Plugins: Core provides an advanced plugin system that allows Core Assets and Collections to store extra state, provide lifecycle validations, and an enhanced dynamic experience. The possibilities here are endless!
 - Cost: While not as cheap as Bubblegum, Core is **significantly cheaper** to create and mint compared to Token Metadata due to the optimized account structures.
 
 [Create An NFT with Core](/core/guides/javascript/how-to-create-a-core-nft-asset)
@@ -28,7 +28,7 @@ Token Metadata is the Solana NFT standard that started it all. Created back in 2
 
 #### Why Use Token Metadata:
 
-- Tried and Trusted: Token Metadata has been used as Solana's primary NFT Token Standard for the last 4 years from projects such as Solana Monkey Business, Degods, Claynosaurus just to name a few.
+- Tried and Trusted: Token Metadata has been used as Solana's primary NFT Token Standard for the last 4 years from projects such as Solana Monkey Business, DeGods, Claynosaurus just to name a few.
 - Eco System Support: NFTs and pNFTs are supported Solana wide by marketplaces and wallets such as MagicEden, Tensor, Phantom, Solflare and many others.
 - SPL Token Based: Token Metadata NFTs/pNFTs are based around Solana's SPL Token program.
 
@@ -36,7 +36,7 @@ Token Metadata is the Solana NFT standard that started it all. Created back in 2
 
 ## Bubblegum cNFT
 
-When it comes to creating NFTs that are cheap in mass then Bubblegum is the protocol to choose. Bubblegum uses the technology of **Compresed NFTs (cNFTs)** By applying a Merkle tree approach instead of creating accounts for each individual NFT.
+When it comes to creating NFTs that are cheap in mass then Bubblegum is the protocol to choose. Bubblegum uses the technology of **Compressed NFTs (cNFTs)** By applying a Merkle tree approach instead of creating accounts for each individual NFT.
 
 #### Why Use Bubblegum:
 

src/pages/guides/rpcs-and-das.md

@@ -82,7 +82,7 @@ By indexing all the Digital Assets (NFTs and Tokens) users have access to much f
 ### Syncing
 DAS has the ability to sync the reindexing of data during certain lifecycle instructions that are sent to the blockchain. By watching these instructions such as create, update, burn, and transfer we can always be assured that the DAS indexed data is up to date.
 
-Currently Core, Token Metadata, and Bubbglegum are all indexed by DAS.
+Currently Core, Token Metadata, and Bubblegum are all indexed by DAS.
 
 To find out more about Metaplex DAS you can visit these pages:
 

src/pages/guides/rust/how-to-cpi-into-a-metaplex-program.md

@@ -10,7 +10,7 @@ You may have heard the term "CPI'ing into a program" or "Call a CPI on the progr
 
 A CPI (Cross Program Invocation) is the interaction of one program invoking an instruction on another program.
 
-An example would be that I make a program and during this transaction I need to transfer an NFT or Asset during this transaction. Well my program can CPI call and ask the Token Metadata or Core programs to exectute the transfer instruction for me if I give it all the correct details.
+An example would be that I make a program and during this transaction I need to transfer an NFT or Asset during this transaction. Well my program can CPI call and ask the Token Metadata or Core programs to execute the transfer instruction for me if I give it all the correct details.
 
 ## Using Metaplex Rust Transaction CPI Builders
 
@@ -32,7 +32,7 @@ TransferV1InstructionData
 
 The one we are interested in here is the `TransferV1CpiBuilder`.
 
-To initialize the builder we can call `new` on the `CpiBuilder` and pass in the program `AcountInfo` of the program address the CPI call is being made to.
+To initialize the builder we can call `new` on the `CpiBuilder` and pass in the program `AccountInfo` of the program address the CPI call is being made to.
 
 ```rust
 TransferV1CpiBuilder::new(ctx.accounts.mpl_core_program);
@@ -110,16 +110,16 @@ CreateV1CpiBuilder::new()
         .payer(context.accounts.payer)
         .owner(context.accounts.owner)
         .update_authority(context.accounts.update_authority)
-        .system_program(context.acccounts.system_program)
+        .system_program(context.accounts.system_program)
         .data_state(input.data_state.unwrap_or(DataState::AccountState))
         .name(args.asset_name)
-        .uri(arts.asseet_uri)
+        .uri(arts.asset_uri)
         .plugins(args.plugins)
 ```
 
 ## Invoking
 
-Invoking is the term used to exectute the CPI call to the other program, a programs version of "sending a transaction" if you may.
+Invoking is the term used to execute the CPI call to the other program, a programs version of "sending a transaction" if you may.
 
 We have two options when it comes to invoking a CPI call. `invoke()` and `invoke_signed()`
 
@@ -138,7 +138,7 @@ CreateV1CpiBuilder::new()
 
 ### invoke_signed()
 
-`invoke_signed()` is used when a PDA is one of the accounts that needs to be a signer in a cpi call. Lets say for example we had a program that took possesion of our Asset and one of our programs PDA addresses became the other of it. In order to transfer it and change the owner to someone else that PDA will have sign transaction.
+`invoke_signed()` is used when a PDA is one of the accounts that needs to be a signer in a cpi call. Lets say for example we had a program that took possession of our Asset and one of our programs PDA addresses became the other of it. In order to transfer it and change the owner to someone else that PDA will have sign transaction.
 
 You'll need to pass in the original PDA seeds and bump so that the PDA can be recreated can sign the cpi call on your programs behalf.
 

src/pages/guides/rust/metaplex-rust-sdks.md

@@ -6,7 +6,7 @@ description: A quick overview on Metaplex Rust SDKs.
 
 ## Introduction
 
-Metaplex provides Rust SDKs for most of our programs which have consistant and predictable outputs and functionality leading to improved intergration times for developers working with our products.
+Metaplex provides Rust SDKs for most of our programs which have consistent and predictable outputs and functionality leading to improved integration times for developers working with our products.
 
 ## Modules
 
@@ -29,7 +29,7 @@ mpl_core::accounts
 
 ### Instructions
 
-Each SDK comes with an **instructions** module that comes with multiple versions of the supplied instructions from the given program that strips away alot of the boiler plate depending on your needs.
+Each SDK comes with an **instructions** module that comes with multiple versions of the supplied instructions from the given program that strips away a lot of the boiler plate depending on your needs.
 
 An example below shows all the `CreateV1` instructions coming from the `mpl-core` crate.
 
@@ -51,7 +51,7 @@ mpl_core::instructions
 
 ### Types
 
-Each of the Metaplex Rust SDKs comes with a **types** module that supplies all the nessacery extra types that may not be in the initial accounts module structs.
+Each of the Metaplex Rust SDKs comes with a **types** module that supplies all the necessary extra types that may not be in the initial accounts module structs.
 
 These can be accessed from `<crate_name>::types`. In the case of `mpl-core` you could access the accounts as follows;
 
@@ -154,7 +154,7 @@ Now that we have our instruction ready we need to create a normal Solana transac
 
 ### Full Builder Example
 
-This is a full example of creating a instruction using a Metaplex `Builder` function and sending that transction off to the chain.
+This is a full example of creating a instruction using a Metaplex `Builder` function and sending that transaction off to the chain.
 
 ```rust
 use mpl_core::instructions::CreateV1Builder;
@@ -194,6 +194,6 @@ let rpc_client = rpc_client::RpcClient::new("https://api.devnet.solana.com".to_s
 
 The `CpiBuilder` instructions are designed to be used when you wish to call and execute instructions from a Metaplex program from your own program.
 
-We have a full seperate guide discussing `CpiBuilders` which can be viewed here;
+We have a full separate guide discussing `CpiBuilders` which can be viewed here;
 
 [CPI Into a Metaplex Program](/guides/rust/how-to-cpi-into-a-metaplex-program)

src/pages/guides/rust/working-with-rust.md

@@ -145,7 +145,7 @@ let rpc_client = rpc_client::RpcClient::new("https://api.devnet.solana.com".to_s
 
 ```
 
-## Working with Progams
+## Working with Programs
 
 ### CPI (Cross Program Invocation)
 
@@ -153,7 +153,7 @@ You may have heard the term "CPI'ing into a program" or "Call a CPI on the progr
 
 Well CPI'ing into a program is basically one program calling upon another program during a transaction.
 
-An example would be that I make a program and during this transaction I need to transfer an Nft or Asset during this transaction. Well my program can CPI call and ask the Token Metadata or Core programs to exectute the transfer instruction for me if I give it all the correct details.
+An example would be that I make a program and during this transaction I need to transfer an Nft or Asset during this transaction. Well my program can CPI call and ask the Token Metadata or Core programs to execute the transfer instruction for me if I give it all the correct details.
 
 ### Using Metaplex Rust Transaction CPI Builders
 
@@ -175,7 +175,7 @@ TransferV1InstructionData
 
 The one we are interested in here is the `TransferV1CpiBuilder`.
 
-To initialize the builder we can call `new` on the CpiBuilder and pass in the program `AcountInfo` of the program address the CPI call is being made to.
+To initialize the builder we can call `new` on the CpiBuilder and pass in the program `AccountInfo` of the program address the CPI call is being made to.
 
 ```rust
 TransferV1CpiBuilder::new(ctx.accounts.mpl_core_program);
@@ -253,16 +253,16 @@ CreateV1CpiBuilder::new()
         .payer(context.accounts.payer)
         .owner(context.accounts.owner)
         .update_authority(context.accounts.update_authority)
-        .system_program(context.acccounts.system_program)
+        .system_program(context.accounts.system_program)
         .data_state(input.data_state.unwrap_or(DataState::AccountState))
         .name(args.asset_name)
-        .uri(arts.asseet_uri)
+        .uri(arts.asset_uri)
         .plugins(args.plugins)
 ```
 
 ### Invoking
 
-Invoking is the term used to exectute the CPI call to the other program. And programs version of "sending a transaction" if you may.
+Invoking is the term used to execute the CPI call to the other program. And programs version of "sending a transaction" if you may.
 
 We have two options when it comes to invoking a CPI call. `invoke()` and `invoke_signed()`
 
@@ -281,7 +281,7 @@ CreateV1CpiBuilder::new()
 
 #### invoke_signed()
 
-`invoke_signed()` is used when a PDA is one of the accounts that needs to be a signer in a cpi call. Lets say for example we had a program that took possesion of our Asset and one of our programs PDA addresses became the other of it. In order to transfer it and change the owner to someone else that PDA will have sign transaction.
+`invoke_signed()` is used when a PDA is one of the accounts that needs to be a signer in a cpi call. Lets say for example we had a program that took possession of our Asset and one of our programs PDA addresses became the other of it. In order to transfer it and change the owner to someone else that PDA will have sign transaction.
 
 You'll need to pass in the original PDA seeds and bump so that the PDA can be recreated can sign the cpi call on your programs behalf.
 

src/pages/guides/understanding-pdas.md

@@ -15,7 +15,7 @@ Only the program that derived the PDA can sign transactions involving the addres
 ## Role of PDAs
 PDAs are primarily used to:
 
-- **Manage State**: PDAs allow programs to create accounts and store data to a determinstic PDA address which allows read and write access for the program.
+- **Manage State**: PDAs allow programs to create accounts and store data to a deterministic PDA address which allows read and write access for the program.
 - **Authorize Transactions**: Only the program that owns the PDA can authorize transactions involving it, ensuring secure controlled access. For example this allows programs and PDA accounts to store tokens/own NFTs that would require the current owner of the tokens/NFT to sign a transaction to transfer the items to another account.
 
 ## How PDAs are Derived

src/pages/token-metadata/guides/get-by-collection.md

@@ -98,7 +98,7 @@ Rust `Option`s are represented in [Borsh](https://borsh.io/) encoding with a 0 f
 
 There are two ways to do this: brute force and gathering a priori knowledge of the variants. 
 
-Brute force requires computing all the possible variants and running multiple `getProgramAccount` calls in parallel. Given up to five creators in the creators array and two possible options for each of the two `Option` fields prior to `Collection`, that leads to a total number of 20 possible combinations, meaning that you would have to make 20 `getProgramAccount` calls with various offsets to take this approach. This is obviously not a feasible nor scaleable approach. 
+Brute force requires computing all the possible variants and running multiple `getProgramAccount` calls in parallel. Given up to five creators in the creators array and two possible options for each of the two `Option` fields prior to `Collection`, that leads to a total number of 20 possible combinations, meaning that you would have to make 20 `getProgramAccount` calls with various offsets to take this approach. This is obviously not a feasible nor scalable approach. 
 If some a priori information is known about a collection though, this can be reduced to a smaller number of calls. Knowing how many creators there are is the biggest gain, reducing the number of `getProgramAccount` calls down to only four which can be reasonably run in parallel. 
 
 This approach is not the recommended one due to the high number of edge cases it involves and the fact that it can only be pragmatically used on collections where there is only one creator or the number of variations of how many creators there are is known ahead of time. 

src/pages/umi/guides/serializing-and-deserializing-transactions.md

@@ -18,9 +18,9 @@ Transactions are usually serialized to facilitate movement across different envi
 - You may require signatures from different authorities stored in separate environments.
 - You may wish to create a transaction on the frontend, but then send and validate it on the backend before storing it to a database.
 
-For example, when creating NFTs, you may need to sign the transaction with the `collectionAutority` keypair to authorize the NFT into the Collection. To safely sign it, without exposing your keypair, you could first create the transaction in the backend, partially sign the transaction with the `collectionAutority` without having to expose the keypair in a non secure environment, serialize the transaction and then send it. You can then safely deserialize the transactions and sign it with the `Buyer` wallet.
+For example, when creating NFTs, you may need to sign the transaction with the `collectionAuthority` keypair to authorize the NFT into the Collection. To safely sign it, without exposing your keypair, you could first create the transaction in the backend, partially sign the transaction with the `collectionAuthority` without having to expose the keypair in a non secure environment, serialize the transaction and then send it. You can then safely deserialize the transactions and sign it with the `Buyer` wallet.
 
-**Note**: When using the Candy Machine, you don't need the `collectionAutority` signature 
+**Note**: When using the Candy Machine, you don't need the `collectionAuthority` signature 
 
 ## Initial Setup
 
@@ -123,11 +123,11 @@ const umi = createUmi('https://api.devnet.solana.com')
 
 ## Serialization
 
-Serialization of a transaction is the process of converting the transaction object into a series of bytes or string that saves the state of the transction in an easily transmittable form. This allows it to be passed through the likes of a http request.  
+Serialization of a transaction is the process of converting the transaction object into a series of bytes or string that saves the state of the transaction in an easily transmittable form. This allows it to be passed through the likes of a http request.  
 
 Within the serialization example we're going to:  
 - Use the `NoopSigner` to add the `Payer` as `Signer` in the instruction
-- Create a Versioned Transaction and sign it with the `collectionAutority` and the `Asset`
+- Create a Versioned Transaction and sign it with the `collectionAuthority` and the `Asset`
 - Serialize it so all the details are preserved and can be accurately reconstructed by the frontend
 - And send it as a String, instead of a u8, so it can be passed through a request