grammatical fixes

docs/building-apps/wallet/sep24.mdx

@@ -5,13 +5,13 @@ sidebar_position: 50
 
 import { CodeExample } from "@site/src/components/CodeExample";
 
-[SEP-24] standard defines the standard way for anchors and wallets to interact on behalf of users. Wallets use this standard to facilitate exchanges between on-chain assets (such as stablecoins) and off-chain assets (such as fiat, or other networks assets, e.g. BTC).
+The [SEP-24] standard defines the standard way for anchors and wallets to interact on behalf of users. Wallets use this standard to facilitate exchanges between on-chain assets (such as stablecoins) and off-chain assets (such as fiat, or other network assets such as BTC).
 
-During the flow wallet makes several requests to the anchor, and finally receives an interactive URL to open in iframe. This URL is used by the user to provide an input (such as KYC) directly to the Anchor. Finally, wallet can fetch transaction information using query endpoints.
+During the flow, a wallet makes several requests to the anchor, and finally receives an interactive URL to open in iframe. This URL is used by the user to provide an input (such as KYC) directly to the anchor. Finally, the wallet can fetch transaction information using query endpoints.
 
 ## Get Anchor Information
 
-Let's start with getting instance of `Interactive` class, responsible for all SEP-24 interaction:
+Let's start with getting an instance of `Interactive` class, responsible for all SEP-24 interactions:
 
 <CodeExample>
 
@@ -21,7 +21,7 @@ val sep24 = anchor.sep24()
 
 </CodeExample>
 
-First, let's get the information about Anchor's support for [SEP-24]. This request doesn't require authentication, and will return generic info, such as supported currencies, and features supported by the anchor. You can get full list of returned fields in the [SEP-24 specification](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0024.md#info)
+First, let's get the information about the anchor's support for [SEP-24]. This request doesn't require authentication, and will return generic info, such as supported currencies, and features supported by the anchor. You can get a full list of returned fields in the [SEP-24 specification](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0024.md#info).
 
 <CodeExample>
 
@@ -35,9 +35,9 @@ suspend fun getAnchorServices(): AnchorServiceInfo {
 
 ## Interactive Flows
 
-Before getting started, make sure you have connected to the anchor and got an authentication token, as described in [Stellar Authentication] wallet guide. We will use `token` object in the examples below as [SEP-10] authentication token, obtained earlier.
+Before getting started, make sure you have connected to the anchor and received an authentication token, as described in the [Stellar Authentication] wallet guide. We will use the `token` object in the examples below as the [SEP-10] authentication token, obtained earlier.
 
-To initiate an operation, we need to know an asset. You may want to hard-code it, or get it dynamically from the Anchor's info file, like shown above (for USDC):
+To initiate an operation, we need to know an asset. You may want to hard-code it, or get it dynamically from the anchor's info file, like shown above (for USDC):
 
 <CodeExample>
 
@@ -51,7 +51,7 @@ val asset = info.currencies.first { it.code == "USDC" }.assetId
 
 [//]: # "TODO: link to establish trustline guide"
 
-Before starting with deposit flow, make sure that user account has established a trustline for the asset you are working with.
+Before starting with the deposit flow, make sure that the user account has established a trustline for the asset you are working with.
 
 :::
 
@@ -67,9 +67,9 @@ val deposit = sep24.deposit(asset, token)
 
 </CodeExample>
 
-As the result, you will get an [interactive response](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0024.md#deposit-and-withdraw-shared-responses) from the anchor.
+As a result, you will get an [interactive response](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0024.md#deposit-and-withdraw-shared-responses) from the anchor.
 
-Getting a URL that you should open in an iframe and deposit transaction id for future reference is as simple as:
+Open the received URL in an iframe and deposit the transaction ID for future reference:
 
 <CodeExample>
 
@@ -80,7 +80,7 @@ val id = deposit.id
 
 </CodeExample>
 
-Similarly to deposit, basic withdrawal flow has the same method signature and repose type:
+Similarly to the deposit flow, a basic withdrawal flow has the same method signature and repose type:
 
 <CodeExample>
 
@@ -94,11 +94,11 @@ val id = withdrawal.id
 
 ### Providing KYC Info
 
-To improve user experience, [SEP-24] standard supports passing user KYC to the anchor via [SEP-9]. In turn, anchor will pre-fill this information in the interactive popup.
+To improve the user experience, the [SEP-24] standard supports passing user KYC to the anchor via [SEP-9]. In turn, the anchor will pre-fill this information in the interactive popup.
 
 :::info
 
-While [SEP-9] supports passing binary data, current version of SDK doesn't offer such functionality.
+While [SEP-9] supports passing binary data, the current version of the SDK doesn't offer such functionality.
 
 :::
 
@@ -120,7 +120,7 @@ val deposit = sep24.deposit(asset, token, sep9)
 
 ### Changing Stellar Transfer Account
 
-By default, Stellar transfer will be sent to the authenticated account (with memo) that initiated a deposit.
+By default, the Stellar transfer will be sent to the authenticated account (with a memo) that initiated the deposit.
 
 While in most cases it's acceptable, some wallets may split their accounts. To do so, pass additional account (and optionally a memo):
 
@@ -136,7 +136,7 @@ suspend fun depositDifferentAccount(): InteractiveFlowResponse {
 
 </CodeExample>
 
-Similarly, for withdrawal, origin account of the Stellar transaction could be changed:
+Similarly, for a withdrawal, the origin account of the Stellar transaction could be changed:
 
 <CodeExample>
 
@@ -149,13 +149,13 @@ val withdrawal = sep24.withdraw(asset, token, withdrawalAccount = originAccount)
 
 ## Getting Transaction Info
 
-On the typical flow, wallet would get transaction data to notify user about status updates. This is done via [SEP-24] `GET /transaction` and `GET /transactions` endpoint.
+On the typical flow, the wallet would get transaction data to notify users about status updates. This is done via the [SEP-24] `GET /transaction` and `GET /transactions` endpoint.
 
-Alternatively, some anchors support webhooks for notifications. Note, that this feature is not widely adopted yet.
+Alternatively, some anchors support webhooks for notifications. Note that this feature is not widely adopted yet.
 
 ### Tracking Transaction
 
-Let's look into how to use wallet SDK to track transaction status change. We will use `Watcher` class for this purpose. First, let's initialize watcher and start tracking a transaction.
+Let's look into how to use the wallet SDK to track transaction status changes. We will use `Watcher` class for this purpose. First, let's initialize watcher and start tracking a transaction.
 
 <CodeExample>
 
@@ -166,7 +166,7 @@ val result = watcher.watchOneTransaction(token, "transaction id")
 
 </CodeExample>
 
-Alternatively, we can track multiple transactions for the same asset
+Alternatively, we can track multiple transactions for the same asset.
 
 <CodeExample>
 
@@ -195,21 +195,21 @@ do {
 
 </CodeExample>
 
-This code example will consume all events coming from channel, until it's closed. There are 3 types of events:
+This code example will consume all events coming from the channel until it's closed. There are three types of events:
 
 - `StatusChange`: indicates that transaction status has changed.
-- `ExceptionHandlerExit`: indicates that exception handler exited the processing loop. With default retry handler it happens when retries are exhausted.
-- `ChannelClosed`: indicates that channel is closed and no more events will be emitted. This event will always fire. If `ExceptionHandlerExit` happened, channel will close right after. Otherwise, (under normal circumstances) it will stop when all transactions reached terminal statuses.
+- `ExceptionHandlerExit`: indicates that the exception handler exited the processing loop. With default retry handler it happens when retries are exhausted.
+- `ChannelClosed`: indicates that the channel is closed and no more events will be emitted. This event will always fire. If `ExceptionHandlerExit` happened, channel will close right after. Otherwise, (under normal circumstances) it will stop when all transactions reach terminal statuses.
 
 :::info
 
-Events are stored in the channel until they are received, and calling `receive()` method will block the channel until a message is received. You can read more about how channel works in the [channel documentation](https://kotlinlang.org/docs/coroutines-and-channels.html#channels).
+Events are stored in the channel until they are received, and calling the `receive()` method will block the channel until a message is received. You can read more about how channels work in the [channel documentation].(https://kotlinlang.org/docs/coroutines-and-channels.html#channels).
 
 :::
 
 ### Fetching Transaction
 
-While `Watcher` class offers powerful tracking capabilities, sometimes it's required to just fetch transaction (or transactions) once. `Anchor` class allows to fetch transaction by id, Stellar transaction id, or external transaction id:
+While `Watcher` class offers powerful tracking capabilities, sometimes it's required to just fetch a transaction (or transactions) once. The `Anchor` class allows you to fetch a transaction by ID, Stellar transaction ID, or external transaction ID:
 
 <CodeExample>