ASA Details

Parameters. The key way that you can specify the information associated with an ALGORAND standard asset, including metadata and other properties.

And for instance, when you create an asset for the first time, you need to set the values of some of these key fields.

You need to be careful with which fields you set, with what values. Some of them aren't able to be changed later. So it's important to have an understanding of what all of these fields mean so that you can plan ahead and understand.

So the asset that you need to represent what each of these values should be. So let's run through all of the fields and I can give you some tips about them.

First and foremost, it's basically four different categories of fields. So we've got the ID and name. We've got various things related to the quantity of the asset.

We've got some metadata properties, and then there's a series of algorand account addresses that can be associated with an ALGORAND standard asset.

A more useful way of representing these fields is to look at two sets of properties.

The first is whether or not the fields are immutable or immutable. So what that means is immutable fields can only be set at creation time and then cannot be changed.

Whereas under certain circumstances the immutable fields in the right column can be changed. And then the second property to look at is whether or not these parameters

are mandatory, i.e. you have to specify a value when creating an asset or if they are optional. You don't have to specify a value.

Let's start by honing in on the mandatory immutable parameters. So these are the ones that you have to set

when creating an asset and cannot be changed. So you need to get them right first go. The first one is the asset index. The asset index is an ID that allows you

to uniquely identify a given asset on the ALGORAND blockchain. Now, this is one that you don't actually set. It's set for you. It's created automatically and will often be displayed as asset ID

on various user interfaces in the Algorand ecosystem.

The Creator is the Algorand account that actually issued the transaction to create the asset, so that one is also set automatically.

The total field is a number that represents the total number of these assets that exist. So if you're creating an nonfungible token, then you're probably going to set this value to one to indicate that there is only one of these items.

And if you're implementing something like the Usdc Stablecoin, then you might say that there's a total supply of, say, $10 billion.

Now in here, the actual total value for Usdc is actually about $18 trillion. Decimals specify whether or not you can

fractionalize or split up the asset. That is, you can divide any one of the asset into multiple parts.

So the equivalent for real money is dollars and cents. You can have 100 cents to a dollar. So if you were representing dollars and cents, then you would set

the decimals to be two because you've got two decimal places. Now in this case, Usdc actually has very fine grained ability to be split and the decimals is actually set to six

Algoanna 220 as an NFT can't be divided into parts. So in this case the decimals zero are default frozen

relates to one of the building blocks that Algorand has built into it. For context, one of the key use cases for Algorand is decentralized finance or defi.

There are concept parts in finance more broadly that are highly useful, and one of them is freezing this says that a particular account cannot transact with an asset.

Now, in an algorand sense, there's a number of situations where being able to use freezing is useful. So one example might be where you need to perform a know your customer check

before allowing someone to transact with an asset. So what this default frozen field does is it says that when you create this asset,

it is frozen by default and no one can transact with it unless an action is taken to unfreeze the asset.

Next, let's have a look at the immutable fields that are optional. So these are the fields that, again, you can only set when creating the asset. And once they are set, they can't be changed.

But in this case, you don't have to specify them. The first one is the asset name, which is absolutely a recommended field. If you don't specify it, then most user interfaces are going to be

pretty unusable because the asset name is often used to describe the asset. For instance, if you have an asset in your wallet, the asset name has a maximum of 32 bytes.

So for a standard set of characters that would translate to a 32 character name, the unit name is

used as the representation when you are transferring an asset. So for instance, if I was going to transfer a quantity of 200 USD, say then it would actually

say I'm transferring 200 of Usdc is the unit name. Now in this case, the unit name in the asset name of the same. So you wouldn't be able to tell the difference.

However, a better example would be if I was going to send you, Algoanna 220. It would say that I'm transferring one times, goan20 rather than one times Algoanna 220.

The URL is an optional bit of metadata that basically allows you to point to information or metadata that's relevant for the asset.

In the case of Usdc, that field is not populated, but in the case of Algo in A220 it's pointing to an ipfs URL

that actually contains the image that you can see that of the owner. And finally, the metadata hash, which is an optional field that allows you to specify an integrity

hash of what you should expect when you request the URL. This can be used to give confidence that the content being requested is intact.

Finally, let's look at the immutable fields. The manager address is the address for an algorand account

that has permission to change these mutable asset parameters. If you don't set this, when you create the asset, it means that all of the fields become immutable,

since no one actually has the permission to set any of them. And at any point in the future. If you ever set the manager address to empty, then it can never be set to anything else.

So at that point in time you would turn an asset from being mutable to being immutable. This can be quite handy if there's a period of time where you want an asset to be able to be modified.

Then there's a point in time where you want to give confidence that it can't be changed and it would stay intact. The reserve address

is basically just an informational field. Notionally, it points to an account that you designate as the reserve. So for instance, if you minted USDC with the $18

trillion worth but you're only currently circulating, say $1.000.000.000 worth of currency, then that would mean that you'd have $17.999 trillion sitting in the reserve account

given that this is a immutable field and it's only for informational purposes.

Sometimes the reserve address actually gets used for immutable metadata, particularly in the case of some of the NFT metadata standards in algorand. The freeze address is the address that has permission to either

freeze or unfreeze this asset. So for instance, if you set default frozen to true, you would have to set the freeze address so that you can actually unfreeze

the asset for a particular account to transact with it. And finally, the clawback address is another feature

in Algorand that's built in as a useful financial building block. The basic idea is that the clawback address, regardless of the frozen status or who currently owns

the asset, can actually repossess the asset essentially, and move it to a different account at any point in time.

So again, this is just a really handy building block feature that can be useful in certain circumstances, particularly when combined with the freeze functionality.

It's worth pointing out that for all of these fields, as soon as you set any one of them to empty, the net field is then immutable and can no longer be set to something in the future.

And to reiterate, the manager address is the only one that has permission to change any of this.