Zircon Docs
Providing Liquidity
Zircon enables you to provide liquidity in just one asset, but since we are simply tranching risks between two different sides, Float liquidity providers need to be matched with Anchor liquidity providers. There are two main ways that the Zircon protocol does this.

Synchronous LPing

The most straightforward way to add liquidity to Pylon is by collecting deposits from the two sides, and send them into the pool when there is a match.
This is what we call the Sync liquidity provisioning (LPing for short). The protocol maintains a certain reserve of assets that are kept aside at any point. These are used as the "stockpile" of its respective side.
For example, if the Float Stockpile is full, the protocol begins to reject new LPs who place their assets in it (there's an alternative, don't worry). Any time someone adds liquidity to the Anchor Stockpile, it gets matched with the liquidity in the Float Stockpile and sent to the Zircon pool in a neat 50-50 distribution (as mandated by the Uniswap xy=k invariant).
The reserve is similarly used to honor withdrawals of existing Float/Anchor LPs, who simply receive a portion of the stockpile.

Asynchronous LPing

What happens when there is an imbalance between prospective Float and Anchor liquidity providers? If the Sync stockpiles don't accept any more of a particular side, the Async LPing model saves the day.
In Async mode, your tokens get instantly sent into the pool to earn fees, bypassing the reserves. In the backend, your tokens is sold against the pool to form the 50-50 split required by Uniswap. This approach involves slippage, and so is less efficient. It is also more expensive due to the imbalances it may create in the Pylon pool.
Users still get only Float or Anchor tokens depending on which one they chose. Because in the backend it's all the same, users can also supply a 50-50 mix of assets and still join just the Float or the Anchor side.
This mechanism is called "Async" because it assumes that eventually the two sides will balance each other out as more people provide liquidity. Think of it like this:
  • Alice first adds 5 ETH and 5000 USDC as Float, and then Bob provides the same 5 ETH and 5000 USDC as Anchor.
  • Or Alice puts 10 ETH in the sync pool while Bob puts 10,000 USDC.
  • In both cases the pool has 10 ETH and 10,000 USDC, while Alice and Bob each hold half of it.
Still, Async is fundamentally different from Sync because it affects the relative shares of the Float and Anchor sides inside the pool. The effects of this can be far-reaching and add a level of new interesting outcomes for particular pools, such as eliminating impermanent loss for Float holders (when there is a constant stream of new Anchor liquidity) or creating permanently "high-yield, high-risk" pools for Anchor holders (if Float supplies dominate).
Last modified 6mo ago