fix: typos

CONTRIBUTING.md

@@ -914,7 +914,7 @@ To embed a Whimsical diagram:
   [Edwards curves](https://en.wikipedia.org/wiki/Edwards_curve). This is
   [what the curve Ed25519 uses looks like](https://www.wolframalpha.com/input?i=x%5E2+%2B+y%5E2+%3D+1+-+%28121665%2F121666%29*x%5E2*y%5E2).
   Solana public keys are the Y values on this curve (we can omit the X value
-  because the curve is symmatrical). Ed25519 is symmetrical, and looks like a
+  because the curve is symmetrical). Ed25519 is symmetrical, and looks like a
   slightly deflated beach ball. **Do not draw a snake or some other kind or
   curve!**
 

content/cookbook/programs/cross-program-invocation.md

@@ -391,7 +391,7 @@ pub fn process_instruction(
         system_program.clone(),
     ];
 
-    // Passing the TransactionInstruction to send (with the issused program_id)
+    // Passing the TransactionInstruction to send (with the issued program_id)
     invoke(&create_account_instruction, &required_accounts_for_create)?;
 
     msg!("Transfer successful");

content/cookbook/tokens/create-token-account.md

@@ -9,7 +9,7 @@ A token account is required for a user to hold tokens.
 
 A user will have at least one token account for every type of token they own.
 
-Associated Token Accounts are deterministicly created accounts for every
+Associated Token Accounts are deterministically created accounts for every
 keypair. ATAs are the recommended method of managing token accounts.
 
 ```typescript filename="ata.ts"

content/cookbook/tokens/manage-wrapped-sol.md

@@ -68,7 +68,7 @@ import bs58 from "bs58";
   let amount = 1 * 1e9; /* Wrapped SOL's decimals is 9 */
 
   let tx = new Transaction().add(
-    // trasnfer SOL
+    // transfer SOL
     SystemProgram.transfer({
       fromPubkey: alice.publicKey,
       toPubkey: ata,

content/cookbook/wallets/sign-message.md

@@ -8,7 +8,8 @@ The primary function of a keypair is to sign messages, transactions and enable
 verification of the signature. Verification of a signature allows the recipient
 to be sure that the data was signed by the owner of a specific private key.
 
-<Tabs groupId="language" items={['web3.js v2', 'web3.js v1']}> <Tab value="web3.js v2">
+<Tabs groupId="language" items={['web3.js v2', 'web3.js v1']}>
+<Tab value="web3.js v2">
 
 ```typescript
 import {

content/courses/mobile/mwa-deep-dive.md

@@ -16,7 +16,7 @@ description:
   key management
 - Mobile and Web dApps handle their wallet-app connection differently
 - MWA handles all of its wallet interaction by wrapping all the wallet's
-  functionalities within the `transact` function for easier intergration.
+  functionalities within the `transact` function for easier integration.
 - Solana Mobile's `walletlib` does the heavy lifting for surfacing wallet
   requests to wallet apps
 

content/courses/native-onchain-development/serialize-instruction-data-frontend.md

@@ -45,7 +45,7 @@ create transactions with instructions for common Solana programs.
 
 This lessons shows how to create instructions for our own native Solana
 programs, which we will develop in a few lessons. Specifically, we're going to
-learn about serialization and deserialization, which is requiredfor native
+learn about serialization and deserialization, which is required for native
 (non-Anchor) program development.
 
 #### Transaction Contents

content/courses/offline-transactions/durable-nonces.md

@@ -64,7 +64,7 @@ This is known as the double-spend problem and is one of the core issues that
 blockchains, like Solana, solve. A naive solution could be to crosscheck all
 transactions made in the past and see if we find a duplicate transaction
 signature. This is not practically possible, as the size of the Solana ledger
-is >80 TB. So to solve this, Solana uses recent blockhashs.
+is >80 TB. So to solve this, Solana uses recent blockhashes.
 
 A recent blockhash is a 32-byte SHA-256 hash of a valid block's last
 [entry id](https://solana.com/docs/terminology#blockhash) within the last 150

content/courses/onchain-development/anchor-cpi.md

@@ -454,7 +454,7 @@ Next, update the `AddMovieReview` context type to add the following accounts:
 - `token_program` - we'll be using the Token Program to mint tokens
 - `mint` - the mint account for the tokens that we'll mint to users when they
   add a movie review
-- `token_account` - the associated token account for the afforementioned `mint`
+- `token_account` - the associated token account for the aforementioned `mint`
   and reviewer
 - `associated_token_program` - required because we'll be using the
   `associated_token` constraint on the `token_account`

content/courses/program-optimization/lookup-tables.md

@@ -698,7 +698,7 @@ we will follow these steps:
    recipients' addresses.
 2. Call `waitForNewBlock`: Ensure the lookup table is activated by waiting for a
    new block.
-3. Retrieve the Lookup Table: Use `connection.getAddressLookupTabl`e to fetch
+3. Retrieve the Lookup Table: Use `connection.getAddressLookupTable` to fetch
    the lookup table and reference it in the transaction.
 4. Create Transfer Instructions: Generate a transfer instruction for each
    recipient.

content/courses/program-optimization/program-architecture.md

@@ -1598,7 +1598,7 @@ This is our last instruction. This instruction lets anyone send the spent
 Again, let's box the rpg accounts and use safe math.
 
 ```rust filename="collect_points.rs"
-// ----------- REDEEM TO TREASUREY ----------
+// ----------- REDEEM TO TREASURY ----------
 
 // Inside src/instructions/collect_points.rs
 use anchor_lang::prelude::*;

content/courses/program-optimization/rust-macros.md

@@ -744,8 +744,8 @@ members = [
 anchor-lang = "0.30.1"
 ```
 
-The `[workspace.dependecies]` has _anchor-lang_ as a dependency, which allows us
-to define the version of _anchor-lang_ in the root project configuration and
+The `[workspace.dependencies]` has _anchor-lang_ as a dependency, which allows
+us to define the version of _anchor-lang_ in the root project configuration and
 then inherit that version in all other members of the workspace that depend on
 it, by registering `<dependency-name>.workspace = true`, like the _custom-macro_
 crate and _custom-macro-test_ crate which will be defined next.

content/courses/program-security/arbitrary-cpi.md

@@ -17,7 +17,7 @@ description: "How to safely invoke Solana programs from other Solana programs."
   passed into the instruction handler. Your program should check for incorrect
   or unexpected programs.
 - Perform program checks in native programs by simply comparing the public key
-  of the passed-in program to the progam you expected.
+  of the passed-in program to the program you expected.
 - If a program is written in Anchor, then it may have a publicly available CPI
   module. This makes invoking the program from another Anchor program simple and
   secure. The Anchor CPI module automatically checks that the address of the
@@ -90,9 +90,9 @@ token program that they created and control.
 
 ### Add Program Checks
 
-It's possible to fix this vulnerabilty by simply adding a few lines to the `cpi`
-instruction handler to check whether or not `token_program`'s public key is that
-of the SPL Token Program.
+It's possible to fix this vulnerability by simply adding a few lines to the
+`cpi` instruction handler to check whether or not `token_program`'s public key
+is that of the SPL Token Program.
 
 ```rust
 pub fn cpi_secure(ctx: Context<Cpi>, amount: u64) -> ProgramResult {

content/courses/program-security/bump-seed-canonicalization.md

@@ -313,7 +313,7 @@ be occasionally and unpredictably exceeded.
 
 On the other hand, if you only need to verify the address of a PDA passed in
 without initializing an account, you'll be forced to either let Anchor derive
-the canonical bump or expose your program to unecessary risks. In that case,
+the canonical bump or expose your program to unnecessary risks. In that case,
 please use the canonical bump despite the slight mark against performance.
 
 ## Lab

content/courses/program-security/closing-accounts.md

@@ -378,7 +378,7 @@ attacker to drain an entire rewards pool.
 ### 3. Create a `redeem_rewards_secure` instruction
 
 To prevent this from happening we're going to create a new instruction that
-closes the lottery account seucrely using the Anchor `close` constraint. Feel
+closes the lottery account securely using the Anchor `close` constraint. Feel
 free to try this out on your own if you'd like.
 
 The new account validation struct called `RedeemWinningsSecure` should look like
@@ -471,7 +471,7 @@ struct, the attacker shouldn't be able to call this instruction multiple times.
 
 ### 4. Test the Program
 
-To test our new secure instruction, let's create a new test that trys to call
+To test our new secure instruction, let's create a new test that tries to call
 `redeemingWinningsSecure` twice. We expect the second call to throw an error.
 
 ```typescript

content/courses/token-extensions/cpi-guard.md

@@ -4,7 +4,7 @@ objectives:
   - Explain what the CPI Guard protects against
   - Write code to test the CPI Guard
 description:
-  "Create tokens that don't allow certain accounts to be invoked from toher
+  "Create tokens that don't allow certain accounts to be invoked from other
   programs."
 ---
 
@@ -23,10 +23,10 @@ CPI Guard is an extension that prohibits certain actions inside cross-program
 invocations, protecting users from implicitly signing for actions they can't
 see, such as those hidden in programs that aren't the System or Token programs.
 
-A specific example of this is when the CPI gaurd is enabled, no CPI can approve
+A specific example of this is when the CPI guard is enabled, no CPI can approve
 a delegate over a token account. This is handy, because if a malicious CPI calls
 `set_delegate` no immediate balance change will be apparent, however the
-attacker now has transfer and burn authority over the token account. CPI gaurd
+attacker now has transfer and burn authority over the token account. CPI guard
 makes this impossible.
 
 Users may choose to enable or disable the CPI Guard extension on their token
@@ -628,7 +628,7 @@ pub struct ApproveAccount<'info> {
         token::authority = authority
     )]
     pub token_account: InterfaceAccount<'info, token_interface::TokenAccount>,
-    /// CHECK: delegat to approve
+    /// CHECK: delegate to approve
     #[account(mut)]
     pub delegate: AccountInfo<'info>,
     pub token_program: Interface<'info, token_interface::TokenInterface>,
@@ -892,7 +892,7 @@ Moving on to the `prohibited_set_authority` instruction, the CPI Guard protects
 against a CPI setting the `CloseAccount` authority.
 
 ```rust
-pub fn prohibted_set_authority(ctx: Context<SetAuthorityAccount>) -> Result<()> {
+pub fn prohibited_set_authority(ctx: Context<SetAuthorityAccount>) -> Result<()> {
     msg!("Invoked ProhibitedSetAuthority");
 
     msg!(
@@ -924,7 +924,7 @@ pub struct SetAuthorityAccount<'info> {
         token::authority = authority
     )]
     pub token_account: InterfaceAccount<'info, token_interface::TokenAccount>,
-    /// CHECK: delegat to approve
+    /// CHECK: delegate to approve
     #[account(mut)]
     pub new_authority: AccountInfo<'info>,
     pub token_program: Interface<'info, token_interface::TokenInterface>,
@@ -964,7 +964,7 @@ it("sets authority when CPI guard in enabled", async () => {
 
   try {
     const tx = await program.methods
-      .prohibtedSetAuthority()
+      .prohibitedSetAuthority()
       .accounts({
         authority: payer.publicKey,
         tokenAccount: userTokenAccount.publicKey,
@@ -1003,7 +1003,7 @@ it("Set Authority Example", async () => {
   );
 
   await program.methods
-    .prohibtedSetAuthority()
+    .prohibitedSetAuthority()
     .accounts({
       authority: payer.publicKey,
       tokenAccount: userTokenAccount.publicKey,
@@ -1238,7 +1238,7 @@ pub struct SetOwnerAccounts<'info> {
         token::authority = authority
     )]
     pub token_account: InterfaceAccount<'info, token_interface::TokenAccount>,
-    /// CHECK: delegat to approve
+    /// CHECK: delegate to approve
     #[account(mut)]
     pub new_owner: AccountInfo<'info>,
     pub token_program: Interface<'info, token_interface::TokenInterface>,

content/courses/token-extensions/group-member.md

@@ -200,7 +200,7 @@ const signature = tokenGroupUpdateGroupMaxSize(
   connection, //connection - Connection to use
   payer, // payer - Payer for the transaction fees
   mint.publicKey, // mint - Group mint
-  updpateAuthority, // account - Update authority of the group
+  updateAuthority, // account - Update authority of the group
   4, // maxSize - new max size of the group
   undefined, // multiSigners — Signing accounts if `authority` is a multisig
   { commitment: "finalized" }, // confirmOptions - Options for confirming thr transaction

content/courses/token-extensions/intro-to-token-extensions-program.md

@@ -4,7 +4,7 @@ objectives:
   - Learn about the Token Extensions Program
   - Understand that mints that use Token Extensions must be created with the
     Token Extensions Program
-  - Learn about the wide variuety of token extensions
+  - Learn about the wide variety of token extensions
   - Use token extensions from the Solana CLI
 description:
   "Learn what token extensions are, and how to create tokens that use their
@@ -271,7 +271,7 @@ First let's create a new vanilla mint with no additional extensions:
 spl-token create-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb
 ```
 
-You should get something simular to this:
+You should get something similar to this:
 
 ```bash
 Creating token FXnaqGm42aQgz1zwjKrwfn4Jk6PJ8cvkkSc8ikMGt6EU under program TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

content/courses/token-extensions/token-extensions-metadata.md

@@ -702,7 +702,7 @@ NFT.Storage using the helper functions provided in the starting code.
 
 To upload our offchain metadata, we need to first prepare an image that will
 represent our NFT. We've provided `cat.png`, but feel free to replace it with
-your own. Most image types are supported by most wallets. (Again devenet Irys
+your own. Most image types are supported by most wallets. (Again devnet Irys
 allows up to 100KiB per file)
 
 Next, let's decide on what metadata our NFT will have. The fields we are

content/courses/token-extensions/token-extensions-onchain.md

@@ -1477,7 +1477,7 @@ the pool, both values representing the amount the user has staked and the total
 amount staked in the pool should increase by the `stake_amount`.
 
 To do this, we will deserialize the `pool_state` and `user_entry` accounts as
-mutable and increase the `pool_state.amount` and `user_enry.balance` fields by
+mutable and increase the `pool_state.amount` and `user_entry.balance` fields by
 the `stake_amount` using `checked_add()`. `CheckedAdd` is a Rust feature that
 allows you to safely perform mathematical operations without worrying about
 buffer overflow. `checked_add()` adds two numbers, checking for overflow. If
@@ -1814,7 +1814,7 @@ let signer = &[&auth_seeds[..]];
 
 Once we have those seeds stored in the `signer` variable, we can easily pass it
 into the `transfer_checked_ctx()` method. At the same time, we'll call the
-`transfer_checked` helper function from the Anchor crate to acually invoke the
+`transfer_checked` helper function from the Anchor crate to actually invoke the
 CPI behind the scenes.
 
 ```rust

content/courses/token-extensions/transfer-hook.md

@@ -1231,8 +1231,8 @@ Extensions Program, and Solana does not allow
 To illustrate:
 
 ```text
-Token Extensions Program -CPI-> Transfer Hook Program -❌CPI❌-> Token Extensions Progra
-Token Extensions Program -CPI-> Transfer Hook Program -✅CPI✅-> Token Progra
+Token Extensions Program -CPI-> Transfer Hook Program -❌CPI❌-> Token Extensions Program
+Token Extensions Program -CPI-> Transfer Hook Program -✅CPI✅-> Token Program
 ```
 
 So, that's why we're making the crumb SFT a Token Program mint.

content/guides/advanced/verified-builds.md

@@ -430,7 +430,7 @@ PDA transaction manually and then trigger the transaction through Squads.
 solana-verify export-pda-tx https://github.com/solana-developers/verify-squads --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD --uploader <your program authority> --encoding base58 --compute-unit-price 0
 ```
 
-This will return you a base58 transcation. If you want a base64 encoded
+This will return you a base58 transaction. If you want a base64 encoded
 transaction for use in a transaction inspector, you can use `--encoding base64`.
 
 ```bash

docs/intro/installation.md

@@ -548,7 +548,7 @@ Generating a new keypair
 
 For added security, enter a BIP39 passphrase
 
-NOTE! This passphrase improves security of the recovery seed phrae NOT the
+NOTE! This passphrase improves security of the recovery seed phrase NOT the
 keypair file itself, which is stored as insecure plain text
 
 BIP39 Passphrase (empty for none):

docs/programs/anchor/client-typescript.md

@@ -2,7 +2,7 @@
 title: JS/TS Client
 description:
   Learn how to use Anchor's TypeScript client library to interact with Solana
-  progra
+  program
 sidebarLabel: JS/TS Client
 sidebarSortOrder: 3
 ---

docs/programs/anchor/cpi.md

@@ -9,7 +9,7 @@ sidebarSortOrder: 5
 
 [Cross Program Invocations (CPI)](/docs/core/cpi.md) refer to the process of one
 program invoking instructions of another program, which enables the
-composibility of programs on Solana.
+composability of programs on Solana.
 
 This section will cover the basics of implementing CPIs in an Anchor program,
 using a simple SOL transfer instruction as a practical example. Once you

docs/programs/anchor/program-structure.md

@@ -236,7 +236,7 @@ pub struct Initialize<'info> {
 
 ### Account Validation
 
-To prevent security vulnerabiliies, it's important to verify that accounts
+To prevent security vulnerabilities, it's important to verify that accounts
 provided to an instruction are the expected accounts. Accounts are validated in
 Anchor programs in two ways that are generally used together:
 

docs/programs/rust/program-structure.md

@@ -814,7 +814,7 @@ Once the account is created, we initialize the account data by:
 3. Serializing the `CounterAccount` struct into the account's data field,
    effectively storing the `initial_value` on the account.
 
-```rs filename="lib.rs" {35-44} /inital_value/
+```rs filename="lib.rs" {35-44} /initial_value/
 fn process_initialize_counter(
     program_id: &Pubkey,
     accounts: &[AccountInfo],

docs/rpc/http/getInflationReward.mdx

@@ -44,7 +44,7 @@ Configuration object containing the following fields:
 
 The result field will be a JSON array with the following fields:
 
-- `epoch: <u64>` - epoch for which reward occured
+- `epoch: <u64>` - epoch for which reward occurred
 - `effectiveSlot: <u64>` - the slot in which the rewards are effective
 - `amount: <u64>` - reward amount in lamports
 - `postBalance: <u64>` - post balance of the account in lamports