{
  "version": "1.0",
  "asOf": "2026-08-30T16:06:54.232Z",
  "editorialStatus": "Human-published, source-first event research; not investment advice",
  "taxonomy": {
    "reported": "Reported, not confirmed",
    "confirmed": "Confirmed",
    "proposed": "Proposed",
    "approved": "Approved, not executed",
    "executed": "Executed",
    "contained": "Contained",
    "recovered": "Recovery reported",
    "postmortem": "Postmortem",
    "launched": "Live launch",
    "deprecated": "Deprecated"
  },
  "entries": [
    {
      "id": "event-13de2c76-eb4c-41aa-a1be-a08b4ff85afe",
      "stableKey": "defi-saver-asset-management-tvl-exodus-2026-08-30",
      "version": 1,
      "eventDate": "2026-08-30",
      "publishedAt": "2026-08-30T16:06:54.232Z",
      "title": "DeFi Saver tracked TVL declines 27% between observations",
      "category": "market_stress",
      "posture": "confirmed",
      "materiality": "material",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "other",
          "id": "defi-saver-asset-management",
          "name": "DeFi Saver Asset Management"
        }
      ],
      "primaryDocuments": [
        {
          "title": "DeFi Saver protocol TVL fell 27% since the last observation, from $309.2M to $225.5M",
          "authority": "Ketju quantitative monitor",
          "url": "https://monitor.ketjuresearch.com/alerts.json#protocol-tvl-exodus%7Cdefi-saver-asset-management%7C2026-08-30T11%3A00%3A26.803Z",
          "documentType": "reproducible state observation",
          "publishedOn": "2026-08-30"
        }
      ],
      "whatHappened": "Ketju's quantitative monitor observed DeFi Saver Asset Management tracked TVL decline from $309.2 million to $225.5 million, a 27% reduction, by 2026-08-30T11:00:26.803Z.",
      "whatChanged": "The aggregate value attributed to positions with active DeFi Saver automation subscriptions decreased by approximately $83.7 million between monitor observations.",
      "whatDidNotChange": "The observation does not confirm a protocol exploit, client loss, withdrawal failure, automation outage, contract change, or impairment of any underlying lending position. It also does not establish that the decline represents funds exiting rather than automation subscriptions ending, position changes, or a data-classification issue.",
      "confirmedFacts": [
        "The monitor measured tracked TVL of $225,501,461 after a prior observation of $309,157,875.",
        "The measured decline was 27%.",
        "DeFi Saver Asset Management is a Ketju-approved-with-limits dependency rather than a standalone allocation."
      ],
      "unresolved": [
        "Whether the decline reflects genuine position exits, discontinued automation subscriptions, changes in underlying positions, or a data discontinuity.",
        "Whether the decline is sustained in subsequent observations.",
        "Whether any client-held automated positions or DeFi Saver services experienced operational problems."
      ],
      "advisorDiligenceImplications": [
        "Reopen memo defi-saver-asset-management to reconcile the TVL decline against subsequent observations and underlying protocol balances.",
        "Verify that any client use remains limited to the approved automation dependency and that each underlying protocol remains separately approved.",
        "Do not infer loss or impaired exit from the TVL observation alone."
      ],
      "followUpOn": "2026-08-31",
      "previousInterpretation": "DeFi Saver was approved with limits as an automation dependency, with tracked TVL treated as aggregate value of subscribed underlying positions rather than pooled protocol assets.",
      "supersedesId": null
    },
    {
      "id": "event-c93e3018-e471-4959-b787-deb3753032a4",
      "stableKey": "aave-v3-gho-prime-tvl-exodus-2026-08-26",
      "version": 1,
      "eventDate": "2026-08-26",
      "publishedAt": "2026-08-26T20:23:58.625Z",
      "title": "Aave v3 GHO Prime Instance deposits fall 40% between checks",
      "category": "market_stress",
      "posture": "confirmed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        },
        {
          "type": "product",
          "id": "41683a7c-20a2-4cd7-83a7-3ccedaad0db1",
          "name": "Aave v3 GHO Prime Instance on Ethereum"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Aave v3 GHO Prime Instance deposit exodus observation",
          "authority": "Ketju quantitative monitor",
          "url": "https://monitor.ketjuresearch.com/alerts.json#tvl-exodus%7C41683a7c-20a2-4cd7-83a7-3ccedaad0db1%7C2026-08-26T11%3A00%3A21.733Z",
          "documentType": "quantitative monitor observation",
          "publishedOn": "2026-08-26"
        }
      ],
      "whatHappened": "Ketju's quantitative monitor observed deposits in the Ethereum GHO Prime Instance decline from about $12.6 million to $7.6 million between checks.",
      "whatChanged": "Observed venue deposits fell 40%, reducing the liquidity base and warranting an immediate check of exit depth and the cause of the outflow.",
      "whatDidNotChange": "The observation does not establish an exploit, bad debt, frozen assets, halted withdrawals, a GHO peg failure, or a change to Aave contracts or governance parameters.",
      "confirmedFacts": [
        "The monitored pool is Aave v3 GHO Prime Instance on Ethereum.",
        "Deposits declined from $12,587,260 to $7,600,955 between monitor checks.",
        "The measured decline was 40%."
      ],
      "unresolved": [
        "Whether the decline reflects ordinary depositor movement, a data discontinuity, incentives, a governance change, or emerging risk.",
        "Whether current on-chain liquidity can support the memo's contemplated exit size without material slippage."
      ],
      "advisorDiligenceImplications": [
        "Recheck the venue's withdrawable liquidity and reconcile the monitor observation before treating its displayed capacity as unchanged.",
        "Review the Aave v3 memo and any client decision files referencing this specific pool; the observation alone does not justify claiming an incident."
      ],
      "followUpOn": "2026-08-27",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-c03875df-fc19-4122-a22e-3ad6704a7b25",
      "stableKey": "lido-cmc-deposit-reserve-target-easy-track",
      "version": 1,
      "eventDate": "2026-08-25",
      "publishedAt": "2026-08-26T20:23:38.059Z",
      "title": "Lido proposal would delegate deposit-reserve targeting to CMC Easy Track",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Proposal: Add Easy Track factory for Deposit Reserve Target management by CMC",
          "authority": "Lido Governance",
          "url": "https://research.lido.fi/t/proposal-add-easy-track-factory-for-deposit-reserve-target-management-by-cmc/11827",
          "documentType": "official governance proposal",
          "publishedOn": "2026-08-25"
        }
      ],
      "whatHappened": "A Lido governance proposal would add an Easy Track factory allowing the CMC 5-of-9 multisig to adjust Lido's depositsReserveTarget up to 9,600 ETH.",
      "whatChanged": "The proposal creates a concrete path to delegate recurring control over how buffered ETH is prioritized between new consensus-layer deposits and withdrawal finalization during withdrawal pressure.",
      "whatDidNotChange": "The proposal is not yet approved or executed. The current role assignment and reserve target are not shown as changed, and the proposed permission cannot transfer funds, mint, burn, or change fees.",
      "confirmedFacts": [
        "The proposed trusted caller is the CMC 5-of-9 multisig at 0x2570e0b22AD904501dfB0d49575991ACB801dD91.",
        "The proposed factory is limited to Lido.setDepositsReserveTarget(uint256).",
        "The proposed immutable maximum target is 9,600 ETH.",
        "The DAO Agent would retain the ability to set the target directly, revoke the permission, or remove the factory."
      ],
      "unresolved": [
        "Completion and findings of the planned security audit.",
        "Whether the next Aragon vote will grant BUFFER_RESERVE_MANAGER_ROLE and register the factory.",
        "The final review cadence and reporting format for CMC motions.",
        "Whether any later execution reaches Ketju's withdrawal-mechanism kill criterion."
      ],
      "advisorDiligenceImplications": [
        "Monitor the audit, Aragon vote, and any executed Easy Track motions because the delegated parameter affects withdrawal-finalization priority under stress.",
        "Do not mark the Lido withdrawal-mechanism criterion as fired while the change remains only proposed."
      ],
      "followUpOn": "2026-09-01",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-f06e2693-0d74-47f4-bc10-e83ef8435479",
      "stableKey": "aave-v3-august-2026-stablecoin-rate-adjustments",
      "version": 1,
      "eventDate": "2026-08-24",
      "publishedAt": "2026-08-26T20:24:09.082Z",
      "title": "Aave service provider proposes broad stablecoin rate repricing",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "critical",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[Risk Stewards] August 2026 - Stablecoin Interest Rate Adjustments",
          "authority": "Aave governance / TokenLogic",
          "url": "https://governance.aave.com/t/risk-stewards-august-2026-stablecoin-interest-rate-adjustments/25519",
          "documentType": "official governance proposal",
          "publishedOn": "2026-08-24"
        }
      ],
      "whatHappened": "TokenLogic proposed staged changes across Aave v3 stablecoin interest-rate curves, including Slope1 increases, lower Slope2 on X Layer, a 5.25% USDe base rate, and temporary optimal-utilization increases intended to accommodate debt migration.",
      "whatChanged": "A concrete Risk Steward execution plan now exists for broad economic changes. Its stated rationale includes competitive positioning, retaining and attracting demand, and projected market growth, which plausibly matches a written Ketju Aave kill criterion.",
      "whatDidNotChange": "The cached record does not prove that any parameter step has executed. It does not directly change the approved Ethereum sGHO vault's withdrawal mechanics, and its forecasts are disputed in the same thread.",
      "confirmedFacts": [
        "TokenLogic published the proposal on August 24, 2026.",
        "The proposal recommends Slope1 increases for 22 reserves, generally in 10-basis-point stages.",
        "It proposes setting the USDe base rate to 5.25% and standard Slope1 to 0.25%.",
        "It proposes temporary two-percentage-point optimal-utilization increases for selected USDC and USDT reserves.",
        "The proposal says execution would use Risk Steward authority and span approximately two weeks."
      ],
      "unresolved": [
        "Which parameter changes, if any, have executed on-chain.",
        "Whether the USDe yield and migration assumptions are supportable; forum respondents dispute the derivation and projected borrower behavior.",
        "Whether governance will revise, pause, or split the USDe component before execution.",
        "Whether the conduct is sufficient for an editor to treat the written kill criterion as definitively fired rather than plausibly fired."
      ],
      "advisorDiligenceImplications": [
        "Open an immediate review of the Aave v3 memo because the proposal publicly frames risk parameters partly through growth and competitive-market objectives.",
        "Do not state that rates have changed until Risk Steward transactions or reproducible on-chain state confirm execution.",
        "Assess the governance rationale separately from direct exposure: Ketju's approved sleeve is narrow, but the criterion monitors the decision process that previously produced collateral risk."
      ],
      "followUpOn": "2026-08-27",
      "previousInterpretation": "Aave v3 remained approved with limits because post-incident governance safeguards and monitoring were expected to prevent a repeat of growth-driven risk decisions.",
      "supersedesId": null
    },
    {
      "id": "event-e2004127-6093-4e08-8223-10cd555131e6",
      "stableKey": "axelar-v1-5-3-upgrade",
      "version": 1,
      "eventDate": "2026-08-23",
      "publishedAt": "2026-08-26T20:23:23.457Z",
      "title": "Axelar governance approves axelar-core v1.5.3 upgrade",
      "category": "upgrade_migration",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Axelar v1.5.3 Upgrade Proposal",
          "authority": "Axelar on-chain governance",
          "url": "https://axelarscan.io/proposal/495",
          "documentType": "on-chain governance proposal",
          "publishedOn": "2026-08-23"
        }
      ],
      "whatHappened": "Axelar on-chain governance proposal 495 passed, authorizing an upgrade of axelar-core to v1.5.3.",
      "whatChanged": "The v1.5.3 network upgrade is governance-approved. The associated official release describes a Cosmos SDK, IBC-Go and Wasmd migration plus vote-handling, queue-ordering, fee-policy and hardening changes.",
      "whatDidNotChange": "The candidate record does not establish that the upgrade has executed at a block height or that all validators are running the new binary.",
      "confirmedFacts": [
        "Axelar proposal 495 identifies axelar-core v1.5.3 as the intended upgrade.",
        "The proposal status is passed.",
        "An official v1.5.3 release build exists for networks that have not yet run the upgrade."
      ],
      "unresolved": [
        "The scheduled upgrade height and whether execution has occurred.",
        "Whether validator adoption and post-upgrade chain operation are healthy.",
        "Whether downstream integrations require configuration or compatibility review."
      ],
      "advisorDiligenceImplications": [
        "Review Axelar dependency diligence for the approved architecture and security changes before treating the new version as operative.",
        "Monitor the execution height and chain behavior; approval and release publication do not prove successful migration."
      ],
      "followUpOn": "2026-08-28",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-77c52ba7b212f01671604796",
      "stableKey": "rocket-pool:rpip-84-signaling-governance:2026-08",
      "version": 1,
      "eventDate": "2026-08-19",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "Rocket Pool pDAO approves RocketDash signaling platform and emergency replacement process",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "rocket-pool",
          "name": "Rocket Pool"
        }
      ],
      "primaryDocuments": [
        {
          "title": "pDAO Signaling Governance",
          "authority": "Rocket Pool pDAO Snapshot",
          "url": "https://snapshot.org/#/rocketpool-dao.eth/proposal/0xe856fea4f85ea5fb7488402b1073ff8cec9b9f6cec58e9173921cc5c42bbd3c3",
          "documentType": "official governance vote",
          "publishedOn": "2026-08-05"
        }
      ],
      "whatHappened": "Rocket Pool's pDAO approved RPIP-84, replacing Snapshot with RocketDash as the recognized platform for off-chain signaling votes, naming an initial lead vote administrator, and adding a narrowly scoped on-chain emergency process for changing the signaling platform or its administrators.",
      "whatChanged": "The recognized off-chain signaling venue and official vote-publishing authority were approved for replacement. Future emergency platform and administrator changes can use the specified on-chain process and then be recorded in RPIP-84.",
      "whatDidNotChange": "The vote did not alter rETH economics, node registration, oracle reporting, withdrawal mechanics, or smart-contract upgrade authority. It did not grant the emergency process authority over subjects other than the signaling platform and required administrators.",
      "confirmedFacts": [
        "The final vote recorded 11,108.35 votes for, zero against, and 1,071.97 abstaining.",
        "The 12,180.32 total score exceeded the stated 10,050 quorum.",
        "RPIP-84 designates RocketDash as the recognized platform for off-chain pDAO signaling votes.",
        "Darren Langley was designated as the initial lead vote administrator.",
        "The emergency ballot scope is limited to changing the recognized signaling platform and appointing the administrators needed to operate it."
      ],
      "unresolved": [
        "The date on which RocketDash becomes the sole operational venue was not independently observed.",
        "The final RPIP-84 record and administrator roster should be reconciled after the vote.",
        "Operational controls over RocketDash publication, authentication, availability, and archival continuity require review."
      ],
      "advisorDiligenceImplications": [
        "Update the Rocket Pool governance-control map so monitoring follows RocketDash and the recognized vote administrators rather than relying solely on Snapshot.",
        "Document the emergency platform-change path as a governance dependency and verify how advisors can authenticate official votes and historical records.",
        "No current rETH allocation limit or protocol availability change is supported solely by this governance-platform change."
      ],
      "followUpOn": "2026-08-26",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-5e14372b2fa49dd2cb6b1676",
      "stableKey": "aave-v3:low-adoption-deprecation-arfc:2026-08",
      "version": 1,
      "eventDate": "2026-08-15",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "Aave ARFC advances broad V3 reserve and deployment wind-down",
      "category": "closure_deprecation",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Low Adoption Asset Deprecation on Aave V3",
          "authority": "Aave DAO Snapshot",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0x4ec0c13baf55472ecd538a2fae4bbdb60f30c96621a97ecf4db073b3e65597c7",
          "documentType": "official governance vote",
          "publishedOn": "2026-08-11"
        }
      ],
      "whatHappened": "An Aave DAO ARFC vote closed with final support for winding down 50 low-adoption reserves, 21 matured Pendle principal tokens, and whole Aave V3 deployments on Sonic, Scroll, zkSync, Metis, Soneium, and Aptos.",
      "whatChanged": "The proposal cleared the Snapshot signaling stage and can advance toward an executable AIP. Its specified wind-down path includes freezes, supply and borrow caps reduced to 1, higher reserve factors, and possible later interest-rate or liquidation-threshold changes.",
      "whatDidNotChange": "The Snapshot result did not itself execute an AIP or alter reserve parameters. Existing collateral positions may remain open under the proposed default mechanics, and Aave V3 as a whole was not approved for shutdown.",
      "confirmedFacts": [
        "The final Snapshot result recorded 395,522.02 votes for, zero against, and zero abstaining.",
        "The individual-reserve scope covers 50 reserves and 21 matured Pendle PTs across eleven deployments.",
        "The proposal also covers whole-market deprecations on Sonic, Scroll, zkSync, Metis, Soneium, and Aptos.",
        "The default proposed mechanics freeze reserves, reduce supply and borrow caps to 1, and raise reserve factors where borrowing exists.",
        "The proposal states that further interest-rate or liquidation-threshold changes may be applied case by case."
      ],
      "unresolved": [
        "No executable AIP transaction or completed parameter change was established for this candidate.",
        "The final AIP payload, implementation sequence, and any modifications to the ARFC specification remain unresolved.",
        "Ketju or client exposure to each named reserve and deployment has not been mapped in this editorial decision."
      ],
      "advisorDiligenceImplications": [
        "Map all approved and client-held Aave V3 positions against the proposed reserve and deployment list before an AIP executes.",
        "Treat any affected reserve as a potential exit-planning issue because freezing and higher reserve factors can reduce new activity, supplier yield, and available liquidity.",
        "Review the aave-v3 memo's approved market perimeter; do not interpret this risk-surface reduction proposal as a protocol-wide safety improvement."
      ],
      "followUpOn": "2026-08-22",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-8bca5a705ffc422a860f7b9b",
      "stableKey": "morpho-blue:dao-multisig:spearbit-6-of-10",
      "version": 1,
      "eventDate": "2026-08-14",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "Morpho proposes adding Spearbit and raising the DAO multisig threshold",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "morpho-blue",
          "name": "Morpho Blue"
        },
        {
          "type": "controller",
          "id": "morpho-dao",
          "name": "Morpho DAO"
        }
      ],
      "primaryDocuments": [
        {
          "title": "MIP 133 - Add Spearbit as a DAO multisig signer and update threshold to 6/10",
          "authority": "Morpho Governance Forum (Morpho Association)",
          "url": "https://forum.morpho.org/t/mip-133-add-spearbit-as-a-dao-multisig-signer-and-update-threshold-to-6-10/2383",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-08-14"
        }
      ],
      "whatHappened": "Morpho Association proposed adding Spearbit as a tenth signer of the Ethereum DAO multisig and increasing its execution threshold to 6-of-10.",
      "whatChanged": "If approved and implemented, DAO operations would require six approvals, and Spearbit would provide paid trusted-signer services.",
      "whatDidNotChange": "No execution was confirmed. The proposal does not change Morpho Blue contracts, vault curators, market parameters, withdrawal mechanics, or user custody.",
      "confirmedFacts": [
        "The proposal would add Spearbit as a DAO multisig signer.",
        "The proposed threshold is 6-of-10.",
        "The proposed initial annual service cost is $33,000, with separately billed off-cycle and urgent work.",
        "The proposal requires approval before signer onboarding and multisig reconfiguration."
      ],
      "unresolved": [
        "The final vote outcome.",
        "Spearbit's final signer address and completed onboarding state.",
        "The executed multisig owner set and threshold.",
        "Whether the higher quorum materially affects routine or urgent execution times."
      ],
      "advisorDiligenceImplications": [
        "Monitor the vote and verify the Ethereum DAO multisig's final owners and threshold if implemented.",
        "Update the Morpho governance-control record after execution while keeping curator and vault-level controls separately assessed."
      ],
      "followUpOn": "2026-08-22",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-e1c01346adc527eee6c1d872",
      "stableKey": "grove-finance:dpau:sky-pas-configurator-admin",
      "version": 1,
      "eventDate": "2026-08-13",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "Grove proposes granting Sky PAS administrator authority over DPAU controls",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "grove-finance",
          "name": "Grove"
        },
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[August 27, 2026] - Proposed Changes to Grove for Upcoming Spell",
          "authority": "Sky Forum (Grove Labs)",
          "url": "https://forum.skyeco.com/t/august-27-2026-proposed-changes-to-grove-for-upcoming-spell/28164",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-08-13"
        }
      ],
      "whatHappened": "Grove proposed granting Sky's PAS Configurator DEFAULT_ADMIN_ROLE on Grove's DPAU AccessControls and RateLimits contracts and advancing the Uniswap V3 deposit-limit ramp.",
      "whatChanged": "If executed, PAS could alter Grove DPAU roles and rate limits without a separate Grove spell for each pre-authorized action. The Uniswap V3 deposit allowance would retain a 5 million maximum but begin replenishing at 350,000 per day.",
      "whatDidNotChange": "The proposal does not establish execution. Grove would retain its administrator role and revocation path; the Uniswap deposit maximum, withdrawal settings, swap settings, and facet code would remain unchanged.",
      "confirmedFacts": [
        "The proposed AccessControls contract is 0x4F6d1704700cd494DD4cd9bF59c0C39DA1Bc9164.",
        "The proposed RateLimits contract is 0xE016Ae733A77Ba77E7907aAA749394Fc5e75C0e1.",
        "The proposed PAS Configurator is 0xb7E61Df6CAb0A51E9A5dab1A7DD3f942dDe5b929.",
        "The deposit maximum would remain 5 million while its slope would rise from zero to 350,000 per day.",
        "Grove is identified as the first Prime proposed to adopt PAS."
      ],
      "unresolved": [
        "The Grove vote outcome and final August 27 spell contents.",
        "The final PAS operating parameters, timelock, and ceilings.",
        "Whether the pending additional PAS audit was completed before execution.",
        "The executed role state and effective Uniswap rate limits."
      ],
      "advisorDiligenceImplications": [
        "Review the Sky memo's Grove allocator-control map because execution would introduce a Sky-operated administrator into Grove's allocation stack.",
        "Verify the executed role grants, PAS bounds, timelock, ceilings, revocation path, and rate limits before treating the new control model as operative.",
        "Do not infer that the proposal approves Grove or any underlying asset exposure."
      ],
      "followUpOn": "2026-08-28",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-f60b00737be21df7a0543f5b",
      "stableKey": "aave-v3-governance-emergency-guardian-signer-rotation-2026",
      "version": 1,
      "eventDate": "2026-08-12",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "Aave proposes Governance Emergency Guardian signer rotation",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Aave Governance Emergency Guardian: Signer Rotation",
          "authority": "Aave Labs via Aave governance",
          "url": "https://governance.aave.com/t/arfc-aave-governance-emergency-guardian-signer-rotation/25469",
          "documentType": "official governance proposal",
          "publishedOn": "2026-08-12"
        }
      ],
      "whatHappened": "Aave Labs published an ARFC proposing a new nine-address signer roster for the Governance Emergency Guardian.",
      "whatChanged": "A concrete signer-rotation proposal now exists for the multisig that can cancel malicious, erroneous, or unsafe governance proposals and payloads. No operative owner rotation is established by this record.",
      "whatDidNotChange": "The proposal retains the existing 5-of-9 threshold, Governance Emergency Guardian Safe addresses, assigned cancellation permissions, and exercise conditions. It does not show Snapshot approval, AIP approval, or executed Safe owner transactions.",
      "confirmedFacts": [
        "The proposed guardian remains a 5-of-9 multisig.",
        "The proposal identifies nine replacement or retained signing addresses.",
        "Existing Safe addresses and Governance and PayloadsController permissions are proposed to remain unchanged.",
        "A chain-by-chain execution manifest is expected before implementation."
      ],
      "unresolved": [
        "Whether the ARFC will receive favorable community sentiment and Snapshot approval.",
        "Whether every proposed signer will confirm operational readiness.",
        "The final chain-by-chain execution manifest and resulting on-chain Safe owner sets."
      ],
      "advisorDiligenceImplications": [
        "Keep the Aave v3 memo unchanged while the proposal remains unapproved and unexecuted.",
        "Monitor the Snapshot, execution manifest, and each Safe owner-management transaction.",
        "Reopen the control review if implementation changes a Safe address, threshold, cancellation authority, or other permission beyond the stated signer rotation."
      ],
      "followUpOn": "2026-08-21",
      "previousInterpretation": "The Aave v3 memo treats this as a signer-only proposal that does not fire its emergency-powers kill criterion because the threshold, Safe addresses, and powers remain unchanged.",
      "supersedesId": null
    },
    {
      "id": "event-event-draft-9ecbf0c49861173b151f5899",
      "stableKey": "defi-saver:aave-v3-v4-migration-liquidation-protection:2026-08",
      "version": 1,
      "eventDate": "2026-08-11",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "DeFi Saver launches Liquidation Protection and Aave v3-to-v4 migration workflows",
      "category": "launch_access",
      "posture": "launched",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "product",
          "id": "defi-saver-asset-management",
          "name": "DeFi Saver Asset Management"
        },
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "DeFi Saver Newsletter: August 2026",
          "authority": "DeFi Saver",
          "url": "https://blog.defisaver.com/defi-saver-newsletter-august-2026/",
          "documentType": "official_product_update",
          "publishedOn": "2026-08-11"
        }
      ],
      "whatHappened": "DeFi Saver launched a minimal Liquidation Protection automation across supported lending protocols and a dedicated workflow for migrating Aave v3 positions to Aave v4 in one transaction.",
      "whatChanged": "The approved automation dependency can now execute an additional collateral-sale-and-repayment strategy and a more accessible cross-version Aave migration path.",
      "whatDidNotChange": "The launch does not approve Aave v4, any migrated asset, or the underlying leveraged position. DeFi Saver's dependency-only limits and each base protocol's separate verdict remain unchanged.",
      "confirmedFacts": [
        "Liquidation Protection was described as live on August 10, 2026.",
        "The feature monitors supported positions and uses the minimum stated collateral amount needed to repay part of a debt when configured thresholds are reached.",
        "The Aave v3-to-v4 migration tool was described as live and capable of migrating a position in one transaction.",
        "The official update lists Aave, Morpho, Compound, Fluid, Spark, and Maker among supported Liquidation Protection protocols."
      ],
      "unresolved": [
        "The exact contracts, authorization scopes, trigger defaults, and execution slippage for the new automation.",
        "Which Aave v3 assets and positions are eligible for migration.",
        "Whether any approved or client-held position enabled either feature.",
        "The failure and rollback behavior if a migration or protection transaction cannot complete."
      ],
      "advisorDiligenceImplications": [
        "Inventory client automation permissions before enabling the new strategy and verify its collateral-sale, slippage, and trigger settings.",
        "Do not infer approval of Aave v4 or any destination market from DeFi Saver's interface support.",
        "Review operational procedures for positions migrated away from the separately assessed Aave v3 perimeter."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-20b5a4cf4ab1993d9f490596",
      "stableKey": "aave-v3:pt-ausd-monad-arfc:2026-08",
      "version": 1,
      "eventDate": "2026-08-09",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "Aave ARFC advances PT-AUSD collateral proposal for the Monad V3 instance",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Onboard PT-AUSD-8OCT2026 to Aave V3 Monad Instance",
          "authority": "Aave DAO Snapshot",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0x1d5029f1b99b62843590e28d027a1a5aa21f4fe19f175284197c58779db14027",
          "documentType": "official governance vote",
          "publishedOn": "2026-08-05"
        }
      ],
      "whatHappened": "An Aave DAO ARFC vote passed for proposed onboarding of PT-AUSD-8OCT2026 to the Aave V3 Monad instance, with specified token addresses, a capped linear-discount oracle, and a proposed high-LTV e-mode configuration.",
      "whatChanged": "The proposal cleared the Snapshot signaling stage and can advance to an executable AIP. The proposal would introduce a short-dated, multi-component Pendle principal token as collateral in a dedicated Agora-stablecoin e-mode category.",
      "whatDidNotChange": "The Snapshot result did not list the asset on-chain or activate the proposed 93% maximum LTV and 95% liquidation threshold. The asset is not part of Ketju's approved Ethereum Aave exposure.",
      "confirmedFacts": [
        "The final vote recorded 392,114.33 votes for, zero against, and 10.67 abstaining.",
        "The proposed asset is PT-AUSD-8OCT2026 on Monad, maturing October 8, 2026.",
        "The proposed oracle applies a linear discount to a capped AUSD reference and decays toward par at maturity.",
        "The proposal specifies a 20 million unit supply cap and no ordinary borrowing.",
        "The proposed e-mode parameters include 93% maximum LTV and a 95% liquidation threshold."
      ],
      "unresolved": [
        "No executable AIP or completed on-chain listing was established.",
        "Final implementation timing and any changed risk parameters remain unresolved.",
        "The proposal's fixed-one-dollar AUSD reference, Pendle-market exit liquidity, and maturity handling require separate diligence."
      ],
      "advisorDiligenceImplications": [
        "Monitor for an AIP but do not treat PT-AUSD as approved or live based on the Snapshot vote.",
        "If executed, review the multi-wrap collateral structure, the capped AUSD oracle assumption, e-mode leverage, maturity transition, and proposed-size exit liquidity.",
        "Keep the Monad proposal outside the existing Ethereum-only Aave watchlist exposure unless a separate perimeter decision is completed."
      ],
      "followUpOn": "2026-08-21",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-5e781973e36779181d1a873a",
      "stableKey": "sky-lending:osero-sparklend-usds-crr:100-to-25",
      "version": 1,
      "eventDate": "2026-08-07",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "Sky proposes reducing Osero's SparkLend USDS capital ratio to 25%",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Atlas Edit Weekly Cycle Proposal - Week Of 2026-08-10",
          "authority": "Sky Forum (Core GovOps)",
          "url": "https://forum.skyeco.com/t/atlas-edit-weekly-cycle-proposal-week-of-2026-08-10/28155",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-08-07"
        }
      ],
      "whatHappened": "Sky Core GovOps proposed reducing the Capital Ratio Requirement for Osero's Ethereum SparkLend USDS instance from 100% to 25%.",
      "whatChanged": "If approved, the instance's required capital buffer would fall by 75 percentage points, permitting greater reliance on Sky-supplied capital relative to Osero capital.",
      "whatDidNotChange": "The cached record does not establish ratification, an executive payload, execution, or the resulting live exposure. Other instance and protocol parameters were not shown as changing.",
      "confirmedFacts": [
        "The current stated Capital Ratio Requirement is 100%.",
        "The proposed requirement is 25%.",
        "The proposal was triggered for the weekly Atlas-edit process.",
        "The same proposal also documents a 5% tolerance for maximum-exposure overruns caused solely by accrued interest."
      ],
      "unresolved": [
        "The final governance outcome and effective Atlas text.",
        "The risk analysis supporting the reduction.",
        "The instance's live exposure, Osero capital, and post-change loss-allocation profile.",
        "Whether a coordinated on-chain spell was required or executed."
      ],
      "advisorDiligenceImplications": [
        "Review the Sky backing and allocator-risk assessment if the reduction becomes operative.",
        "Verify the final capital ratio, instance exposure, and loss-allocation mechanics before incorporating the change into the memo.",
        "Do not treat the proposal as evidence that Osero or SparkLend is approved."
      ],
      "followUpOn": "2026-08-21",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-81c8f88461ebd8208e0f147f",
      "stableKey": "sky-lending:treasury-management-target-state:2026-08",
      "version": 1,
      "eventDate": "2026-08-07",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "Sky proposes activating its full Treasury Management Function waterfall",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Treasury Management Function (TMF) Configurations",
          "authority": "Sky Forum (BA Labs and Core Facilitator)",
          "url": "https://forum.skyeco.com/t/treasury-management-function-tmf-configurations/28153",
          "documentType": "official_parameter_recommendation",
          "publishedOn": "2026-08-07"
        }
      ],
      "whatHappened": "BA Labs stated that the transition condition for Sky's full Treasury Management Function had been met and recommended August 13 spell parameters implementing the revenue-allocation waterfall.",
      "whatChanged": "If executed, July net revenue would fund security and maintenance, retain capital for Sky reserves, and split remaining capital among USDS staking rewards, SKY buybacks distributed to stakers, and buyback-and-burn treatment.",
      "whatDidNotChange": "The record confirms recommendation and Core Facilitator acceptance for inclusion but does not prove executive-vote approval or spell execution. It does not change the sUSDS redemption mechanism or directly state a new Sky Savings Rate.",
      "confirmedFacts": [
        "July net revenue was calculated at 10,517,426 USDS.",
        "Aggregate Backstop Capital was reported below its 150 million USDS Turbo-Fill Floor, producing a 50% Step 2 retention rate.",
        "The proposed Step 3 allocation is 45% USDS staking rewards, 45% buybacks distributed as SKY rewards, and 10% buyback-and-burn treatment.",
        "The proposed splitter hop and rewards duration are both 3,748 seconds.",
        "The Core Facilitator confirmed the values for inclusion in the next executive vote."
      ],
      "unresolved": [
        "The executive-vote outcome and execution transaction.",
        "The resulting live splitter, vesting, and rewards parameters.",
        "Whether the reported reserve and revenue inputs were independently reconciled on-chain.",
        "The effect of the new waterfall on future sUSDS subsidy and reserve coverage."
      ],
      "advisorDiligenceImplications": [
        "Review Sky's reserve, subsidy, and cash-allocation assumptions if the configuration executes.",
        "Verify live parameters and subsequent reserve coverage before updating the memo's economic-control description.",
        "Do not present proposed SKY or USDS staking distributions as current until execution is verified."
      ],
      "followUpOn": "2026-08-21",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-8eb8ba0bc5402d3dacc64f64",
      "stableKey": "sky-lending:sbe-beam:august-2026-launch-proposal",
      "version": 1,
      "eventDate": "2026-08-06",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "Sky proposes delegated Smart Burn Engine parameter control through SBE BEAM",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        },
        {
          "type": "controller",
          "id": "sky-sbe-beam",
          "name": "Sky Smart Burn Engine BEAM"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Smart Burn Engine Bounded External Access Module (SBE BEAM) launch",
          "authority": "Sky Forum (Sidestream, BA Labs, Soter Labs, and Core Facilitator)",
          "url": "https://forum.skyeco.com/t/smart-burn-engine-bounded-external-access-module-sbe-beam-launch/28149",
          "documentType": "official_technical_scope",
          "publishedOn": "2026-08-06"
        }
      ],
      "whatHappened": "Sky contributors proposed initializing SBE BEAM and FarmOwner contracts so a permissioned operator could adjust Smart Burn Engine and staking-reward timing parameters outside the normal core-spell cadence.",
      "whatChanged": "If executed, the operator could jointly change kbump, burn, hop, and rewardsDuration within configured throughput, delay, and cooldown bounds.",
      "whatDidNotChange": "The cached record identifies an intended August 13 spell but does not prove initialization or execution. The Pause Proxy would remain administrator, and the operator's discretion would remain contractually bounded.",
      "confirmedFacts": [
        "The proposed SBEBeam address is 0xc8b61d211D3D03A630Fb09199E17953a8c9749a9.",
        "The proposed FarmOwner address is 0xA3d3A2e9Fe5d0901D720D5382E4a7eA12D4E2b0e.",
        "The permissioned operator address supplied by Soter Labs is 0x869294B42B80f99CF3Bdac0F44abddAd6cD41330.",
        "BA Labs recommended a 12,000 USDS maximum kbump, 550-second minimum hop, 350 million USDS annual maximum rate, and 30-minute cooldown.",
        "The contracts were described as pre-deployed and based on an audited commit, but initialization was assigned to a future core spell."
      ],
      "unresolved": [
        "Whether the August 13 executive spell passed and executed.",
        "The final live operator set, bounds, and contract permissions.",
        "Whether FarmOwner and SBE BEAM ownership was transferred and initialized exactly as proposed.",
        "How frequently the delegated operator uses the new authority and how changes are monitored."
      ],
      "advisorDiligenceImplications": [
        "Review Sky's delegated-authority and economic-control map if SBE BEAM becomes operative.",
        "Verify the executed initialization, operator list, bounds, Pause Proxy authority, and change history before relying on the new control model.",
        "Monitor whether delegated changes materially affect reserve retention, buybacks, or staking distributions supporting the broader Sky balance sheet."
      ],
      "followUpOn": "2026-08-21",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-922238cb5ac382a23757d082",
      "stableKey": "sky-lending:osero-prysm-a-debt-ceiling:5m-to-10m",
      "version": 1,
      "eventDate": "2026-08-06",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "Osero proposes doubling ALLOCATOR-PRYSM-A debt capacity",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Osero — Requested Changes to Allocator Vault Parameters",
          "authority": "Sky Forum (Osero, BA Labs, and Soter Labs)",
          "url": "https://forum.skyeco.com/t/osero-requested-changes-to-allocator-vault-parameters/28147",
          "documentType": "official_parameter_proposal",
          "publishedOn": "2026-08-06"
        }
      ],
      "whatHappened": "Osero requested that Sky Core double ALLOCATOR-PRYSM-A's maximum debt ceiling and target available debt.",
      "whatChanged": "If executed, the allocator's maximum USDS capacity would rise from 5 million to 10 million and immediately targetable debt would rise from 1 million to 2 million.",
      "whatDidNotChange": "The 24-hour ceiling-increase cooldown would remain unchanged, and the cached record does not establish executive-vote approval or execution.",
      "confirmedFacts": [
        "The requested maximum debt ceiling is 10 million USDS, up from 5 million.",
        "The requested target available debt is 2 million USDS, up from 1 million.",
        "The requested cooldown remains 86,400 seconds.",
        "BA Labs supported the requested values, and Soter Labs requested their inclusion in a future executive vote."
      ],
      "unresolved": [
        "Whether the changes were included in an executive spell.",
        "The final executed parameter state.",
        "The asset strategy, loss boundary, and balance-sheet classification of the additional capacity.",
        "Resulting utilization and exposure after any execution."
      ],
      "advisorDiligenceImplications": [
        "Monitor the executive spell and determine whether expanded allocator capacity changes the Sky memo's backing or counterparty assessment.",
        "Do not treat the requested limits as operative until executed state is verified."
      ],
      "followUpOn": "2026-08-21",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-a981af72ff6356bd92b86ff4",
      "stableKey": "sky-lending:msc-5-10-accounting-reconciliation:2026-08",
      "version": 1,
      "eventDate": "2026-08-06",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "Sky confirms Prime Agent settlement and oracle-accounting corrections",
      "category": "economic_change",
      "posture": "confirmed",
      "materiality": "material",
      "evidenceState": "mixed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Settlement Reconciliation - MSC #5–#10 (January–June 2026)",
          "authority": "Sky Forum (Soter Labs)",
          "url": "https://forum.skyeco.com/t/settlement-reconciliation-msc-5-10-january-june-2026/28150",
          "documentType": "official_accounting_reconciliation",
          "publishedOn": "2026-08-06"
        }
      ],
      "whatHappened": "Sky's settlement operator published a reconciliation correcting prior Prime Agent revenue and Sky-share calculations after identifying methodology, data-source, block-timing, and oracle-feed errors.",
      "whatChanged": "The reconciliation adds approximately 820,320 USDS of net Prime Agent revenue and 297,559 USDS of net Sky share to later settlement calculations, while replacing or correcting several accounting inputs.",
      "whatDidNotChange": "The report does not identify a loss of client USDS or impairment of sUSDS redemption. It does not establish that every historical accounting case is resolved, and two Distribution Rewards cases remain outside scope.",
      "confirmedFacts": [
        "Spark corrections included previously missed aToken yield, a phantom idle-stablecoin outflow, a subsidized-borrow benchmark change, and data-source revisions.",
        "Grove corrections included fabricated T-bill series rows and an ACRDX Chronicle consumer feed that continued returning a stale value after its last update on May 7, 2026.",
        "Obex, Skybase, and Keel calculations were affected by an end-of-month block pinned approximately 2.8 hours early.",
        "The reconciliation reports approximately 820,320 USDS owed to Prime Agents and 297,559 USDS of net additional Sky share.",
        "Morpho-market and certain frontend Distribution Rewards cases remain for future reconciliation."
      ],
      "unresolved": [
        "The final correction for the two excluded Distribution Rewards cases.",
        "Whether every corrective mint and transfer was executed as calculated.",
        "The duration and financial effect of the stale Chronicle feed outside the reported settlement calculations.",
        "Whether the accounting-control changes prevent recurrence across all Prime Agents."
      ],
      "advisorDiligenceImplications": [
        "Review the Sky memo's allocator reporting and oracle-accounting controls because the errors affected multiple months and Prime Agents.",
        "Verify corrective execution and later reconciliation reports rather than treating the published calculations as settled on-chain state.",
        "Continue monitoring for any evidence that accounting errors affected backing, reserve coverage, or client redemption capacity."
      ],
      "followUpOn": "2026-09-10",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-bef2606ef1a3a6bf81aa3d1a",
      "stableKey": "sky-lending:sky-vaults-launch:2026-08-06",
      "version": 1,
      "eventDate": "2026-08-06",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "Sky.money adds five live Morpho-based stablecoin vaults outside the existing savings exposure",
      "category": "launch_access",
      "posture": "launched",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        }
      ],
      "primaryDocuments": [
        {
          "title": "What Are Sky Vaults?",
          "authority": "Sky.money / Skybase International",
          "url": "https://sky.money/blog/what-are-sky-vaults",
          "documentType": "official product documentation",
          "publishedOn": "2026-08-07"
        }
      ],
      "whatHappened": "Sky.money documented five live non-custodial vaults accepting USDS, USDC, or USDT and deploying deposits into defined Morpho lending strategies. The source reported $121.7 million deployed across the vaults as of August 6.",
      "whatChanged": "The Sky.money interface now exposes strategy-driven lending vaults alongside the Sky Savings Rate. Users can take collateral, oracle, smart-contract, utilization, and withdrawal-liquidity risk that is not present in the same form in a direct sUSDS savings position.",
      "whatDidNotChange": "The launch did not change the Sky Savings Rate, the USDS-to-sUSDS accounting mechanism, or the existing Ketju approval, which covers only Ethereum USDS and sUSDS. Skybase states that it operates the interface and does not control the underlying protocol or vault strategies.",
      "confirmedFacts": [
        "Five vaults were described as live: USDS Flagship, USDT Savings, and USDS, USDC, and USDT Risk Capital vaults.",
        "Each vault accepts a specified stablecoin and deploys it into a defined Morpho-based strategy.",
        "The source reported $121.7 million deployed across Sky Vaults as of August 6, 2026.",
        "Withdrawals depend on vault liquidity and can be delayed by high utilization in underlying lending markets.",
        "Vault yield is variable, market-driven, and may be below the Sky Savings Rate."
      ],
      "unresolved": [
        "The exact contract addresses, curators, oracle configurations, caps, and live liquidity for each vault were not reconciled in this candidate review.",
        "No separate Ketju approval or position limit exists for any of the five vaults.",
        "The degree to which each vault depends specifically on Morpho Blue rather than another Morpho component was not independently resolved."
      ],
      "advisorDiligenceImplications": [
        "Do not extend the existing sky-lending approval for Ethereum USDS/sUSDS to any Sky Vault.",
        "Create separate diligence for each vault before advisor use, including curator authority, collateral and oracle mapping, withdrawal-liquidity testing, and proposed-size exits.",
        "Ensure client and interface controls distinguish direct sUSDS savings exposure from the materially different Morpho vault exposures."
      ],
      "followUpOn": "2026-08-28",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-02070e9ba719ad3577520cf3",
      "stableKey": "aave-gho-stewards-2-of-3-signer-update-2026",
      "version": 1,
      "eventDate": "2026-08-05",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "Aave proposes 2-of-3 service-provider control for GHO Stewards",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] GHO Stewards Signer Update",
          "authority": "TokenLogic via Aave governance",
          "url": "https://governance.aave.com/t/arfc-gho-stewards-signer-update/25452",
          "documentType": "official governance proposal",
          "publishedOn": "2026-08-08"
        }
      ],
      "whatHappened": "TokenLogic published an ARFC proposing that the GHO Risk Council Safe move from four individual signers with a 3-of-4 threshold to entity Safes controlled by Aave Labs, LlamaRisk, and TokenLogic with a 2-of-3 threshold.",
      "whatChanged": "The proposal creates a concrete path to lower the GHO Steward signing threshold and replace individual signing addresses with nested service-provider entity Safes. The candidate does not establish approval or execution.",
      "whatDidNotChange": "The GHO Risk Council Safe address would remain unchanged, as would the Steward contract role references and governance-defined bounds on Steward actions. No AIP is proposed because implementation would be a Safe owner-management transaction.",
      "confirmedFacts": [
        "The current configuration is described as 3-of-4 and the proposed configuration as 2-of-3.",
        "The proposed signer entities are Aave Labs, LlamaRisk, and TokenLogic.",
        "The GHO Risk Council Safe address is proposed to remain 0x8513e6F37dBc52De87b166980Fa3F50639694B60.",
        "The Steward contracts would continue referencing the same Safe address."
      ],
      "unresolved": [
        "Whether the ARFC will pass Snapshot.",
        "The internal signer thresholds and controls of each proposed entity Safe at execution time.",
        "Whether the current Council signers will execute the owner and threshold changes exactly as proposed.",
        "What additional coordination or segregation controls govern sensitive 2-of-3 Steward actions."
      ],
      "advisorDiligenceImplications": [
        "Monitor the Snapshot and the Safe owner-management transaction before treating the change as operative.",
        "If executed, review the Aave v3 memo's GHO control layer because two organizations rather than three individual signers could authorize bounded parameter actions.",
        "Document the nested entity-Safe thresholds and signer independence before deciding whether the current sleeve cap remains appropriate.",
        "Do not restrict the approved Ethereum GHO/sGHO position solely on this unapproved proposal."
      ],
      "followUpOn": "2026-08-22",
      "previousInterpretation": "The existing Aave v3 memo recognizes governance and steward controls but does not incorporate an executed 2-of-3 entity-Safe configuration for the GHO Stewards.",
      "supersedesId": null
    },
    {
      "id": "event-event-draft-19a6c64d3240636d0d9904f9",
      "stableKey": "axelar:moonbeam-deactivation:2026-08",
      "version": 1,
      "eventDate": "2026-08-04",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "Axelar governance executes Moonbeam connection deactivation",
      "category": "closure_deprecation",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Deactivate Moonbeam on nexus",
          "authority": "Axelar on-chain governance",
          "url": "https://axelarscan.io/proposal/494",
          "documentType": "executed on-chain governance proposal",
          "publishedOn": "2026-08-04"
        }
      ],
      "whatHappened": "Axelar governance proposal 494 passed and executed a Nexus DeactivateChainRequest for Moonbeam. Axelar's Nexus state reports the Moonbeam connection as inactive.",
      "whatChanged": "Moonbeam is no longer an active Axelar Nexus connection, removing that route from Axelar's available cross-chain perimeter until a separate reactivation action occurs.",
      "whatDidNotChange": "The event did not establish an exploit of Axelar's validator consensus, threshold-signature, or gateway-contract layer. Other Axelar connections and the protocol's consensus thresholds were not changed by this proposal.",
      "confirmedFacts": [
        "Proposal 494 was submitted and began voting on August 1, 2026.",
        "Voting ended on August 4 with proposal status PASSED, 157,176,988,734,355 yes units, and no negative votes.",
        "The proposal message was an Axelar Nexus DeactivateChainRequest naming Moonbeam.",
        "The proposal record contains no failed execution reason.",
        "Axelar Nexus state reports Moonbeam activated=false."
      ],
      "unresolved": [
        "The operational reason for the deactivation is not stated in the proposal metadata.",
        "The treatment of in-flight transfers and any user-facing recovery process was not specified.",
        "No reactivation conditions or timetable were supplied."
      ],
      "advisorDiligenceImplications": [
        "Remove Moonbeam as an assumed available Axelar route in dependency and exit-planning maps.",
        "Identify any approved or client-held position whose entry, exit, or recovery path depended on Axelar's Moonbeam connection.",
        "Review integration-specific continuity controls; Axelar approval does not certify that an affected downstream route remains usable."
      ],
      "followUpOn": "2026-08-25",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-bfcbcce9e135bd2dffa58540",
      "stableKey": "ccip:wbtc-migration-selection:2026-08",
      "version": 1,
      "eventDate": "2026-08-04",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "BitGo selects Chainlink CCIP for a planned WBTC cross-chain migration",
      "category": "upgrade_migration",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "other",
          "id": "ccip",
          "name": "Chainlink CCIP"
        }
      ],
      "primaryDocuments": [
        {
          "title": "BitGo Selects Chainlink CCIP as Exclusive Cross-Chain Infrastructure Provider for WBTC, Migrating Away From Legacy Solution",
          "authority": "BitGo",
          "url": "https://www.bitgo.com/resources/blog/bitgo-selects-chainlink-ccip-for-wbtc/",
          "documentType": "official issuer announcement",
          "publishedOn": "2026-08-04"
        }
      ],
      "whatHappened": "BitGo selected Chainlink CCIP as the exclusive cross-chain infrastructure provider for WBTC and stated that it plans to migrate WBTC away from its legacy solution. BitGo also plans to default future issued assets to CCIP.",
      "whatChanged": "CCIP became BitGo's selected interoperability standard for the planned WBTC migration, materially expanding the prospective use of this watched dependency and introducing a unified CCT model with issuer-managed risk parameters.",
      "whatDidNotChange": "The announcement did not confirm that WBTC routes had migrated, that CCIP-backed WBTC transfers were live, or that the legacy solution had been retired. BitGo retains ownership and issuer control over token deployments, and this event does not approve WBTC as a Ketju asset.",
      "confirmedFacts": [
        "BitGo selected Chainlink CCIP as its exclusive cross-chain infrastructure provider.",
        "The announced scope includes WBTC and future BitGo-issued assets.",
        "BitGo stated that it plans to migrate WBTC away from its legacy cross-chain solution.",
        "The planned design uses Chainlink's Cross-Chain Token standard with issuer-managed risk parameters and security controls.",
        "BitGo stated that it retains ownership of token deployments and can add security controls."
      ],
      "unresolved": [
        "No deployed WBTC CCIP lane, contract registry, supported-chain list, or first successful transfer was established.",
        "The migration schedule and retirement date for the legacy solution were not stated.",
        "The live CCIP Risk Management Network configuration and issuer-controlled rate limits for each WBTC route remain unresolved.",
        "The source's WBTC value figure was issuer-supplied and was not independently reconciled."
      ],
      "advisorDiligenceImplications": [
        "Review the ccip dependency memo for the substantially larger prospective WBTC integration and its issuer-controlled configuration.",
        "Do not treat the WBTC migration as executed until deployed addresses, supported routes, configuration, and live transfer evidence are available.",
        "A CCIP dependency approval does not approve WBTC or remove the need to review BitGo custody, redemption, token-control, and per-chain route risks."
      ],
      "followUpOn": "2026-08-31",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-23d6881ae1d33f56426756fa",
      "stableKey": "sky-lending:spark-liquidity-layer:usdg-rlusd-pools-2026-08",
      "version": 1,
      "eventDate": "2026-08-03",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "Spark proposes USDG and RLUSD liquidity integrations",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        },
        {
          "type": "protocol",
          "id": "sparklend",
          "name": "SparkLend"
        },
        {
          "type": "protocol",
          "id": "spark-liquidity-layer",
          "name": "Spark Liquidity Layer"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[August 13, 2026] Proposed Changes to Spark for Upcoming Spell",
          "authority": "Sky Forum (Phoenix Labs, Spark Risk Council, and BA Labs)",
          "url": "https://forum.skyeco.com/t/august-13-2026-proposed-changes-to-spark-for-upcoming-spell/28135",
          "documentType": "official_spell_proposal",
          "publishedOn": "2026-08-03"
        }
      ],
      "whatHappened": "Phoenix Labs proposed adding USDG/USDS and RLUSD/USDS Uniswap V4 liquidity positions, an RLUSD/USDC Curve swap route, recurring SparkLend reserve claims, and a 1,756,359 USDS buyback transfer.",
      "whatChanged": "If executed, Spark would gain new USDG and RLUSD issuer, depeg, pool, and planner-execution exposure under replenishing deposit and swap limits.",
      "whatDidNotChange": "The record does not establish Snapshot passage or spell execution. No Spark contract would be deployed, upgraded, or repointed, and the proposed pools would use the existing ALM Controller.",
      "confirmedFacts": [
        "Each proposed Uniswap V4 pool has a 10 million deposit maximum and unlimited withdrawals.",
        "The USDG pool's proposed deposit slope is 100 million per day and swap slope is 200 million per day.",
        "The RLUSD pool's proposed deposit slope is 50 million per day and swap slope is 100 million per day.",
        "The Curve RLUSD/USDC integration is swap-only, with a 5 million maximum, 25 million-per-day slope, and 0.1% maximum slippage.",
        "The Spark Risk Council and BA Labs supported advancing the proposed items to voting.",
        "The recurring buyback transfer is proposed at 1,756,359 USDS."
      ],
      "unresolved": [
        "Snapshot outcomes and final executive-spell execution.",
        "The final live pool and rate-limit configuration.",
        "Actual cumulative USDG and RLUSD inventory and available exit liquidity.",
        "Whether the buyback calculation's treatment of accrued but unrealized user yield was reconciled with the Atlas definition.",
        "The financial effect of reserve claims and new stablecoin concentration on Sky backing."
      ],
      "advisorDiligenceImplications": [
        "Review the Sky dependency and backing map if the spell executes because new stablecoin issuer and pool exposures would enter Spark's allocation path.",
        "Keep the rejected SparkLend and Spark Liquidity Layer conclusions unchanged unless their stated reopen criteria are independently satisfied.",
        "Verify actual positions, utilization, rate limits, withdrawal capacity, and executed buyback transfer after governance action."
      ],
      "followUpOn": "2026-08-21",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-b06f32e5e67cde8b4a1c34a0",
      "stableKey": "sky-atlas-sbe-beam-and-uniswap-controller-functions",
      "version": 1,
      "eventDate": "2026-07-31",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Sky proposes delegated Smart Burn Engine controls and new Uniswap functions",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Atlas Edit Weekly Cycle Proposal - Week Of 2026-08-03",
          "authority": "Sky",
          "url": "https://forum.skyeco.com/t/atlas-edit-weekly-cycle-proposal-week-of-2026-08-03/28131",
          "documentType": "official governance proposal",
          "publishedOn": "2026-07-31"
        }
      ],
      "whatHappened": "Sky's weekly Atlas proposal would create a bounded external-access module for the Smart Burn Engine, delegate parameter authority to a 4-of-6 operator multisig, and add Uniswap v3 liquidity and swap functions to Diamond PAU controllers.",
      "whatChanged": "The proposal defines a new no-executive-vote control path for kbump, hop, and burn settings and expands controller capabilities available to Prime Agents.",
      "whatDidNotChange": "The proposal was not yet approved or executed. Existing Smart Burn Engine authority and controller functions remained operative pending governance action.",
      "confirmedFacts": [
        "The proposed operator is a whitelisted 4-of-6 multisig.",
        "Proposed bounds include a 12,000 USDS maximum kbump, 550-second minimum hop, and 350 million USDS annual maximum rate.",
        "The proposed burn setting can range from 0% to 100%.",
        "The Atlas edit would add Uniswap v3 add-liquidity, remove-liquidity, and swap controller functions."
      ],
      "unresolved": [
        "Whether governance approved and implemented the Atlas edit.",
        "A documented tension between the existing parameter-governance text and the proposed multisig's 0%-100% burn authority.",
        "The final deployed contracts, bounds, and operator membership."
      ],
      "advisorDiligenceImplications": [
        "Review the Sky memo's administrator and delegated-authority map if the proposal became operative.",
        "Verify whether inherited Uniswap capabilities or burn discretion affect any approved or client-used Sky product before relying on existing control assumptions."
      ],
      "followUpOn": "2026-08-10",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-bb27a57ac225bcca6f8977b1",
      "stableKey": "sky-morpho-pt-susds-usds-market-launch",
      "version": 1,
      "eventDate": "2026-07-31",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "PT-sUSDS becomes live Morpho collateral with Sky vault allocation",
      "category": "launch_access",
      "posture": "launched",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        },
        {
          "type": "protocol",
          "id": "morpho-blue",
          "name": "Morpho Blue"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Using PT-sUSDS as Collateral on Morpho Vaults",
          "authority": "Sky",
          "url": "https://sky.money/blog/advanced-strategies-ptsusds-morpho",
          "documentType": "official product update",
          "publishedOn": "2026-07-31"
        }
      ],
      "whatHappened": "A Morpho market went live using PT-sUSDS as collateral and USDS as the loan asset, while a Sky.money-curated USDS vault began adding an allocation to that market.",
      "whatChanged": "PT-sUSDS can now support variable-rate USDS borrowing and leveraged looping, and the curated vault can route depositor USDS into the new market.",
      "whatDidNotChange": "The market is outside Sky.money's control and is not a Sky Protocol primitive. The source does not show that any Ketju-approved or client-held Morpho vault allocated to it.",
      "confirmedFacts": [
        "A live Morpho market accepts PT-sUSDS collateral and lends USDS.",
        "The collateral retains its fixed-rate maturity exposure while the USDS borrowing cost is variable.",
        "Sky.money said its USDS Flagship Vault was adding an allocation to the market.",
        "Looping increases loan-to-value and liquidation risk."
      ],
      "unresolved": [
        "The market's LLTV, oracle, liquidation penalty, caps, utilization, and liquidity.",
        "The amount and effective time of the curated-vault allocation.",
        "Whether any approved or client-held vault touches the market.",
        "The early-exit liquidity available before PT-sUSDS maturity."
      ],
      "advisorDiligenceImplications": [
        "Treat the PT-sUSDS market and looping strategy as unapproved until separately underwritten.",
        "Check approved Morpho-vault allocations for exposure to PT-sUSDS and apply off-list-market controls if applicable.",
        "Review the Sky memo's integration perimeter without attributing third-party Morpho controls to Sky."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-cbaab8ca59ec507bc34b9f1a",
      "stableKey": "rocket-pool-saturn-2-rpip-86-2026-07-30",
      "version": 1,
      "eventDate": "2026-07-30",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Rocket Pool outlines proposed Saturn 2 withdrawal, penalty, and economic changes",
      "category": "governance",
      "posture": "proposed",
      "materiality": "critical",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "rocket-pool",
          "name": "Rocket Pool"
        }
      ],
      "primaryDocuments": [
        {
          "title": "RPIP-86: Saturn 2 Upgrade",
          "authority": "Rocket Pool",
          "url": "https://dao.rocketpool.net/t/rpip-86-saturn-2-upgrade/4012",
          "documentType": "official governance proposal",
          "publishedOn": "2026-07-30"
        }
      ],
      "whatHappened": "Rocket Pool published RPIP-86 as an informational package describing the likely Saturn 2 scope and the draft RPIPs that would implement it. Formal voting had not started and the final package remained subject to pDAO decisions.",
      "whatChanged": "The proposed package would add protocol-level rETH withdrawals backed by validator exits, permissionless challenges and exits for underperforming validators, exit-request and minipool-penalty mechanics, higher megapool bond requirements, lower RPL issuance, and the end of ongoing RPL rewards for node operators.",
      "whatDidNotChange": "No component had been formally approved or executed. Existing rETH withdrawal, validator-selection, penalty, bond, and RPL issuance mechanics remained operative pending governance and deployment.",
      "confirmedFacts": [
        "RPIP-86 was in an informal-sentiment and scoping stage; the underlying RPIPs were draft and not yet voted.",
        "RPIP-71 proposes an rETH withdrawal queue that can trigger validator exits.",
        "RPIP-71's first phase would have the oDAO select minipools for exit, while a later megapool selection rule remained undecided.",
        "RPIP-80 proposes penalties for minipools that do not respond to exit requests.",
        "The package proposes increasing megapool bond requirements, reducing RPL issuance to 2.5%, and ending ongoing RPL rewards for node operators."
      ],
      "unresolved": [
        "The final Saturn 2 scope, vote structure, voting outcome, implementation parameters, and deployment date were undecided.",
        "The pDAO had not selected the final megapool exit criterion.",
        "The practical interaction between oDAO minipool selection and penalties for failed exit requests requires governance and control review.",
        "The effects on rETH withdrawal liquidity, operator participation, and protocol economics remain prospective."
      ],
      "advisorDiligenceImplications": [
        "Open a Rocket Pool memo review now because the written criterion covers RPIPs that expand oDAO power over penalties, and the package plausibly links oDAO exit selection to minipool penalties.",
        "Do not treat the proposed withdrawal queue as available liquidity until governance approval, deployment, and live performance are confirmed.",
        "Monitor formal votes and executed parameters for withdrawal priority, validator selection, penalty discretion, bond requirements, and RPL economics."
      ],
      "followUpOn": "2026-08-31",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-fa5f6c82cdc88500fd2f0406",
      "stableKey": "sky-grove-august-2026-capacity-and-controller-proposal",
      "version": 1,
      "eventDate": "2026-07-30",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Grove proposes lower reserves, higher exposure limits, and new Uniswap capacity",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[August 13, 2026] - Proposed Changes to Grove for Upcoming Spell",
          "authority": "Sky / Grove",
          "url": "https://forum.skyeco.com/t/august-13-2026-proposed-changes-to-grove-for-upcoming-spell/28126",
          "documentType": "official spell proposal",
          "publishedOn": "2026-07-30"
        }
      ],
      "whatHappened": "Grove proposed enabling Uniswap v3 functions on its Diamond PAU controller, retiring a Maple deposit permission, lowering the JTRSY capital reserve ratio, doubling JTRSY maximum exposure, and doubling allocator debt-capacity parameters.",
      "whatChanged": "If executed, Grove would gain new Uniswap liquidity and swap capacity, the JTRSY reserve ratio would fall from 100% to 25%, maximum exposure would rise from 2.5 million to 5 million, and ALLOCATOR-GROVE-A maxLine would rise from 5 million to 10 million USDS.",
      "whatDidNotChange": "The July record is a proposal for an August spell. It does not prove execution, and the JTRSY artifact and Sky Core autoline changes were explicitly outside the Grove spell payload.",
      "confirmedFacts": [
        "The proposed Uniswap deposit allowance is capped at 5 million with no replenishing slope during the initial phase.",
        "The proposal would set the Maple syrupUSDC deposit limit to zero.",
        "The requested JTRSY CRR is 25%, down from 100%.",
        "The requested ALLOCATOR-GROVE-A maxLine is 10 million USDS and gap is 2 million USDS."
      ],
      "unresolved": [
        "Whether the August 13 Grove and coordinated Sky Core spells executed.",
        "Whether the off-chain JTRSY artifact update was completed.",
        "The resulting live exposure, rate-limit, and autoline state."
      ],
      "advisorDiligenceImplications": [
        "Review the Sky memo if execution is confirmed because the proposal materially increases delegated deployment capacity and reduces reserve requirements.",
        "Verify that any approved Sky exposure does not inherit unreviewed Grove, JTRSY, Uniswap, or Maple risk."
      ],
      "followUpOn": "2026-08-13",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-4f233cf15437266a5e671c2a",
      "stableKey": "rocket-pool-rpip-84-signaling-platform-migration",
      "version": 1,
      "eventDate": "2026-07-28",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Rocket Pool advances proposal to replace Snapshot with RocketDash",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "rocket-pool",
          "name": "Rocket Pool"
        }
      ],
      "primaryDocuments": [
        {
          "title": "pDAO Signaling Governance - sentiment poll",
          "authority": "Rocket Pool",
          "url": "https://dao.rocketpool.net/t/pdao-signaling-governance-sentiment-poll/4004",
          "documentType": "official governance proposal and poll record",
          "publishedOn": "2026-07-21"
        }
      ],
      "whatHappened": "Rocket Pool's RPIP-84 sentiment poll closed 20-0 in favor of advancing a proposal that would make RocketDash the recognized signaling platform and create an on-chain emergency ballot system.",
      "whatChanged": "The platform migration became a concrete proposal ready for formal review and voting rather than an informal discussion.",
      "whatDidNotChange": "The record says a further vote is required; Snapshot remained the recognized venue and RocketDash had not yet received binding authorization.",
      "confirmedFacts": [
        "The sentiment poll closed 20-0 in favor of proceeding.",
        "RPIP-84 would designate RocketDash as the initial Recognized Signaling Platform.",
        "The proposal would recognize a lead vote administrator and create an emergency on-chain mechanism for replacing an unusable or untrusted platform."
      ],
      "unresolved": [
        "Whether RPIP-84 passed its binding vote.",
        "Whether RocketDash became the operative signaling platform and the emergency ballot system was implemented."
      ],
      "advisorDiligenceImplications": [
        "Monitor authorization and implementation because the proposal changes the off-chain governance trust model and continuity controls.",
        "Retain the existing Rocket Pool governance assessment until a binding result and operative migration are verified."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-784ea1667c60bd141f008e81",
      "stableKey": "rocket-pool-pdao-parameter-guardrail-revisions",
      "version": 1,
      "eventDate": "2026-07-28",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Rocket Pool proposes revisions to pDAO parameter guardrails",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "rocket-pool",
          "name": "Rocket Pool"
        }
      ],
      "primaryDocuments": [
        {
          "title": "RPIP: pDAO Parameter Guardrail Revisions",
          "authority": "Rocket Pool",
          "url": "https://dao.rocketpool.net/t/rpip-pdao-parameter-guardrail-revisions/4010",
          "documentType": "official governance proposal",
          "publishedOn": "2026-07-28"
        }
      ],
      "whatHappened": "Rocket Pool published a formal RPIP proposing revised governance guardrails for RPL inflation, governance quorums, the rETH collateral target, megapool dissolution delay, and the reduced-bond parameter.",
      "whatChanged": "A concrete proposal now defines possible new bounds, including a 25% annual RPL-inflation ceiling and broader quorum ranges.",
      "whatDidNotChange": "The cached record does not show approval, on-chain execution, or any currently operative parameter change.",
      "confirmedFacts": [
        "The proposal would cap annual RPL inflation at 25%.",
        "It would widen allowed proposal, veto, and upgrade-veto quorum ranges.",
        "It would change guardrails governing the rETH collateral target, megapool dissolution delay, and reduced bond."
      ],
      "unresolved": [
        "Whether the RPIP proceeded to a binding vote.",
        "The final approved text and any executed parameter values."
      ],
      "advisorDiligenceImplications": [
        "Monitor the proposal because executed guardrail changes would alter the governance and economic-control assumptions in the Rocket Pool memo.",
        "Do not treat the proposed bounds as operative until approval and execution are verified."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-71bc24aeef9125c618cefa3d",
      "stableKey": "morpho-sky-vault-market-update-2026-07-27",
      "version": 1,
      "eventDate": "2026-07-27",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "sky.money proposes new Morpho vault markets and sUSDS/USDT migration",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "morpho-blue",
          "name": "Morpho Blue"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Updating the sky.money USDT Savings Vault & USDS Flagship Vault",
          "authority": "Morpho Blue",
          "url": "https://forum.morpho.org/t/updating-the-sky-money-usdt-savings-vault-usds-flagship-vault/2368",
          "documentType": "official forum change record",
          "publishedOn": "2026-07-27"
        }
      ],
      "whatHappened": "sky.money announced planned allocation changes for its Morpho USDT Savings and USDS Flagship vaults, including two new isolated markets and a gradual migration away from an existing sUSDS/USDT market.",
      "whatChanged": "The proposed replacement sUSDS/USDT market uses a 96.5% LLTV and caps the USDT oracle leg at $1.00. A PT-sUSDS-26NOV2026/USDS market with a 91.5% LLTV and linear-discount oracle was also slated for the USDS vault. The old market's utilization and rates would be increased gradually to encourage migration.",
      "whatDidNotChange": "The record does not establish execution on-chain and does not identify the held Steakhouse-curated Morpho vaults as affected. Morpho Blue's core contracts were not described as changing.",
      "confirmedFacts": [
        "The proposed capped sUSDS/USDT market ID is 0x26b178d49895f80ca3c39b2745efc4cd9adcddfcc73dae93e531e86977ec4d96.",
        "The proposed PT-sUSDS-26NOV2026/USDS market ID is 0x9a8dab6de1059e6dc66c34b358764b70effb289e514e237f3161ffb09eaaf24f.",
        "The announced LLTVs were 96.5% for sUSDS/USDT and 91.5% for PT-sUSDS/USDS.",
        "The announcement described a gradual migration incentive for borrowers in the older sUSDS/USDT market."
      ],
      "unresolved": [
        "On-chain execution and final vault allocations were not confirmed by the cached record.",
        "The realized liquidation and exit-liquidity effects of the capped oracle and high-LLTV markets remain unknown."
      ],
      "advisorDiligenceImplications": [
        "Monitor the new markets as examples of curator-specific oracle and high-LLTV risk within Morpho.",
        "Do not infer that these sky.money vaults or markets are covered by approval of separately diligenced Morpho vaults.",
        "No held-vault kill criterion is established because the record does not affect a vault identified as held."
      ],
      "followUpOn": "2026-08-21",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-b2c7e475e8e06ef5a573289e",
      "stableKey": "axelar:governance-deposit-increase:proposal-493",
      "version": 1,
      "eventDate": "2026-07-25",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Axelar approves sharply higher governance proposal deposits",
      "category": "governance",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Increase governance deposit: min_deposit to 150,000 AXL, expedited to 400,000 AXL",
          "authority": "Axelar on-chain governance",
          "url": "https://axelarscan.io/proposal/493",
          "documentType": "onchain_governance_record",
          "publishedOn": "2026-07-25"
        }
      ],
      "whatHappened": "Axelar governance passed proposal 493 to raise the deposit required to open ordinary and expedited governance proposals.",
      "whatChanged": "Governance approved a 75-fold increase in the ordinary minimum deposit and an approximately 133-fold increase in the expedited minimum deposit, materially raising the capital required to initiate votes.",
      "whatDidNotChange": "The record does not independently prove that the new parameters became operative. Voting periods, quorum, thresholds, deposit ratio, and refund treatment were unchanged by the proposal.",
      "confirmedFacts": [
        "The ordinary minimum deposit would increase from 2,000 to 150,000 AXL.",
        "The expedited minimum deposit would increase from 3,000 to 400,000 AXL.",
        "The proposal passed.",
        "Deposits remain returnable when a proposal passes or fails without a veto."
      ],
      "unresolved": [
        "The effective parameter-update transaction or post-execution state is not supplied.",
        "The practical effect on proposer diversity and governance participation is not yet observable."
      ],
      "advisorDiligenceImplications": [
        "Review the Axelar memo's governance-access and concentration assumptions because materially fewer holders may be able to originate proposals independently.",
        "Verify live governance parameters before treating the approved amounts as operative.",
        "Monitor whether the higher deposits reduce spam without materially narrowing credible proposer access."
      ],
      "followUpOn": "2026-08-01",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-db7371c0a406558b73b9b43f",
      "stableKey": "lido-srv3-oracle-vebo-incident-2026-07-25",
      "version": 1,
      "eventDate": "2026-07-25",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Lido postmortem details SRv3 Accounting Oracle and VEBO incident",
      "category": "security_incident",
      "posture": "postmortem",
      "materiality": "material",
      "evidenceState": "mixed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[Security Disclosure] 25/7/2026 Minor Underreporting of Total Protocol CL-side balances in Accounting Oracle Report",
          "authority": "Lido",
          "url": "https://research.lido.fi/t/security-disclosure-25-7-2026-minor-underreporting-of-total-protocol-cl-side-balances-in-accounting-oracle-report/11756",
          "documentType": "official incident disclosure and postmortem",
          "publishedOn": "2026-07-25"
        }
      ],
      "whatHappened": "Following the SRv3 release, Lido's Accounting Oracle and Validators ExitBus Oracle experienced report delays and edge-case failures. The July 25 Accounting Oracle report omitted one in-flight 32 ETH deposit, and some VEBO reports from July 26 through July 28 were not produced.",
      "whatChanged": "The omitted balance was included in the July 26 rebase. Lido replaced slow BLS verification, fixed the VEBO zero-weight edge case, and added Accounting Oracle invariant checks, circuit breakers, three-way input matching, and expanded logging.",
      "whatDidNotChange": "Lido reported no lost or frozen funds. Withdrawal finalization remained below the Ethereum network average, and the incident did not establish a change to stETH redemption rights. Existing rebase guardrails did not stop the 32 ETH discrepancy because it was within their allowed range.",
      "confirmedFacts": [
        "AO and VEBO report delivery was delayed by approximately three to six hours between July 24 and July 28.",
        "The July 25 report omitted one in-flight 32 ETH deposit and showed an extrapolated APR of 2.04% rather than the expected 2.15%.",
        "A manually checked July 26 report included the missing ETH and showed an extrapolated APR of 2.29%.",
        "Some VEBO reports were not produced between July 26 and July 28, modestly extending withdrawal-request finalization.",
        "Lido reported that no funds were lost or frozen and deployed oracle-code remediations."
      ],
      "unresolved": [
        "The exact cause of the single omitted pending deposit could not be reproduced or established; a CL, EL, and KAPI response race remained a working assumption.",
        "The long-term effectiveness of the new invariant checks and circuit breakers requires observation across subsequent oracle-report cycles."
      ],
      "advisorDiligenceImplications": [
        "Add the incident and remediation details to the Lido diligence record because accounting and exit-oracle reliability directly affect reported backing, rebases, and withdrawal timing.",
        "Review subsequent AO and VEBO reports for repeated balance mismatches or delayed exit processing before treating the issue as fully closed.",
        "The confirmed recovery and absence of loss do not independently justify a restriction, but they do require memo review of SRv3 oracle dependencies."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-c7f7d7ea1a6ed7491bcbc5ed",
      "stableKey": "sky-july-2026-ssr-and-core-vault-fee-proposal",
      "version": 1,
      "eventDate": "2026-07-23",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Sky risk advisor proposes an 8 bp SSR cut and 100 bp Core Vault fee increases",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Risk Month in Review: July 2026",
          "authority": "Sky / BA Labs",
          "url": "https://forum.skyeco.com/t/risk-month-in-review-july-2026/28128",
          "documentType": "official risk-advisor report",
          "publishedOn": "2026-07-31"
        }
      ],
      "whatHappened": "BA Labs reported recommending an 8-basis-point reduction in the Sky Savings Rate and one-percentage-point increases in Core Vault stability fees following consultation with the Core Council.",
      "whatChanged": "A concrete rate proposal entered the Sky parameter process and would change both saver yield and borrower costs if executed.",
      "whatDidNotChange": "The monthly report does not itself prove the poll, BEAM action, or executive execution; no operative rate is inferred from the recommendation.",
      "confirmedFacts": [
        "The recommended SSR reduction was 0.08 percentage points.",
        "The recommended Core Vault stability-fee increase was 1 percentage point.",
        "BA Labs estimated the combined changes could increase annual USDS profit by approximately 8.51 million USDS."
      ],
      "unresolved": [
        "Whether the recommendation was approved and executed.",
        "The exact effective timestamp and resulting live SSR and vault fees."
      ],
      "advisorDiligenceImplications": [
        "Verify live rate state and update Sky yield assumptions if the recommendation became operative.",
        "Review client-facing yield materials so a proposed rate is not presented as current."
      ],
      "followUpOn": "2026-08-03",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-9bc7df216a6c6e181d3e5394",
      "stableKey": "morpho-midnight-public-launch",
      "version": 1,
      "eventDate": "2026-07-21",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Morpho launches Midnight fixed-rate, fixed-term credit markets",
      "category": "launch_access",
      "posture": "launched",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "morpho-blue",
          "name": "Morpho Blue"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Now Live: Morpho Midnight & New Markets App",
          "authority": "Morpho",
          "url": "https://morpho.org/blog/now-live-morpho-midnight",
          "documentType": "official launch notice",
          "publishedOn": "2026-07-21"
        }
      ],
      "whatHappened": "Morpho launched Midnight, an immutable noncustodial fixed-rate, fixed-term lending protocol, together with a new Markets App.",
      "whatChanged": "Morpho's live product perimeter expanded beyond Blue's variable-rate, open-term markets to a distinct fixed-term credit primitive initially available on Base for cbBTC/USDC.",
      "whatDidNotChange": "Midnight is not Morpho Blue v2 and does not replace Blue. The launch did not include vault adapters, auto-rolling, callbacks, cross-chain support, gates, or secondary exits.",
      "confirmedFacts": [
        "The protocol and Markets App were live on July 21, 2026.",
        "Initial access was limited to Base, cbBTC/USDC, and a limited set of maturities.",
        "Launch functionality supported direct lending and borrowing.",
        "Morpho described Midnight contracts as immutable and non-upgradeable."
      ],
      "unresolved": [
        "Deployment-address verification and initial market utilization.",
        "Maturity liquidity and early-exit behavior without a secondary market.",
        "The timing and control implications of later vault adapters, callbacks, gates, and cross-chain features."
      ],
      "advisorDiligenceImplications": [
        "Do not extend the Morpho Blue approval or limits to Midnight; it requires a separate diligence determination.",
        "Add fixed-term liquidity, maturity, rate-discovery, and collateral controls to the Morpho research perimeter."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-c80c7773b9a33a4c3a91da8d",
      "stableKey": "morpho-birch-hill-rwa-usdc-launch-2026-07-21",
      "version": 1,
      "eventDate": "2026-07-21",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Birch Hill launches RWA USDC vault on Morpho",
      "category": "launch_access",
      "posture": "launched",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "morpho-blue",
          "name": "Morpho Blue"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Introducing Birch Hill vaults on Morpho",
          "authority": "Morpho Blue",
          "url": "https://forum.morpho.org/t/introducing-birch-hill-vaults-on-morpho/2364",
          "documentType": "official forum launch record",
          "publishedOn": "2026-07-21"
        }
      ],
      "whatHappened": "Birch Hill announced that its RWA USDC Vault was live on Base in a controlled rollout, supplying USDC to isolated asset-backed credit markets on Morpho.",
      "whatChanged": "The launch added a curator-managed Morpho exposure whose first target was GRO/USDC, using tokenized equity in a private multifamily REIT as collateral, a Chronicle NAV oracle, and a 62.5% LLTV.",
      "whatDidNotChange": "The launch did not modify Morpho Blue's immutable core market contracts and did not make the Birch Hill vault part of Ketju's existing Morpho approval. No current client holding was identified.",
      "confirmedFacts": [
        "The operator described the vault as live on Base in a controlled rollout.",
        "The supply asset is USDC and the initial target market is isolated GRO/USDC.",
        "The announced collateral is GRO tokenized private-REIT equity, with a Chronicle NAV oracle and 62.5% LLTV.",
        "The announced fee is a 10% performance fee."
      ],
      "unresolved": [
        "The cached record does not expose a vault contract address for independent state verification.",
        "Controlled-rollout capacity, withdrawal liquidity, collateral enforceability, valuation controls, and oracle performance remain to be diligenced."
      ],
      "advisorDiligenceImplications": [
        "Add the vault to the Morpho research perimeter as a separate RWA and curator exposure.",
        "Require diligence on Birch Hill, GRO legal rights, Chronicle's NAV process, utilization, and exit liquidity before considering advisor use.",
        "Do not treat general Morpho protocol approval as approval of this vault."
      ],
      "followUpOn": "2026-09-01",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-38579cf17a3246557d4ab7d0",
      "stableKey": "spark-liquidity-layer:freezer-multisig-threshold:2026-07-20",
      "version": 1,
      "eventDate": "2026-07-20",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Spark proposes a 2-of-4 freezer multisig and signer rotation",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "spark-liquidity-layer",
          "name": "Spark Liquidity Layer"
        }
      ],
      "primaryDocuments": [
        {
          "title": "SAEP-18: Update Spark Liquidity Layer Freezer Multisig",
          "authority": "Spark governance via Snapshot",
          "url": "https://snapshot.org/#/sparkfi.eth/proposal/0x5ac67ae3e4808faf16cbd271d9c7398f86116747c4b395ba56e47fb2b4068627",
          "documentType": "governance_proposal",
          "publishedOn": "2026-07-20"
        }
      ],
      "whatHappened": "Spark governance received a proposal to replace the Spark Assets Foundation signer with an additional Phoenix Labs signer and increase the Liquidity Layer Freezer Multisig threshold from 1-of-4 to 2-of-4.",
      "whatChanged": "A concrete control-change proposal entered governance review, supplying new evidence about the freezer role's signer composition and intended approval threshold.",
      "whatDidNotChange": "The record does not prove that the multisig configuration changed, identify an execution transaction, disclose the multisig address, or resolve the rejected memo's broader per-chain administrator and relayer-control gaps.",
      "confirmedFacts": [
        "The proposal identifies the prior freezer configuration as one Spark Assets Foundation signer, two Phoenix Labs signers, VoteWizard, and a 1-of-4 threshold.",
        "The freezer can deauthorize addresses holding the Relayer Role.",
        "The proposal would replace the Spark Assets Foundation signer with another Phoenix Labs signer.",
        "The proposed threshold is 2-of-4."
      ],
      "unresolved": [
        "The vote outcome and any implementation transaction are not established.",
        "The operative multisig address, signer addresses, and chain-by-chain scope remain undisclosed in this record.",
        "It is not established whether every Liquidity Layer deployment uses this freezer or has separate local emergency authority."
      ],
      "advisorDiligenceImplications": [
        "Review the Spark Liquidity Layer memo because the proposal partially addresses its documented freezer-control disclosure gap.",
        "Verify the live multisig address, owners, threshold, and per-chain authority before crediting the proposed configuration.",
        "Do not reopen or approve the rejected object solely because governance proposed a safer threshold."
      ],
      "followUpOn": "2026-07-27",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-621c85ce33d9b1e7bea15f9a",
      "stableKey": "lido-cmv2-penalty-framework-2026-07-20",
      "version": 1,
      "eventDate": "2026-07-20",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Lido governance approves CMv2 penalty framework",
      "category": "governance",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Penalty Framework | CMv2",
          "authority": "Lido",
          "url": "https://research.lido.fi/t/penalty-framework-cmv2/11732",
          "documentType": "official governance record",
          "publishedOn": "2026-07-06"
        }
      ],
      "whatHappened": "Lido's Snapshot vote approved the Curated Module v2 Penalty Framework, establishing rules for assessing node-operator incidents, losses, missed rewards, withdrawal delays, and other operational failures.",
      "whatChanged": "The framework authorizes the Curated Module Committee to use a General Delayed Penalty that can lock an assessed amount from an operator's bond, pursue voluntary compensation, or progress the locked bond toward burn through the applicable governance or Easy Track process. It also delegates non-material framework refinements to the committee.",
      "whatDidNotChange": "Material changes to penalty scope, new penalty mechanisms, significant operator obligations, or governance authority still require standard DAO approval. The approval did not itself impose a penalty on a named operator or change stETH withdrawal rights.",
      "confirmedFacts": [
        "The Snapshot concluded successfully on July 20 with 58.0 million LDO for adoption and zero against.",
        "The General Delayed Penalty is the primary manual mechanism for violations or losses not handled automatically.",
        "Reported penalty amounts can be locked from a node operator's bond and may be compensated, burned through governance or Easy Track, or released under the framework's conditions.",
        "The Curated Module Committee may refine thresholds, methods, examples, and non-material procedures without a full DAO vote.",
        "Material penalty or governance changes remain subject to DAO approval."
      ],
      "unresolved": [
        "No operator-specific application demonstrates how the committee will exercise its discretion in practice.",
        "The downstream effect on Curated Module operator participation, bond economics, and validator performance remains to be observed."
      ],
      "advisorDiligenceImplications": [
        "Update Lido control diligence to reflect the committee's approved discretion over incident assessment and operator bond penalties.",
        "Monitor committee amendments and the first operator-specific cases for consistency, transparency, and effects on validator operations.",
        "Review whether the memo's operator-governance analysis adequately captures the new delegated authority and loss-compensation process."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-654ba71939d66645415b8811",
      "stableKey": "aave-v3:arbitrum:usdai-susdai-arfc:2026-07-20",
      "version": 1,
      "eventDate": "2026-07-20",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Aave proposes USDai and sUSDai onboarding on Arbitrum",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        },
        {
          "type": "asset",
          "id": "usd-ai",
          "name": "USD.AI (sUSDai)"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Onboard USDai & sUSDai to Aave V3 Arbitrum Instance",
          "authority": "Aave DAO via Snapshot",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0xea4a214958299ff36fb85c53cf2f727ce2df3e145279e8f6bef6766f26297d76",
          "documentType": "governance_proposal",
          "publishedOn": "2026-07-20"
        }
      ],
      "whatHappened": "An Aave ARFC proposed onboarding USDai and sUSDai to the Arbitrum V3 instance with supply caps, a USDai borrow cap, CAPO settings, and isolated E-mode collateral configurations.",
      "whatChanged": "A concrete pathway was proposed for Aave to accept exposure connected to the rejected USD.AI credit product, requiring cross-memo review before any implementation.",
      "whatDidNotChange": "The ARFC did not execute an AIP, activate either reserve, extend Ketju approval to the assets, or establish that the proposed parameters became operative.",
      "confirmedFacts": [
        "The proposal specifies 55 million supply caps for both USDai and sUSDai.",
        "It specifies a 45 million borrow cap for USDai.",
        "The proposed sUSDai/USDai E-mode uses 89% LTV and a 91% liquidation threshold.",
        "The proposed sUSDai stablecoin E-mode uses 88% LTV and a 90% liquidation threshold.",
        "The proposal says a successful ARFC would require a later AIP for final confirmation and enforcement."
      ],
      "unresolved": [
        "The ARFC vote result and any subsequent AIP or execution are not established.",
        "The proposal's top-level borrowability table conflicts with its borrow-cap and E-mode specifications for USDai.",
        "No executed reserve configuration, oracle address, liquidity assessment, or deployed CAPO configuration is supplied."
      ],
      "advisorDiligenceImplications": [
        "Review the Aave v3 memo for potential leakage of rejected USD.AI credit exposure through collateral and E-mode pathways.",
        "Keep USDai and sUSDai outside approved Aave allocations unless a later executed payload receives asset-specific review.",
        "Reconcile the contradictory borrowability specifications before evaluating any final AIP."
      ],
      "followUpOn": "2026-07-27",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-a4953c64166ed9f11e0c4db7",
      "stableKey": "aave-v3:ethereum-core:syrupusdc-arfc:2026-07-20",
      "version": 1,
      "eventDate": "2026-07-20",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Aave proposes syrupUSDC onboarding on Ethereum Core",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        },
        {
          "type": "asset",
          "id": "maple",
          "name": "Maple Finance"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Onboard syrupUSDC to Aave V3 Core Instance",
          "authority": "Aave DAO via Snapshot",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0x0800663767b84a5bdcdeb417cc0eb7a55b80561684d763bca593363dd83dfcc2",
          "documentType": "governance_proposal",
          "publishedOn": "2026-07-20"
        }
      ],
      "whatHappened": "An Aave ARFC proposed onboarding Maple's syrupUSDC to the Ethereum Core instance with a 50 million supply cap and a stablecoin E-mode against USDC and GHO.",
      "whatChanged": "A concrete governance path was proposed for a rejected private-credit exposure to become collateral within an approved-with-limits Aave deployment.",
      "whatDidNotChange": "The proposal did not execute an AIP, activate syrupUSDC, change Ketju's Maple rejection, or extend the Aave approval to this collateral path.",
      "confirmedFacts": [
        "The proposed syrupUSDC supply cap is 50 million.",
        "The stablecoin E-mode specifies 90% LTV, a 92% liquidation threshold, and a 4% liquidation bonus.",
        "The E-mode table identifies syrupUSDC as collateral and USDC and GHO as borrowable assets.",
        "The proposal says a successful ARFC would require a later AIP for final confirmation and enforcement."
      ],
      "unresolved": [
        "The ARFC vote result and any subsequent AIP or execution are not established.",
        "The top-level specification says collateral is disabled while the E-mode table says syrupUSDC is collateral, leaving the intended configuration ambiguous.",
        "No executed oracle, cap, liquidity, or liquidation configuration is supplied."
      ],
      "advisorDiligenceImplications": [
        "Review the Aave v3 memo for rejected Maple credit exposure entering through syrupUSDC collateral.",
        "Do not treat the existing Aave approval as covering syrupUSDC without asset-specific custody, credit, oracle, liquidity, and withdrawal review.",
        "Require the final payload to resolve the proposal's contradictory collateral specification."
      ],
      "followUpOn": "2026-07-27",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-ef73165e78a6aa9ff0ec4c6f",
      "stableKey": "axelar:amplifier-contract-admin-rotation:proposal-492",
      "version": 1,
      "eventDate": "2026-07-17",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Axelar approves Amplifier contract-admin rotation to a multisig",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Rotate mainnet Amplifier CosmWasm contract admin to multisig",
          "authority": "Axelar on-chain governance",
          "url": "https://axelarscan.io/proposal/492",
          "documentType": "onchain_governance_record",
          "publishedOn": "2026-07-17"
        }
      ],
      "whatHappened": "Axelar governance passed proposal 492 to rotate the administrator and upgrade authority for 35 mainnet Amplifier CosmWasm contracts to a specified multisig.",
      "whatChanged": "Governance authorized a new upgrade-control endpoint across gateway, routing, voting, rewards, service-registry, multisig, and Interchain Token Service components.",
      "whatDidNotChange": "The governance record does not independently prove that every contract-admin update executed or disclose the destination multisig's signer identities, threshold, or internal controls.",
      "confirmedFacts": [
        "Proposal 492 passed.",
        "The destination address is axelar14vps3ev03zyp2wmj89etx8rrxdxyltfy4rzl5m.",
        "The proposal identifies 35 affected contracts.",
        "Affected contract families include gateways, routers, voting verifiers, multisig components, rewards, service registry, and Interchain Token Service."
      ],
      "unresolved": [
        "Execution and post-change admin state for each contract are not established.",
        "The destination multisig's signer identities, threshold, key custody, and transaction policy are not supplied.",
        "It is not established whether every affected contract shares identical upgrade and emergency powers."
      ],
      "advisorDiligenceImplications": [
        "Review the Axelar memo's upgrade-authority map and replace prior administrator assumptions only after contract-level verification.",
        "Obtain the multisig owner set and threshold before assessing whether the rotation reduces or concentrates control risk.",
        "Reconcile all 35 contracts because partial execution would leave mixed administrator states."
      ],
      "followUpOn": "2026-07-24",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-a5a58214066ee066acefe993",
      "stableKey": "lido:0x02-csm:launch-proposal:2026-07-10",
      "version": 1,
      "eventDate": "2026-07-10",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Lido proposes a separate permissionless 0x02 validator module",
      "category": "governance",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "0x02 CSM: New Permissionless Module Launch",
          "authority": "Lido DAO via Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0xed2a3b1f796cefdd531abe14ba01363b2da7887434cefdd54ba71ffb6dff59a7",
          "documentType": "governance_proposal",
          "publishedOn": "2026-07-10"
        }
      ],
      "whatHappened": "Lido governance received a proposal to launch a separate permissionless Community Staking Module for 0x02 withdrawal credentials and validators with effective balances up to 2,048 ETH.",
      "whatChanged": "The proposal introduced a two-stage deposit and top-up allocation design and sought a 20% combined stake-share ceiling for the existing and proposed CSM instances.",
      "whatDidNotChange": "The proposal does not prove mainnet deployment. The existing 0x01 CSM would continue serving smaller operators, and the exact top-up queue capacity was deferred.",
      "confirmedFacts": [
        "The proposed 0x02 CSM is a separate module rather than a replacement for 0x01 CSM.",
        "It is designed for validators with effective balances up to 2,048 ETH.",
        "The design first allocates 32 ETH and then uses a capacity-limited queue for progressive top-ups.",
        "The proposal seeks a 20% maximum combined stake share for the 0x01 and 0x02 CSM instances.",
        "Existing 0x01 operators would not receive a direct consolidation path into the new module."
      ],
      "unresolved": [
        "The vote result, final launch parameters, deployed addresses, and mainnet activation are not established.",
        "The number of top-up queue seats remained deferred until closer to deployment.",
        "Production bond-risk, exit, penalty, and allocation behavior for variable-balance validators remains untested."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido memo's validator-module concentration, permissionless operator, bond, and allocation assumptions.",
        "Do not treat the proposed module as live or covered by the existing approval until deployed contracts and final parameters are verified.",
        "Monitor whether the combined 20% ceiling and queue controls are encoded and enforceable on-chain."
      ],
      "followUpOn": "2026-07-31",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-5f7b0364993c9042e30b5b6e",
      "stableKey": "morpho-presto-usdc-vaults-launch-2026-07-08",
      "version": 1,
      "eventDate": "2026-07-08",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Presto launches two USDC vaults on Morpho",
      "category": "launch_access",
      "posture": "launched",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "morpho-blue",
          "name": "Morpho Blue"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Introducing Presto Vaults on Morpho",
          "authority": "Morpho Blue",
          "url": "https://forum.morpho.org/t/introducing-presto-vaults-on-morpho/2354",
          "documentType": "official forum launch record",
          "publishedOn": "2026-07-08"
        }
      ],
      "whatHappened": "Presto introduced two Ethereum Morpho vaults: USDC Prime, lending against WBTC, and USDC Forte, allocating to private-credit and RWA collateral markets.",
      "whatChanged": "The launch added curator-managed USDC exposures with different risk mandates. Prime targets WBTC/USDC with a 10% performance fee; Forte targets FalconX- and JAAA-related markets with a 15% performance fee and higher counterparty, legal, oracle, and liquidity complexity.",
      "whatDidNotChange": "The launch did not modify Morpho Blue's core contracts and did not extend Ketju approval to either Presto vault. No current client holding was identified.",
      "confirmedFacts": [
        "Presto USDC Prime was identified at 0x133614490896bc02C774bc3399E4Db1B6D05a2CA on Ethereum.",
        "Presto USDC Forte was identified at 0x68A65f315BCd3C3456d1368Ff88bC661856548E1 on Ethereum.",
        "Prime was described as lending exclusively against WBTC with a 10% performance fee.",
        "Forte was described as allocating to AA_FalconXUSDC/USDC, wFalconX/USDC, and wJAAA/USDC with a 15% performance fee.",
        "The record states that market additions are subject to timelocks of at least three days, with more critical actions delayed seven days."
      ],
      "unresolved": [
        "Independent verification of live allocations, caps, utilization, withdrawal liquidity, and role configuration remains necessary.",
        "The legal enforceability, counterparty quality, liquidity, and oracle behavior of Forte's private-credit collateral require separate diligence."
      ],
      "advisorDiligenceImplications": [
        "Add both vaults to the Morpho research perimeter without treating them as approved exposures.",
        "Require separate curator, collateral, oracle, timelock, utilization, and exit-liquidity review before advisor consideration.",
        "Give Forte heightened diligence because its yield depends on private-credit and RWA structures rather than only liquid crypto collateral."
      ],
      "followUpOn": "2026-09-01",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-141dd827d3f9f05f4536ecf0",
      "stableKey": "axelar:secret-bridge-recovery-signal:proposal-490",
      "version": 1,
      "eventDate": "2026-07-05",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Axelar approves a non-binding freeze and recustody signal",
      "category": "governance",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "mixed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Signaling Proposal: Freeze Hacker Funds and Recustody to a Trusted Distributor at a Later Date",
          "authority": "Axelar on-chain governance",
          "url": "https://axelarscan.io/proposal/490",
          "documentType": "onchain_governance_record",
          "publishedOn": "2026-07-05"
        }
      ],
      "whatHappened": "Axelar governance passed a non-binding signaling proposal supporting a coordinated freeze of funds attributed to the June Axelar–Secret IBC bridge attacker and later recustody to a vetted distributor.",
      "whatChanged": "The community created a formal on-chain record of recovery intent and authorized contributors to prepare a later binding proposal with freeze, custody, and redistribution mechanics.",
      "whatDidNotChange": "The text proposal did not freeze, seize, move, recustody, or distribute funds, and it did not select a distributor or approve a final victim-repayment plan.",
      "confirmedFacts": [
        "Proposal 490 passed.",
        "The proposal is explicitly non-binding and carries no automatic on-chain action.",
        "It identifies axelar1hzra9z4zn8q0w8f3dj2wnw0xgetu8dfdhl6ad8 as the attacker-controlled wallet.",
        "It calls for a later binding proposal specifying the freeze mechanism, distributor, and redistribution plan."
      ],
      "unresolved": [
        "Whether the identified funds were actually frozen remains unverified.",
        "The amount, asset composition, custody status, and recoverability of the referenced funds are not established by this record.",
        "No trusted distributor, binding payload, entitlement schedule, or repayment timing had been approved."
      ],
      "advisorDiligenceImplications": [
        "Keep the Axelar incident and recovery path under memo review; a favorable signal is not recovered funds.",
        "Require operative freeze evidence and a binding, auditable distribution plan before crediting recovery.",
        "Continue monitoring bridge loss-allocation, custody, and cross-chain administrator powers implicated by the response."
      ],
      "followUpOn": "2026-07-19",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-424e0265db2664969d237288",
      "stableKey": "axelar:service-governance-ownership-migration:proposal-491",
      "version": 1,
      "eventDate": "2026-07-03",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Axelar approves ITS and Amplifier gateway ownership migration",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Accept AxelarServiceGovernance ownership of ITS and Amplifier Gateways",
          "authority": "Axelar on-chain governance",
          "url": "https://axelarscan.io/proposal/491",
          "documentType": "onchain_governance_record",
          "publishedOn": "2026-07-03"
        }
      ],
      "whatHappened": "Axelar governance passed proposal 491 to schedule AxelarServiceGovernance ownership acceptance for Interchain Token Service contracts across 21 EVM chains and Amplifier gateways on Hedera, Hyperliquid, Monad, and XRPL EVM.",
      "whatChanged": "Governance authorized a broad cross-chain migration of ownership and administrative control to AxelarServiceGovernance.",
      "whatDidNotChange": "The record does not prove that each timelock expired, each acceptOwnership call completed, or every target's final owner state changed on July 3.",
      "confirmedFacts": [
        "Proposal 491 passed.",
        "The payload targets Interchain Token Service on 21 EVM chains.",
        "It also targets AxelarAmplifierGateway on Hedera, Hyperliquid, Monad, and XRPL EVM.",
        "The mechanism uses scheduled timelock proposals delivered through AxelarnetGateway calls."
      ],
      "unresolved": [
        "The effective ownership-acceptance transaction and final owner state for each target are not supplied.",
        "Per-chain timelock delays, failed calls, retries, and partial completion remain unverified.",
        "The full authority and internal controls of AxelarServiceGovernance require reconciliation."
      ],
      "advisorDiligenceImplications": [
        "Review the Axelar memo's cross-chain ownership and upgrade-authority map.",
        "Verify the owner and pending-owner state for every relevant ITS and Amplifier gateway before treating the migration as complete.",
        "Monitor timelock and governance dependencies separately for client-used chains."
      ],
      "followUpOn": "2026-07-10",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-618f51ec4d9dd1dbb8a08c90",
      "stableKey": "rocket-pool-rpip-83-six-eth-megapool-bond",
      "version": 1,
      "eventDate": "2026-07-02",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Rocket Pool proposes a 6 ETH megapool-validator bond",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "rocket-pool",
          "name": "Rocket Pool"
        }
      ],
      "primaryDocuments": [
        {
          "title": "RPIP-83: Increasing Megapool Bond Requirement",
          "authority": "Rocket Pool",
          "url": "https://dao.rocketpool.net/t/rpip-83-increasing-megapool-bond-requirement/3990",
          "documentType": "official governance proposal",
          "publishedOn": "2026-07-02"
        }
      ],
      "whatHappened": "RPIP-83 proposed requiring 6 ETH of node-operator bond for each new megapool validator and using rewards to top up bonds below the required curve.",
      "whatChanged": "A concrete alternative to the planned lower reduced-bond setting entered governance consideration in response to limited rETH demand and withdrawal-liquidity needs.",
      "whatDidNotChange": "No approval or executed bond-curve parameter change is shown; existing megapool requirements remained operative.",
      "confirmedFacts": [
        "The proposal specifies 6 ETH per new megapool validator.",
        "It would allow node operators to top up bonds to the new curve.",
        "Megapool rewards below the curve would increase the bond instead of being paid directly."
      ],
      "unresolved": [
        "Whether RPIP-83 was approved and executed.",
        "The final implementation schedule and interaction with later Saturn upgrades."
      ],
      "advisorDiligenceImplications": [
        "Monitor because execution would change node-operator capital requirements, migration capacity, and the economic assumptions supporting rETH liquidity.",
        "Do not update the Rocket Pool memo's operative bond mechanics before execution evidence is available."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-cd8d2a386ec11b13f74ab01f",
      "stableKey": "defi-saver-aave-v3-pt-usdg-september-2026-integration",
      "version": 1,
      "eventDate": "2026-07-01",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "DeFi Saver launches PT-USDG Aave v3 looping and unwinding support",
      "category": "launch_access",
      "posture": "launched",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "product",
          "id": "defi-saver-asset-management",
          "name": "DeFi Saver Asset Management"
        },
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "DeFi Saver Newsletter: July 2026",
          "authority": "DeFi Saver",
          "url": "https://blog.defisaver.com/defi-saver-newsletter-july-2026/",
          "documentType": "official product update",
          "publishedOn": "2026-07-10"
        }
      ],
      "whatHappened": "DeFi Saver added live support for the PT-USDG-24SEP2026 Aave v3 collateral market, including atomic looping and unwinding workflows.",
      "whatChanged": "The DeFi Saver dependency can now automate a new fixed-maturity collateral exposure and leveraged looping path.",
      "whatDidNotChange": "DeFi Saver's dependency approval does not approve PT-USDG, Aave v3, Pendle, or any underlying leveraged strategy; base-protocol verdicts and limits remain separate.",
      "confirmedFacts": [
        "The PT-USDG-24SEP2026 integration was described as live.",
        "DeFi Saver supports one-transaction looping and one-transaction unwinding for the market.",
        "The official update said the initial 15 million supply cap had been reached."
      ],
      "unresolved": [
        "The exact live Aave market parameters and oracle configuration.",
        "Whether any approved or client-held position used the integration.",
        "Whether subsequent cap increases changed the available exposure."
      ],
      "advisorDiligenceImplications": [
        "Keep the DeFi Saver approval dependency-only and do not infer approval of the newly supported collateral or looping strategy.",
        "Review automation inventories for client positions using the new market."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-1cfb3d4336c6430a542cc4ff",
      "stableKey": "axelar:amplifier-permission-control:admin-rotation-proposal-487",
      "version": 1,
      "eventDate": "2026-06-30",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Axelar rotates permission-control administrators for ITS, Router, and Multisig",
      "category": "control_change",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Update permission-control admin for ITS, Router and Multisig",
          "authority": "Axelar on-chain governance",
          "url": "https://axelarscan.io/proposal/487",
          "documentType": "on_chain_governance_record",
          "publishedOn": "2026-06-30"
        }
      ],
      "whatHappened": "Axelar governance passed proposal 487, executing administrator updates on three Amplifier contracts.",
      "whatChanged": "The permission-control administrator for the Interchain Token Service, Router, and Multisig moved from axelar1nctnr9x0qexemeld5w7w752rmqdsqqv92dw9am to axelar1kctshqfxw74usjme9mqlvkf0rgdh96ty0mmm6p.",
      "whatDidNotChange": "The record does not identify the new controller's signer set, threshold, or internal governance policy, and it reports no asset loss or route interruption.",
      "confirmedFacts": [
        "Proposal 487 passed at the June 30 voting deadline.",
        "The payload contains three MsgExecuteContract update_admin calls.",
        "All three calls set the same new administrator address."
      ],
      "unresolved": [
        "The identity, signer composition, threshold, and emergency powers of the new administrator remain unresolved from this record."
      ],
      "advisorDiligenceImplications": [
        "Update the Axelar control map for all three Amplifier contracts.",
        "Verify the new controller's composition, threshold, rotation process, and ability to migrate or pause contracts.",
        "Reassess whether the new controller changes the dependency's concentration or emergency-governance assumptions."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-db345c132f00a6fa16b111cc",
      "stableKey": "axelar:cosmwasm-emergency-multisig:upload-instantiate-authority-proposal-486",
      "version": 1,
      "eventDate": "2026-06-29",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Axelar expands emergency multisig CosmWasm deployment authority",
      "category": "control_change",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Allow the emergency multisig to upload and instantiate CosmWasm code",
          "authority": "Axelar on-chain governance",
          "url": "https://axelarscan.io/proposal/486",
          "documentType": "on_chain_governance_record",
          "publishedOn": "2026-06-29"
        }
      ],
      "whatHappened": "Axelar governance passed proposal 486 and updated x/wasm parameters to permit an emergency multisig to upload and instantiate or migrate CosmWasm code.",
      "whatChanged": "The emergency address axelar14vps3ev03zyp2wmj89etx8rrxdxyltfy4rzl5m gained a fast path for code upload and default instantiation or migration.",
      "whatDidNotChange": "The proposal does not itself migrate a named contract or authorize direct asset transfers; it changes who may perform future emergency code actions.",
      "confirmedFacts": [
        "Proposal 486 passed on June 29.",
        "The payload is a MsgUpdateParams transaction for the CosmWasm module.",
        "code_upload_access and instantiate_default_permission were both changed to AnyOfAddresses."
      ],
      "unresolved": [
        "The emergency multisig's full signer identity, operating policy, and activation procedures are not established by this record.",
        "No subsequent exercise of the new authority is established here."
      ],
      "advisorDiligenceImplications": [
        "Record the emergency multisig as an upgrade-capable controller in the Axelar dependency memo.",
        "Verify signer composition, quorum, disclosure, monitoring, and post-action accountability for the fast upgrade path.",
        "Treat future emergency code uploads and migrations as memo-review events."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-bfc4de7a3e257f032fb112ed",
      "stableKey": "axelar:xrpl-amplifier-contracts:admin-rotation-proposal-482",
      "version": 1,
      "eventDate": "2026-06-27",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Axelar transfers XRPL Amplifier migration authority to 3-of-6 multisig",
      "category": "control_change",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Rotate XRPL{Gateway,VotingVerifier,MultisigProver} admin to multisig",
          "authority": "Axelar on-chain governance",
          "url": "https://axelarscan.io/proposal/482",
          "documentType": "on_chain_governance_record",
          "publishedOn": "2026-06-27"
        }
      ],
      "whatHappened": "Axelar governance passed proposal 482 and reassigned the migration administrator for the XRPL Gateway, VotingVerifier, and MultisigProver contracts.",
      "whatChanged": "Migration authority moved from axelar1nctnr9x0qexemeld5w7w752rmqdsqqv92dw9am to the 3-of-6 multisig axelar14vps3ev03zyp2wmj89etx8rrxdxyltfy4rzl5m.",
      "whatDidNotChange": "The proposal does not report a contract migration, verifier-set change, route pause, or asset loss.",
      "confirmedFacts": [
        "Proposal 482 passed on June 27.",
        "The payload contains three MsgUpdateAdmin actions.",
        "All three XRPL-related contracts received the same 3-of-6 multisig administrator."
      ],
      "unresolved": [
        "The six signer identities, key-custody arrangements, rotation policy, and emergency procedures remain unresolved."
      ],
      "advisorDiligenceImplications": [
        "Update XRPL integration diligence to reflect concentrated 3-of-6 migration authority.",
        "Verify whether the multisig is the same emergency controller used by other Axelar proposals and assess aggregate authority.",
        "Require review of any future migration performed through this administrator."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-52a07778c4d9319436948a02",
      "stableKey": "aave-v3:risk-stewards-umbrella-pauser:arfc-approval-2026-06",
      "version": 1,
      "eventDate": "2026-06-26",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Aave approves faster Risk Steward actions and Umbrella pauser reassignment",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Risk Stewards Cooldown Reduction & Umbrella Pauser Role Reassignment",
          "authority": "Aave DAO via Snapshot",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0x7083921f2f549ffa2cdc294c8ff60fdc82af0becbb7b2f20f4f296c34694aaf2",
          "documentType": "snapshot_governance_record",
          "publishedOn": "2026-06-22"
        }
      ],
      "whatHappened": "Aave DAO's Snapshot vote approved an ARFC to shorten the minimum delay for selected cap and interest-rate parameters and reassign Umbrella pause authority.",
      "whatChanged": "The approved design reduces selected Risk Steward minDelay settings from 72 to 36 hours and assigns Umbrella pause and unpause authority to the Aave Protocol Guardian.",
      "whatDidNotChange": "The vote did not execute an AIP; maxPercentChange bounds were not reduced, and Umbrella configuration and role-management authority remains with the Aave Governance Executor under the approved design.",
      "confirmedFacts": [
        "The Snapshot vote closed on June 26 with all recorded voting power cast for the ARFC.",
        "The proposal covers selected supply-cap, borrow-cap, and interest-rate-model parameters.",
        "The proposed Umbrella role controls both pause and unpause, while DEFAULT_ADMIN_ROLE remains with governance."
      ],
      "unresolved": [
        "The candidate does not establish a subsequent AIP or on-chain execution of either control change."
      ],
      "advisorDiligenceImplications": [
        "Review whether a 36-hour cooldown materially changes the expected notice period for Aave exposure-cap and rate changes.",
        "Record the Protocol Guardian as the proposed rapid-response controller for Umbrella pauses, while preserving the distinction between pause authority and configuration authority.",
        "Monitor the final AIP payload and execution before treating the changes as operative."
      ],
      "followUpOn": "2026-08-26",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-5155d42f1193182414fb5406",
      "stableKey": "coinbase-bridge:base-mainnet-chain-stall:2026-06-25",
      "version": 1,
      "eventDate": "2026-06-25",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Base recovers from consecutive mainnet chain stalls",
      "category": "market_stress",
      "posture": "recovered",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "coinbase-bridge",
          "name": "Base canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Base Mainnet Chain Stall",
          "authority": "Base",
          "url": "https://status.base.org/incidents/5c4gm1wzbjs4",
          "documentType": "official_status_incident",
          "publishedOn": "2026-06-26"
        }
      ],
      "whatHappened": "Base mainnet block production stalled on June 25 after a consensus problem allowed a problematic block to interfere with subsequent block building. A similar chain halt recurred on June 26 before Base reported block production progressing and the incident resolved.",
      "whatChanged": "The incident established a realized chain-availability failure affecting deposits, withdrawals, block production, and client software. Node operators were required to restart affected nodes to resume syncing, and the halt recurred the following day.",
      "whatDidNotChange": "The status record did not report a canonical-bridge contract exploit, asset loss, or chain reorganization. It did not include the promised detailed postmortem or enough evidence to verify that the root cause could not recur.",
      "confirmedFacts": [
        "The June 25 disruption prevented new blocks after block 47,806,542.",
        "Base identified a consensus problem involving an invalid or problematic block.",
        "Sequencing resumed, but affected ecosystem nodes required restart and resynchronization.",
        "A similar chain halt occurred on June 26.",
        "The incident record lists deposits, withdrawals, block production, and client software as affected and reports final resolution on June 26."
      ],
      "unresolved": [
        "The complete technical root cause and the mechanism behind the next-day recurrence.",
        "The permanent remediation, deployment evidence, and testing showing the fault cannot recur.",
        "The duration and transaction-level impact of deposit and withdrawal unavailability.",
        "Whether any nodes, indexers, or bridge-dependent services remained impaired after the status page was resolved."
      ],
      "advisorDiligenceImplications": [
        "Review the Base canonical-bridge memo's chain-availability and withdrawal-access assumptions against two realized stalls.",
        "Record that deposits and withdrawals can become temporarily unavailable during Base sequencing failures even without a bridge-contract exploit.",
        "Obtain the promised postmortem and verify permanent remediation before treating recovery as evidence of reduced operational risk."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-51c94eac6e439bc2979d4cdc",
      "stableKey": "spark-liquidity-layer:avalanche-governance-bridge:timelock-guardian-approval-2026-06",
      "version": 1,
      "eventDate": "2026-06-25",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Spark approves Avalanche governance-bridge timelock and guardian",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "spark-liquidity-layer",
          "name": "Spark Liquidity Layer"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[Avalanche] Spark Liquidity Layer - Add Timelock and Guardian to Avalanche Governance Bridge",
          "authority": "Spark via Snapshot",
          "url": "https://snapshot.org/#/sparkfi.eth/proposal/0x5f3a7d62d6d26c06890dd0300071d0f22cd4fdd7115c0d9c94577b90f644089c",
          "documentType": "snapshot_governance_record",
          "publishedOn": "2026-06-22"
        }
      ],
      "whatHappened": "Spark governance approved adding a three-day timelock and a guardian multisig to the Avalanche governance bridge.",
      "whatChanged": "The approved design inserts a delay before governance actions become effective and gives a guardian multisig cancellation power during that delay.",
      "whatDidNotChange": "The guardian is not granted general administrative authority over the Avalanche deployment, and the proposal does not resolve Spark's other per-chain control or legal-entity disclosure gaps.",
      "confirmedFacts": [
        "The Snapshot vote closed on June 25 with all recorded voting power in favor.",
        "The proposal identifies roughly 17 million spUSDC liabilities on Avalanche.",
        "The planned guardian requires at least five signers and a quorum of half the signer set rounded up.",
        "The guardian's stated power is limited to cancelling pending actions during the timelock."
      ],
      "unresolved": [
        "The candidate does not establish contract deployment or activation of the timelock and guardian.",
        "The final signer set and whether the planned multisig address was retained remain unresolved."
      ],
      "advisorDiligenceImplications": [
        "Update the Spark Liquidity Layer control map if implementation is confirmed, recording both the three-day notice period and the cancellation controller.",
        "Do not treat this chain-specific mitigation as resolving undisclosed control structure across Spark's other deployments.",
        "Verify deployed contracts and role assignments before giving the proposal credit in any future reopen review."
      ],
      "followUpOn": "2026-08-26",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-8d0d4f5d4d2105a58b7b551f",
      "stableKey": "lido-0x02-csm-module-proposal-2026-06-25",
      "version": 1,
      "eventDate": "2026-06-25",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Lido proposes a permissionless 0x02 CSM module",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "0x02 CSM Landscape",
          "authority": "Lido Governance",
          "url": "https://research.lido.fi/t/0x02-csm-landscape/11697",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-06-25"
        }
      ],
      "whatHappened": "Lido contributors proposed a separate permissionless CSM using 0x02 withdrawal credentials and validator balances up to 2,048 ETH.",
      "whatChanged": "A concrete design entered governance discussion with proposed bond, fee, penalty, capacity, queue, and delegated-role parameters.",
      "whatDidNotChange": "Within June it had not been approved, deployed, or activated; the exact module allocation and top-up seats were not final, and 0x01 operators had no direct migration path.",
      "confirmedFacts": [
        "The proposal calls for a new CSM v3 instance using 0x02 credentials.",
        "The proposed maximum validator balance is 2,048 ETH.",
        "Proposed bonds are 32 ETH and 30 ETH, with a 2% operator and 8% DAO split.",
        "The proposed combined 0x01/0x02 capacity ceiling is 20%.",
        "The CSM Committee would receive penalty, queue, bond-curve, and pause roles."
      ],
      "unresolved": [
        "Approval and deployment after June 30.",
        "Final capacity, queue seats, addresses, role holders, thresholds, audits, and activation conditions.",
        "Realized slashing, exit, liquidity, and concentration effects."
      ],
      "advisorDiligenceImplications": [
        "Monitor approval and deployment, then review concentration, slashing, queue, and delegated-control assumptions.",
        "Do not infer that the proposal is operative or safer than existing CSM."
      ],
      "followUpOn": "2026-07-20",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-e36227c0b90d311411525cc0",
      "stableKey": "optimism-bridge:citizens-house-pause-token-house-only-voting:2026-06-25",
      "version": 1,
      "eventDate": "2026-06-25",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Optimism proposes Token House-only voting during the Citizens' House pause",
      "category": "governance",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "optimism-bridge",
          "name": "Optimism canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Operating Manual Update Proposal",
          "authority": "Optimism Foundation",
          "url": "https://gov.optimism.io/t/operating-manual-update-proposal/10735",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-06-25"
        }
      ],
      "whatHappened": "The Optimism Foundation proposed updating the Operating Manual to remove references to the paused Citizens' House and Joint House voting, leaving the Token House as the voting body during the pause.",
      "whatChanged": "If approved, the documented governance process would consolidate voting in the token-weighted Token House while the Citizens' House remains paused. The proposal states that removals require Token House approval at a 51% threshold.",
      "whatDidNotChange": "The June 25 candidate did not establish approval or merger of the manual update. It did not change bridge contracts, Security Council permissions, upgrade keys, pause roles, or withdrawal mechanics.",
      "confirmedFacts": [
        "The Foundation had decided to pause Citizens' House operations.",
        "The proposed manual would remove references to the Citizens' House and Joint House voting.",
        "Only the Token House would vote while the Citizens' House is paused.",
        "The proposal states that removal of important manual provisions requires approval at a 51% threshold."
      ],
      "unresolved": [
        "The vote outcome and manual merge after the June event boundary.",
        "The duration and reactivation criteria for the Citizens' House pause.",
        "How the revised process changes stakeholder checks on canonical-bridge and shared protocol upgrades.",
        "Whether any separate charter, constitutional, Security Council, or on-chain authorization changes were required."
      ],
      "advisorDiligenceImplications": [
        "Review the Optimism bridge memo's governance and upgrade-authorization map if the manual change becomes effective.",
        "Distinguish Token House voting-process changes from on-chain Security Council, pause, and upgrade-key authority.",
        "Monitor whether reduced non-token stakeholder participation alters the diligence assessment for future bridge upgrades."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-5ac66f8c5bc8a88686ad2542",
      "stableKey": "lido-blockscape-ovh-validator-outage-2026-06-24",
      "version": 1,
      "eventDate": "2026-06-24",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Blockscape reports Lido validator outage and failed failover",
      "category": "security_incident",
      "posture": "postmortem",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[Post-Mortem] Blockscape - OVH Infrastructure Incident",
          "authority": "Blockscape via Lido Governance",
          "url": "https://research.lido.fi/t/post-mortem-blockscape-ovh-infrastructure-incident/11706",
          "documentType": "official_operator_postmortem",
          "publishedOn": "2026-06-29"
        }
      ],
      "whatHappened": "An OVH failure took Blockscape's Lido-2 cluster offline and simultaneously impaired components needed by its failover design.",
      "whatChanged": "Fresh Vouch and MikroTik instances restored the cluster, Blockscape compensated missed rewards, and the operator committed to test a cross-provider multi-instance Vouch design.",
      "whatDidNotChange": "The record does not establish a Lido-wide outage, slashing, key compromise, withdrawal impairment, or production deployment of the planned remediation.",
      "confirmedFacts": [
        "The incident occurred June 24, 2026 and affected Blockscape's Lido-2 cluster.",
        "The infrastructure failure made Vouch and MikroTik unavailable and prevented failover.",
        "Muted monitoring delayed normal detection.",
        "Fresh instances restored service.",
        "Blockscape says it compensated lost rewards."
      ],
      "unresolved": [
        "Exact duration, validator count, and missed-reward amount.",
        "Compensation transaction and final settlement evidence.",
        "Production timing for the cross-provider remediation."
      ],
      "advisorDiligenceImplications": [
        "Add the shared-infrastructure and alert-suppression failures to Lido node-operator diligence.",
        "Verify compensation and remediation; this operator event alone does not justify restricting Lido-wide exposure."
      ],
      "followUpOn": "2026-07-31",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-44bf81c6e7db4513bf99660b",
      "stableKey": "aave-v3:megaeth:stcusd-onboarding-arfc-approval-2026-06",
      "version": 1,
      "eventDate": "2026-06-23",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Aave advances stcUSD onboarding on MegaETH",
      "category": "economic_change",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Onboard stcUSD to Aave V3 MegaETH",
          "authority": "Aave DAO via Snapshot",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0x84ccc14e104b18a74ef47375ccd59f7f7aeeb61716dbb2c362ea7a538da3e08f",
          "documentType": "snapshot_governance_record",
          "publishedOn": "2026-06-19"
        }
      ],
      "whatHappened": "Aave DAO's Snapshot vote approved advancing stcUSD onboarding to the Aave v3 MegaETH market.",
      "whatChanged": "The approved ARFC specifies a 10 million supply cap and an isolated stablecoin E-Mode with 88% LTV, 90% liquidation threshold, and a 4% liquidation bonus.",
      "whatDidNotChange": "The ARFC did not itself list stcUSD on-chain; the base reserve configuration states collateral disabled, while collateral use is confined to the proposed E-Mode configuration.",
      "confirmedFacts": [
        "The vote closed on June 23 with overwhelming support.",
        "stcUSD is described as the staked, yield-bearing component of Cap Protocol's cUSD.",
        "The proposed reserve is not borrowable and has no borrow cap.",
        "The proposal states that a final AIP is required after ARFC approval."
      ],
      "unresolved": [
        "The record does not establish final AIP execution or that the reserve became live.",
        "The final deployed risk parameters and oracle configuration remain unconfirmed."
      ],
      "advisorDiligenceImplications": [
        "Monitor the final AIP because the proposed E-Mode introduces an 88% LTV for a yield-bearing stablecoin wrapper.",
        "Assess cUSD backing, stcUSD staking mechanics, oracle design, and wrap depth before recognizing the listing as acceptable collateral.",
        "Do not apply the proposed configuration to existing Aave markets before on-chain execution is verified."
      ],
      "followUpOn": "2026-08-26",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-5ff05040fee0f6555c434388",
      "stableKey": "lido:simple-dvt:regular-cluster-winddown-approval-2026-06",
      "version": 1,
      "eventDate": "2026-06-22",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Lido approves early wind-down of Simple DVT regular clusters",
      "category": "closure_deprecation",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Wind Down Simple DVT Module Regular Clusters",
          "authority": "Lido DAO via Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x6ab9651fba999ba29ba780fe61d68cc23e7aeb83c841181c5c1933dec9197f37",
          "documentType": "snapshot_governance_record",
          "publishedOn": "2026-06-12"
        }
      ],
      "whatHappened": "Lido DAO approved an early wind-down plan for the 72 regular clusters in the Simple DVT Module.",
      "whatChanged": "The approved plan moves regular-cluster operators toward CSM continuation paths and authorizes a grant framework funded from an existing allocation.",
      "whatDidNotChange": "The vote does not prove that any cluster exited, that stake was migrated, or that the combined Community Staking and Simple DVT share changed for two consecutive quarters.",
      "confirmedFacts": [
        "The vote closed on June 22 with all recorded voting power in support.",
        "The wind-down occurs before the previously communicated maximum three-year module lifetime.",
        "Continuation paths include CSM and an Identified DVT Cluster operator type.",
        "No additional funding was requested beyond the existing grant allocation."
      ],
      "unresolved": [
        "The executed wind-down schedule, number of continuing operators, stake migration, and effect on validator diversity remain unresolved.",
        "The resulting Simple DVT and CSM stake shares require post-transition measurement."
      ],
      "advisorDiligenceImplications": [
        "Reassess Lido's operator-diversity evidence as clusters exit or move into CSM.",
        "Track quarterly Simple DVT and CSM stake shares against the memo's decentralization criterion.",
        "Verify that validator exits and migrations do not create withdrawal, slashing, or operational congestion."
      ],
      "followUpOn": "2026-08-26",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-6d9a1c4ed9fc9765dbdd25b2",
      "stableKey": "lido:lip-33:cmv2-csmv3-architecture-approval-2026-06",
      "version": 1,
      "eventDate": "2026-06-22",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Lido approves CMv2 and CSMv3 architecture and rollout plan",
      "category": "upgrade_migration",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "LIP-33: CMv2 and CSMv3 Architecture, Key Parameters, Rollout Plan",
          "authority": "Lido DAO via Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x7b07bc31f0b38b69a117473031bc126becc70b9fa37246b53d9fe5a841c814f5",
          "documentType": "snapshot_governance_record",
          "publishedOn": "2026-06-15"
        }
      ],
      "whatHappened": "Lido DAO approved LIP-33's architecture, parameters, governance model, and rollout plan for Curated Module v2 and Community Staking Module v3.",
      "whatChanged": "The approved design adds 0x02 withdrawal-credential support, large validators, new bonding and penalty mechanics, more granular roles, weighted Curated Module allocation, and a proposed 15% CSM stake-share upper bound.",
      "whatDidNotChange": "The vote did not deploy the modules, migrate validators, or prove that the audited production code and live parameters match the approved design.",
      "confirmedFacts": [
        "The vote closed on June 22 with all recorded voting power in favor.",
        "CMv2 and CSMv3 share substantial code and depend on Staking Router v3.",
        "CSMv3 introduces reward splitting, semi-automated penalties, and more granular operator-type roles.",
        "CMv2 introduces bonding, weighted stake allocation, a node-operator meta registry, and foundations for a validator marketplace."
      ],
      "unresolved": [
        "Security audits, final production code, deployment timing, and live Easy Track permissions remain unconfirmed.",
        "The realized effect on operator concentration and the combined CSM and Simple DVT share is unresolved until rollout."
      ],
      "advisorDiligenceImplications": [
        "Review module-level governance roles, bonding, penalty, and allocation controls before recognizing the upgrade as operative.",
        "Track whether the rollout improves or weakens operator diversity relative to Lido's memo criteria.",
        "Verify deployed parameters, especially the CSM stake-share limit and Easy Track permissions."
      ],
      "followUpOn": "2026-08-26",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-715bac9aa2a75fcd10ad6967",
      "stableKey": "lido:wsteth-bridge-endpoints:canonical-status-revocation-approval-2026-06",
      "version": 1,
      "eventDate": "2026-06-22",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Lido approves bridge-endpoint de-recognition and future NEC revocations",
      "category": "closure_deprecation",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Revoke Canonical Status of (w)stETH Bridge Endpoints on Selected Chains and Authorize NEC for Revocations",
          "authority": "Lido DAO via Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x09880de4739dcef13c4aa5605f1dca23556fc7495d09ecc84561a10f26a59b5c",
          "documentType": "snapshot_governance_record",
          "publishedOn": "2026-06-12"
        }
      ],
      "whatHappened": "Lido DAO approved revoking canonical recognition for selected stETH and wstETH bridge endpoints and delegating future revocation decisions to the Network Expansion Committee.",
      "whatChanged": "The approved governance position narrows Lido's recognized multichain perimeter and expands the NEC's authority from endpoint recognition to future de-recognition.",
      "whatDidNotChange": "The proposal explicitly does not disable bridge infrastructure, force migration, impair existing token balances, or make a technical safety judgment about the affected bridges.",
      "confirmedFacts": [
        "The vote closed on June 22 with overwhelming approval.",
        "The listed networks are zkSync Era, Mode, Scroll, Mantle, Swell, Zircuit, Soneium, Polygon PoS, and Lisk.",
        "Future revocations are delegated to the NEC under the approved governance framework.",
        "The proposal states that holders do not need to take immediate action."
      ],
      "unresolved": [
        "The timing and publication of each recognition-status update remain to be verified.",
        "The precise disclosure and review process the NEC will use for future revocations remains unresolved."
      ],
      "advisorDiligenceImplications": [
        "Remove canonical-recognition assumptions for the listed endpoints from bridge diligence once the status update is confirmed.",
        "Do not equate loss of recognition with technical shutdown or immediate asset impairment.",
        "Add NEC revocation authority and its public-notice process to the Lido control map."
      ],
      "followUpOn": "2026-08-26",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-9f040e9e527012035b09ebfa",
      "stableKey": "lido:lip-35:staking-router-v3-architecture-approval-2026-06",
      "version": 1,
      "eventDate": "2026-06-22",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Lido approves Staking Router v3 architecture",
      "category": "upgrade_migration",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "LIP-35: Staking Router v3 Architecture and Key Parameters",
          "authority": "Lido DAO via Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x8fdec5d2cb70f8a266c4f5a269051fcfa985fab0f66cbe747702719d7433f606",
          "documentType": "snapshot_governance_record",
          "publishedOn": "2026-06-15"
        }
      ],
      "whatHappened": "Lido DAO approved the architecture and key parameters for Staking Router v3.",
      "whatChanged": "The approved design replaces validator-count accounting with balance-based accounting, supports validators up to 2,048 ETH, adds governed consolidation-based module migration, updates exit oracles, and reserves configurable buffered ETH for consensus-layer deposits.",
      "whatDidNotChange": "Snapshot approval did not deploy SRv3, execute module migrations, or establish that stETH withdrawal mechanics changed on-chain.",
      "confirmedFacts": [
        "The vote closed on June 22 with overwhelming support.",
        "SRv3 is the foundation for the separately proposed CMv2 and CSMv3 modules.",
        "The design includes balance-aware deposits, top-ups, accounting, and exit-oracle behavior.",
        "The initial consolidation pipeline is scoped to migration from Curated Module v1 to v2."
      ],
      "unresolved": [
        "Deployment timing, final audited code, and actual migration execution are not established by this record.",
        "The final governance-configured buffered-ETH reservation and operational limits remain to be verified on-chain."
      ],
      "advisorDiligenceImplications": [
        "Reopen Lido architecture diligence before execution because accounting, exits, stake allocation, and module-migration controls all change.",
        "Verify that the withdrawal path and liquidity buffer behavior remain compatible with the memo's withdrawal-related kill criteria.",
        "Track audit completion, deployed bytecode, migration safeguards, and live parameter values."
      ],
      "followUpOn": "2026-08-26",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-c0ea242c4c3623209b3f33dc",
      "stableKey": "lido-labs-board-nemo-approval-2026-06-22",
      "version": 1,
      "eventDate": "2026-06-22",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Lido tokenholders approve the proposed Lido Labs board update",
      "category": "governance",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Lido Labs proposes Nemo as a new director",
          "authority": "Lido Labs via Lido Governance",
          "url": "https://research.lido.fi/t/lido-labs-proposes-nemo-as-a-new-director/11624",
          "documentType": "official_governance_record",
          "publishedOn": "2026-06-04"
        }
      ],
      "whatHappened": "Lido's Snapshot process approved appointing Nemo as a Lido Labs director while Konstantin transitions to an advisory role.",
      "whatChanged": "The community-approval step advanced a change in oversight of the foundation that develops and helps maintain Lido.",
      "whatDidNotChange": "The record does not establish the board resolution's completion or any transfer of on-chain roles, signers, emergency authority, upgrade rights, assets, or parameters.",
      "confirmedFacts": [
        "Lido Labs researches, develops, deploys, and helps maintain Lido on Ethereum.",
        "Its bylaws require board and community approval for director elections.",
        "The Snapshot ended June 22 with 55.1 million LDO for and 17 against.",
        "The proposed board is Sam Kozin, Jacobus Pietersen, and Nemo."
      ],
      "unresolved": [
        "Board resolution and effective appointment date.",
        "Any resulting committee, signer, or reporting-line changes.",
        "Practical effects on deployment, maintenance, or emergency operations."
      ],
      "advisorDiligenceImplications": [
        "Update Lido's governance map after the board resolution and appointment are verified.",
        "Do not describe on-chain control as changed without separate signer, role, or contract evidence."
      ],
      "followUpOn": "2026-07-15",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-2b6f6f3f65d50efd38e4f267",
      "stableKey": "rocket-pool:rpip-81:rpl-inflation-rebalance-approval-2026-06",
      "version": 1,
      "eventDate": "2026-06-19",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Rocket Pool approves RPIP-81 inflation and funding rebalance",
      "category": "economic_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "rocket-pool",
          "name": "Rocket Pool"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Rebalance RPL Inflation for Protocol Funding (RPIP-81)",
          "authority": "Rocket Pool DAO via Snapshot",
          "url": "https://snapshot.org/#/rocketpool-dao.eth/proposal/0x13c4cec1a2631fc08424945e859144ee717b27fa4afd1ddf030929d817aa3af9",
          "documentType": "snapshot_governance_record",
          "publishedOn": "2026-06-05"
        }
      ],
      "whatHappened": "Rocket Pool governance approved RPIP-81, which reallocates RPL inflation toward protocol funding before Saturn 2 and changes inflation and allocations after Saturn 2.",
      "whatChanged": "The approved policy reduces the pre-Saturn-2 node-operator allocation from 70% to 50%, raises pDAO's share to 47.5%, and calls for 2.5% annual inflation with 95% of rewards to pDAO after Saturn 2.",
      "whatDidNotChange": "The Snapshot vote did not itself execute the required on-chain pDAO parameter change or establish that Saturn 2 had launched.",
      "confirmedFacts": [
        "The vote closed on June 19 with the required outcome and approximately 11,734.6 RPL voting for versus 99.7 against.",
        "The pre-Saturn-2 target allocation is 50% node operators, 47.5% pDAO, and 2.5% oDAO.",
        "The post-Saturn-2 target removes node-operator RPL rewards and allocates 95% to pDAO and 5% to oDAO.",
        "The internal pDAO policy is set at 30% IMC, 40% GMC, and 30% reserve treasury."
      ],
      "unresolved": [
        "On-chain implementation timing and final Saturn 2 activation remain unresolved.",
        "The realized effect on node-operator participation and protocol decentralization is not yet established."
      ],
      "advisorDiligenceImplications": [
        "Review whether reduced node-operator incentives affect operator retention or decentralization evidence supporting rETH.",
        "Separate RPL tokenomics changes from rETH backing and redemption mechanics, which the proposal does not directly change.",
        "Verify on-chain implementation and monitor active operator count after the incentive transition."
      ],
      "followUpOn": "2026-08-26",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-cc5eedc2474b352bb7f2baa4",
      "stableKey": "optimism-bridge-kona-fault-proof-soundness-fix-2026-06-19",
      "version": 1,
      "eventDate": "2026-06-19",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "OP Labs discloses and patches a kona fault-proof soundness bug",
      "category": "security_incident",
      "posture": "confirmed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "bridge",
          "id": "optimism-bridge",
          "name": "Optimism canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "kona-client v1.6.0",
          "authority": "OP Labs",
          "url": "https://github.com/ethereum-optimism/optimism/releases/tag/kona-client/v1.6.0",
          "documentType": "official_code_release",
          "publishedOn": "2026-06-19"
        }
      ],
      "whatHappened": "OP Labs published a required kona-client release disclosing a fault-proof soundness bug in post-Jovian BLOBBASEFEE handling.",
      "whatChanged": "A patched client became available and was designated as required for Upgrade 19, which is intended to promote kona-client to the primary fault-proof program.",
      "whatDidNotChange": "The release does not establish that affected code was active on OP Mainnet, that it was exploited, that an invalid withdrawal finalized, that funds were lost, or that Upgrade 19 deployed in June.",
      "confirmedFacts": [
        "The official release labels v1.6.0 a critical security fix and required update.",
        "The defect could make proof execution diverge from the canonical chain.",
        "The patch pins the post-Jovian blob-fee inputs to canonical-client values.",
        "The release states that v1.6.0 is required for Upgrade 19."
      ],
      "unresolved": [
        "Whether vulnerable code was active for OP Mainnet.",
        "Whether the defect was triggered or exploitable in a live dispute game.",
        "Upgrade 19 approval, deployment, activation, and patched-program adoption."
      ],
      "advisorDiligenceImplications": [
        "Review the bridge memo's fault-proof dependency before treating Upgrade 19 as operative.",
        "Verify deployed program versions and governance execution; the release alone does not establish client loss or justify a restriction."
      ],
      "followUpOn": "2026-07-08",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-9a37461213c06c35e9597bb1",
      "stableKey": "axelar:amplifier-multisig-provers:admin-rotation-proposal-481",
      "version": 1,
      "eventDate": "2026-06-17",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Axelar rotates administrators for nine MultisigProver contracts",
      "category": "control_change",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Rotate MultisigProver Admin for flow, sui, stellar, xrpl-evm, plume, hedera, berachain, hyperliquid, monad.",
          "authority": "Axelar on-chain governance",
          "url": "https://axelarscan.io/proposal/481",
          "documentType": "on_chain_governance_record",
          "publishedOn": "2026-06-17"
        }
      ],
      "whatHappened": "Axelar governance passed proposal 481 and updated the administrator on MultisigProver contracts for nine chain integrations.",
      "whatChanged": "The Flow, Sui, Stellar, XRPL-EVM, Plume, Hedera, Berachain, Hyperliquid, and Monad MultisigProver contracts were assigned administrator axelar1w2ey0ek9e8q2dfmeznz6ah49zdywpdme0z0kly.",
      "whatDidNotChange": "The proposal did not confirm new verifier sets, migrate contract code, or establish any service interruption.",
      "confirmedFacts": [
        "Proposal 481 passed on June 17.",
        "The payload contains nine update_admin contract calls.",
        "Every listed MultisigProver received the same new administrator address."
      ],
      "unresolved": [
        "The controller type, signer identities, threshold, and operating rules for axelar1w2ey0ek9e8q2dfmeznz6ah49zdywpdme0z0kly remain unresolved."
      ],
      "advisorDiligenceImplications": [
        "Update the controller map for all nine Amplifier integrations.",
        "Assess the aggregate blast radius created by one administrator controlling multiple MultisigProver contracts.",
        "Monitor subsequent verifier-set confirmations and migrations for use of the new authority."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-316e33e59c8236f6e6f640e5",
      "stableKey": "axelar:core-v1.4.7:upgrade-approval-proposal-480",
      "version": 1,
      "eventDate": "2026-06-16",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Axelar approves core v1.4.7 upgrade at height 30,135,800",
      "category": "upgrade_migration",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Axelar Core v1.4 Upgrade Proposal",
          "authority": "Axelar on-chain governance",
          "url": "https://axelarscan.io/proposal/480",
          "documentType": "on_chain_governance_record",
          "publishedOn": "2026-06-16"
        }
      ],
      "whatHappened": "Axelar governance passed proposal 480, scheduling axelar-core v1.4.7 at block height 30,135,800.",
      "whatChanged": "The network obtained an approved consensus-upgrade plan and reproducible binary references for Linux and macOS builds.",
      "whatDidNotChange": "The passage record does not establish that the target height was reached successfully, that validators upgraded, or that cross-chain service remained uninterrupted.",
      "confirmedFacts": [
        "Proposal 480 passed on June 16.",
        "The payload is a Cosmos MsgSoftwareUpgrade.",
        "The plan names v1.4 and specifies axelar-core v1.4.7 binaries at height 30,135,800."
      ],
      "unresolved": [
        "Upgrade execution, validator adoption, state-migration results, and service continuity are not established by this candidate.",
        "The candidate does not describe the functional changes included in v1.4.7."
      ],
      "advisorDiligenceImplications": [
        "Verify the upgrade-height block, resulting software version, and any incident or halt before closing monitoring.",
        "Review release notes and state migrations for effects on consensus, routing, gateway governance, or emergency controls.",
        "Do not infer improved safety from upgrade approval alone."
      ],
      "followUpOn": "2026-08-26",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-8f0e61fc4cba537da29623d1",
      "stableKey": "optimism-bridge:upgrade-19-karst-hardfork:2026-06-15",
      "version": 1,
      "eventDate": "2026-06-15",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Optimism proposes Upgrade 19 and the Karst hardfork",
      "category": "upgrade_migration",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "optimism-bridge",
          "name": "Optimism canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Upgrade 19b — Karst Hardfork",
          "authority": "OP Labs",
          "url": "https://gov.optimism.io/t/upgrade-19b-karst-hardfork/10713",
          "documentType": "official_protocol_upgrade_proposal",
          "publishedOn": "2026-06-15"
        }
      ],
      "whatHappened": "OP Labs submitted the off-cycle Upgrade 19 proposal, bundling the Karst execution-layer hardfork with new predeploy upgrade machinery, OP Contracts Manager v2, a new primary fault-proof implementation, and portal dispatch changes.",
      "whatChanged": "If approved and executed, permissionless fault-proof chains would change their respected game type from CANNON to CANNON_KONA for withdrawal proving; L2CM and OPCMv2 would change upgrade execution; the portal would dispatch claims by game type; seven Fusaka EIPs and a lower BN256 pairing-input limit would become active; and op-geth and op-program support would end.",
      "whatDidNotChange": "The proposal did not establish mainnet approval or activation during June. It stated that fee take, governor/servicer role separation, ossified gas limits, and direct fee-margin controls would not change, and it anticipated no downtime.",
      "confirmedFacts": [
        "CANNON_KONA was proposed as the respected game type for permissionless fault-proof chains.",
        "The proposal would make kona-client on Cannon the primary fault-proof program used for withdrawals.",
        "L2CM would add deterministic predeploy upgrades through ProxyAdmin.",
        "OPCMv2 would replace five manager functions with unified deploy and upgrade calls.",
        "The mainnet activation was scheduled for July 8, 2026, pending governance approval, outside the permitted event-date boundary."
      ],
      "unresolved": [
        "The governance outcome and mainnet execution after the June boundary.",
        "Final audit results, production contract addresses, upgrade transactions, and deployed component versions.",
        "Operator readiness for migration from op-geth and op-program to op-reth and kona-client.",
        "Whether the new fault-proof and portal-dispatch paths operated normally after activation."
      ],
      "advisorDiligenceImplications": [
        "Review the Optimism bridge memo's withdrawal-proof, respected-game-type, and upgrade-execution assumptions before recognizing Upgrade 19 as operative.",
        "Verify governance approval, deployed contracts, upgrade transactions, audits, prestates, and operator migration evidence on-chain.",
        "Do not infer that deterministic tooling or completed testing makes the bridge safer or approved."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-91c1cff429b66e7c1cb8f515",
      "stableKey": "axelar:secret-ibc-bridge:forged-deposit-drain:2026-06-10",
      "version": 1,
      "eventDate": "2026-06-10",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Axelar–Secret IBC route contained after unbacked-token drain",
      "category": "security_incident",
      "posture": "contained",
      "materiality": "material",
      "evidenceState": "mixed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Security Incident: Axelar<>Secret IBC Bridge Exploit (June 10, 2026)",
          "authority": "Secret Network",
          "url": "https://forum.scrt.network/t/security-incident-axelar-secret-ibc-bridge-exploit-june-10-2026/7995",
          "documentType": "official_incident_postmortem",
          "publishedOn": "2026-06-19"
        }
      ],
      "whatHappened": "An attacker exploited the Secret-side ICS-20 contract used by the Axelar–Secret route, minted unbacked saTokens, and redeemed them through the legitimate channel against real escrowed assets.",
      "whatChanged": "The affected saTokens became impaired or undercollateralized, and the Axelar Secret and Secret-SNIP connections were paused after discovery.",
      "whatDidNotChange": "The primary account says Axelar's core validator and threshold-signature protocol and other Axelar integrations were not affected; containment does not imply asset recovery.",
      "confirmedFacts": [
        "The exploit occurred on June 10, 2026 and involved the Secret-side contract at secret1yxjmepvyl2c25vnt53cr2dpn8amknwausxee83.",
        "The official account estimates approximately $4.67 million of unbacked tokens were minted and redeemed against genuine bridge reserves.",
        "Axelar–Secret bridging was disabled and the relevant connections were paused by June 19.",
        "Existing Axelar-bridged saTokens on Secret were identified as impaired or undercollateralized."
      ],
      "unresolved": [
        "Axelar and Secret accounts differ on responsibility for monitoring and recovery decisions; this draft does not resolve that dispute.",
        "The amount ultimately recoverable and the disposition of residual attacker-controlled funds remain unresolved."
      ],
      "advisorDiligenceImplications": [
        "Treat the Axelar–Secret route and its saTokens as unavailable pending verified recapitalization and restoration.",
        "Review every approved use of Axelar at the receiving-contract level; Axelar core approval does not validate a downstream integration's source authentication.",
        "Reopen the Axelar memo to record the integration-layer loss and containment without misclassifying it as a core Axelar consensus compromise."
      ],
      "followUpOn": "2026-08-26",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-0845a67386f42a9dc524e010",
      "stableKey": "axelar:evm-gateways:governance-transfer-approval-proposal-474",
      "version": 1,
      "eventDate": "2026-06-08",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Axelar approves governance-transfer calls for multi-chain Gateway contracts",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Interchain Governance Proposal",
          "authority": "Axelar on-chain governance",
          "url": "https://axelarscan.io/proposal/474",
          "documentType": "on_chain_governance_record",
          "publishedOn": "2026-06-08"
        }
      ],
      "whatHappened": "Axelar governance passed proposal 474 containing interchain calls to Gateway contracts across 17 EVM integrations.",
      "whatChanged": "The approved payloads encode transferGovernance(address) calls directing Gateway governance toward 0x7acbae6cba67d78aaf69e47000884ae00f9b2525.",
      "whatDidNotChange": "Passage on Axelar does not by itself prove each destination-chain call cleared its delay and executed successfully.",
      "confirmedFacts": [
        "Proposal 474 passed on June 8.",
        "The record includes calls for Celo, Ethereum, Avalanche, Polygon, Moonbeam, BNB Chain, Arbitrum, Kava, Filecoin, Optimism, Linea, Base, Mantle, Scroll, Immutable, Fraxtal, and Blast.",
        "The target contract addresses correspond to Axelar Gateway contracts, and the nested call selector is transferGovernance(address)."
      ],
      "unresolved": [
        "Execution status on each destination chain remains unresolved.",
        "The ownership, signer composition, threshold, and operating rules of the proposed new governance address remain unresolved."
      ],
      "advisorDiligenceImplications": [
        "Verify destination-chain execution and timelock completion separately for every relevant Gateway.",
        "Update the Axelar control map only for chains where the governance transfer is confirmed.",
        "Identify and assess the new governance controller before treating the transfer as an improvement."
      ],
      "followUpOn": "2026-08-26",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-4689e67ea087ab159e91a68a",
      "stableKey": "axelar:centrifuge-legacy-chain:route-deactivation-proposal-473",
      "version": 1,
      "eventDate": "2026-06-06",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Axelar deactivates routing for the legacy Centrifuge chain",
      "category": "closure_deprecation",
      "posture": "deprecated",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Deactivate legacy EVM chain centrifuge",
          "authority": "Axelar on-chain governance",
          "url": "https://axelarscan.io/proposal/473",
          "documentType": "on_chain_governance_record",
          "publishedOn": "2026-06-06"
        }
      ],
      "whatHappened": "Axelar governance passed proposal 473 and deactivated the legacy Centrifuge chain in the nexus module.",
      "whatChanged": "Axelar stopped routing transfers and messages to and from the deprecated legacy Centrifuge chain.",
      "whatDidNotChange": "The proposal did not deactivate other Axelar integrations or affect Centrifuge's newer Ethereum-native CFG token directly.",
      "confirmedFacts": [
        "Proposal 473 passed on June 6.",
        "The payload is an Axelar DeactivateChainRequest naming centrifuge.",
        "The stated migration window for the legacy canonical token had closed on November 30, 2025.",
        "The proposal states that the legacy chain remained block-producing but was no longer actively supported."
      ],
      "unresolved": [
        "Any residual user balances, unsupported messages, or applications still relying on the retired route are not identified by the record."
      ],
      "advisorDiligenceImplications": [
        "Remove the legacy Centrifuge route from any approved Axelar path inventory.",
        "Confirm that no client workflow or dependency still references the deprecated integration.",
        "Preserve the distinction between this route retirement and the status of Ethereum-native CFG."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-53012331af923cc221885a19",
      "stableKey": "lido:staking-router-v3:lip-35-proposal:2026-06-03",
      "version": 1,
      "eventDate": "2026-06-03",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Lido proposes Staking Router v3 accounting and deposit architecture",
      "category": "upgrade_migration",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Staking Router v3 — Design & Implementation Proposal (LIP-35)",
          "authority": "Lido",
          "url": "https://research.lido.fi/t/staking-router-v3-design-implementation-proposal-lip-35/11621",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-06-03"
        }
      ],
      "whatHappened": "Lido published LIP-35 for review, proposing Staking Router v3 as the foundational upgrade for supporting validators with effective balances up to 2,048 ETH.",
      "whatChanged": "If approved and executed, Lido would replace count-based consensus-layer accounting with balance-based accounting, add proof-gated validator top-ups, introduce a consolidation pipeline, reserve buffered ETH for consensus-layer deposits, and add bounded Easy Track control over module share limits.",
      "whatDidNotChange": "The June 3 record was a design and implementation proposal awaiting a vote. It did not establish a mainnet upgrade, final deployed addresses, completed audits, or an operative change to stETH accounting or withdrawals during the June event window.",
      "confirmedFacts": [
        "The proposal supports validators with effective balances between 32 and 2,048 ETH.",
        "The proposed accounting model tracks validator balances rather than multiplying validator counts by 32 ETH.",
        "A proposed TopUpGateway would require on-chain Merkle proofs of consensus-layer state.",
        "The proposed consolidation pipeline would support migration from Curated Module v1 to Curated Module v2.",
        "The proposal would protect part of buffered ETH for consensus-layer deposits and add a bounded Easy Track factory for module share limits."
      ],
      "unresolved": [
        "The proposal's vote and execution outcomes after the June event boundary.",
        "Final audits, deployed contract addresses, parameters, pausers, proof assumptions, and module-share bounds.",
        "How the deposit reserve would interact with withdrawal demand under stress.",
        "Whether implementation testing demonstrated correct totalPooledEther and reward accounting for large validators."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido memo's validator-accounting, withdrawal-liquidity, and module-allocation assumptions before treating Staking Router v3 as operative.",
        "Verify final contracts, audits, governance execution, reserve parameters, and proof-verification controls on-chain.",
        "Do not infer that the proposed architecture improves safety or that any Ketju approval changed."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-07527a97ce94009082f75471",
      "stableKey": "coinbase-bridge:withdrawal-delay-tee-proposal-halt:2026-05-29",
      "version": 1,
      "eventDate": "2026-05-31",
      "publishedAt": "2026-08-22T14:06:01.557Z",
      "title": "Base restores mainnet withdrawals after a TEE enclave issue halted proposals",
      "category": "market_stress",
      "posture": "recovered",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "coinbase-bridge",
          "name": "Base canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Base Mainnet Withdrawal Delay",
          "authority": "Base Status",
          "url": "https://status.base.org/incidents/lj9f7jhbb2ys",
          "documentType": "official_status_incident",
          "publishedOn": "2026-05-29"
        }
      ],
      "whatHappened": "Base reported that a TEE enclave issue halted proposals and delayed Base mainnet withdrawals beginning May 29. The first-party status record marked the incident resolved on May 31.",
      "whatChanged": "The canonical exit path experienced a temporary operational delay because state proposals needed for withdrawal progression stopped advancing.",
      "whatDidNotChange": "The notice reported no bridge-contract exploit, fund loss, change to the seven-day challenge period, change to upgrade authority, or permanent withdrawal-mechanism modification.",
      "confirmedFacts": [
        "Base identified the incident on May 29, 2026 at 15:55 UTC.",
        "Base attributed the withdrawal delay to a TEE enclave issue that halted proposals.",
        "The incident affected Base mainnet withdrawals.",
        "Base marked the incident resolved on May 31, 2026 at 03:38 UTC."
      ],
      "unresolved": [
        "The root cause of the TEE enclave failure and the exact remediation deployed.",
        "The number and value of withdrawals delayed and their maximum additional completion time.",
        "Whether alternative proposer or proof paths were available and tested during the incident.",
        "The recurrence risk and any subsequent changes to proposer failover or monitoring."
      ],
      "advisorDiligenceImplications": [
        "Add proposer and TEE-enclave availability to the Base bridge operational-dependency review.",
        "Review withdrawal monitoring and contingency procedures for a proposal halt lasting longer than one day.",
        "Because Base reported recovery, the historical incident does not by itself justify a current restriction, but it requires memo and operating-runbook review."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-c5357a07e231434087031b63",
      "stableKey": "axelar:voting-verifier-code64-ten-chain-migration:2026-05-22",
      "version": 1,
      "eventDate": "2026-05-22",
      "publishedAt": "2026-08-22T14:06:01.557Z",
      "title": "Axelar executes VotingVerifier migrations across ten Amplifier chains",
      "category": "upgrade_migration",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Migrate VotingVerifier to code id 64 on 10 chains",
          "authority": "Axelar on-chain governance",
          "url": "https://axelarscan.io/proposal/472",
          "documentType": "official_onchain_governance_record",
          "publishedOn": "2026-05-22"
        }
      ],
      "whatHappened": "Axelar governance passed and executed proposal 472, migrating ten VotingVerifier contracts to code ID 64 across Flow, Sui, Stellar, XRPL EVM, Plume, Hedera, Berachain, Hyperliquid, Monad, and Solana Amplifier integrations.",
      "whatChanged": "The VotingVerifier implementation governing verification for the ten named integrations moved to code ID 64, with chain-codec addresses supplied in each migration message.",
      "whatDidNotChange": "The record did not establish any change to Axelar's validator consensus quorum, gateway contracts, emergency committee, or integrations outside the ten named Amplifier chains.",
      "confirmedFacts": [
        "Proposal 472 reached passed status on May 22, 2026.",
        "The proposal contained ten MsgMigrateContract messages.",
        "Each migration targeted VotingVerifier code ID 64.",
        "The named integrations were Flow, Sui, Stellar, XRPL EVM, Plume, Hedera, Berachain, Hyperliquid, Monad, and Solana.",
        "Live contract information for sampled proposal targets reports code ID 64."
      ],
      "unresolved": [
        "The behavioral and security differences between the prior VotingVerifier implementation and code ID 64.",
        "The audit coverage and deployment testing for the new implementation and chain-codec dependencies.",
        "Whether all ten integrations processed messages normally after migration.",
        "Whether any Ketju position used one of the named Amplifier routes."
      ],
      "advisorDiligenceImplications": [
        "Review Axelar's integration-specific verification assumptions for any contemplated route among the ten migrated chains.",
        "Obtain the code diff, audit, and post-migration operating evidence before treating the upgrade as risk-reducing.",
        "No exploit or consensus-threshold change is established, so the event requires review rather than an automatic restriction."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-8ffa0fc005e3b24a6c7a7ee6",
      "stableKey": "axelar:interchain-token-service-code63-migration:2026-05-15",
      "version": 1,
      "eventDate": "2026-05-15",
      "publishedAt": "2026-08-22T14:06:01.557Z",
      "title": "Axelar executes an InterchainTokenService contract migration",
      "category": "upgrade_migration",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Migrate InterchainTokenService contract",
          "authority": "Axelar on-chain governance",
          "url": "https://axelarscan.io/proposal/470",
          "documentType": "official_onchain_governance_record",
          "publishedOn": "2026-05-15"
        }
      ],
      "whatHappened": "Axelar governance passed and executed proposal 470, migrating the identified InterchainTokenService contract to code ID 63.",
      "whatChanged": "The on-chain InterchainTokenService contract implementation changed to code ID 63 under the governance-administered migration path.",
      "whatDidNotChange": "The record did not establish a change to validator consensus, gateway thresholds, custody of existing tokens, or token-service economics, and it did not characterize the code-level behavior changed by code ID 63.",
      "confirmedFacts": [
        "Proposal 470 reached passed status on May 15, 2026.",
        "The proposal contained one MsgMigrateContract action.",
        "The target contract was migrated to code ID 63.",
        "Live contract information reports code ID 63 for the proposal's target."
      ],
      "unresolved": [
        "The complete code diff and security rationale for code ID 63.",
        "Audit coverage and pre-deployment testing for the new implementation.",
        "Whether supported token integrations required user or issuer action.",
        "Post-migration operating results and any incidents or compatibility problems."
      ],
      "advisorDiligenceImplications": [
        "Review Axelar's InterchainTokenService implementation and audit evidence before relying on an affected token route.",
        "Verify the deployed contract and integration-specific configuration for any contemplated exposure.",
        "The migration is operative but is not evidence that Axelar became safer or that any new route is approved."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-aa050ffdabb298e81c461164",
      "stableKey": "lombard-btc.b:ccip-exclusive-migration:2026-05-15",
      "version": 1,
      "eventDate": "2026-05-15",
      "publishedAt": "2026-08-22T14:06:01.557Z",
      "title": "Lombard commits BTC.b and LBTC to an exclusive Chainlink CCIP migration",
      "category": "upgrade_migration",
      "posture": "confirmed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "asset",
          "id": "lombard-btc.b",
          "name": "Lombard BTC.b"
        },
        {
          "type": "other",
          "id": "ccip",
          "name": "Chainlink CCIP"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Lombard Is Exclusively Migrating to Chainlink CCIP To Secure $1B+ in Bitcoin Assets",
          "authority": "Lombard Finance",
          "url": "https://www.lombard.finance/blog/lombard-is-exclusively-migrating-to-chainlink-ccip-to-secure-1-b-in-bitcoin-assets/",
          "documentType": "official_protocol_notice",
          "publishedOn": "2026-05-15"
        }
      ],
      "whatHappened": "Lombard announced that Chainlink CCIP would become the exclusive cross-chain infrastructure for LBTC and BTC.b, replacing LayerZero on Solana, Etherlink, Berachain, Corn, and TAC and deprecating LayerZero usage on Morph and Swell.",
      "whatChanged": "Lombard established a concrete migration perimeter and selected CCIP's Cross-Chain Token burn-and-mint model, rate limits, and optional Security Consortium attestation as its future cross-chain architecture.",
      "whatDidNotChange": "The notice did not establish that every lane had completed migration, identify all deployed token and lane addresses, or show any change to Bitcoin reserves, redemption terms, or asset backing on May 15.",
      "confirmedFacts": [
        "The official notice was published on May 15, 2026.",
        "Lombard said CCIP would replace LayerZero across Solana, Etherlink, Berachain, Corn, and TAC.",
        "Lombard said LayerZero usage on Morph and Swell would be deprecated.",
        "The announced design adopts CCIP's Cross-Chain Token standard and retains Lombard ownership of token contracts.",
        "Lombard said its Security Consortium could provide an additional transaction attestation layer."
      ],
      "unresolved": [
        "The chain-by-chain cutover dates and whether each announced migration completed successfully.",
        "The deployed token, pool, lane, rate-limit, and Security Consortium configuration for BTC.b on each supported chain.",
        "The user migration process for any legacy LayerZero representation and whether liquidity remained available throughout cutover.",
        "Whether any legacy LayerZero contracts or privileges remained active after migration."
      ],
      "advisorDiligenceImplications": [
        "Review the Lombard BTC.b memo's bridge, token-contract, rate-limit, and Security Consortium dependency map for the new CCIP architecture.",
        "Verify the live route and deployed addresses for each contemplated chain rather than treating the announcement as proof of completed migration.",
        "Review the CCIP memo for integration-specific configuration because protocol-level CCIP approval does not validate Lombard's individual lane setup."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-02ad76ce6de4c3268b53f630",
      "stableKey": "coinbase-bridge:missed-blocks-transaction-delays:2026-05-13",
      "version": 1,
      "eventDate": "2026-05-14",
      "publishedAt": "2026-08-22T14:06:01.557Z",
      "title": "Base recovers from mainnet transaction delays caused by missed blocks",
      "category": "market_stress",
      "posture": "recovered",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "coinbase-bridge",
          "name": "Base canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Delayed Transactions",
          "authority": "Base Status",
          "url": "https://status.base.org/incidents/0h468wjw300f",
          "documentType": "official_status_incident",
          "publishedOn": "2026-05-13"
        }
      ],
      "whatHappened": "Base experienced an elevated rate of missed mainnet blocks. Transactions submitted during missed blocks were delayed until a later successful block, and Base marked the incident resolved the following day.",
      "whatChanged": "Timely mainnet transaction inclusion was temporarily impaired, creating operational delay risk for bridge initiation, proof, and other Base transactions even though no bridge-specific transaction was identified.",
      "whatDidNotChange": "The notice did not report a complete chain halt, transaction reorganization, fund loss, canonical-bridge exploit, or change to withdrawal and upgrade controls.",
      "confirmedFacts": [
        "Base began investigating elevated missed blocks on May 13, 2026 at 16:44 UTC.",
        "Transactions submitted during missed blocks were delayed until the next successful block.",
        "The incident affected Base mainnet block production.",
        "Base marked the incident resolved on May 14, 2026 at 05:04 UTC."
      ],
      "unresolved": [
        "The cause of the elevated missed-block rate and remediation applied.",
        "The total number and maximum delay of affected transactions.",
        "Whether any deposit, withdrawal, proof, or finalization transactions experienced materially longer processing.",
        "The recurrence risk under comparable block-production conditions."
      ],
      "advisorDiligenceImplications": [
        "Review Base bridge assumptions for sequencer and block-production availability.",
        "Maintain transaction-status checks and resubmission procedures for bridge operations during elevated missed-block periods.",
        "The recovered event does not establish current unavailability but should remain in the Base operational incident record."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-16f2afd5d960112cbd69c364",
      "stableKey": "lido:nest-automated-buyback-lp-proposal:2026-05-11",
      "version": 1,
      "eventDate": "2026-05-11",
      "publishedAt": "2026-08-22T14:06:01.557Z",
      "title": "Lido proposes automated revenue-funded LDO buybacks and liquidity provision",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "NEST: Automated LDO Buyback and Liquidity Provisioning",
          "authority": "Lido Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x022e901a6368573d18b150eecda563dd2ee17ad2aa6a0ef9772151cc7ba55187",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-05-11"
        }
      ],
      "whatHappened": "Lido opened a Snapshot proposal for NEST, a permissionless system that would use bounded staking-revenue surplus to buy LDO through CoW Swap and pair it with wstETH as DAO-owned Curve liquidity.",
      "whatChanged": "If launched through a later on-chain vote and funded, NEST would add automated daily treasury execution, a $40 million annual revenue baseline, a daily order cap, component-level emergency pauses, and Treasury Management Committee funding and recovery powers.",
      "whatDidNotChange": "The proposal did not launch or fund NEST, alter stETH rebase accounting, change withdrawals, modify node-operator allocation, or establish that audits and the later on-chain launch vote had completed.",
      "confirmedFacts": [
        "The initial proposed mode would pair purchased LDO with wstETH in DAO-owned liquidity.",
        "The proposal specifies a $40 million annual revenue baseline and a daily order cap.",
        "Execution would be permissionless but dependent on funding and successful order settlement.",
        "Individual NEST components could be paused independently.",
        "Launching NEST would require a subsequent on-chain DAO vote."
      ],
      "unresolved": [
        "The Snapshot outcome and later on-chain launch vote.",
        "The final audited contracts, deployed addresses, parameters, and funding amount.",
        "The identities and authority boundaries of keepers, pausers, oracle components, and the Treasury Management Committee.",
        "The effect of automated operations on treasury risk and wstETH liquidity."
      ],
      "advisorDiligenceImplications": [
        "Monitor the final on-chain launch and deployed control configuration.",
        "Add NEST's trading, oracle, pause, funding, and asset-recovery roles to Lido governance diligence if executed.",
        "Do not infer any change to client stETH economics before the system is deployed and funded."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-52332d4ad09bfb88588fe7b4",
      "stableKey": "lido:circuitbreaker-gateseal-transition:2026-05-11",
      "version": 1,
      "eventDate": "2026-05-11",
      "publishedAt": "2026-08-22T14:06:01.557Z",
      "title": "Lido proposes replacing GateSeals with a permanent CircuitBreaker",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Transition from GateSeals to CircuitBreaker",
          "authority": "Lido Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x46d8df504c019be2be84a38c8705cd8bdbe4f5f4d2b141d4e8bd3e69af9ef5f3",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-05-11"
        }
      ],
      "whatHappened": "Lido opened a Snapshot proposal to replace temporary, expiring, single-use GateSeals with CircuitBreaker, a permanent contract assigning selective emergency pause authority to designated multisig committees.",
      "whatChanged": "If executed, pausers could maintain authority through periodic heartbeat transactions, pause assigned contracts independently, and retain authority over other assigned contracts after using one pause. The DAO would control pauser assignment and restoration.",
      "whatDidNotChange": "The Snapshot record did not establish deployment, audit completion, on-chain execution, pauser assignments, heartbeat parameters, or any active pause of staking or withdrawals.",
      "confirmedFacts": [
        "CircuitBreaker is proposed as a permanent emergency-pause contract.",
        "Each pausable contract would have one assigned pauser, while a committee could cover multiple contracts.",
        "A pause would revoke the committee's authority over the paused contract but not its other assignments.",
        "Expired heartbeat authorization could only be restored through DAO reassignment.",
        "The DAO could revoke CircuitBreaker permissions through on-chain governance."
      ],
      "unresolved": [
        "The Snapshot result and subsequent on-chain execution.",
        "Final audits, deployed address, heartbeat interval, pause duration, and covered-contract list.",
        "The committee identities, multisig thresholds, and operational procedures for each pauser.",
        "Whether the withdrawal queue or other client-critical contracts were assigned to CircuitBreaker and when GateSeals were retired."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido memo's emergency-pause control map before any CircuitBreaker execution.",
        "Verify final pausers, multisig thresholds, heartbeat settings, pause durations, and contract assignments on-chain.",
        "Treat the proposal as a material control redesign, not evidence that current GateSeal protections already changed."
      ],
      "followUpOn": null,
      "previousInterpretation": "The current Lido memo describes GateSeals as single-use, expiring emergency pause authorities, including for the withdrawal queue.",
      "supersedesId": null
    },
    {
      "id": "event-event-draft-786b08b4f81a6fb150802b8b",
      "stableKey": "lido:lol-easy-track-limit-increase:2026-05-11",
      "version": 1,
      "eventDate": "2026-05-11",
      "publishedAt": "2026-08-22T14:06:01.557Z",
      "title": "Lido proposes higher Easy Track transfer authority for its liquidity committee",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Increase Easy Track transfer limits for Liquidity Observation Lab to align with EGG",
          "authority": "Lido Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x863859d857c7429a0dcb85a4b324de803e2f66ddd8f50e4c2f04a31c35c6ae6f",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-05-11"
        }
      ],
      "whatHappened": "The Lido Ecosystem Foundation proposed increasing the Liquidity Observation Lab multisig's Easy Track stETH transfer limit and creating a dedicated stablecoin transfer factory.",
      "whatChanged": "If implemented through the stated later Aragon vote, the multisig's stETH transfer ceiling would rise from 6,000 to 8,000 stETH per six months and it would gain a stablecoin payment path capped at $8 million per six months.",
      "whatDidNotChange": "The proposal said it added no budget beyond previously approved funding, and it did not itself deploy the new factories, publish their addresses, execute an Aragon vote, or alter stETH holder balances and withdrawal mechanics.",
      "confirmedFacts": [
        "The existing stETH Easy Track factory limit was described as 6,000 stETH per six months.",
        "The proposed stETH limit is 8,000 stETH per six months.",
        "The proposed stablecoin payment-factory limit is $8 million per six months.",
        "The proposal identified the Liquidity Observation Lab multisig address.",
        "On-chain implementation was to follow through a later Aragon vote."
      ],
      "unresolved": [
        "The Snapshot result and later Aragon execution.",
        "The deployed addresses, allowed recipients, stablecoins, and administrative controls for the new factories.",
        "Actual transfers made under the expanded limits.",
        "Whether the change materially increased treasury counterparty or multisig concentration risk."
      ],
      "advisorDiligenceImplications": [
        "Monitor the final on-chain implementation and verify factory addresses and recipient controls.",
        "Update Lido treasury-control diligence if the higher limits become operative.",
        "Keep this treasury authority separate from client stETH custody and withdrawal mechanics."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-7a5b8b88950efe987d9458fa",
      "stableKey": "lido:pier-two-mavan-operator-continuation:2026-05-11",
      "version": 1,
      "eventDate": "2026-05-11",
      "publishedAt": "2026-08-22T14:06:01.557Z",
      "title": "Lido votes on retaining Pier Two after its acquisition by Bitmine",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Should Pier Two continue in the Curated and SDVT sets following the acquisition by Bitmine Immersion Technologies?",
          "authority": "Lido Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x80959462b3026fc118ee9a3d7f46485b335677a2a5a739b3ede2656b7982f8e8",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-05-11"
        }
      ],
      "whatHappened": "Lido opened a Snapshot vote on allowing MAVAN, formerly Pier Two, to continue as a node operator in the Curated and Simple DVT modules following Pier Two's acquisition by Bitmine Immersion Technologies.",
      "whatChanged": "The acquisition introduced a new parent and control context for an existing node operator, while governance considered whether its participation should continue.",
      "whatDidNotChange": "The governance record relayed claims that the team, infrastructure, monitoring, key management, and operating procedures remained unchanged, but it did not independently verify those claims or establish the final vote result.",
      "confirmedFacts": [
        "Pier Two participated in Lido's Curated and Simple DVT modules.",
        "The governance record states that Bitmine acquired Pier Two and would operate it through MAVAN.",
        "The Curated Module Committee reported no identified concern requiring removal at that stage.",
        "A vote for the proposal would allow continued node operations."
      ],
      "unresolved": [
        "The final Snapshot result and any conditions attached to continued participation.",
        "Independent verification that validator infrastructure, key management, personnel, and operational procedures remained unchanged.",
        "MAVAN's resulting share of Lido validators and any parent-level concentration with other staking operations.",
        "Whether subsequent assessments changed the operator's module allocation or status."
      ],
      "advisorDiligenceImplications": [
        "Monitor the final vote and subsequent operator-allocation records.",
        "Review whether the ownership change alters Lido operator concentration, key-management, or correlated-operations assumptions.",
        "Do not treat committee comfort as independent verification of unchanged controls."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-8e66a5394d918b9ac2bc9ef9",
      "stableKey": "lido:cmv2-node-operator-type-framework:2026-05-11",
      "version": 1,
      "eventDate": "2026-05-11",
      "publishedAt": "2026-08-22T14:06:01.557Z",
      "title": "Lido proposes a delegated node-operator assessment framework for CMv2",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Adopt the Node Operator Type Assessment Framework for CMv2",
          "authority": "Lido Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x2b221847bae789551593115be9a364db4c9a478056d6394b1bef7728790258ee",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-05-11"
        }
      ],
      "whatHappened": "Lido opened a Snapshot proposal to approve six node-operator classifications for Curated Module v2 and delegate ongoing framework maintenance, assessment, and reassessment to the Curated Module Committee.",
      "whatChanged": "If adopted and later applied, the framework would formalize operator classifications and give the committee discretion to define round-specific scoring parameters and thresholds that influence subsequent operator treatment.",
      "whatDidNotChange": "The proposal did not itself set operator fees, incentive coefficients, onboarding results, validator allocations, or core-pool staking and withdrawal mechanics.",
      "confirmedFacts": [
        "The proposal defines Professional, Professional Trusted, Public Good, Extra Effort, Decentralization, and Intra-Operator DVT Cluster types.",
        "The Curated Module Committee would maintain and apply the framework.",
        "Scoring parameters and thresholds would be defined for each assessment round.",
        "Operator onboarding lists and economic parameters would require separate governance actions."
      ],
      "unresolved": [
        "The Snapshot result and whether the framework was formally adopted.",
        "The scoring parameters, thresholds, and reassessment cadence selected by the committee.",
        "The resulting operator classifications and effect on validator concentration, client diversity, and incentives.",
        "Whether any subsequent on-chain implementation altered operator allocation or fee settings."
      ],
      "advisorDiligenceImplications": [
        "Monitor adoption and the first completed CMv2 assessment round.",
        "Review whether delegated scoring discretion changes the Lido memo's operator-selection and concentration assumptions.",
        "Treat future operator incentives and allocations as separate events requiring their own primary evidence."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-11064e17cd3c0a2568ffaf93",
      "stableKey": "lido:earneth:kelp-first-loss-exception:2026-04",
      "version": 1,
      "eventDate": "2026-04-30",
      "publishedAt": "2026-08-22T14:06:01.122Z",
      "title": "Lido proposes Kelp-specific EarnETH first-loss exception",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Authorize Lido EarnETH Loss Coverage Below 1% Threshold For The Kelp Incident",
          "authority": "Snapshot (Lido DAO space)",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x5629f9b201f32dbd5780f7e2e5601eed7504cdb7919b622a7ef039261d3c671a",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-04-30"
        }
      ],
      "whatHappened": "Lido Earn contributors proposed authorizing a one-off use of the existing first-loss mechanism for actual residual Kelp-related losses borne by EarnETH users, even when losses fall below the existing 1% threshold.",
      "whatChanged": "If approved, EarnETH could apply its first-loss backstop below the normally applicable threshold for this incident, but only after accounting for alternative coverage.",
      "whatDidNotChange": "The proposal does not alter the general threshold, add a treasury allocation, subsidize yield, replace foregone APY, or establish that any payment has occurred.",
      "confirmedFacts": [
        "The requested authorization is limited to residual Kelp-related losses borne by EarnETH users.",
        "The proposal describes the exception as one-off and leaves the general threshold unchanged.",
        "The backstop would apply only to the extent alternative loss coverage is insufficient.",
        "The proposal commits contributors to publishing a postmortem if approved."
      ],
      "unresolved": [
        "The Snapshot outcome and any additional implementation authorization.",
        "The actual residual loss after external recovery and curator coverage.",
        "The contributors' attributed estimate of approximately 400–600 ETH.",
        "The timing of normal operations and withdrawals for affected EarnETH users.",
        "Whether and how much of the first-loss backstop is ultimately used."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido memo's EarnETH loss-allocation and withdrawal assumptions before treating the proposed exception as effective coverage.",
        "Monitor the vote, final loss calculation, alternative coverage, postmortem, and any executed payment.",
        "Do not infer that the proposed backstop makes EarnETH or the underlying Kelp exposure safe or fully recovered."
      ],
      "followUpOn": "2026-05-07",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-8036b970fef33d2b4a8ed5db",
      "stableKey": "morpho-blue:steakhouse-svr-metaoracle-migration:2026-04-27",
      "version": 1,
      "eventDate": "2026-04-27",
      "publishedAt": "2026-08-22T14:06:01.122Z",
      "title": "Steakhouse announces SVR MetaOracle migration for Morpho markets",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "morpho-blue",
          "name": "Morpho Blue"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Improving Oracles on Eligible Markets",
          "authority": "Steakhouse Financial on Morpho Governance Forum",
          "url": "https://forum.morpho.org/t/improving-oracles-on-eligible-markets/2250",
          "documentType": "official_curator_control_notice",
          "publishedOn": "2026-04-27"
        }
      ],
      "whatHappened": "Steakhouse announced a planned oracle migration for its Prime BTC- and ETH-related Morpho markets on Ethereum, replacing hardcoded collateral pricing in eligible markets with SVR-based MetaOracle designs and explicit backup feeds.",
      "whatChanged": "The announced target design adds private-auction SVR delivery, standard Chainlink fallback paths, exact-collateral backup pricing where applicable, a 2% deviation trigger, a two-hour challenge timelock, and an eight-hour healing timelock.",
      "whatDidNotChange": "The forum record does not prove that each listed Morpho market had switched to the new oracle on April 27. It does not announce changed LLTVs, collateral assets, or completed adoption on Arbitrum or Base.",
      "confirmedFacts": [
        "Steakhouse published the notice on April 27, 2026.",
        "The notice identifies Ethereum-mainnet Morpho markets involving cbBTC, WBTC, LBTC, WETH, wstETH, and weETH.",
        "For eligible wrapped-Bitcoin markets, the proposed MetaOracle compares an SVR BTC/USD primary path with an exact-collateral Chainlink backup.",
        "The specified MetaOracle parameters are a 2% deviation threshold, a two-hour challenge timelock, and an eight-hour healing timelock.",
        "The notice provides exact Ethereum oracle addresses for the listed market groups and says Arbitrum and Base adoption would follow progressively."
      ],
      "unresolved": [
        "The record does not identify the execution transaction or effective switch date for each market.",
        "The exact client-held or approved vault allocations touching each listed market were not established by this candidate.",
        "The configured SVR auction delay and observed behavior during feed divergence or private-route failure remain unverified.",
        "Adoption on Arbitrum and Base was prospective rather than operative in this event record."
      ],
      "advisorDiligenceImplications": [
        "Review the Morpho Blue memo's oracle and liquidation assumptions for any approved Steakhouse vault allocating to the listed markets.",
        "Reconcile each held vault's market allocations and live oracle address before treating the announced fallback design as operative.",
        "Do not infer that additional fallback layers remove Chainlink, curator, liquidation-auction, or collateral-depeg risk."
      ],
      "followUpOn": "2026-05-04",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-3acca96976fb5ee299747ab5",
      "stableKey": "aave-v3:rseth-kelp-bridge-incident:2026-04-18",
      "version": 1,
      "eventDate": "2026-04-18",
      "publishedAt": "2026-08-22T14:06:01.122Z",
      "title": "Kelp rsETH bridge exploit triggers Aave V3 reserve freezes",
      "category": "security_incident",
      "posture": "confirmed",
      "materiality": "critical",
      "evidenceState": "mixed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Pause AAVE Buybacks",
          "authority": "Snapshot (Aave DAO space)",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0x10a2af0110b1ad6f4afd7a3a052b2a119d102cc22949e80e9bbd5132587107c8",
          "documentType": "official_governance_proposal_and_incident_response_record",
          "publishedOn": "2026-04-27"
        }
      ],
      "whatHappened": "Aave's official governance record states that an exploit affecting Kelp's LayerZero rsETH bridge route introduced unbacked rsETH into Aave V3 markets across multiple chains.",
      "whatChanged": "The Aave Protocol Guardian and Risk Steward froze rsETH and wrsETH reserves and adjusted WETH interest rates across affected deployments. AAVE buybacks stopped on April 19 to preserve balance-sheet flexibility while losses and recovery remained unresolved.",
      "whatDidNotChange": "The record does not establish final loss allocation, recovered backing, realized bad debt, or complete resumption of affected reserves. The buyback ARFC does not itself resolve the incident.",
      "confirmedFacts": [
        "The official record dates the underlying bridge incident to April 18, 2026.",
        "Aave's Guardian and Risk Steward executed freezes on rsETH and wrsETH reserves across affected deployments.",
        "WETH reserve interest rates were adjusted as part of the defensive response.",
        "No AAVE buyback transactions were executed after April 19 according to the proposal.",
        "The proposal says potential loss allocation, recovery, and DAO-level responses remained unsettled."
      ],
      "unresolved": [
        "The amount of unbacked rsETH that entered each Aave deployment.",
        "The affected chains, reserve-level exposure, and client exposure requiring reconciliation.",
        "Whether bad debt materialized and how any loss was allocated.",
        "The extent and timing of rsETH backing recovery.",
        "When reserve freezes and defensive interest-rate settings were lifted.",
        "Whether the proposed buyback policy was approved or later superseded."
      ],
      "advisorDiligenceImplications": [
        "Immediately reconcile approved or client-held Aave positions against rsETH, wrsETH, and affected WETH markets.",
        "Review the Aave memo's collateral, freeze, bad-debt, and emergency-control analysis using chain-specific executed state.",
        "Do not generalize the reserve-specific incident to every Aave V3 market, but do not treat affected reserves as available until recovery and configuration are verified."
      ],
      "followUpOn": "2026-04-29",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-2e6bb763cfdd21fed574044e",
      "stableKey": "optimism-bridge:op-challenger-security-release:v1.9.1:2026-04-15",
      "version": 1,
      "eventDate": "2026-04-15",
      "publishedAt": "2026-08-22T14:06:01.122Z",
      "title": "Optimism publishes required op-challenger security release v1.9.1",
      "category": "upgrade_migration",
      "posture": "confirmed",
      "materiality": "material",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "optimism-bridge",
          "name": "Optimism canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "op-challenger v1.9.1",
          "authority": "OP Labs",
          "url": "https://github.com/ethereum-optimism/optimism/releases/tag/op-challenger/v1.9.1",
          "documentType": "official_github_security_release",
          "publishedOn": "2026-04-15"
        }
      ],
      "whatHappened": "OP Labs published op-challenger v1.9.1 with security and reliability fixes for chains using permissionless fault proofs and designated it a required upgrade for all users.",
      "whatChanged": "A fixed official challenger version became available for a direct dependency of the fault-proof process that secures challenged withdrawals.",
      "whatDidNotChange": "The release does not establish an exploit, fund loss, invalid withdrawal, bridge-contract upgrade, or adoption by every live challenger operator.",
      "confirmedFacts": [
        "op-challenger v1.9.1 was released on April 15, 2026.",
        "The official release calls the update required for all users.",
        "The release fixes routing that could send large non-Keccak preimages to an incompatible Keccak-only on-chain path.",
        "The release also introduces strict uint64 configuration parsing and fixes a shutdown race that could make the challenger hang."
      ],
      "unresolved": [
        "The candidate does not establish when OP Mainnet challenger operators adopted v1.9.1.",
        "It is not established whether any live dispute encountered the affected preimage-routing path before upgrade.",
        "The record does not identify an exploit, failed challenge, or affected withdrawal."
      ],
      "advisorDiligenceImplications": [
        "Review the Optimism canonical-bridge memo's dependence on permissionless challenger availability and software-version monitoring.",
        "Verify that relevant operators and service providers tracked the required release; publication alone does not prove adoption.",
        "Continue normal exposure treatment unless separate primary evidence establishes an impaired challenge or withdrawal path."
      ],
      "followUpOn": "2026-04-22",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-9ee6061c3d4ec201d14287b5",
      "stableKey": "lombard-btc.b:bitcoin-smart-accounts-architecture:2026-04-15",
      "version": 1,
      "eventDate": "2026-04-15",
      "publishedAt": "2026-08-22T14:06:01.122Z",
      "title": "Lombard details Bitcoin Smart Account controls for BTC.b",
      "category": "control_change",
      "posture": "confirmed",
      "materiality": "material",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "asset",
          "id": "lombard-btc.b",
          "name": "Lombard BTC.b"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Bitcoin Smart Accounts: architecture, explained",
          "authority": "Lombard Finance",
          "url": "https://www.lombard.finance/blog/bitcoin-smart-accounts-architecture-explained/",
          "documentType": "official_technical_architecture_notice",
          "publishedOn": "2026-04-15"
        }
      ],
      "whatHappened": "Lombard published a technical architecture guide describing how Bitcoin Smart Accounts retain BTC under depositor control while issuing BTC.b on Ethereum for use as on-chain collateral.",
      "whatChanged": "The primary diligence record now identifies the pre-signed Bitcoin spending paths, Ethereum Smart Account Registry, Token Operator, TEE-based Arbitration Oracles, unilateral exit route, and liquidation-driven reserve rebalancing used by this BTC.b issuance model.",
      "whatDidNotChange": "The guide does not establish that every BTC.b unit uses this architecture, provide all deployed contract addresses or named independent Arbitration Oracle operators, prove public availability, or demonstrate safety under stress.",
      "confirmedFacts": [
        "The architecture pre-signs the allowed PSBT spending paths before BTC is deposited and uses Taproot addresses to constrain future states.",
        "A unilateral path from the vault to an unbond timelock address is designed to permit exit if the Token Operator is unavailable.",
        "Lombard states that a Smart Account Registry deployed on Ethereum records BSA instances, deposited UTXOs, pre-signed PSBTs, and position state.",
        "The Token Operator mints BTC.b on Ethereum after a Bitcoin deposit is finalized.",
        "Arbitration Oracles monitor Bitcoin and Ethereum, run in AWS Nitro Enclaves, and use AWS KMS policy restrictions for signing keys.",
        "The described liquidation process moves one or more vault UTXOs to Lombard reserves after a liquidator acquires and exits BTC.b collateral."
      ],
      "unresolved": [
        "The exact registry and related contract addresses, production code hashes, attestation policy, and independent Arbitration Oracle set were not supplied in the cached article.",
        "It remains unclear which existing BTC.b supply uses Bitcoin Smart Accounts versus Lombard's other custody and issuance routes and how fungibility and reserve reporting distinguish them.",
        "Public eligibility, legal title, custodian terms, fees, dispute-operation history, and observed unilateral-exit timing remain unverified.",
        "No stress evidence establishes the behavior of partial liquidations, Token Operator outages, Arbitration Oracle outages, or conflicting Bitcoin and Ethereum state."
      ],
      "advisorDiligenceImplications": [
        "Review the Lombard BTC.b memo so its custody, control, redemption, reserve, and liquidation analysis distinguishes the Bitcoin Smart Account issuance route from other BTC.b routes.",
        "Require deployed-address, attestation, operator, reserve-accounting, legal-title, and exit evidence before treating Smart Account-issued BTC.b as equivalent to previously reviewed BTC.b.",
        "Do not infer that a 1-of-k arbitration claim, TEE isolation, or pre-signed spending paths eliminate hardware, cloud, Token Operator, oracle-availability, liquidation, or implementation risk."
      ],
      "followUpOn": "2026-04-30",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-e767328c1bba4777ee64f1f7",
      "stableKey": "morpho-blue:steakhouse-v2-direct-market-adapter-migration:2026-04-15",
      "version": 1,
      "eventDate": "2026-04-15",
      "publishedAt": "2026-08-22T14:06:01.122Z",
      "title": "Steakhouse plans direct-market migration for Morpho Vault V2 allocations",
      "category": "upgrade_migration",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "morpho-blue",
          "name": "Morpho Blue"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Steakhouse Vault V2 simplification",
          "authority": "Steakhouse Financial on Morpho Governance Forum",
          "url": "https://forum.morpho.org/t/steakhouse-vault-v2-simplification/2235",
          "documentType": "official_curator_migration_notice",
          "publishedOn": "2026-04-15"
        }
      ],
      "whatHappened": "Steakhouse announced that its Morpho Vault V2 products would progressively stop allocating through intermediate Morpho Vault V1 vaults and instead allocate directly through the Markets V1 Adapter.",
      "whatChanged": "The planned migration removes a nested vault layer from the allocation path and requires numerous curator operations across Steakhouse V2 vaults.",
      "whatDidNotChange": "Steakhouse stated that the underlying market exposures would not change and that users of the V1 vaults themselves would not be affected. The notice does not prove completion for any specific vault.",
      "confirmedFacts": [
        "Steakhouse published the migration notice on April 15, 2026.",
        "Most affected V2 vaults were then allocating to a V1 vault that in turn allocated to Morpho Blue markets.",
        "The announced target was direct allocation from V2 vaults to the Markets V1 Adapter.",
        "Steakhouse characterized the change as operational and structural and said underlying market exposures would remain unchanged.",
        "Implementation was planned progressively over the following weeks."
      ],
      "unresolved": [
        "The exact vault addresses, migration transactions, and completion dates are not supplied in the candidate.",
        "It is not established which client-held or approved Steakhouse vaults were affected.",
        "Post-migration withdrawal queues, adapter permissions, cap settings, and allocation state require address-level reconciliation."
      ],
      "advisorDiligenceImplications": [
        "Monitor approved Steakhouse vault addresses for migration completion and reconcile their contract versions and allocation paths.",
        "Update operational diligence if a held vault removes the V1-vault intermediary; do not infer that simplification reduces underlying market or curator risk.",
        "Verify that approved-market restrictions, caps, withdrawal behavior, and monitoring coverage remain intact after migration."
      ],
      "followUpOn": "2026-05-15",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-19833c8a919f0adece496eec",
      "stableKey": "aave-v3:sonic:ussd-onboarding-temp-check:2026-04",
      "version": 1,
      "eventDate": "2026-04-13",
      "publishedAt": "2026-08-22T14:06:01.122Z",
      "title": "Aave considers onboarding USSD to its Sonic market",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        },
        {
          "type": "asset",
          "id": "wisdomtree",
          "name": "WisdomTree digital funds"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[TEMP CHECK] Onboard USSD to Aave V3 Sonic Instance",
          "authority": "Snapshot (Aave DAO space)",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0x98d5e8024e327a7b72608f1cdeecd318bd2f94c3e863ebe44e498059bcec5aa7",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-04-13"
        }
      ],
      "whatHappened": "An Aave DAO temperature check proposed onboarding USSD as a supply and borrowing reserve on the Aave V3 Sonic instance.",
      "whatChanged": "If governance advances and executes the proposal, Aave Sonic would gain a new stablecoin exposure whose stated reserve and redemption stack includes cross-chain minting, third-party custodians, and tokenized Treasury products including WTGXX.",
      "whatDidNotChange": "No ARFC, AIP, execution, reserve activation, risk parameters, caps, collateral settings, or independently verified reserve state is established by this temperature check.",
      "confirmedFacts": [
        "The proposal identifies USSD's Sonic token address.",
        "The proposal describes USSD as redeemable through CCTP-supported chains and interoperable through LayerZero.",
        "WTGXX is among the tokenized Treasury instruments the proposal says can support USSD.",
        "Risk parameters were deferred to later service-provider review.",
        "The stated process requires further ARFC and AIP stages before enforcement."
      ],
      "unresolved": [
        "The temperature-check vote outcome.",
        "Independent verification of USSD reserves, custodians, redemption rights, and legal structure.",
        "Whether WTGXX or another reserve asset would actually back circulating USSD used on Aave.",
        "Final oracle design, caps, collateral status, liquidation parameters, and bridge assumptions.",
        "Any ARFC, AIP, deployment address, and executed reserve state."
      ],
      "advisorDiligenceImplications": [
        "Monitor the governance sequence without treating USSD as an approved or live Aave reserve.",
        "If the proposal advances, review USSD's reserve attestations, redemption waterfall, bridge dependencies, oracle design, and WTGXX linkage before changing the Aave or WisdomTree memos."
      ],
      "followUpOn": "2026-04-20",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-0a71163446838cd1eff71b59",
      "stableKey": "lido:dvt-apm-incentives:routing-proposal:2026-04",
      "version": 1,
      "eventDate": "2026-04-06",
      "publishedAt": "2026-08-22T14:06:01.122Z",
      "title": "Lido proposes rerouting DVT and APM incentive flows",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Redirect DVT & APM Incentives to Current Meta Treasury and LoL",
          "authority": "Snapshot (Lido DAO space)",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x60cfe3531cd13ab84f5f6aaef7bcaab1747cbea4544dc7d18daaf642e36c9d39",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-04-06"
        }
      ],
      "whatHappened": "Lido proposed redirecting post-node-operator DVT incentives from the Decentralized Validator Vault to the Lido Earn Current Meta Treasury and routing APM incentives to the Liquidity Observation Lab multisig.",
      "whatChanged": "If implemented, the destination and delegated management of these incentive flows would shift to the Lido Earn treasury and Growth Committee-linked liquidity structure.",
      "whatDidNotChange": "No vote outcome, transfer, or executed routing change is confirmed. The proposal does not state that core stETH staking rewards, withdrawals, or validator principal would change.",
      "confirmedFacts": [
        "The identified Lido Earn treasury multisig is 0xcCf2daba8Bb04a232a2fDA0D01010D4EF6C69B85.",
        "The proposed DVT routing concerns the post-node-operator share of Obol and SSV incentives.",
        "The proposed APM routing would make incentives available to the Growth Committee for liquidity-focused strategies.",
        "The proposal describes Lido Earn as absorbing the Decentralized Validator Vault's former coordination role."
      ],
      "unresolved": [
        "The governance result and any executed transfers or routing configuration.",
        "The final accounting treatment for current Decentralized Validator Vault participants.",
        "The Growth Committee's deployment constraints and reporting requirements.",
        "The effect on realized rewards, liquidity support, and Lido Earn risk concentration."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido memo's incentive-flow, multisig, and Lido Earn dependency map if the proposal is approved.",
        "Verify executed destinations, committee mandates, accounting, and user disclosures before treating the new reward flow as operative."
      ],
      "followUpOn": "2026-04-13",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-66d01fa74dca3f6ff6f27aa9",
      "stableKey": "lido:csm:idvtc-operator-type-proposal:2026-04",
      "version": 1,
      "eventDate": "2026-04-06",
      "publishedAt": "2026-08-22T14:06:01.122Z",
      "title": "Lido proposes Identified DVT Cluster operator class for CSM",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Introduce an Identified DVT Cluster type in the Community Staking Module",
          "authority": "Snapshot (Lido DAO space)",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x1d416954538fb9b82aae05daca1be29f7b20d5f9fac61bd2eb9da1f5901a3867",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-04-06"
        }
      ],
      "whatHappened": "Lido proposed adding an Identified DVT Cluster operator type to the Community Staking Module for four-person clusters of verified independent community stakers.",
      "whatChanged": "If implemented with CSM v3, qualifying clusters would receive distinct bond, reward, priority-queue, strike, monitoring, and committee-administered onboarding treatment.",
      "whatDidNotChange": "The operator class is not live, CSM v3 deployment is not confirmed, and current CSM operator parameters remain unchanged by the proposal alone.",
      "confirmedFacts": [
        "Each proposed cluster must contain four eligible Identified Community Stakers.",
        "The proposed bond is 1.5 ETH for the first key and 0.5 ETH for each subsequent key.",
        "The proposed node-operator reward is 3.5% for the first 64 keys and 2% thereafter.",
        "The proposal permits up to 40 lifetime priority-queue keys per cluster.",
        "Clusters would be added to the relevant gate through committee-initiated Easy Track motions."
      ],
      "unresolved": [
        "The Snapshot result and final CSM v3 implementation.",
        "Final deployed contracts, gate permissions, and parameter values.",
        "The approved DVT configurations and monitoring requirements.",
        "How identity, independence, downgrade, slashing, and dispute controls perform in operation.",
        "Whether the expected Q3 2026 launch schedule is met."
      ],
      "advisorDiligenceImplications": [
        "Review Lido's CSM operator, bond, slashing, and delegated-gate controls before the new class becomes operative.",
        "Verify the final deployed parameters and committee permissions rather than relying on proposal values."
      ],
      "followUpOn": "2026-04-13",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-91fde763a72ab26f6f58cc3c",
      "stableKey": "lido:curated-modules:cmc-governance-proposal:2026-04",
      "version": 1,
      "eventDate": "2026-04-06",
      "publishedAt": "2026-08-22T14:06:01.122Z",
      "title": "Lido proposes Curated Module Committee with delegated operating authority",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "From LNOSG to CMC: Evolving Curated Staking Modules Governance",
          "authority": "Snapshot (Lido DAO space)",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x1c929502f12c61a510c71965d7a7f82dcc76b5d812e2f52796f6bacd6f66e32b",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-04-06"
        }
      ],
      "whatHappened": "Lido proposed creating a Curated Module Committee to replace LNOSG and manage routine operations across CMv1, CMv2, and the Simple DVT Module.",
      "whatChanged": "If approved and implemented, a dedicated 5-of-9 multisig committee would receive bounded on-chain permissions for penalties, parameter updates, registry management, and operator administration.",
      "whatDidNotChange": "No committee deployment or permission grant is confirmed. The proposal says high-impact decisions such as node-operator onboarding would remain subject to DAO Snapshot votes, with routine actions subject to Easy Track objections.",
      "confirmedFacts": [
        "The proposed committee has nine named members and a 5-of-9 signing quorum.",
        "The proposal would deprecate LNOSG and transfer its responsibilities to the new committee.",
        "The proposed scope covers CMv1, CMv2, and SDVTM operations.",
        "High-impact node-operator onboarding would remain subject to DAO voting under the proposed model."
      ],
      "unresolved": [
        "The Snapshot outcome and any on-chain execution.",
        "The final multisig address, signer set, permissions, and permission ceilings.",
        "The exact boundary between routine committee actions and high-impact DAO decisions.",
        "The final CMv2 deployment and transition schedule.",
        "Whether emergency, revocation, and monitoring procedures are adequate after delegation."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido memo's node-operator and staking-module control map before the committee becomes operative.",
        "Verify the final multisig, permissions, veto path, reporting duties, and transition from LNOSG after execution."
      ],
      "followUpOn": "2026-04-13",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-ad7f1af464ab72f328631858",
      "stableKey": "lido:dao-ops-multisigs:policy-3-proposal:2026-04",
      "version": 1,
      "eventDate": "2026-04-06",
      "publishedAt": "2026-08-22T14:06:01.122Z",
      "title": "Lido proposes DAO Ops Multisigs Policy 3.0",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Lido DAO Ops Multisigs Policy 3.0",
          "authority": "Snapshot (Lido DAO space)",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0xde04e720b6c44e6d5a356021e464dc4d4b3036c6602c6088806f1f898cb7a56b",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-04-06"
        }
      ],
      "whatHappened": "Lido proposed replacing DAO Ops Multisigs Policy 2.0 with Policy 3.0 and aligning related Lido Foundation bylaws with the new framework.",
      "whatChanged": "If approved, signer rotations would no longer have to preserve a simple majority of original signers, static signers would lose protected status, and the existing seven-day rotation objection period would be removed.",
      "whatDidNotChange": "The proposal does not itself rotate a signer, change a particular Safe threshold, or expand a specific multisig's transaction authority. The DAO would retain the ability to object through Snapshot voting.",
      "confirmedFacts": [
        "The proposal would replace Policy 2.0.",
        "The original-signer-majority requirement would be deprecated.",
        "The static-signer rule would be deprecated.",
        "The seven-day objection period for member rotation would be removed.",
        "Related Foundation bylaws would require at least three multisig members."
      ],
      "unresolved": [
        "The Snapshot outcome and effective policy text.",
        "Which existing multisigs and bylaws are ultimately updated.",
        "The final rotation, disclosure, emergency, and objection procedures.",
        "Whether removal of the safeguards materially increases signer-capture or rapid-rotation risk.",
        "Any subsequent signer rotations performed under Policy 3.0."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido memo's multisig rotation and delegated-control assumptions before Policy 3.0 is treated as operative.",
        "Inventory affected Safes and verify thresholds, owners, rotation procedures, disclosure exceptions, and DAO revocation paths after implementation."
      ],
      "followUpOn": "2026-04-13",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-fa59e28be2db98e8dc22a691",
      "stableKey": "lido:alliance-borg:easy-track-limit-proposal:2026-04",
      "version": 1,
      "eventDate": "2026-04-06",
      "publishedAt": "2026-08-22T14:06:01.122Z",
      "title": "Lido proposes higher Alliance BORG Easy Track transfer limits",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Increase Lido Alliance BORG Operational Easy Track Limits to align with EGG",
          "authority": "Snapshot (Lido DAO space)",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x429bdf30549800d3ed87ffa701802d267f6a1e06d1719c6f0a4cb2ecefde521e",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-04-06"
        }
      ],
      "whatHappened": "The Lido Alliance BORG Foundation proposed increasing the Easy Track security limit governing treasury transfers to its operational multisig.",
      "whatChanged": "If executed, the limit would rise from $250,000 per three-month period to $5 million per six-month period, materially increasing the amount accessible through the delegated Easy Track path.",
      "whatDidNotChange": "The proposal says it adds no budget beyond an already approved annual allocation and does not change the transfer mechanism. No Aragon execution is confirmed.",
      "confirmedFacts": [
        "The existing limit stated in the proposal is $250,000 per three months.",
        "The proposed limit is $5 million per six months.",
        "The affected recipient is the Lido Alliance BORG Foundation operational multisig.",
        "The proposal requires a later Aragon vote for on-chain implementation."
      ],
      "unresolved": [
        "The Snapshot and Aragon vote outcomes.",
        "The final executed Easy Track parameters and effective date.",
        "The operational multisig's owner set and threshold at execution.",
        "Whether objection, revocation, monitoring, and reporting controls remain proportionate to the larger ceiling.",
        "Actual transfers made under any increased limit."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido memo's treasury delegation and Easy Track security limits before the higher ceiling becomes operative.",
        "Verify the executed parameters, multisig controls, objection path, and transaction reporting after implementation."
      ],
      "followUpOn": "2026-04-13",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-381220d11d9b27b0340b2824",
      "stableKey": "aave-v4-ethereum-mainnet-launch-2026-03-30",
      "version": 1,
      "eventDate": "2026-03-30",
      "publishedAt": "2026-08-22T14:06:00.334Z",
      "title": "Aave v4 launched on Ethereum with Hub-and-Spoke liquidity architecture",
      "category": "launch_access",
      "posture": "launched",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v4",
          "name": "Aave v4"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Aave V4 is Live on Ethereum",
          "authority": "Aave Labs",
          "url": "https://aave.com/blog/aave-v4-live-ethereum",
          "documentType": "official launch notice",
          "publishedOn": "2026-03-30"
        }
      ],
      "whatHappened": "Aave v4 became live on Ethereum mainnet with three Liquidity Hubs, multiple Spokes, conservative initial caps, and the Aave Pro interface.",
      "whatChanged": "The launch created a live lending exposure in which Hubs custody shared liquidity while Spokes define collateral, risk-premium, and liquidation rules. Advisor analysis must therefore identify the exact Hub, Spoke, and asset rather than inherit an Aave-wide conclusion.",
      "whatDidNotChange": "Aave v3 remained a separate protocol architecture and no migration of existing v3 positions was established. The launch, audits, conservative caps, and Aave branding did not make v4 approved or suitable for client allocation. This March event does not establish an Avalanche launch.",
      "confirmedFacts": [
        "Aave v4 was live on Ethereum mainnet on March 30, 2026.",
        "The initial deployment contained Core, Prime, and Plus Liquidity Hubs.",
        "Spokes drew from shared Hub liquidity while retaining distinct collateral and risk rules.",
        "Initial supply and borrow caps were intentionally conservative.",
        "Aave Pro provided a live interface for supplying and borrowing through v4."
      ],
      "unresolved": [
        "Production behavior under large liquidations, high utilization, credit-line contraction, and Spoke upgrades was not yet demonstrated.",
        "Exact loss boundaries and withdrawal exposure across every connected Hub and Spoke required separate diligence.",
        "No evidence established that any Ketju mandate approved Aave v4 at launch."
      ],
      "advisorDiligenceImplications": [
        "Create or review a separate aave-v4 memo; do not extend the aave-v3 approval to v4.",
        "Require proposed exposure to identify the exact chain, Hub, supplying Spoke, asset, caps, credit lines, pause authority, and liquidation configuration.",
        "Maintain zero allocation until the maturity and reproducibility requirements in the Aave v4 diligence file are independently satisfied."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-a6337941b02eee952323d59b",
      "stableKey": "aave-v3-sonic-ussd-temp-check-2026-03-25",
      "version": 1,
      "eventDate": "2026-03-25",
      "publishedAt": "2026-08-22T14:06:00.334Z",
      "title": "Aave DAO considered onboarding USSD to the Aave v3 Sonic instance",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[TEMP CHECK] Onboard USSD to Aave V3 Sonic Instance",
          "authority": "Aave DAO via Snapshot",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0x0bd92516f4ee59ccc1016c0660916b331651ea1a43d2474c583abd69e4d611fb",
          "documentType": "official governance proposal",
          "publishedOn": "2026-03-25"
        }
      ],
      "whatHappened": "An official Aave DAO temperature check proposed adding USSD as a supplied and borrowable stablecoin in the Aave v3 Sonic instance.",
      "whatChanged": "The proposal placed USSD and its reserve, minting, redemption, custody, and interoperability dependencies into Aave governance review. It did not yet change live Aave parameters.",
      "whatDidNotChange": "No ARFC, AIP, execution, live reserve, collateral status, caps, LTV, liquidation threshold, or oracle configuration was established by this temperature check.",
      "confirmedFacts": [
        "The proposal targeted the Aave v3 Sonic instance.",
        "It proposed enabling users to supply USSD and use it as a borrowing asset.",
        "The proposal described USSD as relying on tokenized Treasury reserves, institutional custodians, and cross-chain minting infrastructure.",
        "Risk parameters were deferred to later service-provider review and an ARFC."
      ],
      "unresolved": [
        "The temperature-check vote outcome and any subsequent ARFC or AIP were not established by the candidate record.",
        "Final reserve parameters, oracle design, caps, collateral eligibility, and liquidation settings were unspecified.",
        "The reserve, redemption, custody, and interoperability claims had not been independently underwritten for Ketju.",
        "No live execution was confirmed."
      ],
      "advisorDiligenceImplications": [
        "Monitor the proposal through ARFC and on-chain execution before treating USSD as part of any approved Aave v3 market.",
        "If the listing advances, review the Sonic instance and USSD as a distinct exposure with issuer, reserve, custodian, bridge, oracle, and redemption dependencies.",
        "Do not infer approval from the Aave v3 protocol-level verdict."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-efc1f0c82f23e5200d4e0ffd",
      "stableKey": "resolv-usr-signing-infrastructure-compromise-2026-03-22",
      "version": 1,
      "eventDate": "2026-03-22",
      "publishedAt": "2026-08-22T14:06:00.334Z",
      "title": "Resolv signing-infrastructure compromise enabled 80M unbacked USR mint",
      "category": "security_incident",
      "posture": "postmortem",
      "materiality": "critical",
      "evidenceState": "mixed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "resolv-usr",
          "name": "Resolv USR"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Resolv Postmortem: March 22, 2026 Incident",
          "authority": "Resolv",
          "url": "https://resolv.xyz/blog/resolv-postmortem-march-22-2026-incident",
          "documentType": "official postmortem",
          "publishedOn": "2026-04-04"
        }
      ],
      "whatHappened": "Attackers traversed compromised third-party and Resolv infrastructure, obtained authority over the signing key used by Resolv's off-chain minting service, and executed two Counter transactions that created 80 million unbacked USR and extracted approximately $25 million in ETH.",
      "whatChanged": "Resolv halted backend services, paused relevant contracts, revoked and rotated compromised credentials, and neutralized approximately 46 million illicit USR through burns and blacklist functionality. The incident demonstrated that an off-chain signing compromise could become an unconstrained on-chain mint.",
      "whatDidNotChange": "Resolv reported that its collateral pool was not directly compromised. The postmortem did not establish complete recovery, a protocol restart, full compensation for every holder category, or that the rebuilt system was safe or advisor-appropriate.",
      "confirmedFacts": [
        "The official postmortem dates the incident to March 22, 2026.",
        "Two illicit Counter transactions minted 50 million and 30 million USR, respectively.",
        "Resolv attributed approximately $25 million of extracted value to the attack.",
        "Relevant contracts with pause functionality were paused and identified compromised credentials were revoked.",
        "Approximately 46 million of the 80 million illicit USR had been neutralized when the postmortem was published.",
        "Most pre-incident USR holders had received or were in the pipeline for 1:1 compensation."
      ],
      "unresolved": [
        "The external forensic investigation, attacker attribution, and upstream compromise remained open.",
        "The disposition of the remaining illicit USR and recovery of extracted value were incomplete.",
        "Final outcomes for post-incident holders, liquidity providers, RLP holders, and other affected integrations were not established.",
        "Deployment and independent verification of the planned on-chain mint caps, oracle validation, and automated pause controls remained pending.",
        "The timeline and conditions for resuming paused protocol operations were unresolved."
      ],
      "advisorDiligenceImplications": [
        "The Resolv USR diligence file should treat off-chain signing infrastructure and cloud access policy as direct mint-authority dependencies, not merely operational support.",
        "The later Resolv rejection should be checked to ensure it records the unconstrained mint path, pause and blacklist powers, incomplete recovery, and cross-organization credential risk.",
        "Compensation of some holders and planned safeguards do not satisfy reopening criteria or establish advisor suitability."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-a7217a370654cc19b533a53f",
      "stableKey": "aave-v3-wsteth-capo-misconfiguration-2026-03-10",
      "version": 1,
      "eventDate": "2026-03-10",
      "publishedAt": "2026-08-22T14:06:00.334Z",
      "title": "Aave v3 CAPO misconfiguration caused erroneous wstETH liquidations",
      "category": "security_incident",
      "posture": "postmortem",
      "materiality": "critical",
      "evidenceState": "mixed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Post-Mortem: Exchange Rate Misallignment on wstETH Core and Prime Instances",
          "authority": "Chaos Labs via Aave governance",
          "url": "https://governance.aave.com/t/post-mortem-exchange-rate-misallignment-on-wsteth-core-and-prime-instances/24269",
          "documentType": "official postmortem",
          "publishedOn": "2026-03-10"
        }
      ],
      "whatHappened": "A mismatch between CAPO's rate-limited snapshot ratio and its snapshot timestamp artificially reduced the wstETH/stETH exchange rate used by Aave v3 Ethereum Core and Prime, liquidating otherwise healthy E-Mode positions.",
      "whatChanged": "The erroneous update temporarily changed the oracle value used for liquidation and led risk stewards to reduce the affected wstETH borrow caps to 1. The snapshot parameters were then manually realigned and the oracle returned to its prior value.",
      "whatDidNotChange": "The postmortem reports no protocol bad debt and no exploit of Aave v3 core contracts. Restoration of the oracle did not itself complete user compensation, provider accountability, or deployment of all proposed prevention controls.",
      "confirmedFacts": [
        "The incident occurred on March 10, 2026 in Aave v3 Ethereum Core and Prime.",
        "The effective wstETH exchange rate used by the protocol fell approximately 2.85%.",
        "Approximately 10,938 wstETH was liquidated across 34 accounts, representing about $26 million of liquidation volume.",
        "The postmortem reports no bad debt to the protocol.",
        "The affected wstETH borrow caps were reduced to 1 during containment.",
        "Risk Steward intervention realigned the snapshot ratio and timestamp and restored the oracle value."
      ],
      "unresolved": [
        "Final per-user reimbursement and reconciliation were not complete in the postmortem.",
        "The ultimate division of financial responsibility among the DAO and service providers remained unresolved.",
        "Several proposed off-chain validation and on-chain guardrails had not yet been demonstrated as deployed.",
        "The final amount recovered from liquidation-linked activity remained open."
      ],
      "advisorDiligenceImplications": [
        "Review any approved Aave v3 strategy using wstETH E-Mode for exposure to CAPO configuration and delegated Risk Steward operations.",
        "The Aave v3 memo should record oracle-operator configuration as a material operational dependency even when core contracts are not exploited and no bad debt results.",
        "Do not treat restored pricing or a reimbursement proposal as evidence that recurrence controls are complete."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-4717bb1d9392b15e9601dbe7",
      "stableKey": "morpho-sky-vaults-launch-2026-03-03",
      "version": 1,
      "eventDate": "2026-03-03",
      "publishedAt": "2026-08-22T14:06:00.334Z",
      "title": "sky.money launches USDT Savings and USDS Flagship vaults on Morpho",
      "category": "launch_access",
      "posture": "launched",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "morpho-blue",
          "name": "Morpho Blue"
        },
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Announcing the sky.money USDT Savings Vault & USDS Flagship Vault",
          "authority": "sky.money on the Morpho Governance Forum",
          "url": "https://forum.morpho.org/t/announcing-the-sky-money-usdt-savings-vault-usds-flagship-vault/2199",
          "documentType": "official governance-forum launch notice",
          "publishedOn": "2026-03-03"
        }
      ],
      "whatHappened": "sky.money announced the launch of two Morpho vaults: a USDT Savings Vault supplying an existing sUSDS/USDT market and a USDS Flagship Vault combining Sky Savings Rate exposure with allocations to selected Morpho lending markets.",
      "whatChanged": "The launch created new advisor-accessible wrappers joining Sky savings exposure to Morpho curator and allocator risk. The USDT vault routes deposits to a 96.5% LLTV sUSDS/USDT market. The USDS vault states that 80% of deposits earn the Sky Savings Rate through launch rewards while up to 20% is actively allocated across specified Morpho markets, with a 5% limit per market.",
      "whatDidNotChange": "The record does not show a change to the immutable Morpho Blue base contract or to direct USDS/sUSDS redemption mechanics. The USDT vault uses an existing market, and neither launch expands Ketju's existing approved scope or establishes that the new vaults are appropriate or safe.",
      "confirmedFacts": [
        "The official forum record is dated March 3, 2026 and expressly announces the two vault launches.",
        "The USDT Savings Vault accepts USDT and supplies the existing sUSDS/USDT Morpho market at a stated 96.5% LLTV.",
        "The USDS Flagship Vault accepts USDS and uses an allocator bot subject to a stated 20% aggregate market-exposure cap and 5% cap per market.",
        "The listed USDS markets use stUSDS, wstETH, WETH, or cbBTC collateral at stated 86% LLTVs.",
        "The launch included time-limited Merkl incentives denominated in USDT or USDS."
      ],
      "unresolved": [
        "The record does not provide the vault contract addresses, deployed MetaMorpho version, or the on-chain owner, curator, allocator, guardian, and timelock configuration.",
        "Actual allocations, utilization, TVL, exit liquidity, and withdrawal performance at launch are not independently established.",
        "The post does not establish how the allocation set or fees could change after launch incentives end."
      ],
      "advisorDiligenceImplications": [
        "Do not treat the USDS Flagship Vault as equivalent to holding direct sUSDS; it adds Morpho curator, allocator, collateral, oracle, liquidation, incentive, and withdrawal-liquidity risks.",
        "The existing Morpho memo approves only the Steakhouse-curated USDC vault, so these sky.money vaults require separate underwriting before inclusion.",
        "Review both memo files for overlapping Sky and Morpho exposure so the same USDS economic risk is not double-counted."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-7a2c556ba71ad8384f795085",
      "stableKey": "aave-v3-x-layer-arfc-2026-03-02",
      "version": 1,
      "eventDate": "2026-03-02",
      "publishedAt": "2026-08-22T14:06:00.334Z",
      "title": "Aave DAO considered an Aave v3 deployment on X Layer",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Deploy Aave v3 on X Layer",
          "authority": "Aave DAO via Snapshot",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0x251c520f1f1da8287168420fa2d2a73a2eb5342c3c62508553123129dec059b0",
          "documentType": "official governance proposal",
          "publishedOn": "2026-03-02"
        }
      ],
      "whatHappened": "An official Aave DAO ARFC proposed deploying a new Aave v3 instance on X Layer and supplied an indicative initial asset set and risk configuration.",
      "whatChanged": "The proposal placed a chain-specific Aave deployment, its collateral set, cross-chain dependencies, oracles, caps, and liquidation parameters into formal governance review.",
      "whatDidNotChange": "The ARFC did not itself deploy or activate contracts. Its stated parameters were indicative, so it did not establish final live assets, caps, LTVs, oracle routes, governance messaging, or advisor approval for the new instance.",
      "confirmedFacts": [
        "The proposal targeted an Aave v3 instance on X Layer.",
        "The indicative asset set included USDT0, USDG, GHO, xBTC, wOKB, xETH, xSOL, xBETH, and xOKSOL.",
        "The proposal included indicative collateral, cap, interest-rate, and E-Mode parameters.",
        "The proposal stated that parameters required further risk-provider feedback."
      ],
      "unresolved": [
        "The vote outcome and any subsequent AIP or execution were not established by this candidate.",
        "Final parameters and the deployed contract-address registry were not confirmed.",
        "The security and operational properties of X Layer, cross-chain governance, bridges, and oracle dependencies required separate diligence.",
        "No evidence established that the X Layer instance inherited Ketju's approval for other Aave v3 markets."
      ],
      "advisorDiligenceImplications": [
        "Track the proposal through on-chain execution and require a chain-specific memo before considering exposure.",
        "Do not treat the protocol-level Aave v3 verdict as blanket approval of a new network instance or its assets.",
        "If activated, review each listed asset's bridge depth, oracle, caps, LTV, liquidation liquidity, and exit path."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-878ac37d9f4c3c07a46acf23",
      "stableKey": "lido-stakin-the-tie-operator-continuation-2026-03-02",
      "version": 1,
      "eventDate": "2026-03-02",
      "publishedAt": "2026-08-22T14:06:00.334Z",
      "title": "Lido considered Stakin's continuation after acquisition by The Tie",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Should Stakin continue in the Curated and DVT sets following its acquisition by The Tie?",
          "authority": "Lido DAO via Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x60d9126fed2a492a22ef53942a16a7a8a7ec3a576ffc2b2367ebcec8eb6baa30",
          "documentType": "official governance proposal",
          "publishedOn": "2026-03-02"
        }
      ],
      "whatHappened": "Lido governance considered allowing node operator Stakin to remain in the Ethereum Curated and Simple DVT sets following its acquisition by The Tie, while updating its on-chain registry name and reward address.",
      "whatChanged": "The acquisition introduced new ownership and reward-routing context for a node operator in Lido's curated infrastructure. The proposal created a pending governance decision about continued participation and a later on-chain registry update.",
      "whatDidNotChange": "The proposal states that infrastructure, validator operations, geographic deployment, custody, key management, and validator assignments were not expected to change. The Snapshot record does not prove that the registry or reward-address update was executed.",
      "confirmedFacts": [
        "Stakin participated in Lido's Curated and Simple DVT modules.",
        "Stakin had been acquired by The Tie.",
        "The proposal sought approval for continued node operations under the Stakin by The Tie name.",
        "The proposal contemplated a later on-chain update to the operator name and reward address.",
        "The proposal reported no planned changes to infrastructure, custody, key management, or validator operations."
      ],
      "unresolved": [
        "The Snapshot outcome and any later on-chain registry execution were not established by the candidate record.",
        "The new reward address and executed transaction were not identified in the record.",
        "Independent confirmation that operational personnel, key controls, geography, and infrastructure remained unchanged was not provided.",
        "Any resulting change in operator concentration required separate measurement."
      ],
      "advisorDiligenceImplications": [
        "Update Lido operator diligence to record the ownership change and pending reward-address update.",
        "Verify the executed registry transaction and current reward address before treating the control change as complete.",
        "Continue monitoring operator concentration, key management, and module allocation; the acquisition alone does not fire a documented Lido kill criterion."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-8148c9cf0ce03d958933950f",
      "stableKey": "aave-v3:v3.7-candidate-preapproval:2026-02",
      "version": 1,
      "eventDate": "2026-02-28",
      "publishedAt": "2026-08-22T14:05:59.950Z",
      "title": "Aave approves v3.7 candidate scope ahead of final activation vote",
      "category": "upgrade_migration",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Aave v3.7 candidate",
          "authority": "Aave DAO Snapshot",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0x2cdd27eda22b36ddde2303c3d69859f74b330eb93661e632700d18c6095335a8",
          "documentType": "official_governance_record",
          "publishedOn": "2026-02-24"
        }
      ],
      "whatHappened": "Aave tokenholders approved the proposed v3.7 candidate scope, authorizing security procedures before a separate final on-chain AIP activation vote.",
      "whatChanged": "The approved candidate scope advanced changes to eMode isolation, removal of legacy isolation and siloed-borrowing configurations, removal of L2 sequencer-uptime gating, append-only reserve lists, and liquidation-calculation precision into security review and final-governance preparation.",
      "whatDidNotChange": "The Snapshot did not activate v3.7, upgrade any deployment, alter live reserve parameters, or immediately remove existing borrowing and liquidation protections. A final on-chain AIP remained required.",
      "confirmedFacts": [
        "The Snapshot closed on 2026-02-28 with approximately 584,549.94 voting power for and negligible voting power against or abstaining.",
        "The candidate adds an isolated eMode flag under which assets outside the category's collateral bitmap contribute no borrowing LTV.",
        "The candidate removes legacy Isolation Mode and Siloed Borrowing configuration features.",
        "The candidate removes L2 sequencer-uptime checks that can block borrowing and liquidation during an outage or grace period.",
        "The candidate removes the reserve-dropping flow, making reserve lists append-only, and proposes precision improvements to liquidation calculations.",
        "The approved scope could be reduced at the final AIP stage but not expanded except for production bug fixes."
      ],
      "unresolved": [
        "The final audited code, security-review findings, and executable AIP payload.",
        "Which Aave v3 deployments would receive the upgrade and on what schedule.",
        "Whether the final AIP would retain every approved candidate feature.",
        "The detailed liquidation-calculation changes, which the proposal said would be disclosed after internal development and security evaluation.",
        "The operational effect of removing sequencer-uptime gating during future L2 outages and recoveries."
      ],
      "advisorDiligenceImplications": [
        "Review the Aave v3 memo's assumptions about L2 outage protections, liquidation availability, eMode borrowing capacity, and governance-controlled collateral isolation.",
        "Track the final AIP and deployment-specific execution before treating any v3.7 mechanic as operative.",
        "Require deployment-level verification because approval of an upgrade candidate does not establish execution, improved safety, or advisor suitability."
      ],
      "followUpOn": "2026-03-31",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-3cb2e6edd1c8db3868bf3a84",
      "stableKey": "rocket-pool:saturn-1-mainnet-upgrade:2026-02-18",
      "version": 1,
      "eventDate": "2026-02-18",
      "publishedAt": "2026-08-22T14:05:59.950Z",
      "title": "Rocket Pool executes the Saturn 1 mainnet upgrade",
      "category": "upgrade_migration",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "rocket-pool",
          "name": "Rocket Pool"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Rocket Pool v1.4.0 — Saturn",
          "authority": "Rocket Pool",
          "url": "https://github.com/rocket-pool/rocketpool/releases/tag/v1.4",
          "documentType": "official_code_release",
          "publishedOn": "2026-02-11"
        },
        {
          "title": "Rocket Pool protocol timeline",
          "authority": "Rocket Pool",
          "url": "https://rocketpool.net/protocol/about",
          "documentType": "official_protocol_timeline",
          "publishedOn": "2026-02-18"
        },
        {
          "title": "The Saturn 1 Upgrade — What's New",
          "authority": "Rocket Pool",
          "url": "https://docs.rocketpool.net/upgrades/saturn-1/whats-new",
          "documentType": "official_protocol_documentation",
          "publishedOn": "2026-02-18"
        }
      ],
      "whatHappened": "Rocket Pool launched Saturn 1 on Ethereum mainnet, replacing the new-validator minipool path with megapools and changing node-operator bonds, reward routing, protocol economics, and future upgrade mechanics.",
      "whatChanged": "New megapool validators could use 4 ETH bonds; legacy minipool deposits were disabled; multiple validators could share a megapool withdrawal contract; revenue splits became adjustable; and forced delegate upgrades expanded the protocol's ability to migrate megapool logic.",
      "whatDidNotChange": "The launch did not establish that every legacy operator migrated, that rETH exit liquidity improved under stress, or that the upgrade made rETH safer or newly approved.",
      "confirmedFacts": [
        "Rocket Pool's official timeline dates the Saturn 1 mainnet launch to 2026-02-18.",
        "The official v1.4 release was published on 2026-02-11 with a mainnet genesis-time correction.",
        "Official documentation says megapools consolidate multiple validators under one node-operator contract and reduce the required bond per validator to 4 ETH.",
        "Official documentation says legacy minipool deposits are disabled and megapool delegate logic can be forcibly upgraded."
      ],
      "unresolved": [
        "The supplied evidence does not independently reconcile every deployed implementation address and execution transaction.",
        "Operator migration, megapool concentration, deposit-pool capacity, rETH secondary liquidity, and stressed exit performance required post-launch observation.",
        "The practical limits and governance process for adjustable revenue splits and forced delegate upgrades required memo-level control review."
      ],
      "advisorDiligenceImplications": [
        "Review the Rocket Pool memo's node economics, delegate-upgrade authority, validator structure, and exit assumptions against the operative Saturn 1 design.",
        "Update the control graph for megapool contracts, adjustable revenue allocation, and forced delegate upgrades.",
        "Continue monitoring rETH discount, deposit-pool capacity, operator count, and megapool concentration; launch alone does not resolve liquidity or governance risk."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-86f2d0719c7a468b4d6cafeb",
      "stableKey": "lombard-btc.b:bitcoin-smart-accounts-pilot:2026-02-11",
      "version": 1,
      "eventDate": "2026-02-11",
      "publishedAt": "2026-08-22T14:05:59.950Z",
      "title": "Lombard launches Bitcoin Smart Accounts in a private-client pilot",
      "category": "launch_access",
      "posture": "launched",
      "materiality": "material",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "asset",
          "id": "lombard-btc.b",
          "name": "Lombard BTC.b"
        },
        {
          "type": "protocol",
          "id": "morpho-blue",
          "name": "Morpho Blue"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Lombard Introduces Bitcoin Smart Accounts",
          "authority": "Lombard Finance",
          "url": "https://www.lombard.finance/blog/lombard-introduces-bitcoin-smart-accounts/",
          "documentType": "official_product_launch_notice",
          "publishedOn": "2026-02-11"
        }
      ],
      "whatHappened": "Lombard announced that Bitcoin Smart Accounts were live in pilot with select custodian clients. The product recognizes BTC retained in an existing custody account as collateral, issues BTC.b, and uses Morpho as lending infrastructure.",
      "whatChanged": "A new pilot issuance and collateral route connected custodied or self-custodied BTC to on-chain lending without the standard asset-transfer flow described in the existing BTC.b diligence record.",
      "whatDidNotChange": "The product was not publicly available, and the notice did not provide deployed contract addresses, named launch custodians, exact Morpho market addresses, complete legal terms, or evidence that Ketju's existing BTC.b or Morpho approvals extend to this route.",
      "confirmedFacts": [
        "Lombard dated the announcement 2026-02-11 and described the product as live in pilot with select clients.",
        "The designated custody account recognizes locked BTC and issues a receipt token identified as BTC.b.",
        "Lombard identified Morpho as the launch lending infrastructure.",
        "The described architecture uses partially signed Bitcoin transactions and timelocks to create emulated covenants."
      ],
      "unresolved": [
        "The exact custodians, eligible clients, contracts, Morpho markets, oracle configuration, loan-to-value terms, liquidation path, fees, and legal documentation were not disclosed.",
        "It was not established how Smart Account-issued BTC.b integrates with existing BTC.b reserve attestations, redemption mechanics, fungibility, and Security Consortium controls.",
        "Public availability was expected in Q1 2026 but was not established by this event record."
      ],
      "advisorDiligenceImplications": [
        "Review the Lombard BTC.b memo before treating Smart Account-issued BTC.b as equivalent to the previously reviewed mint and custody route.",
        "Require reserve, lock-enforcement, redemption, liquidation, oracle, legal-title, and custodian evidence for this issuance path.",
        "The Morpho approval is limited to reviewed Steakhouse-curated USDC exposure and must not be extended to an unidentified Bitcoin Smart Account market."
      ],
      "followUpOn": "2026-03-31",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-c85ddd439b2b68b9a7195673",
      "stableKey": "aave-v3:megaeth-deployment-arfc:2026-01",
      "version": 2,
      "eventDate": "2026-02-09",
      "publishedAt": "2026-08-22T14:05:59.950Z",
      "title": "BTC.b and Aave launch on MegaETH mainnet",
      "category": "launch_access",
      "posture": "launched",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        },
        {
          "type": "asset",
          "id": "lombard-btc.b",
          "name": "Lombard BTC.b"
        }
      ],
      "primaryDocuments": [
        {
          "title": "BTC.b Is Live on MegaETH",
          "authority": "Lombard Finance",
          "url": "https://www.lombard.finance/blog/hardest-money-meets-fastest-chain-btc-b-is-live-on-mega-eth/",
          "documentType": "official_launch_notice",
          "publishedOn": "2026-02-09"
        }
      ],
      "whatHappened": "Lombard reported that MegaETH mainnet launched with BTC.b as its canonical Bitcoin asset and that Aave was one of four live protocols supporting BTC.b at launch.",
      "whatChanged": "The previously proposed Aave MegaETH deployment and BTC.b listing were represented by a first-party issuer as live, expanding both watched objects to a new chain and operational dependency perimeter.",
      "whatDidNotChange": "The launch did not make MegaETH, its Aave market, or BTC.b exposure on that chain approved for Ketju clients. The notice did not provide verified contract addresses, an executed Aave payload, or independent liquidity and oracle observations.",
      "confirmedFacts": [
        "Lombard dated the launch notice 2026-02-09.",
        "The notice states that MegaETH mainnet and its BTC.b infrastructure were live.",
        "BTC.b was identified as MegaETH's canonical Bitcoin asset.",
        "Aave, Avon, Kumbaya, and Prism were identified as live BTC.b venues at launch."
      ],
      "unresolved": [
        "The final Aave governance execution, deployed market and asset addresses, oracle configuration, caps, liquidation settings, and administrative controls were not reconciled in this record.",
        "BTC.b minting, bridging, redemption, proof-of-reserve coverage, and stressed liquidity on MegaETH required separate verification.",
        "MegaETH's sequencer, upgrade, data-availability, bridge, and exit controls were outside the supplied evidence."
      ],
      "advisorDiligenceImplications": [
        "Supersede the proposal-stage MegaETH interpretation in the Aave and BTC.b diligence files, while keeping the new chain exposure unapproved pending review.",
        "Require chain-specific verification of Aave contracts, BTC.b contracts, oracles, caps, liquidation liquidity, bridge routes, reserve coverage, and exit mechanics.",
        "Do not infer safety or suitability from the launch announcement or promotional performance claims."
      ],
      "followUpOn": null,
      "previousInterpretation": "Aave's MegaETH deployment and BTC.b inclusion were previously recorded as proposed, with no live market or verified deployment established at the January boundary.",
      "supersedesId": null
    },
    {
      "id": "event-event-draft-da6ea1d6fa9d520525a8accf",
      "stableKey": "coinbase-bridge:base-mainnet-transaction-drops-postmortem:2026-02-03",
      "version": 1,
      "eventDate": "2026-02-03",
      "publishedAt": "2026-08-22T14:05:59.950Z",
      "title": "Base publishes postmortem on severe transaction drops and inclusion delays",
      "category": "market_stress",
      "posture": "postmortem",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "coinbase-bridge",
          "name": "Base canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "High Rate of Transaction Drops and Transaction Inclusion Delays",
          "authority": "Base Status",
          "url": "https://status.base.org/incidents/zfvvgt46j9d8",
          "documentType": "official_status_postmortem",
          "publishedOn": "2026-02-03"
        }
      ],
      "whatHappened": "Base published a postmortem for a January 31 period of severe mainnet transaction drops, inclusion latency, and some block-production delays under high transaction load.",
      "whatChanged": "Base rolled back the transaction-propagation configuration change identified as the immediate cause and committed to mempool-pipeline, alerting, and change-monitoring improvements. The event added a significant realized availability failure to canonical-bridge operational diligence.",
      "whatDidNotChange": "The postmortem did not report a canonical-bridge contract exploit, asset loss, withdrawal-rule change, challenge-period change, or continuing impairment after the rollback.",
      "confirmedFacts": [
        "Base estimates that approximately 20% of submitted transactions landed on-chain during the acute incident window.",
        "Base reports 2.1 million dropped transactions and 512,000 transactions included in blocks.",
        "Approximately 2% of blocks during the reported window took longer than two seconds to build.",
        "Base attributed the incident to an interaction between a transaction-propagation queue-size change, rising base fees, and mempool-client behavior.",
        "The mitigation was to roll back the configuration change, after which Base reported restored network stability."
      ],
      "unresolved": [
        "The postmortem lists 19:17–20:41 UTC as the incident endpoints but calls that interval two hours and 26 minutes; those figures are arithmetically inconsistent.",
        "The record does not identify how many canonical-bridge deposits, proofs, or withdrawal transactions were delayed or dropped.",
        "Completion and effectiveness of the promised mempool-pipeline and monitoring improvements were not established by the postmortem."
      ],
      "advisorDiligenceImplications": [
        "Review the Coinbase Bridge memo's sequencer, mempool, block-builder, RPC, retry, and transaction-inclusion assumptions.",
        "Preserve transaction resubmission, alternate-RPC, nonce-management, and status-monitoring procedures for bridge operations during congestion.",
        "The resolved event does not independently fire a bridge-contract loss criterion, but recurrence should inform operational limits and exit planning."
      ],
      "followUpOn": "2026-03-03",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-5b4713886a15a1731cb52d26",
      "stableKey": "lido:rewards-share-committee-reform:2026-01",
      "version": 1,
      "eventDate": "2026-01-26",
      "publishedAt": "2026-08-22T14:05:59.620Z",
      "title": "Lido approves Rewards Share Committee reform",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Rewards Share Committee Reform",
          "authority": "Lido DAO",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0xb4a35720b03f4c888c2fb41ab66ed324262d7a5b4696ffc3ee20bb35ebb0df6f",
          "documentType": "Official Snapshot governance proposal and vote",
          "publishedOn": "2026-01-19"
        }
      ],
      "whatHappened": "Lido DAO approved reforming and relaunching the Rewards Share Committee as a DAO-authorized operational committee with added duties for node-operator rebates and stVault rewards disbursement.",
      "whatChanged": "The approved mandate expands the committee's operational role in allocating approved rebates and executing treasury-funded stVault reward payments within DAO-approved budgets.",
      "whatDidNotChange": "The vote did not itself change stETH withdrawals, the core staking fee, validator balances, or demonstrate that any particular payment had been executed.",
      "confirmedFacts": [
        "The official vote closed on 2026-01-26.",
        "Approximately 54.58 million voting units supported the proposal, with approximately 1.32 against.",
        "The approved mandate covers manual node-operator rebates and operational execution of stVault reward disbursements within approved budgets."
      ],
      "unresolved": [
        "The candidate record does not establish when the reformed committee began operating.",
        "Specific future payout instructions and their on-chain execution remain separate actions."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido memo's operational-control map to reflect the committee's approved treasury-disbursement and rebate duties.",
        "Continue to distinguish committee execution authority from DAO approval of budgets and from the separate stVault Committee's payout instructions."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-dfc52c7f7ef0c8c02868f702",
      "stableKey": "lido:dvt-dvv-incentive-allocation:2026-01",
      "version": 1,
      "eventDate": "2026-01-26",
      "publishedAt": "2026-08-22T14:05:59.620Z",
      "title": "Lido approves variable DVT and DVV incentive allocations",
      "category": "economic_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "DVT & DVV Incentive Allocation Changes",
          "authority": "Lido DAO",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x8b8619f09213b868708b25cb2512023234e5e160cba5c291f4e9d944d2ccd3fa",
          "documentType": "Official Snapshot governance proposal and vote",
          "publishedOn": "2026-01-19"
        }
      ],
      "whatHappened": "Lido DAO approved replacing the fixed allocation of certain DVT incentives with a variable monthly split between eligible node operators and Mellow Distributed Validator Vault stakers.",
      "whatChanged": "For covered Curated Module and Community Staking Module operators, the node-operator share can rise to 50% when modeled DVT costs are high, while the staker share can rise to 85% as costs fall or incentives increase.",
      "whatDidNotChange": "The proposal expressly leaves the Simple DVT Module unchanged. It does not change Lido's core staking fee, withdrawal mechanism, or prove any particular monthly allocation was executed.",
      "confirmedFacts": [
        "The official vote closed on 2026-01-26.",
        "Approximately 54.54 million voting units supported the proposal, with approximately 205.11 against.",
        "The approved model applies to covered CM and CSM operators using SSV or Obol and is calculated monthly.",
        "The proposal states that the Simple DVT Module is unchanged."
      ],
      "unresolved": [
        "The first calculated allocation and payment execution are not established by the candidate record.",
        "The realized effect on operator behavior, validator performance, and staker returns remained unknown at approval."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido memo's node-operator incentive analysis and return attribution for covered DVT modules.",
        "Do not generalize the approved allocation to the Simple DVT Module or to the core stETH fee."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-2d02ddaade731022a5edf38a",
      "stableKey": "rocket-pool:rpip-77-latest-minipool-delegate:2026-01",
      "version": 1,
      "eventDate": "2026-01-23",
      "publishedAt": "2026-08-22T14:05:59.620Z",
      "title": "Rocket Pool proposes defaulting Smart Node minipools to the latest delegate",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "rocket-pool",
          "name": "Rocket Pool"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Use Latest Delegate for Minipools (RPIP-77)",
          "authority": "Rocket Pool",
          "url": "https://snapshot.org/#/rocketpool-dao.eth/proposal/0x0f82693c42d491f8a74fe0584a1d503e30ab8c27a3800bc0c257d0f35340bcc5",
          "documentType": "Official Snapshot governance proposal",
          "publishedOn": "2026-01-23"
        }
      ],
      "whatHappened": "Rocket Pool opened the RPIP-77 vote to make Smart Node-managed minipools use the latest delegate and remove supported configuration for older delegate implementations.",
      "whatChanged": "The proposal would increase governance's practical ability to propagate approved minipool logic through the supported Smart Node path and reduce delegate-version fragmentation.",
      "whatDidNotChange": "At the January window boundary, the vote was still open and no Smart Node update was confirmed released or adopted. Non-Smart Node users would not be forced to change delegates.",
      "confirmedFacts": [
        "The official vote opened on 2026-01-23.",
        "The proposal states that only 7% of operators had proactively selected the latest delegate.",
        "A positive result would lead to a Smart Node update changing defaults and removing supported older-delegate options."
      ],
      "unresolved": [
        "The vote did not close until 2026-02-06, outside the backfill window.",
        "Implementation timing, release contents, adoption, and any later enforcement mechanism were not established within January."
      ],
      "advisorDiligenceImplications": [
        "Monitor the vote and resulting Smart Node release because delegate propagation changes the practical control model for legacy minipools.",
        "Do not infer that governance-approved logic became universal or that non-Smart Node operators lost their ability to retain older delegates."
      ],
      "followUpOn": "2026-02-06",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-395db654497003c963409a2e",
      "stableKey": "aave-v3:mantle-deployment-arfc:2026-01",
      "version": 1,
      "eventDate": "2026-01-23",
      "publishedAt": "2026-08-22T14:05:59.620Z",
      "title": "Aave approves Mantle deployment ARFC",
      "category": "governance",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Deploy Aave v3 on Mantle",
          "authority": "Aave DAO",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0x2f9378770f1838f0ea8d483239af1530c9fbea98d648e0b11e4647dcb722d119",
          "documentType": "Official Snapshot governance proposal and vote",
          "publishedOn": "2026-01-19"
        }
      ],
      "whatHappened": "Aave DAO approved the ARFC for a prospective Aave V3 deployment on Mantle with an initial asset set and proposed risk, GHO, GSM, and budget parameters.",
      "whatChanged": "The Mantle deployment advanced through an off-chain governance stage, creating a concrete new-market research item for Aave.",
      "whatDidNotChange": "The ARFC approval did not itself deploy contracts, execute a final AIP, establish live liquidity, or extend Ketju's existing Aave approval to Mantle.",
      "confirmedFacts": [
        "The official vote ran from 2026-01-20 through 2026-01-23.",
        "Approximately 654,785.57 voting units supported the proposal, compared with approximately 15.22 against and 2.47 abstaining.",
        "The proposal contains a prospective initial asset and risk-parameter configuration for Mantle."
      ],
      "unresolved": [
        "Final AIP execution, verified deployed addresses, oracle configuration, and launch timing were not established by this record.",
        "Live liquidity, stressed exits, and the final effective parameters remained unconfirmed."
      ],
      "advisorDiligenceImplications": [
        "Monitor any final AIP and deployed-address record, but do not treat Mantle as covered by the existing Aave memo.",
        "Require chain, data-availability, oracle, collateral, liquidity, and exit-path review before considering the Mantle market."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-754e4a83650bd050c0470cc2",
      "stableKey": "axelar:cometbft-csa-2026-001-patch-release:2026-01-23",
      "version": 1,
      "eventDate": "2026-01-23",
      "publishedAt": "2026-08-22T14:05:59.620Z",
      "title": "Axelar publishes CometBFT security-patch release v1.3.8",
      "category": "upgrade_migration",
      "posture": "confirmed",
      "materiality": "material",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Axelar Core v1.3.8",
          "authority": "Axelar",
          "url": "https://github.com/axelarnetwork/axelar-core/releases/tag/v1.3.8",
          "documentType": "Official GitHub release",
          "publishedOn": "2026-01-23"
        }
      ],
      "whatHappened": "Axelar published axelar-core v1.3.8 with an upgraded CometBFT dependency containing the fix for CSA-2026-001.",
      "whatChanged": "A patched official validator build became available, creating a concrete infrastructure-version diligence requirement for the watched Axelar dependency.",
      "whatDidNotChange": "The release says the change is not consensus-breaking and no funds are at risk. It does not prove network-wide validator adoption, an exploit, fund loss, or a gateway-contract change.",
      "confirmedFacts": [
        "Axelar Core v1.3.8 was released on 2026-01-23.",
        "The release upgrades CometBFT with a fix for CSA-2026-001.",
        "Axelar states that the change is not consensus-breaking and that no funds are at risk."
      ],
      "unresolved": [
        "The cached record does not establish validator adoption of v1.3.8 across the live network.",
        "The operative vulnerability details and any exposure before upgrade are not stated in the candidate record."
      ],
      "advisorDiligenceImplications": [
        "Review the Axelar memo's infrastructure-security record and verify that relevant service providers or integrations track the patched validator version.",
        "Do not infer that release publication alone proves the live validator set has upgraded."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-7cd4ca3232d18804945b3f84",
      "stableKey": "coinbase-bridge:base-mainnet-delayed-blocks:2026-01-20",
      "version": 1,
      "eventDate": "2026-01-20",
      "publishedAt": "2026-08-22T14:05:59.620Z",
      "title": "Base recovers from periodically delayed block building",
      "category": "market_stress",
      "posture": "recovered",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "coinbase-bridge",
          "name": "Base canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Periodically delayed block building on Base Mainnet",
          "authority": "Base",
          "url": "https://status.base.org/incidents/c9cjh8jbz8b0",
          "documentType": "Official status incident",
          "publishedOn": "2026-01-20"
        }
      ],
      "whatHappened": "Base reported periodically delayed blocks during volatile activity and marked the incident resolved after degraded block building and transaction inclusion between 14:45 and 15:10 UTC.",
      "whatChanged": "Transaction inclusion on the chain supporting the watched canonical bridge was temporarily less reliable, adding a confirmed operational incident to the bridge diligence record.",
      "whatDidNotChange": "The status record does not report a bridge-contract exploit, fund loss, withdrawal pause, challenge-period change, or continuing impairment after resolution.",
      "confirmedFacts": [
        "Base's official status page marked the incident resolved.",
        "The reported degradation occurred between 14:45 and 15:10 UTC on 2026-01-20.",
        "Users may have experienced delayed transaction inclusion and degraded block-building performance."
      ],
      "unresolved": [
        "The status record does not quantify affected transaction volume or identify whether any canonical-bridge transactions were specifically delayed.",
        "The record attributes the condition to volatile activity but provides no detailed root-cause analysis."
      ],
      "advisorDiligenceImplications": [
        "Add the incident to the Coinbase Bridge operational-reliability record and review recurrence before the next memo decision.",
        "No kill criterion is confirmed by this short resolved delay, but stressed exits should continue to account for sequencer and inclusion risk."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-f4650d1555951e124cb89dca",
      "stableKey": "optimism-bridge:op-node-security-release:v1.16.5:2026-01-13",
      "version": 1,
      "eventDate": "2026-01-13",
      "publishedAt": "2026-08-22T14:05:59.620Z",
      "title": "Optimism publishes essential op-node security release v1.16.5",
      "category": "upgrade_migration",
      "posture": "confirmed",
      "materiality": "material",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "optimism-bridge",
          "name": "Optimism canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "op-node v1.16.5",
          "authority": "OP Labs",
          "url": "https://github.com/ethereum-optimism/optimism/releases/tag/op-node/v1.16.5",
          "documentType": "Official GitHub release",
          "publishedOn": "2026-01-13"
        }
      ],
      "whatHappened": "OP Labs published op-node v1.16.5 and warned that its corresponding op-geth release contains security fixes, making the release essential for all chains.",
      "whatChanged": "A security-relevant official node version became available and was designated essential, creating an infrastructure-version review requirement for OP Mainnet dependencies.",
      "whatDidNotChange": "The release does not identify an exploited vulnerability, fund loss, bridge-contract change, withdrawal change, or confirmed OP Mainnet adoption.",
      "confirmedFacts": [
        "op-node v1.16.5 was released on 2026-01-13.",
        "The release upgrades the corresponding op-geth dependency.",
        "The official notice says the corresponding op-geth release includes security fixes and calls the release essential for all chains."
      ],
      "unresolved": [
        "The security fixes are not described in the cached candidate record.",
        "The record does not establish when OP Mainnet operators adopted the release."
      ],
      "advisorDiligenceImplications": [
        "Review the Optimism bridge memo's infrastructure-security record and verify upgrade tracking by relevant operators and service providers.",
        "Do not treat release publication as proof that the live network had already adopted the patched software."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-21cfb0ef8066c75f7b835a8e",
      "stableKey": "rocket-pool-balancer-alliance-v3-pool-proposal-2025-12-19",
      "version": 1,
      "eventDate": "2025-12-19",
      "publishedAt": "2026-08-22T14:05:59.252Z",
      "title": "Balancer proposes moving Rocket Pool alliance treatment to its v3 liquidity pool",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "rocket-pool",
          "name": "Rocket Pool"
        }
      ],
      "primaryDocuments": [
        {
          "title": "BIP-896: Rocket Pool Balancer Alliance Addendum",
          "authority": "Balancer governance",
          "url": "https://snapshot.org/#/balancer.eth/proposal/0x2aaa6c1df567752f1be41c61a523632871228ed1a8712e3ea0660d3af6ee5cf4",
          "documentType": "Snapshot governance proposal",
          "publishedOn": "2025-12-19"
        }
      ],
      "whatHappened": "Balancer governance received BIP-896, proposing an alliance addendum after Rocket Pool moved its primary Ethereum liquidity from a deprecated Balancer v2 pool to a Balancer v3 pool.",
      "whatChanged": "The proposal would remove the v2 rETH/WETH pool and add the v3 rETH/waEthWETH pool to the special Rocket Pool alliance revenue-sharing treatment.",
      "whatDidNotChange": "The candidate does not establish that the proposal passed or executed, that incentives became active, or that rETH redemption and Rocket Pool protocol controls changed.",
      "confirmedFacts": [
        "The proposal identifies the v2 rETH/WETH pool at 0x1e19cf2d73a72ef1332c882f20534b6519be0276 for removal.",
        "It identifies the v3 rETH/waEthWETH pool at 0x1ea5870f7C037930CE1d5d8d9317c670e89e13E3 for addition.",
        "The proposed incentive token remains RPL.",
        "The proposal states that Rocket Pool had migrated its primary liquidity pool to Balancer v3."
      ],
      "unresolved": [
        "The Snapshot candidate does not establish the final vote result or execution status.",
        "The resulting incentive amount, duration, and realized effect on rETH liquidity are not stated.",
        "The candidate references a prior security-driven v2 deprecation but is insufficient to establish that separate incident's cause or scope."
      ],
      "advisorDiligenceImplications": [
        "Monitor whether alliance treatment becomes operative and whether liquidity migrates successfully to the named v3 pool.",
        "Reassess executable rETH secondary-market depth after migration rather than inferring liquidity from governance approval.",
        "The proposal does not fire Rocket Pool's existing discount, operator-count, redemption, or protocol-revenue kill criteria."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-3bba919c37643b15a703d46a",
      "stableKey": "lido:ethereum:seal-safe-harbor-approval-2025-12",
      "version": 1,
      "eventDate": "2025-12-19",
      "publishedAt": "2026-08-22T14:05:59.252Z",
      "title": "Lido approves SEAL Safe Harbor exploit-response framework",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Adopt The SEAL Safe Harbor Agreement",
          "authority": "Lido DAO governance via Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x0188ab77d59b11ce589d88c350093faffdb07b3a9c9ba4d8af12755d4b2178c0",
          "documentType": "governance_record",
          "publishedOn": "2025-12-11"
        }
      ],
      "whatHappened": "LDO holders approved adopting the SEAL Whitehat Safe Harbor framework for Lido on Ethereum, including recovery, bounty, scope-management, and incident-contact terms.",
      "whatChanged": "Governance approved a civil safe-harbor path for whitehats responding to active exploits, a 10% bounty capped at $2 million, return of recovered assets to the Aragon Voting contract, and temporary 4-of-5 committee authority over the agreement’s scoped-account list pending audits and transfer to DAO control.",
      "whatDidNotChange": "The vote did not itself demonstrate on-chain registration, transfer agreement ownership to Aragon Voting, dissolve the temporary committee, allocate a bounty, or establish that any exploit or recovery had occurred.",
      "confirmedFacts": [
        "The Snapshot vote closed on 2025-12-19 with approximately 56.73 million LDO Approve votes and zero Reject votes.",
        "Approved bounty terms were 10% of recovered assets, subject to a $2 million individual and aggregate cap for an incident.",
        "Whitehats must return recovered assets; any bounty payment requires a separate Lido DAO governance vote.",
        "The designated recovery address was the Aragon Voting contract on Ethereum.",
        "A named 4-of-5 committee was approved to manage scoped accounts temporarily; the proposal states that the committee would not custody funds."
      ],
      "unresolved": [
        "Whether the agreement was subsequently registered in the Safe Harbor Registry.",
        "Whether the Safe Harbor contract audits were completed and agreement ownership transferred to Aragon Voting.",
        "Whether the temporary committee was dissolved and whether its scope changed before dissolution.",
        "Whether every contract listed in the initial protected-asset scope was operative and under the represented ownership at approval time."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido control map to record the new exploit-response framework, recovery destination, bounty economics, and temporary scope-management authority.",
        "Verify the later on-chain registration and ownership state before treating the approved framework as operational.",
        "Do not infer that Safe Harbor adoption prevents exploits, guarantees recovery, or changes the existing stETH withdrawal and loss-allocation mechanics."
      ],
      "followUpOn": "2026-08-27",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-e836aabc6e66c06356741e9e",
      "stableKey": "lido:alliance-borg:goose-3-bylaws-approval-2025-12",
      "version": 1,
      "eventDate": "2025-12-19",
      "publishedAt": "2026-08-22T14:05:59.252Z",
      "title": "Lido approves broader purposes for Lido Alliance BORG",
      "category": "governance",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Lido Alliance BORG – Amendment of Bylaws to Enable GOOSE-3 Execution",
          "authority": "Lido DAO governance via Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x5e087c8d53509dd9b55441f9ee6180da21ee5cf8fe68fab9d852b75b35a44a18",
          "documentType": "governance_record",
          "publishedOn": "2025-12-11"
        }
      ],
      "whatHappened": "LDO holders approved a conditional amendment broadening Lido Alliance BORG’s purposes so it could house and operate products and initiatives contemplated by GOOSE-3.",
      "whatChanged": "Governance authorized the DAO-adjacent entity’s directors, subject to GOOSE-3 approval, to expand the entity beyond administration of the Lido Alliance Program into product and revenue-diversification initiatives.",
      "whatDidNotChange": "The record does not establish that the directors adopted the amendment, that any GOOSE-3 product launched, or that Lido’s staking, withdrawal, oracle, custody, upgrade, or loss-allocation mechanics changed.",
      "confirmedFacts": [
        "The Snapshot vote closed on 2025-12-19 with approximately 56.73 million LDO For and zero Against.",
        "The approved text broadens the entity’s purposes to include initiatives and products intended to expand Lido DAO revenue and its product portfolio.",
        "Implementation remained conditional on GOOSE-3 approval and a later board resolution by Lido Alliance BORG’s directors."
      ],
      "unresolved": [
        "Whether GOOSE-3 received every required approval.",
        "Whether the directors subsequently adopted the amended bylaws.",
        "Which products or activities, if any, were later placed inside Lido Alliance BORG."
      ],
      "advisorDiligenceImplications": [
        "Monitor the expanded DAO-adjacent organizational perimeter when assessing governance, accountability, and dependencies of future Lido-branded products.",
        "Do not treat the approval as evidence that a new product was live, safe, or covered by the existing stETH approval."
      ],
      "followUpOn": "2026-08-27",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-aca50fe940a25a7cdcdcfc44",
      "stableKey": "gearbox-mellow-rsteth-emergency-expiry-2025-12-18",
      "version": 1,
      "eventDate": "2025-12-18",
      "publishedAt": "2026-08-22T14:05:59.252Z",
      "title": "Gearbox proposes emergency rstETH account expiry ahead of an in-place upgrade",
      "category": "governance",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "gearbox",
          "name": "Gearbox"
        },
        {
          "type": "protocol",
          "id": "mellow-core",
          "name": "Mellow Core"
        }
      ],
      "primaryDocuments": [
        {
          "title": "GIP-273: Mellow and P2P rstETH implementation update response",
          "authority": "Gearbox governance",
          "url": "https://snapshot.org/#/gearbox.eth/proposal/0xf1afeed54d0878cd2d8979ad710b437f8d451495245cc1127dc602bb743f6dda",
          "documentType": "Snapshot governance proposal",
          "publishedOn": "2025-12-18"
        }
      ],
      "whatHappened": "Gearbox governance proposed expiring affected Chaos Labs wstETH Credit Managers before Mellow and P2P changed the implementation behind the existing rstETH token address. The proposal described compatibility and risk-profile discontinuities and added liquidation protections.",
      "whatChanged": "If executed, affected Credit Managers would expire on 2025-12-20, liquidation fees and premiums would fall to 0.01%, and specified emergency-liquidator profits would be returned to account owners.",
      "whatDidNotChange": "The candidate does not prove that the vote passed, transactions executed, or the rstETH implementation upgrade occurred. It reports no completed liquidation or protocol loss.",
      "confirmedFacts": [
        "GIP-273 identifies an intended in-place rstETH implementation change rather than migration to a new token address.",
        "Gearbox states that existing oracles and adapters could become incompatible with the new implementation.",
        "The proposal sets an expiration timestamp of 2025-12-20 13:00 UTC for specified Chaos Labs wstETH Credit Managers.",
        "It proposes 0.01% expired liquidation fees and premiums and a return of specified emergency-liquidator profits to account owners."
      ],
      "unresolved": [
        "The Snapshot record does not establish the final vote, timelock, or execution result.",
        "The operative Mellow implementation diff, deployment transaction, audits, and final upgrade time are not included.",
        "The number and value of affected rstETH Credit Accounts are not stated.",
        "No evidence establishes whether any account was liquidated or suffered loss."
      ],
      "advisorDiligenceImplications": [
        "Review both Mellow Core and Gearbox diligence for same-address implementation migration risk.",
        "Treat token-address continuity as insufficient evidence that an asset's technical and economic risk profile is unchanged.",
        "Verify whether affected Gearbox positions were closed or migrated before the expiration timestamp and whether emergency protections executed as proposed."
      ],
      "followUpOn": "2025-12-20",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-0b25776a8dad51ead254479b",
      "stableKey": "axelar-validator-crash-security-patch-2025-12-15",
      "version": 1,
      "eventDate": "2025-12-15",
      "publishedAt": "2026-08-22T14:05:59.252Z",
      "title": "Axelar validators apply a security patch addressing node-crash risk",
      "category": "upgrade_migration",
      "posture": "confirmed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Axelar Core v1.3.5",
          "authority": "Axelar",
          "url": "https://github.com/axelarnetwork/axelar-core/releases/tag/v1.3.5",
          "documentType": "official code release",
          "publishedOn": "2025-12-15"
        }
      ],
      "whatHappened": "Axelar published core release v1.3.5 with an important CometBFT security patch and a staking-rewards fix. The release urged node operators to apply it promptly and stated that a majority of validators had already done so.",
      "whatChanged": "A patched Axelar Core version became available, and Axelar reported majority-validator adoption intended to prevent validator nodes from crashing.",
      "whatDidNotChange": "The release said no funds were at risk and did not report a consensus failure, cross-chain message failure, asset loss, or completed adoption by every validator.",
      "confirmedFacts": [
        "Axelar Core v1.3.5 was released on 2025-12-15.",
        "The official release identifies an important CometBFT security patch and a staking-rewards fix.",
        "Axelar stated that the patch prevents node crashes and that a majority of validators had applied it.",
        "The release stated that no funds were at risk."
      ],
      "unresolved": [
        "The release does not identify the vulnerability or affected CometBFT behavior in enough detail to independently assess exploitability.",
        "The proportion and identity of validators still running unpatched software were not disclosed.",
        "No primary evidence in the candidate establishes whether the vulnerability caused downtime before patching."
      ],
      "advisorDiligenceImplications": [
        "Add the patch and reported adoption to Axelar's operational-resilience history.",
        "Review whether any approved integration depended on Axelar during a period when a material validator share remained unpatched.",
        "Do not interpret majority adoption or the no-funds-at-risk statement as proof that every integration or validator was unaffected."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-4f9730c11a4bcb056964aedb",
      "stableKey": "goldfinch-hack-response-reimbursement-proposal-2025-12-14",
      "version": 1,
      "eventDate": "2025-12-14",
      "publishedAt": "2026-08-22T14:05:59.252Z",
      "title": "Goldfinch proposes a $250,000 reimbursement after a reported test-contract exploit",
      "category": "governance",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "mixed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "goldfinch",
          "name": "Goldfinch"
        }
      ],
      "primaryDocuments": [
        {
          "title": "GIP-85: Goldfinch Hack Response",
          "authority": "Goldfinch governance",
          "url": "https://snapshot.org/#/goldfinch.eth/proposal/0x3581a51f73aa4b2e691c2ac2cdf82520d8421429f23cc8366a923b85df8315b3",
          "documentType": "Snapshot governance proposal",
          "publishedOn": "2025-12-14"
        }
      ],
      "whatHappened": "Goldfinch governance opened GIP-85, stating that attackers exploited a five-year-old test contract on 2025-12-02 and proposing to reimburse $250,000 from the remaining bug-bounty budget.",
      "whatChanged": "The proposal introduced a concrete loss-allocation decision that would cover approximately 75% of the governance record's reported $330,000 USDC loss.",
      "whatDidNotChange": "The candidate does not prove that the vote passed, reimbursement was paid, or the underlying exploit affected Goldfinch's active lending pools or client positions.",
      "confirmedFacts": [
        "Goldfinch governance published GIP-85 on 2025-12-14.",
        "The proposal asks voters to authorize $250,000 from the remaining bug-bounty budget for reimbursement.",
        "The governance record attributes a $330,000 USDC loss to a 2025-12-02 exploit of an old test contract.",
        "The proposal characterizes the reimbursement as approximately 75% of reported damages."
      ],
      "unresolved": [
        "The candidate does not include the exploited contract address, transactions, technical root cause, or independent loss reconciliation.",
        "The final vote result and any reimbursement transaction are not established.",
        "Whether the vulnerable test contract shared code, roles, or dependencies with active Goldfinch contracts is not established.",
        "The identities and eligibility of proposed reimbursement recipients are not stated."
      ],
      "advisorDiligenceImplications": [
        "Add the reported exploit and proposed treasury loss allocation to Goldfinch's incident and governance history.",
        "Require contract-level confirmation before treating the reported amount or scope as fully reconciled.",
        "Review whether the incident changes conclusions about deprecated-contract management, bug-bounty reserves, or recovery governance."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-673b1e8f5d53aa99df5682a1",
      "stableKey": "lido-goose3-ecosystem-grant-budget-2025-12-11",
      "version": 1,
      "eventDate": "2025-12-11",
      "publishedAt": "2026-08-22T14:05:59.252Z",
      "title": "Lido proposes a $60 million 2026 ecosystem grant budget",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Ecosystem Grant gRequest: Executing GOOSE-3",
          "authority": "Lido DAO",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0xf263b730f1c64d637ec27227121d7c5bd2189bf456514bad8225e960cf34d7b0",
          "documentType": "Snapshot governance proposal",
          "publishedOn": "2025-12-11"
        }
      ],
      "whatHappened": "Lido DAO received a 2026 Ecosystem Grant gRequest seeking up to $60 million for protocol maintenance, resilience work, growth initiatives, and execution of the GOOSE-3 strategy through three DAO-adjacent foundations.",
      "whatChanged": "If approved, the proposal would authorize a $43.8 million baseline funding plan and a discretionary growth cap of $16.2 million, with later disbursements requested through Easy Track motions to named operational multisigs.",
      "whatDidNotChange": "The candidate does not establish approval, transfer of funds, or execution of any protocol upgrade. Revenue and staking projections are assumptions, not confirmed outcomes.",
      "confirmedFacts": [
        "The proposal requests up to $60 million for 2026.",
        "The request comprises $26.9 million for Core baseline work, $16.9 million for Growth baseline work, and a $16.2 million discretionary cap.",
        "The proposed implementation relies on later Easy Track funding motions.",
        "The candidate names operational multisigs for Lido Labs, Lido Ecosystem, and Lido Alliance foundations."
      ],
      "unresolved": [
        "The Snapshot candidate does not establish the final vote result.",
        "No later Easy Track motions or actual disbursements are included.",
        "Reporting, clawback, milestone, and discretionary-spending controls are not fully specified in the retained text.",
        "The proposal's revenue, staking-growth, and surplus projections remain illustrative."
      ],
      "advisorDiligenceImplications": [
        "Monitor the vote and subsequent Easy Track motions as separate operative events.",
        "Track treasury disbursements and delegated spending authority against the approved envelope rather than treating the proposal total as already spent.",
        "Do not treat projected protocol growth or revenue as evidence that Lido V3 or other planned products are live."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-c09ef19ebc2049faa407a081",
      "stableKey": "stakewise-v3:balancer-v2-recovered-funds-distribution-approval-2025-12",
      "version": 1,
      "eventDate": "2025-12-10",
      "publishedAt": "2026-08-22T14:05:59.252Z",
      "title": "StakeWise approves recovered-funds distribution after Balancer V2 exploit",
      "category": "governance",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "stakewise-v3",
          "name": "StakeWise V3"
        },
        {
          "type": "protocol",
          "id": "balancer-v2",
          "name": "Balancer V2"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Proposal: Approve Distribution Of Recovered Funds To LPs Affected By Balancer V2 Exploit",
          "authority": "StakeWise DAO governance via Snapshot",
          "url": "https://snapshot.org/#/stakewise.eth/proposal/0x9e28b6b05d8252d792c07bcdbb3e828fb1cf3f4c9e3d9df1472aded4afab0095",
          "documentType": "governance_record",
          "publishedOn": "2025-12-05"
        }
      ],
      "whatHappened": "StakeWise governance approved initiating a claim distribution of recovered osETH and osGNO to liquidity providers in Balancer V2 pools affected by the exploit.",
      "whatChanged": "The vote authorized a Merkle Distributor process through the StakeWise interface for eligible affected wallets to claim recovered assets.",
      "whatDidNotChange": "The governance record does not prove that the Merkle root or distributor was deployed, that claims opened or completed, that all losses were recovered, or that osETH backing or StakeWise vault-staker balances were impaired.",
      "confirmedFacts": [
        "The Snapshot vote closed on 2025-12-10 with approximately 4.91 million SWISE Yes votes and zero No votes.",
        "The approved proposal concerns LPs in the osETH-ETH and osGNO-GNO Balancer V2 pools.",
        "The approved distribution method was a Merkle Distributor with claims exposed through the StakeWise interface.",
        "The proposal states that allocation figures were based on LP ownership information supplied by the Balancer team."
      ],
      "unresolved": [
        "The exact osETH and osGNO allocation amounts are not included in the candidate governance record.",
        "The Merkle root, distributor contract, funding transaction, claim-opening date, and completed claim totals are not established by this record.",
        "The amount remaining unrecovered after the Balancer V2 exploit is not established by this record.",
        "Whether any affected Ketju client position held the relevant Balancer LP tokens is unresolved."
      ],
      "advisorDiligenceImplications": [
        "Record the event as Balancer V2 LP loss-recovery evidence affecting StakeWise V3 secondary-liquidity diligence.",
        "Verify distribution execution and claim eligibility before representing recovered assets as available to any affected wallet.",
        "Keep the AMM-pool loss distinct from StakeWise vault-staking risk and osETH backing unless primary evidence establishes transmission to those layers."
      ],
      "followUpOn": "2026-08-27",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-3947f3a8bead4e987129bafe",
      "stableKey": "coinbase-bridge-base-missed-block-delay-2025-12-09",
      "version": 1,
      "eventDate": "2025-12-09",
      "publishedAt": "2026-08-22T14:05:59.252Z",
      "title": "Base recovers from missed-block transaction delays",
      "category": "market_stress",
      "posture": "recovered",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "coinbase-bridge",
          "name": "Base canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Delayed Transactions",
          "authority": "Base",
          "url": "https://status.base.org/incidents/mqlf3z7xkwt1",
          "documentType": "official status incident",
          "publishedOn": "2025-12-12"
        }
      ],
      "whatHappened": "Base experienced a high rate of missed blocks. Transactions submitted during missed blocks were delayed until a subsequent successful block, after which the condition resolved without a reported intervention.",
      "whatChanged": "The incident added a confirmed transaction-inclusion disruption to Base's operating history, followed by recovery and preparation of a mitigation for recurrence.",
      "whatDidNotChange": "The status record does not report a canonical-bridge contract exploit, fund loss, withdrawal pause, state reorganization, or permanent change to bridge mechanics.",
      "confirmedFacts": [
        "Base reported a high rate of missed blocks.",
        "Transactions sent during missed blocks were delayed until the next successful block.",
        "Base reported that the issue resolved itself.",
        "Base said it prepared a mitigation for use if the issue returned."
      ],
      "unresolved": [
        "The status record does not state the root cause or incident duration.",
        "It does not quantify missed blocks, delayed transactions, or affected users.",
        "It does not establish whether any canonical-bridge deposits, proofs, or withdrawal finalizations were delayed."
      ],
      "advisorDiligenceImplications": [
        "Record the event in the Base canonical bridge's chain-liveness history.",
        "Monitor recurrence because bridge use depends on Base transaction inclusion even when bridge contracts remain intact.",
        "No approval restriction is supported by this isolated, recovered incident, but repeated missed-block events would warrant review."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-1be33af7eb73192c92e54244",
      "stableKey": "aave-v3:ethereum-linea:musd-temp-check-2025-08",
      "version": 2,
      "eventDate": "2025-11-30",
      "publishedAt": "2026-08-22T14:05:58.597Z",
      "title": "Aave executes mUSD onboarding on Ethereum Core and Linea",
      "category": "economic_change",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Add MetaMask USD (mUSD) to Aave V3 Ethereum/Linea",
          "authority": "Aave Governance V3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=415",
          "documentType": "official_onchain_governance_record",
          "publishedOn": "2025-11-26"
        }
      ],
      "whatHappened": "Aave Governance V3 executed proposal 415, adding MetaMask USD reserves to the Ethereum Core and Linea instances.",
      "whatChanged": "mUSD became supplyable, borrowable, and flash-loanable on both markets. Ethereum received 10 million and 8 million supply and borrow caps; Linea received 70 million and 60 million caps.",
      "whatDidNotChange": "mUSD was not enabled as collateral on either instance. Execution did not make mUSD a Ketju-approved asset or establish the safety of its issuer, reserves, oracle, redemption, or cross-chain dependencies.",
      "confirmedFacts": [
        "Proposal 415 executed on November 30, 2025.",
        "The Ethereum mUSD reserve has a 10 million supply cap and 8 million borrow cap.",
        "The Linea mUSD reserve has a 70 million supply cap and 60 million borrow cap.",
        "Both reserves have zero LTV and are not collateral-enabled.",
        "Both configurations use capped mUSD/USD oracle paths."
      ],
      "unresolved": [
        "Live utilization, liquidity, redemption performance, holder concentration, and oracle behavior.",
        "The operative issuer, reserve-custody, freeze, upgrade, and M0 cross-chain control map.",
        "Whether any approved or client-held Aave position interacts with either mUSD reserve."
      ],
      "advisorDiligenceImplications": [
        "Supersede the preliminary Aave memo interpretation that mUSD remained only a proposed reserve.",
        "Review the Aave dependency map for Bridge, M0, reserve custody, redemption, oracle, and Linea-specific risks.",
        "Keep mUSD suitability separate from the Aave protocol verdict; execution does not approve mUSD for clients."
      ],
      "followUpOn": null,
      "previousInterpretation": "The August 26 TEMP CHECK placed mUSD onboarding on the research perimeter, but contracts, oracles, caps, collateral status, and execution remained unresolved.",
      "supersedesId": null
    },
    {
      "id": "event-event-draft-cb1568ea3b7ac16e24b85330",
      "stableKey": "aave-v3:ethereum-core:syrupusdt-onboarding-aip-2025-11",
      "version": 1,
      "eventDate": "2025-11-28",
      "publishedAt": "2026-08-22T14:05:58.597Z",
      "title": "Aave opens final governance for syrupUSDT collateral on Ethereum Core",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Onboard syrupUSDT to Aave V3 Core Instance",
          "authority": "Aave Governance v3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=416",
          "documentType": "onchain_governance_record",
          "publishedOn": "2025-11-28"
        }
      ],
      "whatHappened": "Aave created on-chain Governance proposal 416 to onboard Maple's syrupUSDT as collateral in the Ethereum Core v3 instance and activated its vote the following day.",
      "whatChanged": "The proposed reserve advanced into binding final governance with a 50 million supply cap, borrowing disabled, a capped syrupUSDT-to-USDT-to-USD oracle path, and a correlated-asset E-mode with USDT and GHO.",
      "whatDidNotChange": "As of the November 30 boundary, the vote had not completed and no payload execution or live syrupUSDT reserve was established. Existing Aave collateral, oracle, and liquidation mechanics were unchanged by proposal creation alone.",
      "confirmedFacts": [
        "Aave Governance proposal 416 was created on November 28, 2025, and activated for voting on November 29.",
        "The proposal references Ethereum payload 375.",
        "The proposed configuration enables syrupUSDT as collateral, disables borrowing, sets a 50,000,000-token supply cap, and specifies non-E-mode LTV and liquidation-threshold values of 0.05% and 0.1%.",
        "The proposed correlated-asset E-mode permits syrupUSDT collateral against USDT and GHO with 90% maximum LTV and a 92% liquidation threshold.",
        "The proposed oracle path uses capped syrupUSDT/USDT/USD and capped USDT/USD components, a seven-day minimum snapshot delay, and 8.45% maximum yearly growth."
      ],
      "unresolved": [
        "The vote outcome, queueing, and any execution occurring after November 30 fall outside this historical packet and require a later event review.",
        "Actual secondary liquidity, depositor concentration, Maple credit performance, withdrawal behavior, and oracle performance under stress were not established by the governance record.",
        "The final live reserve configuration must be reconciled on-chain if the payload is executed."
      ],
      "advisorDiligenceImplications": [
        "Monitor proposal 416 and do not treat syrupUSDT as available collateral until execution and live reserve configuration are verified.",
        "Review whether the Aave memo adequately covers Maple underwriting, withdrawal-queue, upgrade, pause, and administrator dependencies introduced by syrupUSDT.",
        "Assess the large difference between the conservative non-E-mode parameters and the proposed 90%/92% correlated E-mode before considering any exposure involving syrupUSDT, USDT, or GHO."
      ],
      "followUpOn": "2025-12-02",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-69ca23ad7a4bcb561b5e1411",
      "stableKey": "aave-v3:avalanche:rseth-onboarding-2025-11",
      "version": 1,
      "eventDate": "2025-11-25",
      "publishedAt": "2026-08-22T14:05:58.597Z",
      "title": "Aave executes wrsETH onboarding on Avalanche",
      "category": "economic_change",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Onboard rsETH to Aave V3 Avalanche Instance",
          "authority": "Aave Governance V3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=414",
          "documentType": "official_onchain_governance_record",
          "publishedOn": "2025-11-21"
        }
      ],
      "whatHappened": "Aave Governance V3 executed proposal 414, adding wrapped rsETH as collateral on the Avalanche instance.",
      "whatChanged": "wrsETH became collateral-enabled with a 5,000-unit supply cap, a capped exchange-rate oracle path, and a wrsETH/WETH E-mode allowing 93% maximum LTV and a 95% liquidation threshold.",
      "whatDidNotChange": "wrsETH was not enabled for ordinary borrowing. Execution did not approve Avalanche, Kelp DAO, LayerZero, wrsETH, or the new E-mode for Ketju clients.",
      "confirmedFacts": [
        "Proposal 414 executed on November 25, 2025.",
        "The wrsETH supply cap is 5,000 units.",
        "Base collateral parameters are 0.05% LTV and a 0.1% liquidation threshold.",
        "The wrsETH/WETH E-mode uses 93% LTV and a 95% liquidation threshold.",
        "The reserve uses a capped wrsETH/ETH/USD oracle path and is not borrowable."
      ],
      "unresolved": [
        "Live wrsETH liquidity, utilization, liquidation performance, and holder concentration on Avalanche.",
        "The continuing security of Kelp, wrapper, LayerZero, multisig, bridger-role, and oracle dependencies.",
        "Whether high E-mode leverage remains liquidatable during bridge, wrapper, or staking-token stress."
      ],
      "advisorDiligenceImplications": [
        "Review the Aave memo for the new cross-chain wrapper, bridge, oracle, and high-leverage E-mode dependencies.",
        "Keep the Avalanche reserve outside any Ethereum-only Aave approval unless separately reviewed.",
        "Monitor live liquidity and liquidation capacity before recognizing the reserve as advisor-accessible exposure."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-2d041fffbb223a4d47ded1dd",
      "stableKey": "lido:curated-module:fee-tiers-2025-11",
      "version": 1,
      "eventDate": "2025-11-24",
      "publishedAt": "2026-08-22T14:05:58.597Z",
      "title": "Lido opens a vote on Curated Module fee tiers",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Curated Module Fee Changes",
          "authority": "Lido Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x3a5d10fcd3fad6d5ccf05f5bd49244046600ad9cbed9a5e07845200b3ae97e09",
          "documentType": "official_governance_proposal",
          "publishedOn": "2025-11-24"
        }
      ],
      "whatHappened": "Lido opened a Snapshot vote on an interim Curated Module fee structure with Standard, Extra Effort, and Client-Team operator tiers.",
      "whatChanged": "A concrete governance path opened to set the module-level operator share to 3.50% and pay qualifying operators an additional 0.50% or 1.00% through manual rebates.",
      "whatDidNotChange": "The proposal would leave Lido's overall 10% protocol fee unchanged. No approval or on-chain implementation occurred within the November event window, and Curated Module v2 remained a future proposal.",
      "confirmedFacts": [
        "The proposed operator tiers are 3.50%, 4.00%, and 4.50%.",
        "Technical limitations in Curated Module v1 would set the module-level operator fee to 3.50%.",
        "Higher-tier amounts would be paid through manual rebate-like operations.",
        "The overall protocol fee would remain 10%.",
        "The Snapshot vote opened on November 24 and extended beyond the November review window."
      ],
      "unresolved": [
        "The vote result and any subsequent Aragon approval or execution.",
        "The final operator classifications, rebate administrator, payment cadence, and verification controls.",
        "The effect on DAO revenue, operator retention, client yield, and operational-error exposure.",
        "The eventual Curated Module v2 fee and automation design."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido memo's fee-allocation and manual-payment control map if the proposal advances.",
        "Verify the final vote, execution, tier assignments, and rebate authority before treating the economics as operative.",
        "Do not infer that lower or differentiated operator fees improve staking safety or decentralization."
      ],
      "followUpOn": "2025-12-02",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-59da0ab00ba311281c48e85d",
      "stableKey": "lido:treasury:susds-tmmf-conversion-2025-11",
      "version": 1,
      "eventDate": "2025-11-24",
      "publishedAt": "2026-08-22T14:05:58.597Z",
      "title": "Lido proposes investing treasury stablecoins in sUSDS and tokenized funds",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Conversion of Treasury Stablecoins into sUSDS or TMMFs",
          "authority": "Lido Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x4dd947f5e73377b074fd393148b377558179f22ea923d584dd3c718f3bab0687",
          "documentType": "official_governance_proposal",
          "publishedOn": "2025-11-24"
        }
      ],
      "whatHappened": "Lido opened a Snapshot vote authorizing its Treasury Management Committee and two Foundations to implement the TMC-6 strategy for approximately $30 million of idle stablecoins.",
      "whatChanged": "The proposal would permit stablecoin withdrawals through existing Easy Track paths, conversion into sUSDS or selected tokenized money-market funds, and custody through Foundation multisigs acting for the DAO.",
      "whatDidNotChange": "No conversion, asset selection, transfer, or custody change was established within November. The proposal did not change stETH staking, withdrawals, validator operations, or the protocol fee.",
      "confirmedFacts": [
        "The proposal described approximately $30 million of idle treasury stablecoins.",
        "Yield-bearing assets would be capped at 15% of total treasury value.",
        "The liquidity floor would require remaining stablecoin liquidity to cover at least two months of operating costs after specified exclusions.",
        "USDS could be converted into sUSDS, while eligible tokenized funds could include products such as BUIDL, Fidelity Digital Treasury Fund, or USYC.",
        "The Snapshot vote extended beyond the November review window."
      ],
      "unresolved": [
        "The vote result and any subsequent on-chain authorization or transfers.",
        "The assets ultimately selected by the Treasury Management Committee.",
        "The final Foundation wallet, signer, custody, KYC, redemption, and concentration arrangements.",
        "The resulting exposure to Sky, fund issuers, custodians, stablecoin liquidity, and legal restrictions."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido governance-resilience memo for the proposed Foundation custody path and delegated asset-selection authority.",
        "Add sUSDS, selected fund issuers, custodians, redemption gates, and liquidity guardrails to diligence if execution occurs.",
        "Verify actual transfers and holdings; governance approval alone would not establish treasury-asset safety."
      ],
      "followUpOn": "2025-12-02",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-3d2fe2f6994402257ee87c88",
      "stableKey": "rocket-pool:saturn1:minipool-queue-closure-rpip74-2025-11",
      "version": 1,
      "eventDate": "2025-11-21",
      "publishedAt": "2026-08-22T14:05:58.597Z",
      "title": "Rocket Pool proposes closing the minipool queue before Saturn 1",
      "category": "closure_deprecation",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "rocket-pool",
          "name": "Rocket Pool"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Minipool Queue Closure pre-Saturn 1 Launch (RPIP-74)",
          "authority": "Rocket Pool Snapshot",
          "url": "https://snapshot.org/#/rocketpool-dao.eth/proposal/0x9d51f88c2820462691599abfb573417993c09d2cd5901fde7a8e3d68249ca7bc",
          "documentType": "official_governance_proposal",
          "publishedOn": "2025-11-21"
        }
      ],
      "whatHappened": "Rocket Pool opened a vote on RPIP-74 to stop new entries into the legacy minipool queue before the Saturn 1 megapool launch.",
      "whatChanged": "The proposal created a concrete path to close the irreversible minipool queue by December 8, 2025, or six weeks before Saturn 1, while defining exceptional conditions for reopening.",
      "whatDidNotChange": "The queue remained open during the November event window, and no Saturn 1 launch or closure transaction was established. Existing queued minipools and rETH redemption mechanics were not directly changed by publication.",
      "confirmedFacts": [
        "The proposed closure deadline was December 8, 2025, or six weeks before Saturn 1, whichever applied under the proposal.",
        "The stated objectives included reserving deposit-pool ETH for megapools and reducing pressure on the rETH discount.",
        "The proposal noted that minipool queue entries cannot be exited.",
        "The Snapshot vote extended into December."
      ],
      "unresolved": [
        "The vote result, executed closure time, and any reopening conditions invoked.",
        "The number and value of minipools remaining in the queue at closure.",
        "The final Saturn 1 launch date and effect on rETH redemption liquidity and peg behavior."
      ],
      "advisorDiligenceImplications": [
        "Review Rocket Pool's access, migration, and rETH-liquidity assumptions before the legacy queue closes.",
        "Identify any client or operator workflow dependent on new minipool admission.",
        "Verify the executed queue state and Saturn 1 readiness rather than treating the proposal as an operative closure."
      ],
      "followUpOn": "2025-12-06",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-53b3ae80be17aca831a1fb24",
      "stableKey": "rocket-pool:saturn1:express-ticket-allocation-rpip75-2025-11",
      "version": 1,
      "eventDate": "2025-11-21",
      "publishedAt": "2026-08-22T14:05:58.597Z",
      "title": "Rocket Pool proposes new Saturn 1 express-ticket allocation",
      "category": "upgrade_migration",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "rocket-pool",
          "name": "Rocket Pool"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Change Express Ticket Allocation for Saturn 1 (RPIP-75)",
          "authority": "Rocket Pool Snapshot",
          "url": "https://snapshot.org/#/rocketpool-dao.eth/proposal/0x4b85eee832dcc7d7ae1ca8b1945ba3365810a8fe943c2fd72defe567a48c7f5c",
          "documentType": "official_governance_proposal",
          "publishedOn": "2025-11-21"
        }
      ],
      "whatHappened": "Rocket Pool opened a vote on RPIP-75 to alter express-ticket issuance and queue priority for migration from legacy minipools to Saturn 1 megapools.",
      "whatChanged": "The proposal would remove the unconditional two-ticket base allocation and match one regular-queue megapool after four express-queue deposits rather than after two.",
      "whatDidNotChange": "No migration rule changed within November. The proposal did not alter rETH's exchange-rate accounting, redemption contract, custody, or validator withdrawal credentials.",
      "confirmedFacts": [
        "The proposed base express-ticket allocation is zero.",
        "Tickets derived from legacy bonded ETH would remain available under the stated formula.",
        "The proposed express priority is four express deposits for each regular-queue deposit.",
        "The Snapshot vote extended into December."
      ],
      "unresolved": [
        "The vote result and implementation transaction.",
        "The final Saturn 1 launch date and migration-state configuration.",
        "The effect on operator migration speed, validator capacity, rETH demand, and redemption liquidity."
      ],
      "advisorDiligenceImplications": [
        "Monitor the final vote and executed Saturn 1 queue configuration.",
        "Update the Rocket Pool operator-migration assumptions if implemented, while keeping client rETH liquidity analysis separate.",
        "The proposal alone does not change the current Rocket Pool memo verdict."
      ],
      "followUpOn": "2025-12-06",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-3d90e6e6f7aca33b8fe71abd",
      "stableKey": "aave-v3:plasma:wsteth-freeze-2025-11",
      "version": 1,
      "eventDate": "2025-11-18",
      "publishedAt": "2026-08-22T14:05:58.597Z",
      "title": "Aave freezes the wstETH reserve on Plasma",
      "category": "closure_deprecation",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Freeze wstETH Plasma",
          "authority": "Aave Governance V3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=410",
          "documentType": "official_onchain_governance_record",
          "publishedOn": "2025-11-14"
        }
      ],
      "whatHappened": "Aave Governance V3 executed proposal 410, freezing the wstETH reserve on Plasma after Lido and Chainlink decided to replace the existing cross-chain representation.",
      "whatChanged": "New wstETH deposits, borrowing, and collateral enablement were disabled on the Plasma Aave market.",
      "whatDidNotChange": "The payload did not freeze the separate wrsETH reserve, alter Lido's Ethereum staking or withdrawal contracts, or establish that existing Plasma wstETH positions had migrated.",
      "confirmedFacts": [
        "Proposal 410 executed on November 18, 2025.",
        "The freeze prevents new deposits, borrows, and collateral enablement for wstETH on Plasma.",
        "The proposal attributed the change to replacement of a wstETH cross-chain deployment that was not considered future-proof.",
        "The proposal reported approximately 0.044 wstETH on Aave Plasma when published."
      ],
      "unresolved": [
        "The migration path and timing for existing Plasma wstETH holders.",
        "The new token contract, CCIP configuration, deployed controls, and Aave re-onboarding path.",
        "Whether any client or approved position used the frozen reserve.",
        "Live exit liquidity and pricing for the deprecated representation."
      ],
      "advisorDiligenceImplications": [
        "Update the Aave memo to treat the Plasma wstETH reserve as unavailable for new exposure.",
        "Review any existing position for exit and migration mechanics without assuming the replacement representation is equivalent or approved.",
        "Reassess the bridge, token, oracle, and freeze-control map before any future re-onboarding."
      ],
      "followUpOn": null,
      "previousInterpretation": "On October 19, Aave executed wstETH and wrsETH onboarding on Plasma, with wstETH enabled as borrowable collateral under a high-efficiency E-mode.",
      "supersedesId": null
    },
    {
      "id": "event-event-draft-2ab4ca042d66e6e621dff281",
      "stableKey": "aave-v3:low-demand-volatile-assets:ltv-zero-2025-11",
      "version": 1,
      "eventDate": "2025-11-14",
      "publishedAt": "2026-08-22T14:05:58.597Z",
      "title": "Aave executes zero-LTV deprecation for nine volatile assets",
      "category": "closure_deprecation",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Deprecation of Low Demand Volatile Assets on Aave V3 Instances",
          "authority": "Aave Governance V3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=409",
          "documentType": "official_onchain_governance_record",
          "publishedOn": "2025-11-10"
        }
      ],
      "whatHappened": "Aave Governance V3 executed proposal 409, setting the LTV of nine low-demand volatile assets to zero across Ethereum Core, zkSync, BNB, and Metis.",
      "whatChanged": "The affected assets no longer provided additional borrowing capacity under their base reserve configurations, advancing their deprecation.",
      "whatDidNotChange": "The payload did not freeze the reserves, set their liquidation thresholds to zero, or establish that existing positions had been closed.",
      "confirmedFacts": [
        "Proposal 409 executed on November 14, 2025.",
        "Ethereum Core UNI, CRV, BAL, ENS, LDO, and 1INCH had their LTVs set to zero.",
        "ZK on zkSync, CAKE on BNB, and METIS on Metis had their LTVs set to zero.",
        "The proposal was described as the second stage of a broader low-demand-asset deprecation process."
      ],
      "unresolved": [
        "Remaining supplied collateral, debt, and client exposure in each affected reserve.",
        "Subsequent freeze, reserve-factor, cap, or full-offboarding actions.",
        "Exit liquidity and borrower behavior following the zero-LTV change."
      ],
      "advisorDiligenceImplications": [
        "Review any affected Aave collateral position for reduced borrowing capacity and migration needs.",
        "Update collateral-eligibility assumptions in the Aave memo while distinguishing zero LTV from a reserve freeze or immediate liquidation-threshold change.",
        "Monitor subsequent deprecation stages and live exit liquidity."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-1b31e2fe711a2743f00e9d9d",
      "stableKey": "aave-v3:gnosis:cap-reinstatement-2025-11",
      "version": 1,
      "eventDate": "2025-11-10",
      "publishedAt": "2026-08-22T14:05:58.597Z",
      "title": "Aave restores supply and borrow caps on Gnosis",
      "category": "economic_change",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "mixed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Reinstate Supply and Borrow Caps on Aave V3 Gnosis Instance",
          "authority": "Aave Governance V3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=406",
          "documentType": "official_onchain_governance_record",
          "publishedOn": "2025-11-06"
        }
      ],
      "whatHappened": "Aave Governance V3 executed proposal 406, restoring supply and borrow caps across the Gnosis instance after caps had been reduced during the Balancer exploit response and canonical-bridge pause.",
      "whatChanged": "The payload reopened capacity for wstETH, sDAI, GNO, WETH, USDC.e, xDAI, GHO, and EURe under the specified revised caps.",
      "whatDidNotChange": "Execution did not itself prove that the Gnosis canonical bridge had reopened, that cross-market pricing had normalized, or that the Balancer-related recovery was complete.",
      "confirmedFacts": [
        "Proposal 406 executed on November 10, 2025.",
        "The prior precautionary configuration had reduced many supply and borrow caps to one.",
        "The executed payload increased caps for the listed Gnosis reserves.",
        "The stated rationale was anticipated restoration of bridge-mediated arbitrage and price alignment."
      ],
      "unresolved": [
        "The exact canonical-bridge reopening time and operational state at execution.",
        "Whether DEX and oracle prices had fully reconverged before capacity returned.",
        "Live utilization, liquidation performance, and any bad debt following reinstatement.",
        "Whether any approved or client-held exposure used the Gnosis instance."
      ],
      "advisorDiligenceImplications": [
        "Review the Aave Gnosis memo assumptions because capacity was restored based on an expected bridge recovery.",
        "Verify bridge status, cross-market price alignment, reserve caps, and liquidation liquidity independently.",
        "Do not extend any Ethereum-only Aave approval to Gnosis solely because the caps were reinstated."
      ],
      "followUpOn": "2025-11-12",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-0017652494ac836c0d0695aa",
      "stableKey": "optimism-bridge:dab-onchain-controls-mvp:2025-10-31",
      "version": 1,
      "eventDate": "2025-10-31",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Optimism proposes DAB on-chain controls MVP",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "bridge",
          "id": "optimism-bridge",
          "name": "Optimism canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Governor Upgrade Proposal: On-chain Controls MVP",
          "authority": "Optimism Developer Advisory Board",
          "url": "https://snapshot.org/#/developeradvisoryboard.eth/proposal/0x11d922eca8a635317c4a0a68657908c40bc7904f8cc86d412d1175d5234ccbaf",
          "documentType": "official_governance_proposal",
          "publishedOn": "2025-10-31"
        }
      ],
      "whatHappened": "The Optimism Developer Advisory Board opened a vote on an On-chain Controls MVP that would change administration and authorized-proposer roles for the Optimism Governor.",
      "whatChanged": "A concrete governance proposal now defines a possible on-chain control model in which the Security Council holds the Governor admin role and Token House authority becomes enforceable through an authorizedProposer role.",
      "whatDidNotChange": "No approval, veto-period completion, deployment, or execution was established within the October window. The record does not show a present change to canonical-bridge custody, withdrawals, dispute resolution, or deployed bridge contracts.",
      "confirmedFacts": [
        "The official DAB proposal was published on October 31, 2025.",
        "The proposed model assigns the Optimism Governor admin role to the Security Council.",
        "The proposal introduces an on-chain authorizedProposer role.",
        "A passing DAB vote would proceed to a one-week veto period."
      ],
      "unresolved": [
        "The DAB vote result and any veto outcome.",
        "The final deployed contracts, role assignments, and activation date.",
        "Whether and how the controls directly reach canonical-bridge upgrades, dispute operations, or emergency actions."
      ],
      "advisorDiligenceImplications": [
        "Monitor the vote, veto period, deployment, and executed role state before changing the Optimism Bridge control assessment.",
        "If implemented, review the Security Council's scope, proposer constraints, revocation path, and any direct authority over bridge upgrades or dispute controls."
      ],
      "followUpOn": "2025-11-07",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-86c836469549007e5c611af2",
      "stableKey": "aave-v3:base:cbbtc-stablecoin-emode-aip-2025-10",
      "version": 1,
      "eventDate": "2025-10-29",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Aave opens final governance for cbBTC Stablecoin E-Mode on Base",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Addition of cbBTC/Stablecoin E-Mode to Aave V3 Base Instance",
          "authority": "Aave Governance V3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=400",
          "documentType": "onchain_governance_proposal",
          "publishedOn": "2025-10-29"
        },
        {
          "title": "Aave Governance proposal 400 creation transaction",
          "authority": "Ethereum — Aave Governance V3",
          "url": "https://etherscan.io/tx/0xf901bb63161d81ecf9ad72f077b5b0f565178aa640e2800fd33f0c15d03c1936",
          "documentType": "onchain_transaction",
          "publishedOn": "2025-10-29"
        }
      ],
      "whatHappened": "Aave Governance V3 proposal 400 opened final on-chain governance for a cbBTC Stablecoin E-Mode on the Aave V3 Base market.",
      "whatChanged": "The plan advanced to a formal AIP. If executed, cbBTC could collateralize USDC and GHO debt under an 80% maximum LTV, 83% liquidation threshold, and 4% liquidation bonus within the new E-Mode.",
      "whatDidNotChange": "Creation of the proposal did not itself activate the E-Mode. The proposal states that cbBTC's base reserve settings would remain unchanged, and no October execution was established by the reviewed creation event.",
      "confirmedFacts": [
        "Aave Governance V3 proposal 400 was created on October 29, 2025.",
        "The proposed E-Mode uses cbBTC as collateral and makes USDC and GHO borrowable within the category.",
        "The proposed maximum LTV is 80% and the liquidation threshold is 83%.",
        "The proposed liquidation bonus is 4%.",
        "The proposal does not alter cbBTC's base reserve settings."
      ],
      "unresolved": [
        "Any approval and target-chain execution occurring after the October 31 cutoff are outside this decision.",
        "The executed Base configuration and activation time.",
        "The effect on borrower leverage, liquidation volumes, oracle dependence, and realized bad debt under market stress.",
        "Whether any approved or client-held position uses the affected Base cbBTC configuration."
      ],
      "advisorDiligenceImplications": [
        "Review the Aave V3 Base memo's cbBTC liquidation-buffer, oracle, custody, and stablecoin-debt assumptions before treating the proposed E-Mode as acceptable.",
        "Verify the final vote, executed configuration, and affected accounts before recognizing the higher collateral efficiency as operative."
      ],
      "followUpOn": "2025-10-31",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-abb58cc5dec8887fe3c53f1c",
      "stableKey": "aave-v3:gnosis:legacy-usdc-deprecation-aip-2025-10",
      "version": 1,
      "eventDate": "2025-10-28",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Aave opens final governance to deprecate legacy USDC on Gnosis",
      "category": "closure_deprecation",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "USDC (old) deprecation on Gnosis Chain Instance",
          "authority": "Aave Governance V3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=399",
          "documentType": "onchain_governance_proposal",
          "publishedOn": "2025-10-28"
        },
        {
          "title": "Aave Governance proposal 399 creation transaction",
          "authority": "Ethereum — Aave Governance V3",
          "url": "https://etherscan.io/tx/0x0ecea0c744b272e5663b041d2aca92a012b2d3c96bdfc23e53cc8a863c9a9d12",
          "documentType": "onchain_transaction",
          "publishedOn": "2025-10-28"
        }
      ],
      "whatHappened": "Aave Governance V3 proposal 399 opened final on-chain governance to deprecate the legacy USDC reserve on Aave V3 Gnosis.",
      "whatChanged": "The deprecation plan advanced to a formal AIP. If executed, the reserve would be frozen against new deposits, borrowing, and collateral enablement, while its reserve factor would rise from 40% to 80%.",
      "whatDidNotChange": "Creation of the proposal did not itself freeze the reserve. The payload would leave existing positions in place and would not deprecate the canonical USDC.e reserve.",
      "confirmedFacts": [
        "Aave Governance V3 proposal 399 was created on October 28, 2025.",
        "The proposal would freeze the legacy USDC reserve against new deposits, borrowing, and collateral enablement.",
        "The proposed reserve-factor change is from 40% to 80%.",
        "The proposal states that existing positions remain unaffected by the freeze.",
        "The stated objective is migration toward the Circle-supported USDC.e reserve."
      ],
      "unresolved": [
        "Any approval and target-chain execution occurring after the October 31 cutoff are outside this decision.",
        "The executed Gnosis reserve configuration and activation time.",
        "The amount of approved or client-held exposure remaining in legacy USDC.",
        "The practical exit liquidity and yield impact for positions that do not migrate."
      ],
      "advisorDiligenceImplications": [
        "Review any Aave V3 Gnosis legacy-USDC exposure and the memo's eligible-reserve assumptions before the proposed freeze becomes operative.",
        "Verify the final vote, execution, reserve state, and migration liquidity; the proposal does not itself justify treating USDC.e or the broader Gnosis market as approved."
      ],
      "followUpOn": "2025-10-31",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-1e7e6adfb99960ad888e68c4",
      "stableKey": "aave-v3:avalanche:usde-susde-onboarding-2025-10",
      "version": 1,
      "eventDate": "2025-10-25",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Aave executes USDe and sUSDe onboarding on Avalanche",
      "category": "economic_change",
      "posture": "executed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Onboard sUSDe and USDe to Aave V3 Avalanche Instance",
          "authority": "Aave Governance V3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=397",
          "documentType": "official_onchain_governance_record",
          "publishedOn": "2025-10-21"
        }
      ],
      "whatHappened": "Aave governance executed proposal 397, onboarding USDe and sUSDe to the Aave V3 Avalanche instance.",
      "whatChanged": "USDe and sUSDe became configured collateral reserves on Avalanche with 50 million-unit supply caps, dedicated capped-oracle paths, and stablecoin E-mode configurations. USDe was enabled for borrowing while sUSDe was not.",
      "whatDidNotChange": "Execution did not expand Ketju's Ethereum-only Aave approval, establish advisor suitability for either asset, or demonstrate sustained liquidity and liquidation performance on Avalanche.",
      "confirmedFacts": [
        "Aave proposal 397 reached executed status on October 25.",
        "The executed proposal configured 50,000,000-unit supply caps for both USDe and sUSDe.",
        "USDe was configured as borrowable; sUSDe was configured as non-borrowable.",
        "Both assets were enabled as collateral and assigned capped-oracle configurations."
      ],
      "unresolved": [
        "Live reserve liquidity, utilization, borrower concentration, and liquidation performance after onboarding.",
        "The assets' suitability for any future chain-specific Ketju approval."
      ],
      "advisorDiligenceImplications": [
        "Add the Avalanche reserves to Aave's cross-chain diligence perimeter and monitor their oracle and liquidation performance.",
        "Do not treat execution as an expansion of the approved Ethereum Aave sleeve."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-d9c7464134d38d52cc7954d2",
      "stableKey": "aave-v3:risk-oracle:slope2-automation-arfc-2025-08",
      "version": 2,
      "eventDate": "2025-10-25",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Aave executes Slope2 Risk Oracle activation",
      "category": "control_change",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Slope2 Risk Oracle Activation On Core Ethereum, Linea",
          "authority": "Aave Governance V3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=395",
          "documentType": "official_onchain_governance_record",
          "publishedOn": "2025-10-21"
        }
      ],
      "whatHappened": "Aave governance executed proposal 395, activating automated Slope2 interest-rate updates on specified Ethereum Core and Linea reserves.",
      "whatChanged": "The approved risk-oracle and steward path became operative for Slope2 updates. Covered Ethereum assets include WETH, USDC, USDT, and USDe; covered Linea assets include WETH, USDC, and USDT.",
      "whatDidNotChange": "The automation is restricted to Slope2 for whitelisted assets and did not transfer unrestricted authority over other interest-rate, collateral, liquidation, oracle, pause, or custody parameters.",
      "confirmedFacts": [
        "Proposal 395 reached executed status on October 25.",
        "The execution included an Ethereum payload and a Linea payload.",
        "The activated steward was limited to Slope2 updates for configured assets.",
        "The proposal assigned the required RiskAdmin authority and specified Chainlink Automation for Ethereum and Gelato automation for Linea."
      ],
      "unresolved": [
        "The realized frequency and magnitude of automated Slope2 changes after activation.",
        "Market-by-market performance during prolonged high-utilization stress."
      ],
      "advisorDiligenceImplications": [
        "Supersede the earlier ARFC-stage interpretation with executed status in the Aave memo's control map.",
        "Monitor automated borrow-rate changes and distinguish them from manually governed parameter changes when evaluating liquidity stress."
      ],
      "followUpOn": null,
      "previousInterpretation": "The Slope2 risk-oracle automation had been approved at the ARFC stage but was not yet confirmed operative.",
      "supersedesId": null
    },
    {
      "id": "event-event-draft-5d415eaa51887409c91d0fe3",
      "stableKey": "sky-lending:sparklend-stablecoin-cap-removal-2025-10",
      "version": 1,
      "eventDate": "2025-10-23",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Spark approves removing USDC, USDT, and PYUSD reserve caps",
      "category": "economic_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        },
        {
          "type": "protocol",
          "id": "sparklend",
          "name": "SparkLend"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[Ethereum] SparkLend - Remove Supply and Borrow Caps for Non Collateral Stablecoins (USDC, USDT, PYUSD)",
          "authority": "Spark governance",
          "url": "https://snapshot.org/#/sparkfi.eth/proposal/0xeea0e2648f55df4e57f8717831a5949f2a35852e32aa0f98a7e16e7ed56268a8",
          "documentType": "official_governance_vote",
          "publishedOn": "2025-10-20"
        }
      ],
      "whatHappened": "Spark governance approved removing supply-cap and borrow-cap automation and setting the USDC, USDT, and PYUSD supply and borrow caps to zero on Ethereum SparkLend.",
      "whatChanged": "The approved configuration would remove explicit reserve-level exposure ceilings for the three stablecoins once implemented.",
      "whatDidNotChange": "On-chain execution was not established by the retained record. The three assets remained non-collateral under the proposal, and approval did not reopen Ketju's rejected SparkLend memo.",
      "confirmedFacts": [
        "The official Spark vote concluded with the For option prevailing.",
        "USDC, USDT, and PYUSD were the only reserves covered.",
        "The approved specification sets each reserve's supply cap and borrow cap to zero, meaning no cap.",
        "The proposal states that the assets are not usable as collateral."
      ],
      "unresolved": [
        "The implementation transaction and effective on-chain parameters.",
        "Post-implementation utilization, concentration, available liquidity, and any replacement exposure controls."
      ],
      "advisorDiligenceImplications": [
        "Review the Sky dependency map because uncapped SparkLend reserves can change balance-sheet concentration and liquidity behavior.",
        "Keep SparkLend allocation at zero unless its asset-specific reopen criteria are independently satisfied, including live exit and utilization tests."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-f3ed3741b9b588f1cde05111",
      "stableKey": "sky-lending:sll-relayer-freezer-multisig-change-2025-10",
      "version": 1,
      "eventDate": "2025-10-23",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Spark approves Liquidity Layer relayer and freezer multisig changes",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        },
        {
          "type": "protocol",
          "id": "spark-liquidity-layer",
          "name": "Spark Liquidity Layer"
        }
      ],
      "primaryDocuments": [
        {
          "title": "SAEP-02: Modify Spark Liquidity Layer Core Relayer and Freezer Multisig Configuration",
          "authority": "Spark governance",
          "url": "https://snapshot.org/#/sparkfi.eth/proposal/0xaceea966c8767ae32966f603d30ff9404d68702e5bb67a33234b2f7c46dac0ec",
          "documentType": "official_governance_vote",
          "publishedOn": "2025-10-20"
        }
      ],
      "whatHappened": "Spark governance approved adding Spark Assets Foundation as a co-controller of the Core Operator Relayer multisig and lowering the Freezer multisig threshold.",
      "whatChanged": "The approved Core Operator Relayer configuration becomes 2-of-5 across two Amatsu signers, two Spark Assets Foundation signers, and one Phoenix Labs signer. The approved Freezer configuration becomes 1-of-4, allowing any one listed signer to initiate an emergency freeze.",
      "whatDidNotChange": "The retained record did not establish on-chain implementation, the final deployed signer addresses, or any change to unfreeze procedures. No asset loss or active incident was reported.",
      "confirmedFacts": [
        "The official Spark vote concluded with the For option prevailing.",
        "The Core Operator Relayer threshold was approved at 2-of-5.",
        "The Freezer threshold was approved to fall from 2-of-4 to 1-of-4.",
        "The proposed Freezer roster comprises one Spark Assets Foundation signer, two Phoenix Labs signers, and VoteWizard."
      ],
      "unresolved": [
        "The implementation transaction and final signer addresses.",
        "The resulting per-chain authority state and tested unfreeze path.",
        "Whether the lower freeze threshold produces material false-positive or key-compromise risk."
      ],
      "advisorDiligenceImplications": [
        "Review the Sky and Spark Liquidity Layer control maps because emergency freezing becomes individually exercisable if implemented.",
        "Verify the deployed thresholds and signers chain by chain; the approval does not satisfy the rejected Liquidity Layer memo's disclosure-based reopen criteria."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-2e26e1ec2f14ec5e74e8dfae",
      "stableKey": "lido:validator-exits-snop-v3-2025-10",
      "version": 1,
      "eventDate": "2025-10-22",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Lido approves Validator Exits SNOP v3",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Proposal for Updating Lido on Ethereum Validator Exits SNOP to v3",
          "authority": "Lido DAO",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x62eb338c6d256d43ee54e2b79e9442b58fcfda4ecdcd817ff6422d564d153e9a",
          "documentType": "official_governance_vote",
          "publishedOn": "2025-10-15"
        }
      ],
      "whatHappened": "Lido tokenholders approved version 3 of the Standard Node Operator Protocol governing validator exits.",
      "whatChanged": "The approved standard incorporates triggerable withdrawals, expands applicability to Simple DVT, Community Staking, and future modules, and clarifies node-operator exit, configuration, responsiveness, and reporting obligations.",
      "whatDidNotChange": "The vote did not itself change the Withdrawal Queue contracts, prove universal operator implementation, or demonstrate stressed-condition exit performance.",
      "confirmedFacts": [
        "The official Lido vote concluded on October 22 with the For option prevailing.",
        "SNOP v3 incorporates triggerable-withdrawal responsibilities.",
        "The standard expands beyond the prior curated-operator context to newer staking modules.",
        "The approved text specifies clearer operator obligations and revised consequences for non-conformance."
      ],
      "unresolved": [
        "Implementation and compliance status across individual node operators and modules.",
        "Observed performance during large, urgent, or congested validator-exit requests."
      ],
      "advisorDiligenceImplications": [
        "Replace SNOP v2 references in Lido diligence with the approved v3 standard.",
        "Continue monitoring operator compliance and withdrawal timing because policy approval does not eliminate execution and queue risk."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-7d8fe42790671fe516ef186b",
      "stableKey": "aave-v3:plasma:syrupusdt-onboarding-2025-10",
      "version": 1,
      "eventDate": "2025-10-22",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Aave executes syrupUSDT onboarding on Plasma",
      "category": "economic_change",
      "posture": "executed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Onboard syrupUSDT to Aave V3 Plasma Instance",
          "authority": "Aave Governance V3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=394",
          "documentType": "official_onchain_governance_record",
          "publishedOn": "2025-10-18"
        }
      ],
      "whatHappened": "Aave governance executed proposal 394, onboarding syrupUSDT to the Aave V3 Plasma instance.",
      "whatChanged": "syrupUSDT became configured as non-borrowable collateral with a 150 million-unit supply cap, a capped syrupUSDT-to-USDT oracle path, and a syrupUSDT/USDT0 E-mode configuration.",
      "whatDidNotChange": "Execution did not expand Ketju's Ethereum-only Aave approval, confirm Maple credit quality, or demonstrate exit liquidity and liquidation performance for the new Plasma reserve.",
      "confirmedFacts": [
        "Proposal 394 reached executed status on October 22.",
        "syrupUSDT was enabled as collateral but not as a borrowable reserve.",
        "The configured supply cap was 150,000,000 syrupUSDT.",
        "The base configuration used 0.05% LTV and a 0.1% liquidation threshold, while the specified E-mode used materially higher values."
      ],
      "unresolved": [
        "Live reserve utilization, available liquidity, borrower concentration, and liquidation performance.",
        "The behavior of the capped exchange-rate oracle during Maple or USDT stress."
      ],
      "advisorDiligenceImplications": [
        "Monitor the new reserve as a layered Maple, USDT, oracle, and Plasma dependency.",
        "Do not treat execution as approval for advisor exposure or as an expansion of the existing Aave memo's chain scope."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-83fa94be30e7421b50214de3",
      "stableKey": "lido:bridge-partnership-authority-2025-10",
      "version": 1,
      "eventDate": "2025-10-22",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Lido approves bridge-partnership authority framework",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Empowering Lido Ecosystem Foundation to Lead Bridge-Related Partnerships",
          "authority": "Lido DAO",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0xf842517c2ffba082efac87ec43365e86548adb38e24d1446d850c7d7b979c423",
          "documentType": "official_governance_vote",
          "publishedOn": "2025-10-15"
        }
      ],
      "whatHappened": "Lido tokenholders approved a framework empowering Lido Ecosystem Foundation to lead bridge-related negotiations and agreements involving stETH and wstETH.",
      "whatChanged": "The approved framework delegates partnership execution, establishes a Bridging Security Committee with approval and veto authority, and removes the prior five-day DAO objection period after NEC publication.",
      "whatDidNotChange": "Lido DAO retains authority to cancel, amend, or override agreements. No particular bridge integration, asset deployment, custody change, or cross-chain exposure was approved by this vote alone.",
      "confirmedFacts": [
        "The official Lido vote concluded on October 22 with the For option prevailing.",
        "Lido Ecosystem received authority to negotiate and execute bridge-related agreements.",
        "The Bridging Security Committee must approve technical setups and may veto materially risky partnerships.",
        "The prior five-day DAO objection period was removed from the canonical-bridge recognition flow."
      ],
      "unresolved": [
        "The bridge counterparties, contract deployments, limits, and monitoring arrangements selected under the framework.",
        "How effectively the new committee's veto and escalation processes operate in practice."
      ],
      "advisorDiligenceImplications": [
        "Update the Lido control map for delegated bridge-partnership authority and the shortened objection process.",
        "Underwrite each bridged stETH or wstETH representation separately; the approval does not make cross-chain exposure equivalent to native Ethereum exposure."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-8adda1df8dba6bf6a4b17b8e",
      "stableKey": "coinbase-bridge:base-mainnet-rpc-inclusion-latency:2025-10-20",
      "version": 1,
      "eventDate": "2025-10-20",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Base recovers from elevated RPC and transaction-inclusion latency",
      "category": "market_stress",
      "posture": "recovered",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "coinbase-bridge",
          "name": "Base canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "High RPC latency and transaction inclusion times on Base Mainnet",
          "authority": "Base Status",
          "url": "https://status.base.org/incidents/3h53zgq1hhx5",
          "documentType": "official_status_incident",
          "publishedOn": "2025-10-20"
        }
      ],
      "whatHappened": "Base Mainnet experienced high RPC latency, delayed transaction inclusion, and periodic inconsistencies in block-production timing before performance returned to normal.",
      "whatChanged": "For approximately two hours, transaction submission and state access were less reliable, degrading an operational dependency used by Base canonical-bridge workflows and monitoring.",
      "whatDidNotChange": "Base did not report a bridge exploit, asset loss, invalid state transition, changed withdrawal contract, or permanent finality-policy change.",
      "confirmedFacts": [
        "Base identified the incident at 18:58 UTC on October 20, 2025.",
        "The incident affected Base Mainnet public RPC and block production.",
        "Base reported that block building and RPC performance returned to normal at 21:07 UTC."
      ],
      "unresolved": [
        "Whether any canonical-bridge deposits or withdrawals were materially delayed rather than only exposed to the broader RPC and inclusion degradation.",
        "The root cause and any durable remediation were not stated in the retained status record.",
        "The retained status surface is not treated as a complete historical incident archive."
      ],
      "advisorDiligenceImplications": [
        "Review the Base bridge memo's assumptions for RPC diversity, transaction resubmission, inclusion monitoring, and block-production availability.",
        "Retain alternate-RPC and delayed-inclusion procedures for bridge operations; the recovered incident does not independently require restricting the bridge."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-ef098bc4d45973588a966b92",
      "stableKey": "coinbase-bridge:base-mainnet-aws-capacity:2025-10-20",
      "version": 1,
      "eventDate": "2025-10-20",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Base recovers from AWS-related capacity and batch-submission disruption",
      "category": "market_stress",
      "posture": "recovered",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "coinbase-bridge",
          "name": "Base canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Limited network capacity",
          "authority": "Base Status",
          "url": "https://status.base.org/incidents/yfb0z5876zyp",
          "documentType": "official_status_incident",
          "publishedOn": "2025-10-20"
        }
      ],
      "whatHappened": "An AWS outage affected Base infrastructure, reducing network capacity and interrupting batch submission on Mainnet and Testnet until service recovered.",
      "whatChanged": "Base Mainnet's production capacity and submission of L2 batches to Ethereum were temporarily degraded, exposing cloud-infrastructure availability as a dependency for timely canonical-bridge settlement and monitoring.",
      "whatDidNotChange": "The status record did not report a consensus failure, bridge compromise, asset loss, changed custody, or a permanent change to withdrawal or finality mechanics.",
      "confirmedFacts": [
        "Base began investigating reduced capacity at 08:23 UTC on October 20, 2025.",
        "Base identified a major AWS outage as affecting its infrastructure.",
        "Mainnet batch submission and block production were affected.",
        "Base reported at 09:50 UTC that batch submission resumed and transaction capacity returned to normal."
      ],
      "unresolved": [
        "The number and duration of affected bridge transactions were not disclosed.",
        "The retained record does not describe infrastructure redundancy or post-incident remediation.",
        "The retained status surface is not treated as a complete historical incident archive."
      ],
      "advisorDiligenceImplications": [
        "Review cloud-provider concentration and continuity assumptions in the Base canonical-bridge memo.",
        "Confirm that bridge operating procedures distinguish L2 inclusion from L1 batch submission and monitor both during infrastructure outages."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-09600ef3e3d58ffd01714919",
      "stableKey": "aave-v3:plasma:wsteth-wrseth-onboarding-2025-10",
      "version": 1,
      "eventDate": "2025-10-19",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Aave executes wstETH and wrsETH onboarding on Plasma",
      "category": "economic_change",
      "posture": "executed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Onboard wrsETH to Aave v3 Plasma Instance",
          "authority": "Aave Governance V3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=393",
          "documentType": "official_onchain_governance_record",
          "publishedOn": "2025-10-15"
        }
      ],
      "whatHappened": "Aave governance executed proposal 393, onboarding wstETH and wrsETH to the Aave V3 Plasma instance.",
      "whatChanged": "Both assets became configured collateral reserves with 20,000-unit supply caps and dedicated capped-oracle paths. wstETH was enabled for borrowing; wrsETH was not. Separate E-mode configurations permitted materially higher leverage than the base settings.",
      "whatDidNotChange": "Execution did not change native Lido staking or withdrawal contracts, expand Ketju's Ethereum-only Aave approval, or establish suitability for bridged or multi-wrap collateral on Plasma.",
      "confirmedFacts": [
        "Proposal 393 reached executed status on October 19.",
        "Both wstETH and wrsETH received 20,000-unit supply caps.",
        "wstETH was configured as borrowable; wrsETH was configured as non-borrowable.",
        "The proposal specified 94%/96% wstETH E-mode LTV and liquidation threshold and 93%/95% wrsETH E-mode values."
      ],
      "unresolved": [
        "Live reserve liquidity, utilization, liquidation performance, and bridge or representation risks on Plasma.",
        "Whether the high E-mode settings remain robust during staking-token or chain-specific stress."
      ],
      "advisorDiligenceImplications": [
        "Monitor the Plasma reserves as chain-specific, oracle, and wrapped-staking dependencies of Aave.",
        "Do not treat the new reserves as equivalent to native Ethereum wstETH or as covered by the approved Aave sleeve."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-4630e2fac9b9899f8e0e0498",
      "stableKey": "aave-v3:plasma:pt-usde-pt-susde-2026-01-onboarding",
      "version": 1,
      "eventDate": "2025-10-19",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Aave executes January 2026 USDe principal-token onboarding on Plasma",
      "category": "economic_change",
      "posture": "executed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Onboard sUSDe and USDe January expiry PT tokens on Aave V3 Plasma Instance",
          "authority": "Aave Governance V3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=392",
          "documentType": "official_onchain_governance_record",
          "publishedOn": "2025-10-15"
        }
      ],
      "whatHappened": "Aave governance executed proposal 392, onboarding PT-USDe-15JAN2026 and PT-sUSDe-15JAN2026 to the Aave V3 Plasma instance.",
      "whatChanged": "The fixed-maturity tokens became non-borrowable collateral reserves with 200 million-unit supply caps, linear-discount oracle paths, and risk-oracle-controlled E-mode parameters.",
      "whatDidNotChange": "Execution did not establish post-maturity handling performance, advisor suitability, or inclusion within Ketju's approved Ethereum Aave sleeve.",
      "confirmedFacts": [
        "Proposal 392 reached executed status on October 19.",
        "Both principal tokens mature on January 15, 2026.",
        "Each reserve received a 200,000,000-unit supply cap and was configured as non-borrowable collateral.",
        "The base configuration used 0.05% LTV and a 0.1% liquidation threshold, with higher dynamic E-mode settings."
      ],
      "unresolved": [
        "Liquidity and oracle behavior as maturity approaches and after the tokens mature.",
        "Live utilization, borrower concentration, liquidation performance, and rollover handling."
      ],
      "advisorDiligenceImplications": [
        "Track the reserves through maturity and treat the Pendle, Ethena, oracle, and Plasma layers as separate dependencies.",
        "Do not infer safety or advisor access from execution; the existing Aave approval scope remains unchanged."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-34958087e70649b04174d785",
      "stableKey": "coinbase-bridge:base-mainnet-transaction-inclusion-delay:2025-10-17",
      "version": 1,
      "eventDate": "2025-10-18",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Base recovers from congestion-related transaction-inclusion delays",
      "category": "market_stress",
      "posture": "recovered",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "coinbase-bridge",
          "name": "Base canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Delayed Transaction Inclusion",
          "authority": "Base Status",
          "url": "https://status.base.org/incidents/gvlvywy8dgfj",
          "documentType": "official_status_incident",
          "publishedOn": "2025-10-18"
        }
      ],
      "whatHappened": "Periodic congestion on Base Mainnet delayed transaction inclusion from October 17 into October 18. Base increased mempool size and reported the incident resolved.",
      "whatChanged": "Transactions could remain pending longer during congestion, and Base changed mempool capacity to improve inclusion speed. This temporarily degraded execution reliability for canonical-bridge-related transactions.",
      "whatDidNotChange": "The official record did not report a bridge exploit, asset loss, failed finality, or a change to bridge custody or withdrawal contracts.",
      "confirmedFacts": [
        "Base began reporting periodic congestion and delayed transaction inclusion at 19:27 UTC on October 17, 2025.",
        "The incident affected the Base Mainnet transaction pool.",
        "Base increased mempool size and marked the incident resolved at 03:34 UTC on October 18."
      ],
      "unresolved": [
        "Whether the mempool increase fully addressed recurrence under comparable congestion.",
        "Whether any bridge transaction exceeded an applicable client timing tolerance.",
        "The retained status surface is not treated as a complete historical incident archive."
      ],
      "advisorDiligenceImplications": [
        "Review transaction-expiry, resubmission, and pending-state monitoring procedures for Base bridge activity.",
        "Record congestion and mempool capacity as operational dependencies without treating the resolved event as a permanent bridge restriction."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-c9395c402c6905c3d8bc1f53",
      "stableKey": "coinbase-bridge:base-mainnet-safe-head-delay:2025-10-10",
      "version": 1,
      "eventDate": "2025-10-11",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Base recovers from a transaction-volume-driven safe-head delay",
      "category": "market_stress",
      "posture": "recovered",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "coinbase-bridge",
          "name": "Base canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Safe head delay from high transaction volume",
          "authority": "Base Status",
          "url": "https://status.base.org/incidents/9hvg33kqxb07",
          "documentType": "official_status_incident",
          "publishedOn": "2025-10-11"
        }
      ],
      "whatHappened": "Heavy Base L2 transaction volume delayed batching data to Ethereum and caused the safe head to lag. Base limited calldata included in L2 blocks until safe-head progression recovered.",
      "whatChanged": "Safe-state progression slowed, users could experience delayed inclusion or dropped transactions, and node clients could fall behind. The event temporarily weakened timing assumptions used for Base canonical-bridge settlement and monitoring.",
      "whatDidNotChange": "Unsafe block building continued normally, and Base did not report an invalid finalized state, bridge compromise, asset loss, or permanent finality-policy change.",
      "confirmedFacts": [
        "Base identified heavy transaction volume as delaying batching to Ethereum at 21:40 UTC on October 10, 2025.",
        "The safe head lagged while unsafe block building continued.",
        "Base limited calldata inclusion so the safe head could progress on Ethereum.",
        "Base reported the chain functioning properly and the incident resolved at 00:35 UTC on October 11."
      ],
      "unresolved": [
        "The maximum safe-head lag and any bridge-specific transfer delays were not quantified.",
        "Whether capacity changes were subsequently implemented to reduce recurrence.",
        "The retained status surface is not treated as a complete historical incident archive."
      ],
      "advisorDiligenceImplications": [
        "Review confirmation, safe-head, and L1-batch assumptions used for Base bridge activity.",
        "Ensure bridge monitoring distinguishes unsafe inclusion from safe-state progression and does not treat the recovered event as a confirmed safety failure."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-7c54193e7de96d9a16990737",
      "stableKey": "lido:triggerable-withdrawals:design-approval-2025-07",
      "version": 2,
      "eventDate": "2025-10-02",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Lido activates triggerable withdrawals on Ethereum mainnet",
      "category": "control_change",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Lido V2.2 release",
          "authority": "Lido Finance",
          "url": "https://github.com/lidofinance/core/releases/tag/v2.2.0",
          "documentType": "official_software_release",
          "publishedOn": "2025-10-13"
        },
        {
          "title": "Triggerable Withdrawals Framework in the Lido Protocol",
          "authority": "Lido Governance",
          "url": "https://research.lido.fi/t/triggerable-withdrawals-framework-in-the-lido-protocol/10299/1",
          "documentType": "official_governance_record",
          "publishedOn": "2025-07-04"
        }
      ],
      "whatHappened": "Lido executed the governance action that activated its triggerable-withdrawals framework on Ethereum mainnet; the subsequent v2.2.0 release identifies LIP-30 as implemented.",
      "whatChanged": "Lido gained an execution-layer path for initiating validator exits without relying exclusively on a node operator to cooperate, adding permissionless exit enforcement and new validator-exit control components.",
      "whatDidNotChange": "The activation was not a security incident and did not eliminate Lido's ordinary withdrawal process. The available evidence does not establish how the new mechanism will perform during stressed exit conditions.",
      "confirmedFacts": [
        "Lido Vote 192 passed and Dual Governance Proposal 5 was executed on October 2, 2025.",
        "Lido's official governance record states that the triggerable-withdrawals framework became live.",
        "The framework uses execution-layer validator-exit functionality and is intended to reduce reliance on node-operator cooperation.",
        "The official v2.2.0 release identifies LIP-30 as implemented and links two September 2025 security audits."
      ],
      "unresolved": [
        "Final deployed role assignments, GateSeal configuration, and all operative limit parameters were not independently reproduced in this review.",
        "The framework's usage frequency and behavior during severe validator-exit congestion remain untested by the cited records.",
        "Whether subsequent governance actions altered the initial configuration."
      ],
      "advisorDiligenceImplications": [
        "Supersede the design-only interpretation in the Lido memo with an executed control-change posture.",
        "Review validator-exit authority, permissionless enforcement, pause controls, request limits, and dependency behavior under withdrawal stress.",
        "Do not infer from activation or cited audits that the mechanism is safe or appropriate without separate deployed-state verification."
      ],
      "followUpOn": null,
      "previousInterpretation": "Prior history treated the triggerable-withdrawals framework as approved design awaiting on-chain activation.",
      "supersedesId": null
    },
    {
      "id": "event-event-draft-eb18ccdf4a6d4ab638a38f9a",
      "stableKey": "lido:v3:design-implementation-approval-2025-09",
      "version": 1,
      "eventDate": "2025-09-29",
      "publishedAt": "2026-08-22T14:05:53.241Z",
      "title": "Lido approves the V3 design and implementation proposal",
      "category": "upgrade_migration",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Lido V3 — Design & Implementation Proposal",
          "authority": "Lido DAO via Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x01cd474645cc7c3ddf68314d475d421ef833499297f508fee5f7411fafff3954",
          "documentType": "governance_vote",
          "publishedOn": "2025-09-22"
        }
      ],
      "whatHappened": "Lido tokenholders approved advancing the V3 architecture, including stVaults, phased minting caps, reserve requirements, rate limits, and pause controls.",
      "whatChanged": "The DAO authorized contributors to finalize audits and testing and prepare an on-chain mainnet execution vote for a major new staking-vault architecture.",
      "whatDidNotChange": "V3 was not executed on mainnet by this vote; the existing Core Pool path remained unchanged and available.",
      "confirmedFacts": [
        "The Snapshot vote closed on September 29, 2025 with support and no recorded opposing voting power.",
        "The approved design introduces opt-in stVaults while retaining the existing Core Pool path.",
        "The design proposed phased stVault minting caps and additional reserve, rate-limit, and pause controls.",
        "A separate on-chain vote remained necessary for mainnet execution."
      ],
      "unresolved": [
        "Final audit findings and audit-driven code changes were not yet known.",
        "The final deployment payload, execution date, and live vault parameters remained pending.",
        "The practical cross-impact of stVault slashing or bad debt on stETH holders required further diligence."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido memo's control, slashing, reserve, pause, and withdrawal analysis before any mainnet execution.",
        "Track the eventual on-chain payload and confirm whether Core Pool users inherit any stVault loss or liquidity path.",
        "Do not treat design approval or completed audits as evidence that V3 is safe or operative."
      ],
      "followUpOn": "2025-10-15",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-fa8b98737a92550079833614",
      "stableKey": "lido:stvaults-committee:approval-2025-09",
      "version": 1,
      "eventDate": "2025-09-29",
      "publishedAt": "2026-08-22T14:05:53.241Z",
      "title": "Lido approves the stVaults Committee and delegated parameter authority",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Establish the stVaults Committee",
          "authority": "Lido DAO via Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x0e8b53944051321d2cedf8881b546427bc6a22c9fe16f7d150af62fd837ff7da",
          "documentType": "governance_vote",
          "publishedOn": "2025-09-22"
        }
      ],
      "whatHappened": "Lido approved a 3-of-5 stVaults Committee intended to configure reserve ratios, operator tiers, DAO fees, and certain bad-debt compensation decisions through Easy Track.",
      "whatChanged": "The DAO approved a delegated control body and defined its intended authority over material stVault economic and risk parameters.",
      "whatDidNotChange": "The committee's stVault authority was not yet operative because the V3 system and enabling on-chain actions had not been executed.",
      "confirmedFacts": [
        "The approved committee address was 0x18A1065c81b0Cc356F1b1C843ddd5E14e4AefffF.",
        "The approved signing threshold was 3-of-5.",
        "The mandate included reserve ratios, tier grids, DAO fees, and complex bad-debt compensation decisions.",
        "Proposed committee actions were subject to Easy Track and tokenholder objection."
      ],
      "unresolved": [
        "The final on-chain permissions and Easy Track factories had not yet been executed.",
        "The limits on discretion in complex slashing and bad-debt cases required reconciliation to deployed code.",
        "Committee monitoring, conflict management, and replacement performance remained untested."
      ],
      "advisorDiligenceImplications": [
        "Add the committee multisig and Easy Track objection path to Lido's control map before V3 execution.",
        "Verify that deployed permissions match the approved mandate and cannot bypass DAO review.",
        "Review how committee-directed reserve and bad-debt decisions could affect stETH liquidity or loss allocation."
      ],
      "followUpOn": "2025-10-15",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-d1c7980d603ab57b7abbeb9f",
      "stableKey": "fassets:fxrp-mainnet-launch-2025-09-24",
      "version": 1,
      "eventDate": "2025-09-24",
      "publishedAt": "2026-08-22T14:05:53.241Z",
      "title": "Flare launches FAssets on mainnet with FXRP",
      "category": "launch_access",
      "posture": "launched",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "fassets",
          "name": "FAssets (Flare Network)"
        }
      ],
      "primaryDocuments": [
        {
          "title": "FAssets are Live: XRP Meets DeFi on Flare",
          "authority": "Flare Network",
          "url": "https://flare.network/news/fassets-fxrp-is-live-on-mainnet",
          "documentType": "official_launch_notice",
          "publishedOn": "2025-09-24"
        }
      ],
      "whatHappened": "Flare launched FAssets on mainnet with FXRP v1.2, allowing XRP to be represented and used across Flare DeFi.",
      "whatChanged": "The FAssets design moved from development into live operation for one supported underlying asset, FXRP.",
      "whatDidNotChange": "The notice did not establish that FBTC, DOGE, LTC, or a diversified set of FAssets was live, and launch did not establish suitability or approval.",
      "confirmedFacts": [
        "FAssets went live on Flare mainnet on September 24, 2025.",
        "The initial live FAsset was FXRP v1.2.",
        "The official notice described minting FXRP from XRP for use in Flare DeFi."
      ],
      "unresolved": [
        "The launch notice did not by itself reconcile all agent, collateral, Core Vault, pause, multisig, redemption, and liquidation controls.",
        "The production status of FAssets other than FXRP remained unconfirmed."
      ],
      "advisorDiligenceImplications": [
        "Create or update the fassets diligence file and scope it honestly to the live FXRP product.",
        "Review the agent collateral model, Data Connector verification, Core Vault custody, pause authority, and stressed redemption path.",
        "Do not infer that the broader FAssets name represents multiple live underlying assets."
      ],
      "followUpOn": "2025-10-24",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-b494550703eb7ccc2813e8d0",
      "stableKey": "aave-v3:plasma:v3.5-activation-2025-09",
      "version": 1,
      "eventDate": "2025-09-22",
      "publishedAt": "2026-08-22T14:05:53.241Z",
      "title": "Aave executes the V3.5 Plasma market activation",
      "category": "launch_access",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Aave V3.5 Plasma Activation",
          "authority": "Aave Governance v3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=379",
          "documentType": "onchain_governance_record",
          "publishedOn": "2025-09-18"
        }
      ],
      "whatHappened": "Aave governance executed the initial Plasma V3.5 market activation and configured USDT0, USDe, sUSDe, XAUt0, weETH, and WETH reserves with bootstrap controls and caps.",
      "whatChanged": "A new Aave deployment became operative on Plasma, expanding the protocol's chain, collateral, oracle, guardian, and cross-chain governance perimeter.",
      "whatDidNotChange": "XPL was not included in the initial activation, and the launch did not make the Plasma market or its assets approved for Ketju clients.",
      "confirmedFacts": [
        "Aave governance proposal 379 executed on September 22, 2025.",
        "The execution sent payload 1 to Plasma chain 9745.",
        "The activation included USDT0, USDe, sUSDe, XAUt0, weETH, and WETH.",
        "The proposal assigned bootstrap administrative roles and authorized later increases to pre-approved cap ceilings."
      ],
      "unresolved": [
        "The timing and amount of any later guardian cap increases required separate on-chain verification.",
        "Production oracle, bridge, liquidity, liquidation, and withdrawal performance remained untested at launch.",
        "XPL onboarding remained separate and pending."
      ],
      "advisorDiligenceImplications": [
        "Open a distinct Plasma deployment review rather than extending approval from another Aave chain.",
        "Reconcile every reserve, oracle, cap, guardian, bridge, and payload-controller dependency before considering access.",
        "Monitor whether bootstrap authorities increased caps and whether those changes stayed within the approved ceilings."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-13de99f340121d6b4d58cd17",
      "stableKey": "aave-v3:x-layer:temp-check-approval-2025-09",
      "version": 1,
      "eventDate": "2025-09-21",
      "publishedAt": "2026-08-22T14:05:53.241Z",
      "title": "Aave advances the proposed X Layer deployment to ARFC review",
      "category": "governance",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[TEMP CHECK] Deploy Aave v3 on X Layer",
          "authority": "Aave DAO via Snapshot",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0xdcf5f6a05adafd1f06b1576e5aeb6b8ab4ac77428998bef2f6f0c107dfe2ad57",
          "documentType": "governance_vote",
          "publishedOn": "2025-09-17"
        }
      ],
      "whatHappened": "Aave tokenholders approved a temperature check to continue evaluating an Aave v3 deployment on X Layer.",
      "whatChanged": "The deployment concept advanced into the formal ARFC diligence stage, adding X Layer to Aave's active research perimeter.",
      "whatDidNotChange": "No Aave contracts were deployed, no market was activated, and no assets or risk parameters were approved by this vote.",
      "confirmedFacts": [
        "The official Aave Snapshot vote closed on September 21, 2025.",
        "The proposal received overwhelming support with only minimal opposing voting power.",
        "The approved next step was ARFC review, followed by later governance stages if supported."
      ],
      "unresolved": [
        "X Layer's final architecture, launch status, bridge and oracle dependencies, market assets, parameters, and administrative controls were not specified.",
        "No final deployment payload or execution date existed at this stage."
      ],
      "advisorDiligenceImplications": [
        "Monitor the ARFC stage for a complete chain, bridge, oracle, guardian, and asset-control assessment.",
        "Do not extend existing Aave approval to X Layer without a chain-specific memo review.",
        "Treat the vote as research-perimeter expansion, not evidence of a live or approved client venue."
      ],
      "followUpOn": "2025-10-15",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-6be900241b3eb0dc814aaa42",
      "stableKey": "aave-v3:ethereum-core:pt-susde-usde-nov2025-cap-increase",
      "version": 1,
      "eventDate": "2025-09-17",
      "publishedAt": "2026-08-22T14:05:53.241Z",
      "title": "Aave executes billion-dollar November PT supply-cap increases",
      "category": "economic_change",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Raise sUSDe and USDe November expiry PT token caps on Aave V3 Core Instance",
          "authority": "Aave Governance v3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=376",
          "documentType": "onchain_governance_record",
          "publishedOn": "2025-09-13"
        }
      ],
      "whatHappened": "Aave governance executed increases to the Ethereum Core supply caps for PT-sUSDe-27NOV2025 and PT-USDe-27NOV2025.",
      "whatChanged": "The PT-sUSDe November cap increased to $1.2 billion and the PT-USDe November cap increased to $1 billion, materially expanding permitted exposure to dated Pendle principal tokens.",
      "whatDidNotChange": "The payload did not onboard new token contracts, change their maturity dates, or establish that the higher caps would be fully utilized.",
      "confirmedFacts": [
        "Aave governance proposal 376 executed on September 17, 2025.",
        "The execution sent payload 341 to Ethereum.",
        "The approved PT-sUSDe-27NOV2025 supply cap was $1.2 billion.",
        "The approved PT-USDe-27NOV2025 supply cap was $1 billion."
      ],
      "unresolved": [
        "Actual utilization after execution and the concentration of rollover deposits required monitoring.",
        "The event record did not establish stressed liquidity at maturity or the exit capacity of the underlying Pendle markets."
      ],
      "advisorDiligenceImplications": [
        "Review the Aave memo's exposure to dated, wrapped principal tokens and maturity-driven liquidity concentration.",
        "Confirm whether any approved or client-held Aave market inherited these collateral paths.",
        "Monitor cap utilization, oracle behavior, and exit liquidity approaching the November maturity."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-87f417cb8d9c683fac57617e",
      "stableKey": "aave-v3:scroll:reserve-factor-50pct-2025-09",
      "version": 1,
      "eventDate": "2025-09-16",
      "publishedAt": "2026-08-22T14:05:53.241Z",
      "title": "Aave executes 50% reserve factors across its Scroll market",
      "category": "economic_change",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Risk Parameter Adjustments for Aave V3 Scroll Instance",
          "authority": "Aave Governance v3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=374",
          "documentType": "onchain_governance_record",
          "publishedOn": "2025-09-12"
        }
      ],
      "whatHappened": "Aave governance executed a 50% reserve factor for WETH, weETH, wstETH, USDC, and SCR on the Scroll instance in response to reported Scroll governance instability.",
      "whatChanged": "A larger share of borrower interest began accruing to protocol reserves rather than suppliers across all listed Scroll assets.",
      "whatDidNotChange": "This payload did not itself change supply caps, borrow caps, collateral factors, liquidation thresholds, or the Scroll chain's governance.",
      "confirmedFacts": [
        "Aave governance proposal 374 executed on September 16, 2025.",
        "The execution sent payload 46 to Scroll.",
        "The reserve factor became 50% for WETH, weETH, wstETH, USDC, and SCR."
      ],
      "unresolved": [
        "Separate risk-steward changes referenced by the proposal were not established by this payload record.",
        "The duration of the conservative settings and the resolution of the cited Scroll governance instability remained open."
      ],
      "advisorDiligenceImplications": [
        "Review supplier-yield assumptions for any Aave Scroll exposure.",
        "Keep the Scroll deployment distinct from approved Aave markets on other chains.",
        "Track separate cap changes and any later reversal of the 50% reserve factors."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-ad56de27d69b96909eafb80d",
      "stableKey": "aave-v3:linea:rseth-supply-cap-70000-2025-09",
      "version": 1,
      "eventDate": "2025-09-15",
      "publishedAt": "2026-08-22T14:05:53.241Z",
      "title": "Aave raises the Linea wrsETH supply cap to 70,000",
      "category": "economic_change",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Increase rsETH Supply Cap on Aave V3 Linea Instance",
          "authority": "Aave Governance v3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=372",
          "documentType": "onchain_governance_record",
          "publishedOn": "2025-09-11"
        }
      ],
      "whatHappened": "Aave governance executed an increase in the Linea wrsETH supply cap from 6,400 to 70,000.",
      "whatChanged": "The maximum permitted wrsETH supply on the Linea Aave market increased by more than tenfold, materially expanding the market's possible liquid-restaking exposure.",
      "whatDidNotChange": "The payload did not change wrsETH's oracle, liquidation thresholds, loan-to-value setting, borrowability, or underlying bridge and wrapping dependencies.",
      "confirmedFacts": [
        "Aave governance proposal 372 executed on September 15, 2025.",
        "The execution sent payload 13 to Linea.",
        "The wrsETH supply cap increased from 6,400 to 70,000."
      ],
      "unresolved": [
        "Actual cap utilization and market liquidity after execution required monitoring.",
        "The event record did not establish stressed exit liquidity for wrsETH or its underlying restaking and bridge dependencies."
      ],
      "advisorDiligenceImplications": [
        "Review the Aave memo's Linea-specific liquid-restaking and wrap-depth exposure.",
        "Confirm whether any approved or client-held market could inherit losses from the expanded wrsETH collateral path.",
        "Monitor cap utilization, oracle deviations, liquidation liquidity, and bridge dependencies."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-b538659b35f10e3ec2dc5c53",
      "stableKey": "ondo-global-markets:ethereum:launch-2025-09-03",
      "version": 1,
      "eventDate": "2025-09-03",
      "publishedAt": "2026-08-22T14:05:53.241Z",
      "title": "Ondo launches more than 100 tokenized U.S. securities on Ethereum",
      "category": "launch_access",
      "posture": "launched",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "product",
          "id": "ondo-global-markets",
          "name": "Ondo Global Markets (Ondo Stocks)"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Ondo Stocks is Now Live: The Dawn of Wall Street 2.0",
          "authority": "Ondo Finance",
          "url": "https://ondo.finance/blog/global-markets-is-live",
          "documentType": "official_launch_notice",
          "publishedOn": "2025-09-03"
        }
      ],
      "whatHappened": "Ondo launched tokenized total-return exposure to more than 100 U.S. stocks and ETFs on Ethereum, with minting and redemption tied to underlying-market liquidity.",
      "whatChanged": "A large, transferable tokenized-securities product became live and usable in DeFi, creating a new tokenized-RWA diligence object.",
      "whatDidNotChange": "The launch did not make the product available to U.S. persons, and the tokens did not confer direct ownership of the referenced stocks or ETFs.",
      "confirmedFacts": [
        "The product launched on Ethereum on September 3, 2025.",
        "Ondo described more than 100 tokenized stocks and ETFs as live.",
        "The official notice limited access to eligible non-U.S. investors.",
        "The tokens track total returns and are not themselves stocks or ETFs."
      ],
      "unresolved": [
        "The launch notice alone did not resolve issuer-discretion, transfer-control, insolvency, or U.S.-advisor implementation questions.",
        "Independent reserve attestations and stressed redemption performance remained to be evaluated."
      ],
      "advisorDiligenceImplications": [
        "Open or update the ondo-global-markets diligence file because the launch materially expanded the tokenized-equities perimeter.",
        "Preserve the U.S.-person exclusion as a binding access constraint rather than treating on-chain transferability as client eligibility.",
        "Review the derivative claim, custody chain, transfer controls, attestations, and redemption mechanics before any approval consideration."
      ],
      "followUpOn": "2025-10-03",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-481c1216c8e2f804f6559c75",
      "stableKey": "aave-v3:ethereum-core:pt-susde-27nov2025-onboarding",
      "version": 1,
      "eventDate": "2025-08-30",
      "publishedAt": "2026-08-22T14:05:43.901Z",
      "title": "Aave opens final governance for November PT-sUSDe collateral",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[Direct to AIP] Onboard sUSDe November expiry PT tokens on Aave V3 Core Instance",
          "authority": "Aave DAO",
          "url": "https://governance.aave.com/t/direct-to-aip-onboard-susde-november-expiry-pt-tokens-on-aave-v3-core-instance/22894",
          "documentType": "official_governance_forum",
          "publishedOn": "2025-08-12"
        },
        {
          "title": "Proposal 365",
          "authority": "Aave Governance",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=365",
          "documentType": "onchain_governance_record",
          "publishedOn": "2025-08-30"
        }
      ],
      "whatHappened": "Aave advanced PT-sUSDe-27NOV2025 to an on-chain governance proposal for the Ethereum Core instance.",
      "whatChanged": "If executed, the proposal would add the dated PT as collateral with a 75 million supply cap, stablecoin and USDe e-modes, and LTV, liquidation-threshold, and bonus values managed by a risk oracle.",
      "whatDidNotChange": "The proposal record alone does not establish execution. Existing collateral parameters were not shown to have changed on August 30.",
      "confirmedFacts": [
        "The official forum identifies PT-sUSDe-27NOV2025 as the proposed collateral asset.",
        "The proposed non-e-mode LTV and liquidation threshold are 0.05% and 0.1%.",
        "The proposal defines stablecoin and USDe e-modes whose collateral parameters are subject to the Edge Risk Oracle.",
        "The candidate links the proposal to Aave Governance proposal 365."
      ],
      "unresolved": [
        "Final vote outcome and execution timing were not established from an operative receipt reviewed for this candidate.",
        "Actual post-execution caps, oracle state, and e-mode membership require on-chain confirmation."
      ],
      "advisorDiligenceImplications": [
        "Monitor whether the dated PT becomes live collateral and verify the final oracle constraints before treating the market as available.",
        "Review the Aave memo's exposure to Ethena, Pendle maturity rollover, and automated collateral-parameter authority.",
        "Do not infer approval of PT-sUSDe exposure from the existence of the governance proposal."
      ],
      "followUpOn": "2025-09-05",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-55ec3494783f10accf544836",
      "stableKey": "aave-v3:base:tbtc-onboarding-arfc-2025-08",
      "version": 1,
      "eventDate": "2025-08-25",
      "publishedAt": "2026-08-22T14:05:43.901Z",
      "title": "Aave approves tBTC-on-Base onboarding at the ARFC stage",
      "category": "governance",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Onboard tBTC to Aave v3 on Base",
          "authority": "Aave DAO",
          "url": "https://governance.aave.com/t/arfc-onboard-tbtc-to-aave-v3-on-base/22226",
          "documentType": "official_governance_forum",
          "publishedOn": "2025-05-30"
        }
      ],
      "whatHappened": "Aave's ARFC vote approved advancing tBTC onboarding for the Base v3 instance.",
      "whatChanged": "The proposal advanced to final AIP preparation with recommended collateral, borrowing, cap, liquidation, and BTC/USD oracle settings.",
      "whatDidNotChange": "ARFC approval did not add the reserve or make tBTC available on Aave Base; final AIP approval and execution remained necessary.",
      "confirmedFacts": [
        "The ARFC passed on August 25, 2025, with quorum and YAE as the winning option.",
        "The proposed Base tBTC contract is 0x236aa50979D5f3De3Bd1Eeb40E81137F22ab794b.",
        "Recommended parameters include a 130 tBTC supply cap, 13 tBTC borrow cap, 73% LTV, and 78% liquidation threshold.",
        "The next stated step was publication of an AIP."
      ],
      "unresolved": [
        "Final AIP result and execution were not established for this event.",
        "Final oracle configuration and live reserve parameters require post-execution reconciliation."
      ],
      "advisorDiligenceImplications": [
        "Monitor the final AIP and verify live parameters before considering tBTC-on-Base exposure.",
        "Review Threshold minting, Wormhole-related Base components, secondary liquidity, and BTC/USD pricing dependencies.",
        "Do not infer that ARFC approval constitutes product approval for clients."
      ],
      "followUpOn": "2025-09-01",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-7a6b777959dcc6edec0edf6d",
      "stableKey": "aave-v3:ethereum-core:xaut-onboarding-arfc-2025-08",
      "version": 1,
      "eventDate": "2025-08-25",
      "publishedAt": "2026-08-22T14:05:43.901Z",
      "title": "Aave approves XAUt collateral onboarding at the ARFC stage",
      "category": "governance",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Add XAUt to Aave v3 Core Instance",
          "authority": "Aave DAO",
          "url": "https://governance.aave.com/t/arfc-add-xaut-to-aave-v3-core-instance/22385",
          "documentType": "official_governance_forum",
          "publishedOn": "2025-06-19"
        }
      ],
      "whatHappened": "Aave's ARFC vote approved advancing XAUt onboarding for the Ethereum Core instance.",
      "whatChanged": "The proposal advanced to final AIP preparation with XAUt as isolated, non-borrowable collateral, a 5,000-token supply cap, and a $3 million debt ceiling.",
      "whatDidNotChange": "ARFC approval did not add XAUt to the live market. Final AIP approval, execution, and live oracle configuration remained outstanding.",
      "confirmedFacts": [
        "The ARFC passed on August 25, 2025, with quorum and YAE as the winning option.",
        "Published parameters include 70% LTV, 75% liquidation threshold, and a 6% liquidation penalty.",
        "The proposal uses isolation mode and a $3 million debt ceiling.",
        "The stated next step was publication of an AIP."
      ],
      "unresolved": [
        "Final AIP result, execution date, and live configuration were not established.",
        "Weekend gold-price behavior, issuer controls, reserve evidence, redemption eligibility, and concentrated liquidity remain material diligence issues."
      ],
      "advisorDiligenceImplications": [
        "Monitor the final AIP and verify the oracle and isolation settings before treating the reserve as live.",
        "Review the Aave memo for tokenized-gold issuer, vault, blacklist, redemption, and weekend-pricing dependencies.",
        "Do not infer client suitability or approval from ARFC passage."
      ],
      "followUpOn": "2025-09-01",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-c1b1464981ac19b615672873",
      "stableKey": "aave-v3:arbitrum:tbtc-onboarding-aip-2025-08",
      "version": 1,
      "eventDate": "2025-08-20",
      "publishedAt": "2026-08-22T14:05:43.901Z",
      "title": "Aave opens final governance for tBTC collateral on Arbitrum",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Onboard tBTC to Aave v3 on Arbitrum",
          "authority": "Aave DAO",
          "url": "https://governance.aave.com/t/arfc-onboard-tbtc-to-aave-v3-on-arbitrum/19756",
          "documentType": "official_governance_forum",
          "publishedOn": "2024-11-11"
        },
        {
          "title": "Proposal 360",
          "authority": "Aave Governance",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=360",
          "documentType": "onchain_governance_record",
          "publishedOn": "2025-08-20"
        }
      ],
      "whatHappened": "Aave opened an on-chain proposal to add tBTC as collateral on its Arbitrum v3 instance.",
      "whatChanged": "If executed, tBTC would become non-borrowable collateral with a 50 tBTC supply cap, 73% LTV, 78% liquidation threshold, and Chainlink BTC/USD pricing.",
      "whatDidNotChange": "The proposal record does not by itself confirm execution or establish that tBTC was available as collateral on August 20.",
      "confirmedFacts": [
        "The proposed Arbitrum tBTC contract is 0x6c84a8f1c29108f47a79964b5fe888d4f4d0de40.",
        "The proposed supply cap is 50 tBTC and the borrow cap is 25, while borrowing is described as disabled in the operative configuration.",
        "The proposed LTV and liquidation threshold are 73% and 78%.",
        "The candidate links Aave Governance proposal 360."
      ],
      "unresolved": [
        "Final vote result and execution timing require operative on-chain confirmation.",
        "The final live reserve configuration and oracle address must be reconciled after execution."
      ],
      "advisorDiligenceImplications": [
        "Monitor final execution before treating tBTC on Arbitrum as an available Aave collateral market.",
        "Review wrapped-Bitcoin minting, bridge, oracle, liquidity, and liquidation dependencies introduced by the listing.",
        "Confirm that the final borrow-enabled flag and borrow cap are internally consistent."
      ],
      "followUpOn": "2025-08-27",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-329c9a6314d58f1752bef38f",
      "stableKey": "aave-v3:linea:rseth-onboarding-aip-2025-08",
      "version": 1,
      "eventDate": "2025-08-19",
      "publishedAt": "2026-08-22T14:05:43.901Z",
      "title": "Aave opens final governance for wrsETH collateral on Linea",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[Direct to AIP] Onboard rsETH to Aave V3 Linea Instance",
          "authority": "Aave DAO",
          "url": "https://governance.aave.com/t/direct-to-aip-onboard-rseth-to-aave-v3-linea-instance/22172",
          "documentType": "official_governance_forum",
          "publishedOn": "2025-05-26"
        },
        {
          "title": "Onboard rsETH to Aave V3 Linea Instance — Proposal 358",
          "authority": "Aave Governance",
          "url": "https://vote.onaave.com/proposal/?ipfsHash=0xe2d5e82594c356931465f14b6d7110e1a0b38a0536090f21312b73243139bd49&proposalId=358",
          "documentType": "onchain_governance_record",
          "publishedOn": "2025-08-19"
        }
      ],
      "whatHappened": "Aave opened on-chain governance to add wrsETH collateral to its Linea v3 instance.",
      "whatChanged": "If executed, wrsETH would become non-borrowable collateral with a 400-token supply cap, 70% LTV, 73% liquidation threshold, a correlated WETH e-mode, and a capped exchange-rate oracle.",
      "whatDidNotChange": "The reviewed evidence does not establish execution or a live reserve as of August 19.",
      "confirmedFacts": [
        "The proposed asset is wrapped rsETH on Linea.",
        "The proposal sets a 400 wrsETH supply cap and disables borrowing.",
        "The proposed base LTV and liquidation threshold are 70% and 73%.",
        "The proposed oracle combines a wrsETH/rsETH ratio provider with an ETH/USD feed and CAPO constraints."
      ],
      "unresolved": [
        "Final vote outcome and execution timing require on-chain confirmation.",
        "The official forum identified limited Linea liquidity and bridge, pricing, and multisig dependencies that require ongoing review."
      ],
      "advisorDiligenceImplications": [
        "Do not treat wrsETH on Linea as available until execution and live configuration are verified.",
        "Review the additional LayerZero bridge, wrapper ownership, exchange-rate feed, and Linea liquidity dependencies.",
        "Check whether the final e-mode and supply cap remain consistent with the published risk analysis."
      ],
      "followUpOn": "2025-08-26",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-059e9c1f02a71bb5235bf2eb",
      "stableKey": "aave-v3:ethereum-core:lseth-onboarding-temp-check-2025-08",
      "version": 1,
      "eventDate": "2025-08-18",
      "publishedAt": "2026-08-22T14:05:43.901Z",
      "title": "Aave advances LsETH collateral onboarding to ARFC review",
      "category": "governance",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[TEMP CHECK] Onboard LsETH to Aave V3 Core Instance",
          "authority": "Aave DAO",
          "url": "https://governance.aave.com/t/temp-check-onboard-lseth-to-aave-v3-core-instance/22832",
          "documentType": "official_governance_forum",
          "publishedOn": "2025-08-06"
        }
      ],
      "whatHappened": "Aave's TEMP CHECK approved advancing Liquid Collective's LsETH for potential collateral onboarding on Ethereum Core.",
      "whatChanged": "LsETH moved to the ARFC diligence and parameter-setting stage.",
      "whatDidNotChange": "No collateral reserve was added. Risk parameters, caps, oracle configuration, and final governance approval remained outstanding.",
      "confirmedFacts": [
        "The TEMP CHECK passed on August 18, 2025, with quorum and YAE as the winning option.",
        "The proposal targets Aave v3 Ethereum Core.",
        "The proposed LsETH contract is 0x8c1bed5b9a0928467c9b1341da1d7bd5e10b6549.",
        "The official post said initial risk parameters would be provided during ARFC review."
      ],
      "unresolved": [
        "Secondary liquidity, holder concentration, redemption timing, platform controls, and final Aave risk parameters remained unresolved.",
        "The claimed deposit commitments were not independently evidenced in the primary governance post."
      ],
      "advisorDiligenceImplications": [
        "Monitor the ARFC without treating LsETH as approved Aave collateral.",
        "Require analysis of Liquid Collective's permissioned mint and redemption paths, validator and platform dependencies, liquidity, oracle design, and concentration.",
        "Verify any deposit commitments before using them in liquidity assumptions."
      ],
      "followUpOn": "2025-09-03",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-e703d642822c121b234b426e",
      "stableKey": "aave-v3:ethereum-core:pt-tusde-dec2025-temp-check",
      "version": 1,
      "eventDate": "2025-08-18",
      "publishedAt": "2026-08-22T14:05:43.901Z",
      "title": "Aave advances December PT-tUSDe onboarding to ARFC review",
      "category": "governance",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[TEMP CHECK] Onboard tUSDe December expiry PT tokens on Aave V3 Core Instance",
          "authority": "Aave DAO",
          "url": "https://governance.aave.com/t/temp-check-onboard-tusde-december-expiry-pt-tokens-on-aave-v3-core-instance/22850",
          "documentType": "official_governance_forum",
          "publishedOn": "2025-08-08"
        }
      ],
      "whatHappened": "Aave's TEMP CHECK approved advancing a December-expiry PT-tUSDe collateral proposal to the ARFC stage.",
      "whatChanged": "The concept moved from initial discussion to formal risk and parameter review.",
      "whatDidNotChange": "No PT contract, risk parameters, oracle, cap, or live collateral reserve was approved or deployed at the TEMP CHECK stage.",
      "confirmedFacts": [
        "The TEMP CHECK passed on August 18, 2025, with quorum and YAE as the winning option.",
        "The proposal targets a December-expiry tUSDe principal token on Aave v3 Ethereum Core.",
        "The official post said the next step was an ARFC.",
        "At the TEMP CHECK stage, the contract address and risk parameters were not final."
      ],
      "unresolved": [
        "The underlying tUSDe and Terminal dependencies required service-provider analysis.",
        "Final contract address, maturity date, liquidity, oracle, caps, e-mode parameters, and execution remained unresolved."
      ],
      "advisorDiligenceImplications": [
        "Monitor the ARFC but do not treat PT-tUSDe as an available or approved Aave collateral.",
        "Require full look-through to tUSDe, Terminal, Midas, Ethena, Pendle, redemption, pause, and oracle dependencies.",
        "Assess maturity and exit liquidity before any future memo inclusion."
      ],
      "followUpOn": "2025-09-01",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-21f9f7e6f84ec23526445c40",
      "stableKey": "aave-v3:ethereum-core:ezeth-onboarding-aip-2025-08",
      "version": 1,
      "eventDate": "2025-08-12",
      "publishedAt": "2026-08-22T14:05:43.901Z",
      "title": "Aave opens final governance for ezETH collateral on Ethereum Core",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[Direct-to-AIP] Add ezETH to Aave v3 Core Instance",
          "authority": "Aave DAO",
          "url": "https://governance.aave.com/t/direct-to-aip-add-ezeth-to-aave-v3-core-instance/22732",
          "documentType": "official_governance_forum",
          "publishedOn": "2025-07-29"
        },
        {
          "title": "Proposal 355",
          "authority": "Aave Governance",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=355",
          "documentType": "onchain_governance_record",
          "publishedOn": "2025-08-12"
        }
      ],
      "whatHappened": "Aave opened an on-chain proposal to add ezETH as collateral to the Ethereum Core instance.",
      "whatChanged": "If executed, ezETH would become non-borrowable collateral with a 50,000-token supply cap and separate wstETH and stablecoin e-modes, including high correlated-mode leverage parameters.",
      "whatDidNotChange": "The reviewed record does not itself confirm execution or establish that ezETH was live in Ethereum Core on August 12.",
      "confirmedFacts": [
        "The proposed ezETH contract is 0xbf5495efe5db9ce00f80364c8b423567e58d2110.",
        "The proposed supply cap is 50,000 ezETH and borrowing is disabled.",
        "The ezETH/wstETH e-mode proposes 93% LTV and a 95% liquidation threshold.",
        "The ezETH/stablecoin e-mode proposes 75% LTV and a 78% liquidation threshold."
      ],
      "unresolved": [
        "Final vote outcome and execution timing require operative on-chain confirmation.",
        "Final live oracle, e-mode, cap, and reserve configuration require reconciliation after execution.",
        "Liquidity concentration and Renzo withdrawal-buffer availability remain material diligence items."
      ],
      "advisorDiligenceImplications": [
        "Monitor final execution before treating ezETH as Ethereum Core collateral.",
        "Review the leverage, depeg, liquidation-liquidity, Renzo administration, timelock, and withdrawal dependencies introduced by the listing.",
        "Do not infer safety or client approval from the proposed risk parameters."
      ],
      "followUpOn": "2025-08-19",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-cf6593154cb5b48329279611",
      "stableKey": "coinbase-bridge:base-mainnet-block-production-halt:2025-08-05",
      "version": 1,
      "eventDate": "2025-08-05",
      "publishedAt": "2026-08-22T14:05:43.901Z",
      "title": "Base recovers from a 33-minute mainnet block-production halt",
      "category": "market_stress",
      "posture": "postmortem",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "coinbase-bridge",
          "name": "Base canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Base Mainnet | Unsafe head delay",
          "authority": "Base",
          "url": "https://status.base.org/incidents/kdq3t8s13gfs",
          "documentType": "official_status_postmortem",
          "publishedOn": "2025-08-05"
        }
      ],
      "whatHappened": "Base's active sequencer fell behind, and an automated Conductor handoff selected a sequencer that was still being provisioned and could not produce blocks. Mainnet block production stopped for 33 minutes.",
      "whatChanged": "The incident established a realized sequencer failover and provisioning failure capable of interrupting Base mainnet block production, deposits, and withdrawals. Base said it would change cluster admission behavior and testing.",
      "whatDidNotChange": "Base reported full network recovery by 06:40 UTC. The postmortem did not report a bridge-contract exploit, asset loss, or chain reorganization.",
      "confirmedFacts": [
        "Base mainnet block production stopped at approximately 06:07 UTC on August 5, 2025.",
        "The status incident identified deposits, withdrawals, block production, and Flashblocks as affected components.",
        "The team manually paused Conductor and transferred leadership to a healthy sequencer.",
        "Base reported full recovery after 33 minutes."
      ],
      "unresolved": [
        "The status postmortem states planned infrastructure and testing improvements but does not prove when each corrective action was deployed.",
        "The receipt does not quantify transaction-level deposit or withdrawal delays after block production resumed."
      ],
      "advisorDiligenceImplications": [
        "Review the coinbase-bridge memo's availability and withdrawal assumptions against a realized sequencer failover outage.",
        "Record that canonical bridge access can become temporarily unavailable during a Base sequencing halt even without a bridge-contract exploit.",
        "Verify whether current operational controls now prevent an unready sequencer from becoming leader."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-10e860bc39c3742d82115ab0",
      "stableKey": "arbitrum-bridge:legacy-usdt-gateway:disable-approval-2025-07",
      "version": 1,
      "eventDate": "2025-07-31",
      "publishedAt": "2026-08-22T14:05:43.445Z",
      "title": "Arbitrum approves disabling its legacy USDT bridge",
      "category": "closure_deprecation",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "arbitrum-bridge",
          "name": "Arbitrum Bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[Constitutional] AIP: Disable Legacy Tether Bridge",
          "authority": "Arbitrum DAO Snapshot",
          "url": "https://snapshot.org/#/arbitrumfoundation.eth/proposal/0xd5a66f784523841511f7ffec4171b9c14404fdbf7c205086312084d19c95c193",
          "documentType": "official_governance_record",
          "publishedOn": "2025-07-23"
        }
      ],
      "whatHappened": "Arbitrum DAO voters approved a constitutional proposal to disable the legacy USDT gateway after migration of most cross-chain activity to USDT0.",
      "whatChanged": "If the approved action is executed, new calls routing legacy Ethereum USDT through the specified L1 gateway would revert, retiring that deposit path and requiring integrations to use another route.",
      "whatDidNotChange": "The Snapshot approval did not execute the DisableGatewayAction. It did not deprecate the canonical bridge for other assets or establish the final state of third-party integrations.",
      "confirmedFacts": [
        "The official vote ended on July 31, 2025 with approximately 159.4 million ARB voting for the proposal.",
        "The target is legacy Ethereum USDT at 0xdAC17F958D2ee523a2206206994597C13D831ec7.",
        "The proposal specifies DisableGatewayAction contract 0x8d3425f7039645223517F6F6e60Ef04C28f4188F.",
        "The stated legacy route has a seven-day withdrawal delay and can create refund problems for depositing smart contracts.",
        "The proposal states that transactions submitted after disablement would revert."
      ],
      "unresolved": [
        "The subsequent Tally vote and execution transaction.",
        "The exact effective block and final L1GatewayRouter mapping.",
        "Whether every wallet, exchange, and smart-contract integration migrated before execution.",
        "Treatment and exit paths for existing legacy bridged USDT balances."
      ],
      "advisorDiligenceImplications": [
        "Review the Arbitrum Bridge memo's supported-asset routes and integration assumptions before treating the legacy USDT path as unavailable.",
        "Verify on-chain execution and existing-balance withdrawal behavior; approval alone does not retire the gateway."
      ],
      "followUpOn": "2025-08-08",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-f1053e13bd411079d921f17a",
      "stableKey": "aave-v3:ethereum-core:pt-usde-25sep2025-onboarding",
      "version": 1,
      "eventDate": "2025-07-30",
      "publishedAt": "2026-08-22T14:05:43.445Z",
      "title": "Aave executes PT-USDe September collateral onboarding",
      "category": "economic_change",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Onboard USDe September expiry PT tokens on Aave V3 Core Instance",
          "authority": "Aave Governance",
          "url": "https://vote.onaave.com/proposal/?proposalId=346",
          "documentType": "executed_onchain_governance_proposal",
          "publishedOn": "2025-07-25"
        }
      ],
      "whatHappened": "Aave governance executed proposal 346, adding PT-USDe-25SEP2025 as collateral on Aave v3 Ethereum Core.",
      "whatChanged": "Ethereum Core gained a maturity-dated Pendle and Ethena collateral dependency with a 50 million supply cap, capped linear-discount pricing, two E-mode configurations, and an assigned emission administrator.",
      "whatDidNotChange": "The asset is not borrowable, its base configuration retains negligible LTV and liquidation threshold outside E-mode, and execution does not make the collateral independently Ketju-approved.",
      "confirmedFacts": [
        "The proposal finished execution on July 30, 2025.",
        "PT-USDe-25SEP2025 matures on September 25, 2025.",
        "The executed supply cap is 50,000,000 tokens.",
        "The reserve is collateral-enabled but not borrowable.",
        "The two configured E-modes use initial LTVs of 90.3% and 91.2%.",
        "The pricing configuration specifies a 9.65% discount rate and 29.10% maximum annual discount rate."
      ],
      "unresolved": [
        "Post-execution verification of reserve, oracle, E-mode, and emission-admin state.",
        "Liquidity and liquidation performance as the token approaches maturity.",
        "Operational rollover and exit handling for positions migrating from the July expiry.",
        "Effects of Ethena, Pendle, oracle, and maturity dependencies during market stress."
      ],
      "advisorDiligenceImplications": [
        "Review the Aave memo's collateral, oracle, E-mode, maturity, and rollover assumptions before recognizing exposure to the new reserve.",
        "Monitor post-execution liquidity and approaching maturity; execution and prior demand do not establish suitability."
      ],
      "followUpOn": "2025-08-06",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-4a64b330357ec526c1d723c7",
      "stableKey": "lido:csm-v2:final-rollout-approval-2025-07",
      "version": 1,
      "eventDate": "2025-07-28",
      "publishedAt": "2026-08-22T14:05:43.445Z",
      "title": "Lido approves the CSM v2 final rollout",
      "category": "upgrade_migration",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "CSM v2 Final Rollout",
          "authority": "Lido DAO Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0xc3f92bcdf8926cfa7528ca6a979c0fdce1e4d0cfaaa72dd6410a76a2e1e55766",
          "documentType": "official_governance_record",
          "publishedOn": "2025-07-21"
        }
      ],
      "whatHappened": "Lido tokenholders approved the final rollout plan for Community Staking Module v2.",
      "whatChanged": "The approval finalized a migration and operating framework with permissionless, Legacy Early Adopter, and Identified Community Staker operator types, EIP-7002 support, revised performance accounting, and committee reimbursement funding.",
      "whatDidNotChange": "CSM v2 was not deployed in July, existing operators were not yet migrated, and pending audits and later on-chain execution remained necessary.",
      "confirmedFacts": [
        "The Snapshot ended on July 28, 2025 with approximately 52.35 million LDO voting for and about 12 LDO against.",
        "The approved rollout defines three initial node-operator types.",
        "The design includes EIP-7002 support and an updated Performance Oracle.",
        "The Identified Community Stakers framework uses address-ownership proofs and published eligibility scoring.",
        "The proposal includes 10 stETH of committee funding for eligible reimbursement of incorrectly penalized operators."
      ],
      "unresolved": [
        "Final audit findings and remediation.",
        "The on-chain upgrade vote, execution date, and deployed contract state.",
        "Final operator classifications, bond curves, module allocation, and committee permissions.",
        "Effects on validator concentration, performance-oracle errors, penalties, reimbursements, and withdrawal behavior."
      ],
      "advisorDiligenceImplications": [
        "Supersede the May architecture-stage interpretation with final-rollout approval while retaining a non-operative posture.",
        "Review final code, audits, operator classifications, committee authority, performance accounting, and executed module limits before updating Lido suitability conclusions."
      ],
      "followUpOn": "2025-09-15",
      "previousInterpretation": "The May event established approval of the CSM v2 architecture and fee structure but not the final rollout plan, finalized operator framework, reimbursement authority, or production authorization.",
      "supersedesId": null
    },
    {
      "id": "event-event-draft-e249eff39a111589ca5d3630",
      "stableKey": "aave-v3:capo:risk-oracle-dynamic-calibration-approval-2025-07",
      "version": 1,
      "eventDate": "2025-07-26",
      "publishedAt": "2026-08-22T14:05:43.445Z",
      "title": "Aave approves dynamic CAPO calibration at the ARFC stage",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Dynamic Calibration of CAPO Parameters via Risk Oracles",
          "authority": "Aave DAO Snapshot",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0x66aa6904f140d56ada880f45c911994c5c6cc20109b55081f508ccdd6417066d",
          "documentType": "official_governance_record",
          "publishedOn": "2025-07-22"
        }
      ],
      "whatHappened": "Aave DAO voters approved an ARFC framework for Risk Oracles to update CAPO snapshotRatio and maxYearlyRatioGrowthPercent parameters.",
      "whatChanged": "The approved design would replace infrequent manual calibration with bounded off-chain recommendations and on-chain updates affecting the maximum recognized exchange-rate growth of yield-bearing collateral.",
      "whatDidNotChange": "No AIP or deployed Risk Oracle was established within July. Existing CAPO contracts, asset allowlists, and live parameters were not changed by the Snapshot alone.",
      "confirmedFacts": [
        "The Snapshot closed on July 26, 2025 with approximately 777,990 voting YAE and negligible opposition.",
        "The approved framework covers snapshotRatio and maxYearlyRatioGrowthPercent.",
        "The proposed snapshotRatio constraint is at most a 5% relative change every 14 days.",
        "The proposed annual-growth constraint is at most a 10% relative change every three days.",
        "The framework uses off-chain analysis to recommend bounded on-chain parameter updates."
      ],
      "unresolved": [
        "The final implementation, asset allowlist, contracts, and assigned roles.",
        "Whether later AIP constraints differ from the approved ARFC design.",
        "Failure and revocation handling for erroneous or compromised recommendations.",
        "Whether automated bounds remain sufficiently tight without incorrectly capping legitimate collateral appreciation."
      ],
      "advisorDiligenceImplications": [
        "Review the Aave memo's collateral-oracle and delegated-control assumptions before the design becomes operative.",
        "Verify the final AIP, allowlist, bounds, roles, and deployed state rather than inferring safety from ARFC approval."
      ],
      "followUpOn": "2025-08-11",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-a51fb08a9f741a82d541e2d3",
      "stableKey": "aave-v3:agrs:optimism-bnb-gnosis-polygon-activation-2025-07",
      "version": 1,
      "eventDate": "2025-07-24",
      "publishedAt": "2026-08-22T14:05:43.445Z",
      "title": "Aave proposes automated cap controls on four additional networks",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Caps AGRS activation on Optimism, BNB, Gnosis, Polygon",
          "authority": "Aave Governance Forum (BGD Labs)",
          "url": "https://governance.aave.com/t/technical-maintenance-proposals/15274/98",
          "documentType": "official_governance_proposal",
          "publishedOn": "2025-07-24"
        }
      ],
      "whatHappened": "BGD Labs proposed enabling Aave Generalised Risk Stewards for supply and borrow caps on Optimism, BNB, Gnosis, and Polygon.",
      "whatChanged": "If executed, whitelisted reserve caps on four additional deployments could be changed through off-chain Edge recommendations, RiskOracle contracts, injector automation, and newly assigned RISK_ADMIN roles.",
      "whatDidNotChange": "No execution was established within July. The stewards would remain limited to supply and borrow caps, whitelisted assets, and maximum 30% changes every three days.",
      "confirmedFacts": [
        "The proposal identifies Optimism, BNB, Gnosis, and Polygon as the new deployments.",
        "The automated authority is limited to supply and borrow caps.",
        "The proposed constraint is a maximum 30% increase or decrease every three days.",
        "Chainlink Automation would run the injectors except on Gnosis, where Gelato Automation is specified.",
        "The official proposal publishes the intended steward, injector, and RiskOracle addresses."
      ],
      "unresolved": [
        "The Aave governance outcome after July 31.",
        "The final execution payload and assigned RISK_ADMIN roles.",
        "Post-execution asset allowlists and automation funding.",
        "Failure handling for stale, erroneous, unavailable, or compromised off-chain recommendations."
      ],
      "advisorDiligenceImplications": [
        "Review the Aave memo's delegated risk-control map before treating the additional cap automation as operative.",
        "Verify final roles, allowlists, constraints, automation dependencies, and revocation paths after execution."
      ],
      "followUpOn": "2025-08-04",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-c5e045e0e34bfe2e9e02d7f7",
      "stableKey": "aave-v3:long-tail-assets:eurs-snx-lusd-deprecation-2025-07",
      "version": 1,
      "eventDate": "2025-07-22",
      "publishedAt": "2026-08-22T14:05:43.445Z",
      "title": "Aave executes long-tail reserve deprecations",
      "category": "closure_deprecation",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Deprecation of Long-tail Assets",
          "authority": "Aave Governance",
          "url": "https://vote.onaave.com/proposal/?ipfsHash=0xcb1dd7a51c7b81f3f1a5a4e4c1c01112777fa515738745c876938010c8b6be8b&proposalId=339",
          "documentType": "executed_onchain_governance_proposal",
          "publishedOn": "2025-07-17"
        }
      ],
      "whatHappened": "Aave governance executed proposal 339 to begin or continue deprecating EURS on Polygon, SNX on Ethereum Core, and LUSD on Arbitrum and Optimism.",
      "whatChanged": "The payload removed collateral capacity for EURS and SNX, eliminated their debt ceilings, increased borrower base rates, and raised reserve factors intended to encourage users to exit the affected reserves.",
      "whatDidNotChange": "The reserves were not removed, existing positions were not automatically closed, and execution does not establish that every supplier or borrower exited without loss or congestion.",
      "confirmedFacts": [
        "Proposal 339 executed on July 22, 2025.",
        "EURS Polygon LTV was set to 0%, its debt ceiling to zero, its base rate to 2%, and its reserve factor to 50%.",
        "SNX Ethereum Core LTV was set to 0%, its debt ceiling to zero, its base rate to 6%, and its reserve factor to 95%.",
        "LUSD base rates on Arbitrum and Optimism were raised to 2% and reserve factors to 50%.",
        "The stated rationale included contracted liquidity, limited demand, and changing risk profiles."
      ],
      "unresolved": [
        "Final Risk Steward cap reductions and their effective blocks.",
        "Remaining supplied and borrowed balances and the pace of user exits.",
        "Liquidation and repayment liquidity for affected borrowers.",
        "Whether any integration or client position retained exposure after deprecation began."
      ],
      "advisorDiligenceImplications": [
        "Review the Aave memo and any position inventory for exposure to the affected reserves, especially Ethereum Core SNX.",
        "Verify remaining balances, caps, liquidity, and exit conditions before treating deprecation as complete."
      ],
      "followUpOn": "2025-08-05",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-10e6378b72d30dba8a9ddea1",
      "stableKey": "aave-v3:ink-whitelabel:arfc-approval-2025-07",
      "version": 1,
      "eventDate": "2025-07-21",
      "publishedAt": "2026-08-22T14:05:43.445Z",
      "title": "Aave approves the Ink whitelabel deployment at ARFC",
      "category": "governance",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Deploy a Whitelabel Aave V3 Instance on Ink",
          "authority": "Aave DAO Snapshot",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0x4185135ca5693f3a7022372dc989ee432c1ca792cde020275f3dfb472a90d6f1",
          "documentType": "official_governance_record",
          "publishedOn": "2025-07-17"
        }
      ],
      "whatHappened": "Aave DAO voters approved an ARFC authorizing progression toward a whitelabel Aave v3 instance governed by the Ink Foundation.",
      "whatChanged": "The approved plan would license Aave code for a centrally governed lending deployment, provide initial Aave service-provider support, create DAO revenue sharing, and permit incentive funding.",
      "whatDidNotChange": "No Ink lending instance was confirmed live in July. The planned instance would not be governed by Aave DAO and would not be covered by Aave's Umbrella system.",
      "confirmedFacts": [
        "The Snapshot closed on July 21, 2025 with approximately 789,556 voting YAE and 1,579 NAY.",
        "The proposal specifies centralized governance by the Ink Foundation without an initial governance token.",
        "The Aave DAO revenue share must be at least the equivalent of a 5% reserve factor based on borrow volume.",
        "Initial Aave service-provider support is specified for six months.",
        "The proposal expressly excludes the whitelabel instance from DAO-operated Umbrella coverage."
      ],
      "unresolved": [
        "The final AIP, deployed contracts, governance transfer, and launch date.",
        "Final collateral, oracle, liquidation, pause, upgrade, and custody controls.",
        "The commercial support arrangement after the initial six months.",
        "Whether incentives create a genuinely advisor-accessible product requiring a separate Ketju object."
      ],
      "advisorDiligenceImplications": [
        "Track the final deployment as a separate, centrally governed exposure rather than extending Aave v3 approval by brand or code lineage.",
        "Map executed controls and insurance boundaries before adding the Ink instance to the research perimeter."
      ],
      "followUpOn": "2025-08-08",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-72458aefc3c118d8cf013169",
      "stableKey": "aave-v3:ethereum-core:fxsave-temp-check-approval-2025-07",
      "version": 1,
      "eventDate": "2025-07-18",
      "publishedAt": "2026-08-22T14:05:43.445Z",
      "title": "Aave advances fxSAVE collateral to ARFC review",
      "category": "governance",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[TEMP CHECK] Onboard fxSAVE to Aave V3 Core Instance",
          "authority": "Aave DAO Snapshot",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0xf2f789b1bf66899c3e2142a93d3d6e46ebb2ce1e00a9b119ab8356c6fc55153c",
          "documentType": "official_governance_record",
          "publishedOn": "2025-07-14"
        }
      ],
      "whatHappened": "Aave DAO voters approved the fxSAVE temperature check, advancing the proposed Ethereum Core collateral listing to ARFC analysis.",
      "whatChanged": "fxSAVE entered formal risk review as a potential collateral asset carrying f(x) Protocol strategy, smart-contract, liquidity, leverage, and underlying stETH dependencies.",
      "whatDidNotChange": "No collateral parameters, oracle, ARFC approval, AIP, execution, or live reserve was established by the temperature check.",
      "confirmedFacts": [
        "The Snapshot closed on July 18, 2025 with approximately 811,728 voting YAE and negligible opposition.",
        "The target market is Aave v3 Ethereum Core.",
        "The proposal identifies fxSAVE as a yield-bearing f(x) Protocol token.",
        "The proposal defers risk parameters to later service-provider analysis.",
        "The stated next governance stage is an ARFC."
      ],
      "unresolved": [
        "Asset contract and complete dependency mapping.",
        "Collateral, liquidation, cap, E-mode, and oracle parameters.",
        "Upgrade, pause, redemption, liquidity, and strategy-loss controls.",
        "ARFC, AIP, and execution outcomes."
      ],
      "advisorDiligenceImplications": [
        "Require a full fxSAVE and f(x) dependency review before any Aave memo expansion.",
        "Monitor later parameters and execution without treating temperature-check approval as a live or suitable collateral listing."
      ],
      "followUpOn": "2025-08-01",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-089aa9fd12e0e371ef45e369",
      "stableKey": "lido:snop:block-proposals-v3-approval-2025-06",
      "version": 1,
      "eventDate": "2025-06-30",
      "publishedAt": "2026-08-22T14:05:42.640Z",
      "title": "Lido approves revised block-proposer and reward policy",
      "category": "economic_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Proposal for Updating Block Proposer Rewards Policy to Lido on Ethereum SNOP on Block Proposals v3",
          "authority": "Lido DAO Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x8b6addc4be1a9ef4b2a1591be5ac4909aa82c868cd9b7871494b626539a99a8e",
          "documentType": "official_governance_record",
          "publishedOn": "2025-06-23"
        }
      ],
      "whatHappened": "Lido tokenholders approved version 3 of the Standard Node Operator Protocol for block proposals, replacing the prior proposer-rewards policy.",
      "whatChanged": "The revised policy expands coverage across staking modules, formalizes allowed Auxiliary Proposer Mechanisms, updates proposer and fee-recipient responsibilities, and specifies module-level consequences for non-conformance.",
      "whatDidNotChange": "The vote did not approve any particular new APM, alter withdrawal contracts, or prove that every node operator had implemented the revised requirements.",
      "confirmedFacts": [
        "Node operators must direct relevant fees to the Lido Execution Layer Rewards Vault.",
        "Operators may use only community-vetted mechanisms on the APM Allowed List.",
        "The policy expands beyond the original Curated Module context.",
        "The policy describes consequences that vary by staking module."
      ],
      "unresolved": [
        "The effective implementation and operator-attestation process.",
        "The current APM Allowed List and future committee changes.",
        "Monitoring, detection, and enforcement of non-conformance.",
        "The realized effect on proposer rewards, censorship resistance, and operational diversity."
      ],
      "advisorDiligenceImplications": [
        "Update the Lido memo's proposer-reward, MEV, APM, and node-operator compliance controls.",
        "Monitor allowed-list changes and enforcement evidence; policy approval alone does not establish operator compliance."
      ],
      "followUpOn": "2025-07-14",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-16375cb633f22e7f59221d32",
      "stableKey": "lido:oracle-set:kyber-to-caliber-rotation-2025-06",
      "version": 1,
      "eventDate": "2025-06-30",
      "publishedAt": "2026-08-22T14:05:42.640Z",
      "title": "Lido approves replacing Kyber with Caliber in its oracle set",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Decision on Kyber Network's position in the Oracle Set: rotate to Caliber or remove and change the quorum",
          "authority": "Lido DAO Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0xdc208507ca0f659c7f9e38056288aedb7610816ea4020ca751c3422434780de8",
          "documentType": "official_governance_record",
          "publishedOn": "2025-06-23"
        }
      ],
      "whatHappened": "Lido tokenholders approved rotating Kyber Network out of the Lido on Ethereum oracle set and replacing it with Caliber.",
      "whatChanged": "The approved path changes the entity responsible for one oracle-set position while preserving the seat rather than removing it and adjusting quorum.",
      "whatDidNotChange": "The Snapshot approval does not itself prove that the on-chain oracle member rotation occurred, and it does not validate Caliber's production security or independence.",
      "confirmedFacts": [
        "The vote offered direct rotation to Caliber or removal of Kyber with a quorum change.",
        "The direct rotation option received the overwhelming voting weight.",
        "Caliber completed a Hoodi testnet period before the vote.",
        "The proposal attributes the change to Kyber's infrastructure operations transitioning to Caliber."
      ],
      "unresolved": [
        "The executed oracle-set membership and effective rotation date.",
        "The final production keys, infrastructure, and incident-response contacts.",
        "Operational overlap and independence between Kyber and Caliber.",
        "Whether quorum or other oracle controls change during implementation."
      ],
      "advisorDiligenceImplications": [
        "Review Lido's oracle-operator roster, key controls, concentration, and business-continuity assumptions.",
        "Verify the executed membership and Caliber's production operating evidence before treating the rotation as complete."
      ],
      "followUpOn": "2025-07-07",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-d444ea0b6a7e1b2f84328ef3",
      "stableKey": "lido:curated-module:intra-operator-dvt-guidelines-2025-06",
      "version": 1,
      "eventDate": "2025-06-30",
      "publishedAt": "2026-08-22T14:05:42.640Z",
      "title": "Lido approves intra-operator DVT rules for Curated Module operators",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "DVT Integration Guidelines for the Curated Module Node Operators",
          "authority": "Lido DAO Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x15cdcb4881d85d48e363bcc449cabfc26b627ac395e2515d65d6637453c35ab3",
          "documentType": "official_governance_record",
          "publishedOn": "2025-06-23"
        }
      ],
      "whatHappened": "Lido tokenholders approved guidelines allowing Curated Module node operators to adopt self-run Obol or SSV distributed-validator clusters under specified limits and safeguards.",
      "whatChanged": "Operators may split up to the lesser of 1,000 or 20% of active validator keys after testnet validation, add DVT keys produced through vetted verifiable DKG, and participate under revised provider-incentive allocations.",
      "whatDidNotChange": "The approval does not require every operator to adopt DVT, does not itself migrate validator keys, and does not establish the security or performance of any specific operator cluster.",
      "confirmedFacts": [
        "Curated Module DVT adoption is optional and limited to intra-operator clusters.",
        "Migration by an operator is capped at the lesser of 1,000 or 20% of its active validator keys.",
        "Obol and SSV are the identified DVT providers.",
        "Curated Module operators receive 20% of provider incentives, with 80% directed to the Mellow Decentralized Validator Vault."
      ],
      "unresolved": [
        "Which operators opt in and how many validators migrate.",
        "The final contributor-vetting process for DKG and key-shard procedures.",
        "Operational concentration, correlated-failure, and slashing behavior of deployed clusters.",
        "Whether incentive routing changes after implementation."
      ],
      "advisorDiligenceImplications": [
        "Update Lido's validator and key-management control map to include intra-operator DVT, DKG review, migration limits, and provider dependencies.",
        "Monitor operator-level adoption and slashing performance before interpreting DVT approval as a reduction in operational risk."
      ],
      "followUpOn": "2025-07-14",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-e47d06ae38a9c6a8400c8f6e",
      "stableKey": "aave-v3:ethereum-core:eurc-onboarding-aip-2025-06",
      "version": 1,
      "eventDate": "2025-06-30",
      "publishedAt": "2026-08-22T14:05:42.640Z",
      "title": "Aave approves EURC collateral for Ethereum Core",
      "category": "economic_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Add EURC to Aave V3 Core Instance",
          "authority": "Aave Governance",
          "url": "https://vote.onaave.com/proposal/?ipfsHash=0xf93eb58ea5cf5aaf82c5e3c799ac717bed7c1879c6a4ae1525087df7a873e5b6&proposalId=331",
          "documentType": "onchain_governance_proposal",
          "publishedOn": "2025-06-26"
        }
      ],
      "whatHappened": "Aave governance approved proposal 331 to add Circle-issued EURC as borrowable collateral in the Ethereum Core instance.",
      "whatChanged": "The approved listing adds EURC issuer, redemption, euro-market, liquidity, and oracle dependencies with explicit caps and liquidation parameters.",
      "whatDidNotChange": "Execution occurred after June 30, so EURC was not yet an operative reserve within this backfill boundary. The vote does not make EURC Ketju-approved.",
      "confirmedFacts": [
        "The approved supply and borrow caps are 7 million and 6.5 million EURC.",
        "The approved LTV and liquidation threshold are 75% and 78%.",
        "The approved liquidation bonus is 5% and reserve factor is 10%.",
        "Pricing uses a capped EURC/USD structure incorporating Chainlink EURC/USD and EUR/USD inputs."
      ],
      "unresolved": [
        "Verification of the July execution and final reserve configuration.",
        "EURC liquidity and liquidation performance under euro-dollar volatility.",
        "Issuer, redemption, freeze, and banking dependency treatment in the Aave memo.",
        "Whether caps or oracle configuration change after launch."
      ],
      "advisorDiligenceImplications": [
        "Review the Aave memo's collateral and oracle perimeter before treating EURC exposure as acceptable.",
        "Verify executed reserve state, issuer controls, redemption mechanics, and stressed liquidity before considering the new market."
      ],
      "followUpOn": "2025-07-02",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-ff35a1d905497123db522641",
      "stableKey": "aave-v3:agrs:pendle-discount-oracle-and-manual-steward-2025-06",
      "version": 1,
      "eventDate": "2025-06-30",
      "publishedAt": "2026-08-22T14:05:42.640Z",
      "title": "Aave approves expanded automated and manual risk-steward authority",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Discount Rate Risk Oracle Activation and update manual AGRS",
          "authority": "Aave Governance",
          "url": "https://vote.onaave.com/proposal/?ipfsHash=0x90c865128c6c5162d7bf4d957fcf33a10a5da36ac6eef6a142299b8df2c2b7cc&proposalId=332",
          "documentType": "onchain_governance_proposal",
          "publishedOn": "2025-06-26"
        }
      ],
      "whatHappened": "Aave governance approved proposal 332 to automate discount-rate updates for three Pendle PT feeds and deploy updated manual AGRS contracts across its instances.",
      "whatChanged": "The approved payload would grant RISK_ADMIN authority to new steward contracts, permit automated discount-rate recommendations through Edge Risk Oracle infrastructure, and allow constrained manual e-mode and Pendle discount-rate changes.",
      "whatDidNotChange": "Execution occurred after the June boundary. The approval did not remove the stated percentage constraints, minimum delays, feed allowlist, or separate handling of GHO.",
      "confirmedFacts": [
        "The automated steward is limited to whitelisted Pendle PT feeds on Ethereum Core.",
        "Automated discount-rate changes are constrained to a maximum one percentage-point absolute change every two days.",
        "Manual e-mode LTV, liquidation-threshold, and liquidation-bonus changes retain stated limits and three-day delays.",
        "The proposal passed before June 30 ended but was not executed until July 1."
      ],
      "unresolved": [
        "Verification of the July execution and final RISK_ADMIN role assignments.",
        "The complete deployed allowlist and automation configuration.",
        "How off-chain recommendation failures or stale inputs are handled operationally.",
        "Whether realized PT pricing behavior remains within memo assumptions."
      ],
      "advisorDiligenceImplications": [
        "Review Aave's oracle and delegated-risk-control map because approval expands automated and manual authority over collateral pricing and e-mode parameters.",
        "Verify executed roles, limits, allowlists, and revocations before treating the new AGRS configuration as operative."
      ],
      "followUpOn": "2025-07-02",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-ad4e22e38d2ccc6ce27781d9",
      "stableKey": "aave-v3:ethereum-core:svr-oracles-phase-3-2025-06",
      "version": 1,
      "eventDate": "2025-06-28",
      "publishedAt": "2026-08-22T14:05:42.640Z",
      "title": "Aave activates nine additional SVR oracles on Ethereum Core",
      "category": "control_change",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Enable additional SVR oracles",
          "authority": "Aave Governance",
          "url": "https://vote.onaave.com/proposal/?proposalId=330",
          "documentType": "executed_onchain_governance_proposal",
          "publishedOn": "2025-06-23"
        }
      ],
      "whatHappened": "Aave governance executed proposal 330 to replace nine Ethereum Core price feeds with Chainlink Smart Value Recapture equivalents.",
      "whatChanged": "The affected liquidations now use SVR feeds intended to recapture oracle-extractable value through the existing SVR steward and price-similarity validation process.",
      "whatDidNotChange": "The execution did not change collateral factors, caps, custody, or reserve listings, and it does not establish that realized SVR performance will match expectations.",
      "confirmedFacts": [
        "The execution completed on June 28.",
        "Affected assets are WETH, weETH, osETH, ETHx, rsETH, wstETH, rETH, cbETH, and USDC.",
        "The payload used the SVR steward to replace existing feeds with SVR equivalents.",
        "The change applies to the Aave V3 Ethereum Core instance."
      ],
      "unresolved": [
        "Post-execution feed-address and configuration verification.",
        "Realized oracle-extractable-value recovery and liquidation latency.",
        "Fallback behavior during auction or oracle infrastructure degradation.",
        "Whether the change affects liquidator participation during stress."
      ],
      "advisorDiligenceImplications": [
        "Update Aave's oracle and liquidation-control record for all nine Ethereum Core reserves.",
        "Monitor feed performance, liquidation latency, fallback behavior, and realized value capture before changing risk conclusions."
      ],
      "followUpOn": "2025-07-14",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-b08389a79d84566e56816919",
      "stableKey": "aave-v3:all-instances:v3.4-upgrade-2025-06",
      "version": 1,
      "eventDate": "2025-06-28",
      "publishedAt": "2026-08-22T14:05:42.640Z",
      "title": "Aave proposes the v3.4 upgrade across all instances",
      "category": "upgrade_migration",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Upgrade Aave instances to v3.4",
          "authority": "Aave Governance",
          "url": "https://vote.onaave.com/proposal/?proposalId=334",
          "documentType": "onchain_governance_proposal",
          "publishedOn": "2025-06-28"
        }
      ],
      "whatHappened": "Aave governance created proposal 334 to upgrade all v3 instances from v3.3 to the reduced v3.4 release.",
      "whatChanged": "If executed, the proposal would replace Pool, PoolConfigurator, PoolDataProvider, AToken, and VariableDebtToken implementations, standardize Ethereum Core GHO accounting, add configurable Position Manager permissions, and simplify flash-loan fees.",
      "whatDidNotChange": "The proposal had not completed voting or execution by June 30. It states that the GHO migration is intended to be non-invasive for users, but that intent does not establish post-upgrade behavior.",
      "confirmedFacts": [
        "The payload covers all Aave v3 instances through multiple network payloads.",
        "The existing native stkAAVE discount on variable-debt GHO would be removed.",
        "The proposal includes a pre-execution process intended to settle outstanding GHO discounts shortly before execution.",
        "Four independent audit reports and extensive testing are identified in the proposal."
      ],
      "unresolved": [
        "The vote outcome and execution after June 30.",
        "The exact GHO balances and facilitator transfers at execution time.",
        "Post-upgrade verification of every instance and Position Manager configuration.",
        "Whether any user accounting or integration issue appears after deployment."
      ],
      "advisorDiligenceImplications": [
        "Open a review of Aave v3 implementation, GHO accounting, delegation, and flash-loan assumptions before treating v3.4 as operative.",
        "Verify every deployed implementation and Ethereum Core GHO transition after execution; audits do not establish suitability or successful migration."
      ],
      "followUpOn": "2025-07-04",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-b09e2c884dcaafd8eb825906",
      "stableKey": "aave-v3:ethereum-core:syrupusdc-temp-check-approval-2025-06",
      "version": 1,
      "eventDate": "2025-06-27",
      "publishedAt": "2026-08-22T14:05:42.640Z",
      "title": "Aave advances proposed syrupUSDC collateral to ARFC review",
      "category": "economic_change",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[TEMP CHECK] Onboard syrupUSDC to Aave V3 Core Instance",
          "authority": "Aave DAO Snapshot",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0xf5951af5d6d7d70be998a72c531708db3ff9c46b033e3e27bfd59fb87542d0ea",
          "documentType": "official_governance_record",
          "publishedOn": "2025-06-24"
        }
      ],
      "whatHappened": "Aave tokenholders approved the syrupUSDC Temp Check, advancing proposed collateral onboarding for Ethereum Core to ARFC review.",
      "whatChanged": "The proposal moved a Maple ERC-4626 yield token backed by institutional lending strategies into Aave's formal risk-review pipeline.",
      "whatDidNotChange": "The vote did not list syrupUSDC, approve final collateral parameters, or validate Maple's credit underwriting and withdrawal behavior.",
      "confirmedFacts": [
        "syrupUSDC is described as a USDC-based ERC-4626 yield-bearing token issued through Maple infrastructure.",
        "The proposal seeks collateral enablement on Aave V3 Ethereum Core.",
        "Final risk parameters were deferred to the ARFC stage.",
        "The Temp Check cites proposed incentives and anticipated institutional allocation, neither of which is guaranteed."
      ],
      "unresolved": [
        "Final LTV, liquidation threshold, caps, oracle, and interest-rate parameters.",
        "Maple borrower, collateral, manager, withdrawal, and loss-allocation risks.",
        "ARFC and AIP outcomes.",
        "Stressed secondary liquidity and redemption capacity for syrupUSDC."
      ],
      "advisorDiligenceImplications": [
        "Monitor the ARFC and require credit, manager, redemption, liquidity, and oracle diligence before any memo conclusion.",
        "Temp Check approval does not make syrupUSDC Ketju-approved or suitable as collateral exposure."
      ],
      "followUpOn": "2025-07-11",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-f19640d3091719f4a49da85a",
      "stableKey": "aave-v3:core-bnb:usd1-temp-check-approval-2025-06",
      "version": 1,
      "eventDate": "2025-06-27",
      "publishedAt": "2026-08-22T14:05:42.640Z",
      "title": "Aave advances proposed USD1 onboarding to ARFC review",
      "category": "economic_change",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[TEMP CHECK] Onboard USD1 to Aave V3 Core and BNB Instance",
          "authority": "Aave DAO Snapshot",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0x1dcccab036766a95d14cb04bf9f3a1a0c2ad912d6e45443f484b3514e6785e06",
          "documentType": "official_governance_record",
          "publishedOn": "2025-06-24"
        }
      ],
      "whatHappened": "Aave tokenholders approved the USD1 Temp Check, allowing the proposed Core and BNB listings to advance to ARFC analysis.",
      "whatChanged": "USD1 entered Aave's formal risk-parameter and service-provider review path as a proposed deposit and borrow asset.",
      "whatDidNotChange": "The vote did not list USD1, approve collateral use, set final caps or liquidation parameters, or execute any reserve configuration.",
      "confirmedFacts": [
        "The proposal describes USD1 as a fiat-backed stablecoin issued by World Liberty Financial.",
        "The initial proposal contemplates deposits and borrowing, with collateral use deferred.",
        "Final risk parameters were not provided at the Temp Check stage.",
        "The approved next step is ARFC review rather than an executable AIP."
      ],
      "unresolved": [
        "Issuer, reserve, redemption, freeze, and banking controls.",
        "Final oracle, cap, interest-rate, and collateral parameters.",
        "ARFC and AIP outcomes.",
        "Whether USD1 liquidity is sufficient for stressed liquidations or exits."
      ],
      "advisorDiligenceImplications": [
        "Monitor the ARFC and require issuer, reserve, redemption, oracle, and liquidity diligence before any memo conclusion.",
        "Temp Check approval does not make USD1 or the proposed Aave markets Ketju-approved."
      ],
      "followUpOn": "2025-07-11",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-c55d538ce8a9a7d725902809",
      "stableKey": "aave-v3:prime:teth-onboarding-aip-2025-06",
      "version": 1,
      "eventDate": "2025-06-23",
      "publishedAt": "2026-08-22T14:05:42.640Z",
      "title": "Aave proposes tETH collateral for its Prime instance",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Onboard tETH to Aave v3 Prime Instance",
          "authority": "Aave Governance",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=329",
          "documentType": "onchain_governance_proposal",
          "publishedOn": "2025-06-23"
        }
      ],
      "whatHappened": "Aave governance created proposal 329 to list Treehouse tETH as collateral in the Ethereum Prime instance.",
      "whatChanged": "Execution would add tETH strategy, redemption, oracle, liquidity, and restaking dependencies with a 20,000-token supply cap and a tETH-to-wstETH e-mode.",
      "whatDidNotChange": "The proposal record does not by itself establish execution or make tETH an approved Ketju asset.",
      "confirmedFacts": [
        "The proposed tETH supply cap is 20,000 and borrowing of tETH is disabled.",
        "The proposed base LTV and liquidation threshold are 0.05% and 0.1%.",
        "The tETH/wstETH e-mode proposes 92% LTV and 94% liquidation threshold for tETH collateral.",
        "Pricing uses a capped tETH/wstETH/USD oracle with a 4.5% maximum yearly growth rate."
      ],
      "unresolved": [
        "The final execution state and effective reserve configuration.",
        "tETH redemption, strategy, and liquidity behavior during stress.",
        "Oracle-ratio and price-cap behavior if the underlying strategy underperforms.",
        "The concentration and counterparty risks embedded in tETH."
      ],
      "advisorDiligenceImplications": [
        "Review tETH's strategy, redemption, oracle, and liquidity dependencies before treating the Prime listing as acceptable.",
        "Verify executed caps and e-mode state and keep tETH outside Ketju approval absent separate asset diligence."
      ],
      "followUpOn": "2025-07-02",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-a67eda0adcf31af975b582b5",
      "stableKey": "aave-v3:aptos-mainnet:arfc-snapshot-2025-04-30",
      "version": 2,
      "eventDate": "2025-06-22",
      "publishedAt": "2026-08-22T14:05:42.640Z",
      "title": "Aave opens final governance for a guarded Aptos activation",
      "category": "launch_access",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Aave V3 Aptos Activation",
          "authority": "Aave Governance",
          "url": "https://vote.onaave.com/proposal/?ipfsHash=0x655034112ecc3f89cbcfc7420c490928d01772bcae507a954f1f26be02b4687b&proposalId=328",
          "documentType": "onchain_governance_proposal",
          "publishedOn": "2025-06-22"
        }
      ],
      "whatHappened": "Aave created a final on-chain proposal to place its deployed Aptos market under a guarded activation process as its first non-EVM deployment.",
      "whatChanged": "Approval would begin a restricted CTF phase with APT, USDC, USDT, and sUSDe, broad initial authority held by a 4-of-7 Launch Steward, and a phased path toward Community Guardian and cross-chain DAO control.",
      "whatDidNotChange": "The proposal states that deployment contracts already exist, but public user capacity is intentionally unavailable during the initial restricted phase. Full DAO control and ordinary advisor access were not established.",
      "confirmedFacts": [
        "The initial CTF phase is planned for approximately four to six weeks.",
        "The deployment team would seed up to $25,000 of each supported asset while leaving no room for user deposits during the restricted phase.",
        "The Launch Steward comprises Aave Labs and Aptos Foundation signers with a 4-of-7 threshold.",
        "Full governance requires later transfer of roles and an audited Governance V3 cross-chain executor."
      ],
      "unresolved": [
        "The final vote and execution state within and after June.",
        "Completion and findings of the CTF, outstanding audit, and subsequent bug-bounty phase.",
        "The effective steward keys, role assignments, and emergency procedures.",
        "The timing and verification of public capacity and full DAO-control transition."
      ],
      "advisorDiligenceImplications": [
        "Review the Aptos deployment as a distinct non-EVM control and implementation perimeter, including Launch Steward authority and cross-chain governance dependencies.",
        "Do not treat the restricted deployment as advisor-accessible or Ketju-approved until public capacity, executed roles, audits, and governance transition are independently verified."
      ],
      "followUpOn": "2025-07-07",
      "previousInterpretation": "The April record treated Aptos as an ARFC-stage proposal awaiting a final AIP, guarded activation, and verification of its non-EVM control model.",
      "supersedesId": null
    },
    {
      "id": "event-event-draft-41984787499f87b7a8ae2eac",
      "stableKey": "optimism-bridge:superchain-upgrade-16:portal-guardian-pause-proposal",
      "version": 1,
      "eventDate": "2025-06-20",
      "publishedAt": "2026-08-22T14:05:42.640Z",
      "title": "Optimism proposes Upgrade 16 bridge and guardian changes",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "optimism-bridge",
          "name": "Optimism canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Optimism Extends $2 Million Bug Bounty Program to Protocol Upgrades Ahead of Superchain Interop",
          "authority": "Optimism Foundation",
          "url": "https://optimism.io/blog/optimism-extends-2-million-bug-bounty-program-to-protocol-upgrades-ahead-of-superchain-interop",
          "documentType": "official_protocol_notice",
          "publishedOn": "2025-06-20"
        }
      ],
      "whatHappened": "Optimism published Superchain Upgrade 16 for review and extended its bug-bounty scope to the proposed upgrade calldata before production deployment.",
      "whatChanged": "The proposal would update OptimismPortal for future cross-chain messaging, remove DeputyGuardianModule, update DeputyPauseModule, and raise the maximum gas limit from 200 million to 500 million.",
      "whatDidNotChange": "The notice states that Upgrade 16 does not enable Superchain interoperability, and it does not establish that the proposed payload was approved or executed.",
      "confirmedFacts": [
        "Upgrade 16 was the first proposed upgrade covered by the expanded calldata bug bounty.",
        "The proposed OptimismPortal changes are preparatory and do not turn on interoperability.",
        "The proposal includes removal of DeputyGuardianModule and updates to DeputyPauseModule.",
        "The maximum gas limit would increase from 200 million to 500 million."
      ],
      "unresolved": [
        "The final governance outcome and executed payload.",
        "The deployed guardian and pause-module state after any execution.",
        "Whether the final code or calldata changes during security review."
      ],
      "advisorDiligenceImplications": [
        "Review the Optimism bridge memo's upgrade, pause, and guardian control map before treating Upgrade 16 as operative.",
        "Verify the final governance payload and deployed contract state after execution; the expanded bounty does not establish safety or approval."
      ],
      "followUpOn": "2025-07-03",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-c19565abc09765d14a49bfc6",
      "stableKey": "aave-v3:soneium:v3.3-activation-2025-05",
      "version": 1,
      "eventDate": "2025-05-29",
      "publishedAt": "2026-08-22T14:05:42.200Z",
      "title": "Aave proposes activating v3.3 on Soneium",
      "category": "launch_access",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Aave V3.3 Soneium Activation",
          "authority": "Aave Governance",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=319",
          "documentType": "onchain_governance_proposal",
          "publishedOn": "2025-05-29"
        }
      ],
      "whatHappened": "Aave proposal 319 opened to activate V3.3 on Soneium and list USDCe, USDT, and WETH.",
      "whatChanged": "The proposal created a path to a new chain instance with Risk Steward risk-admin, Guardian pool-admin, and ACI emission-admin authority.",
      "whatDidNotChange": "No May evidence established vote completion, execution, a live pool, or Ketju approval of the instance or assets.",
      "confirmedFacts": [
        "The proposed reserves were USDCe, USDT, and WETH.",
        "Proposed supply caps were 8 million USDCe, 5 million USDT, and 800 WETH.",
        "The Guardian would hold pool-admin authority during bootstrap."
      ],
      "unresolved": [
        "The vote result after May 31.",
        "Execution and final reserve, oracle, and administrator state.",
        "Soneium bridge, sequencer, liquidity, and emergency-control diligence."
      ],
      "advisorDiligenceImplications": [
        "Open a Soneium-specific Aave diligence branch.",
        "Do not extend existing Aave approval to the proposed instance."
      ],
      "followUpOn": "2025-06-03",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-178f4934c24f8ffed4ca213f",
      "stableKey": "lido:csm-v2:architecture-fees-approval-2025-05",
      "version": 1,
      "eventDate": "2025-05-28",
      "publishedAt": "2026-08-22T14:05:42.200Z",
      "title": "Lido approves the CSM v2 architecture and fee structure",
      "category": "upgrade_migration",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "LIP-29: Community Staking Module v2",
          "authority": "Lido Governance Forum",
          "url": "https://research.lido.fi/t/community-staking-module/5917/117",
          "documentType": "official_governance_record",
          "publishedOn": "2025-05-08"
        }
      ],
      "whatHappened": "Lido voters approved the proposed CSM v2 architecture and fee structure.",
      "whatChanged": "The approval authorized configurable operator types and gates, enhanced performance-oracle inputs, strikes-based ejection, EIP-7002 support, and differentiated rewards.",
      "whatDidNotChange": "The Snapshot did not enact CSM v2 within May, migrate operators, change live contracts, or prove the design safe in production.",
      "confirmedFacts": [
        "The design introduced permissionless and vetted gates.",
        "Performance accounting adds block-proposal and sync-committee inputs.",
        "A strikes-based validator-ejection mechanism was included."
      ],
      "unresolved": [
        "The later on-chain enactment.",
        "Final contracts, parameters, ownership, weights, thresholds, and fee curves.",
        "Migration and effects on concentration, queue access, and false ejections."
      ],
      "advisorDiligenceImplications": [
        "Review CSM allocation, oracle, ejection, gate, concentration, and fee assumptions.",
        "Require final code, audits, execution, and production monitoring."
      ],
      "followUpOn": "2025-06-02",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-18de2ee634a830816f575809",
      "stableKey": "aave-v3:ethereum-core:fbtc-onboarding-aip-2025-05",
      "version": 1,
      "eventDate": "2025-05-28",
      "publishedAt": "2026-08-22T14:05:42.200Z",
      "title": "Aave proposes adding FBTC collateral to Ethereum Core",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Add FBTC to Aave v3 Main Market on Ethereum",
          "authority": "Aave Governance",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=318",
          "documentType": "onchain_governance_proposal",
          "publishedOn": "2025-05-28"
        }
      ],
      "whatHappened": "Aave proposal 318 opened to list FBTC as borrowable collateral and create an FBTC-to-WBTC E-mode.",
      "whatChanged": "Execution would add FBTC bridge, custody, redemption, liquidity, and oracle dependencies with 200/100 FBTC supply and borrow caps.",
      "whatDidNotChange": "No May evidence established vote completion or execution, and FBTC did not become Ketju-approved.",
      "confirmedFacts": [
        "Proposed LTV and liquidation threshold were 73% and 78%.",
        "The proposal specified Chainlink SVR BTC/USD pricing.",
        "The proposed E-mode used 84% LTV and 86% liquidation threshold."
      ],
      "unresolved": [
        "The vote and execution after May 31.",
        "Final oracle, cap, and E-mode state.",
        "FBTC custody, redemption, concentration, and stressed-liquidity risks."
      ],
      "advisorDiligenceImplications": [
        "Review FBTC’s custody and cross-chain trust model.",
        "Require executed-state and liquidity verification before considering exposure."
      ],
      "followUpOn": "2025-06-03",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-35a287629111f772a58d08d4",
      "stableKey": "lido:apm-committee:approval-2025-05",
      "version": 1,
      "eventDate": "2025-05-28",
      "publishedAt": "2026-08-22T14:05:42.200Z",
      "title": "Lido approves an Auxiliary Proposer Mechanisms Committee",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        },
        {
          "type": "controller",
          "id": "lido-apm-committee",
          "name": "Lido Auxiliary Proposer Mechanisms Committee"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Establishing the APM Committee",
          "authority": "Lido Governance Forum",
          "url": "https://research.lido.fi/t/establishing-the-apm-committee/9998",
          "documentType": "official_governance_record",
          "publishedOn": "2025-05-02"
        }
      ],
      "whatHappened": "Lido approved a six-member committee to review and maintain the mechanisms node operators may use.",
      "whatChanged": "The approval created an allowlist process using 5-of-6 consensus, public rationale, and a seven-day review period.",
      "whatDidNotChange": "No particular mechanism, validator key, asset transfer, or withdrawal change was approved.",
      "confirmedFacts": [
        "The committee has six voting members.",
        "Its decision threshold is 5-of-6.",
        "Decisions require public disclosure and a seven-day review."
      ],
      "unresolved": [
        "Final operational and repository controls.",
        "The first approved and rejected mechanisms.",
        "Compliance monitoring and enforcement."
      ],
      "advisorDiligenceImplications": [
        "Add the committee to Lido’s validator-control map.",
        "Monitor membership, decisions, approved mechanisms, and enforcement."
      ],
      "followUpOn": "2025-06-11",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-604ddf3802b3a9e29d751c89",
      "stableKey": "coinbase-bridge:base-mainnet-safe-head-delay:2025-05-28",
      "version": 1,
      "eventDate": "2025-05-28",
      "publishedAt": "2026-08-22T14:05:42.200Z",
      "title": "Base recovers from a batching-related safe-head delay",
      "category": "market_stress",
      "posture": "recovered",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "coinbase-bridge",
          "name": "Base canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Base Mainnet | Safe Head Delay",
          "authority": "Base Status",
          "url": "https://status.base.org/incidents/bqgbcfkj9xyv",
          "documentType": "official_status_incident",
          "publishedOn": "2025-05-28"
        }
      ],
      "whatHappened": "Base reported that mainnet safe head trailed unsafe head because of batching-performance problems. Deposits and withdrawals were affected before batches resumed and the incident was resolved.",
      "whatChanged": "Safe-head progression and timely L1-backed confirmation were impaired from 14:40 UTC until resolution at 18:09 UTC.",
      "whatDidNotChange": "Base reported no asset loss, bridge exploit, custody change, role change, or modification to withdrawal and fault-proof rules.",
      "confirmedFacts": [
        "Base identified batching performance as the cause.",
        "Deposits and withdrawals were listed as affected.",
        "Safe-head advancement recovered the same day."
      ],
      "unresolved": [
        "The number and duration of delayed bridge transactions.",
        "The precise root cause and durable remediation.",
        "Recurrence risk after a separate May 21 safe-head lag."
      ],
      "advisorDiligenceImplications": [
        "Review batching and safe-head assumptions in the Base bridge memo.",
        "Retain fee, retry, alternate-RPC, and confirmation-monitoring procedures."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-b78a1d7c8d2302aa22b07ed3",
      "stableKey": "aave-v3:celo:weth-onboarding-aip-2025-05",
      "version": 1,
      "eventDate": "2025-05-28",
      "publishedAt": "2026-08-22T14:05:42.200Z",
      "title": "Aave proposes WETH collateral for its Celo market",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Onboarding WETH to Aave V3 Celo Instance",
          "authority": "Aave Governance",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=317",
          "documentType": "onchain_governance_proposal",
          "publishedOn": "2025-05-28"
        }
      ],
      "whatHappened": "Aave proposal 317 opened to add Celo-native bridged WETH as borrowable collateral.",
      "whatChanged": "Execution would add a 500 WETH supply cap, 450 WETH borrow cap, 78% LTV, 80% liquidation threshold, and Chainlink ETH/USD pricing.",
      "whatDidNotChange": "The May record did not establish vote completion, execution, reserve activation, or Ketju approval of Aave Celo or Celo WETH.",
      "confirmedFacts": [
        "The reserve would be borrowable and collateral-enabled.",
        "The asset depends on Celo’s OP Stack Standard Bridge.",
        "The proposed liquidation bonus was 7.5%."
      ],
      "unresolved": [
        "The vote and execution after May 31.",
        "Final reserve and oracle state.",
        "Celo bridge, sequencer, concentration, liquidity, and exit-path risks."
      ],
      "advisorDiligenceImplications": [
        "Review Celo-specific dependencies separately from other Aave markets.",
        "Do not infer suitability from WETH familiarity or Aave governance."
      ],
      "followUpOn": "2025-06-03",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-de8f5e95fa8c3878ced0b9e6",
      "stableKey": "lido:lip-28:dual-governance-approval-2025-05",
      "version": 1,
      "eventDate": "2025-05-28",
      "publishedAt": "2026-08-22T14:05:42.200Z",
      "title": "Lido approves the Dual Governance rollout design",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        },
        {
          "type": "controller",
          "id": "lido-dao",
          "name": "Lido DAO and Dual Governance"
        }
      ],
      "primaryDocuments": [
        {
          "title": "LIP-28 Dual Governance",
          "authority": "Lido Governance Forum",
          "url": "https://research.lido.fi/t/lip-28-dual-governance/10032",
          "documentType": "official_governance_record",
          "publishedOn": "2025-05-08"
        }
      ],
      "whatHappened": "Lido voters approved LIP-28’s final implementation, parameters, and committee structure.",
      "whatChanged": "The approval authorized a dynamic timelock through which stETH holders can delay motions and ultimately block execution until a rage quit completes.",
      "whatDidNotChange": "No May evidence established deployment, role transfer, live escrow, or active veto protection.",
      "confirmedFacts": [
        "The first-seal threshold was proposed at 1% of Lido Ethereum TVL.",
        "The second seal was 10%.",
        "Emergency, reseal, and tiebreaker committees were included."
      ],
      "unresolved": [
        "The later Aragon vote and execution.",
        "Final thresholds, signer sets, permissions, and GateSeal configuration.",
        "Behavior during mass withdrawal or committee failure."
      ],
      "advisorDiligenceImplications": [
        "Review governance, timelock, committee, and withdrawal-capacity assumptions.",
        "Verify deployed contracts and roles before treating Dual Governance as operative."
      ],
      "followUpOn": "2025-06-02",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-55d29fd00b1160356820c845",
      "stableKey": "aave-v3:ethereum-core:eusde-collateral-arfc-approval-2025-04",
      "version": 2,
      "eventDate": "2025-05-26",
      "publishedAt": "2026-08-22T14:05:42.200Z",
      "title": "Aave approves eUSDe and two dated PT collaterals for Ethereum Core",
      "category": "economic_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Onboard eUSDe and eUSDe-based PT tokens to Aave V3 Core",
          "authority": "Aave Governance",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=316",
          "documentType": "onchain_governance_proposal",
          "publishedOn": "2025-05-22"
        }
      ],
      "whatHappened": "Aave governance approved a payload covering eUSDe, PT-USDe-31JUL2025, and PT-eUSDe-14AUG2025 collateral configurations.",
      "whatChanged": "The earlier eUSDe ARFC approval advanced to on-chain authorization and expanded to two dated principal-token collaterals using capped, maturity-aware oracles and E-modes.",
      "whatDidNotChange": "Execution and final reserve state were not established within May, and none of the assets became Ketju-approved.",
      "confirmedFacts": [
        "eUSDe used a 550 million supply cap and 90%/93% stablecoin E-mode parameters.",
        "PT-USDe-31JUL2025 used a 40 million supply cap.",
        "PT-eUSDe-14AUG2025 was included in the payload."
      ],
      "unresolved": [
        "Execution and final reserve, oracle, and E-mode state.",
        "Ethereal withdrawal, owner, backing, and concentration risks.",
        "PT liquidity, maturity handling, oracle behavior, and stressed liquidations."
      ],
      "advisorDiligenceImplications": [
        "Supersede the April ARFC-stage entry with an approved-but-unverified execution posture.",
        "Review eUSDe and both PT assets as separate dependencies."
      ],
      "followUpOn": "2025-06-02",
      "previousInterpretation": "The April record described eUSDe as approved only at the ARFC stage, with no on-chain authorization or dated-PT payload established.",
      "supersedesId": null
    },
    {
      "id": "event-event-draft-cb88041553f08c0e34bb5eeb",
      "stableKey": "aave-v3:ethereum-core:wstlink-temp-check-approval-2025-05",
      "version": 1,
      "eventDate": "2025-05-26",
      "publishedAt": "2026-08-22T14:05:42.200Z",
      "title": "Aave advances proposed wstLINK collateral to ARFC",
      "category": "governance",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[TEMP-CHECK] Onboard wstLINK to Aave v3 Core Instance",
          "authority": "Aave Governance Forum",
          "url": "https://governance.aave.com/t/temp-check-onboard-wstlink-to-aave-v3-core-instance/22007",
          "documentType": "official_governance_record",
          "publishedOn": "2025-05-09"
        }
      ],
      "whatHappened": "Aave’s TEMP CHECK for wstLINK collateral passed Snapshot quorum and advanced to ARFC.",
      "whatChanged": "The proposal entered formal risk review for an asset with staking, unbonding, liquidity, node-operator, and wrapper dependencies.",
      "whatDidNotChange": "No parameters, AIP, execution, reserve listing, or collateral enablement was approved.",
      "confirmedFacts": [
        "YAE won with 595,700 votes.",
        "The result was posted May 26.",
        "The stated next step was an ARFC."
      ],
      "unresolved": [
        "Final ARFC parameters and vote.",
        "Any AIP and execution.",
        "wstLINK staking, withdrawal, oracle, concentration, and liquidation-liquidity risks."
      ],
      "advisorDiligenceImplications": [
        "Require complete LINK-staking and wrapper analysis.",
        "Do not treat the TEMP CHECK as a live listing or client approval."
      ],
      "followUpOn": "2025-06-09",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-f779f63b4ac8cf7e7db1369a",
      "stableKey": "aave-v3:risk-oracle:cap-automation-constraints-2025-05",
      "version": 1,
      "eventDate": "2025-05-20",
      "publishedAt": "2026-08-22T14:05:42.200Z",
      "title": "Aave proposes tighter constraints for automated supply and borrow caps",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        },
        {
          "type": "oracle",
          "id": "aave-cap-risk-oracle",
          "name": "Aave Supply and Borrow Cap Risk Oracle"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC-Addendum] Supply and Borrow Cap Risk Oracle Constraint Specification",
          "authority": "Aave Governance Forum / Chaos Labs",
          "url": "https://governance.aave.com/t/arfc-addendum-supply-and-borrow-cap-risk-oracle-constraint-specification/22074",
          "documentType": "official_governance_proposal",
          "publishedOn": "2025-05-15"
        }
      ],
      "whatHappened": "Chaos Labs proposed criteria defining which reserves may receive automated cap changes.",
      "whatChanged": "Young assets, E-mode-only collateral, and smaller markets would be excluded from some or all automated adjustments and return to manual review.",
      "whatDidNotChange": "The primary record did not establish a completed vote, execution, changed cap value, or changed Risk Steward authority.",
      "confirmedFacts": [
        "The framework already operated on Avalanche, Base, and Arbitrum.",
        "Assets younger than 30 days would be excluded.",
        "E-mode-only collateral would be excluded from automated increases.",
        "Markets below $5 million would be excluded from automated increases and decreases."
      ],
      "unresolved": [
        "The final vote and implementation payload.",
        "The enforcing code or configuration.",
        "Manual-review latency during fast market changes."
      ],
      "advisorDiligenceImplications": [
        "Review the boundary between automated and manual cap authority.",
        "Verify executed configuration and exception handling before treating the safeguards as operative."
      ],
      "followUpOn": "2025-06-02",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-612ba483f62533f3c04a882b",
      "stableKey": "optimism-superchain:upgrade-15a:isthmus-prestate-blob-fix:2025-04",
      "version": 2,
      "eventDate": "2025-05-09",
      "publishedAt": "2026-08-22T14:05:42.200Z",
      "title": "Optimism activates the Isthmus hardfork across OP Mainnet and Base",
      "category": "upgrade_migration",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "optimism-bridge",
          "name": "Optimism canonical bridge"
        },
        {
          "type": "protocol",
          "id": "coinbase-bridge",
          "name": "Base canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Optimism Brings Ethereum’s Pectra Upgrade to the Superchain",
          "authority": "Optimism / OP Labs",
          "url": "https://optimism.io/blog/optimism-brings-ethereum-s-pectra-upgrade-to-the-superchain",
          "documentType": "official_upgrade_release",
          "publishedOn": "2025-05-09"
        }
      ],
      "whatHappened": "OP Labs reported successful activation of Isthmus across the Superchain, including OP Mainnet and Base.",
      "whatChanged": "The watched chains became live on the Isthmus release, adding Pectra-derived functionality including EIP-7702 account delegation and blob-scaling changes.",
      "whatDidNotChange": "The release did not establish that either bridge became lower risk and reported no bridge-custody, pause-authority, withdrawal-owner, or governance-role change.",
      "confirmedFacts": [
        "OP Labs dated activation to May 9, 2025.",
        "Base and OP Mainnet were expressly included.",
        "The release identified EIP-7702 functionality and increased blob capacity."
      ],
      "unresolved": [
        "Independent verification of the final upgrade payloads and dispute-game prestates.",
        "Unexpected withdrawal-proof or fault-dispute behavior.",
        "Operator completion of required version migrations."
      ],
      "advisorDiligenceImplications": [
        "Supersede the proposal-stage interpretation in both bridge diligence files.",
        "Verify deployed implementations, dispute-game configuration, withdrawal proofs, and operator-version coverage."
      ],
      "followUpOn": null,
      "previousInterpretation": "Upgrade Proposal 15A was previously recorded as proposed and not operative.",
      "supersedesId": null
    },
    {
      "id": "event-event-draft-3de5a4e859e4ccea3e24ef1d",
      "stableKey": "aave-v3:tron-deployment:temp-check-approval-2025-04",
      "version": 1,
      "eventDate": "2025-04-29",
      "publishedAt": "2026-08-22T14:05:41.464Z",
      "title": "Aave advances a proposed v3 deployment on Tron",
      "category": "governance",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[TEMP CHECK] Deploy Aave v3 on Tron",
          "authority": "Aave Governance Forum",
          "url": "https://governance.aave.com/t/temp-check-deploy-aave-v3-on-tron/21853",
          "documentType": "official_governance_record",
          "publishedOn": "2025-04-18"
        }
      ],
      "whatHappened": "Aave's preliminary governance poll approved advancing a proposed Aave V3 deployment on Tron Mainnet to the ARFC and risk-review stage.",
      "whatChanged": "Tron entered Aave's formal deployment-review pipeline, creating a prospective new chain, governance, oracle, asset, and liquidity perimeter for the watched protocol.",
      "whatDidNotChange": "The TEMP CHECK did not approve final risk parameters, authorize an AIP, deploy contracts, or create a live Aave market on Tron.",
      "confirmedFacts": [
        "The TEMP CHECK Snapshot passed on April 29 with quorum and YAE as the winning option.",
        "The proposal sought a Tron Mainnet Aave V3 deployment.",
        "Tron DAO stated an intention to provide launch liquidity, but no amount was specified at the TEMP CHECK stage.",
        "The official record identifies ARFC analysis and a later AIP as required subsequent stages."
      ],
      "unresolved": [
        "Tron's technical compatibility, governance concentration, legal, oracle, bridge, and asset risks.",
        "Final asset set, risk parameters, liquidity commitments, and control structure.",
        "ARFC and AIP outcomes and any eventual deployment verification.",
        "Whether the proposed market would ever enter Ketju's approved exposure perimeter."
      ],
      "advisorDiligenceImplications": [
        "Monitor the ARFC for primary technical and risk-provider analysis, especially Tron governance and execution differences.",
        "Do not treat preliminary approval as a live market or extend existing Aave approval to Tron.",
        "Create no client exposure until separate chain, asset, liquidity, oracle, and operational diligence is complete."
      ],
      "followUpOn": "2025-05-15",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-434b915d62ca28f010d8c25b",
      "stableKey": "lido:liquidity-observation-lab:easy-track-limit-6000-6mo-approval-2025-04",
      "version": 1,
      "eventDate": "2025-04-28",
      "publishedAt": "2026-08-22T14:05:41.464Z",
      "title": "Lido approves a higher Easy Track limit for the Liquidity Observation Lab",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Increasing LOL ET Limits to align with Lido Ecosystem BORG Foundation Grant Funding Request",
          "authority": "Lido Governance Forum",
          "url": "https://research.lido.fi/t/increasing-lol-et-limits-to-align-with-egg-lido-ecosystem-borg-foundation-grant-funding-request/9881",
          "documentType": "official_governance_record",
          "publishedOn": "2025-04-03"
        }
      ],
      "whatHappened": "Lido's Snapshot approved increasing the Easy Track security limit for stETH transfers to the Liquidity Observation Lab multisig from 2,100 stETH per three months to 6,000 stETH per six months.",
      "whatChanged": "The approval created a path to raise the amount transferable through the existing Easy Track recipient and top-up controls and lengthen the budget-reset period, materially changing the magnitude of the operational transfer authority.",
      "whatDidNotChange": "The April Snapshot did not execute the new limit, approve additional grant funding, change the recipient multisig, or itself transfer stETH.",
      "confirmedFacts": [
        "The official forum reports that the Snapshot ended and passed on April 28.",
        "The approved limit was 6,000 stETH for each six-month period.",
        "The prior limit was 2,100 stETH for each three-month period.",
        "The stated purpose was to align the security threshold with an already approved Liquidity Observation Lab grant."
      ],
      "unresolved": [
        "The final Aragon payload, vote, and execution transaction.",
        "The exact post-execution factory configuration and spent-amount state.",
        "Whether the higher threshold changes operational loss severity or multisig-control assumptions.",
        "Actual transfers made under the expanded limit."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido memo's Easy Track and Liquidity Observation Lab multisig control map because the approved transfer magnitude is materially higher.",
        "Verify the final on-chain factory parameters, recipient, reset period, and execution before treating the limit as operative.",
        "Do not conflate the higher security threshold with new funding approval or evidence that multisig risk decreased."
      ],
      "followUpOn": "2025-05-24",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-4f6601bd0ec85591220ae7a0",
      "stableKey": "aave-v3:ethereum-core:usdtb-borrow-reserve-arfc-approval-2025-04",
      "version": 1,
      "eventDate": "2025-04-27",
      "publishedAt": "2026-08-22T14:05:41.464Z",
      "title": "Aave approves borrow-only USDtb onboarding at the ARFC stage",
      "category": "economic_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Onboard USDtb to Aave v3 Core Instance",
          "authority": "Aave Governance Forum",
          "url": "https://governance.aave.com/t/arfc-onboard-usdtb-to-aave-v3-core-instance/21746",
          "documentType": "official_governance_record",
          "publishedOn": "2025-04-09"
        }
      ],
      "whatHappened": "Aave's ARFC Snapshot approved advancing USDtb as a borrow-enabled, non-collateral reserve on the Ethereum Core instance.",
      "whatChanged": "A concrete AIP path opened for a USDtb reserve with a 50 million supply cap, 40 million borrow cap, and an interest-rate curve intended to deepen borrowing liquidity for stablecoin leverage strategies.",
      "whatDidNotChange": "The ARFC approval did not deploy the reserve, enable USDtb as collateral, execute final parameters, or add USDtb to Ketju's approved assets.",
      "confirmedFacts": [
        "The ARFC Snapshot passed on April 27 with quorum and YAE as the winning option.",
        "USDtb was proposed as borrowable but not collateral-enabled.",
        "The proposed supply and borrow caps were 50 million and 40 million.",
        "The official risk review identified concentrated Ethena-linked holdings, KYC-gated direct redemption, custodian reliance, and BUIDL and stablecoin reserves."
      ],
      "unresolved": [
        "The final AIP payload, vote, and execution.",
        "Live deposit concentration, borrow utilization, secondary liquidity, and redemption performance.",
        "Final reserve composition, custodian exposure, and cross-chain dependencies at execution.",
        "Whether the proposed reserve affects approved GHO-market liquidity or risk in practice."
      ],
      "advisorDiligenceImplications": [
        "Review the Aave memo's reserve and counterparty-risk map for USDtb, BUIDL, Pallas entities, custodians, and KYC-gated redemption.",
        "Verify the final AIP, executed caps, oracle, and live liquidity before treating USDtb as an operative Aave reserve.",
        "Keep Ketju's approved Aave exposure and USDtb asset suitability as separate decisions."
      ],
      "followUpOn": "2025-05-15",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-8f24bbf546f8dda565bc6f99",
      "stableKey": "lido:csm:stake-share-3pct-key-removal-0.02-approval-2025-04",
      "version": 1,
      "eventDate": "2025-04-21",
      "publishedAt": "2026-08-22T14:05:41.464Z",
      "title": "Lido approves conditional CSM expansion and a lower key-removal charge",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Proposal: Update keyRemovalCharge parameter in CSM",
          "authority": "Lido Governance Forum",
          "url": "https://research.lido.fi/t/community-staking-module/5917/104",
          "documentType": "official_control_change_proposal",
          "publishedOn": "2025-03-31"
        },
        {
          "title": "Proposal: CSM stake share limit increase",
          "authority": "Lido Governance Forum",
          "url": "https://research.lido.fi/t/community-staking-module/5917/105",
          "documentType": "official_control_change_proposal",
          "publishedOn": "2025-04-12"
        },
        {
          "title": "CSM parameter-adjustment Snapshot result",
          "authority": "Lido Governance Forum",
          "url": "https://research.lido.fi/t/community-staking-module/5917/111",
          "documentType": "official_governance_result",
          "publishedOn": "2025-04-21"
        }
      ],
      "whatHappened": "Lido's Snapshot approved reducing the Community Staking Module's keyRemovalCharge from 0.05 ETH to 0.02 ETH and conditionally increasing its stakeShareLimit from 2% to 3%.",
      "whatChanged": "The approval authorized a future reduction in the safety charge applied when queued validator keys are removed and created a conditional path to allocate a larger share of Lido stake to CSM.",
      "whatDidNotChange": "Neither parameter changed on-chain in April. The stake-share increase remained conditional on other module and node-operator milestones or a later CSM v2 release.",
      "confirmedFacts": [
        "The Snapshot passed on April 21 with 63.9 million LDO for and one LDO against.",
        "The approved keyRemovalCharge target was 0.02 ETH, based on a conservative 20 Gwei queue-cleanup cost estimate.",
        "The approved stakeShareLimit target was 3%, up from 2%.",
        "The stake-share proposal also called for a 3.75% priorityExitShareThreshold and specified conditions involving SimpleDVT and Pier Two."
      ],
      "unresolved": [
        "The on-chain vote and execution transactions for each parameter.",
        "When or whether the stated conditions for the 3% stake-share limit were met.",
        "Final parameter values if execution was bundled with later CSM or Pectra changes.",
        "The operational effect on queue behavior, node-operator concentration, exits, and module allocation."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido memo's CSM allocation, queue, penalty, and node-operator concentration assumptions.",
        "Verify executed parameter state and satisfaction of the conditional expansion criteria before treating either change as operative.",
        "Continue assessing CSM as a distinct staking-module dependency; governance approval does not establish lower risk."
      ],
      "followUpOn": "2025-05-24",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-d96dfc91e8dec44810ce54bb",
      "stableKey": "aave-v3:sonic:sts-collateral-arfc-approval-2025-04",
      "version": 1,
      "eventDate": "2025-04-14",
      "publishedAt": "2026-08-22T14:05:41.464Z",
      "title": "Aave approves stS collateral parameters for its Sonic market",
      "category": "economic_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Add stS to Aave v3 Sonic Instance",
          "authority": "Aave Governance Forum",
          "url": "https://governance.aave.com/t/arfc-add-sts-to-aave-v3-sonic-instance/21445",
          "documentType": "official_governance_record",
          "publishedOn": "2025-03-15"
        }
      ],
      "whatHappened": "Aave's ARFC Snapshot approved advancing stS as collateral on Aave V3 Sonic, with a 30 million stS supply cap, CAPO pricing, and a high-efficiency stS/wS E-mode configuration.",
      "whatChanged": "The proposal advanced to the AIP stage with concrete collateral, liquidation, cap, oracle, and E-mode parameters. If executed, it would introduce a slashable liquid-staking-token dependency and enable leveraged stS/wS positions.",
      "whatDidNotChange": "The ARFC approval did not list stS on-chain or make the reserve live. It did not change Ketju's approved Aave exposure or establish stS as client-appropriate.",
      "confirmedFacts": [
        "The ARFC vote passed on April 14 with quorum and YAE as the winning option.",
        "The proposed regular-mode stS LTV and liquidation threshold were 66% and 68%.",
        "The proposed stS/wS liquid E-mode LTV and liquidation threshold were 87% and 90%.",
        "The proposal specified a 30 million stS supply cap and CAPO pricing based on the stS exchange rate and S price feed."
      ],
      "unresolved": [
        "The final AIP payload, vote, and execution date.",
        "Live oracle, CAPO, liquidity, liquidation, slashing, and 14-day native-unbonding performance after onboarding.",
        "Whether proposed liquidity commitments materialized.",
        "Whether stS concentration or validator exposure changed before execution."
      ],
      "advisorDiligenceImplications": [
        "Review Aave's Sonic collateral and liquidation dependency map before any stS reserve is treated as acceptable.",
        "Monitor the AIP and verify executed parameters, oracle configuration, caps, and live exit liquidity.",
        "Do not extend Ketju approval from the watched Aave protocol to stS or leveraged Sonic strategies."
      ],
      "followUpOn": "2025-04-30",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-e5961d847827d04ebc494eb9",
      "stableKey": "coinbase-bridge:base-mainnet-transaction-delays:2025-04-09",
      "version": 1,
      "eventDate": "2025-04-09",
      "publishedAt": "2026-08-22T14:05:41.464Z",
      "title": "Base recovers from mainnet transaction delays caused by a batcher backlog",
      "category": "market_stress",
      "posture": "postmortem",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "coinbase-bridge",
          "name": "Base canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Mainnet transaction delays",
          "authority": "Base Status",
          "url": "https://status.base.org/incidents/39v7s5rb39xg",
          "documentType": "official_status_postmortem",
          "publishedOn": "2025-04-09"
        }
      ],
      "whatHappened": "A transaction-volume spike created a Base batcher backlog. The sequencer temporarily reduced block sizes while pending data was submitted to Ethereum, causing some user transactions to be delayed or dropped and some nodes to fall behind.",
      "whatChanged": "For approximately three hours, effective mainnet transaction capacity fell to roughly one-third of its target and users could need to resubmit dropped transactions. The incident exposed batcher throughput and node synchronization as operational dependencies for timely Base bridge use.",
      "whatDidNotChange": "Base reported that user funds were never at risk, normal processing recovered, and no bridge custody, withdrawal contract, dispute-game authority, pause role, or finality rule changed.",
      "confirmedFacts": [
        "The incident began on April 9, 2025 at approximately 01:15 UTC.",
        "The sequencer reduced block sizes to about 20 Mgas versus a 60 Mgas target for roughly three hours.",
        "Some transactions were delayed or dropped from the mempool, and some node operators experienced synchronization problems.",
        "Base reported that the backlog cleared, normal processing resumed, and the incident was fully resolved."
      ],
      "unresolved": [
        "Whether the planned batching and mempool changes were subsequently deployed and independently verified.",
        "The recurrence risk under a comparable transaction-volume or L1-submission backlog.",
        "Whether any bridge-specific transactions experienced materially longer completion than the broader transaction-pool impact described."
      ],
      "advisorDiligenceImplications": [
        "Review the Base bridge memo's operational assumptions for sequencer, batcher, RPC, and node availability.",
        "Preserve transaction resubmission and alternate-RPC procedures in the bridge operating runbook; the resolved event does not independently require restricting the approved bridge."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-b3a166a7f1a2c7c7989139e9",
      "stableKey": "aave-v3:ethereum:chainlink-svr-phase-1:2025-03-29",
      "version": 1,
      "eventDate": "2025-03-29",
      "publishedAt": "2026-08-22T14:05:40.668Z",
      "title": "Aave activates Chainlink SVR on four Ethereum markets",
      "category": "economic_change",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Aave <> Chainlink SVR v1: Phase 1 activation",
          "authority": "Aave Governance / BGD Labs",
          "url": "https://governance.aave.com/t/arfc-aave-chainlink-svr-v1-phase-1-activation/21247",
          "documentType": "official governance and activation record",
          "publishedOn": "2025-03-04"
        }
      ],
      "whatHappened": "Aave activated Chainlink Smart Value Recapture feeds on its Ethereum V3 markets for LBTC, tBTC, LINK, and AAVE.",
      "whatChanged": "The selected markets began using SVR oracle paths that auction liquidation-related oracle extractable value through MEV infrastructure, with fallback feeds and a steward-controlled rollback path. This changed oracle timing, liquidation execution dependencies, and revenue allocation.",
      "whatDidNotChange": "The initial phase excluded ETH, wstETH, WBTC, and other major markets. Standard Chainlink fallback feeds remained available, and the activation did not establish that SVR was risk-free or suitable for other Aave markets.",
      "confirmedFacts": [
        "The activation occurred on March 29, 2025.",
        "The initial markets were LBTC, tBTC, LINK, and AAVE on Aave V3 Ethereum.",
        "The design used fallback feeds and allowed the Protocol Guardian to restore prior oracle feeds through the SVR steward.",
        "The official follow-up reported liquidations through SVR without technical issues or bad-debt accrual during the first observed period."
      ],
      "unresolved": [
        "Longer-term oracle latency, searcher participation, and recapture efficiency were not established at activation.",
        "Expansion to ETH, WBTC, wstETH, or other larger markets remained contingent on later governance and operating evidence.",
        "The event does not resolve broader governance-risk concerns in the Aave memo."
      ],
      "advisorDiligenceImplications": [
        "Review Aave diligence for the new Flashbots and SVR oracle-path dependencies and Guardian rollback authority.",
        "Verify whether any client or approved market consumes an SVR-enabled feed before relying on prior liquidation-mechanics analysis.",
        "Do not generalize the pilot's early operating results to all Aave reserves."
      ],
      "followUpOn": "2025-04-09",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-2fd34879770d002f668a3a58",
      "stableKey": "aave-v3:bnb:lisusd-onboarding-temp-check-2025-03",
      "version": 1,
      "eventDate": "2025-03-26",
      "publishedAt": "2026-08-22T14:05:40.668Z",
      "title": "Aave advances proposed lisUSD onboarding to ARFC review",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Onboard lisUSD to Aave V3 BNB Instance",
          "authority": "Aave Governance / Aave Chan Initiative",
          "url": "https://governance.aave.com/t/temp-check-onboard-lisusd-to-aave-v3-bnb-instance/21309",
          "documentType": "official governance proposal",
          "publishedOn": "2025-03-07"
        }
      ],
      "whatHappened": "Aave's preliminary governance poll supported advancing a proposal to list lisUSD in the Aave V3 BNB Core pool.",
      "whatChanged": "lisUSD entered Aave's formal asset-onboarding and risk-review pipeline. The proposal would add a new stablecoin reserve if it later passed ARFC and on-chain governance.",
      "whatDidNotChange": "The TEMP CHECK did not authorize or execute a lisUSD reserve, set final risk parameters, or alter Ketju's Ethereum sGHO-only Aave approval.",
      "confirmedFacts": [
        "The official proposal sought to onboard lisUSD to Aave V3 on BNB Chain.",
        "The TEMP CHECK reached quorum and passed on March 26 with ARFC identified as the next stage.",
        "No final reserve parameters were specified at the TEMP CHECK stage."
      ],
      "unresolved": [
        "Asset audits, collateral composition, liquidity concentration, peg resilience, caps, and liquidation parameters required further review.",
        "The separate March 15 LISUSD price deviation was not established by primary evidence and had not been reconciled in this proposal stage.",
        "Final ARFC and on-chain approval remained outstanding."
      ],
      "advisorDiligenceImplications": [
        "Monitor the ARFC for primary risk-provider analysis and final parameters.",
        "Do not treat preliminary governance support as a live or Ketju-approved reserve.",
        "Preserve the March peg observation as an unresolved diligence question rather than a confirmed impairment."
      ],
      "followUpOn": "2025-04-01",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-3e8d1bce0ed0dfab77fffe38",
      "stableKey": "lido:starknet-wsteth:reendorsement-proposal-2025-03",
      "version": 1,
      "eventDate": "2025-03-26",
      "publishedAt": "2026-08-22T14:05:40.668Z",
      "title": "Lido opens a vote to re-endorse Starknet wstETH bridge endpoints",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "mixed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Re-endorsement of wstETH on Starknet",
          "authority": "Lido Governance",
          "url": "https://research.lido.fi/t/re-endorsement-of-wsteth-on-starknet/9725",
          "documentType": "official governance proposal",
          "publishedOn": "2025-03-10"
        }
      ],
      "whatHappened": "Lido governance opened a Snapshot on a Starknet Foundation proposal to recognize new Starknet wstETH bridge endpoints as canonical and transfer governance roles to Lido DAO.",
      "whatChanged": "A concrete governance path was opened for restoring canonical status after a legacy-token migration and prior offboarding. This expanded the Lido research perimeter to the replacement Starknet deployment and its governance-forwarder controls.",
      "whatDidNotChange": "The March event did not itself re-endorse the endpoints, complete the governance-role transfer, or change Ethereum stETH withdrawal mechanics. Ketju's Lido approval remained limited to Ethereum.",
      "confirmedFacts": [
        "The official Lido forum proposal identifies the new and legacy Starknet wstETH contracts and the governance forwarder.",
        "The proposal states that governance roles would transfer to Lido DAO only if the proposal passed.",
        "The Snapshot began on March 26 and was scheduled to end April 3."
      ],
      "unresolved": [
        "The proposal described the migration as complete while also stating that legacy-token migrations continued.",
        "The Network Expansion Committee's technical and process objections had not been resolved during March.",
        "The vote outcome, role-transfer execution, and post-execution verification were not established within the event window."
      ],
      "advisorDiligenceImplications": [
        "Monitor the proposal as a possible new Lido bridge/control surface, not as approval of Starknet wstETH.",
        "Require verified role-transfer transactions and deployment verification before treating the replacement endpoints as canonical.",
        "Do not infer that audits, migration progress, or DAO endorsement would make the bridged asset appropriate for clients."
      ],
      "followUpOn": "2025-04-03",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-7e4ce42553899d3ac903b981",
      "stableKey": "lido:lip-27-pectra-compatibility-snapshot-2025-03",
      "version": 1,
      "eventDate": "2025-03-24",
      "publishedAt": "2026-08-22T14:05:40.668Z",
      "title": "Lido advances its Pectra compatibility upgrade",
      "category": "upgrade_migration",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "LIP 27: Ensuring Compatibility with Ethereum's Pectra Upgrade",
          "authority": "Lido Governance",
          "url": "https://research.lido.fi/t/lip-27-ensuring-compatibility-with-ethereum-s-pectra-upgrade/9444",
          "documentType": "official improvement and governance proposal",
          "publishedOn": "2025-01-30"
        }
      ],
      "whatHappened": "Lido's Snapshot supported advancing LIP-27, a compatibility upgrade for Ethereum's Pectra hardfork.",
      "whatChanged": "The plan would increment consensus versions for Lido's Accounting, Validator Exit Bus, and CSM oracles, replace the CS Verifier, and later revise Oracle Report Sanity Checker parameters.",
      "whatDidNotChange": "The March signal did not execute the upgrade. It deliberately excluded new Pectra features such as triggerable withdrawals and validator consolidation, and no deposit pause had fired.",
      "confirmedFacts": [
        "The Snapshot ran March 17–24 and reached quorum with a large majority in favor.",
        "The proposed pre-fork work covered oracle consensus versions and replacement of the CS Verifier.",
        "A separate post-fork vote was contemplated for Oracle Report Sanity Checker parameters.",
        "The proposal described pausing deposits as a fallback if compatibility changes could not be safely approved."
      ],
      "unresolved": [
        "External audits, deployment verification, and the on-chain vote were still pending during March.",
        "The fallback deposit pause had not been invoked.",
        "Final execution timing depended on Ethereum's Pectra schedule and later Lido votes."
      ],
      "advisorDiligenceImplications": [
        "Review Lido diligence because accounting-oracle and verifier behavior are core dependencies of stETH balances and validator accounting.",
        "Monitor for execution and any fallback deposit pause; a pause would require an immediate memo response.",
        "Do not infer compatibility readiness or safety from the preliminary Snapshot alone."
      ],
      "followUpOn": "2025-04-10",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-f4206fdc3867db1bd564dbc6",
      "stableKey": "lido:mev-relay-allowlist-easytrack-proposal-2025-03",
      "version": 1,
      "eventDate": "2025-03-24",
      "publishedAt": "2026-08-22T14:05:40.668Z",
      "title": "Lido advances EasyTrack management of its MEV relay allowlist",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Introduce EasyTrack Factories for Managing MEV-Boost Relay Allowed List",
          "authority": "Lido Governance",
          "url": "https://research.lido.fi/t/introduce-easytrack-factories-for-managing-mev-boost-relay-allowed-list/9638",
          "documentType": "official control-change proposal",
          "publishedOn": "2025-02-28"
        }
      ],
      "whatHappened": "Lido's Snapshot supported adding EasyTrack factories through which the Relay Maintenance Committee could add, edit, or remove entries in the MEV-Boost Relay Allowed List.",
      "whatChanged": "The proposed design would make EasyTrack's EVMScriptExecutor the allowlist manager and use the Relay Maintenance Committee as trusted caller, replacing a manual multisignature update workflow with challengeable EasyTrack motions.",
      "whatDidNotChange": "The factories and manager-role change were not deployed in March. The Snapshot did not itself modify any relay entry or remove LDO-holder oversight.",
      "confirmedFacts": [
        "Lido node operators are required to use at least one relay from the mandatory category of the allowlist.",
        "The proposal specified Add, Edit, and Remove MEV-Boost relay factories and an EVMScriptExecutor manager role.",
        "The March Snapshot reached quorum and passed.",
        "Security audit and on-chain execution were identified as later prerequisites."
      ],
      "unresolved": [
        "Final factory code, deployed addresses, audit results, and on-chain authorization were pending during March.",
        "The operational effect on challenge periods and emergency-brake procedures required verification after deployment.",
        "No specific relay addition, removal, or reclassification was authorized by this event."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido control map for the proposed manager, trusted-caller, challenge, and emergency-brake paths.",
        "Verify final contracts and on-chain authorization before treating the workflow as operative.",
        "Continue monitoring relay concentration and availability separately from the governance mechanism."
      ],
      "followUpOn": "2025-05-13",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-d135e7090e9671302be12e87",
      "stableKey": "arbitrum-bridge:sky-usds-gateway-router-proposal-2025-03",
      "version": 1,
      "eventDate": "2025-03-20",
      "publishedAt": "2026-08-22T14:05:40.668Z",
      "title": "Sky proposes custom USDS gateway registration in Arbitrum's router",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "arbitrum-bridge",
          "name": "Arbitrum Bridge"
        },
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Register the Sky Custom Gateway contracts in the Router",
          "authority": "Arbitrum DAO Snapshot",
          "url": "https://snapshot.org/#/arbitrumfoundation.eth/proposal/0xdb22a77942eddfea9c826790ac03c3e54a34716c0a9bde846399cffe6046d256",
          "documentType": "governance_proposal",
          "publishedOn": "2025-03-20"
        }
      ],
      "whatHappened": "Arbitrum DAO opened a constitutional Snapshot proposal to register custom USDS and sUSDS gateways in the canonical router used by the official bridge UI.",
      "whatChanged": "A concrete governance path opened for routing two Sky assets through token-specific custom gateways instead of default gateway handling in the official UI.",
      "whatDidNotChange": "The March proposal did not change router state or authorize execution. The custom bridge contracts were already live, while official UI routing remained disabled pending governance.",
      "confirmedFacts": [
        "The proposal identified the Ethereum and Arbitrum custom gateway contracts and USDS and sUSDS token addresses.",
        "The proposal stated that the router configuration still used default gateways and that official bridge UI access was disabled for these tokens.",
        "The March Snapshot record opened a governance vote before later execution stages."
      ],
      "unresolved": [
        "Governance approval, payload verification, and execution were not completed during March.",
        "Independent verification of the final governance payload and router state remained outstanding.",
        "Registration would not itself establish the suitability or solvency of USDS or sUSDS."
      ],
      "advisorDiligenceImplications": [
        "Track the proposal because it would add a token-specific custody and upgrade path to the official Arbitrum bridge interface.",
        "Keep Sky-asset diligence separate from the Arbitrum bridge memo; router registration does not approve either asset.",
        "Require executed router state and verified gateway controls before treating the UI path as operative."
      ],
      "followUpOn": "2025-04-01",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-96aaffde01657d83a411c7ba",
      "stableKey": "optimism-bridge:upgrade-13-opcm-incident-response-proposal-2025-03",
      "version": 1,
      "eventDate": "2025-03-13",
      "publishedAt": "2026-08-22T14:05:40.668Z",
      "title": "Optimism votes on OPCM and fault-proof incident-response changes",
      "category": "upgrade_migration",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "optimism-bridge",
          "name": "Optimism canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Upgrade Proposal #13: OPCM and Incident Response improvements",
          "authority": "Optimism Collective Governance / OP Labs",
          "url": "https://gov.optimism.io/t/upgrade-proposal-13-opcm-and-incident-response-improvements/9739/1",
          "documentType": "official protocol-upgrade proposal",
          "publishedOn": "2025-03-07"
        },
        {
          "title": "Voting Cycle Guide #34",
          "authority": "Optimism Collective Governance",
          "url": "https://gov.optimism.io/t/voting-cycle-guide-34/9734",
          "documentType": "official governance process notice",
          "publishedOn": "2025-03-06"
        }
      ],
      "whatHappened": "Optimism opened governance voting on Upgrade Proposal 13, covering OP Contracts Manager, fault-proof incident-response changes, and a DeputyPauseModule.",
      "whatChanged": "The proposal created a concrete path to alter L1 upgrade orchestration, withdrawal-proof validation, dispute-game recovery, and how a designated Pause Deputy could trigger the Superchain-wide withdrawal pause.",
      "whatDidNotChange": "The March vote did not itself deploy the contracts. It did not shorten the seven-day withdrawal challenge period or require node-operator action.",
      "confirmedFacts": [
        "The proposal would introduce per-release OP Contracts Manager instances for batched contract deployment and upgrades.",
        "The proposed OptimismPortal changes separated respected-game selection from retirement timing and changed withdrawal-proof validity checks.",
        "If deployed, the upgrade would invalidate pending L1 withdrawal proofs once, requiring affected users to re-prove rather than lose assets.",
        "The DeputyPauseModule would authorize a dedicated key only to invoke the Superchain-wide pause through the existing control path.",
        "Token House voting was scheduled for March 13–19 with a Citizens' House veto period through March 26."
      ],
      "unresolved": [
        "Final approval after the veto period was not established by the candidate's discovery evidence.",
        "Deployment, final payload verification, and the planned April activation remained outside the March event posture.",
        "Operational criteria and disclosure practices for Pause Deputy key use required continued review."
      ],
      "advisorDiligenceImplications": [
        "Review the Optimism bridge memo for changed withdrawal-proof behavior and incident-response authority before deployment.",
        "Plan for possible re-proving of pending withdrawals during the eventual upgrade window.",
        "Do not treat audits or governance approval as proof that the new controls are risk-free."
      ],
      "followUpOn": "2025-03-26",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-9b32622022c89eb1731adb3e",
      "stableKey": "aave-v3:sonic-deployment:arfc-snapshot-2025-01",
      "version": 2,
      "eventDate": "2025-02-26",
      "publishedAt": "2026-08-22T14:05:40.012Z",
      "title": "Aave opens the final on-chain vote to activate v3.3 on Sonic",
      "category": "launch_access",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Aave V3.3 Sonic Activation",
          "authority": "Aave DAO",
          "url": "https://vote.onaave.com/proposal/?proposalId=257",
          "documentType": "onchain_governance_record",
          "publishedOn": "2025-02-26"
        }
      ],
      "whatHappened": "Aave governance created proposal 257 to activate an Aave v3.3 pool on Sonic with USDC, WETH, and wS.",
      "whatChanged": "The earlier deployment concept advanced to an executable on-chain proposal with initial collateral, borrowing, caps, liquidation parameters, oracle choices, and bootstrap administrator assignments.",
      "whatDidNotChange": "The proposal had not passed or executed by February 28, so it did not create a live advisor-accessible Sonic exposure inside this backfill window.",
      "confirmedFacts": [
        "Proposal 257 was created on February 26, 2025.",
        "It proposed listing USDC, WETH, and wS as borrowable collateral on Sonic.",
        "It proposed assigning the risk steward as RiskAdmin, the guardian as PoolAdmin during bootstrap, and the ACI multisig as emissions admin."
      ],
      "unresolved": [
        "The vote outcome and any execution occurred outside the February event-date boundary and are not drafted here.",
        "Live liquidity, operational performance, and bridge and oracle dependency behavior were not established within the window."
      ],
      "advisorDiligenceImplications": [
        "Update the Aave diligence file to track the concrete Sonic configuration while keeping Sonic outside the approved exposure set pending execution and live-operation evidence.",
        "Review the proposed bootstrap admin roles, oracle choices, and asset caps before any later access decision."
      ],
      "followUpOn": null,
      "previousInterpretation": "The January backfill recorded that Aave had advanced a proposed v3 deployment on Sonic, without a final executable activation payload.",
      "supersedesId": null
    },
    {
      "id": "event-event-draft-1fd24fad7dc7a5eaf68f7e90",
      "stableKey": "optimism-superchain:upgrade-12:pectra-readiness-2025-02",
      "version": 1,
      "eventDate": "2025-02-25",
      "publishedAt": "2026-08-22T14:05:40.012Z",
      "title": "Optimism proposes Pectra-readiness maintenance for OP Stack chains",
      "category": "upgrade_migration",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "optimism-bridge",
          "name": "Optimism canonical bridge"
        },
        {
          "type": "protocol",
          "id": "coinbase-bridge",
          "name": "Base canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Upgrade Proposal #12: L1 Pectra Readiness",
          "authority": "Optimism Collective",
          "url": "https://gov.optimism.io/t/upgrade-proposal-12-l1-pectra-readiness/9706",
          "documentType": "official_governance_proposal",
          "publishedOn": "2025-02-25"
        }
      ],
      "whatHappened": "Optimism published Upgrade Proposal #12 to make OP Stack node software, protocol specifications, and L1 fault-proof contracts compatible with Ethereum Pectra.",
      "whatChanged": "A concrete maintenance payload and operator-upgrade requirement entered governance. The proposal identifies EIP-7702 transaction decoding and the EIP-7685 requestsHash header field as breaking inputs that OP Stack software must support.",
      "whatDidNotChange": "Within the February window this was a proposal, not evidence that every OP Stack chain or canonical bridge had completed the upgrade. The proposal says it does not change fee take, governor/servicer roles, ossified gas limits, or related authorization structures.",
      "confirmedFacts": [
        "The official proposal was published on February 25, 2025.",
        "It states that unmodified OP Stack chains could suffer a safe-head stall, sequencing-window expiry, and a large reorganization after Pectra activates on their L1.",
        "It covers node software, protocol specifications, and fault-proof contracts and anticipates no downtime if applied before the relevant L1 activation."
      ],
      "unresolved": [
        "Approval, execution, and chain-by-chain operator adoption were not established within the backfill window.",
        "The manifest does not receipt bridge-specific deployment state for Optimism or Base."
      ],
      "advisorDiligenceImplications": [
        "Require bridge diligence to verify Pectra-ready node and fault-proof deployments before treating the Optimism and Base canonical bridges as operationally unchanged.",
        "Keep current bridge approvals under review until implementation receipts, not merely governance approval, are documented."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-50e892be644a5522dcb0ca93",
      "stableKey": "aave-v3:arbitrum:agrs-caps-oracle-activation-2025-02",
      "version": 1,
      "eventDate": "2025-02-25",
      "publishedAt": "2026-08-22T14:05:40.012Z",
      "title": "Aave activates automated supply and borrow cap updates on Arbitrum",
      "category": "control_change",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Caps Risk Oracle Activation on Arbitrum",
          "authority": "Aave DAO",
          "url": "https://vote.onaave.com/proposal/?proposalId=253",
          "documentType": "onchain_governance_record",
          "publishedOn": "2025-02-20"
        }
      ],
      "whatHappened": "Aave governance executed proposal 253, activating the automated Aave Generalized Risk Stewards system for supply and borrow caps on the Arbitrum instance.",
      "whatChanged": "Chaos Labs Edge recommendations can flow through a RiskOracle and AaveStewardCapsInjector to an AGRS contract with RiskAdmin authority. Permissionless propagation is limited to a whitelist, with maximum 30% relative cap changes and a three-day minimum delay.",
      "whatDidNotChange": "The automation is limited to supplyCap and borrowCap for the listed Arbitrum assets; it did not authorize automated LTV, liquidation-threshold, oracle-price, reserve-factor, or collateral-listing changes.",
      "confirmedFacts": [
        "Proposal 253 executed on February 25, 2025.",
        "The new steward received RiskAdmin authority for the Arbitrum instance.",
        "The record lists 15 whitelisted assets and constrains both cap types to 30% relative changes with a three-day minimum delay.",
        "The injector runs through Chainlink Automation and was funded with 50 LINK from the Arbitrum Collector."
      ],
      "unresolved": [
        "The proposal record does not by itself establish the operational reliability or governance accountability of the off-chain Edge recommendation process.",
        "Future cap recommendations and whether they remain aligned with Ketju risk limits require ongoing monitoring."
      ],
      "advisorDiligenceImplications": [
        "Add the Edge RiskOracle, injector, Chainlink Automation, and automated AGRS path to the Aave control map.",
        "Review whether three-day, 30% cap changes alter approved exposure or liquidity assumptions, and monitor actual automated updates."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-bd3fb4c37ee7cb4cda697db8",
      "stableKey": "aave-v3:aave-collateral:ltv-lt-increase-2025-02",
      "version": 1,
      "eventDate": "2025-02-25",
      "publishedAt": "2026-08-22T14:05:40.012Z",
      "title": "Aave proposes higher AAVE collateral LTV and liquidation thresholds",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "critical",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Update AAVE Token LTV/Liquidation Percentages",
          "authority": "Aave DAO",
          "url": "https://vote.onaave.com/proposal/?proposalId=255",
          "documentType": "onchain_governance_record",
          "publishedOn": "2025-02-25"
        }
      ],
      "whatHappened": "Aave governance created proposal 255 to increase AAVE collateral LTV and liquidation thresholds on Ethereum Core and Arbitrum.",
      "whatChanged": "The executable proposal would raise Ethereum Core AAVE LTV from 66% to 69% and liquidation threshold from 73% to 76%, and Arbitrum AAVE LTV from 63% to 66% and liquidation threshold from 70% to 73%.",
      "whatDidNotChange": "The vote had not closed or executed by February 28, so the on-chain collateral parameters were not yet changed within this backfill window. No other asset or Aave instance was included.",
      "confirmedFacts": [
        "Proposal 255 was created on February 25, 2025 and opened for voting on February 26.",
        "The proposal specifies three-percentage-point increases to both LTV and liquidation threshold on Ethereum Core and Arbitrum.",
        "Its motivation explicitly invokes greater borrowing power, capital efficiency, and a competitive lending environment."
      ],
      "unresolved": [
        "The final vote and execution occurred outside the February event-date boundary and are not drafted here.",
        "The retained proposal does not establish how borrower behavior or AAVE liquidity would respond after any execution."
      ],
      "advisorDiligenceImplications": [
        "Apply the written Aave kill criterion because governance publicly justified collateral-risk parameters partly through capital-efficiency and competitiveness goals.",
        "Treat new Aave exposure as unavailable pending human review of the approval memo; the event workflow itself does not change the memo or transact.",
        "Reassess endogenous-collateral and liquidation assumptions before relying on the proposed higher thresholds."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-2f59a3d9808eef130c515ab3",
      "stableKey": "aave-v3:all-instances:v3.3-upgrade-2025-02",
      "version": 1,
      "eventDate": "2025-02-24",
      "publishedAt": "2026-08-22T14:05:40.012Z",
      "title": "Aave executes the v3.3 upgrade across all active instances",
      "category": "upgrade_migration",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Upgrade Aave instances to v3.3",
          "authority": "Aave DAO",
          "url": "https://vote.onaave.com/proposal/?proposalId=252",
          "documentType": "onchain_governance_record",
          "publishedOn": "2025-02-19"
        },
        {
          "title": "BGD: Aave v3.3 (feat Umbrella)",
          "authority": "BGD Labs / Aave Governance Forum",
          "url": "https://governance.aave.com/t/bgd-aave-v3-3-feat-umbrella/20129",
          "documentType": "official_protocol_update",
          "publishedOn": "2024-12-10"
        }
      ],
      "whatHappened": "Aave governance executed proposal 252 and upgraded all active Aave v3 instances from v3.2 to v3.3.",
      "whatChanged": "The upgrade replaced pool, configurator, and pool-data-provider implementations; introduced reserve-deficit accounting and deficit-elimination hooks for later Umbrella use; and changed liquidation handling to reduce dust and improve position-wide close-factor behavior.",
      "whatDidNotChange": "Aave v3.3 did not itself activate Umbrella or prove that future deficits would be covered. The official discussion says deficit accounting remains separate from aToken exchange-rate accounting and does not imply safety or approval.",
      "confirmedFacts": [
        "BGD Labs states that proposal 252 was approved and executed on February 24, 2025.",
        "The proposal applied to all active Aave v3 instances.",
        "The upgrade introduced bad-debt logging and burn functionality plus liquidation-engine changes.",
        "The proposal cites StErMi, Certora, Oxorio, and Sherlock security reviews."
      ],
      "unresolved": [
        "Post-upgrade monitoring was still ongoing in the February 24 update.",
        "The behavior of the later Umbrella integration and any realized deficit coverage was outside this event.",
        "Audit completion does not establish absence of defects or advisor suitability."
      ],
      "advisorDiligenceImplications": [
        "Update the Aave memo's liquidation and deficit-accounting description to v3.3 and verify integrations relying on deprecated reserve-data getters.",
        "Do not describe Umbrella coverage as live solely because v3.3 added compatible accounting hooks.",
        "Review client and approved-position assumptions across every active Aave v3 instance because the implementation upgrade was global."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-8c5b1fda1cad4a2c7fb2f207",
      "stableKey": "aave-v3:megaeth-deployment:temp-check-2025-02",
      "version": 1,
      "eventDate": "2025-02-21",
      "publishedAt": "2026-08-22T14:05:40.012Z",
      "title": "Aave proposes a v3 deployment on MegaETH",
      "category": "launch_access",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "TEMP CHECK: Deploy Aave v3 on MegaETH",
          "authority": "Aave DAO",
          "url": "https://governance.aave.com/t/temp-check-deploy-aave-v3-on-megaeth/21155",
          "documentType": "official_governance_forum",
          "publishedOn": "2025-02-21"
        }
      ],
      "whatHappened": "Aave governance opened a TEMP CHECK proposing an Aave v3 pool on MegaETH.",
      "whatChanged": "MegaETH entered Aave's formal deployment-governance pipeline, expanding the potential future research perimeter for Aave v3.",
      "whatDidNotChange": "No Aave deployment, live pool, asset list, risk parameters, oracle configuration, or final approval was established during the February window.",
      "confirmedFacts": [
        "The official forum proposal is dated February 21, 2025.",
        "The proposal is a TEMP CHECK and says risk parameters would be supplied during a later ARFC stage.",
        "The stated process still required Snapshot, ARFC, and final AIP stages before enforcement."
      ],
      "unresolved": [
        "MegaETH infrastructure, oracle availability, deployment addresses, and final risk parameters were not established in this window.",
        "The proposal's later governance outcome falls outside this backfill boundary."
      ],
      "advisorDiligenceImplications": [
        "Monitor the deployment track without adding MegaETH exposure to an approved Aave perimeter.",
        "Require live contracts, deployed-address records, oracle details, and final parameters before any advisor-access assessment."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-1f97a759b7d499cce9c12236",
      "stableKey": "sky-lending:out-of-schedule-community-security:2025-02-18",
      "version": 1,
      "eventDate": "2025-02-19",
      "publishedAt": "2026-08-22T14:05:40.012Z",
      "title": "Sky passes an out-of-schedule security executive with major control and collateral changes",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "mixed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Out-of-Schedule Executive Proposal for Community Security",
          "authority": "Sky Governance Facilitators",
          "url": "https://forum.skyeco.com/t/out-of-schedule-executive-proposal-for-community-security-february-18-2025/26017",
          "documentType": "official_governance_forum",
          "publishedOn": "2025-02-18"
        },
        {
          "title": "Out-of-Schedule Executive Vote: Risk Parameter Changes",
          "authority": "Sky Governance",
          "url": "https://vote.makerdao.com/executive/template-executive-vote-out-of-schedule-executive-vote-risk-parameter-changes-february-18-2025",
          "documentType": "onchain_governance_record",
          "publishedOn": "2025-02-18"
        }
      ],
      "whatHappened": "Sky governance passed an out-of-schedule executive presented as a precaution against a potential governance attack.",
      "whatChanged": "The approved spell would reduce the GSM Pause Delay from 30 to 18 hours and reconfigure LSE-MKR-A: debt ceiling 20 million to 45 million USDS, target available debt 5 million to 45 million, cooldown 16 hours to 30 minutes, stability fee 12% to 20%, liquidation ratio 200% to 125%, and exit fee 5% to 0%.",
      "whatDidNotChange": "Primary evidence did not substantiate the alleged attack vector, identify an attacker, establish asset loss or a protocol freeze, or independently prove the spell's execution and effective state within the retained candidate evidence.",
      "confirmedFacts": [
        "Sky facilitators scheduled the executive on February 18, 2025 and said they believed a successful governance attack was very unlikely.",
        "The official forum and executive record specify the same LSE-MKR-A and GSM Pause Delay changes.",
        "A February 19 official-forum reply links the executive and states that it passed."
      ],
      "unresolved": [
        "The screenshots and whistleblower reports cited by facilitators were not published, so the underlying threat remains unverified.",
        "The execution transaction and exact effective timestamp were not established from the retained primary receipts.",
        "Community participants requested a more specific explanation of how the parameter changes mitigated the reported threat."
      ],
      "advisorDiligenceImplications": [
        "Review the Sky memo's governance-latency and collateral-risk assumptions because the approved package shortened the response delay while substantially loosening LSE-MKR-A leverage constraints.",
        "Do not treat the reported governance attack as confirmed; separately verify spell execution and resulting on-chain parameters before updating operative memo facts."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-364606f9891cb883664a3dbf",
      "stableKey": "axelar:core-v1.2.1:cobalt-fee-burn-2025-02",
      "version": 1,
      "eventDate": "2025-02-17",
      "publishedAt": "2026-08-22T14:05:40.012Z",
      "title": "Axelar approves the v1.2.1 fee-burn upgrade",
      "category": "upgrade_migration",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Axelar Core v1.2.1",
          "authority": "Axelar",
          "url": "https://github.com/axelarnetwork/axelar-core/releases/tag/v1.2.1",
          "documentType": "official_release",
          "publishedOn": "2025-02-07"
        },
        {
          "title": "Axelar v1.2 Upgrade Proposal",
          "authority": "Axelar on-chain governance",
          "url": "https://axelarscan.io/proposal/284",
          "documentType": "onchain_governance_record",
          "publishedOn": "2025-02-17"
        }
      ],
      "whatHappened": "Axelar governance passed proposal 284 to upgrade Axelar Core to v1.2.1 at the specified upgrade height.",
      "whatChanged": "The approved software changes transaction-fee allocation so the community-tax portion remains in the community pool and the remainder is burned instead of distributed to token holders.",
      "whatDidNotChange": "The retained primary evidence does not independently establish historical execution at the specified height. It does not show a change to gateway signing thresholds, validator custody, supported-chain security assumptions, or Ketju approval status, and it does not establish that the upgrade made Axelar safer.",
      "confirmedFacts": [
        "Axelar on-chain proposal 284 passed and specifies the v1.2 upgrade at height 16837700.",
        "The proposal states that AXL transaction fees will be sent to a burn address instead of distributed to token holders.",
        "The official release identifies migration, distribution, dependency, and burner-permission changes included in v1.2.1."
      ],
      "unresolved": [
        "The retained evidence does not independently confirm that historical height 16837700 executed successfully.",
        "Any effect of the new fee flow on validator incentives and dependency resilience requires memo review."
      ],
      "advisorDiligenceImplications": [
        "Review the Axelar memo's economic-security and validator-incentive assumptions against the new fee allocation.",
        "Record v1.2.1 as the operative core version for dependency diligence; do not infer a custody or bridge-security improvement from the upgrade alone."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-6cdc827b24ebb1f2bbccdbe0",
      "stableKey": "lido:ecosystem-borg-foundation:approval-2025-01",
      "version": 1,
      "eventDate": "2025-01-31",
      "publishedAt": "2026-08-22T14:04:59.369Z",
      "title": "Lido approves the Ecosystem BORG Foundation structure",
      "category": "governance",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Establishment of Lido Ecosystem BORG Foundation as a Lido-DAO-Adjacent Foundation",
          "authority": "Lido Governance Forum",
          "url": "https://research.lido.fi/t/establishment-of-lido-ecosystem-borg-foundation-as-a-lido-dao-adjacent-foundation/9345",
          "documentType": "official_governance_record",
          "publishedOn": "2025-01-16"
        }
      ],
      "whatHappened": "Lido's Snapshot vote approved establishing the Lido Ecosystem BORG Foundation as a Cayman Islands DAO-adjacent entity.",
      "whatChanged": "The approval authorized formation of an entity intended to oversee Rewards Share and Liquidity Observation Lab multisigs, support network expansion and institutional relationships, and create a separately governed operational multisig.",
      "whatDidNotChange": "No budget, treasury transfer, Easy Track factory, operational-multisig signer set, or completed wrapping of existing multisigs was approved or verified in this event.",
      "confirmedFacts": [
        "The official forum reports 56.8 million LDO supporting and 97,800 LDO rejecting the proposal.",
        "The approved structure assigns DAO appointment and removal powers over directors and an emergency supervisor.",
        "The planned scope includes Rewards Share and Liquidity Observation Lab multisigs and a new operational multisig.",
        "Later budgets, Easy Track permissions, signer configurations, and migrations require additional steps."
      ],
      "unresolved": [
        "The foundation's incorporation and final governing documents.",
        "Which existing committees and multisigs are ultimately wrapped.",
        "The operational-multisig address, signers, threshold, limits, and Easy Track controls.",
        "Future budget approvals and actual treasury exposure."
      ],
      "advisorDiligenceImplications": [
        "Add the Ecosystem BORG to Lido's governance and operational-dependency map.",
        "Verify later multisig, bridge-expansion, incentive, budget, and Easy Track implementations before treating the approved structure as operative."
      ],
      "followUpOn": "2025-03-31",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-d3bbee2f4f9006fb817c5e48",
      "stableKey": "lido:labs-borg-foundation:approval-2025-01",
      "version": 1,
      "eventDate": "2025-01-31",
      "publishedAt": "2026-08-22T14:04:59.369Z",
      "title": "Lido approves the Labs BORG Foundation structure",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Establishment of Lido Labs BORG Foundation as a Lido-DAO-Adjacent Foundation",
          "authority": "Lido Governance Forum",
          "url": "https://research.lido.fi/t/establishment-of-lido-labs-borg-foundation-as-a-lido-dao-adjacent-foundation/9344",
          "documentType": "official_governance_record",
          "publishedOn": "2025-01-16"
        }
      ],
      "whatHappened": "Lido's Snapshot vote approved establishing the Lido Labs BORG Foundation as a Cayman Islands DAO-adjacent entity for protocol development, maintenance, governance support, and committee oversight.",
      "whatChanged": "The approval authorized formation of an entity intended to legally oversee committees and multisigs that include GateSeal, Emergency Brakes, Relay Maintenance, Treasury Management, and the Simple DVT and Community Staking modules.",
      "whatDidNotChange": "The vote did not itself transfer on-chain roles, replace signers, move treasury assets, fund the foundation, deploy Easy Track factories, or alter pause, withdrawal, bridge, oracle, or staking-module parameters.",
      "confirmedFacts": [
        "The official forum reports 56.8 million LDO supporting and 87,400 LDO rejecting the proposal.",
        "The approved scope includes protocol research, development, deployment, maintenance, and governance support.",
        "The proposed wrapping perimeter includes multisigs with withdrawal-queue pause, validator-exit pause, bridge emergency, relay, treasury, and staking-module functions.",
        "The Board may oversee and replace wrapped-multisig members under participation agreements, while later on-chain and funding steps remain required."
      ],
      "unresolved": [
        "The foundation's incorporation and final governing documents.",
        "Which listed emergency and operational multisigs are ultimately wrapped.",
        "The directors, emergency supervisor, operational-multisig configuration, and practical replacement process.",
        "Later Easy Track, budget, signer, role, and asset-transfer executions."
      ],
      "advisorDiligenceImplications": [
        "Review Lido's control map as each emergency or staking-module multisig is migrated under the foundation's legal oversight.",
        "Do not describe emergency powers or on-chain authorities as changed until signer, role, threshold, and contract state are verified."
      ],
      "followUpOn": "2025-03-31",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-d7c82e536c22afe71cb9202f",
      "stableKey": "lido:curated-set:attestant-bitwise-continuation-2025-01",
      "version": 1,
      "eventDate": "2025-01-31",
      "publishedAt": "2026-08-22T14:04:59.369Z",
      "title": "Lido approves Attestant's continued operation under Bitwise ownership",
      "category": "governance",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Attestant Joins Bitwise",
          "authority": "Lido Governance Forum",
          "url": "https://research.lido.fi/t/attestant-joins-bitwise/8828",
          "documentType": "official_node_operator_governance_record",
          "publishedOn": "2025-01-16"
        }
      ],
      "whatHappened": "Lido voters approved allowing Attestant BVI Limited to continue operating in the Ethereum Curated Module after its acquisition by Bitwise.",
      "whatChanged": "The governance decision accepted Bitwise as Attestant's new ultimate owner without requiring validator exit or operator removal.",
      "whatDidNotChange": "Attestant and Bitwise stated that the team, bare-metal deployment, geography, jurisdiction, organizational structure, registry address, and validator operations would remain unchanged.",
      "confirmedFacts": [
        "The official forum reports 56.8 million LDO for continuation and 86.04 LDO against.",
        "Attestant's ultimate ownership changed to Bitwise before the January ratification vote.",
        "The operator stated that its team and infrastructure would remain intact.",
        "Bitwise stated that it did not control another Lido node operator at the time of review."
      ],
      "unresolved": [
        "Whether ownership later creates operator concentration or conflicts not present at the vote.",
        "Whether the registry name, reward address, team, infrastructure, jurisdiction, or operating model subsequently changes.",
        "Post-transition performance and compliance with Curated Module requirements."
      ],
      "advisorDiligenceImplications": [
        "Update Lido's node-operator ownership map to show Bitwise control of Attestant.",
        "Continue monitoring operator concentration, registry state, infrastructure, and performance; the approval does not establish that acquisition risk is immaterial indefinitely."
      ],
      "followUpOn": "2025-02-14",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-fa92fbd028f9b086356aecc9",
      "stableKey": "lido:curated-set:solstice-continuation-2025-01",
      "version": 1,
      "eventDate": "2025-01-31",
      "publishedAt": "2026-08-22T14:04:59.369Z",
      "title": "Lido approves Solstice's continued Curated Module operation",
      "category": "governance",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Bridgetower is now part of Solstice Staking",
          "authority": "Lido Governance Forum",
          "url": "https://research.lido.fi/t/bridgetower-is-now-part-of-solstice-staking/9135",
          "documentType": "official_node_operator_governance_record",
          "publishedOn": "2025-01-16"
        }
      ],
      "whatHappened": "Lido voters approved allowing Solstice to continue the acquired Bridgetower node operation in the Ethereum Curated Module.",
      "whatChanged": "The governance decision accepted Solstice as the operator's new corporate owner and contemplated renaming Curated Module operator number 17.",
      "whatDidNotChange": "The operator stated that the registry address, validator team, on-premise Swiss infrastructure, and delegated staking operations would remain unchanged; the January vote did not itself verify an on-chain rename.",
      "confirmedFacts": [
        "The official forum reports 51.8 million LDO for continuation and 86.74 LDO against.",
        "Solstice acquired Bridgetower's staking division, team, and resources before the January ratification vote.",
        "The operator stated that existing validators would remain managed by the same team on the same infrastructure.",
        "The registry address was expected to remain unchanged, while a name change to Solstice was separately requested."
      ],
      "unresolved": [
        "Execution and verification of the operator-name change.",
        "Whether ownership later changes the team, infrastructure, registry or reward address, jurisdiction, or concentration profile.",
        "Post-transition performance and compliance with Curated Module requirements."
      ],
      "advisorDiligenceImplications": [
        "Update Lido's node-operator ownership map and separately verify any on-chain rename.",
        "Continue monitoring ownership concentration, registry state, infrastructure, and validator performance; the approval does not remove ongoing operator-transition risk."
      ],
      "followUpOn": "2025-02-14",
      "previousInterpretation": null,
      "supersedesId": null
    },
    {
      "id": "event-event-draft-05b474336e2a9b9177a87791",
      "stableKey": "aave-v3:ethereum-core:pufeth-collateral-temp-check-2025-01",
      "version": 1,
      "eventDate": "2025-01-29",
      "publishedAt": "2026-08-22T14:04:59.369Z",
      "title": "Aave considers pufETH collateral for Ethereum Core",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[TEMP CHECK] Onboard pufETH to Aave V3 Core Instance",
          "authority": "Aave Governance Forum",
          "url": "https://governance.aave.com/t/temp-check-onboard-pufeth-to-aave-v3-core-instance/20770",
          "documentType": "official_governance_proposal",
          "publishedOn": "2025-01-23"
        }
      ],
      "whatHappened": "A pufETH collateral-onboarding TEMP CHECK for Aave v3 Ethereum Core advanced to a Snapshot vote.",
      "whatChanged": "If later approved and executed, Ethereum Core would add liquid-restaking collateral with Puffer, EigenLayer, exchange-rate, withdrawal-liquidity, slashing, and privileged-control dependencies.",
      "whatDidNotChange": "The TEMP CHECK contained no final risk parameters and did not authorize or execute an asset listing. Existing collateral, oracle, liquidation, and borrowing configurations were unchanged.",
      "confirmedFacts": [
        "The target market is Aave v3 Ethereum Core.",
        "The proposal identifies pufETH as a proposed collateral asset.",
        "The official forum states that the TEMP CHECK advanced to Snapshot on January 29.",
        "An Aave-funded risk contributor opposed onboarding at that stage, citing declining supply, reduced liquidity, pricing complexity, double-slashing exposure, and no active bug bounty."
      ],
      "unresolved": [
        "The TEMP CHECK result and whether the proposal advances through ARFC and AIP stages.",
        "Final oracle design, collateral factors, liquidation settings, caps, and e-mode treatment.",
        "Whether pufETH liquidity, withdrawals, incentives, and security controls support the proposed risk parameters."
      ],
      "advisorDiligenceImplications": [
        "Monitor the governance process and require a position-specific collateral and dependency review before treating pufETH as acceptable.",
        "Do not change the existing Aave approval or describe pufETH as supported based on the TEMP CHECK."
      ],
      "followUpOn": "2025-02-05",
      "previousInterpretation": null,
      "supersedesId": null
    }
  ],
  "versions": [
    {
      "id": "event-13de2c76-eb4c-41aa-a1be-a08b4ff85afe",
      "stableKey": "defi-saver-asset-management-tvl-exodus-2026-08-30",
      "version": 1,
      "eventDate": "2026-08-30",
      "publishedAt": "2026-08-30T16:06:54.232Z",
      "title": "DeFi Saver tracked TVL declines 27% between observations",
      "category": "market_stress",
      "posture": "confirmed",
      "materiality": "material",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "other",
          "id": "defi-saver-asset-management",
          "name": "DeFi Saver Asset Management"
        }
      ],
      "primaryDocuments": [
        {
          "title": "DeFi Saver protocol TVL fell 27% since the last observation, from $309.2M to $225.5M",
          "authority": "Ketju quantitative monitor",
          "url": "https://monitor.ketjuresearch.com/alerts.json#protocol-tvl-exodus%7Cdefi-saver-asset-management%7C2026-08-30T11%3A00%3A26.803Z",
          "documentType": "reproducible state observation",
          "publishedOn": "2026-08-30"
        }
      ],
      "whatHappened": "Ketju's quantitative monitor observed DeFi Saver Asset Management tracked TVL decline from $309.2 million to $225.5 million, a 27% reduction, by 2026-08-30T11:00:26.803Z.",
      "whatChanged": "The aggregate value attributed to positions with active DeFi Saver automation subscriptions decreased by approximately $83.7 million between monitor observations.",
      "whatDidNotChange": "The observation does not confirm a protocol exploit, client loss, withdrawal failure, automation outage, contract change, or impairment of any underlying lending position. It also does not establish that the decline represents funds exiting rather than automation subscriptions ending, position changes, or a data-classification issue.",
      "confirmedFacts": [
        "The monitor measured tracked TVL of $225,501,461 after a prior observation of $309,157,875.",
        "The measured decline was 27%.",
        "DeFi Saver Asset Management is a Ketju-approved-with-limits dependency rather than a standalone allocation."
      ],
      "unresolved": [
        "Whether the decline reflects genuine position exits, discontinued automation subscriptions, changes in underlying positions, or a data discontinuity.",
        "Whether the decline is sustained in subsequent observations.",
        "Whether any client-held automated positions or DeFi Saver services experienced operational problems."
      ],
      "advisorDiligenceImplications": [
        "Reopen memo defi-saver-asset-management to reconcile the TVL decline against subsequent observations and underlying protocol balances.",
        "Verify that any client use remains limited to the approved automation dependency and that each underlying protocol remains separately approved.",
        "Do not infer loss or impaired exit from the TVL observation alone."
      ],
      "followUpOn": "2026-08-31",
      "previousInterpretation": "DeFi Saver was approved with limits as an automation dependency, with tracked TVL treated as aggregate value of subscribed underlying positions rather than pooled protocol assets.",
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-c93e3018-e471-4959-b787-deb3753032a4",
      "stableKey": "aave-v3-gho-prime-tvl-exodus-2026-08-26",
      "version": 1,
      "eventDate": "2026-08-26",
      "publishedAt": "2026-08-26T20:23:58.625Z",
      "title": "Aave v3 GHO Prime Instance deposits fall 40% between checks",
      "category": "market_stress",
      "posture": "confirmed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        },
        {
          "type": "product",
          "id": "41683a7c-20a2-4cd7-83a7-3ccedaad0db1",
          "name": "Aave v3 GHO Prime Instance on Ethereum"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Aave v3 GHO Prime Instance deposit exodus observation",
          "authority": "Ketju quantitative monitor",
          "url": "https://monitor.ketjuresearch.com/alerts.json#tvl-exodus%7C41683a7c-20a2-4cd7-83a7-3ccedaad0db1%7C2026-08-26T11%3A00%3A21.733Z",
          "documentType": "quantitative monitor observation",
          "publishedOn": "2026-08-26"
        }
      ],
      "whatHappened": "Ketju's quantitative monitor observed deposits in the Ethereum GHO Prime Instance decline from about $12.6 million to $7.6 million between checks.",
      "whatChanged": "Observed venue deposits fell 40%, reducing the liquidity base and warranting an immediate check of exit depth and the cause of the outflow.",
      "whatDidNotChange": "The observation does not establish an exploit, bad debt, frozen assets, halted withdrawals, a GHO peg failure, or a change to Aave contracts or governance parameters.",
      "confirmedFacts": [
        "The monitored pool is Aave v3 GHO Prime Instance on Ethereum.",
        "Deposits declined from $12,587,260 to $7,600,955 between monitor checks.",
        "The measured decline was 40%."
      ],
      "unresolved": [
        "Whether the decline reflects ordinary depositor movement, a data discontinuity, incentives, a governance change, or emerging risk.",
        "Whether current on-chain liquidity can support the memo's contemplated exit size without material slippage."
      ],
      "advisorDiligenceImplications": [
        "Recheck the venue's withdrawable liquidity and reconcile the monitor observation before treating its displayed capacity as unchanged.",
        "Review the Aave v3 memo and any client decision files referencing this specific pool; the observation alone does not justify claiming an incident."
      ],
      "followUpOn": "2026-08-27",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-c03875df-fc19-4122-a22e-3ad6704a7b25",
      "stableKey": "lido-cmc-deposit-reserve-target-easy-track",
      "version": 1,
      "eventDate": "2026-08-25",
      "publishedAt": "2026-08-26T20:23:38.059Z",
      "title": "Lido proposal would delegate deposit-reserve targeting to CMC Easy Track",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Proposal: Add Easy Track factory for Deposit Reserve Target management by CMC",
          "authority": "Lido Governance",
          "url": "https://research.lido.fi/t/proposal-add-easy-track-factory-for-deposit-reserve-target-management-by-cmc/11827",
          "documentType": "official governance proposal",
          "publishedOn": "2026-08-25"
        }
      ],
      "whatHappened": "A Lido governance proposal would add an Easy Track factory allowing the CMC 5-of-9 multisig to adjust Lido's depositsReserveTarget up to 9,600 ETH.",
      "whatChanged": "The proposal creates a concrete path to delegate recurring control over how buffered ETH is prioritized between new consensus-layer deposits and withdrawal finalization during withdrawal pressure.",
      "whatDidNotChange": "The proposal is not yet approved or executed. The current role assignment and reserve target are not shown as changed, and the proposed permission cannot transfer funds, mint, burn, or change fees.",
      "confirmedFacts": [
        "The proposed trusted caller is the CMC 5-of-9 multisig at 0x2570e0b22AD904501dfB0d49575991ACB801dD91.",
        "The proposed factory is limited to Lido.setDepositsReserveTarget(uint256).",
        "The proposed immutable maximum target is 9,600 ETH.",
        "The DAO Agent would retain the ability to set the target directly, revoke the permission, or remove the factory."
      ],
      "unresolved": [
        "Completion and findings of the planned security audit.",
        "Whether the next Aragon vote will grant BUFFER_RESERVE_MANAGER_ROLE and register the factory.",
        "The final review cadence and reporting format for CMC motions.",
        "Whether any later execution reaches Ketju's withdrawal-mechanism kill criterion."
      ],
      "advisorDiligenceImplications": [
        "Monitor the audit, Aragon vote, and any executed Easy Track motions because the delegated parameter affects withdrawal-finalization priority under stress.",
        "Do not mark the Lido withdrawal-mechanism criterion as fired while the change remains only proposed."
      ],
      "followUpOn": "2026-09-01",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-f06e2693-0d74-47f4-bc10-e83ef8435479",
      "stableKey": "aave-v3-august-2026-stablecoin-rate-adjustments",
      "version": 1,
      "eventDate": "2026-08-24",
      "publishedAt": "2026-08-26T20:24:09.082Z",
      "title": "Aave service provider proposes broad stablecoin rate repricing",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "critical",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[Risk Stewards] August 2026 - Stablecoin Interest Rate Adjustments",
          "authority": "Aave governance / TokenLogic",
          "url": "https://governance.aave.com/t/risk-stewards-august-2026-stablecoin-interest-rate-adjustments/25519",
          "documentType": "official governance proposal",
          "publishedOn": "2026-08-24"
        }
      ],
      "whatHappened": "TokenLogic proposed staged changes across Aave v3 stablecoin interest-rate curves, including Slope1 increases, lower Slope2 on X Layer, a 5.25% USDe base rate, and temporary optimal-utilization increases intended to accommodate debt migration.",
      "whatChanged": "A concrete Risk Steward execution plan now exists for broad economic changes. Its stated rationale includes competitive positioning, retaining and attracting demand, and projected market growth, which plausibly matches a written Ketju Aave kill criterion.",
      "whatDidNotChange": "The cached record does not prove that any parameter step has executed. It does not directly change the approved Ethereum sGHO vault's withdrawal mechanics, and its forecasts are disputed in the same thread.",
      "confirmedFacts": [
        "TokenLogic published the proposal on August 24, 2026.",
        "The proposal recommends Slope1 increases for 22 reserves, generally in 10-basis-point stages.",
        "It proposes setting the USDe base rate to 5.25% and standard Slope1 to 0.25%.",
        "It proposes temporary two-percentage-point optimal-utilization increases for selected USDC and USDT reserves.",
        "The proposal says execution would use Risk Steward authority and span approximately two weeks."
      ],
      "unresolved": [
        "Which parameter changes, if any, have executed on-chain.",
        "Whether the USDe yield and migration assumptions are supportable; forum respondents dispute the derivation and projected borrower behavior.",
        "Whether governance will revise, pause, or split the USDe component before execution.",
        "Whether the conduct is sufficient for an editor to treat the written kill criterion as definitively fired rather than plausibly fired."
      ],
      "advisorDiligenceImplications": [
        "Open an immediate review of the Aave v3 memo because the proposal publicly frames risk parameters partly through growth and competitive-market objectives.",
        "Do not state that rates have changed until Risk Steward transactions or reproducible on-chain state confirm execution.",
        "Assess the governance rationale separately from direct exposure: Ketju's approved sleeve is narrow, but the criterion monitors the decision process that previously produced collateral risk."
      ],
      "followUpOn": "2026-08-27",
      "previousInterpretation": "Aave v3 remained approved with limits because post-incident governance safeguards and monitoring were expected to prevent a repeat of growth-driven risk decisions.",
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-e2004127-6093-4e08-8223-10cd555131e6",
      "stableKey": "axelar-v1-5-3-upgrade",
      "version": 1,
      "eventDate": "2026-08-23",
      "publishedAt": "2026-08-26T20:23:23.457Z",
      "title": "Axelar governance approves axelar-core v1.5.3 upgrade",
      "category": "upgrade_migration",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Axelar v1.5.3 Upgrade Proposal",
          "authority": "Axelar on-chain governance",
          "url": "https://axelarscan.io/proposal/495",
          "documentType": "on-chain governance proposal",
          "publishedOn": "2026-08-23"
        }
      ],
      "whatHappened": "Axelar on-chain governance proposal 495 passed, authorizing an upgrade of axelar-core to v1.5.3.",
      "whatChanged": "The v1.5.3 network upgrade is governance-approved. The associated official release describes a Cosmos SDK, IBC-Go and Wasmd migration plus vote-handling, queue-ordering, fee-policy and hardening changes.",
      "whatDidNotChange": "The candidate record does not establish that the upgrade has executed at a block height or that all validators are running the new binary.",
      "confirmedFacts": [
        "Axelar proposal 495 identifies axelar-core v1.5.3 as the intended upgrade.",
        "The proposal status is passed.",
        "An official v1.5.3 release build exists for networks that have not yet run the upgrade."
      ],
      "unresolved": [
        "The scheduled upgrade height and whether execution has occurred.",
        "Whether validator adoption and post-upgrade chain operation are healthy.",
        "Whether downstream integrations require configuration or compatibility review."
      ],
      "advisorDiligenceImplications": [
        "Review Axelar dependency diligence for the approved architecture and security changes before treating the new version as operative.",
        "Monitor the execution height and chain behavior; approval and release publication do not prove successful migration."
      ],
      "followUpOn": "2026-08-28",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-77c52ba7b212f01671604796",
      "stableKey": "rocket-pool:rpip-84-signaling-governance:2026-08",
      "version": 1,
      "eventDate": "2026-08-19",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "Rocket Pool pDAO approves RocketDash signaling platform and emergency replacement process",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "rocket-pool",
          "name": "Rocket Pool"
        }
      ],
      "primaryDocuments": [
        {
          "title": "pDAO Signaling Governance",
          "authority": "Rocket Pool pDAO Snapshot",
          "url": "https://snapshot.org/#/rocketpool-dao.eth/proposal/0xe856fea4f85ea5fb7488402b1073ff8cec9b9f6cec58e9173921cc5c42bbd3c3",
          "documentType": "official governance vote",
          "publishedOn": "2026-08-05"
        }
      ],
      "whatHappened": "Rocket Pool's pDAO approved RPIP-84, replacing Snapshot with RocketDash as the recognized platform for off-chain signaling votes, naming an initial lead vote administrator, and adding a narrowly scoped on-chain emergency process for changing the signaling platform or its administrators.",
      "whatChanged": "The recognized off-chain signaling venue and official vote-publishing authority were approved for replacement. Future emergency platform and administrator changes can use the specified on-chain process and then be recorded in RPIP-84.",
      "whatDidNotChange": "The vote did not alter rETH economics, node registration, oracle reporting, withdrawal mechanics, or smart-contract upgrade authority. It did not grant the emergency process authority over subjects other than the signaling platform and required administrators.",
      "confirmedFacts": [
        "The final vote recorded 11,108.35 votes for, zero against, and 1,071.97 abstaining.",
        "The 12,180.32 total score exceeded the stated 10,050 quorum.",
        "RPIP-84 designates RocketDash as the recognized platform for off-chain pDAO signaling votes.",
        "Darren Langley was designated as the initial lead vote administrator.",
        "The emergency ballot scope is limited to changing the recognized signaling platform and appointing the administrators needed to operate it."
      ],
      "unresolved": [
        "The date on which RocketDash becomes the sole operational venue was not independently observed.",
        "The final RPIP-84 record and administrator roster should be reconciled after the vote.",
        "Operational controls over RocketDash publication, authentication, availability, and archival continuity require review."
      ],
      "advisorDiligenceImplications": [
        "Update the Rocket Pool governance-control map so monitoring follows RocketDash and the recognized vote administrators rather than relying solely on Snapshot.",
        "Document the emergency platform-change path as a governance dependency and verify how advisors can authenticate official votes and historical records.",
        "No current rETH allocation limit or protocol availability change is supported solely by this governance-platform change."
      ],
      "followUpOn": "2026-08-26",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-5e14372b2fa49dd2cb6b1676",
      "stableKey": "aave-v3:low-adoption-deprecation-arfc:2026-08",
      "version": 1,
      "eventDate": "2026-08-15",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "Aave ARFC advances broad V3 reserve and deployment wind-down",
      "category": "closure_deprecation",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Low Adoption Asset Deprecation on Aave V3",
          "authority": "Aave DAO Snapshot",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0x4ec0c13baf55472ecd538a2fae4bbdb60f30c96621a97ecf4db073b3e65597c7",
          "documentType": "official governance vote",
          "publishedOn": "2026-08-11"
        }
      ],
      "whatHappened": "An Aave DAO ARFC vote closed with final support for winding down 50 low-adoption reserves, 21 matured Pendle principal tokens, and whole Aave V3 deployments on Sonic, Scroll, zkSync, Metis, Soneium, and Aptos.",
      "whatChanged": "The proposal cleared the Snapshot signaling stage and can advance toward an executable AIP. Its specified wind-down path includes freezes, supply and borrow caps reduced to 1, higher reserve factors, and possible later interest-rate or liquidation-threshold changes.",
      "whatDidNotChange": "The Snapshot result did not itself execute an AIP or alter reserve parameters. Existing collateral positions may remain open under the proposed default mechanics, and Aave V3 as a whole was not approved for shutdown.",
      "confirmedFacts": [
        "The final Snapshot result recorded 395,522.02 votes for, zero against, and zero abstaining.",
        "The individual-reserve scope covers 50 reserves and 21 matured Pendle PTs across eleven deployments.",
        "The proposal also covers whole-market deprecations on Sonic, Scroll, zkSync, Metis, Soneium, and Aptos.",
        "The default proposed mechanics freeze reserves, reduce supply and borrow caps to 1, and raise reserve factors where borrowing exists.",
        "The proposal states that further interest-rate or liquidation-threshold changes may be applied case by case."
      ],
      "unresolved": [
        "No executable AIP transaction or completed parameter change was established for this candidate.",
        "The final AIP payload, implementation sequence, and any modifications to the ARFC specification remain unresolved.",
        "Ketju or client exposure to each named reserve and deployment has not been mapped in this editorial decision."
      ],
      "advisorDiligenceImplications": [
        "Map all approved and client-held Aave V3 positions against the proposed reserve and deployment list before an AIP executes.",
        "Treat any affected reserve as a potential exit-planning issue because freezing and higher reserve factors can reduce new activity, supplier yield, and available liquidity.",
        "Review the aave-v3 memo's approved market perimeter; do not interpret this risk-surface reduction proposal as a protocol-wide safety improvement."
      ],
      "followUpOn": "2026-08-22",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-8bca5a705ffc422a860f7b9b",
      "stableKey": "morpho-blue:dao-multisig:spearbit-6-of-10",
      "version": 1,
      "eventDate": "2026-08-14",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "Morpho proposes adding Spearbit and raising the DAO multisig threshold",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "morpho-blue",
          "name": "Morpho Blue"
        },
        {
          "type": "controller",
          "id": "morpho-dao",
          "name": "Morpho DAO"
        }
      ],
      "primaryDocuments": [
        {
          "title": "MIP 133 - Add Spearbit as a DAO multisig signer and update threshold to 6/10",
          "authority": "Morpho Governance Forum (Morpho Association)",
          "url": "https://forum.morpho.org/t/mip-133-add-spearbit-as-a-dao-multisig-signer-and-update-threshold-to-6-10/2383",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-08-14"
        }
      ],
      "whatHappened": "Morpho Association proposed adding Spearbit as a tenth signer of the Ethereum DAO multisig and increasing its execution threshold to 6-of-10.",
      "whatChanged": "If approved and implemented, DAO operations would require six approvals, and Spearbit would provide paid trusted-signer services.",
      "whatDidNotChange": "No execution was confirmed. The proposal does not change Morpho Blue contracts, vault curators, market parameters, withdrawal mechanics, or user custody.",
      "confirmedFacts": [
        "The proposal would add Spearbit as a DAO multisig signer.",
        "The proposed threshold is 6-of-10.",
        "The proposed initial annual service cost is $33,000, with separately billed off-cycle and urgent work.",
        "The proposal requires approval before signer onboarding and multisig reconfiguration."
      ],
      "unresolved": [
        "The final vote outcome.",
        "Spearbit's final signer address and completed onboarding state.",
        "The executed multisig owner set and threshold.",
        "Whether the higher quorum materially affects routine or urgent execution times."
      ],
      "advisorDiligenceImplications": [
        "Monitor the vote and verify the Ethereum DAO multisig's final owners and threshold if implemented.",
        "Update the Morpho governance-control record after execution while keeping curator and vault-level controls separately assessed."
      ],
      "followUpOn": "2026-08-22",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-e1c01346adc527eee6c1d872",
      "stableKey": "grove-finance:dpau:sky-pas-configurator-admin",
      "version": 1,
      "eventDate": "2026-08-13",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "Grove proposes granting Sky PAS administrator authority over DPAU controls",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "grove-finance",
          "name": "Grove"
        },
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[August 27, 2026] - Proposed Changes to Grove for Upcoming Spell",
          "authority": "Sky Forum (Grove Labs)",
          "url": "https://forum.skyeco.com/t/august-27-2026-proposed-changes-to-grove-for-upcoming-spell/28164",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-08-13"
        }
      ],
      "whatHappened": "Grove proposed granting Sky's PAS Configurator DEFAULT_ADMIN_ROLE on Grove's DPAU AccessControls and RateLimits contracts and advancing the Uniswap V3 deposit-limit ramp.",
      "whatChanged": "If executed, PAS could alter Grove DPAU roles and rate limits without a separate Grove spell for each pre-authorized action. The Uniswap V3 deposit allowance would retain a 5 million maximum but begin replenishing at 350,000 per day.",
      "whatDidNotChange": "The proposal does not establish execution. Grove would retain its administrator role and revocation path; the Uniswap deposit maximum, withdrawal settings, swap settings, and facet code would remain unchanged.",
      "confirmedFacts": [
        "The proposed AccessControls contract is 0x4F6d1704700cd494DD4cd9bF59c0C39DA1Bc9164.",
        "The proposed RateLimits contract is 0xE016Ae733A77Ba77E7907aAA749394Fc5e75C0e1.",
        "The proposed PAS Configurator is 0xb7E61Df6CAb0A51E9A5dab1A7DD3f942dDe5b929.",
        "The deposit maximum would remain 5 million while its slope would rise from zero to 350,000 per day.",
        "Grove is identified as the first Prime proposed to adopt PAS."
      ],
      "unresolved": [
        "The Grove vote outcome and final August 27 spell contents.",
        "The final PAS operating parameters, timelock, and ceilings.",
        "Whether the pending additional PAS audit was completed before execution.",
        "The executed role state and effective Uniswap rate limits."
      ],
      "advisorDiligenceImplications": [
        "Review the Sky memo's Grove allocator-control map because execution would introduce a Sky-operated administrator into Grove's allocation stack.",
        "Verify the executed role grants, PAS bounds, timelock, ceilings, revocation path, and rate limits before treating the new control model as operative.",
        "Do not infer that the proposal approves Grove or any underlying asset exposure."
      ],
      "followUpOn": "2026-08-28",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-f60b00737be21df7a0543f5b",
      "stableKey": "aave-v3-governance-emergency-guardian-signer-rotation-2026",
      "version": 1,
      "eventDate": "2026-08-12",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "Aave proposes Governance Emergency Guardian signer rotation",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Aave Governance Emergency Guardian: Signer Rotation",
          "authority": "Aave Labs via Aave governance",
          "url": "https://governance.aave.com/t/arfc-aave-governance-emergency-guardian-signer-rotation/25469",
          "documentType": "official governance proposal",
          "publishedOn": "2026-08-12"
        }
      ],
      "whatHappened": "Aave Labs published an ARFC proposing a new nine-address signer roster for the Governance Emergency Guardian.",
      "whatChanged": "A concrete signer-rotation proposal now exists for the multisig that can cancel malicious, erroneous, or unsafe governance proposals and payloads. No operative owner rotation is established by this record.",
      "whatDidNotChange": "The proposal retains the existing 5-of-9 threshold, Governance Emergency Guardian Safe addresses, assigned cancellation permissions, and exercise conditions. It does not show Snapshot approval, AIP approval, or executed Safe owner transactions.",
      "confirmedFacts": [
        "The proposed guardian remains a 5-of-9 multisig.",
        "The proposal identifies nine replacement or retained signing addresses.",
        "Existing Safe addresses and Governance and PayloadsController permissions are proposed to remain unchanged.",
        "A chain-by-chain execution manifest is expected before implementation."
      ],
      "unresolved": [
        "Whether the ARFC will receive favorable community sentiment and Snapshot approval.",
        "Whether every proposed signer will confirm operational readiness.",
        "The final chain-by-chain execution manifest and resulting on-chain Safe owner sets."
      ],
      "advisorDiligenceImplications": [
        "Keep the Aave v3 memo unchanged while the proposal remains unapproved and unexecuted.",
        "Monitor the Snapshot, execution manifest, and each Safe owner-management transaction.",
        "Reopen the control review if implementation changes a Safe address, threshold, cancellation authority, or other permission beyond the stated signer rotation."
      ],
      "followUpOn": "2026-08-21",
      "previousInterpretation": "The Aave v3 memo treats this as a signer-only proposal that does not fire its emergency-powers kill criterion because the threshold, Safe addresses, and powers remain unchanged.",
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-9ecbf0c49861173b151f5899",
      "stableKey": "defi-saver:aave-v3-v4-migration-liquidation-protection:2026-08",
      "version": 1,
      "eventDate": "2026-08-11",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "DeFi Saver launches Liquidation Protection and Aave v3-to-v4 migration workflows",
      "category": "launch_access",
      "posture": "launched",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "product",
          "id": "defi-saver-asset-management",
          "name": "DeFi Saver Asset Management"
        },
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "DeFi Saver Newsletter: August 2026",
          "authority": "DeFi Saver",
          "url": "https://blog.defisaver.com/defi-saver-newsletter-august-2026/",
          "documentType": "official_product_update",
          "publishedOn": "2026-08-11"
        }
      ],
      "whatHappened": "DeFi Saver launched a minimal Liquidation Protection automation across supported lending protocols and a dedicated workflow for migrating Aave v3 positions to Aave v4 in one transaction.",
      "whatChanged": "The approved automation dependency can now execute an additional collateral-sale-and-repayment strategy and a more accessible cross-version Aave migration path.",
      "whatDidNotChange": "The launch does not approve Aave v4, any migrated asset, or the underlying leveraged position. DeFi Saver's dependency-only limits and each base protocol's separate verdict remain unchanged.",
      "confirmedFacts": [
        "Liquidation Protection was described as live on August 10, 2026.",
        "The feature monitors supported positions and uses the minimum stated collateral amount needed to repay part of a debt when configured thresholds are reached.",
        "The Aave v3-to-v4 migration tool was described as live and capable of migrating a position in one transaction.",
        "The official update lists Aave, Morpho, Compound, Fluid, Spark, and Maker among supported Liquidation Protection protocols."
      ],
      "unresolved": [
        "The exact contracts, authorization scopes, trigger defaults, and execution slippage for the new automation.",
        "Which Aave v3 assets and positions are eligible for migration.",
        "Whether any approved or client-held position enabled either feature.",
        "The failure and rollback behavior if a migration or protection transaction cannot complete."
      ],
      "advisorDiligenceImplications": [
        "Inventory client automation permissions before enabling the new strategy and verify its collateral-sale, slippage, and trigger settings.",
        "Do not infer approval of Aave v4 or any destination market from DeFi Saver's interface support.",
        "Review operational procedures for positions migrated away from the separately assessed Aave v3 perimeter."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-20b5a4cf4ab1993d9f490596",
      "stableKey": "aave-v3:pt-ausd-monad-arfc:2026-08",
      "version": 1,
      "eventDate": "2026-08-09",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "Aave ARFC advances PT-AUSD collateral proposal for the Monad V3 instance",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Onboard PT-AUSD-8OCT2026 to Aave V3 Monad Instance",
          "authority": "Aave DAO Snapshot",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0x1d5029f1b99b62843590e28d027a1a5aa21f4fe19f175284197c58779db14027",
          "documentType": "official governance vote",
          "publishedOn": "2026-08-05"
        }
      ],
      "whatHappened": "An Aave DAO ARFC vote passed for proposed onboarding of PT-AUSD-8OCT2026 to the Aave V3 Monad instance, with specified token addresses, a capped linear-discount oracle, and a proposed high-LTV e-mode configuration.",
      "whatChanged": "The proposal cleared the Snapshot signaling stage and can advance to an executable AIP. The proposal would introduce a short-dated, multi-component Pendle principal token as collateral in a dedicated Agora-stablecoin e-mode category.",
      "whatDidNotChange": "The Snapshot result did not list the asset on-chain or activate the proposed 93% maximum LTV and 95% liquidation threshold. The asset is not part of Ketju's approved Ethereum Aave exposure.",
      "confirmedFacts": [
        "The final vote recorded 392,114.33 votes for, zero against, and 10.67 abstaining.",
        "The proposed asset is PT-AUSD-8OCT2026 on Monad, maturing October 8, 2026.",
        "The proposed oracle applies a linear discount to a capped AUSD reference and decays toward par at maturity.",
        "The proposal specifies a 20 million unit supply cap and no ordinary borrowing.",
        "The proposed e-mode parameters include 93% maximum LTV and a 95% liquidation threshold."
      ],
      "unresolved": [
        "No executable AIP or completed on-chain listing was established.",
        "Final implementation timing and any changed risk parameters remain unresolved.",
        "The proposal's fixed-one-dollar AUSD reference, Pendle-market exit liquidity, and maturity handling require separate diligence."
      ],
      "advisorDiligenceImplications": [
        "Monitor for an AIP but do not treat PT-AUSD as approved or live based on the Snapshot vote.",
        "If executed, review the multi-wrap collateral structure, the capped AUSD oracle assumption, e-mode leverage, maturity transition, and proposed-size exit liquidity.",
        "Keep the Monad proposal outside the existing Ethereum-only Aave watchlist exposure unless a separate perimeter decision is completed."
      ],
      "followUpOn": "2026-08-21",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-5e781973e36779181d1a873a",
      "stableKey": "sky-lending:osero-sparklend-usds-crr:100-to-25",
      "version": 1,
      "eventDate": "2026-08-07",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "Sky proposes reducing Osero's SparkLend USDS capital ratio to 25%",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Atlas Edit Weekly Cycle Proposal - Week Of 2026-08-10",
          "authority": "Sky Forum (Core GovOps)",
          "url": "https://forum.skyeco.com/t/atlas-edit-weekly-cycle-proposal-week-of-2026-08-10/28155",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-08-07"
        }
      ],
      "whatHappened": "Sky Core GovOps proposed reducing the Capital Ratio Requirement for Osero's Ethereum SparkLend USDS instance from 100% to 25%.",
      "whatChanged": "If approved, the instance's required capital buffer would fall by 75 percentage points, permitting greater reliance on Sky-supplied capital relative to Osero capital.",
      "whatDidNotChange": "The cached record does not establish ratification, an executive payload, execution, or the resulting live exposure. Other instance and protocol parameters were not shown as changing.",
      "confirmedFacts": [
        "The current stated Capital Ratio Requirement is 100%.",
        "The proposed requirement is 25%.",
        "The proposal was triggered for the weekly Atlas-edit process.",
        "The same proposal also documents a 5% tolerance for maximum-exposure overruns caused solely by accrued interest."
      ],
      "unresolved": [
        "The final governance outcome and effective Atlas text.",
        "The risk analysis supporting the reduction.",
        "The instance's live exposure, Osero capital, and post-change loss-allocation profile.",
        "Whether a coordinated on-chain spell was required or executed."
      ],
      "advisorDiligenceImplications": [
        "Review the Sky backing and allocator-risk assessment if the reduction becomes operative.",
        "Verify the final capital ratio, instance exposure, and loss-allocation mechanics before incorporating the change into the memo.",
        "Do not treat the proposal as evidence that Osero or SparkLend is approved."
      ],
      "followUpOn": "2026-08-21",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-81c8f88461ebd8208e0f147f",
      "stableKey": "sky-lending:treasury-management-target-state:2026-08",
      "version": 1,
      "eventDate": "2026-08-07",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "Sky proposes activating its full Treasury Management Function waterfall",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Treasury Management Function (TMF) Configurations",
          "authority": "Sky Forum (BA Labs and Core Facilitator)",
          "url": "https://forum.skyeco.com/t/treasury-management-function-tmf-configurations/28153",
          "documentType": "official_parameter_recommendation",
          "publishedOn": "2026-08-07"
        }
      ],
      "whatHappened": "BA Labs stated that the transition condition for Sky's full Treasury Management Function had been met and recommended August 13 spell parameters implementing the revenue-allocation waterfall.",
      "whatChanged": "If executed, July net revenue would fund security and maintenance, retain capital for Sky reserves, and split remaining capital among USDS staking rewards, SKY buybacks distributed to stakers, and buyback-and-burn treatment.",
      "whatDidNotChange": "The record confirms recommendation and Core Facilitator acceptance for inclusion but does not prove executive-vote approval or spell execution. It does not change the sUSDS redemption mechanism or directly state a new Sky Savings Rate.",
      "confirmedFacts": [
        "July net revenue was calculated at 10,517,426 USDS.",
        "Aggregate Backstop Capital was reported below its 150 million USDS Turbo-Fill Floor, producing a 50% Step 2 retention rate.",
        "The proposed Step 3 allocation is 45% USDS staking rewards, 45% buybacks distributed as SKY rewards, and 10% buyback-and-burn treatment.",
        "The proposed splitter hop and rewards duration are both 3,748 seconds.",
        "The Core Facilitator confirmed the values for inclusion in the next executive vote."
      ],
      "unresolved": [
        "The executive-vote outcome and execution transaction.",
        "The resulting live splitter, vesting, and rewards parameters.",
        "Whether the reported reserve and revenue inputs were independently reconciled on-chain.",
        "The effect of the new waterfall on future sUSDS subsidy and reserve coverage."
      ],
      "advisorDiligenceImplications": [
        "Review Sky's reserve, subsidy, and cash-allocation assumptions if the configuration executes.",
        "Verify live parameters and subsequent reserve coverage before updating the memo's economic-control description.",
        "Do not present proposed SKY or USDS staking distributions as current until execution is verified."
      ],
      "followUpOn": "2026-08-21",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-a981af72ff6356bd92b86ff4",
      "stableKey": "sky-lending:msc-5-10-accounting-reconciliation:2026-08",
      "version": 1,
      "eventDate": "2026-08-06",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "Sky confirms Prime Agent settlement and oracle-accounting corrections",
      "category": "economic_change",
      "posture": "confirmed",
      "materiality": "material",
      "evidenceState": "mixed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Settlement Reconciliation - MSC #5–#10 (January–June 2026)",
          "authority": "Sky Forum (Soter Labs)",
          "url": "https://forum.skyeco.com/t/settlement-reconciliation-msc-5-10-january-june-2026/28150",
          "documentType": "official_accounting_reconciliation",
          "publishedOn": "2026-08-06"
        }
      ],
      "whatHappened": "Sky's settlement operator published a reconciliation correcting prior Prime Agent revenue and Sky-share calculations after identifying methodology, data-source, block-timing, and oracle-feed errors.",
      "whatChanged": "The reconciliation adds approximately 820,320 USDS of net Prime Agent revenue and 297,559 USDS of net Sky share to later settlement calculations, while replacing or correcting several accounting inputs.",
      "whatDidNotChange": "The report does not identify a loss of client USDS or impairment of sUSDS redemption. It does not establish that every historical accounting case is resolved, and two Distribution Rewards cases remain outside scope.",
      "confirmedFacts": [
        "Spark corrections included previously missed aToken yield, a phantom idle-stablecoin outflow, a subsidized-borrow benchmark change, and data-source revisions.",
        "Grove corrections included fabricated T-bill series rows and an ACRDX Chronicle consumer feed that continued returning a stale value after its last update on May 7, 2026.",
        "Obex, Skybase, and Keel calculations were affected by an end-of-month block pinned approximately 2.8 hours early.",
        "The reconciliation reports approximately 820,320 USDS owed to Prime Agents and 297,559 USDS of net additional Sky share.",
        "Morpho-market and certain frontend Distribution Rewards cases remain for future reconciliation."
      ],
      "unresolved": [
        "The final correction for the two excluded Distribution Rewards cases.",
        "Whether every corrective mint and transfer was executed as calculated.",
        "The duration and financial effect of the stale Chronicle feed outside the reported settlement calculations.",
        "Whether the accounting-control changes prevent recurrence across all Prime Agents."
      ],
      "advisorDiligenceImplications": [
        "Review the Sky memo's allocator reporting and oracle-accounting controls because the errors affected multiple months and Prime Agents.",
        "Verify corrective execution and later reconciliation reports rather than treating the published calculations as settled on-chain state.",
        "Continue monitoring for any evidence that accounting errors affected backing, reserve coverage, or client redemption capacity."
      ],
      "followUpOn": "2026-09-10",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-8eb8ba0bc5402d3dacc64f64",
      "stableKey": "sky-lending:sbe-beam:august-2026-launch-proposal",
      "version": 1,
      "eventDate": "2026-08-06",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "Sky proposes delegated Smart Burn Engine parameter control through SBE BEAM",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        },
        {
          "type": "controller",
          "id": "sky-sbe-beam",
          "name": "Sky Smart Burn Engine BEAM"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Smart Burn Engine Bounded External Access Module (SBE BEAM) launch",
          "authority": "Sky Forum (Sidestream, BA Labs, Soter Labs, and Core Facilitator)",
          "url": "https://forum.skyeco.com/t/smart-burn-engine-bounded-external-access-module-sbe-beam-launch/28149",
          "documentType": "official_technical_scope",
          "publishedOn": "2026-08-06"
        }
      ],
      "whatHappened": "Sky contributors proposed initializing SBE BEAM and FarmOwner contracts so a permissioned operator could adjust Smart Burn Engine and staking-reward timing parameters outside the normal core-spell cadence.",
      "whatChanged": "If executed, the operator could jointly change kbump, burn, hop, and rewardsDuration within configured throughput, delay, and cooldown bounds.",
      "whatDidNotChange": "The cached record identifies an intended August 13 spell but does not prove initialization or execution. The Pause Proxy would remain administrator, and the operator's discretion would remain contractually bounded.",
      "confirmedFacts": [
        "The proposed SBEBeam address is 0xc8b61d211D3D03A630Fb09199E17953a8c9749a9.",
        "The proposed FarmOwner address is 0xA3d3A2e9Fe5d0901D720D5382E4a7eA12D4E2b0e.",
        "The permissioned operator address supplied by Soter Labs is 0x869294B42B80f99CF3Bdac0F44abddAd6cD41330.",
        "BA Labs recommended a 12,000 USDS maximum kbump, 550-second minimum hop, 350 million USDS annual maximum rate, and 30-minute cooldown.",
        "The contracts were described as pre-deployed and based on an audited commit, but initialization was assigned to a future core spell."
      ],
      "unresolved": [
        "Whether the August 13 executive spell passed and executed.",
        "The final live operator set, bounds, and contract permissions.",
        "Whether FarmOwner and SBE BEAM ownership was transferred and initialized exactly as proposed.",
        "How frequently the delegated operator uses the new authority and how changes are monitored."
      ],
      "advisorDiligenceImplications": [
        "Review Sky's delegated-authority and economic-control map if SBE BEAM becomes operative.",
        "Verify the executed initialization, operator list, bounds, Pause Proxy authority, and change history before relying on the new control model.",
        "Monitor whether delegated changes materially affect reserve retention, buybacks, or staking distributions supporting the broader Sky balance sheet."
      ],
      "followUpOn": "2026-08-21",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-922238cb5ac382a23757d082",
      "stableKey": "sky-lending:osero-prysm-a-debt-ceiling:5m-to-10m",
      "version": 1,
      "eventDate": "2026-08-06",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "Osero proposes doubling ALLOCATOR-PRYSM-A debt capacity",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Osero — Requested Changes to Allocator Vault Parameters",
          "authority": "Sky Forum (Osero, BA Labs, and Soter Labs)",
          "url": "https://forum.skyeco.com/t/osero-requested-changes-to-allocator-vault-parameters/28147",
          "documentType": "official_parameter_proposal",
          "publishedOn": "2026-08-06"
        }
      ],
      "whatHappened": "Osero requested that Sky Core double ALLOCATOR-PRYSM-A's maximum debt ceiling and target available debt.",
      "whatChanged": "If executed, the allocator's maximum USDS capacity would rise from 5 million to 10 million and immediately targetable debt would rise from 1 million to 2 million.",
      "whatDidNotChange": "The 24-hour ceiling-increase cooldown would remain unchanged, and the cached record does not establish executive-vote approval or execution.",
      "confirmedFacts": [
        "The requested maximum debt ceiling is 10 million USDS, up from 5 million.",
        "The requested target available debt is 2 million USDS, up from 1 million.",
        "The requested cooldown remains 86,400 seconds.",
        "BA Labs supported the requested values, and Soter Labs requested their inclusion in a future executive vote."
      ],
      "unresolved": [
        "Whether the changes were included in an executive spell.",
        "The final executed parameter state.",
        "The asset strategy, loss boundary, and balance-sheet classification of the additional capacity.",
        "Resulting utilization and exposure after any execution."
      ],
      "advisorDiligenceImplications": [
        "Monitor the executive spell and determine whether expanded allocator capacity changes the Sky memo's backing or counterparty assessment.",
        "Do not treat the requested limits as operative until executed state is verified."
      ],
      "followUpOn": "2026-08-21",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-bef2606ef1a3a6bf81aa3d1a",
      "stableKey": "sky-lending:sky-vaults-launch:2026-08-06",
      "version": 1,
      "eventDate": "2026-08-06",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "Sky.money adds five live Morpho-based stablecoin vaults outside the existing savings exposure",
      "category": "launch_access",
      "posture": "launched",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        }
      ],
      "primaryDocuments": [
        {
          "title": "What Are Sky Vaults?",
          "authority": "Sky.money / Skybase International",
          "url": "https://sky.money/blog/what-are-sky-vaults",
          "documentType": "official product documentation",
          "publishedOn": "2026-08-07"
        }
      ],
      "whatHappened": "Sky.money documented five live non-custodial vaults accepting USDS, USDC, or USDT and deploying deposits into defined Morpho lending strategies. The source reported $121.7 million deployed across the vaults as of August 6.",
      "whatChanged": "The Sky.money interface now exposes strategy-driven lending vaults alongside the Sky Savings Rate. Users can take collateral, oracle, smart-contract, utilization, and withdrawal-liquidity risk that is not present in the same form in a direct sUSDS savings position.",
      "whatDidNotChange": "The launch did not change the Sky Savings Rate, the USDS-to-sUSDS accounting mechanism, or the existing Ketju approval, which covers only Ethereum USDS and sUSDS. Skybase states that it operates the interface and does not control the underlying protocol or vault strategies.",
      "confirmedFacts": [
        "Five vaults were described as live: USDS Flagship, USDT Savings, and USDS, USDC, and USDT Risk Capital vaults.",
        "Each vault accepts a specified stablecoin and deploys it into a defined Morpho-based strategy.",
        "The source reported $121.7 million deployed across Sky Vaults as of August 6, 2026.",
        "Withdrawals depend on vault liquidity and can be delayed by high utilization in underlying lending markets.",
        "Vault yield is variable, market-driven, and may be below the Sky Savings Rate."
      ],
      "unresolved": [
        "The exact contract addresses, curators, oracle configurations, caps, and live liquidity for each vault were not reconciled in this candidate review.",
        "No separate Ketju approval or position limit exists for any of the five vaults.",
        "The degree to which each vault depends specifically on Morpho Blue rather than another Morpho component was not independently resolved."
      ],
      "advisorDiligenceImplications": [
        "Do not extend the existing sky-lending approval for Ethereum USDS/sUSDS to any Sky Vault.",
        "Create separate diligence for each vault before advisor use, including curator authority, collateral and oracle mapping, withdrawal-liquidity testing, and proposed-size exits.",
        "Ensure client and interface controls distinguish direct sUSDS savings exposure from the materially different Morpho vault exposures."
      ],
      "followUpOn": "2026-08-28",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-02070e9ba719ad3577520cf3",
      "stableKey": "aave-gho-stewards-2-of-3-signer-update-2026",
      "version": 1,
      "eventDate": "2026-08-05",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "Aave proposes 2-of-3 service-provider control for GHO Stewards",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] GHO Stewards Signer Update",
          "authority": "TokenLogic via Aave governance",
          "url": "https://governance.aave.com/t/arfc-gho-stewards-signer-update/25452",
          "documentType": "official governance proposal",
          "publishedOn": "2026-08-08"
        }
      ],
      "whatHappened": "TokenLogic published an ARFC proposing that the GHO Risk Council Safe move from four individual signers with a 3-of-4 threshold to entity Safes controlled by Aave Labs, LlamaRisk, and TokenLogic with a 2-of-3 threshold.",
      "whatChanged": "The proposal creates a concrete path to lower the GHO Steward signing threshold and replace individual signing addresses with nested service-provider entity Safes. The candidate does not establish approval or execution.",
      "whatDidNotChange": "The GHO Risk Council Safe address would remain unchanged, as would the Steward contract role references and governance-defined bounds on Steward actions. No AIP is proposed because implementation would be a Safe owner-management transaction.",
      "confirmedFacts": [
        "The current configuration is described as 3-of-4 and the proposed configuration as 2-of-3.",
        "The proposed signer entities are Aave Labs, LlamaRisk, and TokenLogic.",
        "The GHO Risk Council Safe address is proposed to remain 0x8513e6F37dBc52De87b166980Fa3F50639694B60.",
        "The Steward contracts would continue referencing the same Safe address."
      ],
      "unresolved": [
        "Whether the ARFC will pass Snapshot.",
        "The internal signer thresholds and controls of each proposed entity Safe at execution time.",
        "Whether the current Council signers will execute the owner and threshold changes exactly as proposed.",
        "What additional coordination or segregation controls govern sensitive 2-of-3 Steward actions."
      ],
      "advisorDiligenceImplications": [
        "Monitor the Snapshot and the Safe owner-management transaction before treating the change as operative.",
        "If executed, review the Aave v3 memo's GHO control layer because two organizations rather than three individual signers could authorize bounded parameter actions.",
        "Document the nested entity-Safe thresholds and signer independence before deciding whether the current sleeve cap remains appropriate.",
        "Do not restrict the approved Ethereum GHO/sGHO position solely on this unapproved proposal."
      ],
      "followUpOn": "2026-08-22",
      "previousInterpretation": "The existing Aave v3 memo recognizes governance and steward controls but does not incorporate an executed 2-of-3 entity-Safe configuration for the GHO Stewards.",
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-19a6c64d3240636d0d9904f9",
      "stableKey": "axelar:moonbeam-deactivation:2026-08",
      "version": 1,
      "eventDate": "2026-08-04",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "Axelar governance executes Moonbeam connection deactivation",
      "category": "closure_deprecation",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Deactivate Moonbeam on nexus",
          "authority": "Axelar on-chain governance",
          "url": "https://axelarscan.io/proposal/494",
          "documentType": "executed on-chain governance proposal",
          "publishedOn": "2026-08-04"
        }
      ],
      "whatHappened": "Axelar governance proposal 494 passed and executed a Nexus DeactivateChainRequest for Moonbeam. Axelar's Nexus state reports the Moonbeam connection as inactive.",
      "whatChanged": "Moonbeam is no longer an active Axelar Nexus connection, removing that route from Axelar's available cross-chain perimeter until a separate reactivation action occurs.",
      "whatDidNotChange": "The event did not establish an exploit of Axelar's validator consensus, threshold-signature, or gateway-contract layer. Other Axelar connections and the protocol's consensus thresholds were not changed by this proposal.",
      "confirmedFacts": [
        "Proposal 494 was submitted and began voting on August 1, 2026.",
        "Voting ended on August 4 with proposal status PASSED, 157,176,988,734,355 yes units, and no negative votes.",
        "The proposal message was an Axelar Nexus DeactivateChainRequest naming Moonbeam.",
        "The proposal record contains no failed execution reason.",
        "Axelar Nexus state reports Moonbeam activated=false."
      ],
      "unresolved": [
        "The operational reason for the deactivation is not stated in the proposal metadata.",
        "The treatment of in-flight transfers and any user-facing recovery process was not specified.",
        "No reactivation conditions or timetable were supplied."
      ],
      "advisorDiligenceImplications": [
        "Remove Moonbeam as an assumed available Axelar route in dependency and exit-planning maps.",
        "Identify any approved or client-held position whose entry, exit, or recovery path depended on Axelar's Moonbeam connection.",
        "Review integration-specific continuity controls; Axelar approval does not certify that an affected downstream route remains usable."
      ],
      "followUpOn": "2026-08-25",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-bfcbcce9e135bd2dffa58540",
      "stableKey": "ccip:wbtc-migration-selection:2026-08",
      "version": 1,
      "eventDate": "2026-08-04",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "BitGo selects Chainlink CCIP for a planned WBTC cross-chain migration",
      "category": "upgrade_migration",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "other",
          "id": "ccip",
          "name": "Chainlink CCIP"
        }
      ],
      "primaryDocuments": [
        {
          "title": "BitGo Selects Chainlink CCIP as Exclusive Cross-Chain Infrastructure Provider for WBTC, Migrating Away From Legacy Solution",
          "authority": "BitGo",
          "url": "https://www.bitgo.com/resources/blog/bitgo-selects-chainlink-ccip-for-wbtc/",
          "documentType": "official issuer announcement",
          "publishedOn": "2026-08-04"
        }
      ],
      "whatHappened": "BitGo selected Chainlink CCIP as the exclusive cross-chain infrastructure provider for WBTC and stated that it plans to migrate WBTC away from its legacy solution. BitGo also plans to default future issued assets to CCIP.",
      "whatChanged": "CCIP became BitGo's selected interoperability standard for the planned WBTC migration, materially expanding the prospective use of this watched dependency and introducing a unified CCT model with issuer-managed risk parameters.",
      "whatDidNotChange": "The announcement did not confirm that WBTC routes had migrated, that CCIP-backed WBTC transfers were live, or that the legacy solution had been retired. BitGo retains ownership and issuer control over token deployments, and this event does not approve WBTC as a Ketju asset.",
      "confirmedFacts": [
        "BitGo selected Chainlink CCIP as its exclusive cross-chain infrastructure provider.",
        "The announced scope includes WBTC and future BitGo-issued assets.",
        "BitGo stated that it plans to migrate WBTC away from its legacy cross-chain solution.",
        "The planned design uses Chainlink's Cross-Chain Token standard with issuer-managed risk parameters and security controls.",
        "BitGo stated that it retains ownership of token deployments and can add security controls."
      ],
      "unresolved": [
        "No deployed WBTC CCIP lane, contract registry, supported-chain list, or first successful transfer was established.",
        "The migration schedule and retirement date for the legacy solution were not stated.",
        "The live CCIP Risk Management Network configuration and issuer-controlled rate limits for each WBTC route remain unresolved.",
        "The source's WBTC value figure was issuer-supplied and was not independently reconciled."
      ],
      "advisorDiligenceImplications": [
        "Review the ccip dependency memo for the substantially larger prospective WBTC integration and its issuer-controlled configuration.",
        "Do not treat the WBTC migration as executed until deployed addresses, supported routes, configuration, and live transfer evidence are available.",
        "A CCIP dependency approval does not approve WBTC or remove the need to review BitGo custody, redemption, token-control, and per-chain route risks."
      ],
      "followUpOn": "2026-08-31",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-23d6881ae1d33f56426756fa",
      "stableKey": "sky-lending:spark-liquidity-layer:usdg-rlusd-pools-2026-08",
      "version": 1,
      "eventDate": "2026-08-03",
      "publishedAt": "2026-08-22T14:06:03.558Z",
      "title": "Spark proposes USDG and RLUSD liquidity integrations",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        },
        {
          "type": "protocol",
          "id": "sparklend",
          "name": "SparkLend"
        },
        {
          "type": "protocol",
          "id": "spark-liquidity-layer",
          "name": "Spark Liquidity Layer"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[August 13, 2026] Proposed Changes to Spark for Upcoming Spell",
          "authority": "Sky Forum (Phoenix Labs, Spark Risk Council, and BA Labs)",
          "url": "https://forum.skyeco.com/t/august-13-2026-proposed-changes-to-spark-for-upcoming-spell/28135",
          "documentType": "official_spell_proposal",
          "publishedOn": "2026-08-03"
        }
      ],
      "whatHappened": "Phoenix Labs proposed adding USDG/USDS and RLUSD/USDS Uniswap V4 liquidity positions, an RLUSD/USDC Curve swap route, recurring SparkLend reserve claims, and a 1,756,359 USDS buyback transfer.",
      "whatChanged": "If executed, Spark would gain new USDG and RLUSD issuer, depeg, pool, and planner-execution exposure under replenishing deposit and swap limits.",
      "whatDidNotChange": "The record does not establish Snapshot passage or spell execution. No Spark contract would be deployed, upgraded, or repointed, and the proposed pools would use the existing ALM Controller.",
      "confirmedFacts": [
        "Each proposed Uniswap V4 pool has a 10 million deposit maximum and unlimited withdrawals.",
        "The USDG pool's proposed deposit slope is 100 million per day and swap slope is 200 million per day.",
        "The RLUSD pool's proposed deposit slope is 50 million per day and swap slope is 100 million per day.",
        "The Curve RLUSD/USDC integration is swap-only, with a 5 million maximum, 25 million-per-day slope, and 0.1% maximum slippage.",
        "The Spark Risk Council and BA Labs supported advancing the proposed items to voting.",
        "The recurring buyback transfer is proposed at 1,756,359 USDS."
      ],
      "unresolved": [
        "Snapshot outcomes and final executive-spell execution.",
        "The final live pool and rate-limit configuration.",
        "Actual cumulative USDG and RLUSD inventory and available exit liquidity.",
        "Whether the buyback calculation's treatment of accrued but unrealized user yield was reconciled with the Atlas definition.",
        "The financial effect of reserve claims and new stablecoin concentration on Sky backing."
      ],
      "advisorDiligenceImplications": [
        "Review the Sky dependency and backing map if the spell executes because new stablecoin issuer and pool exposures would enter Spark's allocation path.",
        "Keep the rejected SparkLend and Spark Liquidity Layer conclusions unchanged unless their stated reopen criteria are independently satisfied.",
        "Verify actual positions, utilization, rate limits, withdrawal capacity, and executed buyback transfer after governance action."
      ],
      "followUpOn": "2026-08-21",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-b06f32e5e67cde8b4a1c34a0",
      "stableKey": "sky-atlas-sbe-beam-and-uniswap-controller-functions",
      "version": 1,
      "eventDate": "2026-07-31",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Sky proposes delegated Smart Burn Engine controls and new Uniswap functions",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Atlas Edit Weekly Cycle Proposal - Week Of 2026-08-03",
          "authority": "Sky",
          "url": "https://forum.skyeco.com/t/atlas-edit-weekly-cycle-proposal-week-of-2026-08-03/28131",
          "documentType": "official governance proposal",
          "publishedOn": "2026-07-31"
        }
      ],
      "whatHappened": "Sky's weekly Atlas proposal would create a bounded external-access module for the Smart Burn Engine, delegate parameter authority to a 4-of-6 operator multisig, and add Uniswap v3 liquidity and swap functions to Diamond PAU controllers.",
      "whatChanged": "The proposal defines a new no-executive-vote control path for kbump, hop, and burn settings and expands controller capabilities available to Prime Agents.",
      "whatDidNotChange": "The proposal was not yet approved or executed. Existing Smart Burn Engine authority and controller functions remained operative pending governance action.",
      "confirmedFacts": [
        "The proposed operator is a whitelisted 4-of-6 multisig.",
        "Proposed bounds include a 12,000 USDS maximum kbump, 550-second minimum hop, and 350 million USDS annual maximum rate.",
        "The proposed burn setting can range from 0% to 100%.",
        "The Atlas edit would add Uniswap v3 add-liquidity, remove-liquidity, and swap controller functions."
      ],
      "unresolved": [
        "Whether governance approved and implemented the Atlas edit.",
        "A documented tension between the existing parameter-governance text and the proposed multisig's 0%-100% burn authority.",
        "The final deployed contracts, bounds, and operator membership."
      ],
      "advisorDiligenceImplications": [
        "Review the Sky memo's administrator and delegated-authority map if the proposal became operative.",
        "Verify whether inherited Uniswap capabilities or burn discretion affect any approved or client-used Sky product before relying on existing control assumptions."
      ],
      "followUpOn": "2026-08-10",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-bb27a57ac225bcca6f8977b1",
      "stableKey": "sky-morpho-pt-susds-usds-market-launch",
      "version": 1,
      "eventDate": "2026-07-31",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "PT-sUSDS becomes live Morpho collateral with Sky vault allocation",
      "category": "launch_access",
      "posture": "launched",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        },
        {
          "type": "protocol",
          "id": "morpho-blue",
          "name": "Morpho Blue"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Using PT-sUSDS as Collateral on Morpho Vaults",
          "authority": "Sky",
          "url": "https://sky.money/blog/advanced-strategies-ptsusds-morpho",
          "documentType": "official product update",
          "publishedOn": "2026-07-31"
        }
      ],
      "whatHappened": "A Morpho market went live using PT-sUSDS as collateral and USDS as the loan asset, while a Sky.money-curated USDS vault began adding an allocation to that market.",
      "whatChanged": "PT-sUSDS can now support variable-rate USDS borrowing and leveraged looping, and the curated vault can route depositor USDS into the new market.",
      "whatDidNotChange": "The market is outside Sky.money's control and is not a Sky Protocol primitive. The source does not show that any Ketju-approved or client-held Morpho vault allocated to it.",
      "confirmedFacts": [
        "A live Morpho market accepts PT-sUSDS collateral and lends USDS.",
        "The collateral retains its fixed-rate maturity exposure while the USDS borrowing cost is variable.",
        "Sky.money said its USDS Flagship Vault was adding an allocation to the market.",
        "Looping increases loan-to-value and liquidation risk."
      ],
      "unresolved": [
        "The market's LLTV, oracle, liquidation penalty, caps, utilization, and liquidity.",
        "The amount and effective time of the curated-vault allocation.",
        "Whether any approved or client-held vault touches the market.",
        "The early-exit liquidity available before PT-sUSDS maturity."
      ],
      "advisorDiligenceImplications": [
        "Treat the PT-sUSDS market and looping strategy as unapproved until separately underwritten.",
        "Check approved Morpho-vault allocations for exposure to PT-sUSDS and apply off-list-market controls if applicable.",
        "Review the Sky memo's integration perimeter without attributing third-party Morpho controls to Sky."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-cbaab8ca59ec507bc34b9f1a",
      "stableKey": "rocket-pool-saturn-2-rpip-86-2026-07-30",
      "version": 1,
      "eventDate": "2026-07-30",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Rocket Pool outlines proposed Saturn 2 withdrawal, penalty, and economic changes",
      "category": "governance",
      "posture": "proposed",
      "materiality": "critical",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "rocket-pool",
          "name": "Rocket Pool"
        }
      ],
      "primaryDocuments": [
        {
          "title": "RPIP-86: Saturn 2 Upgrade",
          "authority": "Rocket Pool",
          "url": "https://dao.rocketpool.net/t/rpip-86-saturn-2-upgrade/4012",
          "documentType": "official governance proposal",
          "publishedOn": "2026-07-30"
        }
      ],
      "whatHappened": "Rocket Pool published RPIP-86 as an informational package describing the likely Saturn 2 scope and the draft RPIPs that would implement it. Formal voting had not started and the final package remained subject to pDAO decisions.",
      "whatChanged": "The proposed package would add protocol-level rETH withdrawals backed by validator exits, permissionless challenges and exits for underperforming validators, exit-request and minipool-penalty mechanics, higher megapool bond requirements, lower RPL issuance, and the end of ongoing RPL rewards for node operators.",
      "whatDidNotChange": "No component had been formally approved or executed. Existing rETH withdrawal, validator-selection, penalty, bond, and RPL issuance mechanics remained operative pending governance and deployment.",
      "confirmedFacts": [
        "RPIP-86 was in an informal-sentiment and scoping stage; the underlying RPIPs were draft and not yet voted.",
        "RPIP-71 proposes an rETH withdrawal queue that can trigger validator exits.",
        "RPIP-71's first phase would have the oDAO select minipools for exit, while a later megapool selection rule remained undecided.",
        "RPIP-80 proposes penalties for minipools that do not respond to exit requests.",
        "The package proposes increasing megapool bond requirements, reducing RPL issuance to 2.5%, and ending ongoing RPL rewards for node operators."
      ],
      "unresolved": [
        "The final Saturn 2 scope, vote structure, voting outcome, implementation parameters, and deployment date were undecided.",
        "The pDAO had not selected the final megapool exit criterion.",
        "The practical interaction between oDAO minipool selection and penalties for failed exit requests requires governance and control review.",
        "The effects on rETH withdrawal liquidity, operator participation, and protocol economics remain prospective."
      ],
      "advisorDiligenceImplications": [
        "Open a Rocket Pool memo review now because the written criterion covers RPIPs that expand oDAO power over penalties, and the package plausibly links oDAO exit selection to minipool penalties.",
        "Do not treat the proposed withdrawal queue as available liquidity until governance approval, deployment, and live performance are confirmed.",
        "Monitor formal votes and executed parameters for withdrawal priority, validator selection, penalty discretion, bond requirements, and RPL economics."
      ],
      "followUpOn": "2026-08-31",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-fa5f6c82cdc88500fd2f0406",
      "stableKey": "sky-grove-august-2026-capacity-and-controller-proposal",
      "version": 1,
      "eventDate": "2026-07-30",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Grove proposes lower reserves, higher exposure limits, and new Uniswap capacity",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[August 13, 2026] - Proposed Changes to Grove for Upcoming Spell",
          "authority": "Sky / Grove",
          "url": "https://forum.skyeco.com/t/august-13-2026-proposed-changes-to-grove-for-upcoming-spell/28126",
          "documentType": "official spell proposal",
          "publishedOn": "2026-07-30"
        }
      ],
      "whatHappened": "Grove proposed enabling Uniswap v3 functions on its Diamond PAU controller, retiring a Maple deposit permission, lowering the JTRSY capital reserve ratio, doubling JTRSY maximum exposure, and doubling allocator debt-capacity parameters.",
      "whatChanged": "If executed, Grove would gain new Uniswap liquidity and swap capacity, the JTRSY reserve ratio would fall from 100% to 25%, maximum exposure would rise from 2.5 million to 5 million, and ALLOCATOR-GROVE-A maxLine would rise from 5 million to 10 million USDS.",
      "whatDidNotChange": "The July record is a proposal for an August spell. It does not prove execution, and the JTRSY artifact and Sky Core autoline changes were explicitly outside the Grove spell payload.",
      "confirmedFacts": [
        "The proposed Uniswap deposit allowance is capped at 5 million with no replenishing slope during the initial phase.",
        "The proposal would set the Maple syrupUSDC deposit limit to zero.",
        "The requested JTRSY CRR is 25%, down from 100%.",
        "The requested ALLOCATOR-GROVE-A maxLine is 10 million USDS and gap is 2 million USDS."
      ],
      "unresolved": [
        "Whether the August 13 Grove and coordinated Sky Core spells executed.",
        "Whether the off-chain JTRSY artifact update was completed.",
        "The resulting live exposure, rate-limit, and autoline state."
      ],
      "advisorDiligenceImplications": [
        "Review the Sky memo if execution is confirmed because the proposal materially increases delegated deployment capacity and reduces reserve requirements.",
        "Verify that any approved Sky exposure does not inherit unreviewed Grove, JTRSY, Uniswap, or Maple risk."
      ],
      "followUpOn": "2026-08-13",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-784ea1667c60bd141f008e81",
      "stableKey": "rocket-pool-pdao-parameter-guardrail-revisions",
      "version": 1,
      "eventDate": "2026-07-28",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Rocket Pool proposes revisions to pDAO parameter guardrails",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "rocket-pool",
          "name": "Rocket Pool"
        }
      ],
      "primaryDocuments": [
        {
          "title": "RPIP: pDAO Parameter Guardrail Revisions",
          "authority": "Rocket Pool",
          "url": "https://dao.rocketpool.net/t/rpip-pdao-parameter-guardrail-revisions/4010",
          "documentType": "official governance proposal",
          "publishedOn": "2026-07-28"
        }
      ],
      "whatHappened": "Rocket Pool published a formal RPIP proposing revised governance guardrails for RPL inflation, governance quorums, the rETH collateral target, megapool dissolution delay, and the reduced-bond parameter.",
      "whatChanged": "A concrete proposal now defines possible new bounds, including a 25% annual RPL-inflation ceiling and broader quorum ranges.",
      "whatDidNotChange": "The cached record does not show approval, on-chain execution, or any currently operative parameter change.",
      "confirmedFacts": [
        "The proposal would cap annual RPL inflation at 25%.",
        "It would widen allowed proposal, veto, and upgrade-veto quorum ranges.",
        "It would change guardrails governing the rETH collateral target, megapool dissolution delay, and reduced bond."
      ],
      "unresolved": [
        "Whether the RPIP proceeded to a binding vote.",
        "The final approved text and any executed parameter values."
      ],
      "advisorDiligenceImplications": [
        "Monitor the proposal because executed guardrail changes would alter the governance and economic-control assumptions in the Rocket Pool memo.",
        "Do not treat the proposed bounds as operative until approval and execution are verified."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-4f233cf15437266a5e671c2a",
      "stableKey": "rocket-pool-rpip-84-signaling-platform-migration",
      "version": 1,
      "eventDate": "2026-07-28",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Rocket Pool advances proposal to replace Snapshot with RocketDash",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "rocket-pool",
          "name": "Rocket Pool"
        }
      ],
      "primaryDocuments": [
        {
          "title": "pDAO Signaling Governance - sentiment poll",
          "authority": "Rocket Pool",
          "url": "https://dao.rocketpool.net/t/pdao-signaling-governance-sentiment-poll/4004",
          "documentType": "official governance proposal and poll record",
          "publishedOn": "2026-07-21"
        }
      ],
      "whatHappened": "Rocket Pool's RPIP-84 sentiment poll closed 20-0 in favor of advancing a proposal that would make RocketDash the recognized signaling platform and create an on-chain emergency ballot system.",
      "whatChanged": "The platform migration became a concrete proposal ready for formal review and voting rather than an informal discussion.",
      "whatDidNotChange": "The record says a further vote is required; Snapshot remained the recognized venue and RocketDash had not yet received binding authorization.",
      "confirmedFacts": [
        "The sentiment poll closed 20-0 in favor of proceeding.",
        "RPIP-84 would designate RocketDash as the initial Recognized Signaling Platform.",
        "The proposal would recognize a lead vote administrator and create an emergency on-chain mechanism for replacing an unusable or untrusted platform."
      ],
      "unresolved": [
        "Whether RPIP-84 passed its binding vote.",
        "Whether RocketDash became the operative signaling platform and the emergency ballot system was implemented."
      ],
      "advisorDiligenceImplications": [
        "Monitor authorization and implementation because the proposal changes the off-chain governance trust model and continuity controls.",
        "Retain the existing Rocket Pool governance assessment until a binding result and operative migration are verified."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-71bc24aeef9125c618cefa3d",
      "stableKey": "morpho-sky-vault-market-update-2026-07-27",
      "version": 1,
      "eventDate": "2026-07-27",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "sky.money proposes new Morpho vault markets and sUSDS/USDT migration",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "morpho-blue",
          "name": "Morpho Blue"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Updating the sky.money USDT Savings Vault & USDS Flagship Vault",
          "authority": "Morpho Blue",
          "url": "https://forum.morpho.org/t/updating-the-sky-money-usdt-savings-vault-usds-flagship-vault/2368",
          "documentType": "official forum change record",
          "publishedOn": "2026-07-27"
        }
      ],
      "whatHappened": "sky.money announced planned allocation changes for its Morpho USDT Savings and USDS Flagship vaults, including two new isolated markets and a gradual migration away from an existing sUSDS/USDT market.",
      "whatChanged": "The proposed replacement sUSDS/USDT market uses a 96.5% LLTV and caps the USDT oracle leg at $1.00. A PT-sUSDS-26NOV2026/USDS market with a 91.5% LLTV and linear-discount oracle was also slated for the USDS vault. The old market's utilization and rates would be increased gradually to encourage migration.",
      "whatDidNotChange": "The record does not establish execution on-chain and does not identify the held Steakhouse-curated Morpho vaults as affected. Morpho Blue's core contracts were not described as changing.",
      "confirmedFacts": [
        "The proposed capped sUSDS/USDT market ID is 0x26b178d49895f80ca3c39b2745efc4cd9adcddfcc73dae93e531e86977ec4d96.",
        "The proposed PT-sUSDS-26NOV2026/USDS market ID is 0x9a8dab6de1059e6dc66c34b358764b70effb289e514e237f3161ffb09eaaf24f.",
        "The announced LLTVs were 96.5% for sUSDS/USDT and 91.5% for PT-sUSDS/USDS.",
        "The announcement described a gradual migration incentive for borrowers in the older sUSDS/USDT market."
      ],
      "unresolved": [
        "On-chain execution and final vault allocations were not confirmed by the cached record.",
        "The realized liquidation and exit-liquidity effects of the capped oracle and high-LLTV markets remain unknown."
      ],
      "advisorDiligenceImplications": [
        "Monitor the new markets as examples of curator-specific oracle and high-LLTV risk within Morpho.",
        "Do not infer that these sky.money vaults or markets are covered by approval of separately diligenced Morpho vaults.",
        "No held-vault kill criterion is established because the record does not affect a vault identified as held."
      ],
      "followUpOn": "2026-08-21",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-db7371c0a406558b73b9b43f",
      "stableKey": "lido-srv3-oracle-vebo-incident-2026-07-25",
      "version": 1,
      "eventDate": "2026-07-25",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Lido postmortem details SRv3 Accounting Oracle and VEBO incident",
      "category": "security_incident",
      "posture": "postmortem",
      "materiality": "material",
      "evidenceState": "mixed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[Security Disclosure] 25/7/2026 Minor Underreporting of Total Protocol CL-side balances in Accounting Oracle Report",
          "authority": "Lido",
          "url": "https://research.lido.fi/t/security-disclosure-25-7-2026-minor-underreporting-of-total-protocol-cl-side-balances-in-accounting-oracle-report/11756",
          "documentType": "official incident disclosure and postmortem",
          "publishedOn": "2026-07-25"
        }
      ],
      "whatHappened": "Following the SRv3 release, Lido's Accounting Oracle and Validators ExitBus Oracle experienced report delays and edge-case failures. The July 25 Accounting Oracle report omitted one in-flight 32 ETH deposit, and some VEBO reports from July 26 through July 28 were not produced.",
      "whatChanged": "The omitted balance was included in the July 26 rebase. Lido replaced slow BLS verification, fixed the VEBO zero-weight edge case, and added Accounting Oracle invariant checks, circuit breakers, three-way input matching, and expanded logging.",
      "whatDidNotChange": "Lido reported no lost or frozen funds. Withdrawal finalization remained below the Ethereum network average, and the incident did not establish a change to stETH redemption rights. Existing rebase guardrails did not stop the 32 ETH discrepancy because it was within their allowed range.",
      "confirmedFacts": [
        "AO and VEBO report delivery was delayed by approximately three to six hours between July 24 and July 28.",
        "The July 25 report omitted one in-flight 32 ETH deposit and showed an extrapolated APR of 2.04% rather than the expected 2.15%.",
        "A manually checked July 26 report included the missing ETH and showed an extrapolated APR of 2.29%.",
        "Some VEBO reports were not produced between July 26 and July 28, modestly extending withdrawal-request finalization.",
        "Lido reported that no funds were lost or frozen and deployed oracle-code remediations."
      ],
      "unresolved": [
        "The exact cause of the single omitted pending deposit could not be reproduced or established; a CL, EL, and KAPI response race remained a working assumption.",
        "The long-term effectiveness of the new invariant checks and circuit breakers requires observation across subsequent oracle-report cycles."
      ],
      "advisorDiligenceImplications": [
        "Add the incident and remediation details to the Lido diligence record because accounting and exit-oracle reliability directly affect reported backing, rebases, and withdrawal timing.",
        "Review subsequent AO and VEBO reports for repeated balance mismatches or delayed exit processing before treating the issue as fully closed.",
        "The confirmed recovery and absence of loss do not independently justify a restriction, but they do require memo review of SRv3 oracle dependencies."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-b2c7e475e8e06ef5a573289e",
      "stableKey": "axelar:governance-deposit-increase:proposal-493",
      "version": 1,
      "eventDate": "2026-07-25",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Axelar approves sharply higher governance proposal deposits",
      "category": "governance",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Increase governance deposit: min_deposit to 150,000 AXL, expedited to 400,000 AXL",
          "authority": "Axelar on-chain governance",
          "url": "https://axelarscan.io/proposal/493",
          "documentType": "onchain_governance_record",
          "publishedOn": "2026-07-25"
        }
      ],
      "whatHappened": "Axelar governance passed proposal 493 to raise the deposit required to open ordinary and expedited governance proposals.",
      "whatChanged": "Governance approved a 75-fold increase in the ordinary minimum deposit and an approximately 133-fold increase in the expedited minimum deposit, materially raising the capital required to initiate votes.",
      "whatDidNotChange": "The record does not independently prove that the new parameters became operative. Voting periods, quorum, thresholds, deposit ratio, and refund treatment were unchanged by the proposal.",
      "confirmedFacts": [
        "The ordinary minimum deposit would increase from 2,000 to 150,000 AXL.",
        "The expedited minimum deposit would increase from 3,000 to 400,000 AXL.",
        "The proposal passed.",
        "Deposits remain returnable when a proposal passes or fails without a veto."
      ],
      "unresolved": [
        "The effective parameter-update transaction or post-execution state is not supplied.",
        "The practical effect on proposer diversity and governance participation is not yet observable."
      ],
      "advisorDiligenceImplications": [
        "Review the Axelar memo's governance-access and concentration assumptions because materially fewer holders may be able to originate proposals independently.",
        "Verify live governance parameters before treating the approved amounts as operative.",
        "Monitor whether the higher deposits reduce spam without materially narrowing credible proposer access."
      ],
      "followUpOn": "2026-08-01",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-c7f7d7ea1a6ed7491bcbc5ed",
      "stableKey": "sky-july-2026-ssr-and-core-vault-fee-proposal",
      "version": 1,
      "eventDate": "2026-07-23",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Sky risk advisor proposes an 8 bp SSR cut and 100 bp Core Vault fee increases",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Risk Month in Review: July 2026",
          "authority": "Sky / BA Labs",
          "url": "https://forum.skyeco.com/t/risk-month-in-review-july-2026/28128",
          "documentType": "official risk-advisor report",
          "publishedOn": "2026-07-31"
        }
      ],
      "whatHappened": "BA Labs reported recommending an 8-basis-point reduction in the Sky Savings Rate and one-percentage-point increases in Core Vault stability fees following consultation with the Core Council.",
      "whatChanged": "A concrete rate proposal entered the Sky parameter process and would change both saver yield and borrower costs if executed.",
      "whatDidNotChange": "The monthly report does not itself prove the poll, BEAM action, or executive execution; no operative rate is inferred from the recommendation.",
      "confirmedFacts": [
        "The recommended SSR reduction was 0.08 percentage points.",
        "The recommended Core Vault stability-fee increase was 1 percentage point.",
        "BA Labs estimated the combined changes could increase annual USDS profit by approximately 8.51 million USDS."
      ],
      "unresolved": [
        "Whether the recommendation was approved and executed.",
        "The exact effective timestamp and resulting live SSR and vault fees."
      ],
      "advisorDiligenceImplications": [
        "Verify live rate state and update Sky yield assumptions if the recommendation became operative.",
        "Review client-facing yield materials so a proposed rate is not presented as current."
      ],
      "followUpOn": "2026-08-03",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-c80c7773b9a33a4c3a91da8d",
      "stableKey": "morpho-birch-hill-rwa-usdc-launch-2026-07-21",
      "version": 1,
      "eventDate": "2026-07-21",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Birch Hill launches RWA USDC vault on Morpho",
      "category": "launch_access",
      "posture": "launched",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "morpho-blue",
          "name": "Morpho Blue"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Introducing Birch Hill vaults on Morpho",
          "authority": "Morpho Blue",
          "url": "https://forum.morpho.org/t/introducing-birch-hill-vaults-on-morpho/2364",
          "documentType": "official forum launch record",
          "publishedOn": "2026-07-21"
        }
      ],
      "whatHappened": "Birch Hill announced that its RWA USDC Vault was live on Base in a controlled rollout, supplying USDC to isolated asset-backed credit markets on Morpho.",
      "whatChanged": "The launch added a curator-managed Morpho exposure whose first target was GRO/USDC, using tokenized equity in a private multifamily REIT as collateral, a Chronicle NAV oracle, and a 62.5% LLTV.",
      "whatDidNotChange": "The launch did not modify Morpho Blue's immutable core market contracts and did not make the Birch Hill vault part of Ketju's existing Morpho approval. No current client holding was identified.",
      "confirmedFacts": [
        "The operator described the vault as live on Base in a controlled rollout.",
        "The supply asset is USDC and the initial target market is isolated GRO/USDC.",
        "The announced collateral is GRO tokenized private-REIT equity, with a Chronicle NAV oracle and 62.5% LLTV.",
        "The announced fee is a 10% performance fee."
      ],
      "unresolved": [
        "The cached record does not expose a vault contract address for independent state verification.",
        "Controlled-rollout capacity, withdrawal liquidity, collateral enforceability, valuation controls, and oracle performance remain to be diligenced."
      ],
      "advisorDiligenceImplications": [
        "Add the vault to the Morpho research perimeter as a separate RWA and curator exposure.",
        "Require diligence on Birch Hill, GRO legal rights, Chronicle's NAV process, utilization, and exit liquidity before considering advisor use.",
        "Do not treat general Morpho protocol approval as approval of this vault."
      ],
      "followUpOn": "2026-09-01",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-9bc7df216a6c6e181d3e5394",
      "stableKey": "morpho-midnight-public-launch",
      "version": 1,
      "eventDate": "2026-07-21",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Morpho launches Midnight fixed-rate, fixed-term credit markets",
      "category": "launch_access",
      "posture": "launched",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "morpho-blue",
          "name": "Morpho Blue"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Now Live: Morpho Midnight & New Markets App",
          "authority": "Morpho",
          "url": "https://morpho.org/blog/now-live-morpho-midnight",
          "documentType": "official launch notice",
          "publishedOn": "2026-07-21"
        }
      ],
      "whatHappened": "Morpho launched Midnight, an immutable noncustodial fixed-rate, fixed-term lending protocol, together with a new Markets App.",
      "whatChanged": "Morpho's live product perimeter expanded beyond Blue's variable-rate, open-term markets to a distinct fixed-term credit primitive initially available on Base for cbBTC/USDC.",
      "whatDidNotChange": "Midnight is not Morpho Blue v2 and does not replace Blue. The launch did not include vault adapters, auto-rolling, callbacks, cross-chain support, gates, or secondary exits.",
      "confirmedFacts": [
        "The protocol and Markets App were live on July 21, 2026.",
        "Initial access was limited to Base, cbBTC/USDC, and a limited set of maturities.",
        "Launch functionality supported direct lending and borrowing.",
        "Morpho described Midnight contracts as immutable and non-upgradeable."
      ],
      "unresolved": [
        "Deployment-address verification and initial market utilization.",
        "Maturity liquidity and early-exit behavior without a secondary market.",
        "The timing and control implications of later vault adapters, callbacks, gates, and cross-chain features."
      ],
      "advisorDiligenceImplications": [
        "Do not extend the Morpho Blue approval or limits to Midnight; it requires a separate diligence determination.",
        "Add fixed-term liquidity, maturity, rate-discovery, and collateral controls to the Morpho research perimeter."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-621c85ce33d9b1e7bea15f9a",
      "stableKey": "lido-cmv2-penalty-framework-2026-07-20",
      "version": 1,
      "eventDate": "2026-07-20",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Lido governance approves CMv2 penalty framework",
      "category": "governance",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Penalty Framework | CMv2",
          "authority": "Lido",
          "url": "https://research.lido.fi/t/penalty-framework-cmv2/11732",
          "documentType": "official governance record",
          "publishedOn": "2026-07-06"
        }
      ],
      "whatHappened": "Lido's Snapshot vote approved the Curated Module v2 Penalty Framework, establishing rules for assessing node-operator incidents, losses, missed rewards, withdrawal delays, and other operational failures.",
      "whatChanged": "The framework authorizes the Curated Module Committee to use a General Delayed Penalty that can lock an assessed amount from an operator's bond, pursue voluntary compensation, or progress the locked bond toward burn through the applicable governance or Easy Track process. It also delegates non-material framework refinements to the committee.",
      "whatDidNotChange": "Material changes to penalty scope, new penalty mechanisms, significant operator obligations, or governance authority still require standard DAO approval. The approval did not itself impose a penalty on a named operator or change stETH withdrawal rights.",
      "confirmedFacts": [
        "The Snapshot concluded successfully on July 20 with 58.0 million LDO for adoption and zero against.",
        "The General Delayed Penalty is the primary manual mechanism for violations or losses not handled automatically.",
        "Reported penalty amounts can be locked from a node operator's bond and may be compensated, burned through governance or Easy Track, or released under the framework's conditions.",
        "The Curated Module Committee may refine thresholds, methods, examples, and non-material procedures without a full DAO vote.",
        "Material penalty or governance changes remain subject to DAO approval."
      ],
      "unresolved": [
        "No operator-specific application demonstrates how the committee will exercise its discretion in practice.",
        "The downstream effect on Curated Module operator participation, bond economics, and validator performance remains to be observed."
      ],
      "advisorDiligenceImplications": [
        "Update Lido control diligence to reflect the committee's approved discretion over incident assessment and operator bond penalties.",
        "Monitor committee amendments and the first operator-specific cases for consistency, transparency, and effects on validator operations.",
        "Review whether the memo's operator-governance analysis adequately captures the new delegated authority and loss-compensation process."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-38579cf17a3246557d4ab7d0",
      "stableKey": "spark-liquidity-layer:freezer-multisig-threshold:2026-07-20",
      "version": 1,
      "eventDate": "2026-07-20",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Spark proposes a 2-of-4 freezer multisig and signer rotation",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "spark-liquidity-layer",
          "name": "Spark Liquidity Layer"
        }
      ],
      "primaryDocuments": [
        {
          "title": "SAEP-18: Update Spark Liquidity Layer Freezer Multisig",
          "authority": "Spark governance via Snapshot",
          "url": "https://snapshot.org/#/sparkfi.eth/proposal/0x5ac67ae3e4808faf16cbd271d9c7398f86116747c4b395ba56e47fb2b4068627",
          "documentType": "governance_proposal",
          "publishedOn": "2026-07-20"
        }
      ],
      "whatHappened": "Spark governance received a proposal to replace the Spark Assets Foundation signer with an additional Phoenix Labs signer and increase the Liquidity Layer Freezer Multisig threshold from 1-of-4 to 2-of-4.",
      "whatChanged": "A concrete control-change proposal entered governance review, supplying new evidence about the freezer role's signer composition and intended approval threshold.",
      "whatDidNotChange": "The record does not prove that the multisig configuration changed, identify an execution transaction, disclose the multisig address, or resolve the rejected memo's broader per-chain administrator and relayer-control gaps.",
      "confirmedFacts": [
        "The proposal identifies the prior freezer configuration as one Spark Assets Foundation signer, two Phoenix Labs signers, VoteWizard, and a 1-of-4 threshold.",
        "The freezer can deauthorize addresses holding the Relayer Role.",
        "The proposal would replace the Spark Assets Foundation signer with another Phoenix Labs signer.",
        "The proposed threshold is 2-of-4."
      ],
      "unresolved": [
        "The vote outcome and any implementation transaction are not established.",
        "The operative multisig address, signer addresses, and chain-by-chain scope remain undisclosed in this record.",
        "It is not established whether every Liquidity Layer deployment uses this freezer or has separate local emergency authority."
      ],
      "advisorDiligenceImplications": [
        "Review the Spark Liquidity Layer memo because the proposal partially addresses its documented freezer-control disclosure gap.",
        "Verify the live multisig address, owners, threshold, and per-chain authority before crediting the proposed configuration.",
        "Do not reopen or approve the rejected object solely because governance proposed a safer threshold."
      ],
      "followUpOn": "2026-07-27",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-654ba71939d66645415b8811",
      "stableKey": "aave-v3:arbitrum:usdai-susdai-arfc:2026-07-20",
      "version": 1,
      "eventDate": "2026-07-20",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Aave proposes USDai and sUSDai onboarding on Arbitrum",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        },
        {
          "type": "asset",
          "id": "usd-ai",
          "name": "USD.AI (sUSDai)"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Onboard USDai & sUSDai to Aave V3 Arbitrum Instance",
          "authority": "Aave DAO via Snapshot",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0xea4a214958299ff36fb85c53cf2f727ce2df3e145279e8f6bef6766f26297d76",
          "documentType": "governance_proposal",
          "publishedOn": "2026-07-20"
        }
      ],
      "whatHappened": "An Aave ARFC proposed onboarding USDai and sUSDai to the Arbitrum V3 instance with supply caps, a USDai borrow cap, CAPO settings, and isolated E-mode collateral configurations.",
      "whatChanged": "A concrete pathway was proposed for Aave to accept exposure connected to the rejected USD.AI credit product, requiring cross-memo review before any implementation.",
      "whatDidNotChange": "The ARFC did not execute an AIP, activate either reserve, extend Ketju approval to the assets, or establish that the proposed parameters became operative.",
      "confirmedFacts": [
        "The proposal specifies 55 million supply caps for both USDai and sUSDai.",
        "It specifies a 45 million borrow cap for USDai.",
        "The proposed sUSDai/USDai E-mode uses 89% LTV and a 91% liquidation threshold.",
        "The proposed sUSDai stablecoin E-mode uses 88% LTV and a 90% liquidation threshold.",
        "The proposal says a successful ARFC would require a later AIP for final confirmation and enforcement."
      ],
      "unresolved": [
        "The ARFC vote result and any subsequent AIP or execution are not established.",
        "The proposal's top-level borrowability table conflicts with its borrow-cap and E-mode specifications for USDai.",
        "No executed reserve configuration, oracle address, liquidity assessment, or deployed CAPO configuration is supplied."
      ],
      "advisorDiligenceImplications": [
        "Review the Aave v3 memo for potential leakage of rejected USD.AI credit exposure through collateral and E-mode pathways.",
        "Keep USDai and sUSDai outside approved Aave allocations unless a later executed payload receives asset-specific review.",
        "Reconcile the contradictory borrowability specifications before evaluating any final AIP."
      ],
      "followUpOn": "2026-07-27",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-a4953c64166ed9f11e0c4db7",
      "stableKey": "aave-v3:ethereum-core:syrupusdc-arfc:2026-07-20",
      "version": 1,
      "eventDate": "2026-07-20",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Aave proposes syrupUSDC onboarding on Ethereum Core",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        },
        {
          "type": "asset",
          "id": "maple",
          "name": "Maple Finance"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Onboard syrupUSDC to Aave V3 Core Instance",
          "authority": "Aave DAO via Snapshot",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0x0800663767b84a5bdcdeb417cc0eb7a55b80561684d763bca593363dd83dfcc2",
          "documentType": "governance_proposal",
          "publishedOn": "2026-07-20"
        }
      ],
      "whatHappened": "An Aave ARFC proposed onboarding Maple's syrupUSDC to the Ethereum Core instance with a 50 million supply cap and a stablecoin E-mode against USDC and GHO.",
      "whatChanged": "A concrete governance path was proposed for a rejected private-credit exposure to become collateral within an approved-with-limits Aave deployment.",
      "whatDidNotChange": "The proposal did not execute an AIP, activate syrupUSDC, change Ketju's Maple rejection, or extend the Aave approval to this collateral path.",
      "confirmedFacts": [
        "The proposed syrupUSDC supply cap is 50 million.",
        "The stablecoin E-mode specifies 90% LTV, a 92% liquidation threshold, and a 4% liquidation bonus.",
        "The E-mode table identifies syrupUSDC as collateral and USDC and GHO as borrowable assets.",
        "The proposal says a successful ARFC would require a later AIP for final confirmation and enforcement."
      ],
      "unresolved": [
        "The ARFC vote result and any subsequent AIP or execution are not established.",
        "The top-level specification says collateral is disabled while the E-mode table says syrupUSDC is collateral, leaving the intended configuration ambiguous.",
        "No executed oracle, cap, liquidity, or liquidation configuration is supplied."
      ],
      "advisorDiligenceImplications": [
        "Review the Aave v3 memo for rejected Maple credit exposure entering through syrupUSDC collateral.",
        "Do not treat the existing Aave approval as covering syrupUSDC without asset-specific custody, credit, oracle, liquidity, and withdrawal review.",
        "Require the final payload to resolve the proposal's contradictory collateral specification."
      ],
      "followUpOn": "2026-07-27",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-ef73165e78a6aa9ff0ec4c6f",
      "stableKey": "axelar:amplifier-contract-admin-rotation:proposal-492",
      "version": 1,
      "eventDate": "2026-07-17",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Axelar approves Amplifier contract-admin rotation to a multisig",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Rotate mainnet Amplifier CosmWasm contract admin to multisig",
          "authority": "Axelar on-chain governance",
          "url": "https://axelarscan.io/proposal/492",
          "documentType": "onchain_governance_record",
          "publishedOn": "2026-07-17"
        }
      ],
      "whatHappened": "Axelar governance passed proposal 492 to rotate the administrator and upgrade authority for 35 mainnet Amplifier CosmWasm contracts to a specified multisig.",
      "whatChanged": "Governance authorized a new upgrade-control endpoint across gateway, routing, voting, rewards, service-registry, multisig, and Interchain Token Service components.",
      "whatDidNotChange": "The governance record does not independently prove that every contract-admin update executed or disclose the destination multisig's signer identities, threshold, or internal controls.",
      "confirmedFacts": [
        "Proposal 492 passed.",
        "The destination address is axelar14vps3ev03zyp2wmj89etx8rrxdxyltfy4rzl5m.",
        "The proposal identifies 35 affected contracts.",
        "Affected contract families include gateways, routers, voting verifiers, multisig components, rewards, service registry, and Interchain Token Service."
      ],
      "unresolved": [
        "Execution and post-change admin state for each contract are not established.",
        "The destination multisig's signer identities, threshold, key custody, and transaction policy are not supplied.",
        "It is not established whether every affected contract shares identical upgrade and emergency powers."
      ],
      "advisorDiligenceImplications": [
        "Review the Axelar memo's upgrade-authority map and replace prior administrator assumptions only after contract-level verification.",
        "Obtain the multisig owner set and threshold before assessing whether the rotation reduces or concentrates control risk.",
        "Reconcile all 35 contracts because partial execution would leave mixed administrator states."
      ],
      "followUpOn": "2026-07-24",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-a5a58214066ee066acefe993",
      "stableKey": "lido:0x02-csm:launch-proposal:2026-07-10",
      "version": 1,
      "eventDate": "2026-07-10",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Lido proposes a separate permissionless 0x02 validator module",
      "category": "governance",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "0x02 CSM: New Permissionless Module Launch",
          "authority": "Lido DAO via Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0xed2a3b1f796cefdd531abe14ba01363b2da7887434cefdd54ba71ffb6dff59a7",
          "documentType": "governance_proposal",
          "publishedOn": "2026-07-10"
        }
      ],
      "whatHappened": "Lido governance received a proposal to launch a separate permissionless Community Staking Module for 0x02 withdrawal credentials and validators with effective balances up to 2,048 ETH.",
      "whatChanged": "The proposal introduced a two-stage deposit and top-up allocation design and sought a 20% combined stake-share ceiling for the existing and proposed CSM instances.",
      "whatDidNotChange": "The proposal does not prove mainnet deployment. The existing 0x01 CSM would continue serving smaller operators, and the exact top-up queue capacity was deferred.",
      "confirmedFacts": [
        "The proposed 0x02 CSM is a separate module rather than a replacement for 0x01 CSM.",
        "It is designed for validators with effective balances up to 2,048 ETH.",
        "The design first allocates 32 ETH and then uses a capacity-limited queue for progressive top-ups.",
        "The proposal seeks a 20% maximum combined stake share for the 0x01 and 0x02 CSM instances.",
        "Existing 0x01 operators would not receive a direct consolidation path into the new module."
      ],
      "unresolved": [
        "The vote result, final launch parameters, deployed addresses, and mainnet activation are not established.",
        "The number of top-up queue seats remained deferred until closer to deployment.",
        "Production bond-risk, exit, penalty, and allocation behavior for variable-balance validators remains untested."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido memo's validator-module concentration, permissionless operator, bond, and allocation assumptions.",
        "Do not treat the proposed module as live or covered by the existing approval until deployed contracts and final parameters are verified.",
        "Monitor whether the combined 20% ceiling and queue controls are encoded and enforceable on-chain."
      ],
      "followUpOn": "2026-07-31",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-5f7b0364993c9042e30b5b6e",
      "stableKey": "morpho-presto-usdc-vaults-launch-2026-07-08",
      "version": 1,
      "eventDate": "2026-07-08",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Presto launches two USDC vaults on Morpho",
      "category": "launch_access",
      "posture": "launched",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "morpho-blue",
          "name": "Morpho Blue"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Introducing Presto Vaults on Morpho",
          "authority": "Morpho Blue",
          "url": "https://forum.morpho.org/t/introducing-presto-vaults-on-morpho/2354",
          "documentType": "official forum launch record",
          "publishedOn": "2026-07-08"
        }
      ],
      "whatHappened": "Presto introduced two Ethereum Morpho vaults: USDC Prime, lending against WBTC, and USDC Forte, allocating to private-credit and RWA collateral markets.",
      "whatChanged": "The launch added curator-managed USDC exposures with different risk mandates. Prime targets WBTC/USDC with a 10% performance fee; Forte targets FalconX- and JAAA-related markets with a 15% performance fee and higher counterparty, legal, oracle, and liquidity complexity.",
      "whatDidNotChange": "The launch did not modify Morpho Blue's core contracts and did not extend Ketju approval to either Presto vault. No current client holding was identified.",
      "confirmedFacts": [
        "Presto USDC Prime was identified at 0x133614490896bc02C774bc3399E4Db1B6D05a2CA on Ethereum.",
        "Presto USDC Forte was identified at 0x68A65f315BCd3C3456d1368Ff88bC661856548E1 on Ethereum.",
        "Prime was described as lending exclusively against WBTC with a 10% performance fee.",
        "Forte was described as allocating to AA_FalconXUSDC/USDC, wFalconX/USDC, and wJAAA/USDC with a 15% performance fee.",
        "The record states that market additions are subject to timelocks of at least three days, with more critical actions delayed seven days."
      ],
      "unresolved": [
        "Independent verification of live allocations, caps, utilization, withdrawal liquidity, and role configuration remains necessary.",
        "The legal enforceability, counterparty quality, liquidity, and oracle behavior of Forte's private-credit collateral require separate diligence."
      ],
      "advisorDiligenceImplications": [
        "Add both vaults to the Morpho research perimeter without treating them as approved exposures.",
        "Require separate curator, collateral, oracle, timelock, utilization, and exit-liquidity review before advisor consideration.",
        "Give Forte heightened diligence because its yield depends on private-credit and RWA structures rather than only liquid crypto collateral."
      ],
      "followUpOn": "2026-09-01",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-141dd827d3f9f05f4536ecf0",
      "stableKey": "axelar:secret-bridge-recovery-signal:proposal-490",
      "version": 1,
      "eventDate": "2026-07-05",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Axelar approves a non-binding freeze and recustody signal",
      "category": "governance",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "mixed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Signaling Proposal: Freeze Hacker Funds and Recustody to a Trusted Distributor at a Later Date",
          "authority": "Axelar on-chain governance",
          "url": "https://axelarscan.io/proposal/490",
          "documentType": "onchain_governance_record",
          "publishedOn": "2026-07-05"
        }
      ],
      "whatHappened": "Axelar governance passed a non-binding signaling proposal supporting a coordinated freeze of funds attributed to the June Axelar–Secret IBC bridge attacker and later recustody to a vetted distributor.",
      "whatChanged": "The community created a formal on-chain record of recovery intent and authorized contributors to prepare a later binding proposal with freeze, custody, and redistribution mechanics.",
      "whatDidNotChange": "The text proposal did not freeze, seize, move, recustody, or distribute funds, and it did not select a distributor or approve a final victim-repayment plan.",
      "confirmedFacts": [
        "Proposal 490 passed.",
        "The proposal is explicitly non-binding and carries no automatic on-chain action.",
        "It identifies axelar1hzra9z4zn8q0w8f3dj2wnw0xgetu8dfdhl6ad8 as the attacker-controlled wallet.",
        "It calls for a later binding proposal specifying the freeze mechanism, distributor, and redistribution plan."
      ],
      "unresolved": [
        "Whether the identified funds were actually frozen remains unverified.",
        "The amount, asset composition, custody status, and recoverability of the referenced funds are not established by this record.",
        "No trusted distributor, binding payload, entitlement schedule, or repayment timing had been approved."
      ],
      "advisorDiligenceImplications": [
        "Keep the Axelar incident and recovery path under memo review; a favorable signal is not recovered funds.",
        "Require operative freeze evidence and a binding, auditable distribution plan before crediting recovery.",
        "Continue monitoring bridge loss-allocation, custody, and cross-chain administrator powers implicated by the response."
      ],
      "followUpOn": "2026-07-19",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-424e0265db2664969d237288",
      "stableKey": "axelar:service-governance-ownership-migration:proposal-491",
      "version": 1,
      "eventDate": "2026-07-03",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Axelar approves ITS and Amplifier gateway ownership migration",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Accept AxelarServiceGovernance ownership of ITS and Amplifier Gateways",
          "authority": "Axelar on-chain governance",
          "url": "https://axelarscan.io/proposal/491",
          "documentType": "onchain_governance_record",
          "publishedOn": "2026-07-03"
        }
      ],
      "whatHappened": "Axelar governance passed proposal 491 to schedule AxelarServiceGovernance ownership acceptance for Interchain Token Service contracts across 21 EVM chains and Amplifier gateways on Hedera, Hyperliquid, Monad, and XRPL EVM.",
      "whatChanged": "Governance authorized a broad cross-chain migration of ownership and administrative control to AxelarServiceGovernance.",
      "whatDidNotChange": "The record does not prove that each timelock expired, each acceptOwnership call completed, or every target's final owner state changed on July 3.",
      "confirmedFacts": [
        "Proposal 491 passed.",
        "The payload targets Interchain Token Service on 21 EVM chains.",
        "It also targets AxelarAmplifierGateway on Hedera, Hyperliquid, Monad, and XRPL EVM.",
        "The mechanism uses scheduled timelock proposals delivered through AxelarnetGateway calls."
      ],
      "unresolved": [
        "The effective ownership-acceptance transaction and final owner state for each target are not supplied.",
        "Per-chain timelock delays, failed calls, retries, and partial completion remain unverified.",
        "The full authority and internal controls of AxelarServiceGovernance require reconciliation."
      ],
      "advisorDiligenceImplications": [
        "Review the Axelar memo's cross-chain ownership and upgrade-authority map.",
        "Verify the owner and pending-owner state for every relevant ITS and Amplifier gateway before treating the migration as complete.",
        "Monitor timelock and governance dependencies separately for client-used chains."
      ],
      "followUpOn": "2026-07-10",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-618f51ec4d9dd1dbb8a08c90",
      "stableKey": "rocket-pool-rpip-83-six-eth-megapool-bond",
      "version": 1,
      "eventDate": "2026-07-02",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "Rocket Pool proposes a 6 ETH megapool-validator bond",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "rocket-pool",
          "name": "Rocket Pool"
        }
      ],
      "primaryDocuments": [
        {
          "title": "RPIP-83: Increasing Megapool Bond Requirement",
          "authority": "Rocket Pool",
          "url": "https://dao.rocketpool.net/t/rpip-83-increasing-megapool-bond-requirement/3990",
          "documentType": "official governance proposal",
          "publishedOn": "2026-07-02"
        }
      ],
      "whatHappened": "RPIP-83 proposed requiring 6 ETH of node-operator bond for each new megapool validator and using rewards to top up bonds below the required curve.",
      "whatChanged": "A concrete alternative to the planned lower reduced-bond setting entered governance consideration in response to limited rETH demand and withdrawal-liquidity needs.",
      "whatDidNotChange": "No approval or executed bond-curve parameter change is shown; existing megapool requirements remained operative.",
      "confirmedFacts": [
        "The proposal specifies 6 ETH per new megapool validator.",
        "It would allow node operators to top up bonds to the new curve.",
        "Megapool rewards below the curve would increase the bond instead of being paid directly."
      ],
      "unresolved": [
        "Whether RPIP-83 was approved and executed.",
        "The final implementation schedule and interaction with later Saturn upgrades."
      ],
      "advisorDiligenceImplications": [
        "Monitor because execution would change node-operator capital requirements, migration capacity, and the economic assumptions supporting rETH liquidity.",
        "Do not update the Rocket Pool memo's operative bond mechanics before execution evidence is available."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-cd8d2a386ec11b13f74ab01f",
      "stableKey": "defi-saver-aave-v3-pt-usdg-september-2026-integration",
      "version": 1,
      "eventDate": "2026-07-01",
      "publishedAt": "2026-08-22T14:06:02.815Z",
      "title": "DeFi Saver launches PT-USDG Aave v3 looping and unwinding support",
      "category": "launch_access",
      "posture": "launched",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "product",
          "id": "defi-saver-asset-management",
          "name": "DeFi Saver Asset Management"
        },
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "DeFi Saver Newsletter: July 2026",
          "authority": "DeFi Saver",
          "url": "https://blog.defisaver.com/defi-saver-newsletter-july-2026/",
          "documentType": "official product update",
          "publishedOn": "2026-07-10"
        }
      ],
      "whatHappened": "DeFi Saver added live support for the PT-USDG-24SEP2026 Aave v3 collateral market, including atomic looping and unwinding workflows.",
      "whatChanged": "The DeFi Saver dependency can now automate a new fixed-maturity collateral exposure and leveraged looping path.",
      "whatDidNotChange": "DeFi Saver's dependency approval does not approve PT-USDG, Aave v3, Pendle, or any underlying leveraged strategy; base-protocol verdicts and limits remain separate.",
      "confirmedFacts": [
        "The PT-USDG-24SEP2026 integration was described as live.",
        "DeFi Saver supports one-transaction looping and one-transaction unwinding for the market.",
        "The official update said the initial 15 million supply cap had been reached."
      ],
      "unresolved": [
        "The exact live Aave market parameters and oracle configuration.",
        "Whether any approved or client-held position used the integration.",
        "Whether subsequent cap increases changed the available exposure."
      ],
      "advisorDiligenceImplications": [
        "Keep the DeFi Saver approval dependency-only and do not infer approval of the newly supported collateral or looping strategy.",
        "Review automation inventories for client positions using the new market."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-1cfb3d4336c6430a542cc4ff",
      "stableKey": "axelar:amplifier-permission-control:admin-rotation-proposal-487",
      "version": 1,
      "eventDate": "2026-06-30",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Axelar rotates permission-control administrators for ITS, Router, and Multisig",
      "category": "control_change",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Update permission-control admin for ITS, Router and Multisig",
          "authority": "Axelar on-chain governance",
          "url": "https://axelarscan.io/proposal/487",
          "documentType": "on_chain_governance_record",
          "publishedOn": "2026-06-30"
        }
      ],
      "whatHappened": "Axelar governance passed proposal 487, executing administrator updates on three Amplifier contracts.",
      "whatChanged": "The permission-control administrator for the Interchain Token Service, Router, and Multisig moved from axelar1nctnr9x0qexemeld5w7w752rmqdsqqv92dw9am to axelar1kctshqfxw74usjme9mqlvkf0rgdh96ty0mmm6p.",
      "whatDidNotChange": "The record does not identify the new controller's signer set, threshold, or internal governance policy, and it reports no asset loss or route interruption.",
      "confirmedFacts": [
        "Proposal 487 passed at the June 30 voting deadline.",
        "The payload contains three MsgExecuteContract update_admin calls.",
        "All three calls set the same new administrator address."
      ],
      "unresolved": [
        "The identity, signer composition, threshold, and emergency powers of the new administrator remain unresolved from this record."
      ],
      "advisorDiligenceImplications": [
        "Update the Axelar control map for all three Amplifier contracts.",
        "Verify the new controller's composition, threshold, rotation process, and ability to migrate or pause contracts.",
        "Reassess whether the new controller changes the dependency's concentration or emergency-governance assumptions."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-db345c132f00a6fa16b111cc",
      "stableKey": "axelar:cosmwasm-emergency-multisig:upload-instantiate-authority-proposal-486",
      "version": 1,
      "eventDate": "2026-06-29",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Axelar expands emergency multisig CosmWasm deployment authority",
      "category": "control_change",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Allow the emergency multisig to upload and instantiate CosmWasm code",
          "authority": "Axelar on-chain governance",
          "url": "https://axelarscan.io/proposal/486",
          "documentType": "on_chain_governance_record",
          "publishedOn": "2026-06-29"
        }
      ],
      "whatHappened": "Axelar governance passed proposal 486 and updated x/wasm parameters to permit an emergency multisig to upload and instantiate or migrate CosmWasm code.",
      "whatChanged": "The emergency address axelar14vps3ev03zyp2wmj89etx8rrxdxyltfy4rzl5m gained a fast path for code upload and default instantiation or migration.",
      "whatDidNotChange": "The proposal does not itself migrate a named contract or authorize direct asset transfers; it changes who may perform future emergency code actions.",
      "confirmedFacts": [
        "Proposal 486 passed on June 29.",
        "The payload is a MsgUpdateParams transaction for the CosmWasm module.",
        "code_upload_access and instantiate_default_permission were both changed to AnyOfAddresses."
      ],
      "unresolved": [
        "The emergency multisig's full signer identity, operating policy, and activation procedures are not established by this record.",
        "No subsequent exercise of the new authority is established here."
      ],
      "advisorDiligenceImplications": [
        "Record the emergency multisig as an upgrade-capable controller in the Axelar dependency memo.",
        "Verify signer composition, quorum, disclosure, monitoring, and post-action accountability for the fast upgrade path.",
        "Treat future emergency code uploads and migrations as memo-review events."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-bfc4de7a3e257f032fb112ed",
      "stableKey": "axelar:xrpl-amplifier-contracts:admin-rotation-proposal-482",
      "version": 1,
      "eventDate": "2026-06-27",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Axelar transfers XRPL Amplifier migration authority to 3-of-6 multisig",
      "category": "control_change",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Rotate XRPL{Gateway,VotingVerifier,MultisigProver} admin to multisig",
          "authority": "Axelar on-chain governance",
          "url": "https://axelarscan.io/proposal/482",
          "documentType": "on_chain_governance_record",
          "publishedOn": "2026-06-27"
        }
      ],
      "whatHappened": "Axelar governance passed proposal 482 and reassigned the migration administrator for the XRPL Gateway, VotingVerifier, and MultisigProver contracts.",
      "whatChanged": "Migration authority moved from axelar1nctnr9x0qexemeld5w7w752rmqdsqqv92dw9am to the 3-of-6 multisig axelar14vps3ev03zyp2wmj89etx8rrxdxyltfy4rzl5m.",
      "whatDidNotChange": "The proposal does not report a contract migration, verifier-set change, route pause, or asset loss.",
      "confirmedFacts": [
        "Proposal 482 passed on June 27.",
        "The payload contains three MsgUpdateAdmin actions.",
        "All three XRPL-related contracts received the same 3-of-6 multisig administrator."
      ],
      "unresolved": [
        "The six signer identities, key-custody arrangements, rotation policy, and emergency procedures remain unresolved."
      ],
      "advisorDiligenceImplications": [
        "Update XRPL integration diligence to reflect concentrated 3-of-6 migration authority.",
        "Verify whether the multisig is the same emergency controller used by other Axelar proposals and assess aggregate authority.",
        "Require review of any future migration performed through this administrator."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-52a07778c4d9319436948a02",
      "stableKey": "aave-v3:risk-stewards-umbrella-pauser:arfc-approval-2026-06",
      "version": 1,
      "eventDate": "2026-06-26",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Aave approves faster Risk Steward actions and Umbrella pauser reassignment",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Risk Stewards Cooldown Reduction & Umbrella Pauser Role Reassignment",
          "authority": "Aave DAO via Snapshot",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0x7083921f2f549ffa2cdc294c8ff60fdc82af0becbb7b2f20f4f296c34694aaf2",
          "documentType": "snapshot_governance_record",
          "publishedOn": "2026-06-22"
        }
      ],
      "whatHappened": "Aave DAO's Snapshot vote approved an ARFC to shorten the minimum delay for selected cap and interest-rate parameters and reassign Umbrella pause authority.",
      "whatChanged": "The approved design reduces selected Risk Steward minDelay settings from 72 to 36 hours and assigns Umbrella pause and unpause authority to the Aave Protocol Guardian.",
      "whatDidNotChange": "The vote did not execute an AIP; maxPercentChange bounds were not reduced, and Umbrella configuration and role-management authority remains with the Aave Governance Executor under the approved design.",
      "confirmedFacts": [
        "The Snapshot vote closed on June 26 with all recorded voting power cast for the ARFC.",
        "The proposal covers selected supply-cap, borrow-cap, and interest-rate-model parameters.",
        "The proposed Umbrella role controls both pause and unpause, while DEFAULT_ADMIN_ROLE remains with governance."
      ],
      "unresolved": [
        "The candidate does not establish a subsequent AIP or on-chain execution of either control change."
      ],
      "advisorDiligenceImplications": [
        "Review whether a 36-hour cooldown materially changes the expected notice period for Aave exposure-cap and rate changes.",
        "Record the Protocol Guardian as the proposed rapid-response controller for Umbrella pauses, while preserving the distinction between pause authority and configuration authority.",
        "Monitor the final AIP payload and execution before treating the changes as operative."
      ],
      "followUpOn": "2026-08-26",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-8d0d4f5d4d2105a58b7b551f",
      "stableKey": "lido-0x02-csm-module-proposal-2026-06-25",
      "version": 1,
      "eventDate": "2026-06-25",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Lido proposes a permissionless 0x02 CSM module",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "0x02 CSM Landscape",
          "authority": "Lido Governance",
          "url": "https://research.lido.fi/t/0x02-csm-landscape/11697",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-06-25"
        }
      ],
      "whatHappened": "Lido contributors proposed a separate permissionless CSM using 0x02 withdrawal credentials and validator balances up to 2,048 ETH.",
      "whatChanged": "A concrete design entered governance discussion with proposed bond, fee, penalty, capacity, queue, and delegated-role parameters.",
      "whatDidNotChange": "Within June it had not been approved, deployed, or activated; the exact module allocation and top-up seats were not final, and 0x01 operators had no direct migration path.",
      "confirmedFacts": [
        "The proposal calls for a new CSM v3 instance using 0x02 credentials.",
        "The proposed maximum validator balance is 2,048 ETH.",
        "Proposed bonds are 32 ETH and 30 ETH, with a 2% operator and 8% DAO split.",
        "The proposed combined 0x01/0x02 capacity ceiling is 20%.",
        "The CSM Committee would receive penalty, queue, bond-curve, and pause roles."
      ],
      "unresolved": [
        "Approval and deployment after June 30.",
        "Final capacity, queue seats, addresses, role holders, thresholds, audits, and activation conditions.",
        "Realized slashing, exit, liquidity, and concentration effects."
      ],
      "advisorDiligenceImplications": [
        "Monitor approval and deployment, then review concentration, slashing, queue, and delegated-control assumptions.",
        "Do not infer that the proposal is operative or safer than existing CSM."
      ],
      "followUpOn": "2026-07-20",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-e36227c0b90d311411525cc0",
      "stableKey": "optimism-bridge:citizens-house-pause-token-house-only-voting:2026-06-25",
      "version": 1,
      "eventDate": "2026-06-25",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Optimism proposes Token House-only voting during the Citizens' House pause",
      "category": "governance",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "optimism-bridge",
          "name": "Optimism canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Operating Manual Update Proposal",
          "authority": "Optimism Foundation",
          "url": "https://gov.optimism.io/t/operating-manual-update-proposal/10735",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-06-25"
        }
      ],
      "whatHappened": "The Optimism Foundation proposed updating the Operating Manual to remove references to the paused Citizens' House and Joint House voting, leaving the Token House as the voting body during the pause.",
      "whatChanged": "If approved, the documented governance process would consolidate voting in the token-weighted Token House while the Citizens' House remains paused. The proposal states that removals require Token House approval at a 51% threshold.",
      "whatDidNotChange": "The June 25 candidate did not establish approval or merger of the manual update. It did not change bridge contracts, Security Council permissions, upgrade keys, pause roles, or withdrawal mechanics.",
      "confirmedFacts": [
        "The Foundation had decided to pause Citizens' House operations.",
        "The proposed manual would remove references to the Citizens' House and Joint House voting.",
        "Only the Token House would vote while the Citizens' House is paused.",
        "The proposal states that removal of important manual provisions requires approval at a 51% threshold."
      ],
      "unresolved": [
        "The vote outcome and manual merge after the June event boundary.",
        "The duration and reactivation criteria for the Citizens' House pause.",
        "How the revised process changes stakeholder checks on canonical-bridge and shared protocol upgrades.",
        "Whether any separate charter, constitutional, Security Council, or on-chain authorization changes were required."
      ],
      "advisorDiligenceImplications": [
        "Review the Optimism bridge memo's governance and upgrade-authorization map if the manual change becomes effective.",
        "Distinguish Token House voting-process changes from on-chain Security Council, pause, and upgrade-key authority.",
        "Monitor whether reduced non-token stakeholder participation alters the diligence assessment for future bridge upgrades."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-5155d42f1193182414fb5406",
      "stableKey": "coinbase-bridge:base-mainnet-chain-stall:2026-06-25",
      "version": 1,
      "eventDate": "2026-06-25",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Base recovers from consecutive mainnet chain stalls",
      "category": "market_stress",
      "posture": "recovered",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "coinbase-bridge",
          "name": "Base canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Base Mainnet Chain Stall",
          "authority": "Base",
          "url": "https://status.base.org/incidents/5c4gm1wzbjs4",
          "documentType": "official_status_incident",
          "publishedOn": "2026-06-26"
        }
      ],
      "whatHappened": "Base mainnet block production stalled on June 25 after a consensus problem allowed a problematic block to interfere with subsequent block building. A similar chain halt recurred on June 26 before Base reported block production progressing and the incident resolved.",
      "whatChanged": "The incident established a realized chain-availability failure affecting deposits, withdrawals, block production, and client software. Node operators were required to restart affected nodes to resume syncing, and the halt recurred the following day.",
      "whatDidNotChange": "The status record did not report a canonical-bridge contract exploit, asset loss, or chain reorganization. It did not include the promised detailed postmortem or enough evidence to verify that the root cause could not recur.",
      "confirmedFacts": [
        "The June 25 disruption prevented new blocks after block 47,806,542.",
        "Base identified a consensus problem involving an invalid or problematic block.",
        "Sequencing resumed, but affected ecosystem nodes required restart and resynchronization.",
        "A similar chain halt occurred on June 26.",
        "The incident record lists deposits, withdrawals, block production, and client software as affected and reports final resolution on June 26."
      ],
      "unresolved": [
        "The complete technical root cause and the mechanism behind the next-day recurrence.",
        "The permanent remediation, deployment evidence, and testing showing the fault cannot recur.",
        "The duration and transaction-level impact of deposit and withdrawal unavailability.",
        "Whether any nodes, indexers, or bridge-dependent services remained impaired after the status page was resolved."
      ],
      "advisorDiligenceImplications": [
        "Review the Base canonical-bridge memo's chain-availability and withdrawal-access assumptions against two realized stalls.",
        "Record that deposits and withdrawals can become temporarily unavailable during Base sequencing failures even without a bridge-contract exploit.",
        "Obtain the promised postmortem and verify permanent remediation before treating recovery as evidence of reduced operational risk."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-51c94eac6e439bc2979d4cdc",
      "stableKey": "spark-liquidity-layer:avalanche-governance-bridge:timelock-guardian-approval-2026-06",
      "version": 1,
      "eventDate": "2026-06-25",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Spark approves Avalanche governance-bridge timelock and guardian",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "spark-liquidity-layer",
          "name": "Spark Liquidity Layer"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[Avalanche] Spark Liquidity Layer - Add Timelock and Guardian to Avalanche Governance Bridge",
          "authority": "Spark via Snapshot",
          "url": "https://snapshot.org/#/sparkfi.eth/proposal/0x5f3a7d62d6d26c06890dd0300071d0f22cd4fdd7115c0d9c94577b90f644089c",
          "documentType": "snapshot_governance_record",
          "publishedOn": "2026-06-22"
        }
      ],
      "whatHappened": "Spark governance approved adding a three-day timelock and a guardian multisig to the Avalanche governance bridge.",
      "whatChanged": "The approved design inserts a delay before governance actions become effective and gives a guardian multisig cancellation power during that delay.",
      "whatDidNotChange": "The guardian is not granted general administrative authority over the Avalanche deployment, and the proposal does not resolve Spark's other per-chain control or legal-entity disclosure gaps.",
      "confirmedFacts": [
        "The Snapshot vote closed on June 25 with all recorded voting power in favor.",
        "The proposal identifies roughly 17 million spUSDC liabilities on Avalanche.",
        "The planned guardian requires at least five signers and a quorum of half the signer set rounded up.",
        "The guardian's stated power is limited to cancelling pending actions during the timelock."
      ],
      "unresolved": [
        "The candidate does not establish contract deployment or activation of the timelock and guardian.",
        "The final signer set and whether the planned multisig address was retained remain unresolved."
      ],
      "advisorDiligenceImplications": [
        "Update the Spark Liquidity Layer control map if implementation is confirmed, recording both the three-day notice period and the cancellation controller.",
        "Do not treat this chain-specific mitigation as resolving undisclosed control structure across Spark's other deployments.",
        "Verify deployed contracts and role assignments before giving the proposal credit in any future reopen review."
      ],
      "followUpOn": "2026-08-26",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-5ac66f8c5bc8a88686ad2542",
      "stableKey": "lido-blockscape-ovh-validator-outage-2026-06-24",
      "version": 1,
      "eventDate": "2026-06-24",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Blockscape reports Lido validator outage and failed failover",
      "category": "security_incident",
      "posture": "postmortem",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[Post-Mortem] Blockscape - OVH Infrastructure Incident",
          "authority": "Blockscape via Lido Governance",
          "url": "https://research.lido.fi/t/post-mortem-blockscape-ovh-infrastructure-incident/11706",
          "documentType": "official_operator_postmortem",
          "publishedOn": "2026-06-29"
        }
      ],
      "whatHappened": "An OVH failure took Blockscape's Lido-2 cluster offline and simultaneously impaired components needed by its failover design.",
      "whatChanged": "Fresh Vouch and MikroTik instances restored the cluster, Blockscape compensated missed rewards, and the operator committed to test a cross-provider multi-instance Vouch design.",
      "whatDidNotChange": "The record does not establish a Lido-wide outage, slashing, key compromise, withdrawal impairment, or production deployment of the planned remediation.",
      "confirmedFacts": [
        "The incident occurred June 24, 2026 and affected Blockscape's Lido-2 cluster.",
        "The infrastructure failure made Vouch and MikroTik unavailable and prevented failover.",
        "Muted monitoring delayed normal detection.",
        "Fresh instances restored service.",
        "Blockscape says it compensated lost rewards."
      ],
      "unresolved": [
        "Exact duration, validator count, and missed-reward amount.",
        "Compensation transaction and final settlement evidence.",
        "Production timing for the cross-provider remediation."
      ],
      "advisorDiligenceImplications": [
        "Add the shared-infrastructure and alert-suppression failures to Lido node-operator diligence.",
        "Verify compensation and remediation; this operator event alone does not justify restricting Lido-wide exposure."
      ],
      "followUpOn": "2026-07-31",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-44bf81c6e7db4513bf99660b",
      "stableKey": "aave-v3:megaeth:stcusd-onboarding-arfc-approval-2026-06",
      "version": 1,
      "eventDate": "2026-06-23",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Aave advances stcUSD onboarding on MegaETH",
      "category": "economic_change",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Onboard stcUSD to Aave V3 MegaETH",
          "authority": "Aave DAO via Snapshot",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0x84ccc14e104b18a74ef47375ccd59f7f7aeeb61716dbb2c362ea7a538da3e08f",
          "documentType": "snapshot_governance_record",
          "publishedOn": "2026-06-19"
        }
      ],
      "whatHappened": "Aave DAO's Snapshot vote approved advancing stcUSD onboarding to the Aave v3 MegaETH market.",
      "whatChanged": "The approved ARFC specifies a 10 million supply cap and an isolated stablecoin E-Mode with 88% LTV, 90% liquidation threshold, and a 4% liquidation bonus.",
      "whatDidNotChange": "The ARFC did not itself list stcUSD on-chain; the base reserve configuration states collateral disabled, while collateral use is confined to the proposed E-Mode configuration.",
      "confirmedFacts": [
        "The vote closed on June 23 with overwhelming support.",
        "stcUSD is described as the staked, yield-bearing component of Cap Protocol's cUSD.",
        "The proposed reserve is not borrowable and has no borrow cap.",
        "The proposal states that a final AIP is required after ARFC approval."
      ],
      "unresolved": [
        "The record does not establish final AIP execution or that the reserve became live.",
        "The final deployed risk parameters and oracle configuration remain unconfirmed."
      ],
      "advisorDiligenceImplications": [
        "Monitor the final AIP because the proposed E-Mode introduces an 88% LTV for a yield-bearing stablecoin wrapper.",
        "Assess cUSD backing, stcUSD staking mechanics, oracle design, and wrap depth before recognizing the listing as acceptable collateral.",
        "Do not apply the proposed configuration to existing Aave markets before on-chain execution is verified."
      ],
      "followUpOn": "2026-08-26",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-c0ea242c4c3623209b3f33dc",
      "stableKey": "lido-labs-board-nemo-approval-2026-06-22",
      "version": 1,
      "eventDate": "2026-06-22",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Lido tokenholders approve the proposed Lido Labs board update",
      "category": "governance",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Lido Labs proposes Nemo as a new director",
          "authority": "Lido Labs via Lido Governance",
          "url": "https://research.lido.fi/t/lido-labs-proposes-nemo-as-a-new-director/11624",
          "documentType": "official_governance_record",
          "publishedOn": "2026-06-04"
        }
      ],
      "whatHappened": "Lido's Snapshot process approved appointing Nemo as a Lido Labs director while Konstantin transitions to an advisory role.",
      "whatChanged": "The community-approval step advanced a change in oversight of the foundation that develops and helps maintain Lido.",
      "whatDidNotChange": "The record does not establish the board resolution's completion or any transfer of on-chain roles, signers, emergency authority, upgrade rights, assets, or parameters.",
      "confirmedFacts": [
        "Lido Labs researches, develops, deploys, and helps maintain Lido on Ethereum.",
        "Its bylaws require board and community approval for director elections.",
        "The Snapshot ended June 22 with 55.1 million LDO for and 17 against.",
        "The proposed board is Sam Kozin, Jacobus Pietersen, and Nemo."
      ],
      "unresolved": [
        "Board resolution and effective appointment date.",
        "Any resulting committee, signer, or reporting-line changes.",
        "Practical effects on deployment, maintenance, or emergency operations."
      ],
      "advisorDiligenceImplications": [
        "Update Lido's governance map after the board resolution and appointment are verified.",
        "Do not describe on-chain control as changed without separate signer, role, or contract evidence."
      ],
      "followUpOn": "2026-07-15",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-9f040e9e527012035b09ebfa",
      "stableKey": "lido:lip-35:staking-router-v3-architecture-approval-2026-06",
      "version": 1,
      "eventDate": "2026-06-22",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Lido approves Staking Router v3 architecture",
      "category": "upgrade_migration",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "LIP-35: Staking Router v3 Architecture and Key Parameters",
          "authority": "Lido DAO via Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x8fdec5d2cb70f8a266c4f5a269051fcfa985fab0f66cbe747702719d7433f606",
          "documentType": "snapshot_governance_record",
          "publishedOn": "2026-06-15"
        }
      ],
      "whatHappened": "Lido DAO approved the architecture and key parameters for Staking Router v3.",
      "whatChanged": "The approved design replaces validator-count accounting with balance-based accounting, supports validators up to 2,048 ETH, adds governed consolidation-based module migration, updates exit oracles, and reserves configurable buffered ETH for consensus-layer deposits.",
      "whatDidNotChange": "Snapshot approval did not deploy SRv3, execute module migrations, or establish that stETH withdrawal mechanics changed on-chain.",
      "confirmedFacts": [
        "The vote closed on June 22 with overwhelming support.",
        "SRv3 is the foundation for the separately proposed CMv2 and CSMv3 modules.",
        "The design includes balance-aware deposits, top-ups, accounting, and exit-oracle behavior.",
        "The initial consolidation pipeline is scoped to migration from Curated Module v1 to v2."
      ],
      "unresolved": [
        "Deployment timing, final audited code, and actual migration execution are not established by this record.",
        "The final governance-configured buffered-ETH reservation and operational limits remain to be verified on-chain."
      ],
      "advisorDiligenceImplications": [
        "Reopen Lido architecture diligence before execution because accounting, exits, stake allocation, and module-migration controls all change.",
        "Verify that the withdrawal path and liquidity buffer behavior remain compatible with the memo's withdrawal-related kill criteria.",
        "Track audit completion, deployed bytecode, migration safeguards, and live parameter values."
      ],
      "followUpOn": "2026-08-26",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-6d9a1c4ed9fc9765dbdd25b2",
      "stableKey": "lido:lip-33:cmv2-csmv3-architecture-approval-2026-06",
      "version": 1,
      "eventDate": "2026-06-22",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Lido approves CMv2 and CSMv3 architecture and rollout plan",
      "category": "upgrade_migration",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "LIP-33: CMv2 and CSMv3 Architecture, Key Parameters, Rollout Plan",
          "authority": "Lido DAO via Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x7b07bc31f0b38b69a117473031bc126becc70b9fa37246b53d9fe5a841c814f5",
          "documentType": "snapshot_governance_record",
          "publishedOn": "2026-06-15"
        }
      ],
      "whatHappened": "Lido DAO approved LIP-33's architecture, parameters, governance model, and rollout plan for Curated Module v2 and Community Staking Module v3.",
      "whatChanged": "The approved design adds 0x02 withdrawal-credential support, large validators, new bonding and penalty mechanics, more granular roles, weighted Curated Module allocation, and a proposed 15% CSM stake-share upper bound.",
      "whatDidNotChange": "The vote did not deploy the modules, migrate validators, or prove that the audited production code and live parameters match the approved design.",
      "confirmedFacts": [
        "The vote closed on June 22 with all recorded voting power in favor.",
        "CMv2 and CSMv3 share substantial code and depend on Staking Router v3.",
        "CSMv3 introduces reward splitting, semi-automated penalties, and more granular operator-type roles.",
        "CMv2 introduces bonding, weighted stake allocation, a node-operator meta registry, and foundations for a validator marketplace."
      ],
      "unresolved": [
        "Security audits, final production code, deployment timing, and live Easy Track permissions remain unconfirmed.",
        "The realized effect on operator concentration and the combined CSM and Simple DVT share is unresolved until rollout."
      ],
      "advisorDiligenceImplications": [
        "Review module-level governance roles, bonding, penalty, and allocation controls before recognizing the upgrade as operative.",
        "Track whether the rollout improves or weakens operator diversity relative to Lido's memo criteria.",
        "Verify deployed parameters, especially the CSM stake-share limit and Easy Track permissions."
      ],
      "followUpOn": "2026-08-26",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-5ff05040fee0f6555c434388",
      "stableKey": "lido:simple-dvt:regular-cluster-winddown-approval-2026-06",
      "version": 1,
      "eventDate": "2026-06-22",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Lido approves early wind-down of Simple DVT regular clusters",
      "category": "closure_deprecation",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Wind Down Simple DVT Module Regular Clusters",
          "authority": "Lido DAO via Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x6ab9651fba999ba29ba780fe61d68cc23e7aeb83c841181c5c1933dec9197f37",
          "documentType": "snapshot_governance_record",
          "publishedOn": "2026-06-12"
        }
      ],
      "whatHappened": "Lido DAO approved an early wind-down plan for the 72 regular clusters in the Simple DVT Module.",
      "whatChanged": "The approved plan moves regular-cluster operators toward CSM continuation paths and authorizes a grant framework funded from an existing allocation.",
      "whatDidNotChange": "The vote does not prove that any cluster exited, that stake was migrated, or that the combined Community Staking and Simple DVT share changed for two consecutive quarters.",
      "confirmedFacts": [
        "The vote closed on June 22 with all recorded voting power in support.",
        "The wind-down occurs before the previously communicated maximum three-year module lifetime.",
        "Continuation paths include CSM and an Identified DVT Cluster operator type.",
        "No additional funding was requested beyond the existing grant allocation."
      ],
      "unresolved": [
        "The executed wind-down schedule, number of continuing operators, stake migration, and effect on validator diversity remain unresolved.",
        "The resulting Simple DVT and CSM stake shares require post-transition measurement."
      ],
      "advisorDiligenceImplications": [
        "Reassess Lido's operator-diversity evidence as clusters exit or move into CSM.",
        "Track quarterly Simple DVT and CSM stake shares against the memo's decentralization criterion.",
        "Verify that validator exits and migrations do not create withdrawal, slashing, or operational congestion."
      ],
      "followUpOn": "2026-08-26",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-715bac9aa2a75fcd10ad6967",
      "stableKey": "lido:wsteth-bridge-endpoints:canonical-status-revocation-approval-2026-06",
      "version": 1,
      "eventDate": "2026-06-22",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Lido approves bridge-endpoint de-recognition and future NEC revocations",
      "category": "closure_deprecation",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Revoke Canonical Status of (w)stETH Bridge Endpoints on Selected Chains and Authorize NEC for Revocations",
          "authority": "Lido DAO via Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x09880de4739dcef13c4aa5605f1dca23556fc7495d09ecc84561a10f26a59b5c",
          "documentType": "snapshot_governance_record",
          "publishedOn": "2026-06-12"
        }
      ],
      "whatHappened": "Lido DAO approved revoking canonical recognition for selected stETH and wstETH bridge endpoints and delegating future revocation decisions to the Network Expansion Committee.",
      "whatChanged": "The approved governance position narrows Lido's recognized multichain perimeter and expands the NEC's authority from endpoint recognition to future de-recognition.",
      "whatDidNotChange": "The proposal explicitly does not disable bridge infrastructure, force migration, impair existing token balances, or make a technical safety judgment about the affected bridges.",
      "confirmedFacts": [
        "The vote closed on June 22 with overwhelming approval.",
        "The listed networks are zkSync Era, Mode, Scroll, Mantle, Swell, Zircuit, Soneium, Polygon PoS, and Lisk.",
        "Future revocations are delegated to the NEC under the approved governance framework.",
        "The proposal states that holders do not need to take immediate action."
      ],
      "unresolved": [
        "The timing and publication of each recognition-status update remain to be verified.",
        "The precise disclosure and review process the NEC will use for future revocations remains unresolved."
      ],
      "advisorDiligenceImplications": [
        "Remove canonical-recognition assumptions for the listed endpoints from bridge diligence once the status update is confirmed.",
        "Do not equate loss of recognition with technical shutdown or immediate asset impairment.",
        "Add NEC revocation authority and its public-notice process to the Lido control map."
      ],
      "followUpOn": "2026-08-26",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-cc5eedc2474b352bb7f2baa4",
      "stableKey": "optimism-bridge-kona-fault-proof-soundness-fix-2026-06-19",
      "version": 1,
      "eventDate": "2026-06-19",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "OP Labs discloses and patches a kona fault-proof soundness bug",
      "category": "security_incident",
      "posture": "confirmed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "bridge",
          "id": "optimism-bridge",
          "name": "Optimism canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "kona-client v1.6.0",
          "authority": "OP Labs",
          "url": "https://github.com/ethereum-optimism/optimism/releases/tag/kona-client/v1.6.0",
          "documentType": "official_code_release",
          "publishedOn": "2026-06-19"
        }
      ],
      "whatHappened": "OP Labs published a required kona-client release disclosing a fault-proof soundness bug in post-Jovian BLOBBASEFEE handling.",
      "whatChanged": "A patched client became available and was designated as required for Upgrade 19, which is intended to promote kona-client to the primary fault-proof program.",
      "whatDidNotChange": "The release does not establish that affected code was active on OP Mainnet, that it was exploited, that an invalid withdrawal finalized, that funds were lost, or that Upgrade 19 deployed in June.",
      "confirmedFacts": [
        "The official release labels v1.6.0 a critical security fix and required update.",
        "The defect could make proof execution diverge from the canonical chain.",
        "The patch pins the post-Jovian blob-fee inputs to canonical-client values.",
        "The release states that v1.6.0 is required for Upgrade 19."
      ],
      "unresolved": [
        "Whether vulnerable code was active for OP Mainnet.",
        "Whether the defect was triggered or exploitable in a live dispute game.",
        "Upgrade 19 approval, deployment, activation, and patched-program adoption."
      ],
      "advisorDiligenceImplications": [
        "Review the bridge memo's fault-proof dependency before treating Upgrade 19 as operative.",
        "Verify deployed program versions and governance execution; the release alone does not establish client loss or justify a restriction."
      ],
      "followUpOn": "2026-07-08",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-2b6f6f3f65d50efd38e4f267",
      "stableKey": "rocket-pool:rpip-81:rpl-inflation-rebalance-approval-2026-06",
      "version": 1,
      "eventDate": "2026-06-19",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Rocket Pool approves RPIP-81 inflation and funding rebalance",
      "category": "economic_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "rocket-pool",
          "name": "Rocket Pool"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Rebalance RPL Inflation for Protocol Funding (RPIP-81)",
          "authority": "Rocket Pool DAO via Snapshot",
          "url": "https://snapshot.org/#/rocketpool-dao.eth/proposal/0x13c4cec1a2631fc08424945e859144ee717b27fa4afd1ddf030929d817aa3af9",
          "documentType": "snapshot_governance_record",
          "publishedOn": "2026-06-05"
        }
      ],
      "whatHappened": "Rocket Pool governance approved RPIP-81, which reallocates RPL inflation toward protocol funding before Saturn 2 and changes inflation and allocations after Saturn 2.",
      "whatChanged": "The approved policy reduces the pre-Saturn-2 node-operator allocation from 70% to 50%, raises pDAO's share to 47.5%, and calls for 2.5% annual inflation with 95% of rewards to pDAO after Saturn 2.",
      "whatDidNotChange": "The Snapshot vote did not itself execute the required on-chain pDAO parameter change or establish that Saturn 2 had launched.",
      "confirmedFacts": [
        "The vote closed on June 19 with the required outcome and approximately 11,734.6 RPL voting for versus 99.7 against.",
        "The pre-Saturn-2 target allocation is 50% node operators, 47.5% pDAO, and 2.5% oDAO.",
        "The post-Saturn-2 target removes node-operator RPL rewards and allocates 95% to pDAO and 5% to oDAO.",
        "The internal pDAO policy is set at 30% IMC, 40% GMC, and 30% reserve treasury."
      ],
      "unresolved": [
        "On-chain implementation timing and final Saturn 2 activation remain unresolved.",
        "The realized effect on node-operator participation and protocol decentralization is not yet established."
      ],
      "advisorDiligenceImplications": [
        "Review whether reduced node-operator incentives affect operator retention or decentralization evidence supporting rETH.",
        "Separate RPL tokenomics changes from rETH backing and redemption mechanics, which the proposal does not directly change.",
        "Verify on-chain implementation and monitor active operator count after the incentive transition."
      ],
      "followUpOn": "2026-08-26",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-9a37461213c06c35e9597bb1",
      "stableKey": "axelar:amplifier-multisig-provers:admin-rotation-proposal-481",
      "version": 1,
      "eventDate": "2026-06-17",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Axelar rotates administrators for nine MultisigProver contracts",
      "category": "control_change",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Rotate MultisigProver Admin for flow, sui, stellar, xrpl-evm, plume, hedera, berachain, hyperliquid, monad.",
          "authority": "Axelar on-chain governance",
          "url": "https://axelarscan.io/proposal/481",
          "documentType": "on_chain_governance_record",
          "publishedOn": "2026-06-17"
        }
      ],
      "whatHappened": "Axelar governance passed proposal 481 and updated the administrator on MultisigProver contracts for nine chain integrations.",
      "whatChanged": "The Flow, Sui, Stellar, XRPL-EVM, Plume, Hedera, Berachain, Hyperliquid, and Monad MultisigProver contracts were assigned administrator axelar1w2ey0ek9e8q2dfmeznz6ah49zdywpdme0z0kly.",
      "whatDidNotChange": "The proposal did not confirm new verifier sets, migrate contract code, or establish any service interruption.",
      "confirmedFacts": [
        "Proposal 481 passed on June 17.",
        "The payload contains nine update_admin contract calls.",
        "Every listed MultisigProver received the same new administrator address."
      ],
      "unresolved": [
        "The controller type, signer identities, threshold, and operating rules for axelar1w2ey0ek9e8q2dfmeznz6ah49zdywpdme0z0kly remain unresolved."
      ],
      "advisorDiligenceImplications": [
        "Update the controller map for all nine Amplifier integrations.",
        "Assess the aggregate blast radius created by one administrator controlling multiple MultisigProver contracts.",
        "Monitor subsequent verifier-set confirmations and migrations for use of the new authority."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-316e33e59c8236f6e6f640e5",
      "stableKey": "axelar:core-v1.4.7:upgrade-approval-proposal-480",
      "version": 1,
      "eventDate": "2026-06-16",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Axelar approves core v1.4.7 upgrade at height 30,135,800",
      "category": "upgrade_migration",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Axelar Core v1.4 Upgrade Proposal",
          "authority": "Axelar on-chain governance",
          "url": "https://axelarscan.io/proposal/480",
          "documentType": "on_chain_governance_record",
          "publishedOn": "2026-06-16"
        }
      ],
      "whatHappened": "Axelar governance passed proposal 480, scheduling axelar-core v1.4.7 at block height 30,135,800.",
      "whatChanged": "The network obtained an approved consensus-upgrade plan and reproducible binary references for Linux and macOS builds.",
      "whatDidNotChange": "The passage record does not establish that the target height was reached successfully, that validators upgraded, or that cross-chain service remained uninterrupted.",
      "confirmedFacts": [
        "Proposal 480 passed on June 16.",
        "The payload is a Cosmos MsgSoftwareUpgrade.",
        "The plan names v1.4 and specifies axelar-core v1.4.7 binaries at height 30,135,800."
      ],
      "unresolved": [
        "Upgrade execution, validator adoption, state-migration results, and service continuity are not established by this candidate.",
        "The candidate does not describe the functional changes included in v1.4.7."
      ],
      "advisorDiligenceImplications": [
        "Verify the upgrade-height block, resulting software version, and any incident or halt before closing monitoring.",
        "Review release notes and state migrations for effects on consensus, routing, gateway governance, or emergency controls.",
        "Do not infer improved safety from upgrade approval alone."
      ],
      "followUpOn": "2026-08-26",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-8f0e61fc4cba537da29623d1",
      "stableKey": "optimism-bridge:upgrade-19-karst-hardfork:2026-06-15",
      "version": 1,
      "eventDate": "2026-06-15",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Optimism proposes Upgrade 19 and the Karst hardfork",
      "category": "upgrade_migration",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "optimism-bridge",
          "name": "Optimism canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Upgrade 19b — Karst Hardfork",
          "authority": "OP Labs",
          "url": "https://gov.optimism.io/t/upgrade-19b-karst-hardfork/10713",
          "documentType": "official_protocol_upgrade_proposal",
          "publishedOn": "2026-06-15"
        }
      ],
      "whatHappened": "OP Labs submitted the off-cycle Upgrade 19 proposal, bundling the Karst execution-layer hardfork with new predeploy upgrade machinery, OP Contracts Manager v2, a new primary fault-proof implementation, and portal dispatch changes.",
      "whatChanged": "If approved and executed, permissionless fault-proof chains would change their respected game type from CANNON to CANNON_KONA for withdrawal proving; L2CM and OPCMv2 would change upgrade execution; the portal would dispatch claims by game type; seven Fusaka EIPs and a lower BN256 pairing-input limit would become active; and op-geth and op-program support would end.",
      "whatDidNotChange": "The proposal did not establish mainnet approval or activation during June. It stated that fee take, governor/servicer role separation, ossified gas limits, and direct fee-margin controls would not change, and it anticipated no downtime.",
      "confirmedFacts": [
        "CANNON_KONA was proposed as the respected game type for permissionless fault-proof chains.",
        "The proposal would make kona-client on Cannon the primary fault-proof program used for withdrawals.",
        "L2CM would add deterministic predeploy upgrades through ProxyAdmin.",
        "OPCMv2 would replace five manager functions with unified deploy and upgrade calls.",
        "The mainnet activation was scheduled for July 8, 2026, pending governance approval, outside the permitted event-date boundary."
      ],
      "unresolved": [
        "The governance outcome and mainnet execution after the June boundary.",
        "Final audit results, production contract addresses, upgrade transactions, and deployed component versions.",
        "Operator readiness for migration from op-geth and op-program to op-reth and kona-client.",
        "Whether the new fault-proof and portal-dispatch paths operated normally after activation."
      ],
      "advisorDiligenceImplications": [
        "Review the Optimism bridge memo's withdrawal-proof, respected-game-type, and upgrade-execution assumptions before recognizing Upgrade 19 as operative.",
        "Verify governance approval, deployed contracts, upgrade transactions, audits, prestates, and operator migration evidence on-chain.",
        "Do not infer that deterministic tooling or completed testing makes the bridge safer or approved."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-91c1cff429b66e7c1cb8f515",
      "stableKey": "axelar:secret-ibc-bridge:forged-deposit-drain:2026-06-10",
      "version": 1,
      "eventDate": "2026-06-10",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Axelar–Secret IBC route contained after unbacked-token drain",
      "category": "security_incident",
      "posture": "contained",
      "materiality": "material",
      "evidenceState": "mixed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Security Incident: Axelar<>Secret IBC Bridge Exploit (June 10, 2026)",
          "authority": "Secret Network",
          "url": "https://forum.scrt.network/t/security-incident-axelar-secret-ibc-bridge-exploit-june-10-2026/7995",
          "documentType": "official_incident_postmortem",
          "publishedOn": "2026-06-19"
        }
      ],
      "whatHappened": "An attacker exploited the Secret-side ICS-20 contract used by the Axelar–Secret route, minted unbacked saTokens, and redeemed them through the legitimate channel against real escrowed assets.",
      "whatChanged": "The affected saTokens became impaired or undercollateralized, and the Axelar Secret and Secret-SNIP connections were paused after discovery.",
      "whatDidNotChange": "The primary account says Axelar's core validator and threshold-signature protocol and other Axelar integrations were not affected; containment does not imply asset recovery.",
      "confirmedFacts": [
        "The exploit occurred on June 10, 2026 and involved the Secret-side contract at secret1yxjmepvyl2c25vnt53cr2dpn8amknwausxee83.",
        "The official account estimates approximately $4.67 million of unbacked tokens were minted and redeemed against genuine bridge reserves.",
        "Axelar–Secret bridging was disabled and the relevant connections were paused by June 19.",
        "Existing Axelar-bridged saTokens on Secret were identified as impaired or undercollateralized."
      ],
      "unresolved": [
        "Axelar and Secret accounts differ on responsibility for monitoring and recovery decisions; this draft does not resolve that dispute.",
        "The amount ultimately recoverable and the disposition of residual attacker-controlled funds remain unresolved."
      ],
      "advisorDiligenceImplications": [
        "Treat the Axelar–Secret route and its saTokens as unavailable pending verified recapitalization and restoration.",
        "Review every approved use of Axelar at the receiving-contract level; Axelar core approval does not validate a downstream integration's source authentication.",
        "Reopen the Axelar memo to record the integration-layer loss and containment without misclassifying it as a core Axelar consensus compromise."
      ],
      "followUpOn": "2026-08-26",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-0845a67386f42a9dc524e010",
      "stableKey": "axelar:evm-gateways:governance-transfer-approval-proposal-474",
      "version": 1,
      "eventDate": "2026-06-08",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Axelar approves governance-transfer calls for multi-chain Gateway contracts",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Interchain Governance Proposal",
          "authority": "Axelar on-chain governance",
          "url": "https://axelarscan.io/proposal/474",
          "documentType": "on_chain_governance_record",
          "publishedOn": "2026-06-08"
        }
      ],
      "whatHappened": "Axelar governance passed proposal 474 containing interchain calls to Gateway contracts across 17 EVM integrations.",
      "whatChanged": "The approved payloads encode transferGovernance(address) calls directing Gateway governance toward 0x7acbae6cba67d78aaf69e47000884ae00f9b2525.",
      "whatDidNotChange": "Passage on Axelar does not by itself prove each destination-chain call cleared its delay and executed successfully.",
      "confirmedFacts": [
        "Proposal 474 passed on June 8.",
        "The record includes calls for Celo, Ethereum, Avalanche, Polygon, Moonbeam, BNB Chain, Arbitrum, Kava, Filecoin, Optimism, Linea, Base, Mantle, Scroll, Immutable, Fraxtal, and Blast.",
        "The target contract addresses correspond to Axelar Gateway contracts, and the nested call selector is transferGovernance(address)."
      ],
      "unresolved": [
        "Execution status on each destination chain remains unresolved.",
        "The ownership, signer composition, threshold, and operating rules of the proposed new governance address remain unresolved."
      ],
      "advisorDiligenceImplications": [
        "Verify destination-chain execution and timelock completion separately for every relevant Gateway.",
        "Update the Axelar control map only for chains where the governance transfer is confirmed.",
        "Identify and assess the new governance controller before treating the transfer as an improvement."
      ],
      "followUpOn": "2026-08-26",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-4689e67ea087ab159e91a68a",
      "stableKey": "axelar:centrifuge-legacy-chain:route-deactivation-proposal-473",
      "version": 1,
      "eventDate": "2026-06-06",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Axelar deactivates routing for the legacy Centrifuge chain",
      "category": "closure_deprecation",
      "posture": "deprecated",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Deactivate legacy EVM chain centrifuge",
          "authority": "Axelar on-chain governance",
          "url": "https://axelarscan.io/proposal/473",
          "documentType": "on_chain_governance_record",
          "publishedOn": "2026-06-06"
        }
      ],
      "whatHappened": "Axelar governance passed proposal 473 and deactivated the legacy Centrifuge chain in the nexus module.",
      "whatChanged": "Axelar stopped routing transfers and messages to and from the deprecated legacy Centrifuge chain.",
      "whatDidNotChange": "The proposal did not deactivate other Axelar integrations or affect Centrifuge's newer Ethereum-native CFG token directly.",
      "confirmedFacts": [
        "Proposal 473 passed on June 6.",
        "The payload is an Axelar DeactivateChainRequest naming centrifuge.",
        "The stated migration window for the legacy canonical token had closed on November 30, 2025.",
        "The proposal states that the legacy chain remained block-producing but was no longer actively supported."
      ],
      "unresolved": [
        "Any residual user balances, unsupported messages, or applications still relying on the retired route are not identified by the record."
      ],
      "advisorDiligenceImplications": [
        "Remove the legacy Centrifuge route from any approved Axelar path inventory.",
        "Confirm that no client workflow or dependency still references the deprecated integration.",
        "Preserve the distinction between this route retirement and the status of Ethereum-native CFG."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-53012331af923cc221885a19",
      "stableKey": "lido:staking-router-v3:lip-35-proposal:2026-06-03",
      "version": 1,
      "eventDate": "2026-06-03",
      "publishedAt": "2026-08-22T14:06:02.331Z",
      "title": "Lido proposes Staking Router v3 accounting and deposit architecture",
      "category": "upgrade_migration",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Staking Router v3 — Design & Implementation Proposal (LIP-35)",
          "authority": "Lido",
          "url": "https://research.lido.fi/t/staking-router-v3-design-implementation-proposal-lip-35/11621",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-06-03"
        }
      ],
      "whatHappened": "Lido published LIP-35 for review, proposing Staking Router v3 as the foundational upgrade for supporting validators with effective balances up to 2,048 ETH.",
      "whatChanged": "If approved and executed, Lido would replace count-based consensus-layer accounting with balance-based accounting, add proof-gated validator top-ups, introduce a consolidation pipeline, reserve buffered ETH for consensus-layer deposits, and add bounded Easy Track control over module share limits.",
      "whatDidNotChange": "The June 3 record was a design and implementation proposal awaiting a vote. It did not establish a mainnet upgrade, final deployed addresses, completed audits, or an operative change to stETH accounting or withdrawals during the June event window.",
      "confirmedFacts": [
        "The proposal supports validators with effective balances between 32 and 2,048 ETH.",
        "The proposed accounting model tracks validator balances rather than multiplying validator counts by 32 ETH.",
        "A proposed TopUpGateway would require on-chain Merkle proofs of consensus-layer state.",
        "The proposed consolidation pipeline would support migration from Curated Module v1 to Curated Module v2.",
        "The proposal would protect part of buffered ETH for consensus-layer deposits and add a bounded Easy Track factory for module share limits."
      ],
      "unresolved": [
        "The proposal's vote and execution outcomes after the June event boundary.",
        "Final audits, deployed contract addresses, parameters, pausers, proof assumptions, and module-share bounds.",
        "How the deposit reserve would interact with withdrawal demand under stress.",
        "Whether implementation testing demonstrated correct totalPooledEther and reward accounting for large validators."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido memo's validator-accounting, withdrawal-liquidity, and module-allocation assumptions before treating Staking Router v3 as operative.",
        "Verify final contracts, audits, governance execution, reserve parameters, and proof-verification controls on-chain.",
        "Do not infer that the proposed architecture improves safety or that any Ketju approval changed."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-07527a97ce94009082f75471",
      "stableKey": "coinbase-bridge:withdrawal-delay-tee-proposal-halt:2026-05-29",
      "version": 1,
      "eventDate": "2026-05-31",
      "publishedAt": "2026-08-22T14:06:01.557Z",
      "title": "Base restores mainnet withdrawals after a TEE enclave issue halted proposals",
      "category": "market_stress",
      "posture": "recovered",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "coinbase-bridge",
          "name": "Base canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Base Mainnet Withdrawal Delay",
          "authority": "Base Status",
          "url": "https://status.base.org/incidents/lj9f7jhbb2ys",
          "documentType": "official_status_incident",
          "publishedOn": "2026-05-29"
        }
      ],
      "whatHappened": "Base reported that a TEE enclave issue halted proposals and delayed Base mainnet withdrawals beginning May 29. The first-party status record marked the incident resolved on May 31.",
      "whatChanged": "The canonical exit path experienced a temporary operational delay because state proposals needed for withdrawal progression stopped advancing.",
      "whatDidNotChange": "The notice reported no bridge-contract exploit, fund loss, change to the seven-day challenge period, change to upgrade authority, or permanent withdrawal-mechanism modification.",
      "confirmedFacts": [
        "Base identified the incident on May 29, 2026 at 15:55 UTC.",
        "Base attributed the withdrawal delay to a TEE enclave issue that halted proposals.",
        "The incident affected Base mainnet withdrawals.",
        "Base marked the incident resolved on May 31, 2026 at 03:38 UTC."
      ],
      "unresolved": [
        "The root cause of the TEE enclave failure and the exact remediation deployed.",
        "The number and value of withdrawals delayed and their maximum additional completion time.",
        "Whether alternative proposer or proof paths were available and tested during the incident.",
        "The recurrence risk and any subsequent changes to proposer failover or monitoring."
      ],
      "advisorDiligenceImplications": [
        "Add proposer and TEE-enclave availability to the Base bridge operational-dependency review.",
        "Review withdrawal monitoring and contingency procedures for a proposal halt lasting longer than one day.",
        "Because Base reported recovery, the historical incident does not by itself justify a current restriction, but it requires memo and operating-runbook review."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-c5357a07e231434087031b63",
      "stableKey": "axelar:voting-verifier-code64-ten-chain-migration:2026-05-22",
      "version": 1,
      "eventDate": "2026-05-22",
      "publishedAt": "2026-08-22T14:06:01.557Z",
      "title": "Axelar executes VotingVerifier migrations across ten Amplifier chains",
      "category": "upgrade_migration",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Migrate VotingVerifier to code id 64 on 10 chains",
          "authority": "Axelar on-chain governance",
          "url": "https://axelarscan.io/proposal/472",
          "documentType": "official_onchain_governance_record",
          "publishedOn": "2026-05-22"
        }
      ],
      "whatHappened": "Axelar governance passed and executed proposal 472, migrating ten VotingVerifier contracts to code ID 64 across Flow, Sui, Stellar, XRPL EVM, Plume, Hedera, Berachain, Hyperliquid, Monad, and Solana Amplifier integrations.",
      "whatChanged": "The VotingVerifier implementation governing verification for the ten named integrations moved to code ID 64, with chain-codec addresses supplied in each migration message.",
      "whatDidNotChange": "The record did not establish any change to Axelar's validator consensus quorum, gateway contracts, emergency committee, or integrations outside the ten named Amplifier chains.",
      "confirmedFacts": [
        "Proposal 472 reached passed status on May 22, 2026.",
        "The proposal contained ten MsgMigrateContract messages.",
        "Each migration targeted VotingVerifier code ID 64.",
        "The named integrations were Flow, Sui, Stellar, XRPL EVM, Plume, Hedera, Berachain, Hyperliquid, Monad, and Solana.",
        "Live contract information for sampled proposal targets reports code ID 64."
      ],
      "unresolved": [
        "The behavioral and security differences between the prior VotingVerifier implementation and code ID 64.",
        "The audit coverage and deployment testing for the new implementation and chain-codec dependencies.",
        "Whether all ten integrations processed messages normally after migration.",
        "Whether any Ketju position used one of the named Amplifier routes."
      ],
      "advisorDiligenceImplications": [
        "Review Axelar's integration-specific verification assumptions for any contemplated route among the ten migrated chains.",
        "Obtain the code diff, audit, and post-migration operating evidence before treating the upgrade as risk-reducing.",
        "No exploit or consensus-threshold change is established, so the event requires review rather than an automatic restriction."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-aa050ffdabb298e81c461164",
      "stableKey": "lombard-btc.b:ccip-exclusive-migration:2026-05-15",
      "version": 1,
      "eventDate": "2026-05-15",
      "publishedAt": "2026-08-22T14:06:01.557Z",
      "title": "Lombard commits BTC.b and LBTC to an exclusive Chainlink CCIP migration",
      "category": "upgrade_migration",
      "posture": "confirmed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "asset",
          "id": "lombard-btc.b",
          "name": "Lombard BTC.b"
        },
        {
          "type": "other",
          "id": "ccip",
          "name": "Chainlink CCIP"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Lombard Is Exclusively Migrating to Chainlink CCIP To Secure $1B+ in Bitcoin Assets",
          "authority": "Lombard Finance",
          "url": "https://www.lombard.finance/blog/lombard-is-exclusively-migrating-to-chainlink-ccip-to-secure-1-b-in-bitcoin-assets/",
          "documentType": "official_protocol_notice",
          "publishedOn": "2026-05-15"
        }
      ],
      "whatHappened": "Lombard announced that Chainlink CCIP would become the exclusive cross-chain infrastructure for LBTC and BTC.b, replacing LayerZero on Solana, Etherlink, Berachain, Corn, and TAC and deprecating LayerZero usage on Morph and Swell.",
      "whatChanged": "Lombard established a concrete migration perimeter and selected CCIP's Cross-Chain Token burn-and-mint model, rate limits, and optional Security Consortium attestation as its future cross-chain architecture.",
      "whatDidNotChange": "The notice did not establish that every lane had completed migration, identify all deployed token and lane addresses, or show any change to Bitcoin reserves, redemption terms, or asset backing on May 15.",
      "confirmedFacts": [
        "The official notice was published on May 15, 2026.",
        "Lombard said CCIP would replace LayerZero across Solana, Etherlink, Berachain, Corn, and TAC.",
        "Lombard said LayerZero usage on Morph and Swell would be deprecated.",
        "The announced design adopts CCIP's Cross-Chain Token standard and retains Lombard ownership of token contracts.",
        "Lombard said its Security Consortium could provide an additional transaction attestation layer."
      ],
      "unresolved": [
        "The chain-by-chain cutover dates and whether each announced migration completed successfully.",
        "The deployed token, pool, lane, rate-limit, and Security Consortium configuration for BTC.b on each supported chain.",
        "The user migration process for any legacy LayerZero representation and whether liquidity remained available throughout cutover.",
        "Whether any legacy LayerZero contracts or privileges remained active after migration."
      ],
      "advisorDiligenceImplications": [
        "Review the Lombard BTC.b memo's bridge, token-contract, rate-limit, and Security Consortium dependency map for the new CCIP architecture.",
        "Verify the live route and deployed addresses for each contemplated chain rather than treating the announcement as proof of completed migration.",
        "Review the CCIP memo for integration-specific configuration because protocol-level CCIP approval does not validate Lombard's individual lane setup."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-8ffa0fc005e3b24a6c7a7ee6",
      "stableKey": "axelar:interchain-token-service-code63-migration:2026-05-15",
      "version": 1,
      "eventDate": "2026-05-15",
      "publishedAt": "2026-08-22T14:06:01.557Z",
      "title": "Axelar executes an InterchainTokenService contract migration",
      "category": "upgrade_migration",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Migrate InterchainTokenService contract",
          "authority": "Axelar on-chain governance",
          "url": "https://axelarscan.io/proposal/470",
          "documentType": "official_onchain_governance_record",
          "publishedOn": "2026-05-15"
        }
      ],
      "whatHappened": "Axelar governance passed and executed proposal 470, migrating the identified InterchainTokenService contract to code ID 63.",
      "whatChanged": "The on-chain InterchainTokenService contract implementation changed to code ID 63 under the governance-administered migration path.",
      "whatDidNotChange": "The record did not establish a change to validator consensus, gateway thresholds, custody of existing tokens, or token-service economics, and it did not characterize the code-level behavior changed by code ID 63.",
      "confirmedFacts": [
        "Proposal 470 reached passed status on May 15, 2026.",
        "The proposal contained one MsgMigrateContract action.",
        "The target contract was migrated to code ID 63.",
        "Live contract information reports code ID 63 for the proposal's target."
      ],
      "unresolved": [
        "The complete code diff and security rationale for code ID 63.",
        "Audit coverage and pre-deployment testing for the new implementation.",
        "Whether supported token integrations required user or issuer action.",
        "Post-migration operating results and any incidents or compatibility problems."
      ],
      "advisorDiligenceImplications": [
        "Review Axelar's InterchainTokenService implementation and audit evidence before relying on an affected token route.",
        "Verify the deployed contract and integration-specific configuration for any contemplated exposure.",
        "The migration is operative but is not evidence that Axelar became safer or that any new route is approved."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-02ad76ce6de4c3268b53f630",
      "stableKey": "coinbase-bridge:missed-blocks-transaction-delays:2026-05-13",
      "version": 1,
      "eventDate": "2026-05-14",
      "publishedAt": "2026-08-22T14:06:01.557Z",
      "title": "Base recovers from mainnet transaction delays caused by missed blocks",
      "category": "market_stress",
      "posture": "recovered",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "coinbase-bridge",
          "name": "Base canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Delayed Transactions",
          "authority": "Base Status",
          "url": "https://status.base.org/incidents/0h468wjw300f",
          "documentType": "official_status_incident",
          "publishedOn": "2026-05-13"
        }
      ],
      "whatHappened": "Base experienced an elevated rate of missed mainnet blocks. Transactions submitted during missed blocks were delayed until a later successful block, and Base marked the incident resolved the following day.",
      "whatChanged": "Timely mainnet transaction inclusion was temporarily impaired, creating operational delay risk for bridge initiation, proof, and other Base transactions even though no bridge-specific transaction was identified.",
      "whatDidNotChange": "The notice did not report a complete chain halt, transaction reorganization, fund loss, canonical-bridge exploit, or change to withdrawal and upgrade controls.",
      "confirmedFacts": [
        "Base began investigating elevated missed blocks on May 13, 2026 at 16:44 UTC.",
        "Transactions submitted during missed blocks were delayed until the next successful block.",
        "The incident affected Base mainnet block production.",
        "Base marked the incident resolved on May 14, 2026 at 05:04 UTC."
      ],
      "unresolved": [
        "The cause of the elevated missed-block rate and remediation applied.",
        "The total number and maximum delay of affected transactions.",
        "Whether any deposit, withdrawal, proof, or finalization transactions experienced materially longer processing.",
        "The recurrence risk under comparable block-production conditions."
      ],
      "advisorDiligenceImplications": [
        "Review Base bridge assumptions for sequencer and block-production availability.",
        "Maintain transaction-status checks and resubmission procedures for bridge operations during elevated missed-block periods.",
        "The recovered event does not establish current unavailability but should remain in the Base operational incident record."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-8e66a5394d918b9ac2bc9ef9",
      "stableKey": "lido:cmv2-node-operator-type-framework:2026-05-11",
      "version": 1,
      "eventDate": "2026-05-11",
      "publishedAt": "2026-08-22T14:06:01.557Z",
      "title": "Lido proposes a delegated node-operator assessment framework for CMv2",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Adopt the Node Operator Type Assessment Framework for CMv2",
          "authority": "Lido Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x2b221847bae789551593115be9a364db4c9a478056d6394b1bef7728790258ee",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-05-11"
        }
      ],
      "whatHappened": "Lido opened a Snapshot proposal to approve six node-operator classifications for Curated Module v2 and delegate ongoing framework maintenance, assessment, and reassessment to the Curated Module Committee.",
      "whatChanged": "If adopted and later applied, the framework would formalize operator classifications and give the committee discretion to define round-specific scoring parameters and thresholds that influence subsequent operator treatment.",
      "whatDidNotChange": "The proposal did not itself set operator fees, incentive coefficients, onboarding results, validator allocations, or core-pool staking and withdrawal mechanics.",
      "confirmedFacts": [
        "The proposal defines Professional, Professional Trusted, Public Good, Extra Effort, Decentralization, and Intra-Operator DVT Cluster types.",
        "The Curated Module Committee would maintain and apply the framework.",
        "Scoring parameters and thresholds would be defined for each assessment round.",
        "Operator onboarding lists and economic parameters would require separate governance actions."
      ],
      "unresolved": [
        "The Snapshot result and whether the framework was formally adopted.",
        "The scoring parameters, thresholds, and reassessment cadence selected by the committee.",
        "The resulting operator classifications and effect on validator concentration, client diversity, and incentives.",
        "Whether any subsequent on-chain implementation altered operator allocation or fee settings."
      ],
      "advisorDiligenceImplications": [
        "Monitor adoption and the first completed CMv2 assessment round.",
        "Review whether delegated scoring discretion changes the Lido memo's operator-selection and concentration assumptions.",
        "Treat future operator incentives and allocations as separate events requiring their own primary evidence."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-16f2afd5d960112cbd69c364",
      "stableKey": "lido:nest-automated-buyback-lp-proposal:2026-05-11",
      "version": 1,
      "eventDate": "2026-05-11",
      "publishedAt": "2026-08-22T14:06:01.557Z",
      "title": "Lido proposes automated revenue-funded LDO buybacks and liquidity provision",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "NEST: Automated LDO Buyback and Liquidity Provisioning",
          "authority": "Lido Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x022e901a6368573d18b150eecda563dd2ee17ad2aa6a0ef9772151cc7ba55187",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-05-11"
        }
      ],
      "whatHappened": "Lido opened a Snapshot proposal for NEST, a permissionless system that would use bounded staking-revenue surplus to buy LDO through CoW Swap and pair it with wstETH as DAO-owned Curve liquidity.",
      "whatChanged": "If launched through a later on-chain vote and funded, NEST would add automated daily treasury execution, a $40 million annual revenue baseline, a daily order cap, component-level emergency pauses, and Treasury Management Committee funding and recovery powers.",
      "whatDidNotChange": "The proposal did not launch or fund NEST, alter stETH rebase accounting, change withdrawals, modify node-operator allocation, or establish that audits and the later on-chain launch vote had completed.",
      "confirmedFacts": [
        "The initial proposed mode would pair purchased LDO with wstETH in DAO-owned liquidity.",
        "The proposal specifies a $40 million annual revenue baseline and a daily order cap.",
        "Execution would be permissionless but dependent on funding and successful order settlement.",
        "Individual NEST components could be paused independently.",
        "Launching NEST would require a subsequent on-chain DAO vote."
      ],
      "unresolved": [
        "The Snapshot outcome and later on-chain launch vote.",
        "The final audited contracts, deployed addresses, parameters, and funding amount.",
        "The identities and authority boundaries of keepers, pausers, oracle components, and the Treasury Management Committee.",
        "The effect of automated operations on treasury risk and wstETH liquidity."
      ],
      "advisorDiligenceImplications": [
        "Monitor the final on-chain launch and deployed control configuration.",
        "Add NEST's trading, oracle, pause, funding, and asset-recovery roles to Lido governance diligence if executed.",
        "Do not infer any change to client stETH economics before the system is deployed and funded."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-52332d4ad09bfb88588fe7b4",
      "stableKey": "lido:circuitbreaker-gateseal-transition:2026-05-11",
      "version": 1,
      "eventDate": "2026-05-11",
      "publishedAt": "2026-08-22T14:06:01.557Z",
      "title": "Lido proposes replacing GateSeals with a permanent CircuitBreaker",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Transition from GateSeals to CircuitBreaker",
          "authority": "Lido Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x46d8df504c019be2be84a38c8705cd8bdbe4f5f4d2b141d4e8bd3e69af9ef5f3",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-05-11"
        }
      ],
      "whatHappened": "Lido opened a Snapshot proposal to replace temporary, expiring, single-use GateSeals with CircuitBreaker, a permanent contract assigning selective emergency pause authority to designated multisig committees.",
      "whatChanged": "If executed, pausers could maintain authority through periodic heartbeat transactions, pause assigned contracts independently, and retain authority over other assigned contracts after using one pause. The DAO would control pauser assignment and restoration.",
      "whatDidNotChange": "The Snapshot record did not establish deployment, audit completion, on-chain execution, pauser assignments, heartbeat parameters, or any active pause of staking or withdrawals.",
      "confirmedFacts": [
        "CircuitBreaker is proposed as a permanent emergency-pause contract.",
        "Each pausable contract would have one assigned pauser, while a committee could cover multiple contracts.",
        "A pause would revoke the committee's authority over the paused contract but not its other assignments.",
        "Expired heartbeat authorization could only be restored through DAO reassignment.",
        "The DAO could revoke CircuitBreaker permissions through on-chain governance."
      ],
      "unresolved": [
        "The Snapshot result and subsequent on-chain execution.",
        "Final audits, deployed address, heartbeat interval, pause duration, and covered-contract list.",
        "The committee identities, multisig thresholds, and operational procedures for each pauser.",
        "Whether the withdrawal queue or other client-critical contracts were assigned to CircuitBreaker and when GateSeals were retired."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido memo's emergency-pause control map before any CircuitBreaker execution.",
        "Verify final pausers, multisig thresholds, heartbeat settings, pause durations, and contract assignments on-chain.",
        "Treat the proposal as a material control redesign, not evidence that current GateSeal protections already changed."
      ],
      "followUpOn": null,
      "previousInterpretation": "The current Lido memo describes GateSeals as single-use, expiring emergency pause authorities, including for the withdrawal queue.",
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-7a5b8b88950efe987d9458fa",
      "stableKey": "lido:pier-two-mavan-operator-continuation:2026-05-11",
      "version": 1,
      "eventDate": "2026-05-11",
      "publishedAt": "2026-08-22T14:06:01.557Z",
      "title": "Lido votes on retaining Pier Two after its acquisition by Bitmine",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Should Pier Two continue in the Curated and SDVT sets following the acquisition by Bitmine Immersion Technologies?",
          "authority": "Lido Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x80959462b3026fc118ee9a3d7f46485b335677a2a5a739b3ede2656b7982f8e8",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-05-11"
        }
      ],
      "whatHappened": "Lido opened a Snapshot vote on allowing MAVAN, formerly Pier Two, to continue as a node operator in the Curated and Simple DVT modules following Pier Two's acquisition by Bitmine Immersion Technologies.",
      "whatChanged": "The acquisition introduced a new parent and control context for an existing node operator, while governance considered whether its participation should continue.",
      "whatDidNotChange": "The governance record relayed claims that the team, infrastructure, monitoring, key management, and operating procedures remained unchanged, but it did not independently verify those claims or establish the final vote result.",
      "confirmedFacts": [
        "Pier Two participated in Lido's Curated and Simple DVT modules.",
        "The governance record states that Bitmine acquired Pier Two and would operate it through MAVAN.",
        "The Curated Module Committee reported no identified concern requiring removal at that stage.",
        "A vote for the proposal would allow continued node operations."
      ],
      "unresolved": [
        "The final Snapshot result and any conditions attached to continued participation.",
        "Independent verification that validator infrastructure, key management, personnel, and operational procedures remained unchanged.",
        "MAVAN's resulting share of Lido validators and any parent-level concentration with other staking operations.",
        "Whether subsequent assessments changed the operator's module allocation or status."
      ],
      "advisorDiligenceImplications": [
        "Monitor the final vote and subsequent operator-allocation records.",
        "Review whether the ownership change alters Lido operator concentration, key-management, or correlated-operations assumptions.",
        "Do not treat committee comfort as independent verification of unchanged controls."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-786b08b4f81a6fb150802b8b",
      "stableKey": "lido:lol-easy-track-limit-increase:2026-05-11",
      "version": 1,
      "eventDate": "2026-05-11",
      "publishedAt": "2026-08-22T14:06:01.557Z",
      "title": "Lido proposes higher Easy Track transfer authority for its liquidity committee",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Increase Easy Track transfer limits for Liquidity Observation Lab to align with EGG",
          "authority": "Lido Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x863859d857c7429a0dcb85a4b324de803e2f66ddd8f50e4c2f04a31c35c6ae6f",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-05-11"
        }
      ],
      "whatHappened": "The Lido Ecosystem Foundation proposed increasing the Liquidity Observation Lab multisig's Easy Track stETH transfer limit and creating a dedicated stablecoin transfer factory.",
      "whatChanged": "If implemented through the stated later Aragon vote, the multisig's stETH transfer ceiling would rise from 6,000 to 8,000 stETH per six months and it would gain a stablecoin payment path capped at $8 million per six months.",
      "whatDidNotChange": "The proposal said it added no budget beyond previously approved funding, and it did not itself deploy the new factories, publish their addresses, execute an Aragon vote, or alter stETH holder balances and withdrawal mechanics.",
      "confirmedFacts": [
        "The existing stETH Easy Track factory limit was described as 6,000 stETH per six months.",
        "The proposed stETH limit is 8,000 stETH per six months.",
        "The proposed stablecoin payment-factory limit is $8 million per six months.",
        "The proposal identified the Liquidity Observation Lab multisig address.",
        "On-chain implementation was to follow through a later Aragon vote."
      ],
      "unresolved": [
        "The Snapshot result and later Aragon execution.",
        "The deployed addresses, allowed recipients, stablecoins, and administrative controls for the new factories.",
        "Actual transfers made under the expanded limits.",
        "Whether the change materially increased treasury counterparty or multisig concentration risk."
      ],
      "advisorDiligenceImplications": [
        "Monitor the final on-chain implementation and verify factory addresses and recipient controls.",
        "Update Lido treasury-control diligence if the higher limits become operative.",
        "Keep this treasury authority separate from client stETH custody and withdrawal mechanics."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-11064e17cd3c0a2568ffaf93",
      "stableKey": "lido:earneth:kelp-first-loss-exception:2026-04",
      "version": 1,
      "eventDate": "2026-04-30",
      "publishedAt": "2026-08-22T14:06:01.122Z",
      "title": "Lido proposes Kelp-specific EarnETH first-loss exception",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Authorize Lido EarnETH Loss Coverage Below 1% Threshold For The Kelp Incident",
          "authority": "Snapshot (Lido DAO space)",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x5629f9b201f32dbd5780f7e2e5601eed7504cdb7919b622a7ef039261d3c671a",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-04-30"
        }
      ],
      "whatHappened": "Lido Earn contributors proposed authorizing a one-off use of the existing first-loss mechanism for actual residual Kelp-related losses borne by EarnETH users, even when losses fall below the existing 1% threshold.",
      "whatChanged": "If approved, EarnETH could apply its first-loss backstop below the normally applicable threshold for this incident, but only after accounting for alternative coverage.",
      "whatDidNotChange": "The proposal does not alter the general threshold, add a treasury allocation, subsidize yield, replace foregone APY, or establish that any payment has occurred.",
      "confirmedFacts": [
        "The requested authorization is limited to residual Kelp-related losses borne by EarnETH users.",
        "The proposal describes the exception as one-off and leaves the general threshold unchanged.",
        "The backstop would apply only to the extent alternative loss coverage is insufficient.",
        "The proposal commits contributors to publishing a postmortem if approved."
      ],
      "unresolved": [
        "The Snapshot outcome and any additional implementation authorization.",
        "The actual residual loss after external recovery and curator coverage.",
        "The contributors' attributed estimate of approximately 400–600 ETH.",
        "The timing of normal operations and withdrawals for affected EarnETH users.",
        "Whether and how much of the first-loss backstop is ultimately used."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido memo's EarnETH loss-allocation and withdrawal assumptions before treating the proposed exception as effective coverage.",
        "Monitor the vote, final loss calculation, alternative coverage, postmortem, and any executed payment.",
        "Do not infer that the proposed backstop makes EarnETH or the underlying Kelp exposure safe or fully recovered."
      ],
      "followUpOn": "2026-05-07",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-8036b970fef33d2b4a8ed5db",
      "stableKey": "morpho-blue:steakhouse-svr-metaoracle-migration:2026-04-27",
      "version": 1,
      "eventDate": "2026-04-27",
      "publishedAt": "2026-08-22T14:06:01.122Z",
      "title": "Steakhouse announces SVR MetaOracle migration for Morpho markets",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "morpho-blue",
          "name": "Morpho Blue"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Improving Oracles on Eligible Markets",
          "authority": "Steakhouse Financial on Morpho Governance Forum",
          "url": "https://forum.morpho.org/t/improving-oracles-on-eligible-markets/2250",
          "documentType": "official_curator_control_notice",
          "publishedOn": "2026-04-27"
        }
      ],
      "whatHappened": "Steakhouse announced a planned oracle migration for its Prime BTC- and ETH-related Morpho markets on Ethereum, replacing hardcoded collateral pricing in eligible markets with SVR-based MetaOracle designs and explicit backup feeds.",
      "whatChanged": "The announced target design adds private-auction SVR delivery, standard Chainlink fallback paths, exact-collateral backup pricing where applicable, a 2% deviation trigger, a two-hour challenge timelock, and an eight-hour healing timelock.",
      "whatDidNotChange": "The forum record does not prove that each listed Morpho market had switched to the new oracle on April 27. It does not announce changed LLTVs, collateral assets, or completed adoption on Arbitrum or Base.",
      "confirmedFacts": [
        "Steakhouse published the notice on April 27, 2026.",
        "The notice identifies Ethereum-mainnet Morpho markets involving cbBTC, WBTC, LBTC, WETH, wstETH, and weETH.",
        "For eligible wrapped-Bitcoin markets, the proposed MetaOracle compares an SVR BTC/USD primary path with an exact-collateral Chainlink backup.",
        "The specified MetaOracle parameters are a 2% deviation threshold, a two-hour challenge timelock, and an eight-hour healing timelock.",
        "The notice provides exact Ethereum oracle addresses for the listed market groups and says Arbitrum and Base adoption would follow progressively."
      ],
      "unresolved": [
        "The record does not identify the execution transaction or effective switch date for each market.",
        "The exact client-held or approved vault allocations touching each listed market were not established by this candidate.",
        "The configured SVR auction delay and observed behavior during feed divergence or private-route failure remain unverified.",
        "Adoption on Arbitrum and Base was prospective rather than operative in this event record."
      ],
      "advisorDiligenceImplications": [
        "Review the Morpho Blue memo's oracle and liquidation assumptions for any approved Steakhouse vault allocating to the listed markets.",
        "Reconcile each held vault's market allocations and live oracle address before treating the announced fallback design as operative.",
        "Do not infer that additional fallback layers remove Chainlink, curator, liquidation-auction, or collateral-depeg risk."
      ],
      "followUpOn": "2026-05-04",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-3acca96976fb5ee299747ab5",
      "stableKey": "aave-v3:rseth-kelp-bridge-incident:2026-04-18",
      "version": 1,
      "eventDate": "2026-04-18",
      "publishedAt": "2026-08-22T14:06:01.122Z",
      "title": "Kelp rsETH bridge exploit triggers Aave V3 reserve freezes",
      "category": "security_incident",
      "posture": "confirmed",
      "materiality": "critical",
      "evidenceState": "mixed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Pause AAVE Buybacks",
          "authority": "Snapshot (Aave DAO space)",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0x10a2af0110b1ad6f4afd7a3a052b2a119d102cc22949e80e9bbd5132587107c8",
          "documentType": "official_governance_proposal_and_incident_response_record",
          "publishedOn": "2026-04-27"
        }
      ],
      "whatHappened": "Aave's official governance record states that an exploit affecting Kelp's LayerZero rsETH bridge route introduced unbacked rsETH into Aave V3 markets across multiple chains.",
      "whatChanged": "The Aave Protocol Guardian and Risk Steward froze rsETH and wrsETH reserves and adjusted WETH interest rates across affected deployments. AAVE buybacks stopped on April 19 to preserve balance-sheet flexibility while losses and recovery remained unresolved.",
      "whatDidNotChange": "The record does not establish final loss allocation, recovered backing, realized bad debt, or complete resumption of affected reserves. The buyback ARFC does not itself resolve the incident.",
      "confirmedFacts": [
        "The official record dates the underlying bridge incident to April 18, 2026.",
        "Aave's Guardian and Risk Steward executed freezes on rsETH and wrsETH reserves across affected deployments.",
        "WETH reserve interest rates were adjusted as part of the defensive response.",
        "No AAVE buyback transactions were executed after April 19 according to the proposal.",
        "The proposal says potential loss allocation, recovery, and DAO-level responses remained unsettled."
      ],
      "unresolved": [
        "The amount of unbacked rsETH that entered each Aave deployment.",
        "The affected chains, reserve-level exposure, and client exposure requiring reconciliation.",
        "Whether bad debt materialized and how any loss was allocated.",
        "The extent and timing of rsETH backing recovery.",
        "When reserve freezes and defensive interest-rate settings were lifted.",
        "Whether the proposed buyback policy was approved or later superseded."
      ],
      "advisorDiligenceImplications": [
        "Immediately reconcile approved or client-held Aave positions against rsETH, wrsETH, and affected WETH markets.",
        "Review the Aave memo's collateral, freeze, bad-debt, and emergency-control analysis using chain-specific executed state.",
        "Do not generalize the reserve-specific incident to every Aave V3 market, but do not treat affected reserves as available until recovery and configuration are verified."
      ],
      "followUpOn": "2026-04-29",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-2e6bb763cfdd21fed574044e",
      "stableKey": "optimism-bridge:op-challenger-security-release:v1.9.1:2026-04-15",
      "version": 1,
      "eventDate": "2026-04-15",
      "publishedAt": "2026-08-22T14:06:01.122Z",
      "title": "Optimism publishes required op-challenger security release v1.9.1",
      "category": "upgrade_migration",
      "posture": "confirmed",
      "materiality": "material",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "optimism-bridge",
          "name": "Optimism canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "op-challenger v1.9.1",
          "authority": "OP Labs",
          "url": "https://github.com/ethereum-optimism/optimism/releases/tag/op-challenger/v1.9.1",
          "documentType": "official_github_security_release",
          "publishedOn": "2026-04-15"
        }
      ],
      "whatHappened": "OP Labs published op-challenger v1.9.1 with security and reliability fixes for chains using permissionless fault proofs and designated it a required upgrade for all users.",
      "whatChanged": "A fixed official challenger version became available for a direct dependency of the fault-proof process that secures challenged withdrawals.",
      "whatDidNotChange": "The release does not establish an exploit, fund loss, invalid withdrawal, bridge-contract upgrade, or adoption by every live challenger operator.",
      "confirmedFacts": [
        "op-challenger v1.9.1 was released on April 15, 2026.",
        "The official release calls the update required for all users.",
        "The release fixes routing that could send large non-Keccak preimages to an incompatible Keccak-only on-chain path.",
        "The release also introduces strict uint64 configuration parsing and fixes a shutdown race that could make the challenger hang."
      ],
      "unresolved": [
        "The candidate does not establish when OP Mainnet challenger operators adopted v1.9.1.",
        "It is not established whether any live dispute encountered the affected preimage-routing path before upgrade.",
        "The record does not identify an exploit, failed challenge, or affected withdrawal."
      ],
      "advisorDiligenceImplications": [
        "Review the Optimism canonical-bridge memo's dependence on permissionless challenger availability and software-version monitoring.",
        "Verify that relevant operators and service providers tracked the required release; publication alone does not prove adoption.",
        "Continue normal exposure treatment unless separate primary evidence establishes an impaired challenge or withdrawal path."
      ],
      "followUpOn": "2026-04-22",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-e767328c1bba4777ee64f1f7",
      "stableKey": "morpho-blue:steakhouse-v2-direct-market-adapter-migration:2026-04-15",
      "version": 1,
      "eventDate": "2026-04-15",
      "publishedAt": "2026-08-22T14:06:01.122Z",
      "title": "Steakhouse plans direct-market migration for Morpho Vault V2 allocations",
      "category": "upgrade_migration",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "morpho-blue",
          "name": "Morpho Blue"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Steakhouse Vault V2 simplification",
          "authority": "Steakhouse Financial on Morpho Governance Forum",
          "url": "https://forum.morpho.org/t/steakhouse-vault-v2-simplification/2235",
          "documentType": "official_curator_migration_notice",
          "publishedOn": "2026-04-15"
        }
      ],
      "whatHappened": "Steakhouse announced that its Morpho Vault V2 products would progressively stop allocating through intermediate Morpho Vault V1 vaults and instead allocate directly through the Markets V1 Adapter.",
      "whatChanged": "The planned migration removes a nested vault layer from the allocation path and requires numerous curator operations across Steakhouse V2 vaults.",
      "whatDidNotChange": "Steakhouse stated that the underlying market exposures would not change and that users of the V1 vaults themselves would not be affected. The notice does not prove completion for any specific vault.",
      "confirmedFacts": [
        "Steakhouse published the migration notice on April 15, 2026.",
        "Most affected V2 vaults were then allocating to a V1 vault that in turn allocated to Morpho Blue markets.",
        "The announced target was direct allocation from V2 vaults to the Markets V1 Adapter.",
        "Steakhouse characterized the change as operational and structural and said underlying market exposures would remain unchanged.",
        "Implementation was planned progressively over the following weeks."
      ],
      "unresolved": [
        "The exact vault addresses, migration transactions, and completion dates are not supplied in the candidate.",
        "It is not established which client-held or approved Steakhouse vaults were affected.",
        "Post-migration withdrawal queues, adapter permissions, cap settings, and allocation state require address-level reconciliation."
      ],
      "advisorDiligenceImplications": [
        "Monitor approved Steakhouse vault addresses for migration completion and reconcile their contract versions and allocation paths.",
        "Update operational diligence if a held vault removes the V1-vault intermediary; do not infer that simplification reduces underlying market or curator risk.",
        "Verify that approved-market restrictions, caps, withdrawal behavior, and monitoring coverage remain intact after migration."
      ],
      "followUpOn": "2026-05-15",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-9ee6061c3d4ec201d14287b5",
      "stableKey": "lombard-btc.b:bitcoin-smart-accounts-architecture:2026-04-15",
      "version": 1,
      "eventDate": "2026-04-15",
      "publishedAt": "2026-08-22T14:06:01.122Z",
      "title": "Lombard details Bitcoin Smart Account controls for BTC.b",
      "category": "control_change",
      "posture": "confirmed",
      "materiality": "material",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "asset",
          "id": "lombard-btc.b",
          "name": "Lombard BTC.b"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Bitcoin Smart Accounts: architecture, explained",
          "authority": "Lombard Finance",
          "url": "https://www.lombard.finance/blog/bitcoin-smart-accounts-architecture-explained/",
          "documentType": "official_technical_architecture_notice",
          "publishedOn": "2026-04-15"
        }
      ],
      "whatHappened": "Lombard published a technical architecture guide describing how Bitcoin Smart Accounts retain BTC under depositor control while issuing BTC.b on Ethereum for use as on-chain collateral.",
      "whatChanged": "The primary diligence record now identifies the pre-signed Bitcoin spending paths, Ethereum Smart Account Registry, Token Operator, TEE-based Arbitration Oracles, unilateral exit route, and liquidation-driven reserve rebalancing used by this BTC.b issuance model.",
      "whatDidNotChange": "The guide does not establish that every BTC.b unit uses this architecture, provide all deployed contract addresses or named independent Arbitration Oracle operators, prove public availability, or demonstrate safety under stress.",
      "confirmedFacts": [
        "The architecture pre-signs the allowed PSBT spending paths before BTC is deposited and uses Taproot addresses to constrain future states.",
        "A unilateral path from the vault to an unbond timelock address is designed to permit exit if the Token Operator is unavailable.",
        "Lombard states that a Smart Account Registry deployed on Ethereum records BSA instances, deposited UTXOs, pre-signed PSBTs, and position state.",
        "The Token Operator mints BTC.b on Ethereum after a Bitcoin deposit is finalized.",
        "Arbitration Oracles monitor Bitcoin and Ethereum, run in AWS Nitro Enclaves, and use AWS KMS policy restrictions for signing keys.",
        "The described liquidation process moves one or more vault UTXOs to Lombard reserves after a liquidator acquires and exits BTC.b collateral."
      ],
      "unresolved": [
        "The exact registry and related contract addresses, production code hashes, attestation policy, and independent Arbitration Oracle set were not supplied in the cached article.",
        "It remains unclear which existing BTC.b supply uses Bitcoin Smart Accounts versus Lombard's other custody and issuance routes and how fungibility and reserve reporting distinguish them.",
        "Public eligibility, legal title, custodian terms, fees, dispute-operation history, and observed unilateral-exit timing remain unverified.",
        "No stress evidence establishes the behavior of partial liquidations, Token Operator outages, Arbitration Oracle outages, or conflicting Bitcoin and Ethereum state."
      ],
      "advisorDiligenceImplications": [
        "Review the Lombard BTC.b memo so its custody, control, redemption, reserve, and liquidation analysis distinguishes the Bitcoin Smart Account issuance route from other BTC.b routes.",
        "Require deployed-address, attestation, operator, reserve-accounting, legal-title, and exit evidence before treating Smart Account-issued BTC.b as equivalent to previously reviewed BTC.b.",
        "Do not infer that a 1-of-k arbitration claim, TEE isolation, or pre-signed spending paths eliminate hardware, cloud, Token Operator, oracle-availability, liquidation, or implementation risk."
      ],
      "followUpOn": "2026-04-30",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-19833c8a919f0adece496eec",
      "stableKey": "aave-v3:sonic:ussd-onboarding-temp-check:2026-04",
      "version": 1,
      "eventDate": "2026-04-13",
      "publishedAt": "2026-08-22T14:06:01.122Z",
      "title": "Aave considers onboarding USSD to its Sonic market",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        },
        {
          "type": "asset",
          "id": "wisdomtree",
          "name": "WisdomTree digital funds"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[TEMP CHECK] Onboard USSD to Aave V3 Sonic Instance",
          "authority": "Snapshot (Aave DAO space)",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0x98d5e8024e327a7b72608f1cdeecd318bd2f94c3e863ebe44e498059bcec5aa7",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-04-13"
        }
      ],
      "whatHappened": "An Aave DAO temperature check proposed onboarding USSD as a supply and borrowing reserve on the Aave V3 Sonic instance.",
      "whatChanged": "If governance advances and executes the proposal, Aave Sonic would gain a new stablecoin exposure whose stated reserve and redemption stack includes cross-chain minting, third-party custodians, and tokenized Treasury products including WTGXX.",
      "whatDidNotChange": "No ARFC, AIP, execution, reserve activation, risk parameters, caps, collateral settings, or independently verified reserve state is established by this temperature check.",
      "confirmedFacts": [
        "The proposal identifies USSD's Sonic token address.",
        "The proposal describes USSD as redeemable through CCTP-supported chains and interoperable through LayerZero.",
        "WTGXX is among the tokenized Treasury instruments the proposal says can support USSD.",
        "Risk parameters were deferred to later service-provider review.",
        "The stated process requires further ARFC and AIP stages before enforcement."
      ],
      "unresolved": [
        "The temperature-check vote outcome.",
        "Independent verification of USSD reserves, custodians, redemption rights, and legal structure.",
        "Whether WTGXX or another reserve asset would actually back circulating USSD used on Aave.",
        "Final oracle design, caps, collateral status, liquidation parameters, and bridge assumptions.",
        "Any ARFC, AIP, deployment address, and executed reserve state."
      ],
      "advisorDiligenceImplications": [
        "Monitor the governance sequence without treating USSD as an approved or live Aave reserve.",
        "If the proposal advances, review USSD's reserve attestations, redemption waterfall, bridge dependencies, oracle design, and WTGXX linkage before changing the Aave or WisdomTree memos."
      ],
      "followUpOn": "2026-04-20",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-91fde763a72ab26f6f58cc3c",
      "stableKey": "lido:curated-modules:cmc-governance-proposal:2026-04",
      "version": 1,
      "eventDate": "2026-04-06",
      "publishedAt": "2026-08-22T14:06:01.122Z",
      "title": "Lido proposes Curated Module Committee with delegated operating authority",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "From LNOSG to CMC: Evolving Curated Staking Modules Governance",
          "authority": "Snapshot (Lido DAO space)",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x1c929502f12c61a510c71965d7a7f82dcc76b5d812e2f52796f6bacd6f66e32b",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-04-06"
        }
      ],
      "whatHappened": "Lido proposed creating a Curated Module Committee to replace LNOSG and manage routine operations across CMv1, CMv2, and the Simple DVT Module.",
      "whatChanged": "If approved and implemented, a dedicated 5-of-9 multisig committee would receive bounded on-chain permissions for penalties, parameter updates, registry management, and operator administration.",
      "whatDidNotChange": "No committee deployment or permission grant is confirmed. The proposal says high-impact decisions such as node-operator onboarding would remain subject to DAO Snapshot votes, with routine actions subject to Easy Track objections.",
      "confirmedFacts": [
        "The proposed committee has nine named members and a 5-of-9 signing quorum.",
        "The proposal would deprecate LNOSG and transfer its responsibilities to the new committee.",
        "The proposed scope covers CMv1, CMv2, and SDVTM operations.",
        "High-impact node-operator onboarding would remain subject to DAO voting under the proposed model."
      ],
      "unresolved": [
        "The Snapshot outcome and any on-chain execution.",
        "The final multisig address, signer set, permissions, and permission ceilings.",
        "The exact boundary between routine committee actions and high-impact DAO decisions.",
        "The final CMv2 deployment and transition schedule.",
        "Whether emergency, revocation, and monitoring procedures are adequate after delegation."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido memo's node-operator and staking-module control map before the committee becomes operative.",
        "Verify the final multisig, permissions, veto path, reporting duties, and transition from LNOSG after execution."
      ],
      "followUpOn": "2026-04-13",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-0a71163446838cd1eff71b59",
      "stableKey": "lido:dvt-apm-incentives:routing-proposal:2026-04",
      "version": 1,
      "eventDate": "2026-04-06",
      "publishedAt": "2026-08-22T14:06:01.122Z",
      "title": "Lido proposes rerouting DVT and APM incentive flows",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Redirect DVT & APM Incentives to Current Meta Treasury and LoL",
          "authority": "Snapshot (Lido DAO space)",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x60cfe3531cd13ab84f5f6aaef7bcaab1747cbea4544dc7d18daaf642e36c9d39",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-04-06"
        }
      ],
      "whatHappened": "Lido proposed redirecting post-node-operator DVT incentives from the Decentralized Validator Vault to the Lido Earn Current Meta Treasury and routing APM incentives to the Liquidity Observation Lab multisig.",
      "whatChanged": "If implemented, the destination and delegated management of these incentive flows would shift to the Lido Earn treasury and Growth Committee-linked liquidity structure.",
      "whatDidNotChange": "No vote outcome, transfer, or executed routing change is confirmed. The proposal does not state that core stETH staking rewards, withdrawals, or validator principal would change.",
      "confirmedFacts": [
        "The identified Lido Earn treasury multisig is 0xcCf2daba8Bb04a232a2fDA0D01010D4EF6C69B85.",
        "The proposed DVT routing concerns the post-node-operator share of Obol and SSV incentives.",
        "The proposed APM routing would make incentives available to the Growth Committee for liquidity-focused strategies.",
        "The proposal describes Lido Earn as absorbing the Decentralized Validator Vault's former coordination role."
      ],
      "unresolved": [
        "The governance result and any executed transfers or routing configuration.",
        "The final accounting treatment for current Decentralized Validator Vault participants.",
        "The Growth Committee's deployment constraints and reporting requirements.",
        "The effect on realized rewards, liquidity support, and Lido Earn risk concentration."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido memo's incentive-flow, multisig, and Lido Earn dependency map if the proposal is approved.",
        "Verify executed destinations, committee mandates, accounting, and user disclosures before treating the new reward flow as operative."
      ],
      "followUpOn": "2026-04-13",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-66d01fa74dca3f6ff6f27aa9",
      "stableKey": "lido:csm:idvtc-operator-type-proposal:2026-04",
      "version": 1,
      "eventDate": "2026-04-06",
      "publishedAt": "2026-08-22T14:06:01.122Z",
      "title": "Lido proposes Identified DVT Cluster operator class for CSM",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Introduce an Identified DVT Cluster type in the Community Staking Module",
          "authority": "Snapshot (Lido DAO space)",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x1d416954538fb9b82aae05daca1be29f7b20d5f9fac61bd2eb9da1f5901a3867",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-04-06"
        }
      ],
      "whatHappened": "Lido proposed adding an Identified DVT Cluster operator type to the Community Staking Module for four-person clusters of verified independent community stakers.",
      "whatChanged": "If implemented with CSM v3, qualifying clusters would receive distinct bond, reward, priority-queue, strike, monitoring, and committee-administered onboarding treatment.",
      "whatDidNotChange": "The operator class is not live, CSM v3 deployment is not confirmed, and current CSM operator parameters remain unchanged by the proposal alone.",
      "confirmedFacts": [
        "Each proposed cluster must contain four eligible Identified Community Stakers.",
        "The proposed bond is 1.5 ETH for the first key and 0.5 ETH for each subsequent key.",
        "The proposed node-operator reward is 3.5% for the first 64 keys and 2% thereafter.",
        "The proposal permits up to 40 lifetime priority-queue keys per cluster.",
        "Clusters would be added to the relevant gate through committee-initiated Easy Track motions."
      ],
      "unresolved": [
        "The Snapshot result and final CSM v3 implementation.",
        "Final deployed contracts, gate permissions, and parameter values.",
        "The approved DVT configurations and monitoring requirements.",
        "How identity, independence, downgrade, slashing, and dispute controls perform in operation.",
        "Whether the expected Q3 2026 launch schedule is met."
      ],
      "advisorDiligenceImplications": [
        "Review Lido's CSM operator, bond, slashing, and delegated-gate controls before the new class becomes operative.",
        "Verify the final deployed parameters and committee permissions rather than relying on proposal values."
      ],
      "followUpOn": "2026-04-13",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-ad7f1af464ab72f328631858",
      "stableKey": "lido:dao-ops-multisigs:policy-3-proposal:2026-04",
      "version": 1,
      "eventDate": "2026-04-06",
      "publishedAt": "2026-08-22T14:06:01.122Z",
      "title": "Lido proposes DAO Ops Multisigs Policy 3.0",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Lido DAO Ops Multisigs Policy 3.0",
          "authority": "Snapshot (Lido DAO space)",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0xde04e720b6c44e6d5a356021e464dc4d4b3036c6602c6088806f1f898cb7a56b",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-04-06"
        }
      ],
      "whatHappened": "Lido proposed replacing DAO Ops Multisigs Policy 2.0 with Policy 3.0 and aligning related Lido Foundation bylaws with the new framework.",
      "whatChanged": "If approved, signer rotations would no longer have to preserve a simple majority of original signers, static signers would lose protected status, and the existing seven-day rotation objection period would be removed.",
      "whatDidNotChange": "The proposal does not itself rotate a signer, change a particular Safe threshold, or expand a specific multisig's transaction authority. The DAO would retain the ability to object through Snapshot voting.",
      "confirmedFacts": [
        "The proposal would replace Policy 2.0.",
        "The original-signer-majority requirement would be deprecated.",
        "The static-signer rule would be deprecated.",
        "The seven-day objection period for member rotation would be removed.",
        "Related Foundation bylaws would require at least three multisig members."
      ],
      "unresolved": [
        "The Snapshot outcome and effective policy text.",
        "Which existing multisigs and bylaws are ultimately updated.",
        "The final rotation, disclosure, emergency, and objection procedures.",
        "Whether removal of the safeguards materially increases signer-capture or rapid-rotation risk.",
        "Any subsequent signer rotations performed under Policy 3.0."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido memo's multisig rotation and delegated-control assumptions before Policy 3.0 is treated as operative.",
        "Inventory affected Safes and verify thresholds, owners, rotation procedures, disclosure exceptions, and DAO revocation paths after implementation."
      ],
      "followUpOn": "2026-04-13",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-fa59e28be2db98e8dc22a691",
      "stableKey": "lido:alliance-borg:easy-track-limit-proposal:2026-04",
      "version": 1,
      "eventDate": "2026-04-06",
      "publishedAt": "2026-08-22T14:06:01.122Z",
      "title": "Lido proposes higher Alliance BORG Easy Track transfer limits",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Increase Lido Alliance BORG Operational Easy Track Limits to align with EGG",
          "authority": "Snapshot (Lido DAO space)",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x429bdf30549800d3ed87ffa701802d267f6a1e06d1719c6f0a4cb2ecefde521e",
          "documentType": "official_governance_proposal",
          "publishedOn": "2026-04-06"
        }
      ],
      "whatHappened": "The Lido Alliance BORG Foundation proposed increasing the Easy Track security limit governing treasury transfers to its operational multisig.",
      "whatChanged": "If executed, the limit would rise from $250,000 per three-month period to $5 million per six-month period, materially increasing the amount accessible through the delegated Easy Track path.",
      "whatDidNotChange": "The proposal says it adds no budget beyond an already approved annual allocation and does not change the transfer mechanism. No Aragon execution is confirmed.",
      "confirmedFacts": [
        "The existing limit stated in the proposal is $250,000 per three months.",
        "The proposed limit is $5 million per six months.",
        "The affected recipient is the Lido Alliance BORG Foundation operational multisig.",
        "The proposal requires a later Aragon vote for on-chain implementation."
      ],
      "unresolved": [
        "The Snapshot and Aragon vote outcomes.",
        "The final executed Easy Track parameters and effective date.",
        "The operational multisig's owner set and threshold at execution.",
        "Whether objection, revocation, monitoring, and reporting controls remain proportionate to the larger ceiling.",
        "Actual transfers made under any increased limit."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido memo's treasury delegation and Easy Track security limits before the higher ceiling becomes operative.",
        "Verify the executed parameters, multisig controls, objection path, and transaction reporting after implementation."
      ],
      "followUpOn": "2026-04-13",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-381220d11d9b27b0340b2824",
      "stableKey": "aave-v4-ethereum-mainnet-launch-2026-03-30",
      "version": 1,
      "eventDate": "2026-03-30",
      "publishedAt": "2026-08-22T14:06:00.334Z",
      "title": "Aave v4 launched on Ethereum with Hub-and-Spoke liquidity architecture",
      "category": "launch_access",
      "posture": "launched",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v4",
          "name": "Aave v4"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Aave V4 is Live on Ethereum",
          "authority": "Aave Labs",
          "url": "https://aave.com/blog/aave-v4-live-ethereum",
          "documentType": "official launch notice",
          "publishedOn": "2026-03-30"
        }
      ],
      "whatHappened": "Aave v4 became live on Ethereum mainnet with three Liquidity Hubs, multiple Spokes, conservative initial caps, and the Aave Pro interface.",
      "whatChanged": "The launch created a live lending exposure in which Hubs custody shared liquidity while Spokes define collateral, risk-premium, and liquidation rules. Advisor analysis must therefore identify the exact Hub, Spoke, and asset rather than inherit an Aave-wide conclusion.",
      "whatDidNotChange": "Aave v3 remained a separate protocol architecture and no migration of existing v3 positions was established. The launch, audits, conservative caps, and Aave branding did not make v4 approved or suitable for client allocation. This March event does not establish an Avalanche launch.",
      "confirmedFacts": [
        "Aave v4 was live on Ethereum mainnet on March 30, 2026.",
        "The initial deployment contained Core, Prime, and Plus Liquidity Hubs.",
        "Spokes drew from shared Hub liquidity while retaining distinct collateral and risk rules.",
        "Initial supply and borrow caps were intentionally conservative.",
        "Aave Pro provided a live interface for supplying and borrowing through v4."
      ],
      "unresolved": [
        "Production behavior under large liquidations, high utilization, credit-line contraction, and Spoke upgrades was not yet demonstrated.",
        "Exact loss boundaries and withdrawal exposure across every connected Hub and Spoke required separate diligence.",
        "No evidence established that any Ketju mandate approved Aave v4 at launch."
      ],
      "advisorDiligenceImplications": [
        "Create or review a separate aave-v4 memo; do not extend the aave-v3 approval to v4.",
        "Require proposed exposure to identify the exact chain, Hub, supplying Spoke, asset, caps, credit lines, pause authority, and liquidation configuration.",
        "Maintain zero allocation until the maturity and reproducibility requirements in the Aave v4 diligence file are independently satisfied."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-a6337941b02eee952323d59b",
      "stableKey": "aave-v3-sonic-ussd-temp-check-2026-03-25",
      "version": 1,
      "eventDate": "2026-03-25",
      "publishedAt": "2026-08-22T14:06:00.334Z",
      "title": "Aave DAO considered onboarding USSD to the Aave v3 Sonic instance",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[TEMP CHECK] Onboard USSD to Aave V3 Sonic Instance",
          "authority": "Aave DAO via Snapshot",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0x0bd92516f4ee59ccc1016c0660916b331651ea1a43d2474c583abd69e4d611fb",
          "documentType": "official governance proposal",
          "publishedOn": "2026-03-25"
        }
      ],
      "whatHappened": "An official Aave DAO temperature check proposed adding USSD as a supplied and borrowable stablecoin in the Aave v3 Sonic instance.",
      "whatChanged": "The proposal placed USSD and its reserve, minting, redemption, custody, and interoperability dependencies into Aave governance review. It did not yet change live Aave parameters.",
      "whatDidNotChange": "No ARFC, AIP, execution, live reserve, collateral status, caps, LTV, liquidation threshold, or oracle configuration was established by this temperature check.",
      "confirmedFacts": [
        "The proposal targeted the Aave v3 Sonic instance.",
        "It proposed enabling users to supply USSD and use it as a borrowing asset.",
        "The proposal described USSD as relying on tokenized Treasury reserves, institutional custodians, and cross-chain minting infrastructure.",
        "Risk parameters were deferred to later service-provider review and an ARFC."
      ],
      "unresolved": [
        "The temperature-check vote outcome and any subsequent ARFC or AIP were not established by the candidate record.",
        "Final reserve parameters, oracle design, caps, collateral eligibility, and liquidation settings were unspecified.",
        "The reserve, redemption, custody, and interoperability claims had not been independently underwritten for Ketju.",
        "No live execution was confirmed."
      ],
      "advisorDiligenceImplications": [
        "Monitor the proposal through ARFC and on-chain execution before treating USSD as part of any approved Aave v3 market.",
        "If the listing advances, review the Sonic instance and USSD as a distinct exposure with issuer, reserve, custodian, bridge, oracle, and redemption dependencies.",
        "Do not infer approval from the Aave v3 protocol-level verdict."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-efc1f0c82f23e5200d4e0ffd",
      "stableKey": "resolv-usr-signing-infrastructure-compromise-2026-03-22",
      "version": 1,
      "eventDate": "2026-03-22",
      "publishedAt": "2026-08-22T14:06:00.334Z",
      "title": "Resolv signing-infrastructure compromise enabled 80M unbacked USR mint",
      "category": "security_incident",
      "posture": "postmortem",
      "materiality": "critical",
      "evidenceState": "mixed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "resolv-usr",
          "name": "Resolv USR"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Resolv Postmortem: March 22, 2026 Incident",
          "authority": "Resolv",
          "url": "https://resolv.xyz/blog/resolv-postmortem-march-22-2026-incident",
          "documentType": "official postmortem",
          "publishedOn": "2026-04-04"
        }
      ],
      "whatHappened": "Attackers traversed compromised third-party and Resolv infrastructure, obtained authority over the signing key used by Resolv's off-chain minting service, and executed two Counter transactions that created 80 million unbacked USR and extracted approximately $25 million in ETH.",
      "whatChanged": "Resolv halted backend services, paused relevant contracts, revoked and rotated compromised credentials, and neutralized approximately 46 million illicit USR through burns and blacklist functionality. The incident demonstrated that an off-chain signing compromise could become an unconstrained on-chain mint.",
      "whatDidNotChange": "Resolv reported that its collateral pool was not directly compromised. The postmortem did not establish complete recovery, a protocol restart, full compensation for every holder category, or that the rebuilt system was safe or advisor-appropriate.",
      "confirmedFacts": [
        "The official postmortem dates the incident to March 22, 2026.",
        "Two illicit Counter transactions minted 50 million and 30 million USR, respectively.",
        "Resolv attributed approximately $25 million of extracted value to the attack.",
        "Relevant contracts with pause functionality were paused and identified compromised credentials were revoked.",
        "Approximately 46 million of the 80 million illicit USR had been neutralized when the postmortem was published.",
        "Most pre-incident USR holders had received or were in the pipeline for 1:1 compensation."
      ],
      "unresolved": [
        "The external forensic investigation, attacker attribution, and upstream compromise remained open.",
        "The disposition of the remaining illicit USR and recovery of extracted value were incomplete.",
        "Final outcomes for post-incident holders, liquidity providers, RLP holders, and other affected integrations were not established.",
        "Deployment and independent verification of the planned on-chain mint caps, oracle validation, and automated pause controls remained pending.",
        "The timeline and conditions for resuming paused protocol operations were unresolved."
      ],
      "advisorDiligenceImplications": [
        "The Resolv USR diligence file should treat off-chain signing infrastructure and cloud access policy as direct mint-authority dependencies, not merely operational support.",
        "The later Resolv rejection should be checked to ensure it records the unconstrained mint path, pause and blacklist powers, incomplete recovery, and cross-organization credential risk.",
        "Compensation of some holders and planned safeguards do not satisfy reopening criteria or establish advisor suitability."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-a7217a370654cc19b533a53f",
      "stableKey": "aave-v3-wsteth-capo-misconfiguration-2026-03-10",
      "version": 1,
      "eventDate": "2026-03-10",
      "publishedAt": "2026-08-22T14:06:00.334Z",
      "title": "Aave v3 CAPO misconfiguration caused erroneous wstETH liquidations",
      "category": "security_incident",
      "posture": "postmortem",
      "materiality": "critical",
      "evidenceState": "mixed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Post-Mortem: Exchange Rate Misallignment on wstETH Core and Prime Instances",
          "authority": "Chaos Labs via Aave governance",
          "url": "https://governance.aave.com/t/post-mortem-exchange-rate-misallignment-on-wsteth-core-and-prime-instances/24269",
          "documentType": "official postmortem",
          "publishedOn": "2026-03-10"
        }
      ],
      "whatHappened": "A mismatch between CAPO's rate-limited snapshot ratio and its snapshot timestamp artificially reduced the wstETH/stETH exchange rate used by Aave v3 Ethereum Core and Prime, liquidating otherwise healthy E-Mode positions.",
      "whatChanged": "The erroneous update temporarily changed the oracle value used for liquidation and led risk stewards to reduce the affected wstETH borrow caps to 1. The snapshot parameters were then manually realigned and the oracle returned to its prior value.",
      "whatDidNotChange": "The postmortem reports no protocol bad debt and no exploit of Aave v3 core contracts. Restoration of the oracle did not itself complete user compensation, provider accountability, or deployment of all proposed prevention controls.",
      "confirmedFacts": [
        "The incident occurred on March 10, 2026 in Aave v3 Ethereum Core and Prime.",
        "The effective wstETH exchange rate used by the protocol fell approximately 2.85%.",
        "Approximately 10,938 wstETH was liquidated across 34 accounts, representing about $26 million of liquidation volume.",
        "The postmortem reports no bad debt to the protocol.",
        "The affected wstETH borrow caps were reduced to 1 during containment.",
        "Risk Steward intervention realigned the snapshot ratio and timestamp and restored the oracle value."
      ],
      "unresolved": [
        "Final per-user reimbursement and reconciliation were not complete in the postmortem.",
        "The ultimate division of financial responsibility among the DAO and service providers remained unresolved.",
        "Several proposed off-chain validation and on-chain guardrails had not yet been demonstrated as deployed.",
        "The final amount recovered from liquidation-linked activity remained open."
      ],
      "advisorDiligenceImplications": [
        "Review any approved Aave v3 strategy using wstETH E-Mode for exposure to CAPO configuration and delegated Risk Steward operations.",
        "The Aave v3 memo should record oracle-operator configuration as a material operational dependency even when core contracts are not exploited and no bad debt results.",
        "Do not treat restored pricing or a reimbursement proposal as evidence that recurrence controls are complete."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-4717bb1d9392b15e9601dbe7",
      "stableKey": "morpho-sky-vaults-launch-2026-03-03",
      "version": 1,
      "eventDate": "2026-03-03",
      "publishedAt": "2026-08-22T14:06:00.334Z",
      "title": "sky.money launches USDT Savings and USDS Flagship vaults on Morpho",
      "category": "launch_access",
      "posture": "launched",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "morpho-blue",
          "name": "Morpho Blue"
        },
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Announcing the sky.money USDT Savings Vault & USDS Flagship Vault",
          "authority": "sky.money on the Morpho Governance Forum",
          "url": "https://forum.morpho.org/t/announcing-the-sky-money-usdt-savings-vault-usds-flagship-vault/2199",
          "documentType": "official governance-forum launch notice",
          "publishedOn": "2026-03-03"
        }
      ],
      "whatHappened": "sky.money announced the launch of two Morpho vaults: a USDT Savings Vault supplying an existing sUSDS/USDT market and a USDS Flagship Vault combining Sky Savings Rate exposure with allocations to selected Morpho lending markets.",
      "whatChanged": "The launch created new advisor-accessible wrappers joining Sky savings exposure to Morpho curator and allocator risk. The USDT vault routes deposits to a 96.5% LLTV sUSDS/USDT market. The USDS vault states that 80% of deposits earn the Sky Savings Rate through launch rewards while up to 20% is actively allocated across specified Morpho markets, with a 5% limit per market.",
      "whatDidNotChange": "The record does not show a change to the immutable Morpho Blue base contract or to direct USDS/sUSDS redemption mechanics. The USDT vault uses an existing market, and neither launch expands Ketju's existing approved scope or establishes that the new vaults are appropriate or safe.",
      "confirmedFacts": [
        "The official forum record is dated March 3, 2026 and expressly announces the two vault launches.",
        "The USDT Savings Vault accepts USDT and supplies the existing sUSDS/USDT Morpho market at a stated 96.5% LLTV.",
        "The USDS Flagship Vault accepts USDS and uses an allocator bot subject to a stated 20% aggregate market-exposure cap and 5% cap per market.",
        "The listed USDS markets use stUSDS, wstETH, WETH, or cbBTC collateral at stated 86% LLTVs.",
        "The launch included time-limited Merkl incentives denominated in USDT or USDS."
      ],
      "unresolved": [
        "The record does not provide the vault contract addresses, deployed MetaMorpho version, or the on-chain owner, curator, allocator, guardian, and timelock configuration.",
        "Actual allocations, utilization, TVL, exit liquidity, and withdrawal performance at launch are not independently established.",
        "The post does not establish how the allocation set or fees could change after launch incentives end."
      ],
      "advisorDiligenceImplications": [
        "Do not treat the USDS Flagship Vault as equivalent to holding direct sUSDS; it adds Morpho curator, allocator, collateral, oracle, liquidation, incentive, and withdrawal-liquidity risks.",
        "The existing Morpho memo approves only the Steakhouse-curated USDC vault, so these sky.money vaults require separate underwriting before inclusion.",
        "Review both memo files for overlapping Sky and Morpho exposure so the same USDS economic risk is not double-counted."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-878ac37d9f4c3c07a46acf23",
      "stableKey": "lido-stakin-the-tie-operator-continuation-2026-03-02",
      "version": 1,
      "eventDate": "2026-03-02",
      "publishedAt": "2026-08-22T14:06:00.334Z",
      "title": "Lido considered Stakin's continuation after acquisition by The Tie",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Should Stakin continue in the Curated and DVT sets following its acquisition by The Tie?",
          "authority": "Lido DAO via Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x60d9126fed2a492a22ef53942a16a7a8a7ec3a576ffc2b2367ebcec8eb6baa30",
          "documentType": "official governance proposal",
          "publishedOn": "2026-03-02"
        }
      ],
      "whatHappened": "Lido governance considered allowing node operator Stakin to remain in the Ethereum Curated and Simple DVT sets following its acquisition by The Tie, while updating its on-chain registry name and reward address.",
      "whatChanged": "The acquisition introduced new ownership and reward-routing context for a node operator in Lido's curated infrastructure. The proposal created a pending governance decision about continued participation and a later on-chain registry update.",
      "whatDidNotChange": "The proposal states that infrastructure, validator operations, geographic deployment, custody, key management, and validator assignments were not expected to change. The Snapshot record does not prove that the registry or reward-address update was executed.",
      "confirmedFacts": [
        "Stakin participated in Lido's Curated and Simple DVT modules.",
        "Stakin had been acquired by The Tie.",
        "The proposal sought approval for continued node operations under the Stakin by The Tie name.",
        "The proposal contemplated a later on-chain update to the operator name and reward address.",
        "The proposal reported no planned changes to infrastructure, custody, key management, or validator operations."
      ],
      "unresolved": [
        "The Snapshot outcome and any later on-chain registry execution were not established by the candidate record.",
        "The new reward address and executed transaction were not identified in the record.",
        "Independent confirmation that operational personnel, key controls, geography, and infrastructure remained unchanged was not provided.",
        "Any resulting change in operator concentration required separate measurement."
      ],
      "advisorDiligenceImplications": [
        "Update Lido operator diligence to record the ownership change and pending reward-address update.",
        "Verify the executed registry transaction and current reward address before treating the control change as complete.",
        "Continue monitoring operator concentration, key management, and module allocation; the acquisition alone does not fire a documented Lido kill criterion."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-7a2c556ba71ad8384f795085",
      "stableKey": "aave-v3-x-layer-arfc-2026-03-02",
      "version": 1,
      "eventDate": "2026-03-02",
      "publishedAt": "2026-08-22T14:06:00.334Z",
      "title": "Aave DAO considered an Aave v3 deployment on X Layer",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Deploy Aave v3 on X Layer",
          "authority": "Aave DAO via Snapshot",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0x251c520f1f1da8287168420fa2d2a73a2eb5342c3c62508553123129dec059b0",
          "documentType": "official governance proposal",
          "publishedOn": "2026-03-02"
        }
      ],
      "whatHappened": "An official Aave DAO ARFC proposed deploying a new Aave v3 instance on X Layer and supplied an indicative initial asset set and risk configuration.",
      "whatChanged": "The proposal placed a chain-specific Aave deployment, its collateral set, cross-chain dependencies, oracles, caps, and liquidation parameters into formal governance review.",
      "whatDidNotChange": "The ARFC did not itself deploy or activate contracts. Its stated parameters were indicative, so it did not establish final live assets, caps, LTVs, oracle routes, governance messaging, or advisor approval for the new instance.",
      "confirmedFacts": [
        "The proposal targeted an Aave v3 instance on X Layer.",
        "The indicative asset set included USDT0, USDG, GHO, xBTC, wOKB, xETH, xSOL, xBETH, and xOKSOL.",
        "The proposal included indicative collateral, cap, interest-rate, and E-Mode parameters.",
        "The proposal stated that parameters required further risk-provider feedback."
      ],
      "unresolved": [
        "The vote outcome and any subsequent AIP or execution were not established by this candidate.",
        "Final parameters and the deployed contract-address registry were not confirmed.",
        "The security and operational properties of X Layer, cross-chain governance, bridges, and oracle dependencies required separate diligence.",
        "No evidence established that the X Layer instance inherited Ketju's approval for other Aave v3 markets."
      ],
      "advisorDiligenceImplications": [
        "Track the proposal through on-chain execution and require a chain-specific memo before considering exposure.",
        "Do not treat the protocol-level Aave v3 verdict as blanket approval of a new network instance or its assets.",
        "If activated, review each listed asset's bridge depth, oracle, caps, LTV, liquidation liquidity, and exit path."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-8148c9cf0ce03d958933950f",
      "stableKey": "aave-v3:v3.7-candidate-preapproval:2026-02",
      "version": 1,
      "eventDate": "2026-02-28",
      "publishedAt": "2026-08-22T14:05:59.950Z",
      "title": "Aave approves v3.7 candidate scope ahead of final activation vote",
      "category": "upgrade_migration",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Aave v3.7 candidate",
          "authority": "Aave DAO Snapshot",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0x2cdd27eda22b36ddde2303c3d69859f74b330eb93661e632700d18c6095335a8",
          "documentType": "official_governance_record",
          "publishedOn": "2026-02-24"
        }
      ],
      "whatHappened": "Aave tokenholders approved the proposed v3.7 candidate scope, authorizing security procedures before a separate final on-chain AIP activation vote.",
      "whatChanged": "The approved candidate scope advanced changes to eMode isolation, removal of legacy isolation and siloed-borrowing configurations, removal of L2 sequencer-uptime gating, append-only reserve lists, and liquidation-calculation precision into security review and final-governance preparation.",
      "whatDidNotChange": "The Snapshot did not activate v3.7, upgrade any deployment, alter live reserve parameters, or immediately remove existing borrowing and liquidation protections. A final on-chain AIP remained required.",
      "confirmedFacts": [
        "The Snapshot closed on 2026-02-28 with approximately 584,549.94 voting power for and negligible voting power against or abstaining.",
        "The candidate adds an isolated eMode flag under which assets outside the category's collateral bitmap contribute no borrowing LTV.",
        "The candidate removes legacy Isolation Mode and Siloed Borrowing configuration features.",
        "The candidate removes L2 sequencer-uptime checks that can block borrowing and liquidation during an outage or grace period.",
        "The candidate removes the reserve-dropping flow, making reserve lists append-only, and proposes precision improvements to liquidation calculations.",
        "The approved scope could be reduced at the final AIP stage but not expanded except for production bug fixes."
      ],
      "unresolved": [
        "The final audited code, security-review findings, and executable AIP payload.",
        "Which Aave v3 deployments would receive the upgrade and on what schedule.",
        "Whether the final AIP would retain every approved candidate feature.",
        "The detailed liquidation-calculation changes, which the proposal said would be disclosed after internal development and security evaluation.",
        "The operational effect of removing sequencer-uptime gating during future L2 outages and recoveries."
      ],
      "advisorDiligenceImplications": [
        "Review the Aave v3 memo's assumptions about L2 outage protections, liquidation availability, eMode borrowing capacity, and governance-controlled collateral isolation.",
        "Track the final AIP and deployment-specific execution before treating any v3.7 mechanic as operative.",
        "Require deployment-level verification because approval of an upgrade candidate does not establish execution, improved safety, or advisor suitability."
      ],
      "followUpOn": "2026-03-31",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-3cb2e6edd1c8db3868bf3a84",
      "stableKey": "rocket-pool:saturn-1-mainnet-upgrade:2026-02-18",
      "version": 1,
      "eventDate": "2026-02-18",
      "publishedAt": "2026-08-22T14:05:59.950Z",
      "title": "Rocket Pool executes the Saturn 1 mainnet upgrade",
      "category": "upgrade_migration",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "rocket-pool",
          "name": "Rocket Pool"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Rocket Pool v1.4.0 — Saturn",
          "authority": "Rocket Pool",
          "url": "https://github.com/rocket-pool/rocketpool/releases/tag/v1.4",
          "documentType": "official_code_release",
          "publishedOn": "2026-02-11"
        },
        {
          "title": "Rocket Pool protocol timeline",
          "authority": "Rocket Pool",
          "url": "https://rocketpool.net/protocol/about",
          "documentType": "official_protocol_timeline",
          "publishedOn": "2026-02-18"
        },
        {
          "title": "The Saturn 1 Upgrade — What's New",
          "authority": "Rocket Pool",
          "url": "https://docs.rocketpool.net/upgrades/saturn-1/whats-new",
          "documentType": "official_protocol_documentation",
          "publishedOn": "2026-02-18"
        }
      ],
      "whatHappened": "Rocket Pool launched Saturn 1 on Ethereum mainnet, replacing the new-validator minipool path with megapools and changing node-operator bonds, reward routing, protocol economics, and future upgrade mechanics.",
      "whatChanged": "New megapool validators could use 4 ETH bonds; legacy minipool deposits were disabled; multiple validators could share a megapool withdrawal contract; revenue splits became adjustable; and forced delegate upgrades expanded the protocol's ability to migrate megapool logic.",
      "whatDidNotChange": "The launch did not establish that every legacy operator migrated, that rETH exit liquidity improved under stress, or that the upgrade made rETH safer or newly approved.",
      "confirmedFacts": [
        "Rocket Pool's official timeline dates the Saturn 1 mainnet launch to 2026-02-18.",
        "The official v1.4 release was published on 2026-02-11 with a mainnet genesis-time correction.",
        "Official documentation says megapools consolidate multiple validators under one node-operator contract and reduce the required bond per validator to 4 ETH.",
        "Official documentation says legacy minipool deposits are disabled and megapool delegate logic can be forcibly upgraded."
      ],
      "unresolved": [
        "The supplied evidence does not independently reconcile every deployed implementation address and execution transaction.",
        "Operator migration, megapool concentration, deposit-pool capacity, rETH secondary liquidity, and stressed exit performance required post-launch observation.",
        "The practical limits and governance process for adjustable revenue splits and forced delegate upgrades required memo-level control review."
      ],
      "advisorDiligenceImplications": [
        "Review the Rocket Pool memo's node economics, delegate-upgrade authority, validator structure, and exit assumptions against the operative Saturn 1 design.",
        "Update the control graph for megapool contracts, adjustable revenue allocation, and forced delegate upgrades.",
        "Continue monitoring rETH discount, deposit-pool capacity, operator count, and megapool concentration; launch alone does not resolve liquidity or governance risk."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-86f2d0719c7a468b4d6cafeb",
      "stableKey": "lombard-btc.b:bitcoin-smart-accounts-pilot:2026-02-11",
      "version": 1,
      "eventDate": "2026-02-11",
      "publishedAt": "2026-08-22T14:05:59.950Z",
      "title": "Lombard launches Bitcoin Smart Accounts in a private-client pilot",
      "category": "launch_access",
      "posture": "launched",
      "materiality": "material",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "asset",
          "id": "lombard-btc.b",
          "name": "Lombard BTC.b"
        },
        {
          "type": "protocol",
          "id": "morpho-blue",
          "name": "Morpho Blue"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Lombard Introduces Bitcoin Smart Accounts",
          "authority": "Lombard Finance",
          "url": "https://www.lombard.finance/blog/lombard-introduces-bitcoin-smart-accounts/",
          "documentType": "official_product_launch_notice",
          "publishedOn": "2026-02-11"
        }
      ],
      "whatHappened": "Lombard announced that Bitcoin Smart Accounts were live in pilot with select custodian clients. The product recognizes BTC retained in an existing custody account as collateral, issues BTC.b, and uses Morpho as lending infrastructure.",
      "whatChanged": "A new pilot issuance and collateral route connected custodied or self-custodied BTC to on-chain lending without the standard asset-transfer flow described in the existing BTC.b diligence record.",
      "whatDidNotChange": "The product was not publicly available, and the notice did not provide deployed contract addresses, named launch custodians, exact Morpho market addresses, complete legal terms, or evidence that Ketju's existing BTC.b or Morpho approvals extend to this route.",
      "confirmedFacts": [
        "Lombard dated the announcement 2026-02-11 and described the product as live in pilot with select clients.",
        "The designated custody account recognizes locked BTC and issues a receipt token identified as BTC.b.",
        "Lombard identified Morpho as the launch lending infrastructure.",
        "The described architecture uses partially signed Bitcoin transactions and timelocks to create emulated covenants."
      ],
      "unresolved": [
        "The exact custodians, eligible clients, contracts, Morpho markets, oracle configuration, loan-to-value terms, liquidation path, fees, and legal documentation were not disclosed.",
        "It was not established how Smart Account-issued BTC.b integrates with existing BTC.b reserve attestations, redemption mechanics, fungibility, and Security Consortium controls.",
        "Public availability was expected in Q1 2026 but was not established by this event record."
      ],
      "advisorDiligenceImplications": [
        "Review the Lombard BTC.b memo before treating Smart Account-issued BTC.b as equivalent to the previously reviewed mint and custody route.",
        "Require reserve, lock-enforcement, redemption, liquidation, oracle, legal-title, and custodian evidence for this issuance path.",
        "The Morpho approval is limited to reviewed Steakhouse-curated USDC exposure and must not be extended to an unidentified Bitcoin Smart Account market."
      ],
      "followUpOn": "2026-03-31",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-c85ddd439b2b68b9a7195673",
      "stableKey": "aave-v3:megaeth-deployment-arfc:2026-01",
      "version": 2,
      "eventDate": "2026-02-09",
      "publishedAt": "2026-08-22T14:05:59.950Z",
      "title": "BTC.b and Aave launch on MegaETH mainnet",
      "category": "launch_access",
      "posture": "launched",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        },
        {
          "type": "asset",
          "id": "lombard-btc.b",
          "name": "Lombard BTC.b"
        }
      ],
      "primaryDocuments": [
        {
          "title": "BTC.b Is Live on MegaETH",
          "authority": "Lombard Finance",
          "url": "https://www.lombard.finance/blog/hardest-money-meets-fastest-chain-btc-b-is-live-on-mega-eth/",
          "documentType": "official_launch_notice",
          "publishedOn": "2026-02-09"
        }
      ],
      "whatHappened": "Lombard reported that MegaETH mainnet launched with BTC.b as its canonical Bitcoin asset and that Aave was one of four live protocols supporting BTC.b at launch.",
      "whatChanged": "The previously proposed Aave MegaETH deployment and BTC.b listing were represented by a first-party issuer as live, expanding both watched objects to a new chain and operational dependency perimeter.",
      "whatDidNotChange": "The launch did not make MegaETH, its Aave market, or BTC.b exposure on that chain approved for Ketju clients. The notice did not provide verified contract addresses, an executed Aave payload, or independent liquidity and oracle observations.",
      "confirmedFacts": [
        "Lombard dated the launch notice 2026-02-09.",
        "The notice states that MegaETH mainnet and its BTC.b infrastructure were live.",
        "BTC.b was identified as MegaETH's canonical Bitcoin asset.",
        "Aave, Avon, Kumbaya, and Prism were identified as live BTC.b venues at launch."
      ],
      "unresolved": [
        "The final Aave governance execution, deployed market and asset addresses, oracle configuration, caps, liquidation settings, and administrative controls were not reconciled in this record.",
        "BTC.b minting, bridging, redemption, proof-of-reserve coverage, and stressed liquidity on MegaETH required separate verification.",
        "MegaETH's sequencer, upgrade, data-availability, bridge, and exit controls were outside the supplied evidence."
      ],
      "advisorDiligenceImplications": [
        "Supersede the proposal-stage MegaETH interpretation in the Aave and BTC.b diligence files, while keeping the new chain exposure unapproved pending review.",
        "Require chain-specific verification of Aave contracts, BTC.b contracts, oracles, caps, liquidation liquidity, bridge routes, reserve coverage, and exit mechanics.",
        "Do not infer safety or suitability from the launch announcement or promotional performance claims."
      ],
      "followUpOn": null,
      "previousInterpretation": "Aave's MegaETH deployment and BTC.b inclusion were previously recorded as proposed, with no live market or verified deployment established at the January boundary.",
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-da6ea1d6fa9d520525a8accf",
      "stableKey": "coinbase-bridge:base-mainnet-transaction-drops-postmortem:2026-02-03",
      "version": 1,
      "eventDate": "2026-02-03",
      "publishedAt": "2026-08-22T14:05:59.950Z",
      "title": "Base publishes postmortem on severe transaction drops and inclusion delays",
      "category": "market_stress",
      "posture": "postmortem",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "coinbase-bridge",
          "name": "Base canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "High Rate of Transaction Drops and Transaction Inclusion Delays",
          "authority": "Base Status",
          "url": "https://status.base.org/incidents/zfvvgt46j9d8",
          "documentType": "official_status_postmortem",
          "publishedOn": "2026-02-03"
        }
      ],
      "whatHappened": "Base published a postmortem for a January 31 period of severe mainnet transaction drops, inclusion latency, and some block-production delays under high transaction load.",
      "whatChanged": "Base rolled back the transaction-propagation configuration change identified as the immediate cause and committed to mempool-pipeline, alerting, and change-monitoring improvements. The event added a significant realized availability failure to canonical-bridge operational diligence.",
      "whatDidNotChange": "The postmortem did not report a canonical-bridge contract exploit, asset loss, withdrawal-rule change, challenge-period change, or continuing impairment after the rollback.",
      "confirmedFacts": [
        "Base estimates that approximately 20% of submitted transactions landed on-chain during the acute incident window.",
        "Base reports 2.1 million dropped transactions and 512,000 transactions included in blocks.",
        "Approximately 2% of blocks during the reported window took longer than two seconds to build.",
        "Base attributed the incident to an interaction between a transaction-propagation queue-size change, rising base fees, and mempool-client behavior.",
        "The mitigation was to roll back the configuration change, after which Base reported restored network stability."
      ],
      "unresolved": [
        "The postmortem lists 19:17–20:41 UTC as the incident endpoints but calls that interval two hours and 26 minutes; those figures are arithmetically inconsistent.",
        "The record does not identify how many canonical-bridge deposits, proofs, or withdrawal transactions were delayed or dropped.",
        "Completion and effectiveness of the promised mempool-pipeline and monitoring improvements were not established by the postmortem."
      ],
      "advisorDiligenceImplications": [
        "Review the Coinbase Bridge memo's sequencer, mempool, block-builder, RPC, retry, and transaction-inclusion assumptions.",
        "Preserve transaction resubmission, alternate-RPC, nonce-management, and status-monitoring procedures for bridge operations during congestion.",
        "The resolved event does not independently fire a bridge-contract loss criterion, but recurrence should inform operational limits and exit planning."
      ],
      "followUpOn": "2026-03-03",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-4213b19cc1f6a96ef8e12149",
      "stableKey": "aave-v3:megaeth-deployment-arfc:2026-01",
      "version": 1,
      "eventDate": "2026-01-30",
      "publishedAt": "2026-08-22T14:05:59.620Z",
      "title": "Aave opens MegaETH deployment ARFC with BTC.b in the proposed initial market",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        },
        {
          "type": "asset",
          "id": "lombard-btc.b",
          "name": "Lombard BTC.b"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Deploy Aave V3 to MegaETH",
          "authority": "Aave DAO",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0xf6e4ca9941805b3c89615df693c657d81eda6a4c8a24d6d2e220020f9c1c5aa7",
          "documentType": "Official Snapshot governance proposal",
          "publishedOn": "2026-01-29"
        }
      ],
      "whatHappened": "Aave DAO opened an ARFC vote to prepare an Aave V3 deployment for MegaETH mainnet, with BTC.b included in the proposed initial asset set.",
      "whatChanged": "A concrete governance process began for a new Aave market and a potential new Aave use of watched BTC.b, expanding the research perimeter if later approved and deployed.",
      "whatDidNotChange": "At the 2026-01-31 backfill boundary, the vote had not ended. No AIP execution, deployed market, verified addresses, live liquidity, or Ketju approval for MegaETH exposure was established.",
      "confirmedFacts": [
        "The official Snapshot vote opened on 2026-01-30.",
        "The vote was scheduled to close on 2026-02-02, after this backfill window.",
        "The proposal specifies a prospective Day 0 MegaETH deployment and includes BTC.b in the proposed initial asset list."
      ],
      "unresolved": [
        "The vote outcome was not resolved within the January backfill window.",
        "Final execution, deployed addresses, oracle configuration, liquidity, and live BTC.b risk parameters were not established within the window."
      ],
      "advisorDiligenceImplications": [
        "Monitor the vote and any later AIP or deployment, but do not extend the existing Aave or BTC.b memo to MegaETH.",
        "If deployed, require separate review of MegaETH, oracle and data-availability dependencies, BTC.b collateral parameters, and exit liquidity."
      ],
      "followUpOn": "2026-02-02",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": false
    },
    {
      "id": "event-event-draft-5b4713886a15a1731cb52d26",
      "stableKey": "lido:rewards-share-committee-reform:2026-01",
      "version": 1,
      "eventDate": "2026-01-26",
      "publishedAt": "2026-08-22T14:05:59.620Z",
      "title": "Lido approves Rewards Share Committee reform",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Rewards Share Committee Reform",
          "authority": "Lido DAO",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0xb4a35720b03f4c888c2fb41ab66ed324262d7a5b4696ffc3ee20bb35ebb0df6f",
          "documentType": "Official Snapshot governance proposal and vote",
          "publishedOn": "2026-01-19"
        }
      ],
      "whatHappened": "Lido DAO approved reforming and relaunching the Rewards Share Committee as a DAO-authorized operational committee with added duties for node-operator rebates and stVault rewards disbursement.",
      "whatChanged": "The approved mandate expands the committee's operational role in allocating approved rebates and executing treasury-funded stVault reward payments within DAO-approved budgets.",
      "whatDidNotChange": "The vote did not itself change stETH withdrawals, the core staking fee, validator balances, or demonstrate that any particular payment had been executed.",
      "confirmedFacts": [
        "The official vote closed on 2026-01-26.",
        "Approximately 54.58 million voting units supported the proposal, with approximately 1.32 against.",
        "The approved mandate covers manual node-operator rebates and operational execution of stVault reward disbursements within approved budgets."
      ],
      "unresolved": [
        "The candidate record does not establish when the reformed committee began operating.",
        "Specific future payout instructions and their on-chain execution remain separate actions."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido memo's operational-control map to reflect the committee's approved treasury-disbursement and rebate duties.",
        "Continue to distinguish committee execution authority from DAO approval of budgets and from the separate stVault Committee's payout instructions."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-dfc52c7f7ef0c8c02868f702",
      "stableKey": "lido:dvt-dvv-incentive-allocation:2026-01",
      "version": 1,
      "eventDate": "2026-01-26",
      "publishedAt": "2026-08-22T14:05:59.620Z",
      "title": "Lido approves variable DVT and DVV incentive allocations",
      "category": "economic_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "DVT & DVV Incentive Allocation Changes",
          "authority": "Lido DAO",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x8b8619f09213b868708b25cb2512023234e5e160cba5c291f4e9d944d2ccd3fa",
          "documentType": "Official Snapshot governance proposal and vote",
          "publishedOn": "2026-01-19"
        }
      ],
      "whatHappened": "Lido DAO approved replacing the fixed allocation of certain DVT incentives with a variable monthly split between eligible node operators and Mellow Distributed Validator Vault stakers.",
      "whatChanged": "For covered Curated Module and Community Staking Module operators, the node-operator share can rise to 50% when modeled DVT costs are high, while the staker share can rise to 85% as costs fall or incentives increase.",
      "whatDidNotChange": "The proposal expressly leaves the Simple DVT Module unchanged. It does not change Lido's core staking fee, withdrawal mechanism, or prove any particular monthly allocation was executed.",
      "confirmedFacts": [
        "The official vote closed on 2026-01-26.",
        "Approximately 54.54 million voting units supported the proposal, with approximately 205.11 against.",
        "The approved model applies to covered CM and CSM operators using SSV or Obol and is calculated monthly.",
        "The proposal states that the Simple DVT Module is unchanged."
      ],
      "unresolved": [
        "The first calculated allocation and payment execution are not established by the candidate record.",
        "The realized effect on operator behavior, validator performance, and staker returns remained unknown at approval."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido memo's node-operator incentive analysis and return attribution for covered DVT modules.",
        "Do not generalize the approved allocation to the Simple DVT Module or to the core stETH fee."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-754e4a83650bd050c0470cc2",
      "stableKey": "axelar:cometbft-csa-2026-001-patch-release:2026-01-23",
      "version": 1,
      "eventDate": "2026-01-23",
      "publishedAt": "2026-08-22T14:05:59.620Z",
      "title": "Axelar publishes CometBFT security-patch release v1.3.8",
      "category": "upgrade_migration",
      "posture": "confirmed",
      "materiality": "material",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Axelar Core v1.3.8",
          "authority": "Axelar",
          "url": "https://github.com/axelarnetwork/axelar-core/releases/tag/v1.3.8",
          "documentType": "Official GitHub release",
          "publishedOn": "2026-01-23"
        }
      ],
      "whatHappened": "Axelar published axelar-core v1.3.8 with an upgraded CometBFT dependency containing the fix for CSA-2026-001.",
      "whatChanged": "A patched official validator build became available, creating a concrete infrastructure-version diligence requirement for the watched Axelar dependency.",
      "whatDidNotChange": "The release says the change is not consensus-breaking and no funds are at risk. It does not prove network-wide validator adoption, an exploit, fund loss, or a gateway-contract change.",
      "confirmedFacts": [
        "Axelar Core v1.3.8 was released on 2026-01-23.",
        "The release upgrades CometBFT with a fix for CSA-2026-001.",
        "Axelar states that the change is not consensus-breaking and that no funds are at risk."
      ],
      "unresolved": [
        "The cached record does not establish validator adoption of v1.3.8 across the live network.",
        "The operative vulnerability details and any exposure before upgrade are not stated in the candidate record."
      ],
      "advisorDiligenceImplications": [
        "Review the Axelar memo's infrastructure-security record and verify that relevant service providers or integrations track the patched validator version.",
        "Do not infer that release publication alone proves the live validator set has upgraded."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-2d02ddaade731022a5edf38a",
      "stableKey": "rocket-pool:rpip-77-latest-minipool-delegate:2026-01",
      "version": 1,
      "eventDate": "2026-01-23",
      "publishedAt": "2026-08-22T14:05:59.620Z",
      "title": "Rocket Pool proposes defaulting Smart Node minipools to the latest delegate",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "rocket-pool",
          "name": "Rocket Pool"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Use Latest Delegate for Minipools (RPIP-77)",
          "authority": "Rocket Pool",
          "url": "https://snapshot.org/#/rocketpool-dao.eth/proposal/0x0f82693c42d491f8a74fe0584a1d503e30ab8c27a3800bc0c257d0f35340bcc5",
          "documentType": "Official Snapshot governance proposal",
          "publishedOn": "2026-01-23"
        }
      ],
      "whatHappened": "Rocket Pool opened the RPIP-77 vote to make Smart Node-managed minipools use the latest delegate and remove supported configuration for older delegate implementations.",
      "whatChanged": "The proposal would increase governance's practical ability to propagate approved minipool logic through the supported Smart Node path and reduce delegate-version fragmentation.",
      "whatDidNotChange": "At the January window boundary, the vote was still open and no Smart Node update was confirmed released or adopted. Non-Smart Node users would not be forced to change delegates.",
      "confirmedFacts": [
        "The official vote opened on 2026-01-23.",
        "The proposal states that only 7% of operators had proactively selected the latest delegate.",
        "A positive result would lead to a Smart Node update changing defaults and removing supported older-delegate options."
      ],
      "unresolved": [
        "The vote did not close until 2026-02-06, outside the backfill window.",
        "Implementation timing, release contents, adoption, and any later enforcement mechanism were not established within January."
      ],
      "advisorDiligenceImplications": [
        "Monitor the vote and resulting Smart Node release because delegate propagation changes the practical control model for legacy minipools.",
        "Do not infer that governance-approved logic became universal or that non-Smart Node operators lost their ability to retain older delegates."
      ],
      "followUpOn": "2026-02-06",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-395db654497003c963409a2e",
      "stableKey": "aave-v3:mantle-deployment-arfc:2026-01",
      "version": 1,
      "eventDate": "2026-01-23",
      "publishedAt": "2026-08-22T14:05:59.620Z",
      "title": "Aave approves Mantle deployment ARFC",
      "category": "governance",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Deploy Aave v3 on Mantle",
          "authority": "Aave DAO",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0x2f9378770f1838f0ea8d483239af1530c9fbea98d648e0b11e4647dcb722d119",
          "documentType": "Official Snapshot governance proposal and vote",
          "publishedOn": "2026-01-19"
        }
      ],
      "whatHappened": "Aave DAO approved the ARFC for a prospective Aave V3 deployment on Mantle with an initial asset set and proposed risk, GHO, GSM, and budget parameters.",
      "whatChanged": "The Mantle deployment advanced through an off-chain governance stage, creating a concrete new-market research item for Aave.",
      "whatDidNotChange": "The ARFC approval did not itself deploy contracts, execute a final AIP, establish live liquidity, or extend Ketju's existing Aave approval to Mantle.",
      "confirmedFacts": [
        "The official vote ran from 2026-01-20 through 2026-01-23.",
        "Approximately 654,785.57 voting units supported the proposal, compared with approximately 15.22 against and 2.47 abstaining.",
        "The proposal contains a prospective initial asset and risk-parameter configuration for Mantle."
      ],
      "unresolved": [
        "Final AIP execution, verified deployed addresses, oracle configuration, and launch timing were not established by this record.",
        "Live liquidity, stressed exits, and the final effective parameters remained unconfirmed."
      ],
      "advisorDiligenceImplications": [
        "Monitor any final AIP and deployed-address record, but do not treat Mantle as covered by the existing Aave memo.",
        "Require chain, data-availability, oracle, collateral, liquidity, and exit-path review before considering the Mantle market."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-7cd4ca3232d18804945b3f84",
      "stableKey": "coinbase-bridge:base-mainnet-delayed-blocks:2026-01-20",
      "version": 1,
      "eventDate": "2026-01-20",
      "publishedAt": "2026-08-22T14:05:59.620Z",
      "title": "Base recovers from periodically delayed block building",
      "category": "market_stress",
      "posture": "recovered",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "coinbase-bridge",
          "name": "Base canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Periodically delayed block building on Base Mainnet",
          "authority": "Base",
          "url": "https://status.base.org/incidents/c9cjh8jbz8b0",
          "documentType": "Official status incident",
          "publishedOn": "2026-01-20"
        }
      ],
      "whatHappened": "Base reported periodically delayed blocks during volatile activity and marked the incident resolved after degraded block building and transaction inclusion between 14:45 and 15:10 UTC.",
      "whatChanged": "Transaction inclusion on the chain supporting the watched canonical bridge was temporarily less reliable, adding a confirmed operational incident to the bridge diligence record.",
      "whatDidNotChange": "The status record does not report a bridge-contract exploit, fund loss, withdrawal pause, challenge-period change, or continuing impairment after resolution.",
      "confirmedFacts": [
        "Base's official status page marked the incident resolved.",
        "The reported degradation occurred between 14:45 and 15:10 UTC on 2026-01-20.",
        "Users may have experienced delayed transaction inclusion and degraded block-building performance."
      ],
      "unresolved": [
        "The status record does not quantify affected transaction volume or identify whether any canonical-bridge transactions were specifically delayed.",
        "The record attributes the condition to volatile activity but provides no detailed root-cause analysis."
      ],
      "advisorDiligenceImplications": [
        "Add the incident to the Coinbase Bridge operational-reliability record and review recurrence before the next memo decision.",
        "No kill criterion is confirmed by this short resolved delay, but stressed exits should continue to account for sequencer and inclusion risk."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-f4650d1555951e124cb89dca",
      "stableKey": "optimism-bridge:op-node-security-release:v1.16.5:2026-01-13",
      "version": 1,
      "eventDate": "2026-01-13",
      "publishedAt": "2026-08-22T14:05:59.620Z",
      "title": "Optimism publishes essential op-node security release v1.16.5",
      "category": "upgrade_migration",
      "posture": "confirmed",
      "materiality": "material",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "optimism-bridge",
          "name": "Optimism canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "op-node v1.16.5",
          "authority": "OP Labs",
          "url": "https://github.com/ethereum-optimism/optimism/releases/tag/op-node/v1.16.5",
          "documentType": "Official GitHub release",
          "publishedOn": "2026-01-13"
        }
      ],
      "whatHappened": "OP Labs published op-node v1.16.5 and warned that its corresponding op-geth release contains security fixes, making the release essential for all chains.",
      "whatChanged": "A security-relevant official node version became available and was designated essential, creating an infrastructure-version review requirement for OP Mainnet dependencies.",
      "whatDidNotChange": "The release does not identify an exploited vulnerability, fund loss, bridge-contract change, withdrawal change, or confirmed OP Mainnet adoption.",
      "confirmedFacts": [
        "op-node v1.16.5 was released on 2026-01-13.",
        "The release upgrades the corresponding op-geth dependency.",
        "The official notice says the corresponding op-geth release includes security fixes and calls the release essential for all chains."
      ],
      "unresolved": [
        "The security fixes are not described in the cached candidate record.",
        "The record does not establish when OP Mainnet operators adopted the release."
      ],
      "advisorDiligenceImplications": [
        "Review the Optimism bridge memo's infrastructure-security record and verify upgrade tracking by relevant operators and service providers.",
        "Do not treat release publication as proof that the live network had already adopted the patched software."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-21cfb0ef8066c75f7b835a8e",
      "stableKey": "rocket-pool-balancer-alliance-v3-pool-proposal-2025-12-19",
      "version": 1,
      "eventDate": "2025-12-19",
      "publishedAt": "2026-08-22T14:05:59.252Z",
      "title": "Balancer proposes moving Rocket Pool alliance treatment to its v3 liquidity pool",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "rocket-pool",
          "name": "Rocket Pool"
        }
      ],
      "primaryDocuments": [
        {
          "title": "BIP-896: Rocket Pool Balancer Alliance Addendum",
          "authority": "Balancer governance",
          "url": "https://snapshot.org/#/balancer.eth/proposal/0x2aaa6c1df567752f1be41c61a523632871228ed1a8712e3ea0660d3af6ee5cf4",
          "documentType": "Snapshot governance proposal",
          "publishedOn": "2025-12-19"
        }
      ],
      "whatHappened": "Balancer governance received BIP-896, proposing an alliance addendum after Rocket Pool moved its primary Ethereum liquidity from a deprecated Balancer v2 pool to a Balancer v3 pool.",
      "whatChanged": "The proposal would remove the v2 rETH/WETH pool and add the v3 rETH/waEthWETH pool to the special Rocket Pool alliance revenue-sharing treatment.",
      "whatDidNotChange": "The candidate does not establish that the proposal passed or executed, that incentives became active, or that rETH redemption and Rocket Pool protocol controls changed.",
      "confirmedFacts": [
        "The proposal identifies the v2 rETH/WETH pool at 0x1e19cf2d73a72ef1332c882f20534b6519be0276 for removal.",
        "It identifies the v3 rETH/waEthWETH pool at 0x1ea5870f7C037930CE1d5d8d9317c670e89e13E3 for addition.",
        "The proposed incentive token remains RPL.",
        "The proposal states that Rocket Pool had migrated its primary liquidity pool to Balancer v3."
      ],
      "unresolved": [
        "The Snapshot candidate does not establish the final vote result or execution status.",
        "The resulting incentive amount, duration, and realized effect on rETH liquidity are not stated.",
        "The candidate references a prior security-driven v2 deprecation but is insufficient to establish that separate incident's cause or scope."
      ],
      "advisorDiligenceImplications": [
        "Monitor whether alliance treatment becomes operative and whether liquidity migrates successfully to the named v3 pool.",
        "Reassess executable rETH secondary-market depth after migration rather than inferring liquidity from governance approval.",
        "The proposal does not fire Rocket Pool's existing discount, operator-count, redemption, or protocol-revenue kill criteria."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-e836aabc6e66c06356741e9e",
      "stableKey": "lido:alliance-borg:goose-3-bylaws-approval-2025-12",
      "version": 1,
      "eventDate": "2025-12-19",
      "publishedAt": "2026-08-22T14:05:59.252Z",
      "title": "Lido approves broader purposes for Lido Alliance BORG",
      "category": "governance",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Lido Alliance BORG – Amendment of Bylaws to Enable GOOSE-3 Execution",
          "authority": "Lido DAO governance via Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x5e087c8d53509dd9b55441f9ee6180da21ee5cf8fe68fab9d852b75b35a44a18",
          "documentType": "governance_record",
          "publishedOn": "2025-12-11"
        }
      ],
      "whatHappened": "LDO holders approved a conditional amendment broadening Lido Alliance BORG’s purposes so it could house and operate products and initiatives contemplated by GOOSE-3.",
      "whatChanged": "Governance authorized the DAO-adjacent entity’s directors, subject to GOOSE-3 approval, to expand the entity beyond administration of the Lido Alliance Program into product and revenue-diversification initiatives.",
      "whatDidNotChange": "The record does not establish that the directors adopted the amendment, that any GOOSE-3 product launched, or that Lido’s staking, withdrawal, oracle, custody, upgrade, or loss-allocation mechanics changed.",
      "confirmedFacts": [
        "The Snapshot vote closed on 2025-12-19 with approximately 56.73 million LDO For and zero Against.",
        "The approved text broadens the entity’s purposes to include initiatives and products intended to expand Lido DAO revenue and its product portfolio.",
        "Implementation remained conditional on GOOSE-3 approval and a later board resolution by Lido Alliance BORG’s directors."
      ],
      "unresolved": [
        "Whether GOOSE-3 received every required approval.",
        "Whether the directors subsequently adopted the amended bylaws.",
        "Which products or activities, if any, were later placed inside Lido Alliance BORG."
      ],
      "advisorDiligenceImplications": [
        "Monitor the expanded DAO-adjacent organizational perimeter when assessing governance, accountability, and dependencies of future Lido-branded products.",
        "Do not treat the approval as evidence that a new product was live, safe, or covered by the existing stETH approval."
      ],
      "followUpOn": "2026-08-27",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-3bba919c37643b15a703d46a",
      "stableKey": "lido:ethereum:seal-safe-harbor-approval-2025-12",
      "version": 1,
      "eventDate": "2025-12-19",
      "publishedAt": "2026-08-22T14:05:59.252Z",
      "title": "Lido approves SEAL Safe Harbor exploit-response framework",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Adopt The SEAL Safe Harbor Agreement",
          "authority": "Lido DAO governance via Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x0188ab77d59b11ce589d88c350093faffdb07b3a9c9ba4d8af12755d4b2178c0",
          "documentType": "governance_record",
          "publishedOn": "2025-12-11"
        }
      ],
      "whatHappened": "LDO holders approved adopting the SEAL Whitehat Safe Harbor framework for Lido on Ethereum, including recovery, bounty, scope-management, and incident-contact terms.",
      "whatChanged": "Governance approved a civil safe-harbor path for whitehats responding to active exploits, a 10% bounty capped at $2 million, return of recovered assets to the Aragon Voting contract, and temporary 4-of-5 committee authority over the agreement’s scoped-account list pending audits and transfer to DAO control.",
      "whatDidNotChange": "The vote did not itself demonstrate on-chain registration, transfer agreement ownership to Aragon Voting, dissolve the temporary committee, allocate a bounty, or establish that any exploit or recovery had occurred.",
      "confirmedFacts": [
        "The Snapshot vote closed on 2025-12-19 with approximately 56.73 million LDO Approve votes and zero Reject votes.",
        "Approved bounty terms were 10% of recovered assets, subject to a $2 million individual and aggregate cap for an incident.",
        "Whitehats must return recovered assets; any bounty payment requires a separate Lido DAO governance vote.",
        "The designated recovery address was the Aragon Voting contract on Ethereum.",
        "A named 4-of-5 committee was approved to manage scoped accounts temporarily; the proposal states that the committee would not custody funds."
      ],
      "unresolved": [
        "Whether the agreement was subsequently registered in the Safe Harbor Registry.",
        "Whether the Safe Harbor contract audits were completed and agreement ownership transferred to Aragon Voting.",
        "Whether the temporary committee was dissolved and whether its scope changed before dissolution.",
        "Whether every contract listed in the initial protected-asset scope was operative and under the represented ownership at approval time."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido control map to record the new exploit-response framework, recovery destination, bounty economics, and temporary scope-management authority.",
        "Verify the later on-chain registration and ownership state before treating the approved framework as operational.",
        "Do not infer that Safe Harbor adoption prevents exploits, guarantees recovery, or changes the existing stETH withdrawal and loss-allocation mechanics."
      ],
      "followUpOn": "2026-08-27",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-aca50fe940a25a7cdcdcfc44",
      "stableKey": "gearbox-mellow-rsteth-emergency-expiry-2025-12-18",
      "version": 1,
      "eventDate": "2025-12-18",
      "publishedAt": "2026-08-22T14:05:59.252Z",
      "title": "Gearbox proposes emergency rstETH account expiry ahead of an in-place upgrade",
      "category": "governance",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "gearbox",
          "name": "Gearbox"
        },
        {
          "type": "protocol",
          "id": "mellow-core",
          "name": "Mellow Core"
        }
      ],
      "primaryDocuments": [
        {
          "title": "GIP-273: Mellow and P2P rstETH implementation update response",
          "authority": "Gearbox governance",
          "url": "https://snapshot.org/#/gearbox.eth/proposal/0xf1afeed54d0878cd2d8979ad710b437f8d451495245cc1127dc602bb743f6dda",
          "documentType": "Snapshot governance proposal",
          "publishedOn": "2025-12-18"
        }
      ],
      "whatHappened": "Gearbox governance proposed expiring affected Chaos Labs wstETH Credit Managers before Mellow and P2P changed the implementation behind the existing rstETH token address. The proposal described compatibility and risk-profile discontinuities and added liquidation protections.",
      "whatChanged": "If executed, affected Credit Managers would expire on 2025-12-20, liquidation fees and premiums would fall to 0.01%, and specified emergency-liquidator profits would be returned to account owners.",
      "whatDidNotChange": "The candidate does not prove that the vote passed, transactions executed, or the rstETH implementation upgrade occurred. It reports no completed liquidation or protocol loss.",
      "confirmedFacts": [
        "GIP-273 identifies an intended in-place rstETH implementation change rather than migration to a new token address.",
        "Gearbox states that existing oracles and adapters could become incompatible with the new implementation.",
        "The proposal sets an expiration timestamp of 2025-12-20 13:00 UTC for specified Chaos Labs wstETH Credit Managers.",
        "It proposes 0.01% expired liquidation fees and premiums and a return of specified emergency-liquidator profits to account owners."
      ],
      "unresolved": [
        "The Snapshot record does not establish the final vote, timelock, or execution result.",
        "The operative Mellow implementation diff, deployment transaction, audits, and final upgrade time are not included.",
        "The number and value of affected rstETH Credit Accounts are not stated.",
        "No evidence establishes whether any account was liquidated or suffered loss."
      ],
      "advisorDiligenceImplications": [
        "Review both Mellow Core and Gearbox diligence for same-address implementation migration risk.",
        "Treat token-address continuity as insufficient evidence that an asset's technical and economic risk profile is unchanged.",
        "Verify whether affected Gearbox positions were closed or migrated before the expiration timestamp and whether emergency protections executed as proposed."
      ],
      "followUpOn": "2025-12-20",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-0b25776a8dad51ead254479b",
      "stableKey": "axelar-validator-crash-security-patch-2025-12-15",
      "version": 1,
      "eventDate": "2025-12-15",
      "publishedAt": "2026-08-22T14:05:59.252Z",
      "title": "Axelar validators apply a security patch addressing node-crash risk",
      "category": "upgrade_migration",
      "posture": "confirmed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Axelar Core v1.3.5",
          "authority": "Axelar",
          "url": "https://github.com/axelarnetwork/axelar-core/releases/tag/v1.3.5",
          "documentType": "official code release",
          "publishedOn": "2025-12-15"
        }
      ],
      "whatHappened": "Axelar published core release v1.3.5 with an important CometBFT security patch and a staking-rewards fix. The release urged node operators to apply it promptly and stated that a majority of validators had already done so.",
      "whatChanged": "A patched Axelar Core version became available, and Axelar reported majority-validator adoption intended to prevent validator nodes from crashing.",
      "whatDidNotChange": "The release said no funds were at risk and did not report a consensus failure, cross-chain message failure, asset loss, or completed adoption by every validator.",
      "confirmedFacts": [
        "Axelar Core v1.3.5 was released on 2025-12-15.",
        "The official release identifies an important CometBFT security patch and a staking-rewards fix.",
        "Axelar stated that the patch prevents node crashes and that a majority of validators had applied it.",
        "The release stated that no funds were at risk."
      ],
      "unresolved": [
        "The release does not identify the vulnerability or affected CometBFT behavior in enough detail to independently assess exploitability.",
        "The proportion and identity of validators still running unpatched software were not disclosed.",
        "No primary evidence in the candidate establishes whether the vulnerability caused downtime before patching."
      ],
      "advisorDiligenceImplications": [
        "Add the patch and reported adoption to Axelar's operational-resilience history.",
        "Review whether any approved integration depended on Axelar during a period when a material validator share remained unpatched.",
        "Do not interpret majority adoption or the no-funds-at-risk statement as proof that every integration or validator was unaffected."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-4f9730c11a4bcb056964aedb",
      "stableKey": "goldfinch-hack-response-reimbursement-proposal-2025-12-14",
      "version": 1,
      "eventDate": "2025-12-14",
      "publishedAt": "2026-08-22T14:05:59.252Z",
      "title": "Goldfinch proposes a $250,000 reimbursement after a reported test-contract exploit",
      "category": "governance",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "mixed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "goldfinch",
          "name": "Goldfinch"
        }
      ],
      "primaryDocuments": [
        {
          "title": "GIP-85: Goldfinch Hack Response",
          "authority": "Goldfinch governance",
          "url": "https://snapshot.org/#/goldfinch.eth/proposal/0x3581a51f73aa4b2e691c2ac2cdf82520d8421429f23cc8366a923b85df8315b3",
          "documentType": "Snapshot governance proposal",
          "publishedOn": "2025-12-14"
        }
      ],
      "whatHappened": "Goldfinch governance opened GIP-85, stating that attackers exploited a five-year-old test contract on 2025-12-02 and proposing to reimburse $250,000 from the remaining bug-bounty budget.",
      "whatChanged": "The proposal introduced a concrete loss-allocation decision that would cover approximately 75% of the governance record's reported $330,000 USDC loss.",
      "whatDidNotChange": "The candidate does not prove that the vote passed, reimbursement was paid, or the underlying exploit affected Goldfinch's active lending pools or client positions.",
      "confirmedFacts": [
        "Goldfinch governance published GIP-85 on 2025-12-14.",
        "The proposal asks voters to authorize $250,000 from the remaining bug-bounty budget for reimbursement.",
        "The governance record attributes a $330,000 USDC loss to a 2025-12-02 exploit of an old test contract.",
        "The proposal characterizes the reimbursement as approximately 75% of reported damages."
      ],
      "unresolved": [
        "The candidate does not include the exploited contract address, transactions, technical root cause, or independent loss reconciliation.",
        "The final vote result and any reimbursement transaction are not established.",
        "Whether the vulnerable test contract shared code, roles, or dependencies with active Goldfinch contracts is not established.",
        "The identities and eligibility of proposed reimbursement recipients are not stated."
      ],
      "advisorDiligenceImplications": [
        "Add the reported exploit and proposed treasury loss allocation to Goldfinch's incident and governance history.",
        "Require contract-level confirmation before treating the reported amount or scope as fully reconciled.",
        "Review whether the incident changes conclusions about deprecated-contract management, bug-bounty reserves, or recovery governance."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-673b1e8f5d53aa99df5682a1",
      "stableKey": "lido-goose3-ecosystem-grant-budget-2025-12-11",
      "version": 1,
      "eventDate": "2025-12-11",
      "publishedAt": "2026-08-22T14:05:59.252Z",
      "title": "Lido proposes a $60 million 2026 ecosystem grant budget",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Ecosystem Grant gRequest: Executing GOOSE-3",
          "authority": "Lido DAO",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0xf263b730f1c64d637ec27227121d7c5bd2189bf456514bad8225e960cf34d7b0",
          "documentType": "Snapshot governance proposal",
          "publishedOn": "2025-12-11"
        }
      ],
      "whatHappened": "Lido DAO received a 2026 Ecosystem Grant gRequest seeking up to $60 million for protocol maintenance, resilience work, growth initiatives, and execution of the GOOSE-3 strategy through three DAO-adjacent foundations.",
      "whatChanged": "If approved, the proposal would authorize a $43.8 million baseline funding plan and a discretionary growth cap of $16.2 million, with later disbursements requested through Easy Track motions to named operational multisigs.",
      "whatDidNotChange": "The candidate does not establish approval, transfer of funds, or execution of any protocol upgrade. Revenue and staking projections are assumptions, not confirmed outcomes.",
      "confirmedFacts": [
        "The proposal requests up to $60 million for 2026.",
        "The request comprises $26.9 million for Core baseline work, $16.9 million for Growth baseline work, and a $16.2 million discretionary cap.",
        "The proposed implementation relies on later Easy Track funding motions.",
        "The candidate names operational multisigs for Lido Labs, Lido Ecosystem, and Lido Alliance foundations."
      ],
      "unresolved": [
        "The Snapshot candidate does not establish the final vote result.",
        "No later Easy Track motions or actual disbursements are included.",
        "Reporting, clawback, milestone, and discretionary-spending controls are not fully specified in the retained text.",
        "The proposal's revenue, staking-growth, and surplus projections remain illustrative."
      ],
      "advisorDiligenceImplications": [
        "Monitor the vote and subsequent Easy Track motions as separate operative events.",
        "Track treasury disbursements and delegated spending authority against the approved envelope rather than treating the proposal total as already spent.",
        "Do not treat projected protocol growth or revenue as evidence that Lido V3 or other planned products are live."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-c09ef19ebc2049faa407a081",
      "stableKey": "stakewise-v3:balancer-v2-recovered-funds-distribution-approval-2025-12",
      "version": 1,
      "eventDate": "2025-12-10",
      "publishedAt": "2026-08-22T14:05:59.252Z",
      "title": "StakeWise approves recovered-funds distribution after Balancer V2 exploit",
      "category": "governance",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "stakewise-v3",
          "name": "StakeWise V3"
        },
        {
          "type": "protocol",
          "id": "balancer-v2",
          "name": "Balancer V2"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Proposal: Approve Distribution Of Recovered Funds To LPs Affected By Balancer V2 Exploit",
          "authority": "StakeWise DAO governance via Snapshot",
          "url": "https://snapshot.org/#/stakewise.eth/proposal/0x9e28b6b05d8252d792c07bcdbb3e828fb1cf3f4c9e3d9df1472aded4afab0095",
          "documentType": "governance_record",
          "publishedOn": "2025-12-05"
        }
      ],
      "whatHappened": "StakeWise governance approved initiating a claim distribution of recovered osETH and osGNO to liquidity providers in Balancer V2 pools affected by the exploit.",
      "whatChanged": "The vote authorized a Merkle Distributor process through the StakeWise interface for eligible affected wallets to claim recovered assets.",
      "whatDidNotChange": "The governance record does not prove that the Merkle root or distributor was deployed, that claims opened or completed, that all losses were recovered, or that osETH backing or StakeWise vault-staker balances were impaired.",
      "confirmedFacts": [
        "The Snapshot vote closed on 2025-12-10 with approximately 4.91 million SWISE Yes votes and zero No votes.",
        "The approved proposal concerns LPs in the osETH-ETH and osGNO-GNO Balancer V2 pools.",
        "The approved distribution method was a Merkle Distributor with claims exposed through the StakeWise interface.",
        "The proposal states that allocation figures were based on LP ownership information supplied by the Balancer team."
      ],
      "unresolved": [
        "The exact osETH and osGNO allocation amounts are not included in the candidate governance record.",
        "The Merkle root, distributor contract, funding transaction, claim-opening date, and completed claim totals are not established by this record.",
        "The amount remaining unrecovered after the Balancer V2 exploit is not established by this record.",
        "Whether any affected Ketju client position held the relevant Balancer LP tokens is unresolved."
      ],
      "advisorDiligenceImplications": [
        "Record the event as Balancer V2 LP loss-recovery evidence affecting StakeWise V3 secondary-liquidity diligence.",
        "Verify distribution execution and claim eligibility before representing recovered assets as available to any affected wallet.",
        "Keep the AMM-pool loss distinct from StakeWise vault-staking risk and osETH backing unless primary evidence establishes transmission to those layers."
      ],
      "followUpOn": "2026-08-27",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-3947f3a8bead4e987129bafe",
      "stableKey": "coinbase-bridge-base-missed-block-delay-2025-12-09",
      "version": 1,
      "eventDate": "2025-12-09",
      "publishedAt": "2026-08-22T14:05:59.252Z",
      "title": "Base recovers from missed-block transaction delays",
      "category": "market_stress",
      "posture": "recovered",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "coinbase-bridge",
          "name": "Base canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Delayed Transactions",
          "authority": "Base",
          "url": "https://status.base.org/incidents/mqlf3z7xkwt1",
          "documentType": "official status incident",
          "publishedOn": "2025-12-12"
        }
      ],
      "whatHappened": "Base experienced a high rate of missed blocks. Transactions submitted during missed blocks were delayed until a subsequent successful block, after which the condition resolved without a reported intervention.",
      "whatChanged": "The incident added a confirmed transaction-inclusion disruption to Base's operating history, followed by recovery and preparation of a mitigation for recurrence.",
      "whatDidNotChange": "The status record does not report a canonical-bridge contract exploit, fund loss, withdrawal pause, state reorganization, or permanent change to bridge mechanics.",
      "confirmedFacts": [
        "Base reported a high rate of missed blocks.",
        "Transactions sent during missed blocks were delayed until the next successful block.",
        "Base reported that the issue resolved itself.",
        "Base said it prepared a mitigation for use if the issue returned."
      ],
      "unresolved": [
        "The status record does not state the root cause or incident duration.",
        "It does not quantify missed blocks, delayed transactions, or affected users.",
        "It does not establish whether any canonical-bridge deposits, proofs, or withdrawal finalizations were delayed."
      ],
      "advisorDiligenceImplications": [
        "Record the event in the Base canonical bridge's chain-liveness history.",
        "Monitor recurrence because bridge use depends on Base transaction inclusion even when bridge contracts remain intact.",
        "No approval restriction is supported by this isolated, recovered incident, but repeated missed-block events would warrant review."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-1be33af7eb73192c92e54244",
      "stableKey": "aave-v3:ethereum-linea:musd-temp-check-2025-08",
      "version": 2,
      "eventDate": "2025-11-30",
      "publishedAt": "2026-08-22T14:05:58.597Z",
      "title": "Aave executes mUSD onboarding on Ethereum Core and Linea",
      "category": "economic_change",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Add MetaMask USD (mUSD) to Aave V3 Ethereum/Linea",
          "authority": "Aave Governance V3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=415",
          "documentType": "official_onchain_governance_record",
          "publishedOn": "2025-11-26"
        }
      ],
      "whatHappened": "Aave Governance V3 executed proposal 415, adding MetaMask USD reserves to the Ethereum Core and Linea instances.",
      "whatChanged": "mUSD became supplyable, borrowable, and flash-loanable on both markets. Ethereum received 10 million and 8 million supply and borrow caps; Linea received 70 million and 60 million caps.",
      "whatDidNotChange": "mUSD was not enabled as collateral on either instance. Execution did not make mUSD a Ketju-approved asset or establish the safety of its issuer, reserves, oracle, redemption, or cross-chain dependencies.",
      "confirmedFacts": [
        "Proposal 415 executed on November 30, 2025.",
        "The Ethereum mUSD reserve has a 10 million supply cap and 8 million borrow cap.",
        "The Linea mUSD reserve has a 70 million supply cap and 60 million borrow cap.",
        "Both reserves have zero LTV and are not collateral-enabled.",
        "Both configurations use capped mUSD/USD oracle paths."
      ],
      "unresolved": [
        "Live utilization, liquidity, redemption performance, holder concentration, and oracle behavior.",
        "The operative issuer, reserve-custody, freeze, upgrade, and M0 cross-chain control map.",
        "Whether any approved or client-held Aave position interacts with either mUSD reserve."
      ],
      "advisorDiligenceImplications": [
        "Supersede the preliminary Aave memo interpretation that mUSD remained only a proposed reserve.",
        "Review the Aave dependency map for Bridge, M0, reserve custody, redemption, oracle, and Linea-specific risks.",
        "Keep mUSD suitability separate from the Aave protocol verdict; execution does not approve mUSD for clients."
      ],
      "followUpOn": null,
      "previousInterpretation": "The August 26 TEMP CHECK placed mUSD onboarding on the research perimeter, but contracts, oracles, caps, collateral status, and execution remained unresolved.",
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-cb1568ea3b7ac16e24b85330",
      "stableKey": "aave-v3:ethereum-core:syrupusdt-onboarding-aip-2025-11",
      "version": 1,
      "eventDate": "2025-11-28",
      "publishedAt": "2026-08-22T14:05:58.597Z",
      "title": "Aave opens final governance for syrupUSDT collateral on Ethereum Core",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Onboard syrupUSDT to Aave V3 Core Instance",
          "authority": "Aave Governance v3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=416",
          "documentType": "onchain_governance_record",
          "publishedOn": "2025-11-28"
        }
      ],
      "whatHappened": "Aave created on-chain Governance proposal 416 to onboard Maple's syrupUSDT as collateral in the Ethereum Core v3 instance and activated its vote the following day.",
      "whatChanged": "The proposed reserve advanced into binding final governance with a 50 million supply cap, borrowing disabled, a capped syrupUSDT-to-USDT-to-USD oracle path, and a correlated-asset E-mode with USDT and GHO.",
      "whatDidNotChange": "As of the November 30 boundary, the vote had not completed and no payload execution or live syrupUSDT reserve was established. Existing Aave collateral, oracle, and liquidation mechanics were unchanged by proposal creation alone.",
      "confirmedFacts": [
        "Aave Governance proposal 416 was created on November 28, 2025, and activated for voting on November 29.",
        "The proposal references Ethereum payload 375.",
        "The proposed configuration enables syrupUSDT as collateral, disables borrowing, sets a 50,000,000-token supply cap, and specifies non-E-mode LTV and liquidation-threshold values of 0.05% and 0.1%.",
        "The proposed correlated-asset E-mode permits syrupUSDT collateral against USDT and GHO with 90% maximum LTV and a 92% liquidation threshold.",
        "The proposed oracle path uses capped syrupUSDT/USDT/USD and capped USDT/USD components, a seven-day minimum snapshot delay, and 8.45% maximum yearly growth."
      ],
      "unresolved": [
        "The vote outcome, queueing, and any execution occurring after November 30 fall outside this historical packet and require a later event review.",
        "Actual secondary liquidity, depositor concentration, Maple credit performance, withdrawal behavior, and oracle performance under stress were not established by the governance record.",
        "The final live reserve configuration must be reconciled on-chain if the payload is executed."
      ],
      "advisorDiligenceImplications": [
        "Monitor proposal 416 and do not treat syrupUSDT as available collateral until execution and live reserve configuration are verified.",
        "Review whether the Aave memo adequately covers Maple underwriting, withdrawal-queue, upgrade, pause, and administrator dependencies introduced by syrupUSDT.",
        "Assess the large difference between the conservative non-E-mode parameters and the proposed 90%/92% correlated E-mode before considering any exposure involving syrupUSDT, USDT, or GHO."
      ],
      "followUpOn": "2025-12-02",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-69ca23ad7a4bcb561b5e1411",
      "stableKey": "aave-v3:avalanche:rseth-onboarding-2025-11",
      "version": 1,
      "eventDate": "2025-11-25",
      "publishedAt": "2026-08-22T14:05:58.597Z",
      "title": "Aave executes wrsETH onboarding on Avalanche",
      "category": "economic_change",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Onboard rsETH to Aave V3 Avalanche Instance",
          "authority": "Aave Governance V3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=414",
          "documentType": "official_onchain_governance_record",
          "publishedOn": "2025-11-21"
        }
      ],
      "whatHappened": "Aave Governance V3 executed proposal 414, adding wrapped rsETH as collateral on the Avalanche instance.",
      "whatChanged": "wrsETH became collateral-enabled with a 5,000-unit supply cap, a capped exchange-rate oracle path, and a wrsETH/WETH E-mode allowing 93% maximum LTV and a 95% liquidation threshold.",
      "whatDidNotChange": "wrsETH was not enabled for ordinary borrowing. Execution did not approve Avalanche, Kelp DAO, LayerZero, wrsETH, or the new E-mode for Ketju clients.",
      "confirmedFacts": [
        "Proposal 414 executed on November 25, 2025.",
        "The wrsETH supply cap is 5,000 units.",
        "Base collateral parameters are 0.05% LTV and a 0.1% liquidation threshold.",
        "The wrsETH/WETH E-mode uses 93% LTV and a 95% liquidation threshold.",
        "The reserve uses a capped wrsETH/ETH/USD oracle path and is not borrowable."
      ],
      "unresolved": [
        "Live wrsETH liquidity, utilization, liquidation performance, and holder concentration on Avalanche.",
        "The continuing security of Kelp, wrapper, LayerZero, multisig, bridger-role, and oracle dependencies.",
        "Whether high E-mode leverage remains liquidatable during bridge, wrapper, or staking-token stress."
      ],
      "advisorDiligenceImplications": [
        "Review the Aave memo for the new cross-chain wrapper, bridge, oracle, and high-leverage E-mode dependencies.",
        "Keep the Avalanche reserve outside any Ethereum-only Aave approval unless separately reviewed.",
        "Monitor live liquidity and liquidation capacity before recognizing the reserve as advisor-accessible exposure."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-2d041fffbb223a4d47ded1dd",
      "stableKey": "lido:curated-module:fee-tiers-2025-11",
      "version": 1,
      "eventDate": "2025-11-24",
      "publishedAt": "2026-08-22T14:05:58.597Z",
      "title": "Lido opens a vote on Curated Module fee tiers",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Curated Module Fee Changes",
          "authority": "Lido Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x3a5d10fcd3fad6d5ccf05f5bd49244046600ad9cbed9a5e07845200b3ae97e09",
          "documentType": "official_governance_proposal",
          "publishedOn": "2025-11-24"
        }
      ],
      "whatHappened": "Lido opened a Snapshot vote on an interim Curated Module fee structure with Standard, Extra Effort, and Client-Team operator tiers.",
      "whatChanged": "A concrete governance path opened to set the module-level operator share to 3.50% and pay qualifying operators an additional 0.50% or 1.00% through manual rebates.",
      "whatDidNotChange": "The proposal would leave Lido's overall 10% protocol fee unchanged. No approval or on-chain implementation occurred within the November event window, and Curated Module v2 remained a future proposal.",
      "confirmedFacts": [
        "The proposed operator tiers are 3.50%, 4.00%, and 4.50%.",
        "Technical limitations in Curated Module v1 would set the module-level operator fee to 3.50%.",
        "Higher-tier amounts would be paid through manual rebate-like operations.",
        "The overall protocol fee would remain 10%.",
        "The Snapshot vote opened on November 24 and extended beyond the November review window."
      ],
      "unresolved": [
        "The vote result and any subsequent Aragon approval or execution.",
        "The final operator classifications, rebate administrator, payment cadence, and verification controls.",
        "The effect on DAO revenue, operator retention, client yield, and operational-error exposure.",
        "The eventual Curated Module v2 fee and automation design."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido memo's fee-allocation and manual-payment control map if the proposal advances.",
        "Verify the final vote, execution, tier assignments, and rebate authority before treating the economics as operative.",
        "Do not infer that lower or differentiated operator fees improve staking safety or decentralization."
      ],
      "followUpOn": "2025-12-02",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-59da0ab00ba311281c48e85d",
      "stableKey": "lido:treasury:susds-tmmf-conversion-2025-11",
      "version": 1,
      "eventDate": "2025-11-24",
      "publishedAt": "2026-08-22T14:05:58.597Z",
      "title": "Lido proposes investing treasury stablecoins in sUSDS and tokenized funds",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Conversion of Treasury Stablecoins into sUSDS or TMMFs",
          "authority": "Lido Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x4dd947f5e73377b074fd393148b377558179f22ea923d584dd3c718f3bab0687",
          "documentType": "official_governance_proposal",
          "publishedOn": "2025-11-24"
        }
      ],
      "whatHappened": "Lido opened a Snapshot vote authorizing its Treasury Management Committee and two Foundations to implement the TMC-6 strategy for approximately $30 million of idle stablecoins.",
      "whatChanged": "The proposal would permit stablecoin withdrawals through existing Easy Track paths, conversion into sUSDS or selected tokenized money-market funds, and custody through Foundation multisigs acting for the DAO.",
      "whatDidNotChange": "No conversion, asset selection, transfer, or custody change was established within November. The proposal did not change stETH staking, withdrawals, validator operations, or the protocol fee.",
      "confirmedFacts": [
        "The proposal described approximately $30 million of idle treasury stablecoins.",
        "Yield-bearing assets would be capped at 15% of total treasury value.",
        "The liquidity floor would require remaining stablecoin liquidity to cover at least two months of operating costs after specified exclusions.",
        "USDS could be converted into sUSDS, while eligible tokenized funds could include products such as BUIDL, Fidelity Digital Treasury Fund, or USYC.",
        "The Snapshot vote extended beyond the November review window."
      ],
      "unresolved": [
        "The vote result and any subsequent on-chain authorization or transfers.",
        "The assets ultimately selected by the Treasury Management Committee.",
        "The final Foundation wallet, signer, custody, KYC, redemption, and concentration arrangements.",
        "The resulting exposure to Sky, fund issuers, custodians, stablecoin liquidity, and legal restrictions."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido governance-resilience memo for the proposed Foundation custody path and delegated asset-selection authority.",
        "Add sUSDS, selected fund issuers, custodians, redemption gates, and liquidity guardrails to diligence if execution occurs.",
        "Verify actual transfers and holdings; governance approval alone would not establish treasury-asset safety."
      ],
      "followUpOn": "2025-12-02",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-53b3ae80be17aca831a1fb24",
      "stableKey": "rocket-pool:saturn1:express-ticket-allocation-rpip75-2025-11",
      "version": 1,
      "eventDate": "2025-11-21",
      "publishedAt": "2026-08-22T14:05:58.597Z",
      "title": "Rocket Pool proposes new Saturn 1 express-ticket allocation",
      "category": "upgrade_migration",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "rocket-pool",
          "name": "Rocket Pool"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Change Express Ticket Allocation for Saturn 1 (RPIP-75)",
          "authority": "Rocket Pool Snapshot",
          "url": "https://snapshot.org/#/rocketpool-dao.eth/proposal/0x4b85eee832dcc7d7ae1ca8b1945ba3365810a8fe943c2fd72defe567a48c7f5c",
          "documentType": "official_governance_proposal",
          "publishedOn": "2025-11-21"
        }
      ],
      "whatHappened": "Rocket Pool opened a vote on RPIP-75 to alter express-ticket issuance and queue priority for migration from legacy minipools to Saturn 1 megapools.",
      "whatChanged": "The proposal would remove the unconditional two-ticket base allocation and match one regular-queue megapool after four express-queue deposits rather than after two.",
      "whatDidNotChange": "No migration rule changed within November. The proposal did not alter rETH's exchange-rate accounting, redemption contract, custody, or validator withdrawal credentials.",
      "confirmedFacts": [
        "The proposed base express-ticket allocation is zero.",
        "Tickets derived from legacy bonded ETH would remain available under the stated formula.",
        "The proposed express priority is four express deposits for each regular-queue deposit.",
        "The Snapshot vote extended into December."
      ],
      "unresolved": [
        "The vote result and implementation transaction.",
        "The final Saturn 1 launch date and migration-state configuration.",
        "The effect on operator migration speed, validator capacity, rETH demand, and redemption liquidity."
      ],
      "advisorDiligenceImplications": [
        "Monitor the final vote and executed Saturn 1 queue configuration.",
        "Update the Rocket Pool operator-migration assumptions if implemented, while keeping client rETH liquidity analysis separate.",
        "The proposal alone does not change the current Rocket Pool memo verdict."
      ],
      "followUpOn": "2025-12-06",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-3d2fe2f6994402257ee87c88",
      "stableKey": "rocket-pool:saturn1:minipool-queue-closure-rpip74-2025-11",
      "version": 1,
      "eventDate": "2025-11-21",
      "publishedAt": "2026-08-22T14:05:58.597Z",
      "title": "Rocket Pool proposes closing the minipool queue before Saturn 1",
      "category": "closure_deprecation",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "rocket-pool",
          "name": "Rocket Pool"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Minipool Queue Closure pre-Saturn 1 Launch (RPIP-74)",
          "authority": "Rocket Pool Snapshot",
          "url": "https://snapshot.org/#/rocketpool-dao.eth/proposal/0x9d51f88c2820462691599abfb573417993c09d2cd5901fde7a8e3d68249ca7bc",
          "documentType": "official_governance_proposal",
          "publishedOn": "2025-11-21"
        }
      ],
      "whatHappened": "Rocket Pool opened a vote on RPIP-74 to stop new entries into the legacy minipool queue before the Saturn 1 megapool launch.",
      "whatChanged": "The proposal created a concrete path to close the irreversible minipool queue by December 8, 2025, or six weeks before Saturn 1, while defining exceptional conditions for reopening.",
      "whatDidNotChange": "The queue remained open during the November event window, and no Saturn 1 launch or closure transaction was established. Existing queued minipools and rETH redemption mechanics were not directly changed by publication.",
      "confirmedFacts": [
        "The proposed closure deadline was December 8, 2025, or six weeks before Saturn 1, whichever applied under the proposal.",
        "The stated objectives included reserving deposit-pool ETH for megapools and reducing pressure on the rETH discount.",
        "The proposal noted that minipool queue entries cannot be exited.",
        "The Snapshot vote extended into December."
      ],
      "unresolved": [
        "The vote result, executed closure time, and any reopening conditions invoked.",
        "The number and value of minipools remaining in the queue at closure.",
        "The final Saturn 1 launch date and effect on rETH redemption liquidity and peg behavior."
      ],
      "advisorDiligenceImplications": [
        "Review Rocket Pool's access, migration, and rETH-liquidity assumptions before the legacy queue closes.",
        "Identify any client or operator workflow dependent on new minipool admission.",
        "Verify the executed queue state and Saturn 1 readiness rather than treating the proposal as an operative closure."
      ],
      "followUpOn": "2025-12-06",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-3d90e6e6f7aca33b8fe71abd",
      "stableKey": "aave-v3:plasma:wsteth-freeze-2025-11",
      "version": 1,
      "eventDate": "2025-11-18",
      "publishedAt": "2026-08-22T14:05:58.597Z",
      "title": "Aave freezes the wstETH reserve on Plasma",
      "category": "closure_deprecation",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Freeze wstETH Plasma",
          "authority": "Aave Governance V3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=410",
          "documentType": "official_onchain_governance_record",
          "publishedOn": "2025-11-14"
        }
      ],
      "whatHappened": "Aave Governance V3 executed proposal 410, freezing the wstETH reserve on Plasma after Lido and Chainlink decided to replace the existing cross-chain representation.",
      "whatChanged": "New wstETH deposits, borrowing, and collateral enablement were disabled on the Plasma Aave market.",
      "whatDidNotChange": "The payload did not freeze the separate wrsETH reserve, alter Lido's Ethereum staking or withdrawal contracts, or establish that existing Plasma wstETH positions had migrated.",
      "confirmedFacts": [
        "Proposal 410 executed on November 18, 2025.",
        "The freeze prevents new deposits, borrows, and collateral enablement for wstETH on Plasma.",
        "The proposal attributed the change to replacement of a wstETH cross-chain deployment that was not considered future-proof.",
        "The proposal reported approximately 0.044 wstETH on Aave Plasma when published."
      ],
      "unresolved": [
        "The migration path and timing for existing Plasma wstETH holders.",
        "The new token contract, CCIP configuration, deployed controls, and Aave re-onboarding path.",
        "Whether any client or approved position used the frozen reserve.",
        "Live exit liquidity and pricing for the deprecated representation."
      ],
      "advisorDiligenceImplications": [
        "Update the Aave memo to treat the Plasma wstETH reserve as unavailable for new exposure.",
        "Review any existing position for exit and migration mechanics without assuming the replacement representation is equivalent or approved.",
        "Reassess the bridge, token, oracle, and freeze-control map before any future re-onboarding."
      ],
      "followUpOn": null,
      "previousInterpretation": "On October 19, Aave executed wstETH and wrsETH onboarding on Plasma, with wstETH enabled as borrowable collateral under a high-efficiency E-mode.",
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-2ab4ca042d66e6e621dff281",
      "stableKey": "aave-v3:low-demand-volatile-assets:ltv-zero-2025-11",
      "version": 1,
      "eventDate": "2025-11-14",
      "publishedAt": "2026-08-22T14:05:58.597Z",
      "title": "Aave executes zero-LTV deprecation for nine volatile assets",
      "category": "closure_deprecation",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Deprecation of Low Demand Volatile Assets on Aave V3 Instances",
          "authority": "Aave Governance V3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=409",
          "documentType": "official_onchain_governance_record",
          "publishedOn": "2025-11-10"
        }
      ],
      "whatHappened": "Aave Governance V3 executed proposal 409, setting the LTV of nine low-demand volatile assets to zero across Ethereum Core, zkSync, BNB, and Metis.",
      "whatChanged": "The affected assets no longer provided additional borrowing capacity under their base reserve configurations, advancing their deprecation.",
      "whatDidNotChange": "The payload did not freeze the reserves, set their liquidation thresholds to zero, or establish that existing positions had been closed.",
      "confirmedFacts": [
        "Proposal 409 executed on November 14, 2025.",
        "Ethereum Core UNI, CRV, BAL, ENS, LDO, and 1INCH had their LTVs set to zero.",
        "ZK on zkSync, CAKE on BNB, and METIS on Metis had their LTVs set to zero.",
        "The proposal was described as the second stage of a broader low-demand-asset deprecation process."
      ],
      "unresolved": [
        "Remaining supplied collateral, debt, and client exposure in each affected reserve.",
        "Subsequent freeze, reserve-factor, cap, or full-offboarding actions.",
        "Exit liquidity and borrower behavior following the zero-LTV change."
      ],
      "advisorDiligenceImplications": [
        "Review any affected Aave collateral position for reduced borrowing capacity and migration needs.",
        "Update collateral-eligibility assumptions in the Aave memo while distinguishing zero LTV from a reserve freeze or immediate liquidation-threshold change.",
        "Monitor subsequent deprecation stages and live exit liquidity."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-1b31e2fe711a2743f00e9d9d",
      "stableKey": "aave-v3:gnosis:cap-reinstatement-2025-11",
      "version": 1,
      "eventDate": "2025-11-10",
      "publishedAt": "2026-08-22T14:05:58.597Z",
      "title": "Aave restores supply and borrow caps on Gnosis",
      "category": "economic_change",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "mixed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Reinstate Supply and Borrow Caps on Aave V3 Gnosis Instance",
          "authority": "Aave Governance V3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=406",
          "documentType": "official_onchain_governance_record",
          "publishedOn": "2025-11-06"
        }
      ],
      "whatHappened": "Aave Governance V3 executed proposal 406, restoring supply and borrow caps across the Gnosis instance after caps had been reduced during the Balancer exploit response and canonical-bridge pause.",
      "whatChanged": "The payload reopened capacity for wstETH, sDAI, GNO, WETH, USDC.e, xDAI, GHO, and EURe under the specified revised caps.",
      "whatDidNotChange": "Execution did not itself prove that the Gnosis canonical bridge had reopened, that cross-market pricing had normalized, or that the Balancer-related recovery was complete.",
      "confirmedFacts": [
        "Proposal 406 executed on November 10, 2025.",
        "The prior precautionary configuration had reduced many supply and borrow caps to one.",
        "The executed payload increased caps for the listed Gnosis reserves.",
        "The stated rationale was anticipated restoration of bridge-mediated arbitrage and price alignment."
      ],
      "unresolved": [
        "The exact canonical-bridge reopening time and operational state at execution.",
        "Whether DEX and oracle prices had fully reconverged before capacity returned.",
        "Live utilization, liquidation performance, and any bad debt following reinstatement.",
        "Whether any approved or client-held exposure used the Gnosis instance."
      ],
      "advisorDiligenceImplications": [
        "Review the Aave Gnosis memo assumptions because capacity was restored based on an expected bridge recovery.",
        "Verify bridge status, cross-market price alignment, reserve caps, and liquidation liquidity independently.",
        "Do not extend any Ethereum-only Aave approval to Gnosis solely because the caps were reinstated."
      ],
      "followUpOn": "2025-11-12",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-0017652494ac836c0d0695aa",
      "stableKey": "optimism-bridge:dab-onchain-controls-mvp:2025-10-31",
      "version": 1,
      "eventDate": "2025-10-31",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Optimism proposes DAB on-chain controls MVP",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "bridge",
          "id": "optimism-bridge",
          "name": "Optimism canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Governor Upgrade Proposal: On-chain Controls MVP",
          "authority": "Optimism Developer Advisory Board",
          "url": "https://snapshot.org/#/developeradvisoryboard.eth/proposal/0x11d922eca8a635317c4a0a68657908c40bc7904f8cc86d412d1175d5234ccbaf",
          "documentType": "official_governance_proposal",
          "publishedOn": "2025-10-31"
        }
      ],
      "whatHappened": "The Optimism Developer Advisory Board opened a vote on an On-chain Controls MVP that would change administration and authorized-proposer roles for the Optimism Governor.",
      "whatChanged": "A concrete governance proposal now defines a possible on-chain control model in which the Security Council holds the Governor admin role and Token House authority becomes enforceable through an authorizedProposer role.",
      "whatDidNotChange": "No approval, veto-period completion, deployment, or execution was established within the October window. The record does not show a present change to canonical-bridge custody, withdrawals, dispute resolution, or deployed bridge contracts.",
      "confirmedFacts": [
        "The official DAB proposal was published on October 31, 2025.",
        "The proposed model assigns the Optimism Governor admin role to the Security Council.",
        "The proposal introduces an on-chain authorizedProposer role.",
        "A passing DAB vote would proceed to a one-week veto period."
      ],
      "unresolved": [
        "The DAB vote result and any veto outcome.",
        "The final deployed contracts, role assignments, and activation date.",
        "Whether and how the controls directly reach canonical-bridge upgrades, dispute operations, or emergency actions."
      ],
      "advisorDiligenceImplications": [
        "Monitor the vote, veto period, deployment, and executed role state before changing the Optimism Bridge control assessment.",
        "If implemented, review the Security Council's scope, proposer constraints, revocation path, and any direct authority over bridge upgrades or dispute controls."
      ],
      "followUpOn": "2025-11-07",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-86c836469549007e5c611af2",
      "stableKey": "aave-v3:base:cbbtc-stablecoin-emode-aip-2025-10",
      "version": 1,
      "eventDate": "2025-10-29",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Aave opens final governance for cbBTC Stablecoin E-Mode on Base",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Addition of cbBTC/Stablecoin E-Mode to Aave V3 Base Instance",
          "authority": "Aave Governance V3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=400",
          "documentType": "onchain_governance_proposal",
          "publishedOn": "2025-10-29"
        },
        {
          "title": "Aave Governance proposal 400 creation transaction",
          "authority": "Ethereum — Aave Governance V3",
          "url": "https://etherscan.io/tx/0xf901bb63161d81ecf9ad72f077b5b0f565178aa640e2800fd33f0c15d03c1936",
          "documentType": "onchain_transaction",
          "publishedOn": "2025-10-29"
        }
      ],
      "whatHappened": "Aave Governance V3 proposal 400 opened final on-chain governance for a cbBTC Stablecoin E-Mode on the Aave V3 Base market.",
      "whatChanged": "The plan advanced to a formal AIP. If executed, cbBTC could collateralize USDC and GHO debt under an 80% maximum LTV, 83% liquidation threshold, and 4% liquidation bonus within the new E-Mode.",
      "whatDidNotChange": "Creation of the proposal did not itself activate the E-Mode. The proposal states that cbBTC's base reserve settings would remain unchanged, and no October execution was established by the reviewed creation event.",
      "confirmedFacts": [
        "Aave Governance V3 proposal 400 was created on October 29, 2025.",
        "The proposed E-Mode uses cbBTC as collateral and makes USDC and GHO borrowable within the category.",
        "The proposed maximum LTV is 80% and the liquidation threshold is 83%.",
        "The proposed liquidation bonus is 4%.",
        "The proposal does not alter cbBTC's base reserve settings."
      ],
      "unresolved": [
        "Any approval and target-chain execution occurring after the October 31 cutoff are outside this decision.",
        "The executed Base configuration and activation time.",
        "The effect on borrower leverage, liquidation volumes, oracle dependence, and realized bad debt under market stress.",
        "Whether any approved or client-held position uses the affected Base cbBTC configuration."
      ],
      "advisorDiligenceImplications": [
        "Review the Aave V3 Base memo's cbBTC liquidation-buffer, oracle, custody, and stablecoin-debt assumptions before treating the proposed E-Mode as acceptable.",
        "Verify the final vote, executed configuration, and affected accounts before recognizing the higher collateral efficiency as operative."
      ],
      "followUpOn": "2025-10-31",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-abb58cc5dec8887fe3c53f1c",
      "stableKey": "aave-v3:gnosis:legacy-usdc-deprecation-aip-2025-10",
      "version": 1,
      "eventDate": "2025-10-28",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Aave opens final governance to deprecate legacy USDC on Gnosis",
      "category": "closure_deprecation",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "USDC (old) deprecation on Gnosis Chain Instance",
          "authority": "Aave Governance V3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=399",
          "documentType": "onchain_governance_proposal",
          "publishedOn": "2025-10-28"
        },
        {
          "title": "Aave Governance proposal 399 creation transaction",
          "authority": "Ethereum — Aave Governance V3",
          "url": "https://etherscan.io/tx/0x0ecea0c744b272e5663b041d2aca92a012b2d3c96bdfc23e53cc8a863c9a9d12",
          "documentType": "onchain_transaction",
          "publishedOn": "2025-10-28"
        }
      ],
      "whatHappened": "Aave Governance V3 proposal 399 opened final on-chain governance to deprecate the legacy USDC reserve on Aave V3 Gnosis.",
      "whatChanged": "The deprecation plan advanced to a formal AIP. If executed, the reserve would be frozen against new deposits, borrowing, and collateral enablement, while its reserve factor would rise from 40% to 80%.",
      "whatDidNotChange": "Creation of the proposal did not itself freeze the reserve. The payload would leave existing positions in place and would not deprecate the canonical USDC.e reserve.",
      "confirmedFacts": [
        "Aave Governance V3 proposal 399 was created on October 28, 2025.",
        "The proposal would freeze the legacy USDC reserve against new deposits, borrowing, and collateral enablement.",
        "The proposed reserve-factor change is from 40% to 80%.",
        "The proposal states that existing positions remain unaffected by the freeze.",
        "The stated objective is migration toward the Circle-supported USDC.e reserve."
      ],
      "unresolved": [
        "Any approval and target-chain execution occurring after the October 31 cutoff are outside this decision.",
        "The executed Gnosis reserve configuration and activation time.",
        "The amount of approved or client-held exposure remaining in legacy USDC.",
        "The practical exit liquidity and yield impact for positions that do not migrate."
      ],
      "advisorDiligenceImplications": [
        "Review any Aave V3 Gnosis legacy-USDC exposure and the memo's eligible-reserve assumptions before the proposed freeze becomes operative.",
        "Verify the final vote, execution, reserve state, and migration liquidity; the proposal does not itself justify treating USDC.e or the broader Gnosis market as approved."
      ],
      "followUpOn": "2025-10-31",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-d9c7464134d38d52cc7954d2",
      "stableKey": "aave-v3:risk-oracle:slope2-automation-arfc-2025-08",
      "version": 2,
      "eventDate": "2025-10-25",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Aave executes Slope2 Risk Oracle activation",
      "category": "control_change",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Slope2 Risk Oracle Activation On Core Ethereum, Linea",
          "authority": "Aave Governance V3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=395",
          "documentType": "official_onchain_governance_record",
          "publishedOn": "2025-10-21"
        }
      ],
      "whatHappened": "Aave governance executed proposal 395, activating automated Slope2 interest-rate updates on specified Ethereum Core and Linea reserves.",
      "whatChanged": "The approved risk-oracle and steward path became operative for Slope2 updates. Covered Ethereum assets include WETH, USDC, USDT, and USDe; covered Linea assets include WETH, USDC, and USDT.",
      "whatDidNotChange": "The automation is restricted to Slope2 for whitelisted assets and did not transfer unrestricted authority over other interest-rate, collateral, liquidation, oracle, pause, or custody parameters.",
      "confirmedFacts": [
        "Proposal 395 reached executed status on October 25.",
        "The execution included an Ethereum payload and a Linea payload.",
        "The activated steward was limited to Slope2 updates for configured assets.",
        "The proposal assigned the required RiskAdmin authority and specified Chainlink Automation for Ethereum and Gelato automation for Linea."
      ],
      "unresolved": [
        "The realized frequency and magnitude of automated Slope2 changes after activation.",
        "Market-by-market performance during prolonged high-utilization stress."
      ],
      "advisorDiligenceImplications": [
        "Supersede the earlier ARFC-stage interpretation with executed status in the Aave memo's control map.",
        "Monitor automated borrow-rate changes and distinguish them from manually governed parameter changes when evaluating liquidity stress."
      ],
      "followUpOn": null,
      "previousInterpretation": "The Slope2 risk-oracle automation had been approved at the ARFC stage but was not yet confirmed operative.",
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-1e7e6adfb99960ad888e68c4",
      "stableKey": "aave-v3:avalanche:usde-susde-onboarding-2025-10",
      "version": 1,
      "eventDate": "2025-10-25",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Aave executes USDe and sUSDe onboarding on Avalanche",
      "category": "economic_change",
      "posture": "executed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Onboard sUSDe and USDe to Aave V3 Avalanche Instance",
          "authority": "Aave Governance V3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=397",
          "documentType": "official_onchain_governance_record",
          "publishedOn": "2025-10-21"
        }
      ],
      "whatHappened": "Aave governance executed proposal 397, onboarding USDe and sUSDe to the Aave V3 Avalanche instance.",
      "whatChanged": "USDe and sUSDe became configured collateral reserves on Avalanche with 50 million-unit supply caps, dedicated capped-oracle paths, and stablecoin E-mode configurations. USDe was enabled for borrowing while sUSDe was not.",
      "whatDidNotChange": "Execution did not expand Ketju's Ethereum-only Aave approval, establish advisor suitability for either asset, or demonstrate sustained liquidity and liquidation performance on Avalanche.",
      "confirmedFacts": [
        "Aave proposal 397 reached executed status on October 25.",
        "The executed proposal configured 50,000,000-unit supply caps for both USDe and sUSDe.",
        "USDe was configured as borrowable; sUSDe was configured as non-borrowable.",
        "Both assets were enabled as collateral and assigned capped-oracle configurations."
      ],
      "unresolved": [
        "Live reserve liquidity, utilization, borrower concentration, and liquidation performance after onboarding.",
        "The assets' suitability for any future chain-specific Ketju approval."
      ],
      "advisorDiligenceImplications": [
        "Add the Avalanche reserves to Aave's cross-chain diligence perimeter and monitor their oracle and liquidation performance.",
        "Do not treat execution as an expansion of the approved Ethereum Aave sleeve."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-5d415eaa51887409c91d0fe3",
      "stableKey": "sky-lending:sparklend-stablecoin-cap-removal-2025-10",
      "version": 1,
      "eventDate": "2025-10-23",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Spark approves removing USDC, USDT, and PYUSD reserve caps",
      "category": "economic_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        },
        {
          "type": "protocol",
          "id": "sparklend",
          "name": "SparkLend"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[Ethereum] SparkLend - Remove Supply and Borrow Caps for Non Collateral Stablecoins (USDC, USDT, PYUSD)",
          "authority": "Spark governance",
          "url": "https://snapshot.org/#/sparkfi.eth/proposal/0xeea0e2648f55df4e57f8717831a5949f2a35852e32aa0f98a7e16e7ed56268a8",
          "documentType": "official_governance_vote",
          "publishedOn": "2025-10-20"
        }
      ],
      "whatHappened": "Spark governance approved removing supply-cap and borrow-cap automation and setting the USDC, USDT, and PYUSD supply and borrow caps to zero on Ethereum SparkLend.",
      "whatChanged": "The approved configuration would remove explicit reserve-level exposure ceilings for the three stablecoins once implemented.",
      "whatDidNotChange": "On-chain execution was not established by the retained record. The three assets remained non-collateral under the proposal, and approval did not reopen Ketju's rejected SparkLend memo.",
      "confirmedFacts": [
        "The official Spark vote concluded with the For option prevailing.",
        "USDC, USDT, and PYUSD were the only reserves covered.",
        "The approved specification sets each reserve's supply cap and borrow cap to zero, meaning no cap.",
        "The proposal states that the assets are not usable as collateral."
      ],
      "unresolved": [
        "The implementation transaction and effective on-chain parameters.",
        "Post-implementation utilization, concentration, available liquidity, and any replacement exposure controls."
      ],
      "advisorDiligenceImplications": [
        "Review the Sky dependency map because uncapped SparkLend reserves can change balance-sheet concentration and liquidity behavior.",
        "Keep SparkLend allocation at zero unless its asset-specific reopen criteria are independently satisfied, including live exit and utilization tests."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-f3ed3741b9b588f1cde05111",
      "stableKey": "sky-lending:sll-relayer-freezer-multisig-change-2025-10",
      "version": 1,
      "eventDate": "2025-10-23",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Spark approves Liquidity Layer relayer and freezer multisig changes",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        },
        {
          "type": "protocol",
          "id": "spark-liquidity-layer",
          "name": "Spark Liquidity Layer"
        }
      ],
      "primaryDocuments": [
        {
          "title": "SAEP-02: Modify Spark Liquidity Layer Core Relayer and Freezer Multisig Configuration",
          "authority": "Spark governance",
          "url": "https://snapshot.org/#/sparkfi.eth/proposal/0xaceea966c8767ae32966f603d30ff9404d68702e5bb67a33234b2f7c46dac0ec",
          "documentType": "official_governance_vote",
          "publishedOn": "2025-10-20"
        }
      ],
      "whatHappened": "Spark governance approved adding Spark Assets Foundation as a co-controller of the Core Operator Relayer multisig and lowering the Freezer multisig threshold.",
      "whatChanged": "The approved Core Operator Relayer configuration becomes 2-of-5 across two Amatsu signers, two Spark Assets Foundation signers, and one Phoenix Labs signer. The approved Freezer configuration becomes 1-of-4, allowing any one listed signer to initiate an emergency freeze.",
      "whatDidNotChange": "The retained record did not establish on-chain implementation, the final deployed signer addresses, or any change to unfreeze procedures. No asset loss or active incident was reported.",
      "confirmedFacts": [
        "The official Spark vote concluded with the For option prevailing.",
        "The Core Operator Relayer threshold was approved at 2-of-5.",
        "The Freezer threshold was approved to fall from 2-of-4 to 1-of-4.",
        "The proposed Freezer roster comprises one Spark Assets Foundation signer, two Phoenix Labs signers, and VoteWizard."
      ],
      "unresolved": [
        "The implementation transaction and final signer addresses.",
        "The resulting per-chain authority state and tested unfreeze path.",
        "Whether the lower freeze threshold produces material false-positive or key-compromise risk."
      ],
      "advisorDiligenceImplications": [
        "Review the Sky and Spark Liquidity Layer control maps because emergency freezing becomes individually exercisable if implemented.",
        "Verify the deployed thresholds and signers chain by chain; the approval does not satisfy the rejected Liquidity Layer memo's disclosure-based reopen criteria."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-7d8fe42790671fe516ef186b",
      "stableKey": "aave-v3:plasma:syrupusdt-onboarding-2025-10",
      "version": 1,
      "eventDate": "2025-10-22",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Aave executes syrupUSDT onboarding on Plasma",
      "category": "economic_change",
      "posture": "executed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Onboard syrupUSDT to Aave V3 Plasma Instance",
          "authority": "Aave Governance V3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=394",
          "documentType": "official_onchain_governance_record",
          "publishedOn": "2025-10-18"
        }
      ],
      "whatHappened": "Aave governance executed proposal 394, onboarding syrupUSDT to the Aave V3 Plasma instance.",
      "whatChanged": "syrupUSDT became configured as non-borrowable collateral with a 150 million-unit supply cap, a capped syrupUSDT-to-USDT oracle path, and a syrupUSDT/USDT0 E-mode configuration.",
      "whatDidNotChange": "Execution did not expand Ketju's Ethereum-only Aave approval, confirm Maple credit quality, or demonstrate exit liquidity and liquidation performance for the new Plasma reserve.",
      "confirmedFacts": [
        "Proposal 394 reached executed status on October 22.",
        "syrupUSDT was enabled as collateral but not as a borrowable reserve.",
        "The configured supply cap was 150,000,000 syrupUSDT.",
        "The base configuration used 0.05% LTV and a 0.1% liquidation threshold, while the specified E-mode used materially higher values."
      ],
      "unresolved": [
        "Live reserve utilization, available liquidity, borrower concentration, and liquidation performance.",
        "The behavior of the capped exchange-rate oracle during Maple or USDT stress."
      ],
      "advisorDiligenceImplications": [
        "Monitor the new reserve as a layered Maple, USDT, oracle, and Plasma dependency.",
        "Do not treat execution as approval for advisor exposure or as an expansion of the existing Aave memo's chain scope."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-83fa94be30e7421b50214de3",
      "stableKey": "lido:bridge-partnership-authority-2025-10",
      "version": 1,
      "eventDate": "2025-10-22",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Lido approves bridge-partnership authority framework",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Empowering Lido Ecosystem Foundation to Lead Bridge-Related Partnerships",
          "authority": "Lido DAO",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0xf842517c2ffba082efac87ec43365e86548adb38e24d1446d850c7d7b979c423",
          "documentType": "official_governance_vote",
          "publishedOn": "2025-10-15"
        }
      ],
      "whatHappened": "Lido tokenholders approved a framework empowering Lido Ecosystem Foundation to lead bridge-related negotiations and agreements involving stETH and wstETH.",
      "whatChanged": "The approved framework delegates partnership execution, establishes a Bridging Security Committee with approval and veto authority, and removes the prior five-day DAO objection period after NEC publication.",
      "whatDidNotChange": "Lido DAO retains authority to cancel, amend, or override agreements. No particular bridge integration, asset deployment, custody change, or cross-chain exposure was approved by this vote alone.",
      "confirmedFacts": [
        "The official Lido vote concluded on October 22 with the For option prevailing.",
        "Lido Ecosystem received authority to negotiate and execute bridge-related agreements.",
        "The Bridging Security Committee must approve technical setups and may veto materially risky partnerships.",
        "The prior five-day DAO objection period was removed from the canonical-bridge recognition flow."
      ],
      "unresolved": [
        "The bridge counterparties, contract deployments, limits, and monitoring arrangements selected under the framework.",
        "How effectively the new committee's veto and escalation processes operate in practice."
      ],
      "advisorDiligenceImplications": [
        "Update the Lido control map for delegated bridge-partnership authority and the shortened objection process.",
        "Underwrite each bridged stETH or wstETH representation separately; the approval does not make cross-chain exposure equivalent to native Ethereum exposure."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-2e26e1ec2f14ec5e74e8dfae",
      "stableKey": "lido:validator-exits-snop-v3-2025-10",
      "version": 1,
      "eventDate": "2025-10-22",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Lido approves Validator Exits SNOP v3",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Proposal for Updating Lido on Ethereum Validator Exits SNOP to v3",
          "authority": "Lido DAO",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x62eb338c6d256d43ee54e2b79e9442b58fcfda4ecdcd817ff6422d564d153e9a",
          "documentType": "official_governance_vote",
          "publishedOn": "2025-10-15"
        }
      ],
      "whatHappened": "Lido tokenholders approved version 3 of the Standard Node Operator Protocol governing validator exits.",
      "whatChanged": "The approved standard incorporates triggerable withdrawals, expands applicability to Simple DVT, Community Staking, and future modules, and clarifies node-operator exit, configuration, responsiveness, and reporting obligations.",
      "whatDidNotChange": "The vote did not itself change the Withdrawal Queue contracts, prove universal operator implementation, or demonstrate stressed-condition exit performance.",
      "confirmedFacts": [
        "The official Lido vote concluded on October 22 with the For option prevailing.",
        "SNOP v3 incorporates triggerable-withdrawal responsibilities.",
        "The standard expands beyond the prior curated-operator context to newer staking modules.",
        "The approved text specifies clearer operator obligations and revised consequences for non-conformance."
      ],
      "unresolved": [
        "Implementation and compliance status across individual node operators and modules.",
        "Observed performance during large, urgent, or congested validator-exit requests."
      ],
      "advisorDiligenceImplications": [
        "Replace SNOP v2 references in Lido diligence with the approved v3 standard.",
        "Continue monitoring operator compliance and withdrawal timing because policy approval does not eliminate execution and queue risk."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-8adda1df8dba6bf6a4b17b8e",
      "stableKey": "coinbase-bridge:base-mainnet-rpc-inclusion-latency:2025-10-20",
      "version": 1,
      "eventDate": "2025-10-20",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Base recovers from elevated RPC and transaction-inclusion latency",
      "category": "market_stress",
      "posture": "recovered",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "coinbase-bridge",
          "name": "Base canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "High RPC latency and transaction inclusion times on Base Mainnet",
          "authority": "Base Status",
          "url": "https://status.base.org/incidents/3h53zgq1hhx5",
          "documentType": "official_status_incident",
          "publishedOn": "2025-10-20"
        }
      ],
      "whatHappened": "Base Mainnet experienced high RPC latency, delayed transaction inclusion, and periodic inconsistencies in block-production timing before performance returned to normal.",
      "whatChanged": "For approximately two hours, transaction submission and state access were less reliable, degrading an operational dependency used by Base canonical-bridge workflows and monitoring.",
      "whatDidNotChange": "Base did not report a bridge exploit, asset loss, invalid state transition, changed withdrawal contract, or permanent finality-policy change.",
      "confirmedFacts": [
        "Base identified the incident at 18:58 UTC on October 20, 2025.",
        "The incident affected Base Mainnet public RPC and block production.",
        "Base reported that block building and RPC performance returned to normal at 21:07 UTC."
      ],
      "unresolved": [
        "Whether any canonical-bridge deposits or withdrawals were materially delayed rather than only exposed to the broader RPC and inclusion degradation.",
        "The root cause and any durable remediation were not stated in the retained status record.",
        "The retained status surface is not treated as a complete historical incident archive."
      ],
      "advisorDiligenceImplications": [
        "Review the Base bridge memo's assumptions for RPC diversity, transaction resubmission, inclusion monitoring, and block-production availability.",
        "Retain alternate-RPC and delayed-inclusion procedures for bridge operations; the recovered incident does not independently require restricting the bridge."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-ef098bc4d45973588a966b92",
      "stableKey": "coinbase-bridge:base-mainnet-aws-capacity:2025-10-20",
      "version": 1,
      "eventDate": "2025-10-20",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Base recovers from AWS-related capacity and batch-submission disruption",
      "category": "market_stress",
      "posture": "recovered",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "coinbase-bridge",
          "name": "Base canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Limited network capacity",
          "authority": "Base Status",
          "url": "https://status.base.org/incidents/yfb0z5876zyp",
          "documentType": "official_status_incident",
          "publishedOn": "2025-10-20"
        }
      ],
      "whatHappened": "An AWS outage affected Base infrastructure, reducing network capacity and interrupting batch submission on Mainnet and Testnet until service recovered.",
      "whatChanged": "Base Mainnet's production capacity and submission of L2 batches to Ethereum were temporarily degraded, exposing cloud-infrastructure availability as a dependency for timely canonical-bridge settlement and monitoring.",
      "whatDidNotChange": "The status record did not report a consensus failure, bridge compromise, asset loss, changed custody, or a permanent change to withdrawal or finality mechanics.",
      "confirmedFacts": [
        "Base began investigating reduced capacity at 08:23 UTC on October 20, 2025.",
        "Base identified a major AWS outage as affecting its infrastructure.",
        "Mainnet batch submission and block production were affected.",
        "Base reported at 09:50 UTC that batch submission resumed and transaction capacity returned to normal."
      ],
      "unresolved": [
        "The number and duration of affected bridge transactions were not disclosed.",
        "The retained record does not describe infrastructure redundancy or post-incident remediation.",
        "The retained status surface is not treated as a complete historical incident archive."
      ],
      "advisorDiligenceImplications": [
        "Review cloud-provider concentration and continuity assumptions in the Base canonical-bridge memo.",
        "Confirm that bridge operating procedures distinguish L2 inclusion from L1 batch submission and monitor both during infrastructure outages."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-09600ef3e3d58ffd01714919",
      "stableKey": "aave-v3:plasma:wsteth-wrseth-onboarding-2025-10",
      "version": 1,
      "eventDate": "2025-10-19",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Aave executes wstETH and wrsETH onboarding on Plasma",
      "category": "economic_change",
      "posture": "executed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Onboard wrsETH to Aave v3 Plasma Instance",
          "authority": "Aave Governance V3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=393",
          "documentType": "official_onchain_governance_record",
          "publishedOn": "2025-10-15"
        }
      ],
      "whatHappened": "Aave governance executed proposal 393, onboarding wstETH and wrsETH to the Aave V3 Plasma instance.",
      "whatChanged": "Both assets became configured collateral reserves with 20,000-unit supply caps and dedicated capped-oracle paths. wstETH was enabled for borrowing; wrsETH was not. Separate E-mode configurations permitted materially higher leverage than the base settings.",
      "whatDidNotChange": "Execution did not change native Lido staking or withdrawal contracts, expand Ketju's Ethereum-only Aave approval, or establish suitability for bridged or multi-wrap collateral on Plasma.",
      "confirmedFacts": [
        "Proposal 393 reached executed status on October 19.",
        "Both wstETH and wrsETH received 20,000-unit supply caps.",
        "wstETH was configured as borrowable; wrsETH was configured as non-borrowable.",
        "The proposal specified 94%/96% wstETH E-mode LTV and liquidation threshold and 93%/95% wrsETH E-mode values."
      ],
      "unresolved": [
        "Live reserve liquidity, utilization, liquidation performance, and bridge or representation risks on Plasma.",
        "Whether the high E-mode settings remain robust during staking-token or chain-specific stress."
      ],
      "advisorDiligenceImplications": [
        "Monitor the Plasma reserves as chain-specific, oracle, and wrapped-staking dependencies of Aave.",
        "Do not treat the new reserves as equivalent to native Ethereum wstETH or as covered by the approved Aave sleeve."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-4630e2fac9b9899f8e0e0498",
      "stableKey": "aave-v3:plasma:pt-usde-pt-susde-2026-01-onboarding",
      "version": 1,
      "eventDate": "2025-10-19",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Aave executes January 2026 USDe principal-token onboarding on Plasma",
      "category": "economic_change",
      "posture": "executed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Onboard sUSDe and USDe January expiry PT tokens on Aave V3 Plasma Instance",
          "authority": "Aave Governance V3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=392",
          "documentType": "official_onchain_governance_record",
          "publishedOn": "2025-10-15"
        }
      ],
      "whatHappened": "Aave governance executed proposal 392, onboarding PT-USDe-15JAN2026 and PT-sUSDe-15JAN2026 to the Aave V3 Plasma instance.",
      "whatChanged": "The fixed-maturity tokens became non-borrowable collateral reserves with 200 million-unit supply caps, linear-discount oracle paths, and risk-oracle-controlled E-mode parameters.",
      "whatDidNotChange": "Execution did not establish post-maturity handling performance, advisor suitability, or inclusion within Ketju's approved Ethereum Aave sleeve.",
      "confirmedFacts": [
        "Proposal 392 reached executed status on October 19.",
        "Both principal tokens mature on January 15, 2026.",
        "Each reserve received a 200,000,000-unit supply cap and was configured as non-borrowable collateral.",
        "The base configuration used 0.05% LTV and a 0.1% liquidation threshold, with higher dynamic E-mode settings."
      ],
      "unresolved": [
        "Liquidity and oracle behavior as maturity approaches and after the tokens mature.",
        "Live utilization, borrower concentration, liquidation performance, and rollover handling."
      ],
      "advisorDiligenceImplications": [
        "Track the reserves through maturity and treat the Pendle, Ethena, oracle, and Plasma layers as separate dependencies.",
        "Do not infer safety or advisor access from execution; the existing Aave approval scope remains unchanged."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-34958087e70649b04174d785",
      "stableKey": "coinbase-bridge:base-mainnet-transaction-inclusion-delay:2025-10-17",
      "version": 1,
      "eventDate": "2025-10-18",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Base recovers from congestion-related transaction-inclusion delays",
      "category": "market_stress",
      "posture": "recovered",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "coinbase-bridge",
          "name": "Base canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Delayed Transaction Inclusion",
          "authority": "Base Status",
          "url": "https://status.base.org/incidents/gvlvywy8dgfj",
          "documentType": "official_status_incident",
          "publishedOn": "2025-10-18"
        }
      ],
      "whatHappened": "Periodic congestion on Base Mainnet delayed transaction inclusion from October 17 into October 18. Base increased mempool size and reported the incident resolved.",
      "whatChanged": "Transactions could remain pending longer during congestion, and Base changed mempool capacity to improve inclusion speed. This temporarily degraded execution reliability for canonical-bridge-related transactions.",
      "whatDidNotChange": "The official record did not report a bridge exploit, asset loss, failed finality, or a change to bridge custody or withdrawal contracts.",
      "confirmedFacts": [
        "Base began reporting periodic congestion and delayed transaction inclusion at 19:27 UTC on October 17, 2025.",
        "The incident affected the Base Mainnet transaction pool.",
        "Base increased mempool size and marked the incident resolved at 03:34 UTC on October 18."
      ],
      "unresolved": [
        "Whether the mempool increase fully addressed recurrence under comparable congestion.",
        "Whether any bridge transaction exceeded an applicable client timing tolerance.",
        "The retained status surface is not treated as a complete historical incident archive."
      ],
      "advisorDiligenceImplications": [
        "Review transaction-expiry, resubmission, and pending-state monitoring procedures for Base bridge activity.",
        "Record congestion and mempool capacity as operational dependencies without treating the resolved event as a permanent bridge restriction."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-c9395c402c6905c3d8bc1f53",
      "stableKey": "coinbase-bridge:base-mainnet-safe-head-delay:2025-10-10",
      "version": 1,
      "eventDate": "2025-10-11",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Base recovers from a transaction-volume-driven safe-head delay",
      "category": "market_stress",
      "posture": "recovered",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "coinbase-bridge",
          "name": "Base canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Safe head delay from high transaction volume",
          "authority": "Base Status",
          "url": "https://status.base.org/incidents/9hvg33kqxb07",
          "documentType": "official_status_incident",
          "publishedOn": "2025-10-11"
        }
      ],
      "whatHappened": "Heavy Base L2 transaction volume delayed batching data to Ethereum and caused the safe head to lag. Base limited calldata included in L2 blocks until safe-head progression recovered.",
      "whatChanged": "Safe-state progression slowed, users could experience delayed inclusion or dropped transactions, and node clients could fall behind. The event temporarily weakened timing assumptions used for Base canonical-bridge settlement and monitoring.",
      "whatDidNotChange": "Unsafe block building continued normally, and Base did not report an invalid finalized state, bridge compromise, asset loss, or permanent finality-policy change.",
      "confirmedFacts": [
        "Base identified heavy transaction volume as delaying batching to Ethereum at 21:40 UTC on October 10, 2025.",
        "The safe head lagged while unsafe block building continued.",
        "Base limited calldata inclusion so the safe head could progress on Ethereum.",
        "Base reported the chain functioning properly and the incident resolved at 00:35 UTC on October 11."
      ],
      "unresolved": [
        "The maximum safe-head lag and any bridge-specific transfer delays were not quantified.",
        "Whether capacity changes were subsequently implemented to reduce recurrence.",
        "The retained status surface is not treated as a complete historical incident archive."
      ],
      "advisorDiligenceImplications": [
        "Review confirmation, safe-head, and L1-batch assumptions used for Base bridge activity.",
        "Ensure bridge monitoring distinguishes unsafe inclusion from safe-state progression and does not treat the recovered event as a confirmed safety failure."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-7c54193e7de96d9a16990737",
      "stableKey": "lido:triggerable-withdrawals:design-approval-2025-07",
      "version": 2,
      "eventDate": "2025-10-02",
      "publishedAt": "2026-08-22T14:05:58.187Z",
      "title": "Lido activates triggerable withdrawals on Ethereum mainnet",
      "category": "control_change",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Lido V2.2 release",
          "authority": "Lido Finance",
          "url": "https://github.com/lidofinance/core/releases/tag/v2.2.0",
          "documentType": "official_software_release",
          "publishedOn": "2025-10-13"
        },
        {
          "title": "Triggerable Withdrawals Framework in the Lido Protocol",
          "authority": "Lido Governance",
          "url": "https://research.lido.fi/t/triggerable-withdrawals-framework-in-the-lido-protocol/10299/1",
          "documentType": "official_governance_record",
          "publishedOn": "2025-07-04"
        }
      ],
      "whatHappened": "Lido executed the governance action that activated its triggerable-withdrawals framework on Ethereum mainnet; the subsequent v2.2.0 release identifies LIP-30 as implemented.",
      "whatChanged": "Lido gained an execution-layer path for initiating validator exits without relying exclusively on a node operator to cooperate, adding permissionless exit enforcement and new validator-exit control components.",
      "whatDidNotChange": "The activation was not a security incident and did not eliminate Lido's ordinary withdrawal process. The available evidence does not establish how the new mechanism will perform during stressed exit conditions.",
      "confirmedFacts": [
        "Lido Vote 192 passed and Dual Governance Proposal 5 was executed on October 2, 2025.",
        "Lido's official governance record states that the triggerable-withdrawals framework became live.",
        "The framework uses execution-layer validator-exit functionality and is intended to reduce reliance on node-operator cooperation.",
        "The official v2.2.0 release identifies LIP-30 as implemented and links two September 2025 security audits."
      ],
      "unresolved": [
        "Final deployed role assignments, GateSeal configuration, and all operative limit parameters were not independently reproduced in this review.",
        "The framework's usage frequency and behavior during severe validator-exit congestion remain untested by the cited records.",
        "Whether subsequent governance actions altered the initial configuration."
      ],
      "advisorDiligenceImplications": [
        "Supersede the design-only interpretation in the Lido memo with an executed control-change posture.",
        "Review validator-exit authority, permissionless enforcement, pause controls, request limits, and dependency behavior under withdrawal stress.",
        "Do not infer from activation or cited audits that the mechanism is safe or appropriate without separate deployed-state verification."
      ],
      "followUpOn": null,
      "previousInterpretation": "Prior history treated the triggerable-withdrawals framework as approved design awaiting on-chain activation.",
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-eb18ccdf4a6d4ab638a38f9a",
      "stableKey": "lido:v3:design-implementation-approval-2025-09",
      "version": 1,
      "eventDate": "2025-09-29",
      "publishedAt": "2026-08-22T14:05:53.241Z",
      "title": "Lido approves the V3 design and implementation proposal",
      "category": "upgrade_migration",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Lido V3 — Design & Implementation Proposal",
          "authority": "Lido DAO via Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x01cd474645cc7c3ddf68314d475d421ef833499297f508fee5f7411fafff3954",
          "documentType": "governance_vote",
          "publishedOn": "2025-09-22"
        }
      ],
      "whatHappened": "Lido tokenholders approved advancing the V3 architecture, including stVaults, phased minting caps, reserve requirements, rate limits, and pause controls.",
      "whatChanged": "The DAO authorized contributors to finalize audits and testing and prepare an on-chain mainnet execution vote for a major new staking-vault architecture.",
      "whatDidNotChange": "V3 was not executed on mainnet by this vote; the existing Core Pool path remained unchanged and available.",
      "confirmedFacts": [
        "The Snapshot vote closed on September 29, 2025 with support and no recorded opposing voting power.",
        "The approved design introduces opt-in stVaults while retaining the existing Core Pool path.",
        "The design proposed phased stVault minting caps and additional reserve, rate-limit, and pause controls.",
        "A separate on-chain vote remained necessary for mainnet execution."
      ],
      "unresolved": [
        "Final audit findings and audit-driven code changes were not yet known.",
        "The final deployment payload, execution date, and live vault parameters remained pending.",
        "The practical cross-impact of stVault slashing or bad debt on stETH holders required further diligence."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido memo's control, slashing, reserve, pause, and withdrawal analysis before any mainnet execution.",
        "Track the eventual on-chain payload and confirm whether Core Pool users inherit any stVault loss or liquidity path.",
        "Do not treat design approval or completed audits as evidence that V3 is safe or operative."
      ],
      "followUpOn": "2025-10-15",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-fa8b98737a92550079833614",
      "stableKey": "lido:stvaults-committee:approval-2025-09",
      "version": 1,
      "eventDate": "2025-09-29",
      "publishedAt": "2026-08-22T14:05:53.241Z",
      "title": "Lido approves the stVaults Committee and delegated parameter authority",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Establish the stVaults Committee",
          "authority": "Lido DAO via Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x0e8b53944051321d2cedf8881b546427bc6a22c9fe16f7d150af62fd837ff7da",
          "documentType": "governance_vote",
          "publishedOn": "2025-09-22"
        }
      ],
      "whatHappened": "Lido approved a 3-of-5 stVaults Committee intended to configure reserve ratios, operator tiers, DAO fees, and certain bad-debt compensation decisions through Easy Track.",
      "whatChanged": "The DAO approved a delegated control body and defined its intended authority over material stVault economic and risk parameters.",
      "whatDidNotChange": "The committee's stVault authority was not yet operative because the V3 system and enabling on-chain actions had not been executed.",
      "confirmedFacts": [
        "The approved committee address was 0x18A1065c81b0Cc356F1b1C843ddd5E14e4AefffF.",
        "The approved signing threshold was 3-of-5.",
        "The mandate included reserve ratios, tier grids, DAO fees, and complex bad-debt compensation decisions.",
        "Proposed committee actions were subject to Easy Track and tokenholder objection."
      ],
      "unresolved": [
        "The final on-chain permissions and Easy Track factories had not yet been executed.",
        "The limits on discretion in complex slashing and bad-debt cases required reconciliation to deployed code.",
        "Committee monitoring, conflict management, and replacement performance remained untested."
      ],
      "advisorDiligenceImplications": [
        "Add the committee multisig and Easy Track objection path to Lido's control map before V3 execution.",
        "Verify that deployed permissions match the approved mandate and cannot bypass DAO review.",
        "Review how committee-directed reserve and bad-debt decisions could affect stETH liquidity or loss allocation."
      ],
      "followUpOn": "2025-10-15",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-d1c7980d603ab57b7abbeb9f",
      "stableKey": "fassets:fxrp-mainnet-launch-2025-09-24",
      "version": 1,
      "eventDate": "2025-09-24",
      "publishedAt": "2026-08-22T14:05:53.241Z",
      "title": "Flare launches FAssets on mainnet with FXRP",
      "category": "launch_access",
      "posture": "launched",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "fassets",
          "name": "FAssets (Flare Network)"
        }
      ],
      "primaryDocuments": [
        {
          "title": "FAssets are Live: XRP Meets DeFi on Flare",
          "authority": "Flare Network",
          "url": "https://flare.network/news/fassets-fxrp-is-live-on-mainnet",
          "documentType": "official_launch_notice",
          "publishedOn": "2025-09-24"
        }
      ],
      "whatHappened": "Flare launched FAssets on mainnet with FXRP v1.2, allowing XRP to be represented and used across Flare DeFi.",
      "whatChanged": "The FAssets design moved from development into live operation for one supported underlying asset, FXRP.",
      "whatDidNotChange": "The notice did not establish that FBTC, DOGE, LTC, or a diversified set of FAssets was live, and launch did not establish suitability or approval.",
      "confirmedFacts": [
        "FAssets went live on Flare mainnet on September 24, 2025.",
        "The initial live FAsset was FXRP v1.2.",
        "The official notice described minting FXRP from XRP for use in Flare DeFi."
      ],
      "unresolved": [
        "The launch notice did not by itself reconcile all agent, collateral, Core Vault, pause, multisig, redemption, and liquidation controls.",
        "The production status of FAssets other than FXRP remained unconfirmed."
      ],
      "advisorDiligenceImplications": [
        "Create or update the fassets diligence file and scope it honestly to the live FXRP product.",
        "Review the agent collateral model, Data Connector verification, Core Vault custody, pause authority, and stressed redemption path.",
        "Do not infer that the broader FAssets name represents multiple live underlying assets."
      ],
      "followUpOn": "2025-10-24",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-b494550703eb7ccc2813e8d0",
      "stableKey": "aave-v3:plasma:v3.5-activation-2025-09",
      "version": 1,
      "eventDate": "2025-09-22",
      "publishedAt": "2026-08-22T14:05:53.241Z",
      "title": "Aave executes the V3.5 Plasma market activation",
      "category": "launch_access",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Aave V3.5 Plasma Activation",
          "authority": "Aave Governance v3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=379",
          "documentType": "onchain_governance_record",
          "publishedOn": "2025-09-18"
        }
      ],
      "whatHappened": "Aave governance executed the initial Plasma V3.5 market activation and configured USDT0, USDe, sUSDe, XAUt0, weETH, and WETH reserves with bootstrap controls and caps.",
      "whatChanged": "A new Aave deployment became operative on Plasma, expanding the protocol's chain, collateral, oracle, guardian, and cross-chain governance perimeter.",
      "whatDidNotChange": "XPL was not included in the initial activation, and the launch did not make the Plasma market or its assets approved for Ketju clients.",
      "confirmedFacts": [
        "Aave governance proposal 379 executed on September 22, 2025.",
        "The execution sent payload 1 to Plasma chain 9745.",
        "The activation included USDT0, USDe, sUSDe, XAUt0, weETH, and WETH.",
        "The proposal assigned bootstrap administrative roles and authorized later increases to pre-approved cap ceilings."
      ],
      "unresolved": [
        "The timing and amount of any later guardian cap increases required separate on-chain verification.",
        "Production oracle, bridge, liquidity, liquidation, and withdrawal performance remained untested at launch.",
        "XPL onboarding remained separate and pending."
      ],
      "advisorDiligenceImplications": [
        "Open a distinct Plasma deployment review rather than extending approval from another Aave chain.",
        "Reconcile every reserve, oracle, cap, guardian, bridge, and payload-controller dependency before considering access.",
        "Monitor whether bootstrap authorities increased caps and whether those changes stayed within the approved ceilings."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-13de99f340121d6b4d58cd17",
      "stableKey": "aave-v3:x-layer:temp-check-approval-2025-09",
      "version": 1,
      "eventDate": "2025-09-21",
      "publishedAt": "2026-08-22T14:05:53.241Z",
      "title": "Aave advances the proposed X Layer deployment to ARFC review",
      "category": "governance",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[TEMP CHECK] Deploy Aave v3 on X Layer",
          "authority": "Aave DAO via Snapshot",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0xdcf5f6a05adafd1f06b1576e5aeb6b8ab4ac77428998bef2f6f0c107dfe2ad57",
          "documentType": "governance_vote",
          "publishedOn": "2025-09-17"
        }
      ],
      "whatHappened": "Aave tokenholders approved a temperature check to continue evaluating an Aave v3 deployment on X Layer.",
      "whatChanged": "The deployment concept advanced into the formal ARFC diligence stage, adding X Layer to Aave's active research perimeter.",
      "whatDidNotChange": "No Aave contracts were deployed, no market was activated, and no assets or risk parameters were approved by this vote.",
      "confirmedFacts": [
        "The official Aave Snapshot vote closed on September 21, 2025.",
        "The proposal received overwhelming support with only minimal opposing voting power.",
        "The approved next step was ARFC review, followed by later governance stages if supported."
      ],
      "unresolved": [
        "X Layer's final architecture, launch status, bridge and oracle dependencies, market assets, parameters, and administrative controls were not specified.",
        "No final deployment payload or execution date existed at this stage."
      ],
      "advisorDiligenceImplications": [
        "Monitor the ARFC stage for a complete chain, bridge, oracle, guardian, and asset-control assessment.",
        "Do not extend existing Aave approval to X Layer without a chain-specific memo review.",
        "Treat the vote as research-perimeter expansion, not evidence of a live or approved client venue."
      ],
      "followUpOn": "2025-10-15",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-6be900241b3eb0dc814aaa42",
      "stableKey": "aave-v3:ethereum-core:pt-susde-usde-nov2025-cap-increase",
      "version": 1,
      "eventDate": "2025-09-17",
      "publishedAt": "2026-08-22T14:05:53.241Z",
      "title": "Aave executes billion-dollar November PT supply-cap increases",
      "category": "economic_change",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Raise sUSDe and USDe November expiry PT token caps on Aave V3 Core Instance",
          "authority": "Aave Governance v3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=376",
          "documentType": "onchain_governance_record",
          "publishedOn": "2025-09-13"
        }
      ],
      "whatHappened": "Aave governance executed increases to the Ethereum Core supply caps for PT-sUSDe-27NOV2025 and PT-USDe-27NOV2025.",
      "whatChanged": "The PT-sUSDe November cap increased to $1.2 billion and the PT-USDe November cap increased to $1 billion, materially expanding permitted exposure to dated Pendle principal tokens.",
      "whatDidNotChange": "The payload did not onboard new token contracts, change their maturity dates, or establish that the higher caps would be fully utilized.",
      "confirmedFacts": [
        "Aave governance proposal 376 executed on September 17, 2025.",
        "The execution sent payload 341 to Ethereum.",
        "The approved PT-sUSDe-27NOV2025 supply cap was $1.2 billion.",
        "The approved PT-USDe-27NOV2025 supply cap was $1 billion."
      ],
      "unresolved": [
        "Actual utilization after execution and the concentration of rollover deposits required monitoring.",
        "The event record did not establish stressed liquidity at maturity or the exit capacity of the underlying Pendle markets."
      ],
      "advisorDiligenceImplications": [
        "Review the Aave memo's exposure to dated, wrapped principal tokens and maturity-driven liquidity concentration.",
        "Confirm whether any approved or client-held Aave market inherited these collateral paths.",
        "Monitor cap utilization, oracle behavior, and exit liquidity approaching the November maturity."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-87f417cb8d9c683fac57617e",
      "stableKey": "aave-v3:scroll:reserve-factor-50pct-2025-09",
      "version": 1,
      "eventDate": "2025-09-16",
      "publishedAt": "2026-08-22T14:05:53.241Z",
      "title": "Aave executes 50% reserve factors across its Scroll market",
      "category": "economic_change",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Risk Parameter Adjustments for Aave V3 Scroll Instance",
          "authority": "Aave Governance v3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=374",
          "documentType": "onchain_governance_record",
          "publishedOn": "2025-09-12"
        }
      ],
      "whatHappened": "Aave governance executed a 50% reserve factor for WETH, weETH, wstETH, USDC, and SCR on the Scroll instance in response to reported Scroll governance instability.",
      "whatChanged": "A larger share of borrower interest began accruing to protocol reserves rather than suppliers across all listed Scroll assets.",
      "whatDidNotChange": "This payload did not itself change supply caps, borrow caps, collateral factors, liquidation thresholds, or the Scroll chain's governance.",
      "confirmedFacts": [
        "Aave governance proposal 374 executed on September 16, 2025.",
        "The execution sent payload 46 to Scroll.",
        "The reserve factor became 50% for WETH, weETH, wstETH, USDC, and SCR."
      ],
      "unresolved": [
        "Separate risk-steward changes referenced by the proposal were not established by this payload record.",
        "The duration of the conservative settings and the resolution of the cited Scroll governance instability remained open."
      ],
      "advisorDiligenceImplications": [
        "Review supplier-yield assumptions for any Aave Scroll exposure.",
        "Keep the Scroll deployment distinct from approved Aave markets on other chains.",
        "Track separate cap changes and any later reversal of the 50% reserve factors."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-ad56de27d69b96909eafb80d",
      "stableKey": "aave-v3:linea:rseth-supply-cap-70000-2025-09",
      "version": 1,
      "eventDate": "2025-09-15",
      "publishedAt": "2026-08-22T14:05:53.241Z",
      "title": "Aave raises the Linea wrsETH supply cap to 70,000",
      "category": "economic_change",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Increase rsETH Supply Cap on Aave V3 Linea Instance",
          "authority": "Aave Governance v3",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=372",
          "documentType": "onchain_governance_record",
          "publishedOn": "2025-09-11"
        }
      ],
      "whatHappened": "Aave governance executed an increase in the Linea wrsETH supply cap from 6,400 to 70,000.",
      "whatChanged": "The maximum permitted wrsETH supply on the Linea Aave market increased by more than tenfold, materially expanding the market's possible liquid-restaking exposure.",
      "whatDidNotChange": "The payload did not change wrsETH's oracle, liquidation thresholds, loan-to-value setting, borrowability, or underlying bridge and wrapping dependencies.",
      "confirmedFacts": [
        "Aave governance proposal 372 executed on September 15, 2025.",
        "The execution sent payload 13 to Linea.",
        "The wrsETH supply cap increased from 6,400 to 70,000."
      ],
      "unresolved": [
        "Actual cap utilization and market liquidity after execution required monitoring.",
        "The event record did not establish stressed exit liquidity for wrsETH or its underlying restaking and bridge dependencies."
      ],
      "advisorDiligenceImplications": [
        "Review the Aave memo's Linea-specific liquid-restaking and wrap-depth exposure.",
        "Confirm whether any approved or client-held market could inherit losses from the expanded wrsETH collateral path.",
        "Monitor cap utilization, oracle deviations, liquidation liquidity, and bridge dependencies."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-b538659b35f10e3ec2dc5c53",
      "stableKey": "ondo-global-markets:ethereum:launch-2025-09-03",
      "version": 1,
      "eventDate": "2025-09-03",
      "publishedAt": "2026-08-22T14:05:53.241Z",
      "title": "Ondo launches more than 100 tokenized U.S. securities on Ethereum",
      "category": "launch_access",
      "posture": "launched",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "product",
          "id": "ondo-global-markets",
          "name": "Ondo Global Markets (Ondo Stocks)"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Ondo Stocks is Now Live: The Dawn of Wall Street 2.0",
          "authority": "Ondo Finance",
          "url": "https://ondo.finance/blog/global-markets-is-live",
          "documentType": "official_launch_notice",
          "publishedOn": "2025-09-03"
        }
      ],
      "whatHappened": "Ondo launched tokenized total-return exposure to more than 100 U.S. stocks and ETFs on Ethereum, with minting and redemption tied to underlying-market liquidity.",
      "whatChanged": "A large, transferable tokenized-securities product became live and usable in DeFi, creating a new tokenized-RWA diligence object.",
      "whatDidNotChange": "The launch did not make the product available to U.S. persons, and the tokens did not confer direct ownership of the referenced stocks or ETFs.",
      "confirmedFacts": [
        "The product launched on Ethereum on September 3, 2025.",
        "Ondo described more than 100 tokenized stocks and ETFs as live.",
        "The official notice limited access to eligible non-U.S. investors.",
        "The tokens track total returns and are not themselves stocks or ETFs."
      ],
      "unresolved": [
        "The launch notice alone did not resolve issuer-discretion, transfer-control, insolvency, or U.S.-advisor implementation questions.",
        "Independent reserve attestations and stressed redemption performance remained to be evaluated."
      ],
      "advisorDiligenceImplications": [
        "Open or update the ondo-global-markets diligence file because the launch materially expanded the tokenized-equities perimeter.",
        "Preserve the U.S.-person exclusion as a binding access constraint rather than treating on-chain transferability as client eligibility.",
        "Review the derivative claim, custody chain, transfer controls, attestations, and redemption mechanics before any approval consideration."
      ],
      "followUpOn": "2025-10-03",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-481c1216c8e2f804f6559c75",
      "stableKey": "aave-v3:ethereum-core:pt-susde-27nov2025-onboarding",
      "version": 1,
      "eventDate": "2025-08-30",
      "publishedAt": "2026-08-22T14:05:43.901Z",
      "title": "Aave opens final governance for November PT-sUSDe collateral",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[Direct to AIP] Onboard sUSDe November expiry PT tokens on Aave V3 Core Instance",
          "authority": "Aave DAO",
          "url": "https://governance.aave.com/t/direct-to-aip-onboard-susde-november-expiry-pt-tokens-on-aave-v3-core-instance/22894",
          "documentType": "official_governance_forum",
          "publishedOn": "2025-08-12"
        },
        {
          "title": "Proposal 365",
          "authority": "Aave Governance",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=365",
          "documentType": "onchain_governance_record",
          "publishedOn": "2025-08-30"
        }
      ],
      "whatHappened": "Aave advanced PT-sUSDe-27NOV2025 to an on-chain governance proposal for the Ethereum Core instance.",
      "whatChanged": "If executed, the proposal would add the dated PT as collateral with a 75 million supply cap, stablecoin and USDe e-modes, and LTV, liquidation-threshold, and bonus values managed by a risk oracle.",
      "whatDidNotChange": "The proposal record alone does not establish execution. Existing collateral parameters were not shown to have changed on August 30.",
      "confirmedFacts": [
        "The official forum identifies PT-sUSDe-27NOV2025 as the proposed collateral asset.",
        "The proposed non-e-mode LTV and liquidation threshold are 0.05% and 0.1%.",
        "The proposal defines stablecoin and USDe e-modes whose collateral parameters are subject to the Edge Risk Oracle.",
        "The candidate links the proposal to Aave Governance proposal 365."
      ],
      "unresolved": [
        "Final vote outcome and execution timing were not established from an operative receipt reviewed for this candidate.",
        "Actual post-execution caps, oracle state, and e-mode membership require on-chain confirmation."
      ],
      "advisorDiligenceImplications": [
        "Monitor whether the dated PT becomes live collateral and verify the final oracle constraints before treating the market as available.",
        "Review the Aave memo's exposure to Ethena, Pendle maturity rollover, and automated collateral-parameter authority.",
        "Do not infer approval of PT-sUSDe exposure from the existence of the governance proposal."
      ],
      "followUpOn": "2025-09-05",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-1008b6f0033a94870907db4a",
      "stableKey": "aave-v3:risk-oracle:slope2-automation-arfc-2025-08",
      "version": 1,
      "eventDate": "2025-08-29",
      "publishedAt": "2026-08-22T14:05:43.901Z",
      "title": "Aave approves Slope2 risk-oracle automation at the ARFC stage",
      "category": "control_change",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Automation of the Slope2 Parameter via Risk Oracles",
          "authority": "Aave DAO",
          "url": "https://governance.aave.com/t/arfc-automation-of-the-slope2-parameter-via-risk-oracles/22919",
          "documentType": "official_governance_forum",
          "publishedOn": "2025-08-13"
        }
      ],
      "whatHappened": "The Aave ARFC vote approved advancing a mechanism that would automate post-kink Slope2 interest-rate adjustments through risk oracles.",
      "whatChanged": "The proposal advanced from discussion to ARFC approval, moving Aave toward delegated, bounded automation of a parameter that controls borrower costs during high utilization.",
      "whatDidNotChange": "ARFC approval did not itself deploy the oracle or change any reserve's live interest-rate strategy; a final AIP and execution were still required.",
      "confirmedFacts": [
        "The official proposal describes a time-aware, bounded Slope2 response to persistent utilization stress.",
        "The ARFC vote ran from August 26 through August 29, 2025.",
        "Aave reported quorum, a winning YAE result, and 861.4 thousand votes.",
        "The stated next step was an AIP for final confirmation and enforcement."
      ],
      "unresolved": [
        "Final AIP scope, covered reserves, oracle administrators, constraints, pause controls, and execution timing were not yet established.",
        "No operative on-chain configuration change was confirmed for August 29."
      ],
      "advisorDiligenceImplications": [
        "Review how delegated Slope2 automation would change borrowing-cost and liquidity-stress assumptions in the Aave memo.",
        "Require final constraint, administrator, pause, and failure-mode documentation before treating the mechanism as operative.",
        "Monitor for the final AIP and reserve-specific deployment evidence."
      ],
      "followUpOn": "2025-09-05",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": false
    },
    {
      "id": "event-event-draft-e8e597a8e8a5b81f830c12dd",
      "stableKey": "aave-v3:ethereum-linea:musd-temp-check-2025-08",
      "version": 1,
      "eventDate": "2025-08-26",
      "publishedAt": "2026-08-22T14:05:43.901Z",
      "title": "Aave considers mUSD for Ethereum Core and Linea",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[TEMP CHECK] Add MetaMask USD (mUSD) to Aave v3 Core Instance on Ethereum and Linea",
          "authority": "Aave DAO",
          "url": "https://governance.aave.com/t/temp-check-add-metamask-usd-musd-to-aave-v3-core-instance-on-ethereum-and-linea/22990",
          "documentType": "official_governance_forum",
          "publishedOn": "2025-08-21"
        }
      ],
      "whatHappened": "Aave opened a TEMP CHECK on adding MetaMask USD to the Ethereum Core and Linea v3 instances.",
      "whatChanged": "The research perimeter expanded to a proposed reserve-backed stablecoin integration across two Aave markets.",
      "whatDidNotChange": "No Aave reserve was added, and the publication did not yet provide contract addresses, oracle configuration, caps, collateral status, or liquidation parameters.",
      "confirmedFacts": [
        "The proposal targets Aave v3 Ethereum Core and Linea.",
        "The official post states that contract addresses and risk parameters were still pending.",
        "The TEMP CHECK precedes ARFC and final AIP stages."
      ],
      "unresolved": [
        "TEMP CHECK outcome was not confirmed in the reviewed primary record.",
        "Issuer, reserve, freeze, upgrade, oracle, redemption, and final market parameters remained unresolved at this stage."
      ],
      "advisorDiligenceImplications": [
        "Monitor the proposal but do not treat mUSD as an approved Aave reserve.",
        "Require issuer, reserve, redemption, freeze, oracle, and liquidity diligence before any memo expansion.",
        "Confirm whether collateral would be enabled and whether Ethereum and Linea configurations differ."
      ],
      "followUpOn": "2025-09-02",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": false
    },
    {
      "id": "event-event-draft-55ec3494783f10accf544836",
      "stableKey": "aave-v3:base:tbtc-onboarding-arfc-2025-08",
      "version": 1,
      "eventDate": "2025-08-25",
      "publishedAt": "2026-08-22T14:05:43.901Z",
      "title": "Aave approves tBTC-on-Base onboarding at the ARFC stage",
      "category": "governance",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Onboard tBTC to Aave v3 on Base",
          "authority": "Aave DAO",
          "url": "https://governance.aave.com/t/arfc-onboard-tbtc-to-aave-v3-on-base/22226",
          "documentType": "official_governance_forum",
          "publishedOn": "2025-05-30"
        }
      ],
      "whatHappened": "Aave's ARFC vote approved advancing tBTC onboarding for the Base v3 instance.",
      "whatChanged": "The proposal advanced to final AIP preparation with recommended collateral, borrowing, cap, liquidation, and BTC/USD oracle settings.",
      "whatDidNotChange": "ARFC approval did not add the reserve or make tBTC available on Aave Base; final AIP approval and execution remained necessary.",
      "confirmedFacts": [
        "The ARFC passed on August 25, 2025, with quorum and YAE as the winning option.",
        "The proposed Base tBTC contract is 0x236aa50979D5f3De3Bd1Eeb40E81137F22ab794b.",
        "Recommended parameters include a 130 tBTC supply cap, 13 tBTC borrow cap, 73% LTV, and 78% liquidation threshold.",
        "The next stated step was publication of an AIP."
      ],
      "unresolved": [
        "Final AIP result and execution were not established for this event.",
        "Final oracle configuration and live reserve parameters require post-execution reconciliation."
      ],
      "advisorDiligenceImplications": [
        "Monitor the final AIP and verify live parameters before considering tBTC-on-Base exposure.",
        "Review Threshold minting, Wormhole-related Base components, secondary liquidity, and BTC/USD pricing dependencies.",
        "Do not infer that ARFC approval constitutes product approval for clients."
      ],
      "followUpOn": "2025-09-01",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-7a6b777959dcc6edec0edf6d",
      "stableKey": "aave-v3:ethereum-core:xaut-onboarding-arfc-2025-08",
      "version": 1,
      "eventDate": "2025-08-25",
      "publishedAt": "2026-08-22T14:05:43.901Z",
      "title": "Aave approves XAUt collateral onboarding at the ARFC stage",
      "category": "governance",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Add XAUt to Aave v3 Core Instance",
          "authority": "Aave DAO",
          "url": "https://governance.aave.com/t/arfc-add-xaut-to-aave-v3-core-instance/22385",
          "documentType": "official_governance_forum",
          "publishedOn": "2025-06-19"
        }
      ],
      "whatHappened": "Aave's ARFC vote approved advancing XAUt onboarding for the Ethereum Core instance.",
      "whatChanged": "The proposal advanced to final AIP preparation with XAUt as isolated, non-borrowable collateral, a 5,000-token supply cap, and a $3 million debt ceiling.",
      "whatDidNotChange": "ARFC approval did not add XAUt to the live market. Final AIP approval, execution, and live oracle configuration remained outstanding.",
      "confirmedFacts": [
        "The ARFC passed on August 25, 2025, with quorum and YAE as the winning option.",
        "Published parameters include 70% LTV, 75% liquidation threshold, and a 6% liquidation penalty.",
        "The proposal uses isolation mode and a $3 million debt ceiling.",
        "The stated next step was publication of an AIP."
      ],
      "unresolved": [
        "Final AIP result, execution date, and live configuration were not established.",
        "Weekend gold-price behavior, issuer controls, reserve evidence, redemption eligibility, and concentrated liquidity remain material diligence issues."
      ],
      "advisorDiligenceImplications": [
        "Monitor the final AIP and verify the oracle and isolation settings before treating the reserve as live.",
        "Review the Aave memo for tokenized-gold issuer, vault, blacklist, redemption, and weekend-pricing dependencies.",
        "Do not infer client suitability or approval from ARFC passage."
      ],
      "followUpOn": "2025-09-01",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-c1b1464981ac19b615672873",
      "stableKey": "aave-v3:arbitrum:tbtc-onboarding-aip-2025-08",
      "version": 1,
      "eventDate": "2025-08-20",
      "publishedAt": "2026-08-22T14:05:43.901Z",
      "title": "Aave opens final governance for tBTC collateral on Arbitrum",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Onboard tBTC to Aave v3 on Arbitrum",
          "authority": "Aave DAO",
          "url": "https://governance.aave.com/t/arfc-onboard-tbtc-to-aave-v3-on-arbitrum/19756",
          "documentType": "official_governance_forum",
          "publishedOn": "2024-11-11"
        },
        {
          "title": "Proposal 360",
          "authority": "Aave Governance",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=360",
          "documentType": "onchain_governance_record",
          "publishedOn": "2025-08-20"
        }
      ],
      "whatHappened": "Aave opened an on-chain proposal to add tBTC as collateral on its Arbitrum v3 instance.",
      "whatChanged": "If executed, tBTC would become non-borrowable collateral with a 50 tBTC supply cap, 73% LTV, 78% liquidation threshold, and Chainlink BTC/USD pricing.",
      "whatDidNotChange": "The proposal record does not by itself confirm execution or establish that tBTC was available as collateral on August 20.",
      "confirmedFacts": [
        "The proposed Arbitrum tBTC contract is 0x6c84a8f1c29108f47a79964b5fe888d4f4d0de40.",
        "The proposed supply cap is 50 tBTC and the borrow cap is 25, while borrowing is described as disabled in the operative configuration.",
        "The proposed LTV and liquidation threshold are 73% and 78%.",
        "The candidate links Aave Governance proposal 360."
      ],
      "unresolved": [
        "Final vote result and execution timing require operative on-chain confirmation.",
        "The final live reserve configuration and oracle address must be reconciled after execution."
      ],
      "advisorDiligenceImplications": [
        "Monitor final execution before treating tBTC on Arbitrum as an available Aave collateral market.",
        "Review wrapped-Bitcoin minting, bridge, oracle, liquidity, and liquidation dependencies introduced by the listing.",
        "Confirm that the final borrow-enabled flag and borrow cap are internally consistent."
      ],
      "followUpOn": "2025-08-27",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-329c9a6314d58f1752bef38f",
      "stableKey": "aave-v3:linea:rseth-onboarding-aip-2025-08",
      "version": 1,
      "eventDate": "2025-08-19",
      "publishedAt": "2026-08-22T14:05:43.901Z",
      "title": "Aave opens final governance for wrsETH collateral on Linea",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[Direct to AIP] Onboard rsETH to Aave V3 Linea Instance",
          "authority": "Aave DAO",
          "url": "https://governance.aave.com/t/direct-to-aip-onboard-rseth-to-aave-v3-linea-instance/22172",
          "documentType": "official_governance_forum",
          "publishedOn": "2025-05-26"
        },
        {
          "title": "Onboard rsETH to Aave V3 Linea Instance — Proposal 358",
          "authority": "Aave Governance",
          "url": "https://vote.onaave.com/proposal/?ipfsHash=0xe2d5e82594c356931465f14b6d7110e1a0b38a0536090f21312b73243139bd49&proposalId=358",
          "documentType": "onchain_governance_record",
          "publishedOn": "2025-08-19"
        }
      ],
      "whatHappened": "Aave opened on-chain governance to add wrsETH collateral to its Linea v3 instance.",
      "whatChanged": "If executed, wrsETH would become non-borrowable collateral with a 400-token supply cap, 70% LTV, 73% liquidation threshold, a correlated WETH e-mode, and a capped exchange-rate oracle.",
      "whatDidNotChange": "The reviewed evidence does not establish execution or a live reserve as of August 19.",
      "confirmedFacts": [
        "The proposed asset is wrapped rsETH on Linea.",
        "The proposal sets a 400 wrsETH supply cap and disables borrowing.",
        "The proposed base LTV and liquidation threshold are 70% and 73%.",
        "The proposed oracle combines a wrsETH/rsETH ratio provider with an ETH/USD feed and CAPO constraints."
      ],
      "unresolved": [
        "Final vote outcome and execution timing require on-chain confirmation.",
        "The official forum identified limited Linea liquidity and bridge, pricing, and multisig dependencies that require ongoing review."
      ],
      "advisorDiligenceImplications": [
        "Do not treat wrsETH on Linea as available until execution and live configuration are verified.",
        "Review the additional LayerZero bridge, wrapper ownership, exchange-rate feed, and Linea liquidity dependencies.",
        "Check whether the final e-mode and supply cap remain consistent with the published risk analysis."
      ],
      "followUpOn": "2025-08-26",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-e703d642822c121b234b426e",
      "stableKey": "aave-v3:ethereum-core:pt-tusde-dec2025-temp-check",
      "version": 1,
      "eventDate": "2025-08-18",
      "publishedAt": "2026-08-22T14:05:43.901Z",
      "title": "Aave advances December PT-tUSDe onboarding to ARFC review",
      "category": "governance",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[TEMP CHECK] Onboard tUSDe December expiry PT tokens on Aave V3 Core Instance",
          "authority": "Aave DAO",
          "url": "https://governance.aave.com/t/temp-check-onboard-tusde-december-expiry-pt-tokens-on-aave-v3-core-instance/22850",
          "documentType": "official_governance_forum",
          "publishedOn": "2025-08-08"
        }
      ],
      "whatHappened": "Aave's TEMP CHECK approved advancing a December-expiry PT-tUSDe collateral proposal to the ARFC stage.",
      "whatChanged": "The concept moved from initial discussion to formal risk and parameter review.",
      "whatDidNotChange": "No PT contract, risk parameters, oracle, cap, or live collateral reserve was approved or deployed at the TEMP CHECK stage.",
      "confirmedFacts": [
        "The TEMP CHECK passed on August 18, 2025, with quorum and YAE as the winning option.",
        "The proposal targets a December-expiry tUSDe principal token on Aave v3 Ethereum Core.",
        "The official post said the next step was an ARFC.",
        "At the TEMP CHECK stage, the contract address and risk parameters were not final."
      ],
      "unresolved": [
        "The underlying tUSDe and Terminal dependencies required service-provider analysis.",
        "Final contract address, maturity date, liquidity, oracle, caps, e-mode parameters, and execution remained unresolved."
      ],
      "advisorDiligenceImplications": [
        "Monitor the ARFC but do not treat PT-tUSDe as an available or approved Aave collateral.",
        "Require full look-through to tUSDe, Terminal, Midas, Ethena, Pendle, redemption, pause, and oracle dependencies.",
        "Assess maturity and exit liquidity before any future memo inclusion."
      ],
      "followUpOn": "2025-09-01",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-059e9c1f02a71bb5235bf2eb",
      "stableKey": "aave-v3:ethereum-core:lseth-onboarding-temp-check-2025-08",
      "version": 1,
      "eventDate": "2025-08-18",
      "publishedAt": "2026-08-22T14:05:43.901Z",
      "title": "Aave advances LsETH collateral onboarding to ARFC review",
      "category": "governance",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[TEMP CHECK] Onboard LsETH to Aave V3 Core Instance",
          "authority": "Aave DAO",
          "url": "https://governance.aave.com/t/temp-check-onboard-lseth-to-aave-v3-core-instance/22832",
          "documentType": "official_governance_forum",
          "publishedOn": "2025-08-06"
        }
      ],
      "whatHappened": "Aave's TEMP CHECK approved advancing Liquid Collective's LsETH for potential collateral onboarding on Ethereum Core.",
      "whatChanged": "LsETH moved to the ARFC diligence and parameter-setting stage.",
      "whatDidNotChange": "No collateral reserve was added. Risk parameters, caps, oracle configuration, and final governance approval remained outstanding.",
      "confirmedFacts": [
        "The TEMP CHECK passed on August 18, 2025, with quorum and YAE as the winning option.",
        "The proposal targets Aave v3 Ethereum Core.",
        "The proposed LsETH contract is 0x8c1bed5b9a0928467c9b1341da1d7bd5e10b6549.",
        "The official post said initial risk parameters would be provided during ARFC review."
      ],
      "unresolved": [
        "Secondary liquidity, holder concentration, redemption timing, platform controls, and final Aave risk parameters remained unresolved.",
        "The claimed deposit commitments were not independently evidenced in the primary governance post."
      ],
      "advisorDiligenceImplications": [
        "Monitor the ARFC without treating LsETH as approved Aave collateral.",
        "Require analysis of Liquid Collective's permissioned mint and redemption paths, validator and platform dependencies, liquidity, oracle design, and concentration.",
        "Verify any deposit commitments before using them in liquidity assumptions."
      ],
      "followUpOn": "2025-09-03",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-21f9f7e6f84ec23526445c40",
      "stableKey": "aave-v3:ethereum-core:ezeth-onboarding-aip-2025-08",
      "version": 1,
      "eventDate": "2025-08-12",
      "publishedAt": "2026-08-22T14:05:43.901Z",
      "title": "Aave opens final governance for ezETH collateral on Ethereum Core",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[Direct-to-AIP] Add ezETH to Aave v3 Core Instance",
          "authority": "Aave DAO",
          "url": "https://governance.aave.com/t/direct-to-aip-add-ezeth-to-aave-v3-core-instance/22732",
          "documentType": "official_governance_forum",
          "publishedOn": "2025-07-29"
        },
        {
          "title": "Proposal 355",
          "authority": "Aave Governance",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=355",
          "documentType": "onchain_governance_record",
          "publishedOn": "2025-08-12"
        }
      ],
      "whatHappened": "Aave opened an on-chain proposal to add ezETH as collateral to the Ethereum Core instance.",
      "whatChanged": "If executed, ezETH would become non-borrowable collateral with a 50,000-token supply cap and separate wstETH and stablecoin e-modes, including high correlated-mode leverage parameters.",
      "whatDidNotChange": "The reviewed record does not itself confirm execution or establish that ezETH was live in Ethereum Core on August 12.",
      "confirmedFacts": [
        "The proposed ezETH contract is 0xbf5495efe5db9ce00f80364c8b423567e58d2110.",
        "The proposed supply cap is 50,000 ezETH and borrowing is disabled.",
        "The ezETH/wstETH e-mode proposes 93% LTV and a 95% liquidation threshold.",
        "The ezETH/stablecoin e-mode proposes 75% LTV and a 78% liquidation threshold."
      ],
      "unresolved": [
        "Final vote outcome and execution timing require operative on-chain confirmation.",
        "Final live oracle, e-mode, cap, and reserve configuration require reconciliation after execution.",
        "Liquidity concentration and Renzo withdrawal-buffer availability remain material diligence items."
      ],
      "advisorDiligenceImplications": [
        "Monitor final execution before treating ezETH as Ethereum Core collateral.",
        "Review the leverage, depeg, liquidation-liquidity, Renzo administration, timelock, and withdrawal dependencies introduced by the listing.",
        "Do not infer safety or client approval from the proposed risk parameters."
      ],
      "followUpOn": "2025-08-19",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-cf6593154cb5b48329279611",
      "stableKey": "coinbase-bridge:base-mainnet-block-production-halt:2025-08-05",
      "version": 1,
      "eventDate": "2025-08-05",
      "publishedAt": "2026-08-22T14:05:43.901Z",
      "title": "Base recovers from a 33-minute mainnet block-production halt",
      "category": "market_stress",
      "posture": "postmortem",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "coinbase-bridge",
          "name": "Base canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Base Mainnet | Unsafe head delay",
          "authority": "Base",
          "url": "https://status.base.org/incidents/kdq3t8s13gfs",
          "documentType": "official_status_postmortem",
          "publishedOn": "2025-08-05"
        }
      ],
      "whatHappened": "Base's active sequencer fell behind, and an automated Conductor handoff selected a sequencer that was still being provisioned and could not produce blocks. Mainnet block production stopped for 33 minutes.",
      "whatChanged": "The incident established a realized sequencer failover and provisioning failure capable of interrupting Base mainnet block production, deposits, and withdrawals. Base said it would change cluster admission behavior and testing.",
      "whatDidNotChange": "Base reported full network recovery by 06:40 UTC. The postmortem did not report a bridge-contract exploit, asset loss, or chain reorganization.",
      "confirmedFacts": [
        "Base mainnet block production stopped at approximately 06:07 UTC on August 5, 2025.",
        "The status incident identified deposits, withdrawals, block production, and Flashblocks as affected components.",
        "The team manually paused Conductor and transferred leadership to a healthy sequencer.",
        "Base reported full recovery after 33 minutes."
      ],
      "unresolved": [
        "The status postmortem states planned infrastructure and testing improvements but does not prove when each corrective action was deployed.",
        "The receipt does not quantify transaction-level deposit or withdrawal delays after block production resumed."
      ],
      "advisorDiligenceImplications": [
        "Review the coinbase-bridge memo's availability and withdrawal assumptions against a realized sequencer failover outage.",
        "Record that canonical bridge access can become temporarily unavailable during a Base sequencing halt even without a bridge-contract exploit.",
        "Verify whether current operational controls now prevent an unready sequencer from becoming leader."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-10e860bc39c3742d82115ab0",
      "stableKey": "arbitrum-bridge:legacy-usdt-gateway:disable-approval-2025-07",
      "version": 1,
      "eventDate": "2025-07-31",
      "publishedAt": "2026-08-22T14:05:43.445Z",
      "title": "Arbitrum approves disabling its legacy USDT bridge",
      "category": "closure_deprecation",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "arbitrum-bridge",
          "name": "Arbitrum Bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[Constitutional] AIP: Disable Legacy Tether Bridge",
          "authority": "Arbitrum DAO Snapshot",
          "url": "https://snapshot.org/#/arbitrumfoundation.eth/proposal/0xd5a66f784523841511f7ffec4171b9c14404fdbf7c205086312084d19c95c193",
          "documentType": "official_governance_record",
          "publishedOn": "2025-07-23"
        }
      ],
      "whatHappened": "Arbitrum DAO voters approved a constitutional proposal to disable the legacy USDT gateway after migration of most cross-chain activity to USDT0.",
      "whatChanged": "If the approved action is executed, new calls routing legacy Ethereum USDT through the specified L1 gateway would revert, retiring that deposit path and requiring integrations to use another route.",
      "whatDidNotChange": "The Snapshot approval did not execute the DisableGatewayAction. It did not deprecate the canonical bridge for other assets or establish the final state of third-party integrations.",
      "confirmedFacts": [
        "The official vote ended on July 31, 2025 with approximately 159.4 million ARB voting for the proposal.",
        "The target is legacy Ethereum USDT at 0xdAC17F958D2ee523a2206206994597C13D831ec7.",
        "The proposal specifies DisableGatewayAction contract 0x8d3425f7039645223517F6F6e60Ef04C28f4188F.",
        "The stated legacy route has a seven-day withdrawal delay and can create refund problems for depositing smart contracts.",
        "The proposal states that transactions submitted after disablement would revert."
      ],
      "unresolved": [
        "The subsequent Tally vote and execution transaction.",
        "The exact effective block and final L1GatewayRouter mapping.",
        "Whether every wallet, exchange, and smart-contract integration migrated before execution.",
        "Treatment and exit paths for existing legacy bridged USDT balances."
      ],
      "advisorDiligenceImplications": [
        "Review the Arbitrum Bridge memo's supported-asset routes and integration assumptions before treating the legacy USDT path as unavailable.",
        "Verify on-chain execution and existing-balance withdrawal behavior; approval alone does not retire the gateway."
      ],
      "followUpOn": "2025-08-08",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-f1053e13bd411079d921f17a",
      "stableKey": "aave-v3:ethereum-core:pt-usde-25sep2025-onboarding",
      "version": 1,
      "eventDate": "2025-07-30",
      "publishedAt": "2026-08-22T14:05:43.445Z",
      "title": "Aave executes PT-USDe September collateral onboarding",
      "category": "economic_change",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Onboard USDe September expiry PT tokens on Aave V3 Core Instance",
          "authority": "Aave Governance",
          "url": "https://vote.onaave.com/proposal/?proposalId=346",
          "documentType": "executed_onchain_governance_proposal",
          "publishedOn": "2025-07-25"
        }
      ],
      "whatHappened": "Aave governance executed proposal 346, adding PT-USDe-25SEP2025 as collateral on Aave v3 Ethereum Core.",
      "whatChanged": "Ethereum Core gained a maturity-dated Pendle and Ethena collateral dependency with a 50 million supply cap, capped linear-discount pricing, two E-mode configurations, and an assigned emission administrator.",
      "whatDidNotChange": "The asset is not borrowable, its base configuration retains negligible LTV and liquidation threshold outside E-mode, and execution does not make the collateral independently Ketju-approved.",
      "confirmedFacts": [
        "The proposal finished execution on July 30, 2025.",
        "PT-USDe-25SEP2025 matures on September 25, 2025.",
        "The executed supply cap is 50,000,000 tokens.",
        "The reserve is collateral-enabled but not borrowable.",
        "The two configured E-modes use initial LTVs of 90.3% and 91.2%.",
        "The pricing configuration specifies a 9.65% discount rate and 29.10% maximum annual discount rate."
      ],
      "unresolved": [
        "Post-execution verification of reserve, oracle, E-mode, and emission-admin state.",
        "Liquidity and liquidation performance as the token approaches maturity.",
        "Operational rollover and exit handling for positions migrating from the July expiry.",
        "Effects of Ethena, Pendle, oracle, and maturity dependencies during market stress."
      ],
      "advisorDiligenceImplications": [
        "Review the Aave memo's collateral, oracle, E-mode, maturity, and rollover assumptions before recognizing exposure to the new reserve.",
        "Monitor post-execution liquidity and approaching maturity; execution and prior demand do not establish suitability."
      ],
      "followUpOn": "2025-08-06",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-7d70050d31890ca5324fb67f",
      "stableKey": "lido:triggerable-withdrawals:design-approval-2025-07",
      "version": 1,
      "eventDate": "2025-07-28",
      "publishedAt": "2026-08-22T14:05:43.445Z",
      "title": "Lido approves the Triggerable Withdrawals design",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Triggerable Withdrawals Framework in the Lido Protocol",
          "authority": "Lido DAO Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x7d7f0e1a6d181310f8752af37e20515a9be258f30b211872f9acca99bc478851",
          "documentType": "official_governance_record",
          "publishedOn": "2025-07-21"
        }
      ],
      "whatHappened": "Lido tokenholders approved the design of a Triggerable Withdrawals framework based on EIP-7002.",
      "whatChanged": "The approved design would introduce an execution-layer path for authorized or permissionless participants to trigger validator exits after a Validator Exit Bus request, reducing exclusive reliance on node operators and oracles.",
      "whatDidNotChange": "The framework was not live in July. Snapshot approval did not deploy the gateway, activate Easy Track factories, split GateSeal controls, or prove production behavior.",
      "confirmedFacts": [
        "The Snapshot ended on July 28, 2025 with approximately 52.3 million LDO voting for and about 12 LDO against.",
        "The design introduces a Triggerable Withdrawals Gateway as the entry point for requests.",
        "After a valid Validator Exit Bus request, any participant could submit the corresponding execution-layer withdrawal request.",
        "The approved research proposed a maximum outstanding limit of 11,200 validators and approximately 1,800 exits per day.",
        "The design includes Easy Track paths and changes to emergency-pause organization."
      ],
      "unresolved": [
        "The final on-chain vote and activation transaction.",
        "Final deployed contracts, roles, limits, and GateSeal configuration.",
        "Behavior under mass exits, compromised authorized actors, or gateway failure.",
        "Effects on withdrawal latency, validator penalties, and protocol liquidity after activation."
      ],
      "advisorDiligenceImplications": [
        "Review Lido's withdrawal, validator-control, emergency-pause, and node-operator assumptions before treating the framework as operative.",
        "Verify contracts and live limits after execution; design approval does not establish successful withdrawal performance."
      ],
      "followUpOn": "2025-09-15",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": false
    },
    {
      "id": "event-event-draft-4a64b330357ec526c1d723c7",
      "stableKey": "lido:csm-v2:final-rollout-approval-2025-07",
      "version": 1,
      "eventDate": "2025-07-28",
      "publishedAt": "2026-08-22T14:05:43.445Z",
      "title": "Lido approves the CSM v2 final rollout",
      "category": "upgrade_migration",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "CSM v2 Final Rollout",
          "authority": "Lido DAO Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0xc3f92bcdf8926cfa7528ca6a979c0fdce1e4d0cfaaa72dd6410a76a2e1e55766",
          "documentType": "official_governance_record",
          "publishedOn": "2025-07-21"
        }
      ],
      "whatHappened": "Lido tokenholders approved the final rollout plan for Community Staking Module v2.",
      "whatChanged": "The approval finalized a migration and operating framework with permissionless, Legacy Early Adopter, and Identified Community Staker operator types, EIP-7002 support, revised performance accounting, and committee reimbursement funding.",
      "whatDidNotChange": "CSM v2 was not deployed in July, existing operators were not yet migrated, and pending audits and later on-chain execution remained necessary.",
      "confirmedFacts": [
        "The Snapshot ended on July 28, 2025 with approximately 52.35 million LDO voting for and about 12 LDO against.",
        "The approved rollout defines three initial node-operator types.",
        "The design includes EIP-7002 support and an updated Performance Oracle.",
        "The Identified Community Stakers framework uses address-ownership proofs and published eligibility scoring.",
        "The proposal includes 10 stETH of committee funding for eligible reimbursement of incorrectly penalized operators."
      ],
      "unresolved": [
        "Final audit findings and remediation.",
        "The on-chain upgrade vote, execution date, and deployed contract state.",
        "Final operator classifications, bond curves, module allocation, and committee permissions.",
        "Effects on validator concentration, performance-oracle errors, penalties, reimbursements, and withdrawal behavior."
      ],
      "advisorDiligenceImplications": [
        "Supersede the May architecture-stage interpretation with final-rollout approval while retaining a non-operative posture.",
        "Review final code, audits, operator classifications, committee authority, performance accounting, and executed module limits before updating Lido suitability conclusions."
      ],
      "followUpOn": "2025-09-15",
      "previousInterpretation": "The May event established approval of the CSM v2 architecture and fee structure but not the final rollout plan, finalized operator framework, reimbursement authority, or production authorization.",
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-e249eff39a111589ca5d3630",
      "stableKey": "aave-v3:capo:risk-oracle-dynamic-calibration-approval-2025-07",
      "version": 1,
      "eventDate": "2025-07-26",
      "publishedAt": "2026-08-22T14:05:43.445Z",
      "title": "Aave approves dynamic CAPO calibration at the ARFC stage",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Dynamic Calibration of CAPO Parameters via Risk Oracles",
          "authority": "Aave DAO Snapshot",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0x66aa6904f140d56ada880f45c911994c5c6cc20109b55081f508ccdd6417066d",
          "documentType": "official_governance_record",
          "publishedOn": "2025-07-22"
        }
      ],
      "whatHappened": "Aave DAO voters approved an ARFC framework for Risk Oracles to update CAPO snapshotRatio and maxYearlyRatioGrowthPercent parameters.",
      "whatChanged": "The approved design would replace infrequent manual calibration with bounded off-chain recommendations and on-chain updates affecting the maximum recognized exchange-rate growth of yield-bearing collateral.",
      "whatDidNotChange": "No AIP or deployed Risk Oracle was established within July. Existing CAPO contracts, asset allowlists, and live parameters were not changed by the Snapshot alone.",
      "confirmedFacts": [
        "The Snapshot closed on July 26, 2025 with approximately 777,990 voting YAE and negligible opposition.",
        "The approved framework covers snapshotRatio and maxYearlyRatioGrowthPercent.",
        "The proposed snapshotRatio constraint is at most a 5% relative change every 14 days.",
        "The proposed annual-growth constraint is at most a 10% relative change every three days.",
        "The framework uses off-chain analysis to recommend bounded on-chain parameter updates."
      ],
      "unresolved": [
        "The final implementation, asset allowlist, contracts, and assigned roles.",
        "Whether later AIP constraints differ from the approved ARFC design.",
        "Failure and revocation handling for erroneous or compromised recommendations.",
        "Whether automated bounds remain sufficiently tight without incorrectly capping legitimate collateral appreciation."
      ],
      "advisorDiligenceImplications": [
        "Review the Aave memo's collateral-oracle and delegated-control assumptions before the design becomes operative.",
        "Verify the final AIP, allowlist, bounds, roles, and deployed state rather than inferring safety from ARFC approval."
      ],
      "followUpOn": "2025-08-11",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-a51fb08a9f741a82d541e2d3",
      "stableKey": "aave-v3:agrs:optimism-bnb-gnosis-polygon-activation-2025-07",
      "version": 1,
      "eventDate": "2025-07-24",
      "publishedAt": "2026-08-22T14:05:43.445Z",
      "title": "Aave proposes automated cap controls on four additional networks",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Caps AGRS activation on Optimism, BNB, Gnosis, Polygon",
          "authority": "Aave Governance Forum (BGD Labs)",
          "url": "https://governance.aave.com/t/technical-maintenance-proposals/15274/98",
          "documentType": "official_governance_proposal",
          "publishedOn": "2025-07-24"
        }
      ],
      "whatHappened": "BGD Labs proposed enabling Aave Generalised Risk Stewards for supply and borrow caps on Optimism, BNB, Gnosis, and Polygon.",
      "whatChanged": "If executed, whitelisted reserve caps on four additional deployments could be changed through off-chain Edge recommendations, RiskOracle contracts, injector automation, and newly assigned RISK_ADMIN roles.",
      "whatDidNotChange": "No execution was established within July. The stewards would remain limited to supply and borrow caps, whitelisted assets, and maximum 30% changes every three days.",
      "confirmedFacts": [
        "The proposal identifies Optimism, BNB, Gnosis, and Polygon as the new deployments.",
        "The automated authority is limited to supply and borrow caps.",
        "The proposed constraint is a maximum 30% increase or decrease every three days.",
        "Chainlink Automation would run the injectors except on Gnosis, where Gelato Automation is specified.",
        "The official proposal publishes the intended steward, injector, and RiskOracle addresses."
      ],
      "unresolved": [
        "The Aave governance outcome after July 31.",
        "The final execution payload and assigned RISK_ADMIN roles.",
        "Post-execution asset allowlists and automation funding.",
        "Failure handling for stale, erroneous, unavailable, or compromised off-chain recommendations."
      ],
      "advisorDiligenceImplications": [
        "Review the Aave memo's delegated risk-control map before treating the additional cap automation as operative.",
        "Verify final roles, allowlists, constraints, automation dependencies, and revocation paths after execution."
      ],
      "followUpOn": "2025-08-04",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-c5e045e0e34bfe2e9e02d7f7",
      "stableKey": "aave-v3:long-tail-assets:eurs-snx-lusd-deprecation-2025-07",
      "version": 1,
      "eventDate": "2025-07-22",
      "publishedAt": "2026-08-22T14:05:43.445Z",
      "title": "Aave executes long-tail reserve deprecations",
      "category": "closure_deprecation",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Deprecation of Long-tail Assets",
          "authority": "Aave Governance",
          "url": "https://vote.onaave.com/proposal/?ipfsHash=0xcb1dd7a51c7b81f3f1a5a4e4c1c01112777fa515738745c876938010c8b6be8b&proposalId=339",
          "documentType": "executed_onchain_governance_proposal",
          "publishedOn": "2025-07-17"
        }
      ],
      "whatHappened": "Aave governance executed proposal 339 to begin or continue deprecating EURS on Polygon, SNX on Ethereum Core, and LUSD on Arbitrum and Optimism.",
      "whatChanged": "The payload removed collateral capacity for EURS and SNX, eliminated their debt ceilings, increased borrower base rates, and raised reserve factors intended to encourage users to exit the affected reserves.",
      "whatDidNotChange": "The reserves were not removed, existing positions were not automatically closed, and execution does not establish that every supplier or borrower exited without loss or congestion.",
      "confirmedFacts": [
        "Proposal 339 executed on July 22, 2025.",
        "EURS Polygon LTV was set to 0%, its debt ceiling to zero, its base rate to 2%, and its reserve factor to 50%.",
        "SNX Ethereum Core LTV was set to 0%, its debt ceiling to zero, its base rate to 6%, and its reserve factor to 95%.",
        "LUSD base rates on Arbitrum and Optimism were raised to 2% and reserve factors to 50%.",
        "The stated rationale included contracted liquidity, limited demand, and changing risk profiles."
      ],
      "unresolved": [
        "Final Risk Steward cap reductions and their effective blocks.",
        "Remaining supplied and borrowed balances and the pace of user exits.",
        "Liquidation and repayment liquidity for affected borrowers.",
        "Whether any integration or client position retained exposure after deprecation began."
      ],
      "advisorDiligenceImplications": [
        "Review the Aave memo and any position inventory for exposure to the affected reserves, especially Ethereum Core SNX.",
        "Verify remaining balances, caps, liquidity, and exit conditions before treating deprecation as complete."
      ],
      "followUpOn": "2025-08-05",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-10e6378b72d30dba8a9ddea1",
      "stableKey": "aave-v3:ink-whitelabel:arfc-approval-2025-07",
      "version": 1,
      "eventDate": "2025-07-21",
      "publishedAt": "2026-08-22T14:05:43.445Z",
      "title": "Aave approves the Ink whitelabel deployment at ARFC",
      "category": "governance",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Deploy a Whitelabel Aave V3 Instance on Ink",
          "authority": "Aave DAO Snapshot",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0x4185135ca5693f3a7022372dc989ee432c1ca792cde020275f3dfb472a90d6f1",
          "documentType": "official_governance_record",
          "publishedOn": "2025-07-17"
        }
      ],
      "whatHappened": "Aave DAO voters approved an ARFC authorizing progression toward a whitelabel Aave v3 instance governed by the Ink Foundation.",
      "whatChanged": "The approved plan would license Aave code for a centrally governed lending deployment, provide initial Aave service-provider support, create DAO revenue sharing, and permit incentive funding.",
      "whatDidNotChange": "No Ink lending instance was confirmed live in July. The planned instance would not be governed by Aave DAO and would not be covered by Aave's Umbrella system.",
      "confirmedFacts": [
        "The Snapshot closed on July 21, 2025 with approximately 789,556 voting YAE and 1,579 NAY.",
        "The proposal specifies centralized governance by the Ink Foundation without an initial governance token.",
        "The Aave DAO revenue share must be at least the equivalent of a 5% reserve factor based on borrow volume.",
        "Initial Aave service-provider support is specified for six months.",
        "The proposal expressly excludes the whitelabel instance from DAO-operated Umbrella coverage."
      ],
      "unresolved": [
        "The final AIP, deployed contracts, governance transfer, and launch date.",
        "Final collateral, oracle, liquidation, pause, upgrade, and custody controls.",
        "The commercial support arrangement after the initial six months.",
        "Whether incentives create a genuinely advisor-accessible product requiring a separate Ketju object."
      ],
      "advisorDiligenceImplications": [
        "Track the final deployment as a separate, centrally governed exposure rather than extending Aave v3 approval by brand or code lineage.",
        "Map executed controls and insurance boundaries before adding the Ink instance to the research perimeter."
      ],
      "followUpOn": "2025-08-08",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-72458aefc3c118d8cf013169",
      "stableKey": "aave-v3:ethereum-core:fxsave-temp-check-approval-2025-07",
      "version": 1,
      "eventDate": "2025-07-18",
      "publishedAt": "2026-08-22T14:05:43.445Z",
      "title": "Aave advances fxSAVE collateral to ARFC review",
      "category": "governance",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[TEMP CHECK] Onboard fxSAVE to Aave V3 Core Instance",
          "authority": "Aave DAO Snapshot",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0xf2f789b1bf66899c3e2142a93d3d6e46ebb2ce1e00a9b119ab8356c6fc55153c",
          "documentType": "official_governance_record",
          "publishedOn": "2025-07-14"
        }
      ],
      "whatHappened": "Aave DAO voters approved the fxSAVE temperature check, advancing the proposed Ethereum Core collateral listing to ARFC analysis.",
      "whatChanged": "fxSAVE entered formal risk review as a potential collateral asset carrying f(x) Protocol strategy, smart-contract, liquidity, leverage, and underlying stETH dependencies.",
      "whatDidNotChange": "No collateral parameters, oracle, ARFC approval, AIP, execution, or live reserve was established by the temperature check.",
      "confirmedFacts": [
        "The Snapshot closed on July 18, 2025 with approximately 811,728 voting YAE and negligible opposition.",
        "The target market is Aave v3 Ethereum Core.",
        "The proposal identifies fxSAVE as a yield-bearing f(x) Protocol token.",
        "The proposal defers risk parameters to later service-provider analysis.",
        "The stated next governance stage is an ARFC."
      ],
      "unresolved": [
        "Asset contract and complete dependency mapping.",
        "Collateral, liquidation, cap, E-mode, and oracle parameters.",
        "Upgrade, pause, redemption, liquidity, and strategy-loss controls.",
        "ARFC, AIP, and execution outcomes."
      ],
      "advisorDiligenceImplications": [
        "Require a full fxSAVE and f(x) dependency review before any Aave memo expansion.",
        "Monitor later parameters and execution without treating temperature-check approval as a live or suitable collateral listing."
      ],
      "followUpOn": "2025-08-01",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-ff35a1d905497123db522641",
      "stableKey": "aave-v3:agrs:pendle-discount-oracle-and-manual-steward-2025-06",
      "version": 1,
      "eventDate": "2025-06-30",
      "publishedAt": "2026-08-22T14:05:42.640Z",
      "title": "Aave approves expanded automated and manual risk-steward authority",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Discount Rate Risk Oracle Activation and update manual AGRS",
          "authority": "Aave Governance",
          "url": "https://vote.onaave.com/proposal/?ipfsHash=0x90c865128c6c5162d7bf4d957fcf33a10a5da36ac6eef6a142299b8df2c2b7cc&proposalId=332",
          "documentType": "onchain_governance_proposal",
          "publishedOn": "2025-06-26"
        }
      ],
      "whatHappened": "Aave governance approved proposal 332 to automate discount-rate updates for three Pendle PT feeds and deploy updated manual AGRS contracts across its instances.",
      "whatChanged": "The approved payload would grant RISK_ADMIN authority to new steward contracts, permit automated discount-rate recommendations through Edge Risk Oracle infrastructure, and allow constrained manual e-mode and Pendle discount-rate changes.",
      "whatDidNotChange": "Execution occurred after the June boundary. The approval did not remove the stated percentage constraints, minimum delays, feed allowlist, or separate handling of GHO.",
      "confirmedFacts": [
        "The automated steward is limited to whitelisted Pendle PT feeds on Ethereum Core.",
        "Automated discount-rate changes are constrained to a maximum one percentage-point absolute change every two days.",
        "Manual e-mode LTV, liquidation-threshold, and liquidation-bonus changes retain stated limits and three-day delays.",
        "The proposal passed before June 30 ended but was not executed until July 1."
      ],
      "unresolved": [
        "Verification of the July execution and final RISK_ADMIN role assignments.",
        "The complete deployed allowlist and automation configuration.",
        "How off-chain recommendation failures or stale inputs are handled operationally.",
        "Whether realized PT pricing behavior remains within memo assumptions."
      ],
      "advisorDiligenceImplications": [
        "Review Aave's oracle and delegated-risk-control map because approval expands automated and manual authority over collateral pricing and e-mode parameters.",
        "Verify executed roles, limits, allowlists, and revocations before treating the new AGRS configuration as operative."
      ],
      "followUpOn": "2025-07-02",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-e47d06ae38a9c6a8400c8f6e",
      "stableKey": "aave-v3:ethereum-core:eurc-onboarding-aip-2025-06",
      "version": 1,
      "eventDate": "2025-06-30",
      "publishedAt": "2026-08-22T14:05:42.640Z",
      "title": "Aave approves EURC collateral for Ethereum Core",
      "category": "economic_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Add EURC to Aave V3 Core Instance",
          "authority": "Aave Governance",
          "url": "https://vote.onaave.com/proposal/?ipfsHash=0xf93eb58ea5cf5aaf82c5e3c799ac717bed7c1879c6a4ae1525087df7a873e5b6&proposalId=331",
          "documentType": "onchain_governance_proposal",
          "publishedOn": "2025-06-26"
        }
      ],
      "whatHappened": "Aave governance approved proposal 331 to add Circle-issued EURC as borrowable collateral in the Ethereum Core instance.",
      "whatChanged": "The approved listing adds EURC issuer, redemption, euro-market, liquidity, and oracle dependencies with explicit caps and liquidation parameters.",
      "whatDidNotChange": "Execution occurred after June 30, so EURC was not yet an operative reserve within this backfill boundary. The vote does not make EURC Ketju-approved.",
      "confirmedFacts": [
        "The approved supply and borrow caps are 7 million and 6.5 million EURC.",
        "The approved LTV and liquidation threshold are 75% and 78%.",
        "The approved liquidation bonus is 5% and reserve factor is 10%.",
        "Pricing uses a capped EURC/USD structure incorporating Chainlink EURC/USD and EUR/USD inputs."
      ],
      "unresolved": [
        "Verification of the July execution and final reserve configuration.",
        "EURC liquidity and liquidation performance under euro-dollar volatility.",
        "Issuer, redemption, freeze, and banking dependency treatment in the Aave memo.",
        "Whether caps or oracle configuration change after launch."
      ],
      "advisorDiligenceImplications": [
        "Review the Aave memo's collateral and oracle perimeter before treating EURC exposure as acceptable.",
        "Verify executed reserve state, issuer controls, redemption mechanics, and stressed liquidity before considering the new market."
      ],
      "followUpOn": "2025-07-02",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-d444ea0b6a7e1b2f84328ef3",
      "stableKey": "lido:curated-module:intra-operator-dvt-guidelines-2025-06",
      "version": 1,
      "eventDate": "2025-06-30",
      "publishedAt": "2026-08-22T14:05:42.640Z",
      "title": "Lido approves intra-operator DVT rules for Curated Module operators",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "DVT Integration Guidelines for the Curated Module Node Operators",
          "authority": "Lido DAO Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x15cdcb4881d85d48e363bcc449cabfc26b627ac395e2515d65d6637453c35ab3",
          "documentType": "official_governance_record",
          "publishedOn": "2025-06-23"
        }
      ],
      "whatHappened": "Lido tokenholders approved guidelines allowing Curated Module node operators to adopt self-run Obol or SSV distributed-validator clusters under specified limits and safeguards.",
      "whatChanged": "Operators may split up to the lesser of 1,000 or 20% of active validator keys after testnet validation, add DVT keys produced through vetted verifiable DKG, and participate under revised provider-incentive allocations.",
      "whatDidNotChange": "The approval does not require every operator to adopt DVT, does not itself migrate validator keys, and does not establish the security or performance of any specific operator cluster.",
      "confirmedFacts": [
        "Curated Module DVT adoption is optional and limited to intra-operator clusters.",
        "Migration by an operator is capped at the lesser of 1,000 or 20% of its active validator keys.",
        "Obol and SSV are the identified DVT providers.",
        "Curated Module operators receive 20% of provider incentives, with 80% directed to the Mellow Decentralized Validator Vault."
      ],
      "unresolved": [
        "Which operators opt in and how many validators migrate.",
        "The final contributor-vetting process for DKG and key-shard procedures.",
        "Operational concentration, correlated-failure, and slashing behavior of deployed clusters.",
        "Whether incentive routing changes after implementation."
      ],
      "advisorDiligenceImplications": [
        "Update Lido's validator and key-management control map to include intra-operator DVT, DKG review, migration limits, and provider dependencies.",
        "Monitor operator-level adoption and slashing performance before interpreting DVT approval as a reduction in operational risk."
      ],
      "followUpOn": "2025-07-14",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-16375cb633f22e7f59221d32",
      "stableKey": "lido:oracle-set:kyber-to-caliber-rotation-2025-06",
      "version": 1,
      "eventDate": "2025-06-30",
      "publishedAt": "2026-08-22T14:05:42.640Z",
      "title": "Lido approves replacing Kyber with Caliber in its oracle set",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Decision on Kyber Network's position in the Oracle Set: rotate to Caliber or remove and change the quorum",
          "authority": "Lido DAO Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0xdc208507ca0f659c7f9e38056288aedb7610816ea4020ca751c3422434780de8",
          "documentType": "official_governance_record",
          "publishedOn": "2025-06-23"
        }
      ],
      "whatHappened": "Lido tokenholders approved rotating Kyber Network out of the Lido on Ethereum oracle set and replacing it with Caliber.",
      "whatChanged": "The approved path changes the entity responsible for one oracle-set position while preserving the seat rather than removing it and adjusting quorum.",
      "whatDidNotChange": "The Snapshot approval does not itself prove that the on-chain oracle member rotation occurred, and it does not validate Caliber's production security or independence.",
      "confirmedFacts": [
        "The vote offered direct rotation to Caliber or removal of Kyber with a quorum change.",
        "The direct rotation option received the overwhelming voting weight.",
        "Caliber completed a Hoodi testnet period before the vote.",
        "The proposal attributes the change to Kyber's infrastructure operations transitioning to Caliber."
      ],
      "unresolved": [
        "The executed oracle-set membership and effective rotation date.",
        "The final production keys, infrastructure, and incident-response contacts.",
        "Operational overlap and independence between Kyber and Caliber.",
        "Whether quorum or other oracle controls change during implementation."
      ],
      "advisorDiligenceImplications": [
        "Review Lido's oracle-operator roster, key controls, concentration, and business-continuity assumptions.",
        "Verify the executed membership and Caliber's production operating evidence before treating the rotation as complete."
      ],
      "followUpOn": "2025-07-07",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-089aa9fd12e0e371ef45e369",
      "stableKey": "lido:snop:block-proposals-v3-approval-2025-06",
      "version": 1,
      "eventDate": "2025-06-30",
      "publishedAt": "2026-08-22T14:05:42.640Z",
      "title": "Lido approves revised block-proposer and reward policy",
      "category": "economic_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Proposal for Updating Block Proposer Rewards Policy to Lido on Ethereum SNOP on Block Proposals v3",
          "authority": "Lido DAO Snapshot",
          "url": "https://snapshot.org/#/lido-snapshot.eth/proposal/0x8b6addc4be1a9ef4b2a1591be5ac4909aa82c868cd9b7871494b626539a99a8e",
          "documentType": "official_governance_record",
          "publishedOn": "2025-06-23"
        }
      ],
      "whatHappened": "Lido tokenholders approved version 3 of the Standard Node Operator Protocol for block proposals, replacing the prior proposer-rewards policy.",
      "whatChanged": "The revised policy expands coverage across staking modules, formalizes allowed Auxiliary Proposer Mechanisms, updates proposer and fee-recipient responsibilities, and specifies module-level consequences for non-conformance.",
      "whatDidNotChange": "The vote did not approve any particular new APM, alter withdrawal contracts, or prove that every node operator had implemented the revised requirements.",
      "confirmedFacts": [
        "Node operators must direct relevant fees to the Lido Execution Layer Rewards Vault.",
        "Operators may use only community-vetted mechanisms on the APM Allowed List.",
        "The policy expands beyond the original Curated Module context.",
        "The policy describes consequences that vary by staking module."
      ],
      "unresolved": [
        "The effective implementation and operator-attestation process.",
        "The current APM Allowed List and future committee changes.",
        "Monitoring, detection, and enforcement of non-conformance.",
        "The realized effect on proposer rewards, censorship resistance, and operational diversity."
      ],
      "advisorDiligenceImplications": [
        "Update the Lido memo's proposer-reward, MEV, APM, and node-operator compliance controls.",
        "Monitor allowed-list changes and enforcement evidence; policy approval alone does not establish operator compliance."
      ],
      "followUpOn": "2025-07-14",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-b08389a79d84566e56816919",
      "stableKey": "aave-v3:all-instances:v3.4-upgrade-2025-06",
      "version": 1,
      "eventDate": "2025-06-28",
      "publishedAt": "2026-08-22T14:05:42.640Z",
      "title": "Aave proposes the v3.4 upgrade across all instances",
      "category": "upgrade_migration",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Upgrade Aave instances to v3.4",
          "authority": "Aave Governance",
          "url": "https://vote.onaave.com/proposal/?proposalId=334",
          "documentType": "onchain_governance_proposal",
          "publishedOn": "2025-06-28"
        }
      ],
      "whatHappened": "Aave governance created proposal 334 to upgrade all v3 instances from v3.3 to the reduced v3.4 release.",
      "whatChanged": "If executed, the proposal would replace Pool, PoolConfigurator, PoolDataProvider, AToken, and VariableDebtToken implementations, standardize Ethereum Core GHO accounting, add configurable Position Manager permissions, and simplify flash-loan fees.",
      "whatDidNotChange": "The proposal had not completed voting or execution by June 30. It states that the GHO migration is intended to be non-invasive for users, but that intent does not establish post-upgrade behavior.",
      "confirmedFacts": [
        "The payload covers all Aave v3 instances through multiple network payloads.",
        "The existing native stkAAVE discount on variable-debt GHO would be removed.",
        "The proposal includes a pre-execution process intended to settle outstanding GHO discounts shortly before execution.",
        "Four independent audit reports and extensive testing are identified in the proposal."
      ],
      "unresolved": [
        "The vote outcome and execution after June 30.",
        "The exact GHO balances and facilitator transfers at execution time.",
        "Post-upgrade verification of every instance and Position Manager configuration.",
        "Whether any user accounting or integration issue appears after deployment."
      ],
      "advisorDiligenceImplications": [
        "Open a review of Aave v3 implementation, GHO accounting, delegation, and flash-loan assumptions before treating v3.4 as operative.",
        "Verify every deployed implementation and Ethereum Core GHO transition after execution; audits do not establish suitability or successful migration."
      ],
      "followUpOn": "2025-07-04",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-ad4e22e38d2ccc6ce27781d9",
      "stableKey": "aave-v3:ethereum-core:svr-oracles-phase-3-2025-06",
      "version": 1,
      "eventDate": "2025-06-28",
      "publishedAt": "2026-08-22T14:05:42.640Z",
      "title": "Aave activates nine additional SVR oracles on Ethereum Core",
      "category": "control_change",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Enable additional SVR oracles",
          "authority": "Aave Governance",
          "url": "https://vote.onaave.com/proposal/?proposalId=330",
          "documentType": "executed_onchain_governance_proposal",
          "publishedOn": "2025-06-23"
        }
      ],
      "whatHappened": "Aave governance executed proposal 330 to replace nine Ethereum Core price feeds with Chainlink Smart Value Recapture equivalents.",
      "whatChanged": "The affected liquidations now use SVR feeds intended to recapture oracle-extractable value through the existing SVR steward and price-similarity validation process.",
      "whatDidNotChange": "The execution did not change collateral factors, caps, custody, or reserve listings, and it does not establish that realized SVR performance will match expectations.",
      "confirmedFacts": [
        "The execution completed on June 28.",
        "Affected assets are WETH, weETH, osETH, ETHx, rsETH, wstETH, rETH, cbETH, and USDC.",
        "The payload used the SVR steward to replace existing feeds with SVR equivalents.",
        "The change applies to the Aave V3 Ethereum Core instance."
      ],
      "unresolved": [
        "Post-execution feed-address and configuration verification.",
        "Realized oracle-extractable-value recovery and liquidation latency.",
        "Fallback behavior during auction or oracle infrastructure degradation.",
        "Whether the change affects liquidator participation during stress."
      ],
      "advisorDiligenceImplications": [
        "Update Aave's oracle and liquidation-control record for all nine Ethereum Core reserves.",
        "Monitor feed performance, liquidation latency, fallback behavior, and realized value capture before changing risk conclusions."
      ],
      "followUpOn": "2025-07-14",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-f19640d3091719f4a49da85a",
      "stableKey": "aave-v3:core-bnb:usd1-temp-check-approval-2025-06",
      "version": 1,
      "eventDate": "2025-06-27",
      "publishedAt": "2026-08-22T14:05:42.640Z",
      "title": "Aave advances proposed USD1 onboarding to ARFC review",
      "category": "economic_change",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[TEMP CHECK] Onboard USD1 to Aave V3 Core and BNB Instance",
          "authority": "Aave DAO Snapshot",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0x1dcccab036766a95d14cb04bf9f3a1a0c2ad912d6e45443f484b3514e6785e06",
          "documentType": "official_governance_record",
          "publishedOn": "2025-06-24"
        }
      ],
      "whatHappened": "Aave tokenholders approved the USD1 Temp Check, allowing the proposed Core and BNB listings to advance to ARFC analysis.",
      "whatChanged": "USD1 entered Aave's formal risk-parameter and service-provider review path as a proposed deposit and borrow asset.",
      "whatDidNotChange": "The vote did not list USD1, approve collateral use, set final caps or liquidation parameters, or execute any reserve configuration.",
      "confirmedFacts": [
        "The proposal describes USD1 as a fiat-backed stablecoin issued by World Liberty Financial.",
        "The initial proposal contemplates deposits and borrowing, with collateral use deferred.",
        "Final risk parameters were not provided at the Temp Check stage.",
        "The approved next step is ARFC review rather than an executable AIP."
      ],
      "unresolved": [
        "Issuer, reserve, redemption, freeze, and banking controls.",
        "Final oracle, cap, interest-rate, and collateral parameters.",
        "ARFC and AIP outcomes.",
        "Whether USD1 liquidity is sufficient for stressed liquidations or exits."
      ],
      "advisorDiligenceImplications": [
        "Monitor the ARFC and require issuer, reserve, redemption, oracle, and liquidity diligence before any memo conclusion.",
        "Temp Check approval does not make USD1 or the proposed Aave markets Ketju-approved."
      ],
      "followUpOn": "2025-07-11",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-b09e2c884dcaafd8eb825906",
      "stableKey": "aave-v3:ethereum-core:syrupusdc-temp-check-approval-2025-06",
      "version": 1,
      "eventDate": "2025-06-27",
      "publishedAt": "2026-08-22T14:05:42.640Z",
      "title": "Aave advances proposed syrupUSDC collateral to ARFC review",
      "category": "economic_change",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[TEMP CHECK] Onboard syrupUSDC to Aave V3 Core Instance",
          "authority": "Aave DAO Snapshot",
          "url": "https://snapshot.org/#/aavedao.eth/proposal/0xf5951af5d6d7d70be998a72c531708db3ff9c46b033e3e27bfd59fb87542d0ea",
          "documentType": "official_governance_record",
          "publishedOn": "2025-06-24"
        }
      ],
      "whatHappened": "Aave tokenholders approved the syrupUSDC Temp Check, advancing proposed collateral onboarding for Ethereum Core to ARFC review.",
      "whatChanged": "The proposal moved a Maple ERC-4626 yield token backed by institutional lending strategies into Aave's formal risk-review pipeline.",
      "whatDidNotChange": "The vote did not list syrupUSDC, approve final collateral parameters, or validate Maple's credit underwriting and withdrawal behavior.",
      "confirmedFacts": [
        "syrupUSDC is described as a USDC-based ERC-4626 yield-bearing token issued through Maple infrastructure.",
        "The proposal seeks collateral enablement on Aave V3 Ethereum Core.",
        "Final risk parameters were deferred to the ARFC stage.",
        "The Temp Check cites proposed incentives and anticipated institutional allocation, neither of which is guaranteed."
      ],
      "unresolved": [
        "Final LTV, liquidation threshold, caps, oracle, and interest-rate parameters.",
        "Maple borrower, collateral, manager, withdrawal, and loss-allocation risks.",
        "ARFC and AIP outcomes.",
        "Stressed secondary liquidity and redemption capacity for syrupUSDC."
      ],
      "advisorDiligenceImplications": [
        "Monitor the ARFC and require credit, manager, redemption, liquidity, and oracle diligence before any memo conclusion.",
        "Temp Check approval does not make syrupUSDC Ketju-approved or suitable as collateral exposure."
      ],
      "followUpOn": "2025-07-11",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-c55d538ce8a9a7d725902809",
      "stableKey": "aave-v3:prime:teth-onboarding-aip-2025-06",
      "version": 1,
      "eventDate": "2025-06-23",
      "publishedAt": "2026-08-22T14:05:42.640Z",
      "title": "Aave proposes tETH collateral for its Prime instance",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Onboard tETH to Aave v3 Prime Instance",
          "authority": "Aave Governance",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=329",
          "documentType": "onchain_governance_proposal",
          "publishedOn": "2025-06-23"
        }
      ],
      "whatHappened": "Aave governance created proposal 329 to list Treehouse tETH as collateral in the Ethereum Prime instance.",
      "whatChanged": "Execution would add tETH strategy, redemption, oracle, liquidity, and restaking dependencies with a 20,000-token supply cap and a tETH-to-wstETH e-mode.",
      "whatDidNotChange": "The proposal record does not by itself establish execution or make tETH an approved Ketju asset.",
      "confirmedFacts": [
        "The proposed tETH supply cap is 20,000 and borrowing of tETH is disabled.",
        "The proposed base LTV and liquidation threshold are 0.05% and 0.1%.",
        "The tETH/wstETH e-mode proposes 92% LTV and 94% liquidation threshold for tETH collateral.",
        "Pricing uses a capped tETH/wstETH/USD oracle with a 4.5% maximum yearly growth rate."
      ],
      "unresolved": [
        "The final execution state and effective reserve configuration.",
        "tETH redemption, strategy, and liquidity behavior during stress.",
        "Oracle-ratio and price-cap behavior if the underlying strategy underperforms.",
        "The concentration and counterparty risks embedded in tETH."
      ],
      "advisorDiligenceImplications": [
        "Review tETH's strategy, redemption, oracle, and liquidity dependencies before treating the Prime listing as acceptable.",
        "Verify executed caps and e-mode state and keep tETH outside Ketju approval absent separate asset diligence."
      ],
      "followUpOn": "2025-07-02",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-a67eda0adcf31af975b582b5",
      "stableKey": "aave-v3:aptos-mainnet:arfc-snapshot-2025-04-30",
      "version": 2,
      "eventDate": "2025-06-22",
      "publishedAt": "2026-08-22T14:05:42.640Z",
      "title": "Aave opens final governance for a guarded Aptos activation",
      "category": "launch_access",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Aave V3 Aptos Activation",
          "authority": "Aave Governance",
          "url": "https://vote.onaave.com/proposal/?ipfsHash=0x655034112ecc3f89cbcfc7420c490928d01772bcae507a954f1f26be02b4687b&proposalId=328",
          "documentType": "onchain_governance_proposal",
          "publishedOn": "2025-06-22"
        }
      ],
      "whatHappened": "Aave created a final on-chain proposal to place its deployed Aptos market under a guarded activation process as its first non-EVM deployment.",
      "whatChanged": "Approval would begin a restricted CTF phase with APT, USDC, USDT, and sUSDe, broad initial authority held by a 4-of-7 Launch Steward, and a phased path toward Community Guardian and cross-chain DAO control.",
      "whatDidNotChange": "The proposal states that deployment contracts already exist, but public user capacity is intentionally unavailable during the initial restricted phase. Full DAO control and ordinary advisor access were not established.",
      "confirmedFacts": [
        "The initial CTF phase is planned for approximately four to six weeks.",
        "The deployment team would seed up to $25,000 of each supported asset while leaving no room for user deposits during the restricted phase.",
        "The Launch Steward comprises Aave Labs and Aptos Foundation signers with a 4-of-7 threshold.",
        "Full governance requires later transfer of roles and an audited Governance V3 cross-chain executor."
      ],
      "unresolved": [
        "The final vote and execution state within and after June.",
        "Completion and findings of the CTF, outstanding audit, and subsequent bug-bounty phase.",
        "The effective steward keys, role assignments, and emergency procedures.",
        "The timing and verification of public capacity and full DAO-control transition."
      ],
      "advisorDiligenceImplications": [
        "Review the Aptos deployment as a distinct non-EVM control and implementation perimeter, including Launch Steward authority and cross-chain governance dependencies.",
        "Do not treat the restricted deployment as advisor-accessible or Ketju-approved until public capacity, executed roles, audits, and governance transition are independently verified."
      ],
      "followUpOn": "2025-07-07",
      "previousInterpretation": "The April record treated Aptos as an ARFC-stage proposal awaiting a final AIP, guarded activation, and verification of its non-EVM control model.",
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-41984787499f87b7a8ae2eac",
      "stableKey": "optimism-bridge:superchain-upgrade-16:portal-guardian-pause-proposal",
      "version": 1,
      "eventDate": "2025-06-20",
      "publishedAt": "2026-08-22T14:05:42.640Z",
      "title": "Optimism proposes Upgrade 16 bridge and guardian changes",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "optimism-bridge",
          "name": "Optimism canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Optimism Extends $2 Million Bug Bounty Program to Protocol Upgrades Ahead of Superchain Interop",
          "authority": "Optimism Foundation",
          "url": "https://optimism.io/blog/optimism-extends-2-million-bug-bounty-program-to-protocol-upgrades-ahead-of-superchain-interop",
          "documentType": "official_protocol_notice",
          "publishedOn": "2025-06-20"
        }
      ],
      "whatHappened": "Optimism published Superchain Upgrade 16 for review and extended its bug-bounty scope to the proposed upgrade calldata before production deployment.",
      "whatChanged": "The proposal would update OptimismPortal for future cross-chain messaging, remove DeputyGuardianModule, update DeputyPauseModule, and raise the maximum gas limit from 200 million to 500 million.",
      "whatDidNotChange": "The notice states that Upgrade 16 does not enable Superchain interoperability, and it does not establish that the proposed payload was approved or executed.",
      "confirmedFacts": [
        "Upgrade 16 was the first proposed upgrade covered by the expanded calldata bug bounty.",
        "The proposed OptimismPortal changes are preparatory and do not turn on interoperability.",
        "The proposal includes removal of DeputyGuardianModule and updates to DeputyPauseModule.",
        "The maximum gas limit would increase from 200 million to 500 million."
      ],
      "unresolved": [
        "The final governance outcome and executed payload.",
        "The deployed guardian and pause-module state after any execution.",
        "Whether the final code or calldata changes during security review."
      ],
      "advisorDiligenceImplications": [
        "Review the Optimism bridge memo's upgrade, pause, and guardian control map before treating Upgrade 16 as operative.",
        "Verify the final governance payload and deployed contract state after execution; the expanded bounty does not establish safety or approval."
      ],
      "followUpOn": "2025-07-03",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-c19565abc09765d14a49bfc6",
      "stableKey": "aave-v3:soneium:v3.3-activation-2025-05",
      "version": 1,
      "eventDate": "2025-05-29",
      "publishedAt": "2026-08-22T14:05:42.200Z",
      "title": "Aave proposes activating v3.3 on Soneium",
      "category": "launch_access",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Aave V3.3 Soneium Activation",
          "authority": "Aave Governance",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=319",
          "documentType": "onchain_governance_proposal",
          "publishedOn": "2025-05-29"
        }
      ],
      "whatHappened": "Aave proposal 319 opened to activate V3.3 on Soneium and list USDCe, USDT, and WETH.",
      "whatChanged": "The proposal created a path to a new chain instance with Risk Steward risk-admin, Guardian pool-admin, and ACI emission-admin authority.",
      "whatDidNotChange": "No May evidence established vote completion, execution, a live pool, or Ketju approval of the instance or assets.",
      "confirmedFacts": [
        "The proposed reserves were USDCe, USDT, and WETH.",
        "Proposed supply caps were 8 million USDCe, 5 million USDT, and 800 WETH.",
        "The Guardian would hold pool-admin authority during bootstrap."
      ],
      "unresolved": [
        "The vote result after May 31.",
        "Execution and final reserve, oracle, and administrator state.",
        "Soneium bridge, sequencer, liquidity, and emergency-control diligence."
      ],
      "advisorDiligenceImplications": [
        "Open a Soneium-specific Aave diligence branch.",
        "Do not extend existing Aave approval to the proposed instance."
      ],
      "followUpOn": "2025-06-03",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-604ddf3802b3a9e29d751c89",
      "stableKey": "coinbase-bridge:base-mainnet-safe-head-delay:2025-05-28",
      "version": 1,
      "eventDate": "2025-05-28",
      "publishedAt": "2026-08-22T14:05:42.200Z",
      "title": "Base recovers from a batching-related safe-head delay",
      "category": "market_stress",
      "posture": "recovered",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "coinbase-bridge",
          "name": "Base canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Base Mainnet | Safe Head Delay",
          "authority": "Base Status",
          "url": "https://status.base.org/incidents/bqgbcfkj9xyv",
          "documentType": "official_status_incident",
          "publishedOn": "2025-05-28"
        }
      ],
      "whatHappened": "Base reported that mainnet safe head trailed unsafe head because of batching-performance problems. Deposits and withdrawals were affected before batches resumed and the incident was resolved.",
      "whatChanged": "Safe-head progression and timely L1-backed confirmation were impaired from 14:40 UTC until resolution at 18:09 UTC.",
      "whatDidNotChange": "Base reported no asset loss, bridge exploit, custody change, role change, or modification to withdrawal and fault-proof rules.",
      "confirmedFacts": [
        "Base identified batching performance as the cause.",
        "Deposits and withdrawals were listed as affected.",
        "Safe-head advancement recovered the same day."
      ],
      "unresolved": [
        "The number and duration of delayed bridge transactions.",
        "The precise root cause and durable remediation.",
        "Recurrence risk after a separate May 21 safe-head lag."
      ],
      "advisorDiligenceImplications": [
        "Review batching and safe-head assumptions in the Base bridge memo.",
        "Retain fee, retry, alternate-RPC, and confirmation-monitoring procedures."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-18de2ee634a830816f575809",
      "stableKey": "aave-v3:ethereum-core:fbtc-onboarding-aip-2025-05",
      "version": 1,
      "eventDate": "2025-05-28",
      "publishedAt": "2026-08-22T14:05:42.200Z",
      "title": "Aave proposes adding FBTC collateral to Ethereum Core",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Add FBTC to Aave v3 Main Market on Ethereum",
          "authority": "Aave Governance",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=318",
          "documentType": "onchain_governance_proposal",
          "publishedOn": "2025-05-28"
        }
      ],
      "whatHappened": "Aave proposal 318 opened to list FBTC as borrowable collateral and create an FBTC-to-WBTC E-mode.",
      "whatChanged": "Execution would add FBTC bridge, custody, redemption, liquidity, and oracle dependencies with 200/100 FBTC supply and borrow caps.",
      "whatDidNotChange": "No May evidence established vote completion or execution, and FBTC did not become Ketju-approved.",
      "confirmedFacts": [
        "Proposed LTV and liquidation threshold were 73% and 78%.",
        "The proposal specified Chainlink SVR BTC/USD pricing.",
        "The proposed E-mode used 84% LTV and 86% liquidation threshold."
      ],
      "unresolved": [
        "The vote and execution after May 31.",
        "Final oracle, cap, and E-mode state.",
        "FBTC custody, redemption, concentration, and stressed-liquidity risks."
      ],
      "advisorDiligenceImplications": [
        "Review FBTC’s custody and cross-chain trust model.",
        "Require executed-state and liquidity verification before considering exposure."
      ],
      "followUpOn": "2025-06-03",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-b78a1d7c8d2302aa22b07ed3",
      "stableKey": "aave-v3:celo:weth-onboarding-aip-2025-05",
      "version": 1,
      "eventDate": "2025-05-28",
      "publishedAt": "2026-08-22T14:05:42.200Z",
      "title": "Aave proposes WETH collateral for its Celo market",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Onboarding WETH to Aave V3 Celo Instance",
          "authority": "Aave Governance",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=317",
          "documentType": "onchain_governance_proposal",
          "publishedOn": "2025-05-28"
        }
      ],
      "whatHappened": "Aave proposal 317 opened to add Celo-native bridged WETH as borrowable collateral.",
      "whatChanged": "Execution would add a 500 WETH supply cap, 450 WETH borrow cap, 78% LTV, 80% liquidation threshold, and Chainlink ETH/USD pricing.",
      "whatDidNotChange": "The May record did not establish vote completion, execution, reserve activation, or Ketju approval of Aave Celo or Celo WETH.",
      "confirmedFacts": [
        "The reserve would be borrowable and collateral-enabled.",
        "The asset depends on Celo’s OP Stack Standard Bridge.",
        "The proposed liquidation bonus was 7.5%."
      ],
      "unresolved": [
        "The vote and execution after May 31.",
        "Final reserve and oracle state.",
        "Celo bridge, sequencer, concentration, liquidity, and exit-path risks."
      ],
      "advisorDiligenceImplications": [
        "Review Celo-specific dependencies separately from other Aave markets.",
        "Do not infer suitability from WETH familiarity or Aave governance."
      ],
      "followUpOn": "2025-06-03",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-de8f5e95fa8c3878ced0b9e6",
      "stableKey": "lido:lip-28:dual-governance-approval-2025-05",
      "version": 1,
      "eventDate": "2025-05-28",
      "publishedAt": "2026-08-22T14:05:42.200Z",
      "title": "Lido approves the Dual Governance rollout design",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        },
        {
          "type": "controller",
          "id": "lido-dao",
          "name": "Lido DAO and Dual Governance"
        }
      ],
      "primaryDocuments": [
        {
          "title": "LIP-28 Dual Governance",
          "authority": "Lido Governance Forum",
          "url": "https://research.lido.fi/t/lip-28-dual-governance/10032",
          "documentType": "official_governance_record",
          "publishedOn": "2025-05-08"
        }
      ],
      "whatHappened": "Lido voters approved LIP-28’s final implementation, parameters, and committee structure.",
      "whatChanged": "The approval authorized a dynamic timelock through which stETH holders can delay motions and ultimately block execution until a rage quit completes.",
      "whatDidNotChange": "No May evidence established deployment, role transfer, live escrow, or active veto protection.",
      "confirmedFacts": [
        "The first-seal threshold was proposed at 1% of Lido Ethereum TVL.",
        "The second seal was 10%.",
        "Emergency, reseal, and tiebreaker committees were included."
      ],
      "unresolved": [
        "The later Aragon vote and execution.",
        "Final thresholds, signer sets, permissions, and GateSeal configuration.",
        "Behavior during mass withdrawal or committee failure."
      ],
      "advisorDiligenceImplications": [
        "Review governance, timelock, committee, and withdrawal-capacity assumptions.",
        "Verify deployed contracts and roles before treating Dual Governance as operative."
      ],
      "followUpOn": "2025-06-02",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-35a287629111f772a58d08d4",
      "stableKey": "lido:apm-committee:approval-2025-05",
      "version": 1,
      "eventDate": "2025-05-28",
      "publishedAt": "2026-08-22T14:05:42.200Z",
      "title": "Lido approves an Auxiliary Proposer Mechanisms Committee",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        },
        {
          "type": "controller",
          "id": "lido-apm-committee",
          "name": "Lido Auxiliary Proposer Mechanisms Committee"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Establishing the APM Committee",
          "authority": "Lido Governance Forum",
          "url": "https://research.lido.fi/t/establishing-the-apm-committee/9998",
          "documentType": "official_governance_record",
          "publishedOn": "2025-05-02"
        }
      ],
      "whatHappened": "Lido approved a six-member committee to review and maintain the mechanisms node operators may use.",
      "whatChanged": "The approval created an allowlist process using 5-of-6 consensus, public rationale, and a seven-day review period.",
      "whatDidNotChange": "No particular mechanism, validator key, asset transfer, or withdrawal change was approved.",
      "confirmedFacts": [
        "The committee has six voting members.",
        "Its decision threshold is 5-of-6.",
        "Decisions require public disclosure and a seven-day review."
      ],
      "unresolved": [
        "Final operational and repository controls.",
        "The first approved and rejected mechanisms.",
        "Compliance monitoring and enforcement."
      ],
      "advisorDiligenceImplications": [
        "Add the committee to Lido’s validator-control map.",
        "Monitor membership, decisions, approved mechanisms, and enforcement."
      ],
      "followUpOn": "2025-06-11",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-178f4934c24f8ffed4ca213f",
      "stableKey": "lido:csm-v2:architecture-fees-approval-2025-05",
      "version": 1,
      "eventDate": "2025-05-28",
      "publishedAt": "2026-08-22T14:05:42.200Z",
      "title": "Lido approves the CSM v2 architecture and fee structure",
      "category": "upgrade_migration",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "LIP-29: Community Staking Module v2",
          "authority": "Lido Governance Forum",
          "url": "https://research.lido.fi/t/community-staking-module/5917/117",
          "documentType": "official_governance_record",
          "publishedOn": "2025-05-08"
        }
      ],
      "whatHappened": "Lido voters approved the proposed CSM v2 architecture and fee structure.",
      "whatChanged": "The approval authorized configurable operator types and gates, enhanced performance-oracle inputs, strikes-based ejection, EIP-7002 support, and differentiated rewards.",
      "whatDidNotChange": "The Snapshot did not enact CSM v2 within May, migrate operators, change live contracts, or prove the design safe in production.",
      "confirmedFacts": [
        "The design introduced permissionless and vetted gates.",
        "Performance accounting adds block-proposal and sync-committee inputs.",
        "A strikes-based validator-ejection mechanism was included."
      ],
      "unresolved": [
        "The later on-chain enactment.",
        "Final contracts, parameters, ownership, weights, thresholds, and fee curves.",
        "Migration and effects on concentration, queue access, and false ejections."
      ],
      "advisorDiligenceImplications": [
        "Review CSM allocation, oracle, ejection, gate, concentration, and fee assumptions.",
        "Require final code, audits, execution, and production monitoring."
      ],
      "followUpOn": "2025-06-02",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-55d29fd00b1160356820c845",
      "stableKey": "aave-v3:ethereum-core:eusde-collateral-arfc-approval-2025-04",
      "version": 2,
      "eventDate": "2025-05-26",
      "publishedAt": "2026-08-22T14:05:42.200Z",
      "title": "Aave approves eUSDe and two dated PT collaterals for Ethereum Core",
      "category": "economic_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Onboard eUSDe and eUSDe-based PT tokens to Aave V3 Core",
          "authority": "Aave Governance",
          "url": "https://app.aave.com/governance/v3/proposal/?proposalId=316",
          "documentType": "onchain_governance_proposal",
          "publishedOn": "2025-05-22"
        }
      ],
      "whatHappened": "Aave governance approved a payload covering eUSDe, PT-USDe-31JUL2025, and PT-eUSDe-14AUG2025 collateral configurations.",
      "whatChanged": "The earlier eUSDe ARFC approval advanced to on-chain authorization and expanded to two dated principal-token collaterals using capped, maturity-aware oracles and E-modes.",
      "whatDidNotChange": "Execution and final reserve state were not established within May, and none of the assets became Ketju-approved.",
      "confirmedFacts": [
        "eUSDe used a 550 million supply cap and 90%/93% stablecoin E-mode parameters.",
        "PT-USDe-31JUL2025 used a 40 million supply cap.",
        "PT-eUSDe-14AUG2025 was included in the payload."
      ],
      "unresolved": [
        "Execution and final reserve, oracle, and E-mode state.",
        "Ethereal withdrawal, owner, backing, and concentration risks.",
        "PT liquidity, maturity handling, oracle behavior, and stressed liquidations."
      ],
      "advisorDiligenceImplications": [
        "Supersede the April ARFC-stage entry with an approved-but-unverified execution posture.",
        "Review eUSDe and both PT assets as separate dependencies."
      ],
      "followUpOn": "2025-06-02",
      "previousInterpretation": "The April record described eUSDe as approved only at the ARFC stage, with no on-chain authorization or dated-PT payload established.",
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-cb88041553f08c0e34bb5eeb",
      "stableKey": "aave-v3:ethereum-core:wstlink-temp-check-approval-2025-05",
      "version": 1,
      "eventDate": "2025-05-26",
      "publishedAt": "2026-08-22T14:05:42.200Z",
      "title": "Aave advances proposed wstLINK collateral to ARFC",
      "category": "governance",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[TEMP-CHECK] Onboard wstLINK to Aave v3 Core Instance",
          "authority": "Aave Governance Forum",
          "url": "https://governance.aave.com/t/temp-check-onboard-wstlink-to-aave-v3-core-instance/22007",
          "documentType": "official_governance_record",
          "publishedOn": "2025-05-09"
        }
      ],
      "whatHappened": "Aave’s TEMP CHECK for wstLINK collateral passed Snapshot quorum and advanced to ARFC.",
      "whatChanged": "The proposal entered formal risk review for an asset with staking, unbonding, liquidity, node-operator, and wrapper dependencies.",
      "whatDidNotChange": "No parameters, AIP, execution, reserve listing, or collateral enablement was approved.",
      "confirmedFacts": [
        "YAE won with 595,700 votes.",
        "The result was posted May 26.",
        "The stated next step was an ARFC."
      ],
      "unresolved": [
        "Final ARFC parameters and vote.",
        "Any AIP and execution.",
        "wstLINK staking, withdrawal, oracle, concentration, and liquidation-liquidity risks."
      ],
      "advisorDiligenceImplications": [
        "Require complete LINK-staking and wrapper analysis.",
        "Do not treat the TEMP CHECK as a live listing or client approval."
      ],
      "followUpOn": "2025-06-09",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-f779f63b4ac8cf7e7db1369a",
      "stableKey": "aave-v3:risk-oracle:cap-automation-constraints-2025-05",
      "version": 1,
      "eventDate": "2025-05-20",
      "publishedAt": "2026-08-22T14:05:42.200Z",
      "title": "Aave proposes tighter constraints for automated supply and borrow caps",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        },
        {
          "type": "oracle",
          "id": "aave-cap-risk-oracle",
          "name": "Aave Supply and Borrow Cap Risk Oracle"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC-Addendum] Supply and Borrow Cap Risk Oracle Constraint Specification",
          "authority": "Aave Governance Forum / Chaos Labs",
          "url": "https://governance.aave.com/t/arfc-addendum-supply-and-borrow-cap-risk-oracle-constraint-specification/22074",
          "documentType": "official_governance_proposal",
          "publishedOn": "2025-05-15"
        }
      ],
      "whatHappened": "Chaos Labs proposed criteria defining which reserves may receive automated cap changes.",
      "whatChanged": "Young assets, E-mode-only collateral, and smaller markets would be excluded from some or all automated adjustments and return to manual review.",
      "whatDidNotChange": "The primary record did not establish a completed vote, execution, changed cap value, or changed Risk Steward authority.",
      "confirmedFacts": [
        "The framework already operated on Avalanche, Base, and Arbitrum.",
        "Assets younger than 30 days would be excluded.",
        "E-mode-only collateral would be excluded from automated increases.",
        "Markets below $5 million would be excluded from automated increases and decreases."
      ],
      "unresolved": [
        "The final vote and implementation payload.",
        "The enforcing code or configuration.",
        "Manual-review latency during fast market changes."
      ],
      "advisorDiligenceImplications": [
        "Review the boundary between automated and manual cap authority.",
        "Verify executed configuration and exception handling before treating the safeguards as operative."
      ],
      "followUpOn": "2025-06-02",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-612ba483f62533f3c04a882b",
      "stableKey": "optimism-superchain:upgrade-15a:isthmus-prestate-blob-fix:2025-04",
      "version": 2,
      "eventDate": "2025-05-09",
      "publishedAt": "2026-08-22T14:05:42.200Z",
      "title": "Optimism activates the Isthmus hardfork across OP Mainnet and Base",
      "category": "upgrade_migration",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "optimism-bridge",
          "name": "Optimism canonical bridge"
        },
        {
          "type": "protocol",
          "id": "coinbase-bridge",
          "name": "Base canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Optimism Brings Ethereum’s Pectra Upgrade to the Superchain",
          "authority": "Optimism / OP Labs",
          "url": "https://optimism.io/blog/optimism-brings-ethereum-s-pectra-upgrade-to-the-superchain",
          "documentType": "official_upgrade_release",
          "publishedOn": "2025-05-09"
        }
      ],
      "whatHappened": "OP Labs reported successful activation of Isthmus across the Superchain, including OP Mainnet and Base.",
      "whatChanged": "The watched chains became live on the Isthmus release, adding Pectra-derived functionality including EIP-7702 account delegation and blob-scaling changes.",
      "whatDidNotChange": "The release did not establish that either bridge became lower risk and reported no bridge-custody, pause-authority, withdrawal-owner, or governance-role change.",
      "confirmedFacts": [
        "OP Labs dated activation to May 9, 2025.",
        "Base and OP Mainnet were expressly included.",
        "The release identified EIP-7702 functionality and increased blob capacity."
      ],
      "unresolved": [
        "Independent verification of the final upgrade payloads and dispute-game prestates.",
        "Unexpected withdrawal-proof or fault-dispute behavior.",
        "Operator completion of required version migrations."
      ],
      "advisorDiligenceImplications": [
        "Supersede the proposal-stage interpretation in both bridge diligence files.",
        "Verify deployed implementations, dispute-game configuration, withdrawal proofs, and operator-version coverage."
      ],
      "followUpOn": null,
      "previousInterpretation": "Upgrade Proposal 15A was previously recorded as proposed and not operative.",
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-61e393035d28d5218a322a34",
      "stableKey": "aave-v3:aptos-mainnet:arfc-snapshot-2025-04-30",
      "version": 1,
      "eventDate": "2025-04-30",
      "publishedAt": "2026-08-22T14:05:41.464Z",
      "title": "Aave advances its proposed first non-EVM deployment on Aptos",
      "category": "governance",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Aave V3 Deployment on Aptos Mainnet",
          "authority": "Aave Governance Forum",
          "url": "https://governance.aave.com/t/arfc-aave-v3-deployment-on-aptos-mainnet/21823",
          "documentType": "official_governance_proposal",
          "publishedOn": "2025-04-16"
        }
      ],
      "whatHappened": "Aave completed risk-provider parameter updates for a proposed Aptos Mainnet deployment and escalated the ARFC to an off-chain governance vote scheduled to begin May 1.",
      "whatChanged": "A concrete governance path opened for Aave's first non-EVM market, built in Move rather than ported directly from the EVM codebase. The proposed initial control model includes a sandboxed launch and a jointly held Aave Guardian role for emergency actions.",
      "whatDidNotChange": "No Aptos mainnet market launched during April, the Snapshot had not begun by the event-date cutoff, and no AIP or executed deployment was established.",
      "confirmedFacts": [
        "The proposal describes the Aptos implementation as a from-scratch Move deployment rather than a direct Aave v3.3 code port.",
        "The proposed initial asset set and risk parameters were updated on April 30.",
        "Aave Labs stated that Aave Labs and Aptos Foundation would jointly retain the Guardian role for approximately six months, including freeze authority through a multisig.",
        "The official forum states that the proposal was escalated to an ARFC Snapshot scheduled to start after April 30."
      ],
      "unresolved": [
        "The Snapshot outcome, subsequent AIP, and deployment transaction.",
        "Completion and results of all audits and security competitions.",
        "Final Guardian address, signers, threshold, operating procedures, and transition to DAO-selected governance.",
        "Whether Move-specific upgrade, oracle, liquidation, and tooling differences are fully captured in Aave diligence."
      ],
      "advisorDiligenceImplications": [
        "Open a distinct Aptos control and architecture workstream within Aave diligence; do not inherit EVM-market conclusions without verification.",
        "Review the proposed joint Guardian and permissioned-launch controls before any Aptos market could enter the Ketju approval perimeter.",
        "Do not treat the April proposal as a live or approved client venue."
      ],
      "followUpOn": "2025-05-06",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": false
    },
    {
      "id": "event-event-draft-3de5a4e859e4ccea3e24ef1d",
      "stableKey": "aave-v3:tron-deployment:temp-check-approval-2025-04",
      "version": 1,
      "eventDate": "2025-04-29",
      "publishedAt": "2026-08-22T14:05:41.464Z",
      "title": "Aave advances a proposed v3 deployment on Tron",
      "category": "governance",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[TEMP CHECK] Deploy Aave v3 on Tron",
          "authority": "Aave Governance Forum",
          "url": "https://governance.aave.com/t/temp-check-deploy-aave-v3-on-tron/21853",
          "documentType": "official_governance_record",
          "publishedOn": "2025-04-18"
        }
      ],
      "whatHappened": "Aave's preliminary governance poll approved advancing a proposed Aave V3 deployment on Tron Mainnet to the ARFC and risk-review stage.",
      "whatChanged": "Tron entered Aave's formal deployment-review pipeline, creating a prospective new chain, governance, oracle, asset, and liquidity perimeter for the watched protocol.",
      "whatDidNotChange": "The TEMP CHECK did not approve final risk parameters, authorize an AIP, deploy contracts, or create a live Aave market on Tron.",
      "confirmedFacts": [
        "The TEMP CHECK Snapshot passed on April 29 with quorum and YAE as the winning option.",
        "The proposal sought a Tron Mainnet Aave V3 deployment.",
        "Tron DAO stated an intention to provide launch liquidity, but no amount was specified at the TEMP CHECK stage.",
        "The official record identifies ARFC analysis and a later AIP as required subsequent stages."
      ],
      "unresolved": [
        "Tron's technical compatibility, governance concentration, legal, oracle, bridge, and asset risks.",
        "Final asset set, risk parameters, liquidity commitments, and control structure.",
        "ARFC and AIP outcomes and any eventual deployment verification.",
        "Whether the proposed market would ever enter Ketju's approved exposure perimeter."
      ],
      "advisorDiligenceImplications": [
        "Monitor the ARFC for primary technical and risk-provider analysis, especially Tron governance and execution differences.",
        "Do not treat preliminary approval as a live market or extend existing Aave approval to Tron.",
        "Create no client exposure until separate chain, asset, liquidity, oracle, and operational diligence is complete."
      ],
      "followUpOn": "2025-05-15",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-434b915d62ca28f010d8c25b",
      "stableKey": "lido:liquidity-observation-lab:easy-track-limit-6000-6mo-approval-2025-04",
      "version": 1,
      "eventDate": "2025-04-28",
      "publishedAt": "2026-08-22T14:05:41.464Z",
      "title": "Lido approves a higher Easy Track limit for the Liquidity Observation Lab",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Increasing LOL ET Limits to align with Lido Ecosystem BORG Foundation Grant Funding Request",
          "authority": "Lido Governance Forum",
          "url": "https://research.lido.fi/t/increasing-lol-et-limits-to-align-with-egg-lido-ecosystem-borg-foundation-grant-funding-request/9881",
          "documentType": "official_governance_record",
          "publishedOn": "2025-04-03"
        }
      ],
      "whatHappened": "Lido's Snapshot approved increasing the Easy Track security limit for stETH transfers to the Liquidity Observation Lab multisig from 2,100 stETH per three months to 6,000 stETH per six months.",
      "whatChanged": "The approval created a path to raise the amount transferable through the existing Easy Track recipient and top-up controls and lengthen the budget-reset period, materially changing the magnitude of the operational transfer authority.",
      "whatDidNotChange": "The April Snapshot did not execute the new limit, approve additional grant funding, change the recipient multisig, or itself transfer stETH.",
      "confirmedFacts": [
        "The official forum reports that the Snapshot ended and passed on April 28.",
        "The approved limit was 6,000 stETH for each six-month period.",
        "The prior limit was 2,100 stETH for each three-month period.",
        "The stated purpose was to align the security threshold with an already approved Liquidity Observation Lab grant."
      ],
      "unresolved": [
        "The final Aragon payload, vote, and execution transaction.",
        "The exact post-execution factory configuration and spent-amount state.",
        "Whether the higher threshold changes operational loss severity or multisig-control assumptions.",
        "Actual transfers made under the expanded limit."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido memo's Easy Track and Liquidity Observation Lab multisig control map because the approved transfer magnitude is materially higher.",
        "Verify the final on-chain factory parameters, recipient, reset period, and execution before treating the limit as operative.",
        "Do not conflate the higher security threshold with new funding approval or evidence that multisig risk decreased."
      ],
      "followUpOn": "2025-05-24",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-4d340e4a6db8e4b18e6ba67f",
      "stableKey": "aave-v3:ethereum-core:eusde-collateral-arfc-approval-2025-04",
      "version": 1,
      "eventDate": "2025-04-27",
      "publishedAt": "2026-08-22T14:05:41.464Z",
      "title": "Aave approves eUSDe collateral parameters at the ARFC stage",
      "category": "economic_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Onboard eUSDe to Aave v3 Core Instance",
          "authority": "Aave Governance Forum",
          "url": "https://governance.aave.com/t/arfc-onboard-eusde-to-aave-v3-core-instance/21766",
          "documentType": "official_governance_record",
          "publishedOn": "2025-04-11"
        }
      ],
      "whatHappened": "Aave's ARFC Snapshot approved advancing eUSDe as collateral on the Ethereum Core instance with a 150 million supply cap and a dedicated stablecoin E-mode.",
      "whatChanged": "A concrete AIP path opened for eUSDe collateral and highly leveraged eUSDe-versus-stablecoin borrowing. The proposal introduced dependence on Ethereal's pre-deposit vault, its USDe backing, its owner controls, and CAPO pricing.",
      "whatDidNotChange": "The ARFC approval did not execute a reserve listing. eUSDe remained outside Ketju's approved asset set, and proposed owner renunciation and later Ethereal functionality were not confirmed as complete.",
      "confirmedFacts": [
        "The ARFC Snapshot passed on April 27 with quorum and YAE as the winning option.",
        "The proposed eUSDe supply cap was 150 million and eUSDe was not borrowable.",
        "The proposed E-mode LTV and liquidation threshold were 90% and 93%.",
        "The official risk review identified a 2-of-3 owner that could pause deposits or withdrawals and high holder concentration."
      ],
      "unresolved": [
        "The final AIP payload, execution, and deployed parameters.",
        "Whether the eUSDe owner was renounced to the zero address before onboarding.",
        "Future changes when Ethereal moved beyond its pre-deposit phase.",
        "Live liquidity, redemption, oracle, concentration, and liquidation behavior under stress."
      ],
      "advisorDiligenceImplications": [
        "Review the Aave memo for the proposed eUSDe vault, owner, withdrawal-pause, USDe, CAPO, and E-mode dependencies.",
        "Require owner-state, oracle, cap, and executed-payload verification before treating the reserve as operative.",
        "Do not infer that Aave governance approval makes eUSDe or leveraged E-mode positions suitable for clients."
      ],
      "followUpOn": "2025-05-15",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": false
    },
    {
      "id": "event-event-draft-4f6601bd0ec85591220ae7a0",
      "stableKey": "aave-v3:ethereum-core:usdtb-borrow-reserve-arfc-approval-2025-04",
      "version": 1,
      "eventDate": "2025-04-27",
      "publishedAt": "2026-08-22T14:05:41.464Z",
      "title": "Aave approves borrow-only USDtb onboarding at the ARFC stage",
      "category": "economic_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Onboard USDtb to Aave v3 Core Instance",
          "authority": "Aave Governance Forum",
          "url": "https://governance.aave.com/t/arfc-onboard-usdtb-to-aave-v3-core-instance/21746",
          "documentType": "official_governance_record",
          "publishedOn": "2025-04-09"
        }
      ],
      "whatHappened": "Aave's ARFC Snapshot approved advancing USDtb as a borrow-enabled, non-collateral reserve on the Ethereum Core instance.",
      "whatChanged": "A concrete AIP path opened for a USDtb reserve with a 50 million supply cap, 40 million borrow cap, and an interest-rate curve intended to deepen borrowing liquidity for stablecoin leverage strategies.",
      "whatDidNotChange": "The ARFC approval did not deploy the reserve, enable USDtb as collateral, execute final parameters, or add USDtb to Ketju's approved assets.",
      "confirmedFacts": [
        "The ARFC Snapshot passed on April 27 with quorum and YAE as the winning option.",
        "USDtb was proposed as borrowable but not collateral-enabled.",
        "The proposed supply and borrow caps were 50 million and 40 million.",
        "The official risk review identified concentrated Ethena-linked holdings, KYC-gated direct redemption, custodian reliance, and BUIDL and stablecoin reserves."
      ],
      "unresolved": [
        "The final AIP payload, vote, and execution.",
        "Live deposit concentration, borrow utilization, secondary liquidity, and redemption performance.",
        "Final reserve composition, custodian exposure, and cross-chain dependencies at execution.",
        "Whether the proposed reserve affects approved GHO-market liquidity or risk in practice."
      ],
      "advisorDiligenceImplications": [
        "Review the Aave memo's reserve and counterparty-risk map for USDtb, BUIDL, Pallas entities, custodians, and KYC-gated redemption.",
        "Verify the final AIP, executed caps, oracle, and live liquidity before treating USDtb as an operative Aave reserve.",
        "Keep Ketju's approved Aave exposure and USDtb asset suitability as separate decisions."
      ],
      "followUpOn": "2025-05-15",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-74a88226dd14e13fe31c14b4",
      "stableKey": "optimism-superchain:upgrade-15a:isthmus-prestate-blob-fix:2025-04",
      "version": 1,
      "eventDate": "2025-04-25",
      "publishedAt": "2026-08-22T14:05:41.464Z",
      "title": "Optimism proposes Isthmus prestate and blob-proof updates for OP Mainnet and Base",
      "category": "upgrade_migration",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "optimism-bridge",
          "name": "Optimism canonical bridge"
        },
        {
          "type": "protocol",
          "id": "coinbase-bridge",
          "name": "Base canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Upgrade Proposal #15a - Absolute Prestate Updates for Isthmus Activation & Blob Preimage Fix",
          "authority": "Optimism Collective Governance / OP Labs",
          "url": "https://gov.optimism.io/t/upgrade-proposal-15a-absolute-prestate-updates-for-isthmus-activation-blob-preimage-fix/9869",
          "documentType": "official_protocol_upgrade_proposal",
          "publishedOn": "2025-04-25"
        }
      ],
      "whatHappened": "OP Labs proposed updating the absolute prestates used by fault-dispute games on OP Mainnet, Base, Ink, and Unichain, setting the Isthmus activation time and incorporating a fix for incorrect blob preimages.",
      "whatChanged": "If approved and executed, new FaultDisputeGame and PermissionedDisputeGame implementations would use the updated prestate. Node operators, batchers, and challengers would need specified software versions before Isthmus activation.",
      "whatDidNotChange": "The April proposal was not yet executed. It proposed no change to role structures, ossified gas limits, fee controls, or the Standard Rollup Charter.",
      "confirmedFacts": [
        "The proposed Isthmus activation time was May 9, 2025 at 16:00:01 UTC.",
        "The proposal specifies an updated cannon64 absolute prestate and a fix for the incorrect blob-preimages bug.",
        "OP Mainnet, Base, Ink, and Unichain were within the proposed prestate-update scope.",
        "Execution would deploy new dispute-game implementations and update the DisputeGameFactory through the existing proxy-admin-owner paths."
      ],
      "unresolved": [
        "Completion of both governance approval paths and the veto period.",
        "Final payload verification and execution transactions for OP Mainnet and Base.",
        "Whether all relevant node, batcher, and challenger operators upgraded before activation.",
        "Whether the blob-preimage fix or new prestate introduced any unanticipated withdrawal-proof or dispute behavior."
      ],
      "advisorDiligenceImplications": [
        "Review both Optimism and Base bridge memos for the changed fault-proof implementation and required operator versions.",
        "Verify governance completion, deployment transactions, final DisputeGameFactory state, and successful Isthmus activation before treating the change as operative.",
        "The proposal does not itself justify restricting either bridge, but failed or divergent execution would require immediate reassessment."
      ],
      "followUpOn": "2025-05-09",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": false
    },
    {
      "id": "event-event-draft-8f24bbf546f8dda565bc6f99",
      "stableKey": "lido:csm:stake-share-3pct-key-removal-0.02-approval-2025-04",
      "version": 1,
      "eventDate": "2025-04-21",
      "publishedAt": "2026-08-22T14:05:41.464Z",
      "title": "Lido approves conditional CSM expansion and a lower key-removal charge",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Proposal: Update keyRemovalCharge parameter in CSM",
          "authority": "Lido Governance Forum",
          "url": "https://research.lido.fi/t/community-staking-module/5917/104",
          "documentType": "official_control_change_proposal",
          "publishedOn": "2025-03-31"
        },
        {
          "title": "Proposal: CSM stake share limit increase",
          "authority": "Lido Governance Forum",
          "url": "https://research.lido.fi/t/community-staking-module/5917/105",
          "documentType": "official_control_change_proposal",
          "publishedOn": "2025-04-12"
        },
        {
          "title": "CSM parameter-adjustment Snapshot result",
          "authority": "Lido Governance Forum",
          "url": "https://research.lido.fi/t/community-staking-module/5917/111",
          "documentType": "official_governance_result",
          "publishedOn": "2025-04-21"
        }
      ],
      "whatHappened": "Lido's Snapshot approved reducing the Community Staking Module's keyRemovalCharge from 0.05 ETH to 0.02 ETH and conditionally increasing its stakeShareLimit from 2% to 3%.",
      "whatChanged": "The approval authorized a future reduction in the safety charge applied when queued validator keys are removed and created a conditional path to allocate a larger share of Lido stake to CSM.",
      "whatDidNotChange": "Neither parameter changed on-chain in April. The stake-share increase remained conditional on other module and node-operator milestones or a later CSM v2 release.",
      "confirmedFacts": [
        "The Snapshot passed on April 21 with 63.9 million LDO for and one LDO against.",
        "The approved keyRemovalCharge target was 0.02 ETH, based on a conservative 20 Gwei queue-cleanup cost estimate.",
        "The approved stakeShareLimit target was 3%, up from 2%.",
        "The stake-share proposal also called for a 3.75% priorityExitShareThreshold and specified conditions involving SimpleDVT and Pier Two."
      ],
      "unresolved": [
        "The on-chain vote and execution transactions for each parameter.",
        "When or whether the stated conditions for the 3% stake-share limit were met.",
        "Final parameter values if execution was bundled with later CSM or Pectra changes.",
        "The operational effect on queue behavior, node-operator concentration, exits, and module allocation."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido memo's CSM allocation, queue, penalty, and node-operator concentration assumptions.",
        "Verify executed parameter state and satisfaction of the conditional expansion criteria before treating either change as operative.",
        "Continue assessing CSM as a distinct staking-module dependency; governance approval does not establish lower risk."
      ],
      "followUpOn": "2025-05-24",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-d96dfc91e8dec44810ce54bb",
      "stableKey": "aave-v3:sonic:sts-collateral-arfc-approval-2025-04",
      "version": 1,
      "eventDate": "2025-04-14",
      "publishedAt": "2026-08-22T14:05:41.464Z",
      "title": "Aave approves stS collateral parameters for its Sonic market",
      "category": "economic_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Add stS to Aave v3 Sonic Instance",
          "authority": "Aave Governance Forum",
          "url": "https://governance.aave.com/t/arfc-add-sts-to-aave-v3-sonic-instance/21445",
          "documentType": "official_governance_record",
          "publishedOn": "2025-03-15"
        }
      ],
      "whatHappened": "Aave's ARFC Snapshot approved advancing stS as collateral on Aave V3 Sonic, with a 30 million stS supply cap, CAPO pricing, and a high-efficiency stS/wS E-mode configuration.",
      "whatChanged": "The proposal advanced to the AIP stage with concrete collateral, liquidation, cap, oracle, and E-mode parameters. If executed, it would introduce a slashable liquid-staking-token dependency and enable leveraged stS/wS positions.",
      "whatDidNotChange": "The ARFC approval did not list stS on-chain or make the reserve live. It did not change Ketju's approved Aave exposure or establish stS as client-appropriate.",
      "confirmedFacts": [
        "The ARFC vote passed on April 14 with quorum and YAE as the winning option.",
        "The proposed regular-mode stS LTV and liquidation threshold were 66% and 68%.",
        "The proposed stS/wS liquid E-mode LTV and liquidation threshold were 87% and 90%.",
        "The proposal specified a 30 million stS supply cap and CAPO pricing based on the stS exchange rate and S price feed."
      ],
      "unresolved": [
        "The final AIP payload, vote, and execution date.",
        "Live oracle, CAPO, liquidity, liquidation, slashing, and 14-day native-unbonding performance after onboarding.",
        "Whether proposed liquidity commitments materialized.",
        "Whether stS concentration or validator exposure changed before execution."
      ],
      "advisorDiligenceImplications": [
        "Review Aave's Sonic collateral and liquidation dependency map before any stS reserve is treated as acceptable.",
        "Monitor the AIP and verify executed parameters, oracle configuration, caps, and live exit liquidity.",
        "Do not extend Ketju approval from the watched Aave protocol to stS or leveraged Sonic strategies."
      ],
      "followUpOn": "2025-04-30",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-e5961d847827d04ebc494eb9",
      "stableKey": "coinbase-bridge:base-mainnet-transaction-delays:2025-04-09",
      "version": 1,
      "eventDate": "2025-04-09",
      "publishedAt": "2026-08-22T14:05:41.464Z",
      "title": "Base recovers from mainnet transaction delays caused by a batcher backlog",
      "category": "market_stress",
      "posture": "postmortem",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "coinbase-bridge",
          "name": "Base canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Mainnet transaction delays",
          "authority": "Base Status",
          "url": "https://status.base.org/incidents/39v7s5rb39xg",
          "documentType": "official_status_postmortem",
          "publishedOn": "2025-04-09"
        }
      ],
      "whatHappened": "A transaction-volume spike created a Base batcher backlog. The sequencer temporarily reduced block sizes while pending data was submitted to Ethereum, causing some user transactions to be delayed or dropped and some nodes to fall behind.",
      "whatChanged": "For approximately three hours, effective mainnet transaction capacity fell to roughly one-third of its target and users could need to resubmit dropped transactions. The incident exposed batcher throughput and node synchronization as operational dependencies for timely Base bridge use.",
      "whatDidNotChange": "Base reported that user funds were never at risk, normal processing recovered, and no bridge custody, withdrawal contract, dispute-game authority, pause role, or finality rule changed.",
      "confirmedFacts": [
        "The incident began on April 9, 2025 at approximately 01:15 UTC.",
        "The sequencer reduced block sizes to about 20 Mgas versus a 60 Mgas target for roughly three hours.",
        "Some transactions were delayed or dropped from the mempool, and some node operators experienced synchronization problems.",
        "Base reported that the backlog cleared, normal processing resumed, and the incident was fully resolved."
      ],
      "unresolved": [
        "Whether the planned batching and mempool changes were subsequently deployed and independently verified.",
        "The recurrence risk under a comparable transaction-volume or L1-submission backlog.",
        "Whether any bridge-specific transactions experienced materially longer completion than the broader transaction-pool impact described."
      ],
      "advisorDiligenceImplications": [
        "Review the Base bridge memo's operational assumptions for sequencer, batcher, RPC, and node availability.",
        "Preserve transaction resubmission and alternate-RPC procedures in the bridge operating runbook; the resolved event does not independently require restricting the approved bridge."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-b3a166a7f1a2c7c7989139e9",
      "stableKey": "aave-v3:ethereum:chainlink-svr-phase-1:2025-03-29",
      "version": 1,
      "eventDate": "2025-03-29",
      "publishedAt": "2026-08-22T14:05:40.668Z",
      "title": "Aave activates Chainlink SVR on four Ethereum markets",
      "category": "economic_change",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Aave <> Chainlink SVR v1: Phase 1 activation",
          "authority": "Aave Governance / BGD Labs",
          "url": "https://governance.aave.com/t/arfc-aave-chainlink-svr-v1-phase-1-activation/21247",
          "documentType": "official governance and activation record",
          "publishedOn": "2025-03-04"
        }
      ],
      "whatHappened": "Aave activated Chainlink Smart Value Recapture feeds on its Ethereum V3 markets for LBTC, tBTC, LINK, and AAVE.",
      "whatChanged": "The selected markets began using SVR oracle paths that auction liquidation-related oracle extractable value through MEV infrastructure, with fallback feeds and a steward-controlled rollback path. This changed oracle timing, liquidation execution dependencies, and revenue allocation.",
      "whatDidNotChange": "The initial phase excluded ETH, wstETH, WBTC, and other major markets. Standard Chainlink fallback feeds remained available, and the activation did not establish that SVR was risk-free or suitable for other Aave markets.",
      "confirmedFacts": [
        "The activation occurred on March 29, 2025.",
        "The initial markets were LBTC, tBTC, LINK, and AAVE on Aave V3 Ethereum.",
        "The design used fallback feeds and allowed the Protocol Guardian to restore prior oracle feeds through the SVR steward.",
        "The official follow-up reported liquidations through SVR without technical issues or bad-debt accrual during the first observed period."
      ],
      "unresolved": [
        "Longer-term oracle latency, searcher participation, and recapture efficiency were not established at activation.",
        "Expansion to ETH, WBTC, wstETH, or other larger markets remained contingent on later governance and operating evidence.",
        "The event does not resolve broader governance-risk concerns in the Aave memo."
      ],
      "advisorDiligenceImplications": [
        "Review Aave diligence for the new Flashbots and SVR oracle-path dependencies and Guardian rollback authority.",
        "Verify whether any client or approved market consumes an SVR-enabled feed before relying on prior liquidation-mechanics analysis.",
        "Do not generalize the pilot's early operating results to all Aave reserves."
      ],
      "followUpOn": "2025-04-09",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-3e8d1bce0ed0dfab77fffe38",
      "stableKey": "lido:starknet-wsteth:reendorsement-proposal-2025-03",
      "version": 1,
      "eventDate": "2025-03-26",
      "publishedAt": "2026-08-22T14:05:40.668Z",
      "title": "Lido opens a vote to re-endorse Starknet wstETH bridge endpoints",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "mixed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Re-endorsement of wstETH on Starknet",
          "authority": "Lido Governance",
          "url": "https://research.lido.fi/t/re-endorsement-of-wsteth-on-starknet/9725",
          "documentType": "official governance proposal",
          "publishedOn": "2025-03-10"
        }
      ],
      "whatHappened": "Lido governance opened a Snapshot on a Starknet Foundation proposal to recognize new Starknet wstETH bridge endpoints as canonical and transfer governance roles to Lido DAO.",
      "whatChanged": "A concrete governance path was opened for restoring canonical status after a legacy-token migration and prior offboarding. This expanded the Lido research perimeter to the replacement Starknet deployment and its governance-forwarder controls.",
      "whatDidNotChange": "The March event did not itself re-endorse the endpoints, complete the governance-role transfer, or change Ethereum stETH withdrawal mechanics. Ketju's Lido approval remained limited to Ethereum.",
      "confirmedFacts": [
        "The official Lido forum proposal identifies the new and legacy Starknet wstETH contracts and the governance forwarder.",
        "The proposal states that governance roles would transfer to Lido DAO only if the proposal passed.",
        "The Snapshot began on March 26 and was scheduled to end April 3."
      ],
      "unresolved": [
        "The proposal described the migration as complete while also stating that legacy-token migrations continued.",
        "The Network Expansion Committee's technical and process objections had not been resolved during March.",
        "The vote outcome, role-transfer execution, and post-execution verification were not established within the event window."
      ],
      "advisorDiligenceImplications": [
        "Monitor the proposal as a possible new Lido bridge/control surface, not as approval of Starknet wstETH.",
        "Require verified role-transfer transactions and deployment verification before treating the replacement endpoints as canonical.",
        "Do not infer that audits, migration progress, or DAO endorsement would make the bridged asset appropriate for clients."
      ],
      "followUpOn": "2025-04-03",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-2fd34879770d002f668a3a58",
      "stableKey": "aave-v3:bnb:lisusd-onboarding-temp-check-2025-03",
      "version": 1,
      "eventDate": "2025-03-26",
      "publishedAt": "2026-08-22T14:05:40.668Z",
      "title": "Aave advances proposed lisUSD onboarding to ARFC review",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Onboard lisUSD to Aave V3 BNB Instance",
          "authority": "Aave Governance / Aave Chan Initiative",
          "url": "https://governance.aave.com/t/temp-check-onboard-lisusd-to-aave-v3-bnb-instance/21309",
          "documentType": "official governance proposal",
          "publishedOn": "2025-03-07"
        }
      ],
      "whatHappened": "Aave's preliminary governance poll supported advancing a proposal to list lisUSD in the Aave V3 BNB Core pool.",
      "whatChanged": "lisUSD entered Aave's formal asset-onboarding and risk-review pipeline. The proposal would add a new stablecoin reserve if it later passed ARFC and on-chain governance.",
      "whatDidNotChange": "The TEMP CHECK did not authorize or execute a lisUSD reserve, set final risk parameters, or alter Ketju's Ethereum sGHO-only Aave approval.",
      "confirmedFacts": [
        "The official proposal sought to onboard lisUSD to Aave V3 on BNB Chain.",
        "The TEMP CHECK reached quorum and passed on March 26 with ARFC identified as the next stage.",
        "No final reserve parameters were specified at the TEMP CHECK stage."
      ],
      "unresolved": [
        "Asset audits, collateral composition, liquidity concentration, peg resilience, caps, and liquidation parameters required further review.",
        "The separate March 15 LISUSD price deviation was not established by primary evidence and had not been reconciled in this proposal stage.",
        "Final ARFC and on-chain approval remained outstanding."
      ],
      "advisorDiligenceImplications": [
        "Monitor the ARFC for primary risk-provider analysis and final parameters.",
        "Do not treat preliminary governance support as a live or Ketju-approved reserve.",
        "Preserve the March peg observation as an unresolved diligence question rather than a confirmed impairment."
      ],
      "followUpOn": "2025-04-01",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-7e4ce42553899d3ac903b981",
      "stableKey": "lido:lip-27-pectra-compatibility-snapshot-2025-03",
      "version": 1,
      "eventDate": "2025-03-24",
      "publishedAt": "2026-08-22T14:05:40.668Z",
      "title": "Lido advances its Pectra compatibility upgrade",
      "category": "upgrade_migration",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "LIP 27: Ensuring Compatibility with Ethereum's Pectra Upgrade",
          "authority": "Lido Governance",
          "url": "https://research.lido.fi/t/lip-27-ensuring-compatibility-with-ethereum-s-pectra-upgrade/9444",
          "documentType": "official improvement and governance proposal",
          "publishedOn": "2025-01-30"
        }
      ],
      "whatHappened": "Lido's Snapshot supported advancing LIP-27, a compatibility upgrade for Ethereum's Pectra hardfork.",
      "whatChanged": "The plan would increment consensus versions for Lido's Accounting, Validator Exit Bus, and CSM oracles, replace the CS Verifier, and later revise Oracle Report Sanity Checker parameters.",
      "whatDidNotChange": "The March signal did not execute the upgrade. It deliberately excluded new Pectra features such as triggerable withdrawals and validator consolidation, and no deposit pause had fired.",
      "confirmedFacts": [
        "The Snapshot ran March 17–24 and reached quorum with a large majority in favor.",
        "The proposed pre-fork work covered oracle consensus versions and replacement of the CS Verifier.",
        "A separate post-fork vote was contemplated for Oracle Report Sanity Checker parameters.",
        "The proposal described pausing deposits as a fallback if compatibility changes could not be safely approved."
      ],
      "unresolved": [
        "External audits, deployment verification, and the on-chain vote were still pending during March.",
        "The fallback deposit pause had not been invoked.",
        "Final execution timing depended on Ethereum's Pectra schedule and later Lido votes."
      ],
      "advisorDiligenceImplications": [
        "Review Lido diligence because accounting-oracle and verifier behavior are core dependencies of stETH balances and validator accounting.",
        "Monitor for execution and any fallback deposit pause; a pause would require an immediate memo response.",
        "Do not infer compatibility readiness or safety from the preliminary Snapshot alone."
      ],
      "followUpOn": "2025-04-10",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-f4206fdc3867db1bd564dbc6",
      "stableKey": "lido:mev-relay-allowlist-easytrack-proposal-2025-03",
      "version": 1,
      "eventDate": "2025-03-24",
      "publishedAt": "2026-08-22T14:05:40.668Z",
      "title": "Lido advances EasyTrack management of its MEV relay allowlist",
      "category": "control_change",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Introduce EasyTrack Factories for Managing MEV-Boost Relay Allowed List",
          "authority": "Lido Governance",
          "url": "https://research.lido.fi/t/introduce-easytrack-factories-for-managing-mev-boost-relay-allowed-list/9638",
          "documentType": "official control-change proposal",
          "publishedOn": "2025-02-28"
        }
      ],
      "whatHappened": "Lido's Snapshot supported adding EasyTrack factories through which the Relay Maintenance Committee could add, edit, or remove entries in the MEV-Boost Relay Allowed List.",
      "whatChanged": "The proposed design would make EasyTrack's EVMScriptExecutor the allowlist manager and use the Relay Maintenance Committee as trusted caller, replacing a manual multisignature update workflow with challengeable EasyTrack motions.",
      "whatDidNotChange": "The factories and manager-role change were not deployed in March. The Snapshot did not itself modify any relay entry or remove LDO-holder oversight.",
      "confirmedFacts": [
        "Lido node operators are required to use at least one relay from the mandatory category of the allowlist.",
        "The proposal specified Add, Edit, and Remove MEV-Boost relay factories and an EVMScriptExecutor manager role.",
        "The March Snapshot reached quorum and passed.",
        "Security audit and on-chain execution were identified as later prerequisites."
      ],
      "unresolved": [
        "Final factory code, deployed addresses, audit results, and on-chain authorization were pending during March.",
        "The operational effect on challenge periods and emergency-brake procedures required verification after deployment.",
        "No specific relay addition, removal, or reclassification was authorized by this event."
      ],
      "advisorDiligenceImplications": [
        "Review the Lido control map for the proposed manager, trusted-caller, challenge, and emergency-brake paths.",
        "Verify final contracts and on-chain authorization before treating the workflow as operative.",
        "Continue monitoring relay concentration and availability separately from the governance mechanism."
      ],
      "followUpOn": "2025-05-13",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-d135e7090e9671302be12e87",
      "stableKey": "arbitrum-bridge:sky-usds-gateway-router-proposal-2025-03",
      "version": 1,
      "eventDate": "2025-03-20",
      "publishedAt": "2026-08-22T14:05:40.668Z",
      "title": "Sky proposes custom USDS gateway registration in Arbitrum's router",
      "category": "governance",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "arbitrum-bridge",
          "name": "Arbitrum Bridge"
        },
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Register the Sky Custom Gateway contracts in the Router",
          "authority": "Arbitrum DAO Snapshot",
          "url": "https://snapshot.org/#/arbitrumfoundation.eth/proposal/0xdb22a77942eddfea9c826790ac03c3e54a34716c0a9bde846399cffe6046d256",
          "documentType": "governance_proposal",
          "publishedOn": "2025-03-20"
        }
      ],
      "whatHappened": "Arbitrum DAO opened a constitutional Snapshot proposal to register custom USDS and sUSDS gateways in the canonical router used by the official bridge UI.",
      "whatChanged": "A concrete governance path opened for routing two Sky assets through token-specific custom gateways instead of default gateway handling in the official UI.",
      "whatDidNotChange": "The March proposal did not change router state or authorize execution. The custom bridge contracts were already live, while official UI routing remained disabled pending governance.",
      "confirmedFacts": [
        "The proposal identified the Ethereum and Arbitrum custom gateway contracts and USDS and sUSDS token addresses.",
        "The proposal stated that the router configuration still used default gateways and that official bridge UI access was disabled for these tokens.",
        "The March Snapshot record opened a governance vote before later execution stages."
      ],
      "unresolved": [
        "Governance approval, payload verification, and execution were not completed during March.",
        "Independent verification of the final governance payload and router state remained outstanding.",
        "Registration would not itself establish the suitability or solvency of USDS or sUSDS."
      ],
      "advisorDiligenceImplications": [
        "Track the proposal because it would add a token-specific custody and upgrade path to the official Arbitrum bridge interface.",
        "Keep Sky-asset diligence separate from the Arbitrum bridge memo; router registration does not approve either asset.",
        "Require executed router state and verified gateway controls before treating the UI path as operative."
      ],
      "followUpOn": "2025-04-01",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-96aaffde01657d83a411c7ba",
      "stableKey": "optimism-bridge:upgrade-13-opcm-incident-response-proposal-2025-03",
      "version": 1,
      "eventDate": "2025-03-13",
      "publishedAt": "2026-08-22T14:05:40.668Z",
      "title": "Optimism votes on OPCM and fault-proof incident-response changes",
      "category": "upgrade_migration",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "developing",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "optimism-bridge",
          "name": "Optimism canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Upgrade Proposal #13: OPCM and Incident Response improvements",
          "authority": "Optimism Collective Governance / OP Labs",
          "url": "https://gov.optimism.io/t/upgrade-proposal-13-opcm-and-incident-response-improvements/9739/1",
          "documentType": "official protocol-upgrade proposal",
          "publishedOn": "2025-03-07"
        },
        {
          "title": "Voting Cycle Guide #34",
          "authority": "Optimism Collective Governance",
          "url": "https://gov.optimism.io/t/voting-cycle-guide-34/9734",
          "documentType": "official governance process notice",
          "publishedOn": "2025-03-06"
        }
      ],
      "whatHappened": "Optimism opened governance voting on Upgrade Proposal 13, covering OP Contracts Manager, fault-proof incident-response changes, and a DeputyPauseModule.",
      "whatChanged": "The proposal created a concrete path to alter L1 upgrade orchestration, withdrawal-proof validation, dispute-game recovery, and how a designated Pause Deputy could trigger the Superchain-wide withdrawal pause.",
      "whatDidNotChange": "The March vote did not itself deploy the contracts. It did not shorten the seven-day withdrawal challenge period or require node-operator action.",
      "confirmedFacts": [
        "The proposal would introduce per-release OP Contracts Manager instances for batched contract deployment and upgrades.",
        "The proposed OptimismPortal changes separated respected-game selection from retirement timing and changed withdrawal-proof validity checks.",
        "If deployed, the upgrade would invalidate pending L1 withdrawal proofs once, requiring affected users to re-prove rather than lose assets.",
        "The DeputyPauseModule would authorize a dedicated key only to invoke the Superchain-wide pause through the existing control path.",
        "Token House voting was scheduled for March 13–19 with a Citizens' House veto period through March 26."
      ],
      "unresolved": [
        "Final approval after the veto period was not established by the candidate's discovery evidence.",
        "Deployment, final payload verification, and the planned April activation remained outside the March event posture.",
        "Operational criteria and disclosure practices for Pause Deputy key use required continued review."
      ],
      "advisorDiligenceImplications": [
        "Review the Optimism bridge memo for changed withdrawal-proof behavior and incident-response authority before deployment.",
        "Plan for possible re-proving of pending withdrawals during the eventual upgrade window.",
        "Do not treat audits or governance approval as proof that the new controls are risk-free."
      ],
      "followUpOn": "2025-03-26",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-9b32622022c89eb1731adb3e",
      "stableKey": "aave-v3:sonic-deployment:arfc-snapshot-2025-01",
      "version": 2,
      "eventDate": "2025-02-26",
      "publishedAt": "2026-08-22T14:05:40.012Z",
      "title": "Aave opens the final on-chain vote to activate v3.3 on Sonic",
      "category": "launch_access",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Aave V3.3 Sonic Activation",
          "authority": "Aave DAO",
          "url": "https://vote.onaave.com/proposal/?proposalId=257",
          "documentType": "onchain_governance_record",
          "publishedOn": "2025-02-26"
        }
      ],
      "whatHappened": "Aave governance created proposal 257 to activate an Aave v3.3 pool on Sonic with USDC, WETH, and wS.",
      "whatChanged": "The earlier deployment concept advanced to an executable on-chain proposal with initial collateral, borrowing, caps, liquidation parameters, oracle choices, and bootstrap administrator assignments.",
      "whatDidNotChange": "The proposal had not passed or executed by February 28, so it did not create a live advisor-accessible Sonic exposure inside this backfill window.",
      "confirmedFacts": [
        "Proposal 257 was created on February 26, 2025.",
        "It proposed listing USDC, WETH, and wS as borrowable collateral on Sonic.",
        "It proposed assigning the risk steward as RiskAdmin, the guardian as PoolAdmin during bootstrap, and the ACI multisig as emissions admin."
      ],
      "unresolved": [
        "The vote outcome and any execution occurred outside the February event-date boundary and are not drafted here.",
        "Live liquidity, operational performance, and bridge and oracle dependency behavior were not established within the window."
      ],
      "advisorDiligenceImplications": [
        "Update the Aave diligence file to track the concrete Sonic configuration while keeping Sonic outside the approved exposure set pending execution and live-operation evidence.",
        "Review the proposed bootstrap admin roles, oracle choices, and asset caps before any later access decision."
      ],
      "followUpOn": null,
      "previousInterpretation": "The January backfill recorded that Aave had advanced a proposed v3 deployment on Sonic, without a final executable activation payload.",
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-1fd24fad7dc7a5eaf68f7e90",
      "stableKey": "optimism-superchain:upgrade-12:pectra-readiness-2025-02",
      "version": 1,
      "eventDate": "2025-02-25",
      "publishedAt": "2026-08-22T14:05:40.012Z",
      "title": "Optimism proposes Pectra-readiness maintenance for OP Stack chains",
      "category": "upgrade_migration",
      "posture": "proposed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "optimism-bridge",
          "name": "Optimism canonical bridge"
        },
        {
          "type": "protocol",
          "id": "coinbase-bridge",
          "name": "Base canonical bridge"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Upgrade Proposal #12: L1 Pectra Readiness",
          "authority": "Optimism Collective",
          "url": "https://gov.optimism.io/t/upgrade-proposal-12-l1-pectra-readiness/9706",
          "documentType": "official_governance_proposal",
          "publishedOn": "2025-02-25"
        }
      ],
      "whatHappened": "Optimism published Upgrade Proposal #12 to make OP Stack node software, protocol specifications, and L1 fault-proof contracts compatible with Ethereum Pectra.",
      "whatChanged": "A concrete maintenance payload and operator-upgrade requirement entered governance. The proposal identifies EIP-7702 transaction decoding and the EIP-7685 requestsHash header field as breaking inputs that OP Stack software must support.",
      "whatDidNotChange": "Within the February window this was a proposal, not evidence that every OP Stack chain or canonical bridge had completed the upgrade. The proposal says it does not change fee take, governor/servicer roles, ossified gas limits, or related authorization structures.",
      "confirmedFacts": [
        "The official proposal was published on February 25, 2025.",
        "It states that unmodified OP Stack chains could suffer a safe-head stall, sequencing-window expiry, and a large reorganization after Pectra activates on their L1.",
        "It covers node software, protocol specifications, and fault-proof contracts and anticipates no downtime if applied before the relevant L1 activation."
      ],
      "unresolved": [
        "Approval, execution, and chain-by-chain operator adoption were not established within the backfill window.",
        "The manifest does not receipt bridge-specific deployment state for Optimism or Base."
      ],
      "advisorDiligenceImplications": [
        "Require bridge diligence to verify Pectra-ready node and fault-proof deployments before treating the Optimism and Base canonical bridges as operationally unchanged.",
        "Keep current bridge approvals under review until implementation receipts, not merely governance approval, are documented."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-bd3fb4c37ee7cb4cda697db8",
      "stableKey": "aave-v3:aave-collateral:ltv-lt-increase-2025-02",
      "version": 1,
      "eventDate": "2025-02-25",
      "publishedAt": "2026-08-22T14:05:40.012Z",
      "title": "Aave proposes higher AAVE collateral LTV and liquidation thresholds",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "critical",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Update AAVE Token LTV/Liquidation Percentages",
          "authority": "Aave DAO",
          "url": "https://vote.onaave.com/proposal/?proposalId=255",
          "documentType": "onchain_governance_record",
          "publishedOn": "2025-02-25"
        }
      ],
      "whatHappened": "Aave governance created proposal 255 to increase AAVE collateral LTV and liquidation thresholds on Ethereum Core and Arbitrum.",
      "whatChanged": "The executable proposal would raise Ethereum Core AAVE LTV from 66% to 69% and liquidation threshold from 73% to 76%, and Arbitrum AAVE LTV from 63% to 66% and liquidation threshold from 70% to 73%.",
      "whatDidNotChange": "The vote had not closed or executed by February 28, so the on-chain collateral parameters were not yet changed within this backfill window. No other asset or Aave instance was included.",
      "confirmedFacts": [
        "Proposal 255 was created on February 25, 2025 and opened for voting on February 26.",
        "The proposal specifies three-percentage-point increases to both LTV and liquidation threshold on Ethereum Core and Arbitrum.",
        "Its motivation explicitly invokes greater borrowing power, capital efficiency, and a competitive lending environment."
      ],
      "unresolved": [
        "The final vote and execution occurred outside the February event-date boundary and are not drafted here.",
        "The retained proposal does not establish how borrower behavior or AAVE liquidity would respond after any execution."
      ],
      "advisorDiligenceImplications": [
        "Apply the written Aave kill criterion because governance publicly justified collateral-risk parameters partly through capital-efficiency and competitiveness goals.",
        "Treat new Aave exposure as unavailable pending human review of the approval memo; the event workflow itself does not change the memo or transact.",
        "Reassess endogenous-collateral and liquidation assumptions before relying on the proposed higher thresholds."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-50e892be644a5522dcb0ca93",
      "stableKey": "aave-v3:arbitrum:agrs-caps-oracle-activation-2025-02",
      "version": 1,
      "eventDate": "2025-02-25",
      "publishedAt": "2026-08-22T14:05:40.012Z",
      "title": "Aave activates automated supply and borrow cap updates on Arbitrum",
      "category": "control_change",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Caps Risk Oracle Activation on Arbitrum",
          "authority": "Aave DAO",
          "url": "https://vote.onaave.com/proposal/?proposalId=253",
          "documentType": "onchain_governance_record",
          "publishedOn": "2025-02-20"
        }
      ],
      "whatHappened": "Aave governance executed proposal 253, activating the automated Aave Generalized Risk Stewards system for supply and borrow caps on the Arbitrum instance.",
      "whatChanged": "Chaos Labs Edge recommendations can flow through a RiskOracle and AaveStewardCapsInjector to an AGRS contract with RiskAdmin authority. Permissionless propagation is limited to a whitelist, with maximum 30% relative cap changes and a three-day minimum delay.",
      "whatDidNotChange": "The automation is limited to supplyCap and borrowCap for the listed Arbitrum assets; it did not authorize automated LTV, liquidation-threshold, oracle-price, reserve-factor, or collateral-listing changes.",
      "confirmedFacts": [
        "Proposal 253 executed on February 25, 2025.",
        "The new steward received RiskAdmin authority for the Arbitrum instance.",
        "The record lists 15 whitelisted assets and constrains both cap types to 30% relative changes with a three-day minimum delay.",
        "The injector runs through Chainlink Automation and was funded with 50 LINK from the Arbitrum Collector."
      ],
      "unresolved": [
        "The proposal record does not by itself establish the operational reliability or governance accountability of the off-chain Edge recommendation process.",
        "Future cap recommendations and whether they remain aligned with Ketju risk limits require ongoing monitoring."
      ],
      "advisorDiligenceImplications": [
        "Add the Edge RiskOracle, injector, Chainlink Automation, and automated AGRS path to the Aave control map.",
        "Review whether three-day, 30% cap changes alter approved exposure or liquidity assumptions, and monitor actual automated updates."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-2f59a3d9808eef130c515ab3",
      "stableKey": "aave-v3:all-instances:v3.3-upgrade-2025-02",
      "version": 1,
      "eventDate": "2025-02-24",
      "publishedAt": "2026-08-22T14:05:40.012Z",
      "title": "Aave executes the v3.3 upgrade across all active instances",
      "category": "upgrade_migration",
      "posture": "executed",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Upgrade Aave instances to v3.3",
          "authority": "Aave DAO",
          "url": "https://vote.onaave.com/proposal/?proposalId=252",
          "documentType": "onchain_governance_record",
          "publishedOn": "2025-02-19"
        },
        {
          "title": "BGD: Aave v3.3 (feat Umbrella)",
          "authority": "BGD Labs / Aave Governance Forum",
          "url": "https://governance.aave.com/t/bgd-aave-v3-3-feat-umbrella/20129",
          "documentType": "official_protocol_update",
          "publishedOn": "2024-12-10"
        }
      ],
      "whatHappened": "Aave governance executed proposal 252 and upgraded all active Aave v3 instances from v3.2 to v3.3.",
      "whatChanged": "The upgrade replaced pool, configurator, and pool-data-provider implementations; introduced reserve-deficit accounting and deficit-elimination hooks for later Umbrella use; and changed liquidation handling to reduce dust and improve position-wide close-factor behavior.",
      "whatDidNotChange": "Aave v3.3 did not itself activate Umbrella or prove that future deficits would be covered. The official discussion says deficit accounting remains separate from aToken exchange-rate accounting and does not imply safety or approval.",
      "confirmedFacts": [
        "BGD Labs states that proposal 252 was approved and executed on February 24, 2025.",
        "The proposal applied to all active Aave v3 instances.",
        "The upgrade introduced bad-debt logging and burn functionality plus liquidation-engine changes.",
        "The proposal cites StErMi, Certora, Oxorio, and Sherlock security reviews."
      ],
      "unresolved": [
        "Post-upgrade monitoring was still ongoing in the February 24 update.",
        "The behavior of the later Umbrella integration and any realized deficit coverage was outside this event.",
        "Audit completion does not establish absence of defects or advisor suitability."
      ],
      "advisorDiligenceImplications": [
        "Update the Aave memo's liquidation and deficit-accounting description to v3.3 and verify integrations relying on deprecated reserve-data getters.",
        "Do not describe Umbrella coverage as live solely because v3.3 added compatible accounting hooks.",
        "Review client and approved-position assumptions across every active Aave v3 instance because the implementation upgrade was global."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-8c5b1fda1cad4a2c7fb2f207",
      "stableKey": "aave-v3:megaeth-deployment:temp-check-2025-02",
      "version": 1,
      "eventDate": "2025-02-21",
      "publishedAt": "2026-08-22T14:05:40.012Z",
      "title": "Aave proposes a v3 deployment on MegaETH",
      "category": "launch_access",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "TEMP CHECK: Deploy Aave v3 on MegaETH",
          "authority": "Aave DAO",
          "url": "https://governance.aave.com/t/temp-check-deploy-aave-v3-on-megaeth/21155",
          "documentType": "official_governance_forum",
          "publishedOn": "2025-02-21"
        }
      ],
      "whatHappened": "Aave governance opened a TEMP CHECK proposing an Aave v3 pool on MegaETH.",
      "whatChanged": "MegaETH entered Aave's formal deployment-governance pipeline, expanding the potential future research perimeter for Aave v3.",
      "whatDidNotChange": "No Aave deployment, live pool, asset list, risk parameters, oracle configuration, or final approval was established during the February window.",
      "confirmedFacts": [
        "The official forum proposal is dated February 21, 2025.",
        "The proposal is a TEMP CHECK and says risk parameters would be supplied during a later ARFC stage.",
        "The stated process still required Snapshot, ARFC, and final AIP stages before enforcement."
      ],
      "unresolved": [
        "MegaETH infrastructure, oracle availability, deployment addresses, and final risk parameters were not established in this window.",
        "The proposal's later governance outcome falls outside this backfill boundary."
      ],
      "advisorDiligenceImplications": [
        "Monitor the deployment track without adding MegaETH exposure to an approved Aave perimeter.",
        "Require live contracts, deployed-address records, oracle details, and final parameters before any advisor-access assessment."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-1f97a759b7d499cce9c12236",
      "stableKey": "sky-lending:out-of-schedule-community-security:2025-02-18",
      "version": 1,
      "eventDate": "2025-02-19",
      "publishedAt": "2026-08-22T14:05:40.012Z",
      "title": "Sky passes an out-of-schedule security executive with major control and collateral changes",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "mixed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "sky-lending",
          "name": "Sky"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Out-of-Schedule Executive Proposal for Community Security",
          "authority": "Sky Governance Facilitators",
          "url": "https://forum.skyeco.com/t/out-of-schedule-executive-proposal-for-community-security-february-18-2025/26017",
          "documentType": "official_governance_forum",
          "publishedOn": "2025-02-18"
        },
        {
          "title": "Out-of-Schedule Executive Vote: Risk Parameter Changes",
          "authority": "Sky Governance",
          "url": "https://vote.makerdao.com/executive/template-executive-vote-out-of-schedule-executive-vote-risk-parameter-changes-february-18-2025",
          "documentType": "onchain_governance_record",
          "publishedOn": "2025-02-18"
        }
      ],
      "whatHappened": "Sky governance passed an out-of-schedule executive presented as a precaution against a potential governance attack.",
      "whatChanged": "The approved spell would reduce the GSM Pause Delay from 30 to 18 hours and reconfigure LSE-MKR-A: debt ceiling 20 million to 45 million USDS, target available debt 5 million to 45 million, cooldown 16 hours to 30 minutes, stability fee 12% to 20%, liquidation ratio 200% to 125%, and exit fee 5% to 0%.",
      "whatDidNotChange": "Primary evidence did not substantiate the alleged attack vector, identify an attacker, establish asset loss or a protocol freeze, or independently prove the spell's execution and effective state within the retained candidate evidence.",
      "confirmedFacts": [
        "Sky facilitators scheduled the executive on February 18, 2025 and said they believed a successful governance attack was very unlikely.",
        "The official forum and executive record specify the same LSE-MKR-A and GSM Pause Delay changes.",
        "A February 19 official-forum reply links the executive and states that it passed."
      ],
      "unresolved": [
        "The screenshots and whistleblower reports cited by facilitators were not published, so the underlying threat remains unverified.",
        "The execution transaction and exact effective timestamp were not established from the retained primary receipts.",
        "Community participants requested a more specific explanation of how the parameter changes mitigated the reported threat."
      ],
      "advisorDiligenceImplications": [
        "Review the Sky memo's governance-latency and collateral-risk assumptions because the approved package shortened the response delay while substantially loosening LSE-MKR-A leverage constraints.",
        "Do not treat the reported governance attack as confirmed; separately verify spell execution and resulting on-chain parameters before updating operative memo facts."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-364606f9891cb883664a3dbf",
      "stableKey": "axelar:core-v1.2.1:cobalt-fee-burn-2025-02",
      "version": 1,
      "eventDate": "2025-02-17",
      "publishedAt": "2026-08-22T14:05:40.012Z",
      "title": "Axelar approves the v1.2.1 fee-burn upgrade",
      "category": "upgrade_migration",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "axelar",
          "name": "Axelar"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Axelar Core v1.2.1",
          "authority": "Axelar",
          "url": "https://github.com/axelarnetwork/axelar-core/releases/tag/v1.2.1",
          "documentType": "official_release",
          "publishedOn": "2025-02-07"
        },
        {
          "title": "Axelar v1.2 Upgrade Proposal",
          "authority": "Axelar on-chain governance",
          "url": "https://axelarscan.io/proposal/284",
          "documentType": "onchain_governance_record",
          "publishedOn": "2025-02-17"
        }
      ],
      "whatHappened": "Axelar governance passed proposal 284 to upgrade Axelar Core to v1.2.1 at the specified upgrade height.",
      "whatChanged": "The approved software changes transaction-fee allocation so the community-tax portion remains in the community pool and the remainder is burned instead of distributed to token holders.",
      "whatDidNotChange": "The retained primary evidence does not independently establish historical execution at the specified height. It does not show a change to gateway signing thresholds, validator custody, supported-chain security assumptions, or Ketju approval status, and it does not establish that the upgrade made Axelar safer.",
      "confirmedFacts": [
        "Axelar on-chain proposal 284 passed and specifies the v1.2 upgrade at height 16837700.",
        "The proposal states that AXL transaction fees will be sent to a burn address instead of distributed to token holders.",
        "The official release identifies migration, distribution, dependency, and burner-permission changes included in v1.2.1."
      ],
      "unresolved": [
        "The retained evidence does not independently confirm that historical height 16837700 executed successfully.",
        "Any effect of the new fee flow on validator incentives and dependency resilience requires memo review."
      ],
      "advisorDiligenceImplications": [
        "Review the Axelar memo's economic-security and validator-incentive assumptions against the new fee allocation.",
        "Record v1.2.1 as the operative core version for dependency diligence; do not infer a custody or bridge-security improvement from the upgrade alone."
      ],
      "followUpOn": null,
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-b6accbed12e46ca98db6c52c",
      "stableKey": "aave-v3:sonic-deployment:arfc-snapshot-2025-01",
      "version": 1,
      "eventDate": "2025-01-31",
      "publishedAt": "2026-08-22T14:04:59.369Z",
      "title": "Aave advances a proposed v3 deployment on Sonic",
      "category": "launch_access",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[ARFC] Deploy Aave v3 on Sonic",
          "authority": "Aave Governance Forum",
          "url": "https://governance.aave.com/t/arfc-deploy-aave-v3-on-sonic/20543",
          "documentType": "official_governance_proposal",
          "publishedOn": "2025-01-07"
        }
      ],
      "whatHappened": "Aave contributors escalated an ARFC for deploying Aave v3 on Sonic to an off-chain governance vote after infrastructure, liquidity, and risk-provider review.",
      "whatChanged": "The proposal created a concrete path to a new Aave v3 market with WETH, wrapped S, and bridged USDC as initial borrowable collateral reserves under specified caps and liquidation parameters.",
      "whatDidNotChange": "No AIP approval, contract deployment, live market, or client-accessible Sonic exposure was confirmed within the January event window. Existing Aave v3 markets and approvals were unchanged.",
      "confirmedFacts": [
        "The official ARFC targets Sonic mainnet.",
        "The proposed initial reserves are WETH, wrapped S, and USDC.e.",
        "The January 30 specification supplied collateral, liquidation, cap, reserve-factor, and interest-rate parameters.",
        "Aave contributors stated on January 31 that the proposal had been escalated to an ARFC Snapshot."
      ],
      "unresolved": [
        "The ARFC Snapshot result, subsequent AIP outcome, and execution state.",
        "Final deployed addresses and whether the January parameters survive later revisions.",
        "Sonic Gateway, oracle, chain-upgrade, liquidity, and liquidation performance under live conditions."
      ],
      "advisorDiligenceImplications": [
        "Add the proposed Sonic instance to Aave perimeter monitoring without treating it as live or approved.",
        "Require a separate chain, bridge, oracle, liquidity, and deployed-configuration review before any Sonic market could inherit an Aave memo conclusion."
      ],
      "followUpOn": "2025-02-05",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": false
    },
    {
      "id": "event-event-draft-6cdc827b24ebb1f2bbccdbe0",
      "stableKey": "lido:ecosystem-borg-foundation:approval-2025-01",
      "version": 1,
      "eventDate": "2025-01-31",
      "publishedAt": "2026-08-22T14:04:59.369Z",
      "title": "Lido approves the Ecosystem BORG Foundation structure",
      "category": "governance",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Establishment of Lido Ecosystem BORG Foundation as a Lido-DAO-Adjacent Foundation",
          "authority": "Lido Governance Forum",
          "url": "https://research.lido.fi/t/establishment-of-lido-ecosystem-borg-foundation-as-a-lido-dao-adjacent-foundation/9345",
          "documentType": "official_governance_record",
          "publishedOn": "2025-01-16"
        }
      ],
      "whatHappened": "Lido's Snapshot vote approved establishing the Lido Ecosystem BORG Foundation as a Cayman Islands DAO-adjacent entity.",
      "whatChanged": "The approval authorized formation of an entity intended to oversee Rewards Share and Liquidity Observation Lab multisigs, support network expansion and institutional relationships, and create a separately governed operational multisig.",
      "whatDidNotChange": "No budget, treasury transfer, Easy Track factory, operational-multisig signer set, or completed wrapping of existing multisigs was approved or verified in this event.",
      "confirmedFacts": [
        "The official forum reports 56.8 million LDO supporting and 97,800 LDO rejecting the proposal.",
        "The approved structure assigns DAO appointment and removal powers over directors and an emergency supervisor.",
        "The planned scope includes Rewards Share and Liquidity Observation Lab multisigs and a new operational multisig.",
        "Later budgets, Easy Track permissions, signer configurations, and migrations require additional steps."
      ],
      "unresolved": [
        "The foundation's incorporation and final governing documents.",
        "Which existing committees and multisigs are ultimately wrapped.",
        "The operational-multisig address, signers, threshold, limits, and Easy Track controls.",
        "Future budget approvals and actual treasury exposure."
      ],
      "advisorDiligenceImplications": [
        "Add the Ecosystem BORG to Lido's governance and operational-dependency map.",
        "Verify later multisig, bridge-expansion, incentive, budget, and Easy Track implementations before treating the approved structure as operative."
      ],
      "followUpOn": "2025-03-31",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-d3bbee2f4f9006fb817c5e48",
      "stableKey": "lido:labs-borg-foundation:approval-2025-01",
      "version": 1,
      "eventDate": "2025-01-31",
      "publishedAt": "2026-08-22T14:04:59.369Z",
      "title": "Lido approves the Labs BORG Foundation structure",
      "category": "control_change",
      "posture": "approved",
      "materiality": "material",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Establishment of Lido Labs BORG Foundation as a Lido-DAO-Adjacent Foundation",
          "authority": "Lido Governance Forum",
          "url": "https://research.lido.fi/t/establishment-of-lido-labs-borg-foundation-as-a-lido-dao-adjacent-foundation/9344",
          "documentType": "official_governance_record",
          "publishedOn": "2025-01-16"
        }
      ],
      "whatHappened": "Lido's Snapshot vote approved establishing the Lido Labs BORG Foundation as a Cayman Islands DAO-adjacent entity for protocol development, maintenance, governance support, and committee oversight.",
      "whatChanged": "The approval authorized formation of an entity intended to legally oversee committees and multisigs that include GateSeal, Emergency Brakes, Relay Maintenance, Treasury Management, and the Simple DVT and Community Staking modules.",
      "whatDidNotChange": "The vote did not itself transfer on-chain roles, replace signers, move treasury assets, fund the foundation, deploy Easy Track factories, or alter pause, withdrawal, bridge, oracle, or staking-module parameters.",
      "confirmedFacts": [
        "The official forum reports 56.8 million LDO supporting and 87,400 LDO rejecting the proposal.",
        "The approved scope includes protocol research, development, deployment, maintenance, and governance support.",
        "The proposed wrapping perimeter includes multisigs with withdrawal-queue pause, validator-exit pause, bridge emergency, relay, treasury, and staking-module functions.",
        "The Board may oversee and replace wrapped-multisig members under participation agreements, while later on-chain and funding steps remain required."
      ],
      "unresolved": [
        "The foundation's incorporation and final governing documents.",
        "Which listed emergency and operational multisigs are ultimately wrapped.",
        "The directors, emergency supervisor, operational-multisig configuration, and practical replacement process.",
        "Later Easy Track, budget, signer, role, and asset-transfer executions."
      ],
      "advisorDiligenceImplications": [
        "Review Lido's control map as each emergency or staking-module multisig is migrated under the foundation's legal oversight.",
        "Do not describe emergency powers or on-chain authorities as changed until signer, role, threshold, and contract state are verified."
      ],
      "followUpOn": "2025-03-31",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-d7c82e536c22afe71cb9202f",
      "stableKey": "lido:curated-set:attestant-bitwise-continuation-2025-01",
      "version": 1,
      "eventDate": "2025-01-31",
      "publishedAt": "2026-08-22T14:04:59.369Z",
      "title": "Lido approves Attestant's continued operation under Bitwise ownership",
      "category": "governance",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Attestant Joins Bitwise",
          "authority": "Lido Governance Forum",
          "url": "https://research.lido.fi/t/attestant-joins-bitwise/8828",
          "documentType": "official_node_operator_governance_record",
          "publishedOn": "2025-01-16"
        }
      ],
      "whatHappened": "Lido voters approved allowing Attestant BVI Limited to continue operating in the Ethereum Curated Module after its acquisition by Bitwise.",
      "whatChanged": "The governance decision accepted Bitwise as Attestant's new ultimate owner without requiring validator exit or operator removal.",
      "whatDidNotChange": "Attestant and Bitwise stated that the team, bare-metal deployment, geography, jurisdiction, organizational structure, registry address, and validator operations would remain unchanged.",
      "confirmedFacts": [
        "The official forum reports 56.8 million LDO for continuation and 86.04 LDO against.",
        "Attestant's ultimate ownership changed to Bitwise before the January ratification vote.",
        "The operator stated that its team and infrastructure would remain intact.",
        "Bitwise stated that it did not control another Lido node operator at the time of review."
      ],
      "unresolved": [
        "Whether ownership later creates operator concentration or conflicts not present at the vote.",
        "Whether the registry name, reward address, team, infrastructure, jurisdiction, or operating model subsequently changes.",
        "Post-transition performance and compliance with Curated Module requirements."
      ],
      "advisorDiligenceImplications": [
        "Update Lido's node-operator ownership map to show Bitwise control of Attestant.",
        "Continue monitoring operator concentration, registry state, infrastructure, and performance; the approval does not establish that acquisition risk is immaterial indefinitely."
      ],
      "followUpOn": "2025-02-14",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-fa92fbd028f9b086356aecc9",
      "stableKey": "lido:curated-set:solstice-continuation-2025-01",
      "version": 1,
      "eventDate": "2025-01-31",
      "publishedAt": "2026-08-22T14:04:59.369Z",
      "title": "Lido approves Solstice's continued Curated Module operation",
      "category": "governance",
      "posture": "approved",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "lido",
          "name": "Lido"
        }
      ],
      "primaryDocuments": [
        {
          "title": "Bridgetower is now part of Solstice Staking",
          "authority": "Lido Governance Forum",
          "url": "https://research.lido.fi/t/bridgetower-is-now-part-of-solstice-staking/9135",
          "documentType": "official_node_operator_governance_record",
          "publishedOn": "2025-01-16"
        }
      ],
      "whatHappened": "Lido voters approved allowing Solstice to continue the acquired Bridgetower node operation in the Ethereum Curated Module.",
      "whatChanged": "The governance decision accepted Solstice as the operator's new corporate owner and contemplated renaming Curated Module operator number 17.",
      "whatDidNotChange": "The operator stated that the registry address, validator team, on-premise Swiss infrastructure, and delegated staking operations would remain unchanged; the January vote did not itself verify an on-chain rename.",
      "confirmedFacts": [
        "The official forum reports 51.8 million LDO for continuation and 86.74 LDO against.",
        "Solstice acquired Bridgetower's staking division, team, and resources before the January ratification vote.",
        "The operator stated that existing validators would remain managed by the same team on the same infrastructure.",
        "The registry address was expected to remain unchanged, while a name change to Solstice was separately requested."
      ],
      "unresolved": [
        "Execution and verification of the operator-name change.",
        "Whether ownership later changes the team, infrastructure, registry or reward address, jurisdiction, or concentration profile.",
        "Post-transition performance and compliance with Curated Module requirements."
      ],
      "advisorDiligenceImplications": [
        "Update Lido's node-operator ownership map and separately verify any on-chain rename.",
        "Continue monitoring ownership concentration, registry state, infrastructure, and validator performance; the approval does not remove ongoing operator-transition risk."
      ],
      "followUpOn": "2025-02-14",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    },
    {
      "id": "event-event-draft-05b474336e2a9b9177a87791",
      "stableKey": "aave-v3:ethereum-core:pufeth-collateral-temp-check-2025-01",
      "version": 1,
      "eventDate": "2025-01-29",
      "publishedAt": "2026-08-22T14:04:59.369Z",
      "title": "Aave considers pufETH collateral for Ethereum Core",
      "category": "economic_change",
      "posture": "proposed",
      "materiality": "watch",
      "evidenceState": "confirmed",
      "affectedObjects": [
        {
          "type": "protocol",
          "id": "aave-v3",
          "name": "Aave v3"
        }
      ],
      "primaryDocuments": [
        {
          "title": "[TEMP CHECK] Onboard pufETH to Aave V3 Core Instance",
          "authority": "Aave Governance Forum",
          "url": "https://governance.aave.com/t/temp-check-onboard-pufeth-to-aave-v3-core-instance/20770",
          "documentType": "official_governance_proposal",
          "publishedOn": "2025-01-23"
        }
      ],
      "whatHappened": "A pufETH collateral-onboarding TEMP CHECK for Aave v3 Ethereum Core advanced to a Snapshot vote.",
      "whatChanged": "If later approved and executed, Ethereum Core would add liquid-restaking collateral with Puffer, EigenLayer, exchange-rate, withdrawal-liquidity, slashing, and privileged-control dependencies.",
      "whatDidNotChange": "The TEMP CHECK contained no final risk parameters and did not authorize or execute an asset listing. Existing collateral, oracle, liquidation, and borrowing configurations were unchanged.",
      "confirmedFacts": [
        "The target market is Aave v3 Ethereum Core.",
        "The proposal identifies pufETH as a proposed collateral asset.",
        "The official forum states that the TEMP CHECK advanced to Snapshot on January 29.",
        "An Aave-funded risk contributor opposed onboarding at that stage, citing declining supply, reduced liquidity, pricing complexity, double-slashing exposure, and no active bug bounty."
      ],
      "unresolved": [
        "The TEMP CHECK result and whether the proposal advances through ARFC and AIP stages.",
        "Final oracle design, collateral factors, liquidation settings, caps, and e-mode treatment.",
        "Whether pufETH liquidity, withdrawals, incentives, and security controls support the proposed risk parameters."
      ],
      "advisorDiligenceImplications": [
        "Monitor the governance process and require a position-specific collateral and dependency review before treating pufETH as acceptable.",
        "Do not change the existing Aave approval or describe pufETH as supported based on the TEMP CHECK."
      ],
      "followUpOn": "2025-02-05",
      "previousInterpretation": null,
      "supersedesId": null,
      "current": true
    }
  ]
}