ETHUSSD

The problem

Every crypto wallet you've heard of assumes a smartphone. In Kenya, M-Pesa proved two decades ago that serious financial infrastructure can run on *334# — a USSD session on a feature phone. Hundreds of millions of people across Africa bank this way daily.

ETHUSSD, funded by the Ethereum Foundation, asked the obvious question nobody was building toward: can you give a feature-phone user a real Ethereum wallet — custody, transfers, balance — through a USSD menu? Not a custodial IOU with a blockchain logo. An actual wallet.

Constraints

USSD is a brutally honest design partner:

• 182-second sessions. A USSD session dies after ~3 minutes, hard. Ethereum finality doesn't fit inside that window, so every flow had to be designed as intent now, confirmation later — the session captures intent, SMS delivers the outcome.
• No client-side compute. A feature phone can't hold a private key, run a signer, or verify anything. All the trust assumptions that wallets push to the edge had to be rebuilt server-side without becoming "just a database with extra steps."
• Text menus, fat fingers. The entire UI is numbered menus and a 160-character screen. An address typo isn't a UX bug, it's lost money. Every destructive action got a confirmation step with amounts written out in words.
• Telco integration. USSD gateways are leased from carriers with their own rate limits, session quirks, and downtime. The system had to treat the telco as an unreliable network partner.

Architecture

• Session state machine. A Go service models every USSD flow as an explicit state machine, checkpointed to Postgres on every screen transition. A dropped session resumes exactly where it died — dial back in and you're on the same screen.
• Key custody via smart accounts. Each user gets a smart contract account (account abstraction) controlled by a threshold scheme: keys are sharded between an HSM-backed signer and a recovery service. No single component can move funds, and the design leaves a migration path to user-held keys when the user upgrades to a smartphone — the account is theirs, not ours.
• Intent queue. USSD sessions enqueue signed intents; an executor service batches them, manages gas, submits, and watches for finality. Outcomes are delivered over SMS with a human-readable reference code that customer support can resolve to a transaction hash.
• PIN security. Authentication is a PIN, because that's what the channel offers. PINs are Argon2-hashed, rate-limited at the gateway and the service layer, and a wrong-PIN counter locks the account into an SMS-based recovery flow — designed with the same threat model 41Swara applies to client systems: assume the gateway logs everything, so nothing secret may transit the USSD channel itself except the PIN over the carrier's encrypted signaling.

Design for the session dying at every screen, and the happy path takes care of itself.

My role

I led engineering: wrote the session state machine and the intent executor, designed the custody scheme with an external cryptography reviewer, ran the telco gateway integration, and authored the security documentation the Ethereum Foundation grant required. I also ran field testing in Nairobi — handing feature phones to real users and watching where the menus lost them.

Outcomes

• Shipped a working wallet where the full flow — check balance, send, receive confirmation — completes on a 2G feature phone with no app, no smartphone, no internet connection on the user's side.
• The intent-queue pattern held up: zero funds lost to session drops across the entire pilot, because no session was ever trusted to live long enough to matter.
• The custody design and USSD harness were open-sourced as reference material; the session simulator now lives on in the Lab as a standalone tool.
• The project became my standard teaching case at KCA University for one reason: it forces every assumption about "users" out into the open.