Articles on: Features

AMMs and liquidity pools on

Automated Market Makers (AMMs) and their underlying liquidity pools facilitate frictionless 24/7 trading on, allowing users to trade into pre-filled pools of liquidity without needing a conventional trading partner on the other side (as is the case with traditional order-book trading). They also remove the need for conventional market-makers by allowing the community itself to deposit liquidity.

Here, we explain how AMMs work on, and the role they play in our wider offering.


On, as on other platforms, AMMs and liquidity pools are essentially a two-tier technology.

Each liquidity pool includes a pair of tokens, as well as a third, liquidity provider (LP) token, which we’ll explain in more detail shortly. The pool is filled by the community, in exchange for a share of trading fees.

When trading opens, the two tokens are effectively traded against one another. The AMM itself is an algorithm which continually adjusts the relative price of the two tokens in response to trading activity.

AMM providers use a number of different mathematical equations to determine the pricing curve, but at its simplest, the price of each token will rise when it’s bought and fall when it’s sold. has opened four liquidity pools, covering the following pairs:

DVF/ETH (DVF is’s native governance token).

AMMs allow users to earn rewards for holding certain tokens, and make markets for people to swap these tokens.

Beyond that, AMMs provide a way to match supply and demand. So, if people are holding a certain token, they can release the asset to be traded by the community, keeping liquidity flowing around the platform.

AMMs and liquidity pools for traders

For people looking to trade, the user experience is no different to a regular swap. Their trade will simply be routed to one of our liquidity pools in the backend if the relevant tokens match a pair covered by our AMM programme.

So, if they wished to swap DVF for ETH (which is covered by our pools), they would click the ‘Swap’ button in the left-hand corner and see the following interface:

AMMs and liquidity pools for liquidity providers

Liquidity providers (the users who wish to fill up the pools) must visit the ‘Pools’ tab on the left-hand side of the page and then click on the pool they wish to deposit into.

To contribute to the pools, liquidity providers must supply both tokens in the pair, and to equal value.

This doesn’t mean users need to supply the same amount of each token. Instead, they must supply a ratio that corresponds to the ratio of the tokens in the pool.

So if, to take a very simple example, the pool holds 1,000 DVF and 1 ETH, participants would have to supply 1,000 DVF for every 1 ETH they supplied.

When they deposit the pair of tokens, liquidity providers receive the third, LP token: this represents their share of the pool (in other words, the value of assets they have provided as a percentage of the overall assets in the pool) and entitles them to rewards from the pools’ activity, based on trading fees. The LP token is minted when the user provides the tokens and burned when they withdraw.

When a user wishes to remove the tokens they have deposited, it is essentially the same as a regular swap. The user says ‘I possess LP tokens, and I’d like to exchange them for my original assets.’

Unique and distinctive features’s AMMs are built on our scalability engine, StarkEx, which processes transactions off the main Ethereum blockchain, using zero-knowledge technology, before posting a record of the state change (the change to user balances) back on-chain. This means that transactions take place off the congested Ethereum mainnet, so when users execute their swap and receive their LP tokens, there is virtually no gas cost.

Core technology

To facilitate AMMs, has built smart smart contracts based on the UniSwap V2 smart contract. These contracts are built on Layer 1, and trading against them is disabled: they are purely for synchronising token balances from Layer 2 to Layer 1.

These contracts usually include a feature that allows anyone to create a market with an initial deposit of two tokens; for now, disables this feature to ensure we remain the gatekeepers for the creation of markets.

When LP tokens are minted, this takes place on Layer 1, but it happens in batches periodically. There is also a synchronisation mechanism between StarkEx and the Layer 1 contract, using a feature called L1 Orders which was implemented in StarkEx version three.

The L1 Orders feature allows us to achieve periodic synchronisation between Layer 1 and Layer 2.

