Skip to content

Latest commit

 

History

History
100 lines (71 loc) · 3.17 KB

ddip-003.md

File metadata and controls

100 lines (71 loc) · 3.17 KB

Payments in D4 protocol

optional author:akhavr

This DDIP defines OPTIONAL field payment in the worker response that defines payment expectations.

{
[...]
 "version": "0.1.0",
 "payment": <payment protocol: string>
}

If no payment field is present, no payment is expected. Worker then MAY ignore max_iteration_cost and max_total_cost entries in this case.

If a payment field is present in the worker result response, the client MUST use payment protocol it to pay total_cost amount.

This DDIP defines lnurl, lightning address and nip-57 payment methods:

  • lnurl
  • lnaddr
  • nip57

Other payment protocols, for example defining less custodial payment methods, are to be defined in separate DDIPs. They MAY or MAY NOT use the same balance logic.

Worker keeps a balance of the client. There might be several workers, sharing the same balance.

Balance policy is up to worker. For example, the worker MAY allow the balance of a particular client go negative. The worker MAY execute a function call if the balance is already negative.

Since worker balance is not intended for money storage, it MAY also charge a storage fee.

Recomended approach is to fund worker balance, perform a call or several ones, and withdraw it.

If the client has a positive balance at the worker, or the worker allows balance to go negative, client discovers payment protocol and payment details from result response.

If worker needs a prepayment, then the worker MUST submit a price negotiation request with the payment data.

Worker's payment details MAY change anytime, so client SHOULD use the latest supplied worker payment data.

Client SHOULD verify result and price negotiation event signature if it contains payment field.

LNURL payment protocol

For lnurl purposes the worker is "the service".

If worker signaled that he's willing to get paid with lnurl protocol, there MUST be extra field lnurl which contains payRequest endpoint per LUD-06: payRequest base spec

Then the payment MUST proceed using LUD-06 spec.

The client SHALL identify itself using LUD-18: Payer identity in payRequest protocol.

The client MUST pay at least max_total_cost msats.

The worker MUST support at least LUD-03: withdrawRequest base spec

Lightning address payment protocol

If worker signaled that he's willing to get paid with lnaddr protocol, there MUST be an extra field lnaddr which contains the lightning address in the form of [email protected]

From this point on, the event flow is the same as with lnurl payment protocol.

NIP57 payment protocol

Event flow happens per Nostr Lightning Zaps specification. Client MAY zap either worker pubkey or result response or price negotiation event.

Withdrawal is not possible in this payment protocol.