env: line edits

src/technical/env/environments.md

@@ -6,14 +6,18 @@ However, as you get deeper into cross-chain development, you'll likely find your
 
 ### What components do I need now? What components will I need in the future?
 
-- You may be able to get a lot done with just an EVM chain and a Guardian. However, as your application gets more sophisticated, components like relayers, frontends, automated tests, databases, explorers, and other blockchains are likely to get added in to the environment.
+- You may be able to get a lot done with just an EVM chain and a Guardian. However, as your application gets more sophisticated, components like relayers, frontends, automated tests, databases, explorers, and other blockchains are likely to get added into the environment.
 
 ### What are my dependencies?
 
 - If your smart contracts have no dependencies, it may be possible for you to develop in a vacuum.
 
-- If your smart contracts does have dependencies, there are several options that range from deploying your dependencies in Tilt or use something like [Foundry](https://github.com/foundry-rs/foundry) to simulate an existing testnet or mainnet in your local devnet to working to working directly in testnet alongside other teams.
+- If your smart contracts does have dependencies, there are several options that range from deploying your dependencies in [Tilt](./tilt.md) to simulating an existing testnet/mainnet in [Foundry](https://github.com/foundry-rs/foundry) to working directly in [testnet](./testnet.md) alongside other teams.
 
 ### How am I going to collaborate?
 
 - You should consider how your teammates or collaborators are going to work in this environment from the start. There are some basic considerations like "how will they access it", but also some subtler points such as ensuring that contracts will deploy deterministically and that automated tests can be trusted to run reliably. The two paths to accomplish this are to use a public environment (testnet), or to ensure the local environment is well controlled (like tilt).
+
+---
+
+In the following sections we'll describe three different development environments that are available -- Tilt, Wormhole Local Validator, and Testnet -- in more details as well as some additional tools that should be helpful in your xDapp development.

src/technical/env/testnet.md

@@ -2,21 +2,27 @@
 
 Wormhole testnet is spread across many of the most popular testnet blockchains.
 
+### Is Testnet right for you?
+
 The primary reason to use Wormhole testnet is to simplify the management of your dependent contracts. This will vary from blockchain to blockchain.
 
 For example, some blockchain ecosystems have the standard that their contracts are closed-source, and there are no tools to fork mainnet. Other ecosystems, such as EVM, have tools like [foundry](https://github.com/foundry-rs/foundry), which allow you to hardfork the mainnet ecosystem into a local development node.
 
 In short, testnet tends to be the correct choice only when you have contract dependencies, and those dependencies are difficult to get working in a local environment. In most other cases, testnet tends to be more work than it's worth.
 
-If you elect to use testnet, the Wormhole contracts addresses can be found in the [Reference](../../reference/contracts.md) section.
+Here's a succinct list of the pros and cons of the environment, so you can decide if it's the right fit for you.
 
-### Pros:
+**Pros**
 
 - Many other projects deploy their contracts to testnet.
 - In ecosystems without extensive local tooling, this may be the preferred development environment.
 
-### Cons:
+**Cons**
 
 - Many testnets are somewhat unstable and have outages or partitioning events.
 - Wormhole Testnet sometimes misses VAAs due to testnet instabilities.
 - Testnet tokens are often difficult to acquire.
+
+## Using Testnet
+
+If you elect to use testnet, the Wormhole contracts addresses can be found in the [Contracts](../../reference/contracts.md) page.

src/technical/env/tilt.md

@@ -1,10 +1,10 @@
 # Tilt (Devnet)
 
-### What is Tilt?
+## What is Tilt?
 
 [Tilt](https://tilt.dev/) is part of the official Docker ecosystem. It's a tool which allows developers to easily configure a Kubernetes environment for development.
 
-However, in the context of Wormhole, 'Tilt' usually refers to the development environment used by the [Wormhole Core Repository](https://github.com/wormhole-foundation/wormhole). This environment uses Tilt to stand up docker images for all the tools necessary to build across multiple blockchains, including:
+However, in the context of Wormhole, 'Tilt' refers to the development environment used by the [Wormhole Core Repository](https://github.com/wormhole-foundation/wormhole). This environment stands up docker images for all the tools necessary to build across multiple blockchains, including:
 
 - All the Wormhole supported blockchains / ecosystems
 - A Guardian Node
@@ -12,30 +12,32 @@ However, in the context of Wormhole, 'Tilt' usually refers to the development en
 - Databases, Redis
 - Utility frontends
 
-The 'Tilt' environment (also referred to as Wormhole 'Devnet') is meant to provide an entire cross-chain development stack right out of the box.
+The 'Tilt' environment is meant to provide an entire cross-chain development stack right out of the box.
+
+_Note: Tilt is often referred to as 'Devnet' in the Wormhole ecosystem so any information that is labelled as 'devnet' also applies to Tilt._
 
 ### Is Tilt Right for You?
 
 Tilt is generally a good starting point for most developers. Here's a succinct list of the pros and cons of the environment, so you can decide if it's the right fit for you.
 
-### Pros
+**Pros**
 
-- Out-of-the-box support for the many components needed to develop across the heterogenous blockchain space.
+- Out-of-the-box support for the many components needed to develop across the heterogenous blockchain spaces.
 - Consistent development environment, where contracts deploy deterministically and everything is already linked up.
 - Ability to easily enable/disable components as needed.
 - Regularly updated as new components join the Wormhole ecosystem.
 
-### Cons
+**Cons**
 
-- Relatively high system requirements. This can be mitigated by disabling components.
-- Most blockchains are 'fresh' and have no contracts by default. Thus, you may have to deploy your own dependencies, or alter the default tilt configuration.
-- Spin-up and rebuild times can be slow. This can result in a slow workflow if you rely on docker rebuilds.
+- Relatively high system requirements but this can be mitigated by disabling components.
+- Most blockchains are 'fresh' and have no contracts by default. Thus, if your contracts have any dependencies, you may have to deploy them yourself or alter the default tilt configuration.
+- Spin-up and rebuild times can be slow which can result in a slow workflow.
 
-# Setting up Tilt
+## Setting up Tilt
 
-Tilt functions best in a UNIX-style environment. For Windows users, using a WSL environment is recommended.
+Tilt functions best in a UNIX-style environment. For Windows users, a WSL environment is recommended.
 
-In order to run the Tilt environment, you'll first need to make sure you have [Tilt](https://docs.tilt.dev/install.html) and [Go](https://go.dev/doc/install) installed.
+In order to run the Tilt environment, make sure you have [Tilt](https://docs.tilt.dev/install.html) and [Go](https://go.dev/doc/install) installed.
 
 Once you've installed these two dependencies, just clone the Wormhole Core Repository and start Tilt.
 
@@ -47,25 +49,27 @@ cd wormhole
 tilt up
 ```
 
-Be sure to check out the [**Tiltfile**](https://github.com/wormhole-foundation/wormhole/blob/dev.v2/Tiltfile), which has much of the configuration and arguments for the development environment. It's relatively straightforward to enable and disable components. For example, you can disable blockchains by setting them to false at startup
+Be sure to check out the [**Tiltfile**](https://github.com/wormhole-foundation/wormhole/blob/dev.v2/Tiltfile), which has much of the configuration and arguments for the development environment. It's relatively straightforward to enable and disable components. 
+
+For example, you can disable blockchains by setting them to false at startup
 
 ```
 tilt up -- --algorand=false --near=false --solana=false terra_classic=false terra2=false
 ```
 
-# Using Tilt
+## Using Tilt
 
-Tilt can pretty much be treated as though it's an external environment that you can easily spin up and tear down.
+Tilt can pretty much be treated as an external environment / testnet that you can easily spin up and tear down.
 
 If you've followed the standard setup, all your resources will be bound to various ports on localhost. To see all the endpoints which are being hosted in your Tilt environment, you should check the Tilt dashboard, located at [http://localhost:10350/overview](http://localhost:10350/overview).
 
-Tilt is alos referred to as 'Devnet' in the Wormhole ecosystem, so anywhere you see information labeled as 'Devnet', you can apply it to Tilt.
+All the deployed contract addresses can be found under the 'Devnet / Tilt' section of [contracts](../../reference/contracts.md).
 
-For example, you can find all the deployed contract addresses in the 'Devnet' [constants](https://github.com/wormhole-foundation/wormhole/blob/dev.v2/sdk/js/src/utils/consts.ts) of the Wormhole Typescript SDK.
+Useful information pertaining to funded wallets & private keys can also be found in the [devnet.md](https://github.com/wormhole-foundation/wormhole/blob/dev.v2/docs/devnet.md) file of the docs.
 
-Useful information pertaining to funded wallets & useful private keys can also be found in the [devnet.md](https://github.com/wormhole-foundation/wormhole/blob/dev.v2/docs/devnet.md) file of the docs.
+Additional helpful resources can be found in the [Tooling](./tooling.md) page.
 
-From here, Tilt is quite similar to using Testnet, and you should look at the [Tooling](./tooling.md) page for additional resources.
+## Shutting down Tilt
 
 In order to shut down Tilt, simply run
 

src/technical/env/troubleshooting.md

@@ -6,7 +6,9 @@ Tilt, Kubernetes, and Docker may be new tools for developers entering the Wormho
 
 ## Prerequisites
 
-Having `homebrew` on your system makes the installation really straightforward. You can grab it with:
+Install [Homebrew](https://brew.sh) if you don't already have it.
+
+You can grab it with:
 
 ```sh
 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
@@ -38,9 +40,6 @@ brew install tilt
 
 ```sh
 git clone --branch dev.v2 https://github.com/wormhole-foundation/wormhole.git
-```
-
-```sh
 cd wormhole/
 tilt up
 ```

src/technical/env/wlv.md

@@ -4,17 +4,17 @@
 
 [Wormhole Local Validator](https://github.com/wormhole-foundation/xdapp-book/tree/main/projects/wormhole-local-validator) is meant to be the simplest custom environment. It consists only of a dockerized Guardian image, and some utility tooling to aid with contract management. This allows you to set it up with any blockchain you'd like.
 
-## Is WLV Right for You?
+### Is WLV Right for You?
 
 Here's a succinct list of the pros and cons of the environment, so you can decide if it's the right fit for you.
 
-### Pros
+**Pros**
 
 - Lightweight, low system resource demand.
 - Fast iteration times.
 - Can be added into an existing blockchain development setup.
 
-### Cons
+**Cons**
 
 - You may end up reinventing the tilt/testnet environment as you add more components.
 
@@ -30,4 +30,4 @@ Further information can be found in the project's [README](https://github.com/wo
 
 Q: Anvil isn't working
 
-- While Foundry's 'forge' tool is the generally recommended tool for EVM contract compilation, anvil isn't currently compatible with guardiand. Anvil reports block headers in a way which is non-compliant with go-ethereum, which means the guardian node can't correctly read anvil headers.
+- While Foundry's 'forge' tool is the generally recommended tool for EVM contract compilation, Anvil isn't currently compatible with guardiand. Anvil reports block headers in a way which is non-compliant with go-ethereum, which means the guardian node can't correctly read anvil headers.