Governance Parameter Tuning and Risk

Detailed Instructions

Clearly articulate the governance objective, such as adjusting collateral factor to manage liquidation risk or modifying reserve factor to control protocol revenue. Define the scope by identifying the specific asset pool (e.g., USDC, WETH) and the target parameter. Gather baseline metrics, including current utilization rates, historical volatility, and oracle price feeds for the asset. This step ensures the proposal addresses a measurable issue rather than arbitrary change.

• Sub-step 1: Identify the target parameter (e.g., liquidationThreshold, borrowCap).
• Sub-step 2: Analyze on-chain data for the asset's performance over the last 90 days.
• Sub-step 3: Document the desired outcome, such as "Reduce maximum LTV from 75% to 65% to decrease systemic risk."

Tip: Use a governance forum post to frame the problem and gather community feedback before drafting a formal proposal.

Detailed Instructions

Employ agent-based simulations or stress-testing models to forecast the impact of the proposed change. For a lending protocol, simulate scenarios like a 30% price drop in collateral assets under the new loan-to-value (LTV) parameter. Use tools like Gauntlet's framework or custom scripts to model changes in bad debt accumulation and liquidation cascades. The simulation should output key risk metrics, including the revised Probability of Insolvency and expected liquidation efficiency.

• Sub-step 1: Set up a forked mainnet environment using Foundry or Tenderly.
• Sub-step 2: Run the simulation with historical and extreme market data.
• Sub-step 3: Compare the simulated capital efficiency and safety metrics against the baseline.

javascriptCopy
// Example simulation snippet for checking solvency under stress
const newLTV = 0.65;
const priceDrop = 0.30;
const userCollateral = 1000; // ETH
const userDebt = 600; // DAI
const isSolvent = (userCollateral * (1 - priceDrop)) > (userDebt / newLTV);
console.log(`Account solvent under stress: ${isSolvent}`);

Tip: Validate simulation assumptions against recent market events to ensure realism.

Detailed Instructions

Translate the analysis into a concrete, executable proposal. The proposal must specify the exact contract address, function signature, and calldata for the parameter update. For a Compound-style governance system, this involves creating a proposal that calls _setCollateralFactor(address cToken, uint256 newCollateralFactorMantissa). Include a comprehensive rationale linking simulation results to the proposed values. The proposal should be formatted according to the specific DAO's standards, often requiring a markdown document in the governance forum followed by an on-chain transaction.

• Sub-step 1: Write the proposal text with sections for Summary, Motivation, Specification, and Risk Analysis.
• Sub-step 2: Encode the governance action using a tool like cast calldata from Foundry.
• Sub-step 3: Submit the temperature check or signaling poll to the community forum.

solidityCopy
// Example calldata for a Compound Governor Alpha proposal
// Target: Comptroller contract
// Signature: _setCollateralFactor(address,uint256)
// Arguments: cETH address, 0.6e18 (60% collateral factor)
bytes memory data = abi.encodeWithSignature(
    "_setCollateralFactor(address,uint256)",
    0x4Ddc2D193948926D02f9B1fE9e1daa0718270ED5,
    600000000000000000
);

Tip: Use a multisig or proposal helper contract to batch multiple parameter changes into a single proposal for efficiency.

Detailed Instructions

After the voting period concludes and the proposal passes the quorum and vote differential requirements, proceed with the queue and execute transactions. Once executed, initiate a post-implementation monitoring period. Set up dashboards to track the parameter's effect in real-time, monitoring for unintended consequences like reduced market liquidity or increased gas costs for liquidations. Key metrics include changes in the borrow volume, health factor distribution of users, and keeper profitability for liquidations.

• Sub-step 1: Queue the proposal on-chain after the successful vote.
• Sub-step 2: Execute the proposal after the timelock delay expires.
• Sub-step 3: Deploy monitoring bots to alert on anomalous activity, such as a spike in near-liquidations.

Tip: Establish a rollback plan or a follow-up proposal template before execution in case the change has severe negative impacts.

Detailed Instructions

