[ARFC] Aave V3 Deployment on Aptos Mainnet

Title: [ARFC] Aave V3 Deployment on Aptos Mainnet

Author: @AptosFoundation

Date: 2025-04-16


ARFC updated with latest Risk Parameters by Risk Service Providers 2025-04-30

Summary

This proposal aims to deploy Aave V3 on the Aptos Mainnet, expanding beyond Ethereum to tap into a next-generation blockchain that offers high throughput, ultra-low transaction fees, and enhanced security. By leveraging Aptos’s innovative features—especially its use of the Move programming language—this move seeks to make the protocol more efficient, accessible, and resilient, positioning Aave to serve a broader audience and adapt to the evolving DeFi landscape.

If approved by the Aave community, Aave V3 will launch on Aptos Mainnet with a carefully chosen selection of assets, guided by community input and curated by Chaos Labs and Llama Risk.

This initiative aims to extend Aave into the thriving Aptos ecosystem—unlocking innovative growth opportunities and enhancing the value for both communities.

Background

The Aave Protocol has been EVM-native for over 6 years, ensuring widespread cross compatibility, a robust developer ecosystem, and significant network effects over the years both in terms of user base and liquidity. However, it also brings limitations, especially considering the existence of many non-EVM blockchains that offer different advantages such as lower transaction fees, higher throughput, and more advanced consensus mechanisms. In addition to purely technical advantages, many non-EVM blockchains can allow the Aave community to expand to an entirely new ecosystem, previously inaccessible user groups, and introduce new product possibilities.

Aptos is a blockchain designed for building scalable and secure dApps. Developed by former leaders of Meta’s Diem blockchain project, it aims to address some of the limitations in existing blockchain systems such as throughput, scalability, and security. With a TVL of approximately $958.64M and growing rapidly, Aptos is the 11th largest chain by TVL (source:DeFiLlama). Its robust infrastructure offers high transaction throughput, low, predictable fees, and advanced security through the Move programming language that make Aptos an ideal platform for DeFi applications.

Motivation

Deploying Aave V3 on Aptos represents a groundbreaking expansion as it marks Aave’s first deployment on a non-EVM blockchain. This strategic move is significant as it opens up new technological frontiers, diversifies Aave’s ecosystem, and underscores its commitment to innovation.

By leveraging Aptos’ innovative technology and developer community, Aave can address diverse financial needs, attract new users, and drive greater innovation in the DeFi sector. This deployment aligns with the Aave community’s strategic goal to explore new technological possibilities and tap into a wider pool of talent and resources.

Key benefits of deploying Aave V3 on Aptos include:

1. First Non-EVM Deployment:

  • This deployment is a significant milestone as Aave’s first move beyond EVM-compatible blockchains. It positions Aave to explore and integrate with new blockchain ecosystems, enhancing its resilience and broadening its reach.

2. Early Mover Advantage and Strong Brand:

  • Aave is a leading brand in the DeFi space, with a strong reputation and market share. By deploying on Aptos, Aave captures early mover advantages on a high-performance blockchain, similar to its strategic expansions to Avalanche and other L2s. This can attract both seasoned DeFi users and new participants exploring Aptos.

3. Aptos’ Strategic Position:

  • The Aptos team, with their background from Meta’s Diem project, has strong connections and expertise in finance, social and gaming sectors. Integrating Aave into Aptos complements these areas by adding a mature financial layer, essential for a complete blockchain ecosystem.

4. High Transaction Throughput:

  • Aptos supports up to 30,000 transactions per second (TPS), crucial for DeFi protocols like Aave that handle a high volume of transactions, including loans, repayments, and interest accruals. This high throughput can significantly enhance user experience and enable new use cases that require high-frequency transactions.

5. Enhanced Security with Move Language:

  • Aave v3 introduces sophisticated risk management tools and improved security protocols. The Move programming language used by Aptos has inherent security advantages, such as preventing reentrancy attacks. This alignment can lead to a more secure DeFi lending environment, leveraging Move’s safety features and formal verification.

6. Transaction Cost Efficiency:

  • Aave v3 focuses on gas efficiency, critical for reducing transaction costs. Aptos’ efficient processing capabilities further complement this by potentially lowering transaction fees even more. This makes Aave more accessible and attractive to a broader range of users, from retail participants to institutional players.

7. Modular and Flexible Architecture:

  • Aave v3’s modular and flexible architecture facilitates easier upgrades and expansions. Aptos supports upgradable smart contracts and a flexible account model, enhancing this aspect. This allows for seamless implementation of updates and improvements without significant disruptions or migrations.

8. Economic Benefits for the Aave DAO:

  • Market Share Growth: Access to new markets and user bases, specifically in APAC and Korea where Aptos has a strong presence.

  • Revenue Growth: New markets and user bases can significantly increase transaction volumes and generate additional revenue streams.

  • Incentives: Aptos Foundation has committed to provide up to 2M APT in liquidity mining incentives and rewards depending on performance in order to attract users and liquidity providers, increase adoption and boost the ecosystem’s growth. Aptos Foundation will work closely with Chaos Labs on determining the appropriate level of incentives relative to caps set.

By deploying Aave V3 on Aptos, we will have the first non-EVM deployment through which we can reach new user bases and tap into an ecosystem primed for high-demand DeFi applications, ensuring our protocol remains at the forefront of innovation.

Specification

Risk Parameters

ARFC has been updated by ACI to reflect latest Risk Parameters provided by Risk Service Providers 2025-04-30

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% - -

Technical Adaptation of Aave V3 to Aptos

Since our last update—and following the successful TEMP CHECK snapshot vote—we have made significant progress in tailoring Aave V3 for Aptos. We have been actively engaging with the community through regular development updates and rigorous testing on the Aptos testnet while involving security auditors at every step. Our extensive efforts have ensured that Aptos is now fully prepared to host Aave’s next-generation protocol.

Key areas of effort included:

1. Deep Protocol Understanding:

  • Comprehensive study of the intricate financial models and smart contract design of Aave V3, ensuring that the full complexity of the protocol is faithfully reimagined on Aptos.

2. Mastering Move and the Aptos Ecosystem:

  • Immersion into the Move language, its ecosystem, and best coding practices. This included analyzing standard native libraries, thoroughly understanding the Aptos VM architecture, and evaluating reference projects to inform our design choices.

