diff --git a/ledger/src/lib.rs b/ledger/src/lib.rs
index b43029f817..d66aa84276 100644
--- a/ledger/src/lib.rs
+++ b/ledger/src/lib.rs
@@ -1,3 +1,95 @@
+//! # Mina Ledger Crate
+//!
+//! The ledger crate is the most complex component in the Mina Rust node
+//! codebase.
+//! It implements the core ledger functionality, transaction processing, and
+//! proof system integration.
+//!
+//! ## Architecture Overview
+//!
+//! The ledger crate is organized into several key components:
+//!
+//! ### Core Ledger
+//!
+//! - [`base`] - BaseLedger trait providing the fundamental ledger interface
+//! - [`database`] - In-memory account storage implementation
+//! - [`mask`] - Layered ledger views with Arc-based sharing for efficient
+//!   copy-on-write semantics
+//! - [`tree`] - Merkle tree operations for cryptographic integrity
+//!
+//! ### Transaction Processing
+//!
+//! - [`transaction_pool`] - Memory pool (mempool) with fee-based transaction
+//!   ordering
+//! - [`staged_ledger`] - Block validation and transaction application logic
+//! - [`scan_state`] - SNARK work coordination and parallel scan tree management
+//!
+//! ### Proof System
+//!
+//! - [`proofs`] - Transaction, block, and zkApp proof generation and
+//!   verification
+//! - [`sparse_ledger`] - Minimal ledger representation optimized for proof
+//!   generation
+//! - [`zkapps`] - zkApp (zero-knowledge application) transaction processing
+//!
+//! ### Account Management
+//!
+//! - [`account`] - Account structures, balances, and permission management
+//! - [`address`] - Account addressing and public key management
+//!
+//! ## Implementation Status
+//!
+//! The ledger components have proven reliable on devnet despite some technical
+//! debt patterns. The implementation maintains the same battle-tested logic
+//! that runs the production Mina network, ensuring compatibility and
+//! correctness.
+//!
+//! ### Known Areas for Improvement
+//!
+//! #### Error Handling
+//!
+//! - Extensive use of `.unwrap()` and `.expect()` calls, particularly in:
+//!   - `scan_state/transaction_logic.rs`
+//!   - `staged_ledger/staged_ledger.rs`
+//!   - `transaction_pool.rs`
+//! - These calls are generally in code paths with well-understood preconditions
+//!   but could benefit from explicit error propagation
+//! - Inconsistent error handling patterns across modules
+//!
+//! #### Code Organization
+//!
+//! - Large files with multiple responsibilities that could benefit from decomposition
+//! - Some monolithic structures that make testing and maintenance more challenging
+//! - Opportunities for better separation of concerns in transaction processing logic
+//!
+//! ## Design Principles
+//!
+//! The ledger implementation follows several key design principles:
+//!
+//! - **Immutability**: Ledger states are immutable with copy-on-write semantics
+//! - **Layering**: Mask-based layering allows efficient branching and merging
+//! - **Cryptographic Integrity**: All ledger operations maintain Merkle tree
+//!   consistency
+//! - **Protocol Compliance**: Full compatibility with Mina protocol
+//!   specifications
+//! - **Performance**: Optimized for high-throughput transaction processing
+//!
+//! ## Usage Examples
+//!
+//! ```rust,no_run
+//! use mina_tree::{Database, Mask, BaseLedger};
+//!
+//! // Create a new ledger database
+//! let database = Database::create(35); // depth = 35
+//!
+//! // Create a mask for efficient layering
+//! let mask = Mask::new_root(database);
+//!
+//! // Ledger operations can now be performed through the mask
+//! ```
+//!
+//! For more detailed examples and API usage, see the individual module documentation.
+
 #![allow(dead_code)]
 #![allow(clippy::type_complexity)]
 #![allow(clippy::too_many_arguments)]
@@ -43,11 +135,11 @@ mod ffi;
 #[cfg(any(test, feature = "fuzzing"))]
 pub mod generators;
 
-mod account;
-mod address;
-mod base;
+pub mod account;
+pub mod address;
+pub mod base;
 // mod blocks;
-mod database;
+pub mod database;
 pub mod dummy;
 mod hash;
 pub mod mask;
