Aptos Glossary

A

Accumulator Root Hash

An accumulator root hash is the root hash of a Merkle accumulator.

Account

An account in the Aptos blockchain is a container for an arbitrary number of Move modules and Move resources.
The state of each account is composed of both code and data.
The account is identified by account address.

See Accounts for more information.

Account Address

An account address is the address of an Aptos account.
Account address refers to a specific destination on the Aptos network. The address dictates the destination and source of a specific amount of assets exchanged by two parties on the blockchain.
Aptos addresses are 64-character hex string (32 bytes). Often times these strings are prefixed with 0x and for first 16 addresses, the leading 0s are excluded (ex. 0x1)

See Accounts for more information.

API

An Application Programming Interface (API) is a set of protocols and tools that allow users to interact with Aptos blockchain nodes and client networks via external applications. Aptos offers a REST API to communicate with our nodes.
See documentation for more details.

APT

Aptos token (APT) is the Aptos blockchain native token used for paying network and transaction fees.

Aptos

Aptos is a Layer 1 blockchain for everyone. It uses the Move programming language and launched its mainnet on 2022-10-17 to redefine the web3 user experience. The Aptos blockchain is dedicated to creating better user experiences through increased speed, security, scalability, reliability and usability with low transaction costs. The word “Aptos” means “The People” in the Ohlone language. Learn more about the Aptos blockchain on the official Aptos website.

AptosBFT

AptosBFT is the Aptos protocol’s BFT consensus algorithm.
AptosBFT is based on Jolteon.

Aptos Blockchain

The Aptos blockchain is a ledger of immutable transactions agreed upon by the validators on the Aptos network (the network of validators).

Aptos Name Service (ANS)

The Aptos Name Service (ANS) is a decentralized naming address service for the Aptos blockchain. An Aptos name is a human-readable .apt domain name that is used in place of a public key, for example love.apt.
This service also allows users to register subdomain names in addition to the registered domain. Find out more at: Aptosnames.com

Aptos Core

Aptos-core is the open-source repository containing the code for Aptos Network software. Aptos-core contains software for

the Aptos blockchain itself, which generates and stores the immutable ledger of confirmed transactions and
the validation process, which implements the consensus algorithm to validate transactions and add them to the Aptos blockchain immutable ledger.

Aptos Ecosystem

Aptos ecosystem refers to various components of the Aptos blockchain network and their interactions. The Aptos ecosystem includes the community, community-driven projects, and events.

Aptos Explorer

The Aptos Explorer is an interface that helps users examine details of the Aptos blockchain, including account information, validators, and transactions.
The Aptos Explorer help users validate their work in Aptos wallets and other tools in the blockchain.

Aptos Framework

The Aptos Framework defines the public API for blockchain updates and the structure of on-chain data. It defines the business logic and access control for the three key pillars of Aptos functionality: payments, treasury, and on-chain governance. It is implemented as a set of modules written in the Move programming language and stored on-chain as Move bytecode.

Aptos Node

An Aptos node is a peer entity of the Aptos network that tracks the state of the Aptos blockchain. There are two types of Aptos nodes, validators and fullnodes.

Aptos Protocol

Aptos protocol is the specification of how transactions are submitted, ordered, executed, and recorded within the Aptos network.

AptosAccount

A AptosAccount is a Move resource that holds all the administrative data associated with an account, such as sequence number, balance, and authentication key.
A AptosAccount is the only resource that every account is guaranteed to contain.

AptosAccount module

The AptosAccount module is a Move module that contains the code for manipulating the administrative data held in a particular AptosAccount.T resource.
Code for checking or incrementing sequence numbers, withdrawing or depositing currency, and extracting gas deposits is included in the AptosAccount module.

Aptos Devnet

See devnet.

B

Blocks

On Aptos, blocks are a batch of transactions committed at the same time.
Block number is analogous to “block height” in blockchain literature.
Transactions are referenced by ledger version rather than by block.

Byzantine (Validator)

