• The Problem
• The Vision: Nostr Compute Network
  • How It Works (In 60 Seconds)
• Why This Matters
  • ⬡ No Altcoin Required
  • ⬡ Real Privacy
  • ⬡ Instant, Streaming Payments
  • ⬡ Censorship Resistance
  • ⬡ Zero Barriers to Entry
  • ⬡ Built on Proven Protocols
  • ⬡ Validated by Existing Projects
• What You Can Do With It
  • For Developers
  • For Providers
  • For Organizations
• Architecture at a Glance
  • Core Protocol: NIP-90 Extended for Compute
  • Payment Rails
• Trust Without Tokens
• How It Compares
• Who Is This For?
  • Builders & Contributors
  • Early Provider Operators
  • Bitcoin Developers & Entrepreneurs
  • Privacy Advocates & Activists
• Legal Considerations for Providers
  • The Core Tension
  • What Providers Could Realistically Face
  • How Existing Law Applies
  • Protocol-Level Mitigations
  • What This Does Not Solve
  • Recommendations for Providers
  • A Note on Project Responsibility
• Current Status & How to Get Involved
  • Immediate Priorities
  • How to Contribute

Bitcoin-Native · Privacy-First · Censorship-Resistant

§The Problem

Cloud computing is one of the most centralized industries on Earth. Three companies — Amazon, Microsoft, and Google — control the majority of the world’s compute infrastructure. They set the prices, write the terms, and can deny service to anyone, for any reason, at any time.

Decentralized alternatives exist, but they come with their own problems. Akash Network, the most prominent decentralized compute marketplace, requires users to buy and stake AKT, a speculative altcoin token, just to rent a server. Its blockchain architecture creates unnecessary complexity, governance capture risks, and a dependency on an inflationary token economy that serves investors more than users.

The result: people who actually need censorship-resistant, private compute have to either submit to Big Tech surveillance capitalism, or buy into an altcoin ecosystem that contradicts the values of sound money and individual sovereignty.

The core question: What if you could rent compute from anyone in the world, pay with bitcoin, and never reveal your identity — using protocols that already exist?

§The Vision: Nostr Compute Network

A permissionless compute marketplace built entirely on Bitcoin-native protocols. Providers offer spare compute capacity. Tenants rent it. Payments flow over Lightning or Cashu ecash. Everything is coordinated through Nostr — no blockchain, no token, no middleman.

§How It Works (In 60 Seconds)

A tenant writes a simple job specification describing what they need: CPU, memory, GPU, a Docker container image, and how long they need it. They publish this as a Nostr event. Providers who have matching capacity respond with bids — price, availability, and reputation score. The tenant picks a provider, pays a Lightning invoice (or sends Cashu tokens for privacy), and their container spins up within seconds. Streaming micropayments keep the compute running. When the job finishes, the tenant rates the provider, building a decentralized reputation layer for the next person.

Think of it as: Airbnb for servers, where the currency is bitcoin, the listing service is Nostr, and neither the host nor the guest needs to show ID.

§Why This Matters

§⬡ No Altcoin Required

Bitcoin is the only money in this system. No AKT token to buy, no staking minimums, no inflationary governance tokens. Providers earn sats. Tenants spend sats. The protocol doesn’t extract rent.

§⬡ Real Privacy

Cashu ecash tokens break the link between who pays and what they’re paying for. Combined with Nostr pseudonymity, this gives tenants strong privacy that no transparent blockchain can match. The provider knows the job but not the person. The mint knows the money but not the purpose.

§⬡ Instant, Streaming Payments

Lightning settles in seconds. Micro-billing every 10 minutes means tenants only pay for what they use, and providers get paid continuously. No monthly invoices, no credit checks, no payment processors.

§⬡ Censorship Resistance

There is no validator set to subpoena, no company to pressure, no single point of failure. Nostr relays are trivially replaceable — if one censors compute events, publish to another. Providers and tenants can operate behind Tor.

§⬡ Zero Barriers to Entry

Want to be a provider? You need a Linux box, Docker, and a Lightning wallet. That’s it. No staking minimum, no validator approval, no KYC. A Raspberry Pi with a GPU can participate alongside a datacenter rack.

§⬡ Built on Proven Protocols

