As reiterated numerous times, Chaos Labs is providing a Risk Oracle, while the actual pricing component within the system is done through @BGDLabs. Edge is providing a rate, based on the algorithm and risk framework detailed above, created in conjunction with the asset issuer, Pendle.
Chaos Labs Risk and Edge have been integral to Aave for the past two years, operating across every network through Risk Stewards. Rather than introducing a new concept, Edge streamlines and enhances this existing framework, enabling the necessary scale to support Aave’s 25+ deployments. With the DAO already voting in favor of Edge, it is now live and actively contributing to Aave’s risk management. Given the complexity and scale of Aave’s ecosystem, effective risk management would not be possible without Edge Risk Oracles, which play a crucial role in ensuring system integrity and scalability.
Building on this infrastructure, the proposed PT oracle emerges as the most effective and optimal solution for this asset class. Moreover, the technical risks associated with its integration are minimal, with a systemic nature that remains largely abstracted from traditional decentralization and liveness concerns. The specific setup of such a system is not new to Aave, as explored further below.
Technical Risks
Unlike continuous systems that require stringent liveness contingencies, this system operates in a highly discrete manner, generating updates once every 24 hours. The underlying algorithm for deriving the risk oracle’s components is designed with this structure in mind. Even in scenarios of sharp and sudden rate volatility, the system does not automatically adjust its reports to reflect such fluctuations in real-time. Instead, the risk oracle represents a factual market rate averaged over a significant period. Consequently, liveness concerns are significantly mitigated, as the marginal difference between an immediate update and one triggered slightly later has little impact on the overall outcome.
Additionally, the ingested rate naturally converges toward a stable price value, regardless of whether a rate update occurs. Even in the absence of any updates, the price at maturity would still align with its anchored value (1:1). The system’s deeply integrated risk parameterization is designed to respond dynamically to this convergence, ensuring that, under any rate update, it remains mathematically safeguarded against bad debt. This tight linkage between rate updates and risk parameterization reinforces the system’s resilience, positioning risk management as the foundational backbone of its design.
From a technical standpoint, robust fallback mechanisms mitigate risks in the event of an Oracle failure. Any rate update written on-chain is strictly constrained and cannot exceed the maxRate parameter embedded within the smart contract developed by BGD, akin to a CAPO implementation. As previously mentioned, this constraint ensures that no adverse scenarios arise for Aave, as the rate is derived through a rigorous risk framework.
On the LT/LB side, the smart contract enforces an additional safeguard, limiting updates to a highly constrained maximum every 24 hours, regardless of market conditions. This tightly controlled framework, combined with the system’s interconnected mechanics, ensures seamless operation without risk exposure to the DAO.
Alternative Aave Oracle Implementations
It’s important to once again note that, despite claims to the contrary, Chainlink is not the sole price provider for Aave in all realms, especially in the context of deriving exchange rates. This principle applies to most LSTs and LRTs, as well as sUSDe, where the exchange rate is fundamentally derived directly through native smart contracts. For sUSDe and LSTs like wstETH, this process is relatively straightforward, whereas, for LRTs, it often involves more complex mechanisms to account for additional layers of staking and reward distribution.
For instance, Aave derives rsETH’s exchange rate through its LRTOracle, which calculates asset value as staked assets in ETH / rsETH supply. The system queries getTotalAssetDeposits() to retrieve staked amounts from the Deposit Pool, Node Delegator Contracts, and EigenLayer, then multiplies them by their respective, centrally derived exchange rates (for LSTs such as wstETH and ETHx) or 1 (for native ETH). As such, the system fully relies on Kelp, the asset issuer, to derive the exchange rate component through a structured and intricate process. During an adverse scenario such as a slashing event, this system would be required to algorithmically report the associated exchange rate decrease, regardless of network congestion or the occurrence of black swan events.
Expanding on this, rsETH enables minting on L2s such as Arbitrum, utilizing the internally derived exchange rate to facilitate the process. To ensure accurate cross-chain pricing, the system leverages interoperability providers like LayerZero, chosen by the asset issuer, to securely and efficiently transmit the rsETH/ETH exchange rate across networks. Aave will then ingest this exchange rate to accurately price the asset within its ecosystem.
Decentralization Concerns
As @BGDLabs has noted, the centralization inherent in these processes for deriving the exchange rate—driven by the asset issuer through EOA or low-quorum multi-sig access control—necessitates external risk mechanisms like CAPO, which mitigate manipulation risks by capping the maximum per-second and annual growth of an asset’s exchange rate. This is functionally similar to the aforementioned on-chain constraints inherent within this risk oracle. Given the previously mentioned considerations regarding liveness and technical risk—and the fact that the system is mathematically designed to function without strict dependencies on sharp movements—the quality of the provided rates is governed by Chaos, while verification and validation are embedded within smart contracts developed by BGD. Ultimately, pricing is determined by the BGD contract itself.
In this context, further decentralization wrappers do not improve the quality of the solution. While Edge is set to transition to a decentralized model in the coming weeks, our commitment to transparency has been clear from the outset. Decentralization, in this sense, is upheld through governance-approved bounds and contract-enshrined checks, preventing any single provider from unilaterally dictating parameters, akin to the CAPO implementation. In contrast, price oracles rely on consensus to mitigate the risk of front-running. Functionally, multiple nodes verifying a signature offer no advantage over on-chain validation by the BGD contract, as both ensure the same level of security and reliability. Ultimately, it is the economic constraints and risk methodology that serve as the key deterrents against adverse outcomes.