This synchronisation, which follows the rules of the Layer 1 contract, guarantees that will send tokens from Layer 2 to Layer 1 and mint a corresponding number of LP tokens according to the AMM map. It means we cannot mint LP tokens out of thin air, and someone who holds an AMM token can be sure that this asset represents a genuine share of the pool. What’s more, both sides are handled atomically (in other words, instantaneously).

When trading begins, uses a toggle to switch the AMM contracts to Layer 2 mode, which means the assets can’t be traded on Layer 1; the transaction has to take place off-chain.

One exception to this is emergency withdrawals. If ever went offline and/or StarkEx was frozen, liquidity providers can use an emergency withdrawal feature to withdraw their funds from the Layer 1 contract, using their LP tokens.

Pricing mechanism uses a mechanism based on the classic UniSwap curve. However, the implementation of the L1 contract enables to add different pricing mechanisms in future, for example a specific mechanism to facilitate stablecoin pools, with a simple code switch.

Trusted or custodial elements

The entire AMM process on is self-custodial, for both traders and liquidity providers, based on user signatures.

When users trade against the AMM, they are asked to sign a form confirming that ‘I want to have token X or token Y, this is the price I’m willing to accept and the maximum amount of slippage’. And they either receive their requested asset or the swap doesn’t take place due to slippage and they keep their original token.

There is a guarantee that the swap will take place according to the terms the user has signed for, or it doesn’t happen; this guarantee is the same as the guarantee provided by any other trading market on

Likewise, when liquidity providers deposit into the pool, there is a guarantee that they will receive the correct amount of LP tokens, or, if their deposit was unsuccessful for any reason (if, for example, the ratio of the tokens in the pool changed significantly during their deposit), their original assets would be returned at the correct ratio.

Because everything happens on Layer 2, there is the theoretical possibility that could deny the user their request to swap, burn or mint their tokens. However, we are developing a feature that provides a backstop against this, which would enable the user to express their desire to burn their LP tokens on Layer 1 (similar to the guarantees that the StarkEx contract itself offers) and force the contract to release all the funds. We will provide more information in due course.

Risk factors

The risks of trading in and providing liquidity to AMMs are the same as those of any other contract that has control over users’ funds, notably the risk of hacks.

To minimise these risks, has put rigorous checks in place and we attempt to avoid pushing any unnecessary changes. Our contract changes are rigorously audited internally prior to release, and receive regular external audits from industry-leading blockchain security experts, such as PeckShield.

Another risk factor that applies to all AMM pools in DeFi (and a term that often causes confusion) concerns impermanent loss, which refers to an opportunity cost when the value of a token changes dramatically on the open market.

Liquidity pools and AMMs create an enclosed ecosystem. The prices of the two tokens are solely based on trading activity within the pool: the algorithm does not receive any information from outside. This means that a token price can rise far more significantly on regular DeFi trading exchanges than in AMM pools.

In this scenario, arbitrage traders may seek to take advantage of the valuation mismatch by entering the AMM pool and buying the token. If this happens, the supply of this token will fall against the other asset in the pool.

Liquidity providers are only entitled to remove the percentage of tokens they initially invested: they are not entitled to remove the tokens in their original quantities. The ratio of tokens they receive is determined by the available supply at the time they withdraw.

In other words, liquidity providers may find that, when they wish to withdraw, they receive a greater quantity of the ‘less valuable’ token and a lesser quantity of the ‘more valuable’ one (because arbitrage traders have bought the higher-value one from the pool and sold the lower-value one).

In this case, it may have been more valuable for the liquidity providers to hold the two assets rather than depositing them into the pool (because they now have a relatively smaller quantity of the more valuable token).

The loss is described as impermanent because it is essentially theoretical: it only becomes permanent if the user decides to exit the pool. Furthermore, the trading fees accrued through LP tokens can offset these losses, although that is not guaranteed.

If you would like to discuss our process for AMMs and liquidity pools, or any other aspect of’s technology in more detail, please contact us via Twitter or Discord.

Updated on: 30/05/2023

Was this article helpful?

Share your feedback


Thank you!