Great question!
ILQP was deprecated in favor of using test ILP packets / probing to discover the exchange rate. If you want to figure out the current exchange rate for a path, you can send a Prepare packet with an unfulfillable (random) condition to the receiver for a certain source amount. The receiver will reject the packet (because it’s impossible to produce the fulfillment for it) and can include how much arrived in the Reject packet.
The STREAM protocol includes the amount received in every Fulfill and Reject packet and encrypts that so it cannot be tampered with.
Limitations of this approach:
- No guarantees - the exchange rate on the real (fulfillable) Prepare packet you send may be different than the rate on the test packet. However, even ILQP didn’t provide guarantees. If you want to ensure that you don’t get a worse exchange rate than you expected, you can tell the receiver not to fulfill an incoming packet with less than a certain amount (STREAM also includes this behavior)
- Exchange rates changing over time - similar to the point above, the exchange rate may change while you’re sending a bigger chunked payment. You can set the minimum amount the receiver should receive on every packet, but this doesn’t necessarily help if the exchange rate moves permanently. We took a page out of the Internet Protocol’s book on this one and opted for fewer guarantees, which makes the protocol significantly faster and easier to implement for connectors.
- No support for rates that vary by payment size - this was one of the big changes when we removed liquidity curves and switched to packetized payments. The assumption now is that all packets should be within a range where the rate should not vary by amount (for example a packets with amounts between $0.01-$0.10 or even $1 can all have the same rate).
Each connector can set their exchange rate however they like. When a packet comes in, they apply their current exchange rate to the incoming amount and send it on. If the sender wants to determine the rate before sending for real, they can use the method described above. (This is an end-to-end concern for the sender and receiver to decide between themselves, connectors just give whatever rate they give and you take it or leave it.)