Fixed destination amount push payments

Protocol Design
,
2

Hey @bariabbassi!

Fixed destination amount payments are handled at the transport layer, using STREAM, and currently setup using SPSP (but @adrianhopebailie and others are working on improving this with Open Payments).

How this could work (AFAIK, only the Java implementation and the Open Payments demos support this, but hopefully it’ll be expanded upon soon):

  1. Recipient/merchant provides the user with an invoice for the destination amount and asset they want to receive (ideally, this would be automatically populated into the user’s wallet).
  2. The sender’s wallet pulls from an exchange rate API (like CoinMarketCap) to determine the rate between their source asset and the destination asset. It subtracts some slippage/fees from this to determine the maximum amount it’s willing to send in its source asset. It may also send probing packets to the recipient to get a better idea of what the actual exchange rate is before presenting it to the user.
  3. Wallet prompts the user to authorize the payment, likely displaying the maximum source amount, invoice amount in the destination asset, and expected fees. User approves or denies.
  4. The wallet begins sending the payment with STREAM. Using the exchange rate calculated previously, in every STREAM packet the sender effectively says “only fulfill this if you receive more than x amount” (in the destination asset). That way, the sender can enforce that money only gets their if it meets a particular minimum exchange rate, and it knows if the recipient fulfills the packet, they got at least that much money. When they fulfill the packet, the recipient also tells the sender how much they got (*although they could lie about this). The sender uses this to determine how much more money it needs to send. Note that if all the packets received by the recipient don’t meet the minimum exchange rate, they’ll reject them, and the payment will eventually fail. Partial completion is a possibility if the exchange rate fluctuated a lot in the meantime, but this is unlikely.
  5. It’s possible the sender might overpay the recipient slightly, since you can’t precisely account for the exchange rate/fees between source and destination, so if the recipient only wants to receive the exact amount in the invoice, it’s their job to enforce this. Their STREAM receiver should reject packets that would result in the sender overpaying the invoice. The sender would reduce their packet amount, and slowly get closer and closer to completing the payment, kinda like a binary search.

The interesting thing about a lot of this (by contrast to e.g. a blockchain like Ethereum) is it’s mostly implementation-related concerns, rather than protocol concerns. That’s really powerful, since it’s much easier to just update/improve one participant’s software rather than requiring every participant to agree to a new protocol!

1 Like