Forem: Daniel

Understanding Objects in Cedra Move: The Complete Beginner's Guide (Part 1/3)

Daniel — Fri, 21 Nov 2025 09:25:12 +0000

If you're new to Cedra (Aptos) Move and Objects confuse you, you're absolutely not alone.
Coming from Solidity, Rust, or any traditional smart-contract model, the Object system in Move can feel like an entirely different universe.

This three-part series breaks everything down step-by-step — what Objects are, why they exist, and how to use them without the confusion. Cedra Move and Aptos Move work the same way, so we’ll use both terms interchangeably.

Let’s jump straight into today’s topic: why Objects exist and what problem they solve.

Why Objects Even Exist

First, I'll attempt to define what an Object is in Move:

Objects are containers that hold your data and live at their own address, separate from your account.

In basic Move, when you create a struct, it must live inside someone's account as a resource:

struct GameItem has key {
    name: vector<u8>,
    power: u64,
}

// this GameItem MUST live in an account
public entry fun create_item(owner: &signer) {
    move_to(owner, GameItem {
        name: b"Sword",
        power: 100,
    });
}

This creates several limitations:

Resources are glued to accounts → hard to transfer ownership
Only one account can own it → no shared ownership
Either you own it or you don’t → no complex permissions
It's hard to compose -> Can't build on top of others' resources
Inflexible Storage -> Stuck in the original account forever

The Solution: Objects
Objects are smart containers that:

Live at their own address (not in user accounts)
Have built-in ownership tracking
Can be transferred like assets
Support complex permission models
Allow modular composition

Where Objects Actually Live

In my opinion, this is the number 1 source of confusion for beginners.

Common Misconception

Objects are stored in the creator's account address

This is FALSE!

The Truth
When you create an Object:

It gets its own unique address in global storage
This address is either deterministic (based on seed) or random
It exists independently in the blockchain
Your account just gets metadata about ownership

What's Actually Stored Where

In the Object's address (0xabc...):

