<blockquote>
<p>I know that by using –tx-out-datum-embed-file we can embed the datum
data on the transaction (as opposed to the datum hash). However, is
this information persisted on the blockchain? (I am guessing it is as
it is needed in some scripts validators), and if so, how can we
retrieve this data?.</p>
</blockquote>
<p>Yes, this information is persisted, you can retrieve it using db-sync or blockfrost. For db-sync see <a href="https://cardano.stackexchange.com/a/5908/2248">this answer</a>. If you want to use blockfrost, however, you will need to first get the datum-hash, which you can get from the UTxOs with <code>https://cardano-testnet.blockfrost.io/api/v0/addresses/{address}/utxos</code> (take a look <a href="https://docs.blockfrost.io/#tag/Cardano-Addresses/paths/%7E1addresses%7E1%7Baddress%7D%7E1utxos/get" rel="nofollow noreferrer">here</a>). Then, you'll use that datum-hash to get the actual datum with this request <code>https://cardano-testnet.blockfrost.io/api/v0/scripts/datum/{datum_hash}</code> (also take a look <a href="https://docs.blockfrost.io/#tag/Cardano-Scripts/paths/%7E1scripts%7E1datum%7E1%7Bdatum_hash%7D/get" rel="nofollow noreferrer">here</a>)</p>

CC BY-SA 4.0
2022-03-08T11:05:35.447Z
Thanks, this is the correct answer. The answer you just referenced was posted by me :)
AngelCastillo
CC BY-SA 4.0
2022-03-08T11:05:59.017Z
Oh didn't even noticed it lol
Mateus
CC BY-SA 4.0
2022-03-08T11:06:29.770Z
Was looking for an answer to your question my self
Mateus
CC BY-SA 4.0
2022-03-08T10:42:01.337Z
2022-03-08T10:42:01.337Z
Mateus
<p>Your approach won't work, because in order to read the onchain data in a datum file, you have to consume given UTXO.</p>
<p><a href="https://cips.cardano.org/cips/cip25/" rel="nofollow noreferrer">CIP 25 - NFT Metadata Standard</a> has been created before smart contracts and is intended for minting outside of the them.</p>
<p>I'm not sure if it is a good idea to mix these two approaches. If you are a NFT author, it's up to you to choose what you want to do.</p>
<p>If minting native tokens with a script locking, you basically lock yourself out of burning the given token (we might have a solution for it in the future, but it is not possible right now) and it is all you have - a dummy token with metadata.</p>
<p>On the other hand, if you want to enable cool decentralized features to your NFT, you might want to mint it using a smart contract that will enable you, to add different proprieties to it (such as burning and re-minting).</p>
<p>Over time, there will be probably an update to CIP25 to account for smart contract based tokens.</p>

CC BY-SA 4.0
2021-11-18T13:27:54.510Z
To consume the eUTXO to read the metadata onchain, is not an issue, the token will be placed in a new eUTXO after we access the data (and we can enforce this).
AngelCastillo
CC BY-SA 4.0
2021-11-18T13:31:00.297Z
I am trying to figure out how to read this metadata >offchain<. Losing the ability to burn the state token is not important to me atm, most NFTs right now cant do this anyways after the policy expires. And we could allow to burn the native token used as handle.
AngelCastillo
CC BY-SA 4.0
2021-11-18T13:42:00.947Z
My idea is to have access to the token metadata from the minting policy and other validator scripts, you will be required to spend the eUTXOs with the state tokens, of course, to get access to the datum, and will be required by the script to place them on the contract again while conserving the metadata.
AngelCastillo
CC BY-SA 4.0
2021-12-15T05:28:18.677Z
Can you explain what you mean by "in order to read the onchain data in a datum file, you have to consume given UTXO"? Where does the datum file come from if you can only get it at spend time?
yoyobigmanyo
CC BY-SA 4.0
2021-12-15T13:31:50.317Z
You can only access the datum data from the smart-contract when you spent the output, it must be provided as a witness by the spending transaction. What I want to do is to get the datum data off-chain by querying the blockchain so I can display and use the data offchain as well. It must be possible because blockfrost api does it somehow
AngelCastillo
CC BY-SA 4.0
2021-11-18T12:54:50.740Z
2021-11-18T12:54:50.740Z
Marek Mahut - StakeNuts
<p>I have been thinking recently about the way we are predominately creating NFTs on Cardano, right now the trend is to add the NFT attributes to the transaction metadata, however, I think this is not really that good if we want to do more interesting things with the tokens. As long as we keep adding the NFT attributes to the transaction metadata we will never have decentralized minting (creating new NFTs from smart contracts, e.g breeding mechanism etc), as we can not enforce any kind of restrictions on the transaction metadata from the scripts. The users always have all the freedom to add anything to the metadata. Also, we cant read the information stored there from the contracts, making it impossible to use for example to implement business logic on the chain.</p>
<p>I have the following idea, but I am not sure if it could work:</p>
<p>Objectives:</p>
<ol>
<li><p>Stay away from an account base model and if possible keep the NFT as a native token.</p>
</li>
<li><p>Have the metadata accessible from the contracts (token metadata must
be inside an eUTXO).</p>
</li>
</ol>
<p>Possible solution:</p>
<p>At minting time we create two tokens, for example:</p>
<p>“fffffffffffffffffffff.Monster00001” and “fffffffffffffffffffff.Monster00001_state” (they could be in the same policy or different policies).</p>
<p>Token “Monster00001” could still be freely traded as a native token, however token Monster00001_state will be trapped in an eUTXO which holds the token metadata or dynamic state (depending on the use case).</p>
<p>To retrieve the metadata for token fffffffffffffffffffff.Monster00001 we just need to find the eUTXO which contains fffffffffffffffffffff.Monster00001_state and read its datum (from off-chain code to for example display the NFT in a website), but here is where I am stuck.</p>
<p>I know that by using <strong>–tx-out-datum-embed-file</strong> we can embed the datum data on the transaction (as opposed to the datum hash). However, is this information persisted on the blockchain? (I am guessing it is as it is needed in some scripts validators), and if so, how can we retrieve this data?.</p>

