Ethena February E-Modes Adjustments
01Summary
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
Generated by Kvorum
02Description
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
| Asset | PT-sUSDe-5FEB2026 | PT-sUSDe-27NOV2025 | sUSDe | USDC | USDT | USDe | USDtb |
|---|---|---|---|---|---|---|---|
| Collateral | Yes | Yes | Yes | No | No | No | No |
| Borrowable | No | No | No | Yes | Yes | Yes | Yes |
| LTV | Subject to Risk Oracle | Subject to Risk Oracle | Subject to Risk Oracle | - | - | - | - |
| LT | Subject to Risk Oracle | Subject to Risk Oracle | Subject to Risk Oracle | - | - | - | - |
| Liquidation Bonus | Subject to Risk Oracle | Subject to Risk Oracle | Subject to Risk Oracle | - | - | - | - |
PT-sUSDe USDe E-mode
| Asset | PT-sUSDe-5FEB2026 | PT-sUSDe-27NOV2025 | sUSDe | USDe |
|---|---|---|---|---|
| Collateral | Yes | Yes | Yes | No |
| Borrowable | No | No | No | Yes |
| LTV | Subject to Risk Oracle | Subject to Risk Oracle | Subject to Risk Oracle | - |
| LT | Subject to Risk Oracle | Subject to Risk Oracle | Subject to Risk Oracle | - |
| Liquidation Bonus | Subject to Risk Oracle | Subject to Risk Oracle | Subject to Risk Oracle | - |
PT-USDe Stablecoins E-mode
| Asset | PT-USDe-5FEB2026 | PT-USDe-27NOV2025 | USDe | USDC | USDT | USDtb |
|---|---|---|---|---|---|---|
| Collateral | Yes | Yes | Yes | No | No | No |
| Borrowable | No | No | Yes | Yes | Yes | Yes |
| LTV | Subject to Risk Oracle | Subject to Risk Oracle | Subject to Risk Oracle | - | - | - |
| LT | Subject to Risk Oracle | Subject to Risk Oracle | Subject to Risk Oracle | - | - | - |
| Liquidation Bonus | Subject to Risk Oracle | Subject to Risk Oracle | Subject to Risk Oracle | - | - | - |
PT-USDe USDe E-mode
| Asset | PT-USDe-5FEB2026 | PT-USDe-27NOV2025 | USDe |
|---|---|---|---|
| Collateral | Yes | Yes | Yes |
| Borrowable | No | No | Yes |
| LTV | Subject to Risk Oracle | Subject to Risk Oracle | Subject to Risk Oracle |
| LT | Subject to Risk Oracle | Subject to Risk Oracle | Subject to Risk Oracle |
| Liquidation Bonus | Subject to Risk Oracle | Subject to Risk Oracle | Subject to Risk Oracle |
References
- Implementation: AaveV3Ethereum
- Tests: AaveV3Ethereum
- Snapshot: Direct-to-AIP
- Discussion
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
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
04Actions
- Target
- 0x00ce…7ca4
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
05Tally
Summed from votes
06Voters
No votes recorded yet.
07Forum
No forum thread is confidently linked to this proposal.
08Similar proposals
- aaveexecutedamend PT-sUSDe september stablecoin emode90%
- aaveexecutedOnboard eUSDe and eUSDe based PT token to Aave V3 Core88%
- aaveexecutedOnboard sUSDe November expiry PT tokens on Aave V3 Core Instance82%
- aaveexecutedOnboard USDe September expiry PT tokens on Aave V3 Core Instance82%
- aaveexecutedOnboard USDe November expiry PT tokens on Aave V3 Core Instance81%
- aaveexecutedOnboard sUSDe and USDe January expiry PT tokens on Aave V3 Plasma Instance81%
- aaveexecutedOnboard sUSDe September expiry PT tokens on Aave V3 Core Instance80%
- aaveexecutedOnboard PT-srUSDe-22OCT2026 to Aave V3 Core80%
- aaveexecutedRaise sUSDe and USDe November expiry PT tokens caps on Aave V3 Core Instance76%
- aaveexecutedOnboard PT-sUSDe-22OCT2026 to Aave v3 Plasma75%