Cohort 4 is done, and the certificates are already landing in our students' inboxes. Congratulations to everyone who made it through!
With that, we're officially opening applications for the Solana Rust Security Bootcamp (Cohort 5).
A 6-week intensive in Rust and Solana security, built for engineers who want to move beyond writing code to identifying how real systems fail.
> Supported by @SolanaFndn.
> Free to join.
> Only 125 seats.
And this round comes with a little bit of spice. We're teaming up with industry leaders you wouldn't expect to see here 🤫
C5 starts June 22. Applications close June 18.
We recommend applying early. Application form below (as always) 🦀
Cohort 4 is officially in the books. 17 sessions. 24 hours of live instruction.
And that's just the part on camera. Outside class, the students put in countless hours studying the material that @danielkcumming and @m4rio_eth built for them. Reading, debugging, writing PoCs, rerunning lectures, hunting bugs in the capstone.
All made possible thanks to the @SolanaFndn backing this work end to end.
Thank you to every student in C4. We don't take a single one of you for granted, and we're proud of the engineers walking out of this cohort.
Best of luck with everything you build next.
💎 What is the Digital Asset (DA) Standard on Aptos?
Aptos redefines NFTs with Digital Assets, where every NFT/token is an Object with its own unique address.
Let’s break it down! 🧵👇
🔹 1. Why is Aptos DA different?
Unlike traditional NFTs, Aptos Digital Assets are not just tokens—they are on-chain objects with their own unique addresses. This brings:
✅ More efficient storage (no account clutter).
✅ True ownership & portability (each NFT is an independent entity).
✅ Customizability (update metadata, add new traits, and mutate NFTs).
Aptos NFTs are smart, adaptable, and built for the future. 🚀
🏗 2. How are Digital Assets created?
Aptos NFTs follow a structured approach with two main objects:
🔹 Collection → A group of NFTs with metadata (collection.move module).
🔹 Token → The actual NFT, which belongs to a collection and stores its own attributes (token.move module).
Each NFT must be part of a Collection, but the Collection does not own the NFT—creators or users do.
📌 3. Collections: Fixed vs. Unlimited
NFTs are grouped into Collections, which can be either:
1️⃣ Fixed Supply → A limited number of NFTs can be minted.
2️⃣ Unlimited Supply → No cap on minting; creators can add more anytime.
Each collection contains metadata like name, creator, and URI.
🎨 4. How is NFT metadata stored?
Each Aptos NFT stores its properties in a Property Map (property_map.move module), which includes:
🔹 Attribute names (like "rarity" or "power level").
🔹 Data types (string, number, boolean, etc.).
🔹 Values (e.g., "Legendary", 100, true).
This enables dynamic, customizable NFTs with rich metadata.
🚀 5. NFT Actions: Transfer, Burn, Mutate
✅ Transfer → Move NFTs seamlessly between wallets.
✅ Burn/Delete → Permanently remove NFTs from circulation.
✅ Modify Metadata → Update an NFT’s image, description, or attributes after minting.
💰 6. Royalties: How Creators Get Paid
Royalties ensure that NFT creators earn a percentage of secondary sales.
📌 Not enforced on-chain → Since Aptos NFTs are objects, they can be transferred freely.
📌 Handled by marketplaces → Royalties are deducted when NFTs are sold through platforms that support them.
📌 Customizable settings → Creators can set royalties at minting and, in some cases, update them later.
🛠 7. Minting NFTs Easily
The aptos_token module simplifies NFT creation by allowing users to:
✅ Mint transferable NFTs (with royalties).
✅ Create soulbound NFTs (non-transferable).
✅ Manage NFT properties without writing smart contracts.
Perfect for creators who want plug-and-play NFT minting on Aptos.
The Aptos Digital Asset standard isn’t just another NFT model—it’s a scalable, efficient, and customizable framework for Web3 creators.
#Aptos
💰 The Legacy Coin Standard on Aptos 💰
Before the Fungible Asset Standard (FA), Aptos relied on the Coin standard to define and manage fungible tokens. Even today, APT—the network’s native token—is written using it.
So how does it work? Let’s dive in 👇
🧵 1. The Coin Module (0x1::coin)
At the core of the Coin standard are two key structs:
1️⃣ Coin<CoinType> → Represents the actual coins users transfer.
2️⃣ CoinStore<CoinType> → The main wallet where a user’s coins are stored.
Each coin type (e.g., USDC, APT) is uniquely defined by a struct in a module.
🔨 2. Creating a Coin
To create a new coin, a developer has to:
1️⃣ Define a struct (with key ability) to serve as the coin’s type.
2️⃣ Call coin::initialize<CoinType> to register it.
This returns three capabilities:
✅ Minting 🪙
✅ Burning 🔥
✅ Freezing 🚫
🕵️♂️ 3. Account & Coin Registration
Before a user can receive a coin, they need:
1️⃣ An Aptos account (created by sending APT).
2️⃣ To register the coin (coin::register), preventing spam deposits.
This makes wallets cleaner but adds friction to onboarding new coins.
👛 4. Managing Coins
Users can:
1️⃣ Merge or split Coin<CoinType> values.
2️⃣ Deposit and withdraw from CoinStore<CoinType>.
3⃣ Register new CoinStore<CoinType> instances to hold specific coins.
Meanwhile, creators control minting, burning, and freezing.
📄 5. Metadata & Supply Tracking
When creating a coin, developers could set:
1️⃣ Name, Symbol, Decimals → Purely metadata, not enforced on-chain.
2️⃣ Supply Monitoring (monitor_supply) → Enabled tracking of total supply.
However, enabling supply monitoring had a downside: it prevented parallel execution of mint/burn operations, limiting scalability for high-frequency transactions. Many opted to disable it for better performance.
🪙 6. APT & the Legacy of Coin
Even though FA is now the preferred standard, APT—the native Aptos token—still runs on the legacy Coin standard. This means:
1️⃣ Existing Coin-based tokens continue to work and can be bridged into FA if needed.
2️⃣ Developers who built on Coin don’t have to migrate immediately but are encouraged to adopt FA for new projects.
❓ 7. Why Move Away from the Coin Standard?
Aptos is moving away from the Coin standard in favor of the new Fungible Asset (FA) standard due to its enhanced flexibility and improved asset management features. The FA standard allows assets to be represented as objects rather than just stored within account resources, enabling more dynamic and efficient interactions. It also provides better support for metadata and on-chain composability.
🔍 Fungible Asset Standard on Aptos
The Fungible Asset (FA) on Aptos is a standard for creating and managing fungible tokens, similar to Ethereum's ERC-20. It enables developers to mint, burn, and transfer tokens securely and efficiently, leveraging Move's resource-oriented design.
📦Core modules to import:
Unlike Ethereum, where you write a contract that inherits from the ERC-20 standard, Aptos lets you import prebuilt, battle-tested code for fungible tokens:
- fungible_asset.move: for developers to create and manage tokens
- primary_fungible_store.move: handles deposits, withdrawals, and transfers in user wallets.
🔑Key objects:
The standard leverages Move Objects concept (they are more customizable and extensible).
- Metadata Object: contains token information like name, symbol, decimals, and supply. This unique object identifies the token type.
- FungibleStore Object: acts as the user’s wallet, storing balances of a specific token type.
🪙Token transfer:
When tokens (e.g., 100 USDC) are transferred:
- They're temporarily represented as FungibleAsset objects (just like cash).
- FungibleAsset are transferred by removing them from one FungibleStore and adding them to another.
⚙️ How It Works: Creating a Token:
Developers follow these steps to create and manage a fungible token:
1. Create Metadata Object - Use "object::create_named_object" with a signer to initialize a Metadata object for the token.
2. Call "primary_fungible_store::create_primary_store_enabled_fungible_asset" to set up the token with name, symbol, decimals, supply, URIs for the project and icon.
3. Use the ConstructorRef returned from the created object to generate Refs, which enable the token creator to perform key actions such as minting, burning, freezing, and transferring tokens.
🌟 Ethereum vs. Aptos Storage: Breakdown
Ethereum:
1. Built on a Patricia Merkle Tree with 4 layers:
- World State Tree: Tracks global account states.
- Storage Tree: Manages per-account data.
- Transaction Tree: Logs all transactions per block.
- Receipt Tree: Tracks execution outcomes for transactions.
2. Contract-Centric:
- Data is tied to contracts, which serve as hubs for both logic and state.
- Example: NFTs are created using mappings in ERC-721 contracts, linking token IDs to owners.
Aptos:
1. Adopts a forest-like global storage model:
- Each account is a tree🌳, branching into:
- Resources: Data stored as structs.
- Modules: Smart contract code in bytecode format.
2. Account-Centric:
- Structs (e.g., NFTs) are stored directly under accounts.
- Ownership is tied to accounts, not contracts, offering a cleaner, more intuitive storage design.
💡 Key Differences:
Ethereum:
- Contracts are the central hub for both data and logic.
- Ownership is managed using mappings stored within contract state variables.
- Complex storage structure, with data distributed across multiple trees.
Aptos:
- Accounts serve as unified containers, holding both data and code.
- NFTs and other resources are directly tied to accounts, making ownership intuitive and straightforward.
- Simplifies data management by consolidating storage under account trees.
#Ethereum #Aptos #Blockchain #Move #Web3
Easily the most alpha-loaded smart contract security blog post I have recently read
Absolutely a must read for all bug hunters on security audits, contests and bug bounty platforms - over 30 attack vectors here
Great work by @patrickd_de🫡
https://t.co/GVBzOs5et6