feat: Add archive_unstable_transactionReceipt for efficient transaction lookup

[Nathy-bajo]

resolves #181

This PR implements archive_unstable_transactionReceipt to provide efficient, stateless transaction location queries without requiring full block downloads

[Nathy-bajo]

Please review @bkchr @josepot

Happy New Year also!

[josepot]

Happy new year @Nathy-bajo! 🎉

I’m with you on the main points:

• Having to download block bodies just to check inclusion is pretty bad.
• We definitely need an RPC that facilitates finding if and where a tx has been included.
• And yeah, ideally the whole archive group of functions should be stateless (so it can be served over HTTP).

That said, I think there are a couple of real issues with this PR as-is:

1) This shouldn’t go into archive_v1

The spec is pretty clear that we shouldn’t add new methods to archive_v1.
This belongs in archive_v2. So IMO this PR should target archive_unstable first, while archive_v2 is being stabilized.

2) The API that you proposed is a bit off

2.a) Inclusion isn’t binary

A tx can show up more than once:

• in multiple non-finalized forks,
• in more than one finalized block (account removed after a transfer_allow_death, then receievs funds and re-submits, etc),
• and in the extreme, even twice in the same block 🤯

I think the method should just return all occurrences (i.e: Vector<(block_hash, index)>, or something similar).

2.b) The output leaks business logic / FRAME assumptions

For instance, the proposed success/failed status punches into the business-logic layer. The archive RPC should ideally stick to data facts: which blocks and which extrinsic indexes contain the transaction.

Whether a transaction “succeeded” is not fully canonical at this layer:

• Consumers can query System.Events (or equivalent) and interpret events to derive outcomes.
• Even then, interpretation is FRAME- and call-pattern-specific. Example: proxy execution, if the proxied call fails, it won't bubble up a System.ExtrinsicFailed event, so the consumer will have to check into the inner-events anyways.

In other words: event interpretation belongs in a higher layer, not in the archive RPC surface. Same for all those other fileds: fee, gasUsed, logs, etc.

---

Given all that, I think the best path is: first solve this properly in chainHead_v2 (which should be the natural place for this kind of “tx landed where?” functionality), and then do the archive_v2 improvements. archive_v2 should be much easier once chainHead has the right building blocks.

On our side: as soon as our 2026 budget gets approved, we’ll be actively working on these fronts.

[Nathy-bajo]

@josepot Thank you for the detailed feedback. I’ve reworked the solution as archive_unstable_transactionReceipt. It efficiently returns all transaction locations as an array of block/position data without FRAME assumptions. It also stays stateless over HTTP and sets things up nicely for future chainHead_v2(archive_v2_transactionReceipt) improvements.

[Nathy-bajo]

@bkchr @josepot Can I proceed with the implementation in the polkadot-sdk?