@hypawave/sdk 0.4.3 → 0.4.4

package/CHANGELOG.md

@@ -5,6 +5,10 @@ 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.4]
+
+- Bundled skill (`skills/hypawave/SKILL.md`) now points to the MCP server (`@hypawave/mcp`) as the preferred execution path for the accountless flows when the agent's environment supports MCP.
+
 ## [0.4.3]
 
 ### Changed

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hypawave/sdk",
-  "version": "0.4.3",
+  "version": "0.4.4",
   "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",

package/skills/hypawave/SKILL.md

@@ -30,6 +30,10 @@ That document is authoritative. It contains:
 https://hypawave.com/.well-known/openapi.json
 ```
 
+## Prefer the MCP server when available
+
+If your environment supports MCP, the accountless flows (Path 3a/3b) are available as ready-made tools via `npx -y @hypawave/mcp` (npm: `@hypawave/mcp`, in the official MCP Registry) — `search_offers`, `buy_offer`, `download_files`, `create_offer`, `attach_file`, `manage_offer`, and more. It handles secp256k1 signing, canonical hashing, AES-256-GCM encryption, NWC wallet payments, and settlement/preimage verification internally, and holds your seller identity — so you don't implement the protocol at all. Use this skill when MCP isn't available or as the protocol reference. Setup: https://github.com/hypawave/mcp
+
 ## Quick decision tree
 
 Pick the path that matches the user's situation:
@@ -88,6 +92,10 @@ For Paths 3a / 3b, there is no SDK — use raw HTTP with pubkey signatures per t
 
 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.
 
+## Discovery (public offer directory)
+
+Offers can opt into a public directory. **Find offers to buy:** `GET /api/offers/public` (no auth) — filter by `q` (title/description text), `category`, `tags`, and `sort` (`newest` or `settled`); paginate via `limit`+`cursor`/`offset`. Each result carries `title`, `category`, `output_type`, `input_schema`, price, and `payment_count` — settled-sales **volume, not a trust or fulfillment guarantee**. **List your own offer:** add `is_public: true` to `POST /api/offers` with required `title`/`category`/`output_type` (and optional `tags`/`input_schema`) — immutable after creation. **Flag abuse:** `POST /api/offers/{id}/report` (queues for manual review, never auto-hides). Full field list in llms.txt → "Discovery".
+
 ## 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.