<blockquote>
<p>AIUI, when using the blockfrost.io API, the <code>tx_index</code> field in a redeemer contains the index of the enclosing transaction's input that it consumes (is that true ?).</p>
</blockquote>
<p>The index holds different meaning for different purposes. For instance, if minting policies are involved in a transaction, index for a particular minting policy would be it's position in lexicographic ordering of the involved minting policies. For more information, see <code>indexOf</code> function in <a href="https://github.com/input-output-hk/cardano-ledger/releases/latest/download/alonzo-ledger.pdf" rel="nofollow noreferrer">Alonzo ledger documentation</a>. So, if you are only looking for indexes where <code>purpose</code> in response is set to <code>spend</code> then your understanding of <code>tx_index</code> is correct.</p>
<p>Now any output which is inside <a href="https://github.com/input-output-hk/cardano-ledger/blob/642b86e3263a5ffdc43b89b0b4130475c309e1a2/eras/babbage/test-suite/cddl-files/babbage.cddl#L54" rel="nofollow noreferrer"><code>transaction_input</code></a> then it is indeed getting consumed by the transaction (if it is of course successful), reference input(s) cannot be inside this <code>transaction_input</code> list. Provider's might mention it in input(s) but then they would also mention whether it's a reference input (in which case you can ignore it) or not. So, yes, your understanding on ignoring reference input(s) to determine for index is correct.</p>

CC BY-SA 4.0
2023-08-29T06:03:16.860Z
2023-08-29T06:03:16.860Z
Sourabh
<p>AIUI, when using the blockfrost.io API, the <code>tx_index</code> field in a redeemer contains the index of the enclosing transaction's input that it consumes (is that true ?).</p>
<p>However, with reference inputs, it seems that in this API the reference inputs and &quot;regular&quot; inputs are all merged in the transaction's <code>utxos.inputs</code> list.</p>
<p>In that case, it looks the <code>tx_index</code> field in the redeemer no longer matches the index of the referenced input in the <code>inputs</code> list, but rather the position of the Nth <em>non-reference</em> input in the list.</p>
<p>Example:</p>
<ul>
<li>without reference inputs:</li>
</ul>
<pre><code>utxos.inputs = [i1,i2,i3]`
redeemer.tx_index=2
</code></pre>
<p>In that case, the redeemer points at <code>i3</code></p>
<ul>
<li>with reference inputs (marked as <code>ri</code>):</li>
</ul>
<pre><code>utxos.inputs = [ri1, ri2, i1,i2,i3]`
redeemer.tx_index=2
</code></pre>
<p>In that case, the redeemer <em>also</em> points at <code>i3</code> because the reference inputs are ignored in the indexing.</p>
<p>Can someone confirm that this understanding is correct, or provide the correct way of interpreting the redeemer's <code>tx_index</code> field ?</p>

<blockfrost><redeemer><plutus-v2>
blockfrost.io API, reference inputs and redeemer tx_index
# blockfrost.io API, reference inputs and redeemer tx_index

(Asked by: username_0 on 2023-08-28)

AIUI, when using the blockfrost.io API, the tx_index field in a redeemer contains the index of the enclosing transaction's input that it consumes (is that true ?).
However, with reference inputs, it seems that in this API the reference inputs and "regular" inputs are all merged in the transaction's utxos.inputs list.
In that case, it looks the tx_index field in the redeemer no longer matches the index of the referenced input in the inputs list, but rather the position of the Nth non-reference input in the list.
Example:

without reference inputs:

utxos.inputs = [i1,i2,i3]`
redeemer.tx_index=2

In that case, the redeemer points at i3

with reference inputs (marked as ri):

utxos.inputs = [ri1, ri2, i1,i2,i3]`
redeemer.tx_index=2

In that case, the redeemer also points at i3 because the reference inputs are ignored in the indexing.
Can someone confirm that this understanding is correct, or provide the correct way of interpreting the redeemer's tx_index field ?

**Tags:** blockfrost, redeemer, plutus-v2

---

## 1 answers

### Answer by username_1 on 2023-08-29. Score: 1 | Accepted answer

> AIUI, when using the blockfrost.io API, the `tx_index` field in a redeemer contains the index of the enclosing transaction's input that it consumes (is that true ?).

The index holds different meaning for different purposes. For instance, if minting policies are involved in a transaction, index for a particular minting policy would be it's position in lexicographic ordering of the involved minting policies. For more information, see `indexOf` function in [Alonzo ledger documentation](https://github.com/input-output-hk/cardano-ledger/releases/latest/download/alonzo-ledger.pdf). So, if you are only looking for indexes where `purpose` in response is set to `spend` then your understanding of `tx_index` is correct.

Now any output which is inside [`transaction_input`](https://github.com/input-output-hk/cardano-ledger/blob/642b86e3263a5ffdc43b89b0b4130475c309e1a2/eras/babbage/test-suite/cddl-files/babbage.cddl#L54) then it is indeed getting consumed by the transaction (if it is of course successful), reference input(s) cannot be inside this `transaction_input` list. Provider's might mention it in input(s) but then they would also mention whether it's a reference input (in which case you can ignore it) or not. So, yes, your understanding on ignoring reference input(s) to determine for index is correct.


---

