[BUG] - Dijkstra: missing local-submission support for intentionally phase-2-invalid transactions after CIP-0167

Start with CIP-0167's trusted local-submission section, then trace the Dijkstra CLI path behind cardano-cli dijkstra transaction build/build-raw, where --script-invalid was removed, and the node/consensus local-submission path returning ValidationTagMismatch Phase2Valid. The issue names no source files, so map those entry points and the ledger collateral/phase-2 rules first. Done means a specified local-submission intent parameter, not CBOR isValid=false, with tests for collateral-only inclusion, nested batches, all-passing transactions, rollback and resubmission.

Internal/External

Internal

Area

Plutus Related to Plutus Scripts.

Summary

Dijkstra removes --script-invalid from transaction construction, consistent with CIP-0167, but no replacement for expressing trusted local submission intent was identified in the tested tooling.

Consequently, an intentionally phase-2-invalid transaction cannot be submitted through the supported CLI/local-submission path for inclusion with collateral-only effects. This prevents end-to-end validation of collateral handling and phase-2 failure atomicity, including for nested transactions.

This is a node/consensus/API/CLI integration gap, not a request to restore isValid = false in standalone transaction CBOR.

Environment

Observed with:

• cardano-node: koslambrou/prepare-11.2
• cardano-cli: koslambrou/prepare-11.2
• Recorded node and CLI revision: 26912363abc3a6217cb4f4c6971ae9beb092f2b0
• Era: Dijkstra

Relationship to CIP-0167

CIP-0167 identifies the trusted local-submission use case:

The only remaining use is local submission from trusted clients (like cardano-cli), where the node reads the flag to avoid unintended collateral burn.
This use is important, but perhaps the transaction bytes are not the best layer to encode that intent.

It suggests a possible replacement:

The trusted local client submission use case might be better expressed in a different way (for example, as a Node-to-Client submit parameter), rather than embedded in the transaction bytes.

The CIP does not mandate that particular interface. The issue is the absence of an identified supported replacement for the removed capability.

Injecting a false validity flag into transaction CBOR is not a valid workaround: the transitional standalone encoding specified by CIP-0167 accepts the legacy flag only when it is true.

Actual behavior

Attempting to construct an intentionally phase-2-invalid transaction fails locally:

cardano-cli dijkstra transaction build ... --script-invalid ...
Invalid option `--script-invalid'

cardano-cli dijkstra transaction build-raw ... --script-invalid ...
Invalid option `--script-invalid'

Constructing and signing a transaction without that option, with a genuinely failing Plutus script and adequate collateral, then submitting normally results in rejection:

ValidationTagMismatch Phase2Valid (FailedUnexpectedly ...)

This also occurs when the failing script executes only in a nested child and the parent supplies fees and collateral.

Rejecting unexpected script failure protects against unintended collateral loss. However, no supported way was identified to explicitly request the accepted-invalid path instead.

End-to-end behavior that cannot be validated

Without a supported submission mechanism, the following behavior cannot be exercised through local submission, block inclusion, and subsequent node-state queries.

Collateral collection and return

• A phase-2-invalid transaction can be admitted and included with collateral-only effects.
• The correct ADA amount is collected under the applicable total-collateral and collateral-return rules.
• Excess collateral and native assets are returned correctly.
• Ordinary spending inputs remain unspent, and ordinary outputs are not created.
• Resubmission cannot collect the same collateral twice.

Successful script execution and rejected script failure do not exercise these state transitions.

Sponsored execution in nested transactions

• A parent can provide fees and collateral for scripts executed only by its children.
• Failure in a child can result in collateral-only inclusion of the complete batch.
• Only the permitted parent-level collateral effects occur; neither the parent nor any child partially settles.
• Failure position, including different children or the parent, does not permit ordinary effects from otherwise successful components to persist.

Atomicity across ledger operations

For an included phase-2-invalid batch containing payments and stateful operations, verify that collateral processing does not commit ordinary effects such as:

• Asset transfers, minting, or burning.
• Registrations, deregistrations, delegation, deposits, or refunds.
• Reward-account withdrawals or direct deposits.
• Governance proposals or votes.
• Treasury donations.

Applicable phase-1 checks and collateral requirements must still be enforced. Merely observing rejection with unchanged state does not establish the behavior of an included phase-2-invalid batch.

Submission-intent semantics

The replacement interface needs defined, testable behavior for:

• A genuinely failing transaction submitted with explicit intent to allow collateral collection.
• An unexpectedly failing transaction submitted without that intent.
• An all-passing transaction submitted with the corresponding invalidity expectation or permission.

The last case depends on whether the replacement expresses an expected validation result or permission to collect collateral. That distinction needs to be specified.

Rollback and resubmission

• Rolling back a block containing a phase-2-invalid transaction reverses collateral collection and collateral-return outputs consistently.
• Resubmission after rollback follows the defined local-submission intent and cannot produce duplicate effects.

Expected behavior / requested resolution

Please provide or identify a supported end-to-end mechanism for a trusted local client to request phase-2-invalid inclusion without encoding a false validity flag in standalone transaction CBOR.

The mechanism should:

• Preserve default protection against unintended collateral loss.
• Support ordinary Dijkstra transactions and complete nested batches.
• Be available through the relevant node/consensus/API interfaces and CLI tooling.
• Define submission-intent semantics, including behavior when all scripts pass.
• Preserve applicable phase-1 validation and collateral requirements.