The events that can change an advisor’s diligence file.

DeFi Saver tracked TVL declines 27% between observations

Developing record. Confirmed facts and unresolved claims are separated below. This entry will be superseded as primary evidence changes.

What happened

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.

What changed

The aggregate value attributed to positions with active DeFi Saver automation subscriptions decreased by approximately $83.7 million between monitor observations.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• DeFi Saver protocol TVL fell 27% since the last observation, from $309.2M to $225.5M · Ketju quantitative monitor · 2026-08-30

Previous interpretation

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.

Aave v3 GHO Prime Instance deposits fall 40% between checks

What happened

Ketju's quantitative monitor observed deposits in the Ethereum GHO Prime Instance decline from about $12.6 million to $7.6 million between checks.

What changed

Observed venue deposits fell 40%, reducing the liquidity base and warranting an immediate check of exit depth and the cause of the outflow.

What did not change

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.

Confirmed

• 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%.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Aave v3 GHO Prime Instance deposit exodus observation · Ketju quantitative monitor · 2026-08-26

Axelar governance approves axelar-core v1.5.3 upgrade

What happened

Axelar on-chain governance proposal 495 passed, authorizing an upgrade of axelar-core to v1.5.3.

What changed

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.

What did not change

The candidate record does not establish that the upgrade has executed at a block height or that all validators are running the new binary.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Axelar v1.5.3 Upgrade Proposal · Axelar on-chain governance · 2026-08-23

Rocket Pool pDAO approves RocketDash signaling platform and emergency replacement process

What happened

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.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• pDAO Signaling Governance · Rocket Pool pDAO Snapshot · 2026-08-05

Aave ARFC advances broad V3 reserve and deployment wind-down

What happened

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.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• [ARFC] Low Adoption Asset Deprecation on Aave V3 · Aave DAO Snapshot · 2026-08-11

Grove proposes granting Sky PAS administrator authority over DPAU controls

What happened

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.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• [August 27, 2026] - Proposed Changes to Grove for Upcoming Spell · Sky Forum (Grove Labs) · 2026-08-13

Sky proposes reducing Osero's SparkLend USDS capital ratio to 25%

What happened

Sky Core GovOps proposed reducing the Capital Ratio Requirement for Osero's Ethereum SparkLend USDS instance from 100% to 25%.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Atlas Edit Weekly Cycle Proposal - Week Of 2026-08-10 · Sky Forum (Core GovOps) · 2026-08-07

Sky proposes activating its full Treasury Management Function waterfall

What happened

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.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Treasury Management Function (TMF) Configurations · Sky Forum (BA Labs and Core Facilitator) · 2026-08-07

Sky proposes delegated Smart Burn Engine parameter control through SBE BEAM

What happened

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.

What changed

If executed, the operator could jointly change kbump, burn, hop, and rewardsDuration within configured throughput, delay, and cooldown bounds.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Smart Burn Engine Bounded External Access Module (SBE BEAM) launch · Sky Forum (Sidestream, BA Labs, Soter Labs, and Core Facilitator) · 2026-08-06

Sky confirms Prime Agent settlement and oracle-accounting corrections

Developing record. Confirmed facts and unresolved claims are separated below. This entry will be superseded as primary evidence changes.

What happened

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.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Settlement Reconciliation - MSC #5–#10 (January–June 2026) · Sky Forum (Soter Labs) · 2026-08-06

Sky.money adds five live Morpho-based stablecoin vaults outside the existing savings exposure

What happened

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.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• What Are Sky Vaults? · Sky.money / Skybase International · 2026-08-07

Axelar governance executes Moonbeam connection deactivation

What happened

Axelar governance proposal 494 passed and executed a Nexus DeactivateChainRequest for Moonbeam. Axelar's Nexus state reports the Moonbeam connection as inactive.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Deactivate Moonbeam on nexus · Axelar on-chain governance · 2026-08-04

BitGo selects Chainlink CCIP for a planned WBTC cross-chain migration

What happened

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.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• BitGo Selects Chainlink CCIP as Exclusive Cross-Chain Infrastructure Provider for WBTC, Migrating Away From Legacy Solution · BitGo · 2026-08-04

Spark proposes USDG and RLUSD liquidity integrations

What happened

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.

What changed

If executed, Spark would gain new USDG and RLUSD issuer, depeg, pool, and planner-execution exposure under replenishing deposit and swap limits.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• [August 13, 2026] Proposed Changes to Spark for Upcoming Spell · Sky Forum (Phoenix Labs, Spark Risk Council, and BA Labs) · 2026-08-03

Sky proposes delegated Smart Burn Engine controls and new Uniswap functions

What happened

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.

What changed

The proposal defines a new no-executive-vote control path for kbump, hop, and burn settings and expands controller capabilities available to Prime Agents.

What did not change

The proposal was not yet approved or executed. Existing Smart Burn Engine authority and controller functions remained operative pending governance action.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Atlas Edit Weekly Cycle Proposal - Week Of 2026-08-03 · Sky · 2026-07-31

PT-sUSDS becomes live Morpho collateral with Sky vault allocation

What happened

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.

What changed

PT-sUSDS can now support variable-rate USDS borrowing and leveraged looping, and the curated vault can route depositor USDS into the new market.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Using PT-sUSDS as Collateral on Morpho Vaults · Sky · 2026-07-31

Grove proposes lower reserves, higher exposure limits, and new Uniswap capacity

