Handling special rate

[ibanfi]

The stock ILP node is able to handle flat exchange rate only, it cannot handle complex business logic (pricing curves) and it cannot handle either when I want to provide special exchange rate for my customers.

The idea is: instead of implementing a complex and parameterized rate service into the ILP node (or outside, providing as a service), let the customer do this. The sender sends the amount and defines the target amount/currency or target rate. In this case the ILP node won't apply its own rate, it accepts and processes the requested transaction. Of course we have to consider so many restrictions, including:

• Whitelist with acceptable customers/IP address/etc.
• Explicit trust lines between sender end recipient address
• Amount limitations (not more than $100)
• Rate limitations (not more than 1:100)
• Transaction is acceptable only if the sender and the recipient address are on the same node (connector)
• etc.

Sample payload

Target amount

{
  "receiver": "$payment-pointer.example.com",
  "source_amount": 100000,
  "target_amount": 250
  "target_ccy": "USD"
}

Special rate

{
  "receiver": "$payment-pointer.example.com",
  "source_amount": 100000,
  "special_rate": 1.237
  "target_ccy": USD
}

[sappenin]

I'm not sure this is possible as you've framed the question. Let's imagine a $100 payment through the Connector. It's likely the Connector will see this "payment" as a series of packetized ILPv4 "payments" (e.g., 10000 packets of $.01 each).

Because of this, I don't think the Connector would have any way to know that any particular packet is for any particular macro-payment. That is, it won't be able to know: "when sending $100, apply this FX rate".

Some alternative ideas...

• Link-specific FX: Set specific FX rates for a given incoming+outgoing Link. While useful, it doesn't solve your problem because the rates don't vary on a per-payment basis.
• Link-specific FX (Part2): Setup a few different accounts with different FX rates for the same customer. So, if the customer wanted to make a $100 payment, they use account3, which has one pre-configured rate. If the customer wants to make a $1 payment, they use account1, which has a different FX, etc. We could use a /rates API call to adjust these rate overrides throughout the day?
• Make Connector "macro payment aware": We could design a system where the ILP sender passes-in a "paymentId" into each ILP-over-HTTP request. The Connector would need to call out to a service to see what the FX rate should be for each packet. While these call-outs could be cached, I suppose, it would get complicated quickly, and would probably hurt performance. It's also likely this system would break down unless the "sender" and everyone in the payment path was passing this header.

This isn't something we're going to work on in the short-term (next few months), but if you want to start a design spec or conversation around this with the rest of the community, I would be open to thinking more about it.

Implementation-wise, you would probably have to build it though unless you can wait a bit for the feature to gain broad acceptance.