Upstream Broadcaster report

This manual targets 0.1.0-beta.3. Read the source and availability policy before installing. Historical reports retain their original scope.

Historical evidence, not a new 0.1.0-beta.3 verification. Read the record's date and version before interpreting any PASS result.

Status: historical, metadata-minimal diagnostic for the first unresolved payer lineage. A later isolated lineage completed Gate B successfully on its first Broadcaster submission. This report remains useful for the earlier failure and contains no wallet address, nullifier, memo, intent ID, signature, fee-signer value, RPC credential or raw encrypted payload.

Summary

On Arbitrum One with native USDC, the pinned official Wallet SDK and Waku client can discover authorized Broadcasters, build a V2 private ERC-20 transfer, create its proof and populate calldata that succeeds under three independent eth_estimateGas calls. A bounded funded trial nevertheless received no usable transaction hash from two selected Broadcaster identities. One encrypted server response was the sanitized Unknown Broadcaster error.; another client/send failure could not be classified. Nullifier-based recovery found no canonical transaction and the payer balance did not change.

The local payer correctly keeps those outcomes ambiguous and will not issue a fresh spend from that lineage. The subsequent success shows that the public Broadcaster path was not categorically unavailable; it does not explain the two earlier operator responses. Additional blind retries of the original nullifiers remain unsafe and unnecessary.

Subsequent isolated result

After the original retry cap, a separate payer lineage was funded and allowed to become fully Spendable. With the same pinned SDK/Waku versions, trust configuration, token and bounded command path, a new 0.01 USDC payment:

• passed no-send proof generation and final-calldata quorum simulation;
• used a 0.066912 USDC Broadcaster fee below its explicit ceiling;
• returned a hash that matched nullifier-derived canonical recovery;
• mined on the first submission with no payer EVM self-signer;
• completed output PPOI and PPOps reconciliation to PAID.

This changes the project Gate B result to PASS, but it does not retroactively classify the first lineage’s sanitized failures or permit those nullifiers to be released.

Versions and profile

network                              Arbitrum One (42161)
asset                                native USDC
RAILGUN TXID version                 V2 Poseidon Merkle
@railgun-community/wallet            10.9.0
@railgun-community/engine            9.6.0
@railgun-community/shared-models      8.0.1
waku-broadcaster-client-node          9.1.1
Node.js                               >=22 (CI uses pinned Node 24)

The fee-signer list and Waku pubsub topic were pinned locally from an independently reviewed configuration. Quote admission required the expected network/token, a trusted signature, supported version, positive fee, reliability/lifetime floors and enough available wallets.

Reproduced facts

1. A non-financial preflight repeatedly obtained at least five LightPush and five Filter peers and valid native-USDC quotes.

2. A no-send run synchronized a full payer, calculated a bounded fee, generated the transfer proof, populated the proxy transaction and wrote no journal or Waku message.

3. A later no-send diagnostic used the same production preparation path and observed:

   Wallet SDK pre-proof gas estimate   1128365
   final populated call estimate       1123239
   final simulation RPC agreement      3 of 3
   point-in-time token fee              64892 atomic USDC
   payment submitted                    false
   journal record created               false

4. The funded lineage sent one initial encrypted request and three bounded same-nullifier variants. The first three targeted one selected identity; the last excluded it and selected a second identity from 14 eligible unique identities.

5. No attempt returned a usable hash. One selected Broadcaster returned the server’s sanitized UNKNOWN_ERROR; another path ended in an unclassified post-send client/transport error.

6. Recovery more than 15 minutes after the final attempt found no canonical transaction for the reserved nullifiers. The private balance and receiver intent remained unchanged. No fee was observed as charged.

7. A later fresh-intent preparation generated a proof, but its read-only journal admission check found that at least one selected input belonged to the unresolved lineage. It returned SUBMISSION_ALREADY_RECORDED before final simulation or Waku. No new journal record or payment was created.

Interpretation

The final on-chain simulation executes the exact target and calldata, including proof verification, under three public RPC views. It makes malformed final calldata or an invalid proof an unlikely cause of this specific result. It does not reproduce the selected Broadcaster’s funded sender, provider, cached fee, fee-note extraction, PPOI validation, wallet selection, nonce management or send runtime.

The reference server converts any non-allowlisted internal error to Unknown Broadcaster error. when devLog is false. That response therefore does not identify which private stage failed, and it cannot prove that the Broadcaster did not reach its chain-send boundary.

The follow-up admission result also means the Wallet SDK’s current Spendable balance cannot safely be used as fresh diagnostic capital. Resolving the old lineage or providing independently fresh inputs is a prerequisite for another funded attempt; increasing the fee ceiling is not.

Maintainer questions

1. Is client 9.1.1 expected to interoperate with every Broadcaster version admitted by its advertised min/max version range on Arbitrum?
2. Which server stages can currently produce a non-allowlisted error after successful decryption: gas-wallet selection, gas estimation, fee extraction, fee-cache validation, PPOI validation, transaction execution or RPC send?
3. Can production responses expose a stable, non-sensitive stage/error code while keeping raw provider and transaction errors sanitized?
4. Is there a supported way for a controlled client to request detailed error categories without setting the package-global development flag or exposing transaction secrets?
5. Is regeneration with the exact same nullifiers but a new proof, fee ID and different Broadcaster identity an officially supported recovery operation?
6. Can maintainers provide a local integration fixture that validates the encrypted request through fee extraction and PPOI checks without sending a public transaction?

Reproduction references

• PPOps final-call and prepare-admission guards: commits b6d5e3d and d70057e
• Passing public verification: GitHub Actions run 33337865296
• Full bounded workflow and outcome: Gate B runbook
• Security disposition: Broadcaster differential review

The maintainers can reproduce the client-side boundary with prepare-broadcaster: it performs full proof/population and exact-call quorum simulation, but deliberately creates no encrypted Waku request and moves no funds. A new funded reproduction should use fresh, independently bounded funds and must not reuse or delete the unresolved lineage recorded above.