KVORUM
aaveSource: Aave governance v3 · #426

Ethena February E-Modes Adjustments

executedDec 28, 2025, 06:49 PM UTCby570x57ab…2922

01Summary

AISummary by Kvorumclaude-haiku-4-5

Add sUSDe as eligible collateral in PTsUSDe E-Modes and USDe as eligible collateral in PTUSDe E-Modes to reduce friction for users managing leveraged positions across Pendle principal token maturities and allow smoother collateral substitution while preserving E-Mode benefits.

Type
parameter change

Key changes

  • Add sUSDe as eligible collateral in both PTsUSDe5FEB/Stablecoins and PTsUSDe5FEB/USDe E-Modes(high)
  • Add USDe as eligible collateral in both PTUSDe5FEB/Stablecoins and PTUSDe5FEB/USDe E-Modes(medium)
  • Enable users to migrate collateral from principal tokens to sUSDe while preserving E-Mode benefits without unwinding positions(high)
  • Reduce operational overhead and potential liquidity stress around redemption events for Pendle PT users(medium)

Notable concerns

  • USDe inclusion in PT-USDe E-Modes provides limited utility since USDe is not yield-bearing, creating leveraged annualized loss equal to borrowing costs if used as collateral instead of yield-bearing sUSDe
  • Proposed adjustments introduce parameter changes that depend on Risk Oracle determinations for LTV, LT, and Liquidation Bonus values
ContractsPT-sUSDe-5FEB2026PT-sUSDe-27NOV2025PT-USDe-5FEB2026PT-USDe-27NOV2025sUSDeUSDeAave V3 Ethereum E-Modes
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

1,078 words

Simple Summary

We recommend adding sUSDe as an eligible collateral asset in both the PTsUSDe5FEB/Stablecoins and PTsUSDe5FEB/USDe E-Modes and USDe as an eligible collateral asset in both the PTUSDe5FEB/Stablecoins and PTUSDe5FEB/USDe E-Modes.

Motivation

sUSDe

We recommend adding sUSDe as an eligible collateral asset in both the PTsUSDe5FEB/Stablecoins and PTsUSDe5FEB/USDe E-Modes to reduce potential friction for sUSDe-based principal token loopers when substituting collateral. As PT-sUSDe-5FEB2025 can only be redeemed for sUSDe, enabling sUSDe within these E-Modes will allow users to migrate collateral from the principal token to sUSDe while preserving E-Mode benefits, rather than fully unwinding their positions.

To date, this substitution path has seen limited use: in September, approximately 24.27 million sUSDe of collateral, out of more than 2 billion principal tokens with September maturity, was swapped via transactions that burned PT-sUSDe and minted aEthsUSDe. While not widely adopted historically, we view this as a useful tool for advanced position management and would recommend supporting it as the markets scale. This adjustment is therefore expected to increase the stickiness of PT-sUSDe-based demand for stablecoin borrowing, reduce unnecessary deleveraging and operational overhead around redemption events, and lower potential liquidity stress when positions are adjusted at substantial market sizes.

USDe

The motivation behind the addition of sUSDe in the PT-sUSDe E-Modes strains from the fact that users would otherwise need to fully unwind highly leveraged positions in order to shift from the November sUSDe PTs to the February maturity tokens. Since Pendle allows one-to-one redemption of the PTs at maturity, users receive sUSDe without incurring in any swapping cost, which, while yield-bearing, can be utilized as collateral, and can act as a substitution for the PT-sUSDe when users are exiting the previous maturity PTs while awaiting the next maturity PTs (either to be listed or to have sufficient capacity). This way, the presence of sUSDe in the E-Modes serves a high-utility purpose for a subset of users.

The inclusion of USDe in the E-Modes does not provide such utility as it is not yield-bearing. Hence, if users redeem PT-USDe for USDe and then collateralize the debt with USDe, they would be taking a leveraged annualized loss equal to the borrowing costs of the notional debt. We’d also like to note that the utility of such collateral in the PT-related E-Modes does not depend on the type of PT (sUSDe or USDe), as no incremental utility is provided by USDe in either case. In case of unwinding staked USDe positions, the inclusion of USDe under the same parameters effectively presents the same utility. Nevertheless, the inclusion of USDe in the PT-USDe E-Mode can reduce the costs of transition in one specific edge case. Given that a user has a substantial leveraged position and is paying borrowing costs on the notional, if the next PT is expected to be listed within a reasonably short period of time, it might be beneficial to incur the funding costs of the net position instead of converting the USDe collateral to the debt assets.

