Pair Smart Contract
This contract implements the actual pool that exchanges tokens. It is the core LADEX functionality. This contract inherits from UniswapV2ERC20, which provides the the ERC-20 functions for the liquidity tokens. The Pair Smart Contract consists of two main functionalities. The first one represents the liquidity pools associated with the two tokens that compose the second functionality, the swap activity. The way the pair exchange decides on the exchange rate between token0 and token1 is to keep the multiple of the two reserves constant during trades. kLast is this value. It changes when a liquidity provider deposits or withdraws tokens, and it increases slightly because of the 0.3% market fee.As traders provide more of token0, the relative value of token1 increases, and vice versa, based on supply and demand. When a liquidity provider either deposits liquidity (Mint) or withdraws it (Burn) mint event and burn even happen. In either case, the amounts of token0 and token1 that are deposited or withdrawn are part of the event, as well as the identity of the account that called us (sender). In the case of a withdrawal, the event also includes the target that received the tokens (to), which may not be the same as the sender.
The second functionality a Pair SC exposes is the swapping process. Users can trade an amount of one token for an automated computed amount of the other token. The automated market making concept relies on a mathematical formula to price assets. Instead of using an order book like a traditional exchange, assets are priced according to a pricing algorithm.
The LADEX Exchange uses the constant product formula x * y = k, where x is the amount of one token in the liquidity pool, and y is the amount of the other. In this formula, k is a fixed constant, meaning the pool’s total liquidity always has to remain the same. When a trader swaps one token for the other the Swap Event is emitted. Again, the sender and the destination may not be the same. Each token may be either sent to the exchange, or received from it.
Because of how the automated market maker is computed based on the constant product formula, multiple attack vectors can be associated with it. One in particular stands out called front running attack. An attacker can “wrap” a user’s order to swap two tokens with two of his own orders, taking advantage of the price calculations and being able to exchange the same tokens at a lower price thus obtaining a small profit with zero risk associated. To prevent front running attacks, it’s vital to submit swaps that have access to knowledge about the “fair” price their swap should execute at. In other words, swaps need access to an oracle, to be sure that the best execution they can get from the SWAP is close enough to what the oracle considers the “true” price. While this may sound complicated, the oracle can be as simple as an off-chain observation of the current market price of a pair. Because of arbitrage, it’s typically the case that the ratio of the intra-block reserves of a pair is close to the “true” market price.
So, if a user submits a trade with this knowledge in mind, they can ensure that the losses due to front-running are tightly bound. The frontend should ensure trade safety. It calculates the optimal input/output amounts given observed intra-block prices, and uses the router to perform the swap, which guarantees the swap will execute at a rate no less x% worse than the observed intra-block rate, where x is a user-specified slippage tolerance (0.5% by default). We should offer 3 types of swaps: exact input in exchange for maximum output. Exact output in exchange for minimum input. Swap to exact price. (with slippage/tolerance)
Last modified 1yr ago