editorial

docs/build/apps/guestbook/bindings.mdx

@@ -115,7 +115,7 @@ node initialize.js
 
 :::info
 
-For a more comprehensive overview of process of creating, customizing, and using initialization scripts like this, check out the [frontend template guide](https://developers.stellar.org/docs/build/guides/dapps/soroban-contract-init-template).
+For a more comprehensive overview of the process of creating, customizing, and using initialization scripts like this, check out the [frontend template guide](https://developers.stellar.org/docs/build/guides/dapps/soroban-contract-init-template).
 
 :::
 
@@ -127,4 +127,4 @@ pnpm run setup
 
 Right, so we've now created a starter project, written a guestbook smart contract, and generated an NPM package that will help us interact with that contract on the network. Amazing!
 
-Next up, let's take a look at how our users will connect with and interact with our dapp. It's time for passkeys! (insert air horn noises)
+Next up, let's take a look at how our users will connect with and interact with our dapp. It's time for passkeys! (insert air horn noises)📢

docs/build/apps/guestbook/frontend.mdx

@@ -17,7 +17,7 @@ We're using some pieces of [Svelte state](https://svelte.dev/docs/svelte/$state)
 
 ### Connect Buttons Setup
 
-We have a component in `$lib/components/connectButtons.svelte` that houses all the signup, login, logout functionality. This gets put into the header component, and is available throughout the entirety of the Dapp. The basic premise of this component is that we have a collection of buttons, as well as the corresponding functions which should take place when the button is clicked.
+We have a component in `$lib/components/connectButtons.svelte` that houses all the signup, login, and logout functionality. This gets put into the header component, and is available throughout the entirety of the dapp. The basic premise of this component is that we have a collection of buttons, as well as the corresponding functions that should take place when the button is clicked.
 
 The buttons themselves are simple enough:
 
@@ -228,7 +228,7 @@ We're simplifying this function _just a bit_ for this tutorial. In the [real dap
 
 All in, that's a pretty easy invocation of the SAC's `transfer` function. We just pass the `from`, `to`, and `amount` fields. Then, we sign the transaction with our `account` instance, providing our passkey ID in the arguments. Finally, we send the transaction using our helper function, which will fire off the request to Launchtube, and we'll be good to go. In this case, we're not really stressed about the return value. We'll just catch any errors, and notify the user with a toast message.
 
-Enough of the account and asset things, let's get to the gestbook entries!
+Enough of the account and asset things, let's get to the guestbook entries!
 
 ## Sign the guestbook
 
@@ -365,7 +365,7 @@ export const load: PageServerLoad = async ({ params }) => {
 };
 ```
 
-You can see here we're using one of the contract functions, `read_message` to get the data. This is a "read-only" function, meaning that no on-chain state is modified when it's run. So, we can just simulate the invocation, which is already done for you when the bindings-generated function is called, and just take the data from the simulation response! Pretty neat, right!
+You can see here we're using one of the contract functions, `read_message` to get the data. This is a "read-only" function, meaning that no on-chain state is modified when it's run. So, we can just simulate the invocation, which is already done for you when the bindings-generated function is called, and just take the data from the simulation response! Pretty neat, right?!
 
 We pass the resulting message details back to the page, where it will be displayed.
 

docs/build/apps/guestbook/passkeys-prerequisites.mdx

@@ -13,11 +13,11 @@ Before we get into the nitty gritty on passkeys, we have some chores to do. Firs
 
 Let's start with [Launchtube](https://launchtube.xyz). As we mentioned earlier, Launchtube is similar to a "paymaster" service, if you're familiar with account abstraction in EVM networks. We won't actually need to interact with Launchtube _directly_. All that will be handled by the `passkey-kit` package. However, we'll need to get a JWT token that will allow us to authenticate our dapp with Launchtube.
 
-For Testnet Launchtube tokens, we can generate one any time we like. All you have to do is visit `https://testnet.launchtube.xyz/gen` to receive a JWT token that will be valid for 3 months, and will have 100 XLM in credits (these credits will be consumed when you submit network transactions through Launchtube). Go ahead, [give it a try](https://testnet.launchtube.xyz/gen)!
+For Testnet Launchtube tokens, we can generate one any time we like. All you have to do is visit `https://testnet.launchtube.xyz/gen` to receive a JWT token that will be valid for three months, and will have 100 XLM in credits (these credits will be consumed when you submit network transactions through Launchtube). Go ahead, [give it a try](https://testnet.launchtube.xyz/gen)!
 
 :::tip
 
-We do have Mainnet Launchtube tokens available! You can request a token in the [`#launchtube` channel](https://discord.com/channels/897514728459468821/1293204627361108141) on our [Stellar Developers Discord server](https://discord.gg/stellardev). In particular, pinging `@kalepail`, `@ElliotFriend`, `@carsten.xlm`, or `@Chris.anatalio.xlm` should get you on your way pretty quickly.
+We do have Mainnet Launchtube tokens available! You can request a token in the [`#launchtube` channel](https://discord.com/channels/897514728459468821/1293204627361108141) on our [Stellar Developer Discord server](https://discord.gg/stellardev). In particular, pinging `@kalepail`, `@ElliotFriend`, `@carsten.xlm`, or `@Chris.anatalio.xlm` should get you on your way pretty quickly.
 
 :::
 
@@ -46,7 +46,7 @@ The `passkey-kit` package doesn't "ship" with a Zephyr program in the published
    cd passkey-kit/zephyr
    ```
 
-2. Get an authentication token from the Mercury website. You can login to the [Testnet dashboard](https://test.mercurydata.app/) here. Click on the **Get access token** button under the "Active subscriptions" section. You'll be given a JWT which will be valid for the next 7 days.
+2. Get an authentication token from the Mercury website. You can login to the [Testnet dashboard](https://test.mercurydata.app/) here. Click on the **Get access token** button under the "Active subscriptions" section. You'll be given a JWT which will be valid for the next seven days.
 
    ![Mercury Data JWT Token](/img/tutorial/guestbook/mercury_token.png)
 
@@ -92,4 +92,4 @@ It's possible something has gone wrong during your execution of the processes ab
 2. **Make sure your Zephyr program successfully deployed.** I've been stuck more than once with a not-working Mercury request because the Zephyr program hadn't actually deployed successfully. Make sure the `mercury-cli deploy` command's output doesn't have any errors in it.
 3. **Check the [Mercury documentation](https://docs.mercurydata.app/).** It's quite good and can help you get past a lot of the hurdles you might face.
 
-In any case, feel free to ask questions or drop a chat in the [`#passkeys`](https://discord.com/channels/897514728459468821/1250851135561142423) and [`#launchtube`](https://discord.com/channels/897514728459468821/1293204627361108141) channels in the Stellar Developers Discord server. There's usually somebody around who's ready and willing to help out!
+In any case, feel free to ask questions or drop a chat in the [`#passkeys`](https://discord.com/channels/897514728459468821/1250851135561142423) and [`#launchtube`](https://discord.com/channels/897514728459468821/1293204627361108141) channels in the Stellar Developer Discord server. There's usually somebody around who's ready and willing to help out!

docs/build/apps/guestbook/setup-passkeys.mdx

@@ -41,7 +41,7 @@ Now, we've also added some useful "helpers" into the `$lib/passkeyClient.ts` fil
   export const rpc = new Server(PUBLIC_STELLAR_RPC_URL);
   ```
 
-- A SAC client to interact with the native XLM asset contract. We're making an assumption that native Lumens is a "good enough" asset interaction to get the tutorial working, and for playing on Testnet. You could easily export _another_ SAC client to interact with USDC, for example.
+- A SAC client to interact with the native XLM asset contract. We're making an assumption that native lumens is a "good enough" asset interaction to get the tutorial working, and for playing on Testnet. You could easily export _another_ SAC client to interact with USDC, for example.
 
   ```js title="src/lib/passkeyClient.ts"
   import { SACClient } from "passkey-kit";
@@ -64,7 +64,7 @@ Now, we've also added some useful "helpers" into the `$lib/passkeyClient.ts` fil
 
 ## Passkey server
 
-So, that's the client-facing passkey code (and some helpers) taken care of. What about the server-side, where we want to be cautious about leaking secrets and token?!
+So, that's the client-facing passkey code (and some helpers) taken care of. What about the server-side, where we want to be cautious about leaking secrets and tokens?!
 
 We're setting this up in `src/lib/server/passkeyServer.ts`, for similar reasons we listed above. This gives us an importable `server` instance that can be accessed and used in other server-side logic. Svelte gives us the added benefit of [keeping the code in this directory safe](https://svelte.dev/docs/kit/server-only-modules#Your-modules). When we want to safeguard credentials and secrets, we can put any sensitive code in the `$lib/server` directory.