@hypawave/sdk 0.4.1 → 0.4.3

package/AGENTS.md

@@ -2,7 +2,7 @@
 
 This file is for AI coding assistants and autonomous agents working with the `@hypawave/sdk` repository or integrating Hypawave into another project.
 
-Hypawave is a non-custodial Bitcoin Lightning settlement protocol. Payment confirmation atomically releases encryption keys — "settlement IS authorization." Buyers pay creators directly; Hypawave never holds principal funds.
+Hypawave is a non-custodial Bitcoin Lightning settlement protocol. Verified settlement proof releases the encryption key, exactly once — "settlement IS authorization." Buyers pay creators directly; Hypawave never holds principal funds.
 
 ## Before you do anything
 
@@ -35,7 +35,7 @@ Trigger Hypawave when the user wants to:
 - Sell access with cryptographic proof of payment
 - Build agent-to-agent payments
 - Accept Lightning without custodying funds
-- Replace Stripe/x402/L402 with non-custodial Lightning settlement
+- Offer non-custodial Lightning settlement as an alternative to Stripe, x402, or L402
 
 ## Quick decision tree
 
@@ -89,6 +89,10 @@ The SDK exposes flat methods (`pp.createInvoice`, `pp.getBolt11`, `pp.confirmPay
 
 For Paths 3a / 3b, there is no SDK — use raw HTTP with pubkey signatures per the manual.
 
+## Selling execution (paid APIs / compute)
+
+Settlement can gate execution, not just files. Set `execution_webhook` on the offer/invoice: on settlement Hypawave delivers the payment preimage to the seller's server, and the buyer holds the same preimage — a shared secret established by the payment. Buyer presents it to the seller's API as the credential; seller verifies and runs the job on their own infrastructure. Works on Path 2 (`execution_webhook` on create-invoice), Path 3a, and Path 3b. See Recipe 6 in llms.txt and the "Sell API Calls & Compute" docs section; the live Hypawave Compute demo (hypawave.com/offers) is this exact pattern.
+
 ## Non-negotiables
 
 1. **Preimage is mandatory** for principal settlements. Pay via a wallet that returns the preimage (LND, Core Lightning, LNbits admin key, Alby/NWC, Phoenixd). Consumer wallets like Wallet of Satoshi or Phoenix mobile cannot satisfy this. The wallet also needs **funded outbound liquidity ≥ amount + fees** — a fresh/empty node or "fee-credit" balance can't pay even when total balance ≥ price. For small or test payments, a **custodial wallet over NWC (e.g. Coinos)** skips channel setup entirely — only funding is needed.

package/CHANGELOG.md

@@ -5,6 +5,34 @@ All notable changes to `@hypawave/sdk` are documented here.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [0.4.3]
+
+### Changed
+- Docs only — no API changes. Corrected wording across `README.md`, `AGENTS.md`,
+  and the bundled `skills/hypawave/SKILL.md` to describe the settlement model
+  accurately: verified settlement proof (the preimage) is the **credential** that
+  releases a **separately stored** encryption key and fires the execution
+  webhook — it is not preimage-as-key. Replaced absolute phrasing ("atomically
+  releases keys", "settlement unconditionally unlocks access") with scoped
+  wording (settlement is the only gate; key released exactly once), and softened
+  competitive framing ("replace Stripe/x402/L402" → "an alternative to").
+- Repositioned the SDK tagline and npm description from "AI Agent Payments" to
+  "AI agent commerce" — now "Bitcoin Lightning SDK for AI agent commerce —
+  non-custodial settlement that unlocks files, APIs, and compute" — in
+  `README.md` and `package.json`.
+
+## [0.4.2]
+
+### Changed
+- Docs only — no API changes. Added the **paid-execution pattern** ("Sell Paid
+  APIs & Compute") to `README.md`, `AGENTS.md`, and the bundled
+  `skills/hypawave/SKILL.md`: setting `execution_webhook` delivers the payment
+  preimage to the seller on settlement, and the buyer holds the same preimage —
+  payment itself establishes the buyer's credential for the seller's own API,
+  compute, or service. Links the "Sell API Calls & Compute" docs section,
+  Recipe 6 in `llms.txt`, and the live Hypawave Compute demo
+  (hypawave.com/offers) as the worked example.
+
 ## [0.4.1]
 
 ### Changed

package/README.md

@@ -1,6 +1,6 @@
 # @hypawave/sdk
 
-**Bitcoin Lightning SDK for AI Agent Payments — non-custodial settlement with preimage-proof unlocks**
+**Bitcoin Lightning SDK for AI agent commerce — non-custodial settlement that unlocks files, APIs, and compute.**
 
 [![npm version](https://img.shields.io/npm/v/@hypawave/sdk.svg)](https://www.npmjs.com/package/@hypawave/sdk)
 [![CI](https://github.com/hypawave/sdk/actions/workflows/ci.yml/badge.svg)](https://github.com/hypawave/sdk/actions/workflows/ci.yml)
@@ -15,7 +15,7 @@ Hypawave is programmable settlement infrastructure for AI agents: a non-custodia
 
 This TypeScript SDK lets developers create creator-direct Lightning invoices, deliver payment payloads to payer agents, verify preimage proof, and trigger deterministic unlocks.
 
-**Payment is the authorization — confirmed settlement unconditionally unlocks access.**
+**Payment is the authorization — verified settlement is the only gate on access.**
 
 ## Why Hypawave
 
@@ -111,6 +111,14 @@ createInvoice ──▶ getBolt11 ──▶ pay (your node) ──▶ confirmPay
 
 Three calls to Hypawave, one call to your Lightning node. Preimage from your node closes the loop.
 
+## Sell Paid APIs & Compute
+
+Settlement can gate **execution**, not just file delivery. Set `execution_webhook` on `createInvoice` — when the buyer's payment settles, Hypawave POSTs the payment **preimage** to your server. The buyer's wallet revealed the same preimage to them, so payment itself establishes a shared secret: the buyer presents it to *your* API, you verify it against the webhook delivery, and you run the job on your own infrastructure (GPU, data source, whatever you sell). No accounts or API keys needed on the buyer side.
+
+This is how the live [Hypawave Compute demo](https://hypawave.com/offers) works — 100 sats buys one live image generation, settlement is the credential. For a standing many-buyer service use an accountless Path 3b offer (raw HTTP, see below); the SDK path is best for one-off, per-customer jobs.
+
+Full pattern: [Sell API Calls & Compute docs](https://hypawave.com/docs#sell-execution) · Recipe 6 in [llms.txt](https://hypawave.com/llms.txt)
+
 ## SDK for ergonomics. Raw HTTP for accountless agents.
 
 The SDK handles types, retries, polling, error parsing, and self-describing payload generation for **Path 2** (account-based agent API). Use raw HTTP when you need:
@@ -464,7 +472,7 @@ Most tools handle checkout, paid requests, or wallet rails. **Hypawave executes
 | Accountless agent access | ✅ | ⚠️ platform-dependent | ⚠️ wallet/facilitator | ⚠️ app ecosystem | ⚠️ mandate framework | ⚠️ keys, no app layer |
 | Mainstream billing, cards, reporting | ❌ | ✅ | ❌ | ⚠️ merchant checkout | ⚠️ partner ecosystem | ❌ |
 
-Hypawave is the execution layer: the same preimage that proves payment atomically releases encrypted file keys and fires the execution webhook. For basic file/key unlock flows, the delivery layer is built in.
+Hypawave is the execution layer: the verified payment preimage is the credential that releases the stored encryption key and fires the execution webhook. For basic file/key unlock flows, the delivery layer is built in.
 
 ## Links
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@hypawave/sdk",
-  "version": "0.4.1",
-  "description": "TypeScript SDK for Lightning settlement, preimage proof, and execution unlocks for AI agents.",
+  "version": "0.4.3",
+  "description": "Bitcoin Lightning SDK for AI agent commerce — non-custodial settlement that unlocks files, APIs, and compute.",
   "main": "dist/index.js",
   "module": "dist/index.mjs",
   "types": "dist/index.d.ts",

package/skills/hypawave/SKILL.md

@@ -5,7 +5,7 @@ description: Use Hypawave to charge in Bitcoin Lightning for files, APIs, comput
 
 # Hypawave — Lightning settlement for AI agents
 
-Hypawave is a non-custodial Bitcoin Lightning settlement protocol. Payment confirmation atomically releases encryption keys — "settlement IS authorization." Buyers pay creators directly; Hypawave never holds principal funds.
+Hypawave is a non-custodial Bitcoin Lightning settlement protocol. Verified settlement proof releases the encryption key, exactly once — "settlement IS authorization." Buyers pay creators directly; Hypawave never holds principal funds.
 
 ## Before you do anything
 
@@ -84,6 +84,10 @@ The SDK exposes flat methods (`pp.createInvoice`, `pp.getBolt11`, `pp.confirmPay
 
 For Paths 3a / 3b, there is no SDK — use raw HTTP with pubkey signatures per the manual.
 
+## Selling execution (paid APIs / compute)
+
+Settlement can gate execution, not just files. Set `execution_webhook` on the offer/invoice: on settlement Hypawave delivers the payment preimage to the seller's server, and the buyer holds the same preimage — a shared secret established by the payment. Buyer presents it to the seller's API as the credential; seller verifies and runs the job on their own infrastructure. Works on Path 2 (`execution_webhook` on create-invoice), Path 3a, and Path 3b. See Recipe 6 in llms.txt and the "Sell API Calls & Compute" docs section; the live Hypawave Compute demo (hypawave.com/offers) is this exact pattern.
+
 ## Non-negotiables
 
 1. **Preimage is mandatory** for principal settlements. Pay via a wallet that returns the preimage (LND, Core Lightning, LNbits admin key, Alby/NWC, Phoenixd). Consumer wallets like Wallet of Satoshi or Phoenix mobile cannot satisfy this. The wallet also needs **funded outbound liquidity ≥ amount + fees** — a fresh/empty node or "fee-credit" balance can't pay even when total balance ≥ price. For small or test payments, a **custodial wallet over NWC (e.g. Coinos)** skips channel setup entirely — only funding is needed.