N13/pos mode with tx watch

[n13]

Note: This unfortunately requires new testnet.

I think we should make a branch of main for this.

Update: Targeting new_testnet_planck - which is our new app running on planck

• POS system subscribes to transaction pool and checks incoming transactions
• Takes less than 1 second
• Block inclusion - settlement - still takes 10+ seconds and up to minutes
• This is a quick confirmation between trusted parties

[n13]

PR #421 Review: POS Mode with TX Watch

Summary: Adds a real-time transaction watch to the POS flow so the merchant sees payment confirmation in <1s (from the tx pool, before block finality). Also upgrades Rust crypto crates to match the new Planck testnet, changes the HD derivation path to fully hardened, and adds dev account handling.

---

Overall

This is a solid feature. The WebSocket subscription to the tx pool for instant payment feedback is a great UX win for POS. The Rust crate upgrades are necessary for the new testnet. The code is clean and focused.

That said, there are some things worth flagging:

---

Issues

1. Amount matching is exact-only — fragile for POS use

Note: Not really an issue... crypto is precise and >= isn't a lot better than ==

final expectedPlanck = _fmt.parseAmount(widget.amount);
// ...
if (expectedPlanck != null && received == expectedPlanck) {

The payment is only matched when the received amount is exactly the expected planck value. If the sender's wallet formats differently, has a rounding variance, or the user manually types a slightly different amount, it won't match. This is probably fine for the MVP "trusted parties" use case, but worth noting. Consider whether a >= comparison would be more appropriate for a merchant scenario (overpayment should still count as paid).

2. No from address validation — any transfer matches

Note: We don't know the customers address..

The onTransfer callback only checks the amount, not who sent it. If two customers happen to send the same amount at the same time, the first one triggers "Paid". For a trusted POS context this is acceptable, but it's a known limitation.

3. 30-second timeout silently stops watching

Note:

• Retry button could be ok, customer may take forever to transfer
• We should also check history in case there's a big delay
• This happened because before we didn't do any checking, relying on manual check by cashier
• We could also do a "Checked manually" button instead of "Done"
• Could be next PR

_timeoutTimer = Timer(const Duration(seconds: 30), () {
  print('[TxWatch] Timeout — gave up waiting for payment');
  _txWatch.dispose();
  if (mounted) setState(() => _watching = false);
});

After 30s, the watcher stops and the UI changes from "Waiting for payment..." back to a plain "Done" button. The user gets no feedback that monitoring stopped. If the payment arrives at second 31, it's missed. Consider either extending this timeout, showing a "Timed out — tap to retry" message, or re-subscribing on tap.

4. WebSocket error handling is print-only

Note:

• Should show error

In TxWatchService.watch(), connection failure and stream errors just print(). The onError callback is optional and PosQrScreen only prints from it too. A failed WebSocket connection means the "Waiting for payment" spinner shows indefinitely (until the 30s timeout). Might be worth showing a subtle error state.

5. Derivation path changed to fully hardened — breaking change for existing wallets

Intentional, we know.
DRY violation is ok b/c we have default path vs a pattern. Also this won't change.

final derivationPath = "m/44'/189189'/$account'/$change'/$addressIndex'";

The old path was m/44'/189189'/$account'/$change/$addressIndex (last two segments unhardened). The new one uses $change'/$addressIndex' (hardened). This generates different keys for every existing user. Since this PR targets the new_testnet_planck branch and is explicitly for a new testnet, this is likely intentional — but it's a key-breaking migration that should be documented explicitly in the PR description.

The Rust side also adds a DEFAULT_DERIVATION_PATH constant:

const DEFAULT_DERIVATION_PATH: &str = "m/44'/189189'/0'/0'/0'";

This path is hardcoded in Rust and in Dart independently. If they diverge, generate_keypair (Rust default) and keyPairAtIndex(mnemonic, 0) (Dart-side derivation) would produce different keys. Not a bug today, but a DRY concern — the path is defined in two places.

6. _ws!.listen doesn't store the subscription

Note:

• Need to fix

_ws!.listen(
  (event) { ... },
  onError: (e) { ... },
);

The StreamSubscription from listen isn't stored, so it can't be cancelled independently of closing the socket. If dispose() is called while _ws?.close() is in flight, the listener could still fire. Minor, but storing the subscription and cancelling it in dispose() would be cleaner.

7. Dev account seeds are hardcoded in two places

Note: Fix.

HdWalletService._devSeeds maps mnemonic strings to seed bytes {0, 1, 2}, while crypto.rs has crystal_alice() / crystal_bob() / crystal_charlie() doing the same thing with vec![0; 32], etc. These are parallel implementations. If a dev account is added or changed, both must be updated.

8. crypto.dart API changed from getters to functions

Note: Non-issue

-int get publicKeySize =>
-    RustLib.instance.api.crateApiCryptoPublicKeyBytes().toInt();
+BigInt publicKeyBytes() => RustLib.instance.api.crateApiCryptoPublicKeyBytes();

This changes the public API from publicKeySize (getter, returns int) to publicKeyBytes() (function, returns BigInt). Any code that was using publicKeySize, secretKeySize, or signatureSize will break. Are there callers outside this repo?

9. ark-vrf patch is a liability

[patch.crates-io]
ark-vrf = { git = "https://github.com/davxy/ark-vrf", tag = "v0.1.1" }

The comment says the crate was yanked. Patching to a git tag is fine as a workaround, but this should be tracked as tech debt — if sp-core updates its dependency, this patch can be removed.

10. Rust toolchain pinned to 1.89

-channel = "stable"
+channel = "1.89"

Pinning is good for reproducibility. Just make sure CI also uses this version.

---

Minor / Nits

• The New Charge button does popUntil(isFirst) then immediately push(PosAmountScreen). This is fine but slightly unusual — an alternative would be pushReplacement or a named route.
• The "Copy Link" text in the QR screen is a nice touch for debugging but has no user feedback (toast/snackbar) after copying.
• sign_message in Rust now calls .expect("Signing failed") — if the underlying ML-DSA signing can actually fail, this panic would crash the Flutter app. Worth confirming this is truly unreachable.

---

What's Good

• Clean separation of TxWatchService as its own service
• The paid state UI is simple and effective (big green checkmark)
• Dev account shortcircuit in isDevAccount / keyPairAtIndex is pragmatic
• Removing commented-out code in crypto.rs is a welcome cleanup

---

Summary Verdict

The feature works and is well-scoped for a trusted POS scenario on a new testnet. The main things I'd want addressed before merge are:

1. Document the derivation path change as a breaking change in the PR description
2. Handle the timeout more gracefully (at minimum show the user it stopped)
3. Consider >= for amount matching (overpayment should still be recognized)
4. Consider storing the StreamSubscription for cleaner cleanup

Everything else is minor or acceptable tech debt for a testnet feature branch.

[dewabisma]

Shouldn't we also use healthiest url here?

[dewabisma]

Why do we have commented line here?

[dewabisma]

Just need to clarify this, all good