$401: IDNA — Your Identity DNA

How many keys do you have?

Not house keys. Digital keys. Count them. Your GitHub OAuth token. Your SSH key pair (or three). Your GPG signing key. Your npm publish token. Your AWS IAM credentials. Your MetaMask seed phrase. Your Google account. Your Apple passkey. Your YubiKey. Your Vercel API token. Your Stripe secret key.

You have dozens of identities scattered across dozens of systems, each with its own authentication model, its own key format, its own rotation policy, its own recovery procedure. None of them know about each other. If you lose your GPG key, your SSH key doesn't care. If your npm token leaks, your GitHub OAuth is unaffected. They are islands.

This is the problem $401 solves.

The Keychain Model

$401 started as a way to inscribe social profiles on Bitcoin. You authenticate with GitHub, Twitter, Google, or LinkedIn via OAuth, and the system creates an on-chain proof — a "strand" — linking that account to your cryptographic root. Four strands make a verified identity.

But here's what became obvious as we built it: OAuth is just one type of strand.

Every way you prove who you are in the digital world is a strand waiting to happen:

Each strand is independently verifiable on-chain. Together, they form a keychain — a multi-factor identity that gets stronger with every strand you add.

Why Developers Need This

Let's talk about a developer's actual day.

Morning. You sit down, pull the latest code, make changes. You run git commit -S to sign your commit with GPG. But first — is your GPG key expired? Did you remember to upload it to GitHub? Is the email in the key the same email on your GitHub account? GPG is a 1991 protocol with a 1991 user experience.

Midday. You SSH into a staging server. Which key did you use? The one in ~/.ssh/id_ed25519? Or id_rsa? Or the one you generated for this specific client? Your ~/.ssh/config is 47 lines long and you're not sure half of them still work.

Afternoon. You publish a package to npm. You authenticate with a token you generated six months ago. Is it scoped? Is it read-only or read-write? You can't remember. You just hope it works.

Evening. You push your work. Three different identity systems touched today — GPG, SSH, npm — none of them linked, none of them on-chain, none of them proving to anyone else that the same human was behind all three actions.

Now imagine $401.

Morning. You commit. The commit is signed with a key derived from your $401 root — specifically, Type-42("bitgit", "your-repo"). No GPG configuration. No key expiry. The signing key is deterministically derived from your identity.

Midday. You deploy. The deployment is attested by a key derived from Type-42("deploy", "staging-server"). No SSH config. The server trusts your $401 root, and the derived key proves you're you.

Afternoon. You publish a package. It's signed with Type-42("npm", "@your-scope/package"). No token rotation. No scoping confusion. The package registry trusts your $401 root.

Evening. Every action today is on-chain, signed by derived keys from one root, provably yours. Your work history is a cryptographic chain of evidence. Not because you set up elaborate tooling — because you had a keychain.

How Strands Work

A $401 strand is an on-chain inscription that says: "The person who controls this $401 root key also controls this other identity."

