-
Author - Andrey Shevchenko, Co-Founder and CEO of Zircon Labs
-
TLDR - Support a mix of GLMR/USD and native project liquidity, thanks to our unique system battle-tested on Moonriver
-
Primary Goal-
-
*(i) Maintain and Grow Activity (active users, transactions, TVL)
-
Project Description - Zircon is the next generation DEX that reduces impermanent loss and enables deeper liquidity without institutional participation.
-
Requested GLMR Grant Amount - 1M GLMR
-
Use of Grant - Supporting liquidity for the Moonbeam deployment ā half destined to a common good GLMR/Stablecoin pool, half to be used flexibly to support ecosystem projects.
For the stablecoin, we expect to use xcUSDT, but circumstances could change quickly. -
Motivation for Grant Amount- A balance between leaving space for others and achieving a breakthrough level of liquidity. Our system enables concentrated liquidity swaps based on an OTC-like principle. With this amount we expect to reach $600k-$1.2M liquidity for GLMR/USD (without counting our own ZRG rewards), which would enable a max single-swap size of $120k-240k at a total cost of ~0.5%. This is comparable to Pancakeās BNB/BUSD pool, where with $140M TVL max swap size is $190k before paying more than 0.5%.
-
Updates - N/A
-
Project Overview and Relevant KPIs - Zircon launched in October 2022 on Moonriver. It had received a 15k MOVR (approximately $180k) grant from the Foundation to bootstrap the launch. Weāve used this to establish our presence on Moonriver, growing to $2M TVL and testing our unique system in the āwildā.
-
- The Zircon platform enables single-sided liquidity, impermanent loss mitigation and OTC-like swaps, all done by one system. Weāve proven that these work in our initial launch phase, but discovered some flaws in our system (namely, panic was not disincentivized enough) that were exposed by the SBF debacle. Since rectifying these issues, weāve successfully withstood a similar episode with SVB fears, and have been on a steady growth trajectory since relaunching the new version in mid-February, completely self-supported.
-
- Weāve been funded via our token, ZRG, ever since launching. Thanks to our unique system, weāve never depressed the price by a single % to fund ourselves.
-
Team Experience -
-
- Andrey Shevchenko, Co-Founder and CEO of Zircon Labs. Previously worked in an editorial position at Cointelegraph during DeFi summer and beyond. Self-taught degen, and before crypto used to (successfully) hunt Google for vulnerabilities.
-
- David Vittori, Co-Founder and CTO of Zircon Labs. Previously Senior Software Engineer at Banca Sella, Flywallet and other āWeb2ā startups
-
- Another 5 people including frontend developers, marketers and general counsel.
-
Timeline and Milestones for Use of Grant -
-
Launch on Moonbeam before April 15, through our current platform Zircon Gamma
-
Launch of GLMR/USD pool boost on April 15 (2-week 2x boost program for 166k GLMR)
- Standard 166k GLMR/month injection in the subsequent two months
-
Gradual deployment of remainder of grant to support liquidity for ecosystem projects
- Between 25k-75k GLMR per pool per month, to be re-assessed monthly for each project
- We expect to support any Polkadot or Moonbeam-based project wishing to work with us.
- We reserve the right to not use the entirety of the grant during the first period, holding it for better times if market conditions worsen, if we see low efficiency (too high APRs) or if we donāt find enough projects for whom the liquidity injection is useful
-
Vision Of Success -
Our goal is to use the grants as a bootstrapping mechanism, and not an eternal artificial lung. Hence, our success for this grant is: -
- The GLMR/USD pools becomes self-sufficient on fees, or only require minimal ZRG rewards
-
- At least 50% of the projects supported via the remaining grants system retain over 50% of the liquidity at the end of the boost (requiring at most a small injection with their own tokens or a ZRG mix)
-
- Zircon is designed to be what Uniswap V3 couldnāt ā a platform for average users to support strong liquidity for mid and small-cap tokens. In this vision, V3-like platforms (like StellaSwapās Pulsar) can attract expert market makers to support efficient and cheap liquidity for massive tokens like DOT and ETH, while Curve-like platforms support cross-stablecoin swaps.
-
Rationale - Moonbeam ecosystem projects will be able to efficiently put to work and realize their treasuries if necessary, without generating as much downside price pressure as on the old Uniswap V2-like platforms. This will ultimately reduce liquidity friction and help unlock the ecosystem for more DeFi, NFT and XCM use cases. However, it might not increase overall TVL due to the higher efficiency of the platform.
-
Steps to Implement -
-
- Deploy Zircon Gamma platform on Moonbeam. We generally have about 1 week/10 days turnaround for new deployments, mostly involving setting up a ZRG bridge from Moonriver with our partners Multichain.
-
- Collect the grant in a Multisig
-
- Set up recurring farms through a custom script (already existing)
-
- Perform monthly checks of pool balance and adjust relative rewards distribution if necessary
I think this grant should be rejected on spot.
People that publicly shame Moonbeam and their ecosystem incentives should be rejected.
They got a fair point though. All focus is on Stellaswap and neglecting other DEXs. Still no liquidity on Sushiswap on Moonbeam, still no Uniswap, and other protocols like Curve and Lido are not looked at. So I disagree to reject it based on the truth.
Hey, Andrey! Thank you for submitting your proposal.
-
-
Can you provide more details on the use cases for connected contracts?
-
-
-
What security measures do you have in place and how do you ensure user fund safety?
-
-
-
How do you plan to innovate and stay ahead of the competition in Moonbeam DeFi ecosystem?
-
-
-
How would your development plan be affected if there were no incentives for your project?
-
-
-
How often do you audit your code for vulnerabilities or weaknesses, and who do you use as an auditor?
-
-
-
What updates or developments can users expect in the near future?
-
Moonbeam has established numerous HRMP channels with other parachains. Iām curious to learn more about Zirconās future plans in this area, as itās crucial for Moonbeam DeFi to become a central hub for creating use cases for tokens from other parachains. this will enable these tokens to be utilized within the DeFi Moonbeam ecosystem, including for trading, farming, lending & borrowing.
Iām also interested in whether Zircon intends to submit grant proposals to other parachains to receive liquidity incentives. This could create more opportunities for users from different parachains to interact and explore other projects within the dotsama ecosystem, thereby avoiding fragmentation and encouraging users to discover the advantages and opportunities of other parachains.
Could you please point the specific phrases that can be considered āshamingā? I am not seeing anything that isnāt a mere statement of facts and of our own intentions. We have a duty to be transparent to our community and explain radical changes in roadmap with more than empty words and lip service.
The truth is that many projects have left the Moonbeam ecosystem since the last grants. Off the top of my head Moonsama, Firefly and Lido have been the toughest blows. Some of it might have been unrelated, while others must have felt what we did: that there was no way to compete when your rivals get millions in liquidity incentives.
We generally believe that truth is important, even if it hurts, and thatās what Iāve been trying to do. In the most constructive, respectful but at the same time direct manner possible.
Burying your heads in the sand and attacking anyone who dares say that things maybe arenāt going in the right direction doesnāt do a community or organization any favors. Ask Russia how thatās going for them.
Replies in quote:
ā
-
We fully intend to list xcTokens of major parachains, beyond that we do not have XCM usage plans just yet (keen to use something like OAK Networkās scheduling to maintain contracts, but it is not a core user-centric feature)
-
We would expect to submit proposals to support liquidity for tokens from other parachains, but we donāt expect to launch on any of them. We also would rather focus on providing a useful platform for users, so we could also just launch a pool ourselves and see if it sticks without rewards afterwards.
Iām definitely FOR giving the guys a grant. I am always looking for interesting projects in the Moonbeam ecosystem and I was immediately interested in their project with its novelty in the market and it is really interesting.
Here are a few reasons why I find them interesting:
- This is farming, a new level, because in order to start farming a token in a lp pair, you do not need to have 2 tokens, as in traditional farming, but only one.
- The ability to choose a strategy, which I really like.
- The team is very open and listens to its community.
- We have already passed several difficult tests and did not give up.
- The team has the ability to add different networks, which can attract new users from other ecosystems to Moonbeam.
- I personally use their product and only on the basis of this formed my opinion.
Hello! I believe that Zircon Finance can be awarded a grant for several reasons:
- The project brings a new approach to farming, innovative and creative, users of bnb and arbitrage, using the application now understand this, and also daily compare commissions and speed, convenience of working on bnb, and on the moon river, and this can be very useful for the moon river.
- Zircon Finance passed 2 black swans of the crypto market in the last 3 months
very worthy. - The team is open to the community and responds to all requests daily.
- One of the few projects that honestly and adequately fulfilled its obligations this year. I am glad that I use Zircon Finance.
I want to add to my post.
Zircon Finance will openly and honestly discuss any and all business matters. It is worthy of respect. Feedback on the work on the lunar river among Zircon Finance users is very positive and many are waiting for Zircon Finance to be opened on the lunar ray. Comparison of the speed of work, convenience in harvesting farm crops is more like users on the lunar river. Everyone appreciated this in the current work of every day. This fact only increased the reputation of the lunar river. You can say a lot about what was written above, but not everyone can work like Zircon Finance confirm the positive impression of the moon river blockchain.
Gentlemen seriously, Iām reading the comments here and theyāre out of order.
Lets please all show some decorum and avoid wild speculation @GAMA. Clearly your doing the classic trick of editing the messaging to make the team look bad. Iām sure youāre taking those pics out of context and from reading @shvandrew_Zircon_Fin comments, clearly your comments are ābelow the beltā and not relevant to say the least.
Now my technical question for Zircon,
You say youāve made a OTC trading smart contract, that is āV3-likeā. I trade using bots on moonbeam everyday, I will need much more information regarding the mechanics of these contracts, did your team make them or are they licensed ? are they audited?
What makes these contracts āV3-likeā please provide technical details regarding how liquidity is provided at specific increments / at specific levels ? Iāve played around with your product on BSC / MOVR and maybe itās due to the lack of liquidity, but I canāt see the advantage on the front end.
re the asset select - Iām all for it. USDT, Good choice.
If you answer my questions about the contracts/ highlight their benefits, they iām happy to vote in favour. Good luck with your proposal looking forward to seeing your product deploy.
Regards,
TheOyster 
Before making any arbitrary comments, itās important that you acquaint yourself with the topic at hand. Zircon didnāt deploy on Moonbeam for reasons that align with your support for StellaSwap.
Based on your comments on this forum, it appears that you may be a fan or even a covert team member of StellaSwap. Please make an effort to be transparent in your contributions.
Good sir,
This proves you are throwing accusations at everyone you meet on this forum. As I am specifically known in the moonbeam community discord + my watermelon branding is also my signature. ( discord username: TheOyster )
Please feel free to check the Moonbeam discord server, The builders thread, you will see 100ās of messages over the last 15+ months of the moonbeam community literally helping me learn how to code so I could build trading bots, you will also see the and you can also DM that person to prove it.
Why am I commenting,
I have large holdings of GLMR and actively trade on Moonbeam all day, everyday with bots. I have great respect for all DOT/GLMR community members and am active in the GLMR/DOT community myself.
Yes I am vocal, this is because I have an active interest in promoting DeFi on moonbeam so I can trade more and I believe I am entitled to respectfully share my opinions. I will continue to do so.
I hold GLMR coins, meaning I am entitled to both a vote and for my voice to be heard.
Regards,
TheOyster
Just read Zircon Financeās grant proposal on the Moonbeam forum, and Iām impressed with their vision for building a more efficient and accessible ecosystem. Their team seems experienced and capable, and I think they could make a real impact with this grant. Hoping they get the support they need! #Moonbeam #DeFi #Grant
Hello @shvandrew_Zircon_Fin ,
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.
For the first of my questions I am going to refer to a post by user tneves asking what would be the measures to take in case there is a āblack swanā.
You mention you were exposed by the SBF and you took actions to rectify it. This has been expanded in further comments in this discussion post, it may be beneficial for your proposal to expand about the actions you took to rectify it.
Proposal format
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?
Project feedback
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?
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?
How will you measure if a pool is healthy and based on what will you adjust the relative reward distribution?
Whatās the role of the ZRG token on Zircon?
What are the expectations for increase in transactions / new user attraction / TVL due to your deployment on Moonbeam?
Updates to Proposals
Please note that you have until March 19th 2023 11:59PM UTC to make changes to your proposal. A list of changes based on community feedback should be added to the āUpdatesāā section of the proposal and any changes should be reflected in the text of the proposal itself.
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 @turrizt 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.
I have been a user and member of the Zircon Finance community for over a year, almost since its inception.
If you allow, I would like to give my opinion in support of this project, because a positive decision on the grant will accelerate the development of Zircon Finance, and Moonbeam will benefit from the influx of new users from other networks, additional liquidity and goodwill.
The facts
- Zircon Finance came at a not the best time in terms of the world of finance, but it is still alive!
- in Moonriverās parent network Zircon Finance achieved impressive TVL results.
- in the 6 months since the launch of the project in real conditions, Zircon Finance experienced two āblack swansā in the bear market and still recovered.
- Zircon Finance has been tested on the Moonriver network and expanded to other networks.
- the project became self-sufficient
What made it possible?
- implementation of the ultimatum and innovative idea: providing one-way liquidity, reducing non-permanent losses.
- great team, constantly improving their product and obsessed with their work.
- experience gained in a bear market
Opinion on the grant
The grant size for deploying to Moonbeam and maintaining the ecosystem is modest and respectful of other projects.
It is strange that a project born in Moonriver is forced to grow outside of Moonbeam.
I think you are familiar with these words:
āMoonriver is a companion network to Moonbeam and provides a permanently incentivized canary network. New code ships to Moonriver first, where it can be tested and verified under real economic conditions. Once proven, the same code ships to Moonbeam on Polkadot.ā
In my humble opinion, the team has done enough for Zircon Finance to finally join Moonbeam.
Can you provide a chance for Zircon Finance?
Or does Moonbeam have favorites and the development of other projects is not relevant anymore?
Moon River, wider than a mile,
Iām crossing you in style some day.
Old dream maker, you heartbreaker,
wherever youāre going Iām going your way.
Two drifters off to see the world.
Thereās such a lot of world to see.
Weāre after the same rainbowās end
waiting 'round the bend,
my huckleberry friend,
Moon River and me.
Hello @shvandrew_Zircon_Fin ,
I am sorry for what you and your community are going through due to the hack (https://twitter.com/Zircon_Finance/status/1637093661321183233) you have experienced and I hope that you are able to recover from this setback as quickly as possible.
However, I would like to request some clarifications from you regarding the future of the project. Specifically, I would appreciate it if you could provide more information on the following points
1- Regarding the grant proposal that you have submitted, I am curious to know if you plan to move forward with it in its current form. Given the recent events, I can imagine that some investors or community members might have concerns about the projectās viability. Clarifying your intentions regarding the grant proposal would go a long way in addressing these concerns.
2 - Assuming that you do plan to continue with the grant proposal, I would like to know whether the grant funds would still be used for the original purpose. Has the recent hack caused you to reconsider your plans? It would be helpful to understand if there are any changes to the projectās roadmap or priorities as a result of the hack.
3 - Finally, I am interested in learning more about the steps that you plan to take to prevent similar attacks from happening in the future. Specifically, I am curious about your plans for ensuring the security of your project on Moonbeam.
Hope you can understand my questions may be very informational for the community and my intention is not to harass or damage the project.
Hi Ismael, thank you. These are very reasonable questions, of course.
To give a bit of context, the hack involved only our modifications to the Uniswap V2 core, where none of our protection systems I was mentioning before were active. We were reasonably confident about it due to the fact that it was a small, audited change done before going live. We werenāt even able to pause the UniV2 core.
We had a good chunk of our company funds on the platform, so this does affect the financial viability of our project at this stage. I would not consider it to affect the viability of our project on a product or concept level. The vulnerable part was a small piece of the code, basically a macro to save gas. Every advantage I listed earlier still works and still applies.
Of course weāre all personally devastated that this happened and want to make it right by our users. In order to do so, the only possible approach is to restart and keep working on our vision. We have a very unique product that has a number of significant advantages over the competition, and a talented and creative team to continue to innovate over time.
If I have to summarize the events that led to us getting hacked:
- We messed with the Uniswap V2 core at an early stage of development, aware of the dangers of it but thinking that we had a good enough grasp of the system to make some gas-saving macro functions for single-sided actions. Turns out, we had used balanceOf and getReserves inconsistently ā more on this on our technical post mortem to be released this week.
- The project got audited. We were mostly worried about the reliability of the Pylon, but felt that the auditors did a good enough job on the Uniswap portion, given also a past history of auditing forked Uniswap code.
- This complacency led us to not take any actions to review the strength of the Uniswap V2 core, theorycraft exploits or otherwise analyze it post-launch.
- The unexpected happens, the damage is near complete due to poor timing as well (the Pylons and the money in them was untouched, but most of the money had been matched into the underlying pools).
On a wider sense, we are a small team with very little funding. In an ideal world where we had at capacity for a $50-60k/mo burn, weād have hired an in-house security engineer and always ordered two independent audits on large changes. Sadly, we never had it. I wonāt go into the details of why here, but our goal with the relaunch is to change this fact.
With this in mind, before we relaunch we aim to:
- Get two independent audits on the entirety of our codebase, selecting companies that use advanced techniques and with a good history of auditing complex projects.
- Run a contest on a CTF platform such as Code4rena ā the more eyes, the better, even if this method is traditionally looked down at in the industry.
- Get enough reserves to set up and publicize a continuous bug bounty
- Beef up our internal review practices. Test wild and unexpected inputs, never release code that doesnāt produce a verifiably correct output, and run internal contests for who can crack the code to steal money.
The audits + Code4rena alone would be expected to require about a $200-$250k spend.
If we were to nonetheless receive this grant, I feel that weād be obligated for the sake of our community and the GLMR holders to prioritize investing in security, instead of simple liquidity mining rewards. So approximately half of the GLMR we requested would end up devoted for these expenditures, with half remaining for liquidity mining, unless we can secure independent funding.
I would completely understand it if the community was not interested in granting us the money. Weāre not beggars, so we will think of other ways to rebuild. We believe our product is extremely powerful and deserves to be given a fair shot at implementation and usage. If we were to be given this shot, we and our community would be extremely grateful and make it worthwhile for the ecosystem.
This topic was automatically closed after 6 days. New replies are no longer allowed.