What happened

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.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• [August 13, 2026] - Proposed Changes to Grove for Upcoming Spell · Sky / Grove · 2026-07-30

Axelar approves sharply higher governance proposal deposits

What happened

Axelar governance passed proposal 493 to raise the deposit required to open ordinary and expedited governance proposals.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Increase governance deposit: min_deposit to 150,000 AXL, expedited to 400,000 AXL · Axelar on-chain governance · 2026-07-25

Lido postmortem details SRv3 Accounting Oracle and VEBO incident

Developing record. Confirmed facts and unresolved claims are separated below. This entry will be superseded as primary evidence changes.

What happened

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.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• [Security Disclosure] 25/7/2026 Minor Underreporting of Total Protocol CL-side balances in Accounting Oracle Report · Lido · 2026-07-25

Sky risk advisor proposes an 8 bp SSR cut and 100 bp Core Vault fee increases

What happened

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.

What changed

A concrete rate proposal entered the Sky parameter process and would change both saver yield and borrower costs if executed.

What did not change

The monthly report does not itself prove the poll, BEAM action, or executive execution; no operative rate is inferred from the recommendation.

Confirmed

• 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.

Still unresolved

• Whether the recommendation was approved and executed.
• The exact effective timestamp and resulting live SSR and vault fees.

Advisor diligence implications

• 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.

Primary evidence

• Risk Month in Review: July 2026 · Sky / BA Labs · 2026-07-31

Morpho launches Midnight fixed-rate, fixed-term credit markets

What happened

Morpho launched Midnight, an immutable noncustodial fixed-rate, fixed-term lending protocol, together with a new Markets App.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Now Live: Morpho Midnight & New Markets App · Morpho · 2026-07-21

Spark proposes a 2-of-4 freezer multisig and signer rotation

What happened

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.

What changed

A concrete control-change proposal entered governance review, supplying new evidence about the freezer role's signer composition and intended approval threshold.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• SAEP-18: Update Spark Liquidity Layer Freezer Multisig · Spark governance via Snapshot · 2026-07-20

Lido governance approves CMv2 penalty framework

What happened

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.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Penalty Framework | CMv2 · Lido · 2026-07-06

Aave proposes USDai and sUSDai onboarding on Arbitrum

What happened

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.

What changed

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.

What did not change

The ARFC did not execute an AIP, activate either reserve, extend Ketju approval to the assets, or establish that the proposed parameters became operative.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• [ARFC] Onboard USDai & sUSDai to Aave V3 Arbitrum Instance · Aave DAO via Snapshot · 2026-07-20

Aave proposes syrupUSDC onboarding on Ethereum Core

What happened

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.

What changed

A concrete governance path was proposed for a rejected private-credit exposure to become collateral within an approved-with-limits Aave deployment.

What did not change

The proposal did not execute an AIP, activate syrupUSDC, change Ketju's Maple rejection, or extend the Aave approval to this collateral path.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• [ARFC] Onboard syrupUSDC to Aave V3 Core Instance · Aave DAO via Snapshot · 2026-07-20

Axelar approves Amplifier contract-admin rotation to a multisig

What happened

Axelar governance passed proposal 492 to rotate the administrator and upgrade authority for 35 mainnet Amplifier CosmWasm contracts to a specified multisig.

What changed

Governance authorized a new upgrade-control endpoint across gateway, routing, voting, rewards, service-registry, multisig, and Interchain Token Service components.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Rotate mainnet Amplifier CosmWasm contract admin to multisig · Axelar on-chain governance · 2026-07-17

Lido proposes a separate permissionless 0x02 validator module

What happened

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.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• 0x02 CSM: New Permissionless Module Launch · Lido DAO via Snapshot · 2026-07-10

Axelar approves a non-binding freeze and recustody signal

Developing record. Confirmed facts and unresolved claims are separated below. This entry will be superseded as primary evidence changes.

What happened

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.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Signaling Proposal: Freeze Hacker Funds and Recustody to a Trusted Distributor at a Later Date · Axelar on-chain governance · 2026-07-05

Axelar approves ITS and Amplifier gateway ownership migration

What happened

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.

What changed

Governance authorized a broad cross-chain migration of ownership and administrative control to AxelarServiceGovernance.

What did not change

The record does not prove that each timelock expired, each acceptOwnership call completed, or every target's final owner state changed on July 3.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Accept AxelarServiceGovernance ownership of ITS and Amplifier Gateways · Axelar on-chain governance · 2026-07-03

Axelar rotates permission-control administrators for ITS, Router, and Multisig

What happened

Axelar governance passed proposal 487, executing administrator updates on three Amplifier contracts.

What changed

The permission-control administrator for the Interchain Token Service, Router, and Multisig moved from axelar1nctnr9x0qexemeld5w7w752rmqdsqqv92dw9am to axelar1kctshqfxw74usjme9mqlvkf0rgdh96ty0mmm6p.

What did not change

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.

Confirmed

• 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.

Still unresolved

• The identity, signer composition, threshold, and emergency powers of the new administrator remain unresolved from this record.

Advisor diligence implications

• 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.

Primary evidence

• Update permission-control admin for ITS, Router and Multisig · Axelar on-chain governance · 2026-06-30

Axelar expands emergency multisig CosmWasm deployment authority

What happened

Axelar governance passed proposal 486 and updated x/wasm parameters to permit an emergency multisig to upload and instantiate or migrate CosmWasm code.

