2025-12-12

Fuzz: The Permissionless Patronage Protocol

Abstract

We propose a permissionless patronage protocol. An author publishes his work, his authorship. A patron sends value, his patronage, back through a Fuzz client. The patronage is recorded and can be verified in a trust-minimized way. The cost for both the patron and the author to switch between Fuzz clients is zero.

Problem

Sharing ideas is frictionless. Yet we have built systems that treat ideas as physical objects.

Physical objects are scarce. If one takes Pythagoras’s chair, he cannot use it. Ideas are not scarce.[1] If one uses the Pythagorean theorem, Pythagoras can still use it. Digital media is closer to ideas than to physical objects, copying is frictionless, and the copy does not diminish the original.

Communities differ on what sharing means. Academics share freely with attribution; musicians sample, cover, and quote within complex traditions; software developers license their work from proprietary to public domain. No central authority knows all these norms[2], and no single rule can govern all domains.

A protocol cannot decide these norms. It can only provide infrastructure for value to flow back to authors, and let communities govern themselves.

The current system creates value by restricting ideas. We need a system where value flows back to authors without restricting how their work is shared, copied, or modified.

Solution

Three players: an author, a patron, and a Fuzz client.

An author publishes his work, his authorship. The authorship event includes a Bitcoin address for receiving value. Anyone can pay the author directly, though most patrons will interact through a Fuzz client.

A patron sends value, his patronage. He experiences the work and wants to send patronage to the author. But why send patronage if the work is already free?

A Fuzz client lets patrons discover and experience works, and builds an economy around that experience: subscriptions, advertisements, pay-what-you-want, or any model the client invents. The protocol sets the rules, not the economy.

When value flows through the Fuzz client to the author, it is attributed to the patron, who builds a patronage history that lives outside any client’s control, portable, verifiable.

Fuzz changes the incentives. An author can see his top patrons, and reward them with early access, exclusive works, or recognition.

A patron who values his patronage history uses a Fuzz client that sends more to authors. If the client keeps too much, it diminishes the recorded patronage, and since the patron can verify how much each client passes through, he leaves for a better one.

A client that sends little to authors loses patrons to one that sends more. The cost of switching is zero, patrons take their history with them, and clients compete on what they pass through.

An author receives value from patrons regardless of which Fuzz client they use. He depends on no single client, and his audience is not locked in.

Each player acts on his own incentive. The better the work, the more patrons. The better the Fuzz client’s economy, the more patrons. Patrons with more patronage rank higher with authors. Everyone checks everyone, and trust is minimized.[3]

The Mechanism

What is a Fuzz Client

A Fuzz client connects authors and patrons. Concretely, it is a Nostr client that connects to relays, fetches authorship events, displays works to patrons, and may publish patronage events. It also runs an economy, curates works, and provides discovery.

Fuzz clients let authors upload works, organize them, and track how they perform. The author publishes an authorship event, a Nostr event containing the work’s hash, a URL to retrieve it, metadata, and an address for receiving value.

Fuzz clients let patrons browse, search, follow authors, and experience works. When value flows to an author, the client publishes a patronage event, a Nostr event recording the patron, the author, and the amount.

The Fuzz client connects several components:

Relay connection. Authorship events and patronage events flow through Nostr relays. Fuzz clients SHOULD respect NIP-65 relay metadata when fetching authorship events for a given author.

Work storage. Works are stored on Blossom servers, addressed by hash. The author can self-host or use third-party servers. The Fuzz client can mirror works for redundancy.

Client interface. The application authors and patrons interact with, on the web, on a phone, on a desktop, on whatever surface fits.

Curation. Fuzz clients select, organize, and exclude according to whatever standard their community holds.

Economy. The Fuzz client runs an economy. This is how value flows from patrons to authors:

The protocol does not prefer one economy over another. It creates the rules and lets clients compete.

A minimal Fuzz client connects to public relays, proxies works from author servers, and publishes patronage events. A full-featured one runs its own relay, hosts works on its own Blossom server, and builds sophisticated economy models.

Fuzz clients can specialize. Some serve only authors, helping them publish authorship events. Others serve only patrons, helping with discovery and patronage. The patronage event is agnostic of the work, it centers on the author.

Proof of Patronage

The core primitive is simple: a Bitcoin transaction where the OP_RETURN contains the patron’s Nostr public key.

The transaction:

Output 1: Payment to author's Bitcoin address
OP_RETURN: FUZZ<patron's 32-byte Nostr pubkey>

The prefix “FUZZ” (4 bytes) identifies the protocol. The patron’s raw public key (32 bytes) attributes the patronage. Total: 36 bytes.

The author’s address is the recipient of Output 1. The patron’s pubkey in the OP_RETURN says who gets credit.

The transaction can come from any wallet, the source address does not matter, only the OP_RETURN. This decouples the payment source from the attribution: the Fuzz client can generate value through any economy and attribute it to the patron.

The Fuzz client manages the economy. The blockchain records the patronage. The patron owns the proof.

Author verification:

1. Query blockchain: all transactions to author's address
2. For each transaction with OP_RETURN starting with "FUZZ":
   - Parse the 32-byte pubkey
   - Record: { patron_pubkey, amount, timestamp }
3. Aggregate by pubkey
4. Result: ranked list of patrons

Anyone can run this query. The data is public. The proof is the chain.

Patron verification:

When an author offers access to top patrons, the patron proves he owns the pubkey. Any Nostr event signed by that pubkey proves ownership. The blockchain proves patronage. Two public systems: one to prove identity and one to prove patronage.

