Discussed the various application scenarios of ZK technology to achieve privacy protection in DeFi, especially its potential in resisting front-running transactions, liquidity manipulation and lending.
Written by: Salus
Decentralized Finance (DeFi) is an important development direction in the current field of financial innovation. In DeFi, hiding transaction information and maintaining user privacy are crucial. As DeFi continues to expand and deepen, various projects emerge in endlessly and are full of vitality. The application of zero-knowledge proof (ZK) technology has opened up new possibilities for privacy protection in DeFi. ZK technology allows one party to prove to another party that they know a piece of information without revealing any specific details about that information. The application of this technology in DeFi projects such as ZigZag, unyfy and OKX’s ZK DEX has greatly enhanced the privacy protection capabilities of DeFi, especially the protection of transaction information. It is foreseeable that the widespread application of ZK technology will bring about innovations in the way DeFi and the entire cryptocurrency field are handled, promote the future development of the entire field, and achieve major breakthroughs.
There are no secrets on the blockchain, and DeFi’s data transparency is undisputed. Taking a transaction on Uniswap V3 as an example, we can easily view the transaction details through the Etherescan website (as shown in Figure 1). For example, the address 0x3A4D…a6f2 exchanged 2 WETH for 17,654,123,249,375 Bonk on Uniswap V3, and the transaction fee was 0.0046 Ether. Key information such as the sender (From), receiver (To), transaction amount (Value), and transaction fee (Transaction Fee) in these transactions are all publicly available.

Figure 1 Transaction details disclosed on etherescan
We can also view all transaction records under the 0x3A4D…a6f2 address (as shown in Figure 2). If conditions permit, we can also deduce the true identity of this address in the real world.

Figure 2 The list of all transactions for a specific address is public on etherescan
However, DeFi’s data transparency may have some downsides. If you are a DeFi whale, each of your transactions may attract market attention. For example, when a whale withdraws 11.24 million WOO (approximately US$4.2 million) from Binance, this transaction will attract attention. extensive attention. Similarly, any large-value payments or institutional-level transactions may also trigger widespread public concern.
Other market participants may make buying and selling decisions based on these trading behaviors, which may adversely affect your investment strategy. For example, you invest a large amount of money in a certain project, but once your transaction is noticed by the market, other investors may follow suit, causing asset prices to rise, thereby increasing your investment costs. In addition, your selling operation may also trigger market panic, causing prices to fall and affecting your investment returns.
This situation highlights the urgent need for privacy protection among DeFi projects and users. If we do not want our transaction details to be known to the public, we can choose to keep certain information about DeFi transactions private.
ZK technology can ensure the legitimacy of transactions while hiding transaction details. Users need to submit two types of information: one is a transaction that partially hides details (such as transaction recipient or amount) (that is, a private transaction), and the other is a ZK certificate about these hidden information. Verifying the legitimacy of a private transaction is actually verifying the corresponding ZK certificate.
Suppose you are lucky enough to learn that a large company is about to purchase a large amount of a certain asset. You may choose to purchase this asset before the company does. Then, when heavy buying of that company drives up the price of the asset, you sell it for a profit. In this case, your trade before the big players constitute a front-running trade.
Front-running is an investment strategy in financial trading that usually occurs on exchanges, such as Uniswap. This is because transactions in the blockchain are public and transaction confirmation takes a certain amount of time. Therefore, some malicious traders may increase the transaction gas fee to allow their transactions to be mined and confirmed before other people’s transactions, in order to achieve the purpose of front-running transactions.
Front-running trades can cause harm to other traders because it changes the original trading environment so that other traders’ trades may not proceed as originally planned. On the other hand, attackers initiate front-running transactions to make profits for themselves. They can make profits before the price changes. Therefore, many DeFi projects are also trying to prevent front-running transactions through various methods.
ZK technology can play a key role in combating front-running trades. Below, we take the sandwich attack in Decentralized Exchange (DEX) as an example. This is also a common type of front-running transaction for case analysis.
What is a sandwich attack?
Assume that on a DEX, there is a liquidity pool with a reserve status of 100 ETH / 300,000 USDT. Alice initiates a transaction to purchase USDT, exchanging 20 ETH for USDT. When she submits the transaction, the DEX will return a result based on the current reserve status of the liquidity pool, telling Alice that she can buy approximately 50,000 USDT. But in fact, Alice only got 45,714 USDT in the end.
Here, let’s first briefly understand why Alice can purchase 50,000 USDT with 20 ETH. This DEX adopts the Automated Market Maker (AMM) model and automatically calculates the buying and selling price through the Constant Product Market Maker (CPMM) algorithm. CPMM is a currently popular automated market maker algorithm that maintains a constant product of two assets in the trading pool to achieve liquidity supply and automatically adjust asset prices. In this example, the amount of USDT that Alice can buy is calculated through the formula 50,000=300,000-(100*300,000)/(100+20) (assuming there is no handling fee).
Alice did not buy the expected amount of USDT because she suffered a sandwich attack.
Sandwich attacks mainly occur in AMM-based DEXs. In a sandwich attack, the attacker places two transactions around the victim’s regular transactions to manipulate asset prices and profit from the victim’s losses. These two transactions are front-running transactions and follow-up transactions respectively. The transaction before the regular transaction is called the front-running transaction, and the transaction after the regular transaction is called the follow-up transaction.
So, how did Alice’s sandwich attack work? As shown in Figure 3.

