diff --git a/docs/getting-started/create-an-app.mdx b/docs/getting-started/create-an-app.mdx
index 6b8fcf4c..a20c5aeb 100644
--- a/docs/getting-started/create-an-app.mdx
+++ b/docs/getting-started/create-an-app.mdx
@@ -1,6 +1,6 @@
 ---
-sidebar_position: 5
-title: 4. Create an App
+sidebar_position: 6
+title: 5. Create an App
 description: Make a frontend web app that interacts with your smart contracts.
 ---
 
@@ -16,7 +16,7 @@ Let's get started.
 
 You're going to need [Node.js](https://nodejs.org/en/download/package-manager/) v18.14.1 or greater. If you haven't yet, install it now.
 
-Then we want to initialize the current directory, `soroban-tutorial`, as an Astro project, but Astro doesn't like that. It wants to create a new directory. So let's go ahead and do that, then move all the contents of the new directory into their parent directory:
+Then we want to initialize the current directory, `soroban-tutorial`, as an Astro project, but Astro doesn't like that. It wants to create a new directory. So let's go ahead and do that, then move all the contents of the new directory into its parent directory. From the original `soroban-tutorial` directory, run:
 
 ```bash
 npm create astro@4.0.1 soroban-tutorial -- --template basics --install --no-git --typescript strictest
@@ -43,74 +43,27 @@ git commit -m "Initialize Astro project"
 
 Before we even open the new frontend files, let's generate an NPM package for the Hello World contract. This is our suggested way to interact with contracts from frontends. These generated libraries work with any JavaScript project (not a specific UI like React), and make it easy to work with some of the trickiest bits of Soroban, like encoding [XDR](https://soroban.stellar.org/docs/fundamentals-and-concepts/fully-typed-contracts).
 
-This is going to use the CLI command `soroban contract bindings typescript`. Unfortunately, the version of `bindings typescript` packaged with CLI v0.9.4 has some bugs, and the fix can't be released yet because the `main` branch of the CLI is broken with futurenet. To work around this, we're going to install a pinned version of the CLI from a fixed-and-still-futurenet-compatible fork. Create a directory called `.cargo` (with the dot; it's a hidden folder):
-
-    mkdir .cargo
-
-Then add one file to it, `config.toml`. Paste these contents into it:
-
-```toml
-[alias] # command aliases
-install_soroban = "install --git https://github.com/AhaLabs/soroban-tools --branch smartdeploy --root ./target soroban-cli --debug"
-```
-
-Now install the pinned version by using the alias you just set up:
-
-    cargo install_soroban
-
-This will take a couple minutes; it builds a local version from the `smartdeploy` branch into `target/bin/soroban`. Once it's done, check that it worked:
-
-```bash
-ls target/bin/soroban
-```
-
-And check the version info of this `smartdeploy` install:
-
-```bash
-./target/bin/soroban --version
-```
-
-If you want, you can add `./target/bin/` [to your PATH](https://unix.stackexchange.com/questions/26047/how-to-correctly-add-a-path-to-path), so that anytime you're in a project with a locally-installed version of `soroban` in its `target/bin` directory, you'll automatically use it (rather than your global version) when you just type `soroban`. For this project, let's also add a `soroban` script in the root of the project that automatically installs the pinned version if it's not there, then uses it. This will make it easier for your collaborators to work with you. Create a file called just `soroban` and paste the following contents:
+This is going to use the CLI command `soroban contract bindings typescript`:
 
 ```bash
-#!/bin/bash
-if [ ! -f ./target/bin/soroban ]; then
-  cargo install_soroban
-fi
-./target/bin/soroban "$@" # `$@` expands to all arguments passed to this script
-```
-
-Make sure it's executable:
-
-```bash
-chmod +x soroban
-```
-
-Ok, now you can finally generate that NPM package:
-
-```bash
-./soroban contract bindings typescript \
+soroban contract bindings typescript \
   --network testnet \
   --contract-id $(cat .soroban/hello-id) \
-  --output-dir hello-soroban-client
+  --output-dir node_modules/hello-soroban-client
 ```
 
 We attempt to keep the code in these generated libraries readable, so go ahead and look around. Open up the new `hello-soroban-client` directory in your editor. If you've built or contributed to Node projects, it will all look familiar. You'll see a `package.json` file, a `src` directory, a `tsconfig.json`, and even a README. The README is a great place to start. Go ahead and give it a read.
 
-As it says, when using local libraries, we've had the [most success](https://github.com/stellar/soroban-example-dapp/pull/117#discussion_r1232873560) when generating them directly into the `node_modules` folder, and leaving them out of the `dependencies` section. Yes, this is surprising, but it works the best. Go ahead and move this new library there:
-
-```bash
-mv hello-soroban-client node_modules
-```
+As it says, when using local libraries, we've had the [most success](https://github.com/stellar/soroban-example-dapp/pull/117#discussion_r1232873560) when generating them directly into the `node_modules` folder, and leaving them out of the `dependencies` section. Yes, this is surprising, but it works the best.
 
-And then let's update the `package.json` in your `soroban-tutorial` project with a `postinstall` script to make sure the generated library stays up-to-date:
+Let's update the `package.json` in your `soroban-tutorial` project with a `postinstall` script to make sure the generated library stays up-to-date:
 
-```diff
+```diff title="package.json"
   "scripts": {
     ...
 -   "astro": "astro"
 +   "astro": "astro",
-+   "postinstall": "./soroban contract bindings typescript --network testnet --contract-id $(cat .soroban/hello-id) --output-dir node_modules/hello-soroban-client"
++   "postinstall": "soroban contract bindings typescript --network testnet --contract-id $(cat .soroban/hello-id) --output-dir node_modules/hello-soroban-client"
   }
 ```
 
@@ -118,7 +71,7 @@ And then let's update the `package.json` in your `soroban-tutorial` project with
 
 Now let's open up `src/pages/index.astro` and add some code to call the contract. We'll start by importing the generated library:
 
-```diff
+```diff title="src/pages/index.astro"
  ---
  import Layout from '../layouts/Layout.astro';
  import Card from '../components/Card.astro';
@@ -135,7 +88,7 @@ Now let's open up `src/pages/index.astro` and add some code to call the contract
 
 Then find the `<h1>` tag and replace its contents with the greeting:
 
-```diff
+```diff title="src/pages/index.astro"
 -<h1>Welcome to <span class="text-gradient">Astro</span></h1>
 +<h1><span class="text-gradient">{greeting.join(' ')}</span></h1>
 ```
@@ -146,7 +99,7 @@ Now start the dev server:
 npm run dev
 ```
 
