This proposal asks to establish the Risk Pod within Gro DAO. The proposal will be open for comments over the next 3 days. If no substantial changes are required, it will then be open for voting for another 5 days.
In its activities Risk Pod proceeds from the premise that a web3 protocol is an evolving shared narrative living simultaneously in two domains open for exploration: onchain transactions and community interactions. They inform and impact each other in both directions in a myriad of ways creating a bipartite heterogenous living organism. To be able to evaluate risks stemming from Gro DAO’s involvement in web3 means to be able to model the evolution of both Gro protocol and its web3 counterparties in a coherent, unified way.
With the premise above in mind, the Risk Pod Mandate includes but is not limited to the following tasks:
- Risk Parameter Proposals
- Yield Strategy Whitelisting and Delisting Proposals
- Monitoring of Portfolio Exposure
- Community Involvement
- Monitoring DeFi Systemic Risk
- Risk Tooling
DeFi Systemic Risks
Gro DAO is highly integrated in DeFi which continues to expand in total value locked and its complexity. In the long run Risk Pod team needs to evaluate how any potential parameter change or new yield strategy whitelisting at Gro DAO might affect systemic imbalances. Furthermore, it needs to monitor DeFi to properly address liquidity and other risk related concerns.
Besides ongoing risk related work and tasks, the team also aims to perform regular research on potential new protocol design topics and how it might benefit Gro DAO’s risk profile. This also includes monitoring of DeFi addressed above and considering potential integrations with other protocols.
Risk Monitoring & Tooling
Risk monitoring is ensured by regular usage of our internally developed risk models. All risk estimates and methods used are being reported openly.
Plan is in the long run to have all our risk models completely automated and run regularly with an open web access so that the community can get informed about Gro’s risk profile at any time.
This also allows easier access to new Risk contributors and establishment of additional Risk Pods.
Note that Risk Pod is focused on market risks of the protocol, whereas other types of risks should be addressed by other pods with corresponding mandates.
For the foundational period in addition to the Facilitator the team of Blockanalitica is planned to be involved as a primary contractor. Blockanalitica aka MakerDAO Risk CU will be able to leverage their extensive experience as well as battle-tested codebase from their work on MakerDAO risk modelling tooling and methodology as well as Aave analytics dashboard.
The next 3 months will be foundational in the sense that Risk Pod will deliver basic dashboard and qualitative analysis tooling for Gro DAO risk modelling as well as methodology of the results translation into Gro DAO Governance proposals in the style of Computer-Aided Governance.
In particular, it will include risk modelling tooling as a customised version of Blockanalitica software.
It will also include a model for basic analysis of the DeFi community sentiment towards key crypto assets used in the Gro ecosystem leveraging the results of @pavel’s previous DeFi sentiment risk modelling (see the UST sentiment => crash case in particular) and will deliver an improved BERT_large language model, 355m parameters (vs BERT_base, 135m parameters, used in the UST/LUNA demo case).
I propose a budget of 140,000 USDC for the next 3 months, in particular:
- 70k for the Blockanalitica customised tooling;
- 30k for the sentiment analysis tooling;
- 10k for the methodology;
- 5*3 = 15k for the Facilitator 3 month compensation;
- 15k for the Contingency Buffer.
that will be transferred to the Risk Pod operational wallet if approved.
Risk Pod will update the DAO on its progress regularly through the community channels such as Community Forum and Discord including a 3 month report on the Community Forum.
We believe the best way to scale Risk at Gro DAO is to have emergent structures from an initial one proposed here. Risk Pod scaling should be ideally done in a way to have “risk field specialized units” separated from the initial one with its own facilitator.
For instance, a team member within the Risk Pod may want to specialise on Labs products. He creates his own Labs Risk Pod with his own team and budget. He would be separated from the initial Risk Pod, but would still collaborate with it.
In our opinion, such evolution of teams within one broad domain such as Risk is preferred because it doesn’t lead to work overlapping and cost inefficiency, which would be the case if we were to have multiple Risk Pods performing the same type of work initially.
We do however support development of separate additional Risk Pods and are willing to collaborate with them. We only believe development of such units may be most efficient when developed from initial teams where common language already exists and coordination is easier.