<p>Datums are stored on-chain. There is part of <code>PAB</code> called <code>chain-index</code> - it follows the node, pulls Datums and stores them in local database (see <a href="https://docs.cardano.org/plutus/Plutus-tools" rel="nofollow noreferrer">here</a> section <code>Plutus Application Backend</code>).</p>
<p>So for your example, you can see couple lines above</p>
<pre><code>utxos &lt;- Map.filter f &lt;$&gt; utxoAt (oracleAddress oracle)
</code></pre>
<p><code>utxoAt</code> performs call to <code>chain-index</code> co-located with <code>PAB</code>. This call will return transaction output(s) with Datum(s) which <code>chain-index</code> saved while following the node (to dig a bit deeper: the hash of the Datum is known from UTxO at script address, so <code>chain-index</code> can find Datum by hash in its database, and provide transaction output with the Datum itself).</p>
<p>One note, that for this to work Datum must be properly embedded to the body of locking transaction (i.e. transaction performed by &quot;party who creates the output&quot;), but <code>Contract</code> monad machinery and <code>PAB</code> doing it for you automatically.</p>

CC BY-SA 4.0
2022-02-25T21:53:05.820Z
Thanks. What do you mean exactly by "properly embedded to the body of the locking transaction", in a technical description? Where are the datums stored?
hrpr
CC BY-SA 4.0
2022-01-21T08:29:30.483Z
2022-01-21T08:44:17.470Z
2022-01-21T08:44:17.470Z
Mikhail Lazarev
<p>It seems like the example you mention uses the <code>plutus-apps</code> stack, which is doing exactly what you suspect:</p>
<p>It includes the datum in the <em>producing</em> transaction and the PAB does keep track of this to provide it as enhanced <code>TxOutTx</code> values.</p>

CC BY-SA 4.0
2022-01-20T16:47:01.547Z
2022-01-20T16:47:01.547Z
Sebastian Nagel
<p>Every UTXO at a script address must have a TxOutDatumHash (or will be unspendable). To spend the UTXO at the validator you provide a datum and a redeemer, the script must validate with your redeemer, and the datum you provide must hash to the TxOutDatumHash of the UTXO you're spending. The problem, as discussed in CIP-32:</p>
<blockquote>
<p>This is quite inconvenient for users.
Datums tend to represent the result of computation done by the party who creates the output, and as such there is almost no chance that the spending party will know the datum without communicating with the creating party.
That means that either the datum must be communicated between parties off-chain, or communicated on-chain by attaching it to the transaction that creates the output (which is also inconvenient in that the spending party must watch the whole chain to spot it).</p>
</blockquote>
<p>But when I look at the code of, for example, the Oracle in Week 6 (or even the English Auction in Week 1), there seems to be a way of pulling the original datum from somewhere:</p>
<p><code>x &lt;- oracleValue (txOutTxOut o) $ \dh -&gt; Map.lookup dh $ txData $ txOutTxTx o</code> (<a href="https://github.com/mlabs-haskell/plutus-pioneer-program/blob/b50b196d57dc35559b7526fe17b49dd2ba4790bc/code/week06/src/Week06/Oracle/Core.hs#L181" rel="noreferrer">source</a>)</p>
<p>Can someone please explain what is happening here? I assume it is the &quot;on-chain communication&quot; technique that the CIP mentions. Does the datum need to be explicitly handled in a particular way for this to be possible? What are <code>txOutTxOut</code> and <code>txOutTxTx</code>? Thanks!</p>

<plutus-pioneer-program><datum>
Plutus pattern/technique for finding original datum preimage of TxOutDatumHash?
# Plutus pattern/technique for finding original datum preimage of TxOutDatumHash?

(Asked by: username_0 on 2022-01-18)

Every UTXO at a script address must have a TxOutDatumHash (or will be unspendable). To spend the UTXO at the validator you provide a datum and a redeemer, the script must validate with your redeemer, and the datum you provide must hash to the TxOutDatumHash of the UTXO you're spending. The problem, as discussed in CIP-32:

> This is quite inconvenient for users.
> Datums tend to represent the result of computation done by the party who creates the output, and as such there is almost no chance that the spending party will know the datum without communicating with the creating party.
> That means that either the datum must be communicated between parties off-chain, or communicated on-chain by attaching it to the transaction that creates the output (which is also inconvenient in that the spending party must watch the whole chain to spot it).

But when I look at the code of, for example, the Oracle in Week 6 (or even the English Auction in Week 1), there seems to be a way of pulling the original datum from somewhere:

`x <- oracleValue (txOutTxOut o) $ \dh -> Map.lookup dh $ txData $ txOutTxTx o` ([source](https://github.com/mlabs-haskell/plutus-pioneer-program/blob/b50b196d57dc35559b7526fe17b49dd2ba4790bc/code/week06/src/Week06/Oracle/Core.hs#L181))

Can someone please explain what is happening here? I assume it is the "on-chain communication" technique that the CIP mentions. Does the datum need to be explicitly handled in a particular way for this to be possible? What are `txOutTxOut` and `txOutTxTx`? Thanks!

**Tags:** plutus-pioneer-program, datum

---

## 2 answers

### Answer by username_1 on 2022-01-21. Score: 4 | Accepted answer

Datums are stored on-chain. There is part of PAB called chain-index - it follows the node, pulls Datums and stores them in local database (see here section Plutus Application Backend).
So for your example, you can see couple lines above
utxos <- Map.filter f <$> utxoAt (oracleAddress oracle)

utxoAt performs call to chain-index co-located with PAB. This call will return transaction output(s) with Datum(s) which chain-index saved while following the node (to dig a bit deeper: the hash of the Datum is known from UTxO at script address, so chain-index can find Datum by hash in its database, and provide transaction output with the Datum itself).
One note, that for this to work Datum must be properly embedded to the body of locking transaction (i.e. transaction performed by "party who creates the output"), but Contract monad machinery and PAB doing it for you automatically.

> **Comments:**
> **username_0**: Thanks. What do you mean exactly by "properly embedded to the body of the locking transaction", in a technical description? Where are the datums stored?  

---

### Answer by username_2 on 2022-01-20. Score: 0

It seems like the example you mention uses the `plutus-apps` stack, which is doing exactly what you suspect:

It includes the datum in the *producing* transaction and the PAB does keep track of this to provide it as enhanced `TxOutTx` values.


---

