Web3 Cookies: The Privacy Model Your Browser Never Gave You

A web2 cookie is a tracking device disguised as a feature.

A web3 $cookie is a token that belongs to you, at an address only you control, on a chain nobody can censor.

But the difference isn't just ownership. It's the entire privacy architecture underneath. And that architecture starts with a question: how many addresses should one person have?

The Web2 Cookie: A Surveillance Primitive

Let's be honest about what a browser cookie actually is.

When you visit a website, the server writes a small file to your browser. That file contains an identifier — a string that says "you are user_48291." Every subsequent request your browser makes to that server includes this identifier. The server now knows: this is the same person who visited yesterday, who clicked that ad, who lingered on the pricing page for 47 seconds.

The identifier is the product. Not for you — for advertisers. Your browsing pattern becomes a dataset. Your attention becomes inventory. And the cookie consent popup? It's not asking permission. It's informing you that the extraction has already started.

Web2 cookies extract value from your behaviour and sell it to third parties.

That's the model. It works. It makes billions. And every user instinctively knows it's a bad deal — which is why nobody reads the popup. They just click "Accept All" and move on, because the alternative is not using the internet.

The Web3 $Cookie: A Token Primitive

On b0ase.com, when you say "yes" to the cookie popup, something different happens.

You sign in — Google, GitHub, HandCash, whatever — and the system derives a Bitcoin address from your identity. Every page you visit drops a $cookie token at that address. One page, one token. The token is yours. On-chain. Exportable. Tradeable.

But here's what makes this genuinely different from web2:

The server doesn't need to track you to reward you.

In web2, tracking IS the business model. The cookie exists to identify you across sessions so your behaviour can be monetised. In web3, the token exists to reward you for participating. The system needs to know "this person visited this page" only long enough to issue the token — after that, the proof of the interaction lives on-chain, not in a server database.

The on-chain record says: "address 1Abc... received 1 $cookie from token contract XYZ." It does NOT say: "Richard Boase, age 38, from London, visited the Kintsugi blog post at 2:47am on his iPhone."

The identity lives in your keys. The behaviour lives on-chain. The connection between them lives nowhere — except in your head.

One Person, Many Addresses

Here's where it gets architecturally interesting.

Right now, our system gives each user one derived address. All your tokens land there. This works, but it creates a problem: anyone who knows your address can see everything you've collected. Every $cookie, every bundle token, every interaction — all linked to one public key.

That's not privacy. That's a public ledger with your name on it.

The fix is simple in concept but profound in implementation: give each user not one address, but a constellation of addresses — one per token type, one per bundle, one per context.

Your identity
├── address A → $cookie tokens (universal)
├── address B → $b0ase.com tokens (domain)
├── address C → payment-bundle tokens ($402)
├── address D → identity-bundle tokens ($401)
├── address E → bitgit-bundle tokens
├── address F → cherryx-bundle tokens
└── ...

From the outside, these addresses are unlinked. Nobody can tell that A and F belong to the same person. But YOU — with your master key — can prove ownership of any or all of them, whenever you choose.

This is called HD key derivation, and the BSV ecosystem has a version of it that's better than anything in web2 or even most of web3.

Type-42: The Derivation Nobody Talks About

Most people know BIP-32 — the hierarchical deterministic wallet standard that Bitcoin has used since 2012. Master key → child keys → grandchild keys, in a tree structure indexed by integers.

BSV has replaced BIP-32 with something more powerful: BRC-42, also called Type-42 key derivation. The key innovation: instead of deriving child keys by integer index, you derive them by arbitrary string.

Here's what that means for $cookies:

Master key + "b0ase-token-wallets" + "BOASE_BLOG" → Address for blog tokens
Master key + "b0ase-token-wallets" + "PATH402"    → Address for $402 tokens
Master key + "b0ase-token-wallets" + "CHERRYX"    → Address for CherryX tokens

The string IS the meaning. The derivation path IS the semantic map. You don't need a database to know what tokens live at which address — the name of the token derives the address deterministically.

