Arbitrum TXID Graph omission causes permanent verificationHash mismatch and blocks downstream POI generation

[venusgrasshopper-droid]

Environment

• RAILGUN Engine: 9.6.0
• Chain: Arbitrum (42161)
• Wallet client: Railway Wallet

Affected POI transaction

Public unshield tx:

0x17756ad47053b97140da73455829e2a499c6223c26065353b84422d1aad0aae4

Internal railgunTxid:

2e340a52fac1f89e5bc7ba8593a5f72a38bbcc4880376e611af45b8c48604f16

Current state:

• On-chain unshield completed successfully.
• Railway reports MISSING INTERNAL POI / PRIVATE POI PENDING.
• targetSpent = 0 for the railgunTxid.
• The public tx remains in getChainTxidsStillPendingSpentPOIs.
• ppoi.info reports Missing.
• Repeated TXID synchronization does not make progress.

TXID tree failure

The local TXID tree repeatedly stops at:

txidIndex: 61169

Last valid verificationHash:

0x3b4babe44b477bbe2e67b2c6a9462a866dc89ab58fe3d9f24a1e81d0a617d6ac

The first verificationHash mismatch occurs in public transaction:

0xcc51cc50038fa53505d05fea42506ec40a68d52ee83adddd4b275894ccd22cac

Block:

491612310

RAILGUN contract:

0xFA7093CDD9EE6932B4eb2c9e1cde7CE00B1FA4b9

Reproduced Graph omission

Canonical Arbitrum receipt events for that public transaction are:

logIndex 1:
Nullified
treeNumber: 1
nullifier:
0x02baa71f623b794e2358cbb099151a2cf597e73e900322da68b73c50df95d6af

logIndex 4:
Unshield

logIndex 5:
Transact
treeNumber: 1
startPosition: 51528

logIndex 6:
Nullified
treeNumber: 1
nullifier:
0x1169a881dcca72f964547404c5a16b21e8dd18f2847d348987df2f0daac14350

logIndex 7:
Transact
treeNumber: 1
startPosition: 51530

However, quickSyncRailgunTransactionsV2 returns the RailgunTransaction associated with:

0x1169a881dcca72f964547404c5a16b21e8dd18f2847d348987df2f0daac14350

but does not return the preceding RailgunTransaction associated with:

0x02baa71f623b794e2358cbb099151a2cf597e73e900322da68b73c50df95d6af

The returned transaction is:

railgunTxid:
24114ecb79f4cee2a080e6b856a8f8598a7df3b6105e409aeb499375e760269d

Graph verificationHash:

0x329307d13d8257d6744c6271bd7324eba84f09b433ed5fb62489ed07fa333f26

Because the preceding RailgunTransaction is absent from the Graph result, Engine calculates:

0xb1ccb5faaeec31a2e1c743597f29abc307894c863c9c7f3c8e5ecc82289693de

instead.

We independently folded the canonical on-chain nullifiers in their actual order:

0x3b4babe44b477bbe2e67b2c6a9462a866dc89ab58fe3d9f24a1e81d0a617d6ac
-> 0x02baa71f623b794e2358cbb099151a2cf597e73e900322da68b73c50df95d6af
-> 0x1169a881dcca72f964547404c5a16b21e8dd18f2847d348987df2f0daac14350

Result:

0x329307d13d8257d6744c6271bd7324eba84f09b433ed5fb62489ed07fa333f26

This exactly matches the verificationHash returned for the second Graph transaction.

Therefore the returned verificationHash is internally consistent with the canonical two-transaction on-chain sequence, but the Graph query result omits the first RailgunTransaction required to reproduce that hash.

Engine behavior

Repeated synchronization produces:

• Invalid verification hash
• TXID index remains 61169
• targetSpent remains 0
• downstream transaction remains pending for Private POI
• POI generation cannot proceed because the target railgunTxid is not linked into the spent/unshield state

No verificationHash bypass, Engine source modification, or LevelDB modification was used.

Request

Could you please:

1. Check/reindex the Arbitrum TXID data around block 491612310.
2. Check the missing RailgunTransaction associated with nullifier:

0x02baa71f623b794e2358cbb099151a2cf597e73e900322da68b73c50df95d6af

3. Confirm whether there is an official recovery/resync procedure after the indexer data is corrected.
4. Confirm whether the affected downstream railgunTxid should then become available for normal POI generation:

