Skip to content
This repository was archived by the owner on Jun 17, 2025. It is now read-only.
This repository was archived by the owner on Jun 17, 2025. It is now read-only.

Layer-2 Deposit Channels #8

@cmdruid

Description

@cmdruid

This topic is for the discussion of layer-2 deposit channels.

Currently, a deposit account is a 2-of-2 contract that can only be settled once.

We can extend the use of this deposit off-chain using a setup similar to a lightning channel:

  • Alice negotiates a lightning channel with the server, then registers a deposit into the channel (channel open). The escrow server deposits collateral into the channel.

  • Bob also negotiates a lightning channel with the server, then registers a deposit into the channel (channel open).

  • Alice creates an escrow contract that conditionally sends funds to either Bob or herself.

  • Alice signs transaction templates for each condition, with a revocation path that can sweep the collateral if the escrow server double-spends in the future.

  • The server can choose to broadcast one of the templates and close the channel, or negotiate a new channel (and revoke the current state plus ALL templates).

  • If the server double-spends, Alice can use her revocation key to sweep the collateral.

The setup and flow would be similar to a normal lightning channel, the difference being that we would use escrow contracts for exchanging balances between parties, versus an HTLC.

The escrow server would then act as a clearing-house of sorts, negotiating the next state for each deposit channel involved (and splicing out on-chain settlements), or settle all payments on-chain.

The advantages to this setup versus an HTLC:

  • Far easier to negotiate (server acts as coordinator).
  • Hub-and-spoke topology. No need for complex routing.
  • Payment contracts can be much longer lived.
  • No exponential lockup of liquidity.
  • All conditional payments backed by a single stake.
  • You can still program contracts with conditional payments.

The current lightning network is still a far superior choice for sending payments peer-to-peer, so it would make sense for deposit channels to be inter-operable with lightning channels. A "Contract Service Provider" would also benefit from using the existing lightning network to source collateral for their deposits.

This is still a topic heavy in R&D. Feel free to discuss if you have any questions.

Metadata

Metadata

Assignees

Labels

roadmapDiscuss a topic from our Roadmap

Type

No type

Projects

Status

Research

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions