• The problem with the current hashrate markets
• The idea: a standard note format as an order book
• Reputation without a central registry
• What I’m not sure about
• What I’m asking for

§The problem with the current hashrate markets

Braiins , Nicehash, Mining Rig Rentals they all share the same flaw. They are brokers. They custody funds, KYC users, run chainalysis, and charge fees for the privilege. The model is a honeypot for regulators and thieves. Supertestnet’s insight is that we can remove the brokers entirely by using Lightning micropayments tied to PoW verification. The miner proves work in near real-time, the buyer pays in near real-time, and neither party needs a trusted intermediary holding funds.

What’s left unsolved is discovery. How does a miner with spare hashrate and buyers find themselves? Right now the answer is “use the broker.” I want to propose that NOSTR can replace that function in an open, uncensorable and decentralized way without reintroducing any of the broker’s problems.

§The idea: a standard note format as an order book

NOSTR’s parameterized replaceable events (kinds 30000–39999) are well suited for this. An order (ask or bid) is just a note. When conditions change, the hasher/buyer republishes with the same d tag and the relay keeps only the latest version so no stale orders ever pile up. The order dies when the miner stops refreshing it.

A rough sketch of the note format:

{

“kind”: 38383,

“pubkey”: “<seller or buyer pubkey>”,

“tags”: [

[“d”, “<uuid>”],

[“type”, “ask”], // “ask” = offering hashrate, “bid” = wanting it

[“hashrate”, “5”, “PH/s”],

[“price”, “800”, “sats/TH/day”],

[“duration_min”, “60”], // minimum rental in minutes

[“duration_max”, “2880”],

[“algo”, “sha256d”], // future-proofing for other algos

[“contact”, “lightning:you@getalby.com”],

[“expiry”, “1745000000”], // unix timestamp

[“status”, “open”], // open | in_progress | closed

[“t”, “hashrate-market”] // hashtag for relay filtering

],

“content”: “5 PH/s available, home miner, been running 2 years. DM for stratum details.”

}

The stratum URL and negotiation should happen in encrypted DMs, not in the public note. The public note is just the advertisement, enough for a buyer to decide whether to open a conversation. If a deal is taken the note should be republished as “status”, “in progress”

§Reputation without a central registry

When a deal completes, both parties publish a co-signed deal receipt note referencing the same deal UUID. Reputation accrues from the accumulation of dual attestations. The final Lightning payment preimage is included as evidence that real money actually moved. Web of trust filtering does the rest: client can weight the reputation from pubkeys within N hops of people you already trust, which makes Sybil farming expensive and largely irrelevant to any specific user.

§What I’m not sure about

I want to be honest about the unresolved parts:

• Should this extend NIP-99 (kind 30402) or get a dedicated kind? A dedicated kind is cleaner but requires more buy-in. Extending 30402 is faster to ship but probably muddies the name space.

• A clear definition of which tags ought to be necessary and which can be optional

• The PoW verification and Lightning payment loop requires custom software on both sides. I’m hoping Supertestnet can share his progress soon. The NOSTR layer standard format proposal only handles discovery. Am I underestimating how much friction that remaining piece adds for adoption?

• Order freshness enforcement: should relays that serve this market reject notes older than N hours without a refresh? Or is expiry tag + client filtering enough?

• Is the dual-signature reputation model too much friction too complicated for small deals? Would a simpler unilateral rating system, despite being gameable, actually see more adoption?

§What I’m asking for

This is not a finished NIP (obviously). It’s a design direction I want stress-tested before investing time to prepare a formal spec. If there’s a fundamental flaw in using NOSTR’s replaceable event model for an order book, I want to know. If the reputation model is naive, tell me why. If there’s prior work I’m ignoring, please point me to it.

The goal is a hashrate market where the protocol layer is a NIP, the order book lives on relays, payments settle over Lightning, and no company is in the critical path. That goal seems achievable. Whether this specific design gets there is what I need help figuring out.

Relevant prior work:

BH Market protocol — supertestnet https://gist.github.com/supertestnet/a4278a4145dc4afb85867718ff350091

Supertestnet’s progress https://x.com/SuperTestnet/status/2046694129409692081
NIP-99 (Classified Listings)
NIP-17 (Private Direct Messages)
DATUM / Ocean Pool (miner template control)