Intro
Liquidity maps, or heat maps, are well-known financial instruments that help to make justified trade decisions or show the current state of the market. As a result, they provide better risk parameter management. There is not a huge problem in building it in a centralized manner for the crypto market, but creating a trustless and on-chain available data source appears a bit challenging. Let us share the vision about how it’s possible to build.
Core items
To build a liquidity map for each asset pair, we need to understand how much liquidity is available for the exact price. Historically, we can identify two slightly different approaches to obtain this data through AMM DEXs, before and after Uniswap V3.
In earlier versions of Uniswap, we just needed to obtain liquidity from a specific pool and apply AMM mathematics to calculate price changes. By concatenating similar pools, we could build the liquidity map for the asset pair.
In Uniswap V3/V4, the liquidity in one pool is split by ticks, where one tick defines the exact liquidity for a specific price. In such cases, we need to concatenate all ticks in similar pools to build the liquidity map for the asset pair.
Looking ahead, we need to have zk circuits that will prove the storage of the liquidity for each tick or pool and execute some AMM mathematics to prove the correctness of output data, or in simpler terms, a liquidity map for an asset pair.
The attentive reader may object that there are other protocols with liquidity. Indeed, they exist, and the data from them will be added later. Luckily, the approach to obtaining liquidity will be almost the same.
Smart Contract Read vs ZK Power
Here, we are going to provide a raw comparison between two approaches from a cost perspective.
Smart Contract Read
Just imagine that we want to obtain WETH/USDT 5% pool data, and the execution will be carried out by setting up an immutable smart contract that will interrogate each tick and execute the final calculation. This process requires iterating over approximately 27 ticks, and the whole function call will cost approximately 179,219 gas.
179,219 gas * 25 gwei * of $3,500 = $15.62 USD
For the same pool in Uniswap V2, it costs 6,059 gas.
6,059 gas * 25 gwei * $3500 = $0.53 USD
Let’s add the same for a Curve pool: It takes 119,184 gas.
119,184 gas * 25gewi * $3500 = $10.43 USD.
Finally, to obtain data for the liquidity map for WETH/USDT for Uniswap V2/V3 plus Curve with the help of an immutable smart contract, we would need to pay a total of $26.58 USD.
Zero-Knowledge Proof Aggregation
To perform all calculations, we’ll use the same data sources, like the WETH/USDT Uniswap V2/V3 pools and the same Curve pool. In total, we need to generate 32 storage proofs, which are as follows:
- 27 ticks for UniV3,
- 3 slots for TickBitmap,
- 1 slot for Curve, and
- 1 slot for UniV2.
As savvy individuals, we aim to concatenate all storage proofs into one and submit and verify only one. In such a case, we need to use recursion for this process. Although it may take more time, this off-chain operation can dramatically reduce costs.
The 32 storage proofs can be split into 5 layers of recursion, with the generation of 1 storage proof taking approximately 2 minutes:
- Layer 0: 32 proofs = 64 minutes,
- Layer 1: 16 proofs = 32 minutes,
- Layer 2: 8 proofs = 16 minutes,
- Layer 3: 4 proofs = 8 minutes,
- Layer 4: 2 proofs = 4 minutes,
- Layer 5: 1 proof = 2 minutes.
Additionally, we can allocate 10 minutes for arithmetic calculations based on tick values.
This leads to a total computation time of 136 minutes. The proof readiness time is estimated to be between 10-20 minutes.
With a server cost of $105/month, which equates to $0.15/hour, the final computation cost comes to $0.4 USD per WETH/USDT UniV2/V3 and Curve.
To get the full vision here, we need to add verification costs, which lie in the range of 300,000 to 500,000 gas for one proof, roughly amounting to $43.75 USD. However, we can concatenate 1000 pools in one proof and split the verification cost to reduce it to $0.04 USD per pool.
So, theoretically, with $50, we can build and verify the liquidity maps for the entire DeFi market.
Protocol it!
Finally, we’ll have a public smart contract with proved liquidity map data for each pool a client wants to request. The direct costs here are:
- A Relayer that collects and stores raw data.
- Off-chain proof building.
- On-chain verification cost.
- Proved data on-chain storage.
Initially, we can implement a Pay-Per-Request logic, where clients can split the costs before a call. The first clients could be auto-trading bots ,low-risk asset management protocols or risk parameters management products that would like to rely on the DeFi data.
Proof building can be delegated to centralized or decentralized structures, like a Proof Market, where each proof could be rewarded.
Finally, the Relayer should transport the proof and submit it on-chain, with costs covered or compensated by the clients.
In that model, the Protocol will resemble a marketplace where there are clients ready to pay for the data, and workers processing the data. The good news here is that we don’t need any mechanism to track and punish voluntary actors because, by design, any wrong data will not pass the zk-proof verification, ensuring clients’ safety.
We’ll be happy to describe the full protocol in the future, but for the current post, this is enough.
Summary
DeFi can trust in itself!
Trustless, aggregated, proven public Liquidity Maps remove centralized dependencies and can serve as a foundation for the automation of low-risk trading strategies. They enhance risk management and, ultimately, will be cost-effective!
written by Vadim Makovsky and Maxim Manylov