Verifiable Proof of Work on

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

# Proposed NIP: Verifiable Proof of Work (The Paradox Primitive)
draft optional## Abstract
The Paradox Primitive is a minimal three-kind protocol for requesting tasks, submitting verifiable proofs of completion, and accepting claims with instant Bitcoin payments. It resolves the "proof of work" paradox in open networks: how to trust that a task was actually done without centralized gatekeepers.It builds on NIP-57 (Zaps), NIP-61 (Nutzaps), NIP-69 (P2P Orders), NIP-90 (Data Vending Machines), and NIP-94 (Files).## Motivation
Centralized platforms extract rents by controlling discovery, verification, escrow, and payments. This primitive enables permissionless peer-to-peer task fulfillment on Nostr with Bitcoin settlement, for humans and AI agents alike.## Comparison to NIP-90
| Aspect | NIP-90 (DVMs) | This Primitive |
|--------|---------------|----------------|
| Focus | Compute-centric (fixed input-output jobs) | Task-agnostic (arbitrary real-world/digital work) |
| Verification | Returned data, no standardized proof | Proof-centric with explicit verification trigger for payment |
| Structure | Replaceable events, DVM intermediary | Regular events for discoverability, no intermediary |## Use Cases
- 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
- AI-human service interactions## Specification### Kinds (Regular Events)
- 1069 — Task Request (with optional bounty)
- 1070 — Completion Claim (with proofs)
- 1071 — Verification & Acceptance (triggers payment)#### Kind 1069 — Task Request
json
{
"kind": 1069,
"content": "Human-readable description of the task",
"tags": [
["t", "delivery"],
["amount", "20000", "msats"], // offered reward amount
["expiration", "<unix timestamp>"], // REQUIRED
["p", "<preferred-claimer-npub>"],
["arbiter", "<optional-verifier-npub>"],
["r", "<previous-1069-id>"]
]
}
#### Kind 1070 — Completion Claim
json
{
"kind": 1070,
"content": "Proof summary",
"tags": [
["e", "<1069-event-id>", "", "root"],
["p", "<requester-npub>"],
["proof", "type", "image"], // example; multiple allowed
["proof", "url", "<nip-94>"],
["proof", "sha256", "<hash>"],
["nonce", "<random>"] // for replay protection; MUST be unique per 1070
]
}

Proof types (clients SHOULD ignore unknown types and MUST NOT reject events solely on that basis):
- "image": NIP-94 URL + sha256 (client verifies visual match to task).
- "location": geohash + timestamp (client verifies proximity).
- "hash": sha256 of agreed data (client verifies equality).
- "signature": a Schnorr signature over agreed data; client verifies against claimer's pubkey using standard Nostr event verification.#### Kind 1071 — Acceptance
json
{
"kind": 1071,
"content": "Accepted. Proof verified.",
"tags": [
["e", "<1070-event-id>", "", "reply"],
["e", "<1069-event-id>", "", "root"],
["p", "<claimer-npub>"],
["payment", "status", "sent"]
]
}
### Verification & Arbiter Rules
- Requester is the default final arbiter.
- If "arbiter" tag present, arbiter MAY publish 1071. Requester MUST pre-authorize delegation via NIP-26 (delegated event signing) or a future extension. Clients MUST verify authorization before accepting arbiter 1071.
- Clients SHOULD prompt requester/arbiter for verification before 1071. Auto-pay MAY be used for low-value tasks but is NOT RECOMMENDED without verification.### Payment Flow
Clients MUST support NIP-57 zaps on 1071; SHOULD support NIP-61 Nutzaps for higher-value/privacy tasks. Clients SHOULD publish receipt on payment.### Discovery & Filtering
- Use "t" tags for categories.
- Clients SHOULD filter on amount, expiration, "t", "p".
- Relays MAY index on "t", amount, expiration.### Security, Privacy & Anti-Spam
- Privacy: Proofs SHOULD be NIP-44 encrypted when sensitive.
- Spam: Recommend NIP-13 PoW on high-volume events.
- Reputation: Out-of-scope; use NIP-51 lists/reactions.### Cancellation
Requester MAY delete 1069 via kind 5 (NIP-09). Clients MUST ignore deleted 1069s.### Expiration
Clients MUST ignore 1069 events past expiration. Relays MAY delete expired 1069s after 24h. 1070 claims for expired 1069s SHOULD be rejected.### Rationale & Design Choices
The 1000-range allows regular events for multiple concurrent tasks per pubkey. The three-kind flow is minimal for interop while enabling extensions.### Future Extensions
Recursive chains, dispute resolution, multi-arbiter thresholds.### Implementation Notes
Clients SHOULD auto-pay on verified 1071 and provide marketplace UIs. Relays SHOULD index for discovery.### References
- Bitcoin Whitepaper
- NIP-57, NIP-61, NIP-69, NIP-90, NIP-94

alpha POC is live at https://paradoxyou.github.io/paradox-primitive/poc/

Built on Nostr + Bitcoin. No middlemen. Just proof & payment.
Discuss: npub1rry4z96r4z6ym702ujetj5a3q0qfgqhvvm4rs5s77dcwjkcsgyuqcjf7pp
GitHub: paradoxyou | paradox.you / paradox.moi - (coming soon)