diff --git a/content/docs/architecture/cyclic-operations.mdx b/content/docs/architecture/cyclic-operations.mdx
index 3c2db2f..484fe94 100644
--- a/content/docs/architecture/cyclic-operations.mdx
+++ b/content/docs/architecture/cyclic-operations.mdx
@@ -9,7 +9,7 @@ Cyclic operations are a crucial component of the Shardeum blockchain network, en
 
 ### 2. Node List and Cycle Chain
 
-In Shardeum, maintaining an up-to-date and consistent node list is fundamental. Each node keeps a list of every other node, known as the **node list**, and a history of changes made to this list, referred to as the **cycle chain**. Nodes suggest changes to the node list through signed messages called updates. These updates are collected and processed within the cycles.
+In Shardeum, maintaining an up-to-date and consistent node list is fundamental. Each node keeps a list of every other node, known as the **node list**, and a history of changes made to this list, referred to as the **cycle chain**. Nodes suggest changes to the node list through signed messages called cycle transactions. These changes are collected and processed within the cycles.
 
 However, nodes only keep a limited history of cycle records at the validator level. When a node syncs with the network, it first receives a snapshot of each list. Following this, it uses the cycle process to update the list. Nodes do not maintain a full history because the sync-to-snapshot process suffices.
 
@@ -31,41 +31,38 @@ This process ensures the network remains consistent and synchronized, handling t
 
 ### 4. Phases of the Cycle
 
