grammatical fixes

docs/building-apps/wallet/sep10.mdx

@@ -5,27 +5,27 @@ sidebar_position: 40
 
 import { CodeExample } from "@site/src/components/CodeExample";
 
-Wallets connect to anchors using standard way of authentication via Stellar network defined by the [sep-10] standard.
+Wallets connect to anchors using a standard way of authentication via the Stellar network defined by the [SEP-10] standard.
 
-There are many ways of using this authentication method and in this guideline we will cover all options to authenticating with the Anchor.
+This guide will cover all ways to use SEP-10 to authenticate with an anchor.
 
 ## Creating Authentication Key
 
 :::info Custodial wallets only
 
 :::
 
-First, let's create an authentication key. While you can use the same key for authentication and sending funds, it's recommended to split the responsibilities. In your application, you will have one or more funds keypairs (keypairs for the accounts that hold funds, initiate and receive transactions) and one authentication key.
+First, let's create an authentication key. While you can use the same key for authentication and sending funds, it's recommended to split the responsibilities. In your application, you will have one or more fund keypairs (keypairs for the accounts that hold funds and initiate and receive transactions) and one authentication key.
 
-Authentication key is only used for the authentication purposes and don't need to hold any funds. Note, that you don't need to create account for this key pair either.
+The authentication key is only used for authentication purposes and doesn't need to hold any funds. Note that you don't need to create an account for this keypair either.
 
-Go to [Stellar Lab] and generate a keypair. The secret key must be handled securely, because it will be used to authenticate with.
+Go to the [Stellar Lab] and generate a keypair. The secret key must be handled securely, because it will be used for authentication.
 
 ## Basic Authentication
 
-Let's do a basic authentication. In this example we will use wallet sdk to create an authentication token.
+Let's do a basic authentication. In this example, we will use wallet SDK to create an authentication token.
 
-First, let's create an `anchor` object to work with the anchor you are integrating with. In this example, we will be using reference anchor implementation with home domain `testanchor.stellar.org`
+First, let's create an `anchor` object to work with the anchor you are integrating with. In this example, we will be using a reference anchor implementation with the home domain `testanchor.stellar.org`
 
 <CodeExample>
 
@@ -49,11 +49,11 @@ suspend fun getAuthToken(): AuthToken {
 
 </CodeExample>
 
-For non-custodial wallets, you want to use user's private key as an `authKey`.
+For non-custodial wallets, you want to use the user's private key as an `authKey`.
 
 ## Home Domain (Optional)
 
-Home domain is the optional parameter for SEP-10 authentication, when single auth server is shared between multiple domains. Some anchors may require to provide this argument. SDK automatically sets `home_domain` parameter in all SEP-10 requests.
+The home domain is the optional parameter for SEP-10 authentication, when a single auth server is shared between multiple domains. Some anchors may require you to provide this argument. The SDK automatically sets the `home_domain` parameter in all SEP-10 requests.
 
 ## Client Domain (Optional)
 
@@ -63,15 +63,15 @@ Home domain is the optional parameter for SEP-10 authentication, when single aut
 
 :::caution
 
-Some anchors may require `client_domain` to always present as part of the request, even for non-custodial wallets.
+Some anchors may require the `client_domain` to always be present as part of the request, even for non-custodial wallets.
 
 ::: Client domain is used by anchors to verify the origin of user's request (which wallet this user is using?). This is particularly useful for anchors for integrating with non-custodial wallets.
 
-Supporting `client_domain` comes in 2 parts, wallet's client and wallet's server implementations. In this setup, we will have an extra authentication key. This key will be stored remotely, on the server. Using SEP-1 info file anchor will be able to query this key and verify signature. As such, anchor would be able to confirm that request is coming from your wallet, belonging to wallet's `client_domain`.
+Supporting `client_domain` comes in two parts, the wallet's client and the wallet's server implementations. In this setup, we will have an extra authentication key. This key will be stored remotely on the server. Using the SEP-1 info file, the anchor will be able to query this key and verify the signature. As such, the anchor would be able to confirm that the request is coming from your wallet, belonging to wallet's `client_domain`.
 
 ### Client Side
 
-First, let's implement client side. In this example we will connect to remote signer that signs transactions on endpoint `https://demo-wallet-server.stellar.org/sign` for client domain `demo-wallet-server.stellar.org`
+First, let's implement the client side. In this example we will connect to a remote signer that signs transactions on the endpoint `https://demo-wallet-server.stellar.org/sign` for the client domain `demo-wallet-server.stellar.org`.
 
 <CodeExample>
 
@@ -89,11 +89,11 @@ suspend fun getAuthToken(): AuthToken {
 
 :::danger
 
-Demo-wallet signing endpoint is not protected for anybody to use. Your production URL must be protected, otherwise anybody could impersonate your wallet's user.
+The demo-wallet signing endpoint is not protected for anybody to use. Your production URL must be protected, otherwise anybody could impersonate your wallet's user.
 
 :::
 
-Let's add authentication with a bearer token. Simply update request transformer:
+Let's add authentication with a bearer token. Simply update the request transformer:
 
 <CodeExample>
 
@@ -103,7 +103,7 @@ val signer = WalletSigner.DomainSigner("https://demo-wallet-server.stellar.org/s
 
 </CodeExample>
 
-Finally, with the approach above we define signer and client domain per request. If you want to define it once and use it for every authentication call your application is making, you can do so via changing configuration:
+Finally, with the approach above we define the signer and client domain per request. If you want to define it once and use it for every authentication call your application is making, you can do so via changing the configuration:
 
 <CodeExample>
 
@@ -117,11 +117,11 @@ This is particularly useful for integrating with multiple anchors.
 
 ### Server Side
 
-Next, let's implement server side.
+Next, let's implement the server side.
 
-First, generate new authentication key that will be used as a `client_domain` authentication key.
+First, generate a new authentication key that will be used as a `client_domain` authentication key.
 
-Next, create a `SEP-1` toml file placed under `<your domain>/.well-known/stellar.toml` with following content:
+Next, create a `SEP-1` toml file placed under `<your domain>/.well-known/stellar.toml` with the following content:
 
 <CodeExample>
 
@@ -134,7 +134,7 @@ NETWORK_PASSPHRASE = "Test SDF Network ; September 2015"
 
 </CodeExample>
 
-Don't forget to change network passphrase for mainnet deployment.
+Don't forget to change the network passphrase for Mainnet deployment.
 
 Finally, let's add server implementation. This sample implementation uses express framework:
 
@@ -165,8 +165,8 @@ app.post("/sign", (req, res) => {
 
 </CodeExample>
 
-You can see full example [here](https://github.com/stellar/stellar-demo-wallet/blob/52071629f8d29470b61799bef9519776d9c252d2/packages/demo-wallet-server/src/index.ts). As mentioned before, this sample implementation doesn't have any protection against unauthorized requests, so you must add authorization check as part of the request.
+You can see full example [here](https://github.com/stellar/stellar-demo-wallet/blob/52071629f8d29470b61799bef9519776d9c252d2/packages/demo-wallet-server/src/index.ts). As mentioned before, this sample implementation doesn't have any protection against unauthorized requests, so you must add authorization checks as part of the request.
 
 [sep-1]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0001.md
-[sep-10]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0010.md
+[SEP-10]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0010.md
 [stellar lab]: https://laboratory.stellar.org/