Problem
Core's `RebuildListFromBlock` applies provider special transactions (ProRegTx / ProUpServTx / ProUpRegTx / ProUpRevTx) in `block.vtx` order, so when two updates for the same proTxHash land in the SAME block, the later-positioned one wins per field. Downstream consumers that aggregate a wallet's retained provider transactions (e.g. dashpay/platform's masternode list, see dashpay/platform#4120) need that in-block position to reproduce Core's latest-wins semantics — but it is not recoverable from the retained records:
- `BlockInfo` carries only `{ height, block_hash, timestamp }` (`transaction_context.rs`) — no in-block index.
- `TransactionRecord` has no position field, and `account.transactions()` returns a `BTreeMap<Txid, TransactionRecord>`, so iteration order is txid order, not processing order.
- The index exists at processing time but is discarded: `key-wallet-manager/src/process_block.rs:60` iterates `for tx in &block.txdata` (which IS `block.vtx` order) and builds a single `BlockInfo::new(height, block_hash, time)` (line ~31) cloned for every tx in the block.
Result: two same-block provider updates to the same field aggregate in arbitrary (txid/feed) order downstream, which can disagree with the DML.
Proposed fix
Thread the `.enumerate()` index from block processing into the retained record — either an `index: u32` on `BlockInfo` (natural home: it's per-placement data) or a dedicated field on `TransactionRecord`. Persistence round-trip should retain it.
Downstream is already mechanism-ready: platform's aggregation sorts by `(height, position)` and currently passes `position = 0` with a comment pointing here; once the field exists the caller just reads it.
Context
Follow-up in the provider-key/masternode series: #876 (payload retention), #879 (BLS operator derivation), #881 (gate-free provider key API), #884/#885 (platform node id), #887 (PlatformNodeId byte order). Same consumer, same pin-bump train.
Problem
Core's `RebuildListFromBlock` applies provider special transactions (ProRegTx / ProUpServTx / ProUpRegTx / ProUpRevTx) in `block.vtx` order, so when two updates for the same proTxHash land in the SAME block, the later-positioned one wins per field. Downstream consumers that aggregate a wallet's retained provider transactions (e.g. dashpay/platform's masternode list, see dashpay/platform#4120) need that in-block position to reproduce Core's latest-wins semantics — but it is not recoverable from the retained records:
Result: two same-block provider updates to the same field aggregate in arbitrary (txid/feed) order downstream, which can disagree with the DML.
Proposed fix
Thread the `.enumerate()` index from block processing into the retained record — either an `index: u32` on `BlockInfo` (natural home: it's per-placement data) or a dedicated field on `TransactionRecord`. Persistence round-trip should retain it.
Downstream is already mechanism-ready: platform's aggregation sorts by `(height, position)` and currently passes `position = 0` with a comment pointing here; once the field exists the caller just reads it.
Context
Follow-up in the provider-key/masternode series: #876 (payload retention), #879 (BLS operator derivation), #881 (gate-free provider key API), #884/#885 (platform node id), #887 (PlatformNodeId byte order). Same consumer, same pin-bump train.