This isn’t vaporware that requires new cryptography or unproven consensus mechanisms. Nostr, Lightning, and Cashu are production systems with active developer communities. NIP-90 Data Vending Machines already provide the job request/response pattern — this project extends it to general compute.

§⬡ Validated by Existing Projects

This architecture isn’t theoretical — pieces of it are already running in production. Routstr is a decentralized AI inference marketplace that uses Nostr for provider discovery and Cashu ecash for anonymous micropayments, proving that the Nostr + Cashu payment model works for on-demand compute. Civ Kit, authored by Antoine Riard, Nicholas Gregory, and Ray Youssef, demonstrated a general Nostr + Lightning marketplace with escrowed trades, DLC-based dispute resolution, and Web of Trust reputation. Nostr Compute Network generalizes these patterns: where Routstr handles LLM inference and Civ Kit handles goods/services trading, this project extends the same architecture to arbitrary containerized compute — the missing piece that turns the Bitcoin/Nostr ecosystem into a full replacement for centralized cloud providers.

§What You Can Do With It

The Nostr Compute Network enables use cases that are difficult or impossible on centralized platforms.

§For Developers

• Deploy censorship-resistant services: Run Nostr relays, Bitcoin nodes, Tor bridges, and other freedom infrastructure on hardware you don’t own, paid pseudonymously.
• CI/CD without Big Tech: Run build pipelines, test suites, and deployments on decentralized compute, triggered programmatically via the SDK.
• AI/ML workloads: Rent GPU time for model training or inference without giving OpenAI, Google, or AWS visibility into what you’re building. Projects like Routstr already prove this model works for LLM inference — Nostr Compute Network extends it to full training pipelines, fine-tuning, and any containerized GPU workload.
• Ephemeral environments: Spin up a server for 20 minutes to run a data analysis job, pay 500 sats, and walk away. No accounts, no subscriptions.

§For Providers

• Monetize idle hardware: That homelab rack, gaming PC, or retired mining rig can earn sats by serving compute to the network.
• No platform risk: No company can delist you, change your payout terms, or freeze your account. Your Nostr pubkey is your identity and your reputation.
• Stack sats passively: Automated bidding and provisioning means your hardware earns while you sleep.

§For Organizations

• Sovereign infrastructure: Non-profits, activist organizations, and companies in hostile jurisdictions can run services without depending on providers that might comply with censorship requests.
• Cost competition: A global marketplace of providers competing on price drives costs below the oligopoly pricing of AWS/Azure/GCP.
• Regulatory flexibility: Choose providers in jurisdictions that align with your legal and ethical requirements.

§Architecture at a Glance

The system replaces every component of a traditional cloud platform with Bitcoin-native equivalents:

§Core Protocol: NIP-90 Extended for Compute

The system uses four Nostr event kinds, extending the existing NIP-90 Data Vending Machine specification:

§Payment Rails

Tenants choose how to pay based on their priorities:

§Trust Without Tokens

Akash uses staking and slashing to incentivize honest behavior — but this requires a token. Nostr Compute Network achieves accountability through three complementary mechanisms that require only bitcoin and reputation:

1. Micro-billing exposure limits. Payments stream every 10 minutes. If a provider disappears or delivers garbage, the tenant’s maximum loss is 10 minutes of compute. This is the primary defense and requires no trust infrastructure at all.

2. Web of Trust reputation. After each job, tenants publish signed feedback events (kind 7900) rating the provider. Your client computes a trust score weighted by social graph distance — a provider trusted by people you trust scores higher. Sybil attacks are expensive because reputation must be earned through the social graph, not purchased.

3. Optional arbitrated escrow. For high-value jobs, a mutually trusted third party (identified by Nostr pubkey) can hold a Cashu token or Lightning HODL invoice in escrow. On dispute, the arbitrator examines evidence and decides. Arbitrators themselves build reputation through the same WoT system.

The insight: You don’t need a blockchain to punish bad actors. You need small payments (to limit damage), public reputation (to reward honesty), and the option to escalate (for edge cases). Bitcoin and Nostr provide all three.

§How It Compares

§Who Is This For?

§Builders & Contributors

