Twyne 2026-Q1 update

When maxTwyneLTVs is lowered by governance or when the vault implementation is updated, positions that were healthy under the previous parameter may become immediately liquidatable.

In _collateralScaledByLiqLTV1e8(), the effective liquidation LTV is capped at Math.min(twyneLiqLTV, twyneVaultManager.maxTwyneLTVs(address(intermediateVault))). This value is read from twyneVaultManager at query time, meaning any reduction to maxTwyneLTVs takes effect immediately for all existing positions.

A borrower who opened a position at an LTV just below the previous maxTwyneLTV would find their position suddenly above the new threshold, making them liquidatable. The same applies if the vault implementation is upgraded and the new logic changes how twyneLiqLTV interacts with maxTwyneLTVs.

Low. This requires a governance action to reduce maxTwyneLTVs, which is a privileged operation. However, the absence of a buffer or time-delay mechanism means the effect on existing borrowers is immediate and potentially severe.

Consider implementing a time-delayed parameter change or a grace period during which existing positions are evaluated against the old maxTwyneLTV while new positions use the updated value. Additionally, assess the effects of upgrading the implementation over existing collateral vaults.

Fixed in PR#239.

yAudit: Before deploying the ramp-down feature, verify no existing vault has twyneLiqLTV > maxTwyneLTVs on-chain, as those vaults would have already had their effective LTV reduced instantly by a prior maxTwyneLTVs change and the ramp mechanism cannot retroactively protect them.

The IRMTwyneCurve constructor reuses the E_IRMUpdateUnauthorized() error from the Euler Vault Kit's IIRM interface to signal invalid constructor parameters, which is semantically incorrect and can mislead developers and monitoring tools during debugging.

The constructor validates that polynomialParameter_ and nonlinearPoint_ are non-zero and that nonlinearPoint_ is below 100%. When any of these checks fail, it reverts with E_IRMUpdateUnauthorized():

if (
    polynomialParameter_ == 0
    || nonlinearPoint_ == 0
    || nonlinearPoint_ >= 1e18
) revert E_IRMUpdateUnauthorized();

This error is defined in the IIRM interface and is intended for authorization failures, specifically when msg.sender is not the expected vault (as seen in computeInterestRate()). Using it for parameter validation conflates two distinct failure modes: unauthorized access and invalid input. Off-chain tooling or integrators catching E_IRMUpdateUnauthorized would incorrectly interpret a deployment misconfiguration as an authorization issue.

Informational.

Define a dedicated error (e.g., error E_InvalidIRMParameters()) for the constructor validation and revert with that instead.

Acknowledged.

The _collateralScaledByLiqLTV1e8() return value is passed directly into EulerRouter.getQuote() as the input amount. Since this value is already scaled by the LLTV (in 1e8 precision), the oracle must price it linearly — any non-linear pricing behavior would produce incorrect collateral valuations.

In EulerCollateralVault._canLiquidate(), the collateral value used for liquidation checks is computed by calling getQuote() with the output of _collateralScaledByLiqLTV1e8(false, adjExtLiqLTV). This value equals the user's collateral multiplied by a liquidation LTV factor at 1e8 precision. The oracle receives this scaled quantity and is expected to convert it to the unit of account.

If the oracle's getQuote() implementation is not linear in the input amount (i.e., getQuote(k * x) != k * getQuote(x)), the resulting collateral valuation will be incorrect.

Informational.

Document the linearity requirement for Oracles used with getQuote() in this context. Consider adding a comment or NatSpec annotation at the oracle configuration point to alert of this behavior.

Fixed in PR#242.

The @dev comment on _invariantCollateralAmount() describes the formula as ceil(userCollateral * twyneLiqLTV * MAXFACTOR / (externalLiqLTV * buffer)), but the actual computation now uses a dynamic liquidation LTV model introduced with the Dynamic Liquidation LTV update.

The NatSpec comment on _invariantCollateralAmount() in CollateralVaultBase references an older, static formula. The current implementation uses a dynamic LTV derived from the credit reservation invariant (C · λ̃^dyn_t = β_safe · λ̃_e · (C_LP + C)), as implemented in _collateralScaledByLiqLTV1e8().

Informational.

Update the @dev comment on _invariantCollateralAmount() to reflect the dynamic liquidation LTV formula currently in use.

Fixed in PR#242.

The credit handling logic in EulerCollateralVault.sol#L87 and AaveV3CollateralVault.sol#L140 is identical. The only difference is the Aave override mixing in rebalanceATokens_CV, which is aToken wrapper bookkeeping — not credit handling.

Informational. Duplicated logic increases divergence risk — PR #243's bugfix had to be applied to both files independently.

Move the shared logic into CollateralVaultBase. Aave can overrides with a simple super._handleExcessCredit(...) + rebalanceATokens_CV.

Acknowledged.

VaultManager.setIntermediateVault() sets isIntermediateVault[vault] = true but there is no function to set it back to false. Once registered, an intermediate vault cannot be removed from the approved set.

Informational. If an intermediate vault needs to be deprecated, it will remain permanently valid in isIntermediateVault.

Add a bool value parameter to the function and set the mapping with it.

Fixed in PR#252.