We understand the vote outcome reflected the sentiment of the community. This is our first time operating an independent pod within a DAO, and we’ve learned a lot. Our primary takeaway is the importance of improving communication and focusing on delivering features that significantly benefit the community. Here’s our plan for moving forward:
Since the vote, we’ve met with the core contributors and community members to gauge sentiment and how we move forward from here. We’ve gathered valuable input that has led us to the decision on the relayer.
Of all the projects we’ve undertaken in the past six months, this feature promises the most significant benefits for the community. Instead of presenting another proposal, we’ve decided to proceed with its release.
- Final User Testing: Our preliminary testing has been ongoing for over two weeks. We’re formulating a comprehensive plan for the subsequent round of testing, and we encourage more community members to participate. Feedback from this testing will guide our continued refinements to the relayer.
- Smart Contract Audit: We’ve finalized arrangements with our auditors, setting clear parameters for the audit’s scope and focus. Over the upcoming weeks, we aim to expedite and conclude all auditing tasks. The audit expenses will be sourced from our existing budget, and any additional costs will be temporarily covered by the contributor compensation budget from the 1st term.
- Deployment: Once user testing, the audit, and issue resolutions are accomplished in the coming weeks, we’ll rely on the support of the Groda pod to assist with integrating the UI code and deploying the relayer smart contract.
We have exceeded our budget for the initial term. Detailed information is provided below.
To speed up the release of the relayer, we will cover this cost as a gesture of goodwill to the community. In our next proposal, we’ll include an option to recover this expense. However, we understand that if the community votes against it, we may not be able to recover the cost.
We will collaborate with the Groda pod and the community to identify new products to build for the next 6 months. When we’ve gathered sufficient input we’ll post a detailed proposal for community feedback and vote.
To wrap up the first term, here’s a more detailed description of our deliverables, challenges and learnings.
The cross-chain relayer is built on the top of several bridge services (such as stargate, connext, L2 official bridges). In the early phase of the relayer, the design mainly focused on how to reduce user’s cost in bridge services (such as bridge fee and slippage). It also preferred to integrate the bridge which can support various chains to make the relayer easy to extend to other chains.
- During the relayer development, we have finished the following tasks:
- Smart contracts
- Web UI design, modification and implementation
- Build the dashboard to monitor the cross-chain status
- Create the auto task scripts to manage the admin functions of the cross-chain relayer
- First round of user test: we recruited some Gro Protocol users to test the cross-chain functions and UX, and fix and optimize the details based on the feedback we collected (see test guidance here).
The crash of Multichain made the team reconsider the general risk in bridge services (such as liquidation, maintenance level). The design was changed to consider the bridge service by each cross-chain step. Accordingly, the MVP version includes following changes
- Make the bridge service replaceable in the contract
- Integrate native bridge between mainnet and L2
- Switch to more decentralized asset bridge by using multiple bridges since no single bridge service can meet all requirements (stargate, official L2 bridge)
- Improve the sanity check
It is hard to test all the relayer cross-chain workflows with a single chain fork environment. We need to put a lot of effort into the integration test to verify key workflows:
- Design how to set up the integration test with all required bridge services. In the testnet, those services have different dependencies (limited supported tokens and chains), the team had to find the solution to make them work together in the testnet.
- Test bridge service would not be well maintained. Some exceptions may be caused by the bridge service issues. The team had to work closely with the bridge team to find the root cause to make sure the bridge integration in the right way
- After getting more experience in the integration testing, the team improved the resilience of the relayer to handle the finding issues.
Make the relayer more flexible to be used by Gro Protocol and beyond. The relayer will handle cross-chain management and the protocol team can implement their investment contract based on the relayer.
- We encountered some uncontrollable problems during the relayer development, it meant that we spent much more time than expected handling these situations.
- The increase in complexity led to an increase in audit fees, which caused our budget to be insufficient to support the audit.
- When encountering similar issues in the future, we should first assess potential problems and make an adequate budget. When finding that the budget is insufficient, we should synchronize with the community in advance and initiate a vote to solve the problem.
Due to the changes in Fist Pod, the Panda Pod take the extra responsibility to build the monitoring and alerting module for the core protocol
Work closely with the Groda Pod to define the checkpoints and thresholds.
Implement 2 alerting services to provide back up of each other. Make the important alerting reachable for both core team and the community OGs
- Build the event driving monitor service to immediately inform the pod members once the checkpoint change is over threshold
- Work with Sentio to build the on-chain monitoring and analyzing system to inform the community for the emergency alertings.
Public alerts can be followed in the emergency-alerts channel (limited access)
After our strategy research started, we selected 15 strategies worth noting based on TVL, APY, and other key indicators. All details are in this document.
Eventually, we chose lvUSD and crvUSD for in-depth research over the past 3 months.
crvUSD: crvUSD pool strategies
- crvUSD is the best strategy we found after starting the research. In our report, we made a detailed description and assessment of the background, operating mode and risks of this strategy, and compared it with the strategies currently being run by GRO based on the existing allocation framework.
lvUSD: lvUSD thinking
- lvUSD was the first research strategy we chose. It once achieved high ·TVL and APY data after launch. We once held great expectations for it and conducted in-depth analysis of the project’s background, token structure, profit model, etc.
- While we were conducting further risk assessment and research, lvUSD experienced an unpeg event and continued to decline, forcing us to stop the research of this project.
- We’ve encountered these problems during the inital research:
- At first we were exploring only strategies related to 3CRV under the current G2 framework, which did indeed limit our search scope.
- In subsequent research, we began to explore process and risk for strategies outside of 3CRV and found strategies such as crvUSD.
- However, due to the lack of liquidity on Curve, we’ve also struggled to find more strategies, which has resulted in some wasted time.
- During the research process of crvUSD and lvUSD, we have accumulated a lot of experience to provide more assistance in carrying out similar tasks in the future.