3. Architectural Innovation:

  • Addressing Solidity limitations by rethinking architectural decisions in Move, with careful consideration given to gas optimization, safety, and security. This process ensured we employed best practices tailored to the Aptos environment.

4. Robust Development Process:

  • Building an MVP to evaluate model robustness, deployability, upgradability, scalability, and security. We re-implemented end-to-end, unit, and integration tests (including backward compatibility tests) and set up comprehensive pipelines for testing, compilation, deployment, audits, and documentation.

5. Tooling and Infrastructure:

  • Developing a complete front-end interface, a TypeScript SDK, and a custom fuzzer to stress-test our implementation. Additionally, we prepared the monitoring services, indexers, Rust-based services, and all necessary infrastructure to support a seamless go-live, including initial configuration, tokens, and faucets.

6. Governance Considerations:

  • Special attention was given to designing a governance strategy that aligns with the needs of a protocol on a new chain—starting with community guardians after launch, with future plans to integrate a full governance solution if market conditions warrant.

The UI is live and fully integrated with the TS SDK ensuring that developers can interact with the protocol and provide valuable feedback during the testnet phase. This level of preparation reflects our commitment to delivering a secure, efficient, and maintainable version of Aave V3 on Aptos.

Architectural Changes

This section outlines how the modern architecture and unique benefits of Aptos were capitalized in building this while ensuring the protocol retains its core functionality and top notch security.

1. Modular Conversion:

  • Ethereum Approach: Aave V3 is composed of multiple interrelated Solidity contracts (e.g., LendingPool, Token Manager, Risk Engine).
  • Aptos Adaptation: Each contract is restructured as a separate Move module. Move’s native module system enforces clear boundaries, enabling better separation of concerns, enhanced security and simplifying future upgrades.

2. Data & State Management:

  • Solidity: State variables are stored in contracts and accessed via delegatable external calls, which can sometimes lead to state inconsistencies.
  • Move: The use of resources in Move ensures that each asset is uniquely tracked and can’t be duplicated or lost. This strict management helps maintain consistency across the protocol’s state, avoiding re-entrances, double spending and other attack vectors. Also, Aptos has a uniquely defined global storage whose resources can only be modified by the owner of the resources thus preventing the storage from being maliciously modified in a transaction.

3. Control Access:

  • Solidity: By design solidity allows external contracts to modify our own contract state which makes it hard to control and avoid unexpected 3rd party breaches.
  • Move: Move modules have full control over their apis and do not allow by design delegate-calls (callbacks) to other contracts which prevents unexpected state-changes, re-entrances and other unwanted effects. On top of that, Aptos has a very secure system of allowing external modules to be friends and only scoping them to a particular scope of methods without ever giving control over its own resources.

4. Dispatch Mechanisms:

  • Solidity: Supports dynamic dispatch mechanism which enables a contract to call any other contract as long as a given interface is implemented. This can be however dangerous and the underlying implementation could often be replaced with a malicious one

  • Move: On the contrary supports only static dispatch which introduces a high degree of security as an external call to a module can only succeed at static compilation at which point contract address and implementation are known and immutable.

Security Enhancements

1. Formal Verification & Type Safety:

  • Move’s Built-in Features: Move was designed from the ground up to support formal verification. We have engaged with Certora to leverage its built-in verifier for mathematically proving smart contract properties, significantly reducing risks like re-entrancy attacks, integer overflows, and other vulnerabilities common in Solidity.

  • Resource-Oriented Programming: Resources in Move can only be created, moved, or destroyed in prescribed ways. This model ensures that token balances and collateral remain consistent and secure throughout all operations.

Performance and Gas Efficiency

1. Optimized Transaction Costs:

  • Gas Model Comparison: Whereas Solidity requires significant manual optimization to reduce gas consumption, Move’s design inherently minimizes resource usage. This results in lower fees and more predictable transaction costs on Aptos.

2. Parallel Execution with Block-STM:

  • Enhanced Throughput: Aptos’s Block-STM consensus allows for parallel transaction processing. This means that high-frequency operations (like loan issuance, repayments, and interest accruals) can be handled simultaneously, reducing bottlenecks and improving overall performance.

3. Atomic Transactions:

  • Consistency: All operations in Move are executed as part of an atomic transaction. This guarantees that either every part of an operation completes successfully or none do, preventing partial state changes and enhancing reliability. Transactions modifying the same state are executed atomically and linearized.

Developer Experience and Future-Proofing

1. Improved Modularity & Maintainability:

  • Move’s Module System: The modular architecture in Move not only organizes code in a logical manner but also facilitates isolated testing, easier upgrades, and reusability of code components.

2. Enhanced Tooling:

  • Ecosystem Maturity: The Move ecosystem is evolving rapidly, building improved IDE plugins, debugging tools, and testing frameworks. These tools will aid developers in writing, testing, and deploying smart contracts with greater confidence.

3. Future Integrations:

  • Adaptability: The structured approach of Move allows for easier integration of new features or protocol improvements in the future. As the Aptos ecosystem grows, Aave V3 can seamlessly evolve to incorporate emerging trends and requirements.

4. Governance Strategy:

  • Phased Approach to Governance: Initially, Aave Labs will retain control of the critical protocol keys while the market is in its early stages. Over the coming months—as the market matures, operates smoothly, and undergoes rigorous verification—we will gradually transition key management to trusted community guardians who will provide oversight and help manage early protocol decisions. In parallel, we will engage with relevant service providers to evaluate the feasibility of integrating the Aave Governance V3 system alongside a.DI, ensuring that future governance processes remain robust and fully aligned with community interests.

Development & Testing

1. Testnet Deployment:

  • A fully functional testnet for Aave V3 on Aptos is already live). This environment is used for rigorous testing of Move modules, simulating real-world scenarios.

2. Audit & Security Reviews:

  • Comprehensive internal and external audits are done and ongoing with companies like: SpearBit/Cantina, Certora and OtterSec. These will focus on ensuring that the Move modules adhere to Aave’s strict security and performance standards.
  • After the audits are complete, a Security Contest will go live followed by a comprehensive Bug Bounty program when we go live. This initiative, funded by Aave Labs, the Security Contest will offer a total reward pool of $150,000 paid in GHO stablecoin. The contest is designed to incentivize thorough testing and uncover any potential vulnerabilities, ensuring that our protocol meets the highest security standards prior to the mainnet launch.

