Interledger has some unique properties as a value transfer protocol with exchange rates. The plan is to use it for paying with anything, but could we create a decentralized exchange (market and limit orders, orderbooks, users hold their keys, etc.) on top of Interledger, assuming ideal deployment of the protocol?
A couple characteristics draw attention to this and offer a competitive advantage for Interledger:
Interledger provides front running resistance.
Front-running is the practice of a broker or trader stepping in front of large orders to gain an economic advantage. The way this is currently done on platforms like Ethereum is by having someone submitting an order to an on-chain contract, where a miner can avoid publishing certain orders and arbitrage by publishing their own order to the same on chain contract. This doesn’t have to be a miner, it can also be someone who cheats the max-heap transaction fee selector in the individual blockchain clients by outbidding other transactions in the gas market. The main reason this is exploitable is because of the latency of on-chain settlement.
With the low latency nature of transfers and settlement via Interledger, a client can avoid the cases of front-running. In the case of a counterparty settling later on purpose and trying to arbitrage off trades in the same currency with other counterparties, this could be handled by refusing to trade after an expiration.
Interledger can pool liquidity from multiple areas in parallel, thereby being the most distributed in nature.
Interledger is powerful because of how easy it is to just make money flow given any supported currency. Fulfilling a buy or sell order through multiple streams seemed like a cool idea, but getting it optimal is more complex than just using distance vector routing. This is because we’re not routing from point A to B, we are searching for an optimal set of points that sum to a limit order (bin-packing, which is NP-Complete).
This is restricted by the fact we don’t have some kind of order aggregation like the orderbooks posted by Relayers in 0x. Perhaps you could recreate the Relayers on Interledger and have them collect an order matching fee or payment on API request. Would result in an interesting meta-protocol.
Interledger is token agnostic.
Interledger requires no underlying token or platform lock-in. Every other DEX is a smart contract on Ethereum that requires this or is built into the consensus rules of a blockchain (i.e. Stellar). We can support any ledger that offers payment channels.
Some other issues:
How do you receive the other currency when doing an exchange?
We need to keep in mind that to use a blockchain platform on Interledger requires opening a payment channel, at least for scalable decentralized exchange. Therefore if you had a two currency swap, you’d have to open a second payment channel to receive the final settlement in your desired currency. This could get crazy if you need to find a payment route that requires including two different counterparties! To find the best path is essentially a traveling salesman problem in terms of network topology and bin-packing in terms of fulfilling limit order. Pretty ugly. However, playing around with heuristics could reduce this to a distance vector routing problem, but I haven’t thought this through yet. This problem is basically the equivalent of sending payments to yourself, but in a different currency! Pretty cool if you could do HFT with it.
could we create a decentralized exchange (market and limit orders, orderbooks, users hold their keys, etc.) on top of Interledger, assuming ideal deployment of the protocol?
An exchange running on something like Codius would be a practical way of doing this. Users could deposit and withdraw over Interledger, and they could use the Interledger network to rebalance their liquidity. Orders would occur in the exchange system, though, rather than over the Interledger network itself (so as not to complicate the protocol).
I don’t think Interledger on its own functions as a good exchange, because as you’ve laid out the routing just isn’t set up for that and the requirement of bilateral relationships makes it hard to trade directly with many other people.
We need to keep in mind that to use a blockchain platform on Interledger requires opening a payment channel.
Payment channels allow you to lower counterparty risk to near-zero by bringing the time of settlements to near-zero, but it isn’t required to use Interledger.
The general rule is that you can use a settlement mechanism that takes N seconds if you trust your peer for the value of at least N seconds worth of traffic.
An exchange running on something like Codius would be a practical way of doing this. Users could deposit and withdraw over Interledger, and they could use the Interledger network to rebalance their liquidity. Orders would occur in the exchange system, though, rather than over the Interledger network itself (so as not to complicate the protocol).
Yes, I could see that being a thing. I’m under the impression that centralized orderbook, with trustless off-chain settlement is the way to go for a DEX both in terms of security and scalability. To offer strong security guarantees, I think you’d want to leverage an SGX enclave (or state-of-the-art secure enclave) to simulate a structure similar to IDEX on Ethereum. What you’d really want is the power of verifiable execution of a program, and enclaves are the best shot at doing that quickly in the next few years. Maybe some other cryptographic techniques are feasible since the logic of this DEX isn’t necessarily NP-Hard, with the exception of order matching.
A better term for this would be non-custodial exchange, rather than decentralized. Having your own custody on Interledger means liquidity is always available if you look for it. Also, the lack of orderbooks is a problem if you try to do this on interledger, and distributed orderbooks require a new overlay network. If we apply end-to-end arguments, I think it suggests that we should run the exchanges at endpoints. Mixing that with censorship resistance makes it all the more interesting, and can be done with enclaves!
Right, I should have been more clear about that, I think in this case you’d want a payment channel (or something off-chain) for front-running resistance and alleviating Layer 1 of transactional burden. Also low latency is a huge plus for a real exchange.
When I read this piece last year about investors trying to buy large amounts of stocks and complaining about high-frequency traders driving up the price, I started thinking about the streaming exchange alternative.
What if you had an exchange that capped the max order size (like Interledger’s max packet amount) and basically turned everyone into high frequency traders? HFTs might have a harder time differentiating between orders from other HFTs versus larger investors because all of the orders come in around the same size.
While this wouldn’t have to be implemented through Interledger, this would be an “Interledger-y” approach to trading.
ILP Prepare Packets as Orders
ILP packets are not meant to express order semantics, so there’s a good chance that you would want completely separate protocols for a streaming exchange.
However, what if you had a “netting-only” connector? Imagine a connector that doesn’t provide any liquidity itself and only forwards packets when there are “crossing” packets in opposite directions.
The way to “place an order” is to send an ILP packet through the connector, potentially with a longer-than-normal timeout – or maybe 30 seconds is enough. If there’s a matching order in that time, the packet is forwarded to whatever address you specified, and if not it’s rejected. Is that close enough to the semantics of a limit order?
One question would be how to deal with packets that you forward being rejected. It might be sufficient to take that risk and just drop the priority of that particular sender’s packets in the future so they’re disincentivized from having rejected packets. Having lower order priority would be a very bad penalty for a trader, and we’d be assuming the amounts are relatively small anyway.
Maybe you wouldn’t. In an ideal world there could be some kind of infrastructure to represent an asset that could freely move around over the Interledger (or another overlay network that would support streaming). Otherwise, wouldn’t really be an exchange where you have real ownership of stock. However, if I have the keys to make a transfer on an exchange (treating the exchange like a payment channel), then you could do a streaming exchange of sorts. The problem with this is settlement though, you can’t do HFT unless you have a fast settlement method. If you treat it like credit and don’t settle immediately then there’s too much risk involved. And right now, you can’t just directly send someone 0.01 shares of Apple stock on an exchange.
So maybe creating some kind of universal representation of an asset for easy transfer would not only fix this problem, but be beneficial in other ways. But let’s say we aren’t getting that any time soon. I think if an exchange supported transfer between any individual, we could decouple order matching from those exchanges and bring that functionality out to Interledger.
Right now there’s no transparency of assets on centralized stock exchanges, and you have a very restricted API on most stock exchanges, as well as per transaction fees, so it’s basically a gateway mafia, which is exactly what crypto-networks want to get away from. If dark pools happen, I’d at least prefer them to happen over the Interledger.
Sorry, you’re right. I was thinking of trading assets already represented on a blockchain-like ledger with features such as payment channels. I think there are enough people trying to make tokenized assets happen that this exchange design could just assume it’s for that type of asset.