2e340a52fac1f89e5bc7ba8593a5f72a38bbcc4880376e611af45b8c48604f16

[venusgrasshopper-droid]

Hi Brad, thanks — this is very helpful. I’m dealing with a very similar Arbitrum recovery case and would like to try the same targeted recovery path you described. My affected transaction is: Public tx: 0x17756ad47053b97140da73455829e2a499c6223c26065353b84422d1aad0aae4 Railgun TXID: 0x2e340a52fac1f89e5bc7ba8593a5f72a38bbcc4880376e611af45b8c48604f16 Railway shows *MISSING INTERNAL POI / PRIVATE POI PENDING*, although the unshield completed successfully on-chain. I have already reproduced a TXID-tree sync failure using the official Engine/Wallet code. In my test, PPOI accepts the current Graph transaction at TXID index 61180, while the Graph verificationHash indicates an omitted predecessor, so the normal Engine sync cannot advance through that point. Could you please share the exact recovery method you used for the successful transaction you mentioned? Specifically: 1. How did you rebuild the TXID Merkle proof from Squid/public data? 2. Which Engine function/API did you use to pass the proof for one exact Railgun TXID? 3. Which function/API submitted the targeted PPOI proof? 4. Did the recovery require modifying Railway’s local database, or can it be done through a separate Engine instance? 5. If I provide the Merkle proof/root and my diagnostic output, could the same targeted recovery procedure be applied to my Railgun TXID? I’m trying to avoid resetting or modifying my Railway data until the exact recovery path is confirmed. Any code snippet, function names, branch/commit, or script you used would be extremely helpful. Thank you. BradWMorris ***@***.***> 于2026年8月11日周二 07:29写道：

…

