A Mobile and Generic Asset Exchange using Liquidity Pooling [group 2]

[devos50]

This ticket contains the notes for the liquidity pooling project (#5944)

A Mobile and Generic Asset Exchange using Liquidity Pooling

Ever since the introduction of Bitcoin, there has been a proliferation of blockchain-based currencies and applications. Nowadays, the majority of blockchain-based applications orient around decentralized finance (DeFi), an experimental form of finance that enables value transfer and exchange directly between participants, without intermediaries. The number of different DeFi application is quickly growing. Many of these DeFi applications are deployed using smart contract logic, e.g., on Ethereum.

Currently, decentralized exchanges (DEXes) make up a significant part of the DeFi landscape. DEXes enable the trade between different pairs of digital assets, without risks. Some DEXes facilitate trade by having traders create buy and sell orders and automatically execute orders when a trading opportunity arises. Newer DEXes like Uniswap use a different approach to trade assets. In this approach, there is a pool for every pair of assets, and users can deposit assets in these pools. Such users are called Liquidity Providers and are rewarded with special 'share' tokens. Traders can then exchange asset A for B by depositing asset A in the pool, in exchange for asset B.

Existing DEXes using liquidity pooling only allow the trade of assets that are locked to the ecosystem in which the DEX operates. For example, Uniswap can only exchange Ethereum-based assets, significantly limiting the applicability of this approach. Recently, we have introduced an approach to enable generic asset trading using traditional order books (we will share the paper with you at the start of the project). This approach enables the trade of any asset, managed by any ecosystem. Risks are manageable by splitting up a trade into a series of smaller, intermediate payments.

The goal of this project is to engineer a basic and generic DEX, based on Liquidity Pooling. All operations and asset transfers will be recorded on TrustChain, our lightweight distributed ledger. This approach makes it possible to detect fraudulent behavior, specifically stealing assets. You will integrate this application in our Superapp, which already has several decentralized applications integrated and deployed (e.g., for social networking, music streaming, and federated machine learning). Your final demo will show a simple asset exchange between two real cryptocurrencies, e.g., Bitcoin and Ethereum tokens. For simplicity, you may assume that the liquidity pool will be managed by a trusted identity in the network.

References:

• Introduction to liquidity pools: https://finematics.medium.com/how-do-liquidity-pools-work-defi-explained-6d3418ea71fa
• Generic info on DeFi: https://arxiv.org/pdf/2101.08778
• Attacks on DeFi: https://arxiv.org/pdf/2002.08099.pdf (have a look at Section III-A)
• Working of liquidity pools: https://uniswap.org/docs/v2/protocol-overview/how-uniswap-works
• Flash loans: https://arxiv.org/pdf/2003.03810

(image source: https://uniswap.org/docs/v2/protocol-overview/how-uniswap-works/)

[synctext]

Sprint ToDo ideas.

• Focus on reading and code
  • Liquidity pool collective: build upon DAO https://github.com/Tribler/trustchain-superapp/blob/7a958aec39b89b8a7015d508ef440553a0403788/currencyii/README.md
  • 1st task, get superapp code going
  • Creating a collective pool of any pair of tokens
• Liquidity is a long-studied field of science

[devos50]

Meeting notes 15-02-2021:

• Please communicate with the other group regarding the process
• Superapp has been compiled
• Some reading has been done
• First steps: look into multisig wallets, implement a few simple transactions to the multisig wallets using the superapp
• Possible extensions: modify the liquidity pool with decentralized voting

[chrislemaire]

@devos50 I created a PR to create the one module for our project.

[kchong97]

Some (possibly useful) links for basic reading:

• https://www.bitcoin.com/get-started/how-bitcoin-transactions-work/
• https://github.com/Tribler/trustchain-superapp/blob/master/musicdao/src/main/java/com/example/musicdao/wallet/WalletService.kt
• https://bitcoinj.org/working-with-the-wallet#marriedmulti-signature-wallets-and-pluggable-signers
• https://support.bitpay.com/hc/en-us/articles/360032618692-What-is-a-Multisignature-Multisig-or-Shared-Wallet-

[kchong97]

Notes for next meeting:

• bitcoin sender address possibly unknown or not trustworthy

  • This can be resolved by using trustchain as discussed during meetings:
    • If someone wants to trade with LP, store hash of transaction on trustchain
    • LP will confirm this and send it back to the correct person based on that information

• Think about how the wallet holders will sign the transactions, do they do it at a fixed time with some interval, etc.

Future things to look into later on in the project:
- Delayed transaction on trustchain
- Hijacking transaction on trustchain
- Excess coins should be send back

[vstam1]

Links for ethereum wallet:

• documentation about ethereum programming in java:
  https://ethereum.org/en/developers/docs/programming-languages/java/
• Java/android library for communicating with ethereum client:
  http://docs.web3j.io/latest/
• Ethereum remote/local client for connecting to ethereum network with web3j:
  https://infura.io/ (remote)
  https://geth.ethereum.org/ (local)
  https://www.parity.io/ (local)
• possible multisig ethereum wallets:
  https://github.com/Gnosis/MultiSigWallet
  https://ethereum.stackexchange.com/questions/40958/how-to-create-multisignature-transaction
  https://medium.com/@ChrisLundkvist/exploring-simpler-ethereum-multisig-contracts-b71020c19037

[vstam1]

@devos50 How could we get some euro tokens to play with?

[devos50]

Good question 😁 . @rwblokzijl or @xoriole could you answer/help with this?

[rwblokzijl]

The EuroToken system is currently closed. And since the system is collateralized with real euros, opening it up would expose me to all the laws and regulations that banks are subject to. We're looking into how to open the system up for scientific playing around after our trials, but the tokens would not have any value unless someone else picks up the project.

[devos50]

@rwblokzijl thanks for your response! Do you have some kind of testnet environment where we can mint EuroTokens without backing collateral?

[devos50]

Bitcoin added support for compilation with the Android NDK. Taproot implementation can be found here.

[devos50]

Meeting notes 01-03-2021:

• First version of GUI is made.
• Next sprint: focus on the liquidity pool primitives. For now, assume shared private key ownership (no multi-signature transactions), which removes (for now) the dependency on the other group. Create one wallet for BTC and one wallet for Eurotokens.
• Create a liquidity pool, be able to join it, and add money to it. Keep it simple. Joining a liquidity pool = transferring money.

[kchong97]

The current direction to work towards, the workflow for transferring eurotokens from a liquidity pool will work as follows:

1. A eurotoken wallet that acts as the eurotoken part of the liquidity will request signatures from all share holders of the pool when it wants to do a transaction (i.e. when a user wants to trade with the pool by sending it bitcoins and expects eurotokens back)
2. Once the wallet has enough signatures it will perform a transaction as usual with the transfer proposal blocks, but now with additional information about the signatures obtained.
3. The gateway which usually checks these transactions and creates the checkpoints will now additionally check for the obtained signatures and only create the checkpoint if the signatures obtained are enough.

[kchong97]

Current progress:
Created a new block type on trust chain that allows one to join a liquidity pool on the eurotoken side.
One device acts as the liquidity pool, with the list of pool owners that have joined this pool. The other device acts as a user who wants to join the pool.

Next step is to further work this out combining both sides of bitcoin and eurotoken into one workflow.

[kchong97]

Finished the complete flow of joining a liquidity pool. A user now goes to this screen and sends both bitcoin and eurotokens before they are allowed to send a join pool request. When the liquidity pool receives bitcoins/eurotokens they keep track of this on trustchain, for eurotokens this is done using the regular transfer blocks, for bitcoin an extra block is added to the chain.

When the pool receives a join request, this request is accompanied by two hashes, one for the eurotoken transaction and one for the bitcoin transaction. The liquidity pool will look for the blocks containing the corresponding hashes, if they are found the pool will agree on this join request, if they are not found the pool will reject it.

When testing this, note that it can take quite some time for the bitcoin side to get fully verified.

[kchong97]

Liquidity Pool

A liquidity pool is simulated using a single device that has both a bitcoin wallet and a eurotoken wallet. This pair of wallet will function as the pool, any user that wants to interact with the pool will need to have the pair of public key for this pool.

Join Pool

To join a liquidity pool a user needs to first provide liquidity. This is done by first transferring both eurotokens and bitcoins to the corresponding wallets of the liquidity pool. The hashes for both transactions will need to be remembered for the next step. The liquidity pool will handle a eurotoken transfer as usual, a bitcoin transaction will have an additional step, where the pool puts the hash and amount transferred on their own trustchain.

Once both transactions have been completed, the user can send a new proposal block to the pool using the public key of the pool's eurotoken wallet (i.e. their Ipv8 publickey). Once the pool receives this block, it will need to look up corresponding blocks containing these hashes. If found it can accept the request to join the liquidity pool, otherwise it will reject it.

Exchanging Funds

To trade with the liquidity pool, you need to first transfer some bitcoin/eurotokens and send trade proposal to the pool using the public key of the pool's eurotoken wallet (i.e. their Ipv8 publickey). This proposal block will include the hash of the transaction, the direction of the trade, as well as the address where you want to receive the exchanged funds. The liquidity pool will handle a eurotoken transfer as usual, a bitcoin transaction will have an additional step, where the pool puts the hash and amount transferred on their own trustchain. When the liquidity pool gets a trade proposal, they will look up the block with the corresponding hash in either the bitcoin/eurotoken blocks. If such a block is found, the pool will send an equivalent amount of funds of the opposite type to the address included in the proposal block.

As the liquidity pool can have multiple owners by this point, there should be some consensus before sending money from the pool. For this reason, the pool will need to collect signatures from the other pool owners. These signatures will then need to be checked by the gateway.

[synctext]

• Idea: multi-sig digital Euro
• temporarily put in central server gateway

[mmelas]

Finished the Trading part. (Not tested on physical devices yet)
Left device acts as the liquidity provider and right one as the trader. The first bitcoin wallet is the liquidity wallet.
After the trader choses a currency and an amount to trade, he presses convert and cannot trade until the transaction has been made. The process after the trader presses convert is :

• A bitcoin/eurotoken transaction is being made with the bitcoin/eurotoken liquidity wallet of the pool owner as the receiver
• After this transaction is finalized (i.e. (for bitcoin) included in the block of the best chain of the bitcoin network or (for eurotoken) the block of the eurotoken transaction has been verified by the receiver in the trustchain), he sends a TrustChain block with type eurotoken_trade, including some fields like the hash of the bitcoin/eurotoken transaction he sent, and the eurotoken/bitcoin address he'd like to receive the respective money from the pool.
• The liquidity owner receives a trade proposal and if he also has received the corresponding currency and if he has, he sends the corresponding amount back to the address that the sender specified. (We will implement the sending currency back to the trader this week).
• The trader is able to trade again

[devos50]

Meeting notes 22-03-2021:

• Eurotoken gateway up and running! Has hard dependency on Tikkie logic.
• The superapp would benefit from a single access point/interface logic, but this is more suitable for a later sprint.
• Problem for a future sprint: one can re-use the hash of a BTC/EuroToken transaction to join the pool, without actually transferring the funds. Possible solution: add a proof-of-ownership to the join request.
• Refactoring is another viable option, e.g., the TransactionRepository.

For next sprint: E2E demo of a BTC/EuroToken trade, if there are no unforeseen difficulties.

[chrislemaire]

We got a personal Eurotoken gateway up and running for testing purposes only.
The gateway in the centralized transaction verification, and money creation and burning server for Eurotoken. The test gateway will run during the rest of the project under this address on a cheap machine.

For this, we needed to create a stub bank implementation on the gateway so that it would correctly approve creation of money.
To create money for personal testing use, you can do the following:

1. [GW] Go to the Exchange page
2. [GW] Enter an amount in the first box and hit enter or the Convert button
3. [GW] No click "Connect to gateway"
4. [TC] In the app, remove all previous gateways under Eurotoken > Manage Gateways by holding the entry and tapping Delete.
5. [TC] Now go to the Exchange tab and click Scan qr code to scan the code in your browser
6. [TC] Make sure to save the gateway as your preferred gateway next and click "Connect"
7. [GW] Finally, in the gateway, click "Select payment method", then "Pay with Tikkie", then "Waiting for payment", and then "Payment complete"

[chrislemaire]

@devos50

So we've (me and @vstam1) looked into implementing multi-sig transactions for Eurotoken.
We found that it might be possible to add a multi signature transfer block to the Eurotoken gateway, but it would add no extra security if the gateway is unaware of the identities of the liquidity providers.
This means the liquidity pool owner would be able to make up a few signatures (from generated keypairs) and send them along with their transfer. So the element of trust in this interaction is solely placed on the liquidity pool owner.

Would it be alright to trust the liquidity pool owner with this task of collecting and checking signatures? If so, we will also not need to make a special transfer block and implement this on the gateway side, as we can keep using the old one, as we can do the signature check fully at the liquidity pool owner side. If not, we can come up with a proposal for how to do this securely inside the gateway but might very well not have the time to implement a working prototype.

[devos50]

it would add no extra security if the gateway is unaware of the identities of the liquidity providers.

What do you specifically mean by this? Does the gateway need to know the identities (public/private keypair) that are part of a particular liquidity pool? If so, that information is recorded on TrustChain upon joining a particular pool right?

[chrislemaire]

Yeah correct, it would need to know who is part of a particular pool-to-user transaction (which should be everyone that joined the pool before that transaction). The information should be available, but might be out of scope to retrieve on the gateway. We were thinking this would limit the genericness of a multi-sig implementation for eurotoken, making it only usable for liquidity pools.
Thus we didn't think the gateway would be the right place for it, instead opting to put that same responsibility in the superapp. If we do implement it on the gateway, it would shift the focus of the gateway and also only be the same check that already happens at the pool owner.

[devos50]

So the problem is that implementing the envisioned solution would create a hard dependency on the gateway, thus limiting genericness. This is not a very nice solution indeed.

Thus we didn't think the gateway would be the right place for it, instead opting to put that same responsibility in the superapp. If we do implement it on the gateway, it would shift the focus of the gateway and also only be the same check that already happens at the pool owner.

I agree. How much (additional) time would it cost to implement this functionality in a more generic way?

[chrislemaire]

Exactly! Yeah so this hard dependency is not preferred indeed.

An alternative, more generic approach might be possible, but we're having trouble coming up with a truly distributed solution.
One approach could be as follows: on the gateway, the following blocks are processed:

1. A transaction proposal block from the wallet owner with the public keys of those that can sign the transaction and the number that need to sign
2. Any number of signature blocks by the signers
3. A ready-to-send block or a verification block that the money is transferred once the n-out-of-m signatures.

In this solution the responsibilities are divided over wallet owner and gateway, but the wallet is not really owned by the n out of m people signing. Additionally, the wallet owner can then still come up with any number of people that need to sign or can sign.
I think this might not be enough for a true proof of concept of multi-sig transactions as it doesn't solve these essential problems.

An alternative approach would need to consider seriously rewriting Eurotoken to no longer be strongly bound by the one peer hardwired in IPV8. I am not sure how this would work out, but I don't think we will have enough time to fully explore the options there.

Do you have any suggestions from this?

[devos50]

I see. For now, I would target the easier (gateway-oriented) approach, even though it is not the optimal one. Document the limitations, shortcomings, and suggestions for further engineering efforts. This might be interesting content for a master thesis. At least then you have something to show at the end of the project.

I think this might not be enough for a true proof of concept of multi-sig transactions as it doesn't solve these essential problems.

We don't expect you to solve all identified problems; there are quite a few challenges left (e.g., security and economic ones). Building a fully functional, low-risk liquidity pool is challenging. As long as you can explain your design decisions, this is fine for me.

We can also discuss these matters further on Monday.

[kchong97]

Joining	Trading

EDIT: Fixed the gif

[kchong97]

Joining	Trading

The apk can be downloaded here (this is the last build also found in the aritfacts in the PR)

The readme can be found here

[synctext]

• it installs !!! 🎊 🎊 🎊 First team of class of 2021 which has running code in the wild.
• the wallet tab inside your liquidity pool needs to distinguish between nerd info: public key character and the vital info: how much money do I have
• Customer journey is still bit difficult. Hand-holding of the original developers is still handy. For instance, setting screen or config screen, confirmations, etc.
• the Digital Euro gateway connected to the IBAN financial system is modified for this liquidity pool
• please make your own gateway version the default and integrate a faucet (actual fake EuroTokens 👍)
• Readme is good to keep targeted at developers audience. ToDo: intro a bit more
  "context and positioning" (cross-chain liquidity pool {Thorchain,Centaur}), in intro describe the level of maturity, purity of decentralisation is there (despite the central owner, its is only a matter of engineering to support unbounded scalability in theory), elsewhere in readme mention issues {multi-sig, reliable messaging with re-transmissions, limit to single trustchain, no shared ownership trustchain}, etc.

[devos50]

Besides the stuff we already discussed in the meeting today, I have the following comments:

• Feel free to refer the reader to other material for a more extensive overview of liquidity pools/AMMs - e.g., this paper, section III-A.
• The application seems to consists of four and not three screens.
• Suggestion: rename “Main Flow” to “Main User Story” (“main flow” is ambiguous)
• Can you remove the black borders around the gifs?
• Small detail: you talk about step 2 and 3 but you are using a bullet list for the steps the user has to perform. You can better use a numbered list for that.
• For clarity, you might want to draw TrustChain as a separate component (even though the Eurotoken mechanism is critically dependent on TrustChain).
• Please briefly describe the function of each of the listed packages and files.
• typo: mutlisignature -> multisignature
• Can you be a bit more specific on how you can implement the future work?
• I would swap the sections ‘known issues and limitations’ and ‘future work’ (future work usually comes last).

[kchong97]

apk
readme

[synctext]

"Hacky spaghetti" level of code in Superapp. At least it did not get worse with this pending PR

[devos50]

Congratulations on passing the course 🎉 . Please finish the PR 👍

Final deliverables:

• Liquidity pool PR
• APK
• README.md

[xoriole]

Tribler/trustchain-superapp#75 PR is merged, closing the issue