<p>An other user on the Cardano forum answered this question, for ease of use I'll will post that answer here as well [<a href="https://forum.cardano.org/t/on-datums-and-or-metadata-in-transactions/81924" rel="nofollow noreferrer">1</a>].</p>
<blockquote>
<p>The protocol allows to embed datum into the witness set, though the current version of the cardano-cli does not support it. What, you can do is download the <a href="https://hydra.iohk.io/jobset/Cardano/cardano-node/latest-eval" rel="nofollow noreferrer">latest cli build from Hydra</a> and use that one.
Example:</p>
<p>cardano-cli transaction build --tx-out-datum-embed-file ... # or  --tx-out-datum-embed-value</p>
<p>I highly encourage you to use only the precise JSON i.e. -file option instead of the causal one -value one.</p>
<p>But, what do you mean by uncompressed metadata transaction? The metadata in block is serialized from JSON to CBOR.</p>
</blockquote>
<p>And</p>
<blockquote>
<p>To clear the things a little bit. Datum hash is in the UTxO or as a map key in the witness set.</p>
<p>And yes a datum should not be act like an un-locking thing (that is why there is redeem) and should be publicly available all the time and or easily be reconstructed off chain. They only should be acting as state holders. iirc there was a discussion in the past whether the whole datum should be the part of the UTxO, but they (IOG) have decided not to go with that route for several reasons.</p>
<p>The problem is that in the current implementation the protocol cannot distinguish between the native script addresses (which do not need datum) and the Plutus script addresses, meaning the transaction validator cannot make decision whether an output in its pending/validating transaction requires a datum or not.</p>
<p>Also, keep in mind, due to the nature of UTxO model, everybody can send to any semi valid address (i.e. valid prefix and valid bytes length based on prefix but not existing address e.g, all 0s 0x80000000000....) to anything, which can mean it can be lost forever (or until there is private key generated which can derive that address).</p>
</blockquote>

CC BY-SA 4.0
2021-10-28T07:09:39.893Z
2021-10-28T07:09:39.893Z
Fermat
<p>What is the best practice of storing the local state of an UTXO to be publicly visible on-chain?</p>
<p>Thinking about how application would function in the future I thought that in a good DeFi ecosystem all datums should be publicly deducible. That is, no intermediate should be needed to process the state. And since the hash function is a one way function there is no deducing what a hashed state represents.</p>
<p>Right now datums can only be send in a transaction as a hashed values right? The cardano-cli only supports building transactions with the command <code>--tx-out-datum-hash</code>. I do not know what the protocol allows at the moment, maybe it is allowed but the client won't construct such transactions for you. Now to overcome this one can send unhashed metadata with the transaction to publicly anounce the datum in the same transaction. I am missing some other way? This extra hashed datum is a bit redundant, though I know it is needed now since UTXO's with empty datums are unclaimable <a href="https://forum.cardano.org/t/problem-with-smart-contracts/76830" rel="nofollow noreferrer">[1]</a>.</p>
<p>I think that the SpaceBudz auction contract is initiated in the above described way, metadata is send with every UTXO that is inbound of the script address <a href="https://cardanoscan.io/transaction/673f8768eefe41b12fa1a7d874c09f056390c54916160dad51455323f6b18c13?tab=metadata" rel="nofollow noreferrer">[2]</a>. I have not figured out how this metadata is correctly formatted to correspond to datumhash. More explicitly, I am yet to construct a json that hashes to the datum via the command <code>cardano-cli transaction hash-script-data --script-data-file file.json</code>.</p>
<p>Lastly I wonder in general what the impact is of these uncompressed metadata transaction. All plutus core code is serialized to hex and is transformed to CBOR before transacting. Would it be a good habit to do this for metadata as well? I have now idea what the PAB will do in this respect, maybe this is a no-brainer?</p>

<smart-contract><cardano-cli><eutxo><transaction-metadata>
How to handle datum in a decentralized way?
# How to handle datum in a decentralized way?

(Asked by: username_0 on 2021-10-27)

What is the best practice of storing the local state of an UTXO to be publicly visible on-chain?

Thinking about how application would function in the future I thought that in a good DeFi ecosystem all datums should be publicly deducible. That is, no intermediate should be needed to process the state. And since the hash function is a one way function there is no deducing what a hashed state represents.

Right now datums can only be send in a transaction as a hashed values right? The cardano-cli only supports building transactions with the command `--tx-out-datum-hash`. I do not know what the protocol allows at the moment, maybe it is allowed but the client won't construct such transactions for you. Now to overcome this one can send unhashed metadata with the transaction to publicly anounce the datum in the same transaction. I am missing some other way? This extra hashed datum is a bit redundant, though I know it is needed now since UTXO's with empty datums are unclaimable [[1]](https://forum.cardano.org/t/problem-with-smart-contracts/76830).

I think that the SpaceBudz auction contract is initiated in the above described way, metadata is send with every UTXO that is inbound of the script address [[2]](https://cardanoscan.io/transaction/673f8768eefe41b12fa1a7d874c09f056390c54916160dad51455323f6b18c13?tab=metadata). I have not figured out how this metadata is correctly formatted to correspond to datumhash. More explicitly, I am yet to construct a json that hashes to the datum via the command `cardano-cli transaction hash-script-data --script-data-file file.json`.

Lastly I wonder in general what the impact is of these uncompressed metadata transaction. All plutus core code is serialized to hex and is transformed to CBOR before transacting. Would it be a good habit to do this for metadata as well? I have now idea what the PAB will do in this respect, maybe this is a no-brainer?

**Tags:** smart-contract, cardano-cli, eutxo, transaction-metadata

---

## 1 answers

### Answer by username_0 on 2021-10-28. Score: 0 | Accepted answer

An other user on the Cardano forum answered this question, for ease of use I'll will post that answer here as well [[1](https://forum.cardano.org/t/on-datums-and-or-metadata-in-transactions/81924)].

> The protocol allows to embed datum into the witness set, though the current version of the cardano-cli does not support it. What, you can do is download the [latest cli build from Hydra](https://hydra.iohk.io/jobset/Cardano/cardano-node/latest-eval) and use that one.
> Example:
>
> cardano-cli transaction build --tx-out-datum-embed-file ... # or --tx-out-datum-embed-value
>
> I highly encourage you to use only the precise JSON i.e. -file option instead of the causal one -value one.
>
> But, what do you mean by uncompressed metadata transaction? The metadata in block is serialized from JSON to CBOR.

And

> To clear the things a little bit. Datum hash is in the UTxO or as a map key in the witness set.
>
> And yes a datum should not be act like an un-locking thing (that is why there is redeem) and should be publicly available all the time and or easily be reconstructed off chain. They only should be acting as state holders. iirc there was a discussion in the past whether the whole datum should be the part of the UTxO, but they (IOG) have decided not to go with that route for several reasons.
>
> The problem is that in the current implementation the protocol cannot distinguish between the native script addresses (which do not need datum) and the Plutus script addresses, meaning the transaction validator cannot make decision whether an output in its pending/validating transaction requires a datum or not.
>
> Also, keep in mind, due to the nature of UTxO model, everybody can send to any semi valid address (i.e. valid prefix and valid bytes length based on prefix but not existing address e.g, all 0s 0x80000000000....) to anything, which can mean it can be lost forever (or until there is private key generated which can derive that address).


---

