The "Trojan Horse" in the Ethereum Fusaka upgrade: How to turn billions of mobile phones into hardware wallets?

The upcoming Ethereum Fusaka upgrade, specifically through EIP-7951, introduces a "precompile contract" that will enable billions of smartphones to function as secure hardware wallets for Ethereum. This solves a long-standing compatibility issue.

The Problem: Modern smartphones have built-in secure chips (like Apple's Secure Enclave or Android's StrongBox) that use the industry-standard secp256r1 cryptographic curve for security functions (e.g., Face ID, fingerprint login). However, Ethereum's account system uses a different curve, secp256k1, making these chips unable to sign Ethereum transactions directly.
The Solution: Instead of changing hardware, Ethereum is adapting. The Fusaka upgrade adds a low-cost "precompile contract" that allows the Ethereum Virtual Machine (EVM) to natively and cheaply verify signatures made with the secp256r1 curve, reducing the cost from hundreds of thousands of gas to just 6900 gas.
The Impact: This is a key enabler for Account Abstraction (AA) wallets. Future smart contract-based wallets can be programmed to authorize transactions using the secure biometric verification (r1 signature) from a phone's chip. Users won't need traditional seed phrases or dedicated hardware wallets.
The Vision: It removes a major barrier to mass adoption. New users won't need to understand private keys or manage seed phrases. They can securely transact using just their face or fingerprint, merging high security with a seamless, familiar user experience—effectively turning everyday devices into bank-grade crypto wallets.

Author: Zhixiong Pan

You actually already have a "hardware wallet" in your pocket.

The mobile phones and computers we use every day actually have built-in security chips. For example, there is the "Secure Enclave" in iPhones, or Keystore / Trust Zone / StrongBox in Android phones.

This isolated physical area is usually called a TEE (Trusted Execution Environment). Its characteristic is that it is "in-only": private keys are generated inside and never leave this physical area; external entities can only request it to sign data.

This is essentially the standard for hardware wallets. These chips generally use an industry-standard algorithm curve selected by NIST (National Institute of Standards and Technology): secp256r1, when signing. This is also the cornerstone behind WebAuthn and FIDO2 (such as your fingerprint login and Face ID).

A gap of just one letter

The awkward thing is that Ethereum does not natively support this mainstream secp256r1.

Back then, the Bitcoin community chose the relatively obscure secp256k1 due to concerns about the potential presence of "national backdoors" in the NIST curve. Therefore, Ethereum followed the tradition of using this curve when designing its account system.

Although r1 and k1 seem to differ by only one letter, they are mathematically completely different languages. This leads to a huge pain point: the security chip in your phone is completely clueless about Ethereum and cannot directly sign Ethereum transactions.

Since we can't change the hardware, we'll just make this version "compatible" with it.

Ethereum obviously cannot force Apple or Samsung to change their chip designs to accommodate the secp256k1; the only way is for Ethereum to adapt to the secp256r1 itself.

Is it possible to use smart contract code to verify the r1 signature? Theoretically, yes, but the mathematical calculations are too complex, and running a verification could consume hundreds of thousands of gas, which is completely impractical from an economic standpoint.

Therefore, in the Fusaka upgrade, developers unleashed a powerful tool: precompile contracts. This is equivalent to opening a "backdoor" or "plug-in" within the Ethereum Virtual Machine (EVM). Instead of having the EVM calculate step by step, this verification function is directly written into the client's underlying code. Developers only need to call a specific address to complete the verification at extremely low cost.

In EIP-7951, this cost was fixed at 6900 Gas, dropping directly from hundreds of thousands to thousands, finally entering the range of "can be used in real products in daily life".

The final piece of the puzzle in account abstraction

The successful implementation of this EIP means that we can finally sign and authorize smart accounts on Ethereum within the TEE environment of a mobile phone.

It's important to note that this does not apply to your current MetaMask EOA address (because their public key generation logic is still k1).

It's specifically designed for "Account Abstraction" (AA Wallet). In the future, your wallet will no longer be a mnemonic phrase, but a smart contract. This contract states:

"As long as the fingerprint (r1 signature) is verified to be correct, the transfer is allowed."

Summarize

EIP-7951 may not make mnemonic phrases disappear overnight, but it has finally removed the biggest stumbling block on the road to the widespread adoption of Ethereum.

Before this, users were always faced with a cruel choice: Want "bank-grade" self-security? You have to spend money to buy OneKey, Keystone, or Ledger, and you have to keep your mnemonic phrase safe like you would a gold bar; Want the smoothest experience? You can only store your coins on an exchange or in a custodial wallet, at the cost of giving up control (sacrificing decentralization).

After the Fusaka upgrade, this choice will no longer exist.

With the implementation of EIP-7951, "mobile phone as hardware wallet" will gradually become a reality. For the next billion new users, they may not need to know what a "private key" is, nor will they need to face the psychological pressure of copying 12 words.

They only need to scan their face and press their fingerprint, just like buying coffee normally. The iPhone's security chip on the back will call secp256r1 to sign the transaction and complete the verification through Ethereum's native pre-compiled contract.

This is the right way for Ethereum to embrace its next billion users: instead of arrogantly demanding that users learn complex cryptography, it should humble itself to be compatible with common internet standards and proactively reach into users' pockets.