Detailed Instructions

Define the risk parameters that your application is most exposed to, such as smart contract exploits, oracle failures, or liquidity crunches. For each parameter, set precise trigger conditions using quantifiable on-chain data.

• Sub-step 1: Identify critical contract addresses (e.g., lending pool, AMM router) and oracle feeds to monitor.
• Sub-step 2: Set numerical thresholds for triggers, like a 20% deviation in an oracle price or a 15% drop in a liquidity pool's TVL within one hour.
• Sub-step 3: Map each trigger to a specific insurance policy coverage clause, ensuring the event is a valid claim condition.

javascriptCopy
// Example trigger condition for an oracle failure
const oracleDeviationTrigger = {
  targetAddress: "0x5f4eC3Df9cbd43714FE2740f5E3616155c5b8419", // Chainlink ETH/USD
  metric: "priceDeviation",
  threshold: 0.20, // 20%
  timeWindow: 300, // 5 minutes in seconds
  comparisonFeed: "0xE62B71cf983019BFf55bC83B48601ce8419650CC" // Backup oracle
};

Tip: Use historical data and stress-test scenarios to calibrate thresholds, avoiding false positives that could drain operational resources.

Detailed Instructions

Build or integrate monitoring agents that subscribe to blockchain events and state changes. These agents must run reliably and have low-latency access to node RPC endpoints.

• Sub-step 1: Choose a framework like Forta, Tenderly Alerts, or OpenZeppelin Defender to build your monitoring bots.
• Sub-step 2: Code the agent logic to query on-chain data (e.g., using eth_call) and compare it against your thresholds. Listen for specific event signatures like FlashLoan() or PriceUpdated().
• Sub-step 3: Implement a failover mechanism by running agents on multiple node providers (e.g., Alchemy, Infura) to avoid RPC endpoint single points of failure.

javascriptCopy
// Forta bot example snippet for TVL drop detection
async function handleBlock(fortaEvent) {
  const findings = [];
  const currentTVL = await getPoolTVL(POOL_ADDRESS);
  const historicalTVL = await getHistoricalTVL(POOL_ADDRESS, 60); // TVL 60 blocks ago

  const dropPercentage = (historicalTVL - currentTVL) / historicalTVL;
  if (dropPercentage > 0.15) { // 15% drop trigger
    findings.push({
      alertId: "TVL-DRASTIC-DROP",
      severity: FindingSeverity.High,
      metadata: { pool: POOL_ADDRESS, dropPercentage }
    });
  }
  return findings;
}

Tip: Set up separate severity levels for alerts (High/Medium/Low) to prioritize responses and insurance claim initiation.

Detailed Instructions

Connect your monitoring system's alert output to an automated response layer. This layer should gather necessary proof and submit transactions to the insurance protocol.

• Sub-step 1: Configure a secure, dedicated wallet (e.g., a Gnosis Safe) to hold funds for gas and act as the claim submitter. Store its private key in a hardware-secured environment like AWS KMS or GCP Secret Manager.
• Sub-step 2: Build a serverless function (AWS Lambda, GCP Cloud Run) that is triggered by a high-severity alert. Its job is to compile the claim proof: block numbers, transaction hashes, and state diffs.
• Sub-step 3: Use the insurance protocol's SDK (e.g., Nexus Mutual's Claims contract interface) to programmatically call the submitClaim(uint coverId, bytes data) function with the compiled proof.

solidityCopy
// Interface for initiating a claim on a typical insurance protocol
interface IClaims {
    function submitClaim(
        uint256 _coverId,
        bytes calldata _data
    ) external returns (uint256 claimId);
}

// The _data payload should be ABI-encoded proof
bytes memory proofData = abi.encode(
    incidentBlockNumber,
    exploiterAddress,
    affectedContract,
    lossAmount
);

Tip: Introduce a short, configurable delay (e.g., 3 blocks) for manual override before the automated claim submission executes, allowing for emergency intervention.

Detailed Instructions

After a claim is submitted, track its progression through the protocol's governance or claims assessment process. Plan for the integration of the payout.

• Sub-step 1: Set up a monitor to track the claim's status by listening for events like ClaimSubmitted(uint claimId), ClaimAccepted(uint claimId), and ClaimPayout(uint claimId, uint amount).
• Sub-step 2: If the claim is accepted, ensure the payout (e.g., in WETH or DAI) is received by your designated treasury contract. Verify the received amount matches the expected coverage.
• Sub-step 3: Program your application's treasury management or user reimbursement smart contract to accept and distribute the insurance payout. This could involve pro-rata transfers to affected users' addresses or replenishing a protocol-owned liquidity pool.

