Discussion for ARC-0003 - Algorand Standard Asset Parameters Conventions for Fungible and Non-Fungible Tokens

[fabrice102]

Draft is https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0003.md
See also proposed PR that may be listed below.

Included but not limited to the following points of discussion:

• Adding the possibility to store the JSON metadata file in the note of the transaction creating the asset. If such an option is added, the indexer should ideally be modified to be able to more easily read such a note.
• Comment on the integrity format for localized JSON metadata files.
• Use of the terms "NFT" and "fractional NFT"

[barnjamin]

Overall I very much like this, thank you for taking the time to put it together.

• Adding the possibility to store the JSON metadata file in the note of the transaction creating the asset. If such an option is added, the indexer should ideally be modified to be able to more easily read such a note.

I like this idea in theory. To me the creation of an asset should be treated with some special consideration. If the note field was used to store the metadata document the URL field should either contain:

• A Direct link to the digital media
• A URI constructed to reference the note field, maybe something like algorand://{txnid}/note

• Use of the terms "NFT" and "fractional NFT"

The term "fractional NFT" seems to contradict itself, I'd like to suggest completely removing it from the ARC. If the ASA is not 1 of 1, I don't think it can be referred to as non-fungible since Algorand doesn't uniquely identify the underlying units, making them completely fungible.

Perhaps there should be another ARC or an addendum or separate section to prescribe how one might "fractionalize" an NFT (ASA with supply of 1 unit) to make some supply of tokens > 1 that represent ownership of the underlying NFT.

If the name for an NFT was different I'd take no issue with fractional ownership of some digital media. If it were called a Tokenized Digital Asset the fractional aspect would seem natural.

[ChrisAntaki]

People commonly refer to tokens with supplies of 1-100 or so as "NFTs"

Ex: https://niftygateway.com/collections/warnymphvolume1

Constraining the spec to just 1/1 NFTs seems unnecessary, and could hurt this spec's adoption among the NFT community

[ChrisAntaki]

If the indexer could return the creation note field, along with the other ASA details, that would be incredibly useful, beyond this spec even

[ChrisAntaki]

A Direct link to the digital media

The Algorand NFT community is doing this currently. It's nice because clients can fetch the media ASAP, right after fetching ASA details. If the indexers and APIs started including the creation note with the ASA details, and the JSON was in that note, clients could keep on fetching the media ASAP 👍

[barnjamin]

People commonly refer to tokens with supplies of 1-100 or so as "NFTs"

If it is common use already, OK. I don't want to die alone on this hill and I don't want to try and argue with the hoards of folks already calling them NFTs.

Maybe I'm being pedantic but it is still is a misnomer since >1 supply of indistinguishable units makes them absolutely fungible, right?

[ChrisAntaki]

Haha, I think you're totally right

Meeting the audience where they are just seems like the best move, in my opinion

Here's another example:
https://www.dahai.uk/lot/1057#ARTB

This is a non asset backed NFT that may not be redeemed for the original artwork.

Sold as an edition of 10.

NFT has come to mean digital collectible trading card, essentially

[cusma]

I know this argument may sound a little contradictory with respect the concept of uniqueness and fungibility but I think we should reason about "intrinsic fungibility" and "extrinsic fungibility", extending the NFT definition to “Fractional-NFT”. I don't want to sound wordy but I will try to point out why it is not just a "wording" matter.

“Pure NFTs”, like collectibles or identities are ASAs with total supply 1 and decimals 0, which uniqueness is ensured by the Asset ID itself. “Fractional-NFT”, in my opinion, are ASAs representing wider non-fungible asset classes with huge cardinality of instances, like intellectual property, whose ownership/management can be fractionalised.

In this sense you may have tokens whose fractional parts are fungible among themselves but, taken as a whole, they are different and non-fungible instances of the same tokenisation class.

