From b5fef3dc37c1c9d1c3d9b6da32ffe3a6ac03b642 Mon Sep 17 00:00:00 2001 From: mkflow27 Date: Tue, 23 Jul 2024 17:28:15 +0200 Subject: [PATCH 1/3] Kernel Rate Providers Fixes #100 --- rate-providers/KernelProtocolRateProviders.md | 59 +++++++++++++++++++ rate-providers/registry.json | 23 ++++++++ 2 files changed, 82 insertions(+) create mode 100644 rate-providers/KernelProtocolRateProviders.md diff --git a/rate-providers/KernelProtocolRateProviders.md b/rate-providers/KernelProtocolRateProviders.md new file mode 100644 index 0000000..37de313 --- /dev/null +++ b/rate-providers/KernelProtocolRateProviders.md @@ -0,0 +1,59 @@ +# Rate Provider: `krETHRateProvider` & `ksETHRateProvider` + +## Details +- Reviewed by: @mkflow27 +- Checked by: @\ +- Deployed at: + - [ethereum:0x8fDDab48DD17dDCeD87730020F4213528042dba3](https://etherscan.io/address/0x8fDDab48DD17dDCeD87730020F4213528042dba3#code) + - [ethereum:0x1A9fA10CA260387314185B9D7763164FD3D51226](https://etherscan.io/address/0x1A9fA10CA260387314185B9D7763164FD3D51226#code) +- Audit report(s): + - [Kernel audits](https://drive.google.com/file/d/1MqenDKmDDb6OcsG-0YTlQAwlfFndSk7J/view) + +## Context +Kernel Protocol will be offering a suite of Karak Native LRTs that allow users to restake assets on Karak and receive LRT tokens that can be deployed in further yield-bearing DeFi activities. This rate provider is essentially a wrapper with some modifications around `WeETH`. krETHRateProvider calls weETHRateProvider which calls `WeETH`. The same is true for ksETHRateProvider. This rate provider calls into a wstETHRateProvider, which calls into wsteth. + +## Review Checklist: Bare Minimum Compatibility +Each of the items below represents an absolute requirement for the Rate Provider. If any of these is unchecked, the Rate Provider is unfit to use. + +- [x] Implements the [`IRateProvider`](https://github.com/balancer/balancer-v2-monorepo/blob/bc3b3fee6e13e01d2efe610ed8118fdb74dfc1f2/pkg/interfaces/contracts/pool-utils/IRateProvider.sol) interface. +- [x] `getRate` returns an 18-decimal fixed point number (i.e., 1 == 1e18) regardless of underlying token decimals. + +## Review Checklist: Common Findings +Each of the items below represents a common red flag found in Rate Provider contracts. + +If none of these is checked, then this might be a pretty great Rate Provider! If any of these is checked, we must thoroughly elaborate on the conditions that lead to the potential issue. Decision points are not binary; a Rate Provider can be safe despite these boxes being checked. A check simply indicates that thorough vetting is required in a specific area, and this vetting should be used to inform a holistic analysis of the Rate Provider. + +### Administrative Privileges +- [ ] The Rate Provider is upgradeable (e.g., via a proxy architecture or an `onlyOwner` function that updates the price source address). + +- [x] Some other portion of the price pipeline is upgradeable (e.g., the token itself, an oracle, or some piece of a larger system that tracks the price). + #### krETHRateProvider + - upgradeable component: `WeETH` ([ethereum:0xCd5fE23C85820F7B72D0926FC9b05b43E359b7ee](https://etherscan.io/address/0xCd5fE23C85820F7B72D0926FC9b05b43E359b7ee)) + - admin address: [ethereum:0xcdd57D11476c22d265722F68390b036f3DA48c21](https://etherscan.io/address/0xcdd57D11476c22d265722F68390b036f3DA48c21#readProxyContract) + - admin type: multisig + - multisig threshold/signers: 4/7 + - multisig timelock? YES: 3 days + +### Oracles +- [x] Price data is provided by an off-chain source (e.g., a Chainlink oracle, a multisig, or a network of nodes). + - comment: The explanation of how oracles are involved in the rate setting can be found in the review for `WeETH` [here](./WeETH.md). + +- [ ] Price data is expected to be volatile (e.g., because it represents an open market price instead of a (mostly) monotonically increasing price). + +### Common Manipulation Vectors +- [ ] The Rate Provider is susceptible to donation attacks. + +## Additional Findings +To save time, we do not bother pointing out low-severity/informational issues or gas optimizations (unless the gas usage is particularly egregious). Instead, we focus only on high- and medium-severity findings which materially impact the contract's functionality and could harm users. + +### M-01: Missing rate exposure of LSTs used to mint LRTs. +> ksETH: Restake any ETH-denominated LST accepted by Karak (eg Lido’s stETH, Rocket Pool’s rETH etc) via Kernel Protocol to receive our ksETH LRT that can be deployed in further yield-bearing activities. [source](https://medium.com/@vectorreserve/introducing-kernel-protocol-the-first-suite-of-karak-native-lrts-unlocking-liquidity-yields-for-993f4995249d). +For the example of ksETH, the rateProvider exposes the rate based on wsteth's rate. Since the documentation for Kernel states that multiple LSTs can be used to mint ksETH, the rate reported by the ksETHRateProvider does not take into account the distribution of LSTs backing ksETH. The same logic applies to krETH. + +### M-02: Missing rate exposure of LSTs used to mint LRTs. +Kernel protocol uses Karak to mint LRTs to the user. Karak is a restaking protocol with the intention to generate yield for depositors. However this yield source is not accounted for in the rate providers. This means there is a deviation in rate reported by the rate provider and true rate generated. This will generate arbitrage opportunities between the pool and the protocol around the mint/redeem price. + +## Conclusion +**Summary judgment: ** + +The Kernel protocol rate providers should work well with Balancer pools on a technical. They are essentially wrappers around downstream rate computations and expose this data as part of their onchain scope. However, the rate reported might be inaccurate if multiple LSTs/LRTs are used as deposit assets and if Karak generates yield, the rate reported and the true rate will deviate. diff --git a/rate-providers/registry.json b/rate-providers/registry.json index 6a5213f..6d2a921 100644 --- a/rate-providers/registry.json +++ b/rate-providers/registry.json @@ -1172,6 +1172,29 @@ "implementationReviewed": "0xaf108ae0AD8700ac41346aCb620e828c03BB8848" } ] + }, + "0x8fDDab48DD17dDCeD87730020F4213528042dba3": { + "asset": "", + "name": "krETHRateProvider", + "summary": "", + "review": "./KernelProtocolRateProviders.md", + "warnings": [""], + "factory": "", + "upgradeableComponents": [ + { + "entrypoint": "0xCd5fE23C85820F7B72D0926FC9b05b43E359b7ee", + "implementationReviewed": "0xe629ee84C1Bd9Ea9c677d2D5391919fCf5E7d5D9" + } + ] + }, + "0x1A9fA10CA260387314185B9D7763164FD3D51226": { + "asset": "", + "name": "ksETHRateProvider", + "summary": "", + "review": "./KernelProtocolRateProviders.md", + "warnings": [""], + "factory": "", + "upgradeableComponents": [] } }, "fantom": { From 0b1aae699c7aa352719091234954148aca4835d9 Mon Sep 17 00:00:00 2001 From: mkflow27 Date: Wed, 24 Jul 2024 10:14:29 +0200 Subject: [PATCH 2/3] Kernel Rate Providers Fixes #100 --- rate-providers/KernelProtocolRateProviders.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/rate-providers/KernelProtocolRateProviders.md b/rate-providers/KernelProtocolRateProviders.md index 37de313..ce2c620 100644 --- a/rate-providers/KernelProtocolRateProviders.md +++ b/rate-providers/KernelProtocolRateProviders.md @@ -10,7 +10,7 @@ - [Kernel audits](https://drive.google.com/file/d/1MqenDKmDDb6OcsG-0YTlQAwlfFndSk7J/view) ## Context -Kernel Protocol will be offering a suite of Karak Native LRTs that allow users to restake assets on Karak and receive LRT tokens that can be deployed in further yield-bearing DeFi activities. This rate provider is essentially a wrapper with some modifications around `WeETH`. krETHRateProvider calls weETHRateProvider which calls `WeETH`. The same is true for ksETHRateProvider. This rate provider calls into a wstETHRateProvider, which calls into wsteth. +Kernel Protocol will be offering a suite of Karak Native LRTs that allow users to restake assets on Karak and receive LRT tokens that can be deployed in further yield-bearing DeFi activities. The rate providers in this review are essentially wrappers of downstream LST/LRT rate providers. krETHRateProvider calls weETHRateProvider which calls `WeETH`. The same is true for ksETHRateProvider, which calls into a wstETHRateProvider, which calls into wsteth. ## Review Checklist: Bare Minimum Compatibility Each of the items below represents an absolute requirement for the Rate Provider. If any of these is unchecked, the Rate Provider is unfit to use. @@ -48,7 +48,8 @@ To save time, we do not bother pointing out low-severity/informational issues or ### M-01: Missing rate exposure of LSTs used to mint LRTs. > ksETH: Restake any ETH-denominated LST accepted by Karak (eg Lido’s stETH, Rocket Pool’s rETH etc) via Kernel Protocol to receive our ksETH LRT that can be deployed in further yield-bearing activities. [source](https://medium.com/@vectorreserve/introducing-kernel-protocol-the-first-suite-of-karak-native-lrts-unlocking-liquidity-yields-for-993f4995249d). -For the example of ksETH, the rateProvider exposes the rate based on wsteth's rate. Since the documentation for Kernel states that multiple LSTs can be used to mint ksETH, the rate reported by the ksETHRateProvider does not take into account the distribution of LSTs backing ksETH. The same logic applies to krETH. + +For the example of ksETH, the rateProvider exposes the rate based on wsteth's rate. Since the documentation for Kernel states that multiple LSTs can be used to mint ksETH (apxETH, cbETH, rETH, swETH, wstETH), the rate reported by the ksETHRateProvider does not take into account the distribution of LSTs backing ksETH. The same logic applies to krETH. ### M-02: Missing rate exposure of LSTs used to mint LRTs. Kernel protocol uses Karak to mint LRTs to the user. Karak is a restaking protocol with the intention to generate yield for depositors. However this yield source is not accounted for in the rate providers. This means there is a deviation in rate reported by the rate provider and true rate generated. This will generate arbitrage opportunities between the pool and the protocol around the mint/redeem price. From b374b903ee4b750631c9bfe1589800bdecef6885 Mon Sep 17 00:00:00 2001 From: mkflow27 Date: Wed, 24 Jul 2024 10:15:45 +0200 Subject: [PATCH 3/3] add missing word --- rate-providers/KernelProtocolRateProviders.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rate-providers/KernelProtocolRateProviders.md b/rate-providers/KernelProtocolRateProviders.md index ce2c620..aeefa92 100644 --- a/rate-providers/KernelProtocolRateProviders.md +++ b/rate-providers/KernelProtocolRateProviders.md @@ -57,4 +57,4 @@ Kernel protocol uses Karak to mint LRTs to the user. Karak is a restaking protoc ## Conclusion **Summary judgment: ** -The Kernel protocol rate providers should work well with Balancer pools on a technical. They are essentially wrappers around downstream rate computations and expose this data as part of their onchain scope. However, the rate reported might be inaccurate if multiple LSTs/LRTs are used as deposit assets and if Karak generates yield, the rate reported and the true rate will deviate. +The Kernel protocol rate providers should work well with Balancer pools on a technical level. They are essentially wrappers around downstream rate computations and expose this data as part of their onchain scope. However, the rate reported might be inaccurate if multiple LSTs/LRTs are used as deposit assets and if Karak generates yield, the rate reported and the true rate will deviate.