What changed

The emergency address axelar14vps3ev03zyp2wmj89etx8rrxdxyltfy4rzl5m gained a fast path for code upload and default instantiation or migration.

What did not change

The proposal does not itself migrate a named contract or authorize direct asset transfers; it changes who may perform future emergency code actions.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Allow the emergency multisig to upload and instantiate CosmWasm code · Axelar on-chain governance · 2026-06-29

Axelar transfers XRPL Amplifier migration authority to 3-of-6 multisig

What happened

Axelar governance passed proposal 482 and reassigned the migration administrator for the XRPL Gateway, VotingVerifier, and MultisigProver contracts.

What changed

Migration authority moved from axelar1nctnr9x0qexemeld5w7w752rmqdsqqv92dw9am to the 3-of-6 multisig axelar14vps3ev03zyp2wmj89etx8rrxdxyltfy4rzl5m.

What did not change

The proposal does not report a contract migration, verifier-set change, route pause, or asset loss.

Confirmed

• 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.

Still unresolved

• The six signer identities, key-custody arrangements, rotation policy, and emergency procedures remain unresolved.

Advisor diligence implications

• 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.

Primary evidence

• Rotate XRPL{Gateway,VotingVerifier,MultisigProver} admin to multisig · Axelar on-chain governance · 2026-06-27

Aave approves faster Risk Steward actions and Umbrella pauser reassignment

What happened

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.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still unresolved

• The candidate does not establish a subsequent AIP or on-chain execution of either control change.

Advisor diligence implications

• 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.

Primary evidence

• [ARFC] Risk Stewards Cooldown Reduction & Umbrella Pauser Role Reassignment · Aave DAO via Snapshot · 2026-06-22

Base recovers from consecutive mainnet chain stalls

What happened

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.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Base Mainnet Chain Stall · Base · 2026-06-26

Spark approves Avalanche governance-bridge timelock and guardian

What happened

Spark governance approved adding a three-day timelock and a guardian multisig to the Avalanche governance bridge.

What changed

The approved design inserts a delay before governance actions become effective and gives a guardian multisig cancellation power during that delay.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• [Avalanche] Spark Liquidity Layer - Add Timelock and Guardian to Avalanche Governance Bridge · Spark via Snapshot · 2026-06-22

Optimism proposes Token House-only voting during the Citizens' House pause

What happened

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.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Operating Manual Update Proposal · Optimism Foundation · 2026-06-25

Blockscape reports Lido validator outage and failed failover

What happened

An OVH failure took Blockscape's Lido-2 cluster offline and simultaneously impaired components needed by its failover design.

What changed

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.

What did not change

The record does not establish a Lido-wide outage, slashing, key compromise, withdrawal impairment, or production deployment of the planned remediation.

Confirmed

• 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.

Still unresolved

• Exact duration, validator count, and missed-reward amount.
• Compensation transaction and final settlement evidence.
• Production timing for the cross-provider remediation.

Advisor diligence implications

• 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.

Primary evidence

• [Post-Mortem] Blockscape - OVH Infrastructure Incident · Blockscape via Lido Governance · 2026-06-29

Lido approves early wind-down of Simple DVT regular clusters

What happened

Lido DAO approved an early wind-down plan for the 72 regular clusters in the Simple DVT Module.

What changed

The approved plan moves regular-cluster operators toward CSM continuation paths and authorizes a grant framework funded from an existing allocation.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Wind Down Simple DVT Module Regular Clusters · Lido DAO via Snapshot · 2026-06-12

Lido approves CMv2 and CSMv3 architecture and rollout plan

What happened

Lido DAO approved LIP-33's architecture, parameters, governance model, and rollout plan for Curated Module v2 and Community Staking Module v3.

What changed

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.

What did not change

The vote did not deploy the modules, migrate validators, or prove that the audited production code and live parameters match the approved design.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• LIP-33: CMv2 and CSMv3 Architecture, Key Parameters, Rollout Plan · Lido DAO via Snapshot · 2026-06-15

Lido approves bridge-endpoint de-recognition and future NEC revocations

What happened

Lido DAO approved revoking canonical recognition for selected stETH and wstETH bridge endpoints and delegating future revocation decisions to the Network Expansion Committee.

What changed

The approved governance position narrows Lido's recognized multichain perimeter and expands the NEC's authority from endpoint recognition to future de-recognition.

What did not change

The proposal explicitly does not disable bridge infrastructure, force migration, impair existing token balances, or make a technical safety judgment about the affected bridges.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Revoke Canonical Status of (w)stETH Bridge Endpoints on Selected Chains and Authorize NEC for Revocations · Lido DAO via Snapshot · 2026-06-12

Lido approves Staking Router v3 architecture

What happened

Lido DAO approved the architecture and key parameters for Staking Router v3.

What changed

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.

What did not change

Snapshot approval did not deploy SRv3, execute module migrations, or establish that stETH withdrawal mechanics changed on-chain.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• LIP-35: Staking Router v3 Architecture and Key Parameters · Lido DAO via Snapshot · 2026-06-15

Rocket Pool approves RPIP-81 inflation and funding rebalance

What happened

Rocket Pool governance approved RPIP-81, which reallocates RPL inflation toward protocol funding before Saturn 2 and changes inflation and allocations after Saturn 2.

What changed

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.

What did not change

