# 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](https://stacker.news/items/399400): Overview, Installation, and first Peg-In
* [Part II](https://stacker.news/items/407806): Asset Creation and Configuration
* Part III (this): Advanced Topics and Peg-out

# Advanced Asset Topics

[In Part II](https://stacker.news/items/407806), 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, this implies many things to build: 
  * An accounting system to manage the points 
  * A way to issue these points to the clients, who themselves would need some a way to store and manage their points
  * Middleware to handle the exchanging of points for cash
  * Security? How do we secure this? How to reduce fraud as much as possible? 
  
Sure, Stacker News could just do all this themselves using SQL, but lets assume that since they were clever boys & girls, 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

In this case, let's suppose our Customer has earned 1 SND token (which for our purposes is our pretend airline mile token) and now he wants to exchange that for L-BTC. How do we do that?

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*. Moreover all of the above lends itself to risk of fraud and counterparty default.

Luckily, due to the additional OPCODEs in Liquid, Atomic Swaps are supported[^2]. In fact, [Blockstream has a tool](https://github.com/Blockstream/liquid-swap) to simplify using it[^3].

To do a swap we will need another wallet, as you can't swap between the same wallet (techically you can use the *same node* and use 2 different wallets on that node[^4]). In my case, I have 2 nodes each running their own `elementsd` server (Umbrel and my desktop). So I will use those, 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
  },
```

The Blockstream Liquid Swap tool mentioned previously works both in CLI and GUI mode. So for this example we will use CLI for Node1 and GUI for Node 2.
The swap offer (proposal) is StackerNews Airline (Node 1) is willing to accept a SND token and return to the client 2,300 sats (approx $1 USD currently). So Node1 makes the following proposal:

```
# StackerNews Airline, Inc.
$ 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:

![](1-part3-clientaccept.png)


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

![](1b-part3-clientaccept.png)


The export `accepted.txt` file is transferred back to Node1 where it is finalized and sent.

```
# Node 1 - StackerNews Airline, Inc.
$ liquidswap-cli -u http://$E_RPCUSER:$E_RPCPASS@localhost:7041 finalize accepted.txt -s
{
    "broadcast": true,
    "txid": "e427ff20ee93b5c9fef74031492357f3fcb535ec834f2035918008d3de406808"
}
```

Now lets review the state our wallets post swap:

```
#Node1 - StackerNews Airline, Inc.
"balance": {
    "bitcoin": 0.00129180,
    "3e62af3c80c56ab6fec3d1e5646637152afebaf2a86ace075bbb7a88702e1fe5": 9.00000000
  }

 
#Node2 - The Customer
"balance": {
    "bitcoin": 0.00012656
  }, 
```

|SWAP SUMMARY| Node 1 (Stacker News) | Node 2 (The Customer) |
|------------|-----------------------|-----------------------|
|SND Pre-Swap| 8 | 1 |
|SND Post-Swap| 9 | 0 |
|L-BTC Pre-Swap| 131755 sat | 10623 sat |
|L-BTC Post-Swap| 129180 sat | 12656 sat |
|TOTAL FEES PAID| 251 sat | 291 sat |
 

## Securities / Transfer Restricted / etc

## Lightning Integration

There are two separate topics to go over with Lightning <-> Liquid. First is *L-BTC Lightning* (that is LN as a 2nd layer to Liquid). Secondly, the more familiar, using regular BTC LN with Liquid. 

## Using Liquid with BTC / LN 

What if you have no desire to create tokens, securities, etc...can you still make use of Liquid? 

Yes, probably one of the best ways to do that is to use it as a *staging area* for opening Lightning channels. In fact, both Blockstream Green and the newly announced (more user friendly) AQUA both do that under-the-hood. They are using services like Boltz, which allows you to open Lightning Channels with L-BTC.

### 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

## Building Your Own Federation

## Pegging Out

# Final Discussion and Ideas



[^1]: BlockStream Green, AQUA, Anser (web wallet), Specter, Marina (web wallet)
[^2]: Atomic Swaps allow parties to exchange different tokens directly without the need for a 3rd party, eliminating most of the risk of fraud and counterparty default.In fact, Blockstream has a tool to simplify using it.
[^3]: Please `git clone` the repo and don't rely on the pre-compiled downloads in repo (they are out of date from source)
[^4]: You can specify to individual wallets in the swap-tool URL connect string by using the `http://user:password@localhost:7041/wallet/walletname` syntax