-And open [http://localhost:3000](http://localhost:3000) in your browser. You should see the greeting from the contract!
+And open [http://localhost:4321](http://localhost:4321) in your browser. You should see the greeting from the contract!
 
 You can try updating the `{ to: 'Soroban' }` argument. When you save the file, the page will automatically update.
 
@@ -177,10 +130,11 @@ While `hello` is a simple view-only/read method, `increment` changes on-chain st
 
 The way signing works in a browser is with a _wallet_. Wallets can be web apps, browser extensions, standalone apps, or even separate hardware devices.
 
-Right now, the wallet that best supports Soroban is
-[Freighter](../reference/freighter.mdx). It's a Chrome extension. Go ahead and [install it now](https://freighter.app).
+Right now, the wallet that best supports Soroban is [Freighter](../reference/freighter.mdx). It is available as a Firefox Add-on, as well as extensions for Chrome and Brave. Go ahead and [install it now](https://freighter.app).
 
-Once it's installed, open it up, go to Settings (the gear icon) → Preferences and toggle the switch to Enable Experimental Mode. Then go back to its home screen and select "Future Net" from the top-right dropdown. Finally, if it shows the message that your Stellar address is not funded, go ahead and click the "Fund with Friendbot" button.
+Once it's installed, open it up by clicking the extension icon. If this is your first time using Freighter, you will need to create a new wallet. Go through the prompts to create a password and save your recovery passphrase.
+
+Go to Settings (the gear icon) → Preferences and toggle the switch to Enable Experimental Mode. Then go back to its home screen and select "Test Net" from the top-right dropdown. Finally, if it shows the message that your Stellar address is not funded, go ahead and click the "Fund with Friendbot" button.
 
 Now you're all set up to use Freighter as a user, and you can add it to your app.
 
@@ -202,7 +156,7 @@ npm run postinstall
 
 Now let's add a new component to the `src/components` directory called `ConnectFreighter.astro` with the following contents:
 
-```html
+```html title="src/components/ConnectFreighter.astro"
 <div id="freighter-wrap" class="wrap" aria-live="polite">
   <div class="ellipsis">
     <button data-connect aria-controls="freighter-wrap">Connect</button>
@@ -270,7 +224,7 @@ Before we add this to our index page, let's make the buttons look better. Open `
 
 <!-- prettier-ignore-start -->
 <!-- Astro uses tabs. It's not worth fighting or mentioning, let's just make the pasted code look good with the rest-->
-```css
+```css title="layouts/Layout.astro"
 button {
 	border: 1px solid rgb(var(--accent));
 	background-color: #23262d;
@@ -302,7 +256,7 @@ This copies the styles from the `Card` components that Astro included in the tem
 
 Now we can import the component in the frontmatter of `pages/index.astro`:
 
-```diff
+```diff title="pages/index.astro"
  ---
  import Layout from '../layouts/Layout.astro';
  import Card from '../components/Card.astro';
@@ -313,7 +267,7 @@ Now we can import the component in the frontmatter of `pages/index.astro`:
 
 And add it right below the `<h1>`:
 
-```diff
+```diff title="pages/index.astro"
  <h1><span class="text-gradient">{greeting.join(' ')}</span></h1>
 +<ConnectFreighter />
 ```
@@ -330,11 +284,11 @@ Now you're ready to sign the call to `increment`!
 
 ### Call `increment`
 
-We're going to generate a contract client for the incrementor contract with a similar command to the one we used before. Let's move the `hello` bindings generation to its own script, add this one, and call them both from `postinstall` using a double ampersand ([&&](https://stackoverflow.com/a/25669618/249801)):
+We're going to generate a contract client for the incrementor contract with a similar command to the one we used before. Let's move the `hello` bindings generation to its own script, add one for incrementor, and call them both from `postinstall` using a double ampersand ([&&](https://stackoverflow.com/a/25669618/249801)):
 
-```json
-"bindings:hello": "./soroban contract bindings typescript --network testnet --contract-id $(cat .soroban/hello-id) --output-dir node_modules/hello-soroban-client",
-"bindings:incrementor": "./soroban contract bindings typescript --network testnet --contract-id $(cat .soroban/incrementor-id) --output-dir node_modules/incrementor-client",
+```json title="package.json"
+"bindings:hello": "soroban contract bindings typescript --network testnet --contract-id $(cat .soroban/hello-id) --output-dir node_modules/hello-soroban-client",
+"bindings:incrementor": "soroban contract bindings typescript --network testnet --contract-id $(cat .soroban/incrementor-id) --output-dir node_modules/incrementor-client",
 "postinstall": "npm run bindings:hello && npm run bindings:incrementor"
 ```
 
@@ -346,14 +300,19 @@ npm i
 
 Now we can import from `incrementor-client` and start using it. We'll again create a new Astro component. Create a new file at `src/components/Counter.astro` with the following contents:
 
-```html
+```html title="src/components/Counter.astro"
 <strong>Incrementor</strong><br />
 Current value: <strong id="current-value" aria-live="polite">???</strong><br />
 <br />
 <button data-increment aria-controls="current-value">Increment</button>
 
 <script>
-  import { increment } from "incrementor-client";
+  import { Contract, networks } from "incrementor-client";
+
+  const incrementor = new Contract({
+    ...networks.testnet,
+    rpcUrl: "https://soroban-testnet.stellar.org", // from https://soroban.stellar.org/docs/reference/rpc-list#sdf-futurenet-and-testnet-only
+  });
 
   const button = document.querySelector("[data-increment]");
   const currentValue = document.querySelector("#current-value");
@@ -365,7 +324,7 @@ Current value: <strong id="current-value" aria-live="polite">???</strong><br />
       currentValue.innerHTML +
       '<span class="visually-hidden"> – updating…</span>';
 
-    const newValue = await increment();
+    const newValue = await incrementor.increment();
 
     // Only use `innerHTML` with contract values you trust!
     // Blindly using values from an untrusted contract opens your users to script injection attacks!
@@ -385,7 +344,7 @@ Let's add styles for `visually-hidden` and `loading` class. In `layouts/Layout.a
 
 <!-- prettier-ignore-start -->
 <!-- Astro uses tabs. It's not worth fighting or mentioning, let's just make the pasted code look good with the rest-->
-```css
+```css title="layouts/Layout.astro"
 button:is(:disabled).loading {
 	background: linear-gradient(-45deg, #ffffff44, #ffffff22);
 	background-size: 200%;
@@ -413,19 +372,19 @@ button:is(:disabled).loading {
 
 Now let's use this component. In `pages/index.astro`, first import it:
 
-```diff
+```diff title="pages/index.astro"
  ---
  import Layout from '../layouts/Layout.astro';
  import Card from '../components/Card.astro';
  import ConnectFreighter from '../components/ConnectFreighter.astro';
 +import Counter from '../components/Counter.astro';
- import { hello } from 'hello-soroban-client';
+ import { Contract, networks } from "hello-soroban-client";
  ...
 ```
 
 Then use it. Let's replace the contents of the `instructions` paragraph with it:
 
-```diff
+```diff title="pages/index.astro"
  <p class="instructions">
 -  To get started, open the directory <code>src/pages</code> in your project.<br />
 -  <strong>Code Challenge:</strong> Tweak the "Welcome to Astro" message above.
@@ -435,8 +394,7 @@ Then use it. Let's replace the contents of the `instructions` paragraph with it:
 
 Check the page; if you're still running your dev server, it should have already updated. Click the "Increment" button; you should see a Freighter confirmation. Confirm, and... the value updates! 🎉
 
-There's obviously some functionality missing, though. For example, that `???` is a bummer. But our `incrementor` contract doesn't give us a way to query the
-current value without also updating it.
+There's obviously some functionality missing, though. For example, that `???` is a bummer. But our `incrementor` contract doesn't give us a way to query the current value without also updating it.
 
 Before you try to update it, let's streamline the process around building, deploying, and generating clients for contracts.
 
@@ -446,7 +404,7 @@ Right now, the `postinstall` script assumes that you already have a `.soroban` d
 
 First, let's add a `clean` script that removes the `.soroban` directory to make it easy to go back to how collaborators will experience this repository when they first clone it. We'll also remove the `node_modules/.vite` directory, which is where Astro caches its build artifacts ([Vite](https://vitejs.dev/) is a build tool [used by Astro](https://docs.astro.build/en/reference/configuration-reference/#vite)). Add the following to the `scripts` section of `package.json`:
 
-```json
+```json title="package.json"
 "scripts": {
   "clean": "rm -rf .soroban node_modules/.vite",
   ...
@@ -455,21 +413,21 @@ First, let's add a `clean` script that removes the `.soroban` directory to make
 
 Next, let's add a `setup` script that builds your contracts, then checks if the `.soroban` folder is present, and if not, creates and funds the `alice` identity and deploys your contracts. This is a lot for a single NPM script, so we've broken it into a few to make it a little more legible. Add the following to the `scripts` section of `package.json`:
 
-```json
+```json title="package.json"
   "scripts": {
     ...
-   "create_deployer": "./soroban config identity generate alice && ./soroban config identity fund alice --network testnet",
-   "deploy:hello": "./soroban contract deploy --wasm target/wasm32-unknown-unknown/release/hello_soroban.wasm --source alice --network testnet > .soroban/hello-id",
-   "deploy:incrementor": "./soroban contract deploy --wasm target/wasm32-unknown-unknown/release/incrementor.wasm --source alice --network testnet > .soroban/incrementor-id;",
+   "create_deployer": "soroban config identity generate alice && soroban config identity fund alice --network testnet",
+   "deploy:hello": "soroban contract deploy --wasm target/wasm32-unknown-unknown/release/hello_soroban.wasm --source alice --network testnet > .soroban/hello-id",
+   "deploy:incrementor": "soroban contract deploy --wasm target/wasm32-unknown-unknown/release/incrementor.wasm --source alice --network testnet > .soroban/incrementor-id;",
    "deploy": "npm run deploy:hello && npm run deploy:incrementor",
-   "setup": "./soroban contract build && if [ ! -d .soroban ]; then npm run create_deployer && npm run deploy; fi",
+   "setup": "soroban contract build && if [ ! -d .soroban ]; then npm run create_deployer && npm run deploy; fi",
     ...
   }
 ```
 
 Finally, let's add a `reset` that calls both in order:
 
-```json
+```json title="package.json"
 "scripts": {
     ...
     "reset": "npm run clean && npm run setup",
@@ -481,9 +439,8 @@ Now anytime you make changes to your contracts, you can run `npm run reset` to b
 
 You can also update the `postinstall` script to check for the existence of `.soroban` and automatically `npm run setup` if it's not found:
 
-```json
-  "postinstall": "if [ ! -d .soroban ]; then npm run setup; fi && npm run bindings:hello && npm run bindings:incrementor"
-"
+```json title="package.json"
+  "postinstall": "if [ ! -d .soroban ]; then npm run setup; fi && npm run bindings:hello && npm run bindings:incrementor",
 ```
 
 ## Take it further
diff --git a/docs/getting-started/deploy-incrementor.mdx b/docs/getting-started/deploy-incrementor.mdx
new file mode 100644
index 00000000..4d4da538
--- /dev/null
+++ b/docs/getting-started/deploy-incrementor.mdx
@@ -0,0 +1,85 @@
+---
+sidebar_position: 5
+title: 4. Deploy Incrementor
+description: Deploy the Incrementor contract to Testnet.
+---
+
+<head>
+  <title>4. Deploy Incrementor to Testnet.</title>
+  <meta charSet="utf-8" />
+  <meta
+    property="og:title"
+    content="Deploy the Incrementor contract to Testnet."
+  />
+  <meta
+    property="og:description"
+    content="Deploy the Incrementor contract to Testnet."
+  />
+  <link
+    rel="canonical"
+    href="https://soroban.stellar.org/docs/getting-started/deploy-incrementor"
+  />
+</head>
+
+## Two-step deployment
+
+It's worth knowing that `deploy` is actually a two-step process.
+
+1. Upload the contract bytes to the network. Soroban currently refers to this as _installing_ the contract—from the perspective of the blockchain itself, this is a reasonable metaphor. This uploads the bytes of the contract to the network, indexing it by its hash. This contract code can now be referenced by multiple contracts, which means they would have the exact same _behavior_ but separate storage state.
+
+2. Instantiate the contract. This actually creates what you probably think of as a Smart Contract. It makes a new contract ID, and associates it with the contract bytes that were uploaded in the previous step.
+
+You can run these two steps separately. Let's try it with the Incrementor contract:
+
+```bash
+soroban contract install \
+  --network testnet \
+  --source alice \
+  --wasm target/wasm32-unknown-unknown/release/incrementor.wasm
+```
+
+This returns the hash of the Wasm bytes. Now you can use `--wasm-hash` with `deploy` rather than `--wasm`. Let's also automatically pipe the returned contract ID into a file in the `.soroban` directory, so that when you search your command history and reuse the deploy command in the future, you don't forget that step (you might want to go back and do something similar with the Hello World deploy, too):
+
+```bash
+soroban contract deploy \
+  --wasm-hash [paste the output from the last command] \
+  --source alice \
+  --network testnet \
+  > .soroban/incrementor-id
+```
+
+You can check that it saved the contract ID correctly:
+
+```bash
+cat .soroban/incrementor-id
+```
+
+Now you can interact with it over RPC like you did with the Hello World contract:
+
+```bash
+soroban contract invoke \
+  --id $(cat .soroban/incrementor-id) \
+  --source alice \
+  --network testnet \
+  -- \
+  increment
+```
+
+You should see the following output:
+
+```bash
+1
+```
+
+Run it a few more times to watch the count change.
+
+## Run your own network/node
+
+Sometimes you'll need to run your own node:
+
+- Production apps! Stellar maintains public test RPC nodes for Testnet and Futurenet, but not for Mainnet. Instead, you will need to run your own node, and point your app at that. If you want to use a software-as-a-service platform for this, [various providers](../reference/rpc-list.mdx) are available.
+- When you need a network that differs from the version deployed to Testnet.
+
+The Soroban team maintains Docker containers that makes this as straightforward as possible. See the [RPC](../reference/rpc.mdx) reference for details.
+
+Up next, we'll use the deployed contracts to build a simple web app.
diff --git a/docs/getting-started/deploy-to-testnet.mdx b/docs/getting-started/deploy-to-testnet.mdx
index da6d384d..7d0a395b 100644
--- a/docs/getting-started/deploy-to-testnet.mdx
+++ b/docs/getting-started/deploy-to-testnet.mdx
@@ -1,19 +1,19 @@
 ---
-sidebar_position: 4
-title: 3. Deploy to Testnet
-description: Deploy smart contracts to a live test network.
+sidebar_position: 3
+title: 2. Deploy to Testnet
+description: Deploy a smart contract to a live test network.
 ---
 
 <head>
-  <title>Deploy smart contracts to a live test network.</title>
+  <title>Deploy a smart contract to a live test network.</title>
   <meta charSet="utf-8" />
   <meta
     property="og:title"
-    content="Deploy smart contracts to a live test network."
+    content="Deploy a smart contract to a live test network."
   />
   <meta
     property="og:description"
-    content="Configure networks and identities, fund accounts with Friendbot, and deploy and interact with smart contracts on a live test network called Testnet."
+    content="Deploy and interact with smart contract on a live test network called Testnet."
   />
   <link
     rel="canonical"
@@ -21,80 +21,43 @@ description: Deploy smart contracts to a live test network.
   />
 </head>
 
-You've built two simple contracts and run them locally in Sandbox. Now you can deploy them to a network.
+To recap what we've done so far, in [Setup](setup.mdx):
 
-Soroban has a test network called Testnet that you can use to deploy and test your contracts. It's a live network, but it's not the same as the Stellar public network. It's a separate network that is used for development and testing, so you can't use it for production apps. But it's a great place to test your contracts before you deploy them to the public network.
+- we set up our local environment to write Rust smart contracts
+- installed the soroban-cli
+- configured the soroban-cli to communicate with the Soroban Testnet via RPC
+- and configured an identity to sign transactions
 
-## Configure Testnet in your CLI
-
-The first step toward deploying to testnet is to configure your CLI to use it. You can do this by running the following command:
-
-    soroban config network add --global testnet \
-      --rpc-url https://soroban-testnet.stellar.org:443 \
-      --network-passphrase "Test SDF Network ; September 2015"
-
-Note the `--global`. This creates a file in your home folder's `/.config/soroban/network/testnet.toml` with the settings you specified. This
-means that you can use the `--network testnet` flag in any Soroban CLI command to use this network.
-
-If you want project-specific network configurations, you can omit the `--global` flag, and the networks will be added to your working directory's `.soroban/network` folder instead.
-
-## Configure an Identity
-
-So far when using Sandbox, you haven't needed to consider _who_ is sending the transactions. But when you deploy to a network, you need to specify an identity that will be used to sign the transactions.
-
-Let's configure an identity called `alice`. You can use any name you want, but it might be nice to have some named identities that you can use for testing, such as [`alice`, `bob`, and `carol`](https://en.wikipedia.org/wiki/Alice_and_Bob).
-
-    soroban config identity generate --global alice
-
-You can see the public key of `alice` with:
-
-    soroban config identity address alice
-
-Like the Network configs, the `--global` means that the identity gets stored in `~/.config/soroban/identity/alice.toml`. You can omit the `--global` flag to store the identity in your project's `.soroban/identity` folder instead.
-
-All this did so far is generate a public/private keypair on your local machine. No network requests were made, and `alice` has no funds on Testnet. This means that you can't make any transactions with `alice` yet.
-
-To get `alice` some Testnet tokens, you'll need to use [Friendbot](https://developers.stellar.org/docs/fundamentals-and-concepts/testnet-and-pubnet#friendbot). All Stellar and Soroban test networks have a Friendbot that you can use to get some test tokens. The public Friendbot instance for Testnet lives at `https://friendbot.stellar.org`. Use it:
-
-     curl "https://friendbot.stellar.org/?addr=$(soroban config identity address alice)"
-
-:::tip Command Expansion `$(…)`
-This uses [command expansion](https://www.gnu.org/software/bash/manual/html_node/Command-Substitution.html), which only works with bash-compatible shells. If you are using Windows or some other shell, you will need to copy the output of `soroban config…` and paste it into the `curl` command, or figure out how command expansion works in your shell.
-:::
+In [Hello World](hello-world.mdx) we wrote a simple contract, and now we are ready to deploy that contract to Testnet, and interact with it.
 
 ## Deploy
 
-Now you can deploy your Hello World contract:
+To deploy your Hello Soroban contract, run the following command:
 
-    soroban contract deploy \
-      --wasm target/wasm32-unknown-unknown/release/hello_soroban.wasm \
-      --source alice \
-      --network testnet
+```bash
+soroban contract deploy \
+  --wasm target/wasm32-unknown-unknown/release/hello_soroban.wasm \
+  --source alice \
+  --network testnet
+```
 
-This returns the ID of the contract, starting with a `C`. Let's put it somewhere semi-permanent so we can use it later. Copy that value and:
+This returns the ID of the contract, starting with a `C`. Let's put it somewhere semi-permanent so we can use it later. Copy that value and put it into a file in the `.soroban` directory called `hello-id`. You may need to create the `.soroban` folder first with `mkdir .soroban`.
 
 ```bash
-echo "C…" > .soroban/hello-id
+echo "C...[your contract id here]" > .soroban/hello-id
 ```
 
-You may need to create the `.soroban` folder first with `mkdir .soroban`.
-
 ## Interact
 
-This should look a lot like interacting with the contract in the Sandbox, as you did in [1. Hello World](./hello-world.mdx). Only now the contract lives on the Testnet network, and the CLI is making [RPC](../reference/rpc.mdx) calls in the background. Let's try it:
+Using the code we wrote in [Write a Contract](hello-world.mdx#write-a-contract) and the resulting `.wasm` file we built in [Build](hello-world.mdx#build), run the following command to invoke the `hello` function.
 
-```bash
-soroban contract invoke \
-  --id $(cat .soroban/hello-id) \
-  --source alice \
-  --network testnet \
-  -- \
-  --help
-```
+:::info
+
+In the background, the CLI is making RPC calls. For information on that checkout out the [RPC](../reference/rpc.mdx) reference page.
 
-This again makes use of command expansion `$(…)`; see the note about that above.
+:::
 
-This looks a lot like interacting with the contract back in [1. Hello World](./hello-world.mdx), but rather than using a `--wasm` flag to point to a local wasm file, you now specify the `--network` and the `--source`. That's it! You can try calling `hello` as before:
+Here we're setting the `to` argument to `RPC`. This again makes use of command expansion `$(…)`; see the note about that in the [Configure an Identity](setup#configure-an-identity) section of Setup.
 
 ```bash
 soroban contract invoke \
@@ -106,68 +69,33 @@ soroban contract invoke \
   --to RPC
 ```
 
-## Two-step deployment
-
-It's worth knowing that `deploy` is actually a two-step process.
-
-1. Upload the contract bytes to the network. Soroban currently refers to this as _installing_ the contract—from the perspective of the blockchain itself, this is a reasonable metaphor. This uploads the bytes of the contract to the network, indexing it by its hash. This contract code can now be referenced by multiple contracts, which means they would have the exact same _behavior_ but separate storage state.
-
-2. Instantiate the contract. This actually creates what you probably think of as a Smart Contract. It makes a new contract ID, and associates it with the contract bytes that were uploaded in the previous step.
-
-You can run these two steps separately. Let's try it with the Incrementor contract:
+The following output should appear.
 
-```bash
-soroban contract install \
-  --network testnet \
-  --source alice \
-  --wasm target/wasm32-unknown-unknown/release/incrementor.wasm
+```json
+["Hello", "RPC"]
 ```
 
-This returns the hash of the Wasm bytes. Now you can use `--wasm-hash` with `deploy` rather than `--wasm`. Let's also automatically pipe the returned contract ID into a file in the `.soroban` directory, so that when you search your command history and reuse the deploy command in the future, you don't forget that step (you might want to go back and do something similar with the Hello World deploy, too):
+:::info
 
-```bash
-soroban contract deploy \
-  --wasm-hash [paste the output from the last command] \
-  --source alice \
-  --network testnet \
-  > .soroban/incrementor-id
-```
+The `--` double-dash is required!
 
-You can check that it saved the contract ID correctly:
+This is a general [CLI pattern](https://unix.stackexchange.com/questions/11376/what-does-double-dash-mean) used by other commands like [cargo run](https://doc.rust-lang.org/cargo/commands/cargo-run.html). Everything after the `--`, sometimes called [slop](https://github.com/clap-rs/clap/issues/971), is passed to a child process. In this case, `soroban contract invoke` builds an _implicit CLI_ on-the-fly for the `hello` method in your contract. It can do this because Soroban SDK embeds your contract's schema / interface types right in the `.wasm` file that gets deployed on-chain. You can also try:
 
-```bash
-cat .soroban/incrementor-id
-```
+    soroban contract invoke ... -- --help
 
-Now you can interact with it over RPC like you did with the Hello World contract:
+and
 
-```bash
-soroban contract invoke \
-  --id $(cat .soroban/incrementor-id) \
-  --source alice \
-  --network testnet \
-  -- \
-  increment
-```
-
-## Run your own network/node
+    soroban contract invoke ... -- hello --help
 
-Sometimes you'll need to run your own node:
-
-- Production apps! It's a bad idea to rely on the public, Stellar-maintained Soroban RPC endpoint. Instead, you should run your own node, and point your app at that.
-- When you need a network that differs from the version deployed to Testnet.
-
-The Soroban team maintains Docker containers that makes this as straightforward as possible. See the [RPC](../reference/rpc.mdx) reference for details.
+:::
 
 ## Summary
 
 In this lesson, we learned how to:
 
-- configure networks and identities using Soroban CLI
-- fund accounts on test networks using Friendbot
-- deploy contracts to a test network
-- interact with deployed contracts
+- deploy a contract to Testnet
+- interact with a deployed contract
 
 You shouldn't have any changes to commit to git, because we didn't change any code in this lesson!
 
-Up next, we'll use the deployed contracts to build a simple web app.
+Next we'll add a new contract to this project, reorganizing the project as a multi-contract project using Cargo Workspaces. The new contract will show off a little bit of Soroban's storage capabilities.
diff --git a/docs/getting-started/hello-world.mdx b/docs/getting-started/hello-world.mdx
index 5221e81a..2d5d02aa 100644
--- a/docs/getting-started/hello-world.mdx
+++ b/docs/getting-started/hello-world.mdx
@@ -13,7 +13,7 @@ description: Create your first smart contract in Rust.
   />
   <meta
     property="og:description"
-    content="Write a simple smart contract in Rust that can be deployed to a Soroban network. Run the contract locally using a sandbox environment and learn to optimize the build."
+    content="Write a simple smart contract in Rust that can be deployed to a Soroban network."
   />
   <link
     rel="canonical"
@@ -24,7 +24,7 @@ description: Create your first smart contract in Rust.
 import Tabs from "@theme/Tabs";
 import TabItem from "@theme/TabItem";
 
-Once you've [Setup](./setup.mdx) your development environment, you're ready to create your first Soroban contract.
+Once you've [setup](./setup.mdx) your development environment, you're ready to create your first Soroban contract.
 
 ## Create New Project
 
@@ -54,7 +54,7 @@ crate-type = ["cdylib"]
 
 ### Import `soroban-sdk` and Features
 
-Add the following sections to the `Cargo.toml` that will import the `soroban-sdk`, and configure a set of features explained below.
+Add the following sections to the `Cargo.toml` to import the `soroban-sdk`, and configure a set of features explained below.
 
 :::caution
 
@@ -77,7 +77,7 @@ The `features` list includes a `testutils` feature, which will cause additional
 
 :::info
 
-The `testutils` test utilities are automatically enabled inside [Rust unit tests] inside the same crate as your contract. If you write tests from another crate, you'll need to require the `testutils` feature for those tests and enable the `testutils` feature when running your tests with `cargo test --features testutils` to be able to use those test utilities.
+The `testutils` are automatically enabled inside [Rust unit tests] inside the same crate as your contract. If you write tests from another crate, you'll need to require the `testutils` feature for those tests and enable the `testutils` feature when running your tests with `cargo test --features testutils` to be able to use those test utilities.
 
 :::
 
@@ -101,7 +101,7 @@ lto = true
 
 ### Configure the `release-with-logs` Profile
 
-Configuring a `release-with-logs` profile can be useful for if you need to build a `.wasm` that has logs enabled for printing debug logs when using the [`soroban-cli`]. Note that this is not necessary to access debug logs in tests or to use a step-through-debugger.
+Configuring a `release-with-logs` profile can be useful if you need to build a `.wasm` file that has logs enabled for printing debug logs when using the [`soroban-cli`]. Note that this is not necessary to access debug logs in tests or to use a step-through-debugger.
 
 Add the following to your `Cargo.toml` and use the `release-with-logs` profile when you need logs.
 
@@ -117,7 +117,7 @@ See the [logging example] for more information about how to log.
 
 ### Wrapping it Up
 
-The steps below should produce a `Cargo.toml` that looks like so.
+The steps above should produce a `Cargo.toml` that looks like so.
 
 ```toml title="Cargo.toml"
 [package]
@@ -128,15 +128,15 @@ edition = "2021"
 [lib]
 crate-type = ["cdylib"]
 
-[features]
-testutils = ["soroban-sdk/testutils"]
-
 [dependencies]
 soroban-sdk = "20.0.0-rc2"
 
 [dev_dependencies]
 soroban-sdk = { version = "20.0.0-rc2", features = ["testutils"] }
 
+[features]
+testutils = ["soroban-sdk/testutils"]
+
 [profile.release]
 opt-level = "z"
 overflow-checks = true
@@ -154,28 +154,30 @@ debug-assertions = true
 
 [Rust unit tests]: https://doc.rust-lang.org/rust-by-example/testing/unit_testing.html
 [Rust integration tests]: https://doc.rust-lang.org/rust-by-example/testing/integration_testing.html
-[`soroban-cli`]: ../getting-started/setup#install-the-soroban-cli
+[`soroban-cli`]: setup.mdx#install-the-soroban-cli
 
 ## Write a Contract
 
-Once you've created a project, writing a contract involves writing Rust code in the projects `lib.rs` file.
+Once you've created a project, writing a contract involves writing Rust code in the project's `lib.rs` file. You can delete the default functions that cargo added to `lib.rs`.
+
+All contracts should begin with `#![no_std]` to ensure that the Rust standard library is not included in the build. The Rust standard library is large and not well suited to being deployed into small programs like those deployed to blockchains.
 
 ```rust
 #![no_std]
 ```
 
-All contracts should begin with `#![no_std]` to ensure that the Rust standard library is not included in the build. The Rust standard library is large and not well suited to being deployed into small programs like those deployed to blockchains.
+The contract will need to import the types and macros that it needs from the `soroban-sdk` crate. Take a look at [Create a Project](#create-new-project) to see how to setup a project.
 
 ```rust
 use soroban_sdk::{contract, contractimpl, symbol_short, vec, Env, Symbol, Vec};
 ```
 
-The contract will need to import the types and macros that it needs from the `soroban-sdk` crate. Take a look at [Create a Project](#create-new-project) to see how to setup a project.
-
 Many of the types available in typical Rust programs, such as `std::vec::Vec`, are not available, as there is no allocator and no heap memory in Soroban contracts. The `soroban-sdk` provides a variety of types like `Vec`, `Map`, `Bytes`, `BytesN`, `Symbol`, that all utilize the Soroban environment's memory and native capabilities. Primitive values like `u128`, `i128`, `u64`, `i64`, `u32`, `i32`, and `bool` can also be used. Floats and floating point math are not supported.
 
 Contract inputs must not be references.
 
+The `#[contract]` attribute designates the Contract struct as the type to which contract functions are associated. This implies that the struct will have contract functions implemented for it. Contract functions are defined within an `impl` block for the struct, which is annotated with `#[contractimpl]`. It is important to note that contract functions should have names with a maximum length of 32 characters. Additionally, if a function is intended to be invoked from outside the contract, it should be marked with the `pub` visibility modifier. It is common for the first argument of a contract function to be of type `Env`, allowing access to a copy of the Soroban environment, which is typically necessary for various operations within the contract.
+
 ```rust
 #[contract]
 pub struct Contract;
@@ -183,13 +185,11 @@ pub struct Contract;
 #[contractimpl]
 impl Contract {
     pub fn hello(env: Env, to: Symbol) -> Vec<Symbol> {
-        todo!()
+        vec![&env, symbol_short!("Hello"), to]
     }
 }
 ```
 
-The `#[contract]` attribute designates the Contract struct as the type to which contract functions are associated. This implies that the struct will have contract functions implemented for it. Contract functions are defined within an `impl` block for the struct, which is annotated with `#[contractimpl]`. It is important to note that contract functions should have names with a maximum length of 32 characters. Additionally, if a function is intended to be invoked from outside the contract, it should be marked with the `pub` visibility modifier. It is common for the first argument of a contract function to be of type `Env`, allowing access to a copy of the Soroban environment, which is typically necessary for various operations within the contract.
-
 Putting those pieces together a simple contract will look like this.
 
 ```rust title="src/lib.rs"
@@ -213,6 +213,13 @@ impl Contract {
 
 Writing tests for Soroban contracts involves writing Rust code using the test facilities and toolchain that you'd use for testing any Rust code.
 
+You'll need to add an annotation to bottom of `lib.rs` to tell Rust to compile and run the test code.
+
+```rust
+#[cfg(test)]
+mod test;
+```
+
 Given a simple contract like the contract demonstrated in the Write a Contract section, a simple test will look like this.
 
 <Tabs>
@@ -302,6 +309,12 @@ test test::test ... ok
 
 Try changing the values in the test to see how it works.
 
+:::note
+
+The first time you run the tests you may see output in the terminal of cargo compiling all the dependencies before running the tests.
+
+:::
+
 [Rust unit test]: https://doc.rust-lang.org/rust-by-example/testing/unit_testing.html
 [Rust integration test]: https://doc.rust-lang.org/rust-by-example/testing/integration_testing.html
 
@@ -327,97 +340,6 @@ target/wasm32-unknown-unknown/release/hello_soroban.wasm
 
 The `.wasm` file contains the logic of the contract, as well as the contract's [specification / interface types](../fundamentals-and-concepts/fully-typed-contracts.mdx), which can be imported into other contracts who wish to call it. This is the only artifact needed to deploy the contract, share the interface with others, or integration test against the contract.
 
-:::tip Optimize Builds
-To further optimize builds to be as small as possible, see [Optimizing Builds](#optimizing-builds).
-:::
-
-## Run on Sandbox
-
-If you have [`soroban-cli`] installed, you can run contracts in a local sandbox environment.
-
-The Soroban sandbox environment is the same Soroban environment that runs on Stellar networks, but it runs without nodes, and without the other features you find on a Stellar network.
-
-:::info
-It's also possible to run a contract on a fully featured local network. See [the RPC Reference page](../reference/rpc.mdx) for more details.
-:::
-
-Using the code we wrote in [Write a Contract] and the resulting `.wasm` file we built in [Build], run the following command to invoke the `hello` function. Here we're setting the `to` argument to `friend`:
-
-```sh
-soroban contract invoke \
-    --wasm target/wasm32-unknown-unknown/release/[project_name].wasm \
-    --id 1 \
-    -- \
-    hello \
-    --to friend
-```
-
-The contract invocation should result in the following output.
-
-```json
-["Hello", "friend"]
-```
-
-:::info The `--` double-dash is required!
-
-This is a general [CLI pattern](https://unix.stackexchange.com/questions/11376/what-does-double-dash-mean) used by other commands like [cargo run](https://doc.rust-lang.org/cargo/commands/cargo-run.html). Everything after the `--`, sometimes called [slop](https://github.com/clap-rs/clap/issues/971), is passed to a child process. In this case, `soroban contract invoke` builds an _implicit CLI_ on-the-fly for the `hello` method in your contract. It can do this because Soroban SDK embeds your contract's schema / interface types right in the `.wasm` file that gets deployed on-chain. You can also try:
-
-```bash
-soroban contract invoke ... -- --help
-```
-
-and
-
-```bash
-soroban contract invoke ... -- hello --help
-```
-
-:::
-
-### Diagnostic Events
-
-You will also notice here (and with any other contract run in the sandbox environment) that some diagnostic output will be displayed on the screen. This is because the `soroban-cli` automatically sets the diagnostic level to "Debug" for contracts running in the sandbox.
-
-Here, we'll see two diagnostic events were emitted by our contract invocation:
-
-1. First is a `fn_call` diagnostic event. It tells you the _kind_ of event, the contract ID that will be called, the name of the function being called, and a vector of the arguments passed to the function. A (greatly simplified) version of this event's body would look like this:
-
-```
-{
-    event: {
-        body: {
-            topics: [
-                Symbol(fn_call),
-                Bytes(0000000000000000000000000000000000000000000000000000000000000001),
-                Symbol(hello),
-            ],
-            data: Symbol(friend),
-        }
-    }
-}
-```
-
-2. Next is a `fn_return` diagnostic event. These events are emitted when a contract call completes and contains the _kind_ of event, the name of the function that is returning, and the value returned by the function. A (greatly simplified) version of this event's body would look like this:
-
-```
-{
-    event: {
-        body: {
-            topics: [
-                Symbol(fn_return),
-                Symbol(hello),
-            ],
-            data: [
-                Symbol(Hello),
-                Symbol(friend),
-            ]
-        }
-    }
-}
-```
-
-You can learn more about diagnostic events in our [Events article](../fundamentals-and-concepts/events#what-are-diagnosticevents).
-
 ## Optimizing Builds
 
 Use `soroban contract optimize` to further minimize the size of the `.wasm`. First, re-install soroban-cli with the `opt` feature:
@@ -435,12 +357,9 @@ This will optimize and output a new `hello_soroban.optimized.wasm` file in the s
 Building optimized contracts is only necessary when deploying to a network with fees or when analyzing and profiling a contract to get it as small as possible. If you're just starting out writing a contract, these steps are not necessary. See [Build] for details on how to build for development.
 :::
 
-[Write a Contract]: #write-a-contract
-[Build]: #build
-
 ## Commit to version control
 
-Now that everything's working, this is a great time to commit your code to version control. Even if you don't share your project with others, this will make it easier for you to see and understand your own changes throughout the rest of the tutorial.
+Before we go on to deploying the contract to Testnet in the next section, this is a great time to commit your code to version control. Even if you don't share your project with others, this will make it easier for you to see and understand your own changes throughout the rest of the tutorial.
 
 Go ahead and initialize `hello-soroban` as a git repository:
 
@@ -469,6 +388,6 @@ git commit -m "Initial commit: hello-soroban contract"
 
 ## Summary
 
-In this section, we wrote a simple contract that can be deployed to a Soroban network. We also learned how to run the contract locally using the Soroban sandbox environment.
+In this section, we wrote a simple contract that can be deployed to a Soroban network.
 
-Next we'll add a new contract to this project, reorganizing the project as a multi-contract project using Cargo Workspaces. The new contract will show off a little bit of Soroban's storage capabilities.
+Next we'll learn to deploy the hello-soroban contract to Soroban's Testnet network and interact with it over RPC using the CLI.
diff --git a/docs/getting-started/setup.mdx b/docs/getting-started/setup.mdx
index 681eca52..1aac5a37 100644
--- a/docs/getting-started/setup.mdx
+++ b/docs/getting-started/setup.mdx
@@ -35,7 +35,7 @@ If you use macOS, Linux, or another Unix-like OS, the simplest method to install
 a Rust toolchain is to install `rustup`. Install `rustup` with the following
 command.
 
-```
+```bash
 curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
 ```
 
@@ -74,7 +74,7 @@ contract will execute on network, however in a local sandbox.
 Install the Soroban CLI using `cargo install`.
 
 ```bash
-cargo install --locked --version 20.0.0-rc2 soroban-cli
+cargo install --locked --version 20.0.0-rc.4.1 soroban-cli
 ```
 
 :::info
@@ -143,5 +143,54 @@ Users of non-bash shells may need to adapt the above commands to suit their need
 
 :::
 
+### Configuring the CLI for Testnet
+
+Soroban has a test network called Testnet that you can use to deploy and test your smart contracts. It's a live network, but it's not the same as the Stellar public network. It's a separate network that is used for development and testing, so you can't use it for production apps. But it's a great place to test your contracts before you deploy them to the public network.
+
+To configure your CLI to interact with Testnet, run the following command:
+
+```bash
+soroban config network add --global testnet \
+  --rpc-url https://soroban-testnet.stellar.org:443 \
+  --network-passphrase "Test SDF Network ; September 2015"
+```
+
+Note the `--global`. This creates a file in your home folder's `/.config/soroban/network/testnet.toml` with the settings you specified. This
+means that you can use the `--network testnet` flag in any Soroban CLI command to use this network.
+
+If you want project-specific network configurations, you can omit the `--global` flag, and the networks will be added to your working directory's `.soroban/network` folder instead.
+
+### Configure an Identity
+
+When you deploy a smart contract to a network, you need to specify an identity that will be used to sign the transactions.
+
+Let's configure an identity called `alice`. You can use any name you want, but it might be nice to have some named identities that you can use for testing, such as [`alice`, `bob`, and `carol`](https://en.wikipedia.org/wiki/Alice_and_Bob).
+
+```bash
+soroban config identity generate --global alice
+```
+
+You can see the public key of `alice` with:
+
+```bash
+soroban config identity address alice
+```
+
+Like the Network configs, the `--global` means that the identity gets stored in `~/.config/soroban/identity/alice.toml`. You can omit the `--global` flag to store the identity in your project's `.soroban/identity` folder instead.
+
+All this did so far is generate a public/private keypair on your local machine. No network requests were made, and `alice` has no funds on Testnet. This means that you can't make any transactions with `alice` yet.
+
+To get `alice` some Testnet tokens, you'll need to use [Friendbot](https://developers.stellar.org/docs/fundamentals-and-concepts/testnet-and-pubnet#friendbot). All Stellar and Soroban test networks have a Friendbot that you can use to get some test tokens. The public Friendbot instance for Testnet lives at `https://friendbot.stellar.org`. Use it:
+
+```bash
+curl "https://friendbot.stellar.org/?addr=$(soroban config identity address alice)"
+```
+
+:::tip Command Expansion `$(…)`
+
+This uses [command expansion](https://www.gnu.org/software/bash/manual/html_node/Command-Substitution.html), which only works with bash-compatible shells. If you are using Windows or some other shell, you will need to copy the output of `soroban config…` and paste it into the `curl` command, or figure out how command expansion works in your shell.
+
+:::
+
 [Rust]: https://www.rust-lang.org/
-[Soroban CLI]: setup#install-the-soroban-cli
+[Soroban CLI]: setup.mdx#install-the-soroban-cli
diff --git a/docs/getting-started/storing-data.mdx b/docs/getting-started/storing-data.mdx
index 91487743..c3001d2a 100644
--- a/docs/getting-started/storing-data.mdx
+++ b/docs/getting-started/storing-data.mdx
@@ -1,6 +1,6 @@
 ---
-sidebar_position: 3
-title: 2. Storing Data
+sidebar_position: 4
+title: 3. Storing Data
 description: Write a smart contract that stores and retrieves data.
 ---
 
@@ -29,7 +29,7 @@ Now that we've built a basic Hello World example to see the rough structure of S
 This is going to follow along with the [increment example](https://github.com/stellar/soroban-examples/tree/v20.0.0-rc2/increment), which has a single function that increments an internal counter and returns the value. If you want to see a working example, [try it in
 GitPod](https://gitpod.io/#https://github.com/stellar/soroban-examples/tree/v20.0.0-rc2).
 
-This tutorial assumes that you've already completed the previous steps in Getting Started: [Setup](./setup.mdx) and [Hello World](./hello-world.mdx).
+This tutorial assumes that you've already completed the previous steps in Getting Started: [Setup](./setup.mdx), [Hello World](./hello-world.mdx), and [Deploy to Testnet](./deploy-to-testnet.mdx).
 
 ## Setting up a multi-contract project
 
@@ -55,6 +55,7 @@ You're going to want some Rust and Cargo stuff in different spots. From the new
 ```bash
 rm contracts/hello-soroban/Cargo.lock
 mv contracts/hello-soroban/target .
+mv contracts/hello-soroban/.soroban .
 cp contracts/hello-soroban/Cargo.toml .
 ```
 
@@ -63,11 +64,16 @@ Note that we copied the Cargo.toml file. That's because we're going to need some
 In the root `Cargo.toml`:
 
 - remove the `[package]`, `[lib]`, `[features]`, and `[dev_dependencies]` sections
-- keep the `[release.*]` stuff
+- keep the `[profile.release*]` stuff
 - replace the line `[dependencies]` with `[workspace.dependencies]`
-- add a `[workspace]` section
+- add a `[workspace]` section (see below for specific values)
 
-In the project-specific `Cargo.toml`, keep roughly the opposite sections, and use the dependency versions as specified in the workspace root. It all ends up looking like this:
+In the contract-specific `Cargo.toml`:
+
+- remove the `[profile.release*]` stuff
+- set the dependency versions to use the workspace versions (see example below)
+
+It all ends up looking like this:
 
 <Tabs>
 <TabItem value="soroban-tutorial/Cargo.toml" label="Cargo.toml">
@@ -134,7 +140,7 @@ All tests should pass.
 
 ## Code
 
-Rather than initializing this contract with `cargo new`, let's copy the `hello-soroban` project:
+Rather than initializing the new contract with `cargo new`, let's copy the `hello-soroban` project:
 
 ```bash
 cp -r contracts/hello-soroban contracts/incrementor
@@ -173,7 +179,7 @@ impl IncrementorContract {
 
         env.storage().instance().set(&COUNTER, &count);
 
-        env.storage().instance().bump(100);
+        env.storage().instance().bump(100, 100);
 
         count
     }
@@ -199,12 +205,12 @@ Follow along in your `contracts/incrementor/src/lib.rs` file.
 
 ### Contract Data Keys
 
-Contract data is associated with a key. The key is the value that can be used at
-a later time to lookup the value.
+Contract data is associated with a key. The key can be used at
+a later time to look up the value.
 
 `Symbol` is a short (up to 32 characters long) string type with limited
 character space (only `a-zA-z0-9_` characters are allowed). Identifiers like
-contract function names are represented by `Symbol`s.
+contract function names and contract data keys are represented by `Symbol`s.
 
 The `symbol_short!()` macro is a convenient way to pre-compute short symbols up to 9 characters in length at compile time using `Symbol::short`. It generates a compile-time constant that adheres to the valid character set of letters (a-zA-Z), numbers (0-9), and underscores (\_). If a symbol exceeds the 9-character limit, `Symbol::new` should be utilized for creating symbols at runtime.
 
@@ -232,6 +238,12 @@ Values stored as contract data and retrieved are transmitted from [the environme
 
 The `set()` function stores the new count value against the key, replacing the existing value.
 
+```rust
+env.storage()
+    .instance()
+    .set(&COUNTER, &count);
+```
+
 ### Managing Contract Data Lifetimes with `bump()`
 
 All contract data has a "lifetime" that must be periodically bumped. If an
@@ -240,43 +252,6 @@ entry's lifetime is not periodically bumped, the entry will eventually reach the
 For now, it's worth knowing that there are three kinds of storage:
 `Persistent`, `Temporary`, and `Instance`. This contract only uses `Instance` storage: `env.storage().instance()`. Every time the counter is incremented, this storage gets bumped by 100 [ledgers](https://developers.stellar.org/docs/fundamentals-and-concepts/stellar-data-structures/ledgers), or about 500 seconds.
 
-## Run on Sandbox
-
-Let's invoke this contract the same way we invoked the Hello World contract. We'll use `--id 2`, since we already used `--id 1` for the Hello World contract. For Sandbox, these values are stored in a `.soroban/ledger.json` file in the current directory; you can always remove this file to reset the ledger.
-
-    soroban contract invoke \
-      --wasm target/wasm32-unknown-unknown/release/incrementor.wasm \
-      --id 2 \
-      -- \
-      increment
-
-You should see the following output:
-
-    1
-
-Rerun the invoke with the `--footprint` option to view the [footprint](../fundamentals-and-concepts/persisting-data.mdx#footprints-and-parallel-contention) of the invocation, which is the ledger entries that the contract will read or write to.
-
-    soroban contract invoke \
-      --wasm target/wasm32-unknown-unknown/release/incrementor.wasm \
-      --id 2 \
-      --footprint \
-      -- \
-      increment
-
-You should see:
-
-    Footprint: {"readOnly":[{"contractData":{"contractId":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1],"key":{"static":"ledgerKeyContractCode"}}}],"readWrite":[{"contractData":{"contractId":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1],"key":{"symbol":[67,79,85,78,84,69,82]}}}]}
-
-:::info Footprint formats are unstable
-Soroban is a pre-release and at this time outputs footprints in an unstable JSON format.
-:::
-
-Run it without the `--footprint` a few more times to watch the count change.
-
-Use `contract read` to inspect what the full storage looks like after a few runs.
-
-    soroban contract read --id 1 --key COUNTER
-
 ## Tests
 
 Open the `contracts/increment/src/test.rs` file and replace the contents with:
@@ -339,4 +314,4 @@ git commit -m "add incrementor contract"
 
 In this section, we added a new contract to this project, reorganizing the project as a multi-contract project using Cargo Workspaces. The new contract made use of Soroban's storage capabilities to store and retrieve data. We also learned about the different kinds of storage and how to manage their lifetimes.
 
-Next we'll learn to deploy contracts to Soroban's Testnet network and interact with them over RPC using the CLI.
+Next we'll learn a bit more about deploying contracts to Soroban's Testnet network and interact with our incrementor contract using the CLI.