solidityCopy
// Example function in a treasury contract to handle an insurance payout
function receiveInsurancePayout(address insuranceToken, uint256 amount) external onlyGovernance {
    IERC20 token = IERC20(insuranceToken);
    require(token.transferFrom(msg.sender, address(this), amount), "Transfer failed");
    
    // Logic to distribute funds, e.g., to a reimbursement pool
    totalReserves[insuranceToken] += amount;
    emit PayoutReceived(insuranceToken, amount, block.timestamp);
}

Tip: Maintain clear records of all claims, including submission TX hashes and assessment outcomes, for audit trails and to refine future risk parameters.

Detailed Instructions

Define the specific trigger conditions for each severity level (e.g., Critical, High). For a lending protocol, a Critical trigger could be a collateral ratio falling below 110% on a major vault. Use a risk scoring engine to aggregate signals like oracle deviation (>5%), TVL drawdown (>20% in 1 hour), or a spike in failed transactions. Map each condition to a severity tier. Configure these thresholds in your monitoring dashboard (e.g., setting an alert for health_factor < 1.1 on a specific market). The conditions must be unambiguous and verifiable by smart contract or trusted API to prevent false positives.

Tip: Use historical attack data to calibrate thresholds, ensuring they are sensitive enough to catch exploits but not so tight they cause operational noise.

Detailed Instructions

For each trigger, link a concrete mitigation action. These are often executed via smart contract functions or privileged keeper scripts. Common actions include: pausing deposits/borrows in a vulnerable pool, increasing protocol fees temporarily, or executing a safety withdrawal to a treasury multisig. Code these handlers to be permissioned and gas-optimized. For example, a handler for a flash loan attack might call pool.setPause(true) on the vulnerable contract at 0x.... Implement a circuit breaker pattern where actions are time-locked or require multi-sig confirmation for the most severe interventions to add a human verification layer.

Tip: Test all action handlers on a forked mainnet environment to ensure they execute correctly and do not revert under high gas conditions.

Detailed Instructions

Execution should be handled by a decentralized network of keepers or a robust, funded relayer to guarantee liveness. Upon alert, the system submits the transaction with a sufficient gas premium (e.g., 150% of current base fee). Immediately after broadcast, the protocol must verify the on-chain state to confirm success. This involves checking the transaction receipt for a status: 1 and reading the new contract state. For a pause action, verify that the contract's paused() function returns true. Log the transaction hash and new state to an immutable audit log. Implement a fallback: if the first execution fails, the system should retry with a higher gas limit or escalate to a manual operator.

Tip: Use a service like Chainlink Automation or Gelato for decentralized execution, ensuring uptime and censorship resistance.

Detailed Instructions

Once mitigation is confirmed, the protocol must notify the insurance provider. This typically involves calling a specific function on the insurance protocol's smart contract, such as InsurerContract.initiateClaim(uint256 policyId, bytes calldata proof), providing the alert data and mitigation proof as calldata. Simultaneously, generate a post-mortem report for stakeholders. This report should include: the original alert payload, the executed transaction hash, before/after state snapshots, and a preliminary impact assessment (e.g., "Potential loss of 500 ETH was prevented"). Store this report on IPFS or Arweave and broadcast its CID to a dedicated incident channel. This documentation is critical for the insurance claim and for protocol transparency.

Tip: Structure the proof data to match your insurance policy's required format precisely to avoid claims rejection due to technicalities.

Detailed Instructions

After the incident is fully resolved, conduct a root cause analysis. Determine if the trigger was optimal or if it fired too early/late. Analyze the response latency from alert to on-chain confirmation. Use this data to refine your risk models and alert thresholds. For example, if a price oracle deviation triggered an alert but the market recovered naturally, consider adding a time-weighted average check. Propose and execute a governance vote to update the relevant smart contract parameters, such as adjusting the liquidationThreshold or deviationThreshold in your monitoring system. Update the automated response playbook with lessons learned.

Tip: Create a simulation of the incident using Tenderly forks to test if your updated parameters would have performed better, creating a feedback loop for system hardening.