diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index bb8c7c0f7..01fe405a2 100644 --- a/CONTRIBUTING.md +++ b/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!** diff --git a/content/cookbook/programs/cross-program-invocation.md b/content/cookbook/programs/cross-program-invocation.md index 539f1a1ca..57dd12aa7 100644 --- a/content/cookbook/programs/cross-program-invocation.md +++ b/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"); diff --git a/content/cookbook/tokens/create-token-account.md b/content/cookbook/tokens/create-token-account.md index f126b21de..8b03e3182 100644 --- a/content/cookbook/tokens/create-token-account.md +++ b/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" diff --git a/content/cookbook/tokens/manage-wrapped-sol.md b/content/cookbook/tokens/manage-wrapped-sol.md index b1dc14fb1..6138c4ad8 100644 --- a/content/cookbook/tokens/manage-wrapped-sol.md +++ b/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, diff --git a/content/cookbook/wallets/sign-message.md b/content/cookbook/wallets/sign-message.md index fe6488b23..42a07f1fd 100644 --- a/content/cookbook/wallets/sign-message.md +++ b/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. - + + ```typescript import { diff --git a/content/courses/mobile/mwa-deep-dive.md b/content/courses/mobile/mwa-deep-dive.md index 0ceaa2fd7..dc3363acf 100644 --- a/content/courses/mobile/mwa-deep-dive.md +++ b/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 diff --git a/content/courses/native-onchain-development/serialize-instruction-data-frontend.md b/content/courses/native-onchain-development/serialize-instruction-data-frontend.md index 410b2abf2..1387e4334 100644 --- a/content/courses/native-onchain-development/serialize-instruction-data-frontend.md +++ b/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 diff --git a/content/courses/offline-transactions/durable-nonces.md b/content/courses/offline-transactions/durable-nonces.md index 3a91b11e2..7074a1546 100644 --- a/content/courses/offline-transactions/durable-nonces.md +++ b/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 diff --git a/content/courses/onchain-development/anchor-cpi.md b/content/courses/onchain-development/anchor-cpi.md index 83286aebd..08fc99197 100644 --- a/content/courses/onchain-development/anchor-cpi.md +++ b/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` diff --git a/content/courses/program-optimization/lookup-tables.md b/content/courses/program-optimization/lookup-tables.md index 6576eb3d5..cf02dad80 100644 --- a/content/courses/program-optimization/lookup-tables.md +++ b/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. diff --git a/content/courses/program-optimization/program-architecture.md b/content/courses/program-optimization/program-architecture.md index 2eaa0bd57..6800b51d5 100644 --- a/content/courses/program-optimization/program-architecture.md +++ b/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::*; diff --git a/content/courses/program-optimization/rust-macros.md b/content/courses/program-optimization/rust-macros.md index 6f9e106a1..825c2844f 100644 --- a/content/courses/program-optimization/rust-macros.md +++ b/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 `.workspace = true`, like the _custom-macro_ crate and _custom-macro-test_ crate which will be defined next. diff --git a/content/courses/program-security/arbitrary-cpi.md b/content/courses/program-security/arbitrary-cpi.md index edb15793d..975d241d3 100644 --- a/content/courses/program-security/arbitrary-cpi.md +++ b/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, amount: u64) -> ProgramResult { diff --git a/content/courses/program-security/bump-seed-canonicalization.md b/content/courses/program-security/bump-seed-canonicalization.md index 1ee208d63..b850b9ae3 100644 --- a/content/courses/program-security/bump-seed-canonicalization.md +++ b/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 diff --git a/content/courses/program-security/closing-accounts.md b/content/courses/program-security/closing-accounts.md index d4a9b28de..5b55b9c9a 100644 --- a/content/courses/program-security/closing-accounts.md +++ b/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 diff --git a/content/courses/token-extensions/cpi-guard.md b/content/courses/token-extensions/cpi-guard.md index f78461d1b..0d3d1fd45 100644 --- a/content/courses/token-extensions/cpi-guard.md +++ b/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) -> Result<()> { +pub fn prohibited_set_authority(ctx: Context) -> 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>, diff --git a/content/courses/token-extensions/group-member.md b/content/courses/token-extensions/group-member.md index ca12d49d3..96eb49ed9 100644 --- a/content/courses/token-extensions/group-member.md +++ b/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 diff --git a/content/courses/token-extensions/intro-to-token-extensions-program.md b/content/courses/token-extensions/intro-to-token-extensions-program.md index 2c74eee2b..607df31dd 100644 --- a/content/courses/token-extensions/intro-to-token-extensions-program.md +++ b/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 diff --git a/content/courses/token-extensions/token-extensions-metadata.md b/content/courses/token-extensions/token-extensions-metadata.md index 8baf0fa57..2e06244be 100644 --- a/content/courses/token-extensions/token-extensions-metadata.md +++ b/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 diff --git a/content/courses/token-extensions/token-extensions-onchain.md b/content/courses/token-extensions/token-extensions-onchain.md index 1cbf6c2ce..768d72d29 100644 --- a/content/courses/token-extensions/token-extensions-onchain.md +++ b/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 diff --git a/content/courses/token-extensions/transfer-hook.md b/content/courses/token-extensions/transfer-hook.md index f27cead37..a5a4fa122 100644 --- a/content/courses/token-extensions/transfer-hook.md +++ b/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. diff --git a/content/guides/advanced/verified-builds.md b/content/guides/advanced/verified-builds.md index e601ab46d..9bb9916db 100644 --- a/content/guides/advanced/verified-builds.md +++ b/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 --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 diff --git a/docs/intro/installation.md b/docs/intro/installation.md index f9c2e3004..e398aa551 100644 --- a/docs/intro/installation.md +++ b/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): diff --git a/docs/programs/anchor/client-typescript.md b/docs/programs/anchor/client-typescript.md index ba5c096ec..f3d72118d 100644 --- a/docs/programs/anchor/client-typescript.md +++ b/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 --- diff --git a/docs/programs/anchor/cpi.md b/docs/programs/anchor/cpi.md index 092b9481f..bb1d0d583 100644 --- a/docs/programs/anchor/cpi.md +++ b/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 diff --git a/docs/programs/anchor/program-structure.md b/docs/programs/anchor/program-structure.md index a8b0f2475..a7d5fc07c 100644 --- a/docs/programs/anchor/program-structure.md +++ b/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: diff --git a/docs/programs/rust/program-structure.md b/docs/programs/rust/program-structure.md index b07022736..5a46ce82d 100644 --- a/docs/programs/rust/program-structure.md +++ b/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], diff --git a/docs/rpc/http/getInflationReward.mdx b/docs/rpc/http/getInflationReward.mdx index ebde5bc1b..87d83acf7 100644 --- a/docs/rpc/http/getInflationReward.mdx +++ b/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: ` - epoch for which reward occured +- `epoch: ` - epoch for which reward occurred - `effectiveSlot: ` - the slot in which the rewards are effective - `amount: ` - reward amount in lamports - `postBalance: ` - post balance of the account in lamports