A validator that does not follow the specification of the consensus protocol, and wishes to compromise the correct execution of the protocol.
BFT algorithms traditionally support up to one-third of the algorithm’s voting power being held by Byzantine validators.

Byzantine Fault Tolerance (BFT)

Byzantine Fault Tolerance (BFT) is the ability of a distributed system to provide safety and liveness guarantees in the presence of faulty, or “Byzantine,” validators below a certain threshold.
The Aptos blockchain uses AptosBFT, a consensus protocol based on Jolteon.
BFT algorithms typically operate with a number of entities, collectively holding $N$ votes (which are called “validators” in the Aptos network’s application of the system).
$N$ is chosen to withstand some number of validators holding $f$ votes, which might be malicious.
In this configuration, $N$ is typically set to $3f + 1$ . Validators holding up to $f$ votes will be allowed to be faulty — offline, malicious, slow, etc. As long as $2f + 1$ votes are held by honest validators, they will be able to reach consensus on consistent decisions.
This implies that BFT consensus protocols can function correctly, even if up to one-third of the voting power is held by validators that are compromised or fail.

C

CLI

Command line interface refers to the Aptos CLI used for developing on the Aptos blockchain, operating nodes, and debugging issues. Find out more at the Aptos CLI page.

Client

Client is software that receives information from the blockchain and manages transactions. Clients interact with the blockchain through the Aptos nodes.

Code Labs

Code labs and tutorials depict various workflows - such as the use of the Aptos CLI in minting non-fungible tokens (NFTs) - in order for users to understand how the process works and employ related functions in their code. If users have the necessary funds in their accounts, they can follow the same code lab and tutorial steps used in devnet, testnet and mainnet networks.

Consensus

Consensus is a component of a validator.
The consensus component is responsible for coordination and agreement amongst all validators on the block of transactions to be executed, their order, and the execution results.
The Aptos blockchain is formed with these agreed-upon transactions and their corresponding execution results.
The consensus component is accountable for achieving security, trust, and agreement among all validators on the Aptos blockchain.

Consensus Protocol

A consensus protocol is collectively executed by n validators to accept or reject a transaction and to agree on the ordering of transactions and execution results.
See BFT.

D

Dapps

Decentralized applications (dapps) are programs or digital applications that run on the Aptos blockchain autonomously. Smart contracts are commonly used to achieve this function.

Devnet

The Aptos devnet is a publicly deployed instance of the Aptos network that runs using a set of validator test nodes.
The devnet is a demonstration of the Aptos network that is built for experimenting with new ideas
The devnet simulates a digital payment system and the coins on the devnet have no real world value.
The devnet is the network by which developers are given the opportunity to test given protocols. It is similar to testnet as it operates independently of the mainnet yet is reset weekly.

E

Ed25519

Ed25519 is our supported digital signature scheme.
More specifically, the Aptos network uses the PureEdDSA scheme over the Ed25519 curve, as defined in RFC 8032.

Epoch

An epoch is the period of time between reconfigurations of the validator set and other administrative actions by the blockchain. On Aptos mainnet currently, it is every 2 hours.

Event

An event is the user-facing representation of the effects of executing a transaction.
A transaction may be designed to emit any number of events as a list. For example, a Coin<AptosCoin> transfer emits a WithdrawEvent for the sender account and a DepositEvent for the recipient account.
In the Aptos protocol, events provide evidence that the successful execution of a transaction resulted in a specific effect. The DepositEvent (in the above example) allows the recipient to confirm that a payment was received into their account.
Events are persisted on the blockchain and are used to answer queries by clients.

Execution

Execution in the Aptos blockchain is an Aptos node component that manages the block of transactions. The execution component stores successful transactions.

Expiration Time

A transaction ceases to be valid after its expiration time. If it is assumed that:

$Time_C$ is the current time that is agreed upon between validators ( $Time_C$ is not the local time of the client);
$Time_E$ is the expiration time of a transaction $T_N$ ; and
$Time_C > Time_E$ and transaction $T_N$ has not been included in the blockchain, then there is a guarantee that $T_N$ will never be included in the blockchain.

F

Faucet