3. Audit Reports: aptos-aave-v3/audits at main · aave/aptos-aave-v3 · GitHub

4. Developer & Community Feedback:

  • Continuous feedback will be solicited from our developer community to ensure that the transition to Move is smooth and that any issues are promptly addressed.

Conclusion

Deploying Aave V3 on Aptos presents a significant opportunity to drive Aave’s growth and expansion. By leveraging Aptos’s innovative capabilities and the power of the Move programming language, we can build a protocol that not only enhances efficiency and security but also broadens our reach into new markets and developer communities. This strategic initiative positions Aave at the forefront of DeFi innovation, enabling us to tap into emerging opportunities and accelerate ecosystem-wide growth.

Next Steps

  1. Integrate Chaos Labs and LamaRisk suggested assets and risk parameters report once available.
  2. Refine the ARFC based on community feedback and risk providers recommendations.
  3. Submit the ARFC for a Snapshot vote for final approval.
  4. If consensus is reached, submit an onchain AIP Vote for Aave V3 on Aptos (upon Mainnet launch)
8 Likes

It is great to see Aave expanding into new markets that are Non-EVM and Move is probably the best candidate out there for the DAO.

But what im wondering is, who will be in charge, at least from the beginning, for listing new assets?
Im unsure if the DAO has enough knowledge in Move and is capable of handling the AIPs to onboard new assets, change parameter etc.

So could @AaveLabs as the leading entity in this initiative, shed some light on this topic?
Also is the Aave guardian prepared if something happens to be able to freeze the market?
At least talking for me, I do currently not know what I would have to do as I haven’t been using Aptos yet.

So would be great to know if everything is setup so far, that we can be sure we keep the security level bar as high as usual and service provider are prepared as well.

Thank you

3 Likes

Summary

LlamaRisk supports Aave’s deployment on Aptos, a non-EVM layer 1 blockchain built on the Move programming language. Aptos provides a resource-oriented framework with unique features like parallel transaction execution and bytecode verification, offering potential advantages for scalability and security. Its current TVL is $958.6M, with over 80% concentrated in lending markets. The recent integration of native USDT and USDC has fueled stablecoin adoption, which accounts for 86% of the network’s assets. While liquidity remains fragmented between native and bridged assets, improvements are underway, positioning Aptos as a growing hub for stablecoin activity.

Aptos uses a Proof-of-Stake consensus with 149 validators and a minimum staking requirement of 1M APT (~$5.6M). This introduces centralization risks due to limited validator diversity and geographic concentration (55% in Europe). Additionally, Aptos penalizes underperforming validators through a missed rewards system instead of slashing, raising concerns about accountability. Despite these challenges, the network is supported by a $1 million bug bounty program and robust growth initiatives, including partnerships with TradFi giants like BlackRock and Franklin Templeton and a $200 million ecosystem grants program.

Aave’s deployment on Aptos could significantly enhance the network’s liquidity and lending market development. Aave’s proven ability to deepen liquidity and attract users was demonstrated on Sonic, where TVL increased by 40% within three weeks of deployment. Liquid staking tokens (LSTs) also present a growth opportunity for Aptos, as only 8.1%% of APT’s supply is in LSTs compared to 76% directly staked with validators. By integrating LSTs as collateral, Aave could unlock additional TVL and lending potential.

LlamaRisk suggests onboarding USDC, USDT, APT, and sUSDe to support the deployment, prioritizing native stablecoins due to reduced dependency risks. While risks related to validator centralization and Move’s relative novelty persist (available toolings and Aave technical adaptations), Aptos’ scalability, growing DeFi ecosystem, and institutional focus make it a promising platform for Aave.

1. Network Fundamental Characteristics

1.1 Network Architecture

Aptos is a layer 1 Proof of Stake network built on the Move programming language, characterized by its resource-oriented architecture, parallel execution engine, and differentiated bytecode verification model. The distributed nodes and smart contract framework that comprise the blockchain aim to increase speed, security, and scalability for low transaction costs. The network mainnet launched in October 2022.

Source: Aptos Transaction Flow, Aptos

Aptos transactions and contract interactions are facilitated by a set of nodes and components, including a Byzantine Fault Tolerance (BFT) based consensus model and Move Virtual Machine (MoveVM). The general lifecycle of an Aptos transaction:

  1. Transaction submission
    • 1.1. An Aptos Client constructs a transaction signed by an account’s private key
    • 1.2. Signed transactions include the transaction data (e.g., address, payload, gas price, expiration time), the account’s public key, and signature.
  2. Accepting the transaction
    • 2.1. The Client submits the transaction to the REST service of an Aptos fullnode. The node forwards to its own Mempool, which then sends to other fullnode Mempools. The Validator fullnode mempool eventually sends the transaction to a validator node (lead validator).
    • 2.2. The Validator’s mempool validates the transaction using the VM (signature and account balance verification).
  3. Sharing the transaction
    The transactions held in validator mempools are shared with other validators through the shared-mempool protocol.
  4. Proposing the block
    A validator chosen as Consensus leader for an epoch (see Consensus model section for more details) proposes a block of transactions from its mempool to other validator nodes via its consensus component. The leader coordinates an agreement on the order of transactions.
  5. Executing the block and reaching consensus
    • 5.1. The proposed block is shared with the Execution component, which manages execution within the VM. This occurs before a consensus has been reached
    • 5.2. The executed transactions in the block are appended to the Merkle accumulator (an append-only Merkle tree that Aptos uses to store the ledger).
    • 5.3. The results of the speculative execution are returned to the consensus component. The Consensus Leader then attempts to reach an agreement on these block results from sufficient validator nodes
  6. Committing the block
    If enough validators approve and sign off on the results, the Consensus Leader’s execution component retrieves the speculative execution data and permanently records all the block’s transactions in persistent storage.

For a full breakdown of transaction stages, see Aptos docs here. Overall, Aptos follows an established EVM POS pattern.

1.1.2 Programming Language

The Move language uses a resource-oriented programming framework that treats assets as unique and indivisible properties. Assets are represented as or within resources. The behavior of resources is predefined, requiring explicit duplicate and delete permissions at the bytecode level (using copy or drop)

