update formatting for the infra section

Author: eshaben

infrastructure/index.md

@@ -8,33 +8,33 @@ template: index-page.html
 
 Running infrastructure on Polkadot is essential to supporting the network’s performance and security. Operators must focus on reliability, ensure proper configuration, and meet the necessary hardware requirements to contribute effectively to the decentralized ecosystem.
 
-- Not sure where to start? Visit the [Choosing the Right Role](#choosing-the-right-role) section for guidance
-- Ready to get started? Jump to [In This Section](#in-this-section) to get started
+- Not sure where to start? Visit the [Choosing the Right Role](#choosing-the-right-role) section for guidance.
+- Ready to get started? Jump to [In This Section](#in-this-section) to get started.
 
 ## Choosing the Right Role
 
 Selecting your role within the Polkadot ecosystem depends on your goals, resources, and expertise. Below are detailed considerations for each role:
 
 - **Running a node**:
-    - **Purpose** - a node provides access to network data and supports API queries. It is commonly used for:
-        - **Development and testing** - offers a local instance to simulate network conditions and test applications
-        - **Production use** - acts as a data source for dApps, clients, and other applications needing reliable access to the blockchain
-    - **Requirements** - moderate hardware resources to handle blockchain data efficiently
-    - **Responsibilities** - a node’s responsibilities vary based on its purpose:
-        - **Development and testing** - enables developers to test features, debug code, and simulate network interactions in a controlled environment
-        - **Production use** - provides consistent and reliable data access for dApps and other applications, ensuring minimal downtime
+    - **Purpose**: A node provides access to network data and supports API queries. It is commonly used for.
+        - **Development and testing**: Offers a local instance to simulate network conditions and test applications.
+        - **Production use**: Acts as a data source for dApps, clients, and other applications needing reliable access to the blockchain.
+    - **Requirements**: Moderate hardware resources to handle blockchain data efficiently.
+    - **Responsibilities**: A node’s responsibilities vary based on its purpose.
+        - **Development and testing**: Enables developers to test features, debug code, and simulate network interactions in a controlled environment.
+        - **Production use**: Provides consistent and reliable data access for dApps and other applications, ensuring minimal downtime.
 
 - **Running a validator**:
-    - **Purpose** - validators play a critical role in securing the Polkadot relay chain. They validate parachain block submissions, participate in consensus, and help maintain the network's overall integrity
-    - **Requirements** - becoming a validator requires:
-        - **Staking** - a variable amount of DOT tokens to secure the network and demonstrate commitment
-        - **Hardware** - high-performing hardware resources capable of supporting intensive blockchain operations
-        - **Technical expertise** - proficiency in setting up and maintaining nodes, managing updates, and understanding Polkadot's consensus mechanisms
-        - **Community involvement** - building trust and rapport within the community to attract nominators willing to stake with your validator
-    - **Responsibilities** - validators have critical responsibilities to ensure network health:
-        - **Uptime** - maintain near-constant availability to avoid slashing penalties for downtime or unresponsiveness
-        - **Network security** - participate in consensus and verify parachain transactions to uphold the network's security and integrity
-        - **Availability** - monitor the network for events and respond to issues promptly, such as misbehavior reports or protocol updates
+    - **Purpose**: Validators play a critical role in securing the Polkadot relay chain. They validate parachain block submissions, participate in consensus, and help maintain the network's overall integrity.
+    - **Requirements**: Becoming a validator requires.
+        - **Staking**: A variable amount of DOT tokens to secure the network and demonstrate commitment.
+        - **Hardware**: High-performing hardware resources capable of supporting intensive blockchain operations.
+        - **Technical expertise**: Proficiency in setting up and maintaining nodes, managing updates, and understanding Polkadot's consensus mechanisms.
+        - **Community involvement**: Building trust and rapport within the community to attract nominators willing to stake with your validator.
+    - **Responsibilities**: Validators have critical responsibilities to ensure network health.
+        - **Uptime**: Maintain near-constant availability to avoid slashing penalties for downtime or unresponsiveness.
+        - **Network security**: Participate in consensus and verify parachain transactions to uphold the network's security and integrity.
+        - **Availability**: Monitor the network for events and respond to issues promptly, such as misbehavior reports or protocol updates.
 
 ## In This Section
 

infrastructure/running-a-node/index.md

@@ -12,18 +12,18 @@ Running a node on the Polkadot network enables you to access blockchain data, in
 
 Full nodes and bootnodes serve different roles within the network, each contributing in unique ways to connectivity and data access:
 
-- **Full node** - stores blockchain data, validates transactions, and can serve as a source for querying data
-- **Bootnode** - assists new nodes in discovering peers and connecting to the network, but doesn’t store blockchain data
+- **Full node**: Stores blockchain data, validates transactions, and can serve as a source for querying data.
+- **Bootnode**: Assists new nodes in discovering peers and connecting to the network, but doesn’t store blockchain data.
 
 The following sections describe the different types of full nodes—pruned, archive, and light nodes—and the unique features of each for various use cases.
 
 ## Types of Full Nodes
 
 The three main types of nodes are as follows:
 
-- **Pruned node** - prunes historical states of all finalized block states older than a specified number except for the genesis block's state
-- **Archive node** - preserves all the past blocks and their states, making it convenient to query the past state of the chain at any given time. Archive nodes use a lot of disk space, which means they should be limited to use cases that require easy access to past on-chain data, such as block explorers
-- **Light node** - has only the runtime and the current state but doesn't store past blocks, making them useful for resource-restricted devices
+- **Pruned node**: Prunes historical states of all finalized block states older than a specified number except for the genesis block's state.
+- **Archive node**: Preserves all the past blocks and their states, making it convenient to query the past state of the chain at any given time. Archive nodes use a lot of disk space, which means they should be limited to use cases that require easy access to past on-chain data, such as block explorers.
+- **Light node**: Has only the runtime and the current state but doesn't store past blocks, making them useful for resource-restricted devices.
 
 Each node type can be configured to provide remote access to blockchain data via RPC endpoints, allowing external clients, like dApps or developers, to submit transactions, query data, and interact with the blockchain remotely.
 
@@ -34,8 +34,8 @@ Each node type can be configured to provide remote access to blockchain data via
 
 A pruned node retains only a subset of finalized blocks, discarding older data. The two main types of pruning are:
 
-- **State pruning** - removes the states of old blocks while retaining block headers
-- **Block pruning** - removes both the full content of old blocks and their associated states, but keeps the block headers
+- **State pruning**: Removes the states of old blocks while retaining block headers.
+- **Block pruning**: Removes both the full content of old blocks and their associated states, but keeps the block headers.
 
 Despite these deletions, pruned nodes are still capable of performing many essential functions, such as displaying account balances, making transfers, setting up session keys, and participating in staking.
 

infrastructure/running-a-node/setup-bootnode.md

@@ -15,15 +15,15 @@ This guide will walk you through setting up a Polkadot bootnode, configuring P2P
 
 Before you start, you need to have the following prerequisites:
 
-- Verify a working Polkadot (`polkadot`) binary is available on your machine
-- Ensure you have nginx installed. Please refer to the [Installation Guide](https://nginx.org/en/docs/install.html){target=\_blank} for help with installation if needed
-- A VPS or other dedicated server setup
+- Verify a working Polkadot (`polkadot`) binary is available on your machine.
+- Ensure you have nginx installed. Please refer to the [Installation Guide](https://nginx.org/en/docs/install.html){target=\_blank} for help with installation if needed.
+- A VPS or other dedicated server setup.
 
 ## Accessing the Bootnode
 
 Bootnodes must be accessible through three key channels to connect with other nodes in the network:
 
-- **P2P** - a direct peer-to-peer connection, set by:
+- **P2P**: A direct peer-to-peer connection, set by.
 
     ```bash
 
@@ -33,8 +33,8 @@ Bootnodes must be accessible through three key channels to connect with other no
 
     This is not enabled by default on non-validator nodes like archive RPC nodes.
 
-- **P2P/WS** - a WebSocket (WS) connection, also configured via `--listen-addr`
-- **P2P/WSS** - a secure WebSocket (WSS) connection using SSL, often required for light clients. An SSL proxy is needed, as the node itself cannot handle certificates
+- **P2P/WS**: A WebSocket (WS) connection, also configured via `--listen-addr`.
+- **P2P/WSS**: A secure WebSocket (WSS) connection using SSL, often required for light clients. An SSL proxy is needed, as the node itself cannot handle certificates.
 
 ## Node Key
 

infrastructure/running-a-node/setup-full-node.md

@@ -21,7 +21,7 @@ Now that you're familiar with the different types of nodes, this section will wa
 
 Before getting started, ensure the following prerequisites are met:
 
-- Ensure [Rust](https://www.rust-lang.org/tools/install){target=\_blank} is installed on your operating system
+- Ensure [Rust](https://www.rust-lang.org/tools/install){target=\_blank} is installed on your operating system.
 - [Install the necessary dependencies for the Polkadot SDK](/develop/parachains/install-polkadot-sdk/){target=\_blank}
 
 !!! warning
@@ -73,8 +73,8 @@ This section will walk you through installing and building the Polkadot binary f
 
     Once installed, you have a couple options for installing the Polkadot binary:
 
-    - If Rust is installed, then `cargo` can be used similar to the macOS instructions
-    - Or, the instructions in the Linux section can be used
+    - If Rust is installed, then `cargo` can be used similar to the macOS instructions.
+    - Or, the instructions in the Linux section can be used.
 
 ??? interface "Linux (pre-built binary)"
 
@@ -255,9 +255,9 @@ Once you've fully configured your start-up command, you can execute it in your t
 
 The node startup settings allow you to choose what to expose, how many connections to expose, and which systems should be granted access through the RPC server.
 
-- You can limit the methods to use with `--rpc-methods`; an easy way to set this to a safe mode is `--rpc-methods safe`
-- You can set your maximum connections through `--rpc-max-connections`, for example, `--rpc-max-connections 200`
-- By default, localhost and Polkadot.js can access the RPC server. You can change this by setting `--rpc-cors`. To allow access from everywhere, you can use `--rpc-cors all`
+- You can limit the methods to use with `--rpc-methods`; an easy way to set this to a safe mode is `--rpc-methods safe`.
+- You can set your maximum connections through `--rpc-max-connections`, for example, `--rpc-max-connections 200`.
+- By default, localhost and Polkadot.js can access the RPC server. You can change this by setting `--rpc-cors`. To allow access from everywhere, you can use `--rpc-cors all`.
 
 For a list of important flags when running RPC nodes, refer to the Parity DevOps documentation: [Important Flags for Running an RPC Node](https://paritytech.github.io/devops-guide/guides/rpc_index.html?#important-flags-for-running-an-rpc-node){target=\_blank}.
 

infrastructure/running-a-node/setup-secure-wss.md

@@ -82,7 +82,7 @@ Apache2 can run in various modes, including `prefork`, `worker`, and `event`. In
 
 ## Connect to the Node
 
-1. Open [Polkadot.js Apps interface](https://polkadot.js.org/apps){target=\_blank} and click the logo in the top left to switch the node
+1. Open [Polkadot.js Apps interface](https://polkadot.js.org/apps){target=\_blank} and click the logo in the top left to switch the node.
 2. Activate the **Development** toggle and input either your node's domain or IP address. Remember to prefix with `wss://` and, if you're using the 443 port, append `:443` as follows:
 
     ```bash

infrastructure/running-a-validator/onboarding-and-offboarding/key-management.md

@@ -19,14 +19,14 @@ There are multiple ways to create the session keys. It can be done by interactin
 
 === "Polkadot.js Apps UI"
 
-    1. In Polkadot.js Apps, connect to your local node, navigate to the **Developer** dropdown, and select the **RPC Calls** option
+    1. In Polkadot.js Apps, connect to your local node, navigate to the **Developer** dropdown, and select the **RPC Calls** option.
 
-    2. Construct an `author_rotateKeys` RPC call and execute it
+    2. Construct an `author_rotateKeys` RPC call and execute it:
 
-        1. Select the **author** endpoint
-        2. Choose the **rotateKeys()** call
-        3. Click the **Submit RPC Call** button
-        4. Copy the hex-encoded public key from the response
+        1. Select the **author** endpoint.
+        2. Choose the **rotateKeys()** call.
+        3. Click the **Submit RPC Call** button.
+        4. Copy the hex-encoded public key from the response.
 
         ![](/images/infrastructure/running-a-validator/onboarding-and-offboarding/key-management/key-management-1.webp)
 
@@ -72,9 +72,9 @@ There are multiple ways to create the session keys. It can be done by interactin
 
 Now that you have generated your session keys, you must submit them to the chain. Follow these steps:
 
-1. Go to the **Network > Staking > Accounts** section on Polkadot.js Apps
-2. Select **Set Session Key** on the bonding account you generated earlier
-3. Paste the hex-encoded session key string you generated (from either the UI or CLI) into the input field and submit the transaction
+1. Go to the **Network > Staking > Accounts** section on Polkadot.js Apps.
+2. Select **Set Session Key** on the bonding account you generated earlier.
+3. Paste the hex-encoded session key string you generated (from either the UI or CLI) into the input field and submit the transaction.
 
 ![](/images/infrastructure/running-a-validator/onboarding-and-offboarding/key-management/key-management-2.webp)
 
@@ -84,8 +84,8 @@ Once the transaction is signed and submitted, your session keys will be register
 
 To verify that your session keys are properly set, you can use one of two RPC calls:
 
-- **`hasKey`** - checks if the node has a specific key by public key and key type
-- **`hasSessionKeys`** - verifies if your node has the full session key string associated with the validator
+- **`hasKey`**: Checks if the node has a specific key by public key and key type.
+- **`hasSessionKeys`**: Verifies if your node has the full session key string associated with the validator.
 
 For example, you can [check session keys on the Polkadot.js Apps](https://polkadot.js.org/apps/#/rpc){target=\_blank} interface or by running an RPC query against your node. Once this is done, your validator node is ready for its role.