Messari Research Report: A Comprehensive Look at Aptos’ Technical Improvements, Ecosystem Development, and Network Activity
TechFlow Selected TechFlow Selected
Messari Research Report: A Comprehensive Look at Aptos’ Technical Improvements, Ecosystem Development, and Network Activity
Aptos is ready to go.
Navigating Web3 tides with focused insightsWritten by: Peter Horton, Messari
Translated by: Aptos Global
TL;DR
1) Aptos is a Layer 1 blockchain designed around core principles of scalability, security, reliability, and upgradability. It originated from Meta’s Diem and Novi projects and launched in October 2022.
2) Aptos’ tech stack features several novel components, including the AptosBFTv4 consensus mechanism, Quorum Store mempool protocol, Block-STM parallel execution engine, and the programming language Aptos Move.
3) Since July 2023, Aptos has averaged over 475,000 daily transactions and more than 72,000 daily active addresses, driven by on-chain activity from social media platform Chingari, oracle Pyth, and one-day public art creation events on Graffio.
4) Aptos Labs and the Aptos Foundation have formed partnerships with numerous well-known companies and conglomerates, including Microsoft, Alibaba Cloud, NPIXEL, Rakuten Group, Coinbase Pay, among others, with many growth initiatives focused on the Asia-Pacific region.
The debate between modular and integrated architectures has been widely discussed. In summary, both paths are converging toward similar outcomes: modular chains initially optimize for verifiability and decentralization, while integrated chains prioritize low latency and high throughput.
Aptos is one of the largest players in the integrated camp. The development team, Aptos Labs, has raised approximately $400 million in total funding. Since its mainnet launch in October 2022, the network has rapidly upgraded, releasing over 40 AIPs and eight major versions. Aptos’ ecosystem is relatively young but already includes projects such as on-chain order books, perp DEXs, and social media platforms. In recent test environments resembling mainnet conditions, Aptos has demonstrated peak throughput of 30,000 TPS and processed over two billion transactions in a single day. If it can sustain technical upgrades and attract developers and users, Aptos is poised for significant growth.
Background
Aptos emerged from Meta’s Diem and Novi projects. In 2019, Meta (then Facebook) officially announced plans for a blockchain-based payment network consisting of the permissioned Diem blockchain (originally called Libra) and the Novi wallet (originally Calibra). Led by the independent Diem Association and Meta subsidiary Novi Financial, the project never launched due to regulatory pushback. Diem was shut down in January 2022 and its assets sold to Silvergate Capital, while Meta announced the end of Novi in September 2022.
Aptos Labs was founded in December 2021 and formally launched in February 2022. It was co-founded by Mo Shaikh, former Head of Strategic Partnerships at Novi, and Avery Ching, a software engineer from Novi with a background in supercomputing who previously led strategy at ConsenSys and founded Meridio, a blockchain-based fractional real estate platform. The rest of the founding team consists of PhDs, researchers, engineers, designers, and strategists, many of whom also worked on Diem or Novi.
In March 2022, Aptos Labs announced a $200 million raise and launched its public developer network and open-source codebase. This round included equity and token options, led by a16z with participation from Multicoin Capital, ParaFi Capital, Coinbase Ventures, and many others. In July 2022, Aptos Labs announced a subsequent $150 million raise, reportedly at a $2 billion valuation, led by FTX Ventures and Jump Crypto. FTX Ventures also participated in the first round; those investments are now under the control of FTX’s bankruptcy proceedings. Further strategic investments from Binance Labs and Dragonfly Capital brought total funding to approximately $400 million.
After publishing the Aptos whitepaper in August 2022, the mainnet launched in October 2022. Since then, the Aptos network has completed multiple upgrades and is currently on version V1.8.0, with the Aptos Foundation leading ecosystem development efforts.
Technology
Aptos’ technology stack is designed around the core principles of scalability, security, reliability, and upgradability, introducing novel mechanisms across many aspects of the stack.
Consensus
Aptos is a Proof-of-Stake (DPoS) Layer 1 using the AptosBFTv4 consensus protocol.
Aptos BFT
AptosBFT (originally DiemBFT) underwent four iterations during the Diem era before being adopted by the Aptos blockchain. The initial AptosBFT was based on HotStuff, which itself builds upon traditional Practical Byzantine Fault Tolerance (pBFT) protocols. Aptos’ current implementation, AptosBFTv4, is now based on Jolteon, improving HotStuff latency by 50% through pBFT-style quadratic view changes.
Additionally, to reduce delays caused by faulty leaders, AptosBFT selects leaders not only based on stake but also performance (collectively termed “reputation”). Validators are scored based on their success rate both as leaders (frequency of submitting proposals) and non-leaders (frequency of voting on proposals).
Through the implementation of Quorum Store in the Aptos V1.5 upgrade completed on July 18, 2023, Aptos throughput has been further enhanced. Quorum Store is an implementation of the mempool protocol Narwhal. It improves consensus by decoupling data dissemination from consensus. This separation of data propagation and consensus is a key finding from the Narwhal and Tusk paper jointly authored by researchers from Aptos Labs and Mysten Labs.
Before Quorum Store, transaction processing involved two stages: mempool and consensus:
1) Mempool phase: All transactions are broadcast to all validators.
2) Consensus phase: The leader broadcasts all transactions in its proposed block to all validators; non-leaders vote by sending signed block metadata.
This led to two bottlenecks:
1) Redundant transaction propagation: All transactions were propagated twice—to all validator nodes—during both mempool and consensus phases.
2) Uneven workload distribution: During consensus, the leader performed significantly more work than non-leaders, as it had to send raw transactions along with relatively small signed block metadata messages. Thus, total bandwidth was capped by the leader’s bandwidth, leaving non-leader bandwidth underutilized.
Quorum Store introduces an intermediate stage between the mempool and consensus protocols. The new full process is now:
Mempool Phase: Transactions are no longer broadcast to validators but are instead sent to Quorum Store.
Quorum Store Phase: The Quorum Store protocol receives transactions from the mempool and batches them in order based on gas fees. These batches are then broadcast to validators. Upon receipt, validators sign the batch and send signatures to other validators. Once a batch receives signatures from more than ⅔ of validators, Quorum Store creates a proof of availability, guaranteeing the batch’s uniqueness and accessibility.
Consensus Phase: The consensus protocol remains the same, except that now the leader uses certified batches from Quorum Store—instead of raw transactions from the mempool—to create blocks.
This resolves both bottlenecks mentioned above:
Redundant transaction propagation: Raw transactions are propagated only once (from mempool to Quorum Store); afterward, only batches are propagated, reducing data volume in messages.
Uneven workload distribution: During consensus, the leader now only needs to send batch metadata (and corresponding PoAv), significantly reducing its workload and making it more comparable to non-leaders. Additionally, all validator nodes perform equally during the Quorum Store phase.
In testing, Quorum Store increased TPS limits by 12x in consensus-only tests and 3x in end-to-end tests. However, leader-based protocols like AptosBFT cannot fully realize Quorum Store’s benefits, so Aptos Labs is exploring upgrading to a DAG-based consensus protocol. More details can be found in the roadmap section.
DPoS
Validators are compensated through inflationary staking rewards. Currently, all transaction fees are burned. Staking rewards are weighted by validator reputation (stake and performance). Rewards are distributed and automatically compounded every epoch, which lasts two hours. Staked tokens are locked for a global 30-day period.
Each validator sets a commission rate and passes the remaining percentage of tokens to its delegators. On-chain delegation was implemented on mainnet on April 20, 2023. Delegators need at least 11 APT to participate, enabling broader community access to staking, as the minimum stake required to operate a validator is 1 million APT (worth $10.5 million as of December 26, 2023).
The maximum stake per validator is capped at 50 million APT, roughly 5% of total supply—a relatively soft cap. However, if a validator operator accumulates sufficient stake, they may be incentivized to run multiple validator nodes. Notably, locked tokens can be staked to earn liquid rewards after the 30-day unlocking period.
Currently, there are no slashing penalties for offline or malicious validators, though such mechanisms could be added via governance in the future.
Execution
Once validators agree on block ordering, they must execute the transactions within the block and save the results to storage. Many blockchains use sequential transaction engines, where transactions are processed one after another. To accelerate execution, Aptos employs a parallel execution engine. Moreover, unlike other networks with parallel transaction processing such as Solana and Sui, Aptos does not require users to pre-declare dependency knowledge.
To achieve this, Aptos uses Block-STM, built on the principles of Software Transactional Memory (STM) and Optimistic Concurrency Control (OCC). STM libraries with OCC follow a general framework where transactions execute optimistically (assuming no dependencies), are validated post-execution, aborted if dependencies arise, and eventually re-executed. However, due to overhead from managing dependencies and cascading aborts, this approach has limited performance and is rarely used in practice.
To make OCC STM systems deployable and overcome these limitations, Block-STM leverages predetermined transaction order to estimate dependencies, thereby reducing abort rates. One key finding from the Bohm (2014) research paper is that predetermined transaction order may be a blessing rather than a curse. Block-STM exploits this ordering even more than Bohm, improving dependency estimation after each abort and thus reducing chances of further aborts.
Block-STM further improves upon general STM by leveraging blockchain-specific features:
1) VM Safety: The Move VM (Move will be detailed below) ensures uncommitted states do not negatively affect other ongoing transactions by catching errors and charging gas fees;
2) Block granularity: Garbage collection is simple because it can occur between blocks. While Block-STM initially only tracked block commitments to reduce synchronization costs, Aptos Labs later improved the algorithm to support intra-block rolling commits without sacrificing performance.
Before stepping through each phase of Block-STM, it helps to define a term already mentioned: dependencies. Blockchain transactions consist of smart contract code that reads and writes shared memory. During execution, each transaction maintains lists of these read and write locations, known as read sets and write sets. If Mo’s transaction reads from a location in shared memory first written by Avery’s transaction, then Mo’s transaction depends on Avery’s. Dependent transactions must be executed sequentially—in this case, Avery first, then Mo.
With this understanding, we can now break down Block-STM’s step-by-step process into five main stages:
1. Pre-ordering Transactions
From the prior consensus phase, there exists a block containing transactions in a specific order. As noted earlier, this predetermined order is a key advantage of Block-STM—the parallel execution result must produce identical read and write sets as sequential execution.
2. Optimistic Execution
Block-STM executes transactions in parallel, optimistically—that is, assuming no dependencies exist.
3. Validation
Executed transactions are then validated—i.e., checked for dependencies—by re-reading the transaction’s read set and comparing it with the latest executed read set. If the two read sets differ, the transaction is aborted.
A critical aspect of Block-STM is efficiently scheduling execution and validation tasks in sequence, specifically:
Prioritizing earlier tasks according to the pre-set order.
Batching validations early to detect missed dependencies and avoid cascading aborts.
Note that validation is much cheaper than execution, so continuous validation (re-reading read sets) is not a primary bottleneck.
4. Abort and Re-execute
When a transaction is aborted, an ESTIMATE tag is applied to the location it wrote to. Subsequent transactions reading this location will see the ESTIMATE tag and pause execution until a value overwrites the tag. This occurs when the original, aborted transaction successfully re-executes. Whenever a transaction re-executes, the scheduler ensures any higher-ordered dependent transactions are re-validated.
This dynamic dependency management is a key concept in Block-STM. Without the ESTIMATE tag, the second transaction would execute and potentially abort due to reading from a location written by an aborted transaction. Thus, Block-STM avoids wasteful work from executing transactions likely to abort. Additionally, dynamic dependency management offers improvements over prior dependency systems: First, users don’t need to declare dependencies, supporting atomicity of arbitrarily complex transactions (no need to decompose). Second, it manages dependencies only when needed, rather than storing dependencies for all transactions. Finally, most dependencies are based on state updates newer than the block’s starting state.
5. Commitment
Once Block-STM detects that a transaction’s optimistic execution output is correct, it is committed via a rolling commit mechanism. Rolling commits rely on lightweight synchronization to validate and commit batches of transactions incrementally before processing the next batch.
In testing, Block-STM achieved up to 170,000 TPS using 32 threads on Aptos benchmarks—17 times faster than sequential execution.
6. Storage
When a block is committed, its data is persisted in the storage layer. Although commits happen per block, each individual transaction is separately stored in a Merkle tree after execution. Everything that happens on the blockchain—including transactions and state changes—can be cryptographically proven via a digest called the "root hash," authenticated by signatures from current validators. This differs from other blockchains that require tracking the entire chain to verify past transactions, enabling finer-grained provable data access.
To handle large volumes of data, Aptos uses two types of Merkle trees: Jellyfish Merkle Trees for disk-based data storage and in-memory sparse Merkle trees for fast updates. These trees are optimized for efficient data storage and concurrent updates. Aptos Labs is exploring several additional approaches to scale storage, particularly sharding, detailed further in the roadmap section.
7. Move
Move is a bytecode language inspired by Rust, created by the Diem and Novi teams. Move offers enhanced flexibility and security compared to Solidity and other Web3 programming languages.
Move consists of two types of programs: transaction scripts and modules. Transaction scripts are atomic and can only be used once, while modules are published to global state and persist indefinitely.
Modules are analogous to smart contracts in other languages—they define resources and associated procedures. Resources act like objects, and procedures are operations that can be performed on them, such as creation, modification, or deletion. Resources are specifically designed to represent scarce assets like tokens and include built-in protections to prevent accidental duplication or loss.
Modules enforce data abstraction: types are transparent within their declaring module but opaque outside. In other words, only the original module can create, destroy, or update values. External access to module data is limited to public procedures exposed by the module. These guarantees are enforced at runtime by Move’s bytecode verifier, which all modules and transaction scripts must pass before execution via the Move VM. This data abstraction is more explicitly enforced in Move than in Solidity/EVM, which supports encapsulation but less strictly.
Move aims to eliminate attack vectors present in Solidity and EVM, particularly those arising from lack of first-class assets beyond ETH and reentrancy attacks.
First-class assets: On EVM, ERC-20 and other assets lack the native scarcity and access control properties of Ether. Solidity developers must manually implement protections to avoid bugs causing asset duplication, reuse, or loss. In contrast, all resources on Move—not just native assets—are treated as first-class assets with these protections built-in.
Reentrancy attacks: Unlike EVM, Move lacks unsafe dynamic dispatch, where the VM doesn't know what external contract functions are doing before the original contract finishes execution. Dynamic dispatch enables reentrancy attacks—one of the most common sources of blockchain hacks, including the recent Curve/Vyper vulnerability. In a reentrancy attack, a contract calls an external contract, which then callbacks into the original contract before it completes execution and updates balances, potentially draining funds repeatedly.
Move is designed to make it harder for developers to make mistakes.
Beyond the bytecode verifier, developers can also leverage the formal verification tool Move Prover. Of course, Move does not eliminate the possibility of vulnerabilities in smart contracts. Programmers still need to establish proper security invariants within their modules. Additionally, the bytecode verifier and Move Prover do not replace the need for audits. Audit firm CertiK has observed cases where developers either fail to use Move’s built-in protections or adopt programming patterns ported from legacy code designs contrary to Move’s design philosophy.
8. Other Key Features
User Safeguards
Aptos includes several features to improve user experience and security, including flexible key management, transaction outcome transparency, and light client support.
Aptos accounts decouple private keys from public keys, enabling flexible key management. Users can rotate their account’s private keys proactively or in response to compromise, without transferring all assets to a new account. Users can also configure their account as multi-signature, with different permissions per public key. For example, a user might create an account with two hot public keys capable of signing transactions, and one cold public key that can sign transactions and also rotate private keys. The user could then require 2 out of 3 account keys to sign transactions.
To help prevent phishing attacks and generally improve transparency, wallets can use transaction pre-execution to explain transaction outcomes in readable format before the user signs.
Aptos also adds transaction protection by including expiration time and sequence numbers in transactions. Sequence numbers function similarly to nonces on EVM, helping prevent replay attacks.
Light clients allow users to easily verify blockchain state by downloading only block headers, minimizing trust assumptions when accessing blockchain data—especially important for high-performance blockchains like Aptos with higher node hardware requirements.
Upgradability
Source: Messari
Aptos is designed to support frequent protocol upgrades. This is largely enabled by on-chain validator management, allowing validators to easily sync to new upgrades. Parts of Aptos itself are also written in Move, shortening time-to-market as described earlier. Since launch, approximately 46 improvement proposals have been implemented.
Tokenomics
Overview
Aptos’ native token APT is used for security and Sybil resistance (validator and delegator staking), resource consumption (transaction fees), and on-chain governance. Initially, 1 billion APT were allocated across several buckets with varying lock-up schedules. APT has no fixed supply; the current annual inflation rate is 6.895%. All transaction fees are currently burned.
Initial Distribution
As noted, 1 billion tokens were distributed at genesis. Additionally, 13% were unlocked at genesis, while the remainder is subject to vesting schedules. Distribution is as follows:
Ecosystem (51.02% of initial total supply): The largest portion of the initial APT allocation is dedicated to ecosystem development. About a quarter of these tokens were unlocked at genesis, with the remainder linearly unlocked monthly over the next 10 years. Prior to allocation, about 80% of these tokens were held by the Aptos Foundation, with the rest held by Aptos Labs. At genesis, an APT airdrop distributed over 20 million tokens from the ecosystem bucket to more than 110,000 participants.
Team (19% of initial total supply): These tokens are allocated to Aptos Labs and follow a four-year vesting schedule: one-year cliff, followed by 6 months of 6.25% monthly unlocks, then 30 months of 2.083% monthly unlocks. Note that employees joining Aptos Labs after genesis still follow the same four-year schedule.
Foundation (16.5% of initial total supply): These tokens are allocated to the Aptos Foundation, with 3% (5 million tokens) available at genesis. The remainder follows the same four-year vesting schedule as team tokens. The Foundation plans to use these tokens for events, legal support, sponsored research, and other initiatives, as well as covering operational costs to assist validator operators and further geographic distribution of validators.
Private Investors (13.48% of initial token supply): These tokens were allocated to investors who purchased tokens in Aptos Labs’ private funding rounds and follow the same four-year vesting schedule as team and foundation tokens.
As noted, APT is inflationary and continuously provides rewards to stakers. The annual inflation rate for the first year post-genesis was set at 7%, decreasing by 1.5% annually (6.895% in year two) until stabilizing at 3.25%. Note that this rate is based on the initial 1 billion APT total supply and is governed.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
Messari
