Recently had a conversation about a weird use case for ILP, thought it would be fun to write up. The challenge is as follows: how can we utilize ILP’s trust model for non-fungible assets like Cryptokitties?
A fun solution is to place the kitty into a smart contract which maintains a token and a resolveOwner function. On resolveOwner, the contract looks at all token balances, and randomly distributes the kitty to an owner with probability equivalent to the relative balance of each token holder.
The token balance would be initialized as fully owned by the initial owner of the kitty. Then, they may put that token in a payment channel, and stream the token like any other. Each packet would be equivalent to giving up a small probability of owning the kitty after the contract is resolved.
In expected value, this should be equivalent to sending “fractions” of the indivisible object. Of course, since that’s only in expected value, this might not be an appealing option unless you’re trading many kitties–at which point, you might argue you should stream individual kitties and execute trades over large batches of kitties. Nevertheless, this construction does allow you to trade “one at a time” instead of in batches.
3 Likes
“Probabilistic macropayments” 
Fun idea! It doesn’t sound all that practical but it’s an interesting one to think about. I’d guess that in most cases, it would be better to just use a contract as an escrow agent and have it transfer the full kitty once the full amount has been received.
Side note: here’s one way of describing why sending super high value packets through a network like Interledger (or Lightning) is probably not a good idea. The core protocol effectively escrows assets while you’re trading them. Escrow is a somewhat expensive service. If you make the whole network of nodes act as escrow agents for you while you’re waiting for some large (or long) trade to execute, that’s going to be super expensive – and much more expensive than getting a single escrow agent to execute a trade for you. That’s why for this type of use case, it’s better to use a dedicated escrow service than adding that as a feature to the whole core network (end-to-end principle).
Love the name! 
I actually am not sure this can work–because all payments up to the last are not meaningful, and withholding the last payment would be equivalent to preventing the trade. Why not just have a swap contract on the main chain at that point?
Regarding the last point: do you mean specifically because each node along the money packet’s path needs to be locked in escrow?
Yep.
James Prestwich (Summa) described a really neat way of doing this with stateless swaps for Bitcoin to/from Ethereum at the MIT Bitcoin Expo, but it only works because of the specific properties of each chain (SHA256 EVM OPCODE), so a lot of other chains will not work. With stateless swaps, there is no free option issue, but it does require certain functionality to be enabled on either ledger, and therefore not universally interoperable. I cannot find the recording online, but it is worth the watch.
In my opinion, the most practical (but still impractical) use case for transferring an NFT over ILP is using it at as a source of liquidity for a single hop between peers, so that nothing is actually locked up, but I would assume that out-of-band negotiation would be required. For example: suppose you have a good relationship with a peer and collateralize your boat in exchange for credit.
Yes, if you are escrowing funds for a large amount of time, you are potentially losing money by not forwarding packets you would have otherwise prepared and fulfilled. In other words: when you are sending money to trustlessly receive an NFT, you are restricting the liquidity of every node in the path until that payment is fulfilled.
Probabilistic micro-payments kind of reminds me of FOMO 3D and PoWH3D in some ways, which was really cool to watch. It would be interesting to pay for probability “shares” and receive payouts in a non-native currency over ILP auto-magically, but I am not sure about its actual feasibility.