-* **Quarter 1: Update Phase Start**
+**Quarter 1: Update Phase Start**
   * **Function:** [`runQ1()`](https://github.com/shardeum/shardus-core/blob/e8c14ce4ba19785145646e840082acb57ec8ce3b/src/p2p/CycleCreator.ts#L496)
-  * **Detailed Operation:**
-    * Nodes use the `runQ1()` function to start collecting updates. This phase allows nodes to gather all the proposed changes, ensuring they have a comprehensive view of the network's current state.
-    * Nodes collect these updates for a specified duration, ensuring that all potential changes are captured for the current cycle.
+
+Detailed Operation:
+  * Nodes use the `runQ1()` and `runQ2()` functions to gather the proposed changes, ensuring they have a comprehensive view of the network's current state.
     * [`sendRequests()`](https://github.com/shardeum/shardus-core/blob/e8c14ce4ba19785145646e840082acb57ec8ce3b/src/p2p/Lost.ts#L582) in `p2p/Lost.ts` is invoked:
-      * **Lost Node Reporting:** It checks and reports nodes that are deemed lost based on certain conditions, using aggregated data collected until the first quarter (Q1).
-      * **Scheduled Removals:** It handles and processes scheduled node removals, ensuring nodes are removed as necessary and deletes them from the tracking list.
+* **Lost Node Reporting:** It tells the checker nodes to check on some nodes that were unresponsive.      * **Scheduled Removals:** It handles and processes scheduled node removals, ensuring nodes are removed as necessary and deletes them from the tracking list.
       * **Gossiping Status Updates:** It gossips information about nodes that have been verified as down to other nodes in the network, and manages self-refutation messages to update the network about nodes that are back online.
-    * [`sendRequests()`](https://github.com/shardeum/shardus-core/blob/e8c14ce4ba19785145646e840082acb57ec8ce3b/src/p2p/Apoptosis.ts#L296) from `p2p/Apoptosis.ts` is invoked:
-      * When a node decides to exit the network, it sends an Apoptosis message to around three other active nodes to notify them of its departure, allowing for immediate removal from their node lists. This message, which can be sent at any time, is verified and stored to be gossiped in the next quarter 1, ensuring the exiting node is quickly removed from the network's node list without waiting for the usual discovery process.
-    * [`sendRequests()`](https://github.com/shardeum/shardus-core/blob/e8c14ce4ba19785145646e840082acb57ec8ce3b/src/p2p/Active.ts#L262) from `p2p/Active.ts` is invoked:
-      * This function handles the process of sending queued requests for a node to become active in the network. If a request is queued and the node is not restricted from becoming active, it signs the request and attempts to add it to the list of active transactions. It then gossips the signed request to other nodes. If the node does not become active within the expected cycle duration, it retries the request. If the node goes active, it stops the retry process.
-    * [`sendRequests()`](https://github.com/shardeum/shardus-core/blob/e8c14ce4ba19785145646e840082acb57ec8ce3b/src/p2p/LostArchivers/index.ts#L199) from `p2p/LostArchivers/index.ts` is invoked:
-      * This function manages the `lostArchiversMap`. It logs the current state of the map for debugging, then iterates through each entry to handle different statuses. For 'reported' entries, it creates and sends an investigation message and removes the entry. For 'down' statuses that haven't been gossiped, it creates and gossips a down message, marking it as gossiped. Similarly, for 'up' statuses, it creates and gossips an up message, marking it as gossiped. This ensures accurate and timely updates about the status of archivers in the network.
+    * [`sendRequests()`](https://github.com/shardeum/shardus-core/blob/0106966cd63fa7836f9d02ada452094d7ea84974/src/p2p/Join/index.ts#L604) from `p2p/Join/index.ts` is invoked:
+      * This function processes queued syncing and standby refresh requests by signing and validating them, and then gossiping the relevant messages to the network.
     * Config queue changes and debug logic updates are being handled in a [listener](https://github.com/shardeum/shardus-core/blob/e8c14ce4ba19785145646e840082acb57ec8ce3b/src/shardus/index.ts#L934-L947) inside the `shardus.ts` [`start()`](https://github.com/shardeum/shardus-core/blob/e8c14ce4ba19785145646e840082acb57ec8ce3b/src/shardus/index.ts#L435) function.
     * Changes in network coverage are calculated and summaries of previous cycles are processed are being executed by [listener](https://github.com/shardeum/shardus-core/blob/e8c14ce4ba19785145646e840082acb57ec8ce3b/src/state-manager/index.ts#L3703-L3740) in `state-manager.ts` `startShardCalculations()`.
-* **Quarter 2: Update Phase End**
+
+**Quarter 2: Update Phase End**
   * **Function:** [`runQ2()`](https://github.com/shardeum/shardus-core/blob/e8c14ce4ba19785145646e840082acb57ec8ce3b/src/p2p/CycleCreator.ts#L526)
-  * **Detailed Operation:**
+
+Detailed Operation:
     * The `runQ2()` function marks the end of this collection period, consolidating the updates for synchronization.
     * Node selection is triggered by [`executeNodeSelection()`](https://github.com/shardeum/shardus-core/blob/e8c14ce4ba19785145646e840082acb57ec8ce3b/src/p2p/Join/v2/select.ts#L28-L38).
 * **Quarter 3: Cycle Sync Start**
   * **Function:** [`runQ3()`](https://github.com/shardeum/shardus-core/blob/e8c14ce4ba19785145646e840082acb57ec8ce3b/src/p2p/CycleCreator.ts#L561)
-  * **Detailed Operation:**
+
+Detailed Operation:
     * During `runQ3()`, nodes compare their collected updates by exchanging hashes (`cycle_tx_hash`). This step ensures all nodes have a consistent view of the updates.
     * Nodes validate these updates by checking the `cycle_tx_hash` and creating a cycle certificate based on the highest value votes from other nodes. This certificate ensures that only valid updates are applied.
     * Nodes gossip their certificates to ensure the network agrees on the cycle's contents.
     * Cycle data is being [cleaned up](https://github.com/shardeum/shardus-core/blob/e8c14ce4ba19785145646e840082acb57ec8ce3b/src/state-manager/index.ts#L3742-L3770) on every 5 cycles.
 * **Quarter 4: Cycle Finalization**
   * **Function:** [`runQ4()`](https://github.com/shardeum/shardus-core/blob/e8c14ce4ba19785145646e840082acb57ec8ce3b/src/p2p/CycleCreator.ts#L634)
-  * **Detailed Operation:**
-    * The `runQ4()` function handles the final certification of the updates. Nodes certify the agreed updates, creating a cycle marker and certificate to log the cycle's changes.
-    * This phase ensures the network's integrity by preventing double voting and other malicious activities through a robust consensus mechanism.
-    * Nodes prune the cycle chain to keep it within a manageable size, typically retaining a set number of recent cycles.
+
+Detailed Operation:
+  * The `runQ4()` function involves comparing cycle certificates with other nodes until the best one is identified.
 
 ![Cycle](/img/new/i8.jpg)
 
diff --git a/content/docs/architecture/node-lifecycle.mdx b/content/docs/architecture/node-lifecycle.mdx
index 6d8aec4..f64eda8 100644
--- a/content/docs/architecture/node-lifecycle.mdx
+++ b/content/docs/architecture/node-lifecycle.mdx
@@ -18,7 +18,8 @@ In the network, nodes exist in two primary states:
 
 * **Staking and Joining**: To enter the standby list, nodes must first stake and submit a join request. This process involves creating a staking transaction, which is validated and recorded on the blockchain. The staking information is stored in the node and the operator account. Each staking transaction is associated with a unique address and includes a JSON blob containing the staking instructions, encoded in base 64. This allows the system to easily recognize and validate staking transactions without processing them through the EVM. Once validated, the user's balance is updated, and node and operator accounts are updated. This process is secured by requiring nodes to present signed certificates, ensuring that only verified nodes can enter the queue. The request to join the standby list can be seen at [`addStandbyJoinRequests()`](https://github.com/shardeum/shardus-core/blob/8e69984a098c8ed387ca8f0684b313a75f85aec4/src/p2p/Join/v2/index.ts#L107).
 * **Rotation:** Nodes are periodically rotated out of active duty as a measure of security and efficiency. The network chooses which nodes to rotate based on their age (expired nodes). The number of nodes that will be replaced with ones from the standby list is a configurable parameter. The expired and removed nodes are returned from [`getExpiredRemoved()`](https://github.com/shardeum/shardus-core/blob/8e69984a098c8ed387ca8f0684b313a75f85aec4/src/p2p/Rotation.ts#L118).
-![Cycle](/img/new/i8.jpg)
+
+![Cycle](/img/new/iframe2000.jpg)
 
 ### 4. Node Selection and Activation
 
@@ -26,7 +27,7 @@ In the network, nodes exist in two primary states:
 * **Syncing Process:** When a node is selected to become active, it first enters a syncing mode to prevent disruptions in case it is chosen but turns off unexpectedly, stalling the process. The node begins by syncing cycle data from the network, followed by syncing account data relevant to it from other nodes. After completing this process, the node notifies the network that it has finished syncing. If a node fails to complete syncing within a specified threshold (typically double the median sync time of active nodes), it is subject to slashing and removal from the network. The syncing process can be examined in [`sync()`](https://github.com/shardeum/shardus-core/blob/8e69984a098c8ed387ca8f0684b313a75f85aec4/src/p2p/Sync.ts#L97).
 * **Activation Process:** Once syncing is complete, nodes do not immediately become active due to the complexities involved in sharding calculations. These calculations could significantly disrupt the address space, creating conflicts over which nodes possess the necessary data. To maintain a steady rate of activation, only a certain number of nodes are allowed to go active in each cycle. This helps to smooth out potential waves and inconsistencies. The data synced from the queued nodes is discarded, as the likelihood of a node being assigned to the same shard in the next cycle is very low. Additionally, the time it might take for this node to be randomly selected again could be substantial. The activation process can be seen in [`updateRecord()`](https://github.com/shardeum/shardus-core/blob/8e69984a098c8ed387ca8f0684b313a75f85aec4/src/p2p/Active.ts#L146).
 
-
+![Cycle](/img/new/lifecycle2.jpg)
 
 ### 5. Handling Node Failures and Loss Detection
 
@@ -54,7 +55,7 @@ The lost node detection system kicks into action when a node (Node A) attempts t
 * **Finality of Status**: If Node B fails to refute its status, it is permanently removed from the active node list, ensuring that only functional and honest nodes participate in network activities.
 * The status of the node is updated in [`updateRecord()`](https://github.com/shardeum/shardus-core/blob/8e69984a098c8ed387ca8f0684b313a75f85aec4/src/p2p/Lost.ts#L429).
 
-![Cycle](/img/new/i31.jpg)
+![Cycle](/img/new/lifecycle1.jpg)
 
 #### 5.5 Prevention of Abuse
 
diff --git a/content/docs/architecture/security/node-security-and-integrity.mdx b/content/docs/architecture/security/node-security-and-integrity.mdx
index b23e423..a28cecb 100644
--- a/content/docs/architecture/security/node-security-and-integrity.mdx
+++ b/content/docs/architecture/security/node-security-and-integrity.mdx
@@ -6,33 +6,27 @@ title: Node Security & Integrity
 
 Node security and integrity are critical components of the Shardeum blockchain, ensuring that nodes operate correctly and the network remains secure against unauthorized or malicious activities. The following sections detail the comprehensive security measures implemented in Shardeum to prevent unauthorized or malicious behavior by nodes.
 
-### **2. Node Authentication and Authorization**
-
-Every node in the Shardeum network must be authenticated before joining. The authentication process checks the legitimacy and integrity of the nodes to ensure compliance with the network's standards. This process guarantees that only legitimate and verified nodes can participate in network activities, reducing the risk of malicious entities infiltrating the network.
-
-![Node Authentication](/img/new/i41.png)
-
-### **3. Validator Security**
+### **2. Validator Security**
 
 Shardeum employs a system where every active validator must know all other active validators. This control and visibility prevent unauthorized nodes from participating in the consensus process, ensuring only verified nodes can validate transactions.
 
-![Validator Security](/img/new/i43.png)
+![Validator Security](/img/image4247.png)
 
-### **4. Permissioned Standby List**
+### **3. Permissioned Standby List**
 
 Nodes in the standby list are permissioned, meaning their credentials and roles are pre-verified before they can become active validators. This ensures that the standby nodes meet all network security requirements before activation, preventing infiltration by malicious nodes.
 
 ![Permissioned Standby List](/img/new/i44.png)
 
-### **5. Deterministic Lottery for Node Selection**
+### **4. Deterministic Lottery for Node Selection**
 
 The transition from standby to active nodes is governed by a deterministic lottery system. This system is designed to be tamper-proof, making it impossible for standby nodes to manipulate their selection. The lottery is based on cryptographic principles that ensure fairness and randomness, preventing any single node from gaining an unfair advantage.
 
-### **6. Consensus Mechanism**
+### **5. Consensus Mechanism**
 
 Shardeum employs a combination of Proof of Stake (PoS) and Byzantine Fault Tolerance (BFT) for its consensus mechanism. This hybrid approach ensures that nodes participating in the consensus process are both financially incentivized and cryptographically secured to act honestly. Validators are selected based on their stake, and BFT consensus ensures fast and secure transaction finality. This combination reduces the risk of Sybil attacks, where an attacker might create multiple fake nodes to gain control of the network.
 
-### **7. Slashing Mechanisms**
+### **6. Slashing Mechanisms**
 
 Shardeum has implemented robust slashing mechanisms to penalize nodes that exhibit malicious behavior or fail to perform their duties correctly. Key slashing rules and their enforcement include:
 
@@ -42,7 +36,7 @@ Shardeum has implemented robust slashing mechanisms to penalize nodes that exhib
 
 These slashing rules ensure that nodes operate honestly and contribute positively to the network's security and integrity.
 
-### **8. Lost Node Detection and Refutation**
+### **7. Lost Node Detection and Refutation**
 
 To maintain network stability, Shardeum has a system to detect and handle lost nodes. A node is considered lost if it fails to respond to requests. The detection process involves:
 
@@ -51,44 +45,56 @@ To maintain network stability, Shardeum has a system to detect and handle lost n
 
 Refutation involves the node proving its activity and rejoining the network. Persistent failure to refute leads to penalties and eventual removal.
 
-### **9. Transaction Lifecycle and Nonce Handling**
+### **8. Transaction Lifecycle and Nonce Handling**
 
 Shardeum's transaction lifecycle includes several security features to prevent unauthorized transactions and replay attacks:
 
 * **Nonce Mechanism**: Each transaction includes a nonce, which is a sequential number to prevent replay attacks. Transactions with nonces out of order are held until the preceding transactions are processed.
 * **Signature Verification**: Transactions must be signed with the sender’s private key, ensuring that only authorized parties can initiate transactions from an account.
 
-### **10. Access Lists and Memory Management**
+### **9. Access Lists and Memory Management**
 
 Shardeum uses access lists to manage and control memory access during transaction execution. This ensures that transactions do not interfere with each other, preventing unauthorized data manipulation:
 
 * **Predictive Access Lists**: Before execution, transactions provide access lists indicating which parts of memory they will touch. This helps schedule transactions and avoid conflicts.
 * **Runtime Verification**: During execution, if a transaction tries to access memory not listed in its access list, it is flagged and potentially rejected. This prevents unauthorized data access and manipulation.
 
-### **11. Dynamic State Sharding and Data Healing**
+### **10. Dynamic State Sharding and Data Healing**
 
 Shardeum's dynamic state sharding ensures balanced resource usage and prevents bottlenecks. The network dynamically assigns transactions to shards based on load. Data integrity across shards is maintained through:
 
 * **Data Healing**: Nodes periodically compare their state against hashes of data held by other nodes. If discrepancies are detected, nodes request the correct data from their peers and update their state accordingly.
 * **Efficient Hashing**: Shardeum employs a custom hashing algorithm suitable for a sharded network, allowing efficient verification and repair of data across shards.
 
-### **12. Node Lifecycle Management and Certificates**
+### **11. Node Lifecycle Management and Certificates**
 
 The node lifecycle in Shardeum includes several steps to ensure only legitimate nodes participate in the network:
 
 * **Certificate-Based Staking**: Nodes must obtain certificates to join the network. This involves staking tokens, getting certificates from existing nodes, and passing readiness checks.
 * **Standby and Active Modes**: Nodes join the network in standby mode and undergo a rigorous syncing process before becoming active. This includes syncing cycle data and account data, ensuring they are up-to-date and ready to participate in consensus.
 
-### **13. Networking and Gossip Protocol**
+### **12. Networking and Gossip Protocol**
 
 Shardeum uses a custom networking library and a gossip protocol to ensure efficient and secure communication between nodes:
 
 * **Shardeum Net**: This internal protocol handles socket connections between nodes, with optimizations for performance and security.
 * **Gossip Protocol**: For broadcasting messages efficiently, Shardeum uses a gossip protocol where messages propagate quickly and redundantly across the network, reducing the chance of missing critical information.
 
-### **14. Periodic Patching and Consensus on State**
+### **13. Periodic Patching and Consensus on State**
 
 To maintain data consistency and integrity:
 
 * **Periodic Patching**: Nodes engage in periodic state checks using a tree structure to identify and correct discrepancies.
 * **Consensus on State**: Nodes share state hashes with each other and repair any mismatches through efficient data requests, ensuring all nodes have the correct and consistent state data.
+
+### 14. Network Modes
+
+Shardeum uses various network modes to ensure stability and consistency throughout its lifecycle. The key network modes include:
+
+* **Forming:** The network allows nodes to join, sync, and go active until a minimum number of active nodes is achieved.
+* **Processing:** The network processes application transactions. Nodes can be rotated.
+* **Safety:** Only protocol transactions are processed.
+* **Recovery:** The network stops processing application transactions and nodes stop syncing application data, but still handle protocol data.
+* **Restart:** The network allows nodes to join without syncing or going active until a minimum total node count is reached.
+* **Restore:** Nodes sync data from Archivers and other nodes, going active once synced.
+* **Shutdown:** All transactions stop being processed and nodes exit the network after a short period.
\ No newline at end of file
diff --git a/content/docs/architecture/transaction-lifecycle.mdx b/content/docs/architecture/transaction-lifecycle.mdx
index b68301c..314293b 100644
--- a/content/docs/architecture/transaction-lifecycle.mdx
+++ b/content/docs/architecture/transaction-lifecycle.mdx
@@ -3,7 +3,6 @@ title: Transaction Lifcycle
 description: Learn Shardeum's transaction lifecycle
 ---
 
-
 ### 1. Overview
 
 The transaction lifecycle in the network encompasses both protocol-level transactions, which maintain network cycles and handle consensus, and user transactions, which include coin transfers and smart contract interactions. User transactions are particularly significant for measuring transactions per second (TPS), as these are the interactions that most users care about. Unlike some other networks that count internal transactions towards TPS, this network only counts user transactions to provide an honest metric.
@@ -26,7 +25,7 @@ The transaction lifecycle in the network encompasses both protocol-level transac
 * **Validator Network**: The transaction is initially sent to one active validator. Then, this transaction is distributed to validators in the transaction group using the gossip protocol. Each validator in the group holds a part of the transaction data necessary for processing. For example, if a transaction requires access to account data for accounts A, B, and C, then each of these accounts will have its own consensus group. Let's say there is a consensus group for account A, a consensus group for account B, and a consensus group for account C. Together, these three consensus groups form a transaction group. Each validator within these consensus groups collaborates to process the transaction. These consensus groups can be perfectly or partially overlapped, ensuring flexibility and efficiency in transaction processing. The forwarding of a transaction is executed by the gossip protocol with the [`spread_tx_to_group`](https://github.com/shardeum/shardus-core/blob/e8c14ce4ba19785145646e840082acb57ec8ce3b/src/state-manager/TransactionQueue.ts#L2238) message.
 * **Execution Group Selection**: Before placing the transaction in a queue, an execution group is selected. The developers have determined that 2/3 of the shard size is enough to determine the value of a transaction. However, the shard executing the transaction may not have all necessary information for accounts B and C. The function that enqueues and choses the execution group is [`routeAndQueueAcceptedTransaction()`](https://github.com/shardeum/shardus-core/blob/e8c14ce4ba19785145646e840082acb57ec8ce3b/src/state-manager/TransactionQueue.ts#L1810).
 
-![Transaction Submission](/img/new/i5.jpg)
+![Transaction Submission](/img/new/iframe3540.jpg)
 
 * **Transaction Group Dynamics**: Validators use a "corresponding tell" process to efficiently share data needed for transaction processing. For instance, if Account B's data is required by an execution group, nodes in Account B's consensus group will forward this data to the nodes in the execution group. This process is designed to be efficient and secure, preventing any single node from unduly influencing the transaction by ensuring data is only forwarded to a specific node as defined by sharding math. The sending of this message is done in [`tellCorrespondingNodes()`](https://github.com/shardeum/shardus-core/blob/e8c14ce4ba19785145646e840082acb57ec8ce3b/src/state-manager/TransactionQueue.ts#L3930).
 * **Consensus Formation**: Validators execute the transaction, apply it to their local state, and form a consensus on the transaction’s result. The process begins with execution group validators waiting to receive all necessary data for a given transaction, sometimes from non-execution group nodes. Note that no data can be sent or loaded while there are upstream transactions that could modify the state.\
@@ -44,7 +43,7 @@ The transaction lifecycle in the network encompasses both protocol-level transac
   There are two variations of gossip algorithms used in the network: "Burst" and "Linear." These algorithms differ in their deterministic calculations of how many messages are sent out at each level of gossip. "Burst" sends more messages and is typically used for gossiping to large groups, such as all nodes. In most cases, "Linear" gossip is preferred, note that while it also includes a burst aspect, it is less pronounced compared to the "Burst" algorithm.
 * The main function the processes transactions is [`processTransactions()`](https://github.com/shardeum/shardus-core/blob/e8c14ce4ba19785145646e840082acb57ec8ce3b/src/state-manager/TransactionQueue.ts#L4623).
 
-![Validator Stages](/img/new/i6.jpg)
+![Validator Stages](/img/new/iframe3541.jpg)
 
 ### 5. Data Distribution and State Updates
 
diff --git a/content/docs/architecture/validator-operations.mdx b/content/docs/architecture/validator-operations.mdx
index 1ef5767..dbe157e 100644
--- a/content/docs/architecture/validator-operations.mdx
+++ b/content/docs/architecture/validator-operations.mdx
@@ -87,9 +87,8 @@ Example: If a smart contract manages a token balance, each user's balance is sto
 
 * **Purpose of Slashing:** Slashing serves as a penalty for validators that exhibit malicious or undesirable behavior. This includes actions such as leaving the network prematurely or attempting to double vote on transactions. When such behavior is detected, the network imposes a penalty, reducing the validator's stake.
 * **Examples of Slashing Conditions:**
-  * **Early Exit:** Validators that leave the network before completing their assigned duty cycle are penalized to discourage instability.
-  * **Double Voting:** Validators attempting to double vote on a transaction are penalized, as this behavior can undermine the consensus process.
-  * **Lazy Nodes:** Validators that fail to participate actively or meet their responsibilities can be penalized to ensure network efficiency and reliability.
+* **Early Exit:** Validators that leave the network before completing their assigned duty cycle are penalized to discourage instability.
+* **Double Voting:** Validators attempting to double vote on a transaction are penalized, as this behavior can undermine the consensus process.  * **Lazy Nodes:** Validators that fail to participate actively or meet their responsibilities can be penalized to ensure network efficiency and reliability.
 * **Slashing Process:** Slashing involves submitting a transaction to the network, detailing the offense and the proposed penalty. Other validators then vote on this transaction to form a consensus. If agreed upon, the penalty is enforced, and the validator's stake is reduced accordingly. This process ensures that all changes to the state are recorded through consensus, maintaining the integrity of the distributed ledger.
 
 ![Slashing Mechanisms](/img/new/validator1.jpg)
diff --git a/content/docs/faucet/claim.mdx b/content/docs/faucet/claim.mdx
index 68b0f89..d90d33d 100644
--- a/content/docs/faucet/claim.mdx
+++ b/content/docs/faucet/claim.mdx
@@ -15,12 +15,6 @@ title: Claim Testnet SHM
 
 3. Go to the faucet channel in Shardeum discord.
 
-import { Callout } from 'fumadocs-ui/components/callout';
- 
-<Callout title="Atomium Limit" type="info">
-  Atomium faucet only allows 1 claim (8 SHM) every 24 hours
-</Callout>
-
     - Atomium: https://discord.com/channels/933959587462254612/1253938152775749673 
     - Sphinx: https://discord.com/channels/933959587462254612/1070780355931541514
 
diff --git a/content/docs/smart-contracts/boilerplate.mdx b/content/docs/smart-contracts/boilerplate.mdx
index dc58bb1..7ac0606 100644
--- a/content/docs/smart-contracts/boilerplate.mdx
+++ b/content/docs/smart-contracts/boilerplate.mdx
@@ -55,22 +55,18 @@ npm install
 
 npm run dev
 ```
-##  Usecases
-There are three primary modules in the boilerplate:
-
-- **RPC:** This module demonstrates the functionality of an Shardeum RPC. Be in reading useful data from the blockchain or sending transactions, rpcs serve as a gateway to the blockchain.
-
-- **NFT Minting:** This module demonstrates a basic NFT minting page which let's user mint NFTs for a fixed mint price.
 
-- **DeFi:** This module demonstrate the use of Uniswap V2 to swap between two tokens.
+## Usecases
+There are three primary modules in the boilerplate:
+- **RPC**: This module demonstrates the functionality of a Shardeum RPC. Whether it is reading useful data from the blockchain or sending transactions, RPCs serve as a gateway to the blockchain.
+- **NFT Minting**: This module demonstrates a basic NFT minting page which lets users mint NFTs for a fixed mint price.
+- **DeFi**: This module demonstrates the use of Uniswap V2 to swap between two tokens.
 
 ## Layout
 
 - **Header**: An easily configurable header with wallet connect functionality along with displaying user address and balance.
+- **Pages**: Individual pages for demonstrating functionality for 3 major verticals in web3 - RPC, NFT, and DeFi.
+- **Smart Contracts**: All primary smart contracts used in the application can be found in the '**contracts**' directory, and the appropriate scripts in the '**scripts**' directory.
 
-- **Pages**: Individual pages for demonstrating functionality for 3 major verticals in web3 - RPC, NFT and Defi.
-
-- **Smart Contracts**: All primary smart contracts used in the application can be found in the '**contracts**' directory and the appropriate scripts in the '**scripts**' directory.
-
-##  Contributing Guidelines
+## Contributing Guidelines
 We warmly welcome contributions to the Shardeum Dapp Boilerplate! Whether you're fixing bugs, adding new features, or improving documentation, your help makes a big difference.
diff --git a/public/img/image4247.png b/public/img/image4247.png
new file mode 100644
index 0000000..89cdff7
Binary files /dev/null and b/public/img/image4247.png differ
diff --git a/public/img/new/Frame 3572 copy.jpg b/public/img/new/Frame 3572 copy.jpg
new file mode 100644
index 0000000..435406c
Binary files /dev/null and b/public/img/new/Frame 3572 copy.jpg differ
diff --git a/public/img/new/iframe2000.jpg b/public/img/new/iframe2000.jpg
new file mode 100644
index 0000000..cd1ef3f
Binary files /dev/null and b/public/img/new/iframe2000.jpg differ
diff --git a/public/img/new/iframe3540.jpg b/public/img/new/iframe3540.jpg
new file mode 100644
index 0000000..5226a8b
Binary files /dev/null and b/public/img/new/iframe3540.jpg differ
diff --git a/public/img/new/iframe3541.jpg b/public/img/new/iframe3541.jpg
new file mode 100644
index 0000000..531b0d9
Binary files /dev/null and b/public/img/new/iframe3541.jpg differ
diff --git a/public/img/new/image copy.png b/public/img/new/image copy.png
new file mode 100644
index 0000000..89cdff7
Binary files /dev/null and b/public/img/new/image copy.png differ
diff --git a/public/img/new/lifecycle1.jpg b/public/img/new/lifecycle1.jpg
new file mode 100644
index 0000000..69b1d7d
Binary files /dev/null and b/public/img/new/lifecycle1.jpg differ
diff --git a/public/img/new/lifecycle2.jpg b/public/img/new/lifecycle2.jpg
new file mode 100644
index 0000000..71d62f3
Binary files /dev/null and b/public/img/new/lifecycle2.jpg differ