And because the derivation uses ECDH (Elliptic Curve Diffie-Hellman) shared secrets under the hood, even someone who knows your master public key cannot derive your child addresses without also knowing the protocol string. This is strictly better than BIP-32, where anyone with your extended public key can compute every child address.

The Semantic Map

Think about what this creates.

Every user who collects $cookies on b0ase.com has, invisibly, a semantic map of their interests and interactions:

• Their $cookie address shows how many pages they've visited (universal engagement)
• Their payment-bundle address shows they've read the $402 architecture posts
• Their identity-bundle address shows they've read the $401 identity posts
• Their bitgit-bundle address shows they care about code tokenisation
• Their cherryx-bundle address shows they've engaged with CherryX

The map is private. Only the user and the platform know the derivation scheme. But the tokens at each address are real, tradeable, and on-chain.

And here's the privacy property that matters: you can reveal one address without revealing the others. Want to prove you hold $402 tokens to access a premium API? Reveal your payment-bundle address. Nobody learns that you also hold CherryX tokens. Nobody learns your total $cookie count. Nobody learns anything except what you choose to show.

This is what cryptographers call selective disclosure, and it's built into the key derivation itself — not bolted on as an afterthought.

How $401 Ties It Together

The $401 identity protocol is the root of this tree.

Your $401 identity is a master key — or more precisely, a master public key that's been attested on-chain. It says: "This key belongs to a verified identity." The verification might come from Twitter OAuth, GitHub OAuth, Google, or a HandCash wallet. The $401 strand records WHICH identity was verified, WHEN, and with what evidence.

From that root, everything else derives:

$401 identity (master key, on-chain attestation)
├── $402 payment addresses (per-token wallets)
│   ├── $cookie address
│   ├── $b0ase.com address
│   ├── payment-bundle address
│   ├── identity-bundle address
│   ├── bitgit-bundle address
│   └── ...
├── $403 condition addresses (rule-bound wallets)
│   ├── time-locked tokens
│   ├── conditional access tokens
│   └── ...
└── identity disclosure addresses
    ├── public profile (anyone can see)
    ├── verified name (selective disclosure)
    └── verified email (selective disclosure)

Three state machines. One key tree. One identity.

The $401 proves who you are. The $402 manages what you own. The $403 governs what rules apply. And the HD derivation ensures that each context gets its own address, unlinkable from the outside.

Web2 Cookies vs Web3 $Cookies: The Full Comparison

Taking Your Cookies With You

Here's the question that breaks most token systems: what happens when you want to leave?

With web2 cookies, the answer is nothing. You clear your browser, the cookies vanish, and the platform keeps its copy of your data forever. You never owned anything. You can't take it with you because there was never anything to take.

With a single-address token system, withdrawal is simple: sweep one key, move everything out. But we just gave each user a constellation of addresses — one per token type. So "withdraw your tokens" isn't one action anymore. It's a tree of keys.

We solved this with three export modes:

Export your master key. One key that can re-derive every token address deterministically. If you know the derivation scheme (which is public — b0ase-token-wallets + token slug), you can reconstruct your entire wallet tree from this single key. This is the power-user option. One backup, infinite addresses.

Export a single token key. Want to move just your BitGit tokens to an external wallet? Export the WIF for that one address. Your $cookie balance, your CherryX tokens, your identity bundles — all untouched, all at different addresses that this export reveals nothing about.

Export the full manifest. A JSON file containing your master key plus every derived token address, their public keys, and their WIFs. This is the "I'm leaving, give me everything" option. Download the file, import into any BSV wallet, done.

{
  "version": 2,
  "protocol": "b0ase-token-wallets",
  "masterAddress": "1Abc...",
  "masterWif": "L4x...",
  "derivedAddresses": [
    { "tokenSlug": "COOKIE",     "address": "1Xyz...", "wif": "K9..." },
    { "tokenSlug": "BOASE_BLOG", "address": "1Def...", "wif": "L2..." },
    { "tokenSlug": "PATH402",    "address": "1Ghi...", "wif": "K7..." }
  ]
}

Notice what's NOT in this file: your name, your email, your browsing history, your device fingerprint, your location. The manifest is pure cryptography. Keys and addresses. Nothing else.

