APTOS Token V2

Aptos's new token standard based on an Object storage model instead of an account resource model has incited excitement within the community. Here, in Mokshya Protocol we have been developing cool games and projects based on this version of token standard.

You can visit Aptos Warcade Game built by Mokshya Protocol

Now let’s discuss the design principles behind the Aptos token v2 standard, which is an improved version of the Aptos Token standard v1:

1. Flexibility: NFTs are designed to be flexible, allowing for customization to accommodate various creative designs. This means that creators have the freedom to create unique and personalized NFTs.

2. Composability: NFTs can be easily combined or composed together to create a more valuable and complex object. When multiple NFTs are combined, the final object becomes greater than the sum of its individual parts.

3. Scalability: The Aptos token v2 standard aims to achieve greater parallelism between tokens, allowing for more efficient and scalable operations within the blockchain.

The base token provided by the standard offers minimal functionalities. It serves as a foundation upon which creators can build and add more functionalities. These functions are not directly accessible from external sources and require the creators to write their own modules or use “no code” solutions provided within the framework.

Mokshya Protocol supported Wapal is all set to go for the no-code solution supporting both Token V1 and Token V2

When comparing the Token v2 standard to its previous version, Token v1, there are several notable differences:

1. Use of Aptos Objects: Token v2 uses Aptos objects instead of account resources, which were traditionally used in the Move language. This change allows for storing data outside of the account, offering more flexibility in designing NFTs.

2. Extensibility: Token v2 allows for easier extension of tokens with custom data and functionalities without requiring changes in the framework. This means that creators can add new features to their NFTs without disrupting the existing infrastructure.

3. Token Ownership: In Token v2, NFTs can own other NFTs, enabling greater composability. This feature allows for more complex and interconnected NFT ecosystems.

4. Soul Bound Tokens: Token v2 provides built-in support for soul-bound tokens, which are non-transferable by holders. This feature adds an additional layer of security and control for certain types of NFTs.

In the Token v2 standard, both collections and tokens are separate objects. They have their own distinct addresses and can be referenced both on and off the blockchain by their addresses. This separation allows for better organization and management of NFTs.

On-chain, a reference struct can include pointers to collection or token objects. For example:

struct ReferenceExample has key 
{
my_collection: Object<Collection>,
my_token: Object<Token>,
}

In this example, `my_collection` and `my_token` are addresses wrapped in the `Object<>` wrapper.

Off-chain, the address of the object can be passed as an argument in entry functions called during transaction creation. This allows for easy interaction with collection and token objects.

Let’s move on to the topic of royalties. Following the object extensibility pattern, royalties can be added to collections or tokens as a resource using the royalty module. Royalties specify the percentage of the sale price that goes to the creator of the collection or token. The royalty settings can be updated as long as a MutatorRef, which is a storable struct that grants permissions, is generated at the time of creation and stored securely.

The Token v2 standard also includes a token lifecycle, which consists of various stages:

1. Collection Creation: Every token belongs to a collection, so the first step is to create a collection. The creator needs to provide the necessary details such as the collection’s name, description, maximum supply, royalty settings, and URI.

2. Collection Customization: After creating the collection, the creator can further customize it by adding more data or functionalities. For example, the creator can track the creation timestamp of the collection or limit when tokens can be minted.

3. Token Creation: Once the collection is created, creators can mint tokens. Tokens can be named or unnamed, depending on the creator’s preference. Named tokens have deterministic addresses based on a hash of the creator’s address, collection name, and token name, making them easier to query. Unnamed tokens, on the other hand, have addresses generated based on the creator’s account’s GUID. Creators can specify properties such as name, description, URI, and royalty settings for each token.

4. Token Customization: Like collections, tokens can also be customized by adding more resources or data to them. This allows creators to enhance the functionality and uniqueness of their tokens.

5. Token Burn: If necessary, creators can choose to burn tokens. This process involves removing all custom data from the token object and deleting the token if it is an unnamed token. For named tokens, burning the token will delete its data but keep the underlying object intact.

6. Token Transfer: Tokens can be easily transferred by treating them as objects and using the object::transfer function. This allows for seamless ownership transfer of NFTs between users

In addition to the base Token v2 standard, there is also a module called “Aptos Token” for the following functionalities:

1. Soul Bound Tokens: Aptos Token allows creators to mint soul-bound tokens, which cannot be transferred by holders. This feature is useful for creating unique and exclusive NFTs.

2. Property Map: Aptos Token provides a PropertyMap, which is a simple map data structure that allows creators to define custom properties for their NFTs. These properties can store additional information and can be added or removed as needed.

3. Freezing and Unfreezing of Transfers: Creators can freeze or unfreeze the transferability of non-soul bound tokens. This allows them to control the transferability of their NFTs based on their requirements.

4. Creator Management: Aptos Token includes functionalities for managing collections and tokens. Creators can modify metadata, update royalty settings, and perform other management tasks related to their NFTs.

It’s important to note that Aptos Token provides a convenient solution for someone with practical “Coding” knowledge. Mokshya Protocol supported “Wapal” which is going to support every basic “no-code” functionalities for the Creators.