Topic starter
01/08/2026 8:59 pm
TL;DR: Kraken Wallet’s WalletConnect flow can let a malicious dApp impersonate a verified one, while Solana payload handling can present a transaction as a message signature, creating a path to user-authorised fund theft, according to Veria Labs. The case shows how trust signalling and message domain separation fail when wallet UX and signing logic are not tightly bound to transaction intent.
Editorial analysis by NHI Mgmt Group, based on content published by Veria Labs: “Securing Open Source Part 2: Cracking Kraken”.
Key questions
Q: What breaks when a wallet trusts dApp metadata too much?
A: The wallet can be tricked into treating an untrusted application as verified, which undermines the user’s ability to judge whether a signing request is legitimate.
Q: Why do message signing bugs create transaction theft risk in wallet apps?
A: Because message signing and transaction signing can share the same low-level cryptography while carrying very different security meaning.
Q: How should teams test for signing trust gaps in dApp wallets?
A: They should test the full approval chain, from session identity to payload labelling to final signature output.
Practitioner guidance
- Harden dApp origin verification Require verified, non-fallback identity sources for WalletConnect session safety decisions, and fail closed when the verified origin is absent or ambiguous.
- Separate message and transaction signing paths Make the wallet UI, parsing layer, and policy engine distinguish message signatures from transaction signatures before any approval is rendered.
- Test consent confusion with malicious dApp simulations Use red-team scenarios that swap verified metadata, encode transaction bytes as messages, and measure whether the approval flow still exposes the real intent.
Bottom line: The article shows how a wallet can fail when identity verification and payload intent are governed separately.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
01/08/2026 9:06 pm
Signing trust is a governance problem, not just a UI problem. When a wallet can display a benign identity and a benign action label for something materially different, the control plane has failed at the point of user consent. That means the security model is not enforcing a single, authoritative binding between verified origin, session identity, and payload intent. Practitioners should treat approval screens as enforceable controls, not cosmetic context.
A few things that frame the scale:
- Software supply chain attacks were projected to cost organisations $60 billion in 2025.
A question worth separating out:
Q: When should mobile wallet teams treat approval UX as a security control?
A: Always, but especially when the product supports third-party dApps, WalletConnect-style sessions, or multiple signing modes. In those environments, the approval screen is the last control before authorisation, so its labels, warnings, and identity cues must be enforced with the same rigor as backend policy.
👉 Read our full editorial: Kraken Wallet dApp impersonation shows how signing trust breaks