docs(addition): add Sol testnet validator guide

docs/docs/develop/guest-blockchain-testnet.md

@@ -0,0 +1,47 @@
+# Guest Blockchain Testnet Guide
+
+:::info
+This document serves as a guide for becoming a validator of the Guest Blockchain on Solana during the testing phase. Only current Solana validators have the capability to validate the Guest Blockchain. Additional information can be found [here](../technology/solana-restaking/technical-overview.md).
+:::
+
+### Validator Security Model
+The validator set of the Guest Blockchain will be directed by majority where it is the responsibility of active validators to maintain uptime and sign corresponding payloads of transactions.
+
+### Bonding
+
+Joining as a validator will require a bonded stake to keep participation gated from malicious actors easily onboarding. The size of the bond will be 0.1 SOL.
+
+### (Re) Staking
+The validator set will be able to utilize liquid staked derivatives of SOL, such as jitoSOL, mSOL, bSOL and LST.   
+
+### Oracles
+Pyth oracle will be used to access pricing feeds for LSD assets staked to the platform. 
+
+## Validator Setup
+
+1. Install the validator CLI using the following command (From `validator-testing` branch) 
+```
+cargo install --git https://github.com/composableFi/emulated-light-client#validator-testing
+```
+2. Check if the validator CLI is installed using the following command. The current version should be returned as a value indicating successful installation.
+```
+validator --version
+> 0.0.1
+```
+3. Set up the rpc url with validator keypair using the command below (note that the program ID is already added). Try to use custom 
+rpc since the solana public rpc is not good enough to send transactions and will usually be dropped frequently. You can get the rpc
+from helius, quicknode or triton. Keypair path is the path to your keypair json file. [For Example](https://github.com/ComposableFi/emulated-light-client/blob/2313bbd4c1f838ce36b894e781ede5eb63b7c698/solana/solana-ibc/keypair.json)
+```
+validator init --rpc-url <RPC_URL> --ws-url <WS_URL> --program-id 7uvnkZxh7Z1wwVFMQ1ak7u4LXWx9f8tkgUnMMyiZrSZb --keypair-path <KEYPAIR_PATH>
+```
+4. Once the config file is set, run the validator. 
+```
+validator run
+```
+:::note
+You can even pass any of the arguments which would override the default config set in previous step. These arguments are
+optional and has higher preference than the default config file. Any of the arguments can be passes and its not neccessary to pass
+all of them.
+```
+validator run --rpc-url <RPC_URL> --ws-url <WS_URL> --program-id 7uvnkZxh7Z1wwVFMQ1ak7u4LXWx9f8tkgUnMMyiZrSZb --keypair-path <KEYPAIR_PATH>
+:::

docs/docs/technology/mantis/protocol-flow.md

@@ -1,32 +1,32 @@
 # Protocol Flow
-A summary of the flow of the MANTIS protocol is below, with further details found in subsequent sections of this documentation:
+A summary of the MANTIS protocol flow in different scenarios is below, with further details found in subsequent sections of this documentation:
 
-1. **Intent Submission**:
+## 1. Intent Submission:
 - **User-Driven Transactions**: Users specify their transaction requirements, typically involving an exchange of a certain amount of one cryptocurrency (Token A) for another (Token B).
 - **Assisted Order Formulation**: MANTIS assists in setting up order limits; in the example of exchanging A for B, MANTIS provides suggestions for the exchange amount of Token B. The exchange rate will not be less than the user-defined A/B ratio.
 - **Confirmation and Blockchain Registration**: Users review, confirm, and sign their transaction details for blockchain recording.
 - **Timeout vs. Price Limits**: A balance between price limits and matching times is maintained, with tighter limits possibly leading to longer wait times for order matching.
 
-2. **Order Execution Observation**:
+## 2. Order Execution Observation:
 - **Status Monitoring**: Users can track the status of their orders post-placement.
 - **Possible Outcomes**: Orders may be fully executed, partially filled, canceled, or timed out.
 - **Handling Partial Fills**: Partially filled orders result in users receiving a portion of the requested amount, with the remainder being canceled or expiring based on the order settings.
 
-3. **Single-Chain Execution Scenario**:
+## 3a. Single-Chain Execution Scenario:
 - **Efficient Execution**: The platform swiftly matches orders in a single transaction block for prompt fulfillment.
 - **Batch Auctions**: Batch Auctions process multiple orders simultaneously, maximizing the product of exchanged amounts (A * B) for efficient matching.
 
-    **Order Pricing**:
+### 3b. Order Pricing:
 
 - **Dynamic Price Matching**: The platform matches orders to achieve optimal trading volume without violating user-set limits.
 - **Execution at Optimal Prices**: Execution occurs at a price that maximizes volume, ensuring efficiency.
 
-1. **Cross-Chain Execution Scenario**:
+## 4. Cross-Chain Execution Scenario:
 - **Multi-Chain Execution**: Certain orders are executed using liquidity pools across multiple blockchain networks, involving several blocks and chains.
 - **Cross-Chain Virtual Machine (CVM) Program**: The CVM facilitates these transactions, ensuring efficient multi-chain swaps.
 - **Monitoring Interface**: A detailed interface provides real-time updates for multi-chain transactions.
 - **Cross-Chain Transfers**: This includes straightforward cross-chain transfers.
 
-The above components are displayed in the following architecture diagram of Composable’s Cosmos chain:
+The above components are displayed in some form in the following architecture diagram of Composable’s Cosmos chain:
 
 ![architecture](../mantis/components.png)

docs/sidebars.js

@@ -267,6 +267,7 @@ mantis: [
       id: "develop/build-on-composable",
     },
     "develop/composable-cosmos",
+    "develop/guest-blockchain-testnet",
     "develop/local-picasso-guide",
     "develop/oracle-set-up-guide",
     "develop/collator-guide",