Smart wallets must be provable

Wallets are the first piece of software that people interact with on the blockchain. The little Metamask fox greets a sizeable portion of the blockchain ecosystem whenever they want to make a transaction. Wallets hold keys, sign transactions, and show balances to users. They’re genuinely yours. You can fall back on them when UIs and apps break down.

Your blockchain address is akin to your social security number: it’s your identity, where you receive funds, and what you transact with.

If you don’t know what a smart wallet is, we recommend you read the WTF is account abstraction series by Argent to learn more before reading this blog post. I also wrote an article on my blog called Wallets must be invisible: this one is a direct follow-up. Special thanks to Nicolas Bacca for reviewing this post!

How EOAs and smart wallets work

Understanding EOAs

Cryptographic signatures are the backbone of wallets.

A user generates a private key, which is used to derive the public blockchain address. Only the owner of the private key can sign transactions for an address; that’s the EOA (externally owned account) model.

Chains specify a type of signature, and while there is some standardization around wallets, there are differences between blockchains. Ethereum uses ECDSA signatures on the secp256k1 curve, while Polkadot uses a Schnorr signature on the sr25519 curve. 

The EOA model is much simpler than the smart wallet model. It’s a single signature scheme, which is easy for wallets to support. In the EOA model, anyone can generate an account and receive funds without paying anything: key generation is free.

This model has many drawbacks. If an account address links to exactly one private key, then the private key cannot be rotated while keeping the same address. If you lose your private key, you lose control of the address. It's also very vulnerable to phishing attacks!

Smart wallets

One way to counter this problem is smart wallets. They represent user accounts not as derivatives of private keys but as smart contracts on a blockchain. Smart wallets can implement complex authentication methods and support key rotation, multi-signature, multi-calls, spending limits, etc. They also bring programmability to wallets.

Account abstraction is a long-standing discussion in the blockchain ecosystem. Implementing account abstraction on Ethereum has proven challenging, and only a handful of ecosystems have it running in production.  

Smart wallets are very flexible because they allow writing any kind of logic with a smart contract. But they also have limitations. Features such as passwordless authentication through Passkeys require extensive optimization work, as the EVM does not natively support the secp256r1 curve.

Account abstraction as a whole comes with its own set of problems. An entire ERC focuses on solving issues related to denial-of-service attacks. In the EOA model, it’s trivial to know whether a transaction is valid or not: just check if the ECDSA signature of the transaction is valid. This does not mean the transaction will be processed onchain: it can still run out of gas, fail at the smart contract level, etc. But at the very least, nodes know they can broadcast the transaction and include it in blocks because it can pay for its fees.

« The EOA model implicitly follows the rule: a valid transaction can’t become invalid without payment by the account: e.g account balance can’t be reduced (except with a higher paying transaction) »

− EIP67562

With account abstraction, the validation logic of a transaction is much more complex than that of an ECDSA signature verification. Without limitations, an attacker could create extremely complex logic to validate transactions without paying for them onchain, clogging the network.

All in all, smart wallets and account abstraction are extremely useful features that we are using to their full potential. Base shipped a smart wallet with Passkey to great success! But they're still far from ubiquitous or even standardized.

zkAccounts: the future of account abstraction

An extension of the smart wallet/account abstraction paradigm is to use zero-knowledge proofs to control wallets. Rather than writing a smart contract and deploying it on the blockchain, then paying for the execution of its logic for every transaction, one could treat an account as a rollup. The spending logic is run offchain, and a zero-knowledge proof of the execution is generated to be verified onchain. If the proof verification succeeds, the funds are transferred.

These are zk accounts.

With this approach, you can use any program for authentication. Digital signatures don't limit us, thanks to zero-knowledge proofs. Any program can be an authentication method. You can control an application with a zkEmail proof natively. You also gain access to any cryptographic signature: you just need to prove the signature rather than write a specific smart contract that will specifically verify the signature.

Furthermore, you can now use private inputs to control your wallet. A user can generate a zero-knowledge proof of the fact they know their password and use it for authentication! This sounds trivial, but it has so far been impossible in the blockchain world. In the long run, users will be able to authenticate with zkML proofs of their biometrics!

Verifying proofs of execution rather than running the execution onchain unlocks new possibilities: you can run a very large computation offchain and only verify a smaller proof onchain. Transaction fees are what limits you, not their content! Using the succinctness property of specific zk protocols, your computation is constant: you’ll always pay the same amount, no matter how complex the logic is.

Celestia has spearheaded zk account development to achieve expressivity at the base layer without an on-chain smart contract. To learn more, I recommend this great video by NashQ on the topic.

How Hylé does it

Hylé is a sequencing and settlement layer for provable applications. It does not ship an execution environment but instead verifies proofs of execution performed off-chain. Therefore, there are no EOAs or smart wallets on Hylé; everything is a ZK account.

This means Hylé will natively support any type of wallet (Metamask, Keplr, etc.) by verifying the proof of the signature and will support innovative identification methods such as zkEmail. Imagine an application that allows you to invite your friends through email: they’ll just log in using a zkEmail and be quickly onboarded. This will enable builders to leverage marketing tactics such as referral schemes very easily: just send an email to your friends!

We have used this on Vibe Check, our 1st provable application, which used Passkeys to authenticate users with their biometrics rather than requiring them to download and use a regular wallet. Users simply authenticate with their face, then broadcast the transaction to Hylé and benefit from Hylé’s delayed proving to get instant finality. 

In future articles, we’ll discuss identity abstraction, specifically how Hylé decouples the user identity from a single blockchain address to facilitate bridging and cross-app communication.