Faucet is a service that mints APT on devnet and testnet. APT on these networks has no real world value, it is only for development purposes.
You can use the faucet in a few different ways:
- With the Aptos CLI.
- Through a wallet, such as Petra or Pontem. See full list of Aptos Wallets.
- Using an SDK, for example by using the FaucetClient in the TypeScript SDK.
- With a direct HTTP request. Learn how to do this here.

Fullnodes

Fullnodes are clients that ensure data are stored up-to-date on the network. They replicate blockchain state and transactions from other fullnodes and validator nodes.

Fungible Asset

A fungible asset is an asset, such as a currency, share, in-game resource, etc., that is interchangeable with another identical asset without any loss in its value. For example, APT is a fungible asset because you can exchange one APT for another.
Follow the Asset Standards to create fungible assets on the Aptos blockchain.
Next generation of the Coin standard that addresses shortcomings of aptos_framework::coin such as lack of guaranteed enforcement of freeze and burn and advanced functionalities such as programmable transfers, e.g., approve in ERC-20.

Fungible Token

For the legacy Aptos Token Standard (aptos_token::token), a fungible token is a token that is interchangeable with other identical tokens (i.e., tokens that share the same TokenId). This means the tokens have the same creator address, collection name, token name, and property version.
For the Aptos Digital Asset Standard (aptos_token_objects::token), a * fungible token* is a fungible asset with metadata object that includes a Digital Asset resource.

Fungible Unit

A fungible unit is an individual unit of a fungible asset. These units are identical and interchangeable without any loss in value. For example, each Octa (the smallest unit of APT) is a fungible unit.

G

Gas

Gas is a way to pay for computation and storage on a blockchain network. All transactions on the Aptos network cost a certain amount of gas.
The gas required for a transaction depends on the size of the transaction, the computational cost of executing the transaction, and the amount of additional global state created by the transaction (e.g., if new accounts are created).
The purpose of gas is regulating demand for the limited computational and storage resources of the validators, including preventing denial of service ( DoS) attacks.

See Gas and Storage Fees for more information.

Gas Unit Price

Each transaction specifies the gas unit price the sender is willing to pay per unit of gas.
The price of gas required for a transaction depends on the current demand for usage of the network.
Gas price is expressed in Octas.

See Gas and Storage Fees for more information.

H

Honest (Validator)

Honesty means a validator that faithfully executes the consensus protocol and is not Byzantine.

Jolteon

Jolteon is a recent proposal for a BFT consensus protocol.
AptosBFT, the Aptos network’s consensus algorithm, is based on Jolteon.
It simplifies the reasoning about safety, and it addresses some performance limitations of previous consensus protocols. In particular, it reduces latency by 33% compared to HotStuff.

I

Indexer

Indexer is the component of Aptos that retrieves, processes, and efficiently stores raw data in the database to provide speedy access to the Aptos blockchain state.
At a high level, indexer gets data from a gRPC stream and runs processors to transform raw blockchain data and serve transformed data via GraphQL endpoint.

L

Leader

A leader is a validator that proposes a block of transactions for the consensus protocol.
In leader-based protocols, nodes must agree on a leader to make progress.
Leaders are selected by a function that takes the current round number as input.

M

Mainnet

Mainnet refers to a working, fully-operational blockchain. A mainnet network has been fully deployed and performs the functionality of transferring digital currency from a sender to a recipient.

Maximum Gas Amount

The Maximum Gas Amount of a transaction is the maximum gas amount in gas units that the sender is ready to pay for the transaction.
The transaction can be successfully executed only if the gas used does not exceed the maximum gas amount.
The gas charged is equal to the gas price multiplied by units of gas required to process this transaction.
If the transaction runs out of gas while it is being executed or the account runs out of balance during execution, then the sender will be charged for gas used and the transaction will fail.

See Gas and Storage Fees for more information.

Mempool

Mempool is one of the components of the validator. It holds an in-memory buffer of transactions that have been submitted but not yet agreed upon and executed. Mempool receives transactions from other full nodes.
Transactions in the mempool of a validator are added from the JSON-RPC Service of the current node and from the mempool of other Aptos nodes.
When the current validator is the leader, its consensus component pulls the transactions from its mempool and proposes the order of the transactions that form a block. The validator quorum then votes on the proposal.

Merkle Trees

Merkle tree is a type of authenticated data structure that allows for efficient verification of data integrity and updates.
The Aptos network treats the entire blockchain as a single data structure that records the history of transactions and states over time.
The Merkle tree implementation simplifies the work of apps accessing the blockchain. It allows apps to:
- Read any data from any point in time.
- Verify the integrity of the data using a unified framework.

Merkle Accumulator

The Merkle Accumulator is an append-only Merkle tree that the Aptos blockchain uses to store the ledger.
A Merkle accumulator can provide proofs that a transaction was included in the chain (“proof of inclusion”).
They are also called “history trees” in literature.

Module

A module in the Move programming language may either be a program or library that can create, transfer, or store assets.

Move

Move is a new programming language that implements all the transactions on the Aptos blockchain.
It has two different kinds of code — Move scripts and Move modules.
Move is a safe and secure programming language for web3 that emphasizes access control and scarcity. It is the programming language used to build the Aptos blockchain. You can read more about it in Move on Aptos.

Move Bytecode

Move programs are compiled into Move bytecode.
Move bytecode is used to express Move scripts and Move modules.

Move Module

A Move module defines the rules for updating the global state of the Aptos blockchain.
In the Aptos protocol, a Move module is a smart contract.
Each user-submitted transaction includes a Move script. The Move script invokes procedures of one or more Move modules to update the global state of the blockchain according to the rules.

Move Resources

Move resources contain data that can be accessed according to the * procedures* declared in a Move module.
Move resources can never be copied, reused, or lost. This protects Move programmers from accidentally or intentionally losing track of a resource.

Move Script

Each transaction submitted by a user includes a Move script.
These transactions, also known as Move scripts, represent the operations a client submits to a validator.
The operation could be a request to move coins from user A to user B, or it could involve interactions with published Move modules (smart contracts).
The Move script is an arbitrary program that interacts with resources published in the global storage of the Aptos blockchain by calling the procedures of a module. It encodes the logic for a transaction.
A single Move script can send funds to multiple recipients and invoke procedures from several different modules.
A Move script is not stored in the global state and cannot be invoked by other Move scripts. It is a single-use program.

To see example uses of Move scripts, follow Move scripts.

Move Virtual Machine (MVM)

The Move virtual machine executes Move scripts written in Move bytecode to produce an execution result. This result is used to update the blockchain state.
The virtual machine is part of a validator.
The Move virtual machine (MoveVM) processes each validator node that translates transactions along with the current blockchain ledger state to produce a changeset as input or storage delta as output.

N

Node

A node is a peer entity of the Aptos network that tracks the state of the Aptos blockchain.
An Aptos node consists of logical components. Mempool, consensus, and the Move virtual machine are examples of node components.

Nonce

Nonce is a number only used once, a random or semi-random number that is generated for a specific use for authentication protocols and cryptographic hash functions.

O

Octa

An Octa is the smallest unit of APT. 1 APT = 10⁸ Octas.

Open-Source Community

Open-source community is a term used for a group of developers who work on open-source software. If you’re reading this glossary, then you are part of the Aptos project’s developer community.

P

Proof

A proof is a way to verify the accuracy of data in the blockchain.
Every operation in the Aptos blockchain can be verified cryptographically that it is indeed correct and that data has not been omitted.
For example, if a user queries the information within a particular executed transaction, they will be provided with a cryptographic proof that the data returned to them is correct.

Proof-of-Stake (PoS)

Proof-of-Stake (PoS) is a security mechanism that serves in confirming the uniqueness and legitimacy of blockchain transactions. The PoS consensus mechanism is leveraged by the Aptos blockchain powered by a network of validators, which in turn update the system and process transactions.

R

Randapp

A dapp that uses randomness for its functionality.

Resource Account

