LlamaRisk values the productive conversation thus far and seeks to establish a concrete collaboration model for Umbrella Risk Oracles. Our primary objective is to combine the strengths of both approaches: using LlamaRisk’s previously ratified Umbrella Methodology to define risk-based targetLiquidity, and using @ChaosLabs’ Risk Oracle to automate and optimize emissions against those targets. In this structure, the oracle’s scope would extend beyond emissions to also update targetLiquidity on-chain based on our jointly aligned monthly recommendations, while coverage calibration remains externally defined and governance-aligned.
Collaboration Model
In the hybrid model, we propose that LlamaRisk remains the lead for defining the targetLiquidity for Umbrella on a per‑reserve basis, while Chaos Labs’ Risk Oracle focuses on determining the appropriate MaxEmissionPerYear given those targets. On our side, the target setting will continue to be based on an external, risk‑adjusted methodology that incorporates liquidity conditions, correlations, and stress scenarios, which the proposed oracle would treat these targets as inputs and solve the financial optimization problem of how to reach and maintain them with minimal leakage, using the framework already outlined in the proposal.
In terms of process, we see value in keeping the interface between our teams and the community as simple as possible. Each month, LlamaRisk would prepare recommended targetLiquidity values per asset based on our risk methodology, which would then be jointly reviewed and agreed upon with @ChaosLabs before being published on-chain via the Risk Oracle. We would maintain a forum thread for Umbrella Target Coverage updates, listing current and recommended values by asset and noting where no change is proposed. This ensures that the final targetLiquidity parameter reflects alignment between both teams, while maintaining a transparent and auditable link between the risk-based targets and the oracle’s emissions calibration.
Cadence and Oracle Operation
To keep the system predictable for stakers and aligned with the 20‑day cooldown, we suggest anchoring targetLiquidity updates to a monthly frequency. Our current view is that a monthly cycle is a good baseline: LlamaRisk would publish updated target values for the existing Umbrella reserves (USDC, USDT, WETH, GHO) once per month, along with concise reasoning for any recommended changes, aligned with @ChaosLabs. This would also solve the problem of the currently static total coverage targets being used by the risk oracle to optimize emissions. In stable market regimes, there may be periods when no updates are proposed.
The proposed Risk Oracle would incorporate the new target coverage values at the start of each monthly cycle and update both targetLiquidity and MaxEmissionPerYear on-chain accordingly, subject to the guardrails and smoothing already envisaged in the design. While targetLiquidity would only change based on updated monthly recommendations, the oracle retains full autonomy over MaxEmissionPerYear between cycles, adjusting emissions at whatever granularity it deems appropriate to respond to shifting user behaviour, within bounded parameter changes and rate limits.
Conclusion
We believe this division of responsibilities respects the scope you outlined, keeping the current Oracle focused on emissions, while making direct use of an already ratified risk framework for Target Liquidity. It avoids duplicating coverage modelling work, keeps the operational footprint manageable for Umbrella stakers, and still leaves ample room for future extensions as the system matures.