The Snapshot vote did not itself execute the required on-chain pDAO parameter change or establish that Saturn 2 had launched.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Rebalance RPL Inflation for Protocol Funding (RPIP-81) · Rocket Pool DAO via Snapshot · 2026-06-05

OP Labs discloses and patches a kona fault-proof soundness bug

What happened

OP Labs published a required kona-client release disclosing a fault-proof soundness bug in post-Jovian BLOBBASEFEE handling.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• kona-client v1.6.0 · OP Labs · 2026-06-19

Axelar rotates administrators for nine MultisigProver contracts

What happened

Axelar governance passed proposal 481 and updated the administrator on MultisigProver contracts for nine chain integrations.

What changed

The Flow, Sui, Stellar, XRPL-EVM, Plume, Hedera, Berachain, Hyperliquid, and Monad MultisigProver contracts were assigned administrator axelar1w2ey0ek9e8q2dfmeznz6ah49zdywpdme0z0kly.

What did not change

The proposal did not confirm new verifier sets, migrate contract code, or establish any service interruption.

Confirmed

• Proposal 481 passed on June 17.
• The payload contains nine update_admin contract calls.
• Every listed MultisigProver received the same new administrator address.

Still unresolved

• The controller type, signer identities, threshold, and operating rules for axelar1w2ey0ek9e8q2dfmeznz6ah49zdywpdme0z0kly remain unresolved.

Advisor diligence implications

• 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.

Primary evidence

• Rotate MultisigProver Admin for flow, sui, stellar, xrpl-evm, plume, hedera, berachain, hyperliquid, monad. · Axelar on-chain governance · 2026-06-17

Optimism proposes Upgrade 19 and the Karst hardfork

What happened

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.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Upgrade 19b — Karst Hardfork · OP Labs · 2026-06-15

Axelar–Secret IBC route contained after unbacked-token drain

Developing record. Confirmed facts and unresolved claims are separated below. This entry will be superseded as primary evidence changes.

What happened

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.

What changed

The affected saTokens became impaired or undercollateralized, and the Axelar Secret and Secret-SNIP connections were paused after discovery.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Security Incident: Axelar<>Secret IBC Bridge Exploit (June 10, 2026) · Secret Network · 2026-06-19

Axelar approves governance-transfer calls for multi-chain Gateway contracts

What happened

Axelar governance passed proposal 474 containing interchain calls to Gateway contracts across 17 EVM integrations.

What changed

The approved payloads encode transferGovernance(address) calls directing Gateway governance toward 0x7acbae6cba67d78aaf69e47000884ae00f9b2525.

What did not change

Passage on Axelar does not by itself prove each destination-chain call cleared its delay and executed successfully.

Confirmed

• 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).

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Interchain Governance Proposal · Axelar on-chain governance · 2026-06-08

Lido proposes Staking Router v3 accounting and deposit architecture

What happened

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.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Staking Router v3 — Design & Implementation Proposal (LIP-35) · Lido · 2026-06-03

Base restores mainnet withdrawals after a TEE enclave issue halted proposals

What happened

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.

What changed

The canonical exit path experienced a temporary operational delay because state proposals needed for withdrawal progression stopped advancing.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Base Mainnet Withdrawal Delay · Base Status · 2026-05-29

Axelar executes VotingVerifier migrations across ten Amplifier chains

What happened

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.

What changed

The VotingVerifier implementation governing verification for the ten named integrations moved to code ID 64, with chain-codec addresses supplied in each migration message.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Migrate VotingVerifier to code id 64 on 10 chains · Axelar on-chain governance · 2026-05-22

Axelar executes an InterchainTokenService contract migration

What happened

Axelar governance passed and executed proposal 470, migrating the identified InterchainTokenService contract to code ID 63.

What changed

The on-chain InterchainTokenService contract implementation changed to code ID 63 under the governance-administered migration path.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Migrate InterchainTokenService contract · Axelar on-chain governance · 2026-05-15

Lombard commits BTC.b and LBTC to an exclusive Chainlink CCIP migration

What happened

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.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Lombard Is Exclusively Migrating to Chainlink CCIP To Secure $1B+ in Bitcoin Assets · Lombard Finance · 2026-05-15

Base recovers from mainnet transaction delays caused by missed blocks

What happened

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.

What changed

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.

What did not change

The notice did not report a complete chain halt, transaction reorganization, fund loss, canonical-bridge exploit, or change to withdrawal and upgrade controls.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Delayed Transactions · Base Status · 2026-05-13

Lido proposes replacing GateSeals with a permanent CircuitBreaker

What happened

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.

What changed

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.

What did not change

The Snapshot record did not establish deployment, audit completion, on-chain execution, pauser assignments, heartbeat parameters, or any active pause of staking or withdrawals.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Transition from GateSeals to CircuitBreaker · Lido Snapshot · 2026-05-11

Previous interpretation

The current Lido memo describes GateSeals as single-use, expiring emergency pause authorities, including for the withdrawal queue.

Lido proposes Kelp-specific EarnETH first-loss exception

What happened

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.

What changed

If approved, EarnETH could apply its first-loss backstop below the normally applicable threshold for this incident, but only after accounting for alternative coverage.

What did not change

The proposal does not alter the general threshold, add a treasury allocation, subsidize yield, replace foregone APY, or establish that any payment has occurred.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Authorize Lido EarnETH Loss Coverage Below 1% Threshold For The Kelp Incident · Snapshot (Lido DAO space) · 2026-04-30

