<p>Your deductions are partially correct. <code>isPayToScriptOut</code> looks at the credentials of an address <a href="https://playground.plutus.iohkdev.io/doc/haddock/plutus-ledger-api/html/Plutus-V2-Ledger-Api.html#t:Credential" rel="nofollow noreferrer">(1)</a> and return true if it is a script address, false if it is a public key credential. It thus does not look at the datum, it can deterministically check whether an output is made at a script address.</p>
<p>Here comes the crux, currently there are two types of scripts, native scripts and plutus scripts (V1 or V2). This function and the <code>credential</code> data type do not encode or differentiate between these scripts!</p>
<p>So in conclusion, you do know that that address is locked by a script, but you do not know what kind of script it is. It could be a native script locked by just a single public key.</p>
<p>This might change due to this CIP <a href="https://github.com/cardano-foundation/CIPs/pull/310" rel="nofollow noreferrer">(2)</a>. It aims to add a distinction between the types of scripts we have on the ledger.</p>
<p><strong>EDIT</strong>
A previous version of plutus indeed did use the datum for this function <a href="https://playground.plutus.iohkdev.io/doc/haddock/plutus-ledger-api/html/src/Plutus.V1.Ledger.Tx.html#txOutDatum" rel="nofollow noreferrer">(3)</a>. Note that this haddock host an outdated version of what is available in plutus. I would recommend using a local, up-to-date version. You can build this in the plutus-apps repo by entering a nix-shell and executing <code>build-and-serve-docs</code>.</p>
<p>Luckily, both the new plutus V1 <a href="https://github.com/input-output-hk/plutus/blob/c8d4364d0e639fef4d5b93f7d6c0912d992b54f9/plutus-ledger-api/src/PlutusLedgerApi/V1/Tx.hs#L212" rel="nofollow noreferrer">(4)</a> and V2 <a href="https://github.com/input-output-hk/plutus/blob/c8d4364d0e639fef4d5b93f7d6c0912d992b54f9/plutus-ledger-api/src/PlutusLedgerApi/V2/Tx.hs#L136" rel="nofollow noreferrer">(5)</a> implementations of these helper functions now implement it via the credentials. But note that the argument about it being unsafe due to not knowing what kind of script belong to a credential still holds.</p>

CC BY-SA 4.0
2022-08-16T07:17:25.177Z
2022-08-18T07:44:52.413Z
2022-08-18T07:44:52.413Z
Fermat
<p>As far as i understood, function <strong>&quot;isPayToScriptOut&quot;</strong> assumes every output that has a datum hash is a script output. But what if we create new output with datum, assigned to some pub key (for example due to use of: <em>&quot;mustPayWithDatumToPubKey&quot;</em> in off-chain code). So our new output wont be related to script one, but <strong>&quot;isPayToScriptOut&quot;</strong> will return true in this case? Because datum hash can be attached to any transaction. And that makes <strong>&quot;isPayToScriptOut&quot;</strong> not safe enough for development.</p>
<p>My deductions are correct?</p>
<p>*Here is considered function's code from plutus library:</p>
<pre><code> -- | Whether the output is a pay-to-script output.
    isPayToScriptOut :: TxOut -&gt; Bool
    isPayToScriptOut = isJust . txOutDatum

    txOutDatum :: TxOut -&gt; Maybe DatumHash
    txOutDatum TxOut{txOutDatumHash} = txOutDatumHash
</code></pre>

<plutus><transaction><datum><on-chain><datum-hash>
Is function "isPayToScriptOut" unsafe?
# Is function "isPayToScriptOut" unsafe?

(Asked by: username_0 on 2022-08-15)

As far as i understood, function **"isPayToScriptOut"** assumes every output that has a datum hash is a script output. But what if we create new output with datum, assigned to some pub key (for example due to use of: *"mustPayWithDatumToPubKey"* in off-chain code). So our new output wont be related to script one, but **"isPayToScriptOut"** will return true in this case? Because datum hash can be attached to any transaction. And that makes **"isPayToScriptOut"** not safe enough for development.

My deductions are correct?

\*Here is considered function's code from plutus library:

```
 -- | Whether the output is a pay-to-script output.
    isPayToScriptOut :: TxOut -> Bool
    isPayToScriptOut = isJust . txOutDatum

    txOutDatum :: TxOut -> Maybe DatumHash
    txOutDatum TxOut{txOutDatumHash} = txOutDatumHash

```

**Tags:** plutus, transaction, datum, on-chain, datum-hash


---

## 1 answers

### Answer by username_1 on 2022-08-16. Score: 4 | Accepted answer

Your deductions are partially correct. `isPayToScriptOut` looks at the credentials of an address [(1)](https://playground.plutus.iohkdev.io/doc/haddock/plutus-ledger-api/html/Plutus-V2-Ledger-Api.html#t:Credential) and return true if it is a script address, false if it is a public key credential. It thus does not look at the datum, it can deterministically check whether an output is made at a script address.

Here comes the crux, currently there are two types of scripts, native scripts and plutus scripts (V1 or V2). This function and the `credential` data type do not encode or differentiate between these scripts!

So in conclusion, you do know that that address is locked by a script, but you do not know what kind of script it is. It could be a native script locked by just a single public key.

This might change due to this CIP [(2)](https://github.com/cardano-foundation/CIPs/pull/310). It aims to add a distinction between the types of scripts we have on the ledger.

**EDIT**
A previous version of plutus indeed did use the datum for this function [(3)](https://playground.plutus.iohkdev.io/doc/haddock/plutus-ledger-api/html/src/Plutus.V1.Ledger.Tx.html#txOutDatum). Note that this haddock host an outdated version of what is available in plutus. I would recommend using a local, up-to-date version. You can build this in the plutus-apps repo by entering a nix-shell and executing `build-and-serve-docs`.

Luckily, both the new plutus V1 [(4)](https://github.com/input-output-hk/plutus/blob/c8d4364d0e639fef4d5b93f7d6c0912d992b54f9/plutus-ledger-api/src/PlutusLedgerApi/V1/Tx.hs#L212) and V2 [(5)](https://github.com/input-output-hk/plutus/blob/c8d4364d0e639fef4d5b93f7d6c0912d992b54f9/plutus-ledger-api/src/PlutusLedgerApi/V2/Tx.hs#L136) implementations of these helper functions now implement it via the credentials. But note that the argument about it being unsafe due to not knowing what kind of script belong to a credential still holds.


---