Let me give here a more concrete example: suppose we want to create a standard way to tokenize intellectual property. Now, nobody would disagree on the fact that the intellectual property is “non-fungible” per-se, in the sense that each right over any creative production is really different from one to another, so that these ASA IDs represent a really non fungible kind of real world assets. At the end of the day those assets are strictly personal and different among authors (Tom Jobim != Ennio Morricone).

Now, intellectual properties rights may have so many different attributes, like: reproducing music in public, use a lyrics, expose a piece of art, make use of a photo and so on.

In this example specifically, for each author you can have a bunch of ASAs, with the same name (maybe related to the author), with the same unit name (maybe related to the common issuance application) but with different attributes (which identifies the intellectual properties categories that are common to the whole tokenisation class). What really differentiate the ASAs is always the Asset ID and their supply just enables a shared ownership/management of that non-fungible tokenisation class.

Given the fact that for such use cases the cardinality of different ASAs will be huge, making them fractional does not make them, in my opinion, fungible among themselves. Their fungibility is only "intrinsic" if you wish.

So, although there will exists 100 units of “Tom Jobim musical work” this copyright is really non-fungible with “Ennio Morricone musical work”.

Just my 2 microALGO.

[KBryan]

1, I think I have enough backstory on why this is a suggested option. If this is the case, it should be more flexible or abstract but have some predefined properties to build on.

2, Possibly a content hash that is
{
"title":"Asset Data",
"type":"object",
"properties": {
"creator":"string",
"assetid":uint,
"description":"string",
"media_url":"string",
...// option for extended properties
}
}

3, The term fractional NFT is new to me. If I understand this correctly, would it allow partial ownership say x% of the NFT?

[fabrice102]

There seems to be many definitions of NFTs.
Let me try to illustrate with examples 4 cases:

1. A single unique object like the original "Mona Lisa" painting. Total supply = 1, decimals = 0. The ASA represents ownership of this single unique object. I think everyone agrees to call this an NFT. That is what @cusma calls pure NFTs.
2. Shares of a a single unique object, e.g., share of a specific rental building or share of a specific intellectual property asset (like “Tom Jobim musical work” to re-use @cusma examples). Total supply = 100, decimals = 0 for example, if we want 100 shares. That is what @cusma calls fractional NFT. Each share itself is fungible but the ASA globally represent an "NFT"
3. Small number of exact copies of the same object: for example, 10 identical printings of a piece of arts. Total supply = 10, decimals = 0. Some people seem to consider those as NFT, but at least formally, the 10 copies are actually fungible. It is an NFT in the very extended meaning of "ownership of some piece of art or physical object".
4. Multiple sculptures created from the same mold but with a way to distinguish them (e.g., a serial number on them). If the goal is to keep distinguishing them, I think the only solution is to create a pure NFT for each of the sculptures.

Questions:
a. Do you think this represent all the cases people name NFT?
b. Should case 3 be also called an NFT? Or a "..." NFT?
c. If case 3 is an NFT, should there be a way to indicate the intention that this is an NFT? Can this be a field in the metadata?

Personally, I would tend to think case 3 should not be called an NFT, but I'd like to understand what the consensus is.

[ChrisAntaki]

Cases #1 and #3 sound closest to how real-life NFT creators/collectors use the term, at least from my experience

• https://www.dahai.uk/lot/1057#ARTB (Dahai)
• https://niftygateway.com/collections/warnymphvolume1 (Grimes on Nifty Gateway)

[barnjamin]

I think you summed it up well @fabrice102. And @cusma thanks for explaining how you think about it. I do not want to try and go against the common use even if it isn't TeChNicalLy correct use of the term fungible.

b. Should case 3 be also called an NFT? Or a "..." NFT?

If this is something we do want to change, I would say we take out the N completely and make it SFT/PFT for Semi Fungible or Pseudo Fungible tokens.

Another topic, I started using https://nft.storage/ instead of the vanilla ipfs client to deal with storing the Images/Metadata and the structure is required to be as ERC-1155 but the metadata.json and image are stored in a directory together.

e.g. at ipfs://bafybeigtnw6qqyv7a4b4mgpm7fovfw6phme6xddzu5ycl5eqnmbhsxyfoy/metadata.json is the payload:

