diff --git a/tasks_answers/session5_answer.md b/tasks_answers/session5_answer.md
new file mode 100644
index 0000000..af40d5c
--- /dev/null
+++ b/tasks_answers/session5_answer.md
@@ -0,0 +1,124 @@
+# Ethereum Consensus Mechanisms: Casper LMD-GHOST, Checkpoint Sync, and Consensus Specifications
+
+## Introduction
+Ethereum’s consensus mechanism ensures the security, efficiency, and finalization of transactions within the network. This document provides an in-depth exploration of three essential components of Ethereum’s Proof-of-Stake (PoS) consensus mechanism:
+
+- **Casper LMD-GHOST**: The fork-choice rule that determines the best chain for block finalization.
+- **Checkpoint Sync**: A synchronization mechanism that enables nodes to efficiently sync with the network.
+- **Consensus Specifications**: The formal rules that govern validator behavior and network security.
+
+Each section provides detailed explanations, diagrams, and code snippets where applicable.
+
+---
+
+## **Casper LMD-GHOST**
+
+### **Overview**
+Casper LMD-GHOST (Latest Message Driven Greedy Heaviest Observed SubTree) is the fork-choice rule used in Ethereum’s Proof-of-Stake (PoS) consensus. It helps validators decide which chain to extend by selecting the heaviest subtree of blocks based on accumulated votes.
+
+### **How Casper LMD-GHOST Works**
+1. **Validators Vote on Blocks**
+   - Every validator casts an attestation (vote) on the latest block they consider valid.
+   - The vote is weighted by the validator’s stake.
+
+2. **Fork-Choice Decision**
+   - The chain with the highest accumulated weight (sum of validator votes) is chosen as the canonical chain.
+   - If two blocks have competing chains, the one with more accumulated votes is preferred.
+
+3. **Finalization**
+   - If a block is justified and later confirmed through multiple rounds of voting, it becomes finalized.
+   - Finalized blocks cannot be reverted unless a major network failure occurs.
+
+### **Diagram: Casper LMD-GHOST Fork-Choice Rule**
+![image](https://hackmd.io/_uploads/BJdMUlnTJg.png)
+
+
+### **Code Snippet: Casper LMD-GHOST (Python Pseudocode)**
+```python
+class Block:
+    def __init__(self, hash, parent, weight):
+        self.hash = hash
+        self.parent = parent
+        self.weight = weight
+
+class LMDGhost:
+    def select_head(self, blocks):
+        return max(blocks, key=lambda b: b.weight)
+```
+This pseudocode represents how the heaviest observed subtree is chosen using accumulated validator votes.
+
+---
+
+## **Checkpoint Sync**
+
+### **Overview**
+Checkpoint Sync is a mechanism that allows Ethereum nodes to quickly synchronize with the network using finalized checkpoints instead of downloading the entire blockchain history. It drastically reduces synchronization time.
+
+### **How Checkpoint Sync Works**
+1. **Nodes Fetch the Latest Finalized Checkpoint**
+   - Instead of downloading all past blocks, a new node starts from the latest finalized checkpoint.
+
+2. **Verify the Checkpoint’s Validity**
+   - Nodes ensure that the checkpoint is valid by verifying cryptographic proofs.
+
+3. **Continue Syncing from the Finalized Block**
+   - From this point, the node only downloads recent blocks rather than the entire history.
+
+### **Benefits of Checkpoint Sync**
+✅ Reduces sync time from days to minutes.  
+✅ Ensures new nodes start from a valid and finalized state.  
+✅ Lowers bandwidth and storage requirements.
+
+### **Diagram: Checkpoint Sync Process**
+![checkpoint-1024x535](https://hackmd.io/_uploads/r1OHnb36yx.png)
+
+
+---
+
+## **Consensus Specifications**
+
+### **Overview**
+Ethereum’s consensus specifications define the rules and responsibilities of validators, how blocks are finalized, and the penalties for misbehavior. These rules ensure the security and efficiency of the network.
+
+### **Key Components of Ethereum Consensus**
+
+#### **1. Validator Duties**
+- Validators are responsible for proposing new blocks and attesting to existing ones.
+- Each validator votes on the most valid block to finalize transactions.
+
+#### **2. Finality Conditions**
+- A block becomes **justified** if it receives enough attestations.
+- A block is **finalized** when it is justified and backed by another justified block in the next epoch.
+- Finalized blocks are immutable unless a catastrophic event occurs.
+
+#### **3. Slashing Conditions**
+Validators face penalties if they:
+- **Double vote** (vote for two conflicting chains simultaneously).
+- **Surround vote** (vote in a way that contradicts previous attestations).
+- **Fail to participate** in consensus for extended periods.
+
+### **Ethereum Consensus Specifications References**
+- **Ethereum Consensus Specs:** [https://github.com/ethereum/consensus-specs](https://github.com/ethereum/consensus-specs)
+- **Ethereum PoS Documentation:** [https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/)
+
+---
+
+## **Ethereum Networking Layer (DevP2P)**
+
+Ethereum uses a custom peer-to-peer (P2P) protocol called **DevP2P** to facilitate communication between nodes.
+
+### **How DevP2P Works**
+- **Node Discovery**: Ethereum nodes use a distributed hash table (DHT) to find peers.
+- **Peer Communication**: Nodes establish encrypted connections and exchange blocks, transactions, and consensus messages.
+- **Gossip Protocol**: Nodes relay new blocks and transactions across the network to ensure rapid dissemination.
+
+
+### **DevP2P Specifications and Resources**
+- [Ethereum DevP2P Documentation](https://github.com/ethereum/devp2p)
+- [Ethereum Networking Guide](https://ethereum.org/en/developers/docs/networking/)
+
+---
+
+## **Conclusion**
+Ethereum’s consensus mechanisms Casper LMD-GHOST, Checkpoint Sync, and Consensus Specifications work together to ensure secure and efficient transaction finalization. Additionally, the DevP2P networking layer facilitates seamless communication between nodes. Understanding these mechanisms is crucial for grasping Ethereum’s security, scalability, and reliability under Proof-of-Stake.
+