Reviewed and updated: October 19, 2026.
Aptos is a Layer 1 blockchain whose design combines Move-based applications with parallel transaction execution. Those two ideas address different problems: Move constrains how programs handle assets, while execution machinery tries to process work efficiently without changing the agreed result.
What the Move resource model contributes
The Aptos Move documentation describes resources, module-controlled access and explicit abilities such as copy and drop. A program cannot freely duplicate a resource that lacks the copy ability. This helps developers express scarcity and permissions in the type system.
It does not make every application economically sound. A resource can still be priced incorrectly, transferred under an overly broad permission or used by an application with flawed incentives. Language rules and application correctness are separate review tasks. The earlier assertion that assets cannot be lost was too broad.
What Block-STM does
Block-STM executes transactions speculatively in parallel and validates dependencies. Work that used an inconsistent input can be re-executed. The goal is a result consistent with the transaction ordering, not permission for two conflicting writes to silently overwrite each other.
Consider three fictional operations: Alice transfers an asset to Ben; Carla transfers a different asset to Dan; Ben then spends the asset received from Alice. The first two may have independent data dependencies. The third depends on the first. Parallel hardware does not erase that relationship.
Now imagine 1,000 users buying tickets from one counter stored in a single shared resource. If each operation must update the same remaining-ticket value, contention becomes part of the workload. Splitting independent state can help, but a design that must enforce a single inventory limit still needs correct coordination. Aptos's resource documentation explicitly contrasts per-user data with hot global resources.
Separate execution from consensus and user experience
| Stage | Question to ask |
|---|---|
| Submission | Was the request accepted, rejected or left pending? |
| Ordering and agreement | When do validators agree on the committed result? |
| Execution | How much work is independent, and how much conflicts? |
| Storage and serving | When does the committed result become available to the application? |
A fast execution benchmark measures only what its setup includes. The Aptos white paper's benchmark description labels a Block-STM experiment execution-only and specifies an in-memory database. It should not be presented as an unconditional end-to-end throughput guarantee for the live network.
A practical benchmark worksheet
For any throughput claim, record the software version, machine configuration, validator topology, transaction type, conflict rate and success definition. Also record latency distributions and fees. If one test counts simple transfers while another executes complex contract calls, their TPS numbers alone do not establish a winner.
For a fictional measurement, 9,000 committed user transactions during a 30-second observation window equal 300 transactions per second. If a separate chart counts 12,000 submitted requests, its 400 requests per second is a different metric. Failed requests and system transactions need explicit treatment.
How to read the Diem connection
Move originated in the Diem research lineage. That technical ancestry is useful context, but it does not establish a shared current network, legal entity or operating model. This guide removes the previous unsupported name etymology and compressed founding chronology. Readers looking for the policy history should use the separate Libra and Diem article.
Assess an Aptos application through its actual permissions, upgrade controls, state dependencies and observed performance. A language choice or a peak benchmark is one input to that assessment, not a substitute for it.
Sources and scope
- Aptos documentation: Move
- Aptos documentation: execution
- Aptos documentation: resources
- Aptos white paper, benchmark methodology
Continue reading: Libra and Diem history · Layer 1 and Layer 2
Editorial update: Removed unsupported etymology and unconditional TPS comparisons; clarified resource safety, shared-state contention and execution-only benchmarks.