Including Metadata in the transaction thoughts

Hi. I’m wondering about this approach to send a Native Token and have the metadata on-chain by including it in the transaction. Doesn’t this make the Native Token a bit pointless? I mean if I receive it, with metadata and then send it to someone else, the metadata is not included in the transaction since it’s not directly attached to the token. The concept of a token is nice but using this approach couldn’t this simply be a transaction only? with the minimum amount of ada needed to send over and then metadata attached with the transaction?

I think that the answer depends upon the purpose of the metadata:

  • For instance, in a voting scenario, sending the token could correspond to placing a vote, but the metadata attached to that transaction could indicate what was voted for. In this scenario, the token demonstrates that the voter is authorized—otherwise one would need off-chain information or a registry of voters’ addresses to determine the voter’s eligibility.
  • The metadata attached to the minting transaction for an NFT has a special purpose of describing the token, linking to its image, etc.
1 Like

those or good points. What I’m thinking is. If I send someone a token and later, say in 2 years he wants to transfer this token to another person. The token is exchanged between the two wallets but wouldn’t the sender need to specify the exact same metadata in this new transaction for it to be transferred? can the new owner trace the history of this token and see that originally it was sent over in a transaction containing a certain metadata?

Hi!

And what about the case when you want send the received token for someone else… that case the original transaction will be separated from the token… does the token remain NFT?

1 Like

Actually, I think I’m wrong here. The metadata is attached to the minting transaction, not the actual transaction used to send the token over. So metadata should persist even if the token is sent around. The minting transaction used to create can always be tracked to this token

1 Like

This will be easier to define with smart contracts. The way to keep them NFTs now is to use a time based policy so say I create 10 copies of a token, the policy I use with it declares that I can only mint these tokens before a certain time. Once that time hits, no more tokens of this kind can be minted.

Time based policy not a good solution either, I think - since you can mint a lot of tokens with that policy…

true, that’s possible. I guess until smart contracts the transfer/sale of NFTs is very trust based. You have to trust the issuer for the policy and not to mint more than what he declares. You should be able to verify this though by looking up how many NFTs have been minted with a certain policy.

1 Like

so these solution not creating NFTs. Cardano right now supporting only native, fungible tokens.

Indeed, with or without smart contracts, one would have to verify that the minting policy doesn’t allow any more of the NFTs to be created, and that just one was created. If the person who minted the NFTs doesn’t publish a copy of the minting script somewhere, then it isn’t possible to verify that it is a true NFT, and one just has to trust them. (BTW, very few sellers of “NFTs” nowadays seem to be posting links to the minting-policy scripts used to create them.)

For example, here is the procedure for checking whether an NFT created by a time-locked script is a true NFT:

  1. Obtain a copy of the policy script, which the person who minted the tokens has posted somewhere (maybe in a link in minting metadata, in the token registry, or somewhere on their website). Note that the script or contract isn’t posted on the blockchain–only its hash is posted.

  2. A time-locked script will look something like this:

    {
      "type" : "all",
      "scripts" : [
        {
          "type" : "sig",
          "keyHash" : "b395c1a9464d419c69d05c148a19d44130c249abfb990c6a3fcd0b07"
        },
        {
          "type" : "before",
          "slot" : 25251428
        }
      ]
    }
    
  3. Run cardano-cli query tip --mainnet to find the current slotNo on the blockchain. If the script has the form shown above and the current slotNo is greater than the slot in the script, then no more tokens can ever be minted using that policy.

  4. Run cardano-cli transaction policyid --script-file on that script file to compute the policy ID of the script.

  5. Look up the NFT somewhere like on cardanoscan.io to see what its policy ID is. If that policy ID matches the one you just computed with cardano-cli, then that script did mint the token and only that script ever could.

  6. If the policy ID matches (step #5), the before slot has passed (step #3), and cardanoscan.io (or somewhere similar) shows that only one token was minted, then it is true NFT.

With smart contracts, the verification procedure will be even more involved, because you’d have to read and analyze the logic of the smart contract to verify that it can only ever mint one of the token.

1 Like

FYI: Yesterday pool.pm announced that one can view some NFT minting scripts and their locking properties on pool.pm/tokens.

1 Like