This is an open protocol, not a company. If you write code in Rust, Go, TypeScript, or Python and care about Bitcoin-native infrastructure, there is meaningful work to do: the provider daemon, tenant CLI, Nostr relay extensions, Cashu payment integration, Web of Trust algorithms, and Kubernetes orchestration all need contributors.

§Early Provider Operators

If you run a homelab, a spare VPS, or have idle GPU capacity, you can be among the first providers on the network. Early operators shape the protocol by surfacing real-world problems that theoretical design misses. You’ll also build reputation early, which compounds as the network grows.

§Bitcoin Developers & Entrepreneurs

The NIP-90 compute extension creates a foundation for an entire ecosystem of Bitcoin-native services: serverless functions billed in sats, GPU marketplaces for AI training, privacy-preserving CI/CD pipelines, and censorship-resistant hosting. Each of these is a potential product or business built on open protocols.

§Privacy Advocates & Activists

If you need compute that can’t be traced, seized, or censored — for journalism, activism, research, or simply principle — this system is designed for you. Cashu ecash payments and Nostr pseudonymity mean the provider knows the job but not the person, and the payment rail knows the money but not the purpose.

§Legal Considerations for Providers

Any honest discussion of decentralized compute must address the legal reality that providers face. Running infrastructure that executes arbitrary code for pseudonymous tenants creates genuine legal exposure, and this project would do its participants a disservice by pretending otherwise.

§The Core Tension

When you operate a compute provider, you sit somewhere on a legal spectrum between “common carrier” (like a phone company, generally not liable for what’s transmitted) and “active participant” (fully liable for what you facilitate). Decentralized compute providers don’t cleanly fit into either category, and most existing legal frameworks were written with centralized platforms in mind.

A provider running a Kubernetes cluster that accepts anonymous job requests via Nostr and gets paid in ecash has no KYC on their tenants, no content moderation policy, and potentially no ability to inspect what’s running inside encrypted containers. From a cypherpunk perspective, that’s the point. From a legal perspective, it creates real exposure.

§What Providers Could Realistically Face

The risk scenarios range from mundane to severe:

• Low severity: A tenant scrapes websites, sends spam, or runs workloads that violate some upstream provider’s ToS. Annoying, but unlikely to trigger criminal liability.
• Moderate severity: A tenant runs a piracy service, unlicensed gambling platform, or unregistered financial services. The provider is potentially facilitating regulatory violations, depending on jurisdiction and the provider’s level of knowledge.
• Severe: A tenant hosts CSAM, runs command-and-control infrastructure for malware, or operates services that directly enable serious crimes. This is where providers face genuine criminal exposure in most jurisdictions, and “I didn’t know” is not a universally accepted defense.

§How Existing Law Applies

United States: Section 230 of the Communications Decency Act provides some protection for “interactive computer services” against liability for user-generated content, but it was written for platforms like forums and social media — not anonymous compute providers. DMCA safe harbor provisions require a takedown mechanism, which is difficult to implement when you can’t identify the tenant or inspect the workload. The Electronic Communications Privacy Act and Stored Communications Act create data preservation obligations that a truly anonymous system cannot fulfill.

European Union: The Digital Services Act imposes due diligence obligations on hosting providers, including the ability to respond to removal orders and designate a legal representative. A provider that genuinely cannot identify tenants or inspect workloads may struggle to claim these protections.

Other jurisdictions: Legal frameworks vary widely. Some jurisdictions have strong intermediary liability protections; others impose strict obligations on anyone providing hosting services. Providers must understand their own local legal environment.

The closest legal precedent may be Tor exit node operators, who face a similar situation: they provide infrastructure enabling anonymous activity, cannot inspect the traffic, and periodically face legal scrutiny. Outcomes for Tor operators have been mixed — mostly fine in practice, occasionally problematic, and highly jurisdiction-dependent.

§Protocol-Level Mitigations

The Nostr Compute Network protocol is designed to give providers the tools to manage their own risk exposure rather than imposing a single policy:

