FairWins was born EVM. Every address was twenty bytes of 0x…, every network
was a numeric chainId, every balance read went through an RPC provider, and
every signature came from a passkey-backed ERC-4337 smart account. Then we
decided members should be able to hold, receive, and send actual Bitcoin —
first-class, self-custodied, inside the same account.
Bitcoin is not “another chain” to an EVM app. It’s a different account model
(UTXOs, not balances), a different address universe (four generations of
formats), a different fee market (sat/vB, not gas), and no smart contracts at
all. This post is about the five design decisions that made it fit — and the
guardrails that keep it honest.
1. The wallet nobody has to back up
The hardest question was key management. FairWins deliberately killed the
seed phrase: accounts are WebAuthn passkeys driving P-256 smart accounts.
Bitcoin needs secp256k1 keys. Where do they come from, if not a new mnemonic
we’d force members to write down?
The answer was already in our stack. Our passkey accounts maintain a 32-byte
master seed — created once per account, wrapped under a key derived from
the WebAuthn PRF extension, recoverable on any device with one passkey
ceremony, and shareable across a member’s registered devices. It already
powers our end-to-end encryption. It is, functionally, a seed phrase that
nobody ever sees.
Bitcoin becomes one more consumer of that seed:
masterSeed (32B, PRF-recoverable)
→ HKDF-SHA256(info = "fairwins-btc-seed-v1", 64 bytes)
→ BIP32 root
→ m/84'/0'/0' native segwit (bc1q…, default)
→ m/86'/0'/0' taproot (bc1p…, opt-in)The HKDF info string gives us domain separation — the Bitcoin tree can never
collide with the encryption keys or any future consumer of the seed. The
paths are bog-standard BIP84/BIP86, which means the wallet is legible to the
wider Bitcoin ecosystem, not a proprietary scheme. Those constants are
frozen in a normative contract in-repo and marked wallet-breaking: funds
live at the derived addresses, so changing them ever requires a versioned
migration, not a refactor.
Recovery falls out for free. Sign in on a new device → one PRF ceremony
unwraps the master seed → standard gap-limit-20 discovery walks the
derivation chain against chain data and rebuilds every address and balance.
There is no Bitcoin backup step because there is no Bitcoin-specific secret.
Everything stays client-side. Private keys and account xpubs never leave the
browser; our backend sees bare addresses (batched, max 50 per call) and
signed raw transactions. That’s the whole interface.
2. A network that isn’t a chainId
Our network registry was a map keyed by numeric EVM chainIds, and dozens of
consumers assume those keys mean “something wagmi can switch to” and
“somewhere contracts are deployed.” The tempting hack — give Bitcoin a fake
number and stuff it in — would have leaked those assumptions everywhere:
contract-address lookups, subgraph routing, wallet switch prompts for a chain
no wallet can switch to.
Instead, Bitcoin lives in a parallel, string-keyed registry: 'bitcoin'
and 'bitcoin-testnet' (testnet4), with their own capability descriptors,
explorer links, and testnet/mainnet pairing. A single type guard —isBitcoinNetworkId() — sits at every boundary the two worlds share, and a
dedicated test suite pins that no Bitcoin id ever reaches EVM-typed code.
That suite earned its keep before launch: our capability resolver had a
default-network fallback that quietly reported Polygon’s features as
available for unknown ids — meaning Bitcoin would have claimed swap and DAO
support it doesn’t have. The guard-rail test caught it; the fix shipped with
the feature.
Capabilities are self-disclosed and blunt: Bitcoin does portfolio, send,
receive, and Stamps display. It does not do wagers, pools, memberships,
swaps, or gasless anything, and every surface that lists networks says so
rather than hiding the row.
3. A stateless data plane you can turn off
The app needs UTXOs, balances, fee estimates, transaction status, and a
broadcast path. Browsers calling public block explorers directly would leak
members’ full address sets to third parties, with no rate control and CORS
fragility.
We already had a pattern for this: our relay gateway fronts external services
(prediction markets, NFT data) through small self-contained modules with a
fixed pipeline — killswitch → validation → per-IP and global quotas → TTL
cache → normalize to DTOs. Bitcoin became one more module, speaking the
Esplora REST dialect. mempool.space is the default upstream; because Esplora
is the de-facto standard, swapping to blockstream.info or a self-hosted
electrs is a config change, not a code change.
Two details we’d underline for anyone building similar infrastructure:
- Broadcasts are never retried. A timed-out broadcast may still have
propagated; a retry loop can double-submit. Reads retry, writes don’t. - The whole module is optional. With
BTC_ENABLED=falsethe routes
return an explicit “disabled” status and every Bitcoin surface in the app
hides or degrades with an honest message. Ops can also kill it instantly
mid-incident — and because keys are client-side, members’ funds remain
theirs and fully recoverable in any standard wallet regardless of what our
infrastructure is doing.
4. Transactions built like a contract audit
Signing happens entirely in the client with @scure/btc-signer and@scure/bip32 — audited, zero-WASM libraries from the same family as the
crypto primitives we already ship, so the whole signing path stays auditable
JavaScript in our bundle. We can spend our own P2WPKH and P2TR (key-path)
coins and pay out to every standard destination type: P2PKH, P2SH, bech32 v0,
bech32m v1.
The interesting engineering is in coin selection and fees, where we applied
the same paranoia we’d give a smart contract:
- Fail-safe classification. Every UTXO is classified before selection:
spendable,pending(unconfirmed),protected(a Bitcoin Stamp travels
with it), orunverified(Stamps recognition unavailable). Only
positively-verifiedspendablecoins may fund a send. This is how Stamps
protection works: spending a Stamps-bearing UTXO destroys or transfers the
collectible, so recognition failure defaults to over-protection. The
degraded state is disclosed in the UI along with exactly how much value is
protected — total ≠ spendable is always explained, never mysterious. - A fee ceiling, enforced twice. Fee quotes (fast/normal/slow, sat/vB)
expire after 60 seconds. The fee a member confirms becomes a hard ceiling:
the planner checks it, and the signer independently refuses to produce a
signature for any transaction whose real fee exceeds it. If the mempool
moves, the member re-confirms against a fresh quote. The UI can’t promise
one fee and pay another even if it has a bug — the signing layer won’t let
it. - No dust, no strays. Sub-dust change folds into the fee (reported
honestly as fee, not vanished); MAX computes everything-spendable-minus-fee
to the satoshi; selection tests assert exact conservation — inputs equal
amount + fee + change on every path. - Concurrency locks. Coins referenced by an in-flight send are excluded
from selection until the transaction confirms or is abandoned, so two
quick sends can’t double-commit the same UTXO. Everything signals RBF.
Address rotation rounds out the receive side: every receive request issues
the next derivation index, cursors never decrease (even against stale local
caches), and old addresses are monitored forever. The local address ledger is
just a cache — chain-driven discovery is the source of truth, which is what
makes recovery trustworthy.
5. Tests that pin the protocol, not the mock
A wallet is the wrong place for “seems to work.” The test strategy leaned on
the fact that Bitcoin’s derivation standards publish reference vectors:
- Derivation is tested against the official BIP84 and BIP86 vectors, plus
pinned FairWins fixture vectors that freeze our HKDF domain separation —
if anyone ever changes a constant, byte-exact assertions fail loudly. - Address parsing runs an accept/reject matrix: checksum mutations,
mainnet/testnet cross-use, EVM addresses pasted by muscle memory, mixed-case
bech32, unknown witness versions — each with its own member-facing reason,
because “invalid address” is a uniquely useless error in a four-format
universe. - Coin selection is tested as properties (protected coins never selected,
MAX leaves zero remainder, no dust outputs exist) rather than examples. - The gateway module’s route tests cover the unhappy paths that matter
operationally: quota breaches, upstream outages, degraded Stamps data,
cache behavior, and boot-time config validation that fails loudly.
Roughly 250 tests landed with the feature, alongside a security review that
covered key hygiene, fund-loss vectors, and the gateway surface. The review’s
two real findings were both honesty bugs — a capability leak and a gasless
badge that could have appeared on the Bitcoin row — and both were caught by
tests written to enforce disclosure rules, which says something about where
the real risks live in a wallet UI.
What we deliberately didn’t build
No Lightning (on-chain only, for now). No BTC wagers — FairWins escrow is
smart-contract-based and Bitcoin has no contracts; we’d rather not offer a
trust-us version. No server-side anything for keys: no custody, no xpub
sync, no address registry. And no gasless Bitcoin — sponsoring UserOps on an
EVM chain is one thing; misrepresenting who pays a Bitcoin miner is another.
The confirm screen says, in plain words, that you pay the network fee.
The pattern that made all of this tractable: derive from what you already trust, isolate what doesn’t fit, and disclose everything the system can’t do. The passkey seed gave us self-custody without new backup burdens; the
parallel registry kept a UTXO chain from contaminating EVM assumptions; and
the honesty rules — stale-not-zero balances, pending-not-final deposits,
fee ceilings, capability self-disclosure — did more for member safety than
any single cryptographic choice.
Bitcoin is FairWins’ first non-EVM network. The seams we cut for it are the
ones the next one will slide through.