@@ -58,7 +150,7 @@ pub mod scan_state;
 pub mod sparse_ledger;
 pub mod staged_ledger;
 pub mod transaction_pool;
-mod tree;
+pub mod tree;
 mod tree_version;
 mod util;
 pub mod verifier;
diff --git a/ledger/src/proofs/circuit_blobs.rs b/ledger/src/proofs/circuit_blobs.rs
index 8fb6588d40..40bae2607b 100644
--- a/ledger/src/proofs/circuit_blobs.rs
+++ b/ledger/src/proofs/circuit_blobs.rs
@@ -1,3 +1,117 @@
+//! # Circuit Constraint Extraction
+//!
+//! This module handles circuit constraint extraction for the Mina Rust node.
+//! Circuit constraints are sourced from the
+//! [circuit-blobs](https://github.com/openmina/circuit-blobs) repository, which
+//! contains pre-compiled circuit data generated by the OCaml implementation.
+//!
+//! ## Overview
+//!
+//! The Mina Rust node automatically handles downloading and caching circuit
+//! files, making the process transparent to users. When you run the node or
+//! generate proofs, the system will automatically fetch the required circuit
+//! data if it's not already available locally.
+//!
+//! ## Circuit Data Files
+//!
+//! The circuit-blobs repository contains three types of files for each circuit:
+//!
+//! ### Gates Definition (`*_gates.json`)
+//!
+//! - JSON files containing the list of gates for each circuit
+//! - Define the circuit structure and operations
+//! - Used for generating proving and verification keys
+//!
+//! ### Internal Variables (`*_internal_vars.bin`)
+//!
+//! - Binary files containing internal variable mappings
+//! - Store relationships between field elements and variable indices
+//! - Essential for witness generation
+//!
+//! ### Row Reversal Data (`*_rows_rev.bin`)
+//!
+//! - Binary files containing constraint system data
+//! - Used for efficient constraint evaluation
+//! - Required for proof generation
+//!
+//! ## Extraction Process
+//!
+//! The Mina Rust node automatically handles circuit constraint extraction
+//! through this module's [`fetch_blocking`] function.
+//!
+//! ### Local Resolution
+//!
+//! The system searches for circuit files in these locations (in order):
+//!
+//! 1. **Environment Variable**: `MINA_CIRCUIT_BLOBS_BASE_DIR`
+//! 2. **Cargo Manifest Directory**: Current project directory
+//! 3. **Home Directory**: `~/.openmina/circuit-blobs/`
+//! 4. **System Directory**: `/usr/local/lib/openmina/circuit-blobs`
+//!
+//! ### Remote Fetching
+//!
+//! If files are not found locally, the system automatically downloads them from:
+//!
+//! ```text
+//! https://github.com/openmina/circuit-blobs/releases/download/<filename>
+//! ```
+//!
+//! Downloaded files are cached locally for future use.
+//!
+//! ## Web Environment
+//!
+//! For web deployments, circuit files are served statically:
+//!
+//! - **Frontend Path**: `/assets/webnode/circuit-blobs/<version>/`
+//! - **Download Script**: `frontend/docker/startup.sh` handles automatic
+//!   downloading
+//! - **Version**: Specified by `CIRCUITS_VERSION` environment variable
+//!
+//! ## How It Works for Users
+//!
+//! ### First Run Experience
+//!
+//! When you first run the Mina Rust node or generate proofs:
+//!
+//! 1. **Automatic Detection**: The system checks for required circuit files
+//! 2. **Local Search**: Searches in these locations (in order):
+//!    - `$MINA_CIRCUIT_BLOBS_BASE_DIR` (if set)
+//!    - Current project directory
+//!    - `~/.openmina/circuit-blobs/`
+//!    - `/usr/local/lib/openmina/circuit-blobs`
+//! 3. **Automatic Download**: If files aren't found locally, downloads from GitHub
+//! 4. **Local Caching**: Saves downloaded files to `~/.openmina/circuit-blobs/`
+//! 5. **Ready to Use**: Circuit data is loaded and ready for proof generation
+//!
+//! ### Subsequent Runs
+//!
+//! - Uses cached files from `~/.openmina/circuit-blobs/`
+//! - No network requests needed
+//! - Fast startup times
+//!
+//! ## Development Guidelines
+//!
+//! ### Adding New Circuit Types
+//!
+//! 1. Generate circuit data using OCaml implementation
+//! 2. Add files to circuit-blobs repository
+//! 3. Update circuit configuration in `mina_core::network`
+//! 4. Add prover creation logic in [`crate::proofs::provers`]
+//!
+//! ### Local Development
+//!
+//! Set `MINA_CIRCUIT_BLOBS_BASE_DIR` environment variable to point to your
+//! local circuit-blobs repository clone:
+//!
+//! ```bash
+//! export MINA_CIRCUIT_BLOBS_BASE_DIR=/path/to/your/circuit-blobs
+//! ```
+//!
+//! ## Related Modules
+//!
+//! - [`crate::proofs::provers`]: Prover creation using circuit data
+//! - [`crate::proofs::constants`]: Circuit type definitions
+
 use std::path::Path;
 
 #[cfg(not(target_family = "wasm"))]
