-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Yield Fi yUSD Rate Providers #252
Changes from all commits
78d7849
0bbc74b
44356a0
8e3415a
92830f0
510a1b3
7f96523
968d41b
598d084
e87a88f
4bfb532
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,59 @@ | ||
# Rate Provider: ERC4626RateProvider | ||
|
||
## Details | ||
- Reviewed by: @brunoguerios | ||
- Checked by: @mkflow27 | ||
- Deployed at: | ||
- [ethereum:0xa65ffBa1CD05414df3fD24Bf5dc319B47450Fbf4](https://etherscan.io/address/0xa65ffBa1CD05414df3fD24Bf5dc319B47450Fbf4) | ||
- Audit report(s): | ||
- [Protocol Audits](https://docs.yield.fi/resources/audits) | ||
|
||
## Context | ||
This rate provider works with a standard approach of `totalAssets/totalSupply`. | ||
|
||
## 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 usable 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). | ||
|
||
- upgradeable component: `YToken` ([ethereum:0x1CE7D9942ff78c328A4181b9F3826fEE6D845A97](https://etherscan.io/address/0x1CE7D9942ff78c328A4181b9F3826fEE6D845A97#code)) | ||
- admin address: [ethereum:0x7c2c44a988E0B74bcaE644fC8cD1200fcF727001](https://etherscan.io/address/0x7c2c44a988E0B74bcaE644fC8cD1200fcF727001) | ||
- multisig threshold/signers: 2/4 | ||
--- | ||
- upgradeable component: `Administrator` ([ethereum:0x9305a0cc13293b69deE0B9d281D21144b029BdFf](https://etherscan.io/address/0x9305a0cc13293b69deE0B9d281D21144b029BdFf#code)) | ||
- admin address: [ethereum:0x7c2c44a988E0B74bcaE644fC8cD1200fcF727001](https://etherscan.io/address/0x7c2c44a988E0B74bcaE644fC8cD1200fcF727001) | ||
- multisig threshold/signers: 2/4 | ||
--- | ||
- upgradeable component: `Yield` ([ethereum:0xf4eF3ba63593dfD0967577B2bb3C9ba51D78427b](https://etherscan.io/address/0xf4eF3ba63593dfD0967577B2bb3C9ba51D78427b#code)) | ||
- admin address: [ethereum:0x7c2c44a988E0B74bcaE644fC8cD1200fcF727001](https://etherscan.io/address/0x7c2c44a988E0B74bcaE644fC8cD1200fcF727001) | ||
- multisig threshold/signers: 2/4 | ||
|
||
|
||
### Oracles | ||
- [ ] Price data is provided by an off-chain source (e.g., a Chainlink oracle, a multisig, or a network of nodes). | ||
|
||
- [ ] 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. | ||
|
||
No additional findings. | ||
|
||
## Conclusion | ||
**Summary judgment: USABLE** | ||
|
||
Rate provider is a standard ERC4626RateProvider that relies on totalAssets/totalSupply. All other contracts in the pipeline that are upgradeable and can directly influence the rate are managed by multisigs. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,52 @@ | ||
# Rate Provider: `ChainlinkRateProvider` | ||
|
||
## Details | ||
- Reviewed by: @brunoguerios | ||
- Checked by: @mkflow27 | ||
- Deployed at: | ||
- [arbitrum:0xb1D5c23DbfCb36864f32bc704AE4205BB9720C33](https://arbiscan.io/address/0xb1D5c23DbfCb36864f32bc704AE4205BB9720C33) | ||
- Audit report(s): | ||
- [Protocol Audits](https://docs.yield.fi/resources/audits) | ||
|
||
## Context | ||
This RateProvider is updated via the API3 product. It reports the exchangeRate of yUSD/USD on mainnet. It is read on mainnet and available as an Oracle on arbitrum. | ||
|
||
## 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 usable 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). | ||
- upgradeable component: `Api3ReaderProxyV1` ([arbitrum:0xE88DA976479461080072D6461128fd401B6D4Dcb](https://arbiscan.io/address/0xE88DA976479461080072D6461128fd401B6D4Dcb#readProxyContract)) | ||
- admin address: [arbitrum:0x2AAE699ed04BBbD068f67a5b3C813eBB35f2c9E8](https://arbiscan.io/address/0x2AAE699ed04BBbD068f67a5b3C813eBB35f2c9E8) | ||
- admin type: multisig | ||
- multisig threshold/signers: 4/8 | ||
- multisig timelock? NO | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I couldn't find timelocks in the implementation, but if it's too relevant, it would be nice if you could double check. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not every system has them. They are helpful for the reader to have but not a requirement. |
||
|
||
### Oracles | ||
- [x] Price data is provided by an off-chain source (e.g., a Chainlink oracle, a multisig, or a network of nodes). | ||
- source: API3. | ||
- source address: The data is sourced from multiple so called "beacons" which are a set of nodes which provide the rate data to be aggregated by the `Api3ServerV1` [base:0x709944a48cAf83535e43471680fDA4905FB3920a](https://arbiscan.io/address/0x709944a48cAf83535e43471680fDA4905FB3920a) | ||
- any protections? The rate is calculated as the median of all the rate data "fetched" from beacons. For more information about more protections see [api3 docs](https://docs.api3.org/reference/dapis/understand/deviations.html) and consult the `updateBeaconSetWithBeacons` & `updateOevProxyDataFeedWithSignedData` functions. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Same here about not fully grasping API3 and replicating ezETH findings. Please confirm 🙏 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Fine to leave it like this. |
||
|
||
- [ ] 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. | ||
|
||
## Conclusion | ||
**Summary judgment: USABLE** | ||
|
||
This rate provider should work well with Balancer pools. API3 updates the rate on arbitrum regularly and has various protections in place to ensure the correct values are bridged accurately. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,52 @@ | ||
# Rate Provider: `ChainlinkRateProvider` | ||
|
||
## Details | ||
- Reviewed by: @brunoguerios | ||
- Checked by: @mkflow27 | ||
- Deployed at: | ||
- [base:0xD47c15CDD7c734db321F07CB9AB1f852aE9A0b83](https://basescan.org/address/0xD47c15CDD7c734db321F07CB9AB1f852aE9A0b83) | ||
- Audit report(s): | ||
- [Protocol Audits](https://docs.yield.fi/resources/audits) | ||
|
||
## Context | ||
This RateProvider is updated via the API3 product. It reports the exchangeRate of yUSD/USD on mainnet. It is read on mainnet and available as an Oracle on base. | ||
|
||
## 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 usable 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). | ||
- upgradeable component: `Api3ReaderProxyV1` ([base:0xE88DA976479461080072D6461128fd401B6D4Dcb](https://basescan.org/address/0xE88DA976479461080072D6461128fd401B6D4Dcb#code)) | ||
- admin address: [base:0x2AAE699ed04BBbD068f67a5b3C813eBB35f2c9E8](https://basescan.org/address/0x2AAE699ed04BBbD068f67a5b3C813eBB35f2c9E8) | ||
- admin type: multisig | ||
- multisig threshold/signers: 4/8 | ||
- multisig timelock? NO | ||
|
||
### Oracles | ||
- [x] Price data is provided by an off-chain source (e.g., a Chainlink oracle, a multisig, or a network of nodes). | ||
- source: API3. | ||
- source address: The data is sourced from multiple so called "beacons" which are a set of nodes which provide the rate data to be aggregated by the `Api3ServerV1` [base:0x709944a48cAf83535e43471680fDA4905FB3920a](https://basescan.org/address/0x709944a48cAf83535e43471680fDA4905FB3920a#code) | ||
- any protections? The rate is calculated as the median of all the rate data "fetched" from beacons. For more information about more protections see [api3 docs](https://docs.api3.org/reference/dapis/understand/deviations.html) and consult the `updateBeaconSetWithBeacons` & `updateOevProxyDataFeedWithSignedData` functions. | ||
|
||
- [ ] 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. | ||
|
||
## Conclusion | ||
**Summary judgment: USABLE** | ||
|
||
This rate provider should work well with Balancer pools. API3 updates the rate on base regularly and has various protections in place to ensure the correct values are bridged accurately. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I must say I'm not able to fully grasp this API3 data source, but I'm assuming it's a standard and I replicated the findings registered on the ezETH rate provider review.
Can you guys please confirm this is indeed the case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey Bruno. Gerally speaking whenever we first took a look at a new oracle rate provider, they were reviewed as part of the review. After that if the rate is a "direct" result of a oracle price provider, we have marked it as usable. This includes oracle such as:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In cases like this, you can refer to the review already being done at review