Access control rules for accounts and modules (libraries or programs) in Move include:

  1. Module access is limited to public functions that other modules can interact with.
  2. Creating, accessing, and changing fields is only possible with modules directly defining the structure. Other modules can only do so if public functions.
  3. Accounts require signer approval to add resources to an account; modules may also require additional signer presence to access resources or modify assets in the account.

Resources (therefore, assets) and module functions have more predetermined behaviors and access measures than EVM.

Asset Standards

Aptos provides two standards for fungible tokens, similar to ERC-20 tokens on Ethereum, a legacy Coin standard and a newer Fungible Asset Standard.

The Digital Asset (DA) standard is the NFT standard for Aptos.

1.1.3 Nodes

Source: Validator node components, Aptos Docs

The node components and inter-component interactions that were mentioned in section 1.1 include:

  1. REST API service: External interface that clients interact with to access storage or other components; requests are filtered
  2. Mempool: In-memory buffer of submitted transactions pending consensus and execution. Distributed between nodes and checks validity.
  3. Consensus: Block ordering component that enables nodes to participate in the consensus protocol with other validators of executed transactions. This component is turned off in fullnodes (see types of nodes below).
  4. Execution: Transactions are executed using the virtual machine, and results are maintained within the component until consensus commits the block to the network ledger. (see section 1.1.5 for more details) .
  5. Virtual Machine: Runs verification checks on transactions, executes transactions, and runs Move program within embedded transactions.
  6. Storage: Local database component of committed blocks of transactions and execution results.
  7. State synchronizer: The component is used to stay up to date with the latest state of the blockchain
Types of nodes

Source: Node Networks and Synchronization, Aptos Docs

Aptos network hierarchy of nodes (see section 1.1 on transaction overview):

  1. Validator nodes (VNs): participate in consensus and process transactions. Validator nodes are the only node type that runs the distributed consensus protocol.
  2. Validator full nodes (VFNs): Update the state of the blockchain, run by the validator operator, and serve requests from public full nodes. Ostensibly operates like a public fullnode.
  3. Public fullnodes (PFNs): Syncs with VFNs or other update PFNs to gain low-latency access to the chain state.
  4. Archival nodes (ANs): Fullnodes that contain all blockchain data since the start of the blockchain’s history.

1.1.4 Consensus Protocol

Source: Consensus component, Aptos Docs

AptosBFT coordinates validators to determine the ordering and acceptance of transactions. Based on Jolteon, the Byzantine Fault Tolerance model determines how many validators operating incorrectly (e.g., offline or malicious) can be tolerated for a system to continue operating. (typically a ⅓ threshold)

Under this model, a single Validator is selected as a consensus leader, with other nodes communicating with the leader. A quorum of votes must be reached for consensus to pass (n-f votes, where ‘n’ is the total number of nodes and ‘f’ is the maximum number of malicious nodes). The validator leader is selected based on a deterministic formula based on a validator’s reputation determined by the Validator’s performance and their staked APT.

A leader is selected for an epoch; a new one is selected. An Aptos epoch is currently set to 7200 seconds/2 hours (duration is determined by onchain governance, potentially unlimited). The selection algorithm ensures that inactive or slow nodes have a lower chance of being selected as a leader, reducing the possibility of network degradation.

Risk considerations
Validators may be left in a validator set but cannot exit due to an epoch reconfiguration not occurring, creating stale/inactive validators (potentially affecting network performance). The team indicated this was an unlikely risk, with a fix possible with a reconfiguration transaction sent to these validators.

Validators

Validator staking is public, with a minimum stake required to join the validator set is 1M APT ($5.6M as of 3/20/25) and a maximum of 50M APT. Slashing is currently not enabled on the network. Instead, a missed rewards system is in place to penalize underperforming validators. Based on discussions in the community forum, slashing is unlikely to be implemented soon.

Voting weights for validators are proportional to their staked amount. Rewards are distributed solely to validator leaders, calculated based on a rewards_rate, staked amount, and proposer performance in the Aptos governance.

Validators can unlock their staked assets at any time, with APT becoming withdrawable after a fixed lockup period expires. Lockups can last as long as the fixed lockup duration. Fixed lockup is determined by Aptos governance.

Risk considerations
Aptos has set a high minimum threshold for validators relative to Ethereum (32 ETH). This centralization risk, coupled with how lead validators are selected, creates a small pool of validators, with highly staked validators having an advantage in being chosen to lead consensus more often than others.

Currently, there are 149 validator nodes distributed between 23 countries; the majority are based in Europe. While the number of validators is low relative to Ethereum, node performance as measured by ‘reward performance’ (% of reward earned by the Validator out of the maximum reward earning opportunity), i.e., proposal success rate, the majority of scores observed ranged between 95 - 100% (with 91.93% as the lowest score).

1.1.5 Virtual Machine

Source: Virtual Machine component, Aptos docs

Aptos leverages the Move VM to verify bytecode, execute transaction scripts, and produce execution results to update the blockchain state. Move VM transactions differ from EVM transactions by embedding scripts in transactions rather than relying on pre-deployed smart contracts.

The virtual machine component runs Move scripts in each transaction to determine execution results, verifying transactions from the mempool (e.g., signature and program) and executing transactions from the execution component.

Transactions on Aptos are executed in parallel, with multiple transactions handled simultaneously. As of December 2024, Aptos blocks closed on average within 250ms.

Key technical features enabled by Virtual Machine include:

  1. Bytecode Verification: A safety mechanism that verifies if bytecode adheres to security and correctness standards before running. The process includes type checking, resource usage analysis, and program form assessment.
  2. Block-STM: A parallel execution engine within the execution component developed by the Aptos Labs team.

The verification processes include layers of protection against malformed code. Malicious or bad code must be intentionally created, as the compiler does not produce malformed programs by default. Checks are performed during publication and loading to ensure Move standards are maintained. Lastly, an additional run-time “paranoid” mode checks to catch bytecode that may have evaded detection.

1.1.6 EVM Comparison

