In this section, we will see how to mint native assets with a ForgeScript. For minting assets with smart contract, visit Transaction - Smart Contract - Minting Assets with Smart Contract.

Firstly, we need to define the forgingScript with ForgeScript. We use the first wallet address as the "minting address" (you can use other addresses).

Then, we define the metadata.

Finally, we create a transaction and mint the asset with the mintAsset method.

Like minting assets, we need to define the forgingScript with ForgeScript. We use the first wallet address as the "minting address". Note that, assets can only be burned by its minting address.

Then, we define Asset and set tx.burnAsset()

Here is the full code:

Additionally, you can define the forging script with NativeScript. For example if you want to have a policy locking script, you can create a new ForgeScript from NativeScript:

To get the keyHash, use the deserializeAddress(). To get the slot, use the resolveSlotNo(). Check out Resolvers on how to use these functions.

Important: if you are using a policy locking script, you must define setTimeToExpire before the expiry; otherwise, you will catch the ScriptWitnessNotValidatingUTXOW error. See Transaction - set time.

Next, we define the metadata for the asset and create the asset object:

Finally, we create a transaction and mint the asset with the mintAsset method:

You can get the policy ID for this Native Script with resolveNativeScriptHash:

In this section, we will see how to mint native assets with a PlutusScript.

The PlutusScript object is used to define the Plutus script that will be used to mint the asset. The redeemer object is used to provide the data that the validator script will use to validate the transaction. For this example, the validator script is expecting a redeemer with a data field of "mesh".

Similar to previous examples, we define the asset metadata and mint object. The asset metadata is a JSON object that contains the metadata for the asset. The mint object contains the asset name, quantity, metadata, label, and recipient address.

Finally, we create a transaction and mint the asset with the mintAsset method. We set the required signers to include the address that is minting the asset.

CIP-68 proposes a metadata standard for assets on the Cardano blockchain, not limited to just NFTs but any asset class. It aims to address the limitations of a previous standard (CIP-25).

The basic idea is to have two assets issued, where one references the other. We call these two a reference NFT and an user token, where theuser token can be an NFT, FT or any other asset class that is transferable and represents any value. So, the user token is the actual asset that lives in a user's wallet.

To find the metadata for the user token you need to look for the output, where the reference NFT is locked in. How this is done concretely will become clear below. Moreover, this output contains a datum, which holds the metadata. The advantage of this approach is that the issuer of the assets can decide how the transaction output with the reference NFT is locked and further handled. If the issuer wants complete immutable metadata, the reference NFT can be locked at the address of an unspendable script. Similarly, if the issuer wants the NFTs/FTs to evolve or wants a mechanism to update the metadata, the reference NFTcan be locked at the address of a script with arbitrary logic that the issuer decides.

Lastly and most importantly, with this construction, the metadata can be used by a Plutus V2 script with the use of reference inputs (CIP-31) . This will drive further innovation in the token space.

Royalty tokens is a special type of token that allows the creator to collect a royalty fee, this proposed standard will allow for uniform royalties' distributions across the secondary market space. Read CIP-27 for more information.

The implementation of royalty tokens is very simple, minting a token with 777 label, with "rate" and "addr" in the metadata.

Here is the full code: