Storage-Backed Persistence — Hydration From Explicit Writes Only
Source: Ledger & State Engine
The Ledger Engine depends only on storage interfaces — no concrete backend is coupled
Storage Provider
Default null provider. No storage backend is configured. Register a real StorageProvider implementation to enable persistence.
Persists and retrieves RTWOLedgerState records by block height.
Persists and retrieves RTWOStateTransition records.
Persists RTWOAccountState entries and RTWOStorageNode (MPT) nodes.
Persists and retrieves RTWOStateSnapshot records for archival.
Persists and retrieves RTWOLedgerRecoveryPoint records for disaster recovery.
Future Storage Backends
The Ledger Engine depends only on interfaces. Any backend above can be registered via StorageProviderRegistry.register() without modifying engine logic.
6 strongly typed domain models defining the RTWO ledger and state layer
Top-level ledger state tracking state root, block height, supply figures, and engine status.
Click to expand fieldsRecords a single state transition from one state root to another, triggered by a transaction.
Click to expand fieldsIndividual account state entry in the state tree with balance, nonce, and storage root.
Click to expand fieldsA node in the Merkle Patricia Trie storage tree representing a key-value pair.
Click to expand fieldsA point-in-time snapshot of the full ledger state for recovery and archival.
Click to expand fieldsA recovery point linking a block height to a verified snapshot for disaster recovery.
Click to expand fieldsSource: Real Storage — Not Connected
Account Fields
Account Types
Externally Owned Account
Standard user wallet address
Contract Account
Smart contract with code hash
Validator Account
Consensus validator with stake
Treasury Account
Protocol treasury holdings
System Account
Internal protocol system account
Waiting for Real Ledger Data
Source: Real Storage — Not Connected7-stage lifecycle from request to commit or revert
A state transition has been requested by the protocol engine or consensus layer.
The transition is being validated against current state root and account balances.
Requires real storageValidated transition is being applied to the account state tree.
Requires real storageTransition has been applied to the in-memory state. Awaiting commit.
Requires real storageTransition is permanently committed to the ledger storage and state root updated.
Requires real storageTransition was rolled back due to block rejection or consensus failure.
Requires real storageTransition failed due to invalid state, insufficient balance, or storage error.
Requires real storage6-stage lifecycle from pending to archived or failed
Snapshot has been scheduled and is waiting for the ledger to reach a stable state.
Snapshot is being created by serializing the current state tree to storage.
Snapshot has been written to storage and is awaiting integrity verification.
Snapshot integrity has been verified against the state root hash.
Snapshot has been archived for long-term storage and recovery purposes.
Snapshot creation or verification failed due to storage error or hash mismatch.
7-step process from transaction execution to ledger commit
Transaction Execution
Transactions are executed and account state changes are computed.
Source: Blockchain Protocol EngineAccount State Update
Affected account balances, nonces, and storage roots are updated in memory.
Source: Ledger & State EngineStorage Node Write
Updated account entries are written as leaf nodes in the Merkle Patricia Trie.
Source: Real Storage — Not ConnectedTrie Recomputation
Branch and extension nodes are recomputed bottom-up from modified leaves.
Source: Real Storage — Not ConnectedRoot Hash Derivation
The new state root hash is derived from the updated trie root node.
Source: Real Storage — Not ConnectedConsensus Verification
The new state root is submitted to the Consensus Engine for block finality.
Source: Consensus EngineLedger Commit
After finality, the state root is committed to the ledger and storage is persisted.
Source: Real Storage — Not ConnectedSource: Real Storage — Not Connected
Node Types
Root Node
Top-level trie root — hash is the state root
Branch Node
16-child branch node for path routing
Extension Node
Compressed path segment for efficiency
Leaf Node
Terminal node holding account state value
RTWOStorageNode Fields
Not Connected to Real Storage
Snapshot and recovery point architecture for disaster recovery
RTWOStateSnapshot
RTWOLedgerRecoveryPoint
10 typed service interfaces — all placeholder implementations
| Service | Layer | Integration | Status |
|---|---|---|---|
| Ledger State Management | R3 | R3 Core Orchestrator | Interface Ready |
| Account State Management | R4 | R4 Blockchain Protocol Engine | Interface Ready |
| State Transition Execution | R4 | R4 Blockchain Protocol Engine | Interface Ready |
| State Root Calculation | R4 | R4 Blockchain Protocol Engine | Interface Ready |
| Storage Tree Management | R4 | R4 Blockchain Protocol Engine | Interface Ready |
| Snapshot Creation | R7 | R7 Enterprise Services | Interface Ready |
| Recovery Point Management | R7 | R7 Enterprise Services | Interface Ready |
| Ledger Validation | R6 | R6 Security & Automation | Interface Ready |
| State Proof Generation | R4 | R4 Blockchain Protocol Engine | Interface Ready |
| Ledger Event Publishing | R3 | R3 Core Orchestrator | Interface Ready |
Connection status with Core Engine, Blockchain Protocol Engine, and Consensus Engine
R3 Core Orchestrator
Ledger state management and event publishing integrated
Source: Core EngineR4 Blockchain Protocol Engine
State transitions, account state, and state root pipeline integrated
Source: Blockchain Protocol EnginePhase 4 Consensus Engine
State root submitted after block finality — architecture connected
Source: Consensus EngineR6 Security & Automation
Ledger validation service integrated
Source: Core EngineR7 Enterprise Services
Snapshot and recovery point services integrated
Source: Core EngineReal Ledger Storage
Requires real database — not configured
Source: Real Storage — Not ConnectedP2P Network
Required for Phase 6 — not yet started
Source: Real Network — Not ConnectedAll items must be complete before proceeding to Phase 6 (P2P Networking)
ledger-state-engine module exists
Created in Phase 5
All six domain models implemented
RTWOLedgerState, RTWOStateTransition, RTWOAccountState, RTWOStorageNode, RTWOStateSnapshot, RTWOLedgerRecoveryPoint
Service interfaces defined
10 typed service interfaces with placeholder implementations
State transition lifecycle implemented
Requested → Validating → Applying → Applied → Committed → Reverted → Failed
Snapshot lifecycle implemented
Pending → Creating → Created → Verified → Archived → Failed
Ledger & State Dashboard exists
Phase 5 dashboard with acceptance checklist
Core Engine integration complete
Integrated with R3, R4, R6, R7 execution layers
Consensus Engine integration complete
Phase 4 Consensus Engine connected via orchestrator
No fake ledger data shown
Truthful Data Policy enforced throughout
Storage provider connected to Ledger Engine
Operational RocksDB/in-memory storage bridged via StorageProviderRegistry
Persistent ledger hydration and recovery
Phase C.2 — bootstrap from storage on initialize; no fabricated genesis data
Ready for P2P Network Phase
Ledger architecture complete — awaiting Phase 6
Truthful Data Policy — Phase 5