eOracle EOFactory

The ERC4626CappedFeedAdapter contract extends Ownable. However, during deployment and initialization, the initialization function is invoked by the EOFactory contract. As a result, the factory becomes the owner of the adapter rather than the deployer. This ownership discrepancy prevents the deployer from directly controlling the adapter, meaning they cannot invoke the owner-restricted function setMaxYearlyGrowthPercent.

The rate computed by EOPendleLPFeed::_getLPSanityRate can be manipulated. An attacker can temporarily skew the pool composition within a single transaction or block, altering totalPt and totalSy while totalLP remains unchanged. Since the PtToSy rate returned by the TWAP does not immediately reflect such intra-transaction changes, the attacker can artificially inflate or deflate the LPSanityRate depending on the pool tilt direction and the relationship between the actual average execution price (SY per PT) and the TWAP ptToSYRate.

EOPendleLPFeed::latestRoundData relies on the potentially manipulated LPSanityRate to bound the lpToSYRate TWAP. As a result, an attacker could:

• Force a revert by shifting the bounds so that a valid lpToSYRate TWAP falls outside of the accepted range. This could disrupt the oracle and cause denial of service for protocols depending on it.

• Validate a manipulated rate by adjusting the bounds to make an otherwise invalid or manipulated lpToSYRate TWAP appear valid. This undermines the integrity of the oracle, potentially enabling incorrect pricing or misinformed downstream decisions.

In EOLPYAPFeed, the computation of the lpYAPRate for the boosted position relies on the NAV formula (adjustedA * rateFeedA + adjustedB * rateFeedB). While the use of external price feeds protects against direct spot-price manipulation, an attacker can still manipulate the NAV through inventory manipulation. By shifting the pool across multiple bins, the attacker can alter the balances of tokens A and B, thereby skewing the adjustedA and adjustedB values used in the calculation.

This design leaves the rate calculation vulnerable to NAV manipulation despite using external feeds. The practical impact depends on how the oracle is integrated:

• If downstream consumers rely on lpYAPRate for critical pricing or collateralization logic, an attacker could artificially inflate or deflate values, enabling mispricing or exploitation.

• If usage is limited or auxiliary, the manipulation is expected to have minimal impact.

• In EOLPYAPFeed, the latestRoundData function queries two Chainlink feeds to get the prices of the two tokens of the Maverick pool. However, these values and their updatedAt timestamps are not checked for their validity to verify that the prices are positive values or fresh. For example, should any of the feeds return a 0 price, while the other returns a valid price, the oracle will end up calculating its final price based on partial and invalid data.

function latestRoundData() external view returns (...) {
    (int256 rateFeedA, uint8 decimalsFeedA) =
      _getFeedData(tokenAFeed);
    (int256 rateFeedB, uint8 decimalsFeedB) =
      _getFeedData(tokenBFeed);

    ...
    uint256 totalSupply = IERC20(lpYAPToken).totalSupply();
    ...

    int256 lpYAPRate = (
        int256(adjustedA) * rateFeedA / int256(10 ** decimalsFeedA)
      + int256(adjustedB) * rateFeedB / int256(10 ** decimalsFeedB)
    ) * int256(10 ** lpYAPTokenDecimals) / int256(totalSupply);

    return (0, lpYAPRate, 0, block.timestamp, 0);
}

• The same applies to both EOSingleFeedAdapter::latestRoundData and EOMultiFeedAdapter::latestRoundData that fetch prices directly from external price feeds without validating the returned values. One possible feed is Chainlink, which under certain conditions may return a price of zero. Without validation, these zero values are used in internal multiplications and divisions.

function latestRoundData() external view returns (...) {
    int256 rate = numeratorMultiplier;
    ...
    uint256 latestUpdatedAt;
    for (uint256 i = 0; i < baseFeedsLength; i++) {
        (int256 feedRate, uint256 updatedAt) =
          _baseFeeds[i].getRate();
        rate = rate * feedRate;
        ...
    }
    uint256 quoteFeedsLength = _quoteFeeds.length;
    for (uint256 i = 0; i < quoteFeedsLength; i++) {
        (int256 feedRate, uint256 updatedAt) =
          _quoteFeeds[i].getRate();
        rate = rate / feedRate;
        ...
    }
    rate = rate / denominatorMultiplier;
    return (0, rate, 0, latestUpdatedAt, 0);
}

• In EOMultiFeedAdapter::latestRoundData, multiple different feeds are queried for prices, each returning possibly different updatedAt timestamps. To account for this, the contract returns the most recent timestamp as its own price timestamp. However, it would be more accurate for the oracle’s external consumers if the oldest of the timestamps was returned instead to allow them to decide if the returned result can be considered fresh or not.