Define a set of historical scenarios (e.g., May 2021 crash, March 2020 Black Thursday, FTX collapse) and hypothetical stress events (e.g., 80% ETH price drop in 24 hours, 50% surge in stablecoin depeg). For each scenario, identify the core risk metrics to track. These include the protocol's solvency ratio, health factor distribution of user positions, total bad debt accrued, and liquidation efficiency. Use on-chain data oracles like Chainlink to source accurate historical price feeds for your simulation's initial state. The goal is to create a reproducible test suite that models realistic on-chain conditions.

• Sub-step 1: Catalog 3-5 major historical volatility events relevant to your protocol's assets.
• Sub-step 2: Define 2-3 extreme, low-probability hypothetical scenarios to test tail risks.
• Sub-step 3: For each scenario, specify the exact metrics (e.g., solvency_ratio < 1.0) that constitute a failure state.

javascriptCopy
// Example scenario definition object
const stressScenario = {
  name: "ETH Black Swan",
  initialBlock: 12965000, // Pre-crash state
  priceShock: {
    'ETH/USD': -75, // Percentage change
    durationBlocks: 7200 // ~24 hours
  },
  failureConditions: [
    'totalBadDebt > 10000000', // $10M USD
    'solvencyRatio < 1.05'
  ]
};

Tip: Use a multi-asset correlation matrix during scenario design to ensure shocks are applied realistically across related tokens (e.g., wBTC and ETH).

Detailed Instructions

Utilize a tool like Foundry's forge or Hardhat to create a local fork of Ethereum mainnet (or another relevant chain) at the block height corresponding to the start of your chosen scenario. This creates a sandboxed environment with real historical state, including token balances and price feeds. Within this forked environment, write a script to execute the governance proposal that changes the parameters you intend to test. This typically involves simulating a call from the protocol's Timelock Controller or Governor contract to the target configuration module. For example, you might lower the Loan-to-Value (LTV) ratio for a collateral asset from 75% to 65% or increase a liquidation penalty.

• Sub-step 1: Fork mainnet using anvil --fork-url <RPC_URL> --fork-block-number <BLOCK> or equivalent.
• Sub-step 2: Impersonate the governance executor address using vm.prank() (Foundry) or hardhat_impersonateAccount.
• Sub-step 3: Execute the transaction that calls setConfiguration() or similar on the protocol's parameters contract.

solidityCopy
// Foundry example: Simulating a parameter change on a fork
function testLowerLTV() public {
    uint256 forkId = vm.createFork(MAINNET_RPC, 12965000);
    vm.selectFork(forkId);
    // Impersonate the timelock executor
    vm.prank(TIMELOCK_ADDRESS);
    // Call the configuration function
    LendingPoolConfigurator(CONFIGURATOR_ADDRESS).setLTV(
        ASSET_ETH,
        6500 // 65% in basis points
    );
}

Tip: Always verify the parameter change was applied correctly by calling the relevant public view function on the contract after the transaction.

Detailed Instructions

With the new parameters active on the fork, you must now apply the price trajectory of your stress scenario. This is done by mocking or manipulating the oracle contracts that the protocol relies on for price data. Using Foundry's vm.mockCall() or Hardhat's network manipulation, override the latestAnswer() return value of the oracle (e.g., a Chainlink Aggregator) to simulate the price drop or spike over the defined period. Advance the blockchain state in blocks or time intervals, updating prices at each step. After each price update, trigger any keeper bots or liquidation engines that would operate in the live environment to process liquidations. Use event logs and direct contract calls to record the resulting state: amounts liquidated, bad debt generated, and health of remaining positions.

• Sub-step 1: Write a loop to advance the chain n blocks, representing the duration of the event.
• Sub-step 2: At each interval, use vm.mockCall() to set the new oracle price for the target asset.
• Sub-step 3: Call a helper function to trigger the protocol's public liquidationCall() or updateState() method.
• Sub-step 4: Query and store key metrics from the protocol's contracts after each step.

