In typical order book markets, anyone can easily set a limit order: to buy or sell an asset at a specific predetermined price, allowing the order to be filled at an indeterminate time in the future. However, AMM is different.
A liquidity pool is a trading venue for a pair of HTS tokens (represented as a LP token). The pool contract, once initialized, has a balance of zero in LP token; in order for the pool to begin facilitating trades, it is necessary for someone to seed it with an initial deposit of each token into the pool. This first liquidity provider is the one who sets the initial price of the pool. They are incentivized to deposit an equal value of both tokens into the pool.
If we consider the case where the first liquidity provider deposits tokens at a ratio that is different from the current market rate. This immediately creates a profitable arbitrage opportunity, which is likely to be taken by an external party.
When other liquidity providers add to an existing pool, they must deposit pair tokens proportional to the current price. If they do not, the liquidity they added is at risk of being arbitraged as well. If they believe the current price is not correct, they may arbitrage it to the level they desire, and add liquidity at that price. This market mechanism keeps the price of all tokens in an appropriate range.
Liquidity tokens (LP tokens) are automatically minted by the system when liquidity is deposited into a pool (liquidity = tokenA + tokenB). The proportion of the pool's liquidity provided determines the number of liquidity tokens the provider receives. For a user, an amount of LP tokens represents the amount of liquidity shares in a pool. If the provider is minting a new pool, the number of liquidity tokens they are going to receive will equal
sqrt(x \* y), where x and y represent the amount of each token provided. As liquidity tokens are themselves tradable assets, liquidity providers may sell, transfer, or otherwise use their liquidity tokens in any way they see suitable.
As an incentive for those who contribute liquidity, they will earn a trading fee whenever there is a trade in their pool.
Whenever a trade occurs, a 0.25% fee is charged to the transaction sender. This fee is distributed pro-rata to all LPs in the pool upon completion of the trade. The fees due to your liquidity position will be denominated in both tokens of the given pair. For example, if a trade occurs in HBAR-USDC pool, after swapping HBAR for USDC, or USDC for HBAR, a small amount the input token of each trade will be due to your account as liquidity provisioning rewards.
Learn more about Fees.
As mentioned above, Sigmaswap is not operated using an order book for pricing and trading. Instead, the protocol uses what is called liquidity pools.
Order book is great in a certain point of trading in an organization control, but there are limitations when it is applied with decentralized settings. Order books require intermediary infrastructure to host the order book and match orders. This creates points of control and adds additional layers of complexity. They also require active participation and management from market makers who usually use sophisticated infrastructure and algorithms, limiting participation to advanced traders.
Sigmaswap focuses on bringing development and adoption to the strong advantages of Hedera Hashgraph capability that is being the most scalable and fastest decentralized network which can deliver the best experience in decentralized finance to everyone.
Please note that a Pool is only a smart contract which is operated by users calling functions on it. Swapping tokens is calling
swap on a Pool contract instance, while providing liquidity is calling a
Similar to how end-users can interact with the Sigmaswap protocol through the Interface (which in turn interacts with the underlying contracts), developers can interact directly with the smart contracts and integrate Sigmaswap functionality into their own applications without the need of intermediaries or permission.