{
  name: "surfboi",
  description: "hawaii 2018",
  properties: {
    file: {
      name: "QmUNPvC36Du4pGEpbzaBzGhi5xP51sQkYT6MrcJhTSx9BV.jpg",
      size: 2470195,
      type: "image/jpeg"
    },
    artist: "mother earth"
  },
  image: "ipfs://bafybeigtnw6qqyv7a4b4mgpm7fovfw6phme6xddzu5ycl5eqnmbhsxyfoy/QmUNPvC36Du4pGEpbzaBzGhi5xP51sQkYT6MrcJhTSx9BV.jpg"
}

So what should the URL in the token be? the full metadata URL with ipfs:// protocol? the IPFS gateway? just the directory and metadata.json is assumed?

[cusma]

@fabrice102

Questions:
a. Do you think this represent all the cases people name NFT?
b. Should case 3 be also called an NFT? Or a "..." NFT?
c. If case 3 is an NFT, should there be a way to indicate the intention that this is an NFT? Can this be a field in the metadata?

a. Yes, I believe so.

b. We should not call case 3 "NFT". I don't know how many of you are passionate about card games, a-la Magic the Gathering, but I think playing cards are a good example of case 3. If a Magic the Gathering card has the same name, the same art-work, obeys the same rules of the game then that card, even from the point of view of a regulated use in a tournament, is completely fungible or exchangeable with other players. There may be N copies of a card - not necessarily a power of 10 - and possibly be reprinted in the future modifying the print run. When present in multiple copies in the same deck these cards are indistinguishable from each other. So although there could be over tens of thousands of different cards in Magic the Gathering today, copies of each of these cards are fungible (even at the game rules level), so assets of this type shouldn't be classified as NFT in my opinion.

c. See point b.

[fabrice102]

So what should the URL in the token be? the full metadata URL with ipfs:// protocol? the IPFS gateway? just the directory and metadata.json is assumed?

From my quick look at nft.storage, I would say, you need to put ipfs://bafybeigtnw6qqyv7a4b4mgpm7fovfw6phme6xddzu5ycl5eqnmbhsxyfoy/metadata.json.

I think it's best to use ipfs:// protocol instead of gateways when using the ipfs protocol. The reason is gateways may disappear while hopefully the ipfs protocol won't.

What do you think?

[barnjamin]

I think it's best to use ipfs:// protocol instead of gateways when using the ipfs protocol.

Def, not to mention with that url and a medium length domain for the gateway you're getting close to the char limit for url in the asa

[shaih]

I mostly agree with @cusma on this matter, here is my suggestion for naming, hopefully it is not too far from what people are using:

1. One unit, decimal = 0: NFT
2. Many units, sharing rights in a "non-fungible object": maybe Shared NFT? For this we require decimal = log_10(units)
3. A few units, identical objects: this is not a NFT at all, so let's not call it this (even if some others do). Is there anything to standardize for this type? If so then we need a different name, maybe Collection?

[cusma]

1. One unit, decimal = 0: NFT
2. Many units, sharing rights in a "non-fungible object": maybe Shared NFT? For this we require decimal = log_10(units)
3. A few units, identical objects: this is not a NFT at all, so let's not call it this (even if some others do). Is there anything to standardize for this type? If so then we need a different name, maybe Collection?

Since we are trying to classify different kind of Algorand Standard Assets I think that, at least on a more formal level (like internal specs and docs), we should start adopting an Algorand-oriented naming convention.

I'm suggesting this because the general concept of token (inherited form other blockchains) do not always re-map exactly just to the concept of ASA (with all its properties like, the role-based management and so on). To be future-proof with respect to Algorand itself, we should avoid confusions with other protocol features that may be used to model "tokens": someone can come up with an ASC1-based implementation of a "token".

Since here we are trying to define naming conventions strictly related to the Algorand Standard Assets, I think we should clearly specifying an ASA-oriented naming convention, at least for formal contents (internal specs, docs, etc.), something like:

