I am very curious to learn about the move language, I am really thankful for this guide.
16 Likes
Noted well
20 Likes
it is awesome
18 Likes
Where can I find it
17 Likes
thats interesing! Thank you for sharing this buddy!
16 Likes
A good work thank s sir
16 Likes
the Aptos Ecosystem that have focused on education and learning concerning the Aptos Move environment⊠aptos is great
17 Likes
I literally thought of learning the move language to contribute to the Aptos ecosystem.
Looking forward to more future potentials.
23 Likes
Iâve learnt HTML, currently learning CSS , Am I on the right track?
17 Likes
Of course, yes.
27 Likes
Good information
30 Likes
Hello all,
Iâve recently gravitated to Aptos as a fellow MOVE network (formally developed rather heavily on Sui) and I have some questions regarding the Fungible Asset standard.
In order to effectively create a fungible token (ERC-20 equivalent) my understanding based on the documentation is that you must:
- Create an immutable object to âownâ the metadata object for the new fungible asset.
- Generate any refs you may desire: mint ref being obviously required in order to mint any supply, but others can also be added (i.e. burn & transfer ref)
first question
What is the best way to effectively âfreezeâ or drop the mint ref after the initial TGE? I do not want to have the ability to mint tokens at a future date, I simply want to mint the total supply upon deployment and then freeze or burn or drop the mint ref and not allow anyone to have the ability to mint any future tokens of my fungible assetâwhat is the best way to achieve this result? Would I simply create the mint ref in the constructor ref (since they are destroyed upon deployment) and mint the total supply that way?
second question
I have been told by a friend that I need to âregisterâ my fungible asset before it can be visualized by any Aptos wallet or be explorable via Aptos explorers. Is this correct? How do I effectively register my newly created fungible asset? Is this handled in the actual token.move code or is that an external function that happens elsewhere? Or is this what creating the âprimary storeâ effectively does? Unsure exactly what this means and want to be sure that my fungible asset is freely transferable and able to be held by various wallets/viewed on explorers etcâessentially am looking for functional parity with any basic ERC-20 token (discoverable name, symbol, decimals, image, freely tradeable, able to be visualized in any wallet and viewable on any explorer for Aptos, but not able to mint future tokens past initial token genesis event, cannot burn tokens, and cannot control the supply or restrict anyone from trading the token.)
Apologies for the super long post, but itâs of vital importance that I make sure I have all these details properly ironed out and this seems to be the best place. Thank you so much for making it this far and I hope to get some confirmations or pointed in the right direction from this. Cheers!
20 Likes
Great questions mate.
Youâve clearly done your research, and itâs great to see the level of detail youâre aiming for. IMO, hereâs a breakdown of the answers based on your queries:
Question 1: Freezing or Dropping the Mint Ref
To achieve a capped supply and ensure no future minting, youâre on the right track. Here are some approaches:
- Mint Total Supply in Constructor: As you mentioned, creating the mint ref in the constructor and minting the full supply upfront can be effective. By doing so, the mint ref is utilized during deployment and wonât persist beyond it.
- Burn Mint Authority After Deployment: Alternatively, if youâre minting supply in a subsequent transaction, ensure you burn or nullify the mint ref immediately afterward. This prevents any further minting operations, essentially making the token supply immutable post-TGE.
- Role-Based Freezing: Another common practice is to leverage role-based permissions, whereby the mint role is assigned to a designated authority and then permanently revoked. This is often safer for managing access control.
These methods should secure your tokenâs fixed supply without future minting capabilities.
Question 2: Registering the Fungible Asset for Visualization
Yes, registering your token is essential for visibility across Aptos wallets and explorers. Hereâs how to proceed:
- Registration Process: Youâll need to register your fungible asset on the Aptos network so that itâs recognizable by wallets and explorer tools. This is typically a separate step from the token creation in token.move.
- Primary Store: Creating the primary store during deployment effectively registers the asset, allowing Aptos wallets to read and visualize it. This step is akin to making your token publicly accessible on Ethereum.
- Metadata Completeness: Be sure your metadata (name, symbol, decimals, image) is fully defined in the primary store. This ensures that wallets and explorers can recognize and accurately display your asset, providing the ERC-20-like experience youâre seeking.
- Testing: After deployment, verify your tokenâs discoverability on multiple wallets and Aptos explorers to confirm the metadata renders correctly and that the token is freely transferable.
This should give you functional parity with ERC-20, minus minting or burning functions.
Hopefully, this clears things up. Let me know if you have further questions or need guidance on specific code-level implementations. Best of luck with your token launch on Aptos mate.
22 Likes
Fantastic read. Lfg
20 Likes
Great read. Lfg 
18 Likes
Wow. I am SO grateful for your detailed and thoughtful response. Thank you so much for taking the time to write that, I am truly so blown away by the response. Much appreciated !!!
10 Likes
good topic.
A lot of information!
5 Likes
Full of information bro thanks
5 Likes
Great piece of information.
Kudos brr
3 Likes
Are there any other platforms or projects in the Aptos ecosystem focusing on education and learning for developers?
4 Likes