❤️ 0 Likes · ⚡ 0 Tips
{
"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,
"attachments": [],
"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"
}