Sky governance executed an onchain executive proposal on 29 October that sets initial deposit rate limits for the Osero x Gauntlet USDC Prime Vault and whitelists specified proxy spells for Spark, Grove and Pattern. The official voting portal records that the proposal passed on 27 October at 12:26 UTC and was executed on 29 October at 12:28 UTC.

The change is a governance and risk-control event rather than evidence that the Osero vault has already received its maximum allocation. It establishes how quickly the authorized operator can expand the deposit capacity, while the separate proxy-spell provisions define approved execution paths for a broader set of ecosystem actions.

Osero receives a bounded USDC deposit path

The executive sets a default maximum amount of 5 million USDC and a replenishing slope of 650,000 USDC per day for the Osero x Gauntlet vault deposit key. Sky's proposal says this permits the Osero Operator Multisig, also described as Osero's cBEAM, to raise the vault's deposit slope from zero through the Configurator without requiring a separate Osero spell.

A rate limit is not the same as an immediate deposit. The maximum amount caps the available capacity, while the slope governs how that capacity restores over time after use. The mechanism therefore gives Osero operational flexibility inside a ceiling that governance has already approved.

The distinction matters for readers following protocol exposure. The executive creates permission and capacity; it does not by itself establish the vault's later balance, the quality of every asset position or the amount ultimately deployed. Those outcomes require separate transaction and portfolio evidence.

Three StarGuard proxy spells are whitelisted

The executed proposal also whitelists one specified proxy spell in each of the Spark, Grove and Pattern StarGuard modules. The governance record publishes each spell address and code hash, providing identifiers that can be checked against subsequent execution activity.

For Spark, the approved payload described by the proposal includes bridging 100 million sUSDS from an Ethereum asset-liability-management proxy to an Arbitrum proxy. It also includes lowering the SparkLend WETH interest-rate-model Slope 2 parameter from 75% to 30% and setting new interest-rate models for PYUSD, RLUSD and USDG.

Those stablecoin-market models are specified with 80% optimal utilization, a base rate of the Sky Savings Rate plus 0.20%, Slope 1 of 0.20% and Slope 2 of 15%. The same Spark payload description includes November operating transfers of 865,000 USDS to the Spark Foundation, 45,000 USDS to the Spark Assets Foundation and 341,970 USDS to the Spark Operations Multisig for SPK buybacks, as well as claiming accrued SparkLend reserves.

The Grove payload described in the governance record includes an 800,000 USDS transfer to the Grove Foundation Multisig and retirement of an Avalanche CCTP v1 governance-relay role. The Pattern payload sets a USDC transfer-asset rate limit for the River I allocation to River SPV II with a 35 million USDC maximum and a replenishment slope of 10 million USDC per day.

Execution status does not erase verification boundaries

The portal's executed status establishes that the top-level Sky executive was executed. It supports reporting that the Osero rate-limit defaults and StarGuard whitelist changes were approved and activated through that governance process.

NetNapz has not independently traced every downstream proxy transaction, bridge settlement, treasury receipt or reserve transfer described in the whitelisted payloads. Whitelisting a spell is an authorization step; readers should not treat the proposal page alone as proof that every downstream action completed successfully or that funds arrived at their destinations.

This is especially relevant to the 100 million sUSDS bridge item and the treasury transfers. Their operational completion, timing and final balances should be verified from the relevant chain records and recipient addresses rather than inferred solely from the executive summary.

What changes for risk monitoring

The Osero provision moves the vault from a zero-slope starting point to a governed path for adding USDC capacity. The 650,000-USDC daily slope slows the rate at which the full 5 million-USDC allowance can become available after use, giving observers a clearer boundary than an unrestricted allocation would provide.

The proxy-spell structure also concentrates several economically different actions in one governance package: cross-chain liquidity, lending-market interest parameters, operating transfers, buybacks, reserve collection and an off-ramp allocation. Each item has its own execution and risk profile even though governance considered them through the same executive.

NetNapz assessment

The most material development is the conversion of a proposed Osero configuration into an executed governance control. For risk monitoring, the useful numbers are the 5 million-USDC maximum and 650,000-USDC-per-day slope, because they define the approved pace and ceiling for this deposit key.

The whitelisted spells broaden the operational scope but should be monitored transaction by transaction. A governance record can establish authority and intended parameters; it cannot replace verification of bridge delivery, recipient balances or post-execution market settings.

Future reporting should separate three questions: whether a spell was authorized, whether it was executed, and whether its intended downstream state was reached. Collapsing those stages would overstate what the current evidence proves.

Sources and verification limits

• Sky Governance voting portal — executive status and execution timestamp
• Sky Governance — Osero rate limits and Prime Agent proxy-spell proposal details

NetNapz checked the official governance portal and proposal text, searched the published site for overlapping Osero coverage, and verified featured-media attachment 4279 as a 960×960 PNG with a Circle/Wikimedia Commons CC BY-SA 4.0 credit. It did not connect a wallet, operate a trading application, audit the spell code, run a node or independently confirm every downstream transfer.