diff --git a/site/docs/community-responses/frontrunning-and-attack-vectors.md b/site/docs/community-responses/frontrunning-and-attack-vectors.md
new file mode 100644
index 000000000..0faa14b9e
--- /dev/null
+++ b/site/docs/community-responses/frontrunning-and-attack-vectors.md
@@ -0,0 +1,70 @@
+---
+sidebar_position: 4
+---
+
+# Frontrunning and Attack Vectors
+
+## Concern
+
+Community feedback raised concerns about potential attack vectors in the proposed Leios protocol, specifically regarding frontrunning opportunities and resource waste attacks through empty or minimal blocks.
+
+> "Empty blocks have value in Praos (chain length) but empty EBs are negative value in Leios... [this creates] frontrunning concerns."
+
+
+
+
+
+## Analysis
+
+The concerns about frontrunning and resource waste attacks require examination within the broader context of blockchain security and the existing Praos system.
+
+### Frontrunning Context
+
+Frontrunning opportunities in proposed Leios are fundamentally similar to those in the current Praos system:
+
+**Current Praos**: Block producers can selectively include transactions from the mempool, enabling frontrunning through transaction ordering or exclusion.
+
+**Proposed Leios**: Similar selective inclusion capabilities exist, but with increased throughput providing more opportunities overall. This represents a **quantitative** rather than **qualitative** change in frontrunning potential.
+
+### Empty Block Analysis
+
+The concern about "empty EBs having negative value" requires clarification:
+
+- **Empty EBs**: Have zero bytes in length and trigger no diffusion or voting when announced
+- **Minimal EBs**: Could theoretically waste voting resources relative to transaction throughput
+- **Mitigation**: Protocol can enforce minimum EB size requirements to address disproportionate voting costs
+
+### Resource Waste Attack Vectors
+
+The potential for adversarial resource waste exists but must be evaluated against:
+
+1. **Attack Cost**: Producing EBs requires winning sortition, limiting attack frequency
+2. **Waste Magnitude**: Voting verification represents minimal computational cost (~600ms total across all validators)
+3. **Existing Vulnerabilities**: Current Praos system has similar attack surfaces through mempool manipulation
+
+### Comparative Security Analysis
+
+Proposed Leios does not introduce fundamentally new attack vectors but may amplify existing ones due to increased throughput. However:
+
+- **Detection**: Malicious behavior patterns are observable and can trigger community response
+- **Cost-Benefit**: Attack costs generally exceed potential benefits
+- **Mitigation**: Protocol parameters can be adjusted to minimize attack effectiveness
+
+## Conclusion
+
+While proposed Leios may increase the scale of certain attack opportunities due to higher throughput, it does not introduce qualitatively new vulnerabilities. The protocol includes mechanisms to mitigate resource waste attacks, and the increased frontrunning potential is a natural consequence of improved scalability rather than a design flaw.
+
+Comprehensive security analysis and potential parameter adjustments can further minimize these risks while preserving the protocol's scalability benefits.
+
+---
+
+**References**: [CIP Leios Specification](https://github.com/cardano-scaling/CIPs/blob/leios/CIP-0164/README.md#specification)
diff --git a/site/docs/community-responses/index.md b/site/docs/community-responses/index.md
new file mode 100644
index 000000000..eb99ee865
--- /dev/null
+++ b/site/docs/community-responses/index.md
@@ -0,0 +1,18 @@
+---
+sidebar_position: 1
+---
+
+# Overview
+
+Following the publication of the [Leios CIP](https://github.com/cardano-scaling/CIPs/blob/leios/CIP-0164/README.md), we've received community feedback through video analyses and technical discussions. This section addresses specific claims and questions about the proposed Leios protocol.
+
+## Topics
+
+### Efficiency and Resource Utilization
+- [Efficiency of Discarded Endorser Blocks](./wasted-work-discarded-ebs.md)
+
+### Performance and Scalability
+- [System Performance Under Load](./system-performance-under-load.md)
+
+### Protocol Design and Security
+- [Frontrunning and Attack Vectors](./frontrunning-and-attack-vectors.md)
diff --git a/site/docs/community-responses/system-performance-under-load.md b/site/docs/community-responses/system-performance-under-load.md
new file mode 100644
index 000000000..0083846ad
--- /dev/null
+++ b/site/docs/community-responses/system-performance-under-load.md
@@ -0,0 +1,94 @@
+---
+sidebar_position: 3
+---
+
+# System Performance Under Load
+
+## Concern
+
+Community feedback expressed concerns about system degradation under high demand, referencing Figure 9 of the CIP as evidence that proposed Leios exhibits poor performance characteristics as load increases.
+
+> "As you increase load you reach a maximum throughput and then the throughput will dropoff as you [continue to] increase load... it's a given that delays will increase."
+
+
+
+
+
+## Analysis
+
+The concern appears to stem from a misinterpretation of Figure 9 in the CIP specification. This figure represents a **limit analysis** used for parameter selection, not operational recommendations or expected system behavior.
+
+### Purpose of Figure 9
+
+Figure 9 from the [CIP specification](https://github.com/cardano-scaling/CIPs/blob/leios/CIP-0164/README.md#figure-9) demonstrates system behavior across a wide range of protocol parameters to identify optimal operating points.
+
+
+
+
+[*Figure 9: Time for transaction to reach the ledger*](https://github.com/cardano-scaling/CIPs/blob/leios/CIP-0164/README.md#figure-9)
+
+
+The higher throughput scenarios showing increased latency represent **overcapacity conditions** that would not be used in practice. These data points serve to:
+
+- Establish safe operational boundaries
+- Guide protocol parameter selection
+- Demonstrate system limits for research purposes
+
+### Operational Parameter Selection
+
+The proposed Leios protocol parameters are selected from the **efficient region** of the parameter space, specifically avoiding the degraded performance zones shown in Figure 9. The system is designed to operate well within capacity limits where performance remains stable.
+
+### Transaction Lifecycle
+
+The apparent latency increase in Figure 9's higher throughput scenarios reflects a shift in transaction processing patterns rather than system degradation:
+
+- **Lower throughput**: Mix of fast RB inclusion and slower EB inclusion
+- **Higher throughput**: Predominantly EB inclusion (by design)
+- **Overcapacity**: Transactions queue in mempool (same as current Praos behavior)
+
+This represents normal queueing behavior during congestion, not a fundamental protocol flaw.
+
+### Comparison with Current System
+
+The current Praos system exhibits similar behavior under congestion:
+- Mempool saturation causes increased transaction latency
+- Throughput plateaus at maximum capacity
+- Performance degrades when demand exceeds capacity
+
+Proposed Leios maintains these same characteristics while providing significantly higher baseline throughput.
+
+### Recent Simulation Improvements
+
+Following community feedback, the research team conducted additional analysis to test the specific performance concerns raised. This investigation led to the discovery and resolution of a simulation bug that was artificially degrading performance metrics.
+
+**Bug Discovery**: The Rust simulator was incorrectly including duplicate transactions in the ledger, which:
+- Lowered effective throughput proportional to the redundancy
+- Clogged the memory pool and slowed simulations
+- Created misleading performance degradation patterns
+
+**Resolution**: The bug was fixed in [sim-cli 1.3.1](https://github.com/input-output-hk/ouroboros-leios/releases/tag/sim-rs-1.3.1), and new simulations show that the protocol achieves its theoretical capacity more effectively than previously measured.
+
+**Improved Results**: Updated simulations demonstrate that throughput properly plateaus at capacity limits rather than degrading, confirming that the protocol design meets its performance objectives under load.
+
+## Conclusion
+
+Figure 9 represents a comprehensive analysis of system limits used for parameter selection, not a prediction of operational performance. The proposed protocol parameters are specifically chosen to avoid the degraded performance regions, ensuring stable operation under normal and high-load conditions.
+
+The recent discovery and correction of simulation bugs demonstrates the value of community feedback in improving both the protocol analysis and documentation. The corrected simulations show even better performance characteristics than originally reported.
+
+---
+
+**References**: [CIP Leios Specification - Figure 9](https://github.com/cardano-scaling/CIPs/blob/leios/CIP-0164/README.md#figure-9)
diff --git a/site/docs/community-responses/wasted-work-discarded-ebs.md b/site/docs/community-responses/wasted-work-discarded-ebs.md
new file mode 100644
index 000000000..f07168064
--- /dev/null
+++ b/site/docs/community-responses/wasted-work-discarded-ebs.md
@@ -0,0 +1,57 @@
+---
+sidebar_position: 2
+---
+
+# Efficiency of Discarded Endorser Blocks
+
+## Concern
+
+A community member raised concerns about resource efficiency in the proposed Leios protocol:
+
+> "All the work you've done, all the transmission you've done, all the voting you've done will be discarded [when EBs are discarded probabilistically]."
+
+
+
+
+
+## Analysis
+
+The proposed Leios protocol incorporates several design features that preserve computational work when Endorser Blocks (EBs) are discarded, making the characterization above inaccurate for honest network conditions.
+
+### Transaction Processing Efficiency
+
+A Leios node relies on caching mechanisms where nodes maintain local stores of previously processed transactions. When constructing new EBs, nodes prioritize transactions from discarded EBs. Since transactions are transmitted by reference rather than full content, subsequent EBs require minimal additional network overhead for previously seen transactions.
+
+**Validation Work Reuse**: Crucially, the computational work spent validating transactions in a discarded EB is preserved. The protocol design includes multiple validation levels - when transactions are reused in subsequent EBs or RBs, nodes can apply cheaper revalidation methods rather than repeating expensive operations like script evaluation and signature verification.
+
+### Voting Resource
+
+The primary computational cost when EBs are discarded is indeed voting verification. However, this represents minimal resource consumption:
+
+- **Vote size**: Under 200 bytes per vote
+- **Verification time**: 1.4ms (unoptimized worst case) for ~100 non-persistent voters, 670μs for ~500 persistent voters
+- **Total wasted time**: Approximately 600ms per discarded EB across all validators
+- **Infrastructure context**: Stake Pool Operators provision significantly above average utilization to handle Praos' inherent demand spikes
+
+This voting overhead was not identified as a concern by SPOs during consultation, as it utilizes the cheapest computational resources (network bandwidth and compute) that would otherwise remain idle.
+
+### Resource Utilization
+
+The voting overhead utilizes network bandwidth and computational resources that would otherwise remain idle in the current Praos system. This represents efficient use of already-provisioned infrastructure rather than additional operational burden.
+
+## Conclusion
+
+The protocol design specifically addresses efficiency concerns through transaction caching, reference-based transmission, and minimal voting overhead. The majority of computational and network transmission work is preserved even when EBs are discarded, contradicting the assertion that "all work is wasted."
+
+---
+
+**References**: [CIP Leios Specification](https://github.com/cardano-scaling/CIPs/blob/leios/CIP-0164/README.md#specification)
diff --git a/site/sidebars.ts b/site/sidebars.ts
index 6231d6f22..05d233571 100644
--- a/site/sidebars.ts
+++ b/site/sidebars.ts
@@ -11,7 +11,27 @@ import type { SidebarsConfig } from "@docusaurus/plugin-content-docs";
Create as many sidebars as you want.
*/
const sidebars: SidebarsConfig = {
- documentationSidebar: ["roadmap", "strategy", "resources", "faq", "glossary"],
+ documentationSidebar: [
+ "roadmap",
+ "strategy",
+ "resources",
+ "faq",
+ {
+ type: "category",
+ label: "Community Responses",
+ items: [
+ {
+ type: "doc",
+ id: "community-responses/index",
+ label: "Overview",
+ },
+ "community-responses/wasted-work-discarded-ebs",
+ "community-responses/system-performance-under-load",
+ "community-responses/frontrunning-and-attack-vectors",
+ ],
+ },
+ "glossary",
+ ],
developmentSidebar: [
{
type: "category",
+
+