Figure 3 Sandwich attack process
The attacker’s preemptive transaction: Before the transaction initiated by Alice to purchase USDT was executed, the attacker also initiated a transaction to purchase USDT (preemptive transaction), that is, exchanging 5 ETH for USDT. Moreover, the gas fee paid by the attacker to the miner for this transaction is higher than that of Alice, so the attacker’s transaction will be executed before Alice.
After the attacker’s transaction to purchase USDT was executed, he got approximately 14,286 USDT from the liquidity pool, 14,286≈300,000-(100*300,000)/(100+5). The reserve of the liquidity pool changed from the initial state of 100 ETH / 300,000 USDT to 105 ETH / 285,714 USDT. However, Alice does not know that the reserve status of the liquidity pool has changed between the time she submits the transaction and the time her transaction is executed.
Victim’s regular transaction: Alice’s regular transaction is then executed.
After Alice’s transaction to purchase USDT was executed, she received 45,714 USDT from the liquidity pool (according to the constant product function, 45,714≈285,714-(105*285,714)/(105+20)). The liquidity reserve status changed from 105 ETH / 285,714 USDT to 125 ETH / 240,000 USDT. Therefore, Alice should have been able to buy 50,000 USDT with 20 ETH, but now she can only buy 45,714 USDT due to changes in the liquidity pool caused by the attacker’s transaction. Alice lost approximately 4286 USDT (4286=50,000-45,714).
The attacker’s follow-up transaction: Finally, the attacker initiated a transaction (follow-up transaction) again, that is, exchanging 14,286 USDT for ETH (this 14,286 USDT was bought just now).
After the attacker’s follow-up transaction was executed, he took out 7 ETH from the liquidity pool (definite product function, 7≈125-(125*240,000)/(240,000+14,286)). The reserve status of the liquidity pool changed from 125 ETH / 240,000 USDT to 118 ETH / 254,286 USDT. Therefore, the attacker only spent 5 ETH at the beginning, but finally got 7 ETH and gained 2 ETH (2=7-5).
During the entire sandwich attack process, the attacker initiated a total of two transactions, namely a front-running transaction and a follow-up transaction. The front-running transaction caused Alice to lose approximately 4286 USDT. The combination of front-running and follow-up transactions made the attacker profit 2 ETH.
In DEXs, the publicity of transactions is a key factor leading to the emergence of sandwich attacks, especially in AMM protocols. These protocols make real-time transaction information on DEXs public. This high transparency provides attackers with the possibility to observe and analyze transaction flows in order to find opportunities to carry out sandwich attacks.
The application of ZK technology can significantly reduce the possibility of sandwich attacks. By using ZK technology to hide transaction volume, asset types, user or liquidity pool balances, user identities, transaction instructions and other protocol-related information, the privacy of transaction data can be effectively improved. As a result, it is difficult for the attacker to obtain complete transaction information, making it more difficult to implement a sandwich attack.
In addition, ZK technology can not only resist sandwich attacks, but ZK-based private transactions can also increase the difficulty of judging user behavior models. Any third party that attempts to collect blockchain data to analyze account historical transactions, infer behavioral patterns, explore activity cycles, transaction frequencies or preferences, etc., will face challenges. This kind of analysis, known as behavioral model inference, not only violates user privacy, but can also pave the way for honeypot attacks and phishing scams.
Liquidity manipulation and front-running trading are both attack methods in DeFi. Both attack methods involve using market information and transaction speed to obtain benefits, but their specific strategies and operation methods are different.
Front-running is taking advantage of information, while liquidity manipulation is taking advantage of market activity to mislead other traders. The former mainly makes profits by obtaining and using undisclosed important information, while the latter misleads other investors by creating false market activity, causing them to make unfavorable trading decisions.
ZK technology can not only play a key role in resisting front-running trades, it can also help prevent liquidity manipulation.
Suppose you are buying apples in a busy fruit market. Market prices typically fluctuate based on changes in supply and demand. You usually watch prices over a period of time and then decide whether to buy based on the average price. Now imagine that a very wealthy buyer enters the market and he really wants to buy apples. He started buying apples in large quantities, regardless of the price. This will cause Apple’s price to skyrocket in a short period of time. If you still buy Apple based on this price, you’re probably paying more than it’s actually worth.
This example can better understand the working principle of the TWAP (Time-Weighted Average Price) oracle and the concept of liquidity manipulation. The act of deciding to buy apples based on the average price is similar to the operation of the TWAP oracle. The purchase of apples by wealthy businessmen in large quantities causing prices to rise is similar to liquidity manipulation.
The TWAP oracle determines asset prices by calculating the average transaction price over a period of time. The more recent the transaction, the greater the impact on the average price. If someone makes a large number of transactions or trades with a large amount of money in a short period of time, which may significantly affect the average price of an asset, this is liquidity manipulation. Liquidity manipulation can artificially raise or lower asset prices, resulting in inaccurate price information. If someone wants to use the TWAP oracle to deliberately increase the price of an asset, he can use a large amount of money to purchase the asset in the short term, causing the price to rise temporarily. If the asset price increases significantly during this time window, the TWAP oracle may treat this higher price as the asset price.
Liquidity manipulation of TWAP oracles can have a significant impact on DeFi protocols, especially emerging tokens with low liquidity. These DeFi protocols usually make financial decisions, such as liquidation, lending, etc., based on the price of the asset. If price information is inaccurate or unreliable, it may lead to wrong decisions, thereby causing losses to users. Therefore, it is crucial to protect TWAP oracles from liquidity manipulation.
Based on ZK technology, it can resist liquidity manipulation in the TWAP oracle. A smart contract can be designed to rely on the TWAP oracle to obtain asset prices. If an attacker performs liquidity manipulation, the price obtained from the TWAP oracle may exceed the preset acceptable range. In this case, the contract will temporarily stop its operations. It will then recalculate and confirm the asset price based on ZK technology.
To use ZK technology to calculate asset prices, you first need to add a wrapper contract to the TWAP oracle. The contract can directly access N price reports, or record N checkpoint values of the price at arbitrary intervals. Once N data points are available within a given interval, a ZK proof can be constructed to prove the median of the unsorted array of prices. The unsorted price array is labeled as a column vector x, of length N. The following is the process of calculating asset prices based on ZK technology:
The proof can be verified in either of two ways, in either case the prover cannot arbitrarily choose an array of prices as input.
There is an N x N matrix A (square matrix). When the matrix is multiplied by the column vector x, a column vector y is generated such that y=Ax. A is an invertible permutation matrix, but since there may be duplicate price values, A is not necessarily unique, and A contains only binary values.
The values in y are ordered, that is, yiyi+1 i 0…N-1. Again, < cannot be used because there may be duplicate price values.
The circuit’s public output m is the median vaue of y. The proof shows that y⌊N/2⌋=m, where N is a static value when the circuit is compiled and must be an odd number.
According to the above process, a median price m is output based on ZK technology, which is tamper-proof. The median m can prevent liquidity manipulation to a certain extent. In order to achieve this, we need to limit the value of y so that in each block, the value of y is only inserted once, or the number of insertions is within an acceptable number. within the range.
As mentioned above, ZK technology is able to resist front-running and liquidity manipulation in DEXs. So, can we further explore the application possibilities of ZK technology in other DeFi scenarios? For example, ZK technology can also play a key role in lending, an important component of DeFi projects.
On traditional lending platforms, the loan application process usually covers five steps: application, credit assessment, loan approval, loan issuance and repayment. Among them, the credit evaluation link is particularly important. Borrowers must prove that their income meets the standard and they have the ability to repay. During the evaluation process, the platform will conduct an in-depth investigation of the borrower’s credit history, including income, liabilities, and past repayment records, to ensure that the borrower has the ability to repay the loan. Only on this basis will the platform consider approving the loan application.
However, when you turn to DeFi lending platforms such as Aave or Compound, the situation changes. Due to their decentralized nature, most DeFi lending platforms do not have the KYC (Know Your Customer, Know Your Customer) procedures and risk assessment procedures of traditional banks, and they cannot investigate the credit status of borrowers through joint credit bureaus. In this case, you may be wondering, how will my credit be evaluated?
On the DeFi lending platform, you can prove your creditworthiness through reputation token proof. Reputation token is a credit system based on blockchain technology, which uses digital tokens to represent and quantify users’ reputation. The number of reputation tokens has become an important indicator for evaluating a user’s creditworthiness. The greater the number of tokens, the better the user’s reputation and corresponding improvement in credit rating, making it possible to obtain more loan lines on the DeFi lending platform.
However, the generation of reputation tokens relies on users’ transaction history and financial information, which may violate users’ privacy rights.
ZK technology protects user privacy. The combination of ZK technology and reputation tokens can protect user privacy while maintaining and tracking their reputation in the network.
Users can use ZK technology to generate reputation tokens without disclosing historical transactions. On the one hand, users can generate proof of historical transactions based on ZK technology; on the other hand, the proof is verified by a smart contract (often called a reputation token generation contract), and reputation tokens can be generated if the verification passes.
In addition, on some DeFi lending platforms that require over-collateralization, reputation tokens can reduce mortgage requirements, thereby solving the problem of over-collateralization and improving market liquidity. And the application of reputation tokens based on ZK technology is not limited to DeFi lending platforms, it can also be widely used in insurance, medical subsidies and other fields.
This article explores the various application scenarios of ZK technology to achieve privacy protection in DeFi, especially its potential in resisting front-running transactions, liquidity manipulation, and lending. In the process of exploring DeFi, we face multiple challenges, especially issues related to privacy and security. Privacy challenges in the DeFi ecosystem are a key issue, and ZK technology provides a unique solution that not only enhances privacy protection, but also improves transaction efficiency and security. If you want to introduce ZK technology into your DApp, please contact Salus.
Looking to the future, ZK technology may be applied in deeper DeFi fields, such as liquidity staking, derivatives protocols, real-world assets, insurance, etc. Salus focuses on researching and exploring the application of ZK technology in DeFi and other Ethereum application layer projects. We sincerely invite blockchain researchers, technology developers and all professionals in the web3 field around the world to work with us to promote the in-depth development and widespread application of ZK technology to drive the development of DeFi and even the entire industry.