diff --git a/ledger/src/proofs/mod.rs b/ledger/src/proofs/mod.rs
index cd2c76ac0f..c359d55c86 100644
--- a/ledger/src/proofs/mod.rs
+++ b/ledger/src/proofs/mod.rs
@@ -4,7 +4,7 @@ use poly_commitment::evaluation_proof::OpeningProof;
 pub mod accumulator_check;
 pub mod block;
 pub mod caching;
-mod circuit_blobs;
+pub mod circuit_blobs;
 pub mod constants;
 mod conv;
 pub mod field;
diff --git a/website/docs/developers/circuits.md b/website/docs/developers/circuits.md
new file mode 100644
index 0000000000..8cd461a8cd
--- /dev/null
+++ b/website/docs/developers/circuits.md
@@ -0,0 +1,274 @@
+---
+sidebar_position: 4
+title: Circuit Generation and Management
+description: Circuit logic implementation and proof generation capabilities
+slug: /developers/circuits
+---
+
+# Circuit Generation and Management
+
+## Overview
+
+The Mina Rust node has ported the circuit logic from the Mina protocol, but with
+an important architectural distinction: the implementation only handles witness
+production, not constraint generation. This means that while the Mina Rust node
+can produce proofs using existing circuits, it cannot generate the circuit
+definitions themselves.
+
+For an overview of the proof system implementation in `ledger/src/proofs/`, see
+the
+[ledger crate documentation](https://o1-labs.github.io/mina-rust/api-docs/ledger/index.html).
+
+## Architecture
+
+### Proof Generation Implementation and Limitations
+
+The Mina Rust node codebase includes complete proof generation capabilities with
+one key limitation:
+
+**What the Mina Rust node Can Do:**
+
+- **Witness generation**: Full implementation for producing witnesses needed for
+  proof generation
+- **Proof production**: Complete capability to create proofs using pre-existing
+  circuit definitions
+- **Circuit logic**: Equivalent to the OCaml implementation for all proof types
+- **Proof verification**: Can verify proofs using precomputed verification
+  indices
+
+**What the Mina Rust node Cannot Do:**
+
+- **Circuit constraints**: Missing the constraint declarations from the OCaml
+  code that define circuit structure
+- **Constraint compilation/evaluation**: Missing the functionality to
+  compile/evaluate constraint declarations into circuit constraints
+- **Verification key generation**: Cannot generate verification keys for new
+  circuits
+
+**Practical Implications:**
+
+- Can generate proofs and witnesses for existing circuits
+- Cannot create new circuits or modify existing circuit definitions
+- Relies on OCaml implementation for all circuit creation and constraint
+  processing
+- Uses precomputed verification indices from the OCaml implementation
+
+The circuit logic is equivalent to the OCaml implementation except both the
+constraint declarations and the constraint compilation/evaluation functionality
+are missing - these were not ported due to time constraints during development,
+not technical limitations, and could be added for full independence.
+
+### Circuit Generation Process
+
+Since these constraint capabilities are missing, the Mina Rust node requires
+externally generated circuit data. The following process describes how circuits
+are created and distributed using the original Mina codebase:
+
+1. **Circuit Definition**: Circuits are defined using the OCaml implementation's
+   constraint system
+2. **Index Generation**: Verification and proving indices are generated from the
+   circuit definitions
+3. **Distribution**: Pre-generated indices are distributed for use by Rust nodes
+4. **Proof Generation**: The Mina Rust node uses these indices to generate and
+   verify proofs
+
+## Implementation Details
+
+### Witness Production
+
+The Mina Rust node implements complete witness production for all supported
+proof types:
+
+- **Transaction proofs**: Witness generation for user command verification
+- **Block proofs**: Witness production for blockchain state transitions
+- **Merge proofs**: Witness generation for proof aggregation
+- **Base proofs**: Witness production for foundational protocol operations
+
+### Proof Types Supported
+
+#### Transaction Proofs
+
+- User command verification
+- Payment and delegation transactions
+- zkApp account updates and state changes
+
+#### Blockchain Proofs
+
+- Block state transition verification
+- Consensus state updates
+- Protocol state evolution
+
+#### SNARK Work Proofs
+
+- Transaction SNARK generation
+- Proof merging and aggregation
+- Work verification
+
+### Circuit Data Management
+
+#### Verification Indices
+
+- Pre-computed verification keys from OCaml implementation
+- Distributed as binary data files
+- Loaded at runtime for proof verification
+
+#### Proving Indices
+
+- Pre-computed proving keys for proof generation
+- Large binary files stored separately
+- Lazy-loaded when proof generation is required
+
+## Performance Characteristics
+
+### Witness Generation
+
+- **Speed**: Comparable to OCaml implementation
+- **Memory Usage**: Efficient memory management during witness production
+- **Parallelization**: Some witness generation can be parallelized
+
+### Proof Production
+
+- **Throughput**: Supports concurrent proof generation
+- **Resource Usage**: CPU and memory intensive operations
+- **Optimization**: Optimized for production workloads
+
+## Integration with Protocol
+
+### Block Producer Integration
+
+- Seamless integration with block production pipeline
+- Automatic proof generation for produced blocks
+- Efficient witness caching and reuse
+
+### Transaction Pool Integration
+
+- On-demand proof generation for transactions
+- Batch processing for multiple transactions
+- Memory-efficient proof storage
+
+### Archive Integration
+
+- Proof verification for historical blocks
+- Efficient storage of verification results
+- Support for proof re-verification
+
+## Limitations and Future Work
+
+### Current Limitations
+
+#### Constraint System
+
+- Missing constraint declaration framework
+- No support for custom circuit creation
+- Dependent on OCaml implementation for new circuits
+
+#### Verification Key Generation
+
+- Cannot generate verification keys independently
+- Requires external tooling for circuit updates
+- Limited flexibility for protocol upgrades
+
+### Future Improvements
+
+#### Constraint Implementation
+
+- **Goal**: Port constraint declaration system from OCaml
+- **Benefit**: Full independence from OCaml implementation
+- **Effort**: Significant development work required
+
+#### Circuit Optimization
+
+- **Goal**: Rust-specific circuit optimizations
+- **Benefit**: Improved performance over OCaml version
+- **Effort**: Moderate development work
+
+#### Custom Circuit Support
+
+- **Goal**: Enable creation of custom circuits
+- **Benefit**: Support for protocol evolution and experimentation
+- **Effort**: Requires constraint system implementation first
+
+## Development Guidelines
+
+### Working with Circuits
+
+#### Adding New Proof Types
+
+1. Implement witness generation logic
+2. Define proof type structure
+3. Add integration points with existing systems
+4. Test with precomputed verification indices
+
+#### Optimizing Performance
+
+1. Profile witness generation bottlenecks
+2. Optimize memory allocation patterns
+3. Consider parallelization opportunities
+4. Benchmark against OCaml implementation
+
+#### Debugging Circuit Issues
+
+1. Use structured logging for witness generation
+2. Compare outputs with OCaml reference implementation
+3. Validate proof generation against known test vectors
+4. Monitor memory usage during proof production
+
+### Testing Strategy
+
+#### Unit Tests
+
+- Individual witness generation functions
+- Proof type serialization and deserialization
+- Circuit data loading and validation
+
+#### Integration Tests
+
+- End-to-end proof generation and verification
+- Performance benchmarks against OCaml
+- Memory usage validation
+
+#### Compatibility Tests
+
+- Cross-verification with OCaml-generated proofs
+- Protocol compliance validation
+- Regression testing for circuit changes
+
+## Circuit Constraint Extraction
+
+For a comprehensive technical overview of circuit constraint extraction, see the
+[circuit_blobs module documentation](https://o1-labs.github.io/mina-rust/api-docs/ledger/proofs/circuit_blobs/index.html)
+in the ledger crate.
+
+### Overview
+
+Circuit constraints for the Mina Rust node are sourced from the
+[circuit-blobs](https://github.com/openmina/circuit-blobs) repository, which
+contains pre-compiled circuit data generated by the OCaml implementation.
+
+The Mina Rust node automatically handles downloading and caching these circuit
+files, making the process transparent to users. When you run the node or
+generate proofs, the system will automatically fetch the required circuit data
+if it's not already available locally.
+
+## Related Documentation
+
+- [Proof System Overview](https://o1-labs.github.io/mina-rust/api-docs/ledger/proofs/index.html):
+  Technical implementation details
+- [SNARK Work](../researchers/snark-work): Protocol-level SNARK work
+  documentation
+- [Architecture Overview](architecture): Overall system architecture
+- [Performance Considerations](mainnet-readiness): Mainnet performance
+  requirements
+
+## Conclusion
+
+While the Mina Rust node successfully implements witness production and proof
+generation, the missing constraint system represents a significant dependency on
+the OCaml implementation. This architectural choice was made to accelerate
+initial development but represents an area for future enhancement to achieve
+full protocol independence.
+
+The current implementation provides sufficient functionality for mainnet
+operation while maintaining compatibility with the broader Mina ecosystem.
+Future work on constraint system implementation would enable full circuit
+independence and support for protocol evolution.
diff --git a/website/docs/developers/ledger-crate.md b/website/docs/developers/ledger-crate.md
new file mode 100644
index 0000000000..028b8d05ed
--- /dev/null
+++ b/website/docs/developers/ledger-crate.md
@@ -0,0 +1,309 @@
+---
+sidebar_position: 5
+title: Ledger Crate Architecture
+description:
+  Comprehensive architecture overview of the ledger crate implementation
+slug: /developers/ledger-crate
+---
+
+# Ledger Crate Architecture
+
+## Overview
+
+The [`ledger`](https://o1-labs.github.io/mina-rust/api-docs/ledger/index.html)
+crate is a comprehensive Rust implementation of the Mina protocol's ledger,
+transaction pool, staged ledger, scan state, proof verification, and zkApp
+functionality, providing a direct port of the OCaml implementation. For
+developers familiar with the OCaml codebase, this maintains the same
+architecture and business logic while adapting to Rust idioms.
+
+This document provides an in-depth architectural overview complementing the
+[API documentation](https://o1-labs.github.io/mina-rust/api-docs/ledger/index.html).
+
+## Architecture
+
+### Core Components
+
+#### BaseLedger Trait (`src/base.rs`)
+
+- Direct mapping to OCaml's `Ledger_intf.S`
+- Defines the fundamental ledger interface for account management, Merkle tree
+  operations, and state queries
+- All ledger implementations (Database, Mask) implement this trait
+- Provides consistent interface across different ledger storage backends
+
+#### Mask System (`src/mask/`)
+
+- Port of OCaml's `Ledger.Mask` with identical copy-on-write semantics
+- Provides layered ledger views for efficient state management
+- Uses `Arc<Mutex<MaskImpl>>` for cheap reference counting; `Mask::clone()` is
+  fast
+- Used extensively in transaction processing to create temporary ledger states
+- Enables efficient branching and merging of ledger states during block
+  processing
+
+#### Database (`src/database/`)
+
+- In-memory implementation (ondisk module exists but is not used)
+- Corresponds to OCaml's `Ledger.Db` interface
+- Handles account storage and Merkle tree management
+- Optimized for high-performance account lookups and updates
+
+### Transaction Processing
+
+#### Transaction Pool (`src/transaction_pool.rs`)
+
+Complete port of `Transaction_pool.Indexed_pool` with identical behavior:
+
+- **Fee-based transaction ordering**: Higher fee transactions prioritized
+- **Sender queue management**: Nonce-based ordering per sender
+- **Revalidation on best tip changes**: Ensures transaction validity
+- **VkRefcountTable**: Verification key reference counting for memory efficiency
+- **Mempool operations**: Transaction addition, removal, and replacement logic
+- **Expiration handling**: Automatic cleanup of stale transactions
+
+#### Staged Ledger (`src/staged_ledger/`)
+
+Maps directly to OCaml's staged ledger implementation:
+
+- **Diff structures**: Correspond to `Staged_ledger_diff` with same partitioning
+- **Transaction application**: Manages sequential application of transactions
+- **Block validation**: Ensures blocks meet protocol requirements
+- **Fee collection**: Handles coinbase and fee distribution
+- **State transitions**: Manages ledger state evolution during block processing
+
+#### Scan State (`src/scan_state/`)
+
+Port of the parallel scan state system:
+
+- **SNARK work coordination**: Manages proof generation across the network
+- **Parallel scan trees**: Efficient proof aggregation structures
+- **Work distribution**: Coordinates SNARK worker assignments
+- **Proof verification**: Validates submitted SNARK work
+- **State management**: Tracks scan state evolution across blocks
+
+### Proof System Integration
+
+#### Proofs Module (`src/proofs/`)
+
+Comprehensive proof generation and verification:
+
+- **Transaction proofs**: User command and payment verification
+- **Block proofs**: Blockchain state transition validation
+- **zkApp proofs**: Zero-knowledge application proof handling
+- **Merge proofs**: Efficient proof aggregation
+- **Verification**: Fast proof validation using precomputed indices
+
+#### Sparse Ledger (`src/sparse_ledger/`)
+
+- Minimal ledger representation optimized for proof generation
+- Contains only accounts needed for specific proof context
+- Reduces proof generation overhead by eliminating unnecessary data
+- Maintains cryptographic integrity through Merkle path verification
+
+### zkApp Support
+
+#### zkApps Module (`src/zkapps/`)
+
+Complete zkApp transaction processing:
+
+- **Account updates**: Manages complex multi-account operations
+- **Authorization handling**: Validates zkApp permissions and signatures
+- **State management**: Handles zkApp on-chain state updates
+- **Event emission**: Processes zkApp events and sequencing
+- **Precondition validation**: Ensures zkApp execution prerequisites
+
+### Account Management
+
+#### Account Structures (`src/account/`)
+
+- **Account types**: Standard accounts, zkApp accounts, token accounts
+- **Balance management**: Handles account balances and locked funds
+- **Permission systems**: Manages account access controls and delegates
+- **Token support**: Native support for custom tokens
+- **Timing constraints**: Handles vesting and unlock schedules
+
+#### Address Management (`src/address/`)
+
+- **Public key handling**: Account identification and verification
+- **Address derivation**: Deterministic address generation
+- **Token address mapping**: Links token accounts to parent accounts
+
+## Implementation Details
+
+### Memory Management
+
+#### Arc-based Sharing
+
+- Extensive use of `Arc<T>` for efficient memory sharing
+- Copy-on-write semantics through mask system
+- Minimizes memory overhead during state transitions
+
+#### Caching Strategies
+
+- Merkle tree path caching for performance
+- Account lookup optimization
+- Proof verification result caching
+
+### Concurrency Model
+
+#### Thread Safety
+
+- `Mutex` protection for mutable state
+- Lock-free operations where possible
+- Careful ordering to prevent deadlocks
+
+#### Parallel Processing
+
+- SNARK work can be processed in parallel
+- Transaction validation optimizations
+- Block application pipeline efficiency
+
+### Performance Optimizations
+
+#### Fast Account Lookups
+
+- Efficient hash-based account storage
+- Merkle tree optimization for batch operations
+- Memory-mapped storage preparation (ondisk module)
+
+#### Transaction Processing
+
+- Batch transaction validation
+- Optimized fee calculation
+- Efficient nonce management
+
+## Protocol Compliance
+
+### OCaml Compatibility
+
+- Identical business logic to OCaml implementation
+- Same data structures and serialization formats
+- Compatible proof generation and verification
+- Consistent state transition behavior
+
+### Network Interoperability
+
+- Full compatibility with OCaml nodes
+- Identical block validation rules
+- Same transaction pool behavior
+- Compatible SNARK work distribution
+
+## Development Guidelines
+
+### Working with Ledger Code
+
+#### Understanding Masks
+
+```rust
+// Create a new mask for temporary operations
+let temp_mask = ledger.mask().unwrap();
+
+// Make modifications without affecting parent
+temp_mask.create_account(account_id, account)?;
+
+// Commit changes back to parent or discard
+temp_mask.commit();
+```
+
+#### Transaction Processing Patterns
+
+```rust
+// Typical transaction application flow
+let staged_ledger = StagedLedger::create(ledger);
+let diff = staged_ledger.apply_diff(transactions)?;
+let new_ledger = staged_ledger.apply(diff)?;
+```
+
+#### Account Management
+
+```rust
+// Safe account operations
+if let Some(account) = ledger.get_account(&account_id)? {
+    let updated = account.set_balance(new_balance)?;
+    ledger.set_account(&account_id, &updated)?;
+}
+```
+
+### Testing Strategies
+
+#### Unit Tests
+
+- Individual component testing (masks, accounts, transactions)
+- Property-based testing for invariants
+- Compatibility tests against OCaml reference
+
+#### Integration Tests
+
+- End-to-end transaction processing
+- Block application and validation
+- SNARK work coordination
+
+#### Performance Tests
+
+- Memory usage validation
+- Transaction throughput benchmarks
+- Proof generation performance
+
+## Known Limitations
+
+### Technical Debt Areas
+
+#### Error Handling
+
+- Extensive use of `.unwrap()` and `.expect()` in well-understood code paths
+- Opportunities for more explicit error propagation
+- Inconsistent error handling patterns across modules
+
+#### Code Organization
+
+- Some large files with multiple responsibilities
+- Opportunities for better separation of concerns
+- Legacy patterns from OCaml port that could be Rust-ified
+
+#### Performance Opportunities
+
+- Memory allocation optimization potential
+- Further parallelization possibilities
+- Caching strategy improvements
+
+### Future Improvements
+
+#### Persistence Integration
+
+- Integration with planned persistence layer
+- Disk-based storage backend completion
+- Efficient state recovery mechanisms
+
+#### Performance Enhancements
+
+- Lock contention reduction
+- Memory usage optimization
+- Parallel transaction processing
+
+#### Code Quality
+
+- Error handling improvements
+- Module decomposition
+- Better separation of concerns
+
+## Related Documentation
+
+- [Ledger Crate API Docs](https://o1-labs.github.io/mina-rust/api-docs/ledger/index.html):
+  Complete API reference
+- [Circuits Documentation](circuits): Circuit generation and proof system
+  integration
+- [Persistence Design](persistence-design): Future storage layer plans
+- [SNARK Work](../researchers/snark-work): Protocol-level SNARK work details
+
+## Conclusion
+
+The ledger crate represents the heart of the Mina Rust node, implementing all
+core ledger functionality with full protocol compliance. While maintaining
+compatibility with the OCaml implementation, it provides the foundation for
+efficient transaction processing, proof generation, and zkApp execution.
+
+The architecture balances performance, correctness, and maintainability, though
+opportunities exist for continued refinement as the codebase matures.
+Understanding this crate is essential for developers working on any aspect of
+the Mina Rust node's core functionality.
diff --git a/website/docusaurus.config.ts b/website/docusaurus.config.ts
index bac43014ed..74dc08fb69 100644
--- a/website/docusaurus.config.ts
+++ b/website/docusaurus.config.ts
@@ -111,6 +111,12 @@ const config: Config = {
           position: 'left',
           label: 'Developers',
         },
+        {
+          type: 'docSidebar',
+          sidebarId: 'researchersSidebar',
+          position: 'left',
+          label: 'Researchers',
+        },
         {
           type: 'docSidebar',
           sidebarId: 'appendixSidebar',
@@ -148,6 +154,10 @@ const config: Config = {
               label: 'Developers',
               to: '/docs/developers/architecture',
             },
+            {
+              label: 'Researchers',
+              to: '/docs/researchers/protocol',
+            },
             {
               label: 'Appendix',
               to: '/docs/appendix/docker-installation',
diff --git a/website/sidebars.ts b/website/sidebars.ts
index f814a92cb8..83784be925 100644
--- a/website/sidebars.ts
+++ b/website/sidebars.ts
@@ -67,6 +67,8 @@ const sidebars: SidebarsConfig = {
       items: [
         'developers/why-rust',
         'developers/architecture',
+        'developers/circuits',
+        'developers/ledger-crate',
       ],
     },
     {