*bradwmorris* left a comment (Railgun-Community/engine#143) <#143 (comment)> Update: the Arbitrum index now contains the later transactions. We rebuilt the V2 TXID tree from public Squid data through index 61273. PPOI accepted the rebuilt root. Railway still could not recover. Its local V2 TXID tree was empty (latest index: -1). Incremental sync did not rebuild it. The targeted PPOI action also failed because the desktop worker sent the call to the Bridge IPC client instead of the engine. One targeted recovery worked after we: 1. rebuilt the TXID Merkle proof from public data; 2. checked the root with PPOI; 3. passed that proof to the engine for one exact TXID; 4. submitted one PPOI proof. The PPOI became Valid. The private change became spendable. Recovered public transaction: 0x956dfda7574cb2ebf7917cc96765e1b5f9d99a60d0c5838623072a66dd4a6fb4 Recovered Railgun TXID: 0x16923d2a63aa83527179a676ac0192e23aaa7d83d4aef32b2599342a903455af Two fixes still appear necessary: - rebuild an empty V2 TXID tree; - send the targeted PPOI worker call to the engine handler. — Reply to this email directly, view it on GitHub <#143?email_source=notifications&email_token=CE5U3ZCGK76YCPHC4V6ZX235JL7P7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMRVGI2TGNBUHA2KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5252534484>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CE5U3ZHRCHLHQ73JKOJRKE35JL7P7AVCNFSNUABFKJSXA33TNF2G64TZHMZTSMRSGEZDKNJRHNEXG43VMU5TKMJRGA3TANJYGI42C5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CE5U3ZFFBIDNYJ25I4GTNQD5JL7P7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMRVGI2TGNBUHA2KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/CE5U3ZAJ4XFFFMVTR6JYOU35JL7P7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMRVGI2TGNBUHA2KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[venusgrasshopper-droid]

Additional upstream transaction/history evidence

I found an additional wallet-history inconsistency that may help narrow down the missing POI state.

Railway shows two shield-history entries for the same amount:

58,845.246838 USDC
Shield fee: 147.481821 USDC

1. Actual successful shield

Public transaction:

0xf8cf508f38a4f123fa3b62d9dd31d78b566e538742bcf189fc1c6a7f082d0ed9

Arbiscan: Success
PPOI.info: Shield / Valid
Railway: SYNCED — Synced from encrypted on-chain history
2. Same-amount failed shield attempt

Public transaction:

0xb1f3e319b97df2fee999ec224f6d067e70bb03f8705e6a54d40fc4db730c8933

Arbiscan: Failed
Revert reason: ERC20: transfer amount exceeds balance
PPOI.info: No RAILGUN transaction found
Railway saved history still shows this entry as TIMED OUT

Therefore these are not two successful shield TXOs. The 0xb1f3... entry appears to be a stale/timed-out client-side saved transaction, while 0xf8cf... is the successful shield later recovered from encrypted on-chain history.

There is another important update:

Railway's current Pending Balances → Incomplete view now resolves the affected balance directly to the downstream unshield transaction:

0x17756ad47053b97140da73455829e2a499c6223c26065353b84422d1aad0aae4

It displays:

MISSING INTERNAL POI

and:

This transaction includes a change output. Please wait. Your wallet will make these funds spendable within a few minutes.

The available action is now Resync proofs.

This suggests Railway currently recognizes the exact downstream transaction, but the Internal POI still cannot be generated/recovered.

The corresponding Railgun TXID is:

0x2e340a52fac1f89e5bc7ba8593a5f72a38bbcc4880376e611af45b8c48604f16

Given the independently reproduced TXID-tree synchronization failure around index 61180, could this indicate that:

the transaction exists in wallet history;
but the required TXID Merkle / spent-TXO context for this exact Railgun TXID is incomplete or unavailable?

In particular, which Engine state/function would be the correct one to inspect to verify that the actual received TXO from the valid upstream path is correctly associated with the nullifier(s) of this Railgun TXID?

I can provide read-only local diagnostics and would prefer not to reset or modify the Railway database until the exact recovery path is understood.

[venusgrasshopper-droid]

Additional local-state evidence

I inspected a byte-for-byte diagnostic copy of Railway's local IndexedDB without opening or modifying the production database.

The downstream unshield public transaction is persisted locally:

0x17756ad47053b97140da73455829e2a499c6223c26065353b84422d1aad0aae4

Its change output is also present in the local V2 UTXO tree:

commitmentType: TransactCommitmentV2
hash: 09c32de21fe8c56a9c319a0bb1fb1011c75a9ce1f6f286705f3f49a0c6c4bb64
blockNumber: 491798921
utxoTree: 1
utxoIndex: 51602

However, this persisted TransactCommitmentV2 record has no railgunTxid field.

The expected Railgun TXID for this public transaction is:

2e340a52fac1f89e5bc7ba8593a5f72a38bbcc4880376e611af45b8c48604f16

I then searched every .ldb and .log file in the copied Railway IndexedDB for this exact value, both as ASCII hex and as raw 32-byte data. There were no matches.

By comparison, the public tx hash and its change commitment are both present in multiple persisted files.

This appears consistent with the wallet having successfully stored the on-chain UTXO/change output, while the corresponding V2 Railgun TXID association was never persisted/recovered.

Since this wallet also reproduces the V2 TXID-tree sync failure around index 61180, could the missing railgunTxid association on this change commitment be a downstream consequence of the TXID-tree/Graph synchronization failure?

If so, would the targeted TXID Merkle-proof recovery path you described be expected to restore this association / allow the Internal POI for this change output to be generated?

[triamazikamno]

I'm investigating this issue for https://github.com/triamazikamno/railoxide, which doesn't use this SDK, but is still affected. It looks like squid has missed events for 3 transactions at some point, which got eventually backfilled, but ppoi.fdi.network ingested incomplete data before the backfill and keeps building on the diverged state.
ppoi.fdi.network operator needs to rebuild the index in order to follow the canonical chain.
Railoxide is using indexed artifacts produced by https://github.com/triamazikamno/railgun-indexer and we've gotten around the issue by temporarily hardcoding omissions for events that ppoi operator is currently missing:

      public_txid_compatibility_omissions:
        - block_number: 491612310
          transaction_hash: "0xcc51cc50038fa53505d05fea42506ec40a68d52ee83adddd4b275894ccd22cac"
          railgun_transaction_index: 0

        - block_number: 491644057
          transaction_hash: "0x24f3eed23bececeaca55316cb7bae7d2a63f78640705bfaee9ccdb8ee342edfb"
          railgun_transaction_index: 0

        - block_number: 491943298
          transaction_hash: "0xd555fe412c1fa826ba47d8edb7cecfcbb89cad54c7b351048cbad786dffe7689"
          railgun_transaction_index: 0

        - block_number: 491943298
          transaction_hash: "0xd555fe412c1fa826ba47d8edb7cecfcbb89cad54c7b351048cbad786dffe7689"
          railgun_transaction_index: 1

Not sure if this is helpful to your case, but if you have a way to remove these from the public txid cache inside your local storage somehow, then it should be able to derive a matching root