1. Non-Fungible ASA (commonly NFT in other blockchains): total supply = 1, decimal = 0
2. Fractional or Shared Non-Fungible ASA (commonly Fractional NFT in other blockchains): decimal = log_10(total supply)
3. ASA Collection (to reuse @shaih example), in this case I would say that decimal = 0 should be a requirement, otherwise this type would be indistinguishable form any other Fungible ASA.

[KBryan]

I agree with having an Algorand angle to the asset as it behaves on a specified blockchain. Although, having a new name for an "asset" with cross-chain characteristics seems a bit much. The word NFT is the word used by the blockchain and greater community but have the 'a' in front of it to define the specific features that Algorand adds. Like aNFT.

[runvnc]

I know that media is only one use case, but would it be possible to standardize somewhere a field for MIME type (such as video/mp4, image/png, etc.)? Maybe if it has to go in the sub-properties, would be nice to have a standard field name for it. mimeType or contentType maybe.

[barnjamin]

Definitely think mimetype would be a good recommended field. Also things like byte size and for an image maybe dimensions or for audio maybe duration

[runvnc]

Overall I very much like this, thank you for taking the time to put it together.

• Adding the possibility to store the JSON metadata file in the note of the transaction creating the asset. If such an option is added, the indexer should ideally be modified to be able to more easily read such a note.

I like this idea in theory. To me the creation of an asset should be treated with some special consideration. If the note field was used to store the metadata document the URL field should either contain:

• A Direct link to the digital media
• A URI constructed to reference the note field, maybe something like algorand://{txnid}/note

• Use of the terms "NFT" and "fractional NFT"

The term "fractional NFT" seems to contradict itself, I'd like to suggest completely removing it from the ARC. If the ASA is not 1 of 1, I don't think it can be referred to as non-fungible since Algorand doesn't uniquely identify the underlying units, making them completely fungible.

Perhaps there should be another ARC or an addendum or separate section to prescribe how one might "fractionalize" an NFT (ASA with supply of 1 unit) to make some supply of tokens > 1 that represent ownership of the underlying NFT.

If the name for an NFT was different I'd take no issue with fractional ownership of some digital media. If it were called a Tokenized Digital Asset the fractional aspect would seem natural.

I hope you guys will really seriously think about taking advantage of the space in the note field for this. For NFTs, what are those 1000 bytes being used for really? Seems perfect for metadata.

[TheWolfWhoSaidWoof]

There may be N copies of a card - not necessarily a power of 10 - and possibly be reprinted in the future modifying the print run

There may be cards which are true NFT with no future print run. The ASAs in algorand are fixed at creation so it should be clear to owners how many there are. I don't think using powers of 10 is a good way to identify an NFT. It is rather limiting to the economics of games using NFTs that may need subtle balancing.

I picked a Rand Gallery collection and there were a number of non power 10 NFTs e.g. https://www.randgallery.com/algo-collection/?address=ROBOTWCDPDJ5YUOSG443OIZEDYFZ67RALBBNKWJWMMS2744HLBIR4WAVYM

Nice to see this discussion going on!

[ChrisAntaki]

I picked a Rand Gallery collection and there were a number of non power 10 NFTs

Nice! Rand Gallery is my side project, hope you're liking it! 🖼️

I don't think using powers of 10 is a good way to identify an NFT

Haha, yeah real creators definitely aren't limiting themselves to powers of 10

[cusma]

@TheWolfWhoSaidWoof, @ChrisAntaki I think there could be a misunderstanding regarding the power of 10.

Just to clarify:

A total number of units equal to the n-th (n ∈ ℕ) power of 10 and the decimals equal to the logarithm in base 10 of total number of units, is a requirement that defines Fractional-NFT. This ensures that a Fractional-NFT will always have a unitary supply, while being divisible up to the n-th decimal position.

So:

• for n = 0, we have a Pure NFT with total supply 1 and no shares.
• for n > 0, we have a Fractional NFT with total supply 1 and 10^n shares.

