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
Sponsored transactions
Improved wallet onboarding
Automated contract testing
Security auditing
Production-grade observability
Aptos' current platform also provides capabilities such as sponsored transactions, keyless accounts, orderless transactions, and indexing/streaming infrastructure that can be interesting when evolving a prototype into a production-grade dApp.
Final Thoughts
Building Aptos Aliens gave me an opportunity to work across the complete Web3 stack:
┌───────────────┐
│ Web DApp │
└───────┬───────┘
│
┌───────▼───────┐
│ Wallet / SDK │
└───────┬───────┘
│
┌───────▼───────┐
│ Aptos TX │
└───────┬───────┘
│
┌───────▼───────┐
│ MoveVM │
└───────┬───────┘
│
┌───────▼───────┐
│ Move Modules │
└───────┬───────┘
│
┌───────▼───────┐
│ On-chain NFTs │
└───────────────┘
For developers interested in Aptos, Move, or NFT infrastructure, the complete implementation is available on GitHub.
Repository: https://github.com/seiji0411/Aptos-NFT-Marketplace
Live DApp: https://www.alienharvesters.com/
If you're building on Aptos, I'd be interested to hear what you're working on and what challenges you've encountered with Move or Web3 architecture.
Top comments (0)