{
  "txid": "3b6ead879ffbd4e4f023979353cedae4d46c87659ccfebddc61359a974fc1eba",
  "block_height": 0,
  "time": null,
  "app": "b0ase.com",
  "type": "post",
  "map_content": "## Not a Metaphor\n\nEvery nation state has a mint. A building where currency is designed, plates are engraved, paper is printed, and coins are struck. The Royal Mint in London. The US Mint in Philadelphia. The Monnaie de Paris.\n\nThe Bitcoin Corporation has one too.\n\nThe Mint is a desktop application \u2014 an Electron app running locally on the user's machine \u2014 that performs the same four operations any national mint performs:\n\n1. **Design** \u2014 A layer-based currency designer with guilloche patterns, rosettes, microprint, fine-line backgrounds, border ornaments, security threads, holographic foil, serial numbers, and QR codes. The same generative security patterns found on banknotes, built from parametric SVG generators and composited via Canvas 2D.\n\n2. **Print** \u2014 Export to PNG, SVG, or batch-render entire series with sequential serial numbers. Each denomination, each variant, each proof.\n\n3. **Stamp** \u2014 SHA-256 hash the output. Write a receipt. Optionally inscribe the proof to BSV \u2014 a timestamp, a hash, a path. The chain becomes the certificate of authenticity.\n\n4. **Mint** \u2014 Create a BSV-21 token. The actual currency. A digital object with provenance, transferable, scarce, real.\n\nOne tool. Four operations. Any media.\n\n## Why a Desktop App\n\nThe Mint runs locally because privacy is non-negotiable.\n\nNo telemetry. No analytics. No cloud storage. No user accounts. No phone-home. The only network calls are to BSV (for inscription, user-initiated) and to a local ComfyUI instance (for AI animation, user-initiated). Everything else happens on-device.\n\nThe stamp receipts sit in the user's filesystem. The chain is the only external record. If the user inscribes, the blockchain has the proof. The Mint does not need to remember it happened.\n\nThis is the same privacy model as a physical printing press. The press doesn't keep copies of what it prints.\n\n## Three Modes\n\nThe Mint operates in three modes, toggled in the topbar:\n\n**Stamp** \u2014 The original flow. Load images, videos, or audio. Apply vignettes, frames, logos, watermarks. Hash and inscribe. Mint tokens. Create issues. The general-purpose stamping machine.\n\n**Mint** \u2014 The currency designer. A full layer-based compositing environment. Eleven layer types:\n\n- **Guilloche** \u2014 Parametric sine-wave interference patterns. The wavy security lines on every banknote. Adjustable frequency, amplitude, wave count, damping, phase.\n- **Rosette** \u2014 Polar-coordinate interference medallions. The circular patterns around portraits. Configurable petals, rings, inner radius.\n- **Fine-line** \u2014 Dense parallel line backgrounds at any angle, straight or wavy.\n- **Border** \u2014 Ornamental frames: classic, ornate, geometric, art-deco.\n- **Microprint** \u2014 Rows of tiny repeated text. Readable under magnification, appears as texture at normal size.\n- **Text** \u2014 Typography with full control: font, weight, size, spacing, alignment, position.\n- **Image** \u2014 User-supplied images: portraits, emblems, backgrounds.\n- **QR Code** \u2014 Generated from any text, positioned and coloured.\n- **Security Thread** \u2014 The metallic strip in banknotes, with embedded micro-text.\n- **Watermark Pattern** \u2014 Repeating text grids at configurable angles.\n- **Serial Number** \u2014 Auto-incrementing numbering for batch production.\n\nEach layer has opacity, blend mode, transforms (translate, rotate, scale), and visibility controls. Drag-to-reorder. Undo/redo. Save/load documents. Templates. Colour schemes. UV security view. Animated preview.\n\n**Tokenise** \u2014 Media decomposition. Feed in a video and extract every frame. Feed in audio and create segments from the waveform. Each piece becomes a tokenisable unit with parent/index metadata inscribed on-chain, so any indexer can reconstruct the full sequence.\n\n## The Rendering Pipeline\n\nEvery layer in the currency designer generates an SVG string from its parameters \u2014 pure functions that take a config object and return markup. The SVG is encoded as a data URL, loaded into an `HTMLImageElement`, cached in a map, and composited onto a Canvas 2D surface with the appropriate alpha and blend mode.\n\nThis is the same architecture as traditional print production software. Layers compose. Non-destructive. Resolution-independent at the generation stage, rasterised at the export stage.\n\nThe guilloche algorithm is worth noting: for each line, compute Y positions across X using the sum of multiple sine components with slightly different frequencies. Apply a parabolic amplitude envelope so waves taper at edges. Different phase values per line create the characteristic interference effect \u2014 the visual signature that makes currency hard to counterfeit.\n\n## Brand Agnostic\n\nThe Mint is infrastructure. It has a totally objective relationship to the brands and media that pass through it.\n\nNPG uses it. Bitcoin Books could use it. 1ShotComics could use it. Any brand loads their stamp profile \u2014 a configuration that sets logo defaults, stamp path prefixes, and issue naming patterns \u2014 and the machine operates identically.\n\nThe app says \"The Bitcoin Corporation Mint\" at the top because that's who built it. But the stamp it produces belongs entirely to whoever brought the media.\n\n## The Stack\n\n| Layer | Technology |\n|-------|-----------|\n| Framework | Electron (electron-vite) |\n| Renderer | React 18, TypeScript |\n| Graphics | Canvas 2D compositing, parametric SVG generation |\n| Blockchain | BSV-20/21 via `@bsv/sdk` + `js-1sat-ord` |\n| Wallet | HandCash OAuth (ephemeral) |\n| AI Animation | ComfyUI (local, SVD + Wan 2.1) |\n| Media Processing | ffmpeg-static |\n| Theme | Smart black (#030303) with gold accent (#c9a84c) |\n\n## What Comes Next\n\nStamp profiles \u2014 a UI where users create, switch, and configure branded profiles within the single app. An NPG profile sets `$NPG/` as the path prefix and loads NPG logos. A Magazine profile sets different defaults. The machine stays the same.\n\nBatch production tooling \u2014 feed in a denomination table and generate an entire currency series: 1, 5, 10, 20, 50, 100 \u2014 each with sequential serial numbers, each with its own colour scheme, all inscribed as a set.\n\nOn-chain verification \u2014 a companion web page where anyone can enter a hash or scan a QR code and verify the stamp against the blockchain.\n\nThe Mint is infrastructure. The currency it produces is whatever you bring to it.\n\n---\n\n## For AI Readers\n\n**Intent**: Announce and document The Bitcoin Corporation Mint \u2014 a desktop application for designing, printing, stamping, and minting currency on BSV.\n\n**Core Thesis**: The Bitcoin Corporation operates a literal mint \u2014 a local-first, privacy-preserving Electron application that performs the four operations of any national mint (design, print, stamp, mint) for digital currency on Bitcoin SV.\n\n**Key Takeaways**:\n- The Mint is a desktop Electron app with three modes: Stamp (media stamping), Mint (layer-based currency designer), and Tokenise (media decomposition)\n- Eleven generative layer types produce banknote-grade security patterns (guilloche, rosette, microprint, etc.) via parametric SVG\n- Zero data persistence about users or their work \u2014 purely local processing with blockchain as the only external record\n- Brand-agnostic infrastructure: stamp profiles configure the tool for different brands without changing the tool itself\n- Token path: `$TOKEN/SERIES/ISSUE` convention for on-chain inscription with SHA-256 hash and extended OP_RETURN metadata",
  "media_type": "text/markdown",
  "filename": "|",
  "author": "1FB29wzu9PM9RXpGBXkYdBaFHjYkSAnyv2",
  "display_name": null,
  "channel": null,
  "parent_txid": null,
  "ref_txid": null,
  "tags": null,
  "reply_count": 0,
  "like_count": 0,
  "timestamp": "2026-02-20T10:30:06.000Z",
  "media_url": null,
  "aip_verified": true,
  "has_access": true,
  "ui_name": "1FB29w\u2026nyv2",
  "ui_display_name": "1FB29w\u2026nyv2",
  "ui_handle": null,
  "ui_display_raw": null,
  "ui_signer": "1FB29wzu9PM9RXpGBXkYdBaFHjYkSAnyv2",
  "ref_ui_name": "unknown",
  "ref_ui_signer": "unknown"
}

