MyFriendlyWallet: making crypto invisible for users, addressable for developers

A wallet address is 42 characters that look like keyboard noise. To send money, a user has to know the right chain, hold the right gas token, paste the right address, and pray they didn't fat-finger a character that nobody can recover. To accept payments as a developer, the options are: integrate a wallet SDK, register with a payment processor that may or may not approve your business, or rebuild what Stripe took ten years to build.

I've spent the last stretch building MyFriendlyWallet (MFW) — a non-custodial, multi-chain wallet that ships as a Progressive Web App — and the thesis underneath all the work is one decision repeated everywhere: make the chain invisible to humans, but addressable for developers.

This is what that thesis produced for each audience.

What MFW solves for users

MFW replaces the wallet address with a username. You sign up and become @MFW-SARAH. People send you money the way they'd tag you on Instagram. Behind that, the protocol picks the right chain, settles in the right token, and pays the gas if you're on Base or Solana — without surfacing any of those decisions to you.

That sentence reads simple. The implications are most of the product.

Sending money looks like sending a text. You type a username, you type an amount, you tap send. The entire send flow on Base USDC, Base EURC, or Solana USDT is gasless. There is no "what chain are you on," no "do you have ETH for gas," no "wait, this is a bridge transaction." For 95% of normal usage, a user could go their entire MFW lifetime without ever learning the word "blockchain."

Receiving money is free, always. Receivers don't pay gas. Receivers don't pay fees. Money lands instantly. This sounds obvious until you realize that most fintech rails charge the recipient — Stripe takes 2.9%, PayPal freezes funds for 21 days, banks charge $25 for international wires. MFW takes 0.25% from the sender and the recipient gets the rest, guaranteed, instantly, with on-chain proof.

Money lives in the user's pocket, not in MFW's bank. This is the non-custodial part: keys are generated and stored on the device, encrypted with the user's PIN. The MFW server is a dumb pipe — it never sees a private key. If MFW disappears tomorrow, every user can recover their funds with their seed phrase from any other wallet. This is the difference between "we can't lose your money" and "you can't lose us your money." Users own the latter.

Buying crypto looks like buying anything else online. Card or bank transfer through a regulated on-ramp partner. The user sees prices in their local currency. They never see a network fee, a slippage warning, or a chain selector. The first transaction many users do is "I sent my mom $20 across continents and it arrived in five seconds." That moment converts more people than any explainer video.

Power Mode for users who want the full keys. The username-and-tap experience is the default for everyone. But for users who already understand crypto and want the full multi-chain wallet underneath — direct address sends, manual chain selection, WalletConnect for DeFi apps like Uniswap, 1inch and Aave, all 156 tokens across all 54 chains, custom gas tokens, advanced controls — there's a Power Mode toggle in settings. Flip it on and the simple wallet becomes a full crypto wallet. Flip it off and everything goes back to looking like a payments app. The same account, the same keys, two interfaces. Beginners never see the complexity; experts never feel constrained by the simplicity.

The whole thing runs on every device through one URL. No app store gatekeeper. No platform-specific code. No update cycles. Open app.myfriendlywallet.io on iOS, Android, Windows, Mac, ChromeOS, Linux — the wallet is there, identical, working. PWA install promotes itself to the user when the moment is right. The Google Play submission is in progress as a nice-to-have for Android users who prefer app store distribution; it was never the launch.

The pitch to users is: a payments app that happens to use crypto, not a crypto wallet that happens to do payments. The tech is in the basement; the experience is what's on the surface.

What MFW solves for developers

This is where the architectural decision pays its second dividend.

Because every MFW user has a stable, human-readable identity (MFW-SARAH), and because every transaction goes through a single API and a single relayer infrastructure, building on top of MFW is dramatically simpler than building on raw blockchain. You're not integrating a chain — you're integrating a payment system that happens to settle on chain.

The developer story has three layers, in increasing order of capability and effort:

Layer 1: The Pay Link — zero integration

Every recipient has a URL. You construct it like this:

<a href="https://app.myfriendlywallet.io/?to=MFW-SARAH&amount=25&action=send">

Pay $25

</a>

That's the entire integration for accepting payments. No API key. No SDK. No backend code. No webhook configuration. Drop the link in an HTML page, an invoice, an email, a QR code, a button, an Instagram bio — anywhere a URL works, payment works.

Anyone with an MFW account who clicks that link lands inside their wallet, on a pre-filled confirm-and-send screen. They tap pay. The recipient gets the funds in seconds.

This is the simplest possible payment integration on the internet. It's simpler than Stripe Checkout (no API call, no session token, no redirect handling). It's simpler than PayPal buttons (no client ID, no Smart Buttons SDK). It's simpler than crypto wallet integrations (no window.ethereum, no chain ID negotiation, no signature handler).

For most developers, this is the entire integration they'll ever need. It works for a coffee shop, a freelancer's invoice, a Substack tip jar, a donation button, a Discord bot, a side project that needs payments before it needs infrastructure.

Layer 2: The Read API — public, free, no auth

If you want richer UX — showing recipient names with avatars, displaying token prices, reading balances — there's a public REST API that requires no authentication. Server-side calls only:

GET /v1/resolve/{code} — Resolve username to display info

GET /v1/prices — ~100 tokens, real-time

GET /v1/{chain}/balance/{addr} — Read balances on 25+ chains

GET /v1/chains — List supported chains

Free for everyone. No rate limit beyond reasonable use. Server-side only by design — this prevents abuse and keeps the API predictable. The token price oracle alone is useful for any crypto-adjacent app, regardless of whether they integrate MFW for payments.

