diff --git a/docs/src/tutorials/tutorial-0.md b/docs/src/tutorials/tutorial-0.md index e43156881..7684c6ea0 100644 --- a/docs/src/tutorials/tutorial-0.md +++ b/docs/src/tutorials/tutorial-0.md @@ -65,7 +65,7 @@ accounts, we skip this (important) detail. ## Building and Emitting an IDL -After creating a program, one can use the `anchor` CLI to build and emit an IDL, from which clients +After creating a program, you can use the `anchor` CLI to build and emit an IDL, from which clients can be generated. ```bash diff --git a/docs/src/tutorials/tutorial-1.md b/docs/src/tutorials/tutorial-1.md index ec0cc16d4..1e2fa37d3 100644 --- a/docs/src/tutorials/tutorial-1.md +++ b/docs/src/tutorials/tutorial-1.md @@ -38,19 +38,19 @@ pick it up. ::: Additionally, -notice how we take a mutable reference to `my_account` and assign the `data` to it. This leads us +notice how we take a mutable reference to `my_account` and assign the `data` to it. This leads us to the `Initialize` struct, deriving `Accounts`. There are three things to notice about `Initialize`. 1. The `my_account` field is of type `ProgramAccount<'info, MyAccount>`, telling the program it *must* be **owned** by the currently executing program, and the deserialized data structure is `MyAccount`. 2. The `my_account` field is marked with the `#[account(init)]` attribute. This should be used in one situation: when a given `ProgramAccount` is newly created and is being used by the program -for the first time (and thus it's data field is all zero). If `#[account(init)]` is not used +for the first time (and thus its data field is all zero). If `#[account(init)]` is not used when account data is zero initialized, the transaction will be rejected. 3. The `Rent` **sysvar** is required for the rent exemption check, which the framework enforces by default for any account marked with `#[account(init)]`. To be more explicit about the check, one can specify `#[account(init, rent_exempt)]`. To skip this check, (and thus -allowing one to omit the `Rent` acccount) one can specify +allowing you to omit the `Rent` acccount), you can specify `#[account(init, rent_exempt = skip)]` on the account being initialized (here, `my_account`). ::: details @@ -75,7 +75,7 @@ Marking an account as `mut` persists any changes made upon exiting the program. Here we've covered the basics of how to interact with accounts. In a later tutorial, we'll delve more deeply into deriving `Accounts`, but for now, just know -one must mark their accounts `init` when using an account for the first time and `mut` +you must mark an account `init` when using it for the first time and `mut` for persisting changes. ## Creating and Initializing Accounts diff --git a/docs/src/tutorials/tutorial-2.md b/docs/src/tutorials/tutorial-2.md index 1538f5c66..bd94d851f 100644 --- a/docs/src/tutorials/tutorial-2.md +++ b/docs/src/tutorials/tutorial-2.md @@ -5,7 +5,7 @@ somewhat unique to the parallel nature of Solana. On Solana, a transaction must specify all accounts required for execution. And because an untrusted client specifies those accounts, a program must responsibly validate all such accounts are what the client claims they are--in addition to any instruction specific access control the program needs to do. -For example, one could imagine easily writing a faulty token program that forgets to check if the **signer** of a transaction claiming to be the **owner** of a Token `Account` actually matches the **owner** on that account. Furthermore, imagine what might happen if the program expects a `Mint` account but a malicious user gives a token `Account`. +For example, you could imagine easily writing a faulty token program that forgets to check if the **signer** of a transaction claiming to be the **owner** of a Token `Account` actually matches the **owner** on that account. Furthermore, imagine what might happen if the program expects a `Mint` account but a malicious user gives a token `Account`. To address these problems, Anchor provides several types, traits, and macros. It's easiest to understand by seeing how they're used in an example, but a couple include diff --git a/docs/src/tutorials/tutorial-3.md b/docs/src/tutorials/tutorial-3.md index 898aa3216..91420a0b7 100644 --- a/docs/src/tutorials/tutorial-3.md +++ b/docs/src/tutorials/tutorial-3.md @@ -26,7 +26,7 @@ We start with the program that will be called by another program, the puppet. If you've followed along the other tutorials, this should be straight forward. We have a program with two instructions, `initialize`, which does nothing other than the initialization of the account (remember, the program *transparently* prepends a unique 8 -byte discriminator the first time an account is used). and `set_data`, which takes a previously +byte discriminator the first time an account is used), and `set_data`, which takes a previously initialized account, and sets its data field. Now, suppose we wanted to call `set_data` from another program. @@ -65,7 +65,7 @@ For more background on signing with program derived addresses, see the official ## Return values -Solana currently has no way to return values from CPI, alas. However, one can approximate this +Solana currently has no way to return values from CPI, alas. However, you can approximate this by having the callee write return values to an account and the caller read that account to retrieve the return value. In future work, Anchor should do this transparently. diff --git a/docs/src/tutorials/tutorial-4.md b/docs/src/tutorials/tutorial-4.md index 83c61c37e..7ee836eb5 100644 --- a/docs/src/tutorials/tutorial-4.md +++ b/docs/src/tutorials/tutorial-4.md @@ -43,7 +43,7 @@ to the full power of the lower level Solana accounts API. Of course, Anchor will ### Invoke the constructor -To access the `#[state]` account and associated instructions, one can use the +To access the `#[state]` account and associated instructions, you can use the `anchor.state` namespace on the client. For example, to invoke the constructor, <<< @/../examples/tutorial/basic-4/tests/basic-4.js#ctor @@ -69,7 +69,7 @@ To invoke an instruction, Performing CPI from one Anchor program to another's state methods is very similar to performing CPI to normal Anchor instructions, except for two differences: 1. All the generated instructions are located under the `::cpi::state` module. -2. One must use a [CpiStateContext](https://docs.rs/anchor-lang/latest/anchor_lang/struct.CpiStateContext.html), instead of a `[CpiContext](https://docs.rs/anchor-lang/latest/anchor_lang/struct.CpiContext.html). +2. You must use a [CpiStateContext](https://docs.rs/anchor-lang/latest/anchor_lang/struct.CpiStateContext.html), instead of a `[CpiContext](https://docs.rs/anchor-lang/latest/anchor_lang/struct.CpiContext.html). For a full example, see the `test_state_cpi` instruction, [here](https://github.com/project-serum/anchor/blob/master/examples/misc/programs/misc/src/lib.rs#L39). diff --git a/docs/src/tutorials/tutorial-5.md b/docs/src/tutorials/tutorial-5.md index 949ad68c5..14b3fb45f 100644 --- a/docs/src/tutorials/tutorial-5.md +++ b/docs/src/tutorials/tutorial-5.md @@ -32,7 +32,7 @@ pub enum ErrorCode { Observe the [#[error]](https://docs.rs/anchor-lang/latest/anchor_lang/attr.error.html) attribute on the `ErrorCode` enum. This macro generates two types: an `Error` and a `Result`, both of which can be used when returning from your program. -To use the `Error`, one can simply use the user defined `ErrorCode` with Rust's [From](https://doc.rust-lang.org/std/convert/trait.From.html) trait. If you're unfamiliar with `From`, no worries. Just know that you need to either call +To use the `Error`, you can simply use the user defined `ErrorCode` with Rust's [From](https://doc.rust-lang.org/std/convert/trait.From.html) trait. If you're unfamiliar with `From`, no worries. Just know that you need to either call `.into()` when using your `ErrorCode`. Or use Rust's `?` operator, when returning an error. Both of these will automatically convert *into* the correct `Error`. diff --git a/docs/src/tutorials/tutorial-6.md b/docs/src/tutorials/tutorial-6.md index ddf85c542..6620b290d 100644 --- a/docs/src/tutorials/tutorial-6.md +++ b/docs/src/tutorials/tutorial-6.md @@ -16,10 +16,10 @@ address for every SPL token? Now generalize this. For every program you use, do want a single account, i.e. your SOL wallet, to define your application state? Or do you want to keep track of all your account addresses, separately, for every program in existance? -Associated accounts allow your users to reason about a single address, their main SOL wallet, +Associated accounts allow your users to reason about a single address, their main SOL wallet. This is a huge improvement on the account model introduced thus far. -Luckily, Anchor provides the ability to easily created associated program accounts for your program. +Luckily, Anchor provides the ability to easily create associated program accounts for your program. ::: details If you've explored Solana, you may have come across the [Associated Token Account Program](https://spl.solana.com/associated-token-account) which uniquely and deterministically defines @@ -31,7 +31,7 @@ Unfortunately, the SPL token program doesn't do this, strictly. It was built *be of associated token accounts (associated token accounts were built as an add-on). So in reality, there are non associated token accounts floating around Solanaland. However, for new programs, this isn't necessary, and it's recommend to only use associated -accounts, when creating accounts on behalf of users, for example, a token account. +accounts when creating accounts on behalf of users, such as a token account. ::: ## Clone the Repo @@ -62,7 +62,7 @@ Two new keywords are introduced to the `CreateToken` account context: * `associated = ` * `with = ` -Both of these allow one to define input "seeds" that +Both of these allow you to define input "seeds" that uniquely define the associated account. By convention, `associated` is used to define the main address to associate, i.e., the wallet, while `with` is used to define an auxilliary piece of metadata which has the effect of namespacing the associated account. @@ -86,7 +86,7 @@ For more details on how to use `#[account(associated)]`, see [docs.rs](https://d ### Defining an Associated Account The new `#[acount(associated)]` attribute will allow you to create a new associated account similar to `#[account(init)]`, but -to actually define an account as associated, one must use the `#[associated]` attribute *instead* of the `#[account]` attribute. +to actually define an account as associated, you must use the `#[associated]` attribute *instead* of the `#[account]` attribute. This new `#[associated]` attribute extends `#[account]` to include two things diff --git a/examples/lockup/docs/lockups.md b/examples/lockup/docs/lockups.md index 8cd44a20b..65727fcda 100644 --- a/examples/lockup/docs/lockups.md +++ b/examples/lockup/docs/lockups.md @@ -84,7 +84,7 @@ a single admin, or the zero address--in which case the authority ceases to exist program will reject transactions signing from that address. Although the **authority** can never move a **Vesting** account's funds, whoever controls the **authority** key controls the whitelist. So when using the **Lockup** program, one should always be -cognizant of it's whitelist governance, which ultimately anchors one's trust in the program, +cognizant of its whitelist governance, which ultimately anchors one's trust in the program, if any at all. ## Creating a Whitelisted Program diff --git a/examples/lockup/docs/staking.md b/examples/lockup/docs/staking.md index ad7c8417a..627c37267 100644 --- a/examples/lockup/docs/staking.md +++ b/examples/lockup/docs/staking.md @@ -89,7 +89,7 @@ from the stake pool is complete, and the funds are ready to be used again. Feel free to skip this section and jump to the **Reward Vendors** section if you want to just see how rewards work. -One could imagine several ways to drop rewards onto a staking pool, each with their own downsides. +One could imagine several ways to drop rewards onto a staking pool, each with there own downsides. Of course what you want is, for a given reward amount, to atomically snapshot the state of the staking pool and to distribute it proportionally to all stake holders. Effectively, an on chain program such as