Limitations

On-chain transactions are expensive for small amounts. If the fee exceeds the patronage, the economics break, and the protocol is limited to patronage above some floor.

Cheaper approaches exist. Lightning settles small payments off-chain at negligible cost.[4] Batching multiple patrons into one transaction reduces fees further. Both require infrastructure and design that fall outside this proposal.

This document specifies on-chain settlement as the primitive. Future iterations can build on this foundation.

Media Distribution

Authors upload their work to a Blossom server, a protocol for storing binary data addressed by SHA-256 hash. The author receives a URL containing the hash, the hash is permanent, and anyone holding it can retrieve the work from any Blossom server that has it.

The author then publishes a Nostr event with:

The url tag is a retrieval hint. If the URL is unreachable, clients SHOULD fall back to the author’s BUD-03 user-server-list (kind:10063) and verify retrieved bytes against the x tag SHA-256 hash.

The authorship event is a Nostr event living on relays, the work itself is stored on Blossom. Events on relays can be queried by kind, discovered through social graphs, and indexed by any Nostr client. Nostr events enable discovery. Fuzz clients solve curation.

The author can self-host on his own machine, use a third-party Blossom server, or run several for redundancy, the choice is his. He does not depend on any Fuzz client to host his work.

A Fuzz client can mirror works through Blossom’s mirroring protocol, which adds redundancy and improves performance. If the original server goes down, the mirrored copy remains accessible. The hash guarantees integrity, and the work is the same whichever server delivers it.

A note on identity. The protocol requires a public key for each author, so if someone creates a work without a Nostr identity, another party can publish the authorship event on his behalf and list his address. The term “author” means whoever publishes the event and controls the address.

The protocol assumes authors share their work freely. Publishing an authorship event declares the work open to copy and to redistribution.

Portability

Patron Switching

A patron’s patronage history must not be locked inside any Fuzz client’s database.

Patronage is recorded on the blockchain, and anyone can query an author’s address and parse the OP_RETURN for patron pubkeys. The patron’s history is the aggregation across all Fuzz clients.

When a patron switches Fuzz clients:

  1. His identity (keypair) is his
  2. His history is on the blockchain
  3. The new Fuzz client can query for existing history
  4. There is nothing to export or migrate

A Fuzz client cannot lock in a patron’s history because it does not control the blockchain. Transactions are permanent.

The cost of switching Fuzz clients is zero.

Author Independence

No author’s work should depend on a single Fuzz client.

The work itself sits on Blossom servers. The author can host his own on his own machine, or use several, the hash-based addressing makes the work retrievable from any server that has it.

The author’s address for receiving value is his, not controlled by any Fuzz client, and patrons can send directly when they choose.

His events live on relays, any Fuzz client can read them, and he is not exclusive to any one.

Events

In the schemas below, <...> denotes a placeholder for the actual value.

Authorship Event (Kind 31339)

{
  "kind": 31339,
  "pubkey": "<author pubkey>",
  "created_at": 1234567890,
  "content": "<description>",
  "tags": [
    ["d", "<unique identifier>"],
    ["title", "<title of work>"],
    ["x", "<SHA-256 hash>"],
    ["url", "https://blossom.server/<sha256>"],
    ["address", "<bitcoin address>"]
  ]
}

The address tag contains the author’s Bitcoin address for receiving patronage.

Kind 31339 is an addressable event. The d tag makes it addressable and updatable.

Patronage Event (Kind 9740)

{
  "kind": 9740,
  "pubkey": "<Fuzz client pubkey>",
  "created_at": 1234567890,
  "content": "",
  "tags": [
    ["p", "<author pubkey>"],
    ["P", "<patron pubkey>"],
    ["amount", "<integer satoshis>", "sat"],
    ["txid", "<bitcoin transaction id>"]
  ]
}

The P tag denotes the patron, following NIP-57 convention (lowercase p for the recipient of value, uppercase P for the sender).

This event is optional. The blockchain is the source of truth. The event provides convenience: it helps clients discover patronage without querying the blockchain directly. The txid allows verification.

Existing Work

Nostr.[5] Protocol for decentralized social networks. Events, relays, signatures. Addressable events use the d tag. Fuzz builds on this foundation.

Blossom.[6] Media storage addressed by SHA-256 hash. Authors use Blossom for storing works. Fuzz clients can mirror for redundancy.

Bitcoin.[7] OP_RETURN is a script opcode for embedding data in transactions. Fuzz uses 36 bytes (4-byte prefix + 32-byte pubkey).

Conclusion

An author publishes his work, his authorship. A patron sends value, his patronage, back through a Fuzz client. The patronage is recorded on the blockchain, the patron’s history is portable, the author receives value, the cost of switching is zero.

The protocol does not dictate which economy works. It provides infrastructure for value to flow back to authors, with proof, and leaves the rest to whatever the communities settle on.

On-chain transactions are expensive for small amounts. Cheaper approaches exist but require additional design work.

Derivative works are not yet addressed: a remix references the original, a cover credits the songwriter. We will address derivative attribution in a follow-up.

References

[1] Kinsella, Against Intellectual Property (2001)

[2] Hayek, The Use of Knowledge in Society (1945); Popper, The Open Society and Its Enemies (1945)

[3] Szabo, Trusted Third Parties Are Security Holes (2001)

[4] Poon and Dryja, The Bitcoin Lightning Network (2015)

[5] fiatjaf, Nostr (2020)

[6] hzrd149, Blossom (2024)

[7] Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System (2008)