Welcome to the REDSHIFT API

This documentation is your entry point to interacting with submarine swaps programmatically on REDSHIFT

What is REDSHIFT?

REDSHIFT is a payment network tool that allows Lightning Network payments to be made using on-chain assets like Bitcoin, Ethereum, and ERC-20 tokens.

It utilizes a technology called Submarine Swap in order to make payments in a trustless way - meaning the on-chain asset is controlled by the original owner until the Lightning Payment is sent.

Why is this useful?

There are a number of use cases for using Submarine Swaps to make Lightning Network payments:

Channel Rebalancing: The payment channels that compose the Lightning Network require maintaining sufficient liquidity in order to send and receive payments. REDSHIFT allows the liquidity within these channels to be adjusted without having to close and re-open channels with peers - avoiding on-chain opening and closing fees and maintaining the channel's successful payment routing history. Essentially, you can "top up" your local channel balance with REDSHIFT.

Merchants: Accept more digital currencies without adding additional infrastructure. If you already accept Lightning Network payments, REDSHIFT enables your customers to pay using other currencies while you still receive payment in LBTC.

Consumers: REDSHIFT allows customers to send payments on the Lightning Network without having to operate their own node or trust custodial wallets with their sats. Simply send on-chain assets from the wallet they already use and the Lighting Network invoice will be paid.

How does it work?

Submarine Swaps utilize a class of payments called Hash Time Locked Contracts (HTLCs).

HTLCs use hashlocks and timelocks to require that the receiver of a payment either acknowledge receiving the payment prior to a deadline by generating cryptographic proof of payment or forfeit the ability to claim the payment, returning it to the payer.

HTLCs are what make REDSHIFT trustless - neither the payer or receiver need to trust that the other party will make their required payment because ownership conditions are baked into the transaction itself.

Routing Node Example Workflow

Alice runs a Lightning Network node that helps route payments through the Lightning Network. She has opened a couple of channels with a handful peers and has been routing payments through them. After a few days, a lot of her balance has accrued on the remote side of her channels.

Instead of closing her lopsided channels and reopening them to regain more local balance, she generates an invoice for her channels with more remote capacity and sends it to REDSHIFT via REDSHIFT's API. REDSHIFT responds with a Bitcoin address and amount to send to the address.

Note: The amount of satoshis Alice will send to the address is typically greater than the amount of satoshis on the invoice. So in Alice's case, she might have to send 100,500 satoshis on-chain in order to fulfill her 100,000 sat invoice. This spread is how liquidity providers (the people paying the Lightning Invoice) make money and cover the cost of the on-chain transaction required to claim their funds after paying the Lightning Invoice that Alice provided.

Alice sends the Bitcoin to the prescribed address and her Lightning Invoice gets paid, pushing the remote balance of the channel back over to her local side, enabling her to send more outgoing payments through the channel without having to close and reopen it.

Merchant / Consumer Example Workflow

Alice wants to pay a 100,000 satoshi Lightning Network invoice with an on-chain asset like Ether. She sends the invoice to REDSHIFT via the REDSHIFT API or a REDSHIFT widget embedded on a webpage. REDSHIFT responds with an unsigned Ethereum transaction, which contains the contract address, input data, and amount of ether to send.

Note: The amount of value of the Ether Alice will send to the address is typically greater than the value of satoshis on the invoice. Let's say that one satoshi is worth $1 and one Ether is worth $1. In this case, Alice might have to send 103,000 Ether on-chain in order to fulfill her 100,000 sat invoice. This spread is how liquidity providers (the people paying the Lightning Invoice) make money and cover the cost of the on-chain transaction required to claim their funds after paying the Lightning Invoice that Alice provided.

Alice sends the prescribed amount of Ether to the address sent back from her REDSHIFT request. These funds are housed in an on-chain escrow protected by HTLCs.

There are now only two ways to claim these funds: either by the liquidity provider using the preimage revealed after paying Alice's Lightning Invoice or by Alice after the timelock has expired.

In most cases, the invoice will be paid and the on-chain asset will be claimed by the liquidity provider. If the invoice is unable to be paid, Alice will be able to re-claim her funds after the timelock expires. This isn't typical but can happen if a route cannot be found.