Building a recipient picker becomes a 20-line component. Building a balance dashboard becomes a single fetch. Building a payment-request flow with token autocomplete becomes a weekend project.

Layer 3: Partner endpoints — API key + user token

For developers building actual platforms on top of MFW — invoicing tools, e-commerce checkout, marketplace settlement — there's a partner API:

POST /v1/partner/request — Generate server-side payment links

GET /v1/partner/transactions — Read your transaction history

POST /v1/partner/send — Direct gasless transfers (PIN-confirmed)

API keys take 30 seconds to register. The fee model lets partners stack their own fee on top of MFW's 0.25%, transparently and on-chain.

The security model is the part most developer audiences immediately probe: a stolen API key is harmless without the user's active session. Every transactional endpoint requires both your partner key AND the user's valid session token. A compromised partner key can read public data and generate payment links, but cannot move funds. Funds always require user consent at the device.

The fee model is fully transparent:

Sender sends $50.00 USDC

MFW gasrelay fee (0.25%, min $0.05) − $0.125

Your partner fee (0–2%, your choice) − $0.15 (0.3% example)

Recipient receives $49.725

Gas cost to sender $0.00 (gasless on Base/Solana)

Everything is logged on-chain and auditable. Partners can build SaaS products that earn recurring revenue on top of MFW's payment rails without ever touching a private key, without holding user funds, without becoming a custodian themselves.

The unifying architecture

Everything above is the surface. Underneath, the architecture is intentionally narrow:

Frontend: a single-file React PWA. ~2.4MB, served from Cloudflare Pages, installs to home screen on every modern device. Hand-edited via Python string-replacement workflows with assert-count discipline and node-check validation on every change. Boring on purpose.

Backend: 100% Cloudflare Workers — RPC proxying, fee enforcement, gas relayer pools, transaction broadcasting across 54 chains and 156 tokens. Sub-100ms cold starts at every edge. Total monthly infrastructure cost in two figures.

Gasless relayers: pools of pre-signed wallets on Base and Solana that pay user gas in exchange for the protocol fee. Nonce coordination across the pool was the hardest engineering problem in the project.

Custody: keys generated on device, encrypted with user PIN using PBKDF2, never transmitted. Recovery via standard BIP39 seed phrases that work in any wallet.

Compliance and operations: Crypteria AS, a Norwegian Aksjeselskap (Norway's equivalent of an LLC). Real legal entity, real org number, real terms of service, real privacy policy, real banking. The product is non-custodial; the company is real.

This is the boring infrastructure that makes the interesting parts possible. Cloudflare Workers don't care if you have ten users or ten million. Single-file PWA doesn't care which platform you're on. Non-custodial keys don't care if MFW the company exists tomorrow.

What MFW doesn't yet solve — being honest about it

Three things that aren't done, in order of when they will be:

Off-ramp to fiat. Withdrawing to a local bank account works today through integrated partners — Transak and MoonPay handle both the buy side and the sell side, in 100+ countries with card and bank rails. What's not yet built: a native MFW off-ramp that bypasses the partner cut. That's on the roadmap for markets where Transak and MoonPay don't have the strongest local banking coverage.

iOS App Store distribution. Apple's policies on crypto wallets are stricter than Google's. The PWA works perfectly on iOS as a home-screen-installed app, but the App Store version is a longer compliance project. For now, iOS users install the PWA via Safari; on Android, Google Play is in production review.

Identity verification beyond username. Right now, an MFW username is anonymous. That's a feature for many users and a blocker for B2B merchants who need KYC at the recipient level. A merchant-tier identity system with on-chain attestations is on the roadmap.

If any of these three are dealbreakers for your use case, MFW isn't your tool yet. If none of them are, MFW is probably the lowest-friction crypto payment integration available today.

Why I built it this way

I'm a solo developer working from Norway. No team, no funding, no investors. The constraint was: ship a real product that works for real users, alone, on a budget I can sustain indefinitely.

That constraint forces every architectural decision toward simplicity, predictability, and reusability. A PWA reuses the same code across every platform — one codebase to maintain. Cloudflare Workers reuse the same infrastructure across every chain — one runtime to operate. The username layer reuses across every integration — one identity primitive that works for users, developers, merchants and partners.

The result is a product that does more than its team size suggests it should, because the architectural choices keep compounding instead of fragmenting.

Every gatekeeper between code and customer is a place where solo founders normally lose. App Stores, payment processors, infrastructure providers, identity systems — each one says "form a US LLC, get a Stripe account, find a US bank, hire a compliance officer, raise $X to make this work." MFW exists because none of those gatekeepers were necessary. The PWA bypassed App Stores. Cloudflare Workers replaced ops infrastructure. Self-custody replaced banking partnerships. The Norwegian AS replaced needing a US legal entity.

The point isn't that MFW is the only way to build payments. The point is that what one person can ship in 2026 is wildly more than the prevailing wisdom suggests. The job is recognizing which gatekeepers are real and which ones you've been told to respect because the people doing the telling needed them.

What you can do with MFW today

If you're a user: open myfriendlywallet.io, install it to your home screen, send your first $5 to a friend with a username, and notice how it doesn't feel like crypto.

If you're a developer: copy the Pay Link example above, drop it in your site, and accept your first payment in five minutes. Then read the developer docs at myfriendlywallet.io/mfw-developers.html when you want more.

If you're a merchant in a market that traditional processors don't serve: the checkout widgets are at myfriendlywallet.io. No application, no underwriting, no rejection by industry.

If you're a builder who's been frustrated by gatekeepers: this is what the gate-free path looks like. Take what's useful and ignore the rest.

The wallet hides every chain underneath. The API exposes them in the cleanest possible primitive. The same architectural decision serves both audiences — and that's the whole story.