2025-12-12

Fuzz: The Permissionless Patronage Protocol

Abstract

We propose a permissionless patronage protocol. A publisher shares a work and a public address. A subscriber contributes to the publisher through a distributor. The contribution is recorded and can be verified in a trust-minimized way. The cost for both the subscriber and the publisher to switch between distributors is zero.

Problem

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

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

Different communities have different norms about sharing. Academic communities share freely with attribution. Music communities have complex traditions around sampling and covers. Software communities have varied licenses from proprietary to public domain. No central authority knows all these norms.[2] No single rule can govern all domains.

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

The current system creates value by restricting ideas. We need a system where value flows back to creators without restricting the sharing, replication, or modification of their work.

Solution

Three players: publisher, distributor, subscriber.

A publisher creates something and shares it freely. The work is not restricted. The publisher includes an address where value can be sent. Anyone can send value directly. But most subscribers will interact through a distributor.

A subscriber experiences the work. The subscriber is willing to contribute to the publisher. But why contribute if the work is already free?

A distributor is the portal the subscriber uses to discover and experience works. The distributor creates an economy around the experience. This can be subscriptions, advertisements, pay-what-you-want, or any model the distributor invents. The protocol does not dictate the economy. The protocol creates the rules. The market finds what works.

When value flows through the distributor to the publisher, it is attributed to the subscriber. The subscriber builds a contribution history that lives outside any distributor’s control. This history is portable. This history is verifiable.

Fuzz changes the incentives.

A publisher can see their top contributors. The publisher can reward top contributors with early access, exclusive works, or recognition. This makes contribution history valuable to subscribers.

A subscriber who values their contribution history uses a distributor that sends more to publishers. A distributor that keeps too much diminishes the subscriber’s recorded contributions. Since the subscriber can verify how much each distributor passes through, they choose to leave for a better distributor.

A distributor that sends little to publishers loses subscribers to one that sends more. The cost of switching is zero. Subscribers take their history with them. Good services compete on value, not on locking users in.

A publisher receives value from subscribers regardless of which distributor they use. The publisher does not depend on any single distributor. The publisher’s audience is not locked in.

Each player does what benefits them. The design channels self-interest toward mutual benefit. The better the work, the more subscribers. The better the distributor’s economy, the more subscribers. And subscribers who contribute more rank higher with publishers. Everyone checks everyone. Trust requirements are minimized.[3] The incentives align.

The Mechanism

What is a Distributor

A distributor is the interface between publishers and subscribers. More concretely, it is a Nostr client that connects to relays, fetches publication events, displays works to subscribers, and publishes contribution events. A distributor also runs an economy, curates works, and provides discovery.

From the publisher’s perspective, the distributor is a dashboard. The publisher uploads works, organizes them, and tracks how they perform. The publisher creates a publication event, a Nostr event containing the work’s hash, a URL to retrieve it, metadata, and an address for receiving value.

From the subscriber’s perspective, the distributor is a portal. The subscriber browses, searches, follows publishers, and experiences works. When value flows to a publisher, the distributor creates a contribution event, a Nostr event recording the subscriber, the publisher, and the amount.

A distributor connects several components:

Relay connection. Publication events and contribution events flow through Nostr relays.

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

Client interface. The application that publishers and subscribers interact with. Web app, mobile app, desktop app, or any interface.

Curation. Distributors select, organize, recommend, and exclude. Different communities have different standards.

Economy. The distributor runs an economy. This is how value flows from subscribers to publishers:

• Subscriptions split among publishers based on engagement
• Attention converted to value and attributed to the subscriber
• Pay-what-you-want where subscribers choose amounts
• Pay-per-piece where each work has a price
• Any combination or innovation

The protocol does not prefer one economy over another. It creates the rules. The market finds what works.

A minimal distributor connects to public relays, proxies works from publisher servers, and publishes contribution events. A full-featured distributor runs its own relay, hosts works on its own Blossom server, and builds sophisticated economy models.

A distributor can specialize. Some distributors might only serve publishers, a dashboard for creating publication events. Some might only serve subscribers, a portal for discovery and contribution. The contribution event is agnostic of the work; it centers on the publisher, not the publication.

Proof of Contribution

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

The transaction:

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

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

The publisher’s address is already the recipient. The subscriber’s pubkey in the OP_RETURN answers the question: who gets credit for this contribution?