solidityCopy
// Pseudocode for applying a linear price drop
for (uint256 i = 0; i < durationBlocks; i += 120) {
    // Advance 120 blocks (~30 minutes)
    vm.roll(block.number + 120);
    // Calculate new price (linear drop from 3000 to 750)
    int256 newPrice = int256(3000 - (2250 * i) / durationBlocks) * 1e8;
    // Mock the Chainlink oracle response
    vm.mockCall(
        CHAINLINK_ETH_USD,
        abi.encodeWithSelector(AggregatorV3Interface.latestAnswer.selector),
        abi.encode(newPrice)
    );
    // Trigger liquidations
    (bool success, ) = address(liquidationEngine).call(
        abi.encodeWithSignature("checkAndLiquidate(address)", USER_ADDRESS)
    );
}

Tip: To simulate network congestion, you can increase the block.timestamp by a larger amount to model delayed liquidations.

Detailed Instructions

Aggregate the data recorded during the simulation run. The critical analysis involves comparing the outcome metrics from the run with the new parameters against a baseline run that used the original parameters under the same scenario. Calculate the difference in bad debt, the change in the number of positions liquidated, and the final solvency ratio. Use statistical summaries like mean, median, and 95th percentile for health factors across the user pool. Look for unintended consequences: did the stricter parameters cause such rapid, large-scale liquidations that they overwhelmed the liquidation capacity or caused excessive gas costs for keepers? Did they merely delay insolvency or prevent it entirely? Visualize the data as time-series graphs of key metrics to understand the dynamics of the stress event.

• Sub-step 1: Re-run the scenario simulation with all steps identical except using the original protocol parameters to establish a baseline.
• Sub-step 2: For both runs, calculate aggregate totals for bad debt, liquidation volume, and gas consumed by keepers.
• Sub-step 3: Compute the distribution of user health factors at the end of the scenario for both runs.
• Sub-step 4: Create a summary table showing the delta between the new parameter run and the baseline.

javascriptCopy
// Example results analysis
const results = {
  baseline: { totalBadDebtUSD: 12.5e6, positionsLiquidated: 450, finalSolvency: 0.98 },
  newParams: { totalBadDebtUSD: 3.1e6, positionsLiquidated: 1200, finalSolvency: 1.12 },
};
const improvement = {
  badDebtReduction: ((results.baseline.totalBadDebtUSD - results.newParams.totalBadDebtUSD) / results.baseline.totalBadDebtUSD * 100).toFixed(1),
  // = 75.2% reduction
};

Tip: A successful parameter change should show a significant reduction in systemic risk (bad debt) without making the protocol unusable or shifting an unreasonable burden onto a subset of users.

Detailed Instructions

Compile a comprehensive report that documents the methodology, each scenario, and the quantitative results. The final output should not be a single recommended value, but a safe operating range for each parameter. For example, based on the simulations, you might conclude that the LTV for wBTC can safely operate between 70% and 78% without causing insolvency in 99% of historical scenarios, but that 80% leads to unacceptable risk. The report should also highlight any non-linear effects or cliff edges discovered, where a small parameter change leads to a disproportionately large change in risk. Include clear visualizations of the risk-parameter relationship. This document becomes the primary artifact for governance discussion, providing data-backed justification for a proposal. It should also outline the assumptions and limitations of the simulation (e.g., oracle reliability, keeper activity).

• Sub-step 1: For each tuned parameter, create a graph showing the key risk metric (e.g., max bad debt) as a function of the parameter value.
• Sub-step 2: Define the acceptable risk threshold (e.g., bad debt must not exceed $5M in any scenario).
• Sub-step 3: From the graphs, identify the parameter values where the risk curve crosses the acceptable threshold. These define the bounds of the safe range.
• Sub-step 4: Draft the governance proposal text, embedding key charts and a concise summary of the simulation findings.

markdownCopy
## Recommendation Summary

*   **Parameter:** Maximum LTV for Wrapped Bitcoin (wBTC)
*   **Current Value:** 75%
*   **Recommended Range:** 70% - 78%
*   **Justification:** Simulations show that at 79%, the "March 2020" scenario generates $8.2M in bad debt, exceeding our $5M safety cap. At 70%, bad debt remains under $1M in all scenarios, but capital efficiency drops 15%. The 70-78% range optimizes for both safety and usability.
*   **Proposed New Value:** 75% (unchanged, but now with validated safety margins).

Tip: Include a "sensitivity analysis" section showing how results change if key assumptions (like oracle latency) are varied.