Skip to content

Inline datums should follow TxCodecOptions.plutusData #611

Description

@solidsnakedev

Summary

The SDK writes a new inline datum with Data.DEFAULT_CBOR_OPTIONS, whatever options the caller passes to the transaction encoder. After #610, witness datums and redeemer data follow TxCodecOptions.plutusData. With CBOR.TX_CANONICAL_OPTIONS or a custom plutusData, the inline datums in the same transaction therefore use a different layout from the rest of its Plutus data.

Cause

DatumOption.ts L87 writes the bytes inside tag 24 as OriginalBytes.get(datum) ?? PlutusData.toCBORBytes(datum.data), with no options. The options passed to Transaction.toCBORHex reach the outer encoder only; TransactionBody, TxOut and DatumOption never see them.

Fix

Pass CBOR.TxCodecOptions down through TransactionBody, TxOut and DatumOption, and write a new inline datum with plutusData. Decoded inline datums keep their original bytes (#603). This fits with #585, where the builder takes codecOptions.

Regression test

  • An inline datum with fields, a list and a map, encoded with TX_DEFAULT_OPTIONS, TX_CANONICAL_OPTIONS and { ledger: CML_DEFAULT_OPTIONS, plutusData: PLUTUS_DATA_OPTIONS }: the bytes inside tag 24 equal Data.toCBORBytes(datum, plutusData).
  • Under TX_DEFAULT_OPTIONS the transaction keeps today's bytes.
  • A decoded inline datum keeps its bytes through addVKeyWitnessesHex.
  • Devnet: the node accepts a transaction with each option set and returns the datum as written.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions