Building an NFT Marketplace on Aptos with Move: Architecture, Smart Contracts, and DApp Integration

Seiji Ito — Mon, 26 Oct 2026 19:31:30 +0000

I've been working on an NFT marketplace built on the Aptos blockchain, using Move for the smart-contract layer and a web-based dApp for interacting with the marketplace.

The project is available on GitHub:

GitHub: https://github.com/seiji0411/Aptos-NFT-Marketplace

Live application: https://www.alienharvesters.com/

The goal was not just to create an NFT minting page, but to explore how an NFT product can be structured across the smart-contract, deployment, CLI, and frontend layers.

What I Built

The project, Aptos Aliens, is an NFT minting/marketplace application running on Aptos.

The repository is organized into three major components:

Aptos-NFT-Marketplace/
│
├── contracts/
│ ├── aliens/
│ └── nft_collections/
│
├── cli/
│
├── dapp/
│
├── .gitignore
└── README.md

This separation keeps the blockchain logic, operational tooling, and frontend application independent.

High-level architecture

             ┌─────────────────────┐
             │      Web DApp        │
             │                     │
             │  NFT UI / Wallet    │
             │  Mint / Marketplace │
             └──────────┬──────────┘
                        │
                        │ Aptos Transactions
                        ▼
             ┌─────────────────────┐
             │    Aptos Network    │
             │                     │
             │     MoveVM          │
             └──────────┬──────────┘
                        │
                        ▼
         ┌───────────────────────────┐
         │       Move Contracts      │
         │                           │
         │  NFT / Collection Logic  │
         │  Ownership / Transfers   │
         │  Marketplace Operations  │
         └─────────────┬─────────────┘
                       │
                       ▼
              ┌──────────────────┐
              │ On-chain Assets  │
              │                  │
              │ Collections      │
              │ NFTs             │
              │ Ownership State  │
              └──────────────────┘

Aptos uses Move's resource-oriented model for on-chain assets, with ownership and access control enforced through Move's type and resource system.

Why Aptos + Move?

One of the most interesting parts of this project was working with Move instead of Solidity.

Move is designed around concepts such as:

Resource safety

Explicit ownership

Type safety

Access control

Scarcity

Module-based smart contracts

For an NFT application, these properties are particularly useful because digital assets should not be arbitrarily copied, destroyed, or transferred without authorization.

In Move, asset structures can use abilities such as:

struct NFT has key, store {
...
}

The key and store abilities determine how values can participate in global storage and ownership relationships.

This is one of the areas where Move's programming model feels particularly natural for asset-oriented applications.

Smart Contract Layer

The blockchain portion of the project lives under:

contracts/

The repository separates the core contract from NFT collection deployment.

The development workflow looks roughly like:

cd contracts/aliens

aptos init

aptos move compile

aptos move publish

This provides a straightforward workflow:

Move Source
↓
Move Compiler
↓
Bytecode
↓
Aptos Transaction
↓
MoveVM
↓
On-chain Module

Aptos executes Move modules through MoveVM, with validators agreeing on transaction ordering and execution results before state changes are committed.

Deploying NFT Collections

One interesting part of the project is the collection deployment workflow.

The repository includes a CLI workflow for deploying multiple NFT collections.

For example:

cd contracts/nft_collections

aptos key generate \
--vanity-prefix 0xae \
--output-file key \
--assume-yes

Then the generated account can be funded on testnet:

aptos account fund-with-faucet \
--account

And the Move package can be published using named addresses:

aptos move publish \
--private-key-file key \
--assume-yes \
--named-addresses \
aliens=,\
collection=

This makes it possible to separate different parts of the NFT system into independently deployable Move packages.

CLI Automation

The cli directory provides another important part of the architecture.

For example:

cd cli

yarn create_collection --config config.json

Instead of manually performing every blockchain operation, the CLI can act as an operational layer between configuration and on-chain transactions.

Conceptually:

config.json
│
▼
CLI
│
├── Wallet / Key Management
│
├── Collection Configuration
│
├── Transaction Construction
│
▼
Aptos Network

This type of tooling becomes increasingly important when an NFT platform needs to manage many collections or perform repeatable deployment operations.

Frontend → Blockchain

The DApp acts as the user-facing layer.

A typical NFT transaction flow looks like:

User
│
│ Connect Wallet
▼
DApp
│
│ Build transaction
▼
Aptos Account
│
│ Sign transaction
▼
Aptos Network
│
▼
MoveVM
│
▼
Smart Contract
│
▼
NFT State Updated

The important design principle is that the frontend should not be the authority for ownership.

The blockchain state is authoritative.

For example:

Frontend:
"User owns NFT #123"

↓

Blockchain:
"Address 0x... owns NFT #123"

The frontend simply reflects the state maintained by the blockchain.

Aptos accounts can control on-chain assets including digital assets, and transactions modify blockchain state through Move execution.

Ownership and Resource Safety

One of the biggest differences when coming from traditional Web2 development is thinking in terms of resources instead of database rows.

In a traditional application, you might have:

NFT

id
owner_id
metadata
collection_id

In a Move-based system, ownership is enforced through the blockchain's resource and type system.

Conceptually:

NFT
│
├── Collection
├── Metadata
└── Ownership
│
▼
Address