Steakhouse announces SVR MetaOracle migration for Morpho markets

What happened

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.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Improving Oracles on Eligible Markets · Steakhouse Financial on Morpho Governance Forum · 2026-04-27

Optimism publishes required op-challenger security release v1.9.1

Developing record. Confirmed facts and unresolved claims are separated below. This entry will be superseded as primary evidence changes.

What happened

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.

What changed

A fixed official challenger version became available for a direct dependency of the fault-proof process that secures challenged withdrawals.

What did not change

The release does not establish an exploit, fund loss, invalid withdrawal, bridge-contract upgrade, or adoption by every live challenger operator.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• op-challenger v1.9.1 · OP Labs · 2026-04-15

Lombard details Bitcoin Smart Account controls for BTC.b

Developing record. Confirmed facts and unresolved claims are separated below. This entry will be superseded as primary evidence changes.

What happened

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.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Bitcoin Smart Accounts: architecture, explained · Lombard Finance · 2026-04-15

Lido proposes rerouting DVT and APM incentive flows

What happened

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.

What changed

If implemented, the destination and delegated management of these incentive flows would shift to the Lido Earn treasury and Growth Committee-linked liquidity structure.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Redirect DVT & APM Incentives to Current Meta Treasury and LoL · Snapshot (Lido DAO space) · 2026-04-06

Lido proposes Identified DVT Cluster operator class for CSM

What happened

Lido proposed adding an Identified DVT Cluster operator type to the Community Staking Module for four-person clusters of verified independent community stakers.

What changed

If implemented with CSM v3, qualifying clusters would receive distinct bond, reward, priority-queue, strike, monitoring, and committee-administered onboarding treatment.

What did not change

The operator class is not live, CSM v3 deployment is not confirmed, and current CSM operator parameters remain unchanged by the proposal alone.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Introduce an Identified DVT Cluster type in the Community Staking Module · Snapshot (Lido DAO space) · 2026-04-06

Lido proposes Curated Module Committee with delegated operating authority

What happened

Lido proposed creating a Curated Module Committee to replace LNOSG and manage routine operations across CMv1, CMv2, and the Simple DVT Module.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• From LNOSG to CMC: Evolving Curated Staking Modules Governance · Snapshot (Lido DAO space) · 2026-04-06

Lido proposes DAO Ops Multisigs Policy 3.0

What happened

Lido proposed replacing DAO Ops Multisigs Policy 2.0 with Policy 3.0 and aligning related Lido Foundation bylaws with the new framework.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Lido DAO Ops Multisigs Policy 3.0 · Snapshot (Lido DAO space) · 2026-04-06

Lido proposes higher Alliance BORG Easy Track transfer limits

What happened

The Lido Alliance BORG Foundation proposed increasing the Easy Track security limit governing treasury transfers to its operational multisig.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Increase Lido Alliance BORG Operational Easy Track Limits to align with EGG · Snapshot (Lido DAO space) · 2026-04-06

Aave v4 launched on Ethereum with Hub-and-Spoke liquidity architecture

What happened

Aave v4 became live on Ethereum mainnet with three Liquidity Hubs, multiple Spokes, conservative initial caps, and the Aave Pro interface.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Aave V4 is Live on Ethereum · Aave Labs · 2026-03-30

sky.money launches USDT Savings and USDS Flagship vaults on Morpho

What happened

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.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Announcing the sky.money USDT Savings Vault & USDS Flagship Vault · sky.money on the Morpho Governance Forum · 2026-03-03

Aave approves v3.7 candidate scope ahead of final activation vote

What happened

Aave tokenholders approved the proposed v3.7 candidate scope, authorizing security procedures before a separate final on-chain AIP activation vote.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• [ARFC] Aave v3.7 candidate · Aave DAO Snapshot · 2026-02-24

Rocket Pool executes the Saturn 1 mainnet upgrade

What happened

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.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Rocket Pool v1.4.0 — Saturn · Rocket Pool · 2026-02-11
• Rocket Pool protocol timeline · Rocket Pool · 2026-02-18
• The Saturn 1 Upgrade — What's New · Rocket Pool · 2026-02-18

Lombard launches Bitcoin Smart Accounts in a private-client pilot

Developing record. Confirmed facts and unresolved claims are separated below. This entry will be superseded as primary evidence changes.

What happened

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.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Lombard Introduces Bitcoin Smart Accounts · Lombard Finance · 2026-02-11

BTC.b and Aave launch on MegaETH mainnet

What happened

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.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• BTC.b Is Live on MegaETH · Lombard Finance · 2026-02-09

Previous interpretation

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.

Base publishes postmortem on severe transaction drops and inclusion delays

What happened

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.

What changed

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.

What did not change

The postmortem did not report a canonical-bridge contract exploit, asset loss, withdrawal-rule change, challenge-period change, or continuing impairment after the rollback.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• High Rate of Transaction Drops and Transaction Inclusion Delays · Base Status · 2026-02-03

Lido approves Rewards Share Committee reform

What happened

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.

What changed

The approved mandate expands the committee's operational role in allocating approved rebates and executing treasury-funded stVault reward payments within DAO-approved budgets.

What did not change

The vote did not itself change stETH withdrawals, the core staking fee, validator balances, or demonstrate that any particular payment had been executed.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Rewards Share Committee Reform · Lido DAO · 2026-01-19

