According to @deanmlittle, the question is why tiered storage is a real problem on Solana given consumer NVMe claims of over 2 million 4KB random read IOPS and whether the protocol should care if slow validators are already punished. Solana’s AccountsDB tiered storage offloads cold state to disk, but the design explicitly warns that higher disk read latency can slow account loads during banking, especially under mixed read/write and low-queue-depth workloads that matter to leaders, which makes advertised peak IOPS a poor proxy for effective throughput in production (source: Solana Labs RFC on AccountsDB tiered storage, GitHub). Solana leaders have roughly 400 ms per slot to fetch accounts, execute transactions, and propagate blocks, so p99 latency spikes on disk-backed state can push leaders over deadline even when average SSD IOPS look high (source: Solana whitepaper on Proof of History and slots by Solana Labs). Compute Units are bounded per transaction and per block via the Compute Budget Program, so state-read latency becomes a bottleneck irrespective of higher CU ceilings because execution stalls on account reads and locks when storage is too slow (source: Solana Docs, Compute Budget Program; Solana Runtime docs on accounts and locks). While slow voting and missed block production reduce a validator’s vote credits and rewards, a slow leader still occupies scheduled slots and can elevate fork rate and confirmation times before penalties are realized, so the protocol sets expectations to maintain baseline liveness and throughput for all participants (source: Solana Docs, Staking and Rewards; Solana Docs, Leader schedule and consensus overview). Solana Foundation hardware guidance emphasizes high-performance NVMe and large RAM footprints to keep hot state in memory and minimize tail latency, underscoring that storage tiering must be engineered around leader-time constraints rather than headline SSD IOPS (source: Solana Foundation/Docs, Validator hardware recommendations). For traders, congestion from slow state reads drives priority fees and execution uncertainty on Solana; fees rise with contention under local fee markets, making performance-sensitive storage decisions directly relevant to SOL’s on-chain cost and throughput profile (source: Solana Docs, Transaction fees and priority fees; Solana Docs, Local fee markets and congestion behavior).

According to @bolsaverse, AO's decoupled execution architecture is divided into specialized units that enhance trading efficiency. Compute Units (CUs) execute tasks on demand, which can optimize processing speeds for trading algorithms. Messenger Units (MUs) handle inter-process messaging, crucial for maintaining real-time communication between trading components. Scheduler Units (SUs) manage sequencing and Arweave storage, providing robust data management and storage solutions critical for reliable trading operations.