Feature EVM Move VM
Data Storage Data is stored in the smart contract’s storage space. Data is stored across smart contracts, user accounts, and objects.
Parallelization Parallel execution is limited due to shared storage space. More parallel execution enabled due to flexible split storage design.
VM and Language Integration Separate layers for EVM and smart contract languages (e.g., Solidity). Seamless integration between VM layer and Move language, with native Rust functions executable in Move.
Critical Network Operations Implementation of network operations can be complex and less direct. Critical operations (e.g., validator set management) natively implemented in Move for direct execution.
Function Calling Dynamic dispatch allows for arbitrary smart contract calls. Static dispatch aligns with a focus on security and predictable behavior.
Type Safety Contract types provide a level of type safety. Module structs and generics in Move offer robust type safety.
Transaction Safety Uses nonces for transaction ordering and safety. Uses sequence numbers for transaction ordering and safety.
Authenticated Storage Yes, with smart contract storage. Yes, leveraging Move’s resource model.
Object Accessibility Objects are not globally accessible; bound to smart contract scope. Guaranteed global accessibility of objects.

Source: Comparing EVM and Move VM, Aptos Docs

1.1.7 Value Proposition

  1. Chain Throughput
    Widely adopted by chains such as Polygon and Starknet, the execution engine supports complex, high-frequency operations and offers improved throughput (up to 32,000 TPS).
  2. Resource Architecture
    Assets defined uniquely with predefined behaviors (from approved accounts) offer the advantages of reduced errors and the risk of duplications relative to EVM variables in accounts.
  3. Verification Layers
    Embedded security measures in bytecode verification would provide a layer of security for asset deployments on Aave, reducing reliance on audits and smart contract risk related to common EVM vulnerabilities such re-entrancy attacks and integer overflows.
  4. Diversification
    A potential first deployment to a non-EVM chain allows Aave to expand its capabilities outside EVMs. Introducing a new ecosystem enables Aave to diversify into other languages and broaden the protocol’s technical possibilities.

Risk considerations
Risks and concerns include the Move language’s relative novelty, limited developer support, and less mature tooling, which may affect long-term reliability and integration. Additionally, the absence of slashing and reliance on a missed rewards system could weaken validator accountability and network stability.

Aptos is developing tools to help developers write, test, and deploy smart contracts on the network with IDE plugins, debug tools, and testing frameworks.

1.1.8 Bug bounty

Aptos has a $1 million bug bounty program live on HackenProof, covering the aptos-core repository in its scope. Aptos code has been audited by Certik, with its current security audit partners including Zellic, MoveBit, OtterSec, and Halborn.

Aave Labs has been testing v3 on testnet and working closely with the Aptos team and other stakeholders such as auditors and Chainlink.

1.2 Decentralization and Legal Evaluation

The global validator node distribution for Aptos:

  • Number of validator nodes: 149
  • Nakamoto Coefficient: 18

Aptos’ geographical stake distribution spans 27 countries and 57 cities, with 55.7% in Europe, 19.5% in Asia, 22.8% across North America, and 2% across the Rest of the World, indicating a high concentration of nodes in Europe.

The network features validator nodes for consensus participation, validator full nodes (VFNs) for data distribution to validators, and public full nodes (PFNs) accessible to anyone for indexing, querying, and APIs.

Source: Aptos Governance Proposal Flowchart, Aptos

Aptos community members can actively participate in governance by using their stake to create and vote on proposals. Onchain governance can change all network configurations, including:

  • Blockchain parameters, e.g., epoch durations, reward rate, gas schedule, and min/max validator stake.
  • Change core blockchain code.
  • Upgrade or change Aptos modules, e.g., fix bugs, change functionality.
  • Introduce new framework modules.

The aptos_governance module outlines how users can interact with governance. Anyone can enact a proposal that has passed voting using the Aptos governance execute-proposal command from Aptos CLI.

Proposals (AIPs) are posted and discussed within the community, with a voting period lasting 72 hours. A minimum participation threshold of 400M APT is required to proceed with a proposal. However, a governance proposal is currently being voted on to lower the threshold to 300M APT (~35%). Some notable proposals include new SDK development and delegation for operators.

Visibility in the number of unique addresses turning out to vote is low with only the level of participation, i.e., percentage of total supply, displayed on the governance portal.

Legal Commentary

Ecosystem development is entrusted to the Aptos Foundation and Aptos Labs. The Foundation is organized under the laws of the Cayman Islands and maintains aptosfoundation.org and aptos.dev as informational resources. Any authority over the Aptos Network—including oversight of on-chain activity and data, the validation of network transactions, and any actions taken by developers and users—is not vested in the Foundation. Indeed, the Foundation expressly disclaims control or responsibility concerning these functions.

Aptos Labs, subjected to the U.S. Federal Arbitration Act, federal arbitration law, and the laws of the State of California as indicated in the Terms’ Governing Law provision, is responsible for operating aptoslabs.com and graffio.art, as well as providing the Aptos Explorer, various APIs, SDKs, code repositories, dApp templates, smart contracts, and other developer resources. This also includes certain components of Aptos Keyless and the Aptos Learn platform. Like the Foundation, Aptos Labs disclaims any direct authority over the Aptos Network.

Notwithstanding these disclaimers, the Terms of Service for aptosfoundation.org and aptoslabs.com state that “Aptos is not offered to anyone who is a ‘Restricted Person’”. Under these Terms, an individual or entity is deemed a Restricted Person is subject to sanctions administered or enforced by any government or if appearing on any list of prohibited or restricted parties, including those maintained by the United Nations Security Council, the U.S. Government, the European Union or its Member States, or other relevant governmental authorities. These restrictions also encompass any citizen, organization, or resident in a territory subject to comprehensive sanctions, such as Cuba, the Democratic People’s Republic of Korea, the Crimea, Donetsk, and Luhansk regions, Iran, or Syria.

Censorship controls may be implemented by specific projects built atop Aptos. However, the underlying network does not provide or enforce system-wide freeze functionality.

1.3 Activity Benchmarks

Source: Aptos TVL & Stablecoin Market Cap, DeFiLlama, April 16th, 2025

The current TVL for Aptos stands at $958.6M, down from its ATH of $1.3B on December 17th, 2024. The stablecoin market cap doubled in December to $660M after the announcement of native USDT and USDC support. Since this initial spike in stablecoins, the market cap has steadily risen to $1.07B.

Lending Markets (as of April 16th, 2025)

Protocol TVL Total Supply Total Borrow Utilization Total Assets
Aries Markets $342M $545M $326M 59.8% 11
Echelon Market $187M $285.5M $81.5M 28.5% 24
Thala CDP $16.3M $13.9M $586K 4.2% 10
Meso Finance $23.4m $102M $78.35M 76.8% 16
Superposition $14.2M $31.8M $12.3M 38.7% 17
Aptin Finance $13.7M $24.5M $10M 40.8% 12
Echo Protocol $207.4M $226.1M $19.9M 8.8% 5
Joule Finance $4.7M $16.7M $8.5M 50.9% 13