Not having this specifications, allowing arbitrary total number of units and arbitrary decimals, would turn the definition of such a standard/convention impossible, bringing us back to the starting point: no rules and no clear definition of the concept of NFT within the ASA framework.

[algokittens]

The genesis message is already used to store NFT MetaData by AlgoGems and OriginMint. I think it makes sense to build on this and to support legacy NFTs by improving the indexer so it is easier to fetch the data.

Using the URL to add the metadata would also work (and seems to be what you are proposing), and I like that it provides a quicker solution than waiting on genesis indexing implementations.

However, if both are feasible why go with the off-chain solution?

In terms of defining "NFTs", if you must have a definitions, what about a "semi" or "pseudo" NFT, e.g. supply >1 but non-divisible (and maybe <1,000). Many artist mint digital art with supplies of 3, 5, 9, 12, 21 etc. why prevent them from following the MetaData convention?

[TheWolfWhoSaidWoof]

@cusma "Not having this specifications, allowing arbitrary total number of units and arbitrary decimals, would turn the definition of such a standard/convention impossible, bringing us back to the starting point: no rules and no clear definition of the concept of NFT within the ASA framework."

I see your point. Perhaps just don't allow both decimals and an arbitrary number. That leaves 2 ways to do an NFT. Either a fixed integer supply (no decimals) or a power of 10 fractions of 1 NFT. Both of those might have different use cases. The former being good for gaming tokens or card games. The latter for curency like cases, we don't use pieces of eight anymore.

I think I am repeating what you said above Cusma!

[runvnc]

I guess the issue for someone like me who has a gallery function is that standardizing on referencing JSON in the URL instead of the content means that the gallery system will have to do significantly more work, UNLESS everyone includes the MIME type in the sub-properties, before it can display the media. Right now I do one Indexer query per asset which I cache, then I hit the URL to look at the content-type header (unless this is already cached), then pass URL and content type to my web page to display.

So if the URL is a JSON file, this introduces another HTTP request before I can get the media URL to look up the content type. Now if we can just agree to put the media type like image/png in the properties of the properties and pick a name such as mimetype, then I will be able to use that instead of the HTTP request to the IPFS gateway to look at the content-type header. And so it will end up being the same amount of work per media.

As far as using the metadata in the Note field, I don't recall if this was mentioned already but I feel like it might be way better if the convention encoded this somehow. Like maybe using the unit name, possibly @arc3n or something.

The thing about it is, since NFTs can be literally anything and are not necessarily images or even media of any kind, the metadata is really critical and so I think my gallery will eventually need to stop assuming assets are media without checking it. Actually I think that not having a metadata field directly attached to the asset might have been an oversight. And since they are talking about all of these crazy massive changes to the AVM such as generating transactions inside of contracts and getting 7000 executions instead of 700, I am just going to go ahead and open an issue on go-algorand proposing that we get a metadata field in the asset. Probably not feasible but wth, it's Saturday, why not troll a little.

If we are not doing that, it would sure be nice if the Indexer could look up the origination note for us and give us that when we query the asset.

[fabrice102]

Regarding mimetype

I guess the issue for someone like me who has a gallery function is that standardizing on referencing JSON in the URL instead of the content means that the gallery system will have to do significantly more work, UNLESS everyone includes the MIME type in the sub-properties, before it can display the media. Right now I do one Indexer query per asset which I cache, then I hit the URL to look at the content-type header (unless this is already cached), then pass URL and content type to my web page to display.

