If I’m a sender, and my receiver has a different currency, once I know how much I want to send, how do I as the sender know what the exchange rates are and how do connectors decide to facilitate payments? Who sets the exchange rate, and is there back and forth until agreement is reach or something? Seems like ILQP was deprecated and there are no pricing curves anymore.
From what I gathered from another reading (can’t remember which one), the sender will indicate how much they will send, and all connectors will basically respond with the exchange rate with their counterparty? Is there some kind of algorithm in the reference implementation?
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.)
Where it gets a bit confusing is how a connector does an optimal pricing strategy. These are going to be autonomous systems similar to that of the internet, so if we were to deploy production grade connectors, what would be a recommended strategy? Polling from an API isn’t ideal if you wanted to make ILP support high frequency exchanges and the markets would be at the mercy of external data providers. If ever manipulated, these autonomous systems can be drained if they don’t take the right precautions and at the very least, they can be influenced. To add onto that efficient markets are important for connectors who are putting up with the risk - if this was a casino, connectors would not take on counterparty risk.
Perhaps this isn’t a bad thing. But if we theoretically had a Venmo to BTC swap support, then where would you get the pricing from? If you just picked a random connector, they could charge you far above market rate because there’s no clarity in what the market rate is. You could poll every connector, for the price, but here’s a simple manipulation attack if we do things that way → spin up a bunch of connectors, pump the exchange rate higher than it really is by responding with exchange rates in favor your connectors, and then capitalize on this eclipse-like attack. Now, maybe as long as there are other exchanges like Coinbase providing pricing on exchange assets, you could leverage that data source. But in a unique scenario of Venmo/BTC or something that doesn’t exist on other exchanges, it could be flawed.
One argument I can come up with to counteract this is that if there are multiple ways to get that asset (including outside of the Interledger protocol), and a connector is incentivized through supply and demand to offer competitive pricing based on that, then this all works out. And maybe executing the attack above requires a monopolistic scenario, where the connector is the only possible supplier. But also this could be considered acceptable because we can argue competition could work it all out.
Outside of the scope of the protocol itself, but very relevant ideas to deployed connectors.
the connector’s cost of liquidity (for example, the interest rate they get if they’re borrowing money)
the rate the connector can get on an exchange for trading the assets back
a buffer based on the volatility of the assets and the speed of the exchanges they use
some prediction of how the asset rates are likely to move
a discount if a particular packet helps the connector rebalance its accounts
Is the “you” in this example an end user / sender or a connector? Our assumption has most often been that relationships with connectors are longer-lived, rather than being picked on a per-payment basis.
You pick a connector because you think that it generally provides a good balance of cost, latency, throughput, liquidity, and reliability – and because you think it has peered with other connectors of similarly high quality. If it’s bad or seems to have consistently high prices (which could be judged by 3rd party rating services), you’ll switch.
In the example, “you” is the sender. But it seems like there’s a problem here for both senders and receivers, and as a result, connectors in general. Market makers will need bots it looks like, and when a connector also acts as a taker, they will probably want a bot that acts on all information available. After all, these other exchanges Coinbase, Stellar, etc. don’t necessarily poll from other places and make a decision. That doesn’t really bode well for staying efficient. You need the full list of fulfilled orders and unfulfilled to make some kind of inferences for the bot. Seems like it would be a useful project to write an application to aggregate things into a single order book, so that users have an idea of what the ILP exchange rates are.
@emschwartz There’s no RFC nor standard behavior for this type of pricing-information exchange, correct? I don’t think Connector’s will natively do this today, so do you think this deserves its own protocol? Perhaps a new ILPv4 Quoting Protocol, or perhaps something that happens in “health check” messages in the echo/ping protocol?
(See my other post, but I’m thinking that echo/ping should be limited “healthchecking”, and maybe some other protocol should cover metrics, like cost).
I agree with this statement in the general sense (especially for non-Connectors), but Connector’s themselves will likely have more than one “reliable and well-priced” partner Connector, just as a good business practice.
So, any thoughts around what should be the primary mechanism a Connector should utilize when it has multiple equivalent paths to a particular destination?
For example, consider this topology of Tier-1 Connectors where A wants to send XRP to D, and has two different choices where all of A’s considerations (i.e., latency, throughput, reliability,liquidity) with its two peers are equal, but the price between B/D and C/D is different:
┌───BTC┐ ┌─XRP──┐
│ │ ┌───┐ │ │
│ └──▷│ B │───┘ ▽
┌───┐ └───┘ ┌───┐
│ A │ │ D │
└───┘ ┌───┐ └───┘
│ ┌──▷│ C │───┐ △
│ │ └───┘ │ │
└────ETH └─XRP──┘
Were I running Connector A, I would of course want to this payment to take the lowest-cost path (i.e., "get the most XRP to D).
Aside from simple, “keep testing the paths to check the price”, are there any algorithmic mechanisms that might help here?
STREAM does include this. See the description here and the prepare amount field here.
I’m not sure that checking prices necessarily needs to be a function that connectors provide if it can be easily implemented by senders and receivers as an end-to-end function.
Not that I know of. Regularly sending packets to test paths and/or having dedicated services that do this for you seems like a decent way to determine the rates to me.
Yep, agree - where I was going with that question is that it feels weird for protocols to exist at the Interledger/Link layer (e.g., the current Echo protocol) that attempt to find path pricing.
Is it unreasonable to say: “All nodes that want to discover path pricing should just use STREAM”…or are there cases where STREAM is insufficient? I suppose this implies that a Connector would be able to initiate a STREAM payment and then peg it to a particular Link-layer account.