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

• 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?

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

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

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

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

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

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

• Asset Holder Registry - Since AMP is notified of transfers, so it makes it possible for the Issuer to always know "who has what". Thus, although everything is confidential on the public blockchain (and even among the asset holders), the Issuer can still have visibility into this.
• Share / Ownership Vetting - Because point-in-time moves can be queried, its possible for the Issuer to calculate "how long has User A owned this asset". This enables concepts like "share vetting" (eg. you can only sell your shares after holding for 365 days)
• Paying Dividends - Since you can calculate point-in-time ownership, this makes it possible to use these assets to pay dividends (say for instance your company was to pay .01 BTC in dividends this month, and you calculated that User A held a share for 10 days and User B for 20 days. Thus, you could pay User A .0033 L-BTC and User B .0066 L-BTC)

• High fees to open / close
• High fees then force larger minimums for open / close
• Higher channel sizes then increases risk in hot wallet

• Use a CEX (Bitfinex, Bull Bitcoin, Btcturk, BTSE)
• Bisq (defi)
• TDEX (defi)
• sideswap.io (atomic swap)
• boltz (if you want to go from Liquid to LN)
• Use a wallet that integrates to one of the above (AQUA)

$ sudo ~/scripts/app compose elements exec node elements-cli -rpcuser=$E_RPCUSER -rpcpassword=$E_RPCPASS -named sendtoaddress address="VJLGBLED..." amount=0.0011 fee_rate=0.1 assetlabel="bitcoin" 

1bf3623924328b22e7b2ae1d7a9fd8bc2879d4cacabd9ba7e2fe0299fe26301e

• Install elements
• Wipe out sidechain data files
• Decide on node discovery ports and search methods (modify node seed list and ports in config)
• Set your sidechain name in config file (replace -chain=liquidv1 option with custom name)⁶
• Set your own n-of-m block signing method and set this config files ⁷
• Set your own n-of-m Peg-in script and set this in config file ⁸
• Set initialfreecoins to 0 in config file
• Set defaultpeggedassetname if you want it to be something other than bitcoin
• Set initialreissuancetokens to non-zero so you can issue default assets as peg-ins happen
• Provide config options to connect to BTC node to watch for pegins

• Liquid is a good testing ground for new OPCODEs being considered for inclusion into BTC. Liquid allows these changes to be real-world tested before they make it into BTC. For example many of the advanced OPCODEs that are argued for inclusion into BTC for Covenants / Vaults already exist in Liquid⁹. This transforms Liquid into being something of a "Beta-test" chain for BTC.
• Given the above, proponents of Covenants could use this to help make their case for inclusion into mainchain BTC. The current debate has stalled in a chicken-egg style standoff. One side is saying: Show us real world use-cases of this solving problems and the other responding we first need the OPCODEs to build these things. A potential solution is for Covenant proponents to go build their use-cases on Liquid.
• Could Fedimints / eCash mints find ways to utilize custom sidechains based on Elements as a way to prove to users that they are not debasing eCash tokens via Frac Reserve? (record eCash issuance as asset issuances on federated sidechain?)
• The community could spin up its own Federated version of Liquid!
• On Federation Trusting. The most hotly debated topic around Liquid is can we trust the Federation to not censure us? I think these are reasonable concerns (but largely overblown).
  • The group Liquid Members includes some of the most traditionally pro-Bitcoin groups.
  • Has there ever been a documented case of censorship in its 6+ year existence?
  • Given Confidential Transactions, it seems to be fairly trivial to bypass any censorship attempts. Remember, not even Federation Members can know what is being transacted, nor what is held in any individual address.
  • The more swap services like boltz / sidewap are used, the more pressure it places on the federation to keep behaving
  • If all else fails, the community can create their own version of Liquid