• Provider-configurable workload policies: Providers can whitelist specific container registries, restrict workload types via required tags, block certain port ranges, or require non-encrypted containers. The protocol supports these restrictions without mandating them.
• Tiered trust profiles: Some providers may choose to accept any workload, operate pseudonymously, and charge a premium for the risk. Others may require tenant identification, limit container images to known registries, or restrict workload categories. Tenants choose providers based on their own privacy and compliance needs.
• Abuse reporting via Nostr events: The reputation system (kind 7900 feedback events) can carry abuse reports. Providers can subscribe to community-maintained blocklists of known-malicious container images or tenant pubkeys.
• Container image transparency: Providers can require that job requests reference images from public registries (Docker Hub, GitHub Container Registry) where the image contents are inspectable, rather than accepting opaque binaries.
• Automated compliance scanning: The provider daemon can integrate with container scanning tools (Trivy, Grype) to reject images with known malware signatures or suspicious characteristics before provisioning.

§What This Does Not Solve

Protocol-level mitigations reduce risk but do not eliminate it. Specifically:

• A determined bad actor can craft workloads that pass automated scanning but still perform harmful activities at runtime.
• Encrypted or confidential computing (AMD SEV, Intel TDX) — listed as an advanced feature in the roadmap — is fundamentally incompatible with provider-side workload inspection. Providers who enable confidential computing accept higher legal risk in exchange for the ability to serve privacy-sensitive workloads.
• No technical system can substitute for legal counsel. Providers operating in regulated environments should consult an attorney familiar with intermediary liability in their jurisdiction.

§Recommendations for Providers

1. Understand your jurisdiction. Legal exposure varies dramatically by country, state, and even municipality. What is low-risk in one jurisdiction may be illegal in another.
2. Start with restrictive policies. Begin by whitelisting known container registries and limiting workload types. Loosen restrictions as you develop confidence in your risk management approach.
3. Maintain logs proportionate to your risk tolerance. You don’t have to log everything, but having some record of what ran on your infrastructure (even if the tenant is pseudonymous) may provide a good-faith defense if questioned.
4. Consider your upstream provider’s ToS. If you’re running the provider daemon on a VPS or colocation facility, your upstream provider likely has acceptable use policies. Violations could result in service termination regardless of whether you face direct legal action.
5. Don’t assume pseudonymity equals immunity. Operating a provider pseudonymously reduces exposure but does not eliminate it. IP addresses, payment trails, and network analysis can potentially deanonymize operators.

§A Note on Project Responsibility

This project will include clear documentation stating that providers are individually responsible for compliance with their local laws. The project does not provide legal advice, cannot guarantee immunity from legal action, and does not encourage or endorse the use of the network for illegal purposes. The protocol is designed to maximize individual choice — including the choice to operate within legal boundaries.

The goal is censorship resistance, not lawlessness. These are different things, and the distinction matters.

§Current Status & How to Get Involved

Status: Active Development The protocol specification is being drafted. A proof-of-concept provider daemon and tenant CLI are the immediate next deliverables. The project is open for contributors, feedback, and early testers.

§Immediate Priorities

1. NIP Draft: Formal Nostr Improvement Proposal extending NIP-90 for compute workloads. Defines the event kinds, tag conventions, and payment flow that everything else builds on.
2. Provider Daemon PoC: A minimal daemon that watches Nostr relays for job requests, matches against local capacity, and provisions Docker containers. First milestone: request → bid → provision on a single machine.
3. Lightning Payment Loop: NWC-based automated payment flow: tenant pays an initial invoice, streaming payments keep the compute running, teardown on expiry or non-payment.
4. Dogfooding: Run real services (Nostr relays, Bitcoin nodes, DVM inference) on the platform to stress-test before opening to external users.

§How to Contribute

• Code: Rust or Go for the provider daemon. TypeScript for the tenant client and web dashboard. Python for tooling and testing.
• Protocol design: Review and refine the NIP draft. Propose improvements to the job spec schema, payment flows, or reputation mechanics.
• Testing: Run a provider node on spare hardware. Submit test jobs. Report bugs, UX friction, and edge cases.
• Spread the word: Share this spec on Nostr. Talk about it at meetups. The network effect matters — more providers and tenants make the marketplace better for everyone.

All communication happens on Nostr. No Discord server, no Slack workspace, no GitHub organization controlled by a single entity. The protocol is the product.

“The computer can be used as a tool to liberate and protect people, rather than to control them.” — Hal Finney

Permissionless compute. Sound money. No middlemen.

Nostr Compute Network is an open protocol. There is no company, no token, and no permission required to build.

Start building. ⚡