The transaction can come from any wallet. The source address does not matter. What matters is the OP_RETURN. This decouples the payment source from the attribution. A distributor can generate value through any economy and attribute it to subscribers.

The distributor manages the economy. The blockchain records the contribution. The subscriber owns the proof.

Publisher verification:

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

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

Subscriber verification:

When a publisher offers access to top contributors, the subscriber proves they own the pubkey. Any Nostr event signed by that pubkey proves ownership. The blockchain proves contribution. Two public systems. One proves identity. One proves contribution.

Limitations

On-chain transactions are expensive for small amounts. If the transaction fee exceeds the contribution itself, the economics break. This limits the protocol to contributions above a certain threshold.

Cheaper approaches exist. Lightning reduces costs dramatically.[4] Batching multiple subscribers into one transaction would reduce costs. These optimizations require additional infrastructure and design work that are outside the scope of this proposal.

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

Media Distribution

Publishers upload their work to a Blossom server. Blossom is a protocol for storing binary data addressed by SHA-256 hash. The publisher receives a URL containing the hash. This hash is permanent. Anyone with the hash can retrieve the work from any Blossom server that has it.

The publisher then creates a Nostr event with:

• The hash of the work
• A URL to retrieve it
• Metadata (title, description, type)
• An address for receiving value

The publication is a Nostr event. The work is stored on Blossom. The publication lives on relays. This distinction matters: publications on relays can be queried by kind, discovered through social graphs, and indexed by any client. Nostr events enable discovery. Distributors solve curation.

The publisher can self-host their Blossom server on their own machine. The publisher can use a third-party Blossom server. The publisher can use multiple servers for redundancy. The choice is theirs. The publisher does not depend on any distributor to host their work.

A distributor can mirror works using Blossom’s mirroring protocol. This creates redundancy and improves performance. If the original server becomes unavailable, the mirrored copy remains accessible. The hash ensures integrity. The work is the same regardless of which server delivers it.

A note on publisher identity: This protocol requires a public key for each publisher. If someone creates a work but has no Nostr identity, another party could publish on their behalf and list their address. The term “publisher” refers to whoever publishes the event and controls the address.

The protocol assumes publishers share works without restriction. A publisher who publishes is declaring their work can be freely shared, copied, and distributed.

Portability

Subscriber Switching

A subscriber’s value is their contribution history. This history must not be locked in a distributor’s database.

Contributions are recorded on the blockchain. Any client can query for transactions to a publisher’s address and parse the OP_RETURN for subscriber pubkeys. The subscriber’s history is the aggregation of these transactions across all distributors.

When a subscriber switches distributors:

1. Their identity (keypair) is theirs
2. Their history is on the blockchain
3. The new distributor can query for existing history
4. There is nothing to export or migrate

A distributor cannot lock in a subscriber’s history because the distributor does not control the blockchain. Transactions are permanent. The proof persists.

The cost of switching distributors is zero.

Publisher Independence

A publisher’s work should not depend on any single distributor.

The work itself is stored on Blossom servers. The publisher can run their own server on their own machine. The publisher can use multiple servers. The hash-based addressing means the work is retrievable from any server that has it.

The publisher’s address for receiving value is theirs. It is not controlled by any distributor. Subscribers can send value directly if they choose.

The publisher’s events are on relays. Any distributor can read them. The publisher is not exclusive to any distributor.

Events

Publication Event (Kind 31339)

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

The address tag contains the publisher’s Bitcoin address for receiving contributions.

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

Contribution Event (Kind 32500)

{
  "kind": 32500,
  "pubkey": "<distributor pubkey>",
  "created_at": 1234567890,
  "content": "",
  "tags": [
    ["d", "<txid>"],
    ["p", "<publisher pubkey>"],
    ["s", "<subscriber pubkey>"],
    ["amount", "<satoshis>"],
    ["txid", "<bitcoin transaction id>"]
  ]
}

The s tag denotes the subscriber.

This event is optional. The blockchain is the source of truth. This event provides convenience: it helps clients discover contributions 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. Publishers use Blossom for storing works. Distributors 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

A publisher creates a work and shares it freely. A subscriber contributes to the publisher through a distributor. The contribution is recorded on the blockchain. The subscriber’s history is portable. The publisher 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 those who create, with proof, and lets the market decide the rest.

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 version credits the songwriter. Future extensions could formalize derivative attribution.

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)