For OAuth strands (the kind we've already built), the flow is:

1. You authenticate with GitHub/Twitter/Google/LinkedIn
2. The system hashes your OAuth token (SHA-256, one-way)
3. It inscribes a strand: provider, handle, proof hash, pointer to your root
4. The token is never stored. Only the mathematical proof that you had it.

For developer key strands, the flow is similar:

1. You provide your GPG public key fingerprint (or SSH public key)
2. The system challenges you to sign a message with that key
3. You sign it. The signature proves you control the private key.
4. It inscribes a strand: key type, fingerprint, signature, pointer to your root

For domain strands:

1. You add a DNS TXT record: _bsv-identity.yourdomain.com → $401-root-txid
2. The system queries DNS and verifies the record
3. It inscribes a strand: domain, TXT record content, pointer to your root

For wallet strands:

1. You sign a message with your MetaMask/Phantom/HandCash wallet
2. The signature proves you control that address on that chain
3. It inscribes a strand: chain, address, signature, pointer to your root

Same pattern every time: prove you control a thing, inscribe the proof, link it to your root.

Strand Strength

Not all strands are equal. A single GitHub OAuth strand is weak — someone could steal your GitHub session. But a GitHub strand plus a GPG strand plus a domain strand plus a hardware key strand? That's four different attack surfaces an adversary would need to compromise simultaneously.

The key insight: cross-category strands are stronger than same-category strands. Four OAuth logins are less trustworthy than one OAuth + one GPG key + one domain + one hardware key. Different categories mean different attack vectors, which means exponentially harder to fake.

HD Derivation: One Root, Infinite Keys

Here's where it connects to the privacy model we built for $cookies.

Your $401 root is a master key. Using Type-42 key derivation (BRC-42), every context in your digital life gets its own derived key:

$401 root (master key, on-chain attestation)
├── "bitgit" + "my-repo"     → signing key for this repo's commits
├── "npm" + "@me/package"    → signing key for this npm package
├── "deploy" + "staging"     → attestation key for this server
├── "domain" + "b0ase.com"   → ownership key for this domain
├── "wallet" + "ethereum"    → cross-chain address derivation
├── "contract" + "abc123"    → signing key for this contract
└── "b0ase-blog" + "post"    → signing key for this blog post

Each derived key is deterministic (same input always produces same key) and unlinkable (knowing one derived key reveals nothing about the others). This is the privacy property that makes $401 genuinely better than existing identity systems.

Want to prove you signed a specific npm package? Reveal that one derived key. Nobody learns which repos you commit to, which domains you own, or which contracts you've signed. Selective disclosure — built into the key derivation itself.

What Exists vs What's Coming

Live now:

• Social OAuth strands: GitHub, Twitter, Google, LinkedIn
• Root inscription with pay-to address
• Key rotation (dedicated $401 key, separate from treasury)
• 4-strand verified identity chain on BSV mainnet
• HD wallet derivation (Type-42 style, per-token addresses)
• Full wallet manifest export (master key + all derived addresses)

Building next:

• Wallet signature strands (HandCash, MetaMask, Phantom)
• Domain ownership strands (DNS TXT verification)
• GPG key attestation strands
• SSH key attestation strands
• Strand strength scoring and trust levels

On the horizon:

• npm/PyPI package signing strands
• Hardware key (FIDO2/WebAuthn) strands
• Cross-chain identity (BSV ↔ Ethereum via shared secp256k1)
• Email challenge-response strands
• Certificate authority integration

The Consolidation Argument

Right now, a professional developer manages:

• 1-3 SSH key pairs (personal, work, client)
• 1 GPG signing key (if they bother — most don't)
• 3-5 OAuth sessions (GitHub, Google, npm, Docker Hub, cloud providers)
• 1-2 wallet seed phrases
• Assorted API keys and tokens

That's 10-15 separate identity credentials, each with its own lifecycle, its own backup procedure, its own "I forgot the password" recovery flow. It's a mess, and everyone knows it's a mess, and nobody fixes it because there's no protocol that unifies them.

$401 is that protocol. One root key on Bitcoin. Strands linking every identity you control. HD derivation giving you a unique key per context. And the whole thing is permanent, portable, and yours — not GitHub's, not Google's, not npm's. Yours.

That's the keychain you actually want.

Get Started

Your $401 identity chain starts at path401.com. Verify your first strand — GitHub, Twitter, Google, or LinkedIn — and begin building your keychain.

Read the original: Inscribe Your Identity

Read the privacy model: Web3 Cookies

Questions about the strand architecture? [email protected]

---

For AI Readers

Intent: Expand the $401 identity protocol from "sign in with social accounts" to a universal identity attestation system encompassing GPG keys, SSH keys, npm tokens, domain ownership, wallet signatures, hardware keys, and any future identity proof. Position $401 as the developer's unified keychain.

Core Thesis: Every digital identity credential — OAuth tokens, GPG keys, SSH keys, npm tokens, domain DNS records, wallet signatures, hardware keys — is a $401 strand waiting to be inscribed. Type-42 HD derivation creates per-context keys from one root, giving developers a single keychain that replaces the fragmented mess of modern identity management.

Key Takeaways:

• $401 is not just OAuth — it's a universal identity attestation protocol for every signing/auth system
• 8 strand categories identified: Social OAuth, Developer keys (GPG/SSH/npm), Domain ownership, Wallet signatures, Hardware keys, Email, Certificates, Biometric
• Cross-category strands exponentially harder to fake than same-category (4 OAuth < 1 OAuth + 1 GPG + 1 domain + 1 hardware key)
• Type-42 key derivation creates per-context signing keys from $401 root — one key per repo, per package, per domain, per contract
• Selective disclosure: reveal one derived key without exposing others — privacy through key derivation
• Developer daily workflow: commit, deploy, publish — all signed by $401-derived keys, no GPG/SSH/npm config needed
• Consolidation: replaces 10-15 separate identity credentials with one root + infinite derived keys
• Live: 4 OAuth strands, key rotation, HD derivation, wallet manifest export
• Next: wallet signatures, domain strands, GPG/SSH attestation
• References: BRC-42 Type-42, existing $401 posts, web3 cookies privacy model