function latestRoundData() external view returns (...) {
    uint256 latestUpdatedAt;
    for (uint256 i = 0; i < baseFeedsLength; i++) {
        (int256 feedRate, uint256 updatedAt) =
          _baseFeeds[i].getRate();
        ...
        if (updatedAt > latestUpdatedAt) {
            latestUpdatedAt = updatedAt;
        }
    }
    ...
    for (uint256 i = 0; i < quoteFeedsLength; i++) {
        (int256 feedRate, uint256 updatedAt) =
          _quoteFeeds[i].getRate();
        ...
        if (updatedAt > latestUpdatedAt) {
            latestUpdatedAt = updatedAt;
        }
    }
    ...
    return (0, rate, 0, latestUpdatedAt, 0);
}

• In FeedUtils, the getRate function is used to wrap around the different feed types and fetch prices. One of the options is Chainlink feeds. However, if they returned a 0-value updatedAt timestamp, which would possibly indicate an issue with the feed, the value gets replaced with the current block.timestamp hiding any issues from the external consumer. The retrieved timestamp could be forwarded instead, even if 0, to the external receiver or handle it internally as an error.

function getRate(
    IEOFeedAdapterBase.Feed memory feed
) internal view returns (int256 rate, uint256 updatedAt) {
    if (feed.feedInterface == IEOFeedAdapterBase.FeedInterface.
      MINIMAL_AGGREGATOR_V3_INTERFACE) {
        (, rate,, updatedAt,) =
          MinimalAggregatorV3Interface(
            feed.feedAddress).latestRoundData();
    } ...
    if (updatedAt == 0) {
        updatedAt = block.timestamp;
    }
}

In EOMultiFeedAdapter, the maximum value for an int256 is approximately $2^{255} - 1 \simeq 10^{76.7626}$. Allowing up to 64 decimals for intermediate values sets an upper bound on the product of actual prices: $\prod price_i \leq \frac{2^{255} - 1}{10^{64}} \simeq 5.7896 * 10^{12}$.

With 4 base feeds totaling 64 decimals, the geometric mean of the raw prices must be $\leq \sim 1551$ for the multiplication loop to be provably safe. This means deployers need to be very cautious when selecting feed combinations to avoid accidental overflows if the decimals for intermediate values approach 64.

In EOFactory, the _setImplementations function does not verify that the provided array matches the length of the ArtifactType enum. If it has fewer elements, it will revert the operation.

• In EOLPYAPFeed, the comment “The number of bits in a uint256” is incorrect. It could be changed to “Index of the most significant bit (MSB) in a uint256 (0-based)”.
• In EOSpectraPTFeedHybrid, the comment “The address of the Spectra pool” is incorrect. It should be changed to “The address of the Curve pool”

In EOMultiFeedAdapter::initialize, the baseFeeds_ and quoteFeeds_ arrays can both be empty.

In EOFactory, the _setImplementations function checks if the given implementation address is 0x00, which is nevertheless checked by _setImplementation, which is called afterwards.

In EOMultiFeedAdapter, the initialize function is declared as public when all other similar functions in the other implementations have been made external, which we only mention as a minor code consistency comment.

In EOPendlePTFeedLinearDiscount::initialize, you can use the constant ONE instead of the 1e18 number directly in the if (baseDiscountPerYear_ > 1e18) check.

The execution of EOLPYAPFeed::latestRoundData can revert unexpectedly due to a division by zero. The function performs calculations involving totalSupply without verifying that totalSupply != 0.

The EOPendlePTFeedTWAP::initialize code distinguishes only between TWAPType.PT_TO_SY and an implicit else branch, which assumes TWAPType.PT_TO_ASSET. Because twapType is an enum, it cannot presently take an arbitrary value. However, if the enum is extended in a future upgrade (e.g., with additional TWAP types), the else branch would unintentionally handle new values as PT_TO_ASSET, leading to incorrect logic.

There are several enums (e.g., TWAPType, DiscountType, FeedInterface) that are used by the upgradeable EOFactory and the various different adapters in their initializers, and thus one should keep in mind that any change in these enums would require an upgrade to all the contracts that use them in order to make sure that the new values are visible by all implementations. For example, updating EOFactory, but not the underlying implementations would not allow the feed deployments to go through. We only mention this for visibility and awareness.

EOPendlePTFeedTWAP, EOPendleLPFeed and EOPendlePTFeedHybrid configure the TWAP duration of the underlying TWAP oracles. It is understood that the TWAP durations are configurable only by the EOFactory deployer, but it might still be worth enforcing reasonable lower bounds within the various oracles to prevent potential misconfigurations.

In README, it is mentioned that Beacon proxies are also supported by the protocol which does not seem to be the case any more.

The code is compiled with Solidity 0.8.25. Version 0.8.25, in particular, has no known bugs.