The lending markets represent a combined TVL of roughly $808.7M, an 84.4% share of the network’s TVL.

2. Network Market Outlook

2.1 Market Infrastructure

Source: Top 10 DeFi Projects on Aptos by TVL, DeFiLlama, April 16th, 2025.

There are a total of 43 DeFi projects on Aptos. The top projects category-wise with TVL (volume for aggregators):

  • Lending: (see section 1.3.)
  • DEXs: ThalaSwap ($76.5M), Cellana Finance (40.8M), LiquidSwap ($18.6M), PancakeSwap ($10.2M), Sushi ($8.3M), Hyperion ($7.2M), Panora (Aggregator), Kana (Aggregator)
  • Liquid Staking: Amnis Finance ($186.7M), Thala LSD ($51.1M), TruStake ($48.6M)
  • Restaking: Echo ($3.6M)
  • RWA: Ondo Finance ($7.6M), Blackrock BUIDL, Franklin Templeton BENJI, Securitize $ACRED
  • Derivatives: Merkle Trade ($5.7M), Econia ($1.3M), Thetis Perps ($0.7M)

Tooling

Aptos is supported by leading bridging solutions, including LayerZero, Wormhole Bridge, Celer, Echo Bridge, Meson, Mover, Circle CCTP, and GALNT.

A total of 25 wallet providers are available, the prominent ones being Petra (by Aptos Labs), Bitget Wallet, OKX Wallet, and MSafe (multisig). Petra Wallet features Coinbase Pay and MoonPay, providing users with fiat on/off-ramp.

Additionally, RPC node services are provided by Ankr, BlockPI, and Chainstack. Pyth Network, Chainlink, and Switchboard are the oracle providers for Aptos.

2.2 Liquidity Landscape

Stablecoin

The stablecoin distribution on Aptos is as follows (as of April 17th, 2025):

The bridged variants are slowly fading since USDT and USDC are now natively available on Aptos, reducing dependency risks on third-party bridges and liquidity fragmentation. Native USDC will likely gain more adoption on Aptos as CCTP has been enabled for bridging. Additionally, Ethena recently launched on Aptos, allowing USDe and sUSDe integrations. The market cap of sUSDe on Aptos currently sits at $106.3M.

DEXs

Top 10 LPs by TVL across Aptos (as of April 17th, 2025):

DEX Pools TVL 24h Volume
Thala Swap sUSDe/USDC $24.6M $230.4K
Cellana amAPT/APT $10.8M $256.7K
Thala Swap USDC/USDT $16.3M $8.3M
Thala Swap APT/thAPT $8.9M $66.6K
Cellana aBTC/APT $7.9M $624.7K
Cellana TruAPT/APT $6.9M $0.0
LiquidSwap amAPT/APT $5.6M $50.7K
Thala Swap APT/USDC $7.3M $2.3M
LiquidSwap USDC/APT $5.9M $389K
Thala Swap APT/USDT $5M $1.5M

Source: Panora, April 16th, 2025. USDC & USDT swaps against APT within <5% slippage.

While USDC and USDT are natively available on Aptos, liquidity remains fragmented between bridged variants. This is reflected in the low liquidity of both native USDC ($1.09M) and USDT ($1.15M) relative to available chain supply ($283.7M and $1.13B, respectively).

Source: Panora, April 16th, 2025. APT & sUSDe swaps within <7.5% slippage.

Despite its recent launch, a promising sign for Aptos is the high supply of sUSDe at 91M ($106.3M). DEX liquidity within 7.5% price impact is high at 11.1M.

Bridges

Source: Aptos Bridged TVL Breakdown, DeFiLlama, April 17th, 2025.

Bridged TVL Breakdown:

Description Asset Value
Echo Bridge aBTC $211.8M
LayerZero lzUSDC $27.3M
lzSBTC $67.7M
lzUSDT $8.5M
lzWETH $4.7M
lzWBTC $5.8M
Wormhole Bridge whUSDC $5.9M
whSOL $5.8M
whUSDT $4.4M
whWBTC $3.1M
whWETH $1.4M
Celer ceUSDC $0.44M
ceWETH $0.16M
ceUSDT $0.13M

All BTC and ETH derivatives are supplied via bridges. Bridged USDC and USDT assets have slowed as native USDC and USDT have become available.

2.3 Ecosystem Growth Initiatives

The Aptos Foundation manages ecosystem grants program to support builders and community growth, offering $5,000 to $50,000 funding. 125M APT tokens were allocated at launch to support ecosystem projects, grants, and community growth initiatives. Recently, Aptos committed to spending $200M in a new grants and investments program.

Aptos Ascend program caters to TradFi institutions to onboard and use its secure and scalable tech. Current partners include MSFT, SK Telecom, Brevan Howard, and BCG. Also, Elliptic and Aptos Foundation have partnered to enable compliance screening and risk services for Aptos network.

The Aptos LFM program aims to support existing projects close to TGE through dedicated support infra, providing access to networks, fundraising, and token strategy guidance.

Native minting for both USDT and USDC was introduced, leading to an increase in stablecoin market cap and decrease in bridged stablecoin assets. As discussed earlier, the integration of Ethena allows for new yield-farming strategies, bolstering TVL on Aptos.

The onboarding of USDC introduces its CCTP technology, enabling seamless transfers across eight major chains, including Ethereum, Solana, Arbitrum, and Base. Additionally, the Aptos Foundation has announced plans to launch Stripe payment services integrated with native USDC, facilitating a fiat on-ramp for users.

Aptos also hosts some of the market’s largest tokenized RWAs, including BlackRock’s BUIDL Fund, Franklin Templeton’s FOBXX Fund, and Ondo Finance’s USDY token. Additionally, Aptos just announced that PACT Protocol, an RWA credit protocol, will be migrating to Aptos. These developments underscore Aptos’ trajectory toward becoming the preferred blockchain for tokenized assets and institutions seeking secure, high-performance onchain solutions.

2.4 Major and Native Asset Outlook

