DeepDive into Liquid: Part III - Advanced Asset Functions, Peg-Out, Discussion

This is a multipart DeepDive that will focus on the Liquid Sidechain. It will be released in 3 Parts:

Part I: Overview, Installation, and first Peg-In
Part II: Asset Creation and Configuration
Part III (this): Advanced Topics and Peg-out

Advanced Asset Topics

In Part II, we focused on issuing Assets. Now let's look at the ways you can use assets.

One of the most basic usecases for a custom issued asset is to exchange it for something else. For purposes of discussion, let's assume that a company - say StackerNews Airline - wants to issue their clients "Air Miles" for each flight they take. The idea is clients will accrue these points and then be able to exchange them for either discounts off future flights or direct cash (ie. USD / BTC).

If we start thinking like a developer for second, all of this implies lots of little things to be built: We would need an accounting system to manage the points, we would need some way to issue these points to the clients, who themselves would need some a way to store and manage their points. Further, there would need to some type of middleware to handle the exchanging of points for cash. Also there is a big question of security...could development staff - either intentionally or unintentionally - wind up giving away millions in points? Sure, Stacker News could just do all this themselves using SQL, but lets suppose that since they were clever boys & girls, so they wanted to do as little of the hard work as possible.

Liquid would make a great solution for this case. They could simple direct their users to download one of the existing Liquid wallets[^1] and use the Liquid sidechain as the "accounting system" for their asset.

Atomic Swaps

So our client has 1 StackerNewsDemo-1 token in their wallet (which for our purposes is our pretend airline mile token) and he wants to exchange that for L-BTC. How do we do that?

Obviously, we could build some type of webservice that had SQL databases and nodejs files that accept Asset A and then issued Asset B once received...however as we said our StackerNews crew is smart and therefore prefers to do less hardwork

Luckily, due to the additional OPCODEs in Liquid, it supports atomic swaps between assets. In fact, Blockstream has a tool to simplify using it (obviously the steps we do here manually with the tool would be automated within the server / client in production).

Obviously to do a swap, we will need another wallet, as you can't swap between the same wallet (you can refer to individual wallets in the swap-tool URL connect string by using the http://user:password@localhost:7041/wallet/walletname path)

In my case, I have 2 nodes each running elementsd server (Umbrel and another). So I will use that, but point is this can be done one a single node by setting up mutliple wallets and using distinct URL connect strings.

Before we start, let's look at state of our 2 wallets:

#Node1 - StackerNews Airline, Inc.
"balance": {
     "bitcoin": 0.00131755,
    "3e62af3c80c56ab6fec3d1e5646637152afebaf2a86ace075bbb7a88702e1fe5": 8.00000000
  }

#Node2 - The Customer
"balance": {
    "bitcoin": 0.00010623,
    "3e62af3c80c56ab6fec3d1e5646637152afebaf2a86ace075bbb7a88702e1fe5": 1.00000000
  },

For our example, we can assume that StackerNews Airline (Node 1) is willing to accept a SND-1 token and return to the client 23,000 sats (approx $1 USD currently). So they make the following proposal

$ liquidswap-cli -u http://$E_RPCUSER:$E_RPCPASS@localhost:7041 propose -o proposal.txt 3e62af3c80c56ab6fec3d1e5646637152afebaf2a86ace075bbb7a88702e1fe5 1 6f0279e9ed041c3d710a9f57d0c02928416460c4b722ae3457a11eec381c526d 0.000023

This file was exported to proposal.txt and transfered to Node2 (the customer), which was then inspected:

We can see that this proposal matches our expectation (1 SND token in exchange for .000023 L-BTC). So Node2 accepts the proposal:

Now the file accept.txt is transferred back to Node1 where it is finalized and sent.

$ liquidswap-cli -u http://$E_RPCUSER:$E_RPCPASS@localhost:7041 finalize accepted.txt -s
{
    "broadcast": true,
    "txid": "e427ff20ee93b5c9fef74031492357f3fcb535ec834f2035918008d3de406808"
}

Securities / Transfer Restricted / etc

Pegging Out

Discussion

Lightning Integration

Using Liquid with BTC / LN

Comparing eCash / Lightning / Liquid / BTC

	eCash	Lightning	Liquid	BTC
UTXO Model:	No UTXO. Bearer token	Your UTXO is in a multisig.	You own UTXO in sidechain	You own UTXO in mainchain
Redemption:	Depends on mint	No dependency (might require fee)	Depends on Federation	No dependecy
Longevity:	Mint must survive	Channels will close at somepoint	Federation must survive	UTXO forever
Online:	Must be online to verify eCash token	You must be online to recieve. You must stay online (or hire watchtower) to secure channel state	Offline receive	Offline receive
TXN Time:	Instant transactions	Instant transactions	Fixed 2 min transactions	Variable ~10 min transactions
Fees:	No fees	Neglible fees (msat)	"Low" fees (~200 sats)	High fees (~15,000 sats)
Liquidity:	No liquidity management	Must manage liquidity (in/out)	No liquidity management	No liquidity management
Privacy:	Mints can aggregate and assemble transaction data	Nodes could aggregate and assemble transaction data	Confidential transactions	Absolute public ledger
Federation:	Must vet each Mint	You choose channel partner	Known federation members	Soverign
Frac Reserve Possible:	Yes	No	Verifiable Issues	No
Likely Threat:	Debasement or Mint rug	Theft of funds while offline	Federation censorship	Losing keys / unspendable UTXO for fees
Maturity:	2023-2024	2018	2018	2009

5.9 KiB Raw Blame History