NWC Commission Payments

Stripe Connect for Lightning, without the custodian. A Nostr Wallet Connect extension that lets a marketplace take its cut on a Lightning sale while never holding funds and never holding a key to the vendor‘s wallet. The customer pays one ordinary invoice.

The problem

Marketplaces earn a commission on sales between buyers and their vendors. On Lightning there is no standard way to collect it without someone holding the money or holding a spending key. Nostr marketplaces today either skip the commission, make it voluntary, or route every payment through the platform.

The options with NWC as it stands:

• Custodial forwarding. The platform becomes a custodian and a honeypot.
• A pay_invoice key on every vendor wallet. One breach of the platform drains every connected wallet up to its budget.
• Pay later. The commission depends on the vendor’s goodwill.
• Two invoices for the buyer. Two payments for the most friction-sensitive party, to settle a deal they are not part of.

The idea

Flip the usual swap: the vendor‘s wallet is the hop in the middle.

1. The platform generates a preimage P and creates a hold invoice for its commission on its own wallet, with hash H.
2. It asks the vendor’s wallet service for a sale invoice with the same hash H, via the new make_commission_invoice method.
3. The customer pays the sale invoice. The vendor‘s wallet holds it.
4. The vendor’s wallet pays the commission invoice, within a commission policy the vendor set: at most X percent, only to this payee, fees capped, monthly budget.
5. The platform settles its hold invoice, revealing P. The vendor‘s wallet settles the sale with P.

The platform can only collect its commission by revealing the preimage that lets the vendor collect the sale. All or nothing by HTLCs, not by trust. The vendor’s wallet follows ordinary forwarding-node timing rules, so the commission HTLC always expires a safety margin before the customer‘s.

Properties

• One payment. The customer pays one BOLT11 invoice and never sees the commission.
• Non-custodial. The platform never holds the customer’s or the vendor‘s money.
• Breach-safe. The platform cannot spend from the vendor’s wallet. A hacked platform can at most create sale invoices and cancel pending sales.
• Guaranteed. The vendor cannot settle the sale without paying the commission.
• Idempotent. The client picks the payment hash, so a repeated request returns the original result.
• Minimal footprint. Customer wallets need no changes. Platforms need only NWC-03 hold invoices. Vendor wallet services add one method.

What is new

A conditional spending permission: “pay at most X ppm of a payment I am receiving, only to this payee, and only atomically with that payment.” It is a new primitive for NWC. Marketplaces are the motivating case, but the same permission covers affiliate fees, referral splits and service fees owed from a received payment.

The construction is the same one lnproxy and submarine swaps use, with the vendor‘s wallet as the relay and the vendor’s share as the relay‘s fee.

Remaining trust

The platform knows P before the customer pays. A platform that is, or colludes with, a routing node on the customer’s route could intercept the payment. PTLCs would remove this. The preimage is therefore not proof of payment for the vendor, who relies on their wallet‘s state instead.

Status

A spec written in the style of the official NWC extensions, building on NWC-02, 03, 08 and 09, submitted to the NWC repository. No implementation yet.

• Proposal and discussion: https://github.com/nostr-wallet-connect/nwc/issues/8
• Draft spec: https://github.com/knockoph/nwc/blob/commission-payments/XX.md

Feedback wanted from wallet service implementers on the timing rules, and from marketplaces on whether the policy model fits how they charge.