Transaction build --tx-out order matters when sending non-ADA assets to Plutus script address

English Community Technical Support
1

Hi, community. I just had an interesting finding. The order of --tx-out matters if you have multiple --tx-out in the cardano-cli transaction build command. Multiple --tx-out is needed if you send non-ADA assets, lets say you send only 10 tokens to the script address while you have to send 30 tokens back to your own wallet (for balancing).

What do I mean by wrong order?

Correct:

cardano-cli transaction build     
--tx-in ...
...
--tx-out addr_OWN_WALLET+2000000+"30 POLICY.NAME" 
--tx-out addr_SCRIPT_ADDRESS+2000000+"10 POLICY.NAME"
...
--alonzo-era

Wrong:

cardano-cli transaction build     
--tx-in ...
...
--tx-out addr_SCRIPT_ADDRESS+2000000+"10 POLICY.NAME"
--tx-out addr_OWN_WALLET+2000000+"30 POLICY.NAME" 
...
--alonzo-era

What happens when the --tx-out order is wrong?

Wrong --tx-out order will result in that UTXO in the script address having TxOutDatumHashNone, while the UTXO you sent back to your own wallet will contain ScriptDataInAlonzoEra "8c..HASH..HERE..

As a result, now, I have a UTXO in the script address, that I don’t know how I can redeem. As it shows the error: The Plutus script witness for the txin does not have a script datum (according to the UTxO).

Question #1 / Problem?

Is my finding correct? Is that wrong --tx-out order will result in UTXO in the script address becoming stuck forever (cannot be redeemed) as it does not have the datum to compare against?

Question #2

Is it possible to redeem this UTXO in the script address that has no datum (TxOutDatumHashNone)?

Question #3

How to ensure that the --tx-out that is send to the script address will surely contain the datum (and not other --tx-out (i.e. those I send back to my own wallet for balancing)?

2

From the cardano-cli transaction build --help …

            (--tx-in TX-IN
              [--tx-in-script-file FILE
                [(--tx-in-datum-file FILE | --tx-in-datum-value JSON VALUE)
                  ( --tx-in-redeemer-file FILE
                  | --tx-in-redeemer-value JSON VALUE
                  )]])
            [--tx-in-collateral TX-IN]
            [--tx-out ADDRESS VALUE [--tx-out-datum-hash HASH]]

it is arguably not clear that a script --tx-out MUST have a --tx-out-datum-hash.

Which however is (currently) the case.

#1 Is my finding correct?

Yes, that is correct. To be precise, the order of your --tx-out does not matter, but each script --tx-out must immediately be followed by it’s associated --tx-out-datum-hash

#2 Is it possible to redeem this UTXO in the script address that has no datum

AFAIK, a UTxO locked by a Plutus script MUST have datum hash. Without it, it cannot be redeemed i.e. it is lost forever

This might arguably be a bug, because if there is no use in UTxO without datum, why can you create such a --tx-out in the first place. Perhaps there is already a github issue about that. If not, please create one - if would help to clarify matters.

#3 How to ensure that the --tx-out that is send to the script address will surely contain the datum

Answered above, the order of the options matters --help gives you an indication what must be followed by what.

PS: You hopefully did this on the testnet, right?

2 Likes
3

Wow. Thank you @tomdx for your time to reply.

The sequence of --tx-out and its associated --tx-out-datum-hash matters.

5

Is it possible to interact with a script 2 times in a single tx? What I’d like to do is make a deposit to the script and claim a utxo from the script in a single transaction. Or is it 1 script tx per transaction?

Yes, that is possible. A Tx can have multiple --tx-in from ordinary addresses and/or script addresses as well as multiple --tx-out to ordinary addresses and/or script addresses.

What you cannot do, is to have a Tx that creates an UTxO and then consume that very UTxO in the same Tx, which should be quite obvious because the Tx is already validated off-chain and in that phase non of the UTxOs that the Tx creates are known.

1 Like
6

Thank you! I figured it out and tried to delete my q, but glad to learn more from your reply!