Lido approves variable DVT and DVV incentive allocations

What happened

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.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• DVT & DVV Incentive Allocation Changes · Lido DAO · 2026-01-19

Axelar publishes CometBFT security-patch release v1.3.8

Developing record. Confirmed facts and unresolved claims are separated below. This entry will be superseded as primary evidence changes.

What happened

Axelar published axelar-core v1.3.8 with an upgraded CometBFT dependency containing the fix for CSA-2026-001.

What changed

A patched official validator build became available, creating a concrete infrastructure-version diligence requirement for the watched Axelar dependency.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Axelar Core v1.3.8 · Axelar · 2026-01-23

Base recovers from periodically delayed block building

What happened

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.

What changed

Transaction inclusion on the chain supporting the watched canonical bridge was temporarily less reliable, adding a confirmed operational incident to the bridge diligence record.

What did not change

The status record does not report a bridge-contract exploit, fund loss, withdrawal pause, challenge-period change, or continuing impairment after resolution.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Periodically delayed block building on Base Mainnet · Base · 2026-01-20

Optimism publishes essential op-node security release v1.16.5

Developing record. Confirmed facts and unresolved claims are separated below. This entry will be superseded as primary evidence changes.

What happened

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.

What changed

A security-relevant official node version became available and was designated essential, creating an infrastructure-version review requirement for OP Mainnet dependencies.

What did not change

The release does not identify an exploited vulnerability, fund loss, bridge-contract change, withdrawal change, or confirmed OP Mainnet adoption.

Confirmed

• 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.

Still unresolved

• The security fixes are not described in the cached candidate record.
• The record does not establish when OP Mainnet operators adopted the release.

Advisor diligence implications

• 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.

Primary evidence

• op-node v1.16.5 · OP Labs · 2026-01-13

Lido approves SEAL Safe Harbor exploit-response framework

What happened

LDO holders approved adopting the SEAL Whitehat Safe Harbor framework for Lido on Ethereum, including recovery, bounty, scope-management, and incident-contact terms.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Adopt The SEAL Safe Harbor Agreement · Lido DAO governance via Snapshot · 2025-12-11

Gearbox proposes emergency rstETH account expiry ahead of an in-place upgrade

Developing record. Confirmed facts and unresolved claims are separated below. This entry will be superseded as primary evidence changes.

What happened

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.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• GIP-273: Mellow and P2P rstETH implementation update response · Gearbox governance · 2025-12-18

Axelar validators apply a security patch addressing node-crash risk

What happened

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.

What changed

A patched Axelar Core version became available, and Axelar reported majority-validator adoption intended to prevent validator nodes from crashing.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Axelar Core v1.3.5 · Axelar · 2025-12-15

Goldfinch proposes a $250,000 reimbursement after a reported test-contract exploit

Developing record. Confirmed facts and unresolved claims are separated below. This entry will be superseded as primary evidence changes.

What happened

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.

What changed

The proposal introduced a concrete loss-allocation decision that would cover approximately 75% of the governance record's reported $330,000 USDC loss.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• GIP-85: Goldfinch Hack Response · Goldfinch governance · 2025-12-14

StakeWise approves recovered-funds distribution after Balancer V2 exploit

What happened

StakeWise governance approved initiating a claim distribution of recovered osETH and osGNO to liquidity providers in Balancer V2 pools affected by the exploit.

What changed

The vote authorized a Merkle Distributor process through the StakeWise interface for eligible affected wallets to claim recovered assets.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Proposal: Approve Distribution Of Recovered Funds To LPs Affected By Balancer V2 Exploit · StakeWise DAO governance via Snapshot · 2025-12-05

Base recovers from missed-block transaction delays

What happened

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.

What changed

The incident added a confirmed transaction-inclusion disruption to Base's operating history, followed by recovery and preparation of a mitigation for recurrence.

What did not change

The status record does not report a canonical-bridge contract exploit, fund loss, withdrawal pause, state reorganization, or permanent change to bridge mechanics.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Delayed Transactions · Base · 2025-12-12

Aave executes mUSD onboarding on Ethereum Core and Linea

What happened

Aave Governance V3 executed proposal 415, adding MetaMask USD reserves to the Ethereum Core and Linea instances.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Add MetaMask USD (mUSD) to Aave V3 Ethereum/Linea · Aave Governance V3 · 2025-11-26

Previous interpretation

The August 26 TEMP CHECK placed mUSD onboarding on the research perimeter, but contracts, oracles, caps, collateral status, and execution remained unresolved.

Aave executes wrsETH onboarding on Avalanche

What happened

Aave Governance V3 executed proposal 414, adding wrapped rsETH as collateral on the Avalanche instance.

What changed

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.

What did not change

wrsETH was not enabled for ordinary borrowing. Execution did not approve Avalanche, Kelp DAO, LayerZero, wrsETH, or the new E-mode for Ketju clients.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Onboard rsETH to Aave V3 Avalanche Instance · Aave Governance V3 · 2025-11-21

Lido opens a vote on Curated Module fee tiers

What happened

Lido opened a Snapshot vote on an interim Curated Module fee structure with Standard, Extra Effort, and Client-Team operator tiers.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Curated Module Fee Changes · Lido Snapshot · 2025-11-24

Lido proposes investing treasury stablecoins in sUSDS and tokenized funds