CC BY-SA 4.0
2022-09-15T18:39:06.143Z
Another option would be to mint only one token “fffffffffffffffffffff.hhhhhhhhhhh” where hhhhhhhhh is hash of the metadata and send it to the buyer. Then on chain you can hash metadata and check with token name (hhhhhhh). If they are equal, you are sure user supplied the correct metadata. This would requere extra on chain computation (hashing) but would avoid storing extra utxos in a smart contract, where each utxo has to have min 1 ada. If there are many nft's that can accumulate a lot
akegalj
CC BY-SA 4.0
2022-09-16T03:15:37.183Z
you cant access the transaction metadata from smart-contracts, so you won't be able to make this check on-chain
AngelCastillo
CC BY-SA 4.0
2022-09-30T08:46:48.507Z
you can't access transaction metadata dirrectly but you can always send metadata (and any other data) to smart contract from off-chain code via redeemer. Then in on-chain code you check if `hash redeemer == nft.tokenName` and if it's true you are sure metadata retrieved via redeemer belongs to a specific nft.
akegalj
<plutus><nft><transaction><metadata><datum>
How to retrieve the datum added with the option –tx-out-datum-embed-file from the tx witness data
# How to retrieve the datum added with the option –tx-out-datum-embed-file from the tx witness data

(Asked by: username_0 on 2021-11-18)

I have been thinking recently about the way we are predominately creating NFTs on Cardano, right now the trend is to add the NFT attributes to the transaction metadata, however, I think this is not really that good if we want to do more interesting things with the tokens. As long as we keep adding the NFT attributes to the transaction metadata we will never have decentralized minting (creating new NFTs from smart contracts, e.g breeding mechanism etc), as we can not enforce any kind of restrictions on the transaction metadata from the scripts. The users always have all the freedom to add anything to the metadata. Also, we cant read the information stored there from the contracts, making it impossible to use for example to implement business logic on the chain.

I have the following idea, but I am not sure if it could work:

Objectives:

1. Stay away from an account base model and if possible keep the NFT as a native token.
2. Have the metadata accessible from the contracts (token metadata must
   be inside an eUTXO).

Possible solution:

At minting time we create two tokens, for example:

“fffffffffffffffffffff.Monster00001” and “fffffffffffffffffffff.Monster00001\_state” (they could be in the same policy or different policies).

Token “Monster00001” could still be freely traded as a native token, however token Monster00001\_state will be trapped in an eUTXO which holds the token metadata or dynamic state (depending on the use case).

To retrieve the metadata for token fffffffffffffffffffff.Monster00001 we just need to find the eUTXO which contains fffffffffffffffffffff.Monster00001\_state and read its datum (from off-chain code to for example display the NFT in a website), but here is where I am stuck.