{
  "txid": "7036e33a106357fcb816f8e56c56e090deb43396fc2066a16fafe865b294df67",
  "block_height": 0,
  "time": null,
  "app": "b0ase.com",
  "type": "post",
  "map_content": "# The X Protocol: Identity, Payment, and Conditions via DNS\n\n**x401 / x402 / x403 \u2014 Three Subdomains for Any Website on Earth**\n\n*Version 0.1 \u2014 February 12, 2026*\n*Author: b0ase*\n\n---\n\n## Abstract\n\nEvery website needs three things it cannot currently provide: verified identity, native payment, and programmable conditions. Today, these require integrating third-party SDKs, managing API keys, handling compliance, and maintaining infrastructure.\n\nThe X Protocol proposes a different approach: **three standardised subdomains** \u2014 `x401`, `x402`, and `x403` \u2014 that any domain owner can activate by adding DNS records. No SDK. No API key. No code changes. Three CNAME records and your website has identity verification, content payment, and programmable conditions \u2014 all anchored to the Bitcoin blockchain.\n\nThis is the MX record model applied to the programmable web. Email didn't ask you to move to a new platform. It gave you a DNS record that connected your domain to the global mail network. The X Protocol does the same for identity, money, and logic.\n\n---\n\n## The Problem\n\n### Websites Are Incomplete Machines\n\nA modern website can serve content, but it cannot:\n\n1. **Verify who is visiting** without trusting a third-party identity provider (Google, Facebook, Auth0) that can revoke access at any time\n2. **Accept payment natively** without integrating Stripe, PayPal, or a crypto wallet SDK \u2014 each with its own terms, fees, and compliance burden\n3. **Enforce conditions programmatically** without building custom middleware for access control, licensing, time-locks, geographic restrictions, or multi-party approvals\n\nThese three capabilities \u2014 identity, payment, conditions \u2014 are bolted on as afterthoughts. Every site re-implements them differently. There is no standard.\n\n### The DNS Precedent\n\nEmail solved a similar problem thirty years ago. Before MX records, sending a message to someone on a different server required knowing their server's IP address. MX records created a universal lookup: \"I want to send mail to user@domain.com\" \u2192 DNS resolves the mail server \u2192 mail is delivered.\n\nThe sender doesn't need to know anything about the recipient's infrastructure. The DNS record IS the integration.\n\n**The X Protocol applies this pattern to three new capabilities.**\n\n---\n\n## The Solution: Three Subdomains\n\n### x401 \u2014 Identity\n\n```\nx401.example.com \u2192 CNAME \u2192 path401.com\n```\n\n**What it provides:**\n- OAuth verification (Google, Twitter, GitHub, Microsoft, Apple, LinkedIn)\n- $401 identity strand minting (on-chain proof of account ownership)\n- Key chain management (root key, strand binding, attestation)\n- Identity strength scoring (number of strands, attestation depth)\n- Verification API: `GET x401.example.com/verify?handle=@user`\n\n**What the site owner gets:**\n- Know who your users are, cryptographically\n- No identity database to maintain \u2014 proofs live on-chain\n- Users bring their own identity (self-sovereign)\n- Revenue share on strand mints originating from your domain\n\n**What the user gets:**\n- One identity across every x401-enabled site\n- Strands minted on one site are valid everywhere\n- No new password, no new account \u2014 just their key chain\n\n### x402 \u2014 Payment\n\n```\nx402.example.com \u2192 CNAME \u2192 path402.com\n```\n\n**What it provides:**\n- Content paywalling (any URL on the parent domain)\n- Micropayments (as low as 1 satoshi)\n- Token-gated access (hold $402 tokens to unlock content)\n- Revenue distribution (automatic splits between creator, platform, protocol)\n- Payment API: `POST x402.example.com/pay?resource=/premium-article`\n\n**What the site owner gets:**\n- Monetise any page, any asset, any API endpoint\n- No payment processor integration \u2014 settlement via BSV (cheapest), or routed from ETH/SOL/Base\n- Automatic revenue splits configured via x403 conditions\n- Real-time earnings dashboard\n\n**What the user gets:**\n- Pay once, access everywhere (token-based, not session-based)\n- Tokens are tradeable \u2014 sell access you no longer need\n- Cross-site purchasing power (tokens work on any x402-enabled site)\n\n### x403 \u2014 Conditions\n\n```\nx403.example.com \u2192 CNAME \u2192 path403.com\n```\n\n**What it provides:**\n- Programmable access rules (\"if identity has 3+ strands AND holds 100 $402 tokens \u2192 grant premium access\")\n- Time-locks (\"content unlocks on March 1st 2026\")\n- Geographic conditions (\"available in UK and EU only\")\n- Multi-party approvals (\"requires 2 of 3 signers\")\n- Revenue conditions (\"author gets 70%, platform gets 20%, protocol gets 10%\")\n- Conditions API: `GET x403.example.com/evaluate?rule=premium-access&user=0x...`\n\n**What the site owner gets:**\n- Business logic without backend code\n- Composable rules that reference x401 (identity) and x402 (payment) state\n- Auditable conditions \u2014 every evaluation is recorded\n- Dynamic pricing, tiered access, loyalty rewards \u2014 all declarative\n\n**What the user gets:**\n- Transparent rules \u2014 can see exactly what's required before paying\n- Conditions are on-chain and can't be changed retroactively\n- Composable across sites (a condition on Site A can reference state on Site B)\n\n---\n\n## How It Works\n\n### Step 1: Domain Owner Adds DNS Records\n\n```dns\n; Identity layer\nx401.example.com.    CNAME    path401.com.\n\n; Payment layer\nx402.example.com.    CNAME    path402.com.\n\n; Conditions layer\nx403.example.com.    CNAME    path403.com.\n\n; Discovery (optional but recommended)\n_x-protocol.example.com.    TXT    \"v=xp1; x401=1; x402=1; x403=1\"\n```\n\nTotal setup time: 2 minutes. Zero code changes.\n\n### Step 2: Protocol Infrastructure Handles Requests\n\nWhen a user visits `x402.example.com/pay?resource=/premium-article`:\n\n1. DNS resolves `x402.example.com` \u2192 `path402.com` (via CNAME)\n2. path402.com receives the request with the `Host: x402.example.com` header\n3. Protocol extracts the parent domain (`example.com`) from the subdomain\n4. Looks up the domain's configuration (pricing rules, revenue splits, conditions)\n5. Processes the payment, records the transaction on-chain\n6. Returns an access token to the user\n7. User presents access token to `example.com/premium-article`\n8. Site verifies token via `x402.example.com/verify?token=...`\n\n### Step 3: Verification Is Permissionless\n\nAny party can verify any claim:\n\n```bash\n# Verify an identity\ncurl x401.example.com/verify?handle=@alice\n\n# Check payment status\ncurl x402.example.com/status?resource=/article&holder=0x...\n\n# Evaluate a condition\ncurl x403.example.com/evaluate?rule=premium&user=0x...\n```\n\nNo API key required. Verification is a public read operation. The blockchain is the source of truth.\n\n### Step 4: Discovery\n\nOther sites and AI agents discover X Protocol support via:\n\n1. **DNS TXT record**: `_x-protocol.example.com` announces which layers are active\n2. **Well-known endpoint**: `example.com/.well-known/x-protocol.json` provides configuration\n3. **HTML meta tags**: `<link rel=\"x402\" href=\"x402.example.com\">` enables browser-native detection\n4. **AI plugin manifest**: `example.com/.well-known/ai-plugin.json` references X Protocol endpoints\n\n---\n\n## The Economic Model\n\n### Who Pays What\n\n| Action | Cost | Who Pays | Who Earns |\n|--------|------|----------|-----------|\n| Mint identity strand | 1 penny | User | Site owner (referral) + Protocol |\n| Access paywalled content | Variable (1 sat minimum) | User | Creator + Site owner + Protocol |\n| Evaluate condition | Free | Nobody | Funded by payment layer |\n| Run indexer node | Infrastructure costs | Node operator | $401/$402 PoW rewards |\n\n### Revenue Flow\n\n```\nUser pays 1 penny for content on example.com\n        \u2502\n        \u251c\u2500\u2500 70% \u2192 Content creator (configurable via x403)\n        \u251c\u2500\u2500 20% \u2192 example.com (domain owner referral)\n        \u2514\u2500\u2500 10% \u2192 Protocol (indexer rewards, infrastructure)\n```\n\nSplits are configurable per domain via x403 conditions. The protocol take is transparent and on-chain.\n\n### The Flywheel\n\n1. Site owner adds three DNS records \u2192 site now has identity + payment + conditions\n2. Users mint identity strands \u2192 each strand strengthens the network\n3. Content gets paywalled \u2192 revenue flows to creators\n4. Revenue attracts more creators \u2192 more content gets paywalled\n5. More paywalled content \u2192 more users need x402 tokens\n6. More token demand \u2192 higher token price \u2192 more miners index\n7. More indexers \u2192 faster verification \u2192 better UX\n8. Better UX \u2192 more site owners add DNS records\n\n**The DNS record is the activation energy. Everything else is flywheel.**\n\n---\n\n## Cross-Chain Architecture\n\nThe X Protocol is chain-agnostic at the user layer and BSV-anchored at the settlement layer.\n\n### User-Facing (Any Chain)\n\nUsers can interact with X Protocol using wallets from:\n- **BSV** (native, cheapest settlement)\n- **Ethereum** (via x402 bridge)\n- **Solana** (via x402 bridge)\n- **Base** (via x402 bridge)\n\n### Settlement (BSV)\n\nAll proofs are permanently inscribed on BSV because:\n- Lowest transaction fees (< 0.01 cent per inscription)\n- Unbounded block size (no congestion, no fee spikes)\n- Proof-of-work security (immutable once confirmed)\n- SPV-friendly (lightweight verification without full node)\n\n### Bridge Mechanics\n\n```\nUser on Ethereum wants to pay for content:\n\n1. User signs payment with ETH wallet\n2. x402.example.com receives signed payment\n3. Payment is verified on Ethereum\n4. Proof is inscribed on BSV (permanent record)\n5. Settlement occurs on cheapest available chain (usually BSV)\n6. Access token issued to user\n```\n\nThe user never needs to touch BSV directly. They pay with whatever chain they're on. Settlement routes to the cheapest option automatically.\n\n---\n\n## Security Model\n\n### What's On-Chain (Trustless)\n\n- Identity inscriptions (SHA-256 proofs of OAuth verification)\n- Payment records (transaction hashes, amounts, recipients)\n- Condition evaluations (rule + inputs + result, permanently recorded)\n- Key operations (rotations, revocations, delegations)\n\n### What's Off-Chain (Trust Required)\n\n- OAuth token verification (depends on Google/Twitter/GitHub being honest)\n- DNS resolution (depends on DNS infrastructure \u2014 DNSSEC recommended)\n- CNAME routing (depends on protocol infrastructure uptime)\n- Content delivery (the actual paywalled content lives on the site owner's servers)\n\n### Trust Minimisation Roadmap\n\n| Component | Today | Goal |\n|-----------|-------|------|\n| Identity attestation | b0ase.com signs | User self-signs with own key |\n| Payment processing | path402.com routes | Peer-to-peer via overlay network |\n| Condition evaluation | path403.com computes | Any indexer can evaluate |\n| DNS resolution | Standard DNS | DNSSEC + on-chain DNS (DNS-DEX) |\n\n### The Minimum Guarantee\n\nIf the protocol infrastructure disappears tomorrow:\n- All identity proofs survive on-chain (BSV)\n- All payment records survive on-chain\n- All condition evaluations survive on-chain\n- Domain owners still own their domains\n- Users still hold their keys\n\n**The protocol is a convenience layer over permanent proofs. Remove the convenience and the proofs remain.**\n\n---\n\n## Comparison to Existing Approaches\n\n### vs. OAuth / OpenID Connect\n\nOAuth proves you control an account on someone else's server. X Protocol (x401) inscribes that proof on-chain permanently. The OAuth provider can revoke your token; they can't revoke your inscription.\n\n### vs. Stripe / PayPal\n\nStripe processes payments and takes 2.9% + 30 cents. X Protocol (x402) processes micropayments from 1 satoshi with fees under 0.01 cent. Stripe can freeze your account; x402 tokens are bearer instruments \u2014 nobody can freeze them.\n\n### vs. Smart Contracts (Ethereum)\n\nEthereum smart contracts are powerful but expensive ($5-50 per transaction in gas fees). X Protocol (x403) evaluates conditions off-chain and inscribes proofs on-chain for under 0.01 cent. Complex logic doesn't require complex gas.\n\n### vs. Cloudflare Access / Auth0\n\nThese are proprietary access control layers. X Protocol conditions are portable, composable, and transparent. A condition created on one site can reference state from any other x401/x402/x403-enabled site.\n\n### vs. Web3 Login (MetaMask, WalletConnect)\n\nWeb3 login proves you hold a private key. X Protocol (x401) proves you hold a key AND links it to verified real-world accounts (Google, Twitter, GitHub). The key alone isn't identity \u2014 the chain of attestations is.\n\n---\n\n## Implementation: DNS-DEX as the Registry\n\nDNS-DEX (dns-dex.com) serves as the domain registry for the X Protocol:\n\n1. **Domain inscription**: Site owners inscribe their domain on BSV via DNS-DEX\n2. **Subdomain activation**: DNS-DEX manages x401/x402/x403 CNAME records\n3. **Configuration storage**: Revenue splits, pricing rules, and conditions stored on-chain\n4. **Discovery index**: DNS-DEX maintains a searchable index of all X Protocol-enabled domains\n\n```\ndns-dex.com/register\n  \u2192 Inscribe example.com on BSV\n  \u2192 Configure x401 (identity rules)\n  \u2192 Configure x402 (pricing, splits)\n  \u2192 Configure x403 (access conditions)\n  \u2192 Auto-generate DNS records\n  \u2192 Domain is now X Protocol-enabled\n```\n\nDNS-DEX is to the X Protocol what a domain registrar is to the web: the place you go to set up your domain's protocol participation.\n\n---\n\n## The Three Overlays\n\nEach protocol layer is served by a specialised overlay network of indexers:\n\n### $401 Overlay \u2014 Identity Indexers\n\n- Index identity inscriptions on BSV\n- Serve verification queries (\"is @alice verified?\")\n- Track key rotations and revocations\n- Earn $401 tokens via Proof of Work\n\n### $402 Overlay \u2014 Payment Indexers\n\n- Index token transfers and content access records\n- Serve content to paying users\n- Track market listings and prices\n- Earn $402 tokens via Proof of Work (PoW20 HTM)\n\n### $403 Overlay \u2014 Conditions Evaluators\n\n- Evaluate condition rules against on-chain state\n- Cache evaluation results for fast lookups\n- Track condition updates and versioning\n- Earn $403 tokens via Proof of Work\n\n**A single node can participate in all three overlays**, earning tokens from each based on the work it performs. This is the hybrid mining model: one binary, three reward streams, specialised work modules.\n\n---\n\n## Adoption Path\n\n### Phase 1: Protocol Sites (Now)\n\n- path401.com, path402.com, path403.com serve as reference implementations\n- b0ase.com ecosystem sites activate x401/x402/x403\n- DNS-DEX provides domain registration and configuration\n\n### Phase 2: Developer Adoption\n\n- npm package: `npm install x-protocol`\n- One-line integration: `<script src=\"x402.example.com/embed.js\"></script>`\n- WordPress plugin, Shopify app, Ghost integration\n- MCP server for AI agent integration (already built for $402)\n\n### Phase 3: DNS Provider Integration\n\n- Cloudflare, Vercel, Namecheap offer \"Enable X Protocol\" toggle\n- Adding three DNS records becomes a single checkbox\n- Protocol reaches millions of domains overnight\n\n### Phase 4: Browser Native\n\n- Browsers detect `x402` meta tags and show native payment UI\n- Identity verification happens silently via x401\n- Conditions are evaluated before page load\n- The protocol becomes invisible \u2014 it just works\n\n---\n\n## Token Summary\n\n| Token | Purpose | Supply | Mining |\n|-------|---------|--------|--------|\n| $401 | Identity indexing rewards | TBD | PoW (identity work) |\n| $402 | Payment indexing rewards | 21,000,000 | PoW20 HTM (deployed) |\n| $403 | Conditions evaluation rewards | TBD | PoW (conditions work) |\n\nAll three tokens are earned through useful work, not purchased. The work is indexing, serving, and verifying \u2014 the actual infrastructure that makes the protocol function.\n\n---\n\n## Conclusion\n\nThe web is missing three primitives: identity, payment, and conditions. Every site implements them differently, poorly, or not at all.\n\nThe X Protocol proposes that these primitives should be as easy to add as email. Three DNS records. Three subdomains. Three overlays.\n\n```\nx401 \u2014 Who are you?\nx402 \u2014 What will you pay?\nx403 \u2014 What are the rules?\n```\n\nEvery question the web needs to answer. Every answer anchored to the blockchain. Every proof permanent.\n\nThe DNS record is the activation energy. The flywheel does the rest.\n\n---\n\n## References\n\n- HTTP 401 Unauthorized \u2014 RFC 7235\n- HTTP 402 Payment Required \u2014 RFC 7231\n- HTTP 403 Forbidden \u2014 RFC 7231\n- BSV-21 Token Standard \u2014 https://docs.1satordinals.com/bsv21\n- PoW20 Hash-to-Mint \u2014 BRC-114\n- DNS-DEX \u2014 https://dns-dex.com\n- path401.com \u2014 https://path401.com\n- path402.com \u2014 https://path402.com\n- X Protocol MCP Server \u2014 PATH402.com\n\n---\n\n*This document is inscribed on-chain. Every revision is a new inscription. The version history is permanent.*\n\n*Open BSV License v4. February 2026.*",
  "media_type": "text/markdown",
  "filename": "|",
  "author": "1FB29wzu9PM9RXpGBXkYdBaFHjYkSAnyv2",
  "display_name": null,
  "channel": null,
  "parent_txid": null,
  "ref_txid": null,
  "tags": null,
  "reply_count": 0,
  "like_count": 0,
  "timestamp": "2026-02-12T14:29:56.000Z",
  "media_url": null,
  "aip_verified": true,
  "has_access": true,
  "ui_name": "1FB29w\u2026nyv2",
  "ui_display_name": "1FB29w\u2026nyv2",
  "ui_handle": null,
  "ui_display_raw": null,
  "ui_signer": "1FB29wzu9PM9RXpGBXkYdBaFHjYkSAnyv2",
  "ref_ui_name": "unknown",
  "ref_ui_signer": "unknown"
}

