<p>if I got you right, what you want to do is not possible.
The spending transaction sends the reedemer for each UTXO the transaction wants to spend.
The spending transaction is created by your offline code and the redeemers for the specific scripts send together with that transaction. The redeemer is not carried on the UTXO, so the UTXO holding the NFT does not have that information, just the datumHash (Datum).</p>
<p>You can use the redeemer with the script validating the NFTs UTXO, e.g. if it is allowed to spend it (as for an oracle). If the validator decline, the UTXO is not spend, which leads to a missing input for &quot;mkTicketPolicy&quot;.</p>
<p>So you have to check in your &quot;mkTicketPolicy&quot; if the NFTs UTXO will be spend. But you cannot check out of another validator script the redeemer backwards.
By submitting your transaction for your &quot;mkTicketPolicy&quot; validator you have to attach another constraint which triggers the validator script for the NFTs UTXO. A good example how to do that is the oracle script from the Plutus Pioneer course.
I hope I could explain it in an understandable way.</p>
<p>Edit:</p>
<pre><code>let v       = txOutValue (txOutTxOut o) &lt;&gt; lovelaceValueOf (oFee oracle)
                        p       = assetClassValue (oAsset oracle) $ price (lovelaces $ txOutValue $ txOutTxOut o') x
                        lookups = Constraints.otherScript (swapValidator oracle)                     &lt;&gt;
                                  Constraints.otherScript (oracleValidator oracle)                   &lt;&gt;
                                  Constraints.unspentOutputs (Map.fromList [(oref, o), (oref', o')])
                        tx      = Constraints.mustSpendScriptOutput oref  (Redeemer $ PlutusTx.toBuiltinData Use) &lt;&gt;
                                  Constraints.mustSpendScriptOutput oref' (Redeemer $ PlutusTx.toBuiltinData ())  &lt;&gt;
                                  Constraints.mustPayToOtherScript
                                    (validatorHash $ oracleValidator oracle)
                                    (Datum $ PlutusTx.toBuiltinData x)
                                    v                                                                             &lt;&gt;
                                  Constraints.mustPayToPubKey pkh' p
                    ledgerTx &lt;- submitTxConstraintsWith @Swapping lookups tx
                    awaitTxConfirmed $ txId ledgerTx
</code></pre>
<p>This is copied from the Swap.hs of the oracle example from the pioneers course. You see that two scripts with two reedemers are part of the transaction. Maybe this clarifies a bit better.</p>
<p>Here is the link to the complete example:
<a href="https://github.com/input-output-hk/plutus-pioneer-program/tree/main/code/week06/src/Week06/Oracle" rel="nofollow noreferrer">https://github.com/input-output-hk/plutus-pioneer-program/tree/main/code/week06/src/Week06/Oracle</a></p>

CC BY-SA 4.0
2021-09-07T15:33:19.203Z
I understand that constructing the scripts and the redeemers is done off-chain. But the transaction - to be executable and validable by a Cardano node - must (in some form) include all the scripts and their redeemers. If the transaction coming to the node includes all these information, wouldn't they be accessible by the validator scripts of the included input UTxOs? I thought the validators have access to the whole transaction.
Jey
CC BY-SA 4.0
2021-09-07T15:43:41.210Z
But I see the issue. If every validator has access to all the validator scripts, their redeemers, and the datums, then it could also run any other validator, potentially, causing an infinite loop. So I guess, it is not correct to say that the whole transaction is visible to the validator scripts.
Jey
CC BY-SA 4.0
2021-09-07T16:05:33.483Z
The whole transaction is visible, but just the transaction which is relevant for the specific UTXO. What you want to achieve is possible but not in the way you are trying it. 
Your first comment is correct - the transaction contains all the scripts and information validable by the cardano node - it is just split into two scripts. 
1. The validator script which checks if the utxo with the NFT can be spend 
2. the validator script for mkTicketPolicy which checks if the UTXO is available and additional checks. 
So your approach is solving 2. already, you still need to do 1.
sbcdn
CC BY-SA 4.0
2021-09-07T17:02:07.983Z
Thank you for your input. The oracle example of the Plutus Pioneer program is another use case. There, the swap validator just needs the exchange rate of the oracle. This rate is in the datum of the oracle utxo and therefore accessible to all validators. What I want to achieve is a bit different. I can shift the logic into the store, there is no problem. I was just under the impression that my way would be possible. So in conclusion, only the transaction without the scripts and redeemers is visible to the validators. Is this correct?
Jey
CC BY-SA 4.0
2021-09-07T17:51:34.047Z
I don't know what exactly you want to achieve, but what I described beside the oracle example also does not need the datum. With the example I wanted to point on the Constraints.otherScript and Constraints.mustSpendScriptOutput. This you can validate   without the need of redeemer or datum. But what you say is basically correct if you see it from the view of an utxo which does not belong to the actual executed validation script so e.g. an input.
sbcdn
CC BY-SA 4.0
2021-09-07T18:03:46.487Z
I think you are confusing something here. Validation can never happen off-chain. The oracle value is needed in the swap validator. You can see the datum being fetched on line 70 here: https://github.com/input-output-hk/plutus-pioneer-program/blob/main/code/week06/src/Week06/Oracle/Swap.hs
Jey
CC BY-SA 4.0
2021-09-07T19:06:45.480Z
Exactly, but you want in the oracle case to check for the datums value. Directly above that from line 57 to 68 its just checked if exactly one input form the address you passed is available. So If you make sure in your other script its just spend under a certain condition, you know that condition was matched when the input is available. The condition is specified in the other script. If we take the oracle example it is e.g. that the NFT and the datum of the new utxo created for the oracle are identical and the fee is paid. Edit: I assume you are in control of both scripts.
sbcdn
CC BY-SA 4.0
2021-09-07T19:44:23.903Z
The reason I want to do what I described is that the transaction will include many utxo outputs with minted tokens in the 'BuyTickets' case. So I want the store-utxo (the one with the nft) to check the validity. This utxo will also have other cases beside 'BuyTickets'. As I don't want to check that no tokens are minted in these other cases, I thought that it would be easiest to check in the minting policy that the store-utxo is spent with redeemer 'BuyTickets'.
Jey
CC BY-SA 4.0
2021-09-07T20:16:11.630Z
Ok I am not sure If I understood it completely, but can you not just check if the nft is available in the values and select the utxo's where the nft is available as input? I Guess they all have the same currency symbol or tokenName for identification?
For the "store-utxo" with the redeemer "BuyTickets" case as you describe I would maybe write to the datum it is in the state "BuyTicket" and make a transition to a neutral state when the NFT arrived in the store-utxo? I am sorry I do not know enough about your system for helping with a clear solution.
sbcdn
CC BY-SA 4.0
2021-09-08T07:40:14.693Z
Each issued ticket has its own token name but the same currency symbol. The token name is an integer representing the ticket number. One can easily see that the validation can not be done on a per ticket base if the tx contains minting of multiple tickets. The validation needs to know all minted tickets of the tx. Hence the idea of letting the store-utxo handle it. Storing the redeemer in the datum seems like a very hacky way to me. I thought of it but I think that it is better to let the minting policy validate all tx as long as it contains the store-nft and let the store-utxo do the rest.
Jey
CC BY-SA 4.0
2021-09-08T13:40:23.107Z
Is my understanding correct with this: 
You have a store, the store has its own NFT to be identified, someone issues a "buy ticket" with a arbitrary amount of tickets. Each ticket is a ticket-NFT which you want to mint from the mkTicketPolicy. You hand over some store-parameters containing e.g. the cn and tn of the store-NFT (possibly also the cn tn of the ticket-NFT). You check the store-NFT is available in inputs of the minting policy and matches the passed parameters to know the correct ticket-NFTs are minted. Is this correct?
What else you want to check with the minting policy?
sbcdn
CC BY-SA 4.0
2021-09-08T17:58:37.483Z
Everything is correct except "to know the correct ticket-NFTs are minted". The correctness is a bit tricky. The store-utxo has a counter in its datum. The token names must satisfy the conditions that they are (i) all different (ii) represent integers, (iii) strictly follow each other in at least one order, (iv) at least one of them is equal to the incremented counter. Additionally the transaction is a collection of buy requests put together to overcome the one-transaction-per-slot issue. The tickets can, therefore, be issued to a multitude of different pub key addresses.
Jey
CC BY-SA 4.0
2021-09-10T09:45:03.820Z
But all this was a distraction from the initial question: Is it possible to access other scripts redeemers ? Does the documentation say something on this ?
Jey
CC BY-SA 4.0
2021-09-10T11:07:20.473Z
Thank you for the explanations, you have a very interesting project. As far as I know it is not possible in on-chain code to access other scripts redeemers. The docs support that as I could not find anything for the script context what holds information about that.
sbcdn
CC BY-SA 4.0
2021-09-07T14:49:36.323Z
2021-09-07T16:11:23.543Z
2021-09-07T16:11:23.543Z
sbcdn
<p>I want to have a minting policy that checks some conditions of another input-utxo of the transaction. Fetching all transaction inputs and iterating over them is possible using <code>txInfoInputs</code> (see <a href="https://alpha.marlowe.iohkdev.io/doc/haddock/plutus-ledger-api/html/Plutus-V1-Ledger-Contexts.html" rel="nofollow noreferrer">plutus-docs</a>). But how do I check which redeemer is handed over to these utxos?</p>
<p>I have the below code. It checks that there is an input utxo with a defined nft. Now I try to check that the redeemer of this <code>storeUtxO</code> is of type <code>BuyTickets</code>. How do I do this?</p>
<pre><code>-- What are we doing here ? We are just checking that the transaction
-- includes a utxo-input with the defined store nft and that the redeemer
-- of the store utxo is 'BuyTickets'. We want that the store takes care
-- of validating the ticket purchase.
{-# INLINABLE mkTicketPolicy #-}
mkTicketPolicy :: Store -&gt; () -&gt; ScriptContext -&gt; Bool
mkTicketPolicy st () ctx =
    traceIfFalse &quot;store nft not found&quot; hasStoreNft
    &amp;&amp; traceIfFalse &quot;wrong redeemer&quot; hasCorrectRedeemer
  where
    let (c, t) = storeNft st -- storeNFT :: Store -&gt; AssetClass

    storeUtxO :: TxInInfo
    storeUtxO = find
        (\i -&gt; (valueOf (txOutValue $ txInInfoResolved $ i) c t) == 1)
        (txInfoInputs $ scriptContextTxInfo $ ctx)

    hasStoreNft :: Bool
    hasStoreNft = case storeUtxO of
        Nothing -&gt; False
        Just _ -&gt; True

    hasCorrectRedeemer :: Bool
    -- TODO
</code></pre>

<plutus><redeemer>
Finding the redeemer of another UTxO in a transaction
# Finding the redeemer of another UTxO in a transaction

(Asked by: username_0 on 2021-09-07)

I want to have a minting policy that checks some conditions of another input-utxo of the transaction. Fetching all transaction inputs and iterating over them is possible using txInfoInputs (see plutus-docs). But how do I check which redeemer is handed over to these utxos?
I have the below code. It checks that there is an input utxo with a defined nft. Now I try to check that the redeemer of this storeUtxO is of type BuyTickets. How do I do this?
-- What are we doing here ? We are just checking that the transaction
-- includes a utxo-input with the defined store nft and that the redeemer
-- of the store utxo is 'BuyTickets'. We want that the store takes care
-- of validating the ticket purchase.
{-# INLINABLE mkTicketPolicy #-}
mkTicketPolicy :: Store -> () -> ScriptContext -> Bool
mkTicketPolicy st () ctx =
    traceIfFalse "store nft not found" hasStoreNft
    && traceIfFalse "wrong redeemer" hasCorrectRedeemer
  where
    let (c, t) = storeNft st -- storeNFT :: Store -> AssetClass

    storeUtxO :: TxInInfo
    storeUtxO = find
        (\i -> (valueOf (txOutValue $ txInInfoResolved $ i) c t) == 1)
        (txInfoInputs $ scriptContextTxInfo $ ctx)

    hasStoreNft :: Bool
    hasStoreNft = case storeUtxO of
        Nothing -> False
        Just _ -> True

    hasCorrectRedeemer :: Bool
    -- TODO

**Tags:** plutus, redeemer

---

## 1 answers

### Answer by username_1 on 2021-09-07. Score: 1

if I got you right, what you want to do is not possible.
The spending transaction sends the reedemer for each UTXO the transaction wants to spend.
The spending transaction is created by your offline code and the redeemers for the specific scripts send together with that transaction. The redeemer is not carried on the UTXO, so the UTXO holding the NFT does not have that information, just the datumHash (Datum).
You can use the redeemer with the script validating the NFTs UTXO, e.g. if it is allowed to spend it (as for an oracle). If the validator decline, the UTXO is not spend, which leads to a missing input for "mkTicketPolicy".
So you have to check in your "mkTicketPolicy" if the NFTs UTXO will be spend. But you cannot check out of another validator script the redeemer backwards.
By submitting your transaction for your "mkTicketPolicy" validator you have to attach another constraint which triggers the validator script for the NFTs UTXO. A good example how to do that is the oracle script from the Plutus Pioneer course.
I hope I could explain it in an understandable way.
Edit:
let v       = txOutValue (txOutTxOut o) <> lovelaceValueOf (oFee oracle)
                        p       = assetClassValue (oAsset oracle) $ price (lovelaces $ txOutValue $ txOutTxOut o') x
                        lookups = Constraints.otherScript (swapValidator oracle)                     <>
                                  Constraints.otherScript (oracleValidator oracle)                   <>
                                  Constraints.unspentOutputs (Map.fromList [(oref, o), (oref', o')])
                        tx      = Constraints.mustSpendScriptOutput oref  (Redeemer $ PlutusTx.toBuiltinData Use) <>
                                  Constraints.mustSpendScriptOutput oref' (Redeemer $ PlutusTx.toBuiltinData ())  <>
                                  Constraints.mustPayToOtherScript
                                    (validatorHash $ oracleValidator oracle)
                                    (Datum $ PlutusTx.toBuiltinData x)
                                    v                                                                             <>
                                  Constraints.mustPayToPubKey pkh' p
                    ledgerTx <- submitTxConstraintsWith @Swapping lookups tx
                    awaitTxConfirmed $ txId ledgerTx

This is copied from the Swap.hs of the oracle example from the pioneers course. You see that two scripts with two reedemers are part of the transaction. Maybe this clarifies a bit better.
Here is the link to the complete example:
https://github.com/input-output-hk/plutus-pioneer-program/tree/main/code/week06/src/Week06/Oracle

> **Comments:**
> **username_0**: I understand that constructing the scripts and the redeemers is done off-chain. But the transaction - to be executable and validable by a Cardano node - must (in some form) include all the scripts and their redeemers. If the transaction coming to the node includes all these information, wouldn't they be accessible by the validator scripts of the included input UTxOs? I thought the validators have access to the whole transaction.  
> **username_0**: But I see the issue. If every validator has access to all the validator scripts, their redeemers, and the datums, then it could also run any other validator, potentially, causing an infinite loop. So I guess, it is not correct to say that the whole transaction is visible to the validator scripts.  
> **username_1**: The whole transaction is visible, but just the transaction which is relevant for the specific UTXO. What you want to achieve is possible but not in the way you are trying it.  Your first comment is correct - the transaction contains all the scripts and information validable by the cardano node - it is just split into two scripts.  1. The validator script which checks if the utxo with the NFT can be spend  2. the validator script for mkTicketPolicy which checks if the UTXO is available and additional checks.  So your approach is solving 2. already, you still need to do 1.  
> **username_0**: Thank you for your input. The oracle example of the Plutus Pioneer program is another use case. There, the swap validator just needs the exchange rate of the oracle. This rate is in the datum of the oracle utxo and therefore accessible to all validators. What I want to achieve is a bit different. I can shift the logic into the store, there is no problem. I was just under the impression that my way would be possible. So in conclusion, only the transaction without the scripts and redeemers is visible to the validators. Is this correct?  
> **username_1**: I don't know what exactly you want to achieve, but what I described beside the oracle example also does not need the datum. With the example I wanted to point on the Constraints.otherScript and Constraints.mustSpendScriptOutput. This you can validate   without the need of redeemer or datum. But what you say is basically correct if you see it from the view of an utxo which does not belong to the actual executed validation script so e.g. an input.  
> **username_0**: I think you are confusing something here. Validation can never happen off-chain. The oracle value is needed in the swap validator. You can see the datum being fetched on line 70 here: https://github.com/input-output-hk/plutus-pioneer-program/blob/main/code/week06/src/Week06/Oracle/Swap.hs  
> **username_1**: Exactly, but you want in the oracle case to check for the datums value. Directly above that from line 57 to 68 its just checked if exactly one input form the address you passed is available. So If you make sure in your other script its just spend under a certain condition, you know that condition was matched when the input is available. The condition is specified in the other script. If we take the oracle example it is e.g. that the NFT and the datum of the new utxo created for the oracle are identical and the fee is paid. Edit: I assume you are in control of both scripts.  
> **username_0**: The reason I want to do what I described is that the transaction will include many utxo outputs with minted tokens in the 'BuyTickets' case. So I want the store-utxo (the one with the nft) to check the validity. This utxo will also have other cases beside 'BuyTickets'. As I don't want to check that no tokens are minted in these other cases, I thought that it would be easiest to check in the minting policy that the store-utxo is spent with redeemer 'BuyTickets'.  
> **username_1**: Ok I am not sure If I understood it completely, but can you not just check if the nft is available in the values and select the utxo's where the nft is available as input? I Guess they all have the same currency symbol or tokenName for identification? For the "store-utxo" with the redeemer "BuyTickets" case as you describe I would maybe write to the datum it is in the state "BuyTicket" and make a transition to a neutral state when the NFT arrived in the store-utxo? I am sorry I do not know enough about your system for helping with a clear solution.  
> **username_0**: Each issued ticket has its own token name but the same currency symbol. The token name is an integer representing the ticket number. One can easily see that the validation can not be done on a per ticket base if the tx contains minting of multiple tickets. The validation needs to know all minted tickets of the tx. Hence the idea of letting the store-utxo handle it. Storing the redeemer in the datum seems like a very hacky way to me. I thought of it but I think that it is better to let the minting policy validate all tx as long as it contains the store-nft and let the store-utxo do the rest.  
> **username_1**: Is my understanding correct with this:  You have a store, the store has its own NFT to be identified, someone issues a "buy ticket" with a arbitrary amount of tickets. Each ticket is a ticket-NFT which you want to mint from the mkTicketPolicy. You hand over some store-parameters containing e.g. the cn and tn of the store-NFT (possibly also the cn tn of the ticket-NFT). You check the store-NFT is available in inputs of the minting policy and matches the passed parameters to know the correct ticket-NFTs are minted. Is this correct? What else you want to check with the minting policy?  
> **username_0**: Everything is correct except "to know the correct ticket-NFTs are minted". The correctness is a bit tricky. The store-utxo has a counter in its datum. The token names must satisfy the conditions that they are (i) all different (ii) represent integers, (iii) strictly follow each other in at least one order, (iv) at least one of them is equal to the incremented counter. Additionally the transaction is a collection of buy requests put together to overcome the one-transaction-per-slot issue. The tickets can, therefore, be issued to a multitude of different pub key addresses.  
> **username_0**: But all this was a distraction from the initial question: Is it possible to access other scripts redeemers ? Does the documentation say something on this ?  
> **username_1**: Thank you for the explanations, you have a very interesting project. As far as I know it is not possible in on-chain code to access other scripts redeemers. The docs support that as I could not find anything for the script context what holds information about that.  

---

