diff --git a/docs/Story Network (L1)/story-network/node-setup-dev-mainnet.md b/docs/Story Network (L1)/story-network/node-setup-dev-mainnet.md
index 1e335bcf..4bc33be9 100644
--- a/docs/Story Network (L1)/story-network/node-setup-dev-mainnet.md	
+++ b/docs/Story Network (L1)/story-network/node-setup-dev-mainnet.md	
@@ -1,45 +1,46 @@
 ---
 title: Node Setup - Dev Mainnet
-excerpt: ''
+excerpt: ""
 deprecated: false
 hidden: false
 metadata:
-  title: ''
-  description: ''
+  title: ""
+  description: ""
   robots: index
 next:
-  description: ''
+  description: ""
 ---
+
 This section will guide you through how to setup a Story node. Story draws inspiration from ETH PoS in decoupling execution and consensus clients. The execution client `story-geth` relays EVM blocks into the `story` consensus client via Engine API, using an ABCI++ adapter to make EVM state compatible with that of CometBFT. With this architecture, consensus efficiency is no longer bottlenecked by execution transaction throughput.
 
 ![](https://files.readme.io/7dee0e873bcb2aeeaf12c3c0d63db44692c1bfe5cee599c52ea5c465240967a4-image.png)
 
 The `story` and `geth` binaries, which make up the clients required for running Story nodes, are available from our latest `release` pages:
 
-* **`story-geth`execution client:**
-  * Release Link: [**Click here**](https://github.com/piplabs/story-geth/releases)
-  * Latest Stable Binary (v1.0.1): [**Click here**](https://github.com/piplabs/story-geth/releases/tag/v1.0.1)
-* **`story`consensus client:**
-  * Releases link: [**Click here**](https://github.com/piplabs/story/releases)
-  * Latest Stable Binary (v1.0.0): [**Click here**](https://github.com/piplabs/story/releases/tag/v1.0.0)
+- **`story-geth`execution client:**
+  - Release Link: [**Click here**](https://github.com/piplabs/story-geth/releases)
+  - Latest Stable Binary (v1.0.1): [**Click here**](https://github.com/piplabs/story-geth/releases/tag/v1.0.1)
+- **`story`consensus client:**
+  - Releases link: [**Click here**](https://github.com/piplabs/story/releases)
+  - Latest Stable Binary (v1.0.0): [**Click here**](https://github.com/piplabs/story/releases/tag/v1.0.0)
 
 # Story Node Installation Guide
 
 ## Pre-Installation Checklist
 
-* [ ] Verify system meets hardware requirements
-* [ ] Operating system: Ubuntu 22.04 LTS
-* [ ] Required ports are available
-* [ ] Sufficient disk space available
-* [ ] Root or sudo access
+- [ ] Verify system meets hardware requirements
+- [ ] Operating system: Ubuntu 22.04 LTS
+- [ ] Required ports are available
+- [ ] Sufficient disk space available
+- [ ] Root or sudo access
 
 ## Quick Reference
 
-* Installation time: \~30 minutes
-* Network: Story Dev mainnet
-* Required versions:
-  * story-geth: v1.0.1
-  * story: v1.0.0
+- Installation time: \~30 minutes
+- Network: Story Dev mainnet
+- Required versions:
+  - story-geth: v1.0.1
+  - story: v1.0.0
 
 ## 1. System Preparation
 
@@ -47,8 +48,8 @@ The `story` and `geth` binaries, which make up the clients required for running
 
 For optimal performance and reliability, we recommend running your node on either:
 
-* A Virtual Private Server (VPS)
-* A dedicated Linux-based machine
+- A Virtual Private Server (VPS)
+- A dedicated Linux-based machine
 
 ### System Specs
 
@@ -61,22 +62,22 @@ For optimal performance and reliability, we recommend running your node on eithe
 
 ### 1.2 Required Ports
 
-*Ensure all ports needed for your node functionality are needed, described below*
-
-* `story-geth`
-  * 8545
-    * Required if you want your node to interface via JSON-RPC API over HTTP
-  * 8546
-    * Required for websockets interaction
-  * 30303 (TCP + API)
-    * MUST be open for p2p communication
-* `story`
-  * 26656
-    * MUST be open for consensus p2p communication
-  * 26657
-    * Required if you want your node interfacing for Tendermint RPC
-  * 26660
-    * Needed if you want to expose prometheus metrics
+_Ensure all ports needed for your node functionality are needed, described below_
+
+- `story-geth`
+  - 8545
+    - Required if you want your node to interface via JSON-RPC API over HTTP
+  - 8546
+    - Required for websockets interaction
+  - 30303 (TCP + API)
+    - MUST be open for p2p communication
+- `story`
+  - 26656
+    - MUST be open for consensus p2p communication
+  - 26657
+    - Required if you want your node interfacing for Tendermint RPC
+  - 26660
+    - Needed if you want to expose prometheus metrics
 
 ## 1.3 Install Dependencies
 
@@ -258,26 +259,26 @@ If you ever run into issues and would like to try joining the network from a fre
 rm -rf ${STORY_DATA_ROOT} && ./story init --network story && ./story run
 ```
 
-* Mac OS X:
-  * `rm -rf ~/Library/Story/story/* && ./story init --network story && ./story run`
-* Linux:
-  * `rm -rf ~/.story/story/* && ./story init --network story && ./story run`
+- Mac OS X:
+  - `rm -rf ~/Library/Story/story/* && ./story init --network story && ./story run`
+- Linux:
+  - `rm -rf ~/.story/story/* && ./story init --network story && ./story run`
 
 To quickly check if the node is syncing, you could
 
-* Check the geth RPC endpoint to see if blocks are increasing:
+- Check the geth RPC endpoint to see if blocks are increasing:
   ```bash
   curl -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' [http://localhost:8545](http://localhost:8545/)
   ```
-* Attach to `geth` as explained above and see if the `eth.blockNumber` is increasing
+- Attach to `geth` as explained above and see if the `eth.blockNumber` is increasing
 
 #### Custom Configuration
 
 To override your own node settings, you can do the following:
 
-* `${STORY_DATA_ROOT}/config/config.toml` can be modified to change network and consensus settings
-* `${STORY_DATA_ROOT}/config/story.toml` to update various client configs
-* `${STORY_DATA_ROOT}/priv_validator_key.json` is a sensitive file containing your validator key, but may be replaced with your own
+- `${STORY_DATA_ROOT}/config/config.toml` can be modified to change network and consensus settings
+- `${STORY_DATA_ROOT}/config/story.toml` to update various client configs
+- `${STORY_DATA_ROOT}/priv_validator_key.json` is a sensitive file containing your validator key, but may be replaced with your own
 
 #### Custom Automation
 
@@ -285,9 +286,9 @@ Below we list a sample `Systemd` configuration you may use on Linux
 
 ```bash
 # story
-sudo tee /etc/systemd/system/cosmovisor.service > /dev/null <<EOF
+sudo tee /etc/systemd/system/story.service > /dev/null <<EOF
 [Unit]
-Description=Cosmovisor
+Description=Story Cosmovisor
 After=network.target
 
 [Service]
@@ -317,21 +318,21 @@ EOF
 
 ```bash
 sudo systemctl daemon-reload
-sudo systemctl enable cosmovisor
-sudo systemctl start cosmovisor
+sudo systemctl enable story
+sudo systemctl start story
 
 # Monitor logs
-journalctl -u cosmovisor -f -o cat
+journalctl -u story -f -o cat
 ```
 
 #### Debugging
 
 If you would like to check the status of `story` while it is running, it is helpful to query its internal JSONRPC/HTTP endpoint. Here are a few helpful commands to run:
 
-* `curl localhost:26657/net_info | jq '.result.peers[].node_info.moniker'`
-  * This will give you a list of consesus peers the node is sync'd with by moniker
-* `curl localhost:26657/health`
-  * This will let you know if the node is healthy - `{}` indicates it is
+- `curl localhost:26657/net_info | jq '.result.peers[].node_info.moniker'`
+  - This will give you a list of consesus peers the node is sync'd with by moniker
+- `curl localhost:26657/health`
+  - This will let you know if the node is healthy - `{}` indicates it is
 
 ## 3. Verify Installation
 
@@ -366,9 +367,9 @@ network from a cleared state, run the following:
 rm -rf ${GETH_DATA_ROOT} && ./geth --story --syncmode full
 ```
 
-* Mac OS X: `rm -rf ~/Library/Story/geth/* && ./geth --story    --syncmode full`
-* Linux: `rm -rf ~/.story/geth/* && ./geth --story --syncmode   
-  full`
+- Mac OS X: `rm -rf ~/Library/Story/geth/* && ./geth --story    --syncmode full`
+- Linux: `rm -rf ~/.story/geth/* && ./geth --story --syncmode   
+full`
 
 ### Story
 
@@ -376,5 +377,89 @@ rm -rf ${GETH_DATA_ROOT} && ./geth --story --syncmode full
 rm -rf ${STORY_DATA_ROOT} && ./story init --network story && ./story run
 ```
 
-* Mac OS X: `rm -rf ~/Library/Story/story/* && ./story init --network story && ./story run`
-* Linux: `rm -rf ~/.story/story/* && ./story init --network story && ./story run`
\ No newline at end of file
+- Mac OS X: `rm -rf ~/Library/Story/story/* && ./story init --network story && ./story run`
+- Linux: `rm -rf ~/.story/story/* && ./story init --network story && ./story run`
+
+### Upgrade Story
+
+There are three types of upgrades
+
+1. Upgrade the story geth client
+2. Upgrade the story client with cosmovisor
+3. Upgrade the story client
+
+#### Upgrade the story geth client
+
+```bash
+sudo systemctl stop story
+sudo systemctl stop story-geth
+
+# Download the new binary
+wget ${STORY_GETH_BINARY_URL}
+sudo mv ./geth-linux-amd64 story-geth
+sudo chmod +x story-geth
+sudo mv ./story-geth $HOME/go/bin/story-geth
+source $HOME/.bashrc
+
+# Restart the service
+sudo systemctl start story-geth
+sudo systemctl start story
+```
+
+#### Upgrade the story client manually
+
+```bash
+sudo systemctl stop story
+
+# Download the new binary
+wget ${STORY_BINARY_URL}
+sudo mv story-linux-amd64 story
+sudo chmod +x story
+sudo mv ./story $HOME/go/bin/story
+
+# Schedule the update
+sudo systemctl start story
+```
+
+#### Schedule the upgrade with Cosmovisor
+
+The following steps outline how to schedule an upgrade using Cosmovisor:
+
+1. Create the upgrade directory and download the new binary
+
+```bash
+# Download the new binary
+wget ${STORY_BINARY_URL}
+
+# Schedule the upgrade
+source $HOME/.bash_profile
+cosmovisor add-upgrade ${UPGRADE_NAME} ${UPGRADE_PATH} \
+  --force \
+  --upgrade-height ${UPGRADE_HEIGHT}
+```
+
+2. Verify the upgrade configuration
+
+```bash
+# Check the upgrade info
+cat $HOME/.story/data/upgrade-info.json
+```
+
+The upgrade-info.json should show:
+
+```json
+{
+  "name": "v1.0.0",
+  "time": "2025-02-05T12:00:00Z",
+  "height": 858000
+}
+```
+
+3. Monitor the upgrade
+
+```bash
+# Watch the node logs for the upgrade
+journalctl -u story -f -o cat
+```
+
+Note: Cosmovisor will automatically handle the binary switch when the specified block height is reached. Ensure your node has enough disk space and is fully synced before the upgrade height.