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

Atomic Swaps allow two parties to exchange different tokens without the need for a 3rd party, eliminating most of the risk of fraud or ounterparty default.

In this case, our Customer has earned 1 SND token (which for our purposes is our pretend airline mile token) via previous purchases and 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 between assets are possible. In fact, Blockstream has a tool to simplify using it.

Obviously to do a swap, we will need another wallet, as you can't swap between the same wallet (you can use the *same node* but use *different wallets*. 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 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
  },
```

For our example, we can assume that StackerNews Airline (Node 1) is willing to accept a SND token and return to the client 23,000 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

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.

One of the main 

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

## Building Your Own Federation

## Pegging Out

# Final Discussion and Ideas



