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

[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 12-02-2021:

• Started reading the literature on liquidity pools + low-risk asset trading
• Keep the economic primitive simple, e.g., the bounding curve
• Superapp source code: https://github.com/Tribler/trustchain-superapp. For next meeting, please have a look at the superapp, setup your development environment, and compile the source code.
• Please coordinate with the other group to minimize the number of conflicts when developing your solution.
• A potential approach is to use multisignature wallets to collectively manage money.
• For testing purposes, you can use testnet transactions.

[thversfelt]

TODO for monday 15-02-2020, 09:00:

• Explore, read literature
• Setup development environment
• Compile SuperApp source code

[daandeheij]

Useful short introduction to Bitcoin blockchain: https://www.youtube.com/watch?v=Lx9zgZCMqXE

[thversfelt]

Compilation instructions:

• Install Android Studio
• Clone https://github.com/Tribler/trustchain-superapp
• In the cloned trustchain-superapp folder, clone https://github.com/Tribler/kotlin-ipv8
• Open trustchain-superapp folder in Android Studio
• Sync project with gradle files
• Run

[devos50]

To get a feeling for how liquidity pools work, you can play a bit around on the Uniswap website.

[daandeheij]

Short detailed paper on Constant Market Maker model implementation:

[thversfelt]

Possible solution: modified luxury communism to incorporate an additional wallet on a different blockchain (not BTC)

[daandeheij]

Possible solution: modified luxury communism to incorporate an additional wallet on a different blockchain (not BTC)

Also:

• modify luxury communism in order for traders to propose exchanges with the liquidity pool
• change entry fee logic to liquidity pool entry logic (record proportion of assests added)
• create logic for liquidity providers exiting liquidity pool and retrieving funds

[thversfelt]

Possible solution: modified luxury communism to incorporate an additional wallet on a different blockchain (not BTC)

Also:

* modify luxury communism in order for traders to propose exchanges with the liquidity pool

* change entry fee logic to liquidity pool entry logic (record proportion of assests added)

* create logic for liquidity providers exiting liquidity pool and retrieving funds

Another idea:

• Automate accepting trades based on liquidity pool logic, so liquidity providers dont have to manually sign each transaction

[daandeheij]

Work done 17-02-2021:

• Duplicated currencyii (luxury-communism) application, and renamed/refactored to liquiditypool
• Trying to make liquiditypool working
• Currently, liquiditypool doesn't start due to bug with CoinCommunity

Questions that came up during work meeting:

• Can we branch on the repo? Or should we fork the repo, and work there?

Code meeting planned for 18-02-2021 (9:30):

• Fix CoinCommunity bug
• Potentially create new empty application not based upon currencyii

[daandeheij]

Work 18-02-2021:

• Forked trustchain superapp: Fork
• Replaced coincommunity by poolcommunity
• Renamed nav_graph to nav_graph_poolcommunity as conflict was causing crash at startup
• Debugging currencyii to get a feel for architecture

[devos50]

Meeting notes 19-02-2021:

• Integration with Luxury Communism app possible, good find!
• Please focus on re-using components instead of copying the full sub-app into a new one.
• Please make PRs to make changes to the luxury communism app.
• Currently, the luxury communism app only supports BTC wallets. We would like to make this more generic to enable universality.

Focus of this sprint: enable universal support for different crypto wallets in the luxury communism app. Prepare the fundamental interfaces for your liquidity pool ideas and give a small code demo next week.

[thversfelt]

Progress:

• Attempted to work on PRs of Luxury Communism
• Looked into Music DAO
• Started an app from scratch
• Worked on interfaces for a shared wallet and coins
• Created a GUI to demonstrate vision of the liquidity pool app

[devos50]

Meeting notes 25-02-2021:

• Please weekly post a progress update + screenshot on your GitHub issue
• Setup a shared meeting with the other group to synchronize and to exchange ideas
• Trouble to get the luxury communism up and running; the app is not designed for genericness
  • Bitcoin is deeply integrated
• Group started from scratch with their own proof-of-concept

Next sprint:

• Dive into the luxury communism code, get familiar with the code.
• Get a Bitcoin testnet transaction up and running, using the Luxury communism app.
• Work towards a first BTC/BTC liquidity pool; required operations: make liquidity pool and add tokens to the pool.

[devos50]

Idea for next sprint: get taproot (multi-)signatures operational in Kotlin code (also see #5984). To achieve this, you have to compile the Bitcoin reference implementation for Android.

[thversfelt]

Progress update 02/03/2021:

• Had meeting with group 2 last friday, discussed liquidity pool app vision and shared progress and ideas.
• Unable to import currencii (Luxury Communism) into liquidity pool app, unable to figure out why
• Joined fork of group 2, which is working on the front-end
• Created a fragment (on a seperate branch) for testing/debugging back-end logic
• Started creating a demo on REGNET, with 2 liquidity providers and a single multi-sig wallet
• Creating BTC multi-sig wallet works
• Adding funds to the multi-sig wallet works
• Now working on retrieving funds from multi-sig wallet (requiring 2/2 liquidity providers to sign the transaction)

[thversfelt]

Progress update 03/03/2021:

• Creating a redeem transaction from the multi-sig wallet works
• Signing the transaction by 2/2 liquidity provider works
• Created demo

Demo:
There are two providers, who create personal BTC wallets as well as a multi-sig wallet requiring 2/2 signatures to redeem from. First, provider 1 creates a 0.02 BTC provide transaction to the multi-sig wallet. Then, provider 2 creates a 0.01 BTC redeem transaction and signs it with his own key. Provider 1 signs the redeem transaction with his own key, and finally provider 2 broadcasts the transaction to receive the 0.01 BTC from the multi-sig wallet.

Note: the demo is run on a single client on BTC REGNET with artificial delays and free funds from a BTC faucet. Next step might be to explore using trustchain for communicating multi-sig wallet addresses, as well as provide/redeem transaction info. That way it can be more easily tested on multiple clients using TESTNET. As requested, we should also be working on getting currencii (Luxury Communism) to perform what is currently implemented, as to avoid code duplication. It was preferable for now to get a hang of programming a bare minimum implemtation of a multi-sig wallet, in order to better understand currencii's implementation.

[devos50]

Next sprint:

• Full focus on supporting Schnorr (Taproot) multi-signatures on Android
• First step: compile the Bitcoin source code for Android
• Second step: build a Taproot-compatible Bitcoin transaction

Technical specifications can be found here.

[thversfelt]

Taproot implementation idea:

• Possibly custom transaction in bitcoinJ using taproot (since there is no support for it yet)
• Try to create a valid taproot multi-sig transaction and send it into the network

[daandeheij]

Update on geth integration:

On branch geth-server, web3j now connects to Rinkeby network using (independent) geth node.

Instructions:

• run geth on windows/linux
• on server run ./geth.exe --rinkeby --syncmode "light" --rpc --rpcapi "eth, net, web3,personal" --ws --ws.origins="*" --ws.api "web3, eth, net, personal" --ws.addr "<ip>". Replace <ip> by your local ip. This will run a light Rinkeby geth node, that accepts rpc over a websocket (ws) connection
• Also replace your local ip in liquiditypool. Note that 10.0.2.2 should also work when using the emulator, as this will link to the emulator's host.

Work for next week

The method web3j.ethGetBalance is not working yet with this geth node. Perhaps some api options are currently missing.

[thversfelt]

Hey guys, I found a really useful guide for implementing Geth on Android with deploying smart contracts: https://freesoft.dev/program/108526336

It shows how to:

• Setup and run geth on Android (which we already could)
• Deploy a smart contract using "Geth.deployContract(...)", which is exactly what we have been stuck on for the last week.

Will try getting this to work, but it looks very promising.

[devos50]

Meeting notes 06-04-2021:

• BTC multiwig wallets are implemented in the code of group 2
• Refactored code of group 2
• Validating BTC transactions need context
• Working on Geth - hopefully that will work by tomorrow
• Please document the difficulties when getting mobile geth up and running
• Unit tests

Deliverables for next week Friday:

• README.md, including limitations, approaches, generic project overview etc.
• A pull request on the main repository with your code
• An E2E demo

[daandeheij]

Progress update yesterday and today (07/04/2021):

This is a joint write-up of Daan and @thversfelt

Work done:

• Implemented creating accounts on Geth Android by importing existing keys.
• Funded the two accounts with 3 Ether each, using a faucet
• Implemented deploying of smart contracts, including our Multi-Sig contract, using Geth.

What problem we have run into now:

Locally, transactions and contract deployments are successful. However, they don't seem to be broadcasted to the Etherereum (Rinkeby) network. We have about 4 connected peers at any given time. Locally, we have an instance of our contract, and the geth node also confirms that the contract has been deployed (including hashes). However, because there is no bound contract (to the contract's address), we can't interact with the (multisignature) contract.

What we tried:

• Opening in/outbound TCP/UDP port 30303, did not fix the problem
• Instead of running Geth on android, running Geth on windows (light mode) and connecting to it through Android: not broadcasting our contract.
• Running on different systems (desktop/laptop)
• Clearing emulator cache

Possible causes:

• It seems like peers are not receiving/are rejecting our broadcasts.

Likely no causes (because we debugged):

• Invalid contract definition
• Too low gas price/limit
• Incorrect transaction nonce
• Incorrect transaction signature
• Not enough Ether balance
• Synchronization (time) issue

What may be worth trying:

• Running a Geth fast or full node and connecting to it through Android. However, this would not be a solution, since the goal is to have a functioning Geth node running on Android as to avoid centralized.
• ..?

Perhaps @devos50 would like to look into this problem. Any help would be greatly appreciated. Please see this commit

[devos50]

@daandeheij That's very unexpected. Are you sure that the light node has fully catched up with the network (also see this SO post)? Also, are you sure that broadcasting is part of the deploy_contract function? It might be a separate method.

Instead of running Geth on android, running Geth on windows (light mode) and connecting to it through Android: not broadcasting our contract.

Is the Windows light node not broadcasting the contract or are you not seeing it on the Android side?

As a last resort, please try to run a full node and see if you can issue your transaction successfully. This should be a small configuration change right?

[devos50]

Also, you might want to join the Ethereum discord/IRC channel and ask their help 👍

[daandeheij]

I just came across an interesting post on stackexchange. The user states that he used to be able to broadcast transactions successfully using a light node previously, but that lately his transactions aren't broadcasted anymore.

I will follow that post closely. Hopefully there will be some answers to it. In the meantime, I will first run a full node on my laptop to see whether it works there. That would confirm that our code is working, and would rule out a bug there.

Edit: Right now I'm running a Geth node on Windows with syncmode=fast. It's syncing right now, and it's almost at age=1y. Hopefully it finishes synchronization tonight!

[daandeheij]

08-04-2021

• Quicker builds: Temporarily removed the need to build other projects. Reduces build time considerably, which will be useful when debugging liquidity pool.
• UI: Getting liquidity pool UI ready for integration
• In progress..

Current problem

• Quicker build causes ipv8 problem. Now causes bitcoinj to not find any peers

[daandeheij]

Just now spend some more hours on seeing what's going wrong with Geth. Right now I made a ethereumClient connected to infura. But even then, I cannot manage to send a transaction. I really don't understand what's up. I checked the nonce, checked every parameter, debugged it for hours.

[thversfelt]

Update (11/04/2021):

• I managed to (briefly) have a pending smart contract deployment transaction on Rinkeby testnet using Geth on Android.
• Created a UI for our demo and added all respective wallet classes:
  • bitcoin (personal/multi-sig)
  • ethereum (personal/multi-sig)

EDIT: See below, a screenshot of the pending smart contract deployment on etherscan

[devos50]

Nice progress! Has the smart contract been deployed already?

[thversfelt]

The smart contract hasn't been deployed yet, nor is it pending anymore. It has disappeared from etherscan, which is puzzling. I also can't find it anywhere else. When trying to deploy other instances, it only briefly appears on etherscan. The same holds for transactions to other addresses.

As far as transaction validity, everything seems to be correct. However, it appears that the network keeps rejecting our transactions for some reason. Perhaps a consensus issue. Occasionally I do get peers that have blocks in the future, so their connection gets dropped. However, that often happens right after submitting a transaction. But still, there are 4 or 5 peers connected any time, so I don't see how that can become an issue as long as the other peers are propagating our transactions.

Here is the above pending contract on etherscan:

Then, after a page refresh, it is gone....

[devos50]

Hmm ok. Then the transaction seems to have been dropped from the mempool. Your gas price seems rather low though, is this competitive with transactions that actually make it into the blockchain?

But still, there are 4 or 5 peers connected any time, so I don't see how that can become an issue as long as the other peers are propagating our transactions.

I'm not sure if these peers are actively propagating your transactions but at least the Etherscan nodes have received your transaction so I would assume so.

[thversfelt]

Your gas price seems rather low though, is this competitive with transactions that actually make it into the blockchain?

The gas price for rinkeby is 1 GWEI, take a look at this recently confirmed transaction (by someone else): https://rinkeby.etherscan.io/tx/0x25c8015c6165021d5fadda4c8011c7a91f1e26dc7ba681dceb184a9ae690380e

Our gas limit is 1,000,000 so that should be plenty to cover mining. So I don't think it is a mining/gas issue.

[devos50]

Meeting notes 12-04-2021:

• Still problems with Android geth transactions - transactions are not executed and dropped.
• Please add the contract specifications to the README.md.

Final E2E demo: BTC-ETH cross-chain liquidity pool.

Please upload the APK a day before the final demo!

[thversfelt]

I couldn't let go of geth, so I tried a couple more things. Ended up switching between a couple of testnets and finally settled on Goerli. Submitted a contract creation, which at first seemed like the same thing was happening as when we were on Rinkeby. Well... after taking a 15 min break, contemplating life choices, I returned to my computer to see the contract still pending.. then after a couple more minutes it was confirmed!! https://goerli.etherscan.io/tx/0x69cbe46ca555eeaed1842240c85cb2fbaa0579324037d5fd2479957e88c0b60d

In other words, we managed to successfully deploy a smart contract on the Goerli ethereum testnet using a Geth light node 😍

Smooth sailing from now on, right? haha..

[devos50]

Nice progress! I noticed that this is on another testnet network, could that be a reason why transactions were failing?

[daandeheij]

Nice progress! I noticed that this is on another testnet network, could that be a reason why transactions were failing?

Yes indeed. As a last resort, we tried to use a different testnet. The code we used for this deployment on Goerli is the same as the one for Rinkeby (besides the chain ids of course). So it seems to have been a problem with the combination of Geth and Rinkeby.

[thversfelt]

Update (16-04-2021)

• After a long week and a lot of hard work, we have finished our demo.
• We managed to get Ethereum multi-sig wallets to work, but confirmations of pending transactions to and from it can take up to 3 hours in a testnet. Therefore, we have decided to implement the ethereum side of the pool using web3j with infura.
• Even then, it can take a long time (> 10 mins) for ethereum transactions to appear in the demo app,
• All in all, we managed to implement a liquidity pool using bitcoin multi-sig contracts and a ethereum multi-sig smart contract that can be deployed using a Geth light node, on Android. The demo is a subset of the implemented features.
• Emiel will upload the demo apk as an attachment to a comment on this issue,

[daandeheij]

See https://goerli.etherscan.io/tx/0x987b0312efe42473c2b86c0e524160eeac4aba52929af66c6a619b49b7e5dbd1 for an example of a interaction with the multi-signature Ethereum wallet

[EmielBoss]

• Updated APK, with QoL improvements and bug fixes.
• README.md
• Pull request of Group 2, with our commit merged into it

[synctext]

• impressive task is operational
• knowledgeable team about coin, code and blockchain
• @xoriole hopefully this PR gets through
• ToDo: PR done and a .GIF for explaning your work would be cool 🎊

[thversfelt]

ToDo: PR done and a .GIF for explaning your work would be cool 🎊

The PR work is underway, and here is a .GIF of liquid swap (our work) in action:

Cheers! Have a good weekend.

[xoriole]

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