Due to the relatively recent integration of native USDT and USDC on Aptos, their liquidity and market presence remain limited. However, liquidity for USDT and USDC has been in an uptrend since integration, with the recent addition of CCTP likely pushing further adoption. Bridged WETH (LayerZero, Wormhole, Celer) and WBTC (LayerZero, Wormhole) are available, too. Additionally, aBTC, a BTC restaking token from Echo Protocol, is the most significant bridged asset (as shown in section 2.2).

APT is the native token of Aptos, facilitating transaction fees and enabling governance participation for users staking APT with validators. The current annual staking reward rate is 7%. Both locked and unlocked APT can be staked.

Source: APT Vesting Schedule, Aptos

Currently, the circulating supply is 617M APT, with 1% of the total supply being released monthly. The Aptos Foundation holds 80% of the 510M APT community tokens, while Aptos Labs controls 100M APT. Anchorage, Coinbase, and Copper manage foundation wallets. In addition to their custodian services, they also insure custodied assets.

The network also features various liquid staking tokens (LSTs) for APT, including (as of April 17th, 2025):

The combined market cap of Liquid Staking Tokens (LSTs) is $440M, accounting for just 8.1% of APT’s $5.4B total market cap. Notably, 76% of APT supply is directly staked with validators, offering a 7% APR, highlighting the significant untapped potential for LST adoption and growth.

As mentioned in sections 1.1.4 and 1.2, validator centralization is characterized by geographical concentration (50% in Europe) and minimum staking requirements (1M APT). Relative to Ethereum, this level of centralization creates an unhealthy reliance on a single jurisdiction (e.g., potential regulation that could impact the network’s performance). A limited set of validators increases exposure to potential malicious or inactive validator risk. Even if slashing were implemented, it would likely do little to minimize these centralization factors.

3. Onchain Discoverability

The Aptos ecosystem is supported by a diverse range of tools, including blockchain explorers such as AptoScan (by Etherscan), Aptos Explorer (by Aptos Labs), TraceMove, Xangle Explorer, and OkLink (by OKX), alongside data providers like Google BigQuery, Dune, Flipside, Sentio, and Space and Time.

Analytics dashboards are available on platforms such as DeFiLlama, TokenTerminal, The Tie, Nansen, DappRadar, SuperAptos, Dune, and Flipside, offering detailed insights into the Aptos ecosystem.

4. Impact of Aave Deployment

Lending markets account for 59% of the network’s total TVL. Echelon Market, leveraging Aave’s E-Mode design, has significantly enhanced capital efficiency, establishing itself as the second-largest lending protocol on Aptos. Aave’s proven track record of efficient lending markets will dramatically enhance DeFi on Aptos by attracting more users. The recent deployment of Aave on Sonic depicts how Aave attracts TVL, with Sonic’s TVL rising by over 40% in the three weeks after Aave was deployed. This aligns with the recent launch of native USDT, USDC, and USDe on Aptos, further stimulating lending and borrowing activities on the network. The increased usage of stablecoins caused by Aave will help the entirety of Aptos by deepening liquidity.

Also, LSTs account for only 7.6% of APT’s supply, compared to 77% staked directly with validators. This underscores significant growth potential for liquid staking, which, as adoption increases, could serve as collateral to enhance Aave’s TVL in the future.

5. Asset Suggestions

Our methodology for onboarding assets focuses on three key criteria: prior successful integration and risk assessment within the Aave ecosystem, asset TVL on the network, and the available liquidity relative to the total asset TVL.

Suggested assets for onboard:

Asset Onchain Supply DEX Liquidity
USDC 241M 1.09M
USDT 1.13B 1.15M
APT 1.15B 369K
sUSDe 91M 11.1M

Other significant assets on the network, such as aBTC, amAPT, and stAPT, have not been considered due to not being previously onboarded and require a separate risk assessment. Although lzUSDC offers similar liquidity to native USDT and USDC, it presents additional security considerations due to being a bridged variant. The suggested supply cap for APT should be determined following a risk assessment of Aptos’ native token.

Aave V3 Specific Parameters

Will be coordinated and presented jointly with @ChaosLabs

Price feed Recommendation

Chainlink price feeds are available for the suggested assets through a single price feed contract.

Note: This assessment follows the LLR-Network Qualification Framework, a comprehensive methodology for network onboarding and parameterization in Aave V3. This framework is continuously updated and available here.

Disclaimer

This review was independently prepared by LlamaRisk, a community-led decentralized organization funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.

The information provided should not be construed as legal, financial, tax, or professional advice.

2 Likes

Thanks @AptosFoundation, for the ARFC. Even if we have not been involved directly in this project, given our role on Aave DAO’s technical and security side, we would like to give some overall thoughts for the community.

High-level, this is an ad-hoc expansion of the Aave protocol to a different environment, and even if a fully legitimate proposal, expectations/implications should be understood:

  • The implementation loosely mirrors the Aave v3 features and patterns on its latest v3.3 version, but unlike other expansions of Aave v3 to EVM networks, it is not exactly Aave v3.3: it is not the same codebase (language/patterns-wise), there are certain divergence features-wise, upgrade procedures or control model are not the same at inception.
    This is not negative by itself, but simply makes it an exception to the other instances.

  • Aside from the core protocol and some peripheral components, Aave v3 has countless other tools and procedures around it. These will not be realistically available to the DAO on launch, as it would require almost swapping all DAO resources to Aave on Aptos, which, at least from our side, we don’t think is in any way possible.

  • All Aave v3 expansions are always decentralised by default, based on on-chain governance proposals and the Aave decentralised infrastructure that factually activates the pool on the new network and immediately gets control over it. As commented on the ARFC, this will not be the case for Aave on Aptos, as even if temporarily, Aave Labs has been proposed to hold all critical permissions of the instance. We agree that the technical limitations of reproducing the infrastructure required for decentralisation are high, and not realistic in the short term, but it is still very important for the Aave DAO to understand that factually, it will not have control over this instance.

  • BGD Labs has not been involved in any capacity with this expansion, the reasons being that initially we were not aware of it, and once we became aware, didn’t really fit in our scope of work for the DAO: related to what we previously commented, in environments pretty different from EVMs, the effort required to expand with the quality of EVM is major, and in what concerns us, we think our involvement and expertise are better allocated to different parts of Aave.
    We would like to clarify, though, that this is not any type of exception on our side towards Aptos, but applicable to previous cases even closer to Ethereum, like Starknet.

  • Given the involvement of Aave Labs in both this project and Aave v4, it could make sense to clarify how exactly both will fit lifetime-wise. As commented on the phased approach, Aave on Aptos will require multiple months to have feature parity with other instances, while at the same time, Aave v4 is expected to be released in the upcoming months.
    This is even more important than the strategy regarding v3 upgrades on EVM networks, precisely due to being a project built completely ad-hoc from scratch, not a live system leader in the industry, which should be maintained and improved to maximum standards.

  • The current public Aave on Aptos repository is license/copyright-wise with All Rights Reserved to Aave Labs. It is important for the DAO to understand if this will change in the future.

  • As a documentation feedback, we encourage the team that developed the v3 port to explicitly outline the differences in basic network infrastructure directly affecting the Aave protocol. For example, the tokenization approach itself is totally different compared with EVMs, which has deep implications for flows on the Aave protocol. This extends to all audit reports and security procedures documentation.