I know that by using **–tx-out-datum-embed-file** we can embed the datum data on the transaction (as opposed to the datum hash). However, is this information persisted on the blockchain? (I am guessing it is as it is needed in some scripts validators), and if so, how can we retrieve this data?.

**Tags:** plutus, nft, transaction, metadata, datum
> **Comments:**
> **username_1**: Another option would be to mint only one token “fffffffffffffffffffff.hhhhhhhhhhh” where hhhhhhhhh is hash of the metadata and send it to the buyer. Then on chain you can hash metadata and check with token name (hhhhhhh). If they are equal, you are sure user supplied the correct metadata. This would requere extra on chain computation (hashing) but would avoid storing extra utxos in a smart contract, where each utxo has to have min 1 ada. If there are many nft's that can accumulate a lot  
> **username_0**: you cant access the transaction metadata from smart-contracts, so you won't be able to make this check on-chain  
> **username_1**: you can't access transaction metadata dirrectly but you can always send metadata (and any other data) to smart contract from off-chain code via redeemer. Then in on-chain code you check if `hash redeemer == nft.tokenName` and if it's true you are sure metadata retrieved via redeemer belongs to a specific nft.  

---

## 2 answers

### Answer by username_2 on 2022-03-08. Score: 1 | Accepted answer

> I know that by using –tx-out-datum-embed-file we can embed the datum
> data on the transaction (as opposed to the datum hash). However, is
> this information persisted on the blockchain? (I am guessing it is as
> it is needed in some scripts validators), and if so, how can we
> retrieve this data?.

Yes, this information is persisted, you can retrieve it using db-sync or blockfrost. For db-sync see [this answer](https://cardano.stackexchange.com/a/5908/2248). If you want to use blockfrost, however, you will need to first get the datum-hash, which you can get from the UTxOs with `https://cardano-testnet.blockfrost.io/api/v0/addresses/{address}/utxos` (take a look [here](https://docs.blockfrost.io/#tag/Cardano-Addresses/paths/%7E1addresses%7E1%7Baddress%7D%7E1utxos/get)). Then, you'll use that datum-hash to get the actual datum with this request `https://cardano-testnet.blockfrost.io/api/v0/scripts/datum/{datum_hash}` (also take a look [here](https://docs.blockfrost.io/#tag/Cardano-Scripts/paths/%7E1scripts%7E1datum%7E1%7Bdatum_hash%7D/get))

> **Comments:**
> **username_0**: Thanks, this is the correct answer. The answer you just referenced was posted by me :)  
> **username_2**: Oh didn't even noticed it lol  
> **username_2**: Was looking for an answer to your question my self  

---

### Answer by username_3 on 2021-11-18. Score: -1

Your approach won't work, because in order to read the onchain data in a datum file, you have to consume given UTXO.

[CIP 25 - NFT Metadata Standard](https://cips.cardano.org/cips/cip25/) has been created before smart contracts and is intended for minting outside of the them.

I'm not sure if it is a good idea to mix these two approaches. If you are a NFT author, it's up to you to choose what you want to do.

If minting native tokens with a script locking, you basically lock yourself out of burning the given token (we might have a solution for it in the future, but it is not possible right now) and it is all you have - a dummy token with metadata.

On the other hand, if you want to enable cool decentralized features to your NFT, you might want to mint it using a smart contract that will enable you, to add different proprieties to it (such as burning and re-minting).

Over time, there will be probably an update to CIP25 to account for smart contract based tokens.

> **Comments:**
> **username_0**: To consume the eUTXO to read the metadata onchain, is not an issue, the token will be placed in a new eUTXO after we access the data (and we can enforce this).  
> **username_0**: I am trying to figure out how to read this metadata >offchain<. Losing the ability to burn the state token is not important to me atm, most NFTs right now cant do this anyways after the policy expires. And we could allow to burn the native token used as handle.  
> **username_0**: My idea is to have access to the token metadata from the minting policy and other validator scripts, you will be required to spend the eUTXOs with the state tokens, of course, to get access to the datum, and will be required by the script to place them on the contract again while conserving the metadata.  
> **username_4**: Can you explain what you mean by "in order to read the onchain data in a datum file, you have to consume given UTXO"? Where does the datum file come from if you can only get it at spend time?  
> **username_0**: You can only access the datum data from the smart-contract when you spent the output, it must be provided as a witness by the spending transaction. What I want to do is to get the datum data off-chain by querying the blockchain so I can display and use the data offchain as well. It must be possible because blockfrost api does it somehow  

---

