Overview
Chaos Labs supports the deployment of an Aave instance on Aptos. This report provides a detailed examination of Aptos’s technical specifications and the associated risks.
Technical Architecture
Aptos is a non-EVM Layer-1 blockchain that leverages the Move language to offer programmability. It uses a Byzantine Fault Tolerant POS consensus mechanism, where a decentralized set of validators collectively receive, validate, and execute user transactions. Token holders delegate their tokens to validators, and each validator’s consensus voting weight is proportional to the total amount staked. Key participants in the system also include clients and nodes. Clients refer to any entities that submit transactions or query blockchain data. Full nodes are a type of client that maintain a complete and synchronized copy of the blockchain’s transaction history and state, sourced from validators or other full nodes.
Aptos Key Components
The Aptos blockchain maintains a versioned ledger state that captures the complete state of all accounts, each identified by a unique 256-bit address. The ledger evolves through transactions, each of which includes a payload (such as a function call or script), gas parameters, a sequence number to prevent replay, and cryptographic authentication. Transactions are executed deterministically by the Aptos virtual machine and produce outputs consisting of state updates (write sets), gas usage, events, and a final status. These events, emitted by Move modules, serve as structured logs and are indexed for querying but cannot be read during execution, preserving determinism. Account data consists of type-keyed resource values stored under the account address, with at most one top-level value per type.
Move
Move is a bytecode-level programming language designed to model values with strict ownership and access semantics using a resource-oriented type system. Its core abstraction is the resource: a value that cannot be copied, discarded, or reused, and must be explicitly moved between storage locations. These linear semantics are enforced at compile time by the type system and further validated by the bytecode verifier, ensuring that resources are never accidentally duplicated, dropped, or reused. This makes them safe to use in open blockchain environments, where correctness cannot rely on trusted users or off-chain enforcement. While commonly used to represent tokens or assets, resources are general-purpose and can be passed, stored, or returned like any other value. Move modules define how resources are created, destroyed, and manipulated, providing strong control and verifiability.
A Move program consists of modules and transaction scripts executed by a stack-based virtual machine. Modules are persistent on-chain units that declare custom types (structs or resources) and procedures (functions), uniquely identified by an account address and module name (e.g., 0x1::Coin). Only the declaring module can access or modify its resource types, ensuring strong encapsulation. Users submit transaction scripts—single-use programs that invoke public procedures from modules to perform state transitions. All programs are verified before execution to enforce type safety, memory integrity, and resource correctness.
Modules act as reusable, namespaced components that define both data types and their governing logic. Each account can declare only one module per name (e.g., 0x1::coin), though different accounts can define modules with the same name, resulting in distinct types like 0x1::coin::Coin and 0x3::coin::Coin. Generic types (e.g., 0x1::coin::Coin<0x2::wallet::USD>) enable shared logic across distinct instantiations. Modules are published in on-chain packages, which include metadata specifying upgradeability. Upgradeable packages allow safe, additive changes (such as adding new functions or types) under strict compatibility checks, supporting long-term maintainability without breaking existing contracts.
Move Module Example
Consensus & Validator
A transaction begins when a client submits a raw transaction to the REST API of an Aptos full node (Client → REST service). The full node forwards it to its local mempool (REST service → mempool), which then propagates the transaction to a validator’s mempool. Upon receipt, the validator invokes the Move Virtual Machine (mempool → VM) to perform stateless validation: verifying the digital signature, checking the sequence number to prevent replays, confirming sufficient balance for gas fees, and ensuring the payload is structurally valid and executable. If the transaction passes these checks, it is retained in the mempool and shared with other validators via the shared-mempool protocol.
Once a transaction has been validated, the validator’s mempool holds it in an in-memory buffer alongside other pending transactions. If multiple transactions from the same sender exist, the mempool ensures proper ordering based on sequence numbers. The transaction is then propagated to other validators using the shared-mempool protocol (mempool → other validators), where each validator shares its mempool contents with peers and integrates received transactions into its own buffer.
When a validator is elected as the proposer for a consensus round, its consensus component pulls a batch of ready-to-execute transactions from its own local mempool, selecting those that have passed validation and meet ordering requirements. This proposed block is broadcast to other validators (Consensus → Other Validators) and passed to the execution component for speculative execution (Consensus → Execution). The execution component processes the block using the Move Virtual Machine (Execution → VM), applying transactions in-memory to compute state changes, gas usage, and emitted events. These speculative results are recorded in a temporary Merkle accumulator and returned to the consensus component (Execution → Consensus), which coordinates validator agreement on the execution outcome (Consensus → Other Validators). Once a quorum of validators signs off on the results, the block is finalized: the execution component retrieves the speculative state and persists the transactions and their effects to storage (Consensus → Execution → Storage).
Aptos Transaction Flow
Aptos’s staking framework uses an owner-operator-voter model. The owner controls the funds, can designate an operator to run the validator node, and optionally assign a voter to participate in governance. While these roles are separable, the owner and operator can also be the same account. To join the validator set, an operator must run a validator node and an owner must stake at least 1M APT through a staking contract. Validators operate under a state model (inactive, pending_active, active, or pending_inactive) and their corresponding stake also transitions through granular states to control lockups and withdrawals.
A validator’s voting power is proportional to their active stake, subject to a governance-defined maximum cap of 50M APT and a minimum of 1M APT. Rewards are calculated each epoch using the following formula:
reward = staked_amount × (rewards_rate / rewards_rate_denominator) × (successful_proposals / total_proposals)
The current reward rate is 15,981 per epoch, with a denominator of 1,000,000,000, effectively defining an APY-like return. Stake is locked in 14-day recurring periods, automatically renewed upon expiration. To withdraw, validators must explicitly submit an unlock request, after which the stake becomes withdrawable only once the current lockup period concludes. As of now, there are 149 nodes distributed across 23 countries, with Europe hosting the majority.
Ecosystem and Market
Aptos experienced strong growth throughout 2024, with TVL rising from around $100M at the beginning of the year to over $1B by year-end, peaking at $1.24B. While growth has moderated somewhat in 2025, total TVL has consistently remained above $900M. As of this writing, Aptos’s TVL stands at $971.45M.
Aptos TVL
Aptos’s daily active address count has shown a trend closely aligned with its TVL growth. Starting in early 2024, the number of daily active addresses steadily increased, peaking at 1.6M by the end of the year. Although activity has slowed somewhat in 2025, it has remained strong, consistently averaging around 1M daily active addresses.
Aptos Daily Active Addresses
A deeper analysis of active account data provides further insight into user behavior. Both daily retained accounts and new user accounts have remained consistently strong. Over the past 60 days, daily retained accounts have ranged between 850K and 1M, while daily new accounts have averaged approximately 300K.
The Aptos ecosystem has developed into a mature and comprehensive landscape, spanning a wide range of sectors including RPC services, explorers, DeFi, GameFi, NFTs, bridging protocols, and stablecoins. Among the leading projects, Aries Markets stands out with a TVL of $314M, offering lending, borrowing, leveraged trading, and margin trading via an on-chain order book. Echo Protocol, with a TVL of $210M, focuses on liquid staking and restaking solutions. Echelon Market, holding $194M in TVL, is a lending protocol that enables borrowing with high LTV ratios across select asset pairs.
Tooling
The Aptos blockchain provides a suite of tooling designed to support developers and users in managing on-chain operations, analyzing network activity, and mitigating ecosystem risks. Four key components form the backbone of this infrastructure: aggregators for parallel transaction processing, MEV-related mechanisms, block explorers for transparency, and analytics platforms.
Aggregators
Aptos’s ecosystem features several notable aggregator and backend trading infrastructure projects, including Econia. Econia is a decentralized order book protocol built specifically for Aptos, utilizing Move-based aggregators to manage order books and balances. This enables parallel transaction processing and high-throughput trading, taking advantage of Aptos’s unique execution model. Other protocols, such as Panora and Pontem, have developed DeFi products like DEX aggregators that route trades across multiple liquidity pools to optimize user swaps.
MEV
Aptos’s architecture differs from Ethereum and Solana by not having a public mempool and by using deterministic parallel execution, which naturally limits traditional forms of MEV such as front-running and sandwich attacks. There are currently limited MEV extraction or mitigation protocols on Aptos akin to those on Ethereum or Solana. However, research and monitoring are ongoing within the Aptos developer community and among DeFi protocols.
Block Explorers
The official Aptos Explorer provides comprehensive data on transactions, blocks, validators, and Move smart contract activity. Third-party explorers such as AptoScan and Sentio Explorer offer difference interfaces, which include advanced filtering, token tracking, and real-time event feeds.
Analytics
Platforms like Dune, Nansen, and Chainbase have integrated Aptos, offering dashboards for asset tracking, wallet profiling, and DeFi analytics. Sentio provides developer-focused analytics, including real-time monitoring of Move contract events, error rates, and user engagement metrics. These tools help projects and users gain insights into network usage, liquidity flows, and protocol health, supporting both day-to-day operations and strategic decision-making.
DEXes
Robust DEX liquidity is a fundamental prerequisite for any Aave deployment, as it ensures efficient trade execution and supports healthy liquidations. Below, we present four of the largest DEXs currently operating on Aptos. Together, they create a healthy and well distributed ecosystem that reduces fluctuations in liquidity.
- ThalaSwap
- TVL: $151.7M
- 7-Day Cumulative Volume: $202.03M
- Hyperion
- TVL: $8.61M
- 7-Day Cumulative Volume: $131.72M
- Cellana Finance
- TVL: $51.34M
- 7-Day Cumulative Volume: $66.09M
- LiquidSwap
- TVL: $26.38M
- 7-Day Cumulative Volume: $8.56M
Tokens
We propose an initial listing of four assets that will provide basic functionality to the new instance; additional assets can be proposed and considered separately to expand the available use cases. Of the four, three have already been reviewed extensively and are listed on other Aave instances. The one that has not, APT, is the native token of the Aptos network. The table below presents basic figures on the four assets, while we cover APT in more detail in the next subsection.
| Asset | Supply on Aptos | Market Cap on Aptos | Sell Liquidity | Link to Asset |
|---|---|---|---|---|
| USDC | 287,804,620 | $287M | $13.1M | Link |
| USDT | 1,130,000,000 | $1.13B | $22.9M | Link |
| APT | 1,152,408,390 | $6.39B | $11.9M | Link |
| sUSDe | 88,610,287 | $103M | $8.6M | Link |
We note that these four assets comprise the majority of TVL on the two existing lending markets on Aptos: Aries (81%) and Echelon (62%; SBTC is the second largest supplied asset).
APT
The APT token serves multiple functions within the ecosystem, primarily enabling network operations through transaction fee payments, validator staking for network security, and participation in on-chain governance decisions. APT holders can stake their tokens with validator nodes to contribute to consensus and potentially earn rewards, or delegate their tokens to preferred validators. The token also supports ecosystem development by incentivizing developers who create applications on the platform.
As the native token of Aptos, we expect that it will serve a similar function as tokens like OP and ARB, which are primarily used as collateral; APT does not have any properties that make it highly risky as collateral.
APT is moderately volatile, with a 30-day daily annualized volatility of 80.64%; its average daily trading volume is $402M, of which Binance accounts for the plurality.
While APT has a total supply of just over 1.1B, its current circulating supply is 619M, meaning that under half of the total supply is due to enter circulation by 2032.
Listing Parameters
In the case of USDC and USDT, we recommend aligning their parameters with their respective parameters on other instances. Regarding sUSDe, we recommend aligning its parameters with those on the ZkSync instance, while creating an E-Mode that will allow users to leverage the asset using USDC and USDT.
For APT, we recommend setting collateral parameters in line with ARB and OP, while aligning its IR curve with other volatile assets. It is expected that the community may wish to onboard APT LSTs; should these assets be suitable for listing, we will likely recommend updating the IR curve to better facilitate APT borrowing.
Supply and Borrow Caps
In line with Chaos Labs’ approach to setting initial supply caps, we recommend a supply cap set to 2x the liquidity available under the a price impact equivalent to the asset’s Liquidation Penalty; a more aggressive methodology is not necessary or prudent because this network is already well established and has demonstrated a stable TVL.
We recommend setting the borrow caps slightly higher than the UOptimal of each asset to allow for a borrow rate increase to follow a surge in demand.
Oracles
We recommend using Chainlink data feeds for each asset, with the same setup for sUSDe as on Ethereum Core.
Specification
| Parameter | Value | Value | Value | Value |
|---|---|---|---|---|
| Asset | APT | USDC | USDT | sUSDe |
| Isolation Mode | No | No | No | No |
| Enable Borrow | Yes | Yes | Yes | Yes |
| Enable Collateral | Yes | Yes | Yes | Yes |
| Loan To Value | 58% | 75% | 75% | 65% |
| Liquidation Threshold | 63% | 78% | 78% | 75% |
| Liquidation Penalty | 10% | 5% | 5% | 8.5% |
| Reserve Factor | 20% | 10% | 10% | 20% |
| Liquidation Protocol Fee | 10% | 10% | 10% | 10% |
| Supply Cap | 1,000,000 | 25,000,000 | 40,000,000 | 14,000,000 |
| Borrow Cap | 500,000 | 23,000,000 | 37,000,000 | - |
| Debt Ceiling | - | - | - | - |
| UOptimal | 45% | 90% | 90% | - |
| Base | 0% | 0% | 0% | - |
| Slope1 | 7% | 6% | 6% | - |
| Slope2 | 300% | 40% | 40% | - |
| Stable Borrowing | No | No | No | No |
| Flashloanable | Yes | Yes | Yes | Yes |
| Siloed Borrowing | No | No | No | No |
| Borrowable in Isolation | No | Yes | Yes | No |
| E-Mode Category | N/A | sUSDe/Stablecoin | sUSDe/Stablecoin | sUSDe/Stablecoin |
sUSDe/Stablecoin
| Asset | sUSDe | USDC | USDT |
|---|---|---|---|
| Collateral | Yes | No | No |
| Borrowable | No | Yes | Yes |
| LTV | 90.00% | - | - |
| LT | 92.00% | - | - |
| Liquidation Bonus | 4.00% | - | - |
Disclaimer
Chaos Labs has not been compensated by any third party for publishing this ARFC.
Copyright
Copyright and related rights waived via CC0