Seven Seas A-2

In the PendleExtension.sol, when pricing either a LP, PT or YT token, a rate conversion of the token to underlying asset is received by querying the oracle contract:

if (stor.kind == PendleAsset.LP) {
    uint256 lpToAssetRate = ptOracle.getLpToAssetRate(stor.market, stor.duration);
    return lpToAssetRate.mulDivDown(underlyingAssetInUsd, 10 ** stor.underlyingDecimals);
} else {
    uint256 ptToAssetRate = ptOracle.getPtToAssetRate(stor.market, stor.duration);
    uint256 ptPriceInUsd = ptToAssetRate.mulDivDown(underlyingAssetInUsd, 10 ** stor.underlyingDecimals);
    ...

Reference: PendleExtension.sol#L94-L99

It is assumed that the rate returned has the same decimals as the underlying asset. However, it returns a rate with a range of 0 to 1e18, which means multiplying the underlying price by the rate and dividing by 1e18 will yield the proper conversion. Currently the calculation is divided by the underlying assets decimals, which in most cases is the standard 18 decimals, but when the underlying asset uses non-standard decimals, the price calculation will be wrong.

If these assets are setup improperly, then the cellar would either under or over value the assets and would lead to inaccurate share prices, loss of cellar funds, and/or issues rebalancing positions.

Remediations to Consider

Instead of dividing by the underlying asset’s decimals, divide by 1e18 to properly price these tokens.

In PendleExtension.sol, SY tokens are priced based on the set underlying asset price:

function getPriceInUSD(ERC20 asset) external view override returns (uint256) {
    ExtensionStorage memory stor = extensionStorage[asset];
    uint256 underlyingAssetInUsd = priceRouter.getPriceInUSD(stor.underlying);
    if (stor.kind == PendleAsset.SY) {
        return underlyingAssetInUsd;
    }
    ...

Reference: PendleExtension.sol#L87-L92

However, the balance of SY tokens may be based on a separate asset that appreciates against the expected underlying asset In the case of SY-stETH, the underlying asset used in pricing the related PT, LP, and YT tokens is stETH, but the balance of SY is related to wstETH, as it appreciates against stETH. Since these values differ, SY tokens have a public exchangeRate() function to convert its balance to the underlying asset that the other protocol’s tokens are priced in.

Since the SY exchange rate is not used to price SY tokens, an inaccurate price may be calculated if the underlying asset is set to be the underlying asset of the other related tokens.

Remediations to Consider

Use the SY tokens exchangeRate() function to convert it’s held appreciating asset to the expected underlying. It is important to note that the exchange rate function implementation varies for each SY token and could be inaccurate, permissioned, or return a separate but correlated asset that leads to an accurate price. Caution should be used when setting up pricing for each.

In PendleAdaptor.sol’s redeemPyToSy(), the market’s PT and YT tokens are exchanged for their corresponding SY token. Since typically the same amount of PT and YT tokens are required to receive some SY tokens, if the netPyIn is set to max, it takes the minimum balance of the cellars YT and PT tokens, and sets that as the amount of PT to send in.

function redeemPyToSy(IPendleMarket market, uint256 netPyIn, uint256 minSyOut) external {
    _verifyMarket(market);
    (, address pt, address yt) = market.readTokens();
    ERC20 ptIn = ERC20(pt);
    ERC20 ytIn = ERC20(yt);
    if (netPyIn == type(uint256).max) {
        uint256 ptBalance = ptIn.balanceOf(address(this));
        uint256 ytBalance = ytIn.balanceOf(address(this));
        // Choose the smaller of the two balances.
        netPyIn = ptBalance > ytBalance ? ytBalance : ptBalance;
    }
    ptIn.safeApprove(address(router), netPyIn);
    ytIn.safeApprove(address(router), netPyIn);
    router.redeemPyToSy(address(this), yt, netPyIn, minSyOut);
    _revokeExternalApproval(ptIn, address(router));
    _revokeExternalApproval(ytIn, address(router));
}

Reference: PendleAdaptor.sol#L180-L196

However, in the case the the YT is expired it is not required to redeem SY tokens, since at that point they are not worth anything. It may be common for a cellar to hold PT tokens to maturity and not have a balance of YT. In this case, they could not call redeemPyToSy() using uint.max for netPyIn, since that would set netPyIn to zero, when the balance of PT should be used instead.

Remediations to Consider

Only use the minimum of YT and PT balance for netPyIn if the YT is not expired. This allows a strategist to redeem using a max netPyIn for a matured PT without requiring holding the same amount of worthless corresponding YT.

Each protocol that Pendle integrates has it’s own custom implementation for each of it’s YT, PT, and SY tokens. This can lead to unexpected differences between the behaviour of interacting with these standard functions, since each protocol is unique. Some exchange rates for SY tokens return different assets, have varying trust assumptions, or are less accurate than others. Issues may arise with the implementation of a particular protocol that may prevent interacting with it in the way that the Pendle adaptor or pricing extension expects. Addtional caution should be made when adding pricing or a Pendle token position to ensure it works as expected and is priced appropriately.