Small spelling adjustments

docs/anchoring-assets/enabling-cross-border-payments/launch.mdx

@@ -7,7 +7,7 @@ Once the testnet and mainnet servers are deployed, KYC collection conforms to re
 
 ## Market Making
 
-It is critical for an anchored asset to have liquid trading markets with XLM and ideally partner **SA** assets. Without a deep orderbook, its impossible to facilitate path payments at rates competivtive with equivalent off-chain fiat assets.
+It is critical for an anchored asset to have liquid trading markets with XLM and ideally partner **SA** assets. Without a deep orderbook, its impossible to facilitate path payments at rates competitive with equivalent off-chain fiat assets.
 
 The SDF maintains a trading bot called [Kelp](https://kelpbot.io/) that supports many trading and market making strategies out of the box, all of which are described in [Kelp's Github Repo](https://github.com/stellar/kelp#kelp). You can use Kelp for free and start automating the order placement process in a matter of minutes.
 

docs/anchoring-assets/enabling-cross-border-payments/reference-implementations.mdx

@@ -13,7 +13,7 @@ TODO: REPLACE PNG ![Screenshots of the reference implementation](/assets/polaris
 
 Polaris modularizes the parts of the codebase that interface with the Stellar network, and provides clear methods for developers to integrate their own customer registrations, banking connections, and KYC and transcation processing. That means you can focus on implementing the business- and country-related aspects of your product without having to spend much time defining how to connect the server to the Stellar Network.
 
-If you choose to use Polaris, you can jumpstart your deployment, and connect local rails to Stellar in weeks instead of months.
+If you choose to use Polaris, you can jump-start your deployment, and connect local rails to Stellar in weeks instead of months.
 
 ## Demo Client & Deployed Example
 

docs/anchoring-assets/enabling-cross-border-payments/setting-up-production-server.mdx

@@ -23,7 +23,7 @@ Since the distribution account will be managed programmatically, it should only
 
 Most anchors need to collect [Know Your Customer](https://en.wikipedia.org/wiki/Know_your_customer) information to comply with local regulations before honoring payments. In SEP-31, the **SA** controls the UX for the **SU**. Typically, the **SA** will offer an online or in-app UX, but physical remittance locations are also acceptable. Its also important for **SA**s to be able to contact **SU**s when information must be updated or when the transaction succeeded.
 
-How the **RA** complies with their local regulations by validating KYC information is up the **RA**: there are many services that provide KYC solutions through APIs that validate the input data against governmental databases to verify requirements. Each jurisdiction has specific KYC requirements, and they differ from jurisdiction to jurisdiction, so it's best to find a country-specific KYC provider that meets your needs. Many **RA** organizations can validiate the KYC data collected without using a third-party service.
+How the **RA** complies with their local regulations by validating KYC information is up the **RA**: there are many services that provide KYC solutions through APIs that validate the input data against governmental databases to verify requirements. Each jurisdiction has specific KYC requirements, and they differ from jurisdiction to jurisdiction, so it's best to find a country-specific KYC provider that meets your needs. Many **RA** organizations can validate the KYC data collected without using a third-party service.
 
 Some countries require different KYC fields depending on the payment amount. If that's the case in an **RA**'s jurisdiction, the **RA** needs to expect and support different KYC `type` values in `GET /customer` requests. Only one `type` value can be specified in the `/info` response per-customer, so a different large-payment `type` value will have to be documented and communicated to the **RA**'s partner **SA**s outside the SEP.
 

docs/anchoring-assets/enabling-cross-border-payments/setting-up-test-server.mdx

@@ -63,15 +63,15 @@ For example, the SDF's reference server has the following `/info` response:
 
 </CodeExample>
 
-It has a single `SRT` asset enabled with minimum and maximum amounts and both fixed rate and percetage fees taken from the amount received. If the receiving anchor has a complex fee structure that can't be expressed with the fee attributes from `/info`, sending anchors can support a `/fee` endpoint. Unfortunately, this endpoint is a pending change to the SEP that has not yet been approved. An update will be made when the `/fee` endpoint specification is finalized.
+It has a single `SRT` asset enabled with minimum and maximum amounts and both fixed rate and percentage fees taken from the amount received. If the receiving anchor has a complex fee structure that can't be expressed with the fee attributes from `/info`, sending anchors can support a `/fee` endpoint. Unfortunately, this endpoint is a pending change to the SEP that has not yet been approved. An update will be made when the `/fee` endpoint specification is finalized.
 
 The `sender_sep12_type` and `receiver_sep12_type` keys signal to the to the **SA** application that [SEP-12](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0012.md) customer registration is required for both the **SU** and **RU**. The values of these attributes are the values the **SA** should include in the `GET /customer?type=<SEP-12 type value>` request for each user. In this context, users are synonymous with customers.
 
 The `fields` object contains the single `transaction` key-value pair, which contains the custom fields the **RA** requires from the **SA**. Typically, these attributes are off-chain rails-related attributes like routing and banking numbers. **SA**s should be aware of their partner **RA**'s `fields.transaction` required attributes and should ideally validate the collected information from the **SU** prior to making the `POST /transaction` API call on the **RA**'s server.
 
 <Alert>
 
-Note: Generally, **RA**s should require the KYC fields of the **SU** and **RU** to be sent via SEP-12 and per-transaction information via SEP-31's `POST /transaction` endpoint in the `forms.transactions` object. Be aware that **SU**s must be able to understand what fields to collect for your service and ideally how to validate. Vauge descriptions or poorly named attributes will cause confusion.
+Note: Generally, **RA**s should require the KYC fields of the **SU** and **RU** to be sent via SEP-12 and per-transaction information via SEP-31's `POST /transaction` endpoint in the `forms.transactions` object. Be aware that **SU**s must be able to understand what fields to collect for your service and ideally how to validate. Vague descriptions or poorly named attributes will cause confusion.
 
 </Alert>
 
@@ -309,7 +309,7 @@ Check out the [SEP-31 standard](https://github.com/stellar/stellar-protocol/blob
 
 ## Streaming Incoming Path Payments
 
-Receving anchors (**RA**s) must be able to detect and match incoming Stellar path payment transactions with receiving users. This can be done one of two ways:
+Receiving anchors (**RA**s) must be able to detect and match incoming Stellar path payment transactions with receiving users. This can be done one of two ways:
 
 - Polling: this option consists of periodically fetching the transactions submitted _after_ an already-seen transaction's `paging_id` that should be updated after each iteration.
 - Streaming: this option consists of maintaining a persistent process that streams incoming transactions from the anchored asset's distribution account, which allows detection and transaction matching in close to real time.

docs/anchoring-assets/enabling-deposit-and-withdrawal/reference-implementations.mdx

@@ -13,7 +13,7 @@ To help with server setup, SDF created [Polaris](https://github.com/stellar/djan
 
 Polaris modularizes the parts of the codebase that interface with the Stellar network, and provides clear methods for developers to integrate their own deposit and withdrawal forms, KYC process, and banking rails connections. That means you can focus on implementing the business- and country-related aspects of your product without having to spend much time defining how to connect the server to the Stellar Network.
 
-If you choose to use Polaris, you can jumpstart your deployment, and connect local rails to Stellar in weeks instead of months.
+If you choose to use Polaris, you can jump-start your deployment, and connect local rails to Stellar in weeks instead of months.
 
 ## Demo Client & Deployed Example
 

docs/anchoring-assets/enabling-deposit-and-withdrawal/setting-up-test-server.mdx

@@ -241,6 +241,6 @@ There are a number of UI pages that should be served to the user while walking t
 - Withdrawal information: The issuer needs to collect the numerical amount of the asset to transfer. There may be other pieces of data you want to collect as well. Make sure you have all the information necessary to submit a successful transaction to the stellar network.
 - Waiting for transfer: Once the issuer has collected all the information needed for a withdrawal, the last page rendered in the interactive flow should make a `postMessage` call to the Wallet, notifying the wallet that it has all the information it needs.
 
-The wallet then submits the transaction to the Stellar network that sends tokens from the user’s Stellar account to the issuer’s Stellar account, andl begins polling the issuer’s `/transaction` endpoint until the relevant transaction has the expected status. For withdrawals, the expected status is “complete.”
+The wallet then submits the transaction to the Stellar network that sends tokens from the user’s Stellar account to the issuer’s Stellar account, and begins polling the issuer’s `/transaction` endpoint until the relevant transaction has the expected status. For withdrawals, the expected status is “complete.”
 
 The issuer should detect that the wallet has submitted a withdrawal transaction by streaming transaction events for the user’s account. Once a matching transaction has been detected, the issuer should mark the transaction as “complete” if it succeeds on the Stellar network, or “error” if there was a problem.

docs/anchoring-assets/index.mdx

@@ -3,7 +3,7 @@ title: Overview
 sidebar_position: 0
 ---
 
-_Stellar Anchors_ are the on/off ramps of the Stellar network: they accept deposits of fiat currencies (such as USD, CNY, and BRL) via existing rails (such as bank deposits or cash-in points), and send a user the equivalent digital tokens representing those deposits on the Stellar network. On the flipside, they allow holders to redeem those tokens for the real-world assets they represent. To read more about the kinds of things you can do with digital fiat currency, check out [this explainer](https://www.stellar.org/learn/the-power-of-stellar).
+_Stellar Anchors_ are the on/off ramps of the Stellar network: they accept deposits of fiat currencies (such as USD, CNY, and BRL) via existing rails (such as bank deposits or cash-in points), and send a user the equivalent digital tokens representing those deposits on the Stellar network. On the flip-side, they allow holders to redeem those tokens for the real-world assets they represent. To read more about the kinds of things you can do with digital fiat currency, check out [this explainer](https://www.stellar.org/learn/the-power-of-stellar).
 
 Stellar Anchors can issue their own assets (in which case, they earn the title _Issuing Anchors_), or they can honor assets that already exist on the network. So if you want to build an on/off ramp for Stellar, you can consult the [Issue Assets](../issuing-assets/index.mdx) section and issue your own token to offer customers _or_ you can find another organization that issues a Stellar-network asset and arrange to broker their token.
 
@@ -30,4 +30,4 @@ Each of the backend services described in these protocols can be implemented usi
 1. Deploying the same service on Stellar's Mainnet network and connecting the anchor's existing off-chain rails
 1. Integrating with existing wallets or anchors on Stellar and launching the product
 
-See the [Enabling Deposits and Withdrawals](./enabling-deposit-and-withdrawal/index.mdx) or [Enabling Cross-Border Payments](./enabling-cross-border-payments/index.mdx) sections for SEP-24 or 31, repectively.
+See the [Enabling Deposits and Withdrawals](./enabling-deposit-and-withdrawal/index.mdx) or [Enabling Cross-Border Payments](./enabling-cross-border-payments/index.mdx) sections for SEP-24 or 31, respectively.

docs/building-apps/basic-wallet.mdx

@@ -18,7 +18,7 @@ In this tutorial, the goal is to get to a place where a user can create, store,
 
 Because we've decided to build a non-custodial wallet, we don’t need to communicate with a server or database at all: everything can happen locally right on a user’s device. We’ll be doing all our work inside of `src/components/wallet/`, so head over there now. We’re going to use the `StellarSdk.Keypair.random()` from the StellarSdk to generate a new valid Stellar keypair. That's the easy part. The hard work will be storing that vital information in a secure yet accessible manner.
 
-The user flow we're building will work like this: Click “Create Account” → UI modal popup asking for a pincode → Enter pincode, click “OK” → App encrypts a new Stellar keypair secret key with pincode → App saves encrypted secret to `localStorage`. On page reload, we’ll fetch the `publicKey` to “login” the user, but for any protected action such as “Copy Secret”, the modal will pop back up asking for the original pincode.
+The user flow we're building will work like this: Click “Create Account” → UI modal popup asking for a pin code → Enter pin code, click “OK” → App encrypts a new Stellar keypair secret key with pin code → App saves encrypted secret to `localStorage`. On page reload, we’ll fetch the `publicKey` to “login” the user, but for any protected action such as “Copy Secret”, the modal will pop back up asking for the original pin code.
 
 ## Create a Popup Modal
 

docs/building-apps/connect-to-anchors/deposit-anchored-assets.mdx

@@ -278,9 +278,9 @@ console.log(auth);
 
 </CodeExample>
 
-This call is actually a part of [SEP-0010](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0010.md), which allows us to verify ownership of a user's public key so the Anchor knows the deposit request is coming from a valid entity. You don’t want someone else issuing deposit requests on your account, so to prove you control the Stellar account request the deposit, you sign a dummy authentication transaction and send it to the Anchor's web auth server. The server responds with a JWT token, which will be used to verify all further API calls to the anchor. For more info on how this works, check out the user authetication from an [Anchor's point of view](../../anchoring-assets/enabling-deposit-and-withdrawal/setting-up-test-server.mdx#authentication).
+This call is actually a part of [SEP-0010](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0010.md), which allows us to verify ownership of a user's public key so the Anchor knows the deposit request is coming from a valid entity. You don’t want someone else issuing deposit requests on your account, so to prove you control the Stellar account request the deposit, you sign a dummy authentication transaction and send it to the Anchor's web auth server. The server responds with a JWT token, which will be used to verify all further API calls to the anchor. For more info on how this works, check out the user authentication from an [Anchor's point of view](../../anchoring-assets/enabling-deposit-and-withdrawal/setting-up-test-server.mdx#authentication).
 
-The endpoint for creating an authenticated user session is specified the `WEB_AUTH_ENDPOINT` on an Anchor's stellar.toml file. The first thing our wallet does is make a GET request with a public `account` param which will send back an unsigned Stellar transaction for that account that has in invalide sequence number, so it doesn't actually _do_ anything when submitted to the network. In response you’ll sign that transaction on behalf of the user and POST it back. If the signature checks out, the success response will contain an Authorization Bearer header JWT which you’ll want to store and use for all future interactions with the Anchor.
+The endpoint for creating an authenticated user session is specified the `WEB_AUTH_ENDPOINT` on an Anchor's stellar.toml file. The first thing our wallet does is make a GET request with a public `account` param which will send back an unsigned Stellar transaction for that account that has in invalid sequence number, so it doesn't actually _do_ anything when submitted to the network. In response you’ll sign that transaction on behalf of the user and POST it back. If the signature checks out, the success response will contain an Authorization Bearer header JWT which you’ll want to store and use for all future interactions with the Anchor.
 
 ## Initiate Deposit
 

docs/building-apps/connect-to-anchors/index.mdx

@@ -7,7 +7,7 @@ Stellar makes it easy to issue assets and to connect them to existing banking ra
 
 Most Anchors set up infrastructure to enable wallets to offer in-app deposits and withdrawals by following best practices specified in Stellar Ecosystem Proposals. SEPs are publicly created, open-source documents that live in a [Github repository](https://github.com/stellar/stellar-protocol/tree/master/ecosystem#stellar-ecosystem-proposals-seps). They define how different institutions (such as asset issuers, wallets, exchanges, and service providers) should interact and interoperate. If you're building an app, you can implement the client side of some key SEPs and immediately give your users access to a whole world of local fiat currencies
 
-This part of the tutorial will focus on the Interactive Anchor/Wallet Asset Transfer Server SEP (aka SEP-24), which defines the specs for deposit and withdrawal implementations. It's focused on the client side of interactive user flows — meaning flows where users interact with an Anchor-hosted interface rendered inside a wallet — and by the end, you should have an implemenation which can be re-purposed to work with any SEP-supporting Anchor.
+This part of the tutorial will focus on the Interactive Anchor/Wallet Asset Transfer Server SEP (aka SEP-24), which defines the specs for deposit and withdrawal implementations. It's focused on the client side of interactive user flows — meaning flows where users interact with an Anchor-hosted interface rendered inside a wallet — and by the end, you should have an implementation which can be re-purposed to work with any SEP-supporting Anchor.
 
 When you implement SEP-0024, users can tokenize their grocery-buying dollars, pesos, or naira, use them on the Stellar network and, when they're ready, redeem them for cash in hand or money in the bank — and they can do it all from the comfort of your app.
 

docs/building-apps/connect-to-anchors/withdraw-anchored-assets.mdx

@@ -221,7 +221,7 @@ export default async function withdrawAsset(e: Event) {
 
 </CodeExample>
 
-We’ll actually skip everything except the stuff that is significantly different than the [deposit flow](./deposit-anchored-assets.mdx). The main difference between the two is who submits the Stellar transaction: in the deposit flow the anchor is sends the wallet a Stellar asset; in the withdraw flow the wallet sends the asset to the anchor. So for the witdraw flow, we’ll need to build and submit a payment transaction.
+We’ll actually skip everything except the stuff that is significantly different than the [deposit flow](./deposit-anchored-assets.mdx). The main difference between the two is who submits the Stellar transaction: in the deposit flow the anchor is sends the wallet a Stellar asset; in the withdraw flow the wallet sends the asset to the anchor. So for the withdraw flow, we’ll need to build and submit a payment transaction.
 
 ## Create and Submit Payment Transaction
 

docs/building-apps/custom-assets.mdx

@@ -8,7 +8,7 @@ import { Alert } from "@site/src/components/Alert";
 
 <Alert>
 
-In this section of the tutorial, we'll add the ability to hold and transfer custom assets to the basic wallet we built in previous sections. It asssumes that you've already completed [Build a Basic Wallet](./basic-wallet.mdx) and [Make XLM Payments](./xlm-payments.mdx).
+In this section of the tutorial, we'll add the ability to hold and transfer custom assets to the basic wallet we built in previous sections. It assumes that you've already completed [Build a Basic Wallet](./basic-wallet.mdx) and [Make XLM Payments](./xlm-payments.mdx).
 
 </Alert>