What happened

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.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Conversion of Treasury Stablecoins into sUSDS or TMMFs · Lido Snapshot · 2025-11-24

Rocket Pool proposes closing the minipool queue before Saturn 1

What happened

Rocket Pool opened a vote on RPIP-74 to stop new entries into the legacy minipool queue before the Saturn 1 megapool launch.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Minipool Queue Closure pre-Saturn 1 Launch (RPIP-74) · Rocket Pool Snapshot · 2025-11-21

Aave freezes the wstETH reserve on Plasma

What happened

Aave Governance V3 executed proposal 410, freezing the wstETH reserve on Plasma after Lido and Chainlink decided to replace the existing cross-chain representation.

What changed

New wstETH deposits, borrowing, and collateral enablement were disabled on the Plasma Aave market.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Freeze wstETH Plasma · Aave Governance V3 · 2025-11-14

Previous interpretation

On October 19, Aave executed wstETH and wrsETH onboarding on Plasma, with wstETH enabled as borrowable collateral under a high-efficiency E-mode.

Aave executes zero-LTV deprecation for nine volatile assets

What happened

Aave Governance V3 executed proposal 409, setting the LTV of nine low-demand volatile assets to zero across Ethereum Core, zkSync, BNB, and Metis.

What changed

The affected assets no longer provided additional borrowing capacity under their base reserve configurations, advancing their deprecation.

What did not change

The payload did not freeze the reserves, set their liquidation thresholds to zero, or establish that existing positions had been closed.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Deprecation of Low Demand Volatile Assets on Aave V3 Instances · Aave Governance V3 · 2025-11-10

Aave restores supply and borrow caps on Gnosis

Developing record. Confirmed facts and unresolved claims are separated below. This entry will be superseded as primary evidence changes.

What happened

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.

What changed

The payload reopened capacity for wstETH, sDAI, GNO, WETH, USDC.e, xDAI, GHO, and EURe under the specified revised caps.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Reinstate Supply and Borrow Caps on Aave V3 Gnosis Instance · Aave Governance V3 · 2025-11-06

Aave opens final governance for cbBTC Stablecoin E-Mode on Base

What happened

Aave Governance V3 proposal 400 opened final on-chain governance for a cbBTC Stablecoin E-Mode on the Aave V3 Base market.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Addition of cbBTC/Stablecoin E-Mode to Aave V3 Base Instance · Aave Governance V3 · 2025-10-29
• Aave Governance proposal 400 creation transaction · Ethereum — Aave Governance V3 · 2025-10-29

Aave opens final governance to deprecate legacy USDC on Gnosis

What happened

Aave Governance V3 proposal 399 opened final on-chain governance to deprecate the legacy USDC reserve on Aave V3 Gnosis.

What changed

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%.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• USDC (old) deprecation on Gnosis Chain Instance · Aave Governance V3 · 2025-10-28
• Aave Governance proposal 399 creation transaction · Ethereum — Aave Governance V3 · 2025-10-28

Aave executes Slope2 Risk Oracle activation

What happened

Aave governance executed proposal 395, activating automated Slope2 interest-rate updates on specified Ethereum Core and Linea reserves.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still unresolved

• The realized frequency and magnitude of automated Slope2 changes after activation.
• Market-by-market performance during prolonged high-utilization stress.

Advisor diligence implications

• 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.

Primary evidence

• Slope2 Risk Oracle Activation On Core Ethereum, Linea · Aave Governance V3 · 2025-10-21

Previous interpretation

The Slope2 risk-oracle automation had been approved at the ARFC stage but was not yet confirmed operative.

Spark approves removing USDC, USDT, and PYUSD reserve caps

What happened

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.

What changed

The approved configuration would remove explicit reserve-level exposure ceilings for the three stablecoins once implemented.

What did not change

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.

Confirmed

• 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.

Still unresolved

• The implementation transaction and effective on-chain parameters.
• Post-implementation utilization, concentration, available liquidity, and any replacement exposure controls.

Advisor diligence implications

• 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.

Primary evidence

• [Ethereum] SparkLend - Remove Supply and Borrow Caps for Non Collateral Stablecoins (USDC, USDT, PYUSD) · Spark governance · 2025-10-20

Spark approves Liquidity Layer relayer and freezer multisig changes

What happened

Spark governance approved adding Spark Assets Foundation as a co-controller of the Core Operator Relayer multisig and lowering the Freezer multisig threshold.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• SAEP-02: Modify Spark Liquidity Layer Core Relayer and Freezer Multisig Configuration · Spark governance · 2025-10-20

Lido approves Validator Exits SNOP v3

What happened

Lido tokenholders approved version 3 of the Standard Node Operator Protocol governing validator exits.

What changed

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.

What did not change

The vote did not itself change the Withdrawal Queue contracts, prove universal operator implementation, or demonstrate stressed-condition exit performance.

Confirmed

• 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.

Still unresolved

• Implementation and compliance status across individual node operators and modules.
• Observed performance during large, urgent, or congested validator-exit requests.

Advisor diligence implications

• 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.

Primary evidence

• Proposal for Updating Lido on Ethereum Validator Exits SNOP to v3 · Lido DAO · 2025-10-15

Lido approves bridge-partnership authority framework

What happened

Lido tokenholders approved a framework empowering Lido Ecosystem Foundation to lead bridge-related negotiations and agreements involving stETH and wstETH.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Empowering Lido Ecosystem Foundation to Lead Bridge-Related Partnerships · Lido DAO · 2025-10-15