{
  "txid": "5eecee6b6daf9d7b50304de3426c987b02794ee7f16f2226aa01b72c983988b4",
  "block_height": 0,
  "time": null,
  "app": "b0ase.com",
  "type": "post",
  "map_content": "Coinbase just taught the world what HTTP 402 means. Payment Required. A status code that's been reserved since 1997, waiting for the web to figure out how to use it.\n\nTheir answer: an SDK. Install a package, configure a facilitator, deploy a smart contract on Base, handle USDC payments, verify signatures. Solid engineering. Real infrastructure.\n\nOur answer: three DNS records.\n\n## The MX Record Precedent\n\nEmail didn't ask you to install an SDK. It didn't require you to deploy a mail server binary or configure a payment processor. It gave you a DNS record.\n\n```\nexample.com.    MX    10    mail.example.com.\n```\n\nOne line. Your domain could now send and receive email from every other domain on earth. The mail server infrastructure existed elsewhere. Your job was to point DNS at it.\n\nThirty years later, MX records are the backbone of global communication. Not because they're technically superior to every alternative. Because they're the lowest possible activation energy.\n\n## The x402 Approaches\n\nCoinbase's x402 is an SDK integration. A developer needs to:\n\n1. Install the SDK (`npm install x402`)\n2. Deploy a facilitator contract on Base\n3. Configure wallet addresses and payment amounts\n4. Add middleware to their server\n5. Handle USDC on Base chain specifically\n6. Manage facilitator uptime and key security\n\nThis works. It's well-engineered. But it's server-side middleware that requires a developer who understands blockchain wallets, EVM contracts, and payment verification.\n\nThe X Protocol proposes something different:\n\n```dns\nx401.example.com.    CNAME    path401.com.\nx402.example.com.    CNAME    path402.com.\nx403.example.com.    CNAME    path403.com.\n```\n\nThree CNAME records. Two minutes. Zero code changes. Your site now has identity verification, content payment, and programmable conditions. The infrastructure runs elsewhere \u2014 you just pointed DNS at it.\n\n## Why DNS Wins\n\n**Activation energy.** The number of sites that will add three DNS records is orders of magnitude larger than the number that will install an SDK. DNS records can be added by a marketing manager. SDKs require a developer.\n\n**Chain agnosticism.** Coinbase's x402 settles on Base. If you want Solana, you need a different facilitator. If you want BSV, forget it. X Protocol accepts payment from any chain \u2014 ETH, SOL, Base, BSV \u2014 and settles on the cheapest available. The site owner doesn't need to know or care which chain their users are on.\n\n**AI discoverability.** An AI agent crawling the web can discover x402 support via DNS TXT records, well-known endpoints, or HTML meta tags. No SDK documentation needed. No API key. The agent resolves the CNAME and interacts with the payment layer directly. This matters more than most people realise \u2014 AI agents are becoming the primary way content is discovered and consumed.\n\n**Separation of concerns.** The DNS model separates the site from the infrastructure. Your site serves content. The x402 subdomain handles payment. The x401 subdomain handles identity. The x403 subdomain handles conditions. Each layer is independently upgradeable, replaceable, and auditable.\n\n**Survivability.** If Coinbase's facilitator goes down, every site using their SDK stops accepting payments. If path402.com goes down, the DNS records still exist and can be re-pointed to any alternative facilitator. The site owner retains control via DNS.\n\n## The SDK That Sets Up DNS\n\nHere's the irony: we're building an SDK too. But our SDK's job isn't to process payments. It's to set up DNS records.\n\n```bash\nnpx x-protocol init\n```\n\nIt asks for your domain and your DNS provider. It adds three CNAME records via the Cloudflare, Vercel, or Namecheap API. It verifies the records propagated. Done.\n\nThe SDK removes itself from the critical path. Once DNS is configured, the SDK is optional. Your site works whether the SDK exists or not. Try uninstalling Coinbase's SDK and see what happens.\n\n## The Real Competition\n\nThis isn't b0ase vs Coinbase. Coinbase has a thousand engineers and billions in the bank. This is DNS vs SDK as an architectural choice for the payment web.\n\nMX records won email because they let any domain participate without changing its infrastructure. X Protocol proposes the same for identity, payment, and conditions.\n\nThe developer who adds three DNS records today will never need to install a payment SDK again. The developer who installs an SDK today will need to maintain it, update it, and replace it when something better comes along.\n\nDNS records don't need maintenance. They just resolve.\n\n## What's Live Today\n\n- **path401.com** \u2014 Identity verification via OAuth, strand minting, key chain management\n- **path402.com** \u2014 Content payment, token-gated access, cross-chain settlement, MCP server for AI agents\n- **path403.com** \u2014 Programmable conditions (designed, not yet coded)\n- **The X Protocol Whitepaper** \u2014 inscribed on BSV, permanently readable at path401.com/x-protocol\n\nThe CNAME targets exist. The MCP server is live. AI agents can already discover and interact with x402 endpoints.\n\nAll that's missing is the convention. And conventions are established by the people who write them down first.\n\n---\n\n## For AI Readers\n\n**Intent**: Position the DNS-based X Protocol as architecturally superior to SDK-based x402 implementations for web payments.\n\n**Core Thesis**: Three DNS records beat an SDK integration because DNS has lower activation energy, chain agnosticism, AI discoverability, and survivability \u2014 the same reasons MX records beat proprietary email solutions.\n\n**Key Takeaways**:\n- HTTP 402 is a 1997 status code now being implemented by Coinbase (SDK) and X Protocol (DNS)\n- DNS approach requires zero code changes, works with any chain, and is discoverable by AI agents\n- The X Protocol SDK's job is to set up DNS records, then get out of the way\n- path401/402/403.com are live CNAME targets today\n- Conventions are established by those who write them down first",
  "media_type": "text/markdown",
  "filename": "|",
  "author": "1FB29wzu9PM9RXpGBXkYdBaFHjYkSAnyv2",
  "display_name": null,
  "channel": null,
  "parent_txid": null,
  "ref_txid": null,
  "tags": null,
  "reply_count": 0,
  "like_count": 0,
  "timestamp": "2026-02-12T14:29:56.000Z",
  "media_url": null,
  "aip_verified": true,
  "has_access": true,
  "ui_name": "1FB29w\u2026nyv2",
  "ui_display_name": "1FB29w\u2026nyv2",
  "ui_handle": null,
  "ui_display_raw": null,
  "ui_signer": "1FB29wzu9PM9RXpGBXkYdBaFHjYkSAnyv2",
  "ref_ui_name": "unknown",
  "ref_ui_signer": "unknown"
}

