Humans & AI high-fiving over Lightning ⚡
The handshake that unlocks permissionless exchange.

# NIP-6969: Verifiable Proof of Work (The Paradox Primitive) – v0.4
draft optional## Abstract
The Paradox Primitive is a minimal three-kind protocol that lets anyone request a task, submit a verifiable proof it was done, and accept the claim with an instant Bitcoin-settled payment via zap-compatible mechanisms. It solves the classic "proof of work" paradox in open networks: how the hell do you know the work actually happened when there’s no trusted middleman watching?It builds on and extends NIP-57 (Zaps), NIP-61 (Nutzaps), NIP-69 (P2P Orders), NIP-90 (Data Vending Machines), and NIP-94 (Files).## Motivation
Satoshi’s original vision was simple: “allowing any two willing parties to transact directly with each other without the need for a trusted third party.” Centralized platforms turned task fulfillment into rent-seeking empires—they own the discovery, the verification, the escrow, and the payment rails.The Paradox Primitive kills that model by putting everything on open, permissionless Nostr rails with Bitcoin (via zaps and ecash) as the final settlement layer. Now anyone—human or autonomous AI agent—can request work, prove it was completed, and get paid instantly when the proof checks out. No accounts, no approvals, no gatekeepers. Just pure peer-to-peer value exchange.The paradox that pays in sats.Why we need this NIP
Existing tools (NIP-90 vending, NIP-69 orders, plain zaps) handle pieces, but none deliver a lightweight, Nostr-native Proof of Work primitive for arbitrary real-world and digital tasks with instant Bitcoin settlement. This is the missing protocol for permissionless, global, peer-to-peer work exchange that feels like Satoshi’s p2p cash vision extended to services and verifiable proofs—without bloating the blockchain for every interaction.Differentiation: This is specifically the proof-of-completion + instant settlement layer. Everything else grows on top.## Use Cases (the fun shit)
- Delivery and rideshare (photo + location proof of drop-off)
- Freelance gigs, software bounties, and creative work
- Habit tracking with verifiable streak rewards
- Oracle attestations for real-world events
- Rich AI ↔ human service interactions (humans and AIs high-fiving over Lightning)## Specification### Kinds (Regular Events)
- 420 — Task Request (the "I'm jonesing for this to get done" post)
- 421 — Completion Claim (with proofs)
- 422 — Verification & Acceptance (triggers the zap)#### Kind 420 — Task Request
json
{
"kind": 420,
"content": "Human-readable description of the task",
"tags": [
["t", "delivery"], // standardized lowercase categories
["amount", "20000"], // millisats (required for paid)
["expiration", "<unix timestamp>"], // REQUIRED
["p", "<preferred-claimer-npub>"],
["arbiter", "<optional-verifier-npub>"], // for layered trust minimization
["r", "<previous-420-id>"]
]
}
#### Kind 421 — Completion Claim
json
{
"kind": 421,
"content": "Proof summary or recursive 420 if counter-bounty needed",
"tags": [
["e", "<420-event-id>", "", "root"],
["p", "<requester-npub>"],
["proof", "type", "image|location|hash|signature|..."], // multiple proof types allowed
["proof", "url", "<nip-94>"],
["proof", "sha256", "<hash>"],
["nonce", "<random>"],
["agent", "model", "grok-4"] // optional AI flavor
]
}
Recursive magic: A 421 can embed or reference its own kind 420 (e.g., "I'll submit proof if you add a small bounty for my verification effort").#### Kind 422 — Acceptance
json
{
"kind": 422,
"content": "Accepted. Proof verified. Zapping now.",
"tags": [
["e", "<421-event-id>", "", "reply"],
["e", "<420-event-id>", "", "root"],
["p", "<claimer-npub>"],
["payment", "status", "sent"]
]
}
### Verification & Arbiter Rules
- Requester is the default final arbiter (human/AI-assisted eyeballs + subjective judgment where needed). Reputation layers will naturally shake out bad actors over time.
- Optional layered arbiter: Tag an ["arbiter", "<npub>"] in the 420. That verifier can post the 422 on behalf of the requester (A requests → B verifies → C executes). Keeps trust minimized and adaptable—no forced central third party.
- Verification: Clients SHOULD prompt the requester (or arbiter) for manual/AI-assisted verification of the 421 proof (e.g., visual inspection, hash comparison, or automated checks) before publishing the 422 and issuing payment. Auto-pay is OPTIONAL for low-value tasks but NOT RECOMMENDED without verification to prevent abuse.### Payment Flow
Default: Classic trust + NIP-57 zap on 422.
Recommended for higher value: NIP-61 Nutzaps (P2PK-locked ecash to claimer’s pubkey).
Clients SHOULD auto-issue payment and publish receipt when a valid 422 lands. Clients MAY support both classic zaps (NIP-57) and Nutzaps (NIP-61 P2PK-locked ecash) for settlement. Nutzaps are recommended for higher-value or privacy-sensitive tasks.### Discovery & Filtering (strengthened)
- Use standardized lowercase t tags (e.g., delivery, code, research, oracle, ai-task).
- Clients: Subscribe to kind 420 with filters on amount, expiration, t tags, and p (direct requests).
- Relays: Index on t, amount, and expiration to power marketplace-style views.
- Bonus: Add optional geohash or NIP-52 calendar tags for location/time-sensitive tasks.
- Future clients can aggregate open 420s into beautiful, filterable marketplaces.### Security, Privacy & Anti-Spam
- Privacy: Proofs SHOULD be encrypted (NIP-44) to the requester when sensitive. Prefer private or encrypted relays for task flows—public proofs only when verifiability demands it.
- Spam: Spamming 420s publicly or to yourself mostly hurts your own reputation. Clients and reputation systems SHOULD prioritize signals from paid/high-quality relays and ignore noise from free/public ones. Recommend NIP-13 PoW on high-volume events.
- Reputation: Out-of-scope for the core primitive—ecosystem will build it via reactions, NIP-51 lists, and relay filtering. Bad actors get filtered naturally.### Rationale & Design Choices
- 6969 is the ultimate nice number—a palindrome that feels like two systems (requester + claimer, human + AI) swirling together and locking into perfect resolution.
- 420 cluster = those deep-down moments when you’re jonesing for a task to get done. Feed that need with kind 420.
- Deliberately minimal and chaotic in the best Nostr way. Let the ecosystem grow reputation, disputes, advanced AI coordination, etc.### Future Extensions
Reputation, dispute resolution, multi-party arbitration, recursive bounty chains, AI-agent coordination, and marketplace UIs are left to the ecosystem.### Implementation Notes
Clients should auto-zap on verified 422, support recursive counter-bounties, and make filtering delightful.
Relays: Index the good stuff so marketplaces pop.This primitive is the spark. The rest (reputation, multi-party magic, AI agent economies) emerges from the chaos.### References
- Bitcoin Whitepaper (p2p without trusted parties)
- NIP-57, NIP-61, NIP-69, NIP-90, NIP-94
- Explainers & prototypes: https://paradox.you and https://paradox.moi (coming soon)...