proofread writing-to-network

Author: ZYJLiu

apps/docs/content/docs/en/intro/quick-start/writing-to-network.mdx

@@ -8,14 +8,14 @@ description:
 
 In the previous section, you learned how to
 [read data from the Solana network](/docs/intro/quick-start/reading-from-network)
-with a Kit client and RPC requests. Writing data to the Solana network requires
-a [transaction](/docs/core/transactions). A transaction contains one or more
+by fetching accounts. Writing data to the Solana network requires a
+[transaction](/docs/core/transactions). A transaction contains one or more
 [instructions](/docs/core/instructions), and each instruction invokes a program.
 
 Programs define the business logic for each instruction. When you send a
 transaction, the Solana runtime executes the transaction's instructions in
-order. The transaction is atomic: either every instruction succeeds, or every
-instruction fails.
+order. Transactions are atomic. Either every instruction in the transaction
+succeeds, or the entire transaction fails.
 
 The examples in this section show how to:
 
@@ -24,11 +24,14 @@ The examples in this section show how to:
 
 ## Transfer SOL
 
-The example below transfers SOL from one account to another. Wallet accounts are
-owned by the [System Program](/docs/core/programs#the-system-program). To deduct
-SOL from a wallet account, the transaction must invoke the System Program's
+The example below transfers SOL from one account to another. Only the program
+designated as an account's owner can modify the account's data or deduct
+lamports from its balance. Wallet accounts are owned by the
+[System Program](/docs/core/programs#the-system-program), so transferring SOL
+between wallet accounts requires an instruction that invokes the System
+Program's
 [transfer](https://github.com/anza-xyz/agave/blob/v2.1.11/programs/system/src/system_processor.rs#L183-L213)
-instruction, and the source account must sign the transaction.
+instruction. The source account must also sign the transaction.
 
 <WithNotes>
 
@@ -115,9 +118,9 @@ Fetch the sender and receiver balances after the transaction is confirmed.
 
 ## !!steps
 
-Create a Kit client for the local test validator. This is the same plugin-client
-syntax used in the token docs. The signer plugin is installed before the RPC
-plugin so the RPC plugin can use the payer when planning transactions.
+Create a Kit client for the local test validator. This snippet adds a payer
+signer, connects to the local RPC endpoint, enables airdrops, and funds the
+payer with test SOL for the transfer.
 
 ```ts title="Client setup"
 const client = await createClient()
@@ -275,9 +278,7 @@ console.log("Transaction Signature:", result.context.signature);
 
 ## !!steps
 
-After the transaction is confirmed, fetch both balances using `client.rpc`. This
-read uses the same RPC pattern from the
-[reading guide](/docs/intro/quick-start/reading-from-network).
+After the transaction is confirmed, fetch both balances using `client.rpc`.
 
 ```ts title="Fetch balances"
 const { value: senderBalance } = await client.rpc
@@ -422,8 +423,8 @@ account rent and transaction fees.
 
 ### !mint
 
-Generate a signer for the mint account. The mint signer authorizes the use of
-the new account address.
+Generate a signer to use as the address of the new mint account. The signer
+authorizes creation of that account.
 
 ### !space
 
@@ -459,9 +460,9 @@ deserializes the mint account's data field into the Mint type.
 
 ## !!steps
 
-Create and fund a Kit client, then generate the mint signer. The client payer
-funds account creation and pays the transaction fee. The mint signer becomes the
-address of the new mint account.
+Create and fund a Kit client, then generate a signer to use as the address of
+the new mint account. The client payer funds account creation and pays the
+transaction fee.
 
 ```ts title="Client and mint setup"
 const client = await createClient()
@@ -507,9 +508,9 @@ const mint = await generateKeyPairSigner();
 
 ## !!steps
 
-Calculate the mint account size, then ask RPC for the rent-exempt balance for
-that size. The mint account must hold at least this many lamports when the
-account is created.
+Calculate the mint account size in bytes, then make an RPC request to calculate
+the lamports required to store that data in the account. This required balance
+is referred to as rent.
 
 ```ts title="Mint account size and rent"
 const space = BigInt(getMintSize());
@@ -559,7 +560,6 @@ allocates the mint account [`space`](mention:space), transfers the rent-exempt
 [`programAddress`](mention:program-address).
 
 ```ts title="Create account instruction"
-// !mark(1:12)
 const createAccountInstruction = getCreateAccountInstruction({
   // !mention payer
   payer: client.payer,
@@ -623,11 +623,10 @@ The second instruction invokes the Token Extensions Program. The instruction
 initializes the [`mint`](mention:mint-account) address with a
 [`decimals`](mention:decimals) value, a
 [`mintAuthority`](mention:mint-authority), a
-[`freezeAuthority`](mention:freeze-authority), and the
+[`freezeAuthority`](mention:freeze-authority), and specifies the
 [`tokenProgram`](mention:token-program) that owns the mint account.
 
 ```ts title="Initialize mint instruction"
-// !mark(1:12)
 const initializeMintInstruction = getInitializeMintInstruction({
   // !mention mint-account
   mint: mint.address,
@@ -761,10 +760,7 @@ console.log("Transaction Signature:", result.context.signature);
 
 ## !!steps
 
-After the transaction is confirmed, fetch the mint account. This final read uses
-the same account-reading concept from the previous guide: fetch the account at
-an address, then inspect the deserialized account data returned by the program
-helper.
+After the transaction is confirmed, fetch the mint account.
 
 ```ts title="Fetch mint account"
 const mintAccount = await fetchMint(client.rpc, mint.address);