The important part is that ownership isn't merely a database field controlled by an API.

The Move module defines the rules under which an asset can be created, transferred, or modified.

Move's resource model is specifically designed around scarcity and access control.

Why Smart Contract Design Matters

NFT marketplaces are not simply frontend applications with blockchain payments added afterward.

The smart contract becomes part of the application's security boundary.

For example, marketplace logic should carefully consider:

Who can mint?
│
▼
Who owns the NFT?
│
▼
Who can transfer it?
│
▼
Who can modify metadata?
│
▼
Who receives payment?
│
▼
Can an NFT be sold twice?

These rules must be enforced on-chain.

The frontend should never be trusted to enforce critical ownership or authorization rules.

Aptos' Move security model provides mechanisms such as abilities, module visibility, signer-based authorization, and resource ownership to help enforce these constraints.

Marketplace Transaction Flow

A simplified marketplace transaction can be represented as:

         SELLER
            │
            │ Lists NFT
            ▼
    ┌────────────────┐
    │ Marketplace   │
    │ Smart Contract │
    └───────┬────────┘
            │
            │ Listing State
            ▼
         BUYER
            │
            │ Purchase
            ▼
    ┌────────────────┐
    │ Atomic Move    │
    │ Transaction     │
    └───────┬────────┘
            │
    ┌───────┴────────┐
    ▼                ▼
  NFT → Buyer      Payment
                   → Seller

For more complex marketplaces, this can evolve into atomic NFT-for-token swaps where the transaction guarantees that the intended asset and payment move together.

Aptos also supports sponsored transactions, orderless transactions, and multi-agent transactions that can be useful for more sophisticated application flows.

The Interesting Part: On-Chain vs Off-Chain

One of the architectural decisions I find particularly important in NFT systems is deciding what belongs on-chain.

A good rule is:

ON-CHAIN
──────────────
Ownership
Transfers
Asset identity
Marketplace state
Authorization
Critical business rules

OFF-CHAIN
──────────────
UI
Search
Caching
Images
Large metadata
Analytics
Indexing

Putting everything on-chain is usually neither necessary nor efficient.

The blockchain should be responsible for truth and settlement, while traditional infrastructure can handle presentation, indexing, search, and other application concerns.

Security Considerations

When building a production NFT marketplace, I would pay particular attention to:

Authorization

Never trust the frontend to determine who can mint or transfer an NFT.

Authorization belongs in Move.

Ownership

The contract should be the source of truth for ownership.

Resource abilities

Move abilities such as:

copy
drop
store
key

should be assigned intentionally.

Incorrect ability usage can introduce security issues or unexpected asset behavior.

Private keys

Private keys should never be committed to Git.

For example:

key
key.pub
.env

should be handled carefully and excluded from source control where appropriate.

Smart contract upgrades

Before deploying to production, contract upgrade policies need to be considered carefully.

Aptos supports module upgrade policies, and contracts can eventually be made immutable when appropriate.

Lessons From Building It

This project reinforced several things for me.

Web3 development is still software engineering

The blockchain is only one part of the system.

A production application still needs:

Smart Contracts
+
Frontend
+
Wallet Integration
+
CLI / Automation
+
Infrastructure
+
Security
+
Monitoring

Move requires a different mental model

Coming from traditional backend development, the biggest conceptual shift is moving from:

Database + API + Authorization

to:

Resources + Modules + Signers + Transactions

Blockchain state should be treated as authoritative

The frontend can display state.

It shouldn't define state.

That distinction becomes extremely important when building financial or asset-management applications.

Project Structure

The current repository can be explored here:

https://github.com/seiji0411/Aptos-NFT-Marketplace

The main components are:

contracts/
├── aliens/
└── nft_collections/

cli/
└── collection/deployment tooling

dapp/
└── Web3 frontend

The live project is available at:

https://www.alienharvesters.com/

What's Next?

There are several directions I would explore for taking an Aptos NFT marketplace further:

More sophisticated marketplace order management

Secondary-market trading

Royalty mechanisms

NFT collection management

Better indexing and search

Event-driven backend services

Analytics dashboards

How do you connect a blockchain node with multiple trading bots without adding TCP/HTTP overhead?

Seiji Ito — Tue, 06 Oct 2026 23:14:45 +0000

What happens when a blockchain node needs to communicate with multiple trading bots running as separate processes?

Instead of adding another network layer, go-ipc uses local IPC.

The flow is surprisingly interesting:

➡️ Bot registers with the node
➡️ Bot creates its dedicated subscription pipe
➡️ Node connects and starts streaming events
➡️ Node creates a dedicated transaction-submit channel
➡️ Bot sends signed transactions back
➡️ Heartbeats keep the connection healthy
➡️ Stale bots are automatically removed

One architecture. Two directions. Multiple independent bots.

And because the transport uses OS-level IPC rather than TCP/HTTP, communication stays local to the machine.

I mapped the architecture and workflow in the diagram below.

🔗 https://github.com/seiji0411/go-ipc

DEV Community: Seiji Ito

Building an NFT Marketplace on Aptos with Move: Architecture, Smart Contracts, and DApp Integration

NFT

How do you connect a blockchain node with multiple trading bots without adding TCP/HTTP overhead?