proofread reading-from-network

Author: ZYJLiu

apps/docs/content/docs/en/intro/quick-start/reading-from-network.mdx

@@ -17,9 +17,10 @@ to locate the account's onchain data. Solana accounts contain either
 <WithMentions>
 
 A wallet account is an account owned by the
-[System Program](/docs/core/programs#the-system-program). Wallet accounts are
-primarily used to hold SOL and sign transactions. When SOL is sent to a new
-address for the first time, a system account is automatically created.
+[System Program](/docs/core/programs/builtin-programs#the-system-program).
+Wallet accounts are primarily used to hold SOL and sign transactions. When SOL
+is sent to a new address for the first time, a system account is automatically
+created.
 
 The example below [creates a Kit client](mention:client), generates a
 [new signer](mention:keypair), [requests SOL](mention:airdrop) to fund the new
@@ -49,7 +50,7 @@ const signer = await generateKeyPairSigner();
 console.log(`Address: ${signer.address}`);
 
 // Funding an address with SOL automatically creates an account
-// !mention(1:4) airdrop
+// !mention airdrop
 await client.airdrop(signer.address, lamports(1_000_000_000n));
 
 // !mention info
@@ -144,8 +145,8 @@ appear.
 
 ## !!steps
 
-The `lamports` field contains the account's SOL balance, in
-[lamports](/docs/references/terminology#lamport).
+The `lamports` field contains the account's SOL balance, measured in
+[lamports](/docs/references/terminology#lamport), the smallest unit of SOL.
 
 <CodePlaceholder title="Example output" />
 
@@ -222,8 +223,10 @@ owner is always the System Program, with the address
 
 ## !!steps
 
-The `executable` field indicates whether the account can be invoked as a
-program. For wallet accounts, the `executable` field is `false`.
+The `executable` field tells you whether the account's address is callable.
+`true` means the address represents a program that can process instructions.
+`false` means the account stores state, such as a wallet balance or account
+data, and is not called as a program. Wallet accounts use `false`.
 
 <CodePlaceholder title="Example output" />
 
@@ -272,9 +275,9 @@ field is still returned for backward compatibility.
 
 ## !!steps
 
-The `space` field shows the number of bytes contained in the `data` field.
-Account-fetching APIs include the `space` value to save you from counting the
-bytes yourself.
+The `space` field shows the number of bytes contained in the `data` field. The
+`space` field is returned with the account-fetching response, but it is not part
+of the account's data type.
 
 For the wallet account example, the `space` field is 0 because the `data` field
 contains 0 bytes of data.
@@ -304,18 +307,24 @@ contains 0 bytes of data.
 ## Fetch the Token Program
 
 The example below fetches the Token Program to demonstrate the difference
-between wallet and program accounts. The Token Program's address is the onchain
-Program account. For upgradeable programs, the Program account stores loader
-metadata and points to a separate ProgramData account that stores the deployed
-bytecode for the Token Program's
-[source code](https://github.com/solana-program/token/tree/main/program). You
-can view the Program account on the
+between wallet and program accounts. The Token Program defines instructions for
+working with tokens, such as creating and transferring tokens. Programs are
+invoked to process instructions. Program state, such as token data and balances,
+are stored in separate accounts owned by the program.
+
+The Token Program's address is the onchain Program account. For simplicity, you
+can think of the program address as the program, because that is the address
+used to invoke it. For upgradeable programs, the Program account stores metadata
+and points to a separate ProgramData account that stores the deployed executable
+code. You can view the Token Program
+[source code](https://github.com/solana-program/token/tree/main/program) and the
+Program account on the
 [Solana Explorer](https://explorer.solana.com/address/TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA).
 
 <CodeTabs flags="r">
 
 ```ts !! title="Fetch program account"
-import { address, createClient } from "@solana/kit";
+import { address, createClient, fetchJsonParsedAccount } from "@solana/kit";
 import { solanaRpc } from "@solana/kit-plugin-rpc";
 import { generatedPayer } from "@solana/kit-plugin-signer";
 
@@ -340,6 +349,14 @@ const accountInfo = await client.rpc
   .send();
 
 console.log(accountInfo);
+
+// !mark(1:4)
+const parsedAccount = await fetchJsonParsedAccount(
+  client.rpc,
+  tokenProgramAddress
+);
+
+console.log(parsedAccount);
 ```
 
 </CodeTabs>
@@ -350,13 +367,10 @@ console.log(accountInfo);
 
 The Token Program is an executable program account. Programs have the same
 underlying fields as all [accounts](/docs/core/accounts#account-structure), but
-with key differences. Your `slot` and `apiVersion` may differ from the Token
-Program output shown here.
+with key differences.
 
 The Token Program example uses `base64` encoding to return the Program account's
-raw bytes without asking RPC to interpret the bytes. The Program account data is
-short because the fetched account is the upgradeable Program account, not the
-separate ProgramData account that stores the compiled bytecode.
+raw data.
 
 The following steps walk through the fields inside `value` in the order the
 fields appear.
@@ -384,8 +398,8 @@ fields appear.
 
 The `data` field stores the BPF Upgradeable Loader's Program account state. The
 first tuple item contains the full account data encoded as base64. The second
-tuple item identifies the encoding. Here, the 36 bytes are the loader-state
-discriminator plus the ProgramData account address.
+tuple item identifies the encoding. Here, the 36 bytes include metadata and the
+ProgramData account address.
 
 For upgradeable programs, the Program account state points to the separate
 ProgramData account that stores the program's executable code.
@@ -463,8 +477,8 @@ Program accounts need enough lamports to remain rent-exempt.
 ## !!steps
 
 Every program account is owned by a
-[loader program](/docs/core/programs#loader-programs). For the Token Program
-account, the `owner` is the BPF Upgradeable Loader.
+[loader program](/docs/core/programs/program-deployment#loader-programs). For
+the Token Program account, the `owner` is the BPF Upgradeable Loader.
 
 <CodePlaceholder title="Token program account" />
 
@@ -515,7 +529,8 @@ field is still returned for backward compatibility.
 
 The `space` field shows the full size of the Program account's data in bytes.
 The `space` value is only `36` bytes because the Program account stores loader
-metadata and a 32-byte pointer to ProgramData, not the full compiled program.
+metadata and the address of the ProgramData account, not the full compiled
+program.
 
 <CodePlaceholder title="Token program account" />
 
@@ -537,16 +552,40 @@ metadata and a 32-byte pointer to ProgramData, not the full compiled program.
 }
 ```
 
+## !!steps
+
+The previous response returned the Program account's `data` field as a base64
+tuple. The parsed response deserializes those bytes into named fields on the
+`data` object. The `programData` field contains the address of the ProgramData
+account that stores the executable program code.
+
+<CodePlaceholder title="Parsed Token program account" />
+
+```ts !! title="Parsed Token program account"
+{
+  executable: true,
+  lamports: 43712780n,
+  programAddress: "BPFLoaderUpgradeab1e11111111111111111111111",
+  space: 36n,
+  address: "TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA",
+  // !focus(1:4)
+  data: {
+    programData: "3gvYRKWyXRR9xKWe1ZjPhLY5ZJRN7KDB4rFZFGoJfFk2",
+    parsedAccountMeta: { program: "bpf-upgradeable-loader", type: "program" }
+  },
+  exists: true
+}
+```
+
 </ScrollyCoding>
 
 ## Fetch a mint account
 
-A
-[mint account](https://github.com/solana-program/token/blob/program%40v8.0.0/program/src/state.rs#L16-L30)
-is an account owned by the Token Program that stores global metadata for a
-specific token. The mint account stores the token's total supply, number of
-decimals, mint authority, and freeze authority. The mint account's address
-uniquely identifies a token on the Solana network.
+A [mint account](/docs/tokens/basics/create-mint) is an account owned by the
+Token Program that stores global metadata for a specific token. The mint account
+stores the token's total supply, number of decimals, mint authority, and freeze
+authority. The mint account's address uniquely identifies a token on the Solana
+network.
 
 The example below fetches the USD Coin Mint account to demonstrate how a
 program's state is stored in a separate account. Exact balances and supply
@@ -590,9 +629,6 @@ Mint accounts store state, not executable code. Mint accounts are owned by the
 Token Program, which includes instructions defining how to create and update
 mint accounts.
 
-The mint account example uses `base64` encoding so the raw account data is
-returned as an encoded string. The mint account is small enough to log directly.
-
 The following steps walk through the fields inside `value` in the order the
 fields appear.
 
@@ -795,21 +831,19 @@ The `space` field shows that the mint account contains 82 bytes of data.
 
 ## Deserialize mint account
 
-Before the raw bytes in an account's `data` field can be interpreted
-meaningfully, the raw bytes must be deserialized. The program that owns the
-account defines the appropriate data type. Most Solana programs provide client
-libraries with helper functions that abstract away the deserialization process.
-Helper functions convert raw account bytes into structured data types, making
-account data easier to work with.
+Account data is stored in the `data` field in a serialized format. To read that
+data as fields like `supply` or `decimals`, deserialize the `data` field into
+the account type defined by the owning program. Most Solana programs provide
+client libraries with helper functions for this step. These helpers return
+structured account data, making the result easier to work with.
 
 <WithMentions>
 
 For example, the _shell`@solana-program/token`_ library includes the
 [_ts`fetchMint()`_](mention:one) function to fetch a mint account and
 deserialize the mint account's `data` field into the
 [Mint](https://github.com/solana-program/token/blob/program%40v8.0.0/program/src/state.rs#L16-L30)
-data type defined by the Token Program. Optional authorities are returned as Kit
-`Option` values.
+data type defined by the Token Program.
 
 <CodeTabs flags="r">
 
@@ -977,8 +1011,7 @@ fields in `data` come from the Token Program's `Mint` account type.
 ## !!steps
 
 The `data.mintAuthority` field shows the only account that can create new units
-of the token. Since the mint authority is optional, Kit returns the mint
-authority as an `Option`.
+of the token.
 
 <CodePlaceholder title="Decoded mint account" />
 
@@ -1104,8 +1137,9 @@ Program.
 ## !!steps
 
 The `data.freezeAuthority` field shows the account with authority to freeze
-token accounts. A frozen token account cannot transfer or burn the token balance
-inside the frozen token account.
+token accounts. A [token account](/docs/tokens/basics/create-token-account) is a
+separate account that stores units of a token for an owner. When frozen, a token
+account cannot transfer or burn its token balance.
 
 <CodePlaceholder title="Decoded mint account" />
 
@@ -1135,9 +1169,8 @@ inside the frozen token account.
 
 ## !!steps
 
-The `executable` field keeps the same meaning after deserialization. The USDC
-mint account stores token state, so the USDC mint account cannot be invoked as a
-program.
+The `executable` field is false. The USDC mint account stores token state, so
+the USDC mint account cannot be invoked as a program.
 
 <CodePlaceholder title="Decoded mint account" />
 
@@ -1198,8 +1231,9 @@ lamports value is the mint account's rent-exempt balance, not the token supply.
 
 ## !!steps
 
-The `programAddress` field shows the program that owns the decoded mint account.
-For USDC, the owning program is the Token Program.
+The `programAddress` field shows the program that owns the mint account. For
+USDC, the owning program is the Token Program. Only the program that owns an
+account can modify its `data` field through the program's deployed instructions.
 
 <CodePlaceholder title="Decoded mint account" />
 
@@ -1262,18 +1296,17 @@ Token Program's base `Mint` account is 82 bytes.
 
 ### Serialized vs deserialized output
 
-Both examples read the same USDC mint account. The raw RPC fetch returns
-serialized bytes in the `data` field. To read the mint account's contents,
-decode the serialized bytes as the account type defined by the owning program.
-For a mint account, the Token Program defines the `Mint` type shown on the
-right.
+Both examples read the same USDC mint account. The first response leaves the
+`data` field serialized. To read the mint account's contents, decode that data
+as the account type defined by the owning program. For a mint account, the Token
+Program defines the `Mint` type shown on the right.
 
 <SideBySide>
 
 ### !left
 
 Before decoding, the [`data`](mention:serialized-data) field contains serialized
-account bytes.
+account data.
 
 ```ts title="Serialized mint account" -w
 {
@@ -1299,8 +1332,8 @@ account bytes.
 
 ### !right
 
-After decoding the serialized bytes as a `Mint`, the
-[`data`](mention:decoded-data) field contains named account fields.
+After decoding the data as a `Mint`, the [`data`](mention:decoded-data) field
+contains named account fields.
 
 ```ts title="Deserialized mint account" -w
 {