Add distinct operation types for collateral operations

[linconvidal]

Problem: Current implementation doesn't distinguish between regular and collateral operations, making it impossible to understand transaction structure from the API response. This is particularly critical for phase 2 validation failures where collateral operations succeed while regular operations fail.

Solution: Introduce new operation types that reflect Cardano's transaction body structure:

New operation types

• "input" - Regular inputs from body.inputs[] array
• "output" - Regular outputs from body.outputs[] array
• "collateralInput" - Collateral inputs from body.collateralInputs[] array
• "collateralReturn" - Collateral return from body.collateralReturn object

Network_index assignment

• Regular inputs: position in body.inputs[]
• Regular outputs: position in body.outputs[]
• Collateral inputs: position in body.collateralInputs[]
• Collateral return: always 0 (single object in transaction body)

Operation visibility rules

Transaction Type	Regular Operations	Collateral Operations
Regular transaction	Show all with appropriate status	Omit (not present)
Successful smart contract	Show all with status=success	Omit (not consumed)
Failed smart contract (phase 2)	Show all with status=invalid	Show all with status=success

Implementation notes:

• Add new operation types to NetworkOptionsResponse
• Detect operation type from transaction body structure, not from success/failure
• For successful smart contracts, collateral operations are omitted entirely (not shown with a special status) to avoid balance calculation issues
• This ensures search/transactions success filter works correctly

Design decision: I also considered adding an "unused" status for collateral operations in successful transactions, but this would create conflicts with search filters and balance calculations. Omitting unused operations is cleaner and avoids logical paradoxes.

Visual representation of the proposal

graph TB
    subgraph "Transaction Types"
        TX1[Regular Transaction]
        TX2[Successful Smart Contract]
        TX3[Failed Smart Contract]
    end
    
    TX1 --> R1[✓ input<br/>✓ output]
    TX1 --> R2[✗ collateralInput<br/>✗ collateralReturn]
    
    TX2 --> S1[✓ input status=success<br/>✓ output status=success]
    TX2 --> S2[✗ collateralInput omitted<br/>✗ collateralReturn omitted]
    
    TX3 --> F1[✓ input status=invalid<br/>✓ output status=invalid]
    TX3 --> F2[✓ collateralInput status=success<br/>✓ collateralReturn status=success]
    
    style TX1 fill:#f9f9f9,stroke:#333,stroke-width:2px
    style TX2 fill:#f9f9f9,stroke:#333,stroke-width:2px
    style TX3 fill:#f9f9f9,stroke:#333,stroke-width:2px
    style R1 fill:#f9f9f9,stroke:#333,stroke-width:1px
    style R2 fill:#ffe6e6,stroke:#333,stroke-width:1px
    style S1 fill:#e6ffe6,stroke:#333,stroke-width:1px
    style S2 fill:#ffe6e6,stroke:#333,stroke-width:1px
    style F1 fill:#ffe6e6,stroke:#333,stroke-width:1px
    style F2 fill:#e6ffe6,stroke:#333,stroke-width:1px

Loading

Operation type and status matrix:

graph LR
    subgraph "Operation Types"
        I[input<br/>network_index: position in body.inputs]
        O[output<br/>network_index: position in body.outputs]
        CI[collateralInput<br/>network_index: position in body.collateralInputs]
        CR[collateralReturn<br/>network_index: 0]
    end
    
    subgraph "Status Values"
        SUCCESS[success<br/>Operation executed]
        INVALID[invalid<br/>Operation attempted but failed]
    end
    
    I --> SUCCESS
    I --> INVALID
    O --> SUCCESS
    O --> INVALID
    CI --> SUCCESS
    CR --> SUCCESS
    
    style I fill:#f9f9f9,stroke:#333,stroke-width:2px
    style O fill:#f9f9f9,stroke:#333,stroke-width:2px
    style CI fill:#f9f9f9,stroke:#333,stroke-width:2px
    style CR fill:#f9f9f9,stroke:#333,stroke-width:2px
    style INVALID fill:#ffe6e6,stroke:#333,stroke-width:2px
    style SUCCESS fill:#e6ffe6,stroke:#333,stroke-width:2px

Loading