A resource account is used to manage resources independent of an account managed by a user. For example, a developer may use a resource account to manage an account for module publishing, say managing a contract.
The contract itself does not require a signer post initialization. A resource account gives you the means for the module to provide a signer to other modules and sign transactions on behalf of the module.

See Resource accounts for instructions on use.

REST API Service

The REST API Service component is the external interface of an Aptos node. Any incoming client request, such as submitted transactions or queries, must first go through the REST Service. A client needs to go through the REST Service component to access storage or any other component in the system. This filters requests and protects the system.
Whenever a client submits a new transaction, the REST Service passes it to mempool.

Round

A round consists of achieving consensus on a block of transactions and their execution results.

Round Number

A round number is a shared counter used to select leaders during an epoch of the consensus protocol.

S

SDKs

Aptos software development kits (SDKs) are sets of tools that enable a developer to quickly create a custom app on the Aptos platform. Find out more at Use the Aptos SDKs.

Sequence Number

The sequence number for an account indicates the number of transactions that have been submitted and committed on chain from that account. It is incremented every time a transaction sent from that account is executed or aborted and stored in the blockchain.
A transaction is executed only if it matches the current sequence number for the sender account. This helps sequence multiple transactions from the same sender and prevents replay attacks.
If the current sequence number of an account A is X, then a transaction T on account A will only be executed if T’s sequence number is X.
These transactions will be held in mempool until they are the next sequence number for that account (or until they expire).
When the transaction is applied, the sequence number of the account will become X+1. The account has a strictly increasing sequence number.

Sender

Alternate name: Sender address.
Sender is the address that originates the transaction. A transaction must be signed by the sender but can have more than one signer.

Shoal

Method for decreasing latency for BFT protocols. See the Shoal paper

Smart Contract

Smart contract refers to a computer program that automatically and directly carries out the contract’s terms.
See Move Module for related details.

State

A state in the Aptos protocol is a snapshot of the distributed database.
A transaction modifies the database and produces a new and updated state.

State Root Hash

State root hash is a Merkle hash over all keys and values the state of the Aptos blockchain at a given version.

T

Table

A table implements the Table type and in Aptos is used to store information as key-value data within an account at large scale.

See table.move for the associated Aptos source file.

Testnet

Testnet describes the Aptos network that is not fully functional yet more stable than devnet; it is an alternative network to mainnet to be used for testing.

Tokens

Tokens are digital units of value issued on a blockchain. They can be redeemed for assets or value held. Tokens can be of the types: Fungible Token (FT), Non-Fungible Token (NFT), and Semi-Fungible Token (SFT).

Transaction

A raw transaction contains the following fields:
A signed transaction is a raw transaction with the digital signature.
An executed transaction changes the state of the Aptos blockchain.

Transaction Script

See Move script

V

Validator

Alternate name: Validators.
A validator is an entity of the Aptos ecosystem that validates on the Aptos blockchain. It receives requests from clients and runs consensus, execution, and storage.
A validator maintains the history of all the transactions on the blockchain.
Internally, a validator needs to keep the current state, to execute transactions, and to calculate the next state.
Aptos validators are in charge of verifying transactions.

Validator Nodes

Validator nodes are a unique class of fullnodes that take part in consensus, specifically a Byzantine Fault Tolerance (BFT) consensus protocol in Aptos. Validators agree upon transactions to be added to the Aptos blockchain as well as the order in which they are added.

Version

A version is a sequentially increasing number that increments for every transaction.
On aptos, transactions are globally ordered and every transaction has a version (often called “height” in blockchain literature.)
Transaction version 0 is the first transaction (genesis transaction), and a transaction version 100 is the 101st transaction in the blockchain.

W

Well-Formed Transaction

An Aptos transaction is well-formed if each of the following conditions are true for the transaction:

The transaction has a valid signature.
An account exists at the sender address.
It includes a public key, and the hash of the public key matches the sender account’s authentication key.
The sequence number of the transaction matches the sender account’s sequence number.
The sender account’s balance is greater than the maximum gas amount.
The expiration time of the transaction has not passed.

Releases