@runvnc, Do you need to know precisely the mimetype or whether it is an image or not? The current proposal follows ERC-1155 that essentially provides an image and other arbitrary property. My understanding is that if the media is not an image, the image would be a thumbnail and you would provide link to the actual document otherwise.
For example, on opensea, they use a property called external_link (https://docs.opensea.io/docs/metadata-standards#metadata-structure).

[ChrisAntaki]

archival nodes and relays are necessary for the network and could become very expensive if so much arbitrary data is stored on-chain

This is kind of concerning. Are you saying if people try using a core feature of Algorand, transaction notes, and Algorand gets more popular, archival nodes and relays could become "very expensive"? What happens if they get too expensive?

[mxmauro]

Following the above analysis, we favor the option to have the URL of ASA point to a metadata file.

Almost all of ASA points to a website. I think it is better to store in note field some sort of extended metadata which can include an url to the image and also allows owners to change it by sending a new acfg tx.

About having archival nodes or indexers: At some point, sites will require to have one of their own or use a third party provider to access/extract the data they need to run their sites.

[cusma]

I think these are interesting questions that are orthogonal to ARC-3 and we should try to discuss them either in another issue or on forum.algorand.org

I think that we may not want to add IPFS to the node code, but that it seems very interesting to provide tooling that would allow meaningful setup of an Algorand+IPFS node.

I very much agree on this. We should have an organic and eco-systemic approach to address this more general topic, regardless the ARC-3: what role Algorand should have, if any, with respect guiding, facilitating or building gateway tools for the integration of (and which) distributed storage protocols?

[robert-zaremba]

People commonly refer to tokens with supplies of 1-100 or so as "NFTs"
Constraining the spec to just 1/1 NFTs seems unnecessary, and could hurt this spec's adoption among the NFT community

By definition, an ASA with more than one 1 supply is not NFT. The tokens are fungible!

[robert-zaremba]

Small number of exact copies of the same object: for example, 10 identical printings of a piece of arts. Total supply = 10, decimals = 0. Some people seem to consider those as NFT, but at least formally, the 10 copies are actually fungible.

Exactly! If a token has more copies and those copies are not distinguishable, then these are not NFTs any more !
Making any assumption about the small number is utterly wrong.

[robert-zaremba]

In the broader blockchain community, we use:

• Fractional NFT to represent a share of something not fungible (usually if you want to divide an ownership of one thing into shares )
• Semi Fungible Token to represent a limited copies of something (eg, an aforementioned 100 units of “Tom Jobim musical work”)

To distinguish tokens / ASA as per fungibility type, I don't see any other way than defining a finite list of types and require metadata for all ASA, and include that type in that ASA. If the metadata is not included, or the type is not included then token type by default is:

• FungibleToken when supply is > 1
• NonFungibleTokenotherwise
  For old tokens, I propose the following method to provide / rectify the metadata: Discussion: Support of pre-ARC-3 tokens #31. Unfortunately it requires an indexer. Other idea is to use an on chain registry.

[fabrice102]

I apologize for the late answer.
Following the above comments, I've pushed the new PR
#33

Up to typos and non-normative changes, this will be the final ARC-3, except if an outstanding problem appears by Oct 22.

A few comments:

Re @robert-zaremba's comment

In the broader blockchain community, we use:

• Fractional NFT to represent a share of something not fungible (usually if you want to divide an ownership of one thing into shares )
• Semi Fungible Token to represent a limited copies of something (eg, an aforementioned 100 units of “Tom Jobim musical work”)

That's good because that does not conflict with ARC-3.
Regarding semi-fungible tokens, are the 100 editions fungible or each edition is distinct?
In the later case, a collection of NFTs (to be standardized later) would be the way to go,

(@jannotti , @runvnc , @emg110)
Regarding the discussion about reserve accounts , for NFTs, the reserve account serve little purpose. However, this ARC also covers fungible tokens, for which reserve accounts are quite meaningful.

[barnjamin]

LGTM thanks so much for coordinating this!

[robert-zaremba]

Maybe it would be worth to mention about DID? Eg: Metadata should contain a DID link

[runvnc]

I assume you mean decentralized identity. What type of identity links are popular? Anyone working on something like this for Algorand? The ones I saw seemed to be tied to Ethereum. Seems like just a URL or something wouldn't be adequate necessarily. You might need a signature to verify identity.

…

On Sun, Oct 24, 2021, 2:06 PM Robert Zaremba ***@***.***> wrote: Maybe it would be worth to mention about DID? Eg: *Metadata should contain a DID link* — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACU5HDJ4QEZGORUYW4SCATUIRYNZANCNFSM5ABMMLBA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[emg110]

I am working on some implementations of it and prepared it for a hackathon and will open-source It right after the event (As I usually do)

[fabrice102]

#33 is now merged.
This makes the ARC-3 final (following #3 (comment)), which should hopefully drive adoption.

Typos can still be corrected and non-normative parts can still be clarified via PR.
Note that the examples have been updated to recommend using the #arc3 version in URL instead of @arc3 in the name. But both options are still allowed.

[runvnc]

Are any NFT marketplaces or sites supporting Arc3? Someone is requesting a lot of metadata that won't currently fit in arc69 because its limited to 1000 characters in the asset config note. I can add arc3 to gifeconomy.com, but that probably won't be a solution to just have the NFTs on one site.

[pbennett]

I think many do - arc3 is a formal spec and one that, for the most part, matches existing conventions like Ethereum NFTs where the URL points to arbitrarily sized metadata. 1K is quite small for some use cases and I likely won't be able to use arc69 either because of it.
An arc3 'mutable' variant would be nice though - perhaps something like https://github.com/nftstorage/ipnftx - which is one proposal for allowing mutability while still using immutable base metadata (of arbitrary size).

[runvnc]

@pbennett when you say many do, can you give me a specific example? Really appreciate it.

[pbennett]

I think @barnjamin had a list somewhere on Discord - but realistically any Algorand NFT marketplace is going to have to support every spec if it's going to be usable. Whether it's early NFTS where it's just an image and nothing else, ARC69 (pre or post official version), or ARC3. As soon as you have any number of NFTs following a particular spec, any marketplace not supporting them automatically excludes themselves from part of the market. This might not be the best place to discuss it though. 😀

[vividn]

In addition to ipfs:// and https:// it would be nice to also allow arweave:// to avoid arweave links requiring arweave.net to stay up permanently.

[scholtz]

Hi @fabrice102 .. can you please rename the standard from Algorand Standard Asset Parameters Conventions for Fungible and Non-Fungible Tokens to Algorand Standard Asset Parameters Conventions for Non-Fungible Tokens ?

As there is no definition on how to create fungible tokens. :)

[simonbelingar]

to my understanding, fractional nfts, which are covered here(last time i checked, i admit it's been a while) are fungible.

…

On Wed, 9 Mar 2022 at 21:09, Ludovit Scholtz ***@***.***> wrote: Hi @fabrice102 <https://github.com/fabrice102> .. can you please rename the standard from Algorand Standard Asset Parameters Conventions for Fungible and Non-Fungible Tokens to Algorand Standard Asset Parameters Conventions for Non-Fungible Tokens ? As there is no definition on how to create fungible tokens. :) — Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEMTOSTM4A7G242K6VXISO3U7EARBANCNFSM5ABMMLBA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[scholtz]

@simonbelingar .. Fractional Non Fungible Tokens, by the name should not be considered as fungible.. I agree that they are fungible in the sense of "One project will not have other tokens" but the specs does not consider how to define fungible tokens. For example if i want to define stable coin, there is no definition how to do it. And i prefer not to do it in this ARC because i believe this one should be about NFTs not about generally how you should describe any tokens. Thats why i think it would be wise to remove the fungible from the title.

[SudoWeezy]

Closing the issue as the ARC is now Final

[nkavian]

Please update the documentation. I spent more than half a day trying to scour information as to how the metadata is stored and I kept reading incomplete information from various web pages.

The lack of coherent documentation will really hinder adoption.

So, should I be using the notes field or not be using it as it was mentioned in ARC69?
Should I use the url field or not?

My context is that I'm integrating via Java, so not interested in JavaScript or python examples.

[SudoWeezy]

The documentation you shared explains how to work with ASA.

For ARC-3, the metadata is stored on the support you want.
Usually, we decentralized storage like IPFS.
You have to write the link to the JSON file in the url field.

There is an example of how to work with ARC-3 here

nb: please use the forum for this kind of question