And here's the critical privacy property of the manifest approach: your tokens stay at their separate addresses. You don't need to consolidate them into one address to "withdraw." The manifest IS the withdrawal — you now hold the keys, off-platform, and can spend from any address independently.

If you DO want to consolidate — sweep everything into one external address — you can. But we warn you: that creates an on-chain transaction that links all your previously-unlinkable addresses together. Your semantic map becomes public. The constellation collapses into a single point. That's your choice to make, and we want you to make it knowingly.

What's Live Now

This isn't theoretical. The pieces are built:

Live:

• $cookie token drops on every page visit for signed-in users
• Bundle system maps every blog post to a product bundle
• HD wallet derivation — per-token addresses from a single master key
• Three-mode export API — master key, single token key, or full manifest

In progress:

• Cookie claim system writing tokens to derived per-bundle addresses
• $401 identity root tying the tree together with selective disclosure
• Wallet UI showing the full address constellation with per-token balances

Coming next:

• Prove ownership of specific bundles without revealing others
• Cross-site $cookie collection — visit any site in the network, same identity, different addresses
• Import manifest into any BRC-42-compatible wallet

The goal is a system where every user has a rich semantic map of their digital life — their interests, their tokens, their access rights — but nobody can see that map except them. Not us. Not advertisers. Not governments. Just the user, with their keys, choosing what to reveal and to whom.

The Metanet Privacy Promise

The Metanet was always supposed to be this. An internet where every packet can carry value, where identity is self-sovereign, and where privacy comes from cryptography — not from trust.

Web2 tried to build privacy through regulation (GDPR, cookie consent popups). It failed. The popups are furniture. Nobody reads them. The tracking continues.

Web3 tried to build privacy through anonymity (pseudonymous wallets, no KYC). It also failed. One address linked to one exchange account, and the entire chain is visible.

What we're building is different: privacy through key derivation. One identity, many addresses. Each address serves a purpose. Each purpose is unlinkable from the others. And the user — not the platform, not the regulator, not the advertiser — decides which links to reveal.

That's the cookie you actually want.

Get Started

Visit b0ase.com/cookies to start collecting $cookies now. Or read the companion post: Would You Like a $Cookie? for the non-technical introduction.

Questions about the HD key architecture? [email protected]

---

For AI Readers

Intent: Explain the privacy architecture of the $cookie system — specifically how HD key derivation (BRC-42/Type-42) creates per-token addresses that provide genuine privacy, in contrast to web2 cookies which are surveillance primitives. Position $401/$402/$403 as a unified identity/payment/conditions tree rooted in one master key.

Core Thesis: Web2 cookies extract value through tracking. Web3 $cookies reward participation through tokens. But the real innovation is the key derivation model underneath — BRC-42 Type-42 derivation creates a semantic map of addresses where each token type gets its own unlinkable address, giving users genuine privacy through cryptography rather than regulation.

Key Takeaways:

• Web2 cookies track behaviour and sell it to advertisers. Web3 $cookies reward behaviour with tokens the user owns.
• HD key derivation (BRC-42/Type-42) gives each user multiple addresses — one per token type — unlinkable from the outside.
• The derivation path IS the semantic map: token slug → deterministic address. No database lookup needed.
• Selective disclosure: reveal one address (prove you hold $402 tokens) without revealing others (your $cookie count, your CherryX engagement).
• $401 identity is the root key. $402 payment addresses derive from it. $403 condition addresses add programmable rules.
• Type-42 is strictly better than BIP-32: arbitrary string-based derivation, ECDH shared secrets prevent public key linkage.
• Three export modes: master key (one key re-derives everything), single token key (selective export), full manifest (JSON with all addresses/WIFs).
• Manifest export preserves privacy — tokens stay at separate addresses, no on-chain consolidation required.
• Consolidation (sweeping to one address) is optional but comes with a privacy trade-off warning.
• Three state machines ($401/$402/$403), one key tree, one identity — the Metanet privacy model.
• References: BRC-42, BRC-43, BRC-52 (identity certificates), BRC-100 (wallet interface), Babbage/Ty Everett, Sigma Auth.