DAM Finance: Ecosystem Grant Draft Proposal

Governance Grant Proposals
8

Feedback:

Hello DAM Finance team.

Thank you for applying for the Moonbeam Ecosystem Grant Program. As a committee member, I would like to add some notes and questions to enhance your proposal and make sure we have some standardized structure so our community can compare proposals as well as vote in full transparency. Also, I’ve added relevant questions about the project itself, which I believe your answers will not only benefit your grant request but also the overall understanding over DAM Finance.

PROPOSAL FORMAT

First of all, I must highlight that your grant application is overall well presented with minor adjustments and comments from my end. Congrats on putting this proposal together with such cohesive content.

Goal: We would like the team to choose one of the two goals as primary. We believe that you may have these goals as a project, but for grant purposes, one should be prioritized.

  • Maintain Growth Activity (Increase the number of active users)
  • Increase the number of connected contract use cases.

Since your milestones are mostly related to TVL targets, your goals might be more related to maintaining growth activity than increasing connected contract use cases? Please expand on this.

Vision of Success: this part is well written, but I believe it is missing some success metrics. It would be great if you can add some actual OKRs that are aligned with this vision and the grant as well. Although your milestones are TVL-based, I would add some specific and tangible metrics of what success looks like after this phase is completed.

BLACK SWAN, MARKET CRASH AND HACKS

We would like the team to make explicit comments on how you would respond to a ‘black swan event’, such as the Luna or Nomad hack. Although your milestones are already phased into gradual steps, we would like the team to detail what is the strategy/tactical response in case of a market crash or other relevant events.

Please consider the emergency tactics for the grant-related activities that will be adopted in case of a hack, market crash and/or other events.

PROJECT FEEDBACK

Business Model

  1. Users should be aware that d2o uses USDC as collateral. Although USDC is one of the most trusted stablecoins in the market, recent depeg of USDC should’ve directly impacted d2o as well. @DAMFinance team, please feel free to comment on that and what measures can be taken (if any) to mitigate this risk.

  2. I can understand the business case for EVM and non-EVM chains. But it’s not clear to me why you need to deploy in other parachains within the Polkadot ecosystem. Please explain the need to deploy d2o natively in other parachains, considering the XCM (xc-tokens) can achieve the same result. It seems redundant.

  3. Please confirm which DEX you will use to create these pairs d2o <> GLMR or d2o <> dot. Also, if you are using Stellaswap, it’s important to note that Stella will use their grant (if approved) to increase rewards on some pools with other stablecoins, like USDT and USDC. If you use Stella, for example, and we have 2 pools [GLMR <> USDT] and [GLMR <> d2o], wouldn’t the users focus on whichever has the most APY%?

3.1 In other words, have you aligned this strategy with your dex partner? Otherwise it might have conflicting pools and jeopardize the overall grant goal.

  1. Is there any pendings that might jeopardize or delay the grant implementation? (Audits, deployments, partner’s dependencies, etc).

Monitoring depegs and security events

  1. It seems that the team relies on off-chain API’s to monitor the state of the smart contracts of different chains and search for inequalities (a minted token on one chain that was not burnt on another). If a hacker can batch_mint thousands, if not millions of d2o, how effective would this mechanism be? Have you ever battle tested this feature? I assume that the hacker only needs <1 minute to mint d2o and swap it in another dex.

  2. Please expand on the off-chain architecture of the dGuardian. dGuardian ‘simple website’ is not working (in here: dGuardian - DAM Finance Documentation).

  3. Who is ‘dGuardian’? How many people are monitoring the network? What automation is in place to secure fast response to an event?

  4. One thing that I would like to highlight is that the large majority (>70%) of the hacks on bridges happened due to human error and not due to a flaw in the bridge architecture design. Sometimes we have only a handful of addresses controlling the multisig that dispatches updates, or lack of standardization on the DevOps and more… Although DAM offers a better architecture solution than the standard bridges, how is the team mitigating these other risks? At the end of the day, if DAM Finance is concentrating a lot of liquidity, you will become a target of hackers as well.

Additional Notes

  1. The code for LMCV and PSM in Docs leads to a 404 page in github. Please update your Docs and/or correct the links on your website.

  2. Please share smart contract addresses on moonscan and etherscan. In the future, it would be useful if you could add the addresses to your Docs.

UPDATES TO PROPOSAL

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.

8 Likes