While the inclusion of USDe in the proposed E-Modes presents limited utility, such an adjustment does not introduce additional risk; therefore, we support the proposed adjustment.

Specification

PT-sUSDe Stablecoins E-mode

AssetPT-sUSDe-5FEB2026PT-sUSDe-27NOV2025sUSDeUSDCUSDTUSDeUSDtb
CollateralYesYesYesNoNoNoNo
BorrowableNoNoNoYesYesYesYes
LTVSubject to Risk OracleSubject to Risk OracleSubject to Risk Oracle----
LTSubject to Risk OracleSubject to Risk OracleSubject to Risk Oracle----
Liquidation BonusSubject to Risk OracleSubject to Risk OracleSubject to Risk Oracle----

PT-sUSDe USDe E-mode

AssetPT-sUSDe-5FEB2026PT-sUSDe-27NOV2025sUSDeUSDe
CollateralYesYesYesNo
BorrowableNoNoNoYes
LTVSubject to Risk OracleSubject to Risk OracleSubject to Risk Oracle-
LTSubject to Risk OracleSubject to Risk OracleSubject to Risk Oracle-
Liquidation BonusSubject to Risk OracleSubject to Risk OracleSubject to Risk Oracle-

PT-USDe Stablecoins E-mode

AssetPT-USDe-5FEB2026PT-USDe-27NOV2025USDeUSDCUSDTUSDtb
CollateralYesYesYesNoNoNo
BorrowableNoNoYesYesYesYes
LTVSubject to Risk OracleSubject to Risk OracleSubject to Risk Oracle---
LTSubject to Risk OracleSubject to Risk OracleSubject to Risk Oracle---
Liquidation BonusSubject to Risk OracleSubject to Risk OracleSubject to Risk Oracle---

PT-USDe USDe E-mode

AssetPT-USDe-5FEB2026PT-USDe-27NOV2025USDe
CollateralYesYesYes
BorrowableNoNoYes
LTVSubject to Risk OracleSubject to Risk OracleSubject to Risk Oracle
LTSubject to Risk OracleSubject to Risk OracleSubject to Risk Oracle
Liquidation BonusSubject to Risk OracleSubject to Risk OracleSubject to Risk Oracle

References

Disclosure

Chaos Labs has not been compensated by any third party for publishing this AGRS recommendation.

Caps updates mentioned on the forum discussion post have been implemented via risk steward so it will not be part of this AIP.

Copyright

Copyright and related rights waived via CC0.

03Mismatch analysis

AIMismatch analysis by Kvorumlow confidenceclaude-sonnet-5
Consistent

The proposal contains a single decoded on-chain action: a parameterless execute() call to what is clearly an Aave governance payload contract, consistent with the standard Aave V3 proposal pattern where granular configuration changes (adding sUSDe/USDe as eligible E-Mode collateral) are implemented inside the linked Solidity payload contract rather than being individually decoded in the top-level calldata. Because the decoded arguments are empty, it is not possible to directly verify from the calldata alone whether the specific E-Mode collateral flags, LTV, LT, and liquidation bonus settings described in the specification tables match what execute() actually does internally. However, this is routine and expected for Aave AIPs — the implementation and test links point to the exact contract that performs these changes, and there is no evidence in the decoded action of any conflicting, additional, or omitted behavior (e.g., no transfers, role grants, or unrelated parameter changes are visible). The description's explicit claim that cap changes are excluded from this AIP is also not contradicted by the single execute() call. Given the lack of granular decoded parameters, confidence in a detailed action-by-action comparison is low, but nothing in the available calldata contradicts the description, so no discrepancy is flagged and the assessment is 'consistent' pending fuller calldata visibility (e.g., trace or internal call decoding) if available in the future.

Generated by Kvorum
model: claude-sonnet-5
provider: anthropic
profile: anthropic-strong-v1
prompt: v1.0
generated: 2mo ago
Review the decoded actions ↗

04Actions

1 total
#0fallback()chain 0x1
Target
0x00ce…7ca4
Value
0 wei
Function
fallback()
Arguments
{}
Calldata

05Tally

Summed from votes

Voters0
VP participating0
Outcome (current)—
Current support—

06Voters

0 total

No votes recorded yet.

07Forum

No forum thread is confidently linked to this proposal.