As Web3 infrastructure expands beyond browsers and desktops, mobile applications are becoming the primary gateway to the decentralised internet. According to a DappRadar report, by early 2024, more than 38% of activity in Web3 gaming already came from mobile devices, and that share continues to grow steadily. But with this convenience comes risk: mobile dApps are increasingly becoming prime targets for phishing, key theft, and compromised SDKs.
Unlike traditional apps, Web3 products don’t rely on centralised servers; users interact directly with the blockchain. That means every signature, every contract, is a potential point of failure. In this environment, a UX flaw, session vulnerability, or WebView exploit can result in complete asset loss for the user.
To understand what the real Web3 threat landscape on mobile looks like today, what kinds of attacks are already happening in production, and how developer teams can build truly secure applications under these conditions, we spoke with Artem Bambalov.
Artem is a Senior Android Developer at P2P.org, where he builds resilient, high-load applications at the intersection of identity, privacy, and security. His background includes mobile apps used by over 10 million monthly active users, which shaped his approach to architecture under real-world load and complexity. Today, he applies that experience to Web3 environments, designing systems for verifiable credentials, smart contract wallets, and zero-knowledge flows.
HackRead: How have approaches to Web3 security evolved over the past two years?
Artem Bambalov: There’s a clear shift toward proactive defence. Secure Enclave and Android Keystore adoption has become table stakes. In my projects, I now assume that key exposure is inevitable unless strong isolation is built in, so I lean heavily on technologies like smart contract wallets (ERC-4337), MPC key sharing, and passkeys to reduce reliance on a single secret.
One project I was a part of moved entirely to ERC-4337, which let us introduce rules like spending limits and social recovery. This drastically reduced panic support requests after accidental approvals.
I’ve also seen teams start threat modelling from day one, something rare just two years ago. In one instance, this early modelling helped us catch a flow where a third-party injected iframe could have initiated signing via message passing. We killed that vector before it reached users.
HackRead: What are the most relevant Web3 threats you’ve seen emerge or escalate in 2025? Any real-world examples?
Artem Bambalov: Web3 threats on mobile in 2025 have not only become more diverse, they’ve also embedded themselves deeper into the user experience, often going unnoticed until it’s too late. One standout example I encountered involved a user who unknowingly approved a malicious eth_sign request while interacting with what looked like a legitimate dApp interface embedded in a WebView. The request mimicked a gasless login flow, but signed over control of the wallet.
The Ledger Connect Kit supply chain attack from late 2023 still has lingering effects. I’ve worked with dApps that unknowingly included compromised dependencies long after the initial disclosure. Cleaning that up required not just updating the packages but auditing every downstream dependency and verifying hash integrity. It was a real lesson in how one compromised library can ripple through the entire ecosystem.
WalletKit (formerly WalletConnect) session misuse is another threat I’ve seen escalate. In one mobile app audit, we discovered stale sessions being reused unintentionally, giving older dApps access long after the user thought the session had ended. We had to implement strict session TTLs and introduce user-visible session management screens to prevent silent reconnections.
HackRead: How do Web3-specific threats differ from traditional risks in mobile development?
Artem Bambalov: The key difference is that in Web3, users manage their assets directly, without servers, intermediaries, or any way to reverse mistakes. There’s no backend to catch a bad decision. One signature is enough to lose everything. That fundamentally changes the threat model: it’s no longer just about protecting API keys or passwords, but about ensuring the entire signing flow is airtight and that users fully understand what they’re approving.
I’ve seen firsthand how a poorly worded transaction prompt can confuse users and lead to irreversible token transfers. That’s why in Web3, every screen and every action inside a wallet or dApp should be treated as a security boundary, just as critical as the blockchain protocol itself.
A good example of this is the Monkey Drainer phishing campaign. Attackers created convincing fake dApps that tricked users into signing eth_sign messages disguised as harmless actions like login or authorisation. One careless signature was enough to transfer all assets, and in some cases, victims lost over a million dollars in a single transaction. What made the scam so effective wasn’t advanced code; it was how well the fake interface mimicked a real dApp, exploiting user trust in familiar patterns.
HackRead: What tools and methods are effective for analysing and monitoring security in Web3 mobile apps?
Artem Bambalov: For smart contracts, I consistently use Slither; it’s fast, catches low-hanging vulnerabilities like reentrancy or storage collisions, and integrates well into CI/CD. I once caught a subtle bug related to uninitialized storage in a contract using Slither, which would’ve allowed users to overwrite admin roles under certain conditions.
Mythril is slower but better for deeper analysis. I run it manually during key releases.
On the mobile side, Sentry has been invaluable. In one case, we caught an abnormal spike in rejected signature requests after a dApp update, which turned out it have changed its domain, and the allowlist didn’t catch it. Firebase Remote Config also helped us quickly disable the session until we could ship a fix.
I also rely on WalletKit’s detailed session logs, which’ve helped us trace exactly when and how connections were established, including peer metadata. In one situation, we noticed a dApp reconnecting every 15 minutes; turns out it was trying to maintain session access even after the user had closed it. We blacklisted the domain.
HackRead: Where should mobile developers begin when designing security for a Web3 application?
Artem Bambalov: Start with private key protection, hardware-backed storage is non-negotiable. Then isolate the signing logic completely. In my experience, signing flows should never be invoked from a WebView or shared component. Build clear boundaries between UI, signing, and business logic.
One practical tip: I often use a signing queue pattern, where every request is placed in a queue requiring explicit user approval, even internally triggered ones. This has saved us multiple times from edge cases where background flows attempted unintended actions.
HackRead: What common mistakes do developers make today, and how can teams build a systematic approach to security going forward?
Artem Bambalov: The biggest mistake I’ve seen is prioritising UX convenience over security, like skipping confirmation prompts or auto-signing transactions. In one audit, I found a production dApp that signed messages silently via an injected script in a WebView. All it took was a reused WalletKit session, and the user’s tokens were gone.
I reworked that flow to always surface a native confirmation sheet, validate the dApp origin, and display decoded transaction data in plain language. Post-release, there were zero further phishing incidents through that vector.
Teams should treat wallet flows like login systems in banking apps, with audits, automated tests, origin validation, and user education built in. I also recommend running regular internal red-team exercises, even simple ones. In one team, we scheduled “attack weeks” where a developer tried to bypass their own app’s protections, which uncovered multiple logic flaws and helped us improve quickly.
HackRead: What new types of attacks or vulnerabilities do you think could still emerge in the Web3 space in 2025, especially in the context of mobile development? Are there already signs of such vectors or trends that developers should keep an eye on?
Artem Bambalov: I expect that shortly, attacks will shift away from direct exploits to target the abstraction layer we are building for user convenience. Attack vectors will become less direct and more contextual. I would highlight three key trends.
AI-Powered Hybrid Attacks
Phishing is becoming a precision tool. Attackers are using AI to craft dynamic phishing sites and messages that mirror a specific user’s interfaces and behavioural patterns. Malicious dApps can now offer seemingly logical actions, like claiming an airdrop from a protocol the user has frequently interacted with.
Social engineering is also entering a new phase. With deepfake technology, attackers can impersonate a user’s “guardian” in social recovery systems, using voice or video to trigger key rotation and gain wallet access.
Intent-Based Attack Surfaces
New standards like ERC-4337 simplify blockchain interaction but introduce new attack surfaces. Instead of signing specific transactions, users now express “intents”, which are then executed through a chain of third parties like bundlers and paymasters.
This creates space for manipulation. Malicious paymasters may alter transaction parameters behind the scenes, while bundlers can selectively execute or censor intents to extract MEV (Maximal Extractable Value) at the user’s expense. For mobile developers, it’s no longer enough to display “swap X for Y.” The full execution chain must be transparent and secure.
The Blurring of Web2 and Web3 Boundaries
As Web3 mechanics merge with familiar Web2 technologies like Passkeys, attackers are adapting. Instead of stealing seed phrases, they can trick users into binding an attacker-controlled Passkey to their wallet. The user thinks they’re setting up a convenient login, when in fact, they’re handing over full control.
Another risk lies in cross-chain bridges within mobile apps. On a small screen, it’s easy to disguise a spoofed destination network address. A user may believe they’re sending funds to Arbitrum, but the transaction is routed to a malicious contract on an entirely different chain. These attacks don’t exploit cryptography; they exploit perception and trust in the interface.
The core trend is clear: attacks are shifting from code to cognition, from vulnerabilities in logic to vulnerabilities in trust. Protecting private keys is no longer enough. Developers must safeguard the entire path, from user intent to final on-chain execution.
