Stop Inventing Custom URIs: use URLs and deeplinks Instead
Standards are the plumbing of the internet. You don’t see them, but every click rides on them. When a website loads over https you’re cashing in three decades of engineering truce: any browser, any device, any network, same green lock. Crypto keeps trying to reinvent that wheel with shiny new URI schemes (bitcoin:, web3://, wallet://), and each one face-plants because it ignores the cardinal rule of tech adoption: if the link doesn’t open in Mom’s phone straight away, your standard is no standard at all. This post cuts through the alphabet soup to show why leaning on plain URLs plus deeplinking keeps you compatible with yesterday’s infrastructure and tomorrow’s wallets at the same time.
⚠️ Disclaimers: I speak only for my cranky self, and—yes—I still love Bitcoin even while trash-talking its UX.
Why this matters
You want regular people to press “Pay” without reading a spec, yet every new foo:// handler punts that burden back onto them, because browsers refuse to auto-trust a random protocol string and most wallets never bother to register one; Bitcoin’s bitcoin: lives only in nerd wallets, and IPFS’s ipfs:// works only after you install Brave or a plug-in—evidence that fifteen years of trying didn’t beat the gravity of https.
The graveyard (and a few survivors)
bitcoin:(2012, BIP-21) – click-to-pay still alive but strictly inside wallets.bitcoin:PoP (BIP-321 draft) – proof-of-payment callback, no mainstream use.lightning:/lnurl:– Lightning invoices and metadata; niche but working.bitcoincash:– BUIP-86; barely used.nano:– feeless transfers, works in Nano wallets only.xrp:/ripple:– XLS-32d draft; stalled.algorand:– ARC-26; shows up in Algorand mobile wallets.solana:– Solana Pay; usable because it’s just a URL under the hood.web+cardano://– CIP-13; polite idea, light adoption.ton:///tonkeeper://– deep-links for TON; lives only inside TON apps.wc:– WalletConnect pairing URI; popular because it rides on a QR code, not the browser.Sidenote:
wc://never aimed to be a browser-native protocol likebitcoin:; it’s just a lightweight envelope for a one-time pairing code. That narrow scope avoids fighting browser security teams while still giving wallets a single, well-known string to register for deep-links. The heavy lifting—relay networking, encryption, JSON-RPC—sits outside the URI, so upgrading from v1 to v2 didn’t require a new scheme, just new params. Custom schemes for full payment flows (bitcoin:,web3://) demand browser privileges and hit a wall;wc:piggybacks on existing transports and gets out of the way.
ethereum:– EIP-681/831; half-implemented, rarely encountered.web3://– ERC-4804; neat demo, zero browsers ship it.placeholder
wallet://– floated, never standardised.Content locators:
ipfs://,ipns://,dweb:,dat://,hyper://,sia://,ar://; all need extensions or gateways.Misc clones:
monero:,litecoin:,zcash:,at:,icp://— copy-paste bitcoin clones.
Fix
You ditch fragile protocol handlers and ship a plain https link:
https://pay.example.com/?address=0x…&chain=optimism&amount=1.23Happy path: wallet that understands the params and jumps straight into a signed transaction, fallback-path is 99 % of first-time users who land on a browser page that pipes the same info into WalletConnect, RainbowKit, or whatever SDK you favour: no extra install, no IANA plea, just working links.
What next
Standardise the query-string keys; you’ll convert more users and spend less time begging Chrome engineers for mercy. If you still crave novelty, write a gateway that upgrades https traffic to your chain under the hood—users won’t care and that’s the point.
DM me / hit me up if you’re hell-bent on adding yet another colon to the pile.
UNLICENSE—copy it, fork it, argue with it, idgaf.
But it needs a central server
You might worry that deeplinking “needs a central server,” but that fear is overblown: any site that speaks the spec can host the URL, e.g. https://zerion.com/pay?to=0x…, https://metamask.io/pay?to=0x…, or even a bare IP like http://12.34.56.78/pay?to=0x…; if they disappear you punt to a neutral mirror such as https://eth.limo/pay?to=0x…, because the link is just static metadata the wallet reads before negotiating out-of-band, so you can cURL it, mirror it, or shove it on IPFS and nothing breaks. No fresh protocol handler, no browser drama, no single choke-point, and most importantly not having to ask all the wallets to implement a standard.
Conclusion
Future-proof software isn’t just about shipping cool features. It’s about not breaking what already works. By sticking to the battle-tested https stack and layering wallet negotiations on top, you inherit global reach, automatic security patches, and a UX users already trust. Custom protocols can still live in niche power-tools, but if you want mainstream adoption you hitch your wagon to the broadest, oldest, most backward-compatible protocol we have. Call it boring if you like; boring built the web and boring will scale Web3. Hit me up if you think otherwise. I’ll bring coffee and RFCs.
Read more
UNLICENSE! You can’t steal thoughts. Attribution appreciated.