HTML + Bitcoin
The web already has a transaction model. You fill out a form, submit it, and something happens. The entire architecture of web commerce is this loop: HTML renders the interface, HTTP carries the intent, a server processes payment through a third party, and HTML renders the result.
Bitcoin removes the third party. What remains is simpler than what came before.
The rails already exist
HTML is the universal rendering layer. Every device has a browser. A payment request is just a thing to render — an amount, a memo, a button. Nothing new here.
URLs
are universal pointers.
A payment request as a URL —
/pay/@bob/5000?memo=Coffee
— is a complete expression of intent: who, how much, what for.
The URL is
the invoice. It works in a text message, an email, a QR code, a hyperlink.
Forms are the web's native input primitive. A form collects structured data and submits it. This is exactly what a payment interaction is: an amount, a recipient, a reason, a submit button.
Bitcoin transactions are programmable money. A transaction isn't just "send money" — it's a script that expresses the conditions for spending. The holder of this key can spend. Two of three parties must agree. Spendable only after a certain time. The script is the contract.
Signatures prove authorship. A signed payment request is a verifiable commitment. A signed transaction is a settled payment. The proof is in the math, not in a database.
The join point
Everything above exists independently. The missing piece is the join point — the moment where an HTML interaction becomes a Bitcoin transaction.
The form collects the intent. The transaction expresses it. The blockchain confirms it. No intermediate servers required for the settlement itself.
Four patterns
1. Form → Transaction
An HTML page with a form. The submit action builds a Bitcoin transaction in the browser, signs it with the user's key, and broadcasts it. The page doesn't need a backend for the payment. It needs a key and a connection to the network.
2. Link → Transaction
A URL encodes the payment parameters. Clicking it opens a page that builds and signs the transaction. This is the QR code pattern, the payment link pattern, the "pay" button pattern. The URL is the invoice.
3. Message → Transaction
A structured message carries payment parameters between two people. The receiver renders it however they want and acts on it. The message could arrive by any transport: WebSocket, chat, email, push notification.
4. Page → Continuous Settlement
A shared page between two parties where interactions produce transactions over time. Not one form, one submit, one payment. An ongoing session where value flows as the interaction progresses. The page is the interface. Transactions are the actions.
What disappears
| Web commerce | HTML + Bitcoin |
|---|---|
| Merchant account required | Keypair required |
| Payment processor mediates | Transaction is direct |
| Server stores order state | Transaction is the state |
| Receipt is a database record | Receipt is on-chain |
| Refund requires merchant action | Script can encode refund logic |
| Identity = account on platform | Identity = key |
The patterns are familiar. Forms, links, messages, pages. The difference is what happens when you press the button.
The transaction is the receipt
Bitcoin transactions carry value. OP_RETURN carries data alongside value. This means a transaction can be both settlement and record:
The transaction settles the payment. The OP_RETURN records what was paid for. The two are atomic — you can't have the receipt without the payment or the payment without the receipt. No order database. No receipt email. The transaction is self-documenting.
Peer-to-peer surfaces
When two people connect directly, the interface doesn't have to be a website that one of them hosts. It can be a shared surface — an HTML space where both parties can render structured objects and act on them.
A payment request appears. It's just HTML: an amount, a memo, a button. But the button builds a Bitcoin transaction. The transaction is signed. The signature proves who paid. The blockchain confirms when.
Chat is one surface. A shared workspace is another. A contract page where both parties edit terms and sign with their keys. A file exchange where preview, payment, and delivery happen in one interaction. The common thread: HTML as the rendering layer, Bitcoin as the action layer.
Build on this
These patterns are not proprietary. They're the natural consequence of combining two open technologies — HTML and Bitcoin — without an intermediary. Anyone can implement them.
What you need:
- • A keypair. Generate one in the browser. That's your identity and your signing capability.
- • HTML. Render whatever interface makes sense for your use case. A form, a page, a chat, a dashboard.
- • A transaction builder. Construct Bitcoin transactions in the browser. Libraries exist for this. The transaction is the action.
- • A broadcast endpoint. Send the signed transaction to the network. Any node will do.
That's the whole stack. Everything else — discovery, presence, handles, balance accounts, stablecoins — is useful infrastructure, but the foundation is just HTML that produces Bitcoin transactions.
Design principles
The URL is the invoice.
If you can express the payment request as a URL, do. URLs are the most portable, shareable, scannable, linkable format we have.
The form is the interface.
HTML forms already solve input collection, validation, and submission. A payment form is just a form whose action produces a transaction instead of an HTTP POST.
The transaction is the receipt.
A Bitcoin transaction is a signed, timestamped, immutable record. The txid is the receipt. OP_RETURN can carry the line items.
The key is the identity.
A user is a keypair. A handle resolves to a key. A signature proves identity. No account creation, no password, no OAuth.
The script is the contract.
Payment conditions — escrow, multi-sig, time locks, refund logic — are expressed in the transaction script, not in a terms-of-service document.
The page is the surface, not the system.
HTML renders the interaction. It doesn't own it. The same payment request can appear as a chat card, a standalone page, a QR code, or a line in a terminal. The rendering is independent of the primitive.
The sketch is simple: HTML for rendering, Bitcoin for settlement, signatures for proof. Commerce without intermediaries. Everything else is details.