By Natalie Newson, Senior Blockchain Investigator, CertiK
Digital wallets already won the convenience argument. Apple Pay, Google Pay and their peers turned a two-step checkout into a single tap, and adoption followed accordingly. The next phase of competition looks different. As wallets take on more financial functions, security is becoming the thing that actually separates providers, and I think a lot of the industry is still underestimating how quickly that shift is happening.
A wallet used to be a container for a card number, but now it might hold a crypto balance, a buy-now-pay-later credit line and a peer-to-peer transfer feature, often behind the same login a user opens to buy coffee. Each of those additions expands what an attacker can target, and providers building at this speed don’t always have the security architecture to match the pace of the feature roadmap.
The mismatch shows up because each of these financial products comes out of a different security tradition. Card rails assume a centralized issuer that can freeze or reverse a transaction if something goes wrong. Crypto rails, by design, frequently offer no such recourse. Buy Now, Pay Later (BNPL) underwriting assumes an ongoing credit relationship with the user, while wallet-native crypto assumes none at all.
Stack all three into one interface and you get a security model that has to reconcile assumptions that were never designed to sit next to each other, monitored by fraud teams that historically specialized in one of these worlds rather than all three at once.
Where I’d focus if I were a wallet provider right now
A handful of risks stand out as this convergence accelerates.
Wallet compromise looks different than it used to; for instance, an account takeover once meant a stolen password. Now it can mean a SIM swap that intercepts a one-time code, a phishing page built to harvest a seed phrase, or a malicious app requesting wallet-connect permissions it has no legitimate reason to keep. The more asset types a single wallet touches, the more valuable a successful compromise becomes to whoever pulls it off.
Malicious transaction approval is the risk I’d flag as most underappreciated. Users are routinely asked to approve smart contract interactions they don’t fully understand, often presented as a routine confirmation prompt. A legitimate approval and a wallet-draining one can look nearly identical to someone without a technical background. CertiK’s own investigations into ice phishing scams and wallet-drainer operations have tracked exactly this pattern. Attackers today don’t need a user’s private key if they can talk them into approving the wrong contract call, and as wallets increasingly initiate contract calls on a user’s behalf, the confirmation screen itself functions as a security control whether or not it was designed with that in mind.
Smart contract and bridge exposure is a risk wallets inherit rather than create. Any wallet that touches crypto assets is exposed to the security posture of whatever smart contracts and bridges it interacts with, even when the wallet provider never wrote a line of that code. A vulnerability several layers removed, in a bridge protocol or a DeFi integration the wallet merely connects to, can still result in a user losing funds, and the wallet’s brand tends to absorb the reputational damage regardless of where the fault actually sits.
Fragmented standards compound all of the above. A wallet operating across the US, UK, EU and APAC is navigating different regulatory philosophies on custody, disclosure and consumer protection, layered on top of whatever baseline the underlying payment networks and blockchain protocols already require. That fragmentation means user protections can vary meaningfully depending on where someone happens to live, and inconsistency of that kind is something sophisticated attackers learn to route around.
What a more serious security posture actually looks like
A transaction approval screen that shows a wallet address and a gas fee isn’t really informing anyone of risk. Wallets should move toward plain-language transaction simulation that shows a user what a contract interaction will actually do to their holdings before they approve it.
Audits also need to extend past a wallet’s own codebase. If a wallet integrates a bridge, a DeFi protocol or a third-party smart contract, that integration point deserves the same scrutiny as the native application. Formal verification and independent security audits of every dependency should happen before a feature ships, ideally as a standard step rather than something triggered by an incident.
Custodial and non-custodial rails need a shared threat model rather than two teams working in parallel with limited overlap. Fraud and security functions built around centralized-reversal assumptions will miss failure modes that are specific to self-custody and smart contracts, so providers converging these rails need people who understand both.
And standard fragmentation is worth treating as a design constraint from the start. Providers operating across multiple jurisdictions are generally better served building to the strictest applicable standard as a baseline, whether that means EU DORA and MiCA requirements or VASP licensing regimes in other markets, rather than maintaining a patchwork of minimum-compliance implementations that leave users unevenly protected depending on geography.
For the first decade of digital wallets, the winning strategy was reducing friction. The next decade asks providers to reduce risk without reintroducing the friction users have gotten used to not feeling, which is a harder problem because it means securing systems they didn’t fully build, across asset types with very different risk profiles, under regulatory regimes that don’t agree with each other. Providers who take that seriously now are likely to end up with something convenience alone never bought them: a level of user trust that’s harder for a competitor to erode.
Natalie Newson, Senior Blockchain Investigator at CertiK, has 4.5 years of experience in blockchain security and data analytics, specializing in incident response for crypto exploits. She bridges the gap between complex on-chain forensics and actionable data insights, dissecting smart contract vulnerabilities, tracing funds, and publishing post-attack analyses to make Web3 safer.