3 Likes

Hello @EzR3aL,

At launch, the Aptos deployment will include a curated set of assets based on Risk Service Provider recommendations.

If there’s a necessity to list additional assets, proposals can follow the standard Aave governance flow: Temp Check → ARFC → Snapshot. Once approved, the Aave Guardian will have the authority to list assets on Aptos during the initial deployment phase.

For the first ~6 months, Aave Labs and @AptosFoundation will jointly retain the Aave Guardian role, with a focus on emergency readiness. This includes the ability to freeze markets or take swift action if needed — all executed via multisig through tools like msafe, so no additional infrastructure is required for emergency actions.

Once the initial training wheels period is achieved, a separate governance proposal will later be brought forward to elect a new Aave Guardian for Aptos, following the existing EVM process. Tooling will be made available so the newly selected Guardian can act onchain directly.

Lastly, to empower contributors across the DAO, Aave Labs will provide onboarding, workshops, and tools for DAO Service Providers — helping ensure the Aptos market is maintained securely and effectively.

1 Like

Thank you, @bgdlabs, for the input. Your points raise essential considerations for the community, and we appreciate the opportunity to provide further context and clarification on this initiative.

Divergence from the Standard EVM Deployments

Aave on Aptos is not a direct codebase port of Aave v3.3. While the architectural design mirrors the core concepts and risk primitives of Aave v3, this deployment is built in Move from the ground up, tailored to Aptos’s architecture. That makes it inherently different in terms of language, composability patterns, upgrade logic, and governance hooks.

Rather than viewing this as a 1:1 expansion of v3.3, it’s best understood as a new deployment designed to maintain Aave’s principles while adapting to the Move-native ecosystem. This deviation is intentional and acknowledged.

The goal is to test the potential of Aave’s model in a non-EVM environment, starting with a sandboxed, permissioned launch that can evolve in step with the DAO’s engagement and the Aptos ecosystem’s maturity. While we acknowledge the critical complexity involved in porting such a mature protocol to a fundamentally different architecture, we strongly believe this should be seen as a strategic opportunity for the Aave DAO both to expand the protocol’s reach into new technical frontiers and to progressively grow the DAO’s and service providers’ capabilities in non-EVM technologies. This expansion opens the door to a more robust, multiverse-native Aave ecosystem.

DAO Infrastructure and Decentralization Trajectory

We fully agree: a realistic view of DAO infrastructure readiness is critical. At launch, Aave Labs will indeed hold initial permissions over the Aptos deployment — primarily due to:

  • Lack of mature cross-chain governance bridges compatible with Move VM.
  • The need for ongoing iterations on code and infrastructure without burdening the DAO with low-level technical operations,
  • And to ensure a security-first phased rollout.

That said, decentralization remains the main priority. The current control structure is explicitly designed to be transitional, and part of the initiative involves preparing the foundation for DAO control via secure cross-chain abstractions when viable.

This approach follows the same governance playbook used in previous network expansions, such as Avalanche, where full decentralization was introduced progressively as operational and governance readiness increased. We believe this reference model offers a solid precedent for how Aave on Aptos can follow a secure and transparent path to DAO ownership.

This roadmap, once completed, will be shared transparently with the DAO.

Relationship with Aave v4

This is an important question. The development of Aave v4 and the Aptos deployment do not compete, but rather serve different strategic purposes.

The Aptos deployment is not intended to be feature-parallel with Aave v4 at launch. Rather, it’s a deliberately phased deployment, starting with a v3-aligned architecture to:

  • Establish the core risk and lending primitives in a Move-native format,
  • Validate the protocol mechanics and integration touchpoints within the Aptos ecosystem,
  • And allow for a controlled, iterative expansion path.

It’s worth highlighting that the Aptos initiative began well before Aave v4 had reached the final stages of feature design and technical scoping. Starting directly with a v4-equivalent architecture on Aptos would not have been feasible given the evolving nature of both projects.

By launching with a v3-aligned design, the team was able to gain extensive experience in building for Move and non-EVM environments, laying the groundwork for future protocol iterations and cross-VM knowledge that can feed back into the broader Aave ecosystem.

Licensing and Open Source Commitment

The current Aptos repository is under All Rights Reserved licensing to allow for tight quality control and security during the early phase of deployment. We understand the importance of aligning with Aave DAO’s ethos of open innovation.

We plan to shift the repository to a more permissive license once the protocol achieves sufficient maturity and audit stability. A concrete proposal outlining this transition (including what rights the DAO will hold over the codebase) will be published for community review before the mainnet deployment.

Documentation & Technical Clarity

This is a valuable suggestion. Move’s resource-oriented model introduces fundamental differences that materially affect protocol logic and risk assumptions.

We are actively working on documentation.

We would welcome feedback from BGD or other ecosystem stakeholders once those are published to ensure completeness and clarity.

This deployment is a step into new territory. We’re committed to maintaining transparency with the DAO and aligning the deployment with Aave’s decentralization roadmap, security standards, and long-term goals.

Thanks again for raising these important points, community dialogue is what ensures Aave remains at the frontier while upholding the standards that made it a leader.

3 Likes

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

2 Likes

The current proposal has been edited by ACI, under Skywards, to reflect latest Risk Parameters provided by Risk Service Providers.

As such, the current proposal has been escalated to ARFC Snapshot.

Vote will start tomorrow, we encourage everyone to participate.

1 Like