=> ObjectCore - ownership info, transfer rules, GUID
=> Your custom structs/resources
=> Any capabilities (refs) you store there (We'll explore refs better in subsequent parts).

In your account (0x123):

=> Reference/proof that you own it
=> NOT the actual data

Types of Objects

=> Normal Objects (Random Address)

let constructor_ref = object::create_object(owner_address);

Characteristics:

Gets a random address
Fully transferable by default
It is deleteable
Can be modified if you have refs
Most common type

Example use cases:

NFTs
Gaming items
Tradeable assets
Assets that should change owners

Example:

public entry fun mint_nft(creator: &signer) {
    let creator_addr = signer::address_of(creator);

    // create transferable object
    let constructor_ref = object::create_object(creator_addr);
    let object_signer = object::generate_signer(&constructor_ref);

    // add your NFT data
    move_to(&object_signer, NFTData {
        name: b"Cool Dragon",
        image_uri: b"ipfs://Qm...",
        ...
    });
}

=> Named Objects (Deterministic Address)

let constructor_ref = object::create_named_object(
    creator, b"my_unique_seed"
);

Characteristics:

Address is derived from creator_address + seed
Same creator + seed = same address (predictable)
Can only be created once per seed
Not deleteable
Transferable by default

Use cases:

Protocol-level resources (treasury, registry)
Singleton patterns
Global leaderboards
Configuration objects
Resources you need to find without storing the address

Example - Game leaderboard:

    const NAME: vector<u8> = b"global_leaderboard_v1";
    const E_NOT_AUTHORIZED: u64 = 1;

    //the Init Function
    public entry fun init_leaderboard(admin: &signer) {
        let admin_addr = signer::address_of(admin);

        // strictly enforce that only the deployer can call this
        assert!(admin_addr == @my_module, E_NOT_AUTHORIZED);

        // create the object
        let constructor_ref = object::create_named_object(
            admin, NAME
        );

        // generate the signer so we can add resources to this object
        let object_signer = object::generate_signer(&constructor_ref);


        move_to(&object_signer, Leaderboard {
            top_players: vector::empty(),
            season: 1,
        });
    }

    // later, anyone can find it without storing the address
    #[view]
    public fun get_leaderboard(): address {
        let admin_addr = @my_module;
        object::create_object_address(&admin_addr, NAME)
    }

Pro Tips: Use descriptive seeds with versioning

b"treasury_v1"
b"config_mainnet_v2" 
b"player_registry_2024"

=> Sticky Objects (Non transferable)

let constructor_ref = object::create_sticky_object(owner_address);

Characteristics:

PERMANENTLY bound to the owner
Cannot be transferred under ANY circumstances
Owner cannot even transfer it themselves
Perfect for identity/reputation
Not deletable
Has random address

Use cases:

Soulbound tokens (SBTs)
Achievement badges
Certifications/credentials
Identity tokens
Reputation scores
KYC/AML credentials

Example - Achievement system

public entry fun award_achievement(
    player: address,
    achievement_id: u64
) {
    // this achievement is permanently bound to the player
    let constructor_ref = object::create_sticky_object(player);
    let object_signer = object::generate_signer(&constructor_ref);

    move_to(&object_signer, Achievement {
        id: achievement_id,
        name: b"Dragon Slayer",
        earned_at: timestamp::now_seconds(),
    });
}

When NOT to use:

Regular NFTs (use regular objects)
Anything that might need to be traded
Items that should be transferable "just in case"

Quick Decision Tree

Need predictable address?
  └─→ Named Object

Should NEVER transfer?
  └─→ Sticky Object

Everything else (NFTs, items, etc.)?
  └─→ Normal Object

How to Add Data to Objects

public entry fun create_game_item(creator: &signer) {
    // step 1: create the object
    let constructor_ref = object::create_object(
        signer::address_of(creator)
    );

    // step 2: get a signer for the object's address
    let object_signer = object::generate_signer(&constructor_ref);

    // step 3: move your struct INTO the object's address
    move_to(&object_signer, GameItem {
        name: b"legendary Sword",
        attack: 150,
        durability: 100,
    });

    // this is optional
    // Store the object's address for later
    let object_addr = object::address_from_constructor_ref(&constructor_ref);
}

Key points:

You need the object_signer to move resources to the object's address
The object_signer can only be created during object creation (via ConstructorRef)
Your data lives at the object's address, not your account

Accessing Objects Later

Reading Object Data

public fun get_item_stats(object_addr: address): (vector<u8>, u64) 
    acquires GameItem 
{
    let item = borrow_global<GameItem>(object_addr);
    (item.name, item.attack)
}

Modifying Object Data

public entry fun upgrade_item(object_addr: address) 
    acquires GameItem 
{
    // check ownership first
    // ... ownership validation ...

    let item = borrow_global_mut<GameItem>(object_addr);
    item.attack = item.attack + 10;
}

Transferring Ownership

public entry fun transfer_item(
    owner: &signer,
    object_addr: address,
    recipient: address
) {
    // verify owner has permission
    let owner_addr = signer::address_of(owner);
    assert!(object::owner(object_addr) == owner_addr, E_NOT_OWNER);

    // transfer
    object::transfer(owner, object_addr, recipient);
}

What's Next?

Now that you understand what Objects are and where they live, you're ready for the real power: Refs (Capabilities).

In Part 2, we'll cover:

What are Refs and why they matter
Types of Refs explained
How to generate and store Refs
When to use each Ref type

Quick Reference Card

// Normal Object (transferable)
object::create_object(owner_addr)

// Named Object (predictable address)
object::create_named_object(creator, seed)

// Sticky Object (non-transferable)
object::create_sticky_object(owner_addr)

Found this helpful? Drop a like and stay tuned for Part 2 where we explore Refs.

Questions? Drop them in the comments below.

You can also reach me on Twitter now X.

Why Move on Aptos Is Better for Financial Accounts Than Traditional Languages

Daniel — Thu, 07 Aug 2025 14:18:33 +0000

When we think about building a financial application, like a digital bank or a credit system, the core requirements are security, reliability, and integrity. The blockchain, with its decentralized and immutable ledger, offers a powerful foundation for meeting these demands. However, to truly harness this potential, you need a programming language designed specifically for the task.

Come with me

Traditional programming languages like Python or Java are versatile and widely used, but they were not designed from the ground up to handle high-value digital assets in a trustless environment.

At this point, Aptos and its purpose-built programming language, Move, offer a compelling solution. Move was engineered to make it inherently difficult to write insecure code, a necessity for managing high-value digital assets. The fundamental design choices of Move make it a far superior choice for creating digital bank accounts and other financial services on the blockchain.

Objects vs. Resources: A Foundational Difference

The single most important feature that sets Aptos Move apart is its concept of resource-oriented programming. This stands in stark contrast to the object-oriented paradigm common in most programming languages.

In traditional programming, objects and their data can be copied freely, and references can be shared. Memory management is often automatic but can be a source of subtle, error-prone bugs. A variable holding a value—say, a number representing a bank balance—can be duplicated or accidentally overwritten, which can be a catastrophic vulnerability in a financial system where every asset must have a unique, single owner.

In Move programming, digital assets are treated as resources with unique ownership. The language and its compiler enforce strict rules:

A resource cannot be copied or accidentally dropped.
An explicit transfer of ownership is required for every asset movement.
This design fundamentally prevents double-spending by design at the language level.

Move treats digital assets like a physical coin that can only be in one place at a time. This design forces developers to handle every asset with care, eliminating an entire class of security bugs that could lead to financial loss.

Formal Verification: Mathematical Proof for Security

For high-stakes applications like banking, simply trying to write secure code isn't enough. You need proof. And it's well known that when precision is non-negotiable, Move’s formal verification comes to the rescue.

The Move ecosystem includes a powerful tool called the Move Prover. This tool can analyze the bytecode of a smart contract and mathematically prove that it meets certain security properties. For example, you can write a specification that proves a function for transferring funds will always result in the sender's balance decreasing by the exact amount transferred and the receiver's balance increasing by the same amount, without any overflow or underflow issues.

This level of rigor is extremely difficult and costly to achieve in traditional languages, which rely heavily on extensive manual audits and unit tests. With Move, you can have a much higher degree of confidence that your financial logic is not only correct but also mathematically proven to be so.

Security by Design: Preventing Common Vulnerabilities

Beyond its core concepts, Move has been designed to prevent many other common vulnerabilities that plague smart contracts.

Type Safety: The language is statically typed, which means it catches data type errors at compile time, long before they can cause a bug in production.
No Dynamic Dispatch: Functions are linked at compile time, eliminating a key vulnerability vector known as reentrancy attacks, where a malicious contract can make a recursive call to drain funds.
Integer Overflow Prevention: Move’s arithmetic operations are designed to check for overflow and underflow, preventing a common source of exploits where a balance can be manipulated to an unexpected value.

By building these protections directly into the language, Move significantly lowers the risk and complexity of creating secure financial applications compared to traditional languages, which often require developers to use third-party libraries and manually implement security best practices.

The Verdict: A Language Built for Trust

Traditional languages are general-purpose tools, but a bank account is not a general-purpose application. It is a system built on trust and a single, unshakeable ledger. The blockchain provides this ledger, but Move is the language that ensures the logic written on that ledger is sound. Its focus on asset management, formal verification, and security by design makes it an ideal foundation for a new generation of reliable and secure financial applications.

I am eager to know what your thoughts are on this. Also, don't hesitate to reach out to me on Twitter if you have any questions.

Understanding Blockspace in Blockchains

Daniel — Sat, 26 Jul 2025 11:11:26 +0000

Blockspace refers to the finite capacity within a blockchain block that is available for storing transactions and other data. See a blockchain like a digital ledger (it's more than this anyway), and each "block" as a page in that ledger. Blockspace is essentially how much "writing room" is available on each page.

This space is a critical resource because,

Limited Supply: Every blockchain has a maximum block size (measured in bytes or gas units) that dictates how much data can fit into a single block. This limit is set by the protocol to manage network load, prevent spam, and ensure decentralization (as larger blocks are harder for nodes to process and store).
High Demand: As blockchain networks gain adoption, there's increasing demand from users and applications to include their transactions in the next available block.
Auction Market: Because blockspace is limited and in high demand, it often becomes an auction market. Users bid with transaction fees (gas) to get their transactions included, especially during periods of high network congestion. This is why gas fees can spike dramatically on busy chains.
Impact on Throughput: The amount of blockspace directly influences a blockchain's maximum throughput (Transactions Per Second, or TPS). More blockspace (or more efficiently used blockspace) generally allows for more transactions to be processed within a given timeframe.

In essence, blockspace is the fundamental economic resource of a blockchain. It's what users are competing for when they send transactions.

Blockspace on Aptos

Aptos approaches blockspace with a focus on maximizing its utilization and ensuring efficient processing to deliver high throughput and low fees. While every blockchain has finite blockspace, Aptos' innovations are designed to make the most of it.

The following make aptos standout:

Dynamic Block Content: Unlike some chains with very rigid block structures, Aptos' blocks can dynamically contain varying numbers of transactions depending on network activity, up to a configurable maximum size.
Efficient Utilization via Block-STM: This makes Aptos excel way more than other chains. Its Block-STM execution engine allows transactions within a block to be processed in parallel. Instead of executing transactions one by one, Block-STM identifies non-conflicting transactions and runs them simultaneously. This means that Aptos can process a much larger volume of transactions within its available blockspace in a given blocktime compared to a sequential execution model. This can be likened to having multiple scribes writing on the same page at once, without stepping on each other's toes.
Quorum Store's Role: As we discussed, Quorum Store ensures that raw transaction data is disseminated efficiently and in parallel before consensus. This means that when a block is proposed, it contains lightweight Proofs of Availability (PoAvs) instead of the bulky raw transactions. This makes the block itself smaller and faster to transmit through the consensus process. It allows more "logical" transactions to be ordered per unit of time, effectively maximizing the utility of the blockspace for ordering.
Low Transaction Costs: By maximizing the number of transactions that can be processed per block (high throughput) and optimizing the underlying architecture, Aptos continues to keep transaction fees low, making its blockspace affordable and accessible for a wider range of applications and users. This is demand and supply in action as Aptos' architecture readily makes blockspace available for use.
Future Scalability (Sharding): While Aptos already achieves high performance on a single ledger state, its modular design and parallel execution capabilities lay the groundwork for future horizontal scaling solutions like sharding. Sharding would effectively create multiple "blockspaces" (or shards) that can process transactions in parallel, further expanding the network's total capacity.

It's safe to conclude that blockspace is the lifeblood of any blockchain, the fundamental resource users compete for. While its scarcity often leads to high fees and congestion on other networks, Aptos has engineered a different path.

Don't hesitate to reach out to me on Twitter if you have any questions.

How Aptos' Quorum Store Unlocks True Scalability

Daniel — Fri, 18 Jul 2025 22:36:16 +0000

Aptos has quickly made a name for itself with its impressive transaction throughput and sub-second finality. But how does it achieve such performance, especially when many blockchains struggle with scalability? One of the core innovations behind this is Quorum Store, a sophisticated mempool protocol that fundamentally transforms how transaction data is handled before it even reaches consensus.

At its heart, Quorum Store is all about decoupling data dissemination from the consensus process, effectively removing a major bottleneck in traditional blockchain architectures.

The Bottleneck Problem: A Single Point of Failure

In many classic leader-based Byzantine Fault Tolerant (BFT) consensus protocols, the process often looks like this:

A leader validator is chosen for a specific round.

This leader is responsible for gathering a block of transactions from its mempool.

Crucially, the leader then broadcasts the entire block of raw transaction data to all other validators in the network.

Only after receiving and validating this full block do other validators cast their votes.

The problem here is glaring; the leader's network bandwidth and processing power become the single bottleneck for the entire network's throughput.

If the leader can only send X transactions per second, the whole chain is limited to X, regardless of how powerful the other validators are. It's like having a single mail carrier trying to deliver every single newspaper (full transaction data) to every house (validator) in the city. This centralized data delivery limits overall system performance.

Quorum Store: Decentralized Data Delivery

Quorum Store is a production-optimized implementation of the "Narwhal" design, introducing a parallel, decentralized approach to transaction data dissemination. It creates an intermediate layer between the mempool and the consensus protocol (AptosBFT), ensuring that raw transaction data is widely available before the consensus leader even needs to propose a block.

We will see how it works in three phases

Phase 1: Decentralized Data Dissemination (The "Full Newspaper" Delivery)

This is the most critical shift. Instead of waiting for a leader,

All validators are active participants. Each validator's Quorum Store component continuously pulls batches of raw transactions from its local mempool (its queue of transactions received from users).
These batches of complete, raw transaction data are then broadcasted in parallel from each validator to all other validators in the network.
It's like every newsstand (validator) in the city constantly printing its own batches of full newspapers (raw transactions) and sharing them directly with every other newsstand. This happens concurrently across the entire validator set.

This parallel, all-to-all dissemination ensures that the heavy lifting of moving transaction data around is distributed, eliminating the single-leader bottleneck.

Phase 2: Proof of Availability (PoAv) Generation

Once a validator has successfully received and stored a batch of raw transactions (whether it originated the batch or received it from another validator),

It cryptographically signs the metadata (a small identifier/hash) of that batch. This signature acts as an attestation that the validator has seen and stored that specific batch.
The validator that originated the batch (or is tracking its dissemination) then collects these signatures.
When it gathers signatures from a quorum (2f+1, where 'f' is the number of Byzantine/faulty validators) of other validators, it can construct a Proof of Availability (PoAv) for that batch.

What does a PoAv look like? It's a lightweight cryptographic certificate. It typically includes:

A cryptographic hash of the entire batch of raw transactions (a small, fixed-size fingerprint).

A collection of aggregated or compressed signatures from the quorum of validators who attested to receiving the batch.

(Optionally) Metadata like an expiration time for the proof.

Crucially, a PoAv does NOT contain the raw transaction data itself. It's just a small, verifiable proof that the data exists and is widely available.

Phase 3: Lightweight Consensus (Ordering the "Table of Contents")

With transaction data already disseminated and proven available via PoAvs, the consensus leader's role becomes much more efficient:

When it's a validator's turn to be the consensus leader (as determined by AptosBFT), it looks at the pool of available PoAvs that have been successfully generated by the network.
The leader then proposes a block that contains only these small PoAvs (metadata), along with other essential block information (like the previous block's hash and round number). It does not need to include or re-send the large raw transaction data.
The consensus protocol then focuses solely on ordering these lightweight PoAvs. This makes block proposals much smaller and faster to transmit and verify, reducing consensus latency.

Once a block (containing ordered PoAvs) is committed by the consensus, the execution engine (Block-STM) can then use these PoAvs to retrieve the actual transaction data (which validators likely already have from Phase 1) for parallel execution.

Key Benefits of Aptos' Quorum Store

The integration of Quorum Store provides several advantages for the Aptos blockchain. They include:

Throughput Increase: By offloading the heavy data dissemination task from the leader and distributing it, Quorum Store directly tackles the primary bottleneck, enabling significantly higher Transactions Per Second (TPS).
Horizontal Scalability: The system can scale horizontally. As network load increases, more validators can contribute to the parallel data dissemination, improving overall capacity.
Lower Latency: Transactions become available to validators much faster, contributing to the sub-second finality that Aptos is known for.
Efficient Resource Utilization: All validators are actively engaged in the data pipeline. This leads to a more balanced and efficient use of network resources compared to leader-centric models.
Enhanced Reliability and Data Availability: The Proof of Availability mechanism ensures that once a batch is included in a block, the underlying transaction data is guaranteed to be available across a supermajority of the network, even if some nodes go offline.
Modular and Pipelined Architecture: Quorum Store fits perfectly into Aptos' modular design. It allows different components (mempool, data dissemination, consensus, execution, storage) to operate concurrently and be optimized independently.

Aptos' Quorum Store isn't just a mempool; it's a fundamental architectural innovation which, by far, optimizes how blockchain networks can achieve high performance and scalability.

By intelligently decoupling data dissemination from consensus, Aptos ensures that transaction data flows efficiently and reliably.

Understanding Quorum Store is key to appreciating why Aptos is positioned as a leading blockchain for mainstream Web3 adoption.

Don't hesitate to reach out to me on Twitter if you have any questions.

Your Digital Identity on Aptos: Accounts, Addresses, and Wallets Explained

Daniel — Fri, 11 Jul 2025 04:45:10 +0000

Understanding how your identity and assets are managed on the blockchain is crucial to decentralized finance and web3 generally. On Aptos, this involves a sophisticated interplay between accounts, addresses, and the wallets you use every day. Let's break down these fundamental concepts.

Aptos Accounts: Not Just a Balance

Unlike some older blockchain models where an account might simply represent a numerical balance, an Aptos account is a robust, on-chain container. It can be likened to a personal, smart digital vault on the blockchain.

Every Aptos account is designed to hold:

Resources: These are your actual digital assets, such as APT tokens, NFTs, stablecoins, or any other programmable digital item. Aptos uses the Move programming language's strict resource model, which ensures these assets are "first-class citizens." This means they can only be explicitly moved or destroyed, making them secure against accidental duplication or loss.
Modules: These are the Move smart contract code that dictates the rules for how resources are managed within that account, or how external interactions with it can occur. An account can publish and own its own custom modules, allowing for unique on-chain logic and behaviors.

This "account as a smart container" is what provides developers and users with greater flexibility and security directly at the account level.

Addresses: Your Permanent Public Identifier

Every Aptos account is assigned a unique 32-byte (256-bit) hexadecimal address, typically displayed with a 0x prefix. This address serves as your public identifier on the Aptos blockchain. It's the digital equivalent of your mailing address. You share it with others to receive tokens, NFTs, or for them to interact with your published smart contracts.

A key distinction on Aptos is that an account, as an on-chain container, must be explicitly created before it can transact or hold resources. This creation process often happens seamlessly when you receive your first APT tokens or when your wallet initializes your presence on the chain. In other words, your account creation on Aptos is only complete when you send APT token into it.

Authentication Keys: The Power of Key Rotation

Aptos stands out when it comes to security and user experience. That's because the core of every Aptos account's control lies with its authentication key.

When you initially set up an Aptos account, an authentication key is derived from your public key (which, in turn, is generated from your secret private key). This initial authentication key is also your account's address.
Key Rotation. Aptos uniquely allows you to rotate your authentication key. This means you can change the underlying private key that controls your account without changing your public Aptos address.
- This sets a new standard for blockchain account management: If you ever suspect your private key has been compromised (e.g., through a phishing attempt or malware), you can generate a brand new, secure private key and perform a key rotation on your Aptos account. Your existing address, all your assets, NFTs, and entire transaction history remain intact at the same address, but control is instantly transferred to your new, secure private key. This is a great leap in cryptographic security, similar to changing a password for a critical online service, but with the immutable guarantees of the blockchain.

Wallets: Your Access to Aptos

A wallet (such as Petra, Pontem, or others) is the essential software application that serves as your primary interface to the Aptos blockchain.

Wallets perform several critical functions:

Secure Key Management: Wallets securely store your private keys (or facilitate connections to hardware wallets for offline key storage). Private keys are fundamental for signing transactions.
Address Management: They display your Aptos addresses and allow you to manage multiple accounts from a single interface.
Transaction Creation and Signing: Wallets simplify the process of creating transactions (e.g., sending APT, interacting with decentralized applications). They present the transaction details for your review and then use your private key to generate a unique digital signature.
Balance and History Tracking: By connecting to the Aptos network, your wallet provides a real-time view of your asset balances and a comprehensive history of your transactions.
DApp Interaction: Wallets enable a secure and seamless connection to decentralized applications (dApps), allowing you to interact with smart contracts and services on Aptos without ever exposing your sensitive private keys.

How It All Comes Together: A Seamless Flow

Key Generation: Your wallet helps you generate a secure private key (often derived from a mnemonic seed phrase).
Address Derivation: From your private key, a public key is derived, which then forms your authentication key, and ultimately your unique Aptos address.
Transaction Authorization: When you decide to perform an action on the blockchain, your wallet constructs the transaction details.
Digital Signature: Your wallet uses your private key to create a cryptographic signature for that specific transaction. This signature proves that you authorized the action.
Broadcast to Network: The signed transaction is then broadcast to the Aptos validators.
Verification and Execution: Aptos validators use the authentication key (derived from your public key) associated with your address to verify the signature's authenticity. If valid, the transaction is executed, updating your account's resources or interacting with its modules, and the changes are permanently recorded on the blockchain.
Adaptive Control: Should the need arise, the authentication key can be rotated, seamlessly linking your existing address to a new private key.

This sophisticated account model, coupled with the inherent safety guarantees of the Move language, means Aptos is built from the ground up for robust security, user control, and a superior digital experience.

Thanks for reading. If anything's unclear or you have more questions, please ask in the comments or reach out directly on Twitter.

Beyond Speed: How Aptos Achieves Ultra-Low Gas Costs at Scale

Daniel — Sun, 29 Jun 2025 11:12:48 +0000

Aptos is engineered from the ground up to keep gas fees low, even as the network scales. It's not just one solution, but a combination of several technical innovations that contribute to its cost efficiency. Why are transactions fees so low on aptos? Let's get straight to the point...

High Throughput and Parallel Execution (Block-STM):
- The Core Principle: When a blockchain can process a massive number of transactions per second (high throughput theoretically at 160k per sec), the demand for block space is spread across a much larger capacity. This naturally drives down the price per unit of that space.
- Aptos' Advantage: Aptos' block-stm engine allows for parallel transaction execution. Unlike older blockchains where transactions are processed one by one (like a single-lane road), Block-STM executes many transactions concurrently. This means the network can handle significantly more transactions without getting congested.    
- Impact on Gas: Less congestion means less competition for transaction inclusion. When there's ample capacity, users don't need to bid extremely high gas prices to get their transactions processed quickly, leading to consistently low base fees.
Efficient Resource Accounting (Move Language):
- The Problem: Some older blockchain environments can be inefficient in how they measure and charge for computational resources (cpu, memory, storage). This can lead to overcharging or under-optimization.
- Aptos' Advantage: The move programming language, designed with resources as first-class citizens, allows for very precise and fine-grained accounting of the actual computational and storage resources consumed by a transaction.  
- Impact on Gas: Because the network can accurately measure the exact gas units used for instructions, i/o, and storage, transactions are only charged for what they truly consume. This granular control, combined with optimization principles baked into Move, helps developers write more gas-efficient smart contracts.   
Storage Fees and Refunds:
- The Problem: Storing data on a blockchain is a long-term cost for the entire network. Some chains charge high, non-refundable fees for storage, even if the data is later deleted.
- Aptos' Advantage: Aptos separates "transient" computation/execution costs from "persistent" storage costs. While you pay a fee for allocating new storage slots, Aptos has a mechanism to refund a portion (currently the entirety) of the storage fee when data is deleted from the blockchain.  
- Impact on Gas: This incentivizes efficient data management. Developers and users are encouraged to clean up unnecessary state, which keeps the overall state of the blockchain lean, reduces validator costs for storing data, and ultimately keeps transaction costs lower by not penalizing temporary storage. Even though gas is burned and minted for refunds, the net effect encourages efficient storage use.  
Dynamic Gas Fee Model (Adaptive Pricing):
- The Principle: Like many modern blockchains, Aptos employs a dynamic gas fee model that adjusts based on network demand.  
- Aptos' Implementation: While there's a minimum gas unit price set by governance, the actual gas price per unit can fluctuate. When the network is less busy, the gas unit price can drop very low. The system also prioritizes transactions with higher gas unit prices if needed (e.g., during periods of high demand), but it's designed to keep the base cost low during normal operations.
- Impact on Gas: This allows transaction costs to remain affordable during periods of low to moderate activity, preventing consistently high fixed costs.
Efficient State Synchronization:
- The Problem: Keeping all nodes synchronized with the latest state changes can be a resource-intensive process, impacting network efficiency and indirectly gas costs. 
- Aptos' Advantage: Aptos uses advanced state synchronization techniques that allow nodes to keep updated rapidly and efficiently. This reduces the overhead for validators and the overall network.  
- Impact on Gas: A more efficient and less resource-intensive network infrastructure means validators can operate at lower costs, which translates into lower operational costs passed on to users in the form of gas fees.

Conclusively, Aptos achieves cheap gas fees by combining massive parallel processing (Block-STM) to handle high transaction volumes, precise resource accounting with Move to only charge what's truly consumed, smart storage refund mechanisms to encourage efficiency, and a dynamic fee model that scales with network load, all built upon an optimized, modular architecture. This collective approach ensures that the network can sustain low transaction costs even as it grows to accommodate billions of users and complex applications.

Thank you for coming this far. Need any clarifications, don't hesitate to ask in comments or reach out to me on Twitter.

Resources:

Aptos docs on gas and storage fees:
https://aptos.dev/en/network/blockchain/gas-txn-fee
Aptos docs on execution and block-stm: https://aptos.dev/en/network/blockchain/execution
Aptos docs on state synchronization (consensus observer): https://aptos.dev/en/network/nodes/configure/state-sync
Medium article by aptos labs:
the path to 10x lower gas fees on aptos with community-driven feedback
General documentation on the move programming language and its resource model.

Fortifying Your Aptos Assets: A Practical Guide to Key Account Rotation

Daniel — Tue, 17 Jun 2025 10:18:19 +0000

While blockchain technology offers transparency and immutability, the security of your funds ultimately rests on the strength and management of your private keys. One of the most critical, yet often overlooked, security practices is key rotation.

What is Key Rotation and Why is it Crucial?
At its core, key rotation involves periodically replacing an existing cryptographic key with a new one. In the context of blockchain accounts, this means changing the key that authorizes transactions for your address. Why is this a security imperative?

Mitigating Compromised Keys: Even with the best security practices, keys can be compromised through phishing attacks, malware, insider threats, or accidental exposure. Regular rotation limits the damage a compromised key can inflict, as its validity period is inherently shortened.
Preventing Long-Term Exposure: The longer a key is active, the greater the window of opportunity for attackers to find vulnerabilities or brute-force their way in (though highly improbable for strong keys, it's a risk).
Enhancing Insider Threat Protection: For organizations or teams managing shared accounts, key rotation ensures that if an insider's access is revoked, their old keys are no longer valid.

Aptos offers a significant advantage in this regard. Unlike some other blockchains where your address is inextricably linked to your initial public key, Aptos decouples the authentication key from the account address. This native support for key rotation without changing your permanent Aptos address is a powerful security feature, making it a critical aspect of Aptos account security.

This guide is designed as a practical resource for developers, DApp operators, institutional users, and advanced individual users seeking to fortify their Aptos assets. I'll walk you through the practical steps, CLI commands, and essential security considerations for seamless and secure key rotation.

Account Address: This is the permanent, 32-byte identifier for your Aptos account (e.g., 0x123...abc). It's derived from the initial authentication key when the account is created. Crucially, your account address remains constant even if you rotate your authentication key. This provides stability and avoids the need to update your address across various platforms after a key change.
Authentication Key: This is the cryptographic key responsible for authorizing transactions originating from your account address. It's a 32-byte hash that can be rotated. When you sign a transaction, it's this key (or more accurately, the private key associated with it) that provides the digital signature.
Public Key & Private Key: Behind every authentication key is a public-private key pair. The private key is the secret credential you use to sign transactions, while the public key is mathematically derived from the private key and is used to verify signatures. Your authentication key is a hash of your initial public key.

The Aptos account model facilitates the unique ability to rotate an account’s private key. Since an account’s address is the initial authentication key, the ability to sign for an account can be transferred to another private key without changing its public address.

How Aptos Enables Key Rotation (Native Support)

A key differentiator for Aptos is its built-in support for key rotation. The blockchain's architecture allows you to change the underlying authentication key without altering your account address. This is achieved through specific Move functions and CLI commands, notably involving the account::set_originating_address function which facilitates the secure transition.

Pre-Rotation Checklist: Preparing for a Smooth Transition

A successful key rotation is not just about executing commands; it's about meticulous preparation. A well-planned approach prevents potential loss of access to your secure Aptos assets.

A. Identify and Document All Key Usages:

This is the most critical step. Create an exhaustive list of every place your current Aptos key is used. Think broadly:

Decentralized Applications (DApps): Are you staking, providing liquidity, or interacting with any DApps using this key?
Scripts and Automations: Do you have any automated scripts (e.g., for node operations, data collection, or wallet interactions) that rely on this key?
Integrations: Is your key integrated with any third-party services or platforms?
Staking and Validator Operations: If you are running an Aptos validator, your consensus key is paramount.
Wallets: Which wallets (software, hardware) currently hold or derive this key?

Map out dependencies to ensure you update credentials everywhere, preventing service disruption.

B. Backup Existing Keys Securely:

Before making any changes, ensure you have multiple, secure backups of your current private key and seed phrase.

Offline Storage: Hardware wallets, encrypted USB drives, or air-gapped computers are ideal.
Redundancy: Store backups in physically separate, secure locations.
Seed Phrase Management: Understand that your seed phrase is the ultimate backup for keys derived from it. Treat it with the utmost care, never storing it digitally or sharing it.

C. Ensure Sufficient APT for Gas Fees:

Key rotation is an on-chain transaction and, like all transactions, incurs gas fees. Confirm your account has enough APT tokens to cover these costs before initiating the process.

D. Choose Your New Key Management Strategy:

Decide how you will manage your new key. This decision significantly impacts your ongoing security posture.

Hardware Wallet Integration: For the highest level of security, especially for mainnet operations and significant funds, a hardware wallet (like Ledger) is strongly recommended. The private key never leaves the device.
Multi-Signature (Multisig) Accounts: For shared treasuries, organizational funds, or enhanced personal security, consider moving to an Aptos multisig account. This requires multiple approvals for transactions, significantly reducing the risk of single-point-of-failure compromise.
Dedicated Hot Wallets: For specific operational needs requiring frequent transactions, a "hot" wallet (online software wallet) might be used, but with extreme caution and limited funds. Implement strict access controls and regular auditing.

Practical Steps for Aptos Key Account Rotation

I presume you're using a Unix-like system.

Now, let's get hands-on with the Aptos CLI to perform the key rotation.

First step is to set up a local network. Run the following command on your terminal.

Setting up a local network is having a local Aptos blockchain network on your machine, suitable for development and testing.

aptos node run-localnet

You will see some key outputs like the following:

Readiness endpoint: http://127.0.0.1:8070/

Completed generating configuration:

.........more info

Aptos is running, press ctrl-c to exit

Faucet is starting, please wait...
Node API is starting, please wait...
Transaction stream is starting, please wait...

.......more into

Applying post startup steps...

Setup is complete, you can now use the localnet!

However, to have this process running in background, use the following command:

mkdir -p localnet-data
aptos node run-localnet \
    --assume-yes \
    --test-dir localnet-data \
    --force-restart \
    > localnet.log 2>&1 & 
export LOCALNET_PID=$!

To terminate it, use

kill $LOCALNET_PID

Next, generate a private key

Create a private key corresponding to an authentication key, and thus initial account address, that starts with the vanity prefix 0xdae.

aptos key generate \
    --assume-yes \
    --output-file private-key-a \
    --vanity-prefix 0xdae

output

{
  "Result": {
    "PublicKey Path": "private-key-a.pub",
    "Account Address:": "0xdaeb4e5126ce109437a8a5159b4d8821ec5db0d904097da88a68ed9231c7a8f5",
    "PrivateKey Path": "private-key-a"
  }
}

Note that the prefix for your vanity prefix must consist of valid hexadecimal characters (0-9, a-f, A-F), else my vanity prefix would have been dan.

Two files containing the private key and public keys are generated simultaneously:

private-key-a
private-key-a.pub

Use the command ls to see them on your terminal.

Next, we're initializing a profile

We will use the generated private key to initialize test-profile-1 on the localnet. Here's the command:

aptos init \
    --assume-yes \
    --network local \
    --private-key-file private-key-a \
    --profile test-profile-1

Terminal Output

Configuring for profile test-profile-1
Configuring for network Local
Using command line argument for private key
Account 0xdaeb4e5126ce109437a8a5159b4d8821ec5db0d904097da88a68ed9231c7a8f5 has been already found onchain

---
Aptos CLI is now set up for account 0xdaeb4e5126ce109437a8a5159b4d8821ec5db0d904097da88a68ed9231c7a8f5 as profile test-profile-1!
---

See the account here: https://explorer.aptoslabs.com/account/0xdaeb4e5126ce109437a8a5159b4d8821ec5db0d904097da88a68ed9231c7a8f5?network=local
{
  "Result": "Success"
}

Note: The command was meant to fund the account with test APT but doesn't. So you can do that with this command aptos account fund-with-faucet --profile test-profile-1 --amount octas. Replace octas with the exact octa value you want. e.g 100000000 for 1 test APT

You can view the just initialized profile with the following command:

aptos config show-profiles --profile test-profile-1

Example Output

Note that the above output doesn't contain my private key. To output the private key, I'll have to use the following command:

aptos config show-private-key --profile test-profile-1

Next, let's look up our address using the command:

aptos account lookup-address \
    --public-key-file private-key-a.pub \
    --url http://localhost:8080

Store address in a shell variable

ADDRESS_A=dae...

ADDRESS_A=dae... The dae... notation is just a way for documentation or explanations to represent "an Aptos address goes here" without showing a very long, specific address that would vary for each user.

Here's the command to store the address:

export ADDRESS_A=$(
    aptos account lookup-address \
        --public-key-file private-key-a.pub \
        --url http://localhost:8080 \
            | jq -r '.Result'
)
echo $ADDRESS_A

Next, we look up the authentication key, which is identical to the account address when first created.

Here's the command for checking the authentication key:

aptos move view \
    --args address:$ADDRESS_A \
    --function-id 0x1::account::get_authentication_key \
    --url http://localhost:8080

Output

{
  "Result": [
    "0xdaeb4e5126ce109437a8a5159b4d8821ec5db0d904097da88a68ed9231c7a8f5"
  ]
}

Store the authentication key in a shell variable

AUTH_KEY_A=$ADDRESS_A

Note, however, since the account has not yet had its authentication key rotated, there is no corresponding entry in the account::OriginatingAddress table:

aptos move view \
    --args address:$AUTH_KEY_A \
    --function-id 0x1::account::originating_address \
    --url http://localhost:8080

So, you'll get an empty vector as shown below:

{
  "Result": [
    {
      "vec": []
    }
  ]
}

Next, set originating address

To ensure an entry in the account::OriginatingAddress table for this new account, run account::set_originating_address:

You need gas for this. Ensure you have some testAPT.

aptos move run \
    --assume-yes \
    --function-id 0x1::account::set_originating_address \
    --profile test-profile-1

Result should like this:

Transaction submitted: https://explorer.aptoslabs.com/txn/0xbf0eac2f8a0818b9af14a5028b4116d6bff387771b5c916ab76b71573c567854?network=local
{
  "Result": {
    "transaction_hash": "0xbf0eac2f8a0818b9af14a5028b4116d6bff387771b5c916ab76b71573c567854",
    "gas_used": 444,
    "gas_unit_price": 100,
    "sender": "daeb4e5126ce109437a8a5159b4d8821ec5db0d904097da88a68ed9231c7a8f5",
    "sequence_number": 0,
    "success": true,
    "timestamp_us": 1750150021132281,
    "version": 16439,
    "vm_status": "Executed successfully"
  }
}

Now run the account::OriginatingAddress function again. You'd see an entry now, no longer an empty vector. Let's do it:

aptos move view \
    --args address:$AUTH_KEY_A \
    --function-id 0x1::account::originating_address \
    --url http://localhost:8080

Output will be:

{
  "Result": [
    {
      "vec": [
        "0xdaeb4e5126ce109437a8a5159b4d8821ec5db0d904097da88a68ed9231c7a8f5"
      ]
    }
  ]
}

Next, rotate authentication Key

First, generate a new private key

aptos key generate \
    --assume-yes \
    --output-file private-key-b \
    --vanity-prefix 0xbbb

Result here

{
  "Result": {
    "Account Address:": "0xbbb6e2c504a6faac5f6d61286cf90ce69bc86265edd27d709fd65223fe00fb6",
    "PrivateKey Path": "private-key-b",
    "PublicKey Path": "private-key-b.pub"
  }
}

Now, rotate the authentication key of the existing onchain account to the new private key:

aptos account rotate-key \
    --assume-yes \
    --new-private-key-file private-key-b \
    --profile test-profile-1 \
    --save-to-profile test-profile-2

Output

{
  "Result": {
    "message": "Saved new profile test-profile-2",
    "transaction": {
      "transaction_hash": "0x274e528b08381e39367bfb9c0820945fefb9e4015cbf7cc136656bf7791adda1",
      "gas_used": 449,
      "gas_unit_price": 100,
      "sender": "daeb4e5126ce109437a8a5159b4d8821ec5db0d904097da88a68ed9231c7a8f5",
      "sequence_number": 1,
      "success": true,
      "timestamp_us": 1750150549220890,
      "version": 17458,
      "vm_status": "Executed successfully"
    }
  }
}

Next, we'll compare both profiles using the following command:

aptos config show-profiles --profile test-profile-1
aptos config show-profiles --profile test-profile-2

Result

{
  "Result": {
    "test-profile-1": {
      "network": "Local",
      "has_private_key": true,
      "public_key": "ed25519-pub-0xf43cd7cd787c061c2864784e9cc62ded86310fe450ffd52e91c436ba12c18a22",
      "account": "daeb4e5126ce109437a8a5159b4d8821ec5db0d904097da88a68ed9231c7a8f5",
      "rest_url": "http://localhost:8080",
      "faucet_url": "http://localhost:8081"
    }
  }
}
{
  "Result": {
    "test-profile-2": {
      "network": "Local",
      "has_private_key": true,
      "public_key": "ed25519-pub-0xe0501701ee022c2a1a3a665957ab4c5a668970ca5ba86caffb0638482d6b6ffe",
      "account": "daeb4e5126ce109437a8a5159b4d8821ec5db0d904097da88a68ed9231c7a8f5",
      "rest_url": "http://localhost:8080",
      "faucet_url": "http://localhost:8081"
    }
  }
}

Now lookup the authentication key:

aptos move view \
    --args address:$ADDRESS_A \
    --function-id 0x1::account::get_authentication_key \
    --url http://localhost:8080

Output:

{
  "Result": [
    "0x0bbb6e2c504a6faac5f6d61286cf90ce69bc86265edd27d709fd65223fe00fb6"
  ]
}

Store the authentication key in a shell variable

AUTH_KEY_B=bbb...

export AUTH_KEY_B=$(
    aptos move view \
        --args address:$ADDRESS_A \
        --function-id 0x1::account::get_authentication_key \
        --url http://localhost:8080 \
        | jq -r '.Result[0]'
)
echo $AUTH_KEY_B

Next, look up originating address:

aptos move view \
    --args address:$AUTH_KEY_B \
    --function-id 0x1::account::originating_address \
    --url http://localhost:8080

Result:

{
  "Result": [
    {
      "vec": [
        "0xdaeb4e5126ce109437a8a5159b4d8821ec5db0d904097da88a68ed9231c7a8f5"
      ]
    }
  ]
}

Now, check the originating address for the old authentication key, you'll find out it's now empty. Use the command:

aptos move view \
    --args address:$AUTH_KEY_A \
    --function-id 0x1::account::originating_address \
    --url http://localhost:8080

The result should look like this:

{
  "Result": [
    {
      "vec": []
    }
  ]
}

The initial authentication key is gone!

Finally, let's clean up

Delete the test profiles we setup.

aptos config delete-profile --profile test-profile-1
aptos config delete-profile --profile test-profile-2

You will see something like this:

{
  "Result": "Deleted profile test-profile-1"
}
{
  "Result": "Deleted profile test-profile-2"
}

Then, stop the local network and delete the private and public key files.

rm private-key-*
kill $LOCALNET_PID
rm -fr localnet-data
rm -fr localnet.log

That's it!

You've now successfully navigated the intricate yet vital process of Aptos key account rotation.

Aptos' unique account model, which decouples the authentication key from the account address, allows you to implement this critical security practice without disrupting your on-chain identity. This guide walked you through the practical steps, from setting up your local environment and generating new keys to updating your on-chain authentication and verifying the changes.

As the Aptos blockchain continues to grow and evolve, so too will its security features and the best practices surrounding them.

Don't hesitate to reach out to me on Twitter

Build Smarter with Aptos Move Objects: A Hands-on Tutorial for DApp Development. (Part 1)

Daniel — Wed, 04 Jun 2025 06:23:59 +0000

In our previous article, we explored Move’s struct abilities (key, store, copy, drop), the foundation of secure smart contract development. Now, let’s level up and unlock Aptos Objects, the framework that powers everything from NFTs to fungible tokens.

This tutorial takes it even further by going deep into one of the most powerful concepts in Aptos Move: Objects. Move Objects provide a flexible and secure way to manage on-chain data, enabling developers to build more sophisticated and composable DApps. Whether you're looking to create advanced NFTs, manage complex game assets, or build intricate DeFi protocols, understanding Move Objects is crucial.

Composable DApps: DApps and protocols that can interact with each other seamlessly, much like Lego bricks. If data is structured as well-defined Objects with clear interfaces, one DApp can easily read from or write to another DApp's objects (with proper authorization), leading to a highly interconnected and innovative ecosystem. For instance, an NFT created in one DApp could be used as collateral in a lending protocol built by another team, precisely because it's a well-understood "Object."

By the end of this hands-on guide, you will have a comprehensive understanding of what Move Objects are, how they function, and how to apply them in your DApp development. We'll explore their core capabilities, walk through practical code examples, and discuss best practices to help you build smarter and more securely on Aptos.

Let's begin.

Understanding Move Objects
At its heart, Move is a "resource-oriented" programming language. Unlike traditional object-oriented languages where objects are merely data structures, in Move, resources are first-class citizens that cannot be copied or implicitly discarded; they can only be moved. This fundamental principle is extended and enhanced by Move Objects.

What are Move Objects?
In Aptos Move, an Object is a special kind of resource that acts as a container for other resources. It's safe to also view it as a smart contract account that can hold various assets and data structures, but crucially, it itself is a resource that can be owned and transferred. Imagine what flexibility this brings.

Key characteristics of Move Objects:

Self-Contained Entities: Objects group related resources together, allowing them to be treated as a single, cohesive entity on the blockchain.
Unique Address: Every object has its own unique address on the Aptos blockchain, derived from its creation. This address allows for direct interaction and referencing.
Ownership: Objects have an owner field within their ObjectCore (which we'll discuss shortly). This owner can be an account address or even another object's address, enabling nested ownership structures.
Resource Container: Objects can own other resources. This means you can store custom data structs (defined with has key ability) directly under an object's address.

Objects have their own address and can own resources similar to an account. They are useful for representing more complicated data types on-chain as Objects can be used in entry functions directly, and can be transferred as complete packages instead of one resource at a time.

Key Features and Capabilities

Move Objects are designed with flexibility and security in mind, offering several powerful capabilities:

Ownership: The owner field within an object's ObjectCore dictates who controls the object. This owner can be an external account or another object, enabling complex ownership hierarchies.
Transferability: By default, objects are transferable. However, this can be finely controlled. You can make an object:
- Ungated Transferable: Freely transferable by its owner.
- Untransferable: Cannot be transferred at all (e.g., for soulbound tokens).
- Controlled Transferable: Requires specific permissions or logic for transfer.
- Linear Transferable: Allows a one-time transfer by the owner.
Extensibility: Objects can be designed to be extensible, meaning new resources can be added to their storage after creation. This is crucial for dynamic DApps where an object's properties might evolve over time (e.g., adding new traits to an NFT).
Immutability: While objects can be extended, certain aspects of their configuration (like whether they are deletable or initially transferable) are set at creation time and cannot be changed later. This ensures predictable behavior.
Deletion: Objects can be made "deletable" at creation. Deleting an object removes it from global storage and can even refund gas costs associated with its storage, promoting efficient resource management on-chain.

*Object Creation and Configuration *
Creating and configuring an object involves using specific functions and references provided by the aptos_framework::object module.

The core of every object is the ObjectCore struct, which is automatically added to any struct declared with has key and used to create an object via object::create_object, object::create_named_object or object::create_sticky_object, depending on the type of object you want to create.

struct ObjectCore has key {
        /// Used by guid to guarantee globally unique objects and create event streams
        guid_creation_num: u64,
        /// The address (object or account) that owns this object
        owner: address,
        /// Object transferring is a common operation, this allows for disabling and enabling
        /// transfers bypassing the use of a TransferRef.
        allow_ungated_transfer: bool,
        /// Emitted events upon transferring of ownership.
        transfer_events: event::EventHandle<TransferEvent>,
    }

This leads us to the types of objects there are.

Normal Object
Named Object
Sticky Object

We’ll explain them in details later in the second part of this article article.

When you create an object, you receive a ConstructorRef, that is, creating an object returns a ConstructorRef, which is a one-time-use capability that allows you to configure the object during its initial setup.

struct ConstructorRef has drop {
    self: address;
    can_delete: bool; //true if object can be deleted. named objects are not deletable
}

This ConstructorRef is vital for:

Generating a Signer: object::generate_signer(&constructor_ref) allows the object itself to act as a signer, enabling it to own and manage its own resources.
Adding Initial Resources: Moving resources into the object's storage using move_to(&object_signer, MyResource { ... }) .
Configuring Capabilities: Creating TransferRef, DeleteRef, or ExtendRef from the ConstructorRef to define the object's behavior. We’ll explain these other refs shortly

Working with Objects in Move

Next, we’ll see the mechanics of interacting with Aptos move objects.

Object Address Generation
An object's address is generated when it's created. This ensures that each object has a unique identifier on the blockchain. The object::create_object function handles this generation and returns a ConstructorRef for the newly created object's address.

Object Storage
Objects, being resources themselves, are stored on the blockchain. When an object is created, its ObjectCore is stored at its unique object address. Any additional resources that the object "owns" are also stored at this same object address. This centralizes all data related to an object under its specific on-chain address.

Object References and Abilities
Move's type system uses "abilities" to define how a struct can be used. For objects, these abilities are crucial:

has key: This ability is essential for any struct that you want to store directly under an account's (or object's) address. The ObjectCore itself has key.
has store: This ability means a value of this type can be stored in global storage (i.e., on-chain).
has copy: Allows values of this type to be copied.
has drop: Allows values of this type to be implicitly dropped at the end of their scope.

We explained abilities in details in our last class, they also apply to objects.

Beyond the ConstructorRef, the aptos_framework::object module provides several other important references that grant specific capabilities:

DeleteRef: Grants the ability to delete the object from storage. This reference can only be created at object construction time if the object is configured to be deletable.

 

struct DeleteRef has drop, store { self: address, }

ExtendRef: Allows adding new resources to the object's storage after its initial creation. This is useful for dynamic objects.

 

struct ExtendRef has drop, store { self: address, }

TransferRef: Provides control over the object's transferability. This reference can be used to disable or re-enable ungated transfers.

struct TransferRef has drop, store { self: address, }

LinearTransferRef: A one-time-use reference derived from a TransferRef that allows for a single, controlled transfer of the object. This is useful for "soulbound" or single-transfer assets.

 

struct LinearTransferRef has drop { self: address, owner: address, }

DeriveRef: Used to create "derived objects" from a given object, allowing for hierarchical object structures.

 

struct DeriveRef has drop, store { self: address, }

Conclusively, we've covered the core concepts of Aptos Move Objects, from their fundamental resource-oriented nature and key characteristics to their powerful features like ownership, transferability, and extensibility. Understanding the ObjectCore and the various Ref types is crucial for configuring and interacting with objects.

Mastering Move Objects isn't just about learning a technical feature; it's about gaining the ability to design sophisticated, composable DApps on Aptos.

In the next part of this series, we'll look into practical code examples, demonstrating how to leverage Normal, Named, and Sticky Objects to build smarter and more securely on Aptos. Stay tuned!

Understanding Structs and Abilities in Move: The Building Blocks of Aptos Smart Contracts

Daniel — Wed, 28 May 2025 14:33:12 +0000

For developers looking to build on the Aptos blockchain, understanding Structs and Abilities in Move is not just beneficial, it's absolutely essential. These two concepts are the very bedrock upon which every Move module is constructed, especially when creating digital assets like tokens, including those conforming to the modern Fungible Asset (FA) standard on Aptos.

At its core, a Move smart contract's power lies in its ability to define and manage custom data. Structs provide the blueprint for this, allowing you to encapsulate related pieces of information into organized, meaningful data types. Without them, you'd be limited to basic primitive types like booleans, and addresses, which simply isn't enough to model complex real-world assets or application states.

Intrinsically linked to structs are Abilities. These are keywords that dictate the fundamental properties and behaviors of your custom data types. Abilities define how a struct can be used, copied, stored, or dropped, acting as crucial guardrails for Aptos Move's famed resource safety guarantees. Every struct you define will inherently possess (or lack) these abilities, directly impacting how it interacts within your module and across the blockchain's global state.

This guide will simplify structs and abilities, making them relatable and easy to understand without sacrificing technical accuracy. We'll explore how structs are defined, what each ability signifies, and crucially, how they collaborate to enable the secure and efficient management of digital assets. You'll learn how these concepts underpin the creation of tokens, where assets are often represented as special structs called "resources”: unique data types that cannot be duplicated or implicitly discarded. By the end, you'll have a solid grasp of how to leverage structs and abilities to write safe, composable, and efficient smart contracts on Aptos, helping you to build compelling dApps and define your own valuable digital assets. Let’s get in!

Structs: Your Custom Data Blueprints

As mentioned, a struct in Move is like a custom blueprint or a template for creating your own data types. It allows you to group related pieces of information, called "fields," into a single, organized unit. It is similar to structs in other languages like Rust or C, but with stronger restrictions in Move due to its resource-oriented model.

We'll go through four stages:

No abilities → won't compile for most real-world usage
Add drop → can discard
Add store → can store in global storage
Add key → can publish under an account

Minimal Token struct - No Abilities

Let's start with a simple, no-abilities struct: defining a Token struct. Note that a struct must be defined inside a module

module my_address::token_copy {
    use std::signer;
    use std::string::{Self, String};

    struct Token {
        name: String,
        supply: u64,
    }
    //functions go here
}

In this example:

struct Token { ... } declares a new struct named Token. It holds a name, which is the name of the token, and a supply: u64, which defines the total supply of the token as an unsigned 64-bit integer.

Any time you create an instance of Token, it will consistently have these two fields, ensuring that your data is always well-structured.

Abilities: The Permissions and Powers of Your Data

If structs are the blueprints for your data, abilities are the rules or permissions that dictate how instances of those structs can be handled by the MoveVM. They are fundamental to Move's security model, especially its "resource safety" guarantees. Each struct you define can be declared with one or more of four core abilities.

The Four Core Abilities

The drop ability

drop is a permission that allows a struct to be automatically discarded when it goes out of scope (like when a function ends). Without it, the Move compiler forces you to explicitly handle the value, meaning you must either move it somewhere useful or destroy it manually.

It is used for memory management during execution only… not related to publishing or storage.

What happens with vs without drop

First, we'll create/instantiate a Token struct without the drop ability to observe how Move enforces explicit value handling

module my_address::token_drop {
    use std::signer;
    use std::string::{Self, String};

    struct Token {
        name: String,
        supply: u64,
    }

    public entry fun initialize(admin: &signer, name: String, supply: u64) {
        let token = Token {
            name,
            supply,
        };
    }

}

Without drop, the Token cannot be silently discarded when the function ends, hence the error below. You must either transfer ownership or explicitly destroy it.

To fix this, we have to add drop ability to the token struct.

module my_address::token_drop {
    use std::signer;
    use std::string::{Self, String};

    struct Token has drop {
        name: String,
        supply: u64,
    }

    public entry fun initialize(admin: &signer, name: String, supply: u64) {
        let token = Token {
            name,
            supply,
        };
    }

}

Ideally, a token should not be droppable.

This will compile with the result below:

The copy ability

The copy ability in Aptos Move is a fundamental feature that determines whether a struct can be duplicated. It plays a crucial role in how data is handled, ensuring safety and preventing unintended behavior in smart contracts.

It allows a struct to be explicitly duplicated using the copy keyword. Without copy, a struct cannot be copied; it can only be moved (that is, ownership transferred).

What happens with vs without copy

Below is an example of code without the copy ability.

module my_address::token_copy {
    use std::signer;
    use std::string::{Self, String};

    struct Token has drop {
        name: String,
        supply: u64,
    }

    fun consume_token(t: Token){}

    public entry fun initialize(admin: &signer, name: String, supply: u64) {
        let token = Token {
            name,
            supply,
        };

        consume_token(token);
        consume_token(token);
    }

}

Since Token is not copyable, calling consume_token(token) moves the value. After this call, token can’t be used again because its ownership has been transferred.

token is no longer valid in this scope.
The memory that held token's data is now owned by the first consume_token.

An attempt to pass token again will result in error, and will not compile.

See the error message here:

Now let's add copy ability to Token.

module my_address::token_copy {
    use std::signer;
    use std::string::{Self, String};

    struct Token has drop, copy {
        name: String,
        supply: u64,
    }

    public entry fun initialize(admin: &signer, name: String, supply: u64) {
        let token = Token {
            name,
            supply,
        };

        consume_token(token);
        consume_token(token);
    }

     fun consume_token(t: Token){}
}

Ideally, a token shouldn't be copyable.

Here we go. Compiled successfully.

You can also make the copy operation explicit by writing consume_token(copy token), which indicates that the token value should be duplicated before being passed to the function.

The key ability

In Aptos Move, a struct becomes a resource when it has the key ability (and typically also store). This combination marks the struct as a persistent, account-bound data type that can be stored in global storage. Here's the definitive explanation:

struct Token has key, store {  // this is a resource
    name: String,
    supply: u64
}

If a struct has the key ability, it automatically has the store ability, even if it's not explicitly declared.

The key ability implies the struct, in this case Token, can be stored in global storage, and can be accessed from same. This makes Token a Resource.

Key Characteristics of Resources:

Stored in Global Storage
- Lives under an account (move_to(account, resource))
- Accessed via borrow_global/move_from
Singular Per Account
- Only one instance per (account_address, struct_type) pair
Explicit Lifetime Management
- Must be explicitly stored/retrieved/deleted
- Cannot be implicitly dropped or copied (no drop ability)

Global Storage

Operations around global storage are critical to the functioning of the key ability.

Global Storage is the on-chain storage where values are persistently stored at an account address. Unlike local variables that disappear after a function finishes running, global storage persists across transactions.

Global Storage Operators

Image source: Aptos docs

These operators all work with key ability.

Example

module my_address::token_key {
    use std::signer;
    use std::string::{Self, String};

    struct Token has key {
        name: String,
        supply: u64,
    }

    public entry fun initialize(admin: &signer, name: String, supply: u64) {
        let token = Token {
            name,
            supply,
        };

        move_to(admin, token); // move the token to the admin's account
    }   
}

The above code compiles successfully.

move_to(admin, token);
Stores the token under the admin's account in global storage. This is why Token needs the key ability.

Acquires

The acquires keyword in Move is used to explicitly declare that a function may access or modify a resource type stored in global storage. It's a safety feature that ensures the compiler knows which resources a function interacts with.

This annotation tells the Move compiler that this function will access the Resource from global storage
It's required whenever a function:
- Reads a resource (borrow_global)
- Modifies a resource (borrow_global_mut)
- Removes a resource (move_from)

Example using the acquires keyword. Note this is a basic code.

module my_address::token_key {
    use std::signer;
    use std::string::{Self, String};

    struct Token has key {
        name: String,
        supply: u64,
    }

    public entry fun initialize(admin: &signer, name: String, supply: u64) {
        let token = Token {
            name,
            supply,
        };

        move_to(admin, token); // move the token to the admin's account
    }

//use acquires
    public fun get_balance(addr: address): u64 acquires Token {
        let token = borrow_global<Token>(addr);
        token.supply
    }
}

In the code above, acquires grants the get_balance function access to the Token resource.

The borrow_global<Token>(addr); gets an immutable reference to the Token resource stored at addr, returns a reference that allows reading but not modifying.

Acquires is optional in Move 2.x as the compiler can now infer this annotation when necessary

We'll dive deeper into other global operators in our subsequent classes.

The store ability

And now, to store ability.
According to the aptos move docs,

The store ability allows values of types with this ability to exist inside a struct (resource) in global storage, but not necessarily as a top-level resource in global storage. This is the only ability that does not directly gate an operation. Instead, it gates the existence in global storage when used in tandem with key.

This is straightforward.

module my_address::token_store {
    use std::signer;
    use std::string::{Self, String};

    struct Token has key, store {
        name: String,
        supply: u64,
    }

    struct Vault has key {
        token: Token,
    }

    /// initialize a Vault that wraps a Token and store it in the signer's account
    public entry fun initialize(admin: &signer, name: String, supply: u64) {
        let token = Token {
            name,
            supply,
        };

        let vault = Vault {
            token,
        };

        move_to(admin, vault); 
    }


    public fun get_token_supply(addr: address): u64 acquires Vault {
        let vault = borrow_global<Vault>(addr);
        vault.token.supply
    }
}

If we try to compile this without the store ability on Token, the compiler will throw an error because storing a value inside another struct requires the store ability. You can try removing it to see the error for yourself.

Struct Ability Requirements in Aptos Move

Golden Rule:

When a struct has an ability, all its fields must have:

Why This Matters:

copy+drop = Temporary data
key+store = Global storage resources
Prevents unsafe combinations at compile time

Conclusively, remember these constraints aren't limitations. They are Move's way of eliminating whole classes of bugs at compile time. Whether you're storing assets globally with key or working with temporary copy data, these rules ensure your contracts behave predictably. Now that you understand how abilities propagate through structs, you're ready to design safer, more efficient Move modules.

How will you apply these rules in your next smart contract?

You can access the examples on github.

You can also reach me on Twitter now X.