Self-custodial EVM wallet. Chrome extension live, hardware signer in progress.
Live demo: https://apo110-dev.github.io/110-Wallet/demo/
I'm 18, studying AI Engineering. This is my first real crack at building something that matters. June = finals, so full-time picks up right after.
flowchart LR
subgraph Extension["Chrome Extension (MV3)"]
Popup["popup.mjs\nUI / Views"]
Background["background.mjs\nService Worker\nSigning / Storage / RPC"]
Content["content-script.mjs\nEIP-6963 Provider"]
Popup --> Background
Content --> Background
end
subgraph Core["@110wallet/core"]
Signer["software-signer.mjs\nBIP-39 / BIP-44"]
Context["wallet-context.mjs\nState + Permissions"]
Chains["chain-config.mjs\n7 EVM Networks"]
Sim["simulation-service.mjs\nTx Decoding + Preview"]
end
subgraph Hardware["Firefly Pixie + ATECC608C"]
Device["Custom Firmware\nSecure Element\nPhysical Approval"]
end
subgraph External["External Services"]
RPC["EVM RPC\n(Infura/Alchemy/Custom)"]
WC["WalletConnect v2\nRelay Server"]
Price["CoinGecko\nPrice Feed"]
ZeroX["0x API\nSwap Quotes"]
end
Background --> Signer
Background --> Context
Background --> Chains
Background --> Sim
Background --> RPC
Background --> WC
Background --> Price
Background --> ZeroX
Background -.BLE.-> Device
ETHPrague 2026. Firefly was giving away Pixie DevKits at the booth. ESP32-C3, 240x240 display, BLE, USB-C, four tactile buttons. Open hardware, open firmware, runs whatever you flash. The default firmware is a Space Invaders clone. Free. The board itself is just a microcontroller with no secure element on it.
Then Istanbul Blockchain Week, a few weeks later. A $226 hardware wallet landed in my hands. Steel case, nice build. They had the design spec on a printed sheet. Anyone holding a wallet at the show got one. The spec spelled out their architecture: an ATECC608C chip for key isolation, paired with an STM32H7. Two components. A $0.60–$0.80 secure element and an STM32H7, wrapped in a $226 box.
The Pixie is already an ESP32-class dev board, which is the part of the architecture we already have. The only piece we need to add is the ATECC608C. Attach it, write custom firmware, and the pair becomes a signing device for 110 Wallet. The software side is what you see in this repo.
| What | Detail |
|---|---|
| HD wallet | BIP-39 seed, private key import (via background.mjs + @scure/bip39) |
| 7 networks | Ethereum, Sepolia, Polygon, Optimism, Base, Arbitrum, Avalanche (chain-config.mjs) |
| dApp connectivity | EIP-6963, per-site permissions, session management |
| WalletConnect v2 | Pairing, eth_sendTransaction, personal_sign, eth_signTypedData_v4 |
| ENS | Resolution through mainnet (w110:resolveEns handler) |
| Custom RPC | Override per network (Settings → Networks) |
| Tokens | Balance display + auto-detect from a static list of 66 tokens across 7 chains (known-tokens.mjs) |
| Activity | Live on-chain status polling |
| Send flow | EIP-1559 gas controls, contact book (address book) |
| Security dashboard | Connected sites + permissions at a glance |
| Swap engine | 0x Permit2 quote/approve/execute, backend wired (swap-service.mjs). UI exposes it for tokens you already hold. |
| Fiat on-ramp | Not shipped. Buy screen says "coming soon". |
What I deliberately did NOT include in this list: MoonPay/Transak integration, token search/discovery, portfolio charts, hardware signing. Those are tracked below.
| Area | Current state | Next step |
|---|---|---|
| Token search | Swap UI only lists tokens you already hold. No search box, no popular-token picker, no address paste. The 0x engine itself can quote any token by address. | Add token search + popular list to the swap view |
| Fiat on-ramp | Not built. The buy screen is a placeholder. | Decide: build a 0x-style aggregator redirect, or skip and ship without fiat |
| Token detection | Static list of 66 tokens across 7 chains. Broad but not exhaustive. | Dynamic on-chain scanning |
| Fiat prices | CoinGecko feed covers major assets per chain. Avalanche mapping is partial. | Full chain coverage |
| Tests | Test framework is in place (node:test). Coverage is growing. | Expand coverage, CI pipeline |
| UI | Functional. Designed for utility, not beauty. | Polish pass post-MVP |
| Mainnet | Intentionally gated. No point shipping a software-only wallet into production when the whole point is hardware signing. | Unlock alongside hardware |
This is the part that matters.
The Firefly Pixie is an ESP32-C3 dev board (display, buttons, BLE, USB-C, nothing else). The secure element isn't on it. The plan is to attach an external ATECC608C to the Pixie, write custom firmware, and turn the pair into a signing device for 110 Wallet.
How it works (once built):
- Extension delegates signing to the Pixie over BLE
- User sees the transaction on the device screen
- Physical button press to approve or reject
- Private key never leaves the secure element
- Host cannot bypass, cannot remote-approve, cannot extract the key
I haven't tested the BLE bridge yet. That's the first thing I build after finals. The Pixie firmware is open source (BSD, on GitHub), so I can iterate on it. The only real disadvantage vs a $226 retail device is the case: theirs is steel, Pixie's is plastic. I'll solve that when the prototype works.
If the secure element integration works as expected, the whole signer costs $0.60–$0.80 in silicon.
Most software wallets I looked at treat hardware signing as an afterthought, something to add later after the extension has shipped. This one's the other way around. The threat model in 110-wallet/docs/THREAT_MODEL.md was written before any line of wallet code. The extension is just whatever needs to be true for the signer to plug in later.
Right now everything is JavaScript. Once the w110-hsp envelope is stable I'd like to move the signing core to Rust, a better fit for a security-critical path. I'd rather find the bugs in a typed language than in JS. I haven't started that work yet. For now the goal is simple: ship, get feedback, see if the architecture holds up.
Chrome Extension (Manifest V3), viem, WalletConnect Sign Client v2, esbuild.
110-wallet/
software/
apps/
extension/ Chrome extension source
test-dapp/ Minimal dApp for E2E
packages/
core/ Protocol envelope, shared types
hardware/ Pixie integration (placeholder)
docs/ Threat model, design specs
- Firefly Pixie Firmware. Ships with Space Invaders, gets custom firmware.
- Firefly. The team, open-source hardware, DevKits at ETH conferences.
- Secure element: ATECC608C, $0.60–$0.80 chip in single-unit quantity.
cd 110-wallet
npm install
cd software/apps/extension
node build.mjsLoad dist/ as unpacked in Chrome (chrome://extensions → Developer mode → "Load unpacked").
On first install the wallet opens unlocked, no password prompt. Click the lock button (top right) to lock it. The first time you lock it, the unlock password is 110. Once you set a real password from Settings, that becomes the only thing that works and 110 stops working.
v0.1 is testnet + a slice of mainnet. Don't put real funds here. Forget the password? Restore from the seed phrase. Lose both and the wallet is gone.
Apache-2.0