Aptos Velociraptr
Learn how Aptos processes 160,000+ transactions per second
Block River
E2E Latency with Finality
p50 median · 0 samples · testnet
Throughput Comparison
Theoretical max TPS (all chains)
Why Each Chain Achieves Its Throughput
Optimistic parallel execution without pre-declared dependencies
Block-STM Innovation: Unlike Solana's Sealevel which requires transactions to pre-declare dependencies, Block-STM speculatively executes all transactions in parallel and only re-executes on conflict. This eliminates upfront overhead while maintaining deterministic results.
Ethereum vs Aptos
The Blockchain Stress Story
Watch how traditional blockchains fail under load, and how Aptos handles it
Progress Bar with Strong Glow
Animated progress bar demonstrating multi-layer glow effects
Timeline
Evolution of consensus milestones
Consensus Rounds
Velociraptr 4-hop consensus speed
Transaction Pipeline
Raptr 4-hop consensus · Particles spawn from real blocks
The 4-Hop Journey
Multiple blocks process concurrently through all stages, not sequentially.
Validator Ring
Top 20 by StakeNetwork Stats
CONSENSUS: How Validators AgreeAptos Consensus Deep Dive
Before your transaction is final, ~140 validators must agree it's valid. These visualizations show the messaging protocol that makes that happen in ~400ms.
Raptr ConsensusDocs
4-hop BFT: Propose → Vote → Certify → Commit (~0ms)
Leader broadcasts block proposal with signature to all validators
Leader multicasts ⟨PROPOSE, B, σ_L⟩ containing block B and leader signature. O(n) messages sent.
Block-STM Parallel ExecutionDocs
Software Transactional Memory with MVCC
Run TX optimistically, record all reads & writes
Check if read versions are still current
Earlier TX wrote to key we read → abort & retry
Write new versions, TX is finalized
Block-STM uses Multi-Version Concurrency Control (MVCC) where each key maintains multiple versions. TXs are pre-ordered (TX1 < TX2 < TX3...) and execute speculatively in parallel. If TX5 reads balance_A@v2 but TX3 later writesbalance_A@v3, TX5 must re-execute with fresh data. This achieves 8-16x speedup over sequential execution with typically <5% conflict rate.
Block-STM ParallelizationVS COMPARISON
Sequential vs parallel transaction execution
Why Block-STM is Revolutionary
Quorum StoreDocs
Batch dissemination for data availability (2/3 quorum)
Narwhal Protocol: Data Availability Layer
Worker broadcasts ⟨BATCH, d, data⟩ where d = H(batch)
Validators store batch, reply with ⟨STORE-VOTE, d, σ_i⟩ partial signature
With 2f+1 signatures: PoS = ⟨d, σ_agg⟩ — aggregated threshold signature
d, not full data — validators already have it.Shoal++ Leader ReputationDocs
Dynamic leader selection by reputation score
Why Reputation-Based Leaders?
In traditional blockchains, leaders are chosen randomly. If a slow or offline validator is picked, everyone waits — wasting precious time.
Track each validator's performance history. Reliable validators get picked more often. Bad actors get skipped automatically.
Shardines: Parallel Execution
Hypergraph partitioning for horizontal scalability
Analyze transaction dependencies by shared resources
Build graph where TXs are nodes, shared resources are hyperedges
EXECUTION: Running Your Smart ContractAptos Execution Deep Dive
Once consensus is reached, your transaction runs on the Move VM. These diagrams show how code goes from bytecode to state changes.
Move Execution Pipeline
Contract → Block-STM → Loader V2 → Chain
Move module defines entry functions
Move VM Execution PipelineDocs
Complete transaction lifecycle through the Move virtual machine
Transaction received and validated
Transaction bytes decoded, signature verified, gas checked
Entry point: execute_script() or execute_function(). Deserialize TransactionPayload, verify Ed25519 signature against sender's public key, check sequence number matches account state.
Pipeline: Each stage is optimized for minimal latency. Pipelining allows next block to start while current commits.
Safe Transaction ExecutionSECURE
Your transaction protected by Move VM safety guarantees
Loader V2: Why 60% Faster?Aptos Execution Details
The secret sauce: multi-level code caching. Instead of reloading smart contract code for every transaction, Aptos keeps hot modules in memory — from per-thread (L1) to epoch-wide (L3) caches.
Loader V2: Code Caching
Multi-level bytecode caching
TX needs module code
AIP-107: ~90% L1 hit rate. L2→L3 promotion at block commit. Result: 60% faster, 14x faster module publishing.
Loader V2: Parallelization
How shared caching enables parallel contract execution
32 Block-STM threads request the same hot module simultaneously
Legacy: Each thread deserializes + verifies independently → O(32 × module_size). Loader V2: First thread loads, others wait on lock-free read → O(1 × module_size).
Thread T1 acquires L2 lock, loads module, stores in L2. Threads T2-T32 spin-wait briefly, then read from L2. All 32 get pointer to same verified module. Zero redundant verification.
- • Per-thread cache (no sharing)
- • 32x redundant loading
- • Cache discarded per block
- • Shared L1→L2→L3 hierarchy
- • Lock-free reads (~90% L1)
- • Epoch-persistent cache
OPTIMIZATIONS: Speed InnovationsAptos White Paper
What makes Aptos the fastest blockchain? These cutting-edge techniques work together: optimistic proposals, parallel pipelines, dynamic sharding, and observer nodes for scale.
Velociraptr: Optimistic ProposalsBlog
~40% faster block times via pipelined proposals (AIP-131)
Leader broadcasts ⟨PROPOSE, B_n⟩ immediately
Archon: Primary-Proxy ConsensusDocs
From 4 global WAN hops to fast internal BFT + 1 broadcast
Key insight: The co-located cluster (same datacenter) runs full PBFT-style consensus in microseconds, then broadcasts the certified block once to external validators.
Why Archon Is 18× Faster Than Mysticeti
Sui Mysticeti v2 (180ms) vs Aptos Archon (10ms)
Key insight: Both need ~3 message rounds for BFT. But Mysticeti's rounds cross the WAN (60ms each), while Archon's internal rounds happen in microseconds (same datacenter).
Zaptos: Parallel PipelineDocs
Multiple blocks processed simultaneously at different stages
Block proposed and voted on
Block-STM parallel processing
State root signatures aggregated
State committed to disk
Key Innovation: Unlike sequential processing, Zaptos overlaps consensus, execution, certification, and storage. While block N is being stored, block N+1 is certifying, N+2 is executing, and N+3 is in consensus.
Shardines: Sharded ExecutionDocs
Dynamic partitioning for horizontal scalability
Hypergraph partitioner analyzes transaction dependencies to find optimal shard assignments
Build hypergraph G = (V, E) where V = transactions, E = shared resource accesses. Run min-cut algorithm to partition V into k shards minimizing |E_cross| (cross-shard edges).
For each transaction: (1) Extract read/write set from Move bytecode, (2) Map resources to hypergraph nodes, (3) Add edges for overlapping accesses. Partitioner uses Kernighan-Lin or spectral methods to find balanced cuts with minimal cross-shard communication.
Key Innovation: Shardines combines hypergraph partitioning (minimize cross-shard edges) with Block-STM per shard (optimistic parallel execution). Workloads automatically rebalance: shards split when overloaded, merge when idle. Cross-shard coordination uses lock-free MVHashMap with versioned reads—conflicts are rare (<5% for typical DeFi workloads) and resolved by deterministic re-execution.
Consensus ObserverDocs
Parallel fullnode sync for 30-50% lower latency
Leader proposes block to validator set and simultaneously forwards to observer network
⟨PROPOSE, B_n, σ_L⟩ broadcast to all validators. Observers receive via P2P gossip layer with block hash + parent linkage for ordering verification.
Leader sends: (1) Block data + transactions, (2) Leader signature σ_L, (3) Parent block reference. Observers validate block hash chain before processing.
Key Innovation: Observers receive ordered blocks directly from validators via P2P gossip and execute speculatively. Since block ordering is guaranteed by the consensus layer, observers can safely process blocks before finalization—rolling back only in rare fork cases (<0.01%).
GAS FEES: Stable Under LoadAptos Gas & Fees
Fee auction models can spike dramatically during demand surges. Aptos uses governance-set pricing—no gas wars, no priority auctions, just predictable fees regardless of network load.
Live Orderbook Stress Test
Block-STM executes orderbook transactions in parallel across 64 threads. At 500K tx/s peak load — no congestion, no fee spikes, sub-second finality.
Chain Comparison
Same orderbook load, drastically different outcomes
Other Chain (15 TPS)
50K orders = 3,333x capacity. Fees spike to $100s, 50%+ transactions fail.
Aptos (160K TPS)
50K orders = 31% capacity. Fees stay at $0.0001, 100% success rate.
Block-STM Parallel Execution
How Aptos achieves 160,000+ TPS
Optimistic Parallel Execution
Fee Market Economics
Why capacity matters more than fee market design
Fee Auction Model
When demand approaches capacity, users bid against each other. Fees spike exponentially with EIP-1559.
Fixed Floor Model
When capacity vastly exceeds demand, no auction is needed. Governance sets a flat minimum fee.
Gas Auction vs Flat FeeMONEY FLOW
Ethereum priority fee auctions vs Aptos $0.0001 flat fee
Where Does Your Money Go?
Encrypted Mempool
GOVERNANCE-PENDINGMEV protection via threshold encryption
How It Works
Encrypted Mempool ProtectionMEV SHIELD
Threshold encryption prevents front-running by ordering before revealing
How Encrypted Mempool Prevents Front-Running
MEV Protection: Side by SideCOMPARISON
Same transaction, different outcomes — see why encryption matters
Why This Matters
Perp DEX Stress Test
BTC flash crash with mass liquidations
Flash Crash Resilience
47,000 orders/sec during a -13% BTC crash with 12,000+ liquidations. On Aptos: fees stay at $0.00012, zero failed transactions, 0.02% slippage. Block-STM handles the chaos at 30% capacity.
Live Gas
Market Rate — Median gas price from recent blocks. What most transactions pay.
Priority Fee — Pay more for faster inclusion. Buckets: 100 → 1M octas.
Unlike Ethereum, Aptos fees stay remarkably stable—no surge pricing during congestion.
Transaction Flow Under Load
How each chain handles increasing transaction demand
- • Transactions queue at scheduler
- • 4-6 execution threads process queue
- • Heavy load → 15-30% drops
- • Dropped txs must be retried
- • Block-STM: no scheduling queue
- • 32+ threads execute in parallel
- • Handles load without drops
- • Conflicts resolved automatically