XLN is an implementation of Extended Lightning Network on top of Ethereum.

Send, trade, borrow and lend any ERC20 token instantly paying no gas-fees.

Channels, being the oldest and simplest to implement layer2 technology, are some of the least used ones. Lightning Network has less TVL lower than a medium sized DeFi project on ETH. Raiden (essentially Lightning Network on ETH) has $420 TVL on mainnet after more than 2 years on mainnet.

Why is that? Do we even correctly understand channels?

I don't think the failure should be attributed to the developing teams or their marketing efforts, instead I claim the one and only reason failure of channel networks failure is its strict collateral lockup requirements, also known as "inbound capacity problem".

Under original no-tradeoff LN architecture a new user cannot onboard without making a hub to commit some collateral to their relationship. The incentives are just not there for this to happen.

Solution: credit lines

I propose to solve it using a similar approach rollups currently use for instant confirmation: a fractional reserve-based promise aka credit line given by the hub/operator to the end user, that the assets will be collateralized in the future (in case of XLN) or the tx will be included in the batch (in case of rollups).

Instead of being collateral-only XLN channels allow any user to open a credit line to other user up to specific credit limit. This alleviates the "no route/capacity" problem of original LN/Raiden.

Why would we still benefit from channel networks when we have rollups being ready?

1. scalability of XLN is unbounded by onchain gaslimits, i.e. there is no necessary per-tx onchain footprint. You only sync heavily unbalanced channels to L1, and a million of $1 payments can remain entirely offchain as long as they net-out each other to zero.

In other words XLN can survive with expensive CALLDATA (e.g. on Ethereum Classic) and/or low gaslimits per block, while rollups will continuously require cheap CALLDATA and further L1 block gaslimit increase to scale

1. channels have perfect data availability because they sync current L2 state to L1 state, while rollups simply flush L2 history to L1 history as CALLDATA. There is no hard proof that re-genesis tricks on ETH or other EVM chains won't destroy historical CALLDATA at some point.

2. while rollups are fully EVM generalized, payment channels support paying/swapping/borrowing and lending (using Rainbow idea) and those are probably 90% of L1 use cases at the moment.

Why is XLN on the hackathon?

This project is NOT eligible for any prizes as it is built on an existing codebase. However I couldn't resist to participate in something called "Scaling Ethereum" and get feedback from Layer2 aficionados in the judges! Thanks in advance for taking your time!

Solidity contracts are 90% ready and are worth reviewing (https://github.com/homakov/xlncontracts).

Javascript daemon codebase is only 50% ready is NOT worth reviewing (https://github.com/homakov/xln).

Frontend UI is purely mockups in Vue.js.

It uses "ethers.js" to talk to L1 (Ganache dev environment).

The most hacky part of the protocol is HTLCs and full duplex interaction of two parties. For example when both parties (likely hubs) send each other 100 hashlocked payments at the same time, to avoid a deadlock the Right party must discard its transitions, apply the transitions by Left party, then re-apply its own transitions.

The channel architecture itself is more lightweight than one used in Raiden. It stores two numbers onchain: "collateral" and "ondelta", and one number offchain: "offdelta". These 3 numbers is all it takes to represent current channel state.

XLN.sol encapsulates all ERC20 inside same channel while Raiden requires per-token contract deployed. Also it allows batched deposits/withdrawals.