[Kshot3000]

signTransfer documents its recipient as "SS58 (prefix 189) or 0x-hex", but parse_account_id threw the decoded SS58 version away:

AccountId32::from_ss58check_with_version(s)
    .map(|(account, _version)| account)

so the same 32-byte account encoded for any other network was accepted and signed for. I reproduced it with the generic Substrate prefix: [2u8; 32] encoded at prefix 42 (5C7LYpP2ZH3tpKbvVvwiVe54AapxErdPBbvkYhe6y9ZBkqWt) parsed as a valid Quantus recipient. The prefix is the only signal that the sender actually meant a Quantus address — without the check, pasting an address copied from a different chain's address book silently produces a signed Quantus transfer to that account.

Fix:

• Validate the decoded version against ext::SS58_PREFIX (189) and reject anything else with recipient: SS58 address is not a Quantus (prefix 189) address. Hex recipients are unchanged.
• Split the parsing into parse_account_id_checked (plain &'static str errors) with parse_account_id as a thin JsError wrapper keeping the exact same messages. This is needed to test the error path at all: JsError::new panics on non-wasm targets, which is also why the new tests call the checked helper.
• Regression tests: prefix-189 address for a known account parses to that account; the prefix-42 encoding of the same account is rejected. On the old code the reject test fails (it parsed); with the fix, cargo test is 11 passed / 0 failed and cargo clippy --all-targets is clean. No new cargo fmt diffs (the pre-existing ext.rs/mnemonic.rs diffs under this rustfmt are untouched).

---

@Kshot9000 (https://x.com/kshot9000) · QTC donations: qznY8nwuvWcCCVys4da1oQdysyh8YUZYRjRqgk3S8Wos8kbau · cc @Quantus-Network