Base recovers from elevated RPC and transaction-inclusion latency

What happened

Base Mainnet experienced high RPC latency, delayed transaction inclusion, and periodic inconsistencies in block-production timing before performance returned to normal.

What changed

For approximately two hours, transaction submission and state access were less reliable, degrading an operational dependency used by Base canonical-bridge workflows and monitoring.

What did not change

Base did not report a bridge exploit, asset loss, invalid state transition, changed withdrawal contract, or permanent finality-policy change.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• High RPC latency and transaction inclusion times on Base Mainnet · Base Status · 2025-10-20

Base recovers from AWS-related capacity and batch-submission disruption

What happened

An AWS outage affected Base infrastructure, reducing network capacity and interrupting batch submission on Mainnet and Testnet until service recovered.

What changed

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.

What did not change

The status record did not report a consensus failure, bridge compromise, asset loss, changed custody, or a permanent change to withdrawal or finality mechanics.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Limited network capacity · Base Status · 2025-10-20

Base recovers from congestion-related transaction-inclusion delays

What happened

Periodic congestion on Base Mainnet delayed transaction inclusion from October 17 into October 18. Base increased mempool size and reported the incident resolved.

What changed

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.

What did not change

The official record did not report a bridge exploit, asset loss, failed finality, or a change to bridge custody or withdrawal contracts.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Delayed Transaction Inclusion · Base Status · 2025-10-18

Base recovers from a transaction-volume-driven safe-head delay

What happened

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.

What changed

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.

What did not change

Unsafe block building continued normally, and Base did not report an invalid finalized state, bridge compromise, asset loss, or permanent finality-policy change.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Safe head delay from high transaction volume · Base Status · 2025-10-11

Lido activates triggerable withdrawals on Ethereum mainnet

What happened

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.

What changed

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.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Lido V2.2 release · Lido Finance · 2025-10-13
• Triggerable Withdrawals Framework in the Lido Protocol · Lido Governance · 2025-07-04

Previous interpretation

Prior history treated the triggerable-withdrawals framework as approved design awaiting on-chain activation.

Lido approves the V3 design and implementation proposal

What happened

Lido tokenholders approved advancing the V3 architecture, including stVaults, phased minting caps, reserve requirements, rate limits, and pause controls.

What changed

The DAO authorized contributors to finalize audits and testing and prepare an on-chain mainnet execution vote for a major new staking-vault architecture.

What did not change

V3 was not executed on mainnet by this vote; the existing Core Pool path remained unchanged and available.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Lido V3 — Design & Implementation Proposal · Lido DAO via Snapshot · 2025-09-22

Lido approves the stVaults Committee and delegated parameter authority

What happened

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.

What changed

The DAO approved a delegated control body and defined its intended authority over material stVault economic and risk parameters.

What did not change

The committee's stVault authority was not yet operative because the V3 system and enabling on-chain actions had not been executed.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Establish the stVaults Committee · Lido DAO via Snapshot · 2025-09-22

Flare launches FAssets on mainnet with FXRP

What happened

Flare launched FAssets on mainnet with FXRP v1.2, allowing XRP to be represented and used across Flare DeFi.

What changed

The FAssets design moved from development into live operation for one supported underlying asset, FXRP.

What did not change

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.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• FAssets are Live: XRP Meets DeFi on Flare · Flare Network · 2025-09-24

Aave executes the V3.5 Plasma market activation

What happened

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.

What changed

A new Aave deployment became operative on Plasma, expanding the protocol's chain, collateral, oracle, guardian, and cross-chain governance perimeter.

What did not change

XPL was not included in the initial activation, and the launch did not make the Plasma market or its assets approved for Ketju clients.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Aave V3.5 Plasma Activation · Aave Governance v3 · 2025-09-18

Aave executes billion-dollar November PT supply-cap increases

What happened

Aave governance executed increases to the Ethereum Core supply caps for PT-sUSDe-27NOV2025 and PT-USDe-27NOV2025.

What changed

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.

What did not change

The payload did not onboard new token contracts, change their maturity dates, or establish that the higher caps would be fully utilized.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Raise sUSDe and USDe November expiry PT token caps on Aave V3 Core Instance · Aave Governance v3 · 2025-09-13

Aave executes 50% reserve factors across its Scroll market

What happened

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.

What changed

A larger share of borrower interest began accruing to protocol reserves rather than suppliers across all listed Scroll assets.

What did not change

This payload did not itself change supply caps, borrow caps, collateral factors, liquidation thresholds, or the Scroll chain's governance.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Risk Parameter Adjustments for Aave V3 Scroll Instance · Aave Governance v3 · 2025-09-12

Aave raises the Linea wrsETH supply cap to 70,000

What happened

Aave governance executed an increase in the Linea wrsETH supply cap from 6,400 to 70,000.

What changed

The maximum permitted wrsETH supply on the Linea Aave market increased by more than tenfold, materially expanding the market's possible liquid-restaking exposure.

What did not change

The payload did not change wrsETH's oracle, liquidation thresholds, loan-to-value setting, borrowability, or underlying bridge and wrapping dependencies.

Confirmed

• 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.

Still 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.

Advisor diligence implications

• 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.

Primary evidence

• Increase rsETH Supply Cap on Aave V3 Linea Instance · Aave Governance v3 · 2025-09-11