Things work a bit differently around here. You'll notice many familiar concepts, though. Read on to learn more.


    There are no liquidity-"pools" - instead, you have a number of "positions", which are represented by a number of state machines, which are embodied by a single UTxO each - we term them "Diracs". A set of one or more of those Diracs representing a position is called a "Pool" (for historical reasons). Each pool belongs to one account only, and that ownership is not transferable.


    Each Dirac has at any point in time a limited capacity for a swap; in most cases, this is only a sub-amount of the total liquidity. You can increase this in two ways:

    • 1. Increase the minimum amount swapped for one or both of the assets involved.
    • 2. Chain transactions. You enable this option by increasing "maximum # (= number of) transactions". This will also require you entering your spending password once for each subsequent swap. This whole process basically equates to using the maximum current capacity of all Diracs available for the asset-pair, waiting a block for the changes to be reflected onchain, then repeating this process until the desired amount is reached. The difference is that with chaining, you don't have to wait; also, it might partially fail if the number of UTxOs in your wallet is too small.


    When providing liquidity, you create a set of Diracs with shared parameters. You don't need to concern yourself with most of them as a beginner; however, the one thing that's important is that you check

    • 1. The initial prices of the assets: You can either enter them manually, defer to the Cexplorer-prices automatically (which in turn are only updated every three hours or so, at the time of writing), or defer to the weighted average prices of other pools. Make sure you double-check this, as a wrong price equates to a paying arbitrageurs for removing that difference.
    • 2. The "divergence" of the inital price of the pool compared to the chosen target price (see the previous point). Analogously, the bigger this difference, the larger the arbitrage opportunity. If it's too high, you can try reducing it by fiddling with the parameters.

    The other parameters do the following:

    • "Virtual Liquidity" creates concentrated liquidity positions. Think of it as extra liquidity that cannot be bought (because it's even more made up than regular liquidity). For example: When an asset has 10 deposited (actual) and 20 virtual liquidity, this means the system will calculate the price as if the total liquidity would be 30. This will function normally, until those 10 tokens have been bought up (assuming no new ones have been sold of course); as a result, the system will still calculate the price as if there were 20 tokens left, but you won't be able to actually buy them.
    • "Tick Size" means how much the available price points differ from each other, multiplicatively speaking. For example, a tick size of 10% and an initial price of 20 means the next price point will be 22, the one after that 24.2, and so on. A higher tick size will result in a higher expected slippage for the user, but will increase the capacity of a single (minimal) swap. The utility of this is that it removes the incentive for whales to split up big trades over many Diracs, with the intention of minimizing slippage, which could result in congestion.
    • "Active Ticks" increases the number of Diracs, which is the product of all pool-assets' active ticks. This increases parallelism, but also increases the uselessly locked up ADA - on Cardano, each UTxO requires a certain minimum ADA-deposit as protection against spam. This parameter is per-asset and not per-pool (as one would expect), because we are not simply creating multiple copies of the same Dirac - instead, their prices are staggered as well. For example, having three assets with "active ticks" 2, 1 and 1, respectively, will result in two Diracs, both with the same price for the second and third asset, but with slightly different prices for the first. This means the increased parallelism will benefit trades against the first (more staggered) asset more.