SAEP-11: Update Spark Savings Configuration - February 23, 2026

Spark's Operational Facilitator has placed a proposal into the voting system on behalf of nested contributor Phoenix Labs.

Review

The Spark community can hereby express support or opposition to the following changes, as described by the author of the proposal:

Summary

This proposal is submitted by Phoenix Labs in its role as a nested contributor, as defined in section A.6.1.1.1.2.2.2.2.1.2.1.1.1 of the Spark Artifact. The proposal recommends that Spark governance update certain Target Liquidity and Rewards Rate parameters.

Background

With the benefit of several months of operational data following the launch of Spark Savings v2, we propose a series of revisions and parameter adjustments to the Spark Savings Configuration and Strategy proposal (SAEP-03). These changes are intended to benchmark parameters against market comparables, reduce costs, and improve capital efficiency.

Proposal Details

We propose that Spark governance approve the following changes to Spark Savings configuration and operational parameters:

• Update Target Liquidity parameter configuration to specify a maximum buffer for instant withdrawals regardless of vault size.

• Specify Target Liquidity and Rewards Rate details for the new Spark Savings PYUSD vault.

• Change the benchmark rate for Spark Savings USDT vault from the Sky Savings Rate to Aave Core USDT supply rate, plus a spread within a governance-defined range.

• Change the method for calculating Spark Savings ETH Rewards Rate to align with potential inclusion of additional backing assets besides SparkLend ETH, and enable a governance defined spread.

Justification

This proposal, if adopted by governance, would make several adjustments to the Spark Savings configuration, and we share justification and reasoning for each component separately below.

Updating Target Liquidity parameters

We propose that Spark governance update Target Liquidity parameters to set a firm maximum liquidity buffer in each Spark Savings vault, meaning that beyond a certain vault size the liquidity buffer amount will not grow, and will decline as a percentage of total vault deposits. This helps reduce the cost of holding idle, non-yielding assets within vault contracts, while maintaining sufficient liquidity for instant withdrawals. Users wishing to withdraw amounts in excess of the maximum liquidity buffer can simply cycle through several transactions to withdraw the desired amount, with Spark Liquidity Layer promptly refilling the liquidity buffer when it gets used up.

Updating Rewards Rate parameters

We propose that Spark governance update Rewards Rate configurations to better align Spark Savings rewards with the Spark Liquidity Layer’s revenue-generating capacity and applicable external benchmark rates. Specifically, we propose to benchmark the USDT savings vault based on the Aave Core USDT supply rate on Ethereum, which represents the primary comparable savings product for USDT within the DeFi ecosystem. For ETH savings, we propose to benchmark the Rewards Rate against the pro-rata net revenue generated by the Spark Liquidity Layer, allowing the rate to rise naturally in line with improved ETH capital allocation efficiency. For both vaults (USDT and ETH), we also propose for Spark governance to adopt a target spread range, allowing the Rewards Rate for the vaults to be set as a fixed percent different from the benchmark rate. This allows Spark governance to define bounded spreads around approved benchmark rates, while keeping the vault yields and protocol costs within clearly defined parameters.

The proposed Spark Artifact changes can be found in the following pull request: https://github.com/sky-ecosystem/next-gen-atlas/pull/188

Outcomes

• If "For" receives the most votes, the proposal will be approved. The associated pull request will be merged into Spark's artifact. When required, the listed changes will proceed to implementation by the relevant actors.

• If "Against" receives the most votes, the proposal will be rejected. No changes will be implemented.