diff --git a/docs/architecture/adr-001-three-layer-architecture.md b/docs/architecture/adr-001-three-layer-architecture.md
new file mode 100644
index 00000000..d06f070c
--- /dev/null
+++ b/docs/architecture/adr-001-three-layer-architecture.md
@@ -0,0 +1,578 @@
+# ADR 001: Three-Layer Architecture (DCL/CL/EL)
+
+## Changelog
+
+* 2025-12-06: Initial draft
+
+## Status
+
+PROPOSED Not Implemented
+
+## Abstract
+
+
+CipherBFT implements a three-layer architecture separating concerns into Data Chain Layer (DCL), Consensus Layer (CL), and Execution Layer (EL). This design follows the Autobahn BFT paper's approach where DCL handles data availability through Car/Attestation/Cut mechanisms, CL runs PBFT-style consensus over Cuts, and EL executes finalized transactions via embedded revm. This separation enables pipelined operation where attestation collection for height N+1 occurs during consensus for height N, reducing latency.
+
+## Context
+
+Traditional BFT consensus implementations tightly couple data dissemination with consensus voting, creating sequential bottlenecks:
+
+1. **Monolithic designs** (CometBFT) process proposals sequentially: receive → validate → vote → commit
+2. **Data availability** is verified during consensus, adding latency to each round
+3. **Execution** happens after commit, further delaying finality perception
+
+Autobahn BFT (arxiv:2401.10369) introduces a separation that allows overlapping operations:
+- Cars (certified transaction batches) can be created and attested independently
+- Cuts (collection of highest attested Cars) are formed when consensus needs a proposal
+- Consensus runs over Cuts, not raw transactions
+
+This design targets:
+- **>100K TPS** throughput with 4 workers per validator
+- **<500ms p50 latency** in geo-distributed networks (21 validators, 3 regions)
+- **2x latency improvement** over Bullshark
+
+### Performance Target Analysis
+
+| Configuration | Autobahn Paper | CipherBFT Target | Notes |
+|---------------|----------------|------------------|-------|
+| Validators | 4 | 21 | 5x more validators |
+| Workers | 1 | 4 | 4x more workers |
+| Throughput | 199K TPS | >100K TPS | Conservative due to validator scaling |
+| Latency | 190ms | <500ms | Higher validator count increases rounds |
+
+Scaling considerations:
+- PBFT message complexity: O(n²) where n = validator count
+- 21 validators ≈ 27x more messages than 4 validators
+- Worker parallelism offsets some throughput loss
+- Target is intentionally conservative pending benchmarks
+
+## Alternatives
+
+### Alternative 1: Monolithic Single-Layer Design
+
+Traditional approach where consensus directly handles transactions.
+
+**Pros:**
+- Simpler implementation
+- Fewer moving parts
+- Well-understood model (CometBFT)
+
+**Cons:**
+- Sequential bottleneck limits throughput
+- No overlap between data availability and consensus
+- Harder to scale horizontally
+
+### Alternative 2: Narwhal/Tusk DAG-based Separation
+
+Use DAG structure for data availability (Narwhal) with separate ordering (Tusk/Bullshark).
+
+**Pros:**
+- High throughput proven in production (Sui)
+- DAG provides natural parallelism
+
+**Cons:**
+- Complex garbage collection
+- Higher memory requirements for DAG maintenance
+- Longer time-to-finality due to DAG depth requirements
+
+### Alternative 3: Autobahn Three-Layer (Chosen)
+
+Car → Cut → PBFT with pipelined attestation collection.
+
+**Pros:**
+- Pipelining reduces effective latency
+- Clean separation of concerns
+- Maintains PBFT simplicity in consensus layer
+- No DAG garbage collection complexity
+
+**Cons:**
+- Novel design, less battle-tested
+- Pipeline state management complexity
+- Requires careful error handling across layers
+
+## Decision
+
+We will implement the Autobahn BFT three-layer architecture:
+
+---
+
+## Layer Interface Definitions
+
+### Data Chain Layer (DCL) Interface
+
+```rust
+/// Data Chain Layer - handles data availability
+#[async_trait]
+pub trait DataChainLayer: Send + Sync {
+ /// Create a new CAR from pending batches
+ fn create_car(&mut self, height: Height) -> Option;
+
+ /// Process received CAR, return attestation if valid
+ fn process_car(&mut self, car: &Car) -> Result