Thank you, appreciate the feedback.
The contracts are custom made. The reason you probably haven’t seen this opportunity is that it’s “hidden” behind a add liquidity → remove liquidity cycle. Our bad, it wasn’t until we launched that we realized how powerful this tool is 
We are currently working on a simple router-level flash loan macro that would expose this to the average user much more easily. But even without that you can already use this feature, and providing liquidity to our pools is essentially a continuous option to realize 50% of your assets for the other token in the pool at no slippage (when you’re inside the pool, you’re exposed to your own token, but to exit you could receive your liquidity as redeemed Uniswap V2 pool tokens, which are 50/50)
On a tech level these contracts would fall under an “oracle-based” AMM category, where the oracle is the xy=k pool itself. Basically every Zircon pool is a hybrid xy=k + concentration layer AMM that supports liquidity at the current price.
It’s of course very important to minimize MEV extraction and extra impermanent loss, which is one of the changes we’ve introduced in our last update. Basically, the concentration layer has a dynamic fee mechanism proportional to price changes since the last update (as supplied by the pool oracle), which is set to a minimum of 120 seconds. It’s also designed so that the first possible arbitrage is always with the standard xy=k, reducing the impact of toxic flow.
As you can imagine, fast price manipulations will trigger both this and our general liquidity-based anti-manipulation system.
Generally our advantage is that impermanent loss is more predictable and controllable than what you’d have with Uniswap V3 or Curve V2, and it’s easier to attract liquidity on single-sided vaults compared to a 4-token pool or concentrated ranges that might require multiple corrections per day (and which can’t be easily incentivized).
On audits, I’ve provided the relevant information to @Aleksandr a little bit above. The initial version is audited, and we’re working on solidifying with an advanced audit these recent changes in time for the launch as well.
I’m Ismael, as a committee member of the Revised Grant Program i´d like to, first of all , thank you for applying and for answering the questions already asked by the members of the community. After reviewing your proposal along with your project documentation and other sources of information such as your social networks and github repositories, I wanted to give you my feedback with the intention of giving you ideas to improve the proposal and make it even more accessible to the community. The questions and feedback broadly falls into two categories: The format of the proposal itself and specific project feedback.
Hi Ismael, thank you for the feedback, you’ve raised some great questions. So first of all, our system is designed to be black swan-tolerant in general. For example, every single pool is an island and one of them failing does not affect the others.
The system uses fees to save up for a “rainy day fund” that compensates impermanent loss for Stable vaults (the ‘senior’ tranche of a pool that often represents stablecoins). The rainy day fund is accumulated externally, preferably directly in the asset to be compensated. Each pool has its own fund.
Overall, the principle behind the system is that as long as the pool continues to exist and earn fees, the rebalancing action that hedges impermanent loss (based on LPs being dynamically incentivized) can continue to occur and recover from any broad market dump.
This is what we tested with SBF. The crash was hugely important as we realized that the system was susceptible to panic and needed more deterrence (essentially, people panic-withdrew stablecoins single-sided, in doing so they dumped the price, which worsened the position of other LPs in the pool, who in turn withdrew etc.). There were also some issues that prevented the rebalancing mechanism from working (people were unable to supply liquidity to the Float side, so it couldn’t restore balance).
So overall after some changes (namely, penalties that keep money in the pool when withdrawing during market panic and a more flexible portfolio value formula) we’ve restarted and successfully passed the SVB panic and USDC depeg (which we used for our largest pools on Moonriver). It’s worth noting though that anything that happened with ZRG is basically the hardest mode possible for the system, while any other token that has outside liquidity and efficient markets for shorting (hedging), can be used very effectively on the platform.
In a Nomad or Luna style situation, unfortunately LPs in these pools would’ve likely lost the vast majority of their money. We do not have the possibility of pausing the underlying Uni V2 pools, and the impermanent loss still exists, so even one asset going to zero will send the value of the pool as a whole to zero. There is very little we can do about this except for not bringing down the entire protocol with that pool. This is for example a key differentiator from Bancor, which was always basically one wrong listing away from pulling a LUNA-style bank run on BNT (the entire protocol is exposed to all pools’ impermanent loss)
The Revised Grant Program calls for several pieces of information to be provided as part of the template. In some areas your application could be enhanced to give the community greater transparency and reassurance while reviewing your application.
Timeline and Milestones for Use of Grant: This section is dedicated to relevant timing data, including but not limited to: start and end date, milestones and goals. Your proposal indicates the steps to follow but it is not clear if you already have thought of a collaboration with other projects in the ecosystem from the beginning. Another thing worth mentioning is the lack of explanation on what will happen to the funds in the event that market conditions worsen. I applaud the fact that you are actively thinking about the possibility of a market turndown and what to do in that case; but at the same time, this could also be abused. Would you be willing to agree to self-imposed limits on how long you can hold the funds before they must be returned to the community?
Re: project collaborations, we would definitely expect to list Interlay assets and hopefully Acala as well. But one of the reasons we’d prefer some discretion in the allocation specifics is because there could exciting project launches by other Moonbeam-native projects that could require solid liquidity. We’d be happy to agree to some general constraints regarding how the funds can be deployed, such as a percentage split between Moonbeam-native, Dotsama-native or external projects.
Re: self-imposed limits, I think this is a great idea for the grants program. However, considering that there are projects from the last grants batch who still have funds remaining, and especially since one of them is once again requesting the maximum allocation, we don’t feel that it would be fair if we were the only project with such a clause. So if this can be introduced as a general grants program rule, then for sure. If not, then not completing the distribution could become a factor to consider if we ever were to request additional funding, for example.
On our end, we obviously commit to using the funds for the betterment of the network, and we don’t really expect to leave that much at the end of the period. This is mostly a precautionary measure to be able to use the funds more efficiently, stemming from our previous experience, where since we felt we needed to use the funds as quickly as possible, we threw away thousands of MOVRs in the latter period for pools that were not really all that useful to the DEX or the network (for example, MOVR/KSM rewards were all essentially going to one whale who later took a chokehold over our project’s emissions).
You mention a gradual deployment of the remainder of grant to support liquidity for ecosystem projects. Between 25-75k GLMR will be set for each pool per month. How are these pools going to be selected? And on what metrics will you base the monthly re-assessment?
The selection criteria can be defined together, but generally we’d prioritize Moonbeam and Dotsama-native projects who need liquidity, i.e. not listed on CEXs or efficient DEXs. A special place in our heart goes to bootstrapped projects like ours, for whom our system can offer a true lifeline thanks to its efficient liquidity and single-sided staking for DAO treasuries. We of course will conduct due diligence and not list potential rugs or scams — honestly might be a nice idea to hold quick snapshot votes for GLMR holders to confirm listed pools, but I’d need to check if it is practical.
Re: reassessment, it depends mostly on the relative APRs, TVL growth and volume. Contrary to what it may seem, lower APRs are actually a good sign for a project or pool, because it means that rewards are used more efficiently. As a general rule, we’d like to cut rewards to pools that are underperforming, or have reached stable levels of volume and TVL, while we’d want to continue and reinforce rewards for actively growing pools.
So if we see that a pool has topped out on growth, the APRs stay very high, and the volume-based APR is not sufficient (i.e. the pool is underperforming), we’d cut rewards to avoid waste — the pool would most likely settle at some lower level of liquidity, but also much lower APRs
If the pool is stable and generates decent volume, this is also a good candidate for cutting. While if it’s still growing in adoption, we want to reinforce that and continue the rewards.
What are your plans if the GLMR/USD pool can’t become self-sufficient once the grant funds are over? In case there’s another pool with higher APY than yours for the same token pair, how would you differentiate from your competitor?
Generally, liquidity is interchangeable and fluid, so we don’t see more liquidity on the same pair as inherently bad.
If the pool cannot become self-sufficient, we’d like to first understand why and improve our protocol in accordance to these findings. Might be a UX issue, might be market-specific, might be because another DEX takes the majority of the taker flow. Most likely, we would then look for a different pool to push through to self-sufficiency.
How will you measure if a pool is healthy and based on what will you adjust the relative reward distribution?
This is basically an internal protocol thing. Each pool has virtual weight of assets that can differ from the “underlying” 50/50 weights. Balanced pools are those where the virtual weight is equal to the true weight, as this generates zero impermanent loss. So we aim to strengthen rewards to the weaker side, with a bias towards the Stable side (as an imbalance towards Stable is generally more acceptable to the two sides than one towards Float).
What’s the role of the ZRG token on Zircon?
Well, besides being tremendously useful to test the system in a real market setting, this is the DAO and incentive-alignment token. Besides rewards, we aim to use a system of ZRG staking to create “skin in the game” for our users, especially to deter predatory behavior such as mercenary farm and dumping. Furthermore, profits from the platform will get routed to the Zircon DAO treasury and eventually, routed to a buyback-and-burn contract.
Tokenomics implementations are still WIP, since the product takes precedence for now.
What are the expectations for increase in transactions / new user attraction / TVL due to your deployment on Moonbeam?
Honestly, I could come up with random numbers that sound convincing, but this is not something that can be known a priori. We do have some TVL projections for the GLMR/USDT pool, which we’ve shown. We’ve also shown what kind of trading slippage these projections would translate to. Whether there will be takers for this liquidity, or new users, is essentially unknown and doesn’t depend on us necessarily.
For us, a measure of success is if the GLMR rewards can be deployed with an efficiency as high as 50% APR for farming (i.e. users are accepting 50% APR to provide liquidity), and within a 100% APR range (which is the range embedded in the TVL and liquidity projections).
Whether Zircon succeeds in bringing new users to Moonbeam depends on:
- The right projects existing in the ecosystem and Zircon supporting them correctly
- Zircon having success on Moonbeam and elsewhere, leading to an increased ZRG valuation which can support larger liquidity and flow users from other chains to Moonbeam to take advantage of the pools and tokens.
- Zircon having the funding and support to continue refining our existing products and developing new primitives.
We see this grant as a chance to execute on 1 and 3, and 2 might follow as well.