Features
Last updated
Last updated
Since the Taker is the only one who truly has the free option in the atomic swap (since they hold the pre-image, the ‘key’ that releases both funds) we require some collateral to be held based on the IV (implied volatility) of the pair over a period of 10 minutes (Bitcoin blocktime, which is the base lifespan of an HTLC).The key (secret) to the collateral is held on Flashnet servers. This way we, the orderbook, can pass the secret onto the Maker who can claim the collateral if the Taker is being malicious. The worst-case scenario is the collateral key gets leaked and a Taker loses some collateral for a specific trade is 0.002 BTC for 100 USD, and the IV of the pair is 1% over 10mins, the Taker may only suffer a $1 loss if he must wait a full 10 minutes to retrieve his collateral. In terms of trust concerns, for comparison, UniX and other RFQ blockchain based trading protocols hold trade signatures in central databases, but instead of a small percentage of the trade being the consequence of a database leak (like in the case of Flashnet), it could be the entire balance of one side of the trade.
By inheriting LN’s Onion Routing mechanisms, Flashnet traders are protected from ‘unfair’ forms of front-running.When orders are passed along the Lightning Network, the full path is encrypted. Each node in the path only knows where to send it to next. They don’t know the final destination. Further the routing node can’t differentiate between a payment and a trade, they don’t know the intent — the other asset in the trade and it’s quantity is unknown to the router. It cannot trace the payment to a specific order in the orderbook.
Flashnet also supports partial fills. Let’s imagine a Taker makes a limit order to buy 1 BTC for $100k USDT. But, in this example let’s also imagine that the only two orders in the order book are a sell order of 0.5 BTC for $55k, and and another sell order of BTC for $45k. The Taker would then be directed to duplicate its order in tranches. One for the $55k fill, and one for the $45k fill. The trade would basically happen in two instances, simultaneously where the Flashnet mechanism is expressed from one Taker but to two Makers.
Lightning is inherently reputational. Due to the nature of channels and the graphical layout of the Lightning network, nodes are incentivized to maintain good relationships with their peers. In a trading setup (vs. mere payments) there are certainly more nuanced behaviors to consider, since the stakes for ‘misbehaving’ are higher (both in punishment and reward). In general, a lot of existing dynamics in regards to liquidity provisioning and routing should naturally extend to these markets. Any node or cluster of nodes can at any moment (via consensus) decide to close their channels with a particular node and agree to not trade with it. These incentives can be used to guide behavior between actors in the exchange. Specifically, Market Maker nodes are heavily dependent on specific strategic channels open in order to have rapid routing and access to liquidity. A Maker node being blacklisted from a certain CEX will force them to find a new ‘cluster’ of nodes (perhaps another exchange) to peer with, and setup his strategic channels again. These strategic channels for a Maker node could look like big LPs who are also all using a certain exchange and maintaining a good reputation with each other.
