btc++ Berlin 2026 · Most Based Payment Protocol

Commission payments over
Nostr Wallet Connect

How a marketplace can take its cut on a Lightning sale without holding funds, without a key to the vendor's wallet, and with the customer paying one invoice.

Proposal: NWC-XX "Commission Payments"Spec: XX.md

The problem

Marketplaces need a cut. Lightning has no Stripe Connect.

What every marketplace wants: one payment, the commission settled between vendor and platform.

With cards, Stripe Connect does exactly this. Stripe holds the money in between.

With Lightning, there is no standard way to do it without someone holding the money or holding a key to the vendor's wallet.

Nostr marketplaces (Plebeian Market, SatShoot, Shopstr, Budabit) either skip the commission, make it voluntary, or route funds through the platform.

What we want

Requirements for the protocol

R1
One payment. The customer pays one ordinary invoice and never sees the commission.
R2
Non-custodial. The platform never holds the customer's or the vendor's money.
R3
Breach-safe. The platform can't spend from the vendor's wallet, even when it's hacked.
R4
Guaranteed commission. No credit and no "pay later".
R5
All or nothing. Either the sale and the commission both settle, or nothing moves.

Assumptions

The vendor uses a wallet with Nostr Wallet Connect, for example Alby Hub.

The platform has its own NWC wallet with hold invoices (NWC-03).

The customer uses any Lightning wallet. No changes on their side.

Status quo

Today: hold the money, or hope the vendor pays

Custodial: the platform becomes a custodian and a honeypot (R2).

Pay later: the commission depends on the vendor's goodwill, enforced by reputation (R4, R5).

Plebeian Market proposed moving from the first model to the second in September 2026.

Attempt 1

Give the platform an NWC key and let it pull the fee

One payment for the customer (R1).

The platform holds spending keys to every vendor wallet. A breach drains them up to their budgets (R3).

The fee is pulled after the sale, so the vendor can empty the wallet first (R4, R5).

Attempt 2

Let the customer pay two hold invoices

Non-custodial, and the vendor's connection is receive-only (R2, R3).

Commission guaranteed: the customer pays it directly (R4).

Two payments for the customer, the party most sensitive to friction (R1).

All-or-nothing only if the platform plays fair, since it coordinates both settlements (R5).

And the commission is a deal between vendor and platform. Why is the customer paying it?

Attempt 3 · prior art: Zaplocker

Put the platform in the middle of the payment

One payment, atomic, works with today's NWC (R1, R4, R5).

The customer pays the platform, not the vendor. Swapping in its own invoice is trivial theft. Zaplocker calls this the man-in-the-middle attack.

The platform needs outbound liquidity for every open order.

The idea

Flip it: the vendor's wallet is the hop in the middle

The vendor's wallet behaves like a forwarding node whose "routing fee" is the vendor's share.

The platform can only claim its commission by revealing P.

Revealing P is exactly what lets the vendor's wallet claim the sale.

The customer's money only moves if P is revealed.

Same mechanism as multi-hop Lightning payments and submarine swaps, so all-or-nothing by HTLCs, not by trust.

The proposal · NWC-XX

A conditional spending permission, enforced by the vendor's wallet

One new method, make_commission_invoice, bound to a commission policy the vendor sets in their wallet:

{
  "max_rate_ppm": 100000,      // at most 10%
  "payees": ["02ab…"],         // only to this node
  "max_routing_fee": { … },    // fees, capped
  "budget_msat": 50000000,     // per month
  "renewal_period": "monthly"
}

Platform X may create invoices for your sales. For each sale you receive, up to 10% is paid automatically to Platform X, only once the sale's payment has arrived. Platform X cannot send any other payments from your wallet.

What the vendor sees when connecting, via NWC-08 one-click connection.

The proposal · flow

One sale, step by step

To void instead, the platform cancels its hold invoice in step 6: the commission payment fails and the vendor's wallet cancels the sale.

Making it safe · timing

The vendor's wallet follows forwarding-node rules

Worked example: a 21,000 sat sale, 10% commission, sale invoice with a final CLTV of 328 blocks. Even if the platform claims at the last moment, the vendor keeps at least M = 80 blocks to claim the customer's payment, on-chain if needed.

Commission ≤ 10% and fees + commission < sale.

Payment hash never reused, paid at most once.

Commission paid only after the customer's HTLC is held.

Worst case for a stalling platform: funds locked about 41 hours, nobody loses money.

Result

How the options compare

Approach	R1 one payment	R2 non-custodial	R3 breach-safe	R4 guaranteed	R5 all-or-nothing
Custodial forwarding					trust
Pay later
Attempt 1: NWC key, pull the fee
Attempt 2: customer pays two invoices					trust
Attempt 3: platform in the middle					trivial MITM
NWC Commission Payments					HTLCs

Remaining trust: the platform knows P before the customer pays. If it is, or colludes with, a routing node on the customer's route, it could intercept the payment. PTLCs remove this. The preimage is therefore not proof of payment: vendors rely on their wallet's state.

Status

A spec, written for the NWC repository

NWC-XX "Commission Payments" in the style of the official NWC extensions, building on 02, 03, 06, 08 and 09.

Issue #8 and PR #9 submitted to github.com/nostr-wallet-connect/nwc.

No implementation yet. Customer wallets need no changes, platforms need only hold invoices, and vendor wallet services need one new method.

What we'd love feedback on

Wallet service implementers (Alby Hub and others): are the timing rules implementable as written?

Marketplaces (Budabit, Shopstr, Plebeian, SatShoot): does the policy model fit how you charge?

Commission payments overNostr Wallet Connect