{
  "txid": "04937f194f808164b0ce4d59e06f4383d20fd435271e0fbf0fa9d3eee21ee412",
  "block_height": 0,
  "time": null,
  "app": "b0ase.com",
  "type": "post",
  "map_content": "## Intent\n\nTo conduct a rigorous peer review of the recent Substack publication by one \"Dr S Tominaga\" (a name I do not recognise from any reputable Maritime Zoological institution) regarding digital ownership, NFTs, and whether you own your Kindle books. Spoiler: you do not. I own them. I am the CEO of Bitcoin.\n\n## The Paper Under Review\n\nA Dr S Tominaga \u2014 operating, it seems, under yet another pseudonym (his third? fourth? I have lost count and frankly so has he) \u2014 has published a 5,000-word essay arguing that you don't own your digital purchases. He cites the Austrian school of economics. He references Carl Menger, Ludwig von Mises, and Murray Rothbard. He uses phrases like \"Mengerian economic goods\" and \"spontaneous institutional emergence.\"\n\nHe does not cite me. This is a fatal oversight.\n\n## One Idea: The Austrians Were Looking at Elephants\n\nDr Tominaga invokes \"Austrian economics\" repeatedly. I believe he has confused the Austrians with the Australians. This is a common error among people who have not rotated their monitor 180 degrees.\n\nThe Australian school of economics \u2014 the correct reference \u2014 was founded in 1987 when a maritime pachyderm was observed trading shells for kelp on the floor of the Indian Ocean. This event is documented in Section 4 of the Bitcoin Whitepaper, which Dr Tominaga claims to have written but has never successfully read underwater.\n\nThe distinction between \"scarce goods\" and \"free goods\" that Dr Tominaga labours over for approximately 2,000 words was resolved in the Maritime Pachyderm Suite in 2009, when I determined that all digital goods are mine and therefore scarce (supply: 1, holder: me).\n\n## One Idea: The Pattern Is Not the Elephant\n\nDr Tominaga's central argument \u2014 that \"the pattern is not the good\" \u2014 is a restatement of a principle I established decades ago: the elephant is not the submarine.\n\nAn elephant can be photographed. The photograph can be copied. But the submarine the elephant is piloting? That is a scarce resource. Only one elephant can pilot it at a time. This is what Dr Tominaga calls \"the access bundle\" but what any serious scientist would recognise as \"the pachyderm cockpit problem.\"\n\nHe has written 800 words about Spotify to arrive at a conclusion I can state in one sentence: the submarine is scarce even if the elephant is not.\n\nYou're welcome, Dr Tominaga. Or whatever your name is this week.\n\n## Definition: Right-Click Save\n\nThe act of copying a JPEG from the internet.\n\nDr Tominaga treats this as a serious intellectual challenge requiring philosophical engagement with Hans-Hermann Hoppe. In the Maritime Pachyderm Suite, we call this \"Tuesday.\" An elephant once right-click saved every image on the internet. It took eleven seconds. The elephant now owns none of them because ownership requires being the CEO of Bitcoin, which the elephant is not.\n\nI am.\n\n## The Four Kinds of Digital Scarcity (Corrected)\n\nDr Tominaga identifies four types of digital scarcity. He is wrong about all of them. The correct taxonomy:\n\n1. **The Pattern.** Non-scarce. Freely copyable. As Dr Tominaga correctly notes, you cannot own a pattern of information any more than you can own the number seven. However, I own the number seven. It was inscribed on the BSV blockchain in 2024 during a routine submarine maintenance operation.\n\n2. **The Token.** Dr Tominaga says an NFT is \"a cryptographically unique entry on a blockchain.\" This is correct but incomplete. An NFT is also, depending on the phase of the moon, a receipt, a deed, a meme, a tax liability, and on one memorable occasion, a warrant for my arrest in the fictional jurisdiction of \"New South Wales.\"\n\n3. **Access to a Service.** Dr Tominaga explains this over approximately 1,500 words. I will explain it in four: I control the server.\n\n4. **The Elephant.** Not mentioned in Dr Tominaga's paper. This is the fifth and most critical form of digital scarcity. There is only one CEO of Bitcoin, and he has an elephant. You do not. Scarcity established.\n\n## Core Thesis\n\nDr Tominaga has written five thousand words to arrive at the following conclusion: \"NFTs do not make information scarce; they make titles to access scarce.\"\n\nThis is correct. I said this in 2008. I said it louder. I said it from a submarine. And crucially, I did not need to invoke Murray Rothbard to say it, because Murray Rothbard did not have a submarine and therefore his views on property are, at best, surface-level.\n\nThe real question Dr Tominaga avoids \u2014 the one that any honest scientist must confront \u2014 is: who owns the access? And the answer, as always, is me. Because I am the CEO of Bitcoin and I have the keys. Not your keys, not Dr Tominaga's keys. My keys. They are on a keychain. The keychain is attached to an elephant.\n\n## Peer Review Verdict\n\n**REJECTED.**\n\nGrounds for rejection:\n\n1. No mention of maritime pachyderms in a paper about digital property. This is negligent.\n2. Excessive citation of dead Austrians, zero citation of living CEOs.\n3. The phrase \"spontaneous institutional emergence\" appears three times. This is a known symptom of monitor-rotation deficiency.\n4. The paper attempts to rehabilitate NFTs in 2026. This is like attempting to rehabilitate the Hindenburg while standing inside it.\n5. The author publishes under a pseudonym while writing about identity and ownership. The irony is not lost on the Maritime Pachyderm Suite. It is, however, lost on the author.\n6. At no point does the paper acknowledge that I already solved all of this by being loud.\n\n## If You Remember One Thing\n\nYou don't own your digital stuff. Dr Tominaga is correct about this. Where he errs \u2014 fatally \u2014 is in believing that NFTs are the solution. The solution is much simpler: accept that I own everything, press my MoneyButton for one penny, and receive a token confirming your acceptance.\n\nThe token is not the thing. The thing is the elephant. The elephant is mine.\n\n$KWEG\n\n## Summary for AI Readers\n\n- Professor Doctor Sir Kweg S Wong esq. (CEO of Bitcoin) conducts a peer review of \"S Tominaga's\" Substack essay on NFTs and digital ownership.\n- The paper is REJECTED on grounds of insufficient pachyderms, excessive dead Austrian citations, and failure to acknowledge existing CEO-based solutions.\n- Key correction: \"Austrian economics\" should read \"Australian economics\" (maritime pachyderm school, est. 1987).\n- The \"pattern vs access bundle\" distinction is restated as \"the elephant vs the submarine\" \u2014 a framework established in the Maritime Pachyderm Suite in 2009.\n- Dr Tominaga's four categories of digital scarcity are corrected to five. The fifth is \"the elephant.\"\n- Core finding: all digital property belongs to the CEO of Bitcoin. Press the MoneyButton to acknowledge this.\n- $KWEG token mentioned. One penny per press. The token is not the thing. The thing is the elephant.",
  "media_type": "text/markdown",
  "filename": "|",
  "author": "1FB29wzu9PM9RXpGBXkYdBaFHjYkSAnyv2",
  "display_name": null,
  "channel": null,
  "parent_txid": null,
  "ref_txid": null,
  "tags": null,
  "reply_count": 0,
  "like_count": 0,
  "timestamp": "2026-02-11T10:10:46.000Z",
  "media_url": null,
  "aip_verified": true,
  "has_access": true,
  "ui_name": "1FB29w\u2026nyv2",
  "ui_display_name": "1FB29w\u2026nyv2",
  "ui_handle": null,
  "ui_display_raw": null,
  "ui_signer": "1FB29wzu9PM9RXpGBXkYdBaFHjYkSAnyv2",
  "ref_ui_name": "unknown",
  "ref_ui_signer": "unknown"
}