Invalid request: specified both 'datumHash' & 'datum'

[bmoore117]

When using the Kupmios provider for lucid-evo, the following code, which is meant to read from a reference input, mint a token with an inline datum, and pay it out to a given address fails with the titular error.

let tx = await lucid.newTx()
.readFrom(deployedContract)
.mintAssets({[assetName]: 1n}, redeemer)
.pay.ToAddressWithData(
    process.argv[6], // sc address in bech32 addr_1 form
    {kind: "inline", value: datum},
    {[assetName]: 1n},
  )
.validFrom(lower.getTime())
.validTo(upper.getTime())
.addSigner(process.argv[7]) // user vkey in bech32 addr_1 form
.complete({localUPLCEval: false});

where datum is defined as

const SubscriptionDetails = Data.Object({
    lock_until: Data.Integer(),
    billable_amount: Data.Integer(),
    merchant_vk: Data.Bytes()
});

let datum = Data.to(
    // now.getTime() is in milliseconds, so add 5 minutes in millis
    { lock_until: BigInt(now.getTime()) + 300000n, billable_amount: 5000n, merchant_vk: process.argv[2]  }, // merchant vkey hash
    SubscriptionDetails,
);

and in practice for me evaluates to d8799f1b00000193c261a8e4191388581cbf67d1fb1b895288bfa25aa949aa56f20fc38915ae2db199990881f6ff
which is a valid value you can paste into any CBOR decoder. For reference, deployedContract evaluates to:

[
  {
    txHash: '6fa82d3f7b8ec496ddb84b731c17a393d685c8e85110023077eb44df052ea5e1',
    outputIndex: 0,
    address: 'addr_test1wrar9ud8rc94k9vnyy4syxjhx5qdepkkwcyf3qdv6gf8ugsx60vwp',
    assets: { lovelace: 36656550n },
    datumHash: '923918e403bf43c34b4ef6b48eb2ee04babed17320d8d1b9ff9ad086e86f44ec',
    datum: undefined,
    scriptRef: {
      type: 'PlutusV3',
      script: '59204259203f010100333232...'
    }
  }
]

There seems to be a bug in the implementation somewhere here: I should be able to specify a reference input, whose datum types or lack thereof should have nothing to do with any datum types present in what I mint and output. I can do this transaction using the cardano-cli, no issue, and can supply example code if needed. Can someone investigate?

[keyan-m]

The error itself is coming from Ogmios. It seems fine to have an undefined datum with a populated datumHash.

Looking at the source code for readFrom, it seems this part is leading to a datum value which its hash does not match the given one:

lucid-evolution/packages/lucid/src/tx-builder/internal/Read.ts

Lines 19 to 26 in 76cdb3f

	if (utxo.datumHash) {
	const data = yield* Effect.tryPromise({
	try: () => datumOf(config.lucidConfig.provider, utxo),
	catch: (cause) => readError(cause),
	});
	utxo.datum = Data.to(data);
	}

@bmoore117 would it possible for you to observe the packet LE is sending to Kupmios (network tab in browser, tcpdump or wireshark otherwise)?

[bmoore117]

I assume ultimately you're looking for the transaction CBOR, at least that's what I've got. It's 84a900d90102818258206fa82d3f7b8ec496ddb84b731c17a393d685c8e85110023077eb44df052ea5e1010182a300581d70fa32f1a71e0b5b1593212b021a573500dc86d676089881acd2127e2201821a0013991ca1581cfa32f1a71e0b5b1593212b021a573500dc86d676089881acd2127e22a14b000643b05465737453756201028201d818582ed8799f1b00000193d6cd20f9191388581cbf67d1fb1b895288bfa25aa949aa56f20fc38915ae2db199990881f6ff82581d60220fa4e22e4227267dabb1707e995ba2e49068cc07979a59db1cdb231b00000001b71e1f21021a00049fa4031a040ad753081a040ad69f09a1581cfa32f1a71e0b5b1593212b021a573500dc86d676089881acd2127e22a14b000643b054657374537562010b582000000000000000000000000000000000000000000000000000000000000000000ed9010281581c220fa4e22e4227267dabb1707e995ba2e49068cc07979a59db1cdb2312d90102818258206fa82d3f7b8ec496ddb84b731c17a393d685c8e85110023077eb44df052ea5e100a200d901028182582000000000220fa4e22e4227267dabb1707e995ba2e49068cc07979a59db1cdb23584000f899d39b17fd5d66c192c4b50d343e42f7235b30504c8ae7619f93c828dc6dce4568dd69177c551828492d777a6727fd66c2fbccbda8c2aeed92032c99790a0581840100d87980820000f5f6

More legibly, it's

[
    {
        0: 258_1([
            [
                h'6fa82d3f7b8ec496ddb84b731c17a393d685c8e85110023077eb44df052ea5e1',
                1,
            ],
        ]),
        1: [
            {
                0: h'70fa32f1a71e0b5b1593212b021a573500dc86d676089881acd2127e22',
                1: [
                    1284380_2,
                    {
                        h'fa32f1a71e0b5b1593212b021a573500dc86d676089881acd2127e22': {h'000643b054657374537562': 1},
                    },
                ],
                2: [
                    1,
                    24_0(<<121_0([_
                        1734475587833_3,
                        5000_1,
                        h'bf67d1fb1b895288bfa25aa949aa56f20fc38915ae2db199990881f6',
                    ])>>),
                ],
            },
            [
                h'60220fa4e22e4227267dabb1707e995ba2e49068cc07979a59db1cdb23',
                7367171873_3,
            ],
        ],
        2: 303012_2,
        3: 67819347_2,
        8: 67819167_2,
        9: {
            h'fa32f1a71e0b5b1593212b021a573500dc86d676089881acd2127e22': {h'000643b054657374537562': 1},
        },
        11: h'0000000000000000000000000000000000000000000000000000000000000000',
        14: 258_1([
            h'220fa4e22e4227267dabb1707e995ba2e49068cc07979a59db1cdb23',
        ]),
        18: 258_1([
            [
                h'6fa82d3f7b8ec496ddb84b731c17a393d685c8e85110023077eb44df052ea5e1',
                0,
            ],
        ]),
    },
    {
        0: 258_1([
            [
                h'00000000220fa4e22e4227267dabb1707e995ba2e49068cc07979a59db1cdb23',
                h'00f899d39b17fd5d66c192c4b50d343e42f7235b30504c8ae7619f93c828dc6dce4568dd69177c551828492d777a6727fd66c2fbccbda8c2aeed92032c99790a',
            ],
        ]),
        5: [[1, 0, 121_0([]), [0, 0]]],
    },
    true,
    null,
]

I don't pretend to be able to read any of this stuff, but if it helps, this is what LE is sending to Kupmios for evaluation

[keyan-m]

The packet itself should be a JSON that contains a list of UTxO pairs (in addition to the CBOR) which my guess is where the problem is coming from. So if you could also observe that JSON object, that'd be very helpful.

However, since this is happening at the evaluation phase, you should be able to avoid this altogether by updating LE, and removing the object you're passing to the .complete() method. Local UPLC evaluation should be working with the latest version.

Also by referring to the era's CDDL file, you can get a better read on its contents 🙂
https://github.com/IntersectMBO/cardano-ledger/blob/master/eras/conway/impl/cddl-files/conway.cddl#L515-L518